Extensible Messaging and Presence Protocol (XMPP): Address Format
RFC 6122

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

(Gonzalo Camarillo) Yes

(Jari Arkko) No Objection

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Ralph Droms) No Objection

(Lars Eggert) No Objection

(Adrian Farrel) No Objection

(Russ Housley) (was Discuss) No Objection

Alexey Melnikov (was Discuss) No Objection

Comment (2010-11-19)
No email
send info
1). In 4.3.1 SASL needs an Informative Reference

2).

o  A resourcepart can be employed as one part of an entity's address
      in XMPP.  One common usage is as the name for an instant messaging
      user's connected resource; another is as the nickname of a user in
      a multi-user chat room; and many other kinds of entities could use
      resourceparts as part of their addresses.  The security of such
      services could be compromised based on different interpretations
      of the internationalized resourcepart; for example, a user could
      attempt to bind multiple resources with the same name,

Can you expand on what is the problem with binding multiple resources to the same name?

3).
In Section 6:

   Feature:  address-domain-length
   Description:  Ensure that the domainpart of an XMPP address is at
      least one byte in length and at most 1023 bytes in length.

Domain names have lower length boundary due to DNS restrictions.
Should this be at least mentioned? (Also applies elsewhere)

   Section:  Section 2.2
   Roles:  Both MUST.

(Tim Polk) No Objection

(Dan Romascanu) No Objection

(Robert Sparks) No Objection

(Sean Turner) No Objection

(Peter Saint-Andre) (was Abstain) Recuse