proposal for capabilities lookup

[Martin Atkins]

Ernst Johannes wrote:
> So I think what we've established so far is that:
>  - the capabilities lookup needs to be orthogonal to the content type
>  - we should use what we can learn from other people who have  addressed
> similar problems with XML and XML schema, for example.
>  - we all think that establishing universal filename conventions is  not
> going to work. The reasons that were brought up are all similar  to the
> ones listed on http://en.wikipedia.org/wiki/Favicon (look for 
> "conflicts with the Architecture of the World Wide Web").
> 
> We also have the goals:
>  - we should not introduce new HTTP verbs (too messy, too hard)
>  - we should stay with common practice where established in similar 
> domains
>  - we should not use mechanism that may create caching problems with 
> intermediate caches outside of our control (or even knowledge)
>  - we need to minimize the number of HTTP requests, and the  bandwidth
> consumed
>  - we need to support users who want to be YADIS-enabled with a non-
> cooperative service provider, and service providers who want to YADIS-
> enable their users without them necessarily knowing what that is or 
> having to do anything special to their part of the puzzle (http  server
> vs. content)
> 

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.
* 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.

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.

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. Since YADIS is
potentially a layer atop OpenID, though, 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.