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
