Everyone: please note that a version of the draft went out with a bug in the
BNF on page 5. The definition of "tspecial" should include the ";" character.
Also note that there are several incompatible changes from the May draft.
I have what may be the first proposal for a change to appear in the September
draft. I apologize for being it up so late; I didn't realize that it was a
problem until I got to that point in my implementation. I've discussed it
briefly with Nathaniel and he supports me. So, here it is:
Content-Transfer-Encoding is revised to indicate that it is not used
with contents which may include contents underneath it (such as
MULTIPART or MESSAGE).
The MULTIPART and MESSAGE types are revised to add an explicit
prohibition on the use of any transfer-encoding. This means,
barring any extensions to the transport to create 8-bit or binary
transport, that all MULTIPART and MESSAGE contents are of type 7BIT.
A transfer-encoding specification to a MULTIPART or MESSAGE content
MUST NOT be specified in a message, and if one appears it MUST be
ignored.
Justification: Use of transfer-encoding in multi-part or encapsulated
message contents means that the UA must decode message contents in
order to discover the structure of the message. What's worse, the
rat-hole of nested encodings and the cost of dealing with them is
opened up. Higher-level transfer-encodings duplicate the function of
low-level transport encodings with no significant functional benefit
and great implementation cost.
-- Mark --