ok, i'm not spoiling for a fight now. i hope i was reasonable before,
and i am certainly going to try to be reasonable now.
uuencode is an example. if it's a bad example, then let's think of
some better ones. i liked the base64 idea. anything that converts
the 8-bit stream into mailable 7-bit with ample application-level
checksums will suit me just fine.
the question of what to do with damaged mail (checksums don't match)
turns into the question: do we believe that the damage was transient
or do we believe that the same message sent through the same relays
a second time would show the same damage? if the former, we would
like to design it with end-to-end retransmission but that is not
reasonable due to the storage involved, so we would toss the mail and
inform the sender and recipients so that they can resend. we are
expecting this kind of transient error to be either very rare in
which case the inconvenience is low, or less rare in which case the
inconvenience level will be high enough to get the problem, whatever
it is, fixed. (conforming mailers should not trash mail, and smtp
uses tcp which has reliability at the stream level). IF the latter
(that is, the same message would be damaged in the same way if sent
through the same relays/paths), then we apparently screwed up when we
designed the encoding mechanism unless there is a nonconforming relay
in the path somewhere in which case that relay should be fixed.
or do we design this protocol with the idea that mail should still get
through even if it passes through a nonconforming host?
But to "bitblast" into one of these formats is exactly what people
have been shooting down for the last several days. It implies, at least
to me, that one is willing to say "ok, this is lots more complicated
than single-part text, encapsulate the whole message". But "encapsulate
the whole message" implies content-encoding at the top level, which, we
have been told, hopelessly complicates UAs.
i must have missed that discussion. i apologize if this analysis is
hopelessly naive, but it seems that either the recipient's transport
will unmap 7->8 before it hits the maildrop, or the user-agent will
have to be taught that trick. i don't favor asking the user agents
to do this, for two reasons: (1) there are more UA's than TA's on the
operating systems i am most familiar with, so it scales badly; (2) if
the user agent is prepared to display complex messages and the user
wants to use this functionality but his transport is not smart enough
to decapsulate, chances are very good that the user can get his transport
fixed -- it is always easier to get the transport fixed if the one you
need fixed runs on some local computer and not one 2,000 miles away.
so i guess i don't see that there will need to be a top-level content-
encoding at the UA level. it's got to be gone by then.
note that if the sending system and receiving system are outfitted with
8-bit TA's and UA's, then the rest of the network does not need to change
in order to let end-to-end 8-bit traffic flow between consenting and
cooperating users. in other words, i could implement this right now and
start using it. hmmm.
The alternative isn't "bitblasting into ..." (presumably Base64). It
is parsing the message, finding each content part separator, making
individual decisions about the correct way to encode each body part, and
then, potentially, using a different transport encoding for each one.
ick. i'm afraid i wouldn't like that at all. ick, ick, ick. but then
you infer that:
*That* isn't easy (not a design criterion). It also isn't easy to
guarantee that someone will do it right, or to determine in a robust and
survivable (i.e., you don't end up bouncing things, which is what you
are trying to avoid) way that it has been done right. And the second
is, IMHO, a reasonable design criterion.
since it's icky let's just not talk about it. i hope i've successfully
argued that the recipient's transport can make this invisible to her UA.
your example about C hit me suarely in the face like a banana cream pie.
however, i was talking about data structures and something like
{ "mumble", 1, 2.45 }
ends up being unambiguous and portable (until you compile it :-)).
cheers,
Paul Vixie, DEC Western Research Lab
Palo Alto, California, USA "Be neither a conformist or a rebel,
<vixie(_at_)decwrl(_dot_)dec(_dot_)com> decwrl!vixie for they are really the
same thing.
<paul(_at_)vixie(_dot_)sf(_dot_)ca(_dot_)us> vixie!paul Find your own
path, and stay on it." (me)