Subject: [precis] review of draft-ietf-xmpp-6122bis-12

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Wed, 30 Jul 2014 21:25:33 +0000

The reasons the precis group got a spate of questions from me today was I
was prepping to do this review.  There are a couple of issues that the
precis folk should pay more attention to.

 > 1.  Introduction
... 

 >    Instead, this document builds upon the
 >    internationalization framework defined by the IETF's PRECIS Working
 >    Group [I-D.ietf-precis-framework], while attempting to ensure that
 >    the characters allowed in Jabber IDs under stringprep are still
 >    allowed and handled in the same way under PRECIS.

"the same way" means more backward-compatibility to me than I think we
intend here.

 > 3.1.  Fundamentals
 > 
 >       jid           = [ localpart "@" ] domainpart [ "/" resourcepart ]
 >       localpart     = 1*1023(localpoint)
 >                       ;
 >                       ; a "localpoint" is a UTF-8 encoded
 >                       ; Unicode code point that conforms to
 >                       ; the "JIDlocalIdentifierClass" profile
 >                       ; of the PRECIS IdentifierClass
 >                       ;

This implies 1023 codepoints, not 1023 bytes to me. Same issue for ifqdn
and resourcepart.  6122 just had 1*; I think going back to that would be
fine since we have a rule below that captures the max size.

 > 3.2.  Domainpart
 > 
 >    The domainpart of a JID is that portion after the '@' character (if
 >    any) and before the '/' character (if any); it is the primary

I think it's often surprising to people that foo/@bar is a valid JID with
"foo" as the domainpart and "@bar" as the resourcepart.  The text above,
although pulled from 6122, might be better as:

The domainpart of a JID is that portion after the first '@' character (if
any) and before the first '/' character (if any);

and possibly adding the example.

 >    In general, the content of a domainpart is an Internationalized
 >    Domain Name ("IDN") as described in the specifications for
 >    Internationalized Domain Names in Applications (commonly called
 >    "IDNA2008"), and a domainpart is an "IDNA-aware domain name slot" as
 >    defined in [RFC5890].  The following rules apply to a domainpart that
 >    consists of a fully-qualified domain name and MUST be applied in the
 >    following order:

When do these rules need to be applied? Only before comparison or routing?

 >    1.  The domainpart MUST contain only NR-LDH labels and U-labels as
 >        defined in [RFC5890] and MUST consist only of Unicode code points
 >        that conform to the rules specified in [RFC5892] (which includes
 >        Unicode normalization).  This implies that the domainpart MUST
 >        NOT include A-labels as defined in [RFC5890]; each A-label MUST
 >        be converted to a U-label during preparation of a domainpart, and
 >        comparison MUST be performed using U-labels, not A-labels.

This seems like an always rule, including for dumb clients.

 >    2.  All uppercase and titlecase code points within the domainpart
 >        MUST be mapped to their lowercase equivalents, preferably using
 >        Unicode Default Case Folding as defined in Chapter 3 of the
 >        Unicode Standard [UNICODE].

Dumb clients might get away with this and the system would still work.

 >    3.  Fullwidth and halfwidth characters within the domainpart MUST be
 >        mapped to their decomposition mappings.

Dumb clients have no shot at this one.

 >       Implementation Note: The foregoing order is different from the
 >       order for localparts and resourceparts as described below, to
 >       maintain consistency with the IDNA methods in both [RFC5892] and
 >       [RFC5895].
 > 
 >    After any and all normalization, conversion, and mapping of code
 >    points, 

as well as conversion to UTF-8.

 >    a domainpart MUST NOT be zero octets in length and MUST NOT
 >    be more than 1023 octets in length.  (Naturally, the length limits of
 >    [RFC1034] apply, and nothing in this document is to be interpreted as
 >    overriding those more fundamental limits.)
 > 
 > 3.3.  Localpart
 > 
 >    The localpart of a JID is an optional identifier placed before the
 >    domainpart and separated from the latter by the '@' character.
 >    Typically a localpart uniquely identifies the entity requesting and
 >    using network access provided by a server (i.e., a local account),
 >    although it can also represent other kinds of entities (e.g., a chat
 >    room associated with a multi-user chat service [XEP-0045]).  The
 >    entity represented by an XMPP localpart is addressed within the
 >    context of a specific domain (i.e., <localpart@domainpart>).
 > 
 >    A localpart MUST NOT be zero octets in length and MUST NOT be more
 >    than 1023 octets in length.  This rule is to be enforced after any
 >    normalization and mapping of code points.

