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