Archive · Yadis wiki

Draft-002 Alternatives

From the archiveThis page is part of the working wiki of the Yadis discovery protocol, kept here as it was written by the project’s participants in 2005–2006. It is preserved for the record and is not maintained as current documentation. All archived pages →

Note: This page is a draft currently under discussion. It is not yet an official part of Yadis.

This page summarizes the alternatives proposed so far for a Capability Discovery Protocol.

Another page summarizes the requirements for a protocol.

General discussion on the discussion page, pros and cons of specific alternatives on the pages indicated below, please.

Name	Alternative	Pro	Con
Draft-002-a	Use the `?meta=capabilities` argument to the identity URL. Discuss at Draft-002-a	Architecturally clean Fallback implementation possible	Requires CGI scripts which slows (prevents?) adoption
Draft-002-b	Use the HTTP Accept header (alternatively user agent or X-Yadis) to ask for capabilities document instead of regular content at identity URL. Discuss at Draft-002-b	No new URLs required, straighforward Fallback implementation possible	Requires CGI scripts which slows (prevents?) adoption Harder to implement (unusual HTTP header)
Draft-002-c	Use a URL convention a la `favicon.ico`. See details and discuss at Draft-002-c	Very simple Even non-tech users may simply upload a file to the webspace they got from their ISP to have their own Yadis domain, but the "file" can as well be provided via scripts on larger identity hosts	New URL convention User adoption: some users may own the document named by their Yadis URL, but not have control over other documents in the same directory; documents named by more than one Yadis URL may be in the same directory.
Draft-002-d	Link attribute in HTML head field points to capabilities URL. Discuss at Draft-002-d	Architecturally clean	Some hosts may not allow users to edit their HTML head field User adoption: many users don't even know what HTML head may be, and won't / won't be able to edit it. Unnecessary overhead/traffic: the whole document must be requested Bound to (X)HTML
Draft-002-e	Texts in the page suggest capabilities. Discuss at Draft-002-e	Easiest for adoption	Architecturally unclean Not all pages saying things like "I do OpenID." really are identity URLs (like this page here). This only identifies the particular protocol(s) provided. So, (in some cases) an additional request will be required to learn the specific capababilities.
Draft-002-f	Require user to enter the URL of the capabilities document (instead of his homepage or blog URL). Discuss at Draft-002-f	Architecturally clean Very simple	Users have two different URLs (if there is also a human-readable profile, homepage or blog related with this user) to remember, to put on business cards etc. However, a qualifier could be used (like Draft-002-a does) to get from one URL to the other, so the user may not have to ever see the two URLs.
Draft-002-g	All capabilities are specified via multiple Link attributes in HTML head field. Discuss at Draft-002-g	Architecturally clean	Some hosts may not allow users to edit their HTML head field User adoption: many users don't even know what HTML head may be, and won't / won't be able to edit it. Unnecessary overhead/traffic: the whole document must be requested Bound to (X)HTML
Draft-002-h	Capabilities document can be retrieved from a URL that the HTTP server returns as part of all/most HTTP non-error responses, similar to the `Location` HTTP header for redirects. E.g. create new header `X-Yadis-Location`. The`http-equiv` trick can be used for those circumstances where the server cannot be configured by the user (in this case, it becomes very similar to Draft-002-d)	Architecturally clean Architectural parallel with URIs pointing to DTDs in XML	requires potentially one more GET operation