<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This is worth reading as it outlines what Eran plans to do with the current XRDS and XRDS-Simple specifications. &nbsp;It will have future implications on OpenID as the current Yadis discovery protocol actually violates the HTTP and web&nbsp;architecture&nbsp;(as pointed out by the W3C). &nbsp;I'm going to be following this work and figure a future version of OpenID should make use of it. &nbsp;That will mean that OPs will likely need to support the new discovery mechanism while also supporting the current one for a period of time as it becomes deprecated.<div><br></div><div>cc'ing Eran in case there are questions, but the discussion is occuring on the XRDS Simple list at&nbsp;<a href="http://groups.google.com/group/xrds-simple">http://groups.google.com/group/xrds-simple</a> for the time being.<br><div><br></div><div>--David<br><div><br><div>Begin forwarded message:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>From: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">Eran Hammer-Lahav &lt;<a href="mailto:eran@hueniverse.com">eran@hueniverse.com</a>></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>Date: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">October 27, 2008 3:06:41 PM PDT</font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>To: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica">"<a href="mailto:xrds-simple@googlegroups.com">xrds-simple@googlegroups.com</a>" &lt;<a href="mailto:xrds-simple@googlegroups.com">xrds-simple@googlegroups.com</a>></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>Subject: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica"><b>[xrds-simple] Refocusing XRDS / XRDS-Simple / Discovery</b></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><font face="Helvetica" size="3" color="#000000" style="font: 12.0px Helvetica; color: #000000"><b>Reply-To: </b></font><font face="Helvetica" size="3" style="font: 12.0px Helvetica"><a href="mailto:xrds-simple@googlegroups.com">xrds-simple@googlegroups.com</a></font></div><div style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; min-height: 14px; "><br></div> </div><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0; "><div lang="EN-US" link="blue" vlink="purple"><div class="Section1"><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">I have been reviewing XRDS and XRDS-Simple for the past couple of months, including their relationship to HTTP, web architecture, and most importantly, the use cases that are driving the development of an HTTP discovery protocol. What I am most interested in has always been a protocol for discovering metadata about an HTTP resource. This metadata is focused on two things: the resource itself, and its relationship to other resources.<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">Brand / Document Type<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><br>I would like to change focus from XRDS/XRDS-Simple to XRD. XRDS as a sequence of XRD elements is specific to XRI resolution where the sequence of XRDs adds value. The inclusion of multiple XRD elements does not fit within the model of a document describing a resource. My proposed use of URI fragment together with xml:id attributes ads much complexity and little value and will be dropped.<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">I propose to name this specification ‘XRD: Extensible Resource Descriptor’. There is existing value in the XRDS and XRDS-Simple brands, but it is extremely low outside the social-web/identity echo-chamber. Pushing out a somewhat new brand of XRD with a simple acronym (Extensible Resource Descriptor) goes a long way in delivering our message.<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">Focusing on the application/xrd+xml and XRD schema will also make the transition easier as there will be less overlap in headers, elements, and existing documents. By offering an XRD-top-level document, there is less chance of conflicting with existing XRI and OpenID documents.<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">This effort should be branded as XRD 1.0. XRDS is currently in version 2.0 (which failed an OASIS vote) and is now planned to become 3.0. I think that for branding purposes, starting with version 3.0 is counterproductive, but I do not have strong opinions in the version number. One idea I like is to drop the version and use a date instead (common for W3C standards).<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">Another advantage of keeping XRDS XRI-specific is that the current XRDS element not included in the new XRD schema will be able to get assigned to the XRDS namespace which will prevent the need to define a third namespace just for XRI-specific elements (on top of the XRDS and XRD namespaces).<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">Venue / Namespace<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">XRD is a product of the OASIS XRI TC and if for no other reason than to give proper attribution, should stay anchored there. I intend to draft and publish the XRD specification as a product of the XRI TC and will be joining OASIS in the next few days. As an OASIS standard, the XRD schema should have an OASIS http namespace (<a href="http://docs.oasis-open.org/ns/xri/xrd/1.0" style="color: blue; text-decoration: underline; ">http://docs.oasis-open.org/ns/xri/xrd/1.0</a><span class="Apple-converted-space">&nbsp;</span>or<span class="Apple-converted-space">&nbsp;</span><a href="http://docs.oasis-open.org/ns/xri/xrd/2008/11" style="color: blue; text-decoration: underline; ">http://docs.oasis-open.org/ns/xri/xrd/2008/11</a>).<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">However, much of the relevant community to a generic HTTP discovery mechanism and resource metadata resides in the IETF where HTTP is defined and evolved. I would like to find a way to publish OASIS drafts simultaneously as IETF I-Ds for informational purposes only. At the end, I would like to see the OASIS standard assigned an IETF RFC number. Again, this is not a proposal for standardization at the IETF, just using the RFC as a publication channel. This proposal needs much discussion by the XRI TC and would ultimately be their decision.<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">Discovery Workflow<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">The entire discovery workflow defined by Yadis will be replaced in XRD. Support for the ‘Accept’ HTTP header will be removed as it violates HTTP and web architecture. The direct-access use case (of accessing the metadata document without interacting with the resource itself) will be supported using the new /site-meta proposal [1] with a dynamic map to transform the resource URI to the metadata URI. The resource metadata map functionality will be added to the next draft of the /site-meta proposal or published as a separate proposal.<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">The plan is to add support for mapping between a resource’s URI to the URI of its metadata document by using a URI template. Currently, the draft only covers links to site-wide metadata. However, there are use cases in which a client is looking for resource-specific metadata. The proposal is to add a simple template-based mechanism to create a map between the resource URI to the metadata URI (specific to that resource). The new addition will add a new element to the site-meta schema (as a child of the &lt;metadata> element):<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">&lt;resource-map type="application/example+xml" rel=”<a href="http://example.com/relationship" style="color: blue; text-decoration: underline; ">http://example.com/relationship</a>” map="<a href="http://meta.example.net?resource=%7buri%7d" style="color: blue; text-decoration: underline; ">http://meta.example.net?resource={uri}</a>" /><o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">The element maps the metadata document URI for:<span class="Apple-converted-space">&nbsp;</span><a href="http://example.net/resource/1" style="color: blue; text-decoration: underline; ">http://example.net/resource/1</a><span class="Apple-converted-space">&nbsp;</span>with<span class="Apple-converted-space">&nbsp;</span><a href="http://meta.example.net?resource=http%3A%2F%2Fexample.net%2Fresource%2F1" style="color: blue; text-decoration: underline; ">http://meta.example.net?resource=http%3A%2F%2Fexample.net%2Fresource%2F1</a>.<br><br><o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">XRD will use the (to-be-registered) content type application/xrd+xml with the Link header [2] and HTML &lt;Link> element to link from the resource itself to the metadata document. This will replace the XRDS mechanism using X-XRDS-Location header and &lt;meta> HTML element. The X-XRDS-Location header will not be directly affected as it is XRDS-specific, but it should be marked as depreciated and replaced by the Link header for the XRDS use case as well (if such support is desired).<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">XRD discovery will not define a relationship type, allowing XRD to be used for any relationship type desired (authorization, list of social services, etc.). In other words, XRD will be useful to describe the same resource in different context using multiple document.<br><br><o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">Tiered Schema<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">XRDS-Simple is a restrictive subset of XRDS which better fits the common use cases needed for HTTP-based discovery. The XRDS schema can be considered to include three types of elements and attributes: basic, advance, and XRI-specific. XRDS-Simple can be considered the basic set. In order to simplify implementation and provide an upgrade path from the basic set to the advance set, the proposed XRD schema will include both the basic and advance sets in one format.<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">In order to allow parsers to check if they are capable of handling extensions, the advance set, or other types, XRD might include a ‘level’ (or ‘profile’) attribute to indicate if the document is a ‘basic’ or ‘advance’. This isn’t mandatory as the specification can simply instruct basic parsers to look for unknown elements in the same namespace and if such found, to treat the document as an advance profile. In a way, this will be required from a basic parser anyway, so the profile attribute might not be needed. Either way, the XRDS-Simple profile will be required while the rest of XRDS defined as optional support.<br><br><o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">Schema Changes<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">The Key change I am proposing is to make the XRD itself a resource-descriptor, closely mirroring how the Service element treats related resources. What this means is adding support for the URI and MediaType elements at the XRD level and defining Type as an attribute of the resource, not the XRD itself (as was previously used by XRDS-Simple).<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">At the XRD level, multiple URI will mean equivalent endpoints for the same resource, while CanonicalID can be used to indicate which is the authoritative view. I am not sure if EquivID is suitable for this use case and if it is, no need to add URI support at the XRD level. I am just not sure if this will break anything with XRI. Both CanonicalID and EquivID can be replaced with URI (with priority attribute support).<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><o:p>&nbsp;</o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; ">EHL<o:p></o:p></span></div><div style="margin-top: 0in; margin-right: 0in; margin-left: 0in; margin-bottom: 0.0001pt; font-size: 12pt; font-family: 'Times New Roman', serif; "><span style="font-size: 11pt; font-family: Calibri, sans-serif; "><br>[1]<span class="Apple-converted-space">&nbsp;</span><a href="http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-00.txt" style="color: blue; text-decoration: underline; ">http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-00.txt</a><br>[2]<span class="Apple-converted-space">&nbsp;</span><a href="http://tools.ietf.org/id/draft-nottingham-http-link-header-02.txt" style="color: blue; text-decoration: underline; ">http://tools.ietf.org/id/draft-nottingham-http-link-header-02.txt</a><o:p></o:p></span></div></div><br>--~--~---------~--~----~------------~-------~--~----~<br>You received this message because you are subscribed to the Google Groups "XRDS-Simple" group.<span class="Apple-converted-space">&nbsp;</span><br>To post to this group, send email to<span class="Apple-converted-space">&nbsp;</span><a href="mailto:xrds-simple@googlegroups.com" style="color: blue; text-decoration: underline; ">xrds-simple@googlegroups.com</a><span class="Apple-converted-space">&nbsp;</span><br>To unsubscribe from this group, send email to<span class="Apple-converted-space">&nbsp;</span><a href="mailto:xrds-simple+unsubscribe@googlegroups.com" style="color: blue; text-decoration: underline; ">xrds-simple+unsubscribe@googlegroups.com</a><span class="Apple-converted-space">&nbsp;</span><br>For more options, visit this group at<span class="Apple-converted-space">&nbsp;</span><a href="http://groups.google.com/group/xrds-simple?hl=en" style="color: blue; text-decoration: underline; ">http://groups.google.com/group/xrds-simple?hl=en</a><span class="Apple-converted-space">&nbsp;</span><br>-~----------~----~----~----~------~----~------~--~---<br><br></div></span></blockquote></div><br></div></div></body></html>