Subject: Transfer-Encodings

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

Re: section 2.5 Transfer Encodings of HTTP adaption draft

> This is still ugly --
> the callout service has no way to know whether the OPES processor
> removed encodings (and the Transfer-Encoding header) or did not
> remove the encodings (but removed the header), etc.

What problem do you see here?
We defined:

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

So, an OPES processor must assume that there is no encoding.
Of course, it gets a problem if the processor violates this rule.
How to detect? Very hard. But it is the same problem as applying a
Transfer-Encoding in HTTP without setting the header.

Or do you think it is to weak because it does not foresee what will
happen if explicit transfer-encoding negotiation will be introduced
in future?

Shall we introduce a Transfer-Encoding parameter to AMS that MUST be
set if a transfer encoding is (still) applied to the content?
Implementations could be better prepared in this case and can at least
terminate the transaction in this case.

Regards
Martin

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 23 Oct 2003 15:44:53 -0600 (MDT)

Martin,

	I think you are right. If we have a MUST that precludes any
encodings, there is no point in documenting a header that describes
encodings. I withdraw my comment. Let's add an informal sentence
emphasizing the importance of both this MUST and the other MUST that
says that an agent MUST terminate if it cannot remove transfer
encoding. Violating either would lead to interoperability problems.

	Logging service would have to define and negotiate exceptions
to the above if they want to get the message "as is" (whatever that
means in an OCP context).

Thanks,

Alex.