Appendix A. Example
The following example list the stores in which an individual name Jane Doe created wish-lists for her friends to use to buy her presents. The examples assumes an open standard has been established for wish-list representation, which is identified by the namespace URI http://specs.example.com/wish_list/1.0. According to the wish-list specification, requests for a user’s wish list include the user’s screen name in a URL-encoded parameter.<XRDS xmlns="xri://$xrds"> <XRD xmlns:simple="http://xrds-simple.net/core/1.0" xmlns="xri://$XRD*($v*2.0)" version="2.0"> <Type>xri://$xrds*simple</Type> <Service priority="10"> <Type>http://specs.example.com/wish_list/1.0</Type> <URI simple:httpMethod="GET">http://books.example.com/wishlist</URI> <LocalID>jane<LocalID> </Service> <Service priority="20"> <Type>http://specs.example.com/wish_list/1.0</Type> <URI simple:httpMethod="GET" priority="10">https://dvds.example.org/lists/wishes</URI> <URI simple:httpMethod="GET" priority="20">http://dvds.example.org/lists/wishes</URI> <LocalID>janedoe<LocalID> </Service> </XRD> </XRDS>
Appendix B. History of XRDS
The XRDS discovery document format originated at the OASIS XRI (Extensible Resource Identifier) Technical Committee working in conjunction with the early OpenID community. The acronym XRDS – Extensible Resource Descriptor Sequence – was coined out of discussions between XRI TC members and OpenID developers at first Internet Identity Workshop held in Berkeley, CA in October 2005.
[OpenID Authentication 1.1] (Recordon, D. and B. Fitzpatrick, “OpenID Authentication 1.1,” .) needed an HTTP(S)-based service discovery mechanism for URLs, and the XRI TC had already defined an HTTP(S)-based resolution mechanism and a general-purpose service discovery format for XRIs (a new type of abstract structured identifier). With a few changes, a subset of the XRDS functionality defined by the XRI Resolution specification would work with both URLs and XRIs. This subset was formalized as the [Yadis] (Miller, J., “Yadis Specification 1.0,” .) specification published by Yadis.org in March 2006, and Yadis subsequently became the service discovery format for OpenID 1.1.
A single discovery service for both URLs and XRIs proved to be so popular that in November 2007 the [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0,” .) specification formally added the Yadis method for URL-based XRDS discovery (Section 6). The [OpenID Authentication 2.0] (OpenID, O., “OpenID Authentication 2.0,” .) specification released in December 2007 referenced this updated specification. Since other applications and protocols needed only a subset of XRDS functionality, work begin on formally defining this subset as XRDS-Simple.
Appendix C. Security Considerations
Appendix D. Acknowledgments
XRDS-Simple is for the most part, an evolution of many existing specifications, most notably [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0,” .) and [Yadis] (Miller, J., “Yadis Specification 1.0,” .). Much of the text in this specification has been adopted directly from these two specifications in an attempt to provide implementers an accessible reference for resource discovery.
The editor would like to thank the members of the OASIS XRI TC for their dedicated work bringing the XRDS format to its current state, and for accommodating the XRDS-Simple use case within XRDS and the [XRI Resolution 2.0] (Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, “Extensible Resource Identifier (XRI) Resolution V2.0,” .) specification. In particular, the editor would like to thank Drummond Reed and Gabe Wachob for their active role in the creation of XRDS-Simple, as well as Markus Sabadello and William Tan for their participation.
The editor would like to thank Chris Messina, John Panzer, and David Recordon for their continued support and assistance.
Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,” RFC 2046.
Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” RFC 2119.