Re: [Geopriv] policy-uri

From: Hannes Tschofenig ^lt;Hannes.Tschofenig@gmx.net>
Date: Fri Jul 30 2010 - 08:34:57 EDT

I did not follow the work; maybe some of the hardcore SIP guys may know
the status of this work.

On 30.07.2010 14:21, Richard L. Barnes wrote:
> What's in the policy URI draft *is* REST/HTTP, and could easily be
> re-used in other contexts. So if the other work stalled, we can
> replace it with this.
>
> Could you provide a more specific reference? Otherwise, it doesn't
> seem like this issue should be blocking for this draft.
>
> --Richard
>
>
> On Jul 30, 2010, at 2:13 PM, Hannes Tschofenig wrote:
>
>> Another question:
>>
>> there was some work to do a non-XCAP (REST/HTTP) based approach to
>> configure call handling (forward etc.) rules on a server. It was not
>> to replace XCAP but that work run into "who's going to implement it"
>> type of issues.
>>
>> What happened with that work? Seems to be relevant to me.
>>
>> Ciao
>> Hannes
>>
>>
>>
>> On 30.07.2010 14:05, Richard L. Barnes wrote:
>>> <hat type="individual"/>
>>>
>>> The only concern raised in the meeting with regard to
>>> draft-barnes-geopriv-policy-uri was when Hannes noted that the
>>> exchange could be made more efficient (in the HELD context)
>>> overlaying the policy interactions on a HELD transaction. For
>>> example, the client could provide policy data in a <locationRequest>
>>> object, and the server could specify policy it intends to use in the
>>> <locationResponse>. I think we should not do this.
>>>
>>> The problem is that it introduces weird failure cases: Consider the
>>> following request:
>>> <locationRequest>
>>> <locationType>civic geodetic locationURI</locationType>
>>> <ruleset> ... </ruleset>
>>> </locationRequest>
>>>
>>> Suppose a server receives this request, and the server is happy to
>>> provide all three types of location, but it doesn't want to accept
>>> the policy. What should happen is that the server can provide
>>> location and indicate that it has rejected the policy. With the
>>> current HELD syntax, the rejection of policy could only be indicated
>>> with an <error> response, which would mean that location wouldn't
>>> get delivered. So we would need to introduce a separate,
>>> "non-critical" error reporting mechanism.
>>>
>>> Handling policy in a separate channel allows policy negotiations not
>>> to interfere with basic delivery -- we can benefit from the
>>> error-handling mechanisms in HTTP, without having to re-implement it
>>> inside the HELD XML. An extra HTTP request is not that expensive.
>>>
>>> As was said on another topic in the meeting: Let's just have one way.
>>>
>>> --Richard
>>> _______________________________________________
>>> 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
Received on Fri, 30 Jul 2010 14:34:57 +0200

This archive was generated by hypermail 2.1.8 : Fri Jul 30 2010 - 08:35:12 EDT