proposal for capabilities lookup

[Ernst Johannes]

I'm not entirely following what you are proposing. Comments in-line.

> I think two goals are most important for adoption:
> * Those using their own site as an identity URL must be able to add
> YADIS support without writing any code or greatly disturbing their
> existing site. (The HTML indirection case.) This implies a regular  
> GET,
> as you mentioned.

So we agree on this one.

> * In *that same request* consumers must somehow indicate that it's
> really capabilities that they are interested in, so that larger  
> identity
> hosts like LiveJournal can remove the layer of indirection and just
> return the capabilities directly, without having to generate a rather
> costly journal page that's just going to be discarded. This is the
> purpose I was bending "Accept" for.

That's why I was talking about the "local convention". Or do you mean  
a global convention?

The idea of returning a new URL from which the capabilities can be  
retrieved is modeled directly after XML: XML files also typically  
specify their schema through a separate URL, rather than in-lining it  
(which they could, but which is undesirable for a variety of reasons).

This compromise is usually acceptable because DTDs change very  
slowly, while XML files change relatively quickly: which is why XML  
processors all have this funny local cache of retrieved DTDs.

> It seems to me that the path of least disruption is just to use a  
> custom
> request header in place of Accept in my proposal. However, this has  
> the
> drawback that it's nonstandard and thus proxy servers are less  
> likely to
> be able to cope with its presence causing a different response,  
> even if
> it appears in the "Vary" header field.

Note that my proposal does not require such a custom request header,  
it only uses a non-standard response header.

> I seem to remember that a very similar conclusion was reached when we
> were discussing this for OpenID, which is why OpenID only supports the
> HTML indirection case despite its inherent inefficiency.

The OpenID case is a little different because the URL points to the  
OpenID identity server, rather than a capabilities lookup (which does  
not exist in OpenID). On another level, of course there is a parallel  
-- but note that my proposal does not make things worse, does it?

> Since YADIS is
> potentially a layer atop OpenID, though,

The other way around? ;-)

> it's not really acceptable to
> add two or more extra requests on top of a protocol that's already
> pushing it. We need to solve this problem here rather than just  
> brushing
> it under the rug.

Well, as I see it, we have not had a proposal that cleanly solves all  
the requirements and optimizes all the goals at the same time, and we  
have been discussing this for quite a while now. Time to compromise?  
I for one don't expect that somebody suddenly has a brilliant idea  
that we all simply hadn't thought of before.... and if so, we could  
always create a YADIS 2 ;-) Time is also an important factor here for  
adoption.

[If you push me, I'd be willing to add a ?meta=x-xrid or ? 
meta=capabilities or some other URL argument back in, with the idea  
that it doesn't impact the operation of most YADIS URLs -- that don't  
understand the argument and just ignore it -- or that return the j- 
meta data directly instead of the indirection]


Johannes Ernst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20051118/ab7e017f/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst