Sxip concerns with YADIS

[Martin Atkins]

Kurt Raschke wrote:
> 
> On Dec 19, 2005, at 8:46 AM, Martin Atkins wrote:
> 
>> While I'd like to agree with you, once the model changes to everyone
>> trampling separately over the LINK REL namespace, what exactly is  YADIS?
>> If everyone's picking their own stuff to add to the HTML HEAD, then  the
>> model is just "look at the HTML head for the stuff you support", which
>> is already possible and indeed widely used to discover RSS feeds  and so
>> forth.
> 
> 
> YADIS would be a way to keep from having "everyone trampling  separately
> over the LINK REL namespace"--a way to centralize  assignment of names
> for protocols in the LINK REL namespace, just as  there are systems for
> DNS, IP address, TCP/IP port numbers, etc.
> 
> YADIS would also provide an aegis under which to develop reference 
> implementations of the technology.
> 
> At the same time it's dead easy to parse--as has been pointed out,  many
> of the existing OpenID libraries use regexes to extract data  from the
> HTML HEAD.  There's no need for an HTML or XML parser there,  nor
> content negotiation.
> 

A centralised repository of anything seems like the antithesis of what
YADIS was created for: a decentralised (the D) means by which people can
work together on an ad-hoc basis by agreeing on a discovery mechanism.

It also seems to me that any attempt to "regulate" the LINK REL
"namespace" is doomed to failure, since that namespace is not owned by
YADIS and thus YADIS has no right to be regulating it. I would argue
further that even if YADIS does attempt this, it will largely be ignored
simply because there really is no benefit from an implementors point of
view to go through the motions to get an approved REL value when they
could equally just make one up, just as our hypothetical reformed YADIS
regulator would have done.

The main reason for moving away from keeping all of this stuff in the
HTML head was that it forces all clients to download all of this
discovery information even though YADIS relying parties are — and likely
always will be — in the minority. While for now most people are only
going to be declaring (for example) openid and LID capabilities, YADIS
is attempting to provide a foundation on which hundreds of overlapping
but not competing applications can be built, and listing 100 or more
capabilities using LINK REL would not only get cumbersome but would also
get quite "heavy" in terms of data transferred.

The converse is also true: YADIS clients would have to download an
entire HTML document as well as the LINK elements they are interested
in. While this is still necessary using the HTML indirection specified
in YADIS, users or identity providers have the option to make things
better using the content negotiation trick to serve the YADIS document
directly.

This is certainly a win for big providers like LiveJournal since the
YADIS replies can potentially be implemented entirely in the load
balancers without needing to touch a database nor an Apache process. If
YADIS is the success that people are hoping it will be, then moving
forward most YADIS URLs will be provided by these big providers just as
most OpenID identities are currently provided by LiveJournal and TypePad.