proposal for capabilities lookup

[Michael Graves]

Xageroth Sekarius <xageroth <at> gmail.com> writes:

> 
> On 11/19/05, Michael Graves <groupmg <at> gmail.com> wrote:
> > If you're OK with "index.html" being a *convention* for serving HTTP 
requests
> > on a directory, then I can't see any problem with "yadis.xml" becoming an
> > analogous convention to "index.html".
> 
> The difference is if I don't want "index.html" to be my default, I can
> make "index.php" or "default.asp" my default. If I want anything other
> than "robots.txt" or "favicon.ico" or "yadis.xml" I'm stuck. Since we
> now use a LINK tag to change "favicon.ico", why not do the same for
> "yadis.xml"?

That's a good point. We're stuck between two evils: the threat of multiple 
indirection and a n-way fetch to get the basic bootstrapping info, and the 
problems caused by "hardcoding" or agreeing on things like "yadis.xml" by 
convention.

Given that, I'd lean toward indirection. Indirection yields flexibility, which 
enables adoption. The performance cost isn't trivial, but not a stopper either.

Given that, let me make this assertion: 

YADIS' Law of Discovery:

===
Any bootstrapping info needed for ID system discovery must be retrievable by 
dereferencing the YADIS ID.
===

That means that given an YADIS ID:

http://myhome.net/mgraves/

Whatever is returned by a fetch of this URL should yield what I need to get 
going in determining what ID capabilities this YADIS ID supports. The document 
returned by the fetch may be one of two things: an HTML document or an XML 
document. ID Consumers are free to to express their preference for one or the 
other in the initial request, but in the real world, it's unlikely that you'll 
get your choice of either; you're bound to get one or the other in most cases.

If the returned doc type is HTML, then we scan for whatever we need in the link 
tags. As you suggest, on of the If it's XML, we can traverse the document to 
discover the capabilities supported.

Note that this avoids file naming conventions for discovery. If the YADIS ID is 
dereferenced, we don't care whether the HTML file was actually 
called "index.php", "index.html" or "foo.htm" on the server's file system. If 
the server returns an XML document, we don't care if it was called "yadis.xml" 
or "ilovejohannes.xml", etc.

> So the primary method would be a CGI request of "meta=capabilities"
> and if the user is for whatever reason unable to handle such a request
> the response will be a HTML page and would then depend on a LINK rel
> for the "yadis.xml" location. (ie: rel="identity.capabilities"?) which
> is similar to if a "favicon.ico" file is not found but a LINK points
> to an icon from the page. That follows the Accept requirements as well
> of XML
> 
> --
> Xageroth Sekarius
> [ http://digitalmyth.net/ ]:[ http://xageroth.blogspot.com/ ]
> 
> 

I think that there's some good value in this idea, too. I'm thinking that the 
HTML document may simply contain a ref to the "yadis.xml" document for user. 
This means that in the case:

1. Consumer -> YADIS ID Host: GET /mgraves/
2. YADIS ID Host -> Consumer: HTML doc, with <link rel="yadis.capabilities", 
ref="/mgraves/yadis.xml"
3. Consumer -> YADIS ID Host: GET /mgraves/yadis.xml
4. YADIS ID Host -> Consumer: XML doc (named "yadis.xml" in this case, but can 
be named anything)

If on the other hand, the YADIS ID Host is smart, and is looking for a YADIS 
MIME type (something YADIS-specific like "application/yadis+xml"), we can skip 
the HTML snarfing and the additional fetch for the named capabilities doc.

In any case, this scenario avoids having to have file name conventions. Either 
the HTML <link> tag names the URL for the capabilities doc, or the server 
returns the capabilities doc as XML when the GET on the YADIS ID is received 
with header requests for a YADIS MIME type ("application/yadis+xml"?)

How about that?

-Mike