and conversion to UTF-8.

 >    A localpart MUST consist only of Unicode code points that conform to
 >    the "JIDlocalIdentifierClass" profile of the "IdentifierClass" base
 >    string class defined in [I-D.ietf-precis-framework].  The
 >    JIDlocalIdentifierClass profile includes all code points allowed by
 >    the IdentifierClass base class, with the exception of the following
 >    characters that are explicitly disallowed in XMPP localparts:

(special precis focus)
I would have expected this to be phrased more similarly to step 2 of
http://tools.ietf.org/html/draft-ietf-precis-framework-17#section-5, or
for section 5 to just have a step about codepoints forbidden in a given
usage of the selected precis class.

 >    The normalization and mapping rules for the JIDlocalIdentifierClass
 >    are as follows, where the operations specified MUST be completed in
 >    the order shown:

Again, I think we need language about when these rules are applied.  The
rest of the section is about what is allowed, not about how to compare.

 >    1.  Fullwidth and halfwidth characters MUST be mapped to their
 >        decomposition mappings.
 > 
 >    2.  Uppercase and titlecase characters MUST be mapped to their
 >        lowercase equivalents, preferably using Unicode Default Case
 >        Folding as defined in Chapter 3 of the Unicode Standard
 >        [UNICODE].

Nothing about SpecialCasing?

 >    A resourcepart MUST NOT be zero octets in length and MUST NOT be more
 >    than 1023 octets in length.  This rule is to be enforced after any
 >    normalization and mapping of code points.
 > 
 >    A resourcepart MUST consist only of Unicode code points that conform
 >    to the "JIDresourceFreeformClass" profile of the "FreeformClass" base
 >    string class defined in [I-D.ietf-precis-framework].
 > 
 >    The normalization and mapping rules for the resourcepart of a JID are
 >    as follows, where the operations specified MUST be completed in the
 >    order shown:

Again, when are the rules applied?

 >    1.  Fullwidth and halfwidth characters MAY be mapped to their
 >        decomposition mappings.

(precis)
I need a hint as to when do this.  "MAY" isn't nearly enough.

 >    2.  Map any instances of non-ASCII space to ASCII space (U+0020).

(precis)
I was hoping either the framework doc or the mappings doc would tell me
more about which characters to map here.  RFC 3454 had table C.1.2, but I
don't see any hints about what I'm supposed to do now.  Is the rule "has a
compatibility mapping to U+0020"?  That doesn't hit U+200B which is in
C.1.2, nor does "has category Zs".  draft-ietf-precis-mappings says
"Therefore, the special mapping table should be based on a well-
   defined mapping table for each protocol", which although I don't
particularly like, I can live with - but we need the table here.

 >    3.  So-called additional mappings MAY be applied, such as mapping of
 >        characters that are similar to common delimiters (such as '@',
 >        ':', '/', '+', '-', and '.', e.g., mapping of IDEOGRAPHIC FULL
 >        STOP (U+3002) to FULL STOP (U+002E)) and special handling of
 >        certain characters or classes of characters (e.g., mapping of
 >        non-ASCII spaces to ASCII space); the PRECIS mappings document
 >        [I-D.ietf-precis-mappings] describes such mappings in more
 >        detail.
 > 
 >    4.  Uppercase and titlecase characters MAY be mapped to their
 >        lowercase equivalents, preferably using Unicode Default Case
 >        Folding as defined in Chapter 3 of the Unicode Standard
 >        [UNICODE].

Again, I need more about the MAY here.

 > 6.  IANA Considerations
 > 
 >    The following completed templates provide the information necessary
 >    for the IANA to add 'JIDlocalIdentifierClass' and
 >    'JIDresourceFreeformClass' to the PRECIS Profiles Registry.

Should we also ask them to mark the status of nodeprep and resourceprep to
deprecated in the stringprep profiles registry?

 > Appendix A.  Differences from RFC 6122
 > 
 >    Based on consensus derived from working group discussion,
 >    implementation and deployment experience, and formal interoperability
 >    testing, the following substantive modifications were made from RFC
 >    6122.

I think it might be nice to point out that this may have made
previously-valid JIDs no longer valid (or vice-versa), and that we suggest
careful testing before migrating user data.

-- 
Joe Hildebrand

---

