From: Jean-Marc Desperrier (jean-marc.desperrier@certplus.com)
Date: Tue Jul 17 2001 - 10:03:20 CDT
"J.B. Moreno" wrote:
> > I don't agree with your assertion that raw 8 bit seldom causes difficulties.
> > It works only when everyone communicating uses the same locale.
> > I've been confronted to context where people who have different; non-US locale
> > try to communicate, and it causes lot of problem.
>
> And that is fairly rare in comparison to the number of post in the various
> non-english hierarchies.
I like the term internationalization to mean that people wil be able to communicate
freely everywhere, not just locally.
Basically for me this is the very spirit of the internet, connecting networks, using
standards, so that communication works everywhere.
So I don't much like the argument that if something works locally, that's good
enough.
This said I'm getting out of what I want to express here.
> > The programs that don't understand RFC 2047 now will not adapt to UTF-8 either
> > (within any short time frame at least).
>
> If you can read and post in UTF8, displaying the text correctly is a lesser
> matter -- one that doesn't /need/ to be addressed except in so far as it
> improves your user experience and thus the likelyhood that you'll have more
> users.
Reading your message and Erland's one, I realise I didn't correctly understand the
term follow-up agent.
I didn't get it was any user agent you use to write a follow-up.
Having a different name for the same software depending on the role it's playing got
me confused.
This caused some incomprehension in the last message.
I was in fact talking about the general case of a user agent creating a new subject,
In fact, I fully agree that a user agent used to send a follow-up should not modify
the subject at all.
> UTF8 is what we are aiming for, no reason to do something inbetween unless
> it has a significant gain. I don't see any such gain here.
Yes, there is no gain for follow-up subjects.
In the more general area of newly created headers, there can be one.
> I'm not sure exactly what section you are addressing but I think we have a
> general statement elsewhere on what to do with 8 bit, non-UTF: clients are
> free to do whatever they want, including treat it as the local charset.
Before posting, I searched for something like that in the last draft, but didn't
find it.
I might just have missed it.