<html>
<body>
<br>
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite=""><font size=3>... static file
semantics be embraced in HTTP requests, as it lets end users work things
out for themselves independently when needed -- a huge advantage in
gaining adoption for the spec.</font></blockquote></blockquote><br>
I have no idea what 'semantics' is intended to mean in "static file
semantics." I do see the advantages that Michael has pointed out in
using only a resource name in the capabilities request (no question mark
or such like) and making it a simple GET request (relying on no other
features). <br><br>
If we can accomplish that, it will be a big win.<br><br>
Thanks, Michael.<br><br>
I'll repeat for emphasis some of Michael's design principles<br><br>
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite=""><font size=3>the priority is
just one thing: adoption. Anything that slows adoption should be
included grudgingly if at all. "The great is the enemy of the
good" <br><br>
anything that is going to require extensions to conventional behavior of
existing web servers is kryponite for <br>
adoption<br>
<br>
straightforward advocacy of "convention over configuration"
[is], in this case, crucial for minimizing the amount of accomodation by
users and hosts to achieve maximum adoption in the shortest possible
timeframe.<br>
<br>
the adoption-friendly "notepad principle" [tells us what
technology we should require of the adopter]
</font></blockquote></blockquote><br>
I'll repeat the conclusion he draws from these principles:<br><br>
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite=""><font size=3>simply ask the
[resource located by the] identity URL to do one thing: tell us your
authoritative identity server.</font></blockquote></blockquote><br>
And I'll repeat his defense of this conclusion:<br><br>
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite=""><font size=3>If we simply scrape
some HTML to determine the delegated ID server for the URL, and carry out
everything else with the ID server, we have a) minimal (maybe zero)
impact on the hosting provider for the Identity URL, and maximum
flexibility in terms of features for the ID server.<br><br>
The ID server can be written anyway that's necessary. It's new machinery,
and has to be developed and deployed somehow anyway. The [adopter's web]
server can't be required to change, or adoption will be severely
constrained. </font></blockquote></blockquote><br>
Cordially, Joaquin<br>
</body>
</html>