RE: sizep parameter again

[Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>]

On Sat, 18 Oct 2003, Martin Stecher wrote:

> > 	An OCP Agent that knows the exact length of the	HTTP
> > 	message entity (Section 7.2.2 Entity Length in RFC 2616),
> > 	SHOULD announce that length using an AM-EL named parameter
> > 	of an AMS message.
>
> May I quote you here, Alex? ;-)
> You wrote on June, 2nd:
> "Why not a MUST? If something so important is known, why not report it?"

:-) Answering my own question here, apparently: if NOT doing the
required action does not lead to interoperability problems, it is a
SHOULD, not a MUST. But this is all very fuzzy, of course. If you
prefer a MUST, I would not argue (for a few months, anyway).

> What I am missing in this description is the mention of the adapted
> message part. As you already pointed out earlier, we have to make it
> very clear what length we are talking about. If, for example, an
> OPES processor is sending a HTTP message for response modification
> with request-body as optional part and skipping the response- body
> part, the AM-EL parameter must still specify the size of the
> response body length and not of the request body length.
>
> How about this:
>
>   An OCP Agent that knows the exact length of the HTTP
>   message entity (Section 7.2.2 Entity Length in RFC 2616)
>   at the time it sends the AMS message, MUST announce that
>   length using an AM-EL named parameter of an AMS message.
>   In the HTTP request profile AM-EL is the length of the
>   request-body part and in the HTTP response profile the
>   length of the response-body part each before any
>   transfer-codings have been applied.

I agree that we have to be specific. Your version is fine. It might be
better to document "entity" when we document "profiles" instead of
piggibacking entity definition to this requirement, but this is up to
you.

> >     an OPES processor would
> > 	have to use chunked transfer-encoding or terminate
> > 	the HTTP connection after sending the adapted HTTP message
> > 	to the next HTTP hop.
>
> This is not always true. OPES processor could wait for the
> transaction to complete (on cost of latency) or close the
> connection. It's a little tricky and their is no general advice. I
> tried to discuss this is the draft in the section Message Header
> Correctness, subsection about Message Length. It's not yet perfect
> and needs polishing but I think it is better to have a separate
> section about this.

Agreed.

> I think the specs should presume that most implementations are sending
> correct AM-ELs. Therefore I vote for SHOULD.

Agreed.

> Again, I would prefer to keep this short in the (new) section that
> will introduce AM-EL and have the detailed description in the
> message length section.

Agreed.

Alex.