Re: WGLC of draft-ietf-xmpp-6122bis-11

On 3/25/14, 2:25 PM, Matt Miller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 3/25/14, 2:16 PM, Peter Saint-Andre wrote:
>> On 3/25/14, 1:58 PM, Matt Miller wrote:
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>>>
>>> I've finished reviewing draft-ietf-xmpp-6122bis-11.  I mostly
>>> think this document is ready to be published.  I think it deals
>>> with the internationalization issues at hand as well as can be
>>> expected.
>>>
>>> However, in 3.2. Domainpart, I wonder about the following:
>>>
>>> 4.  So-called "additional mappings" MAY be applied to the
>>> domainpart, such as those defined in [I-D.ietf-precis-mappings]
>>> or [RFC5895].
>>>
>>> As far as I can tell, just about all of the suggested mappings
>>> from RFC5895 are already required here.  But for any that are
>>> not, I worry about the potential for interoperability problems if
>>> say two servers communicating with each other apply different
>>> mappings.  It might be best to strike this bullet from the list.
>>
>> Yes, I think you are right that it would be best to remove this
>> step. While updating draft-ietf-precis-saslprepbis last night, I
>> removed any mention of additional mappings from the password
>> algorithm, for similar reasons.
>>
>>> Less concerning to me is in 3.3. Localpart:
>>>
>>> 2.  So-called "additional mappings" MAY be applied, such as
>>> those defined in [I-D.ietf-precis-mappings].
>>>
>>> I think there is less concern about interoperability problems
>>> here, but I wonder if it is of any real utility.
>>
>> In saslprepbis, we've changed the username text to read:
>>
>> 3.  So-called additional mappings MAY be applied, such as mapping
>> of delimiters (e.g., characters such as '@', ':', '/', '+', and
>> '-') and special handling of certain characters or classes of
>> characters (e.g., mapping of non-ASCII spaces to ASCII space or
>> mapping of control characters to nothing); the PRECIS mappings
>> document [I-D.ietf-precis-mappings] describes such mappings in more
>> detail.
>>
>> However, that kind of mapping doesn't apply to XMPP localparts
>> because we profile the PRECIS IdentifierClass, which prohibits
>> punctuation and space characters outside the ASCII7 range, control
>> characters, etc. So IMHO it's unnecessary for localparts.
>>
>
> Agreed.

I looked at that text again and made a few changes (we're not mapping 
delimiters, we're mapping characters that are similar to delimiters):

    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.

>>> The similar language in 3.4. Resourcepart is not concerning to me
>>> at all; there are some cases where additional mappings are
>>> desirable (e.g., MUC nicknames), and I think the language makes
>>> it clear that anything beyond "it's opaque" is to be approached
>>> with care.
>>
>> Agreed, although I'd change the bullet to mostly or entirely match
>> what I added to draft-ietf-precis-saslprepbis.
>>
>
> That works for me.

Great.

Thanks again for the review.

Peter