Extensible Messaging and Presence Protocol (XMPP): Address Format
draft-ietf-xmpp-6122bis-24

Here is my AD Evaluation of draft-ietf-xmpp-dna-10. I have a few minor comments, but nothing that needs to delay the last call.

-- Section 4.1:

Does the "(Section 4.3: No Mutual PKIX authentication)" belong where it is, or before the first dialback assertion?
                       
-- 4.3, step 6:

Do I understand correctly that this step involves A sending a valid and trusted server cert, when it was previously unable to send a valid and trusted client cert? Is that a reasonable assumption? Whether yes or no, does it deserve a mention in the text? (It's likely I am missing something that should be obvious.)

-- step 7:

The reference to xep-0344 is informative. Should it be normative? If not, then perhaps a stronger mention of skipping subsequent steps should be included here? (it’s only mentioned in terms of the reference.)

-- 4.4.1, steps 3 and later:

The text says that A sends an initial stream header to B. Should that be considered B or C for the rest of the flow? I guess in the example, B==C, but is that required? (perhaps B and C coordinate dialback keys?) Maybe it doesn't matter from A's perspective.

[Ballot comment]
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).

[Ballot comment]
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.

[Ballot discuss]
This should be a relatively straightforward DISCUSS and may not result in any changes to the document...

I see this definition in the draft:
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 therein
                    ; applies to the matching process
                    ;
                    ; note well that reuse of the IP-literal rule from
                    ; RFC 3986 implies that IPv6 addresses are enclosed
                    ; in square brackets (i.e., beginning with '[' and
                    ; ending with ']')

RFC 3986 was updated by RFC 6874 to allow zone identifiers in address literals when the address is not globally scoped.  Was this considered in the drafting of this update?  RFC 6874 updates the ABNF to be:

      IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture  ) "]"
      ZoneID = 1*( unreserved / pct-encoded )
      IPv6addrz = IPv6address "%25" ZoneID

I suspect you will get varying results depending on how many implementers follow the Updates chain of 3986.

[Ballot comment]
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...

[Ballot comment]
= 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.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-xmpp-6122bis-22.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there is a single action which must be completed.

In the Stringprep Profiles registry located at:

http://www.iana.org/assignments/stringprep-profiles

the entires for:

Nodeprep

and

Resourceprep

will each have their status set to "Not Current" and the reference changed to [ RFC-to-be ].

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Extensible Messaging and Presence Protocol (XMPP): Address Format) to Proposed Standard


The IESG has received a request from the Extensible Messaging and
Presence Protocol WG (xmpp) to consider the following document:
- 'Extensible Messaging and Presence Protocol (XMPP): Address Format'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-06-03. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines the address format for the Extensible Messaging
  and Presence Protocol (XMPP), including support for code points
  outside the ASCII range.  This document obsoletes RFC 6122.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/ballot/


No IPR declarations have been submitted directly on this I-D.

1. Summary

The document shepherd is Matthew Miller.  The responsible Area Director
is Ben Campbell.

This document defines the address format for the Extensible Messaging
and Presence Protocol (XMPP), including support for code points outside
the ASCII range.  This document obsoletes RFC 6122.

This document replaces the XMPP address format, and as such is intended
to be a Proposed Standard.

2. Review and Consensus

This document received review from a small but active number of
individuals from the Working Group and the XMPP Community.  There is
consensus to publish this document.

The XMPP Community did raise the concern that some addresses which are
valid using RFC 6122 are no longer valid using this document.  However,
the consensus of the XMPP Community and the Working Group is that: this
document adequately describes the concerns and potential ways to
resolve such issues; and that such JIDs are exceedingly rare, if they
have ever been encountered.

3. Intellectual Property

There are no IPR declarations against this document.  The author has
confirmed that to the best of his knowledge, all IPR (for which there
is none) has been disclosed.

The Working Group did not explicitly discuss any IPR concerns.  Because
this document is heavily reusing technology from
draft-ietf-precis-framework, and adapting existing address format
specifics from RFC 6122, there is very little concern about IPR issues
in addition to those that apply to draft-ietf-precis-framework and
RFC 6122.  There are no IPR disclosures against
draft-ietf-precis-framework and RFC 6122.

4. Other Points

This document does have requests on IANA, but does not require more
than IETF consensus at best.  It does request IANA update the existing
Nodeprep and Resourceprep profile be marked "not current" and update
the reference for those profiles to point to this document.

The external reference to UNICODE is necessary as this document is
entirely about internationalized identifiers (and therefore is entirely
about UNICODE), and is consistent with the other PRECIS-related
documents.

The external reference to UTR36 is necessary to describe security
concerns, particularly the Address Mimicking problem.

The outdated references to draft-ietf-precis-framework and
draft-ietf-precis-nickname are expected to be resolved by the RFC
Editor before AUTH48 concludes.

The information downward reference to RFC 3490 is intentional as it is
used to discuss interoperability concerns with existing XMPP software,
which still use the stringprep profiles Nodeprep and Resourceprep.

The informational downward reference to RFC 3920 is intentional as it
illustrates the history of the XMPP address format, and is used to
describe interoperability concerns for existing software which still
uses the stringprep profiles Nodeprep and Resourceprep.

The informational downward reference to RFC 3921 is intentional as it
describes specific "JID slots" for server dialback (now defined in
XSF XEP-0220) and privacy lists (now defined in XSF XEP-0016).