Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-13.txt

Florian Zeitz <florob@babelmonkeys.de> Fri, 03 October 2014 04:14 UTC

Return-Path: <florob@babelmonkeys.de>
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 EEDC61ACFE3 for <xmpp@ietfa.amsl.com>; Thu, 2 Oct 2014 21:14:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.336
X-Spam-Level:
X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 tRM_BepihZbT for <xmpp@ietfa.amsl.com>; Thu, 2 Oct 2014 21:13:54 -0700 (PDT)
Received: from babelmonkeys.de (babelmonkeys.de [IPv6:2a02:d40:3:1:10a1:5eff:fe52:509]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D2E61ACFE4 for <xmpp@ietf.org>; Thu, 2 Oct 2014 21:13:54 -0700 (PDT)
Received: from xdsl-78-34-99-244.netcologne.de ([78.34.99.244] helo=[192.168.0.140]) by babelmonkeys.de with esmtpsa (TLS1.1:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <florob@babelmonkeys.de>) id 1XZuFb-0003zW-EY; Fri, 03 Oct 2014 06:13:51 +0200
Message-ID: <542E2279.10608@babelmonkeys.de>
Date: Fri, 03 Oct 2014 06:13:45 +0200
From: Florian Zeitz <florob@babelmonkeys.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2
MIME-Version: 1.0
To: xmpp@ietf.org
References: <20140911015217.14982.19406.idtracker@ietfa.amsl.com> <54110188.7070202@stpeter.im>
In-Reply-To: <54110188.7070202@stpeter.im>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/-lUM8Bs0AqQGONFs6hndp_CTcpw
Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-6122bis-13.txt
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: Fri, 03 Oct 2014 04:14:08 -0000

On 11.09.2014 03:57, Peter Saint-Andre wrote:
> Changes to address feedback from Joe and Florian.
> 
> Please review carefully, because some of the changes are subtle or
> provisional - more feedback would be very helpful.
> 
I've finally found some time (and remembered) to look over this.

I'd like to echo Jonathan Lennox concerns that preparation, enforcement,
and comparison seem a bit under-defined.
In particular enforcement needs some text specifying how invalid JIDs
should be handled by a server.

In section 3 the claim that a server needs to perform preparation in
some cases seems strange to me. From the detailed description in section
5 it always either enforces the rules, or treats the JID as an opaque
part of a c2c protocol.

In section 4.1 it seems a bit unfortunate to say that each code point
needs to conform to a string class. Conformance to such a class is a
property of the string as a whole, due to CONTEXTJ/CONTEXTO.

It is unclear to me how section 4.2.2 is consistent with RFC 5895 as it
claims.
Section 2 of RFC 5895 appears to specify that mappings are performed
before code points are checked for conformance (i.e. step 2 and 3 need
to be performed before step 1 here), and also specifies two more
preparation steps. In general I'm still uncomfortable with trying to
reproduce IDNA2008's algorithms instead of just referencing them.

The text in section 4.4.2 still doesn't seem to address Joe's and my
concerns. Making width and case mappings optional poses an
interoperability hazard. If a sending server performs these mappings,
while the receiving server doesn't, this will yield stanzas that can not
be routed. I would strongly suggest either dropping any text about these
mappings, or making this a MUST NOT.

Regards,
Florian

> Thanks!
> 
> Peter
> 
> On 9/10/14, 7:52 PM, internet-drafts@ietf.org 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-13.txt
>>     Pages           : 29
>>     Date            : 2014-09-10
>>
>> 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-13
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-xmpp-6122bis-13
>>
>>
>> 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/
>>