> > A Location Recipient MAY infer from a response containing the HELD
> content type, "application/held+xml", that a URI references a resource
> that supports HELD.
>
>
> [BA] Thanks.
>
> Some questions:
>
> a. In the above are you referring to the response in the original HELD
> exchange, or to a response to a dereference request (e.g. a GET or
> POST)?
I'm adding this to the discussion on GET, so that would be the implication. I suppose that if you get a HELD response to a HELD request, then you are pretty safe in assuming that the resource supports HELD.
> b. If this would apply to a dereference using a GET, is the
> implication that a HELD-capable client might subsequently choose to
> upgrade its requests to HELD (for error resilience or other reasons?)
Right. Say you dereference using GET and get a geodetic location. You could then upgrade and send a HELD request to get a civic address.
> c.. Should a de-reference request using GET specify the content types
> it prefers/is prepared to handle in the GET via an Accept: header?
Accept is always optional. In the absence of Accept:, the server gets to choose content type. A HELD server should always support application/held+xml, though they might also support application/pidf+xml as noted in S4.2.
> d. If so, are there content types that could be provided in the de-
> reference request other than "application/held+xml"? (e.g. to indicate
> whether the de-reference requester does/doesn't support HELD).
If Accept didn't include */* or application/* or application/held+xml, then the server would have to infer that they didn't support HELD and should send a 406 (Not Acceptable) response.
> e. Should a LIS be prepared to support content types other than
> "application/held+xml" in a request Accept: header?
A compliant HTTP server should act as above. I can see this not happening for various reasons (lazy implementation primarily). Most HTTP clients either send */* or omit Accept entirely so I can see a LIS implementation just ignoring Accept. RFC 2616 uses SHOULD for the 406 response, so that's arguably permissible behaviour.
--Martin
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
