- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Wed, 6 Aug 2008 18:06:40 -0700
- To: John Bradley <john.bradley@wingaa.com>
- Cc: www-tag@w3.org
On Aug 5, 2008, at 7:31 PM, John Bradley wrote: > XRI resolution is about retrieving meta data for resources. It is > not about retrieving resourced http: is about that. All metadata is information. Accessible metadata is a potential resource. Potential resources given a URI and a deployed retrieval protocol are part of the Web. XRI resolution is therefore about retrieving representations of resources (that just happen to be metadata about other resources), and whether you do that using a new identifier or a preexisting identifier is nothing more than an implementation choice. > I have stated this a number of times. XRI and XRDS is an > extensible way of describing and retrieving those resources. Our > requirement is around extensibility and some other properties that > DNS is lacking. And I'll state again that DNS doesn't work the way you think it does. The entire XRI effort is based on one faulty assumption after another. > On the other hand unlike DNS, XRI is not optimized for size, I > would not expect that XRI would be a good replacement for looking > up A records, in most situations. Right, which is why it won't be deployed as widely as DNS. The thing about name resolvers is that they are mostly worthless until they are fully deployed, and people won't deploy them until they are worth the cost of deployment. DNS works as a delegation mechanism because it must be deployed to make any meaningful use of the Internet. We are all dependent on DNS so we place a very high premium on maintaining access to working name servers based on DNS. At the same time, we minimize the amount of stuff placed in DNS in order for it to scale. That's why most URIs use two-part delegation of name resolution, because that's what gets us scalable systems. > Through the HXRI proxy mechanism XRI is better at making that meta- > data available to web applications than DNS is. No, it isn't even remotely comparable. DNS (or its replacement) will still be working for as long as the Internet exists. It is not dependent on any single research effort. XRI will cease to work as soon as the proposing companies lose interest. > One of the things I cant get in http: are the DNS SRV records for > XMPP for a given host. Why would you want that in http? DNS is an information retrieval protocol -- just do an SRV query using DNS. There are some HTTP-to-DNS gateways, but they obviously aren't intended to scale like DNS. > Oh yes I could duplicate the information in RDF in some document > but what is the standard for that. > (hint oAuth, openID, and Google Friend Connect use XRI 2.0 > resolution of XRDS documents to allow service discoverability) > > XRI supports a number of subsegment naming conventions besides > native XRI nodes. You can have a XRI comprised entirely of URI > subsegments. > > Am I to take it that you are opposed to any proposal that would > encode XRI global authority resolution information in the path of a > http: URI? No. I couldn't care less. XRDS seriously screwed up in defining XRI. OpenID could have been deployed far more effectively if it had simply reused existing information systems directly instead of inventing a duplication of DNS using HTTP and making an incomprehensible mess of its documentation as a result. What I care about is the misinformation being spread about http and DNS in this crusade to keep XRI alive. The "http" resolution mechanism is not, and never has been, dependent on DNS. The authority component can contain anything properly encoded within the defined URI syntax. It is only when an http identifier is dereferenced on a local host that a decision needs to be made regarding which global name resolution protocol should be used to find the IP address of the corresponding authority. It is a configuration choice. On my Mac laptop it happens to be /usr/sbin/lookupd: The lookupd daemon acts as an information broker and cache. It is called by various routines in the System framework to find information about user accounts, groups, printers, e-mail aliases and distribution lists, computer names, Internet addresses, and several other kinds of information. lookupd keeps a cache of recently requested items to improve system performance. It also implements a search strategy used to find information from the many information sources that are potentially available to a computer. These include the Domain Name System (DNS), Sun Microsystem's Network Information Services (NIS), Apple's NetInfo system, and a set of files found in the /etc directory. lookupd also has a channel to query Directory Services, allowing access to data from LDAP and other directory systems. It is actively harmful to the longevity of http names to make the choice of global name service within the syntax of the identifier. A metadata service, in contrast, never needs to dereference a URI. It can simply use the entire URI as a primary key to whatever type of lookup it intends to make (just as domain names are a primary key for all the different types of DNS queries). The identifier does not imply the type of query. It is therefore irrelevant to ask how the http namespace should be carved up to support embedded XRI identifiers; just ditch the XRI identifiers and lookup any URI in your metadata service. > Is it your position that other protocols using http: uri > identifiers should not encode other directory information in the > path, and treat them solely as opaque name strings? I think metadata services should use indirect identification rather than duplication within the identifier space. But that wouldn't stop me from providing an HTTP data service that consists of a gateway to the metadata service. > If this is the case how do you feel about ARK? > > In both HXRI, ARK, and PURL the Authority segment is just used as a > placeholder for a proxy for http: scheme computability. The real > sub-scheme authority is encoded in the path. > > We are able able to do this without breaking the http: scheme spec > though we may well be violating the intent of the spec as perceived > by some people. The path is delegated to the authority -- they can do anything that they like within it, including hint that it duplicates some other namespace. But, again, I don't think that this deals with the core issue, which is that the XRI mechanism needlessly duplicates existing and already deployed mechanisms for information retrieval. > XRI certainly has a different graph model than http: is intended to > have. > > Fundamentally we and others want something different from a "naming > scheme that > is delegated hierarchically by association with domain ownership," > > That is why PURL, ARK, XRI and others exist. No, they all have the exact same properties. What PURL adds is a librarian. What ARK adds is a set of librarians. What XRI adds is? None of them are successful outside their original backers. None of them are needed. The identifier simply doesn't need to be changed to achieve decentralized availability. The Harvest system already proved that back in 1994. > Despite opinions to the contrary I think that a http: sub-scheme > system that can bridge other protocols to http via proxies is > valuable, I think I am fully aware of the value of proxies. I don't see any value in standardizing URI path prefixes (what you appear to be calling sub-schemes). > There are still open questions about how to do that. > > We may never agree on the value that XRI and XRDS add. > > I suspect that your position may that HXRI and other http sub- > schemes do not provide sufficient interlinking, and no extensions > to the existing identifier system should be allowed. The identifier system is defined to be extensible. That's why I said that you are completely missing the point of the TAG's objection if you think changing the identifier scheme will resolve the objection. The objection (as I understand it) is that XRI identifiers are not necessary because they address the same information universe as "http". Any parallel system of identification is harmful. Squeezing said parallel system of identification within the syntax of another system of identification does nothing to solve that problem. If XRI actually accomplished something outside the scope of HTTP, then it would be preferred to define an xri URI for that purpose. The problem is that it doesn't provide anything of value that isn't already deployed in the form of HTTP services, so it is ludicrous for the W3C to recommend that member companies duplicate their DNS infrastructure or upgrade all their tools to support yet another variation on distinguished names. That architecture has been repeatedly shown to be less useful and no more secure than good old DNS. ....Roy
Received on Thursday, 7 August 2008 01:07:25 UTC