Re: I-D ACTION:draft-hoffman-utf8headers-00.txt

On Jan 1, 2004, at 6:17 AM, Charles Lindsey wrote:

> I don't think you would need to downgrade for UUCP, because it is 
> already 8-bit clean. But my point was that a message might happily 
> wander around within one protocol (UUCP or NNTP) without anybody 
> needing to care about the encoding or to check for "UTF-8-HEADERS". 
> Then suddenly it arrives at a gateway into something else (e.g. SMTP 
> or an IMAP store) where the distinction really matters.

the possibility exists that the gateway isn't aware of the utf-8 
extension, so it injects messages with utf-8 headers and addresses into 
the legacy mail system without doing a conversion.

> Yes, Email carrries more weight within IETF, and if that means this 
> can be brought straight to standards track, then I would be delighted.

I think it's exactly the opposite.  email is viewed as an essential 
service; usenet isn't.  also, many people feel that usenet is already a 
hopeless mess and they haven't quite gotten to feeling that way about 
email (though there is a trend in this direction).  so there is 
considerable reluctance to making disruptive changes to email, whereas 
with usenet, the attitude is more likely to be "who cares?"  or "why 
are you bothering to upgrade usenet anyway?"

> Yes, our standard will say that the code used in headers MUST be 
> UTF-8, and other codes MUST NOT be used. That, sadly, is not 
> sufficient to prevent it from happening. Which is why I suggest that 
> our Foobar header should contain a possible handle to indicate other 
> usages, though clearly that handle "MUST NOT be used".

at the time we were working on what became RFC 1342 we realized that a 
single header field to tag the charset used throughout the header would 
not be sufficient, because different parts of the header are generated 
by different agents on different machines.   one of the reasons for 
1342 was to be able to encode such things in ASCII, but another reason 
was to be able to tag each bit of human-readable text with a separate 
charset.  what we might be finding out is that it's not reasonable to 
expect everyone to use utf-8, and that we're going to continue to need 
to deal with multiple charsets (though perhaps fewer than are in use 
now) perhaps including different charsets in different parts of the 
message header.