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

From: [email-masked]
Date: Mon, 23 Mar 2015 10:28:49 -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-20.txt
	Pages           : 25
	Date            : 2015-03-23

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-20

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

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: Sam Whited <[email-masked]>
Date: Mon, 23 Mar 2015 13:44:19 -0500

>From the text:

> (e.g., under Unicode Normalization Form KC U+FE6B SMALL COMMERCIAL
> AT decomposes to U+0040 COMMERCIAL AT, although note that this
> decomposition does not occur under Unicode Normalization Form C,
> which is used in this specification).

Using an example which doesn't actually apply to the specification
strikes me as a bad idea. Though it's pretty clearly stated that it's
not actually applicable, this just seems unnecessary and confusing
(you'll end up with a lot of test suites with this as a failing test,
people emailing the various lists to ask about it, and finally them
re-reading and figuring it out).

This is a bit of a contrived problem, admittedly, but in the interest
of clarity and simplicity I still think it makes sense to change it.
Personally, I think it would be best to not have an example at all if
no relevant example can be found (I didn't see one while glancing
through the NFC definitions, but it was certainly not an exhaustive
search).

Best,
Sam

-- 
Sam Whited
pub 4096R/54083AE104EA7AD3
https://blog.samwhited.com

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 23 Mar 2015 14:14:53 -0600

> through the NFC definitions, but it was certainly not an exhaustive

Now that we've switched to NFC, there are no examples that apply. 
However, the principle enunciated here is still valid (because it is 
possible that examples might crop up in future versions of Unicode):

       Implementation Note: When dividing a JID into its component parts,
       an implementation needs to match the separator characters '@' and
       '/' before applying any transformation algorithms, which might
       decompose certain Unicode code points to the separator characters

So removing the example sees appropriate at this time.

Peter

-- 
Peter Saint-Andre
https://andyet.com/