Subject: [xmpp] Fwd: Alexey Melnikov's DISCUSS and COMMENT on draft-ietf-xmpp-address-07

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 22 Nov 2010 12:19:30 -0700

Keeping the XMPP WG in the loop on incoming IESG feedback. I'll also
forward one or more replies because they concern the WG.

/psa

-------- Original Message --------
Subject: Alexey Melnikov's DISCUSS and COMMENT on draft-ietf-xmpp-address-07
Date: Fri, 19 Nov 2010 04:20:04 -0800
From: Alexey Melnikov <[email-masked]>
To: The IESG <[email-masked]>
CC: [email-masked], [email-masked]

Alexey Melnikov has entered the following ballot position for
draft-ietf-xmpp-address-07.

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I just can't possibly resist not having a DISCUSS on this document ;-).
Below are my review comments:

1).
RFC 3920:

      domain          = fqdn / address-literal
      fqdn            = (sub-domain 1*("." sub-domain))
      sub-domain      = (internationalized domain label)
      address-literal = IPv4address / IPv6address

draft-ietf-xmpp-address:

      domainpart    = IP-literal / IPv4address / ifqdn
                      ; the "IPv4address" and "IP-literal" rules are
                      ; defined in RFC 3986, and the first-match-wins
                      ; (a.k.a. "greedy") algorithm described in RFC
                      ; 3986 applies to the matching process

RFC 3986:

      IP-literal = "[" ( IPv6address / IPvFuture  ) "]"

      IPvFuture  = "v" 1*HEXDIG "." 1*( unreserved / sub-delims / ":" )

(DISCUSS DISCUSS)
This means that the draft is proposing usage of "[" and "]" around IPv6
addresses, which is a change from RFC 3920.
I think the change is sensible, but is it covered by Appendix C?

2).
In Section 2.1:

   An XMPP URI or IRI
   [XMPP-URI] is in essence a JID prepended with 'xmpp:', but the native
   addressing format used in XMPP is that of a mere JID without a URI
   scheme.

I think this text is misleading for URIs: it is effectively suggesting
that percent-decoding/encoding is not needed
when converting a JID to URI, which is not correct. URIs are always in
US-ASCII, while JIDs are not.
Similar assumptions about mailto: URIs caused some interoperability
problems.

3). [DNS] seems to be Normative (for the definition of a Fully Qualified
Domain Name).

4). DISCUSS DISCUSS:
Should domainpart be migrated to IDNA2008 now? Apps Area is pretty much
requiring use of IDNA2008 in all documents.

5). I still need to double check the following, but from a cursory look
this seems to be a minor problem:

Can application of Nodeprep/resourceprep to a non empty string result in
an empty string, which would violate the requirement on
nodepart/resourcepart being non empty?

This will affect several sections, including Section 6.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.