I am definitely not the party to be satisfied here;-)... I only jumped in to remind that the issues of IETF Message Bodies and Message Headers are separate and very different, so that the history of the "just send 8 bits" appeared to perhaps need some refreshment.
I think that Keith is talking along the same lines, but beyond what I have said, I am not able to contribute more. I have stopped doing IETF work since the Chicago IETF where I finished my work with MHTML, and no longer had travel support for any more IETF work. And then I also retired, more or less, mostly. So, having had my say for whatever it might have been worth, I would just as soon be omitted from the rest of this discussion. Cheers;-)...\Stef At 12:20 AM -0500 4/2/02, Keith Moore wrote: > > I believe that Einar could be most easily satisfied with something along > > the lines of a UTF8HEADERS ESMTP extension, which would specify both > > that 8 bit character are permitted in the header and that those > > characters MUST be interpreted as UTF-8. > >there are lots of problems with this idea. for instance, there's no >way for SMTP to know whether the recipient's MUA can deal with >utf-8 even in 2047 encoded form, to say nothing about unencoded form. >and it's not as simple as saying just use utf-8 in the message header - >there's also the question of which characters are legal and which aren't, >which ones are separator characters, which ones are white space, etc. > >then consider that, except for the abliity to have non-ascii email >addresses, there's no functional advantage to having raw utf-8 in headers. >there might be a slight win to having a more efficient encoder, but >MUAs would still have to implement both utf-8 and 2047 for many more years. > >let's get the details of non-ascii email addresses worked out before >we start spewing utf-8 in random places in the message header. > >Keith