Subject: RE: [Geopriv] Common Policy Update

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 3 Apr 2006 23:41:14 -0500

Inline,

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Sunday, 2 April 2006 5:52 AM
> To: [email-masked]
> Subject: [Geopriv] Common Policy Update
> 
> Hi all,
> 
> based on the discussion regarding the identity extension I have compiled
> a new draft version. Please find the updated draft at:
> 
> http://www.tschofenig.com/TEMP/draft-ietf-geopriv-common-policy-09.txt
> http://www.tschofenig.com/TEMP/draft-ietf-geopriv-common-policy-09.html
> (Note that I have not yet submitted the document.)
> 
> The important modification relates to the introduction of a new
> extension point at the <identity> element. Here is the modified XML
> schema:
> 
> ------------
> 
>      ~snip~
> 
>      <!-- //conditions/identity -->
>      <xs:complexType name="identityType">
>          <xs:complexContent>
>              <xs:restriction base="xs:anyType">
>                  <xs:choice  minOccurs="0" maxOccurs="unbounded">
>                      <xs:element name="one" type="cp:oneType"/>
>                      <xs:element name="many" type="cp:manyType"/>
>  >>                  <xs:any namespace="##other" processContents="lax"
>  >>                  minOccurs="0" maxOccurs="unbounded"/>

The addition only needs to be:
>>                  <xs:any namespace="##other" processContents="lax"/>
Since the minOccurs and maxOccurs on the <xs:choice...> should suffice.

>                  </xs:choice>
>              </xs:restriction>
>          </xs:complexContent>
>      </xs:complexType>
> 
>      ~snip~
> 
> ------------
> 
> This issue was discussed during the Geopriv working group session at the
> last IETF meeting.
> 
> Additionally, I have added a new section about extensiblity with the
> following content:
> 
> ------------
>
> 12.  Extensibility

It is good to see this section here, but I question whether it was needed, particularly at this point.  I suggested a one sentence clarification to Section 7.1 that covered this for identity only.

If this is retained, then I think that it needs to be a little clearer.  Each point should include notes on the impact of including an extension, which is different for each. 

>     This document can be extended in the following ways:
> 
>     o  Conditions: The XML schema allows new child elements of the
>        <conditions> element to be defined.

Unknown conditions cause a processor to always ignore the rule, since they MUST evaluate as if the condition was not matched.

> 
>     o  Transformations: The XML schema allows new child elements of the
>        <transformations> element to be defined.

An unknown transformation also causes the rule to be skipped, since the processor cannot be sure which sections of the document are removed by the transformation.

> 
>     o  Actions: The XML schema allows new child elements of the <actions>
>        element to be defined.

I'm not sure what the impact of an unknown action would be.  I can see arguments for either ignoring the action or and invalidating the rule; I suspect that the rule would be invalidated though.

> 
>     o  Extensions to the Identity Element: The XML schema allows new
>        child elements of the <identity> element to be defined.

Extensions to identity are the only elements subject to an OR, and therefore they can be safely ignored without increasing permissions.

>     o  URI Schemes: New URI schemes can be defined for the 'id' attribute
>        according to [10].
> 
>     Unknown extensions can be safely ignored without impacting the user's
>     privacy.  In order to allow a RM to learn which extensions are
>     supported by a PS the policy capability extensions might be useful
>     (see [11], [12] and [13]).
> 

> 
> ------------
> 
> Thanks to Henning, Allison, Ted, Andy and Martin for the identity
> discussions. Please let me know if you are happy with the update.
> 
> Ciao
> Hannes
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 04 Apr 2006 13:46:19 +0200

Hi Martin,

thanks for the quick response.

I have added the following sentence to Section 7.1;
"
If a child element of <identity> is in a namespace that is not
known or not supported, it can be ignored.
"
and I deleted Section 12 about extensibility.

Here is the new draft version:
http://www.tschofenig.priv.at/TEMP/draft-ietf-geopriv-common-policy-09.txt
http://www.tschofenig.priv.at/TEMP/draft-ietf-geopriv-common-policy-09.html

Ciao
Hannes

Thomson, Martin wrote:
> Inline,
> 
> 
>> -----Original Message----- From: Hannes Tschofenig
>> [mailto:[email-masked]] Sent: Sunday, 2 April 2006 5:52
>> AM To: [email-masked] Subject: [Geopriv] Common Policy Update
>> 
>> Hi all,
>> 
>> based on the discussion regarding the identity extension I have
>> compiled a new draft version. Please find the updated draft at:
>> 
>> http://www.tschofenig.priv.at/TEMP/draft-ietf-geopriv-common-policy-09.txt
>>  
>> http://www.tschofenig.priv.at/TEMP/draft-ietf-geopriv-common-policy-09.html
>> <!-- //conditions/identity --> <xs:complexType name="identityType">
>>  <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:choice
>> minOccurs="0" maxOccurs="unbounded"> <xs:element name="one"
>> type="cp:oneType"/> <xs:element name="many" type="cp:manyType"/>
>>>> <xs:any namespace="##other" processContents="lax" minOccurs="0"
>>>> maxOccurs="unbounded"/>
> 
> 
>> </xs:choice> </xs:restriction> </xs:complexContent> 
>> </xs:complexType>
>> 
>> ~snip~
>> 
>> ------------
>> 
>> This issue was discussed during the Geopriv working group session
>> at the last IETF meeting.
>> 
>> Additionally, I have added a new section about extensiblity with
>> the following content:
>> 
>> ------------
>> 
>> 12.  Extensibility
> 
> 
> It is good to see this section here, but I question whether it was
> needed, particularly at this point.  I suggested a one sentence
> clarification to Section 7.1 that covered this for identity only.
> 
> If this is retained, then I think that it needs to be a little
> clearer.  Each point should include notes on the impact of including
> an extension, which is different for each.

> Unknown conditions cause a processor to always ignore the rule, since
> they MUST evaluate as if the condition was not matched.
> 
> 
> An unknown transformation also causes the rule to be skipped, since
> the processor cannot be sure which sections of the document are
> removed by the transformation.
> 
> 
>> o  Actions: The XML schema allows new child elements of the
>> <actions> element to be defined.
> 
> 
> I'm not sure what the impact of an unknown action would be.  I can
> see arguments for either ignoring the action or and invalidating the
> rule; I suspect that the rule would be invalidated though.
> 
> 
> Extensions to identity are the only elements subject to an OR, and
> therefore they can be safely ignored without increasing permissions.
> 
> 
>> o  URI Schemes: New URI schemes can be defined for the 'id'
>> attribute according to [10].
>> 
>> Unknown extensions can be safely ignored without impacting the
>> user's privacy.  In order to allow a RM to learn which extensions
>> are supported by a PS the policy capability extensions might be
>> useful (see [11], [12] and [13]).
>> 
> 
> 
>> ------------
>> 
>> Ciao Hannes
>> _______________________________________________ Geopriv mailing
>> list [email-masked] 
>  This message is for the designated recipient only and may contain
> privileged, proprietary, or otherwise private information. If you
> have received it in error, please notify the sender immediately and
> delete the original.  Any unauthorized use of this email is
> prohibited.