My 2 cents:
In the beginning, the deities created 7-bit-ascii-in-an-8-bit-field,
with-the-8th-bit-off. (Feel free to hum, during this incantation.) And the
deities called this 'network virtual ascii'. And for line-oriented
situations, the deities demarced the 'network virtural terminal' with
newline being crlf and all other cr's followed by null, with short lines.
And the text was otherwise unformed or void.
For FTP, the deities also defined the type "other", calling it binary.
8bits, no line delimiter and no line length.
I.e., we had text and binary, with a very strict interpretation of text:
network virtual ascii is a canonical form. Map up to it or down from it,
but sender and receiver may not use special knowledge about each other.
(In some of the messages, there's been language suggesting that things are
different depending upon the characteristics of the receiver.)
I suggest that we try to talk about CTE first in terms of what bits cross
the Internet. This means that we need to define each thing as an
independent and complete entity, independent of any particular platform.
To my reading, 7bit is classic, oldtime, network virtual ascii. 8bit is
7bit with the 8th bit allowed to be on. But line length and newline (crlf,
x0D0A) requirements still apply. Contrary to one of the notes in this
exchange, I believe binary is the same as FTP binary. I.e., no
restrictions. The MIME spec really does say this, though with words like
'adherence not required' it might seem a bit confusing. Perhaps it would
have been clearer simply to say 'there is no newline construct.'
What makes all of this more interesting is that the content-type specifies
data which have 'native' encodings. But I suspect we get confused by the
fact that this 'native' encoding is ALSO a network virtual encoding! I.e.,
you might store GIF differently than I do, but image/gif has exactly one
definition. (If we didn't make the current specs for image/gif, or
whatever, precise enough, then let's go back and fix 'em, but let's NOT get
confused that any of these definitions pertain to specific platforms.)
The presumption for 7bit, 8bit, and qp CTEs is that the content-type is
some sort of text. But this is not required. CTE merely asserts what
bit-ranges might be on and whether 'record' delimiters are used and when.
We defined the 3 forms to accomodate some common (expected) scenarios. CTE
bin64 was designed to take ugly binary data through environments that
really only want 7bit. In a truly binary-clean transport environment, then
CTE binary is fine.
CTEs tell us about demands/expectations on the transport service. They are
packaging for rough or kind transport. I.e., as was observed, they are not
OF the service, they are FOR the service.
The handling sequence is:
(data in my platform-specific formats)
-> encode canonical form for content-types
-> content transfer encoding for transport peculiaries
-> transport service (MTA)
-> CTE decode
-> content-type platform-specific de-code ->
(data in your platform-specific formats)
Another 2 cents: Ned's response that PMDF is part MTA, part gateway and
part UA needs to be underscored.
Mail relaying is different from Mail gatewaying. A gateway tries to do a
constructive job of destroying information. If it didn't have to destroy
information, the services on either side would be semantically identical.
Hence, it has to get into the content and muck with it. A relay doesn't.
A relay is identical to a router.
In particular, a gateway looks like a user agent (i.e., a 'data in your
platform-specific formats') so that the message goes through the logical
sequence:
(data in my platform-specific formats)
-> encode canonical form for content-types
-> content transfer encoding for transport peculiaries
-> transport service (MTA)
-> CTE decode
-> content-type platform-specific de-code ->
(data in gateway's platform-specific formats)
-> encode canonical form for content-types
-> content transfer encoding for transport peculiaries
-> transport service (MTA)
-> CTE decode
-> content-type platform-specific de-code ->
(data in your platform-specific formats)
d/
--------------------
Dave Crocker
Brandenburg Consulting Phone: +1 408 246 8253
675 Spruce Dr. Fax: +1 408 249 6205
Sunnyvale, CA 94086 Email:
dcrocker(_at_)mordor(_dot_)stanford(_dot_)edu