Re: dealing with encapsulation (formerly part of Minutes of the...smtpext)

Bob Smart writes about my hoped-for compromise...

>This seems the basis for an excellent compromise. One level of Content-type 
>encapsulated is the only nested encoding allowed. 

>It will be quite natural for the encapsulation to be undone in system code
>before it gets to places where user-mode parts of the UA/mail-reader have to
>deal with it. So this will obviate the problem of mail-readers having to
>know about nested encodings.
  Well, this is what I had in mind.  To put it a little differently
(and in retrospect--I understand things differently after a few days 
thought and thinking about Mark's response), I was looking for a *real*
transport encoding that would be undone by the receiving transport
agent, passing the UA an (presumably a copy of the original) 8bit 
message.

There are a few problems:
 (a) If the host has never heard of any of this new stuff, something 
that is really astonishingly bad news gets delivered to the user's 
screen without any warning.  Not only can't read it, can't even tell if 
you want to try. Not good.
 (b) If the MTA is mail-extensions-unaware, but the UA is 
mail-extensions-aware, then the life of the UA is made more difficult, 
as Mark points out.
 (c) If the underlying host or operating system is intrinsically not
8bit (e.g., 7), then the notion of the receiving MTA transferring and
8bit message to the receiving UA could get a little complicated, to put
it mildly.

Ignoring (c)--because I'm convinced that this would be a problem to deal 
with as a transport issue even if we could ignore it....
  Let's assume, building on the argument in my last note to Mark, that 
we decide we are going to change SMTP for everybody, and want to do some 
serious bullet-biting.  Now there is a whole new option.  We define 
RFC-XXXX* strictly in terms of 8bit action.  After all, ASCII is a 
proper subset.  We put verbs/clauses/statements in the envelope that say 
"here comes the XXXX rather than 822" and those verbs specify the 
transport encoding.  This is now a *real* transport encoding--it is 
either length-delimited binary (8bit) or it is, e.g., base64 (possibly 
also length-delimited--if we are going to overhaul the thing, let's go 
all the way).  No other cases.  A relay MTA that encounters
length-delimited binary may refuse to accept it (under the metarule that 
anything can refuse to accept anything at any time) or may transport it 
to something that can handle it, or may convert it to base64 for 
transport over a seven-bit channel (but not to an "old" MTA--this is 
"verbs either way" time).
  Now the receiving MTA gets the file and turns it into an 8bit mail 
format (format to be negotiated with the UA to which it is about to 
deliver it).  If it was in that format, fine.  If not, then the base64 
gets de-converted.
  Now we have a purely transport mechanism.  Clean layering.  All the 
transport encoding stuff disappears and the associated confusion about 
what is transport encoding and what is content type disappears with it.  
Mneumonic, quoted-printable, pictures and sound (as distinct from their 
coding) turn back into the presentation formats that they are all, 
without getting mixed up with their useful properties in transport, 
etc., etc.
  And, since we are going to put enough stuff into the SMTP extensions 
to buy everyone's cooperation as a positive, "we need these features" 
action, there will be enough implementations of these smart MTAs around 
that we won't need to worry about the old ones.  At least for long.

  There is really only one problem with that story, which is that it is 
a total fantasy.  I just don't believe it.  You probably don't either.  
Mark certainly doesn't.  For me, the "let's forget SMTP and just deploy 
X.400 in a hurry" plan is a lot more plausible.
  And, if we don't believe it, then we are back to "no pure transport 
solutions".  Even without 7-bits-internally hosts.

>I would favour always encoding the encapsulated Content-type in 
>quoted-printable.
  The only advantage of quoted-printable over base64 (and it has several 
disadvantages, including a difficult algorithm for predicting source 
file size from target file size in both directions) is that people can, 
in some cases, make sense of it.  If one were really looking for a "pure 
transport" format, then that is not an advantage--only MTAs look at 
those.  For transport, that size predictability is an asset. So base64
would be better in all respects; something just like base64 but with
compression or even just run length encoding might be a bit better yet. 

   --john