Internationalized Delivery Status and Disposition Notifications
RFC 6533

Note: This ballot was opened for revision 06 and is now closed.

(Pete Resnick) Yes

(Jari Arkko) No Objection

Comment (2011-10-20 for -)
No email
send info
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.

(Ron Bonica) No Objection

(Gonzalo Camarillo) No Objection

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2011-10-18 for -)
No email
send info
I would like to see Appendix A consolidated to show "Changes from RFC 5337" and retained in the document.

(Stephen Farrell) No Objection

(David Harrington) No Objection

(Russ Housley) No Objection

(Peter Saint-Andre) (was Discuss, No Objection) No Objection

Comment (2011-10-19 for -)
No email
send info
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.

(Robert Sparks) No Objection

(Sean Turner) (was Discuss, No Objection) No Objection

Comment (2011-10-16)
No email
send info
#1) Do the authors wish to also move RFC 5337 to historic?

#2) s4: r/just <text> Also/just <text>.  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.