Re: [XRI] TAG recommendation

Hi Stuart,

Marty is on Vacation, but I will try and keep up our end:)

Let me try another way of explaining XRI.

I am going to stick my neck out with this one, and may have the XRI  
folks disavow me.

XRI comprises two specs:
1. XRI 2.0 Syntax http://www.oasis-open.org/committees/download.php/15376/xri-syntax-V2.0-cs.html
This was completed in 2005.

2. XRI 2.0 Resolution http://docs.oasis-open.org/xri/xri-resolution/2.0/specs/cs01/xri-resolution-V2.0-cs-01.html
This was completed April of 2008.

First lets revisit Syntax:

The Syntax spec defines abstract identifiers  iNames.

These identifiers have two major components:
1. An authority segment
2. A path segment

These are patterned after IRI,  and if proceeded by a IRI/URI scheme  
identifier they would be IRI/URI.

The XRI-TC attempted to make XRI syntax IRI compliant.

I fear there lurks in our discussion a fundamental difference of  
opinion regarding the relative roles of IRI vs http: scheme URI.
The XRI-TC and others still hold to TBL's 1996 Axioms http://www.w3.org/DesignIssues/Axioms.html 
.
The TAG in 2006 partially in response to XRI, published the much  
quoted "URNs, Namespaces and Registries" http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html 
.
This newer document sets forth the primacy of the http: scheme above  
all others.

This W3C document was published after XRI 2.0 syntax was adopted by  
the TC.

Syntax also covers elements that are opaque to the resolver for use in  
cross references and XDI.

I think that David Orchard and David Booth have both made some  
compelling arguments as to why it would be preferable for XRI not to  
register a URI/IRI scheme.   The XRI-TC has stated that they are  
willing to consider the change if a suitable alternative for  
identifying XRI can be agreed upon.  I find the XML name-spacing  
argument one the most convincing personally.

Now lets consider resolution.

XRI is about resolving a abstract XRI to discover an XML description  
for a desired service.

It is not a replacement for http:, it is much closer to DNS.

Like DNS you preform resolution of an identifier to retrieve metadata  
for an application to use.

In DNS you have record types that you look for MX, TXT, SRV,  and A  
amongst others.

So if I resolve www.w3.org selecting for an A record I get an IP  
address.
If I resolve the same name looking for a MX record I may get a  
different IP address.
If I resolve it looking for _xmpp-server._tcp.w3.org SRV record and  
get back an IP address and a port.

I will also note that multiple domain names can map to a single IP or  
conversely the same DNS name can map to multiple IP addresses.

I would say that this is the foundation that XRI builds on not http:  
from a resolution perspective.  True the syntax was taken from URI and  
that perhaps misdirects people.

The XRI-TC has used XML to create an extensible resolution protocol  
for resolving XRI identifiers to entities in an XRI entity space.   
Part of the resolution process uses the XRI path and associated XRI  
query parameters to preform this resolution.

This is much like DNS only extensible.

The XRD document retrieved has a unique address conventionally  
referred to as an iNumber,  or canonical ID element.   Many INames can  
resolve to the same XRDS document  identified bey the same CID element.

As a side issue iNumbers are by policy persistent and non reasonable,   
However a CID is not required to be persistent,  it is however  
strongly recommended in the spec.   iNumbers are similar in form to a  
IPv6 address so there is a sufficient quantity to avoid reuse.

Depending on the query parameters all of the XRDS or some specified  
subset is returned to the requesting application.

The Service Endpoint requested may contain URI and or other XML  
elements describing the service. It may describe an SCP service  
accessed over SS7.  There may be no URI resource associated with a SEP  
in some cases.

The only thing native XRI resolution has to do with http:  is a  
http(s) binding much like soap and other protocols use to tunnel  
through http:.  XRI is capable of having bindings for a number of  
transports.

