thinking: Context has basically two parts,
1. Protocol mechanics for creating/updating/deleting contexts
2. Attributes of contexts that can be set with those mechanics
I was thinking that (1) could move toward being XCAP, and (2) could move
toward extensions of the policy language.
In particular, w.r.t. (2), there are only three things that can be set:
-- "Authorization policy" is already common-policy
-- "Context lifetime" may require some extension, but is largely the
same as the <validity> element of common-policy
-- "Snapshot context" is the most novel, but you could probably still
implement it with an extension to the <provide-location> element from
geopriv-policy.
The protocol mechanics (1) don't do anything really magical; I think you
could map semantics pretty cleanly to a combination of HELD and XCAP.
--Richard
Winterbottom, James wrote:
> Hi Richard,
>
> I see Context as a being a container, one of the things of which it can contain is a common policy document.
>
> Does that help?
>
> Cheers
> James
>
>
> -----Original Message-----
> From: Richard Barnes [mailto:rbarnes@bbn.com]
> Sent: Mon 9/21/2009 3:42 PM
> To: James M. Polk
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); Winterbottom, James; Hannes Tschofenig; GEOPRIV
> Subject: Re: HELD using XCAP wrt Common Policy/Geolocation Policy
>
> James: Don't worry. Nothing in held-context is getting rid of or
> duplicating Common Policy. The difference is that held-context does
> some things that are not possible today with common-policy or
> geopriv-policy framework.
>
> Hannes/James: Thinking back to the discussions at the Dallas interim
> some time ago, I thought that there was a motion to move the
> held-context toward being more of an extension to common-policy, rather
> than an alternative policy transport. Am I recalling correctly?
>
> --Richard
>
>
>
>
> James M. Polk wrote:
>> At 02:27 AM 9/21/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote:
>>> I could imagine that adding the ability to upload Common
>>> Policy/Geolocation Policy as an add-on to
>>> draft-winterbottom-geopriv-held-context-04.txt is a lot easier than
>>> using XCAP, particularly since I believe that 95% of the cases will only
>>> make usage of a fraction of Common Policy (and nothing from the
>>> geolocation policy document).
>> I'm trying to figure out what is being said here in Hannes' paragraph
>> above.
>>
>> Is HELD really not needing Common Policy/Geolocation Policy because it
>> has another ID specifying some other mechanism?
>>
>> If so, why would this WG allow this?
>>
>> Common Policy is supposed to be "common" to everything, right?
>>
>> Geolocation Policy is supposed to be used by everything Geopriv
>> specific, right?
>>
>> It appears the net result of this - if true - is that DHCP has to jump
>> through hoops that HELD doesn't, even though HELD can.
>>
>> James
>>
>>
>>> Ciao
>>> Hannes
>>
>
>
> ------------------------------------------------------------------------------------------------
> 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
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
