Re: I-D Action: draft-ietf-xmpp-6122bis-20.txt

On 3/23/15 12:44 PM, Sam Whited wrote:
> On Mon, Mar 23, 2015 at 12:28 PM,  <[email protected]> wrote:
>> 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.
>
>>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).

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/