Re: [XRI] TAG recommendation

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
> --
>