[xmpp] WGLC Comments on 6122bis

"Ben Campbell" <ben@nostrum.com> Tue, 10 March 2015 22:30 UTC

Return-Path: <ben@nostrum.com>
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 C5D051A8F37; Tue, 10 Mar 2015 15:30:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ITfmK6LndASm; Tue, 10 Mar 2015 15:30:52 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960821A0126; Tue, 10 Mar 2015 15:30:49 -0700 (PDT)
Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t2AMUcbZ084681 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Mar 2015 17:30:49 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23]
From: Ben Campbell <ben@nostrum.com>
To: XMPP Working Group <xmpp@ietf.org>, precis@ietf.org, draft-ietf-xmpp-6122bis.all@ietf.org
Date: Tue, 10 Mar 2015 17:30:38 -0500
Message-ID: <30D40A1D-09C3-4257-8DC1-A90AFE561571@nostrum.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9r5066)
Archived-At: <http://mailarchive.ietf.org/arch/msg/xmpp/ZIzXKqf3s7cyE3b_n4cDTSjoF7M>
Subject: [xmpp] WGLC Comments on 6122bis
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: Tue, 10 Mar 2015 22:30:53 -0000

(as individual)

Hi,

This is a very well written draft. It's easy to understand given the 
complexity of the material. I support it's publication.

I have a few minor comments:

-- section 3.2, paragraph 6:

Is there a reason to avoid a reference for IDNA2008?

-- 3.3, implementation note:

Are there any practical consequences for the implementor? Are there 
potential conflicts where the XMPP implementation correctly forms a 
Localpart, but it contains an identifier that is interpreted incorrectly 
by some SASL mechanism?

-- 3.3.1, implementation note:

I have mixed feelings about XEP-0106 being an informational reference 
(using the standard of "need to read to understand/implement this 
document"). Even if an implementation chooses not to create JIDs with 
escaped characters, it had to be prepared to receive them from somewhere 
else, doesn't it?

-- 4, para 10 (I think): "In such cases, clients SHOULD enforce..."

The sending client, receiving client, or both?  Assuming the former, it 
might be worth adding some words to the effect of "before 
transmitting..."

-- 8:

While I don't object to the approach of the section, I think there's 
some risk of confusion about which text is authoritative from a 2119 
perspective. I think it might be worth noting that the authoritative 
text is in the referenced sections, and only summarized here for 
convenience.  (It only really matters if they conflict, but redundant 
normative text makes life harder for future updates.)

Thanks!

/Ben.