RE: URNs, Namespaces and Registries

I think I hear you describe 2 advantages of xris:
1) less disruption of http ever goes away,
2) a standard (and presumably lower cost?) for configuration rather than
product (apache) specific.

I think it's obvious that if http: ever goes away, then
dereferencability of http: resources will be significantly disrupted.
:-) :-).  However, doesn't the same argument apply to "xri"?  If
somebody deploys xri identifiers everywhere, and then xri goes away, is
there disruption to xri consumers?  And so isn't the argument to an
identifier minter "which do you think more likely to go away, http or
xri"?

I'll point out that the configuration for Apache is internal to apache,
and manifested by the http standard.  So you actually need to compare
the http "redirect" versus the "xri" redirect, which I tried to do in
section 5.  I'm presuming that an XRI implementation can store the
information used to generate an XRDS in any way it likes.

Cheers,
Dave

> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] 
> On Behalf Of Schleiff, Marty
> Sent: Wednesday, August 09, 2006 10:35 AM
> To: www-tag@w3.org
> Subject: 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 Monday, 14 August 2006 18:53:24 UTC