>
> > [BA] So how does the dereferencer know that HELD is to be used to
> > dereference rather than generic HTTP??
>
> They might use the content type of the response entity. The draft now makes this observation in S4.2, along with the other GET semantics.
>
> 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)?
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?)
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?
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).
e. Should a LIS be prepared to support content types other than "application/held+xml" in a request Accept: header?
