From: J.B. Moreno (planb@newsreaders.com)
Date: Tue Mar 04 2003 - 22:10:59 CST
On 3/4/03 6:38 PM, Lawrence Greenfield at <leg+@andrew.cmu.edu> wrote:
> From: "J.B. Moreno" <planb@newsreaders.com>
> [...]
> > And saying that because it's "non-compliant" people should stop and adopt
> > some new standard is simply silly -- either those 15% have rejected using
> > the existing 7 bit encoding, and are almost certainly going to reject a
> > brand new 7 bit encoding, or they are using clients that can't do the 7 bit
> > encoding, and they aren't going to be able to do the brand new 7 bit
> > encoding either.
>
> 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
Which is what fuels the belief that it'll be more acceptable.
-snip-
> Some IMAP servers are more zealous in enforcing RFC 2822 than
> others---most IMAP servers accept 8-bit characters in some fashion. It
> is clear that all IMAP servers are broken when dealing with 8-bit
> characters because IMAP servers need to interpret characters in the
> header (in the appropriate character set) to function correctly.
>
> So instead of saying "IMAP doesn't deal with it", you can try "is
> incompatible with RFC 2822".
Ideally, the real world and the RFC's would be identical, but this
isn't an ideal world. There are conflicts, incompatibilities. As the
people writing the RFC, one of our responsibilities is to try to
eliminate or reduce those conflicts.
We can't do that by dismissing the real world as "incompatible with the
standard". Compromises have to be made -- both by us, and hopefully
the real world (i.e. the world adapts to what we say).
> People using mail readers and IMAP servers to read netnews is one
> factor why RFC 2822 compatibleness is a good thing.
And despite my previous message, I don't disagree. But while it would
be a good thing, even a very good thing, it shouldn't be our primary
goal.
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.
If compatibility with RFC 2822 is the primary goal, then of course we
should do 2 -- but while there is no certainty, the available evidence
indicates that alienates 15% of the users.
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%?
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.
-- J.B. Moreno