Extensible Messaging and Presence Protocol (XMPP): Address Format
RFC 7622
Note: This ballot was opened for revision 23 and is now closed.
Ben Campbell Yes
(Barry Leiba) Yes
Comment (2015-06-09 for -23)
No email
send info
send info
I would make the RFC 6365 reference normative. The ABNF definition for localpart would benefit from citing [draft-ietf-precis-saslprepbis] by "UsernameCaseMapped profile". Similarly for "OpaqueString profile" in the definition of "resourcepart". (And, by the way, I wouldn't put quotation marks around the profile names.) The first paragraph of Section 3.2 defines a particular parsing order, which will affect a JID such as in example 15, way down below. I think it's worth explicitly saying that here, to reduce the likelihood that such JIDs might be mis-parsed. You do mention it in the note explaining example 15, but it'd be useful to highlight it here. In Section 3.3.1, I find the "i.e."s to be distracting clutter, and mildly recommend rendering those lines like this: U+0022 (QUOTATION MARK): " U+0026 (AMPERSAND): & In example 21, it might be more fun to use PILE OF POO (U+1F4A9) instead. Or maybe not...
(Jari Arkko) No Objection
(Alia Atlas) No Objection
Deborah Brungard No Objection
(Benoît Claise) No Objection
Comment (2015-06-11 for -23)
No email
send info
send info
Thanks for this operation-related sentence, based on Dan Romascanu's review: Because it is possible that previously-valid JIDs might no longer be valid (or previously-invalid JIDs might now be valid), operators of XMPP services are advised to perform careful testing before migrating accounts and other data (see Section 6.1 of [I-D.ietf-precis-saslprepbis] for guidance).
Alissa Cooper No Objection
Comment (2015-06-08 for -23)
No email
send info
send info
= Section 6.1 = "Because this document obsoletes RFC 6122, which registered the "Nodeprep" and "Resourceprep" profiles, IANA is requested at the least to mark those profiles as not current (preferably with a pointer to this document)." "At the least" implies that IANA may take some further action at its own discretion, which doesn't seem right. I would suggest deleting that phrase.
(Stephen Farrell) No Objection
(Brian Haberman) (was Discuss) No Objection
Comment (2015-06-10 for -23)
No email
send info
send info
I have cleared my DISCUSS based on the changes proposed by PSA. Thanks for the quick turnaround.
(Joel Jaeggli) No Objection
Comment (2015-06-11 for -23)
No email
send info
send info
I see that the reference to services are advised to perform careful testing before migrating accounts and other data (see Section 6.1 of [I-D.ietf-precis-saslprepbis] for guidance). was added due to last call discuss. I think that's good.