[Simple] Proposed Resolution to the draft-ietf-geopriv-common-policy issue.
Ted Hardie <hardie@qualcomm.com> Fri, 30 June 2006 19:42 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwOsZ-00071P-PZ; Fri, 30 Jun 2006 15:42:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwOsY-000715-BK; Fri, 30 Jun 2006 15:42:14 -0400
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwOsX-0001FZ-SV; Fri, 30 Jun 2006 15:42:14 -0400
Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k5UJg7Hj014455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 30 Jun 2006 12:42:08 -0700
Received: from [10.0.1.5] (dhcp-campbell-28.qualcomm.com [129.46.225.24]) by magus.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id k5UJg36a022329; Fri, 30 Jun 2006 12:42:05 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p06230902c0cb2603bf22@[10.0.1.5]>
Date: Fri, 30 Jun 2006 12:42:01 -0700
To: geopriv@ietf.org, simple@ietf.org
From: Ted Hardie <hardie@qualcomm.com>
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e
Cc: Cullen Jennings <fluffy@cisco.com>, hartmans@mit.edu, phoffman@isc.org
Subject: [Simple] Proposed Resolution to the draft-ietf-geopriv-common-policy issue.
X-BeenThere: simple@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: SIP for Instant Messaging and Presence Leveraging Extensions <simple.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/simple>
List-Post: <mailto:simple@ietf.org>
List-Help: <mailto:simple-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/simple>, <mailto:simple-request@ietf.org?subject=subscribe>
Errors-To: simple-bounces@ietf.org
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. _______________________________________________ Simple mailing list Simple@ietf.org https://www1.ietf.org/mailman/listinfo/simple
- [Simple] Proposed Resolution to the draft-ietf-ge… Ted Hardie
- [Simple] Re: [Geopriv] Proposed Resolution to the… Andrew Newton
- [Simple] RE: [Geopriv] Proposed Resolution to the… Thomson, Martin