[Top] [All Lists]

Re: Last Call: draft-crocker-email-arch (Internet Mail Architecture) to Proposed Standard

2009-02-27 20:05:03


With respect to character set, internationalization, and the like, I cannot tell what text changes you propose for the document. The current text was developed through community discussion. What specific changes are you proposing?

s/old/new/ form, or a multiline equivalent, would be most helpful.

I suggest that the bulk of any changes really does need to refer to community consensus documents, rather than trying to summarize the topic.


John C Klensin wrote:
A few observations:
(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.



  Dave Crocker
  Brandenburg InternetWorking