At BLISS we are trying to define set of URIs along with
rules on how these URIs are to be used to enable/disable
common features on the proxy (call-forward ON/OFF,
voicemail ON/OFF for particular AoR etc.). Each configuration
is viewed as a resource, represented as a URI following the
REST principle.
We are not defining a protocol per se, but trying to
provide a simple solution to an interoperability problems
observed in a wild, while maintaining forward compatibility
to XCAP.
So we are neither updating XCAP nor replacing XCAP.
Regards
Shida
On Sep 22, 2009, at 3:59 PM, Hannes Tschofenig wrote:
> 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: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
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
