Subject: [Geopriv] Domain identifier in common policy

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 11 Nov 2005 13:25:35 -0500

The last remaining open issue in common policy is the format of the 
domain attribute in common policy.

Concrete suggestion:

Use RFC 3987 (internationalized domain names):

ihost = IP-literal / IPv4address / ireg-name

Every URI is also an IRI, so this should work generally. This supports 
both IPv4 and IPv6. RFC 3987 also provides comparison rules, in Section 
5. This has the advantage that the same code would already be needed for 
the full IRI comparison for the 'id' parameter.

Henning

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Andrew Newton <[email-masked]>
Date: Mon, 14 Nov 2005 14:54:55 -0500

On Nov 11, 2005, at 1:25 PM, Henning Schulzrinne wrote:

> Every URI is also an IRI, so this should work generally. This  
> supports both IPv4 and IPv6. RFC 3987 also provides comparison  
> rules, in Section 5. This has the advantage that the same code  
> would already be needed for the full IRI comparison for the 'id'  
> parameter.

Given Jonathan's comment, I thought he was more focused on actual  
domain names and not IP addresses.  I don't care.  I just thought  
that was what was said.

Even if the domain field is limited to ireg-name, I do not believe  
that solves the problem.  I'm not an IRI expert, but it appears that  
not all ireg-name values are legal domain names.

And I still wonder about the IDN case, especially given that this  
appears to be an exact match.  Which form is the exact match  
performed on, the UTF8, a NamePrepped domain, or an ACE encoded  
domain.  Given that there can be variants of an IDN floating around  
on the wire, it always seems to me that the comparison should be done  
on the ACE version.

If there is somebody with better IDN-in-IRI clue, please correct me.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Nov 2005 15:17:10 -0500

> domain names and not IP addresses.  I don't care.  I just thought  that 
> was what was said.

Right; I just want to make sure we don't get into an IPv4 vs. IPv6 
discussion.

> 
> Even if the domain field is limited to ireg-name, I do not believe  that 
> solves the problem.  I'm not an IRI expert, but it appears that  not all 
> ireg-name values are legal domain names.

Sure, but this is not a new problem. example.andy, ccs.columbia.edu or 
ex$ample.com are not valid domain names, either, even without the I18N 
problems. Thus, there will always be valid domain-looking strings that 
don't match any protocol-possible string. This isn't an issue - the rule 
  component just will never match and somebody will have to fix the typo.

> appears to be an exact match.  Which form is the exact match  performed 
> on, the UTF8, a NamePrepped domain, or an ACE encoded  domain.  Given 
> that there can be variants of an IDN floating around  on the wire, it 
> always seems to me that the comparison should be done  on the ACE version.

I may be looking at the wrong thing, but Section 5 of RFC 3987 seems 
relevant:

  5.  Normalization and Comparison . . . . . . . . . . . . . . . . . 21
        5.1.  Equivalence  . . . . . . . . . . . . . . . . . . . . . . 22
        5.2.  Preparation for Comparison . . . . . . . . . . . . . . . 22
        5.3.  Comparison Ladder  . . . . . . . . . . . . . . . . . . . 23
              5.3.1.  Simple String Comparison . . . . . . . . . . . . 23
              5.3.2.  Syntax-Based Normalization . . . . . . . . . . . 24
              5.3.3.  Scheme-Based Normalization . . . . . . . . . . . 27
              5.3.4.  Protocol-Based Normalization . . . . . . . . . . 28

---

From: Andrew Newton <[email-masked]>
Date: Mon, 14 Nov 2005 16:04:14 -0500

On Nov 14, 2005, at 3:17 PM, Henning Schulzrinne wrote:
>> Even if the domain field is limited to ireg-name, I do not  
>> believe  that solves the problem.  I'm not an IRI expert, but it  
>> appears that  not all ireg-name values are legal domain names.
>
> Sure, but this is not a new problem. example.andy, ccs.columbia.edu  
> or ex$ample.com are not valid domain names, either, even without  
> the I18N problems. Thus, there will always be valid domain-looking  
> strings that don't match any protocol-possible string. This isn't  
> an issue - the rule  component just will never match and somebody  
> will have to fix the typo.

I guess what I'm trying to say is that not all IRIs produce a valid  
domain name.  If you are saying, "it doesn't matter, these are never  
handed to gethostbyname()" then I agree with you.

>> domain.  Given that there can be variants of an IDN floating  
>> around  on the wire, it always seems to me that the comparison  
>> should be done  on the ACE version.
>
> I may be looking at the wrong thing, but Section 5 of RFC 3987  
> seems relevant:
>
>        5.1.   
> Equivalence  . . . . . . . . . . . . . . . . . . . . . . 22
>        5.2.  Preparation for  
> Comparison . . . . . . . . . . . . . . . 22
>        5.3.  Comparison  
> Ladder  . . . . . . . . . . . . . . . . . . . 23
>              5.3.1.  Simple String  

