Internationalized Email Headers
draft-ietf-eai-rfc5335bis-13

[Ballot comment]
The title page header indicates that this document obsoletes RFC 5335.
  Please add this fact to the abstract.

  The title page header indicates that this document updates RFC 2045.
  Please add this fact to the abstract.

  The title page header indicates that this document updates RFC 5322.
  Please add this fact to the abstract.

[Ballot discuss]
The Gen-ART Review by Miguel Garcia on 18-Oct-2011 points out that
  this document includes two normative downrefs.  I do not see either
  of these downrefs in the Last Call for this document:

  ** Downref: Normative reference to an Informational draft:
    draft-ietf-eai-frmwrk-4952bis

  ** Downref: Normative reference to an Informational RFC: RFC 5598

[Ballot comment]
Ari Keränen helped me review this, and he said:

Should state in the abstract that this obsoletes and updated various RFCs.

3.  Changes to Message Header Fields

    Also note that messages in this format require the use of the
    &UTF8SMTPbis;

The "&UTF8SMTPbis;" looks like a processing error.


3.4.  Effects on Line Length Limits

    Section 2.1.1 of [RFC5322] limits lines to 998 characters and
    recommends that the lines be restricted to only 78 characters.  This
    specification changes the former limit to 988 octets.

What is the rationale behind the 988 octet limit?

[Ballot comment]
The title page header indicates that this document obsoletes RFC 5335.
  Please add this fact to the abstract.

  The title page header indicates that this document updates RFC 2045.
  Please add this fact to the abstract.

  The title page header indicates that this document updates RFC 5322.
  Please add this fact to the abstract.

[Ballot discuss]
The Gen-ART Review by Miguel Garcia on 18-Oct-2011 points out that
  this document includes two normative downrefs.  I do not see either
  of these downrefs in the Last Call for this document:

  ** Downref: Normative reference to an Informational draft:
    draft-ietf-eai-frmwrk-4952bis

  ** Downref: Normative reference to an Informational RFC: RFC 5598

