% As far as I can tell, the only problem that we don't have a handle on at
% all so far is non-ascii header data. (The people who think they have a
% handle on it tend, I think, to underestimate the risks of messing with
% crucial header fields like "From".) I woke up at 4 AM this morning
% unable to stop thinking about this issue, so I have yet another proposal.
% 1. Existing predefined RFC 822 header fields stay US-ASCII forever.
% No interoperability problems.
I think that unless the Extended SMTP folks sign up for anything
other than US-ASCII in the SMTP envelope, this RFC-XXXX group had best
not permit anything else. A note earlier this morning from someone
about Extended SMTP pointed out that there are DNS and mailbox-name
requirements for US ASCII only and X.400 reportedly requires ISO 646
Invariant codeset only.
% 2. We define a set of new header fields that contain the "real" (= in
% the right charset) data that corresponds to crucial user-relevant data.
% such as the From field:
Any such extension needs to be done in a manner that won't impact
Extended SMTP and its ability to detect end-of-headers and
end-of-message sequences and such like. All of these proposals DO
have transport implications.
% I don't think we're going to find a satisfactory mechanism that puts
% non-ASCII text into the established headers. Would this proposal
% satisfy the needs of the people who really want non-ASCII headers?
% If we don't come up with something soon, I feel very strongly that the RFC
% should go ahead *without* any mechanism for non-ASCII headers, because I
% don't think this is important enough to hold everything else up. --
I agree with the above paragraph.
Regards,
Ran
atkinson(_at_)itd(_dot_)nrl(_dot_)navy(_dot_)mil