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:rbarnes@bbn.com]
>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: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
