- From: John Bradley <john.bradley@wingaa.com>
- Date: Fri, 18 Jul 2008 17:44:31 -0700
- To: Stuart Williams <skw@hp.com>
- Cc: "www-tag@w3.org" <www-tag@w3.org>
- Message-Id: <EBC76D82-1846-48CC-9E1B-B4A9A5EA1E24@wingaa.com>
Thanks Stuart, The TAGs position seems clear and categorical from my position on the outside. Without clear guidelines on how to reach the bar that the W3C has set, it would seem unlikely the XRI or anyone else will reach it. It has been stated that existing schemes don't meet the new standards. I don't know that it is productive for us to start digging into where that bar is if we can find a way of implementing XRI without a new scheme. If people want to start a tread on what standard must be met to justify an new scheme, you know where to find me:) Setting the scheme issue aside for the moment. That gives us a couple of other topics we can try to put to rest before the TAG meeting. A question on your first point. Is there some thought that only URLs should be used as user identifiers for application purposes? If I want to log into a application what identifiers are Good vs Bad? 1. jbradley 2. jbradley@wingaa.com 3. =jbradley 4. xri://=jbradley 5. http://xri.net/=jbradley 6. =!BF81.FD97.C81B.B4E5 7. thread-safe.net 8. http://thread-safe.net 9. VE7JTB 10. 703-650-0389 These are all identifiers that I use to gain accesses to resources. Is there a desire to restrict the acceptable form of input for an openID? If we don't use a URI scheme then obviously the xri:// form that is currently valid would need to be deprecated. If I enter =jbradley into an openID RP and the RP normalizes that to http://xri.net/=jbradley in the same way that if I enter thread-safe.net it will normalize that to http://thread-safe.net, is that a problem? If OpenID were to adopt CURIE as you suggest, then if we define: xmlns:xri="http://xri.net/" That would allow a identifier such as xri:=jbradley to be entered and become http://xri.net/=jbradley ? I am new to CURIE so the answer is probably obvious to others. If that is the idea then perhaps CURIE is an option. On your second question: In native XRI resolution a XRDS document is always returned, so I don't think that is a problem. The HXRI proxy server has a number of input parameters to facilitate backwards compatibility with browsers and other software that is not XRI aware. You should refer to XRI 2.0 Resolution Sec 11.5. This deals with the values passed in the http(s) Accept headers sent to a HXRI proxy Lets consider my XRI =jbradley largely because I may be the only person using accept headers in my actual XRDS. You may want to skip to the end of the XRDS my examples will refer back to the individual SEPs > <?xml version="1.0" encoding="UTF-8"?> > <XRDS ref="xri://=jbradley" xmlns="xri://$xrds"> > <XRD version="2.0" xmlns="xri://$xrd*($v*2.0)"> > <Query>*jbradley</Query> > <Status ceid="off" cid="verified" code="100"/> > <ServerStatus code="100"/> > <Expires>2008-07-19T01:24:34.000Z</Expires> > <ProviderID>xri://=</ProviderID> > <LocalID>!bf81.fd97.c81b.b4e5</LocalID> > <CanonicalID>=!BF81.FD97.C81B.B4E5</CanonicalID> > <Service priority="10"> > <ProviderID>xri://!!1003!103</ProviderID> > <Type match="null"/> > <Path match="null"/> > <MediaType select="true">application/rdf+xml</MediaType> > <URI append="none" priority="1">http://thread-safe.net/data/foaf</ > URI> > </Service> > <Service priority="10"> > <ProviderID>xri://!!1003!103</ProviderID> > <Type select="true">xri://+i-service*(+contact)*($v*1.0)</Type> > <Type match="null" select="false"/> > <Path match="default"/> > <Path match="null"/> > <Path>(+contact)</Path> > <URI append="qxri" priority="1">http://ipage2.ezibroker.net/ipage/ipage.faces?iname= > </URI> > </Service> > <Service priority="10"> > <ProviderID>xri://!!1003!103</ProviderID> > <Type select="true">xri://$res*auth*($v*2.0)</Type> > <MediaType>application/xrds+xml;trust=none</MediaType> > <URI priority="10">http://resolve.ezibroker.net/resolve/=ve7jtb/</ > URI> > </Service> > <Service priority="10"> > <ProviderID>xri://!!1003!103</ProviderID> > <Type match="null"/> > <Path match="null"/> > <MediaType select="true">application/rss+xml</MediaType> > <URI append="none" priority="1">http://feeds.feedburner.com/Thread-Safe > </URI> > </Service> > <Service priority="1"> > <ProviderID>xri://!!1003!103</ProviderID> > <Type match="null" select="false"/> > <Type select="true">xri://+i-service*(+xmpp)*($v*1.0)</Type> > <Path>(+chat:jabber)</Path> > <Path>(+chat:xmpp)</Path> > <URI append="none" priority="1">jabber://jbradley@wingaa.com</URI> > </Service> > <Service priority="10"> > <Type>$context</Type> > <Type select="true">($context)*($ldap)</Type> > <Path select="true">($context)*($ldap)</Path> > </Service> > <Service priority="1"> > <ProviderID>xri://!!1003!103</ProviderID> > <Type select="true">xri://+i-service*(+forwarding)*($v*1.0)</Type> > <Type match="null" select="false"/> > <Path>(+index)</Path> > <URI append="qxri" priority="1">http://linksafe-forward.ezibroker.net/forwarding/ > </URI> > </Service> > <Service> > <ProviderID>xri://!!1003!103</ProviderID> > <Type select="true">http://openid.net/signon/1.0</Type> > <URI append="none" priority="1">https://linksafe.ezibroker.net/server/ > </URI> > <openid:Delegate xmlns:openid="http://openid.net/xmlns/ > 1.0">=ve7jtb</openid:Delegate> > </Service> > </XRD> > </XRDS> > http://beta.xri.net/=jbradley Because the XRI path is empty this will match my contact SEP. The SEP contains a single URL element. The proxy resolver makes the assumption that because the XRDS content type was not requested in the query it should issue a redirect to the URL. If you type it into a browser you are redirected to may contact page. (its a opensocial container under development just so you know not to expect something beautiful) If a RSS reader access the same HXRI it should do so with an accept header of application/rss+xml this will cause the RSS sep to be selected and a redirect to my RSS feed will be returned to the requesting application. The HXRI encodes the accept header as the _xrd_m query parameter. This can be overridden by including _xrd_m as part of the query string for the HXRI. http://beta.xri.net/=jbradley?query&_xrd_m=application/rss+xml this gets you redirected to my RSS feed at feed burner. Use beta.xri.net for testing accept header behavior in HXRI, there are still some code things we are testing before rolling this out on the main xri.net HXRI proxy. If an XRI aware application wants to use a HXRI it can include a number of query parameters to control the proxy behavior. http://beta.xri.net/=jbradley?query&_xrd_r=application/xrds+xml returns the XRDS document for =jbradley http://beta.xri.net/=jbradley?query&_xrd_m=application/rss+xml&_xrd_r=application/xrd+xml&sep=true&https=true This preforms service selection based on the application/rss+xm media type and returns a XRD document containing the selected Service endpoint, and forces all resolution to be preformed over https. It is documented in exhaustive detail in the XRI 2.0 resolution spec. If there is a problem with how we are using accept headers then lets sort it out. Regards John Bradley OASIS IDTRUST-SC http://xri.net/=jbradley 五里霧中 On 18-Jul-08, at 2:57 PM, Stuart Williams wrote: > Hello John, > > John Bradley wrote: >> Stuart, >> >> We have been at the XRI discussion on the list now for over a week. >> >> I have not seen any concrete issue other than the use of a URI >> scheme surface. > Wrt to URI schemes, I think Henry stated the TAG's position which > prioritises reuse over introduction of new scheme where it believes > new schemes need to deliver clear capabilities that cannot be > addressed using existing schemes. The TAG's position has been that > it is unconvinced that the requirements that motivate XRIs cannot be > meet using existing URI schemes - specifically http:. Your > characterisations of the TAGs position elsewhere state it somewhat > more categorically than I would care to. > > Anyway... to answer your question... they are certainly a big part > of the issue. > > A possible related secondary issue is the promulgation of > identifiers that are not URI - specifically, were formats to be > specified on ways that encouraged the use of abbreviated forms (eg i- > name or i-numbers) to the exclusion of URI forms - I believe the TAG > would have issues. I'm not familiar enough with OpenID and OAuth, > but I have heard bells possibly going off. My belief is that the TAG > would prefer the use of URI/IRI forms of identifier abbreviated if > you like through the use of base URI and relative forms or, possibly > through adoption of CURIE syntax (not quite a W3C recommendation yet). >> Given that this started as a result of a TAG recommendation http://lists.w3.org/Archives/Public/www-tag/2008May/0078 >> that indirectly affected the OASIS standard vote for XRI 2.0. >> >> Is it the position of the TAG and others on the list that the move >> away from using a URI scheme is sufficient for the TAG to withdraw >> its recommendation subject to agreed changes re the scheme? > Firstly I can't speak for the TAG without the TAG having reached > some sort of a concensus on question that it is ready to answer. > Unfortuately, summer time availability of TAG members making it > difficult to assemble critical mass to establish concensus. > > You've certainly seen a direct answer from David Orchard [1]. > > [1] http://lists.w3.org/Archives/Public/www-tag/2008Jul/0025 >> >> If there are other issues that need to be resolved from the TAG's >> point of view we should surface them. > In the questions that the TAG raised in [2] the 2nd question was > whether XRI resolution used of HTTP content negotiation to negotiate > between the retrieval of a representation of a denoted thing (an > HTML/PDF... serialisation of a document) and the retrieval of > metadata *about* the denoted thing - that being an abuse of HTTP > content negotiation. > > The response in [3] begins " Yes, local resolvers or proxy resolvers > can do this on behalf of a client (authority servers only handle > XRDS documents)." If HTTP Accept: headers are being used as a signal > to indicate whether or not metadata is being sought then the TAG > would regard that as counter to web architecture (different URI for > resource and its metadata - itself a distinct resource, is fine). > > [2] http://lists.w3.org/Archives/Public/www-tag/2008Feb/0009 > [3] http://lists.w3.org/Archives/Public/www-tag/2008Feb/0104 >> >> The IDTRUST Member Section and others in OASIS would like to be >> certain that a definitive list of issues is produced from this >> process so that the XRI-TC can begin the process of bringing >> forward a revised spec. >> >> I ask that the TAG consider this question at its earliest >> connivence, given the summer schedule. > I am hopeful of a meeting on 24th July (though as I indicate > previously, we will have some absenses). >> >> Regards >> John Bradley >> OASIS IDTRUST-SC >> http://xri.net/=jbradley >> 五里霧中 > > Regards > > Stuart Williams > -- >
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Saturday, 19 July 2008 00:45:16 UTC