Re: Another look at 8 bit transport for local mail

[Nathaniel Borenstein <nsb@xxxxxxxxxxxxxxxxxxxx>]

I commend John on his many insights; I often find myself agreeing with
him even when he is arguing with me.  A few specific comments:

Regarding "Encoding":
> If it only means "how you get 8 bits into 7 and binary into
> characters-with-line-delimiters-etc.", then probably some name other
> than "Encoding" should be found for it.

That's exactly what I thought it meant, and I see now that the word
"Encoding" is misleading.  Alternatives?  Maybe "7Bit-Transfromation"?

With regard to non-ASCII header information, and specificially my
"variable substitution" proposal, simply escaping ISO 10646 character is
a fine solution IF you think that it is the only character set we'll
ever need.  I was looking for a solution in which the headers,
particularly people's names & subjects, could be in arbitrary character
sets/content-types.  Something like Unicode may win someday, or it may
not, and I'd hate to back a single character set now.  Having one header
depend on another is certainly unusual, but I'm not convinced it's
unacceptable.  Anyone unwilling to implement it could simply ignore the
variable expansions.  I still think it's the best of a bad bunch of
alternatives.

> if you "extend" SMTP to support "true binary", including the length
> counts that are needed and all of the content description you probably
> want, what you functionally end up with is X.400.

I'm really skeptical that the result would be as complicated as X.400. 
However, I don't want to give the impression that I'm really gung-ho for
this solution -- I merely see it as more worthwhile than 8 bit text.

Other than that, I agree with just about all of John's conclusions,
although as he noted we didn't always get to our conclusions by the same
reasoning.  -- Nathaniel