[ Although I have been observing things for quite some time, this is my
first time posting to this list. I hope you will forgive an occasional
restating of the extremely obvious... ]
- Binary Encodings v. Binary Transport
Crispin, et. al., have pretty much nailed this one. The existing global
mail transport infrastructure is text-based. This infrastructure
contains a lot of other transports besides SMTP, and is simply too big
to change (even the SMTP-only portion is too big to change). As such,
any attempts to do binary transport for mail are doomed to failure in an
environment of any real size. At the risk of poisoning the well, anyone
who talks about 8-bit SMTP, etc., is simply spending too much time in
fantasyland.
However, the user-to-user mail service should allow delivery of
arbitrary content and encoding, even though the mail transport service
does not. XXXX and base64 layered on top of the existing mail transport
infrastructure does this. Problem solved.
- Simplicity with Encodings
It's best to have a complete conceptual separation between content type
and encoding. I propose a simple rule: if the Content-Transfer-Encoding
field isn't there, the receiver should always assume 7BIT. This means
that a receiver can always do a decode without knowing/caring about the
content type.
Following in this separation vein, when you build a multipart content,
the content shouldn't know/care as to how the individual components are
encoded. This means that, after encoding, each component is
representable as 7BIT. The multipart content then needs no further
encoding, even if it is placed inside a scoping multipart.
- Closure now!
Like Crispin, I am an implementor (he did MM and IMAP; starting back in
79, I did MH for four years). I understand all too well the
argument he makes in regards to simplicity. The more grody this thing
becomes, the less likely we are going to have applications providing
useful service to the community. We need more simple rules, mechanisms,
and policies. Things don't have to be complicated.
Given a free-hand, I would probably chop 15-30% out of draft, just out
of general principle. I'm serious, it would probably double or treble
the number of implementations we'd have within a year of its
introduction as an RFC. However, given this late date, it's more
important to get the document out as an RFC rather than to re-engineer it.
The community is not being well-served by the length of time it has
taken to produce XXXX. I am not going to try delay things further by
trying to get everyone to agree to how XXXX should be cleaned up.
Instead, we should close the matter ASAP, generate the next-to-final
draft by month's end, and be prepared to toss it over the fence in Santa
Fe.
/mtr