Date: Tue, 21 Nov 1995 15:27:18 -0500 Message-Id: <199511212027.PAA09992@lysithea.lcs.mit.edu> From: "Karen R. Sollins" <firstname.lastname@example.org> To: email@example.com Cc: firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, In-Reply-To: <199511072304.SAA19963@wilma.cs.utk.edu> (message from Keith Moore on Tue, 07 Nov 1995 18:04:32 -0500) Subject: Re: report: URN Architecture Meeting at University of Tennessee, Oct 30-31 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. 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. I should say as an aside here that I applaud the group effort to reduce the number of proposed URN/resolution schemes at this time. As a community we can't effectively support many of these, but in order to be realistic about the past and future, we should be supporting more than one. 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? 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. 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? 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? 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. I'd much prefer to see them all on an equal footing. 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? 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.