Re: First strawman for UTF-8 headers proposal

"Adam M. Costello" <[email protected]> writes:

>> > Every protocol that carries messages will need an analogous tagging
>> > mechanism.
>>
>> I'm not clear what you mean here.
>
> POP and IMAP, for example.  They transfer messages from one agent
> to another, like SMTP does.  Therefore, if SMTP needs a negotiation
> mechanism (UTF-8-HEADERS) to verify that the receiving agent can
> handle the new header format, then POP and IMAP will need an analogous
> negotiation mechanism for the same reason.  Maybe NNTP too, though I'm
> not clear on the relationship between news article headers and mail
> headers.  And any other protocol that transfers mail messages from one
> agent to another.

Non-ASCII (even raw binary) is safe in NNTP, and putting UTF-8 in the
"Newsgroups" header have been tested in many clients and servers.  I
don't believe the NNTP would need a negotiation mechanism, rather it
would be sufficient to document that headers are UTF-8 in the next
Usenet message syntax document (if IETF ever manage to publish it).

As for IMAP, there has been good discussions about this on the IMAP
list, because IMAP is also used to access netnews.  I could not find
any up to date mailing list archive of the IMAP list, but if you can
find it, look for the threads 'IMAP and Netnews' by Charles Lindsey
(<[email protected]>) and 'Unicode newsgroup name
options' by Russ Allbery (<[email protected]>).

Both IMAP and POP(3) support capabilities, so it would not be
difficult to add a UTF8HEADER capability.  I'm skeptical about that
approach though, there are many protocols that transfer e-mail, adding
a capability negotiation mechanism, and a new capability, to all of
them is not practical.

Perhaps some protocols are not worth over-engineering a solution for.

If RFC 2822bis say headers are UTF-8, which I understand is the point
of this proposal even though it has been focused on the SMTP
consequences, then if POP3 servers start to send 2822bis messages, the
clients will be updated.  Adding a UTF8HEADER capability and computing
downgrade to existing POP3 clients would probably lead to worse
results overall, even though it would prevent breakage of someone's
hand-tailored POP client from '85.

Thanks,
Simon