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

Andrew Newton <andy@hxr.us> Fri, 30 June 2006 20:04 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwPDt-0006I2-11; Fri, 30 Jun 2006 16:04:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwPDr-0006Gi-6v; Fri, 30 Jun 2006 16:04:15 -0400
Received: from zeke.ecotroph.net ([69.31.8.124]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwPDp-0003oT-RH; Fri, 30 Jun 2006 16:04:15 -0400
Received: from [10.0.1.105] ([::ffff:68.106.115.242]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zeke.ecotroph.net with esmtp; Fri, 30 Jun 2006 16:04:31 -0400 id 01588118.44A583CF.000049F0
In-Reply-To: <p06230902c0cb2603bf22@[10.0.1.5]>
References: <p06230902c0cb2603bf22@[10.0.1.5]>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <5FA36EE9-2705-488A-8A8F-479506B650C6@hxr.us>
Content-Transfer-Encoding: 7bit
From: Andrew Newton <andy@hxr.us>
Date: Fri, 30 Jun 2006 16:04:10 -0400
To: Ted Hardie <hardie@qualcomm.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: geopriv@ietf.org, hartmans@mit.edu, simple@ietf.org, phoffman@isc.org
Subject: [Simple] Re: [Geopriv] 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

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
Simple@ietf.org
https://www1.ietf.org/mailman/listinfo/simple