proposal for capabilities lookup

[Ernst Johannes]

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)

There's also this goal, which I'm not sure we discussed this on this  
list, but certainly it has been discussed in person:

if possible, we should allow high-volume consumers (think Yahoo,  
Google etc.) to shortcut the protocol for those YADIS identity hosts  
where the YADIS identity host has decided on a (local, not universal)  
convention and the consumer is aware of the local convention. For  
example, if site highvolumebloghost.example.com hosts one zillion  
YADIS identifiers, but their "j-meta" information can always be  
retrieved from http://highvolumebloghost.example.com/some/very/ 
specific/j-meta/path, then a high volume consumer of YADIS  
identifiers should be able to write special-purpose code just for  
this site, and just for the time period that  
highvolumebloghost.example.com does not change its mind on its local  
proprietary convention. (If the high-volume consumer does not want to  
write special-purpose code -- and certainly for everybody else who  
isn't a high-volume consumer -- highvolumebloghost.example.com will  
still need to support the general-purpose protocol, and YADIS will  
only standardize that)

All of this seems to point strongly to a separate URL (or URI, or  
IRI, or XRI, ... I will just use the term URL for simplicity from  
here) from which the "j-meta" data should be retrieved, rather than  
"hiding it" behind the same URL as pretty much all of us on this list  
-- me included :-( -- have suggested so far.

So my proposal boils down to something very simple: all we need to  
define is how a given YADIS URL can return another URL that points to  
its "j-meta" data. We don't even have to request it specifically --  
it could always do it, because it's fairly cheap: it's just a single  
URL.

[For those of you who remember when "reflection" or "run-time type  
identification" was introduced to OO languages like C++: I'm  
basically suggesting to add a pointer from the instance to the type  
aka j-meta data, just like they did to make that possible]

Because of the two different deployment scenarios -- user wants YADIS  
in spite of service provider (that controls web server), and vice  
versa -- we need two mechanisms for getting this 'j-meta" URL across:  
one on the HTTP protocol level, and one on the content level.

Which, revealingly enough, is very similar to the HTML META http- 
equiv tags: "Dear user, if for whatever reason you can't change the  
behavior of your web server in spite of the fact that this is really  
a matter of HTTP, not HTML, then we grudgingly give you the  
workaround to say the stuff you want to say inside an HTML document  
using http-equiv".

What remains to define is the field name. Pick any one you like ;-) J- 
Meta comes to mind, or better not ;-) I have no problem with "Meta",  
you might have different suggestions ... Using X-Meta from here.


So this is how it would work (leaving out any potential, site- 
specific shortcuts that are left as an exercise for the reader)

1) User visits Identity Consumer (aka Relying Party) http:// 
consumer.example.com, enters their YADIS-enabled URL such as http:// 
yadis.example.net/johnny

2) Consumer performs a regular HTTP GET or HEAD on http:// 
yadis.example.net/johnny, nothing special

3) YADIS URL http://yadis.example.net/johnny returns the following  
HTTP response header:

HTTP/1.1 200 OK
Date: ....
Server: ....
Transfer-Encoding: ...
Content-Type: text/html (or whatever pleases the web server)
X-Meta: http://capabilities.example.biz/walter

(note there is no problem with caching)

4) Identity consumer now performs an HTTP GET on http:// 
capabilities.example.biz/walter to get the capabilities document

Alternatively:

In step 3, the X-Meta header is not present, but the content type is  
text/html. Then:
In step 4, Identity consumer parses HTML document for special tag  
inside HTML HEAD -- that could be a link tag, or -- what I'd like  
better given the parallels with http-equiv -- looks for
<meta http-equiv="X-Meta" content="http://capabilities.example.biz/ 
walter" />
in the HTML document and proceeds as before.

Regardless of whether you like my proposal or not (I hope you do ...)  
-- are there any requirements that I'm not addressing with this  
proposal?



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/20051117/de9d83e0/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst