- From: Schleiff, Marty <marty.schleiff@boeing.com>
- Date: Wed, 9 Aug 2006 10:35:05 -0700
- To: <www-tag@w3.org>
Comments on section 2.3 (Protocol Independence) of URNs, Namespaces and Registries [1]. Applications may (and often do) treat a URI differently based on the URI's scheme. For example, a URI may be displayed as a clickable link to a user, and if the user clicks the link, then the application may attempt retrieval using a protocol/operation appropriate for the scheme of the URI (LDAP bind and search, FTP, HTTP get, etc.). While such schemes are helpful to let applications know how to interact with the identified resource, they're not ideal for durable/persistent identifiers of a resource. Example: If a resource (let's consider a resource like a certificate revocation list, or CRL) has an identifier (CRLs are commonly identified by LDAP URIs and/or HTTP URIs), and the protocol to interact with the resource changes (e.g., the Certificate Authority, or CA, decides to change publishing from LDAP to HTTP), then the identifier of the resource changes. In the example of X.509 certificates, that would be a very awkward situation, because each published certificate includes a pointer to that certificate's CRL Distribution Point, or CDP. Certificates commonly have multi-year validity periods, so a certificate issued today may have a CDP that still needs to be valid 3 years from now -- the CA cannot change the CDP for 3 years! The document [1] says it's not clear what is meant by protocol independence and why it should be a requirement. Hopefully examples like this will provide the needed clarification. I agree that if retrieval is anticipated, then any myRI <http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html> approach must specify a mapping to one or more protocols. I suggest it must also specify the operation(s) that can be used for retrieval. XRI might be a bit different from some of the other myRIs in that it introduces an abstraction layer between the identifier and the actual resource. XRIs do not support "direct" retrieval; instead they support a single operation that we call "XRI RESOLVE" (which happens to be based on a recursive series of HTTP GETs). Instead of returning the resource representation, dereferencing an XRI returns an XML document (called an eXtensible Resource Descriptor Sequence - or XRDS) describing how to interact with the named resource. The XRDS includes zero-to-many "service points", or ways to interact with the named resource. This allows a resource to maintain its identifier even though the resource's address changes, or the protocols to interact with the resource change, or other aspects of the interacting with the resource change. The XRI doesn't change, but the service points in that resource's XRDS change. This may sound similar to the Apache configuration approach described in section 5.2.2 of [1]; however, XRI specifies a consistent approach instead of an Apache-specific approach or some other product-dependent approach. The document [1] suggests that for some reason in the future the HTTP protocol could become unavailable or inappropriate -- if that ever happened, the XRI resolution protocol would need to be modified to use LDAP or some other protocol, but the assigned XRIs would not change, and even the XRDS for each resource would not change (unless some of the service points happen to be based on HTTP). A demise of http would have huge impacts to any http-aware and xri-aware application, but it might be less impact to an XRI-aware application because it would only have to learn about the new resolution protocol, and the XRDS would take care of the rest. I don't know much about the streaming video example described in the document [1], but I do know that XRIs are intended for representing any kind of resource, which I suppose includes information resources like streaming video. An XRI could be used as a protocol independent identifier for the streaming video resource. An XRI-aware application encountering that XRI would then perform XRI resolution to discover how to interact with the resource. The streaming video protocols may change over time, and as the service points in the XRDS get updated, everything continues to work. I've mentioned "XRI-aware" applications several times in this message. There's not very many XRI-aware applications in existence today. I know the TAG is trying to minimize the burden on applications to become aware of new schemes, which I think is a good goal. I'll try to dedicate a future message to this topic. [1] http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.xml Marty.Schleiff
Received on Wednesday, 9 August 2006 17:35:48 UTC