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

[Bruce Campbell <[e-mail]>]

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

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 7/7/10 3:00 PM, Bruce Campbell wrote:
>>
>> On Tue, 6 Jul 2010, Peter Saint-Andre wrote:
>>
>>> On 7/6/10 6:34 PM, Peter Saint-Andre wrote:
>>>> On 6/29/10 11:47 AM, Bruce Campbell wrote:
>>>>
>>>>> 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 (
>>>>> foo@1.2.3.4/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.
>>>
>>> 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 ]
>>
>> 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.
>
> Good catch.
>
>>>   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.
>>
>> 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.
>
>> 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.
>
> 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?

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.