proposal for capabilities lookup
groupmg at gmail.com
Mon Nov 21 11:10:53 PST 2005
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
> > 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
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
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:
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",
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?
More information about the yadis