- From: John Bradley <john.bradley@wingaa.com>
- Date: Sat, 26 Jul 2008 10:01:19 -0700
- To: Mark Baker <distobj@acm.org>
- Cc: Paul Prescod <paul@prescod.net>, www-tag@w3.org
- Message-Id: <7BDEF375-9F85-41AF-AFBF-6D3D363D0819@wingaa.com>
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. >
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Saturday, 26 July 2008 17:02:08 UTC