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

[Henning Schulzrinne <hgs at cs.columbia.edu>]

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

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.

> The word in the RFC is MAY:
>
>    Implementations with scheme-specific knowledge MAY convert
>    punycode-encoded domain name labels to the corresponding characters
>    by using the ToUnicode procedure.

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

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

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

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