Subject: RE: sizep parameter again

From: "Martin Stecher" <[email-masked]>
Date: Fri, 17 Oct 2003 23:21:08 +0200

> 
> 	I think you've raised two important design questions that must
> be addressed explicitly, possibly in OCP Core (in part).
> 
> 	(1) We need to be more clear what is being adapted, what is
> being supplied for information purposes only, what is being skipped,
> what is potentially stale and must be checked by processor (and when
> the checks are made).

Yes.

> 
> 	(2) We need a "content" size prediction for performance
> reasons, but we do not have a definition of "content", only data.
> Sizep seems to be useless. A new parameter, tied to the "content"
> definition is needed. "Content" definition should probably be
> application-specific and negotiable.

I agree.

> ...

> 
> > Putting all this together, I feel that using the sizep parameter for
> > Content-Length indication does not really work.
> 
> I agree.
> 
> > Shouldn't we better introduce a Content-Length named parameter to
> > AMS messages that does what we really want: Promise a length that
> > can be used for HTTP Content-Length header correction?
> 
> Does sizep have any useful purpose at the lower (application data)
> level it is being used right now? Should we delete sizep from the Core
> and add AM-CLP parameter instead (application message content length
> prediction)?
> 

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?

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?

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?

Martin

---

From: Alex Rousskov <[email-masked]>
Date: Fri, 17 Oct 2003 16:29:27 -0600 (MDT)

On Fri, 17 Oct 2003, Martin Stecher wrote:

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

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

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

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

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

Alex.