[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Another look at 8 bit transport for local mail
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:
> 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
> 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