Fwd: [XRI] resources vs meta-data

Hi Stuart,


Just to clear up the definitions.
XRD ==  Extensible Resource Descriptor XML document
XRDS == An XRDS document contains one or more XRD (Extensible Resource  
Descriptor) elements
SEP    == Service Endpoint,  They are descriptors of concrete URIs at  
which network services are available for the target resource.  
Additional XRI resolution parameters as well as the path component of  
an XRI may be used as service endpoint selection criteria.

XRI Authorities always resolve to XRDS documents.  Based on query  
parameters you can ask for just the final XRD or a particular SEP in  
the final XRD.

XRI resolution is about public service discovery for an identifier.    
Anyone with that identifier can find XML metadata describing the  
Service Endpoints  including concrete URI's.

Other service discovery mechanisms like ID-WSF depend on the  
identifier being registered in the federation.

I am currently working with open-liberty to define the process of  
using a XRI or URI identifier to resolve a ID-WSF Discovery Service  
via a EPR in the XRDS.

Public service discovery via XRDS documents is used in:
1, openID
2, oAuth
3, infocard r-card (higgins)
4, ID-WSF via openID and infocard (experimental proposed to be part of  
Liberty SIG WSH)

These are the things I am involved in personally.

I think this is clear and unambiguous.

If you are trying to resolve a XRI via a HXRI proxy,  If the request  
contains no query parameters the proxy will provide some defaults,  
based on an assumption that the requester has no notion of XRI or  
ability to process returned XRDS XML.

Based on the processing rules that the owner of the XRD document sets  
they can choose to have the proxy redirect the requester to a concrete  
URI resource.

A XRD document can fully configure the behavior of the HXRI proxy.

xri://=jbradley is a identifier that returns an XRDS document to XRI  
aware applications,  If I choose I can define a behavior in that  
document that if something preforms resolution on that identifier, and  
provides no query parameters I can define a redirect behavior based on  
the path and accept header.

Providing perfect backwards compatibility is hard.   I think we have  
done a darn good job with the HXRI proxy.

If you are using HXRI in a RDF document you can encode the accept  
header and other parameters in the HXRI so you can be precise about  
what you are referring to.

XRI has been defined for use with XDI-RDF.  I would say that the  
additional specificity provided by the HXRI encoding makes RDF more  
useful.
Using a HXRI it is clear what you are referring to,  it provides  
useful constraints and documentation for interoperability.
Thats why we think it would be good to have it as an OASIS spec.

I think we are open to changes to the HXRI proxy resolvers default  
behavior if it doesn't involve reducing functionality.

I am interested in finding out if people believe the default behavior  
of the HXRI proxy should be  something different.

Now is the time to get your opinions registered.

I have been at this all day, so don't expect more until tomorrow:)

Have a good weekend.
John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley
五里霧中


On 19-Jul-08, at 3:54 AM, Stuart Williams wrote:

> Hello John,
>
>
>> 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
> --
>