On Thu, 2003-10-16 at 21:26, Martin Stecher wrote:
If an OCP agent receives transfer-encoded application data
in violation of the above requirement, the agent MAY
terminate
the corresponding OCP transaction.
I prefer MUST terminate. It will make things cleaner - there is little
benefit in having an undefined behaviour, when we have explicit
requirement for negotiation already there (three paragraphs up :}).
I think MAY is better. Think about a callout service which is not dealing with
the message body at all. We should not force it to implement checks for
protocol
correctness of the peer, if it works even with the violation.
It depends. If we adopt some or all of the TE HTTP specs for OCP, then
correct behaviour will depend on protocol correctness.
If we don't have TE at all - just use the size prefixed DUM messages
with the identity data, then TE will not appear in any OCP message
because the OCP client will have stripped it to get to the identity.
So, I think its simple: if we use TE, we need to use it correctly. If we
don't use TE, then there's no issue, and the rules can be very simple:
0) All Hop by Hop protocol headers, for any adapted protocol MUST be
removed before handoff to the OCP agent. Any relevant data from those
headers MAY be presented in the appropriate OCP message header as
appropriate.
I.e. an HTTP adaptation service that expects to receive uploads will
always recieve them without any transfer encodings applied. OCP doesn't
provide a message encoding mechanism.
Rob
--
GPG key available at: <http://members.aardvark.net.au/lifeless/keys.txt>.