Re: Last Call: Originator-Info Message Header to Experimental

[Ned Freed <Ned.Freed at innosoft.com>]

> At 07:50 98/07/15 -0700, Chris Newman wrote:

> > If you want to allow unencoded UTF-8 in message headers, you'll have a
> > long and bloody fight ahead of you.  It may not be possible to deploy
> > unencoded UTF-8 in headers without either breaking standards compliant
> > software or deploying a UTF8HEADER extension to SMTP, IMAP and POP.
> > Originator-Info is the wrong place to do either of these.

> I would be nice if some of the old 7-bit die-hards would recognize that
> having UTF-8 directly (i.e. without MIME encoding) in headers is what
> we should end up sooner or later anyway (of course with proper
> standardization),

I'm afraid this is a strawman -- as far as I know there's no such thing
as a "7-bit diehard". I've yet to encounter anyone who believes that 7-bit
headers are a Good Thing we should stick with for all time.

What does exist, however, is a group of people who are very familar with the
realities of present-day email infrastructure and who know that "just send 8"
is NOT an option in either an operational or standards sense. It is even less
of an option with message headers than it is with message bodies. And this
group, of which I am a member, aren't going to accept a change that breaks the
installed base of implementations done in good faith to current standards in
this area.

Now, you may characterize this as being a "7-bit diehard", but I don't think
such a characterization is appropriate or correct. And frankly, I don't think
it does your cause any good to make such a characterization.

Remember, this issue was argued at huge length as part of the original round of
ESMTP/MIME discussions. And the consensus that emerged then was clear, as were
the precedents for how upgrades to existing standards have to be handled.

However, this doesn't mean there are no ways forward. There are several. The
obvious one (and the one I favor personally) is negotiated support for UTF-8 in
headers -- a HEADERS=UTF-8 ESMTP option or something similar. I would have no
problem with such a mechanism.

But I see little point in developing such a thing until it is clear that UTF-8
is the right answer and an ample installed base of UTF-8 support exists to
build on. We need something that can be widely implemented and supported almost
immediately. But such development and deployment hasn't happened yet, at least
not as far as I can tell. I believe it will, but my belief isn't sufficient to
make me want to press forward with this concept at the present time.

In particular, I don't want to have to deal with multiple charsets in this
context, and I don't want to have to defend selecting UTF-8 as the only
charset. If we have to handle multiple 8-bit charsets we might as well stick
with encoded-words.

> so that long and bloody fights can be avoided. Making sure that raw
> headers are consistently UTF-8 is a good way to avoid having them
> (raw!) in whatever other encodings.

Well, you're correct in saying that just-send-8 will result in a fight -- one
which, on procedural grounds alone, there's no chance could be won.

				Ned