- From: John Bradley <john.bradley@wingaa.com>
- Date: Mon, 14 Jul 2008 21:16:51 -0700
- To: "Mark Baker" <distobj@acm.org>
- Cc: "Booth, David (HP Software - Boston)" <dbooth@hp.com>, "www-tag@w3.org" <www-tag@w3.org>
- Message-Id: <BAF0DECF-D11B-40FB-9B46-77D39EEF9FC6@wingaa.com>
Hi Mark, If we were to proceed with David's recommendation to remove the xri: scheme from the spec and use the HXRI form for web compatibility through a proxy, then we would need some way for XRI aware applications to recognize what the actual protocol of a http scheme URL is. We are open to finding the optimal way to achieve this. We had been operating under the impression that the scheme of a URI was designed to do that. This we are told is outdated information. We are now told that: 1. No new schemes should be registered. 2. That all protocols and transports should use http: URLs for addressing to prevent fragmentation of the information space. Clearly that requires having some way to distinguish between the different types of http: URLs that will be required to achieve this across multiple protocols. I admit that this unfortunately requires the URL authority segment to not be opaque to applications. I certainly agree that the authority part of the http URL would need to be unambiguous to correctly identify HXRI encoded XRI's for applications that want to do native resolution or other processing like XDI. Having the HXRI begin with https://xri. was intended as a convenience for people who wanted to run there own proxy servers. In contemplating this change there are a number of things that will need to be changed with HXRI resolution and community XRI registries. It will certainly be more than a search and replace operation for the XRI-TC if the change is to be made properly to everyones satisfaction. If we take this step and encode all information in the path component of a HTTP URL are we still obligated to justify the existence of XRI to the W3C TAG? It is not that we don't have compelling use cases, and unique applications. It is simply that I doubt that any use case could be compelling or unique enough to reach the bar that has been referred to by the TAG. Is this bar only applicable only to new URI schemes, or anything that proposes to use http URLS for processing things other than web pages? if we must justify XRI being documented as a standard. We are willing to engage in a mutually agreeable education process. I ask, are all protocols and transports that are requested to use the http scheme going to be subjected to the same level of scrutiny? If we must meet some objective standard of utility that the W3C has set, then please provide us with the appropriate documentation regarding that standard. We will endeavor to comply. If there is a document stating how others like webdav were able to navigate this process, perhaps that could be of some help to the XRI-TC. Just for my clarification, is your position that, if XRI can be shown to meet certain standards of utility it should register the xri: scheme? This will allow the authority segment of the http scheme to remain opaque. I can personally see some merit in at least the latter half of the above statement. So how do other TAG members feel? Independent of the merits of XRI, should people use URI schemes to indicate a protocol other than http is being used for applications, or should all applications use or at least expose http: scheme urls for addressing, even over alternate protocols. I believe the XRI-TC and others are in need of that answer before we can move forward with specifications that are known to be satisfactory. Regards John Bradley OASIS IDTRUST-SC =jbradley On 14-Jul-08, at 8:06 PM, Mark Baker wrote: > > On 7/13/08, Booth, David (HP Software - Boston) <dbooth@hp.com> wrote: >> Also, I note in section 11.2, that an HXRI is intended to be >> recognizable by starting with "http://xri." (or "https://xri."). >> Wouldn't this potentially cause a regular (non-HXRI) URI that >> happens to start with that sequence to be erroneously interpreted >> as an HXRI? > > It would AFAICT, counter to advice from the AWWW[1]. This is why none > of the suggested fixes, alone or together, address my concerns. > > 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. > > So I think the discussion of URI schemes for XRIs is pretty much a red > herring. What we should, IMO, be talking about, is why http URIs and > hypermedia weren't used to provide the functionality mentioned in > 1.1.1. > > Cheers, > > [1] http://www.w3.org/TR/webarch/#uri-opacity > > Mark. >
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Tuesday, 15 July 2008 04:17:36 UTC