From: "Ronald E. Daniel" <email@example.com> Message-Id: <9511211605.ZM12337@whatthe.acl.lanl.gov> Date: Tue, 21 Nov 1995 16:05:06 -0700 In-Reply-To: "Karen R. Sollins" <firstname.lastname@example.org> To: "Karen R. Sollins" <email@example.com> Subject: Re: report: URN Architecture Meeting at University of Tennessee, Oct 30-31 Cc: firstname.lastname@example.org On Nov 21, 3:27pm, Karen R. Sollins wrote: > 1. You have chosen to omit any sort of scheme name from the URN > syntax. Why? Actually, it is there but it is hidden. We suggest the creation of the URN top-level domain. New (or old) naming schemes would, in order to claim to be URNs, register under the URN TLD. Then, when we come across a novel naming scheme, we have a place to go to ask questions about the naming scheme. > > 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. Mostly this was so we would have a smooth hierarchy. This would allow path-style floating location of resolvers if we decide that is a good thing, and I think there is still a case that can be made for ease of use to people who are internet novices. However, I am not going to draw some line in the sand about that particular syntax. We could flip the whole thing around like a CID for all I care. > 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? We cannot gurantee this in the existing domains unless they already have such a policy (I am told that some do have such a policy). This is another reason why we propose the new top-level domain where such a policy can be applied from the outset. However, if we do not allow people to use their existing domain names as a naming authority, we get into a whole slew of problems trying to establish such a capability - 99% of which already exists. > 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? This is the URN TLD again. To accomodate, for example, ISBNs, someone establishes the isbn.urn domain, and provides the new resource records that point to a bunch of different resolvers. The rest of the name is the opaque string, ala urn:urn/isbn:0-19-853737-9 > 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? Not clear on what you mean here Karen. We do NOT propose shadows of .com, .edu, .... in the URN space. We do propose that naming schemes claiming to be URNs register under the URN TLD. Depending on the naming scheme, naming authorities may become third, fourth, ... level domains, or all that stuff may be buried in the opaque string ala ISBNs. > 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. I'd much prefer to see them all on an equal > footing. Yeah, I can certainly see your point. However, to say that things are "URNs" implies that there is some sort of overarching namespace. We are just saying that the overarching namespace is the URN TLD - and we also make the obvious shortcut of allowing existing TLDs to be used as well. > 6. As I understand it, you have fairly tightly coupled naming > authority names and resolution services. A naming authority, which is a domain name, can have a set of NAPTR records associated with it. Those records would then point to particular servers that can do resolution of names under that authority. The records will contain the hostname, protocol, port, and priority. So, there is a level of indirection from the naming authority to the resolution server. > Is it possible to have > several different resolution services providing translation for > different parts of the namespace of a naming authority? This sounds basically like the path-style multiple resolvers thing. Another interpretation would be for the NAPTR records to contain regexps, only those records whose regexps matched the URN would be considered as candidate resolvers. Which of these (or both) do you mean? > 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? First of all, inferring the location of a resolver based on the naming authority is not the only way resolution can proceed. I fully expect clients to first of all try some local resolver service, then to try some commercial resolver service, and only attempt this inference when that fails. Second, I think that management will typically be over collections rather than individual documents. Those provisos out of the way, it is still the case that we need to consider the worst case you are pointing out. Its a nasty worst case. It puts a resource record per document into DNS, which is exactly what we do not want to do. I had not considered this up to now. My quick reaction is that the key to handling this worst case without ludicrous explosion of resource records is twofold. The first is to require the agency with authority over the domain name not to register huge numbers of resolvers that only deal with tiny portions of the namespace. The second is making sure that the URN resolution software has the ability to forward resolution requests to a "sibling" that has picked up part of the namespace, and the servers have some facilites for keeping track of siblings. > 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? Um, this seems a chicken and egg problem. You say that the resolution service to use should be a characteristic of the object, not the name. However, resolution is the process of mapping a name to an object (or to a means of fetching the object). At the start of the resolution process all we have is the name, not the object. Therefore it seems hard to know characteristics of the object rather than characteristics of the name. > 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. Yeah, that's the URN TLD again. -- Ron Daniel Jr. email: email@example.com Advanced Computing Lab voice: (505) 665-0597 MS B-287 TA-3 Bldg. 2011 fax: (505) 665-4939 Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, 87545 tautology: "Conformity is very popular"