Subject: Re: [xmpp] draft-ietf-xmpp-address

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Jul 2010 18:34:30 -0600

On 6/29/10 11:47 AM, Bruce Campbell wrote:
> 
> On Mon, 28 Jun 2010, Ben Campbell wrote:
> 
>> [as co-chair]
>>
>> Hi,
>>
>> The latest version of 3920bis, which we just WGLC'd, split out the JID
>> definition into draft-ietf-xmpp-address. We did this to work around
>> some of the nameprep/newprep issues.
>>
>> Have people read and understood draft-ietf-xmpp-address? While we will
>> probably WGLC that one later, early feedback would be extremely helpful.
> 
> Something that bugged me slightly when the text was originally in 3920
> was that the format of specifying a possible IP address in the JID
> differed from other RFCs.
> 
> As the JID address draft refers to the term 'address-literal', which is
> frequently surrounded by '[]' characters in other RFCs, including the
> referenced 3986, some implementers may miss the significance of the lack
> of "[" and "]" in the JID ABNF, and inadvertantly generate non-compliant
> JIDs by reusing code from other projects (the classic 'it looks like an
> email address or URI' argument)
> 
> Without changing the current ABNF, I'd like to see a statement in the
> JID address draft explicitly denying the usage of '[]' around IP address
> literals in the domainpart, eg:
> 
>  2.2.
>   ... it is possible that domainparts that are IP addresses will not be
>   acceptable to other services for the sake of interdomain communication.
> 
>   <t>Note: The specifying of IP addresses in the domainpart MUST NOT
>   include enclosing '[' and ']' characters.</t>
> 
> Alternatively, the ABNF for the JID address draft could be brought into
> alignment with 3986 by specifying:
> 
>  2.1.
>   domain = fqdn / IPv4address / IP-literal
>            ; the "IPv4address" and "IP-literal" rules are
>            ; defined in RFC3986.
> 
> which would result in domainpart allowing a bare IPv4 address (
> [email-masked]/bar ), and IPv6 and other literal addresses needing to be
> enclosed in '[]' as per RFC3986 .

Although I have never seen a domainpart consisting of an IPv6 address
(and have rarely seen one consisting of an IPv4 address), I think it
would be best to be consistent with RFC 3986 on this point.

> My other semantic nitpick is para 3 of 2.2:
> 
>   A domainpart <t>consisting of a fully qualified domain name</t> MUST be
>   an "internationalized domain name" ...

Fixed.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 06 Jul 2010 19:07:57 -0600

> would be best to be consistent with RFC 3986 on this point.

Looking at this more closely, I wonder if we could re-use the ihost
definition from RFC 3987. That would yield:

   jid            = [ localpart "@" ] ihost [ "/" resource ]
                    ; the "ihost" rule is defined in RFC 3987

where:

   ihost          = IP-literal / IPv4address / ireg-name
   ireg-name      = *( iunreserved / pct-encoded / sub-delims )
   iunreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~" / ucschar
   ucschar        = %xA0-D7FF / %xF900-FDCF / %xFDF0-FFEF
                  / %x10000-1FFFD / %x20000-2FFFD / %x30000-3FFFD
                  / %x40000-4FFFD / %x50000-5FFFD / %x60000-6FFFD
                  / %x70000-7FFFD / %x80000-8FFFD / %x90000-9FFFD
                  / %xA0000-AFFFD / %xB0000-BFFFD / %xC0000-CFFFD
                  / %xD0000-DFFFD / %xE1000-EFFFD

and where the "IP-literal" and "IPv4address" rules are as in RFC 3896.

This is a step in the right direction, because it appears (!) that the
ABNF in RFC 3920 doesn't allow anything but letter-digit-hyphen (i.e.,
nothing outside the US-ASCII range).

However, ireg-name isn't quite right either because some its aspects
(pct-encoded and sub-delims) are included for compabitility with URI
syntax, and we don't need those in native JIDs.

Thus we could do this:

   jid            = [ localpart "@" ] domainpart [ "/" resourcepart ]
   domainpart     = IP-literal / IPv4address / ifqdn
   ifqdn          = 1*( iunreserved )
                    ; the "iunreserved" rule is defined in RFC 3987

I'm not an ABNF guru, so feedback is welcome.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 7 Jul 2010 14:00:38 -0700

