Internationalized Delivery Status and Disposition Notifications
draft-ietf-eai-rfc5337bis-dsn-06

[Ballot comment]
I asked Ari Keränen to help me with reviewing this document. Had had this comment:

3.  UTF-8 Address Type

    Only the first form is 7-bit safe.

The meaning of this may not be clear for everyone; I'd consider adding a
short explanation since "7-bit safe" is used also later.

Upon approval, IANA will perform three actions:

ACTION 1:

IANA will replace the reference for the following Address Type at
http://www.iana.org/assignments/dsn-types:

UTF-8 UTF-8 mail address [RFC-to-be]


ACTION 2:

IANA will replace the reference to RFC5337 for the following Diagnostic
Type at http://www.iana.org/assignments/dsn-types:

smtp Internet Mail [RFC3461][RFC3464][RFC-to-be]


ACTION 3:

IANA will replace the references for the following message media types
at http://www.iana.org/assignments/media-types/message/index.html:

global-delivery-status [RFC-to-be]
global-disposition-notification [RFC-to-be]
global-headers [RFC-to-be]

[Ballot comment]
UPDATED.

Section 4 mentions that "three new media types are needed". In fact these media types are already defined in RFC 5337 and registered with the IANA. Please consider deleting the word "new".

Placing normative text in the IANA Considerations (Section 6.1) seems sub-optimal, despite the fact that it was done this way in RFC 5337.

[Ballot comment]
Placing normative text in the IANA Considerations (Section 6.1) seems sub-optimal, despite the fact that it was done this way in RFC 5337.

[Ballot discuss]
Changing to a "discuss" position because I'd like to chat about the following process issue:

In accordance with RFC 4288, were the media types 'message/global-headers', 'message/global-delivery-status', and 'message/global-disposition-notification' sent to the ietf-types list for review, either recently or before publication of RFC 5337? I do not see mention of them in the archive at http://www.ietf.org/mail-archive/web/ietf-types/current/maillist.html or http://www.ietf.org/mail-archive/web/ietf-types/current/mail2.html

[Ballot comment]
1. Placing normative text in the IANA Considerations (Section 6.1) seems sub-optimal, despite the fact that it was done this way in RFC 5337.

2. Were the media types 'message/global-headers', 'message/global-delivery-status', and 'message/global-disposition-notification' sent to the ietf-types list for review, either recently or before publication of RFC 5337? I do not see mention of them in the archive at http://www.ietf.org/mail-archive/web/ietf-types/current/maillist.html or http://www.ietf.org/mail-archive/web/ietf-types/current/mail2.html

[Ballot comment]
#1) Do the authors wish to also move RFC 5337 to historic?

#2) s4: r/just  Also/just .  Also  ?

#3) a.1: Is the note to the rfc-editor to just delete A1.  Keeping A.2 (renumbered to A.1 after the existing A.1 is deleted) would help implementers know what's changed.

  (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?


Joseph Yee (jyee@afilias.info)
Yes, I reviewed the draft.
I believed this version is ready for IESG for publication.


  (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? 


The draft had adequate review from both key WG members, and also had reviewed by 2 Apps Review Team members in Nov/Dec 2010.  Another last call announced at Sept 2011 and had reached WG's rough consensus.  I have no concerns about the depth or breath of the reviews that have been performed.


  (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.


No.


  (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 individuals in WG reviewed the document.  During the last few last call attempts and external reviews from application review team members, this document was understood and very little change.


  (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 verified the document.

ID-NITS indicates that the abstract lacks of description about update to RFC3461, RFC3462, RFC3464, RFC3798, also lacks of description about replace RFC5337.  However, the tool can not detect the last sentence in abstract which indicates the intent to update and replace RFCs described above.

Normative Reference RFC5336bis is expected to be replaced by RFCXXXX after its publication.
Normative Reference RFC5335bis is expected to be replaced by RFCXXXX after its publication.

The SMTP extension keyword 'UTF8SMTP' or 'UTF8SMTPbis' are expected to be replaced by the actual keyword after RFC5336bis is approved for publication.

  (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, 2 normative drafts are submitting at the same time with this draft.
RFC5336bis and RFC5335bis are two additional normative references to resolve all reference issues.


  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? 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?


Yes, I have verified the IANA consideration section.

There is no new registries, but there are several update:
Three DSN Types (Address Types, Diagnostic Types, MTA Name Types) need to update reference replacing RFC5337 with the new RFCXXXX of this document.


  (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
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.


Delivery status notifications (DSNs) are critical to the correct
  operation of an email system.  However, the existing Draft Standards
  (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text
  in the machine-readable portions of the protocol.  This specification
  adds a new address type for international email addresses so an
  original recipient address with non-US-ASCII characters can be
  correctly preserved even after downgrading.  This also provides
  updated content return media types for delivery status notifications
  and message disposition notifications to support use of the new
  address type.


    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?


There were nothing controversial nor rough for this document.


    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?


This document was reviewed by many in WG with expertise in mail.  Many thanks to Elliot Lear for external review.  And big thanks to Tony Hansen for his effort to make this document ready for publication.

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 Delivery Status and Disposition Notifications) to Proposed Standard


The IESG has received a request from the Email Address
Internationalization WG (eai) to consider the following document:
- 'Internationalized Delivery Status and Disposition Notifications'
  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


  Delivery status notifications (DSNs) are critical to the correct
  operation of an email system.  However, the existing Draft Standards
  (RFC 3461, RFC 3462, RFC 3464) are presently limited to US-ASCII text
  in the machine-readable portions of the protocol.  This specification
  adds a new address type for international email addresses so an
  original recipient address with non-US-ASCII characters can be
  correctly preserved even after downgrading.  This also provides
  updated content return media types for delivery status notifications
  and message disposition notifications to support use of the new
  address type.

  This document extends RFC 3461, RFC 3462, RFC 3464, and RFC 3798.  It
  replaces the experimental RFC 5337.




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

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


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