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

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