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
