[Simple] Re: [Geopriv] Domain identifier in common policy

[Andrew Newton <andy at hxr.us>]

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.

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

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="納豆" 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

_______________________________________________
Simple mailing list
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple