[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Revised XRI resolution output proposal
The discussion of the XML output format from the service endpoint selection phase of XRI resolution has raised a larger issue. We started with the assumption that the output of service endpoint selection was a single URI. Then... * We revised that to an array of URIs so that consuming applications could make their own choices of transport protocols (such as choosing an HTTPS URI vs. an HTTP URI). * Then Steve raised the need for consuming applications to know the CanonicalID(s) associated with the service endpoint, so we agreed on Thursday's call to add a list of CanonicalIDs. * Today, working on the issue of an XML output format for the results of service endpoint selection, I realized that there are at least two other items of metadata about a service endpoint that a consuming application may need to know: 1) The Type (which may not have been part of the input parameters because a Path parameter or a MediaType parameter or even null parameters may have been used to select the service endpoint). 2) The ProviderID (for applications that need to know this to do things like download SAML metadata regarding the service provider -- this is already a hard requirement of the SAML-based XRI authentication service being developed at XDI.org). * Finally, I had the realization this morning that since XRDs are extensible and may include other metadata describing a service endpoint, we can't even make an arbitrary decision about which service endpoint elements/attributes should be returned to an application as the output of service endpoint selection. Conclusion: 1) The output of the service endpoint selection phase of XRI resolution should be the selected <Service> element from the final XRD. 2) This Service element should contain all the metadata that the service author wishes to make available to a consuming application (including, for example, the CanonicalID). 3) When accessed via a local API, this should be expressed as an array of name/value pairs in which the names are the fully-qualified XPath names of the elements and attributes in the selected Service element and the value is the contents of the element/attribute. Example: xri://$xrd*($v*2.0)/ProviderID, xri://!!1000!1234.5678 xri://$xrd*($v*2.0)/CanonicalID, xri://=!A1B2.C3D4 xri://$xrd*($v*2.0)/Type, xri://+contact*($v*1.0) xri://$xrd*($v*2.0)/Type/@select, true xri://$xrd*($v*2.0)/URI, http://example.com/ctc/=!A1B2.C3D4/ xri://$xrd*($v*2.0)/URI/@append, qxri xri://$xrd*($v*2.0)/URI, http://a.example.com/ctc/=!A1B2.C3D4/ xri://$xrd*($v*2.0)/URI/@append, qxri xri://$xrd*($v*2.0)/URI, https://example.com/ctc/=!A1B2.C3D4/ xri://$xrd*($v*2.0)/URI/@append, qxri 4) When accessed via an HTTP proxy resolver, the output from the service endpoint selection phase would be simply the selected <Service> element. Example: <Service xlmns="xri://$xrd*($v*2.0)"> <ProviderID>xri://!!1000!1234.5678</ProviderID> <CanonicalID>xri://=!A1B2.C3D4</CanonicalID> <Type select="true">xri://+contact*($v*1.0)</Type> <URI append="qxri">http://example.com/ctc/=!A1B2.C3D4/</URI> <URI append="qxri">http://a.example.com/ctc/=!A1B2.C3D4/</URI> <URI append="qxri">https://example.com/ctc/=!A1B2.C3D4/</URI> </Service> This is the only model I can see that directly supports extensibility, i.e., an XRD author can add another element of metadata to a service endpoint description and know that it will be passed to any application that asks any XRI resolver (local or proxy) for this service endpoint. For example, say an XRD author creates the following Service element: <Service xlmns="xri://$xrd*($v*2.0)"> <ProviderID>xri://!!1000!1234.5678</ProviderID> <CanonicalID>xri://=!A1B2.C3D4</CanonicalID> <Type select="true">xri://+contact*($v*1.0)</Type> <Pref xmlns="http://my.example.com/pref" >nothot</Pref> <URI append="qxri">http://example.com/ctc/=!A1B2.C3D4/</URI> <URI append="qxri">http://a.example.com/ctc/=!A1B2.C3D4/</URI> <URI append="qxri">https://example.com/ctc/=!A1B2.C3D4/</URI> </Service> Now the output via a local API for an XRI that selected this service endpoint would be: xri://$xrd*($v*2.0)/ProviderID, xri://!!1000!1234.5678 xri://$xrd*($v*2.0)/CanonicalID, xri://=!A1B2.C3D4 xri://$xrd*($v*2.0)/Type, xri://+contact*($v*1.0) xri://$xrd*($v*2.0)/Type/@select, true http://my.example.com/Pref, nothot xri://$xrd*($v*2.0)/URI, http://example.com/ctc/=!A1B2.C3D4/ xri://$xrd*($v*2.0)/URI/@append, qxri xri://$xrd*($v*2.0)/URI, http://a.example.com/ctc/=!A1B2.C3D4/ xri://$xrd*($v*2.0)/URI/@append, qxri xri://$xrd*($v*2.0)/URI, https://example.com/ctc/=!A1B2.C3D4/ xri://$xrd*($v*2.0)/URI/@append, qxri ***** As always at this stage, please send feedback as soon as you can. Currently this is the last remaining technical open issue to close WD 10. =Drummond
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]