I want to make this very clear,  with or without a URI/IRI scheme for  
XRI Syntax.  XRI resolution will not give up native XRI resolution.    
The one spec is called resolution for a very good reason.

So XRI is a Syntax that is in IRI form and a resolution protocol that  
is more like DNS than http:

I simply point to the fact that in http: the authority resolution  
makes no reference to the path, query string or any other parameter.    
This is fundamentally different from XRI where they are resolved as a  
whole,  much like how DNS uses both the host name and record type to  
resolve a query.

Now we get into a grey area around a http: compatibility mode that the  
W3C recommended we adopt  sometime around 2006.   This came from David  
Booth's work  "Four Uses of a URL: Name, Concept, Web Location, and  
Document Instance"
http://www.w3.org/2002/11/dbooth-names/dbooth-names_clean.htm
http://www.w3.org/2002/11/dbooth-names/dbooth-rfc2396-analysis_clean.htm
http://www.w3.org/2002/11/dbooth-names/rfc2396-numbered_clean.htm

David has been quite helpful in recommending ways that XRI resources  
can be best interpreted by non XRI aware applications through the use  
of a gateway or proxy resolver.

The HXRI form of XRI and the XRI proxy resolver gateway were created  
based on W3C feedback and the reason why the resolution spec took much  
longer to complete after syntax was done.

The XRI proxy resolver differentiates between clients that are XRI  
aware and using the proxy as a connivence function rather than  
directly doing XRI resolution (a number of openID libraries do this),   
and a request coming from a non XRI aware client like a web browser.

In the first case http://xri.net/=jbradley is an abstract identifier  
that is resolved to a CID and XML meta data.

In the second case http://xri.net/=jbradley is treated as a browsers  
request for a concrete URI resource.

So yes the result depends on the context in which the resolution occurs.

If it is better web architecture we could register a URI/IRI scheme so  
that it is always clear that xri://=jbradley  always returns metadata  
about =jbradley rather than http://xri.net/=jbradley which is looking  
for a concrete web resource.

If we are asked to overload the semantics of http:  then it is unfair  
to blame us for the ambiguity that causes.

There are a number of changes we have discussed that would need to be  
make to HXRI and proxy resolution if we don't use a URI/IRI scheme.

If David or others can come up with a way to disambiguate the  
overloading caused by scheme reuse,  I am happy to work with them to  
incorporate it,  in the revised specs.

Best Regards
John Bradley
OASIS IDTRUST-SC
http://xri.net/=jbradley
五里霧中






On 21-Jul-08, at 3:13 AM, Williams, Stuart (HP Labs, Bristol) wrote:

