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