[XRI] Back to XRI (was Private naming conventions and hypermedia)

Hi Mark,

I am fine with people discussing the issues around ARK and its  
implementation.

As referenced in the TAG minutes Henry S. Thompson (HST) advanced ARK  
as a pattern that could be used by XRI and others to enable the use of  
"Non-DNS Authority Resolution".

HST is correct in that ARK is arguably and example of trying to  
incorporate some elements of non-DNS Authority resolution.

There seems to be debate on how well ARK itself meets the goals of AWWW.

One of our requirements if we are to consider using the http: scheme  
with XRI Authority resolution,  is that a client application must have  
some standard means to identify those URLs as HTTP encoded XRI (HXRI)  
for the purposes of local processing, without requiring the use of  
PROPFIND or some other HTTP mechanism to test the resource via http:.

This is something a URI scheme wold have clearly enabled us to do.

HXRI as currently in the spec lacks the above quality in that  XHRI  
was intended as a interim step for compatibility purposes until the  
xri: scheme is widely recognized by client software.

At the moment the XRI 2.0 committee spec includes both HXRI and a xri:  
scheme.
We believe we are being asked by the W3C to drop our requirement for  
and use of a xri: scheme.

A valid position that I think you advocate is that the W3C should not  
be attempting to create a new sub schemes mechanism within the  http:  
scheme.
> If you're trying to extend the Web in a way that requires providing
> license to agents to extract information from URIs - which appears to
> be a key part of the functionality XRIs are trying to provide (see
> 1.1.1 of xri-syntax) - then you need a new URI scheme.

If you and others think the XRI-TC should bypass the W3C discussion  
and move to arguing the XRI case for a URI scheme at IANA, then we  
should have a tread on the topic.

Most of the discussion here has been around keeping the XRI-TC from  
doing exactly that.

We are attempting to document our points of agreement and  
disagreement, so that a path can be found forward.

To the point you have made several times.  XRI is a authority  
resolution protocol. XRI is more directly comparable to DNS than it is  
to HTTP.

The goal of XRI is not to replace HTTP.   They are quite different  
things.  This tends to get muddied by our inclusion of HXRI at the  
W3Cs request.  This HXRI functionality allows for a gateway for http:  
to access URI schemes that a browser is not configured for.

Imagine if you would that a web browser wanted to know the IP address  
of the of the XMPP server for thread-safe.net.
How do I represent that as a http: URL.   The information is in DNS,  
but is inaccessible to me.

If ICANN set up some sort of http proxy at say query.dns.  that  
allowed my java script to make a query and  return a XRDS document  
that had the information, or depending on the query format do a http  
302 redirect to the concrete resource.

They would have created a parallel to HXRI say a HDNS or HIDN gateway.

At that point the W3C might conceivably express an opinion on if HIDN  
conforms to AWWW.
I doubt the TAG would go so far as to express an opinion on IDN itself?

I will point out that XRI is designed to provide those sorts of  
resolution services for protocols like dns: or phone: etc through  
cross-references.

Using XHRI as it now stands I could use a cross ref and with a  
suitable XRI authority server be able to do advanced DNS (TXT, SRV  
etc) queries from within javascript in a browser. ( security may be an  
issue if HXRI are not recognized as special)

Perhaps I run the risk of stir up a whole new batch of opponents by  
attempting to clarify this.

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

On 25-Jul-08, at 11:33 PM, Mark Baker wrote:

>
> On 7/26/08, Paul Prescod <paul@prescod.net> wrote:
>> On Fri, Jul 25, 2008 at 11:24 AM, Mark Baker <distobj@acm.org> wrote:
>>>
>>>
>>> A hypermedia approach would have explicitly declared the "?" URI in
>>> the former representation with some link metadata called
>>> "metadata-record" or some such, e.g. <a rel="metadata" href="?" />
>>
>>
>> think the thing being neglected in this discussion is that the reason
>> for the naming convention is that HTTP based resolution may not be
>> always appropriate for these identifiers. You can't do an HTTP  
>> request
>> to determine that another resolution mechanism would have been more
>> reliable or efficient.
>>
>>
>> I think that you guys are talking about solving a different problem
>> than the XRI team is trying to solve. It isn't about interpreting the
>> representation for purposes of processing the resource. It's about
>> interpreting the identifier itself, for purposes of eventual
>> dereferencing.
>
> In this thread we're just talking about hypermedia in the context of
> Henry's question about out of band agreement on the meaning of names.
> That seems a couple levels detached from the more general
> XRI-and-the-Web issue.
>
>> Can you offer a suggestion that meets the requirements of the
>> applicant and also preserves the benefits of an HTTP URI?
>
> Which requirements?
>
> (and may I suggest a new thread, or reusing an existing one?)
>
> Mark.
>