>   jid            = [ localpart "@" ] domainpart [ "/" resourcepart ]

Do we need a comment about implementations identifying the localpart, 
domainpart and resourcepart portions before applying any transformations? 
A quick glance shows %x2215 (division slash) just lurking there for the 
implementer who applies ToASCII to the domainpart before picking out the 
resourcepart.

> I'm not an ABNF guru, so feedback is welcome.

Apart from personally disliking '~' and '_' in the domainpart, WFM.

You may want to add an additional comment pointing people to IDNA2003 or 
IDNA2008 for rules regarding "ifqdn"/"domain name slot" when used on 
public networks, eg:

   ; the "iunreserved" rule is defined in RFC 3987
   ; [IDNA-DEFS] defines additional rules for "ifqdn" if used on public
   ; networks; see "domain name slot" in that document.

-- 
   Bruce.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Jul 2010 15:33:21 -0600

On 7/7/10 3:00 PM, Bruce Campbell wrote:
> domainpart and resourcepart portions before applying any
> transformations? A quick glance shows %x2215 (division slash) just
> lurking there for the implementer who applies ToASCII to the domainpart
> before picking out the resourcepart.

Good catch.

> Apart from personally disliking '~' and '_' in the domainpart

Yeah I don't like "_" either, and I've never seen "~"...

> , WFM.

Upon further reflection I'm still not sure that ifqdn works, because
iunreserved excludes characters that are disallowed in URIs but not
necessarily in internationalized domain names. I need to double-check.

>   ; networks; see "domain name slot" in that document.

Well, this version of the XMPP address spec is "legacy" in the sense
that it's not attempting to reflect the newer understanding of the world
from the IDNAbis documents. However, I think we need to cover any such
topics in the text and not in the ABNF. What exactly are the "rules for
use on public networks" and where in IDNA2003 are they mentioned?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Bruce Campbell <[email-masked]>
Date: Wed, 7 Jul 2010 15:17:51 -0700

On Wed, 7 Jul 2010, Peter Saint-Andre wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Re-reading the text under 2.2 for domainpart, the rules and references for 
internationalized domain names pretty much covers it with references to 
IDNA2003 and DNS (I was reacting to the removal of the 63 char mention in 
the ABNF).  Never mind ;)

-- 
   Bruce.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Jul 2010 16:25:52 -0600

On 7/7/10 4:17 PM, Bruce Campbell wrote:
> Re-reading the text under 2.2 for domainpart, the rules and references
> for internationalized domain names pretty much covers it with references
> to IDNA2003 and DNS (I was reacting to the removal of the 63 char
> mention in the ABNF).  Never mind ;)

OK. :) I'll work to submit a new version tonight for WG review.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 07 Jul 2010 17:27:43 -0600

>> before picking out the resourcepart.

In fact U+2215 DIVISION SLASH does not decompose to U+002F SOLIDUS,
although U+FE6B SMALL COMMERCIAL AT does decompose to U+0040 COMMERCIAL AT.

I've added this text:

###

      Implementation Note: When dividing a JID into its component parts,
      an implementation needs to match the separator characters '@' and
      '/' before applying any transformation algorithms, which might
      decompose certain Unicode code points to the separator characters
      (e.g., U+FE6B SMALL COMMERCIAL AT might decompose into U+0040
      COMMERCIAL AT).

###

> necessarily in internationalized domain names. I need to double-check.

Given that the Nameprep spec doesn't include ABNF, I'm inclined to punt
on this just as we have for nodeprep and resourceprep, by doing this:

      jid           = [ localpart "@" ] domainpart [ "/" resourcepart ]
      localpart     = 1*(nodepoint)
                      ; a "nodepoint" is a UTF-8 encoded Unicode code
                      ; point that satisfies the Nodeprep profile of
                      ; stringprep
      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 in RFC
                      ; 3986 applies to the matching process
      ifqdn         = 1*(namepoint)
                      ; a "namepoint" is a UTF-8 encoded Unicode
                      ; code point that satisfies the Nameprep
                      ; profile of stringprep
      resourcepart  = 1*(resourcepoint)
                      ; a "resourcepoint" is a UTF-8 encoded Unicode
                      ; code point that satisfies the Resourceprep
                      ; profile of stringprep