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
- [xmpp] Brian Haberman's Discuss on draft-ietf-xmp… Brian Haberman
- Re: [xmpp] Brian Haberman's Discuss on draft-ietf… Peter Saint-Andre - &yet
- Re: [xmpp] Brian Haberman's Discuss on draft-ietf… Brian Haberman
- Re: [xmpp] Brian Haberman's Discuss on draft-ietf… Peter Saint-Andre - &yet
- Re: [xmpp] Brian Haberman's Discuss on draft-ietf… Brian Haberman
- Re: [xmpp] Brian Haberman's Discuss on draft-ietf… Peter Saint-Andre - &yet