Re: Content-Transfer-Encoding "packet"

>would you mind not calling it a content-transfer-encoding?

Yes.  The proposed "packet" CTE is a transfer encoding.  That is,
it indicates what (if any) type of transformation has been applied
to the entity in order to safely transfer it between the sender and
the recipient. This differs from the Content-Encoding in that the
CTE is a property of the message, not of the original resource.

>The possibility of something with a c-t-e of "packet" escaping into
>mail, or the possibility of something with (for some reason) c-t-e base64
>losing its c-t-e because it's being sent with "packet" disturbs my sense
>of orthogonality.

That is because they are not orthogonal.  As I mentioned earlier, we may
want to define a packet64 encoding for this case, but we do not want
to allow a packet encoded message to be CTEd by another encoding.
The packetizing must be the last encoding applied to the message.

>"Content-encoding" I wouldn't mind, since it is wholly a Web thing;
>"Transfer-mode" I wouldn't mind either, for the same reason, but throwing
>a packetized transfer mode into a field used for some other purpose
>disturbs me deeply.

It fits the definition (if not practice) of MIME.  Those fields are
extensible, so it is reasonable to extend them.  The packet scheme is
not a transfer mode -- it applies to the message body, and could be
independent of the protocol (if other protocols used it).

>Yes, it should have been "content-encoding" in MIME, because that fits
>what it really is better, but it's too late to change MIME now.

I disagree -- that is not what content-encoding means in HTTP, nor
do I think it is too late to change MIME now.  Not allowing layered
encodings is a fundamental problem with the media type mechanism.
MIME chose to use a mechanism that replaces the content-type, thus
destroying some very important information.  HTTP can't do that,
so we invented something different.  Internet mail will have to do
the same eventually, whether it is in the MIME spec or not.

My job (in HTTP/1.x) is to describe a protocol in which both can
coexist, using the same basic abstractions and theory, such that
the implementation of the protocol remains relatively simple.

 ....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 Tuesday, 25 July 1995 18:13:37 UTC