On Fri, 17 Oct 2003, Martin Stecher wrote:
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. 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.