<span class="q"><blockquote>Brad Fitzpatrick wrote:<br>
>Plus once there are two ways, people will be surprised when their HTML<br>
>(all they can see!) doesn't work, because there are mystery magic HTTP<br>
>headers.<br>
<br>
>So I'd say HTML headers would have to always override the Link header. I<br>
>don't care much about the HEAD request. I figure people can do GET<br>
>requests with byte ranges, asking for the first 1k or 2k. The latest<br>
>version of Net::OpenID::Consumer (unreleased) has to do a GET to get the<br>
>full head and find rss, atom, foaf, foafmaker, etc, which is then<br>
>available from the VerifiedIdentity object.<br>
</blockquote></span>
I really don't have much to add to any of the conversations that have come up but I did want to interject one thought here.<br>
<br>
A couple of days ago, when the idea of the header element was first
brought up I thought someone made a good point concerning the<br>
link and header relationship. Basically, if the user is on a
service provider, (AOL, MSN, whatever) and that host adds an indentity
server<br>
header it would be great for all those users who don't really want to
worry about doing it themselves. However, if a user wants to specify a<br>
different server that they actually have control over, then their only
real option is the <link> because of that I think the
<link> such supercede<br>
the header.<br>
<br>
In the end it should be up to the user who verifies them. I would
bet MOST users will never know what an HTTP header is let alone how to
set one up. But, thanks to various places that they already login
they may create an OPENID account that they want to use as their
primary identifier and, subsequently, override the header. Heck,
the user probably wont even know their service provide has the header
there. Thus, when their <link> doesn't work they won't
understand, get frustrated, and will probably end up abandoning the
idea of using an OPENID.<br>