> Hello Marty,
>
>> -----Original Message-----
>> From: Schleiff, Marty [mailto:marty.schleiff@boeing.com]
>> Sent: 19 July 2008 16:57
>> To: Williams, Stuart (HP Labs, Bristol); 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.
>
> Nope... eg. <http://purl.org/dc/elements/1.1/title> refers to a  
> relation between, typically, works of some kind and their titles. It  
> does not refer to the 302 redirection response (erroneous, in that  
> it should be a 303 see other. 302 suggest that the resource has  
> 'moved' temporarally to an other location - whereas 303 typically  
> refers you to something distinct but related to what you asked for).  
> The wget trace below (below the signature line), follows a chain of  
> redirections and grounds out with a 200 OK respoonse on a retrieval  
> of <http://dublincore.org/2008/01/14/dcelements.rdf> which  
> 'happens' (as intended) to say something useful (at least to RDF  
> processors) about <http://purl.org/dc/elements/1.1/title> amongst  
> other things.
>
> In this whole process no webarch:representation of <http://purl.org/dc/elements/1.1/title 
> > is provided. Instead redirection is used to reach a distinct (RDF)  
> description (ie. metadata) with its own distinct URI.
>
>> 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.
>
> Ok... so if someone does an http GET operatation on (allow me my  
> ficticious XRI - correct it or improve it to be more in line with  
> XRI intent):
>
>        http://xri.net/@oasis*specs*os*xri($v2.0)*resolution
>
>        (or, allowing an XRI scheme, xri:// 
> @oasis*specs*os*xri($v2.0)*resolution
>         which modulo IRI->URI conversion can be placed on a HTTP  
> request line).
>
> What direct[*] HTTP response should I expect?
>
> 1) An http 3xx redirection (preferably 303 IMO) to an XRDS resource  
> with a distinct URI?
> 2) An http 200 response with an [html|pdf|.doc] representation of  
> the specification?
> 3) An Http 200 response with an application/xrds+xml representation  
> (without a Content-Location: header)?
> 4) An Http 200 response with an application/xrds+xml representation  
> (with a Content-Location: header and a reference to a distinct  
> resource)?
>
> [*] ie. the response to the given request, rather than the final  
> response after the client has followed a one or more 3xx redirections.
>
> Does the answer differ between the different forms of XRI resolution  
> (that would be 'bad')?
>
> IMO...:
>
> *If* the identifier is an identifier for the metadata (rather than  
> an identifier for the subject of the metadata), 1, 3 and 4 are ok.
> *If* (as intended in this scenario) the identifier is an identifier  
> for a praticular specification, 1 and 2 are ok and 3 and 4 would be  
> very wrong.
>
>> When resolving a PURL, if the software is smart enough, it
>> can automatically process the returned redirect to retrieve
>> the named resource.
>
> What it then retrieves a representation of is named by the target  
> URI in the Location header: which in the something distinct from the  
> orignal referee.
>
>> 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
>
> Stuart
> --
> Hewlett-Packard Limited registered Office: Cain Road, Bracknell,  
> Berks RG12 1HN
> Registered No: 690597 England
>
>  $ wget --debug http://purl.org/dc/elements/1.1/title
>  DEBUG output created by Wget 1.11.3 on cygwin.
>
>  --2008-07-21 10:22:42--  http://purl.org/dc/elements/1.1/title
>  ---request begin---
>  GET http://purl.org/dc/elements/1.1/title HTTP/1.0
>  User-Agent: Wget/1.11.3
>  Accept: */*
>  Host: purl.org
>
>  ---request end---
>  Proxy request sent, awaiting response...
>  ---response begin---
>  HTTP/1.1 302 Found
>  Date: Mon, 21 Jul 2008 09:23:22 GMT
>  Server: Apache/1.3.29
>  Location: http://dublincore.org/2008/01/14/dcelements.rdf#title
>  Content-Type: text/html; charset=iso-8859-1
>  Connection: close
>
>  ---response end---
>  302 Found
>  Location: http://dublincore.org/2008/01/14/dcelements.rdf#title  
> [following]
>  Closed fd 3
>  --2008-07-21 10:22:44--  http://dublincore.org/2008/01/14/dcelements.rdf
>  ---request begin---
>  GET http://dublincore.org/2008/01/14/dcelements.rdf HTTP/1.0
>  User-Agent: Wget/1.11.3
>  Accept: */*
>  Host: dublincore.org
>
>  ---request end---
>  Proxy request sent, awaiting response...
>  ---response begin---
>  HTTP/1.1 200 OK
>  Date: Tue, 15 Jul 2008 14:07:59 GMT
>  Server: Apache/1.3.28 (Unix) mod_jk/1.1.0
>  Last-Modified: Sun, 13 Jan 2008 21:49:30 GMT
>  ETag: "790116-449c-478a876a"
>  Accept-Ranges: bytes
>  Content-Type: application/rdf+xml
>  Content-length: 17564
>  Connection: close
>  Age: 501321
>
>  ---response end---
>  200 OK
>  Length: 17564 (17K) [application/rdf+xml]
>  Saving to: `dcelements.rdf'
>
>  Closed fd 3
>  2008-07-21 10:22:45 (856 KB/s) - `dcelements.rdf' saved [17564/17564]