On Feb 12, 7:27pm, Dave Crocker wrote:
} Subject: Transmission issues for transition to UTF-8 Headers
}
} For moving to UTF-8 headers, we need an esmtp option and, I suppose, an
} 822(bis) header.
I think I agree with Keith that a new header field doesn't really help.
I'm not a UTF-8 expert by any means, but it sounds like recognizing the
strings individually is sufficient. We've got these cases:
1. Plain unlabeled (non-UTF-8) octets.
2. A UTF-8 string, which can be recognized by its structure.
3. An RFC2047 string, which can be recognized and the character set
extracted.
4. An RFC2231 string, which can be recognized and the character set
and language extracted.
I don't know of a case where it's valid to include 2231 and 2047
in the same header field. 2231 is for parameter values and
machine-readable text which aren't necessarily displayed to the
recipient; 2047 is for human-readable strings in "plain text" fields
which are intended for display to the recipient.
For similar reasons, I don't think that 2231 strings should be
translated to or from UTF-8, and it's not clear that we need
to ever send them in "raw" form even if they are originated
in UTF-8. Filenames etc. need to stay intact end-to-end.
Keith