Subject: RE: sizep parameter again

From: "Martin Stecher" <[email-masked]>
Date: Sat, 18 Oct 2003 19:55:44 +0200

> 
> > Yes, we should add AM-CLP.
> > For the HTTP request profile this is the predicted length of the
> > request-body message part.
> > For the HTTP response profile this is the predicted length of the
> > response-body message part. Correct?
> 
> Let's avoid confusions of RFC 2616 terminology in sections 4.4 Message
> Length and 14.13 Content-Length and use Section 7.2.2 Entity Length
> terminology instead. This will let us to be more precise.

Though I do not see this as critical right now as we do not have transfer-
codings, I agree that entity-length is more correct and should be used.

> Also, note
> that "predictions" are usueless in this context because HTTP does not
> support them. If we do not know future length for sure, we should not
> be producing a Content-Length header.

You are right.

> 
> Let's call the HTTP-specific OCP named parameter "AM-EL" (application
> message entity length):

ok. I will create a new section and introduce this parameter for AMS.

> 
> 	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?"

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.

>     An OCP Agent that does not know the exact
> 	length of the HTTP message entity, MUST NOT include an AM-EL
> 	named parameter in AMS message. Informally, an abcent
> 	AM-EL parameter in an AMS message means that the entity
> 	length is not known a priory

Good.

>     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.

> 
> 	An OPES processor receiving an AM-EL parameter MAY use
> 	parameter value in a Content-Length HTTP entity header
> 	when constructing an HTTP message (provided a
> 	Content-Length HTTP entity header is allowed for the
> 	given application message by HTTP) and MAY forward it to
> 	the next callout service (if any). Whether a processor
> 	will use and forward AM-EL parameter depends primarily on
> 	how much it trusts the service to produce correct AM-EL
> 	values. Using and forwarding correct AM-EL values is
> 	important for HTTP and OCP pipelining optimizations.
> 
> I am not so sure about the second paragraph. Perhaps the MUST NOT in
> the first paragraph is sufficient to replace all MAYs in the second
> paragraph with SHOULDs? Note that not using or not sending AM-EL does
> not break interoperability, so we cannot say MUST send/use/forward.
> Not using or not sending AM-EL breaks the OCP pipeline only. Thus, we
> can say SHOULD send/use/forward or MAY send/use/forward, probably
> depending on how many implementions are expected to send incorrect
> AM-ELs.

I think the specs should presume that most implementations are sending
correct AM-ELs. Therefore I vote for SHOULD.
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.

> 
> > I suggest that the AM-CLP is not decreased from DUM to DUM message
> > such as sizep. Is it suitable to make it a parameter of the AMS
> > message and not of DUM messages?
> 
> Yes, it is mostly useless in DUM messages. Let's make it
> AMS-exclusive.

Agreed.

> 
> > Is there then a useful purpose of sizep? I am not sure. I tend to
> > agree that AM-CLP could replace sizep. The only purpose I can think
> > of is to allow the peer to prepare some buffer size for all
> > application data. I don't think that this will be necessary for HTTP
> > adaption but it may make sense for other application bindings. Maybe
> > we just leave sizep in. If it does not help, it does not hurt either
> > as an optional parameter. What do you think?
> 
> I will be removing sizep from the Core. If we cannot think of a
> general purpose for it, it should not be there. Applications that need
> it will document it.

Fine with me.

Regards
Martin

---

From: Alex Rousskov <[email-masked]>
Date: Sun, 19 Oct 2003 20:48:18 -0600 (MDT)

> "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:
>

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.

> 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.

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.