Internationalized Delivery Status and Disposition Notifications
RFC 6533
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
(Pete Resnick; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
I would like to see Appendix A consolidated to show "Changes from RFC 5337" and retained in the document.
(David Harrington; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
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.
(Peter Saint-Andre; former steering group member) (was Discuss, No Objection) No Objection
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.
(Ralph Droms; former steering group member) No Objection
(Robert Sparks; former steering group member) No Objection
(Ron Bonica; former steering group member) No Objection
(Russ Housley; former steering group member) No Objection
(Sean Turner; former steering group member) (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.
(Stephen Farrell; former steering group member) No Objection
(Wesley Eddy; former steering group member) No Objection