The reliance on Content-type

[Martin Atkins]

The current spec relies on the returned Content-type value to determine
what kind of document has been retrieved. This is how HTTP was intended,
but in the real world most website owners don't know how to or can't
configure a specific content type for a resource on their site.

In these cases, the XRID file will probably get served as either
text/plain or text/xml. Per the current spec, that would cause the
consumer to flag an error.

I propose, for the sake of "Let's be realistic, here!", that we make a
special allowance for this problem, but *only* in the HTML indirection case.

Per the current spec, the HTML indirection case involves a LINK element
like the following:
<link rel="identity.capabilities"
      type="application/xrid+xml"
      href="http://myid.example.com/capabilities">

The type is spelled out in the LINK element here. My proposal is that in
the case where the type given here is correct, consumers be instructed
to disregard the type returned by the server and attempt XML parsing. If
the root element's namespace is wrong or the document is not well formed
at all failure will soon follow. Consumers should still pay attention to
other aspects of the response, including making sure that the status
code is 200 OK. That way they can fail early if it's a 404 Not Found.

The direct access case is assumed to be used only by people who "know
what they're doing", so we can keep that case simple.

This does make things a little more complicated, but I think it's
important for early adoption.