From: Charles Lindsey (firstname.lastname@example.org)
Date: Thu Jul 04 2002 - 08:24:33 CDT
In <3D230F96.email@example.com> Jean-Marc Desperrier <firstname.lastname@example.org> writes:
>Now, if we take a USEFOR aware user agent, and asks ourself what he
should send to be understable to the highest possible number of non USEFOR
aware user agent, my answer is RFC 2047.
>You can find some user agents that don't understand RFC 2047, but you
will not make those any happier by using UTF-8.
>If it's a user agent under Windows and doesn't understand RFC 2047, it
will not understand UTF-8 either.
>If it's a user agent under Unix that can't decode RFC2047, you can make
it understand UTF-8, but then it won't read anything that is not in UTF-8
anymore, and this is not a viable setting.
Yes, but we already know that someone is going to get upset whatever we
do. But we have proposed a solution which involves checking whether a
sequence is valid UTF-8 or not. I believe we have consensus (even
including yourself) for that. But no, it will not solve every problem
until it becomes deployed.
Now clearly you are advocating RFC 2047 as the preferred solution. But
others on this list are advocating the opposite (mainly on the grounds
that it is ridiculous to carry on encoding things into the foreseeable
future when we know that most systems can already transmit the full 8
bits and surely they all will before long). Which is why my text leaves
the choice of method open, because we are not goint to get consensus for
As to the continued use of random character sets, I believe we are all
agreed that it is a Bad Thing and should be phased out somehow. The only
choice is whether we say MUST NOT generate now, or whether we use the
milder "it is non-compliant" wording. Judging from earlier remarks in this
thread, my present inclination is to change my text to the MUST NOT form.
>The draft never says to apply to all the headers the encoding defined in
>the Content-Type header, that's what OE is doing in this case ...
How can you do that with a multipart message with different Content-Types
in the different parts? Agreed that looking at a Content-Type is a good
heuristic (but implementors can work that out for themselves without being
told). It is also a bit of a pain if you want to process the article
sequentially without backtracking.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: email@example.com Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5