Anonymous user

Draft-002 Alternatives

From Yadis

Jump to: navigation, search

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. Thehttp-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
Retrieved from "https://yadis.org/wiki/Draft-002_Alternatives"
Personal tools