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

From: "Brian Haberman" <[email-masked]>
Date: Wed, 10 Jun 2015 07:28:01 -0700

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.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 10 Jun 2015 11:22:22 -0600

Hi Brian, thanks for the review.

> https://datatracker.ietf.org/doc/draft-ietf-xmpp-6122bis/

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.

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
                      ; 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.

Peter

---

From: Brian Haberman <[email-masked]>
Date: Wed, 10 Jun 2015 13:55:00 -0400

Hi Peter,

> we keep this text, I agree that we should point to RFC 6974.

Agreed.

>                      ; algorithm described in Appendix B of RFC 3896

s/3896/3986/

> 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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 10 Jun 2015 12:07:56 -0600

Proposed text at end.

> 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

---

From: Brian Haberman <[email-masked]>
Date: Wed, 10 Jun 2015 15:27:23 -0400

Hi Peter,

>       zone identifier to any literal address.

This all works for me.  Thanks for the quick response and turn around!

Brian

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 10 Jun 2015 13:28:47 -0600

> This all works for me.  Thanks for the quick response and turn around!

Great. I'll post a revised I-D after the telechat.

Peter