HTTP Headers vs. link rel=

[Bill Rawlinson]

Brad Fitzpatrick wrote:
>Plus once there are two ways, people will be surprised when their HTML
>(all they can see!) doesn't work, because there are mystery magic HTTP
>headers.

>So I'd say HTML headers would have to always override the Link header. I
>don't care much about the HEAD request. I figure people can do GET
>requests with byte ranges, asking for the first 1k or 2k. The latest
>version of Net::OpenID::Consumer (unreleased) has to do a GET to get the
>full head and find rss, atom, foaf, foafmaker, etc, which is then
>available from the VerifiedIdentity object.

 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.

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
link and header relationship. Basically, if the user is on a service 
provider, (AOL, MSN, whatever) and that host adds an indentity server
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
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
the header.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/yadis/attachments/20050524/e1155f62/attachment.html