- From: Keith Moore <moore@cs.utk.edu>
- Date: Tue, 21 Nov 1995 22:08:10 -0500
- To: "Karen R. Sollins" <sollins@lcs.mit.edu>
- Cc: moore@cs.utk.edu, urn@mordred.gatech.edu, uri@bunyip.com, urc@lists.gatech.edu
> Keith et al, > > Unfortunately, I can't be at the URN BOF (but I have now rearranged my > schedule so I will be there for the URC BOF), so I would like to have > some discussion before then to air some of my concerns about the > proposal. I have a number of questions that generally, but not > completely, harken back to the requirements document RFC1737, that > represented consensus of the group. If that is no longer the case, > then we had better reopen the whole thing, but I personally think that > that's a really bad idea and don't recommend it. About RFC 1737: Sometimes people will support concensus on an informational document precisely because it is not cast in stone, and making something informational allows for the possibility of additional refinement before making it a standard. As long as we don't have deployment or documents on the standards track, and as we identify new requirements or reach a better understanding of the implications of previously assumed approaches, we should be free to change things. Having said that, I find nothing in the UTK meeting attendees' proposal that strongly violates the requirements in RFC 1737. Moreover, there are considerations not stated in RFC 1737 which should nevertheless influence design of URNs. For instance, nowhere in RFC 1737 is a requirement that assignment of URNs be limited to wealthy companies, but I suspect most of us would agree that this should not be the case. > I should say also as a preliminary, I think we need several things, > which have been on the table since before Stockholm. For the current > discussion and in light of the note from Keith, they fall into three > parts. First, there is the question of a general syntax for URNs. > Second, within that there may be a variety of more specific schemes > and restrictive schemes. These are often developed in conjunction > with a name resolution plan, which is the third issue. Just because a > naming scheme has been developed in conjunction with a particular > resolution scheme does not mean that that resolution scheme is the > only one that might work for a name of that form. So, a fourth issue > should be (as I suggested in my I-D for Stockholm) an architectural > feature and specification of a mechanism to allow for finding useful > resolution services of various flavors. Okay, as a response to your preliminary: While we clearly need to be able to grandfather other naming systems into URNs, this does not imply that we need an explicit field for a naming "scheme" within URNs. Schemes in URNs may even be undesirable. In particular: We certainly do not want to bind a resolution protocol with a naming scheme, because in the long term, some of those protocols will fall into disuse. This is true even if the resolution protocol is only strongly associated with a "scheme": If it turns out that clients assume a particular resolution protocol when resolving URNs that use a particular scheme, those clients will not be able to access those URNs if the resolution methods change. (Essentially, exposing the "scheme" in the name may degrade long-term persistence of the name in much the same way as using an ordinary Internet domain name or a filename as part of a name degrades long-term persistence -- if doing so encourages clients to make assumptions about the name that are not likely to be valid in the long term.) We therefore need to put the binding between a URN and its resolution protocol somewhere besides the URN -- in a network-accessible registry that can accept *any* URN and return a list of services, service locations, etc., that are valid for that URN. For reasons too numerous to mention here, there can and will be multiple registries. But if any registry can potentially return pointers to services for any URN, the client need only be configured with a list of *registries* to consult, rather than a (more complicated and more frequently changing) list of mappings from URN "schemes" to resolution services. With the introduction of registries, a single URN can be listed in multiple registries and supported by multiple resolution services -- which not only allows transitions, but also facilitates convergence on a smaller number of registry and resolution protocols. For the sake of fairness, it's very important that there be at least one registry that *anyone* can use to define resolution services for their own URNs. Today the obvious way to do this is via DNS. Ten years from now the "default registry" may be different, but one hopes that even ten years from now it will still be possible for anyone to publish things with URNs at very low cost. This implies a widely deployed and accessible directory service with maintenance performed by the suppliers -- like DNS. (To clarify the UTK report, the DNS-based URN registry was never intended to be the only URN registry -- just a registry that anybody could use.) As for support of other schemes: Existing naming schemes can be incorporated into URN-space by creating a .URN domain name for the scheme name. With respect to the DNS-based URN registry, services for names from existing naming schemes can be associated with various schemes by adding and the appropriate DNS resource records for the .URN domain name created for that scheme. Now, having said all of that, I'm not adamantly opposed to having a separate "scheme" field in URNs, as long as: 1. "scheme" doesn't imply "resolution protocol", either in theory or in anticipated practice 2. we define a DNS-based registry that can potentially accept *any* kind of URN (not just those of a "dns" scheme) 3. anybody can easily register a name in the DNS registry. I think this addresses the four issues you mention, though perhaps not in the same order. :) > So with all that said, I am left with some questions for you, Keith, > or whoever from the representing group wishes to address them. > Unfortunately as a community we do not have a real architecture > document, nor do we have requirements documents for anything other > than URNs. But, we do have proposals for both a general syntax (to > which you have chosen not to adhere) and a variety of specific URN > schemes in conjunction with specific proposals for resolution schemes. > Your newest proposal seems not to quite meet the requirements of the > URN requirements document, clearly is slightly different from some of > the previous URN/resolution schemes, and seems not to address at all > the problems of allowing for more than one resolution scheme. I am > left a little puzzled. > > 1. You have chosen to omit any sort of scheme name from the URN > syntax. Why? explained above. > 2. If the NA is simply a transformation of a domain name, why have you > chosen a different syntax for it than a domain name? I'm against > chosing different syntaxes for things unless there is a good reason. I won't argue about this one. The actual syntax of the NA is not an issue for me, as long as there is a simple mapping from every NA into a domain name that can be potentially registered in the DNS-based registry. Right-to-left NA names with dot separators are fine; left-to-right NA names with slash separators are also fine: as long as we pick exactly one of those. > 3. As I understand it there will potentially be naming authorities for > each domain name in the DNS. Since these are frequently reassigned, > how do you propose to guarantee that DNS domain names are not reused > in this specific context? I'd state this a bit differently: anyone who has a chunk of domain space delegated to her can define a naming authority name under that chunk of domain space. (I wouldn't expect there to be nearly as many naming authorities as, say, domain names of hosts.) There is a subtle but important difference between: a. The URN system must guarantee persistence, and b. Clients should be able to assume persistent URNs. I think we can reasonably acheive the second, but not the first. As several people have observed, persistence is largely a matter of discipline in name assignment, and committment to provide resolution services (using whatever protocols are currently in vogue) over the useful life of the resource. While domain names for hosts are frequently reassigned, it is possible to define domain names in ordinary DNS space that are unlikely to be reassigned. For example, the University of Tennessee could define a NA of urn.utk.edu for the purpose of assigning URNs. Reassignment of utk.edu is unlikely, and the University of Tennessee, if it chose, could make a commitment to maintain the urn.utk.edu name and its resolution services for many decades. In rare cases, domain names have been forcibly reassigned to other parties. This is one reason for the proposal for a .URN top-level domain, under which reassignment would be prohibited. But there would probably be other constraints on both names under .URN and operation of the DNS-based registry under .URN to better ensure long-term persistence. Due to the additional costs imposed by these constraints, membership in the .URN space might be unavailable to small information providers. Furthermore, even though there is a clear need for names which are persistent over the long-term, there's also a need for URN-related services for resources and resource names that only have short-term utility. While we'd like to discourage reassignment of such names in any case, ordinary domain names will suffice as NAs for URNs for the purpose of resolving many kinds of resources. (It is still desirable to prevent name collisions, but there are other ways of doing this: e.g. we could require that a date be included in the LUI portion of a URN) Having naming authorities under both .URN and in ordinary domain space is a compromise to provide for both maintenance of names in the long-term (for those who can afford the best), and allowing anyone who wants to be an information provider to assign URNs and provide URN-based resolution services. > 4. The scheme as it stands makes no provision for legacy naming > schemes (or other naming schemes than yours) in the general syntax > suggested. How do you propose to handle this? By defining new names under .URN for those legacy schemes, and optionally establishing pointers to resolution services for those names in the DNS-based registry. > 5. You propose that > a new top level domain called "urn" should be created. That's fine. > The only way I can imagine handling the alternative naming scheme > problem of question 3 is to make each other naming scheme besides > yours be a second level name within the "urn" top level. Do you > consider this a reasonable approach? Comment: If you do, I'm not > sure I agree because it would somehow make your scheme special with > respect to all others, and I'm not sure why that should be the case. The UTK group's proposal for URNs was not intended as a single "scheme" among peers. It *was* intended as an umbrella which could incorporate other naming schemes. The proposal makes more sense when viewed in this light. Even if we had schemes in the URN, I'd still argue that we need a DNS based registry which could incorporate *all* URNs - regardless of scheme - and which allowed those who assign URNs to advertise resolution services for those URNs, and which allowed those services to change over time. > 6. As I understand it, you have fairly tightly coupled naming authority > names and resolution services. Is it possible to have several > different resolution services providing translation for different > parts of the namespace of a naming authority? Over time, this may > degenerate as the management of these resources diverges, so that > each object named within a naming authority may be resolved by a > different resolution service. Is there a way to handle this worst > case scenario? The problem is that for each object, the question of > which resolution service to use for it is (or should be, I believe) > a characteristic of the object not of the namespace from which it > happened to get a globally unique name. Did you intend to couple > these as tightly as you did and if so, why and how can I get around > it? (whew) okay, in order: a. The NA is not coupled with the resolution service. Not at all. The binding between the URN and its resolution services is provided by one or more registries, and thus can be changed at any time. b. Under this scheme, yes it is possible for a URN to have several different resolution servers -- simply by listing multiple services in the registry. We are looking at various ways to specify resolution services for subspaces of the URN space under an NA. (As for *translation* of different parts of the namespace, the ideas we discussed at the UTK meeting would at least allow it for particular resolution protocols.) c. The worst case scenario (of maximum entropy of the URN->resolution service mapping within an NA's portion of URN space) is handled by delegating the resolution service (in each registry) to a service which handles large flat name spaces and issues "redirects" to other servers as needed. This "flat" resolution service need not be provided by the NA itself, since the NA can issue redirects to other servers. d. You and I agree that the resolution service should not be coupled with the object. On the other hand, it's assumed to be likely (especially for recently defined objects) that there is a strong correlation between the NA that assigned a resource name and the entity that provides resolution services for that names. This system proposed at the UTK meeting optimizes for lookup of recently defined names (by aggregating the mapping of names defined under an NA to resolution services), but still allows arbitrary mapping of names to service locations (by allowing those resolution services to issue redirects). > 7. Do you have any thoughts about how you would handle urns > that are created from within some other scheme? I suggest that > perhaps there should be something outside any particular scheme that > helps with this, but that each resolution scheme, when handed a name > that it cannot translate should be prepared to either say so, or > invoke this alternative mechanism. The UTK report says nothing about particular resolution protocols, only about the syntax of URNs in general and the DNS-based registry for mapping URNs to services, protocols, and service locations. What I mean is: I think we've tried to define the "outside" mechanism rather than the "inside" one. Perhaps it seems otherwise because so many of the UTK meeting participants had proposed DNS-based URN schemes, but what we were looking for at UTK was a way to bring an acceptable level of commonality to all URN schemes. Keith
Received on Tuesday, 21 November 1995 22:08:41 UTC