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

Peter Saint-Andre <stpeter@stpeter.im> Wed, 26 March 2014 01:27 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B9EE1A0028 for <xmpp@ietfa.amsl.com>; Tue, 25 Mar 2014 18:27:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qyklcMlX3Ps for <xmpp@ietfa.amsl.com>; Tue, 25 Mar 2014 18:27:54 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 1001F1A0025 for <xmpp@ietf.org>; Tue, 25 Mar 2014 18:27:53 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 1130E4010C; Tue, 25 Mar 2014 19:27:51 -0600 (MDT)
Message-ID: <53322D17.80707@stpeter.im>
Date: Tue, 25 Mar 2014 19:27:51 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Matt Miller <mamille2@cisco.com>, XMPP Working Group <xmpp@ietf.org>
References: <68FA58CE-C00A-4281-8B7E-5C96A0B3B835@nostrum.com> <35972936-21C6-4F35-92EF-4435C3F85C63@nostrum.com> <5331DFEC.4030900@cisco.com> <5331E42D.6020501@stpeter.im> <5331E64A.5080909@cisco.com>
In-Reply-To: <5331E64A.5080909@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/02uHmqXn2jvJU77ujDi2otrh40E
Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-6122bis-11
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Mar 2014 01:27:56 -0000

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