Subject: [Geopriv] HELD Context & Common Policy

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 12 Jul 2008 22:44:42 +0300

At the interim meeting we had discussions how the authorization policies 
in HELD Context
http://tools.ietf.org/id/draft-winterbottom-geopriv-held-context-02.txt
could be expressed using the Common Policy framework.

Here is an example:

   <?xml version="1.0" encoding="UTF-8"?>
   <ruleset
       xmlns="urn:ietf:params:xml:ns:common-policy"
       xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy"
       xmlns:lp="urn:ietf:params:xml:ns:basic-location-profiles"
       xmlns:co="urn:ietf:params:xml:ns:held-context">

       <rule id="AA56ia9">
           <conditions>
              <co:max-use>10</co:max-use>
              <validity>
                <from>2008-07-124T8:00:00+01:00</from>
                <until>2008-07-12T10:00:00+01:00</until>
              </validity>
           </conditions>
           <actions/>
           <transformations>
               <co:snapshot>yes</co:snapshot>
               <gp:provide-location
                  profile="civic-transformation">
                  <lp:provide-civic>full</lp:provide-civic>
               </gp:provide-location>
           </transformations>
       </rule>
   </ruleset>

This is more complex than the current encoding scheme in the HELD 
context document.

Ciao
Hannes

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

---

From: Richard Barnes <[email-masked]>
Date: Sun, 13 Jul 2008 15:20:02 -0400

It seems a little odd to put the "snapshot" designation in the 
"transformations" field.  I think of the transformations as modifying 
whatever LO the LS started with, whereas, the snapshot flag tells the LS 
what LO to start with.

Would it be appropriate to use the "actions" stanza to describe what 
location the LS should use as a base, namely snapshot vs. current?

<actions>
   <co:determine-snapshot time="2008-07-124T8:00:00+01:00"/>
</actions>

<actions>
   <co:determine-current />
</actions>

--Richard

---

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 13 Jul 2008 22:51:29 +0300

That's certainly possible.

Richard Barnes wrote:
> whatever LO the LS started with, whereas, the snapshot flag tells the 
> LS what LO to start with.
>
>> At the interim meeting we had discussions how the authorization 
>> policies in HELD Context

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 13 Jul 2008 18:57:01 -0500

Hi Richard,

The <co:determine-current /> element is not necessary, unless you consider this as a means of controlling caching (that is, disabling it).  I'd prefer to see the elements from draft-thomson-geopriv-location-quality added to the <actions> section if that is what you desire.  That way, it is possible to control caching and also set a target uncertainty.

The "snapshot" concept is the hardest to translate into policy because it is so closely tied to the means for establishing the context.  There are complications.  Prior versions of the specification didn't have any information on whether a LIS was expected to locate the Target when the request was made or not.  If the LIS responded immediately and subsequently couldn't determine a location, there was undefined behaviour.  Something to think on...

I'm interested in what you see the semantic of the "time" attribute to be.  Given the nature of the interactions, there are two boundary times to be concerned with:
  - the time that the context is established; and
  - the time that the location URI is dereferenced.

That leaves three scenarios:

 1 - time < context creation: in this case, it is unlikely that the LS is able to do anything, being limited as it is by well-known temporal restrictions it can't initiate location determination in the past.  It would be forced to reject any such rule - although if the time was only slightly in the past, there might be some room for leniency (how much leniency is an interesting topic).

 2 - time >= context creation && time <= dereference time: this is the easy one.  The LS/LIS can simply wait until the specified time and then attempt to locate the Target.  It can store this result and serve it up when the time comes.

 3 - time > dereference time: this is potentially quite useful.  This could be used to set a start time for the context.  It should be noted that upon creation, the time of dereference can't be known, so there are some ambiguities that arise.  In particular, the varied arrangements of overlap with the requested response time in the dereference request and the time that location determination takes make this one interesting.

In all, I can understand why this might be useful, but the variables would have to be nailed down.  However, for snapshot, I think that it is more appropriate as a function of the base protocol so that behaviour can be more closely tied to the creation of the context.

Cheers,
Martin

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Richard Barnes
> Sent: Monday, 14 July 2008 5:20 AM
> To: Hannes Tschofenig
> Cc: GEOPRIV
> Subject: Re: [Geopriv] HELD Context & Common Policy
> 
> LS
> policies

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