Subject: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-13.txt

From: [email-masked]
Date: Wed, 10 Sep 2014 18:52:17 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Extensible Messaging and Presence Protocol Working Group of the IETF.

        Title           : Extensible Messaging and Presence Protocol (XMPP): Address Format
        Author          : Peter Saint-Andre
	Filename        : draft-ietf-xmpp-6122bis-13.txt
	Pages           : 29
	Date            : 2014-09-10

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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-xmpp-6122bis-13

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-13

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 10 Sep 2014 19:57:28 -0600

Changes to address feedback from Joe and Florian.

Please review carefully, because some of the changes are subtle or 
provisional - more feedback would be very helpful.

Thanks!

Peter

On 9/10/14, 7:52 PM, [email-masked] wrote:
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 11 Sep 2014 16:04:32 +0000

On Sep 10, 2014, at 9:57 PM, Peter Saint-Andre <[email-masked]> wrote:

> Please review carefully, because some of the changes are subtle or provisional - more feedback would be very helpful.

I think the separation of preparation, enforcement, and comparison is very helpful, but I don’t think the description of enforcement is very clear yet — it seems to mix together normalization and validity checking, without a clear discussion of which rules are which.

For example: as far as I can tell, the intention from all discussions is that [email-masked] is a valid JID, which a server should normalize and process as [email-masked], but “StPeter"@example.com is not, and should be rejected with <jid-malformed/>.  But I don’t see how you can deduce this from the document’s current description of “Enforcement” — both the case mapping and the list of invalid characters are specified as “MUST” requirements.

The “Preparation” stage also doesn’t seem to require that JIDs that are transmitted actually be considered valid by the enforcement stage, which seems like a recipe for interop failure.

6122’s language was "A localpart MUST be formatted such that the Nodeprep profile of [STRINGPREP] can be applied without failing” (and similarly for the other JID parts).  Can language something like this (mutis mutandis for Precis rather than Stringprep) be used, once Enforcement is clear about what is or isn’t considered failure?