(3) There are some useful things that can be said that are, at
this point, settled parts of the architecture or at of least the
relevant protocols. As suggested above, one is that the content
matter is settled and that UTF-8 is the winner in the character
set wars (although other things are certainly around). Another
is that work on i18n of email headers and addresses is
progressing, but that, until that work completes, IDNs can be
expressed in ACE form (with appropriate references). I would
personally avoid making anything resembling a normative
reference to the experimental documents, largely because they
introduce more new syntax and terminology that would then need
to be discussed.
(4) It is a nit, but "Because its origins date back to the use
of ASCII" leaves an impression that is not strictly correct. It
would be accurate to say that its origins date back to the time
when even the use of ASCII was controversial. However, the
origins have nothing to do with anything: the email architecture
of today is defined in ASCII terms. RFCs 5321, 5322, and 2045ff
are written in ASCII terms and require ASCII (except in
body-part content) as are most of the other protocols
referenced. It would be far more accurate to simply say that we
have an ASCII-based protocol suite that is gradually being
adapted to accommodate non-ASCII elements where those are
appropriate, with the current thread and model starting with the
introduction of text/ content-types in MIME.
(5) The document needs to be updated to reflect current
references. In particular, RFCs 5321 and 5322 were published
almost six months ago. They also contain some slight
adjustments to terminology and this document should be carefully
checked to be sure its terminology is still consistent with them.
regards,
john
