Help me out, Steve. I've deleted a bunch of mail,
so I might have missed something. To transfer agents now act upon the
Content-Type? The whole reason why MIME was created was (I thought)
to save ourselves from the evils that the transfer agents might do.
MIME was actually created to deal with multiple character sets. Its creation
was not driven by any desire for multimedia, or any desire to clean up tranport
evils, or anything like that. You got all the other stuff "for free" ;-)
Anyway, the problem with this thread is an apparent confusion between transport
operations and user agent operations. A user agent deals with content-type
information on both the sending and receiving end -- it has to since it has to
know how to label things, how to canonicalize, how to decanonicalize, and what
viewer to activate. A transport agent, on the other hand, doesn't need to know
anything about the content type to perform its task.
Now, if a transport agent for some reason decides to perform transformations on
the messages it processess, well, all bets are off as to what it needs. In
theory it could need everything a user agent needs -- it certainly may have to
examine the content type. Heck, it may have to examine the *data* in the
message to do some kinds of transformations -- this is pretty much a
requirement for proper handling of PostScript on some systems.
I have no idea what a transport would do any of these things, but I've seen
enough wierdness in mail to realize that someone can probably come up with a
reason for it somewhere. Anyway, the only requirement is that when the
transport passes the message on that it undo anything it has done.
In practice transports usually do only two sorts of transforms very often:
(1) Conversion of text to local form. Text is this case is generally defined
as an encoded bodypart or something with a text content-type. (This
presupposes that binary transfers are supported. If they aren't you can
convert the entire message to local form without even looking at any
of the labels, since anything encoded as 7bit or 8bit has to be "text
like" in nature.)
(2) Conversion of encodings to deal with transport limitations. This should
not require looking at anything other than the encodings.
There are some problems with both of these in the current MIME specification
that we hope to clean up in the next version.
I do not believe that the CTE: should have any effect on
canonicalization/decanonicalization of a data type. Text encoded in base64
gets canonicalized first. Why should text "encoded" in "binary" not also?
The canonicalization of CT text/plain with CTE Base64
must be handled by the user agent. The transfer agent is oblivious.
There's another canonicalization that *is* handled by the transfer agent
when you're sending from or to a CDC Cyber. (what was the name of that
character set?) CT text/plain with an absent CTE leaves canonicalization
completely in the hands of the transport agents (of which there will
always be more than one).
This isn't correct. The canonicalization is done before the transport
is reached. The transport should not do anything to affect the canonicalization
at all. It may change encodings mid-stream, but if it changes more than that
and leaves it changed it is something more (or less ;-) than a transport.
I got the feeling that CTE binary was an attempt to either
shift responsibility for canonicalization from the user agent to the
transfer agent -or- just shut off canonicalization altogether.
The former will not give the desired results. The latter cannot be
accomplished because it is out of the user agents' control.
It is neither. Canonicalization is still done before transport, and it
is still necessary because different platforms do not agree on how to
represent the same sort of object.
Ned