RE: URNs, Namespaces and Registries

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