Re: [Geopriv] policy-uri

From: Richard L. Barnes ^lt;rbarnes@bbn.com>
Date: Fri Jul 30 2010 - 08:21:00 EDT

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:21:00 +0200

This archive was generated by hypermail 2.1.8 : Fri Jul 30 2010 - 08:21:14 EDT