Re: [Geopriv] HELD Context & Common Policy

["Thomson, Martin" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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
> 
> 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
> 
> 
> 
> Hannes Tschofenig wrote:
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/geopriv
> >
> _______________________________________________
> Geopriv mailing list
> [e-mail]
> https://www.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
[e-mail]
https://www.ietf.org/mailman/listinfo/geopriv