On Tue, Oct 30, 2001 at 06:48:40PM -0500, [EMAIL PROTECTED] wrote: > On Tue, 30 Oct 2001 21:15:35 GMT, Zefram <[EMAIL PROTECTED]> said: > > I'm looking for discussion of the problem more than the solution at this > > stage; my I-D does outline a couple of possible solutions, but considering > > the issues that have arisen already in respect of the problem statement, > > solution finding will have to wait a bit. > > URI - we'll work with the ISSN example that you gave. Designing a DNS > that is fault-tolerant is well-understood (use multiple NS in different > AS, not all in the same /24 like certain famous sites did ;). Therefor, > for this discussion, "if issn.org goes away that URN space is hosed". > Very true - but let's think a bit deeper. "issn.org" is not likely > to go away unless the ISSN International Centre goes away - in which case > the ISSN system is in trouble anyhow.
Woaaaaaah... I think there's a huge misunderstanding of the URI Resolution process here. Cutting out the original document's discussion here: <paste> 2.2 URI Resolution The URI resolution process defined by [NAPTR] refers URI resolvers through a series of domain names to route a resolution request to the appropriate authority that can give a location or other information for a resource. These referrals, being by name, implicitly assume that the name/identity mapping is persistent. In particular, consider URN types that are managed and resolved by a single organisation, for example the "ISSN" URN namespace described in [ISSN-URN]. In cases like this, resources critical to the handling of all URIs of a particular type are named within a domain managed by the single organisation responsible for that URI type. Any interruption of name resolution in that domain, or any compromise of the name/identity correspondence for that domain, would be highly disruptive. It is necessary in these cases that the name of a privately-managed domain be reliably persistent. </paste> The referrals are meant to be dynamic. That's the entire point of the URI Resolution process. If issn.org becomes disrupted either through some DNS problems or through the fact that ISSN changes their dns entries to be ISSSSSN.info or somesuch, the URI Resolution process still works if you do the delegation the way the documents suggest you do it. The ISSN organization could setup their NAPTR resolution process so that every day at 4:00 the delegation through (not to, but through) issn.org gets changed to some other domain-name. The entire process is dynamic enough using DNS' TTLs that there is no need for the domain-names to be persistent. The only one that does have to be persistent is the very first one (uri.arpa). In that one small sense, you are right. We do need some domains to be persistent. But we already have a process for doing that in the .arpa domain. But it should be done _EXTREMELY_ carefully. Persistence in the DNS is just the wrong way of going about it. Make your URIs persistently bound to the logical Resource and then use some dynamic resolution mechanism to make sure you can keep that resolution step in line with the logical binding.... -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | urn:pin:1 [EMAIL PROTECTED] | | http://www.neonym.net
