proposal for capabilities lookup
dag at janrain.com
Thu Nov 17 14:01:11 PST 2005
I'd like to suggest using 'X-YADIS' as the header field for the
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
> - 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
> - 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://
> 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
> 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
More information about the yadis