[Top] [All Lists]

Re: UTF-8 in headers

1999-02-02 20:30:10
In <01J73X4P6BEM8WWDN6(_at_)INNOSOFT(_dot_)COM> Ned Freed 
<Ned(_dot_)Freed(_at_)innosoft(_dot_)com> writes:

On Sun, 24 Jan 1999, Charles Lindsey wrote:

So I can see a great danger that the grand canonical method of downgrading
UTF-8 headers (which is subject of this thread) is likely to degenerate
into a large collection of special cases, all done differently. And I do
not see any immediate clean answer to this :-( .

There is no clean answer short of writing out explicit rules, which is what
I've been saying from the start has to be done.

I cannot believe that anyone could seriously suggest that the way out of
this problem is to invent a separate ad hoc solution for every situation.
That is just not how sensible systems are designed.

Sigh. Nowhere did I say, or even imply, this. Explicit rules can be generic in
form. The difference here is between not having rules that clearly say what to
do and having them.

As such, this is purely a strawman of your own making.

New headers for mail and news are being invented all the time. Often, they
are deployed and widely adopted before the RFC gets written (yes, that is
not supposed to happen, but it does). And now you are saying that everyone
who invents a new headers has also to specify how it gets downgraded to

Nope, that's not what I'm saying at all. What I'm saying is that we need
explicit downgrading rules -- not having any will lead to chaos, as you
yourself said, and that's just not acceptable, if for no other reason that
interoperability is an absolute requirement of the process.

Surely, a more sensible approach would be to define more carefully where
RFC2047 could be used. For example, that no protocol word or protocol
character (i.e. anything specified by an explicit "..." in the syntax)
could be included within an encoded-word. OK, that is too simplistic as it
stands, but surely there MUST be some uniform principles that could be

Uniform principles are what I said we should have.

If not, then my suggestion of encapsulating headers and bodies as
multiparts, which you all described as "ugly" should be looked at again.
At least, it is uniform and applicable for all situations.

However, my guess is that this is a complete operational nonstarter.

BTW, is RFC 2231 actually deployed and in regular use in meatspace yet?

There is some deployment, but not a lot. It also depends on what parts of RFC
2231 you're talking about -- I don't believe I've ever seen the language
tagging facilities used, for example.


<Prev in Thread] Current Thread [Next in Thread>