Re: [Geopriv] HELD using XCAP wrt Common Policy/Geolocation Policy

["Hannes Tschofenig" <[e-mail]>]

Hi Richard, 

Regarding (1): The usage of XCAP for the transport instead of the mechanism
currently described in Context is certain something we could investigate. I
have not followed the recent work in BLISS but aren't some folks trying to
invent a new protocol mechanism to update XCAP?

Regarding (2): I have tried to create such an extension to Common Policy &
the Gelocation Policy (since I thought it was a good idea after the
discussion we had at the interim meeting) but then the outcome convinced me
that it isn't. 

Here is the result I came up with about a year ago:
http://www.ietf.org/mail-archive/web/geopriv/current/msg05907.html

We might want to revisit that very brief discussion and try to the
complexity for implementers. 

Ciao
Hannes


>-----Original Message-----
>From: Richard Barnes [mailto:[e-mail]] 
>Sent: 22 September, 2009 00:08
>To: Winterbottom, James
>Cc: James M. Polk; Tschofenig, Hannes (NSN - FI/Espoo); Hannes 
>Tschofenig; GEOPRIV
>Subject: Re: HELD using XCAP wrt Common Policy/Geolocation Policy
>
>Hm, no, that's not the answer I was looking for.  Here's what I'm
>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:[e-mail]]
>> 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]
>> 
>> 
>