From: Bruce Lilly (blilly@erols.com)
Date: Tue Mar 04 2003 - 23:29:15 CST
J.B. Moreno wrote:
> On 3/4/03 6:38 PM, Lawrence Greenfield at <leg+@andrew.cmu.edu> wrote:
>>Is there a belief that those people are going to adapt UTF-8? Why?
>>UTF-8 displays just as badly as RFC 2047 on the small amount of UAs
>>that don't handle 2047.
>
>
> No, it doesn't display as badly:
>
> local charset: A propos des envois de vote erronés
> 2047 encoding: A propos des envois de vote =?ISO-8859-1?Q?erron=E9s?=
> raw utf-8 : A propos des envois de vote erronés
Your'e right; the utf-8 isn't "as bad[...]" it's worse than
the raw encoded-word; at least that can be transcribed
unambiguously. In any event, the key point is "the small
amount of UAs that don't handle 2047"; that molehill is
being made into Mt. Everest by some.
> 8 bit content exists. We can do one of three things: (1) bless the
> current usage (i.e. multiple local charsets), (2) forbid it, or (3)
> bless a particular charset.
Or (4) remain silent, deferring to the relevant referenced
standards. That what RFC 1036 does, and what the Kohn draft
does.
> If compatibility with RFC 2822 is the primary goal, then of course we
> should do 2
or 4.
> -- but while there is no certainty, the available evidence
> indicates that alienates 15% of the users.
RFC 1036 (the current standard) defers the matter to RFC 822,
which is quite clear that those 15% (or the authors of software
used by them) have alienated themselves.
> You are of course free to reject that conclusion, but if you accept it,
> the question then becomes: is compatibility with RFC 2822 more
> important than those 15%?
There's simply no choice; any standard produced either is
separate from and independent of RFC 1036 which continues as
the article format, or it must be compatible with RFC 2822.
And the former is only possible if the rechartering is
specifically for a separate but parallel implementation
rather than a 1036 successor.
> For myself, I think it will alienate them, and feel that is too high a
> price to pay for compatibility with RFC 2822. I think it's better that
> we simply accept that 15% are going to be incompatible, and deal with
> the consequences as best we can.
But J.B. those 15% are still going to be alienated and
incompatible if utf-8 is blessed. That would legalize the
0.006% utf-8 use and break existing compliant interoperability
with SMTP and IMAP; SMTP is necessary for moderation, which I
suspect accounts for more than 0.006% of all articles, and IMAP
is in widespread use.