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

[Peter Saint-Andre <[e-mail]>]

On 7/7/10 4:17 PM, Bruce Campbell wrote:
> 
> 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 ;)

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

Peter

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