Subject: RE: transfer- and content-encoding

From: "Martin Stecher" <[email-masked]>
Date: Thu, 16 Oct 2003 13:26:01 +0200

Hi,

> > 
> > 	Adaptations that use HTTP transfer-encodings MUST be
> > 	explicitly negotiated. This specification does not document
> > 	such negotiations.
> 
> Yes.

I will incorporate into the draft.

> 
> > 	In the absence of explicit transfer-encoding negotiations, an
> > 	OCP agent MUST NOT send transfer-encoded application messages.
> > 	Informally, this means that the agent or its environment have
> > 	to make sure that all transfer encodings are stripped before
> > 	an application message enters OCP scope.
> 
> Yes.

I will incorporate into the draft.

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

Regards
Martin

---

From: Robert Collins <[email-masked]>
Date: Thu, 16 Oct 2003 22:41:45 +1000

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

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 16 Oct 2003 09:56:02 -0600 (MDT)

On Thu, 16 Oct 2003, 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.

Hmm... We may have a problem here.

I agree with Martin in principle(*), but since Transfer-Encoding
header is gone, an agent cannot reliably detect non-identity coding
since we do not document any way of describing present transfer
encodings. If we say MUST, how will an agent check?

Since we provide no way to detect transfer codings, should we delete
the above MAY? The "receives transfer-encoded application data"
condition seems to be uncomputable in general!

Alex.

(*) We do not know what the service is doing. In addition to Martin's
example above, consider a logging service. OPES should not prevent FBI
from getting all data from a tap just because two P2P nodes are using
a custom transfer encoding underneath HTTP chunks.