OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: FW: Questions..


Feedback from Krishnan Rajagopalan @ Cambridge Technology Partners/Novell.. 




Hi Gabe,

I have not been able to get an outgoing Novell email address, so I
cannot post to xri-comments. So I have forwarded the email that I was
trying to post to the group to you.

Thanks

Krishnan

*********************
Gentlemen,

I had a few questions about the spec. I have not been privy to most of
the discussions so far and have only spent a few days reading the
specifications and overview material, so I apologize for the newbie
questions. 

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)

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

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

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

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

Thanks

Krishnan
 
PS: I did want to add the disclaimer that these comments/questions do
not represent the official Novell viewpoint.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]