At the very least, common-policy ought to point out which comparison  
is being done.  I would assume that since these are being used as  
identifiers, that section 5.3.1 is the section that is relevant here.

And it might be that I'm just not smart enough to understand  
something as trivial as internationalized character comparison, but  
what happens with punycode encoded domain names?  As the example from  
that RFC: if I receive it as domain="xn--99zt52a", do I convert it to  
domain="&#x7D0D;&#x8C46;" for the comparison?  As the RFC states:

    Implementations with scheme-specific knowledge MAY convert
    punycode-encoded domain name labels to the corresponding characters
    by using the ToUnicode procedure.

Again, I'm not an expert, but shouldn't something specify what is to  
happen here for doing this identity comparison?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Nov 2005 16:34:36 -0500

I'm probably well beyond my I18N/IDN depth here, so I agree that 
external advice is called for.

My understanding of RFC 3987, Section 5, is that these steps are 
performed in sequence, starting with the low-cost step in 5.3.1 and 
progressing to steps requiring more work if there's no match.

First, I think we can restrict ourselves to discussing URIs appearing in 
specific protocols, such as part of a SIP From URI or an XMPP URI.

There are probably two cases: Protocols that are clearly specified as 
using IRIs already (XMPP, say) and those that require discussion (SIP, 
say). [Discussion is required for SIP since SIP itself allows UTF-8 and 
RFC 3987 Section 6.3 alludes to the fact that most schemes do not have 
to be upgraded to support IRIs.]

I'll stick to the IRI case. If the IRI shows up in the protocol request, 
the steps in 5.3.1 would be executed until either a match occurred or 
the process falls off the ladder mentioned in the spec. Clearly, some of 
the comparison steps do not apply since they concern the port number or 
path components of the comparison.

 From my reading of 3987, the punycode version would be compared as well 
during the ladder, presumably by converting the IDN to punycode. (I 
suspect that the conversion from UTF-8 to punycode is unique, while I 
suspect that this is not true in the other direction. In other words, 
multiple UTF-8 strings could generate the same punycode.)

This is all a bit messier than ASCII comparison, but I don't think we 
want users to edit punycode into their XML rule files.

Henning

> At the very least, common-policy ought to point out which comparison  is 
> being done.  I would assume that since these are being used as  
> And it might be that I'm just not smart enough to understand  something 
> as trivial as internationalized character comparison, but  what happens 
> with punycode encoded domain names?  As the example from  that RFC: if I 
> receive it as domain="xn--99zt52a", do I convert it to

---

From: Andrew Newton <[email-masked]>
Date: Mon, 14 Nov 2005 17:30:22 -0500

> external advice is called for.

Me too.  So no argument here.

> progressing to steps requiring more work if there's no match.

I'm not saying you are wrong, but that's not the impression I got  
when reading that section.  Otherwise, whey is step 1 (simple string  
comparison) a MUST in certain situations if it always a MUST.

> First, I think we can restrict ourselves to discussing URIs  
> appearing in specific protocols, such as part of a SIP From URI or  
> an XMPP URI.

I do not agree with this.  If HELD comes to fruition, we'll be  
talking about HTTP schemes as well.

> There are probably two cases: Protocols that are clearly specified  
> as using IRIs already (XMPP, say) and those that require discussion  
> (SIP, say). [Discussion is required for SIP since SIP itself allows  
> UTF-8 and RFC 3987 Section 6.3 alludes to the fact that most  
> schemes do not have to be upgraded to support IRIs.]
>
> I'll stick to the IRI case. If the IRI shows up in the protocol  
> request, the steps in 5.3.1 would be executed until either a match  
> occurred or the process falls off the ladder mentioned in the spec.  
> Clearly, some of the comparison steps do not apply since they  
> concern the port number or path components of the comparison.

This sounds right.  I don't think we need to worry about the URI case  
either.

> From my reading of 3987, the punycode version would be compared as  
> well during the ladder, presumably by converting the IDN to  
> punycode. (I suspect that the conversion from UTF-8 to punycode is  
> unique, while I suspect that this is not true in the other  
> direction. In other words, multiple UTF-8 strings could generate  
> the same punycode.)

The word in the RFC is MAY:

Also, what do you do with the domain attribute?  With  
domain="xn--99zt52a" there is no scheme specific part.  Because this  
is being done for comparison purposes, perhaps common-policy ought to  
insist on the conversion in domain= with a MUST ToUnicode.  The only  
problem with this is a future scenario where UTF-8 is considered  
legal in DNS (DNS is 8-bit) labels.  Then you have two domain names  
that are compared as equivalent even though they may not be.  Perhaps  
thats worrying too much.

> This is all a bit messier than ASCII comparison, but I don't think  
> we want users to edit punycode into their XML rule files.

You'd be amazed at what end users find to do with cut-and-paste.

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Nov 2005 19:32:18 -0500

