Internationalized Delivery Status and Disposition Notifications
Note: This ballot was opened for revision 06 and is now closed.
(Pete Resnick) Yes
(Jari Arkko) No Objection
Comment (2011-10-20 for -)
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 -)
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 -)
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
#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.