From: Florian Zeitz <[email-masked]>
Date: Thu, 31 Jul 2014 01:12:49 +0200

Hy Joe, I largely agree with your comments. Some remarks inline.

On 30.07.2014 23:25, Joe Hildebrand (jhildebr) wrote:
> [...]
That is somewhat debatable. 1* is as correct/wrong as 1*1023 is.
1023 is an upper limit on the number of codepoints (all of them 7-bit
ASCII), it does however not capture the separate rule about the maximum
number of bytes. I'm not sure which version is less confusing.

> [snip: when are rules applied, what about dumb clients?]
I specifically pushed for having text clarifying this. I thought it was
sufficiently covered in Section 4. Do you disagree, and/or think we need
a forward reference here?

> usage of the selected precis class.
Personally I think this is fine. It's what I would have expected from
the description in
<http://tools.ietf.org/html/draft-ietf-precis-framework-17#section-4.1.6>.
If anything, I would have expected this to be phrased similarly to
section 3.2.3 or 3.3.3 (Disallowed).
My understanding is that this would be checked as part of step 5 in
section 5.

> [...]
I think this actually relates a lot to how we expect XMPP resources to
be used. They are not supposed to be entered by users. Possibly not even
user visible.

If this mapping was only relevant to servers, I'd say "whatever floats
your boat". Make it implementation defined behaviour and that is that.
Servers probably wouldn't implement it, because it's pointless work.

However, thick clients have some features that communicate full JIDs
between clients directly. For this case it is potentially vital that
both clients perform the same set of mappings. Hence, I actually tend to
prefer "MUST NOT" here.

> particularly like, I can live with - but we need the table here.
I think we need more specific text, and I think it is quite likely more
appropriate for the framework or mapping document than this profile.
I'm not sure it needs to be a table. Potentially "has category Zs" is
good enough, but I'd want to look closer at the Unicode data first.

I think your remark about U+200B being in C.1.2 is slightly off.
The tables in appendix C are specifically prohibition tables, and not
mapping tables. B.1 lists U+200B as commonly mapped to nothing, which I
think is the right thing to do wrt mapping this codepoint. Do you have
any other codepoint in mind that is not in Zs, but should be mapped to
ASCII space?

> Again, I need more about the MAY here.
See above. We might want to have a discussion about the effects of
different implementations performing different sets of mappings.
I personally think we want to explicitly mandate or disallow mappings of
codepoints that are otherwise PVALID.

> [...]
Do we have data to what extend this is the case? I.e. which codepoints
that were previously allowed are now disallowed?
I think it might be worthwhile to be very specific here, particularly
concerning why we think these changes are appropriate. There may be a
very vocal minority that is not okay with their JIDs being deprecated.

Regards,
Florian

---

From: "Joe Hildebrand (jhildebr)" <[email-masked]>
Date: Thu, 31 Jul 2014 15:49:40 +0000

>number of bytes. I'm not sure which version is less confusing.

I'm remembering that we decided that ABNF only worked on octets, not
codepoints.  Maybe we just need to tweak the explanatory text, perhaps
like this:

a "localpoint" is a byte from a UTF-8 encoded...

and perhaps s/localpoint/localbyte/g

>a forward reference here?

A reference to section 4 would make me happier, although it's still not
clear that some of the rules are ones clients MUST do if they want interop.

>My understanding is that this would be checked as part of step 5 in

Because of a lack of parallel structure, the precis framework doc is not
clear to me on this point.  I think this is something that should be
clarified, since my understanding is we're about to open that doc back up
for edits on exactly this point; how to take one of the classes and mold
it to the needs of your protocol by prohibiting particular codepoints.

>both clients perform the same set of mappings. Hence, I actually tend to

MUST NOT would make me happy.  It will increase interoperability.

>good enough, but I'd want to look closer at the Unicode data first.

The mapping doc makes sense to me.

>any other codepoint in mind that is not in Zs, but should be mapped to

You are of course correct about U+200B being in table B.1.  All of the
other codepoints in C.1.2 are in Zs, and there are no other codepoints in
the Unicode 7.0 UCD that are Zs.

>codepoints that are otherwise PVALID.

As above, MUST NOT for the mappings feels right to me, but I'm open to
other arguments.  I'm most worried about XEP-45 nicks here.

>very vocal minority that is not okay with their JIDs being deprecated.

Yeah, that sounds like a bit of work, but it may be worthwhile.

-- 
Joe Hildebrand