proposal for capabilities lookup

[Dag Arneson]

I'd like to suggest using 'X-YADIS' as the header field for the 
capabilities document.

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)
> 
> 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
> 
> ------------------------------------------------------------------------
> 
>  http://netmesh.info/jernst
> 
> 
>