Re: First strawman for UTF-8 headers proposal

John Cowan <[email protected]> wrote:

> > If the message store is a plain text file, what chaos might ensue?
> > Perhaps the UTF-8 headers should be segregated somehow, so they
> > don't accidentally fool old software into thinking it knows what to
> > do with them.
>
> Note that "plain text" should not be used as a synonym for "ASCII
> plain text"; UTF-8 files are plain text if they contain a sequence
> of characters each used for its ordinary meaning, neither binary nor
> markup.

Sorry, the "plain text" part was irrelevant to the point I was trying to
make.  If the message store is a passive file (as opposed to an active
database) then it is not able to negotiate with the program accessing
it; there is nothing analogous to the proposed ESMTP UTF-8-HEADERS
extension to verify that the recipient (the program accessing the file)
understands the new syntax.  If an existing program is pointed at an
mbox file and it sees a header fields named "From", "To", etc, it's
going to assume that the field values ought to obey the RFC-822 syntax
for such fields (which allows only ASCII characters).  If the field
values violate that syntax, who knows what will happen?

Hence I think it might be a good idea to use new field-names for the
UTF-8-enabled fields, to reduce the chance of accidentally misleading
old software.  If there is an algorithmic way to determine the syntax
of the new-style Foo field given the syntax of the old-style Foo field,
then there should also be a way to algorithmically associate the name of
the new-style Foo field with the name Foo.

AMC