RE: Questions..

["Wachob, Gabe" <gwachob@visa.com>]

I wanted to respond to Krishnan's points inline. I'm going out of town until the 18th, so I probably not get much of a chance to back on forth on this, but here's my responses:


<snip>
> 
> The specification lays out the relationship between URI and 
> XRI, but my
> feeling is that it is somewhat vague in terms of the ntention of the
> spec wrt URIs.  Various comments in the spec include:
>  a) The XRI scheme is a URI scheme according to  [RFC2396] 
> b) Appropos the syntax, the spec says " One advantage of this approach
> is that the vast majority of HTTP URIs, which inherit directly from
> generic URI syntax, can be used as valid XRIs simply by changing the
> "http:" scheme name to "xri:".
> 
> Consider the following http uri, "http://www.example.com/resource1",
> which currently identifies resource1 uniquely  and also provides a
> resolution mechanism for it.
> 
> - Is it the INTENT of the spec that people who want to  globally
> identify resource1 in the future  do so by simply changing HTTP: to
> xri:, i.e,  "xri://www.example.com/resource1"?   (statement 
> (b) seems to
> imply this)

This is not the intent neccesarily. I didn't draft this section, but my understanding is that the intent here was to make the migration here to XRIs easier. There is not any assumed  transformation from HTTP to XRI URIs other than in a pure syntactic sense (ie there should be no assumption made that the XRI which is made from translating a HTTP URI using this process has anything to do with the content retrieved by using the HTTP protocol with the original HTTP URI).

Again, the intent with the comparison to HTTP is merely as a place where one might want to migrate a set of HTTP URIs to XRIs - the process for doing so should be (and is) very very straightforward if one chooses to do this. 

> 
> - What is the INTENT of the spec wrt to the HTTP URI? Is it considered
> obsolete, or will it continue to be used as a resolution method. ( I
> suspect the answer is that URIs will defnitely continue to be valid so
> this really sets the stage for my next question)

This spec in no way obviates the need for HTTP URIs. HTTP URIs identify hosts/machines/ports and relative paths that are used in the HTTP protocol. We don't do that, nor would suggest that we should. 

Far from being obsolete, HTTP (the protocol) is more core than ever to networked communications. And one can't really talk about HTTP (the protocol) without using HTTP URIs. We are talking about identifiers, however, that are not tied to a particular protocol (or any protocol at all). The fact that HTTP may be used as part of resolution is a testmament to the simplicity, wide use, and wide deployment of HTTP. HTTP URIs are fine for many applications as well and we don't suggest that one stop using HTTP URIs if the motivations we described in our motivations document don't apply, and you are sure they will NEVER apply. 

> 
> - Will the xri resolution mechanism  kick in for the new xri? If so,
> there seem to be two parallel resolution mechanisms (one 
> using http and
> one using xri resolution) as the xri resolution does not seem to
> support
> delegation to a traditional URI resolution method. Also, are these
> parallel mechanisms meant to resolve to the same resource 
> (using either
> resource equivalence semantics or physical resolution).

I think the document has left you confused about XRI resolution and that probably means it needs more "laying of the land". 

The specificaiton defines a framework which is broken down into naming authority resolution and local access parts. The current spec defines an http-based naming authority resolution mechanism and an http-based local access protocol binding. Each one uses HTTP - they key word is "uses" - they describe how to construct an HTTP request to perform a specific function that is described in the resolution framework. 

I'm not sure what you mean by a "traditional URI resolution method" - XRIs haven't existed before so there is no resolution method defined for them. There is no general purpose resolution mechanism for URIs either (though DDDS attempts to do so). 

> 
> - Regarding resolution, I am wondering why XRI does not add any
> meta-data in the identifier that might help with resolution (if
> appropriate)..  an example meta-data element in the 
> identifier would be
> a scheme element that would help resolution, and help XRI resolution
> delegate to traditional URI resolution, for example:
> "xri://(+HTTP)www.example.com/resource1 (I have not fully 
> picked up the
> syntax of XRI so this is purely for illustrative purposes).  Without
> meta-data, I am trying to understand how resolution of
> xri://www.example.com/resource1
> can be delegated to http resolution (as opposed to some other method),
> or if this is even a desired feature.

Well, you are using examples with DNS authority names. In this case, we have a very straightforward naming authority resolutoin mechanism. Its basically the DDDS algorithm  applied to XRIs. 

If you are asking about non-DNS-based authority names (ie @Gabe, lets say), then you have to do a left-to-right resolution. The first item identifies the "identifier community". In DNS, there is one identifier community - "." .. In XRI, you can have as many as you want. The only requirement is that each identifier community be uniquely identified. This can be done with a cross reference to a URI (or other XRI), or by using one of three or four "global community" identifiers (each one not unlike the "." DNS root). 

So, 

xri://(http://www.wachob.com).personal/foo 

is based on the identifier community uniquely identified by a cross reference to http://www.wachob.com . 

xri://=GabeWachob.personal/foo

is based on the global identifier community "=" (which corresponds to individuals). 

The roots for naming authority resolution for each identifier community is "well known" (just as the root servers for "." in DNS are "well known"). The description of a root contains both the network location (e.g. transport level URL, dns name, etc) and the *type* of resolution mechanism used there (e.g. RDDDS, xri-http, etc). 

Does that make sense? 

> 
> Apologies if this is way off the mark. I am just trying to 
> get my hands
> around the problem space..
> 

Actually, this is really useful. Its very good to have fresh eyes on this. We can tell already that some basic concepts aren't well described enough in the specification. I'm sure we'll find more too!