In <01J73X4P6BEM8WWDN6(_at_)INNOSOFT(_dot_)COM> Ned Freed
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.
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
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
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.
BTW, is RFC 2231 actually deployed and in regular use in meatspace yet?
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Web:
Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5