Re: [xmpp] Brian Haberman's Discuss on draft-ietf-xmpp-6122bis-23: (with DISCUSS)

Brian Haberman <brian@innovationslab.net> Wed, 10 June 2015 17:55 UTC

Return-Path: <brian@innovationslab.net>
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 35BFE1B33E1; Wed, 10 Jun 2015 10:55:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level:
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, J_CHICKENPOX_37=0.6] autolearn=no
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 UKdMkv05i407; Wed, 10 Jun 2015 10:55:13 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F07E91B33D5; Wed, 10 Jun 2015 10:55:12 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id B7B50880F0; Wed, 10 Jun 2015 10:55:12 -0700 (PDT)
Received: from Brians-MacBook-Pro.local (unknown [76.21.129.88]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 9C0A771B0002; Wed, 10 Jun 2015 10:55:11 -0700 (PDT)
Message-ID: <557879F4.3020106@innovationslab.net>
Date: Wed, 10 Jun 2015 13:55:00 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet <peter@andyet.net>, The IESG <iesg@ietf.org>
References: <20150610142801.2677.38267.idtracker@ietfa.amsl.com> <5578724E.10307@andyet.net>
In-Reply-To: <5578724E.10307@andyet.net>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6hMXJgnRLA3fLqXWeq2iXFFcDlfBgoIHS"
Archived-At: <http://mailarchive.ietf.org/arch/msg/xmpp/TgsjvZG3_zREp8-fAr7ZGrZp9kk>
Cc: xmpp-chairs@ietf.org, draft-ietf-xmpp-6122bis@ietf.org, xmpp@ietf.org, draft-ietf-xmpp-6122bis.ad@ietf.org, draft-ietf-xmpp-6122bis.shepherd@ietf.org
Subject: Re: [xmpp] Brian Haberman's Discuss on draft-ietf-xmpp-6122bis-23: (with DISCUSS)
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, 10 Jun 2015 17:55:14 -0000

Hi Peter,

On 6/10/15 1:22 PM, Peter Saint-Andre - &yet wrote:
> Hi Brian, thanks for the review.
> 
> On 6/10/15 8:28 AM, Brian Haberman wrote:
>> Brian Haberman has entered the following ballot position for
>> draft-ietf-xmpp-6122bis-23: Discuss
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>> https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/
>>
>>
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> This should be a relatively straightforward DISCUSS and may not result in
>> any changes to the document...
>>
>> I see this definition in the draft:
>> domainpart   = IP-literal / IPv4address / ifqdn
>>                       ;
>>                       ; the "IPv4address" and "IP-literal" rules are
>>                       ; defined in RFC 3986, and the first-match-wins
>>                       ; (a.k.a. "greedy") algorithm described therein
>>                       ; applies to the matching process
>>                       ;
>>                       ; note well that reuse of the IP-literal rule from
>>                       ; RFC 3986 implies that IPv6 addresses are enclosed
>>                       ; in square brackets (i.e., beginning with '[' and
>>                       ; ending with ']')
>>
>> RFC 3986 was updated by RFC 6874 to allow zone identifiers in address
>> literals when the address is not globally scoped.  Was this considered in
>> the drafting of this update?  RFC 6874 updates the ABNF to be:
>>
>>        IP-literal = "[" ( IPv6address / IPv6addrz / IPvFuture  ) "]"
>>        ZoneID = 1*( unreserved / pct-encoded )
>>        IPv6addrz = IPv6address "%25" ZoneID
>>
>> I suspect you will get varying results depending on how many implementers
>> follow the Updates chain of 3986.
> 
> My apologies, I forgot that RFC 6874 updated RFC 3986 in this regard. If
> we keep this text, I agree that we should point to RFC 6974.

Agreed.

> 
> RFC 6122 had this text:
> 
>                       ; note well that reuse of the IP-literal rule
>                       ; from RFC 3986 implies that IPv6 addresses are
>                       ; enclosed in square brackets (i.e., beginning
>                       ; with '[' and ending with ']'), which was not
>                       ; the case in RFC 3920
> 
> We could, I suppose, remove this text entirely since it was meant to
> give implementers notice about the change from RFC 3920 to RFC 6122.
> However, I think it's always good to keep implementation notes of this
> kind. So, looking at this again, I think I would change it to:
> 
>                      ; the IPv4address and IP-literal rules are
>                      ; defined in RFC 3986 and RFC 6874 respectively,
>                      ; and the first-match-wins (a.k.a. "greedy")
>                      ; algorithm described in Appendix B of RFC 3896

s/3896/3986/

>                      ; applies to the matching process
>                      ;
>                      ; note well that reuse of the IP-literal rule from
>                      ; RFC 6874 implies that IPv6 addresses are enclosed
>                      ; in square brackets (i.e., beginning with '[' and
>                      ; ending with ']'), which was not the case with
>                      ; the definition of the XMPP address format in
>                      ; RFC 3920
> 
> However, I might want to move the last paragraph to an implementation
> note (not an ABNF comment) so that we have a proper reference to RFC 6874.

I agree that a proper reference to 6874 would be useful.  Is there any
need to mention the potential for a literal to include the zone id?

Brian