RE: [XRI] TAG recommendation

Hi Stuart (& All),

Stuart said:
> 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.
 
Using that same logic (with which I disagree), a PURL would not in fact refer to a resource that needs a persistent identifier; rather, a PURL would refer to the returned HTTP redirect. 

I don't know much about PURLs, but I think of them as "abstract" identifiers because there's a layer of abstraction between the identifier and the named resource.

Similar to PURL, XRIs are "abstract" identifiers. XRI resolution NEVER directly returns the named resource; rather, resolution returns an XRDS describing how to interact with the named resource. 

When resolving a PURL, if the software is smart enough, it can automatically process the returned redirect to retrieve the named resource. When resolving an XRI, if the software is smart enough, it can automatically process the returned XRDS to retrieve the named resource. And, if the software is smart enough, it can automatically process the returned XRDS to interact with the named resource in other ways defined by the service points in the XRDS.

BTW, I hope to leave for a week of vacation (as soon as we can finish packing). So please don't misinterpret a lack of email from me as a of lack of interest.

Marty.Schleiff@boeing.com; CISSP
Associate Technical Fellow - Cyber Identity Specialist
Information Security - Technical Controls
(206) 679-5933

-----Original Message-----
From: Stuart Williams [mailto:skw@hp.com] 
Sent: Saturday, July 19, 2008 3:54 AM
To: John Bradley
Cc: www-tag@w3.org
Subject: Re: [XRI] TAG recommendation


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

Received on Saturday, 19 July 2008 15:57:55 UTC