List Info

Thread: Proposed Resolution to the draft-ietf-geopriv-common-policy issue.




Proposed Resolution to the draft-ietf-geopriv-common-policy issue.
user name
2006-06-30 20:04:10
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

_______________________________________________
Simple mailing list
Simpleietf.org
https:/
/www1.ietf.org/mailman/listinfo/simple
[1]

about | contact  Other archives ( Real Estate discussion Medical topics )