[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Will DDDS save us from URI madness?
Anyone looking for information about how to get straight answers about URIs even when they aren't easily resolved should take a look at the Dynamic Delegation Discovery System (DDDS), one of the more recent bits from the IETF: http://uri.net/ DDDS starts off fairly unpromisingly: ------------------------------ The DDDS is an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. ------------------------------- It gets slightly better: ------------------------------- The Dynamic Delegation Discovery System is used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems. The DDDS functions by mapping some unique string to data stored within a DDDS Database by iteratively applying string transformation rules until a terminal condition is reached. This document defines the entire DDDS standard by listing the documents that make up the complete specification at this time. ------------------------------- And then finally, in <http://uri.net/internet-drafts/draft-ietf-urn-uri-res-ddds-07.txt>: ------------------------------- This document describes a DDDS Application for resolving URIs. It does not define the DDDS Algorithm or a Database. The entire series of documents that do so are specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS Standard" (RFC WWWW) [1]. It is very important to note that it is impossible to read and understand any document in that series without reading the related documents. Uniform Resource Identifiers have been a significant advance in retrieving Internet-accessible resources. However, their brittle nature over time has been recognized for several years. The Uniform Resource Identifier working group proposed the development of Uniform Resource Names [8] to serve as persistent, location-independent identifiers for Internet resources in order to overcome most of the problems with URIs. RFC 1737 [6] sets forth requirements on URNs. During the lifetime of the URI-WG, a number of URN proposals were generated. The developers of several of those proposals met in a series of meetings, resulting in a compromise known as the Knoxville framework. The major principle behind the Knoxville framework is that the resolution system must be separate from the way names are assigned. This is in marked contrast to most URIs, which identify the host to contact and the protocol to use. Readers are referred to [7]for background on the Knoxville framework and for additional information on the context and purpose of this proposal. Separating the way names are resolved from the way they are constructed provides several benefits. It allows multiple naming approaches and resolution approaches to compete, as it allows different protocols and resolvers to be used. There is just one problem with such a separation - how do we resolve a name when it can't give us directions to its resolver? For the short term, DNS is the obvious candidate for the resolution framework, since it is widely deployed and understood. However, it is not appropriate to use DNS to maintain information on a per- resource basis. First of all, DNS was never intended to handle that many records. Second, the limited record size is inappropriate for catalog information. Third, domain names are not appropriate as URNs. Therefore our approach is to use the DDDS to locate "resolvers" that can provide information on individual resources, potentially including the resource itself. To accomplish this, we "rewrite" the URI into a Key following the rules found in the Dynamic Delegation Discovery System (DDDS). This document describes URI Resolution as an application of the DDDS and specifies the use of at least one Database based on DNS. ------------------------- There are also some other useful bits about URLs, URNs, and URIs available at http://uri.net. Overall, I suspect the answer to my own question is "no", since piling on specs to patch holes in other specs is rarely all that helpful. This may be useful for some situations, however. -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|