<HTML>
<HEAD>
<TITLE>Re: [OpenID] HTML-Based Discovery incompatibilities</TITLE>
</HEAD>
<BODY>
<FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Exactly. Look at what has been working properly and what has not and clean up the spec. The problem with OpenID, unlike most other protocols in this space is that it is too close to the end-user surface. The sole reason for the inclusion of <link> elements is to allow the end –user direct influence over the internals of the protocol. So if this feature is not widely adopted, it leads directly to breaking the faith the end-user has in the entire protocol. When you use a Yahoo feature that doesn’t work, you don’t blame HTTP for it. But if you use OpenID directly, and it doesn’t work you do blame OpenID more than anything else.<BR>
<BR>
While your approach is correct, I think the issue is the sample size you are using to decide what is “common-practice”. In reality, most of the spec should be dropped due to lack of consistent implementation.<BR>
<BR>
EHL<BR>
<BR>
<BR>
On 1/8/09 1:05 PM, "Martin Atkins" <<a href="mart@degeneration.co.uk">mart@degeneration.co.uk</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>Eran Hammer-Lahav wrote:<BR>
><BR>
> If I will have any influence on future RP adoption, I will do my best to<BR>
> make them ignore HTML discovery completely. After all, in OpenID, it doesn't<BR>
> seem to matter what the spec says anyway (unfortunately).<BR>
><BR>
<BR>
Are there any protocols where this is not the case?<BR>
<BR>
There are bad implementations of every specification. The choice we need<BR>
to make as specification authors is whether to pretend all<BR>
specifications are perfect and continue adding more and more<BR>
requirements, or to instead write a specification that describes current<BR>
implementation practice.<BR>
<BR>
I think in most cases specifications should be driven by<BR>
implementations, rather than the other way around. A specification that<BR>
describes something that doesn't work in practice is of no use to<BR>
anyone, and writing new specs with even more stringent requirements<BR>
doesn't automatically fix all of the existing "broken" implementations.<BR>
<BR>
_______________________________________________<BR>
general mailing list<BR>
<a href="general@openid.net">general@openid.net</a><BR>
<a href="http://openid.net/mailman/listinfo/general">http://openid.net/mailman/listinfo/general</a><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>