capabilities lookup

[Michael Graves]

Drummond Reed <drummond.reed <at> cordance.net> writes:

> 
> 
> 
> While discussing XRI and YADIS with a
> major DNS registrar last Friday, they pointed out something so obvious (from
> their fresh perspective) that I hadn't thought to look at it that way before.
> 
>  
> 
> They pointed out that an XRI *always* points to an YADIS XRD file, by
> definition. That's what makes the full XRI abstraction layer – it's not
> just an abstract identifier, but an abstract descriptor for the resource (the 
YADIS
> XRD file). Even when you turn an XRI into an URL (by using an HTTP proxy
> resolver as defined in section 6 of XRI Resolution Working Draft 09), it still
> points to a YADIS XRD file. That's why the XRI resolution protocol specifies a
> content type of "application/xrds+xml", because the only content type
> the XRI resolution protocol deals with is YADIS XRDs. 
> 
>  
> 
> That gave me a new perspective on the
> issue of how to discover a YADIS file from a URL. I think it's fair to say 
that
> this problem only exists when the URL identifies some other resource besides a
> YADIS file, correct? (After all, if the URL identifies the YADIS file, all the
> relying party has to do is an HTTP GET on the URL to retreive the YADIS file,
> and it's off to the races.)
> 
>  
> 
> So the problem being worked on is: how do
> you retrieve the YADIS file from a URL that does NOT identify the YADIS file,
> i.e., the URL for a Web home page or a blog home page or a page within a CMS
> somewhere?
> 
>  
> 
> Which makes me ask what might be a REALLY stupid
> question: why not just require the URL to identify the YADIS file?
> 
>  
> 
> Yes, I know this means that it might be
> hard to create an identity URL at a web server where you can't place a file or
> you can't control the defaults. But since it is SO easy to find a web server
> where you CAN place a file, is it really worth trying to solve the generalized
> (and difficult) problem of how to specify turning a URL that identifies one
> resource into a URL that identifies a different resource (the YADIS XRD file)?
> 
>  
> 
> (Again, just punt this question if it's
> really fall-off-the-edge stupid 
> 
>  
> 
> =Drummond 

Technically, that's a really smart way to proceed. The problem is that it runs 
into problems with user preferences. For printing on a business card, there's a 
lot of appeal to Joe Foobar if he can use:

http://www.joefoobar.com/

As his YADIS ID. To skip indirection through his home page, he could have have 
business card say instead:

[web] http://www.joefoobar.com/
[yadis] http://joefoobar.com/yadis.xml

Technically, that makes things much more efficient and precise. But the users 
won't dig. Part of the desire is to *coalesce* and *unify* common URLs people 
use right now to identify themselves. Or, to say it another way, an important 
goal is to be able to equip *existing* and *desired* URLs with YADIS 
capabilities.  Specifying the YADIS XRD file is totally straightforward and 
good, but doesn't solve the "business card requirement", which I believe must 
be solved if YADIS is going to have the kind of adoption it deserves.

Our job then, is to support:

1. URLs that directly identify YADIS XRDs
2. URLs that identify HTML pages that contain embedded metadata pointing to a 
YADIS XRD.

#1 will happen, but #2 needs to be smooth and polished, as that is what is 
going to make the masses embrace this. 
 
-Mike