Yadis on LiveJournal and section 6.2.5

[Martin Atkins]

Yesterday I made a commit to LiveJournal to make all LiveJournal
accounts YADIS Identity URLs. For now it's just a different way to
declare the existing OpenID support, but it's a start. This is unlikely
to appear on LiveJournal.com for some time though, since many of
LiveJournal's staff are currently on vacation.  On to my main point,
anyway...

Section 6.2.5 of the spec has the following note:
    The response to the initial request MUST comply with the HTTP
    protocol; therefore, if the request is a GET and does not include
    an Accept: application/xrds+xml request-header, the response MUST be
    of type 1 or 2. This is REQUIRED because the Relying Party MAY omit
    the Accept and so might only look for the X-YADIS-Location.

I was with this until the last sentence. My reading of this suggests
that all identity URLs must support the indirection case even if they
support the content negotiation case. This seems a little crazy. This
essentially gives identity URL maintainers two choices:

* Support just the indirection case.
* Support the indirection case and the content negotiation case.

Out of those, I'd probably pick the first one since it's easier to only
support one case.

I think it's more appropriate to say that YADIS relying parties MUST
send application/xrds+xml in the Accept header with a suitable quality
value. It's much better to place this "burden" in the relying party
since most people will be using pre-rolled libraries for relying parties
and there is no disadvantage to supporting the content negotiation case.

------------------------------------------------

As for the rest of that note, the correct way to respond when you have
no document that matches a type in the Accept header is with the
response code "406 Not Acceptable", so if there's going to be language
in there about complying with the HTTP protocol there should also be
some words about this, presumably saying that when a 406 response is
recieved the relying party should still look for the X-YADIS-Location
header and, if the Content-type is text/html, look for the meta tag.

Note that Apache's content negotiation module will, in its default
configuration, respond with 406 Not Acceptable as per the spec, so this
case is not unlikely to arise. Of course, in the case where Apache's
content negotation module is in play, there's unlikely to be an
X-YADIS-Location header.