> I'm not saying you are wrong, but that's not the impression I got  when 
> reading that section.  Otherwise, whey is step 1 (simple string  

I'm not sure which MUST you are referring to, but based on

  If this range of comparison practices is considered as a ladder, the
    following discussion will climb the ladder, starting with practices
    that are cheap but have a relatively higher chance of producing false
    negatives, and proceeding to those that have higher computational
    cost and lower risk of false negatives.

I take it that you start with 5.3.1 and compare the two IRIs. If the 
string comparison produces "equal", you're done. If not, it is still 
possible that two IRIs are equal, after transformation, so you proceed 
to step 5.3.2, etc. At any step, if you discover equality, you fall off 
the ladder and declare equality. The steps are set up not to produce 
false positives, i.e., declaring two IRIs equal when they are not.

>> First, I think we can restrict ourselves to discussing URIs  appearing 
>> in specific protocols, such as part of a SIP From URI or  an XMPP URI.
> 
> 
> I do not agree with this.  If HELD comes to fruition, we'll be  talking 
> about HTTP schemes as well.

'such as' does not preclude other protocols. For HTTP, the notion of 
using the request URI as an identifier makes little sense since it 
identifies the target of the query (the "presentity"). The authorization 
is clearly based on who is asking, not who is being asked. Thus, for 
HTTP, you would probably need to use the Digest or other identity 
string, not the request URI. This is an orthogonal issue, however.

>    by using the ToUnicode procedure.

For our application, it might make sense to make this MUST.

> domain="xn--99zt52a" there is no scheme specific part.  Because this  is 

> being done for comparison purposes, perhaps common-policy ought to  
> problem with this is a future scenario where UTF-8 is considered  legal 
> in DNS (DNS is 8-bit) labels.  Then you have two domain names  that are 
> compared as equivalent even though they may not be.  Perhaps  thats 
> worrying too much.

I looked at RFC 3490 (IDNA) in more detail just now. For the 'domain' 
attribute, I think we can simplify the comparison process as follows:

--- begin text ---

Common policy MUST use UTF-8 to store domain names in 'id' domain 
attributes. For non-IDNs, lower-case ASCII SHOULD be used.

(1) If both domain attribute and protocol domain identifier are in UTF-8 
and do not begin with xn--, attempt a string comparison. If the string 
comparison indicates equality, the comparison succeeds and the remaining 
steps are skipped.

(2) Translate percent-encoding for either string and repeat (1).

(3) Convert both domain strings using the toASCII operation described in 
RFC 3490. (Naturally, if one of the strings already begins with the ACE 
prefix xn--, the conversion operation has already been performed.)

(4) Compare the two domain strings for ASCII equality, for each label.

If the conversion fails in step (3), the domains are not equal.

--- end text ----

Does this work?

Henning

---

From: Andrew Newton <[email-masked]>
Date: Mon, 14 Nov 2005 20:31:17 -0500

On Nov 14, 2005, at 7:32 PM, Henning Schulzrinne wrote:
> I take it that you start with 5.3.1 and compare the two IRIs. If  
> the string comparison produces "equal", you're done. If not, it is  
> still possible that two IRIs are equal, after transformation, so  
> you proceed to step 5.3.2, etc. At any step, if you discover  
> equality, you fall off the ladder and declare equality. The steps  
> are set up not to produce false positives, i.e., declaring two IRIs  
> equal when they are not.

My reading of section 5 is that it is a ladder where the lower rungs  
are least expensive and more common.  We'll have to seek guidance on  
this.

>>> appearing in specific protocols, such as part of a SIP From URI  
>>> or  an XMPP URI.
> 'such as' does not preclude other protocols. For HTTP, the notion  
> of using the request URI as an identifier makes little sense since  
> it identifies the target of the query (the "presentity"). The  
> authorization is clearly based on who is asking, not who is being  
> asked. Thus, for HTTP, you would probably need to use the Digest or  
> other identity string, not the request URI. This is an orthogonal  
> issue, however.

There are movements afoot to use HTTP URIs as user identifiers.   
Therefore, I think it is reasonable to foresee HTTP URIs as the "who  
is asking."
> (1) If both domain attribute and protocol domain identifier are in  
> UTF-8 and do not begin with xn--, attempt a string comparison. If  
> the string comparison indicates equality, the comparison succeeds  
> and the remaining steps are skipped.
>
> (3) Convert both domain strings using the toASCII operation  
> described in RFC 3490. (Naturally, if one of the strings already  
> begins with the ACE prefix xn--, the conversion operation has  
> already been performed.)
>

I think it does.  What do you mean by "protocol domain identifier" in  
step 1?

-andy

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 14 Nov 2005 20:39:36 -0500

> are least expensive and more common.  We'll have to seek guidance on  this.

I think we're in agreement.

>> UTF-8 and do not begin with xn--, attempt a string comparison. If  the 

> I think it does.  What do you mean by "protocol domain identifier" in  

I mean the part related to the 'asking' (using) protocol that identifies 
the domain of the querier. This probably needs a more descriptive term.