<html>
<body>
<font size=3>Thanks for the comments.<br><br>
In the current draft, which the three reviewers have, the note in 6.2.5
has been removed.<br><br>
I'll put text in the Implementor's Guide based on these
comments.<br><br>
<br>
>>> Remember everyone: it's a wiki. Text for the
Overview and Implementor's Guide are welcome at:<br><br>
<a href="http://yadis.org/wiki/Main_Page#YADIS_Overview" eudora="autourl">
http://yadis.org/wiki/Main_Page#YADIS_Overview</a><br><br>
Cordially, Joaquin <br><br>
<br><br>
<blockquote type=cite class=cite cite="">Drummond wrote:<br>
+1 to Martin's clarification, i.e., it would be better to say that a<br>
conformant implementation MUST accept both a GET with an Accept:<br>
application/xrds+xml request-header and a GET without it, and then
specify<br>
the response in each case.</blockquote><br><br>
<blockquote type=cite class=cite cite="">Martin wrote:<br><br>
Section 6.2.5 of the spec has the following note:<br>
The response to the initial request MUST comply with
the HTTP<br>
protocol; therefore, if the request is a GET and does
not include<br>
an Accept: application/xrds+xml request-header, the
response MUST be<br>
of type 1 or 2. This is REQUIRED because the Relying
Party MAY omit<br>
the Accept and so might only look for the
X-YADIS-Location.<br><br>
I was with this until the last sentence. My reading of this suggests<br>
that all identity URLs must support the indirection case even if
they<br>
support the content negotiation case. This seems a little crazy.
This<br>
essentially gives identity URL maintainers two choices:<br><br>
* Support just the indirection case.<br>
* Support the indirection case and the content negotiation case.<br><br>
Out of those, I'd probably pick the first one since it's easier to
only<br>
support one case.<br><br>
I think it's more appropriate to say that YADIS relying parties MUST<br>
send application/xrds+xml in the Accept header with a suitable
quality<br>
value. It's much better to place this "burden" in the relying
party<br>
since most people will be using pre-rolled libraries for relying
parties<br>
and there is no disadvantage to supporting the content negotiation
case.<br><br>
------------------------------------------------<br><br>
As for the rest of that note, the correct way to respond when you
have<br>
no document that matches a type in the Accept header is with the<br>
response code "406 Not Acceptable", so if there's going to be
language<br>
in there about complying with the HTTP protocol there should also be<br>
some words about this, presumably saying that when a 406 response is<br>
recieved the relying party should still look for the
X-YADIS-Location<br>
header and, if the Content-type is text/html, look for the meta
tag.<br><br>
Note that Apache's content negotiation module will, in its default<br>
configuration, respond with 406 Not Acceptable as per the spec, so
this<br>
case is not unlikely to arise. Of course, in the case where Apache's<br>
content negotation module is in play, there's unlikely to be an<br>
X-YADIS-Location header.</font></blockquote></body>
</html>