- From: John Bradley <john.bradley@wingaa.com>
- Date: Sat, 19 Jul 2008 08:17:00 -0700
- To: Stuart Williams <skw@hp.com>
- Cc: "www-tag@w3.org" <www-tag@w3.org>
- Message-Id: <F5635021-B98A-4792-ACCD-7F728AC45CE0@wingaa.com>
Morning Stuart, Great reply. You will have to excuse my delay in replying, We have a 8h time difference to contend with. I think the best thing for me to do is split this into three replies one on each of the topics. I think each is a sufficiently self-contained issue. Once I have a sufficiency of tea in my system I will start to work on them. I should explain to the lurkers on the tread, that I have the political skill of an engineer. I want to dig into the issues and resolve them or at least understand why we take differing positions. I am appreciative of the time Stuart and others are putting into this discussion. My role in this is to be the best advocate for XRI-TC as possible. I hope that this dialog is helping people better understand the issues at play. Best Regards John Bradley OASIS IDTRUST-SC http://xri.net/=jbradley 五里霧中 On 19-Jul-08, at 3:54 AM, Stuart Williams wrote: > Hello John, > > John Bradley wrote: >> 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. > Guidelines for new URI scheme registrations can be found in RFC 4395 > - section 5 details the registration process. Governance is via the > IETF and at best the TAG and more generally W3C have influence but > no control. > > [1] http://www.rfc-editor.org/rfc/rfc4395.txt >> 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. > ok. > >> 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? > I'd described it as a pro-URI bias - that shouldn't be a surprise. I > also scoped my comment in terms of languge/format definitons - > rather than UI artefacts and login forms. > > Lets say, that my email address, skw@hp.com is used as a user > identifier for me in some system. > > I could define a userId element in some new format and say that its > content must be an email address thus: > > <userID>skw@hp.com</userID> > > or I could leave the definition in the format spec more open and say > that element content must be a URI > > <userID>mailto:skw@hp.com</userID> > > I believe that the TAG bias is toward the latter. >> 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? > I guess that was the question I was asking you... is there a desire > to promote the i-name/i-number based identifiers in formats to the > exclusion of equivalent URI forms. Requiring folks to have to > purchase/rent an i-name (at $12 per personal -name per yeat [2]) to > use, say Oauth or OpenID [and I am not saying that *is* the case, > but I believe that that peception exists] would be unaccceptable to > many. FWIW, and I'm sure that you can correct me, I expect that the > relevant specs.will allow more general URI forms of identifier, and > may even require URI forms of XRI in fields that are exchanged 'on > the wire'. > > [2] http://2idi.com/register > > To answer your question above: wrt to a closed system without shared > identities then whatever you like. Where identities are shared, the > identity components in message that cross the wire should all be URIs. > >> If we don't use a URI scheme then obviously the xri:// form that is >> currently valid would need to be deprecated. > The above is orthogonal to the scheme question =jbradley is not a URI. >> 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? > RP?? > > I think so, certainly I wouldn't have problem with that - and I > wouldn't have a problem with xri://=jbradley either were it > successfull registered as a xri: scheme or were it generally > acceptable as a URI scheme and on track for registration (which I > know was an intent that we may have disrupted). > >> 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 ? > Again, I was not talking in terms of what a user enters in a UI, but > what crosses the wire on a message. > > UI Fields -> URI -> full or abbreviated URI in a message. I was > offering CURIEs as an abbreviation mechanism that could be adopted > in message formats, though equally (IMO) base+rel URI will also > serve in many cases. >> >> I am new to CURIE so the answer is probably obvious to others. >> >> If that is the idea then perhaps CURIE is an option. > I only mention them because, at least in the hypertext community > there is a lot of negative reaction at the prospect of authors > having to correctly and repeadly write lengthy URI that differ only > in a few trailling characters... CURIEs is an approach to addressing > that problem from the hypertext community. > > I would not expect end users typing credentials into a login form to > have to care or be aware of it. >> On your second question: >> >> In native XRI resolution a XRDS document is always returned, so I >> don't think that is a problem. > Well... the question is: too what do the i-name "=jbradley" or the > URI "http://xri.net/=jbradley" and xri://=jbradley refer. Do they > refer to you (a person) or some metadata (about you). > > If I want to say, say in RDF, who created the thing referred to by > the two URI above? > > Your parents? > The author of a metadata document (probably you)? > > The answer you give above suggests that that the identifiers refer > to an XRDS document and not a person. > > How about of you were to mint an XRI identifier for say the XRI 2.0 > resolution spec (there may be one I guess) > > http://xri.net/@oasis*specs*os*xri($v2.0)*resolution (please look > past any clumsy syntactic mistakes - I hope the intent of the > identifier is clear). > > Does that identifier (assuming that the intent was that it refer to > the XRI 2.0 resolution spec) in fact (in this fiction) do so? > > Would a retrieval using that identifier expect to obtain a copy of > the specification or an XRDS document? If the answer to that > question is, that depends on the Accept: header, then that is > counter to web architecture. If the answer, which I think you give > above, is that you always get back a representation of an XRDS > document, then despite the intent the identifier does not infact > refer to the spec it was intended to reference. > > An alternative way of asking the same question: If, say in RDF, I > were to want to speak separately of the spec and the XRDS document > how would I make distinct references. > >> 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. > It will take me more time to internalise what's going on in the > specs - its useful to have a handy guide that knows them well - > thanks. > > I hope the questions I ask above ([document] or [metadata document > about [document]]) help you understand where I and the TAG are > commng from on that topic. > > IIUC'ish the use of HTTP as an underlying mechanism for resolving an > XRI generates a bunch of URI that (as it happens) embed accept > headers in the URI making for distinct URI for referenced 'thing' > and metadata about referenced 'thing'. > > Anyway, lets sort out whether there is really a problem there that > needs to be address. > >> Regards >> John Bradley >> OASIS IDTRUST-SC >> http://xri.net/=jbradley >> 五里霧中 > > Stuart > -- >
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Saturday, 19 July 2008 15:17:50 UTC