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

[Ted Hardie <[e-mail]>]

Howdy,

During the IESG review of this draft, Sam Hartman raised an issue relate to the internationalization aspects
of this draft and asked that it be given further review on that topic.  Paul Hoffman was kind enough to review
it, and after he and I discussed the issues Sam raised, we agreed that there was problem in the description
in 7.1.3.  Below there is a proposed RFC Editor note to resolve it.

Paul also felt that it would be good to include an informative reference to RFC 3987
(the IRI spec) on the first mention of xs:anyURI, since it contains useful applicability language.  He
also suggested that the document highlight the statement made in section 5 that conditions are matched
on equality by repeating and expanding on it in the beginning of Section 7.  I propose adding a reference
to xs:anyURI in Section 7, and combining those notes.
			regards,
				Ted Hardie


In 7.

OLD

   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.

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

Rationale:

The statements that matching was based on equality or "greater than" style comparisons
are repeated more prominently.  An explicit reference to the XML Schema document
and RFC 3987 will also help clarify how to construct conditions such that equality
matching works as expected.

   

In 7.1.3

OLD:

   1.  If the values of the 'domain' attribute and the value of the
       protocol domain identifier does 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 [2].  (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 string comparison for each label indicates
       equality, the comparison succeeds.  Otherwise, the domains are
       not equal.

   If the conversion fails in step (3), the domains are not equal.


NEW:

   1.  Translate percent-encoding for either string.

   3.  Convert both domain strings using the toASCII operation described
       in RFC 3490 [2].

   4.  Compare the two domain strings for ASCII equality, for each
       label.  If the string comparison for each label indicates
       equality, the comparison succeeds.  Otherwise, the domains are
       not equal.

   If the conversion fails in step (2), the domains are not equal.


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.

_______________________________________________
Geopriv mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/geopriv