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

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Fri, 30 Jun 2006 16:04:10 -0400