[XRI] resources vs meta-data

[resending this message as I accidentally hit Send before completing the
last para]

Stuart et al:

I'm responding to Marty's earlier email (below), but I changed the subject
line to match John Bradley's new thread devoted to this specific issue in
order to help keep these threads organized. (Kudos to John for all his
efforts in tracking the issues and providing in-depth background and
explanations on each one.)

On this particular issue, I just wanted to expand on Marty's explanation by
saying that when it comes to the question, "What resource does an XRI
reference?", the XRI TC has always been of one mind: the answer for an XRI
is exactly the same as the answer for a URN, namely, "the abtract identity
of the resource", i.e., the identity of the resource that is independent of
any concrete representation of the resource.

Therefore, just as a URN is designed to be resolved into metadata about a
resource (which may be processed to simply return a redirect to the
resource), so is an XRI. As we have pointed out in earlier threads, and in
the XRI 2.0 FAQ [1], XRI is a actually a superset of URN functionality
because it includes a number of features not included in URNs. But in this
respect, the two are the same -- their job is to reference the resource
indirectly via metadata describing the resource.

As John describes, we have spent several years on XRI proxy resolution
architecture to support the HTTP(S) form of an XRI (HXRIs). We worked hard
to make sure HXRIs and proxy resolvers would be as smart as possible in
terms of returning the correct media type requested by a user agent. Thus an
XRI proxy resolvers can service two different types of requests:

1) If passed a media type in a standard HTTP Accept header from a
non-XRI-aware user agent, and absent any explicity XRI proxy resolution
parameters, the proxy resolver will follow the rules in XRI Resolution 2.0
[2] to automatically redirect to the closest matching media type in the XRDS
document.

2) If passed a media type in an explicit XRI proxy resolution parameter
(meaning either the HXRI explicitly configured enough to include it or the
user agent making the resolution request is XRI-aware), the XRI proxy
resolver can return (as determined by a second resolution parameter): a) an
XRDS document containing one or more service endpoints (SEPs) matching that
request, b) an XRD filtered to contain ONLY SEPs matching that request, or
c) a list of service endpoint URIs filtered to match that request.

Again, as John says, if the TAG feels this is not the proper architecture
for an XRI proxy resolver, please let us know what you think we should do
differently.

Lastly, to echo Marty's comment, I leave tonight for the next two weeks on
vacation with my family and will be completely offline until Monday August
4th. So as Marty says, "Please don't misinterpret a lack of email from me as
a of lack of interest". On the contrary, I think this discussion has been
highly productive, and hope it can continue full steam through all of our
vacations (or even be resolved by the time I get back ;-)

Best,

=Drummond 

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of
> Schleiff, Marty
> Sent: Saturday, July 19, 2008 8:57 AM
> To: Stuart Williams; John Bradley
> Cc: www-tag@w3.org
> Subject: 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 Monday, 21 July 2008 01:25:48 UTC