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

Peter Saint-Andre - &yet <peter@andyet.net> Wed, 10 June 2015 18:08 UTC

Return-Path: <peter@andyet.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 BA16E1B3408 for <xmpp@ietfa.amsl.com>; Wed, 10 Jun 2015 11:08:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.401
X-Spam-Level:
X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_35=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 0cE1q6Y8yfd6 for <xmpp@ietfa.amsl.com>; Wed, 10 Jun 2015 11:08:03 -0700 (PDT)
Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BF9E1B3403 for <xmpp@ietf.org>; Wed, 10 Jun 2015 11:08:00 -0700 (PDT)
Received: by iesa3 with SMTP id a3so40009929ies.2 for <xmpp@ietf.org>; Wed, 10 Jun 2015 11:07:59 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=vS4/j04MJvh6JDaFWG7rcoqCz8fQ/3C5hN5KXeHWz6I=; b=bQ2+MreVCGuRE50QBHptNRfcJPP3rO6LM0vJcO4rdcDPDwkYiSzS1nZR/zF8rDJqDX w60sIKlWScHVuHZxLvmaFbEi7HYRDFZ/xPkbHgg2zQ5o1ovuDGA2D8l8psE+3ph4jbUy QS9Ohue0g3rcrLk/Ey8pQG9IK8aqn7dw7RCWOEoxsluiNAadebhxxEE+/w21BCmgcvPW NRrESH7Z+7Fznfh6afi0Nfsafi7Wo0qiDzLyui6RTwAmjkUNBDnw7k6QceWjcucs/58v 137Hu2TjAhErkIBtOyrQ4rFdvI94+2Y8rwpSMc8TLA4JsS+WU8vPPedRHlDVwwY2vTDd vGbw==
X-Gm-Message-State: ALoCoQlv9TaKJHrOdBaLN74AfbNAg2C2l0+AYVUVegZZfKq/2rMvPc3dvxz1Ox7D9ECGkwv6xdSS
X-Received: by 10.50.43.227 with SMTP id z3mr7541891igl.12.1433959679665; Wed, 10 Jun 2015 11:07:59 -0700 (PDT)
Received: from aither.local ([2601:1:8200:3a60:89a0:20ab:ccd0:50f1]) by mx.google.com with ESMTPSA id g23sm6461716iod.37.2015.06.10.11.07.57 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Jun 2015 11:07:57 -0700 (PDT)
Message-ID: <55787CFC.4050701@andyet.net>
Date: Wed, 10 Jun 2015 12:07:56 -0600
From: Peter Saint-Andre - &yet <peter@andyet.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: Brian Haberman <brian@innovationslab.net>, The IESG <iesg@ietf.org>
References: <20150610142801.2677.38267.idtracker@ietfa.amsl.com> <5578724E.10307@andyet.net> <557879F4.3020106@innovationslab.net>
In-Reply-To: <557879F4.3020106@innovationslab.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/xmpp/tVbAQuWsrxaqraIoFo1oYl155Hk>
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 18:08:04 -0000

Proposed text at end.

On 6/10/15 11:55 AM, Brian Haberman wrote:
> 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?

How is this text?

###

       domainpart   = IP-literal / IPv4address / ifqdn
                      ;
                      ; the "IPv4address" and "IP-literal" rules are
                      ; defined in RFC 3896 and RFC 6874 respectively,
                      ; and the first-match-wins (a.k.a. "greedy")
                      ; algorithm described in Appendix B of RFC 3986
                      ; applies to the matching process

<snip/>

       Implementation Note: Reuse of the IP-literal rule from [RFC6874]
       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 [RFC3920] but
       which was changed in [RFC6122].  Also note that the IP-literal
       rule was updated between RFC 3986 and RFC 6874 to optionally add a
       zone identifier to any literal address.

###

Peter