[Ballot discuss]
The nit-checker indicates several problems that need to be fixed before publication, including some missing and incorrect references (which is why I'm recording this issue as a Discuss).

This document includes a normative reference to an Informational draft, which is not mentioned in the IESG Writeup and apparently not mentioned in the last call text as required by RFC 3967.

[Ballot discuss]
Updated with a second question to chat about...

1. As far as I can see, the 'message/global' media type was never reviewed on the ietf-types list (per RFC 4288), although it is contained in the registry at http://www.iana.org/assignments/media-types/message/index.html -- perhaps this is merely an issue with the archives for the ietf-types list (which moved recently to ietf.org)?

2. Do we think it's acceptable for this specification to simply redefine ABNF constructs like VCHAR (RFC 5234) and qtext (RFC 5322)? Or is it better to define new constructs with different names?

[Ballot discuss]
As far as I can see, the 'message/global' media type was never reviewed on the ietf-types list (per RFC 4288), although it is contained in the registry at http://www.iana.org/assignments/media-types/message/index.html -- perhaps this is merely an issue with the archives for the ietf-types list (which moved recently to ietf.org)?

[Ballot comment]
Almost a total nit but p7 says "If this type is sent to a 7-bit only system,
it has to have..." - to what does the "it" refer the emitter of the
message or the 7-bit only system? Also - wouldn't saying "
MUST do " not be clearer than saying "has to have"

[Ballot comment]
#1) Do the authors also wish to make RFC 5335 Historic?

#2) Please add a section that lists the difference between RFC 5335 and this
document.

[Ballot discuss]


I'm hoping the answer to this is yes, but I had to ask because I didn't see it
in the proto write-up:

This document doesn't have a pre-5378 disclaimer and the author set is not the
same as RFC 5335.  Did Abel grant the rights to the IETF Trust to
allow the document to be published without the pre-5378 disclaimer?

  (1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

Jiankang Yao.  Yes, I believe it is ready.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed?

There has been a lot of discussions about this draft. An earlier
version went through WG last call in Nov. 2010. That version received
a significant number of comments. As a result, an additional author
was added and the document restructured to address all of the issues
that the WG considered substantive.  In Sep. 2011, this draft got
another WG last call to confirm that the revised version had gotten
rough consensus.  The EAI WG has been talking about this draft for
very long time.  I believe it has had adequate review. 
 
  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No.

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

The question of whether this document should be identified as updating
RFC 5322 remains unanswered, partially because neither the IETF nor
the RFC Editor has a clear rule about the point at which document that
extend a base specification but do not significant modify it are
considered to be updated.  Quoting the current lead editor, "we
change the line length limit from 998 characters to 998 octets". This
is really an i18n clarification: a count in "characters" and one in
"octets" are identical for ASCII, but "octets" provides a precise and
invariant length independent of character set and encoding.  The WG is
happy to have the IESG resolve this issue as you think appropriate.

People representing the part of the Netnews community who believe that
netnews and Internet mail are the same except for transport are still
grousing about a decision (Message-IDs) that might have been different
had the WG considered behavior on the other side of gateways as more
important than smooth operation within the SMTP environment on
the public Internet.

There are no other known issues.


  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it? 

Many WG participants from EAI WG have reviewed this document and
had reasonably strong WG consensus.  There has been no dissent in the
last two calls for comment within the WG.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        and http://tools.ietf.org/tools/idnits/). Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

Yes, I have checked it. There is one outdated reference: A later
  version (-13) exists of draft-ietf-eai-rfc5336bis-07

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

Yes.  There are normative references to [I-D.ietf-eai-frmwrk-4952bis]
and [I-D.ietf-eai-rfc5336bis], which are part of this package.  The
former is already in the RFC Editor queue awaiting approval of this
document and draft-ietf-eai-rfc5336bis before being published.  This
document and draft-ietf-eai-rfc5336bis resolve those downward or
missing references; they do not introduce new ones.

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document?

Yes.


        If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

No new registries, but IANA is requested to update the registration of
the message/global MIME type

(1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Yes.

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary

This document specifies an enhancement to the Internet Message Format
that allows use of Unicode in mail addresses and most header field
content.



    Working Group Summary
       
This document has been discussed in EAI WG for a very long time.
The WG came to consensus on this document.



    Document Quality

The documents have been extensively reviewed by people with mail
expertise. It is in very good shape.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Internationalized Email Headers) to Proposed Standard


The IESG has received a request from the Email Address
Internationalization WG (eai) to consider the following document:
- 'Internationalized Email Headers'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-20. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  Internet mail was originally limited to 7-bit ASCII.  MIME added
  support for the use of 8-bit character sets in body parts, and also
  defined an encoded-word construct so other character sets could be
  used in certain header field values.  But full internationalization
  of electronic mail requires additional enhancements to allow the use
  of Unicode, including characters outside the ASCII repertoire, in
  mail addresses as well as direct use of Unicode in header fields like
  From:, To:, and Subject:, without requiring the use of complex
  encoded-word constructs.  This document specifies an enhancement to
  the Internet Message Format that allows use of Unicode in mail
  addresses and most header field content.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5335bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-eai-rfc5335bis/


No IPR declarations have been submitted directly on this I-D.

AD review of -03 (plus extra ABNF errors to be reported separately):

2.  Background and History

  Use of this SMTP extension helps prevent the introduction of such
  messages into message stores that might misinterpret, improperly
  display, or mangle such messages.  It should be noted that using an
  ESMTP extension does not prevent transferring email messages with
  UTF-8 header fields to other systems that use the email format for
  messages and that may not be upgraded, such as unextended POP and
  IMAP servers.  Changes to these protocols to handle UTF-8 header
  fields are addressed in [RFC5721bis] and [RFC5738bis].  [[Note in
  Draft: RFC5721bis and RFC5738bis did not yet posted.]]

Please delete the note, as it is no longer accurate.


4.1.  UTF-8 Syntax and Normalization

  See [RFC5198] for a discussion of normalization; the use of
  normalization form NFC is RECOMMENDED.

I think NFC needs a Normative reference.


4.3.  Syntax Extensions to RFC 5322

  description  = "Content-Description:" unstructured CRLF

  The  syntax is extended above to allow UTF-8 in all
    header fields.

The problem with this is that  is not referencing .
RFC 5322 defines:

  unstructured    =  (*([FWS] VCHAR) *WSP) / obs-unstruct

So should this document also extend  to allow UTF-8?


  Note, however, this does not remove any constraint on the character
  set of protocol elements; for instance, all the allowed values for
  timezone in the "Date:" headers are still expressed in ASCII.  And
  also, none of this revised syntax changes what is allowed in a
  , which will still remain in pure ASCII.

In the last sentence I've noticed that one of the revisions of this draft
changed  to  (as compared to RFC 5335). I believe this
is incorrect, because  is an ABNF production used in many other places,
such as in In-reply-to and References header fields. So please undo the change.

Also, "Date:" headers --> "Date:" header fields.


4.4.  Change on addr-spec Syntax

  Let-dig      = 

This should be pointing to Section 4.1.2 of RFC 5321.


4.5.  Trace Field Syntax

  The uFor ( described in [I-D.ietf-eai-rfc5336bis] Section 3.6.3 ))
  has been added to allow the use of internationalized addresses in
  "For" fields. by use of the new uFor syntax.

Extra dot before "by".


5.  Security Considerations

  If a user has a non-ASCII mailbox address and an ASCII mailbox
  address, a digital certificate that identifies that user may have
  both addresses in the identity.  Having multiple email addresses as
  identities in a single certificate is already supported in PKIX
  (Public Key Infrastructure for X.509 Certificates) and OpenPGP.

This needs Informative references to PKIX and OpenPGP RFC.

  In this specification, a user could provide an ASCII alternative
  address for a non-ASCII address.  However, it is possible these two
  addresses go to different mailboxes, or even different people.  This
  configuration may be based on a user's personal choice or on
  administration policy.  We recognize that if ASCII and non-ASCII
  email is delivered to two different destinations, based on MTA
  capability, this may violate the principle of least astonishment, but
  this is not a "protocol problem".

I think this paragraph is no longer relevant and needs to be deleted.


6.  IANA Considerations

  IANA has registered the message/global MIME type using the
  registration form contained in Section 4.4.

This should be a bit clearer that IANA needs to update the current registration
to point to this document.


[RFC1652]

This reference doesn't seem to be Normative.