Re: [XRI] TAG recommendation

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