Re: [Geopriv] Proposed Resolution to the draft-ietf-geopriv-common-policy issue.

On Jun 30, 2006, at 3:42 PM, Ted Hardie wrote:
> In 7.
>
>
> NEW
>
>    The access to data items needs to be matched with the rule set  
> stored
>    at the PS.  Each instance of a request has different attributes
>    (e.g., the identity of the requestor) that are used for
>    authorization.  A rule in a rule set might have a number of
>    conditions that need to be met before executing the remaining parts
>    of a rule (i.e., actions and transformations).  Details about rule
>    matching are described in Section 10.  This document specifies  
> only a
>    few conditions (i.e., identity, sphere, and validity).  Further
>    condition elements can be added via extensions to this document.
>
>    As noted above in section five, conditions are matched on equality
>    or "great than" style comparisons, rather than regular expressions.
>

    s/great than/greater than/

>    Equality is determined according to the rules for the data type  
> associated
>    with the element in the schema given in section 13 below, unless  
> explicit
>     comparison steps are included in this document.  For xs:anyURI  
> types,
>     readers may wish to consult [RFC 3987] for its discussion  
> xs:anyURI, as
>     well as the text in [XML Schema].
>

> In 7.1.3
[..snip..]
> Rationale:
>
> The original step one described a potential optimization, in which  
> the strings were first checked
> to see if they had already been converted using  toASCII.  Because  
> the "for each label" text appeared
> only in Step 4., this was, however, an incomplete optimization. It  
> only caught the cases where the
> first label was the label that had an IDN component; for all other  
> cases, the string went through
> a second iteration of toASCII.  This wasn't a problem, since  
> applying toASCII to a string which has
> already been transformed by toASCII has no effect (as RFDC 3490,  
> Section 4.1. puts it :
> "Applying the ToASCII operation multiple times has exactly the same  
> effect as applying it just once.")
> It is, however, a bit confusing.  To clarify this, I suggest we  
> drop the optimization entirely.  It does
> no harm to have multiple trips through ToASCII, and the process  
> seems harder to get right in the
> presence of the optimization than in its absence.

I agree.

-andy