Subject: [Geopriv] draft-ietf-geopriv-policy-19.txt

From: "Hannes Tschofenig" <[email-masked]>
Date: Sun, 25 Jan 2009 15:02:31 +0200

Hi all, 

I just submitted an updated version of the geolocation policy document 
http://www.ietf.org/internet-drafts/draft-ietf-geopriv-policy-19.txt
with the following changes: 

* Added a paraprah to the security consideration section to address Tim's
comment in a better way. 
* Added a label attribute that contains a human readable description for
location elements. 
  This addresses Lisa's comment. 
* Added an Internationalization Considerations section. 

There is one open issue, namely a description on how a policy server would
return an appropriate error if the civic-condition could not be interpreted,
or was interpreted in a way that was not useful as a condition. This relates
to the capability of XCAP. Still have to figure this one out.

Ciao
Hannes

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

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 26 Jan 2009 17:55:32 -0600

Hi Hannes,

The schema for the new label doesn't match the examples.  Which is it?

By the examples:

<gp:location-condition>
  <gp:location profile="civic-condition"
	xml:lang="en" label="Siemens Neuperlach site 'Legoland'">

or by schema:

<gp:location-condition>
  <gp:label xml:lang="en">Siemens Neuperlach site 'Legoland'</gp:label>
  <gp:location profile="civic-condition">

I'd be surprised if you hadn't already thought this: I wonder whether the label could be more widely used.  A label sounds pretty handy for _any_ rule, not just a specific condition.

On your addition to security: I don't have a problem with a frank description of the problem without a good solution, but rather than education, it seems like robust feedback is better.  Also, I'd avoid mention of transcoding, since this is just one of many potential sources of error.

   ... Location might be the only factor in the policy that
   triggers a very different action and transformation to be executed.
   The accuracy of location information is not always sufficient to
   unequivocally determine whether a location is within a specific
   boundary [15].  In some situations uncertainty in location 
   information could produce unexpected results from application of
   policy.  Providing adequate user feedback about potential errors
   arising from these limitation can help prevent unintentional
   information leakage.

Other minor things (and I apologise for not mentioning this earlier, I'd be satisfied with a simple answer on either): 

Whitespace: Generally, xs:token behaves more to user expectations than xs:string.  Producers that require whitespace have a slightly harder time with xs:token, but it is consistent with HTML and makes the XML more user readable and allows for formatting.

XCAP: Why is it necessary to distinguish between an application usage of XCAP for 'pres-rules' and 'geolocation-policy'?  Could this not use the XCAP registration established by RFC 5025?

Nit: missing & in the new text for section 4: "each lt;location> element"

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Hannes Tschofenig
> Sent: Monday, 26 January 2009 12:03 AM
> To: 'GEOPRIV'
> Cc: 'Tim Polk'; 'Lisa Dusseault'
> Subject: [Geopriv] draft-ietf-geopriv-policy-19.txt
> 
> Hi all,
> 

------------------------------------------------------------------------------------------------
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://www.ietf.org/mailman/listinfo/geopriv

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 27 Jan 2009 11:39:08 +0200

Hi Martin, 

Comments below:

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Thomson, Martin
>Sent: 27 January, 2009 01:56
>To: Hannes Tschofenig; GEOPRIV
>Cc: Tim Polk; Lisa Dusseault
>Subject: Re: [Geopriv] draft-ietf-geopriv-policy-19.txt
>
>Hi Hannes,
>

Good catch. I might have messed up something with copying the XML files
into the draft document. 

>I'd be surprised if you hadn't already thought this: I wonder 
>whether the label could be more widely used.  A label sounds 
>pretty handy for _any_ rule, not just a specific condition.

True. The problem is that we have placed the extension point in the
Common Policy a bit unfortunate so that this would not work.
We would have to re-issue an updated version of Common Policy IMHO.

>
>On your addition to security: I don't have a problem with a 
>frank description of the problem without a good solution, but 
>rather than education, it seems like robust feedback is 
>better.

What type of robust feedback have you been thinking about? 
Protocol and/or user interface? 

  Also, I'd avoid mention of transcoding, since this is 
>just one of many potential sources of error.

But Tim's issue was specific about transcoding and I wanted to also
include transcoding explicitly. 
I also mentioned that there are other sources for error. 

>   arising from these limitation can help prevent unintentional

Sounds good. 
>
>
>Other minor things (and I apologise for not mentioning this 
>earlier, I'd be satisfied with a simple answer on either): 
>
>Whitespace: Generally, xs:token behaves more to user 
>expectations than xs:string.  Producers that require 
>whitespace have a slightly harder time with xs:token, but it 
>is consistent with HTML and makes the XML more user readable 
>and allows for formatting.

Fine for me. 

>
>XCAP: Why is it necessary to distinguish between an 
>application usage of XCAP for 'pres-rules' and 
>'geolocation-policy'?  Could this not use the XCAP 
>registration established by RFC 5025?

The 'pres-rules' application usage of XCAP could be used with this
document when location is in context of presence information. 
The rules in this could, however, also be used without presence. 

Ciao
Hannes

>> * Added a label attribute that contains a human readable description 
>> for location elements.
>> There is one open issue, namely a description on how a policy server 
>> would return an appropriate error if the civic-condition 
>could not be 
>> interpreted, or was interpreted in a way that was not useful as a 
>> condition. This relates to the capability of XCAP. Still have to 
>> figure this one out.
>> 
>> Ciao
>> Hannes
>> 
>>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 27 Jan 2009 15:42:25 -0600

Hi Hannes,

The label could be provided as an always true condition.  Of course, a revised common policy would have the advantage of allowing you to revise the schema to allow for extension...

On user feedback, user interface is what I was thinking.  For instance, a user could be given a way to see whether their current location matches any of the rules in their policy.  As an extension, a feedback loop using watcher-info could be used, but that's the sort of creativity I'd expect from implementations.

Ta,
Martin

> From: Tschofenig, Hannes (NSN - FI/Espoo)
> [mailto:[email-masked]]
> Sent: Tuesday, 27 January 2009 8:39 PM
> To: Thomson, Martin; Hannes Tschofenig; GEOPRIV
> Subject: RE: [Geopriv] draft-ietf-geopriv-policy-19.txt
> 
> Hi Martin,
> 
> Comments below:
>