Re: Content-Transfer-Encoding "packet"

>Content-transfer-encodings generally stay with the message in store,
>and are not used to find the end of a message, but to protect the content.
>
>The "packet" encoding's primary purpose is to locate the end of the
>message without requiring scanning for special strings or knowing the
>complete length before starting transmission.

Yep, and the above two paragraphs are equivalent under HTTP.  The
packetized CTE would stay with the message (until it was removed),
and its purpose is to protect the content from a premature closure
of the connection (i.e., it allows the recipient to know if it got
the whole thing, and it allows the sender to apply a signature to
the whole thing).

>Note that an almost identical mechanism was proposed for SMTP - I think
>it is still one of the "draft-ietf-mailext" drafts.

Yes, I am aware of <draft-ietf-mailext-smtp-binary-07.txt>.  That mechanism
uses a series of separate messages (each message given a 1*DIGIT length)
to send the binary data.  In other words, it is a stateful message sequence,
which is something HTTP doesn't do.  It does demonstrate that both protocols
need such a thing, and conversion between the two methods would be trivial.

 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
                      Visiting Scholar, MIT/LCS + World-Wide Web Consortium
                      (fielding@w3.org)                (fielding@ics.uci.edu)

Received on Thursday, 27 July 1995 20:38:00 UTC