Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA02419 for urn-ietf-out; Thu, 29 Aug 1996 19:10:27 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA02412 for ; Thu, 29 Aug 1996 19:10:23 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28492 (mail destined for urn-ietf@services.bunyip.com); Thu, 29 Aug 96 19:10:21 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id RAA04968 for ; Thu, 29 Aug 1996 17:10:19 -0600 (MDT) Message-Id: <2.2.32.19960829231601.006980e8@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 29 Aug 1996 17:16:01 -0600 To: urn-ietf@bunyip.com From: Ron Daniel Subject: [URN] more info on edits for NAPTR draft Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com A note on process - this note delves into details of the regular expression syntax for the NAPTR draft. This should *not* be construed as indicating that the group has reached consensus on the issue Leslie brought up yesterday. (For one thing, Karen is on travel and will probably not be able to respond to Leslie's message until next week). I am sending this to the list becase I want to solicit input on a detail of implementation if we do go down the regexp path. A few days back, Terry Allen said that he couldn't get sed to work with the regexp examples in the NAPTR draft. He had to put backslashes in front of the '(' and ')' characters which are used for remembering subexpressions. He also said that his implementation of sed didn't support the /i flag we assumed for case insensitivity. After a bit of research I have found out why. POSIX defines two forms of regular expressions -Basic (BRE) and Extended (ERE). sed is defined to work on BREs, while our implementation set the flag to use EREs. Among the differences between the two is the handling of parens. In BREs, we can create subexpressions by using "\(" and "\)" to delimit the subexpression. Parens are not special in BREs. Second, we can use the \DIGIT "backref" inside the regexp itself. For example, the BRE a\(b\)\1 would match the string "abb" but not the string "abc". In contrast, EREs define parens as special characters. We put a backslash in front of the paren if we want to match a literal paren. Second, EREs do not have the notion of backrefs within the regexp themself. My question to the list is which way shall we go? Extracting subexpressions is a vital part of the rewrite, so we have to go one way or the other. In either case, we probably have to go on and provide a grammar for just what we mean by a "substitution expression. "sed-style" is not enough. I think the /i flag is very important for us to provide. Other flags, such as /p and /w don't seem to have a lot of meaning in ou application. I don't know that it makes a lot of difference which way we go. BREs are closer to sed, but they will require more backslashes. Since we have to escape the backslash with another backslash in zone files, this doesn't seem like a large advantage. Opinions? Mine is to go with EREs, but it is not strongly held. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hypernym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA26121 for urn-ietf-out; Tue, 27 Aug 1996 18:36:27 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA26116 for ; Tue, 27 Aug 1996 18:36:19 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10165 (mail destined for urn-ietf@services.bunyip.com); Tue, 27 Aug 96 18:36:06 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id QAA21885; Tue, 27 Aug 1996 16:35:59 -0600 (MDT) Message-Id: <2.2.32.19960827224137.006d8fe4@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Aug 1996 16:41:37 -0600 To: leslie@bunyip.com (Leslie Daigle), urn-ietf@bunyip.com From: Ron Daniel Subject: Re: Need Input -- was Re: [URN] Concerns Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Leslie Daigle (at least at 04:33 PM 8/27/96 -0400) ... >Let me try to summarize how I read the two sides of >the point, and draw out of it one issue that I would like to hear responses >on -- both affirming and dissenting, so that we can see what the overall >feeling is. > > . We can build a URN system that requires some syntactic structuring > of _all_ components of a URN, with a view to providing more > rigourous (how many u's do we use in that word in Canada?!) > maintenance structures, resolution operations, etc. > > . We can build a URN (resolution) system that relies on federating > heterogeneous name spaces -- both existing and future. In this > case, the primordial need is to build a system that can accommodate > the needs of a broad spectrum of namespaces with widely divergent > aims and goals. The goal is to provide some set of standardized > mechanisms for handling URNs of all namespaces, while minimizing > the requirements placed on the structure of the name. [...] >The real issue on which there needs to be traffic is which of the two >paths we are going to follow here -- or creative suggestions for an >alternate position. Well, I don't know how creative this is, but there is a middle ground to consider. Let me point it out for compleness, then say why I still like the second of your two items. Your first point talks about the structuring of "all" components of a name. I take that to mean that the developer of a namespace could write some expression that would not only check that the syntax of the namespace is being followed, but could yank out pieces of the URN and put them into some canonical order for resolution. This was the gist of Lewis' proposal. The problem with this is that the designer's knowledge stops at the boundries of any "opaque string" in the name. Therefore, the ability to delegate resolution also stops at that point, because we can't detect components in the opaque string. However, lots of publishers may want to put structure into their opaque strings and use that structure in the resolution process for delegation. With the first model, they don't get to, which is why I find it pretty much unacceptable. As a middle ground between the two positions, we could have one where the designer writes an expression that validates the URN and puts its components into the canonical order up to the opaque string. Then, when the resolution process has gotten us to a server that corresponds with that opaque string boundary, we can get a new expression to check the syntax and put it into the canonical order. (This model should also allow recursive opaque strings). I could live with this middle ground if it were the consensus of the group that it was the correct model, but I still like it less than the other position that Leslie mentioned, for at least three reasons: 1) I think that the model where we can do a rewrite at any stage of the resolution process gives us enough power to get ourselves out of unforseeable jams down the line. I know that I am not smart enough to see the future clearly. I would rather approach it with a big toolkit than a small one. 2) I think that the resolution system du jour should have no impact whatsoever on the allowed structure of names. What we do to make names easier to resolve for today's URN resolution system stands an excellent chance of making things more difficult to resolve for tomorrow's resolution system. We also stand a chance of not being able to handle some namespace because we didn't put the right wrench into our toolkit. 3) I think that it will be more difficult to construct the expressions that check syntax, reorder the components, eat components off of the canonical order, etc. than it will be to construct the regular expression alternatives. This difficulty stems from 3 areas: a) The conceptual model, which I think is much more difficult to understand than rewrites of the URN. b) The need to manage multiple inputs and outputs. Lewis' proposal has programs, rules, URNs, domain names, and the canonical string. Programs are what convert the URN into the canonical string. Rules are what eat components from the front of the canonical string and give the next domain name to look at. In addition to that task, the rules leave the canonical string shorter for the next rule. In contrast, the model in the NAPTR draft has URNs, domain names, and regexps. The next domain name to query can either be supplied directly (the replacement field) or can be obtained by a rewrite of the original domain name. c) The bit about the canonical string is important. Using the canonical string puts us into the situation where the input to a rule is the output of another. This is something that makes rewrite rules confusing, because you can't understand a rule without knowing how all preceding rules have affected the input string. Also crucial is that if someone upstream in the resolution process changes their rule, and changes the handling of a delimiter, all of a sudden your rules can be broken. In contrast, the rewrite rules in the NAPTR proposal can be understood in isolation, because they are applied to the URN and have a single output - a domain name. I should note that the canonical string offers a powerful advantage in addition to the disadvantages I have just mentioned. Since the canonical string shrinks at each stage of the resolution process, we have a gurantee of termination. The NAPTR stuff can detect cycles, but has no way of avoiding a long slow walk through a large "funhouse", if someone can construct such a space without being detected. I believe that this possibility is more remote than the one of upstream changes. All my humble opinion of course, :-) Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA25099 for urn-ietf-out; Tue, 27 Aug 1996 17:25:17 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA25094 for ; Tue, 27 Aug 1996 17:25:15 -0400 Received: from oit.gatech.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09801 (mail destined for urn-ietf@services.bunyip.com); Tue, 27 Aug 96 17:25:13 -0400 Received: (from ccoprmm@localhost) by oit.gatech.edu (8.7.5/8.7.3) id RAA22737; Tue, 27 Aug 1996 17:25:12 -0400 (EDT) From: Michael Mealling Message-Id: <199608272125.RAA22737@oit.gatech.edu> Subject: Re: Need Input -- was Re: [URN] Concerns To: leslie@bunyip.com Date: Tue, 27 Aug 1996 17:25:11 -0400 (EDT) Cc: urn-ietf@bunyip.com In-Reply-To: <199608272033.QAA14748@beethoven.bunyip.com> from "Leslie Daigle" at Aug 27, 96 04:33:28 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Michael Mealling Errors-To: owner-urn-ietf@bunyip.com Leslie Daigle said this: > . We can build a URN system that requires some syntactic structuring > of _all_ components of a URN, with a view to providing more > rigourous (how many u's do we use in that word in Canada?!) > maintenance structures, resolution operations, etc. > > . We can build a URN (resolution) system that relies on federating > heterogeneous name spaces -- both existing and future. In this > case, the primordial need is to build a system that can accommodate > the needs of a broad spectrum of namespaces with widely divergent > aims and goals. The goal is to provide some set of standardized > mechanisms for handling URNs of all namespaces, while minimizing > the requirements placed on the structure of the name. > While my answer might be obvious I wanted to iterate on why for a second. I specifically want the second option for two reasons: 1) It facilitates buy in on a large scale due to the ability of current publishers to get into the system with low up front cost. If its one thing we've learned on the net its that if you make it cheap in the beginning they don't mind getting expensive latter. 2) It allows some of the larger players such as OCLC, Handle, D&B to play with their namespaces that have a HELL of a lot of stuff already in them. -MM -- ------------------------------------------------------------------------------ Life is a game. Someone wins and someone loses. Get used to it.
Michael Mealling Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA23816 for urn-ietf-out; Tue, 27 Aug 1996 16:33:37 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA23811 for ; Tue, 27 Aug 1996 16:33:33 -0400 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09397 (mail destined for urn-ietf@services.bunyip.com); Tue, 27 Aug 96 16:33:30 -0400 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id QAA14748 for urn-ietf@bunyip.com; Tue, 27 Aug 1996 16:33:29 -0400 Message-Id: <199608272033.QAA14748@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Tue, 27 Aug 1996 16:33:28 -0400 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: urn-ietf@bunyip.com Subject: Need Input -- was Re: [URN] Concerns Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com I think there is a single point that needs to get resolved before we can proceed with the work here. It is illustrated in the exchange of views between Karen and Ron earlier this week, and to some extent between Lewis and Ron earlier. Let me try to summarize how I read the two sides of the point, and draw out of it one issue that I would like to hear responses on -- both affirming and dissenting, so that we can see what the overall feeling is. . We can build a URN system that requires some syntactic structuring of _all_ components of a URN, with a view to providing more rigourous (how many u's do we use in that word in Canada?!) maintenance structures, resolution operations, etc. . We can build a URN (resolution) system that relies on federating heterogeneous name spaces -- both existing and future. In this case, the primordial need is to build a system that can accommodate the needs of a broad spectrum of namespaces with widely divergent aims and goals. The goal is to provide some set of standardized mechanisms for handling URNs of all namespaces, while minimizing the requirements placed on the structure of the name. >From the sounds of discussion, we cannot do both -- the former requires structuring in the namespace-specific strings, and the latter seeks to include the many namespaces that cannot be so addressed (existing ones, proprietary ones, etc). The latter is too loose in structure to leave hooks for sophisticated maintenance, etc. To regex or not to regex becomes an implementation detail. The real issue on which there needs to be traffic is which of the two paths we are going to follow here -- or creative suggestions for an alternate position. I reserve my own comments, including what I _though_ we'd agreed on to date, for a later posting. Leslie. -- ------------------------------------------------------------------------------ Leslie Daigle "Learn and live." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ------------------------------------------------------------------------------ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA23570 for urn-ietf-out; Tue, 27 Aug 1996 16:11:11 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA23565 for ; Tue, 27 Aug 1996 16:11:05 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08587 (mail destined for urn-ietf@services.bunyip.com); Tue, 27 Aug 96 16:10:56 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id OAA11925; Tue, 27 Aug 1996 14:10:51 -0600 (MDT) Message-Id: <2.2.32.19960827201629.006de180@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Aug 1996 14:16:29 -0600 To: Martin Hamilton , urn-ietf@bunyip.com From: Ron Daniel Subject: Re: [URN] use of info gleaned from DNS Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Martin Hamilton (at least at 08:33 PM 8/27/96 +0100) >I don't think there's any mention of this in the current NAPTR >draft, but it might be worth popping a note into the security >considerations section about the potential danger of using info >gotten from the DNS without any checking/santizing ? > >e.g. don't just invoke a program using info from an NAPTR RR as >command line arguments, because there could be some nasty >characters lurking in there Right, good point. I'll do that. As a clarification, the regexp field is not intended to be given to programs on the command line. It is intended to be given to a regular expression library that the client has linked to. However, client implementors will do what they will do, so I will warn them not to pass the string off to Perl or something similar without checking it for sanity. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA23117 for urn-ietf-out; Tue, 27 Aug 1996 15:33:08 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA23112 for ; Tue, 27 Aug 1996 15:33:06 -0400 Received: from gizmo.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08177 (mail destined for urn-ietf@services.bunyip.com); Tue, 27 Aug 96 15:33:03 -0400 Received: from mrrl.lut.ac.uk (martin@localhost.mrrl.lut.ac.uk [127.0.0.1]) by gizmo.lut.ac.uk (8.7.5/8.6.9) with ESMTP id UAA01372 for ; Tue, 27 Aug 1996 20:33:01 +0100 (BST) Message-Id: <199608271933.UAA01372@gizmo.lut.ac.uk> To: urn-ietf@bunyip.com X-Uri: Subject: [URN] use of info gleaned from DNS Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <1368.841174380.1@mrrl.lut.ac.uk> Date: Tue, 27 Aug 1996 20:33:00 +0100 From: Martin Hamilton Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin Hamilton Errors-To: owner-urn-ietf@bunyip.com I don't think there's any mention of this in the current NAPTR draft, but it might be worth popping a note into the security considerations section about the potential danger of using info gotten from the DNS without any checking/santizing ? e.g. don't just invoke a program using info from an NAPTR RR as command line arguments, because there could be some nasty characters lurking in there Martin Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA22877 for urn-ietf-out; Tue, 27 Aug 1996 15:26:26 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA22846 for ; Tue, 27 Aug 1996 15:26:18 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08009 (mail destined for urn-ietf@services.bunyip.com); Tue, 27 Aug 96 15:26:04 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id NAA01786; Tue, 27 Aug 1996 13:25:52 -0600 (MDT) Message-Id: <2.2.32.19960827193130.006cdce4@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Aug 1996 13:31:30 -0600 To: liberte@ncsa.uiuc.edu (Daniel LaLiberte) From: Ron Daniel Subject: Re: [URN] NAPTR "wizards" Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Daniel LaLiberte (at least at 11:21 AM 8/27/96 CDT) >Ron Daniel writes: > > Actually, at the BOF in Montreal, we explicitly said that URNs are not > > going to solve the friendly naming problem. > >I wasn't there, so I don't know, but I would guess this is a bit >strong. Rather, URNs are not *necessarily* going to solve the >friendly naming problem. In other words, the system supported by >NAPTR-based resolution could be used to support friendly names, but >doing so is beyond the scope of the URN problem, which is unique >names. Right, I was imprecise. We are going after the unique names problem. If they can also be friendly, so much the better. However, we are not going specifically after the friendly names problem. > I would be opposed to a system which made it more difficult >than necessary to allow unique names to also be friendly. Agreed. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA22870 for urn-ietf-out; Tue, 27 Aug 1996 15:26:25 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA22848 for ; Tue, 27 Aug 1996 15:26:18 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08008 (mail destined for urn-ietf@services.bunyip.com); Tue, 27 Aug 96 15:26:04 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id NAA01777; Tue, 27 Aug 1996 13:25:51 -0600 (MDT) Message-Id: <2.2.32.19960827193129.006c5b3c@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Aug 1996 13:31:29 -0600 To: weibel@oclc.org (Stu Weibel), urn-ietf@bunyip.com From: Ron Daniel Subject: Re: [URN] NAPTR "wizards" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Stu Weibel (at least at 02:17 PM 8/27/96 -0400) >Ron Daniel writes: > > > Actually, at the BOF in Montreal, we explicitly said that URNs are not > > going to solve the friendly naming problem. > >Dan LaLiberte writes: > >> I would be opposed to a system which made it more difficult >> than necessary to allow unique names to also be friendly. > >I strongly agree with Dan on this point. > >We're back to the groundhog day problem... we don't agree what the >problem is, so we can't agree on the solution. Whoa, wait a sec. I also agree with what Dan said. There is a big difference between saying "URNs are intended to solve the unique name problem, not the friendly naming problem" and saying "URNs must make friendly names impossible". Dan says that he doesn't want us to mandate that unique names also be unfriendly. I agree. I want us to mandate as little as possible about the names themselves. Where we start having a conflict is that what is normally meant by "friendly names" are normally not unique, the whole thing with Apple was to illustrate that point. First-come, first-serve is not the best algorithm for assiging friendly names, but that is why "apple.com" gets you Apple computer and not Apple music. If someone has a naming scheme for assigning unique friendly names we should be able to use it in deterministic resolution schemes. Non-unique names need additional information from the user, which is what kicks them out of the deterministic world into directory service world. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA22358 for urn-ietf-out; Tue, 27 Aug 1996 15:05:33 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA22352 for ; Tue, 27 Aug 1996 15:05:31 -0400 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07783 (mail destined for urn-ietf@services.bunyip.com); Tue, 27 Aug 96 15:05:27 -0400 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id PAA14680; Tue, 27 Aug 1996 15:05:24 -0400 Message-Id: <199608271905.PAA14680@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Tue, 27 Aug 1996 15:05:22 -0400 In-Reply-To: Stu Weibel's message as of Aug 27, 14:17 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: weibel@oclc.org (Stu Weibel), urn-ietf@bunyip.com Subject: Re: [URN] NAPTR "wizards" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Well, Stu, there may have been areas in which there was less consensus than others in Montreal, but I think this actually need not be one of them. What I understood out of the Montreal meeting is that we agreed to work on a general uniform resolution system -- i.e., those things, and only those things, necessary to get heterogeneous naming systems to hang together so that they could be used in a broad variety of contexts, with some common expectations about longevity, accessibility, and maintenance. [Stu wrote:] > NAPTR-based resolution is solving a RESOLUTION problem, not a unique naming > problem (the solution to which is far simpler, and for which numerous > solutions already exist). Not just "NAPTR-based", but the point of the framework presented in Montreal. Yes, they do tackle the resolution problem, not the naming problem, _because_ those problems are dealt with elsewhere. Let PURLs, FPIs, ISBNs, Handles, etc play in the URN arena, and time and market space will determine which work best. So, [Ron wrote:] > Actually, at the BOF in Montreal, we explicitly said that URNs are not > going to solve the friendly naming problem. and [Dan wrote:] > strong. Rather, URNs are not *necessarily* going to solve the > friendly naming problem. In other words, the system supported by > NAPTR-based resolution could be used to support friendly names, but > doing so is beyond the scope of the URN problem, which is unique > names. [...] and both are right. If we set out with user friendly naming as a goal of the WG, then every thing we did would have to ensure that it was true for all potential namespaces (and my user-friendly is your user-abhorrent). Rather, we focus on the mechanics, and let individual namespace builders worry about how user-friendly their users want names to be. Leslie. -- ------------------------------------------------------------------------------ Leslie Daigle "Learn and live." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ------------------------------------------------------------------------------ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA22300 for urn-ietf-out; Tue, 27 Aug 1996 15:01:37 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA22288 for ; Tue, 27 Aug 1996 15:01:32 -0400 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07723 (mail destined for urn-ietf@services.bunyip.com); Tue, 27 Aug 96 15:01:22 -0400 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id MAA07565; Tue, 27 Aug 1996 12:01:03 -0700 Date: Tue, 27 Aug 1996 12:00:57 -0700 (PDT) From: "Gregory J. Woodhouse" To: Stu Weibel Cc: urn-ietf@bunyip.com Subject: Re: [URN] NAPTR "wizards" In-Reply-To: <199608271817.OAA01940@ws02-00.rsch.oclc.org> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com On Tue, 27 Aug 1996, Stu Weibel wrote: [...] > We're back to the groundhog day problem... we don't agree what the > problem is, so we can't agree on the solution. > > NAPTR-based resolution is solving a RESOLUTION problem, not a unique naming > problem (the solution to which is far simpler, and for which numerous > solutions already exist). > Good point. Perhaps I could rephrase my initial comment as saying that I think regexps serve to minimize the extent to which URN schemes depend upon the specifics of the NAPTR proposal. Ideally, of course, they should be independent of one another, but from a practical point of view I agree that regexps provide a high degree of independence without introducing too much (computational) complexity. That being said, I only ment to suggest that means may be available to help alleviate the difficulty of maintaining a regexp based system and making it less error prone. From the perspective of this group, I only think it is significant that such means are available. The details are another matter altogether. [...] --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/ resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA22230 for urn-ietf-out; Tue, 27 Aug 1996 14:56:39 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA22225 for ; Tue, 27 Aug 1996 14:56:32 -0400 Received: from oit.gatech.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07698 (mail destined for urn-ietf@services.bunyip.com); Tue, 27 Aug 96 14:56:26 -0400 Received: (from ccoprmm@localhost) by oit.gatech.edu (8.7.5/8.7.3) id OAA17590; Tue, 27 Aug 1996 14:56:15 -0400 (EDT) From: Michael Mealling Message-Id: <199608271856.OAA17590@oit.gatech.edu> Subject: Re: [URN] NAPTR "wizards" To: weibel@oclc.org Date: Tue, 27 Aug 1996 14:56:14 -0400 (EDT) Cc: urn-ietf@bunyip.com In-Reply-To: <199608271817.OAA01940@ws02-00.rsch.oclc.org> from "Stu Weibel" at Aug 27, 96 02:17:31 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Michael Mealling Errors-To: owner-urn-ietf@bunyip.com Stu Weibel said this: > Ron Daniel writes: > > Actually, at the BOF in Montreal, we explicitly said that URNs are not > > going to solve the friendly naming problem. > Dan LaLiberte writes: > > I would be opposed to a system which made it more difficult > > than necessary to allow unique names to also be friendly. > > I strongly agree with Dan on this point. > > We're back to the groundhog day problem... we don't agree what the > problem is, so we can't agree on the solution. > > NAPTR-based resolution is solving a RESOLUTION problem, not a unique naming > problem (the solution to which is far simpler, and for which numerous > solutions already exist). > > I'm not sure who the "we" was in Montreal that decided on the scope and > specific nature of the problem. Attempts to clarify this in the BoF itself > were sloughed off as obstructionist. So, here we are again. What we decided was that we weren't going to SPECIFICALLY try and solve the "the user wants an easy term or phrase to remember so he can reliably find Apples homepage". That's a directory services problem. If you personally want to try and design a URN namespace that tries to solve this problem then go right ahead. Many of use just don't want to solve that particular problem as the only problem. -- ------------------------------------------------------------------------------ Life is a game. Someone wins and someone loses. Get used to it.
Michael Mealling Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA21714 for urn-ietf-out; Tue, 27 Aug 1996 14:26:18 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA21709 for ; Tue, 27 Aug 1996 14:26:16 -0400 Received: from fssun09.dev.oclc.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07452 (mail destined for urn-ietf@services.bunyip.com); Tue, 27 Aug 96 14:26:11 -0400 Received: from ws02-00.rsch.oclc.org by fssun09.dev.oclc.org (4.1/SMI-4.1) id AA12272; Tue, 27 Aug 96 14:17:34 EDT From: weibel@oclc.org (Stu Weibel) Received: (weibel@localhost) by ws02-00.rsch.oclc.org (8.6.10/8.6.9) for urn-ietf@bunyip.com id OAA01940; Tue, 27 Aug 1996 14:17:31 -0400 Date: Tue, 27 Aug 1996 14:17:31 -0400 Message-Id: <199608271817.OAA01940@ws02-00.rsch.oclc.org> To: urn-ietf@bunyip.com Subject: Re: [URN] NAPTR "wizards" X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: weibel@oclc.org (Stu Weibel) Errors-To: owner-urn-ietf@bunyip.com Ron Daniel writes: > Actually, at the BOF in Montreal, we explicitly said that URNs are not > going to solve the friendly naming problem. Dan LaLiberte writes: > I would be opposed to a system which made it more difficult > than necessary to allow unique names to also be friendly. I strongly agree with Dan on this point. We're back to the groundhog day problem... we don't agree what the problem is, so we can't agree on the solution. NAPTR-based resolution is solving a RESOLUTION problem, not a unique naming problem (the solution to which is far simpler, and for which numerous solutions already exist). I'm not sure who the "we" was in Montreal that decided on the scope and specific nature of the problem. Attempts to clarify this in the BoF itself were sloughed off as obstructionist. So, here we are again. stu Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA20302 for urn-ietf-out; Tue, 27 Aug 1996 12:25:25 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA20297 for ; Tue, 27 Aug 1996 12:25:23 -0400 Received: from newton.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06240 (mail destined for urn-ietf@services.bunyip.com); Tue, 27 Aug 96 12:25:21 -0400 Received: from void.ncsa.uiuc.edu (void.ncsa.uiuc.edu [141.142.103.20]) by newton.ncsa.uiuc.edu (8.6.11/8.6.12) with SMTP id LAA25654; Tue, 27 Aug 1996 11:25:15 -0500 Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1) id AA06144; Tue, 27 Aug 96 11:21:34 CDT Date: Tue, 27 Aug 96 11:21:34 CDT From: liberte@ncsa.uiuc.edu (Daniel LaLiberte) Message-Id: <9608271621.AA06144@void.ncsa.uiuc.edu> To: Ron Daniel Cc: urn-ietf@bunyip.com Subject: Re: [URN] NAPTR "wizards" In-Reply-To: <2.2.32.19960827160003.006b9c68@acl.lanl.gov> References: <2.2.32.19960827160003.006b9c68@acl.lanl.gov> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: liberte@ncsa.uiuc.edu (Daniel LaLiberte) Errors-To: owner-urn-ietf@bunyip.com Ron Daniel writes: > Actually, at the BOF in Montreal, we explicitly said that URNs are not > going to solve the friendly naming problem. I wasn't there, so I don't know, but I would guess this is a bit strong. Rather, URNs are not *necessarily* going to solve the friendly naming problem. In other words, the system supported by NAPTR-based resolution could be used to support friendly names, but doing so is beyond the scope of the URN problem, which is unique names. I would be opposed to a system which made it more difficult than necessary to allow unique names to also be friendly. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA19951 for urn-ietf-out; Tue, 27 Aug 1996 11:54:38 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA19946 for ; Tue, 27 Aug 1996 11:54:35 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA05861 (mail destined for urn-ietf@services.bunyip.com); Tue, 27 Aug 96 11:54:29 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id JAA21552; Tue, 27 Aug 1996 09:54:24 -0600 (MDT) Message-Id: <2.2.32.19960827160003.006b9c68@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Aug 1996 10:00:03 -0600 To: "Gregory J. Woodhouse" , urn-ietf@bunyip.com From: Ron Daniel Subject: Re: [URN] NAPTR "wizards" Cc: woodhouse@isc-sf.va.gov Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Gregory J. Woodhouse (at least at 07:05 PM 8/26/96 -0700) >people will want to design user friendly >URN schemes, and I think they should. URNs really serve two purposes: one >is persistence and the other is to allow resources to have more intuitive >names. Instead of designing our URN schemes primarily to facilitate >resolution, we should be willing to make the resolution schemes >(meta-schemes?) flexible enough to handle user friendly URN schemes. Actually, at the BOF in Montreal, we explicitly said that URNs are not going to solve the friendly naming problem. The desire for short, mnemonic, names conflicts with the desire for unique names. Apple Music vs. Apple Computer is a classic example. (My town has an elecrical contractor that goes by the name of Apple Electric). Many of us regard friendly names as a directory service sort of problem. The user puts in a friendly sort of name, and gets back a list of possible candidates. They pick which of those they are interested in, and away they go. This is not to say that friendly names are unimportant, just that we are trying to solve a different problem - that of unique names. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA13270 for urn-ietf-out; Mon, 26 Aug 1996 22:06:07 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA13265 for ; Mon, 26 Aug 1996 22:05:52 -0400 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01347 (mail destined for urn-ietf@services.bunyip.com); Mon, 26 Aug 96 22:05:50 -0400 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id TAA17313; Mon, 26 Aug 1996 19:05:40 -0700 Date: Mon, 26 Aug 1996 19:05:40 -0700 (PDT) From: "Gregory J. Woodhouse" To: urn-ietf@bunyip.com Cc: woodhouse@isc-sf.va.gov Subject: [URN] NAPTR "wizards" Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com I can readily sympathize with the concern that regexps are difficult to design and manage correctly. Doubtless, it's the rewrite rules in sendmail that gives it such a reputation for being difficult to administer! Nevertheless, I think the use of regexps in the NAPTR proposal is an excellent idea. My reason is that people will want to design user friendly URN schemes, and I think they should. URNs really serve two purposes: one is persistence and the other is to allow resources to have more intuitive names. Instead of designing our URN schemes primarily to facilitate resolution, we should be willing to make the resolution schemes (meta-schemes?) flexible enough to handle user friendly URN schemes. Okay, enough polemics. My point was only to argue that the flexibility of regexps really is needed functionality, even if maintenance will become much more difficult and error prone. On the other hand, I'd guess that many URN schemes will be quite straightforward and it should be feasible to generate the needed regexps (or even entire records) using simple interactive "wizards" (or "experts" if you prefer Borland). What I propose is that NAPTR wizards could either be made available as BIND add ons, or even included in future releases of BIND. This would both make the NAPTR scheme easier to administer and improve the robustness of the URN schemes that rely on it. --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/ resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA13688 for urn-ietf-out; Mon, 26 Aug 1996 10:28:34 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA13680 for ; Mon, 26 Aug 1996 10:28:31 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22256 (mail destined for urn-ietf@services.bunyip.com); Mon, 26 Aug 96 03:51:44 -0400 Received: from legiron.acl.lanl.gov (transitory39.lanl.gov [128.165.7.161]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id BAA12622; Mon, 26 Aug 1996 01:51:38 -0600 (MDT) Message-Id: <2.2.32.19960826075713.006cfc28@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 26 Aug 1996 01:57:13 -0600 To: "Karen R. Sollins" , urn-ietf@bunyip.com From: Ron Daniel Subject: Re: [URN] concerns Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Karen R. Sollins (at least at 07:12 PM 8/23/96 -0400) >Perhaps we would all be better >off and have a higher probability of success, if we identified a >smaller set of namespaces to which we were addressing our attention. >By limiting the set of namespace schemes we might find that two >additional concerns might be easier to address. Sure, but I don't think it will be as much help as you hope. The primary namespaces I am going after are: 1) CID - MIME ContentIDs. 2) ISO Formal Public Identifiers Best known in conjunction with SGML. These little gems have registered and unregistered naming authorities, as well as opaque strings. Both of these have the notion of "opaque strings". Almost any sort of structural info can be buried in there. That is why I think we don't achieve much restriction on allowed syntax and structure by focussing on a small number of name spaces. In addition to those two main namespaces, there are a few others that I would like to see us tackle once the first two are working reasonably well. They are: 3) SICI - Serial Item Contribution Identifier Used for identifying journal articles - ISSNs only identify the journal, not articles in a journal issue. 4) ISBN - International Standard Book Number 5) ISAN - International Standard Audiovisual Number 6) ISWC - International Standard Work Code (Music IDs) There is a lot of good content already identified with these schemes. 7) OIDs - ISO Object Identifiers Lots of things use OIDs as the naming authority part. Constructed OIDs allow an opaque ASN.1 "thing" to be appended to the hierarchical identifier. 8) http, ... NAPTR rewriting also provides a way for us to retrofit replication of resources and resolvers onto the existing URL pseudo-namespaces. It is less than perfect because there is no good way to ask for the NAPTR and/or A records for a domain name, but it is there. >1) With foreknowledge of some syntactic constraints on URN schemes, we >could reduce the probability of chaos from the otherwise uncontrolled >regular expressions needed to parse and transform aspects of schemes. >Although only a very small number of people have been commenting on >the mailing list, I heard a great deal of concern about this in >Montreal. As mentioned above, there are no syntactic constraints to exploit in "opaque strings". What I heard in Montreal were expressions of concern about the use of rewriting rules in general, not just regular-expression based ones. I also had the sense that people were of the opinion that, worrisome as it might be, this level of power seemed to be needed to meet the requirements. >2) With less complexity in the overall namespace structuring, [...] Again, I doubt that we will see any significant reductions in complexity after we take a look at the things that people will do in opaque strings. Those strings will undoubtably have lots of structure in them, and it will not necessarily follow a simple hierarchy. As an example, my lab already uses technical report identifers like: LA-UR-96-0023 LA = Los Alamos UR = Unclassified Report. We have a number of different report series, so those characters will change depending on the report series. That is one place where delegation might occur. 96 = year of publication. I assume we will change to 4 digits RSN. :-) This year is another bit of significant info that might be used. 0023 = sequentially assigned number These are existing identifiers that we at LANL would like to continue to use, and I happen to think that it is a very reasonable thing for us to do. I would oppose any effort in this group to limit what people might be able to assign in their opaque strings. [With simpler names,] >migrating to a future set of mechanisms that do not involve regular >expressions and the DNS might be manageable. I don't think we can refuse to consider the class of namespaces that use opaque strings. If we can't eliminate that class of namespaces, I don't think we can reasonably achive significant simplification in the names we have to resolve. Preventing people from assigning the names of their choice pushes expense and effort onto others. >Again, there was >significant concern expressed about this in Montreal, although not on >the mailing list since then. This is a problem that is not addressed >in the NAPTR related papers, but should be central to any plan that is >proposed. I don't recall much discussion of the migration issue during the BOF. What I recall is that people were concerned about rewrite rules because they get hairy over time. The topic of being locked into a rewrite-based system because of its power was raised by Lewis, I think, in his presentation but I can't recall it being discussed extensively. (I could be wrong on this - Lewis came up shortly after I finished and it takes me awhile to switch from speaker-mode to audience-mode). You are correct that migration to future resolution systems is not addressed in the NAPTR draft. I think that document should be a tight specification of the NAPTR record format and usage. Migration should be (IMHO) handled in the framework draft. Even there, I don't know that I would regard it as central. There are other areas of concern, such as security, replication, and maybe even rights management, that are equally important. By definition, these concerns have a more pressing time frame than migration. We certainly don't want to do things now that are going to come back to haunt us. Neither do we want to start with such a restricted system that it can't accomplish its purpose. If we want URNs to start taking over for URLs in order to achive their benefits, we have to offer a significant advantage over URLs for J. Random Publisher. I think we have two shots at that. The first is that Netscape, Microsoft, ... would really like a way to transparently direct users to mirror sites instead of having the current hack of listing 10 sites. Our second chance is by accomodating namespaces such as ISBN that have a lot of existing, high-quality, content. If we shut ourselves out of either of those markets, URNs will probably not succeed. Ugh. Its late - I'm going to bed. Best regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA24131 for urn-ietf-out; Fri, 23 Aug 1996 19:12:29 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA24126 for ; Fri, 23 Aug 1996 19:12:23 -0400 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15803 (mail destined for urn-ietf@services.bunyip.com); Fri, 23 Aug 96 19:12:21 -0400 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id TAA10444; Fri, 23 Aug 1996 19:12:20 -0400 Date: Fri, 23 Aug 1996 19:12:20 -0400 Message-Id: <199608232312.TAA10444@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: urn-ietf@bunyip.com Subject: [URN] concerns Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com I have a couple of concerns here having to do with scope of the problem and manageability of the solution. It seems that in discussion, whether or not in the text of the documents, the authors of the NAPTR framework and proposal papers want to provide resolution for all possible namespace schemes. Perhaps we would all be better off and have a higher probability of success, if we identified a smaller set of namespaces to which we were addressing our attention. By limiting the set of namespace schemes we might find that two additional concerns might be easier to address. 1) With foreknowledge of some syntactic constraints on URN schemes, we could reduce the probability of chaos from the otherwise uncontrolled regular expressions needed to parse and transform aspects of schemes. Although only a very small number of people have been commenting on the mailing list, I heard a great deal of concern about this in Montreal. 2) With less complexity in the overall namespace structuring, migrating to a future set of mechanisms that do not involve regular expressions and the DNS might be manageable. Again, there was significant concern expressed about this in Montreal, although not on the mailing list since then. This is a problem that is not addressed in the NAPTR related papers, but should be central to any plan that is proposed. I realize that these statements are not concrete. That is intentional, in order that we begin to set out the scope of what we want to do as an alternative to discussing mechanism with some assumed but perhaps not well stated scope in mind. Karen Sollins ___________________________________________________________________ Karen R. Sollins sollins@lcs.mit.edu Research Scientist Phone: 617/253-6006 M.I.T. Laboratory for Computer Science Fax: 617/253-2673 545 Technology Square Cambridge, MA 02139 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA21030 for urn-ietf-out; Fri, 23 Aug 1996 13:48:34 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA21025 for ; Fri, 23 Aug 1996 13:48:28 -0400 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13323 (mail destined for urn-ietf@services.bunyip.com); Fri, 23 Aug 96 13:48:21 -0400 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id NAA12812; Fri, 23 Aug 1996 13:48:19 -0400 Message-Id: <199608231748.NAA12812@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Fri, 23 Aug 1996 13:48:18 -0400 In-Reply-To: Lewis Girod's message as of Aug 20, 14:46 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Lewis Girod , terry@ora.com Subject: Re: [URN] re URN rewriting Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com [Lewis Girod wrote:] > OK, that makes three disparate interpretations of these > requirements... perhaps a clarification by the authors is in order? Indeed -- and my apologies for the delay in replying. I've been out of town. First, some comments on the draft itself, and then some opinions. [The section of the draft in question:] > ---------------------------------------- > Namespace Identifier Requirements and > Administration > ---------------------------------------- > > Some set of criteria must be established to govern what can and cannot > be used as a (top-level) namespace (NID assignment). This can include: > > . demonstration of an established namespace management system > (including an overview of mechanisms for preventing the > duplication/reassignation of name identifiers. These mechanisms > are particular to the individual namespaces). > . multi-organization participation in the naming system > . rules on how names are assigned, name assignment authority > delegation > . provision of escape clause > > (from draft-daigle-urnframework-00.txt) Ron is right in saying that these were proposed as more political level requirements than technically-implementable ones. They are rather rough comments at this point, flagged as an area requiring more work. The reason they came up is out of a discussion about registering namespaces, what organizations would have to do in order to demonstrate viability, etc. This is why things like "multi-organization participation in the naming system" was put there. For similar requirements, see the Postel draft on new International Top Level Domains. [From Lewis' message:] > . rules on how names are assigned, name assignment authority > delegation >I interpret this as requiring a >specification of the ways in which collections can be delegated within >the syntax of the URNs. The only way I can see to make this work is >to somehow embed the rules of delegation into the URN syntax so that >they can be verified syntactically. The point has been made before that not every namespace is going to want to publish how it assigns names. At the time a namespace is declared, it should be possible to demonstrate that names will be assigned in some reasonable fashion (that will ensure no name collision, etc). [Ron wrote:] > Hmm. That is not how I interpreted it. I was thinking that it would > be more of a definition of the business rules that would be followed > when one organization > 1) Authorized a sub-naming-authority > or > 2) Sold off some of their assigned names to some other > organization. That was certainly part of the original intention. [Lewis wrote:] > Perhaps my interpretations are outside of the sense of the > requirements, or perhaps the requirements simply haven't been > specified clearly... in any case, I think we need to make sure that Agreed -- this does need to be made more clear, and the exact requirements have to be determined. And now, I will slip gently into opinion... [Lewis also wrote:] > I interpreted point one to imply something concrete in the way of a > ``management system''. For example, demonstration of administrative > software that name assignment authorities would be given to maintain > the databases is a requirement I had in mind. That was why I was > assuming that people would have a rule compiler (although it really is > not that hard to implement!). A decompiler would be nice for > emergencies, but I was thinking that the rules would be kept in and > installed from the source format, so to debug things you would go back > to the source file. I may have fallen off the conversational thread here, but are you suggesting that because name assignment is done by algorithm, we should be able to have (naming) rule compilers and decompilers? In my recollection of how we've gotten to where we are, the purpose of the framework was to build as little common structure as necessary to hook together a very wide collection of naming systems into something that could behave in a roughly unified and uniform fashion -- at least to the extent of letting software handle URNs in a reasonable fashion to get to the space that does final resolution. I do not believe we can be in the business of defining _any_ set of rules that will encompass all the ways in which names will be assigned. Dot. Period. [Ron wrote:] > authorities what to do. I am not opposed to a modification of your > proposal that essentially says "once you get to the opaque string, > the rules of hierarchy may change, and naming authorities are free to > give you a new set of rules by which you can follow the new hierarchy". A sort of "algorithmic redirect"? [Terry Allen wrote:] > And these requirements: [see quote from framework draft] > > are, I believe, out of scope. The point is to find ways to resolve those > naming schemes that humanity creates. It is up to the name space owner > to provide resolution, and not up to the top-level registry to limit how > that resolution may be provided. While I agree that we must do our best to handle as many naming systems as possible, I do think it is reasonable to put some practical bounds on what it means to be URN-compliant. Cheers! Leslie. -- ------------------------------------------------------------------------------ Leslie Daigle "Learn and live." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ------------------------------------------------------------------------------ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA01443 for urn-ietf-out; Tue, 20 Aug 1996 17:44:47 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA01438 for ; Tue, 20 Aug 1996 17:44:35 -0400 Received: from rock.west.ora.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19209 (mail destined for urn-ietf@services.bunyip.com); Tue, 20 Aug 96 17:44:22 -0400 Received: (from terry@localhost) by rock.west.ora.com (8.6.13/8.6.11) id OAA12400; Tue, 20 Aug 1996 14:44:15 -0700 Message-Id: <199608202144.OAA12400@rock.west.ora.com> From: Terry Allen Date: Tue, 20 Aug 1996 14:44:14 PDT In-Reply-To: "Ronald E. Daniel" "[URN] revision 1 of the NAPTR draft" (Aug 16, 1:49pm) X-Mailer: Mail User's Shell (7.2.0 10/31/90) To: "Ronald E. Daniel" , urn-ietf@bunyip.com Subject: Re: [URN] revision 1 of the NAPTR draft Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com | From rdaniel@acl.lanl.gov Tue Aug 20 14:27:44 1996 | Received: from ruby.ora.com (ruby.ora.com [198.112.208.25]) by rock.west.ora.com (8.6.13/8.6.11) with ESMTP id OAA11790 for ; Tue, 20 Aug 1996 14:27:42 -0700 | Received: from acl.lanl.gov (acl.lanl.gov [128.165.147.1]) by ruby.ora.com (8.6.13/8.6.11) with ESMTP id RAA04724 for ; Tue, 20 Aug 1996 17:25:52 -0400 | Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id PAA26186 for ; Tue, 20 Aug 1996 15:27:33 -0600 (MDT) | Message-Id: <2.2.32.19960820213257.006ed93c@acl.lanl.gov> | X-Sender: rdaniel@acl.lanl.gov | X-Mailer: Windows Eudora Pro Version 2.2 (32) | Mime-Version: 1.0 | Content-Type: text/plain; charset="us-ascii" | Date: Tue, 20 Aug 1996 15:32:57 -0600 | To: Terry Allen | From: Ron Daniel | Subject: Re: comments on draft | Status: OS | | Here are you original comments - I've flagged the ones | I have tried to address. | | | At 12:34 PM 8/20/96 PDT, you wrote: | >This is pretty clean and clear. A few assorted comments: | > | >| "Must" or "Shall" - Software that does not behave in the mannar that this | >| namespace to another agency. Evaluating the NAPTR recors in the correct | > | >typos | | Got em. | | > | >All quite clear to here, | > | >| * The replacement field is one of two fields used for the rewrite rules. | >| If the rewrite is a simple substitution of a domain name, that name is | >| given in the replacement field. The replacement field is a domain name | >| (subject to compression if a DNS sender knows that a given recipient is | >| able to decompress names in this RR type's RDATA field). If the rewrite | >| is more complex than a simple substitution of a domain name, the | >| replacement field should be set to . and the regexp field used. | > | >You might by way of emphasis say "simple substitution of a domain name | >for the entire domain name submitted". If that's what you mean. | | I've tried something a little different on that point. | > | >| * The regexp field is the other field that may be used for rewrite rules. | >| The regexp field is a String containing sed-style substitution expressions. | > | >Expressions in the plural suggests a script with multiple regexps. Not that | >I'd read this carefully when I wrote you earlier today. | | now is "a sed-style regular expression". | | >| These are applied to the original URN and yield the next domain name | >| to be queried. | > | >So that the server could supply (as a terminal NAPTR?) regexps that extracted | >info from the opaque part of the URN, if it knows they would work right | with all | >opaque parts of all its URNs. But this is not what you want for | size/performance | >reasons. | > | >Now suppose I can redirect all NAPTR inquiries to my name space with a | >script of 64 lines (64 regexps). Will it actually be more efficient | >to return 64 NAPTR records or one long one? Or does it come to the | >same thing? (I dunno, just a thought; you guys are the architects.) | > | >| The first step in the resolution process is to find out about the DUNS | >| namespace. The namespace identifier, duns, is extracted from the URN, | >| prepended to urn.net, and the NAPTRs for duns.urn.net looked up. It might | > | >For us know-nothings, you might say where this first query goes. As a child, | >I thought that Station Identification was some central studio that individual | >stations invoked from time to time. But there isn't any place called urn.net, | >right? Where is duns.urn.net? | > | | No action on any of the preceding points. | | >| Since our example RR specified the "s" flag, it was terminal. Our | >| next action is to lookup SRV RRs for _rcds._udp.isi.dandb.com, which | > | >You need to say "as we can't use dunslink, our next action ..." ? | | Got it. | | > | >| conjunction with a long TTL for *.urn.net records, the average number | >| of probes to DNS for resolving DUNS URNs would approach one. | > | >| ;; order pref flags service replacement regexp | >| cid.urn.net IN NAPTR 100 10 "" "" . "/.+@([^@]+)/\1/i" | > | >I tried that regexp with sed: | > | >% sed 's/.+@([^@]+)/\1/i' < foo | >sed: ``\digit'' out of range: s/.+@([^@]+)/\1/i | > | >but: | > | >% sed 's/.*@\([^@]*\)/\1/' < foo | >mordred.gatech.edu | > | >where foo is urn:cid:199606121851.1@mordred.gatech.edu | > | >My sed(1), under Sun OS 5.4 and 4.1 (where it's sed (1v)) | >doesn't have an /i anyway, useful though that would be. | | Added additional caveats about '(', '*', etc. But point about | your sed not having /i is still valid. Please raise it and we | can see if anyone on the list has the POSIX standard handy. | | > | >| The flags field tells us that this is the last NAPTR patterns we | >| should see, and after the rewrite (a simple replacement in this case) we | >| should look up SRV records to get information on the hosts | >| that can provide the necessary service. | > | >If that fails, what do I do, ask for NAPTR records from the same | >places I asked for SRV records? | > | | No action. | | >| Flags | >| A String giving flags to control aspects of the rewriting. Flags | >| are single characters from the alphabet [A-Z0-9]. The case of | > | >"are single alphanumeric characters" | > | | You might suggest "from the set of characters [A-Z0-9]". | | >| the alphabetic characters is not significant. | >| | >| At this time only two flags, "S" and "A", are defined. "S" means | >| that the next lookup should be for SRV records instead of NAPTR | >| records. "A" means that the next lookup should be for A records. | >| The S and A flags are mutually exclusive, and resolution libraries | >| SHOULD signal and error so that bad NAPTRs can be quickly detected. | > | >"signal an error to the server"? does the client care? | > | >| shells, there is a good chance that when you think you are saying "\\" you | >| are actually saying "\". | > | >And you may need to say \\\ or \\\\ to get things through your shell. | | Here is where the additional caveats on '('et. al went. | > | >| The "a" flag allows the next lookup to be for A records rather than | >| SRV records. Since there is no place for a port specification in the | >| NAPTR record, when the "A" flag is used the specified protocol must | >| be running on its default port. | > | >That seems suboptimal. Why not make a place for it? (Any good | >reason will suffice.) | > | >| Once a NAPTR has "matched" a URN, the client MUST NOT consider | >| any NAPTRs with a higer value of order than that of the matching NAPTR, | > | >typo. And NAPTRs don't match URNs but rather domain names (right?). | | Got the typo. | | >| (A match is defined as: | >| 1) The NAPTR provides a replacement domain name | >| 2) The regular expression matches the URN | >| ) | > | >"The result of applying the regular expression matches the URN." | | Ugh. And I disagree with you on "match" as I said earlier. I still | think I am right on this, but we can let the list judge. | | > | >| - If a record at a particular order matches the URI, but the client | >| doesn't know the specified protocol and service, the client should | >| continue to examine records that have the same order. The client | >| MUST NOT consider records with a higher value of order. This is | >| necesary to make delegation of portions of the namespace work. | > | >typo. | | Got "necessary". | | > And, this rationale could well be inserted above, at "Once a NAPTR". | >Client writers will do what they want so long as | >they don't feel the need to claim conformance, so supplying the | >rationale is a good way to persuade them to do it right. Hey, | >it worked with Netscape, right? | | I added a bit to "Once a NAPTR...". | > | >| - When multiple RRs have the same "order", the client should use | >| the value of the preference field to select the next NAPTR to | >| consider. However, because of preferred protocols or services, | >| estimates of network distance and bandwidth, etc. clients | >| may use different criteria to sort the records. | > | >That's unclear. What does "sort" mean here? It's the first time | >in the document that the word appears in text, rather than code. | | Changed "sort" to "select the next record to process". | | >| - If the lookup after a rewrite fails, clients are strongly encouraged | >| to report a failure, rather than backing up to pursue other rewrite | >| paths. | > | >Answer to my earlier question; might say this earlier. | | Not real clear on this comment. | | > | > | >Regards, | > | >-- | > Terry Allen O'Reilly & Associates, Inc. terry@ora.com | > "In going on with these experiments, how many pretty systems do we build, | > which we soon find ourselves obliged to destroy?" - Benjamin Franklin | > A Davenport Group sponsor http://www.ora.com/davenport/ | > | > | Ron Daniel Jr. email: rdaniel@lanl.gov | Advanced Computing Lab voice: +1 505 665 0597 | MS B287 fax: +1 505 665 4939 | Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ | Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" | | Regards, -- Terry Allen O'Reilly & Associates, Inc. terry@ora.com "In going on with these experiments, how many pretty systems do we build, which we soon find ourselves obliged to destroy?" - Benjamin Franklin A Davenport Group sponsor http://www.ora.com/davenport/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA28999 for urn-ietf-out; Tue, 20 Aug 1996 14:46:37 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA28994 for ; Tue, 20 Aug 1996 14:46:34 -0400 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17627 (mail destined for urn-ietf@services.bunyip.com); Tue, 20 Aug 96 14:46:32 -0400 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa22462; 20 Aug 96 14:46 EDT Received: by skadhwe.lcs.mit.edu; (5.65/1.1.8.2/15Aug95-0306PM) id AA06713; Tue, 20 Aug 1996 14:46:04 -0400 Date: Tue, 20 Aug 1996 14:46:04 -0400 Message-Id: <9608201846.AA06713@skadhwe.lcs.mit.edu> From: Lewis Girod To: terry@ora.com Cc: urn-ietf@bunyip.com In-Reply-To: <199608191522.IAA13231@rock.west.ora.com> (message from Terry Allen on Mon, 19 Aug 1996 08:22:26 PDT) Subject: Re: [URN] re URN rewriting Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: "owner-urn-ietf@bunyip.com Terry Allen" wrote: And these requirements: | ---------------------------------------- | Namespace Identifier Requirements and | Administration | ---------------------------------------- | Some set of criteria must be established to govern what can and cannot | be used as a (top-level) namespace (NID assignment). This can include: | . demonstration of an established namespace management system | (including an overview of mechanisms for preventing the | duplication/reassignation of name identifiers. These mechanisms | are particular to the individual namespaces). | . multi-organization participation in the naming system | . rules on how names are assigned, name assignment authority | delegation | . provision of escape clause are, I believe, out of scope. The point is to find ways to resolve those naming schemes that humanity creates. It is up to the name space owner to provide resolution, and not up to the top-level registry to limit how that resolution may be provided. OK, that makes three disparate interpretations of these requirements... perhaps a clarification by the authors is in order? - Lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA29143 for urn-ietf-out; Mon, 19 Aug 1996 11:22:23 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA29136 for ; Mon, 19 Aug 1996 11:22:21 -0400 Received: from rock.west.ora.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA05394 (mail destined for urn-ietf@services.bunyip.com); Mon, 19 Aug 96 11:22:16 -0400 Received: (from terry@localhost) by rock.west.ora.com (8.6.13/8.6.11) id IAA13231 for urn-ietf@bunyip.com; Mon, 19 Aug 1996 08:22:26 -0700 Message-Id: <199608191522.IAA13231@rock.west.ora.com> From: Terry Allen Date: Mon, 19 Aug 1996 08:22:26 PDT X-Mailer: Mail User's Shell (7.2.0 10/31/90) To: urn-ietf@bunyip.com Subject: [URN] re URN rewriting Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Lewis wrote: | There is some suggestion in the framework document that there be a set | of requirements of new name schemes; any ``enforcement'' is limited to | that sort of thing. We have not yet figured out what requirements are | to be applied, but clearly names will need to be verified somewhere to | ensure that they are satisying them -- otherwise there might as well | be no requirements. So the question becomes, what requirements do we | want to set? One possible requirement for NAPTR classic might be that | the syntax be defined and checked. What I am suggesting boils down to | specifying the hierarchy scheme and ensuring that the NAPTR system | escape names to alternate systems as soon as the hierarchy spec is | invalidated. This seems to limit unnecessarily what the NAPTR system can be made to do, and thus is not an attractive alternative to regexps. And these requirements: | ---------------------------------------- | Namespace Identifier Requirements and | Administration | ---------------------------------------- | Some set of criteria must be established to govern what can and cannot | be used as a (top-level) namespace (NID assignment). This can include: | . demonstration of an established namespace management system | (including an overview of mechanisms for preventing the | duplication/reassignation of name identifiers. These mechanisms | are particular to the individual namespaces). | . multi-organization participation in the naming system | . rules on how names are assigned, name assignment authority | delegation | . provision of escape clause are, I believe, out of scope. The point is to find ways to resolve those naming schemes that humanity creates. It is up to the name space owner to provide resolution, and not up to the top-level registry to limit how that resolution may be provided. Were the top-level registry to decline to include a naming scheme, people who want to resolve URNs employing that naming scheme would have to find alternative methods, and "top-level" would cease to be the top level. | For example, consider the third point; I interpret this as requiring a | specification of the ways in which collections can be delegated within | the syntax of the URNs. The only way I can see to make this work is | to somehow embed the rules of delegation into the URN syntax so that | they can be verified syntactically. Your requirements might be made into a document that recommends ways to construct naming schemes that are easy to resolve by methods presently in use or contemplated, but to the extent that your alternative to regexps is intended to exclude schemes that don't meet these or other criteria from ever being used, it's not useful. Two further points: - it's unwise to overload the syntax of URNs, period. - delegation and all other matters of URN management policy will be decided in the real world (lawyers included), rather than by anyone now aware of this discussion. Ergo, there is no need to, and it is not a good idea to, attempt to enforce policy within the framework of URN resolution. I agree with Ron's remark: | I am opposed to any proposal which allows only the hierarchy set forth | by the namespace designer. Lots of namespaces will be of the | form . The | string is not opaque if the namespace designer can tell the naming | authorities what to do. I am not opposed to a modification of your | proposal that essentially says "once you get to the opaque string, | the rules of hierarchy may change, and naming authorities are free to | give you a new set of rules by which you can follow the new hierarchy". which is in accord with what the real world will do. Regards, -- Terry Allen O'Reilly & Associates, Inc. terry@ora.com "In going on with these experiments, how many pretty systems do we build, which we soon find ourselves obliged to destroy?" - Benjamin Franklin A Davenport Group sponsor http://www.ora.com/davenport/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA11005 for urn-ietf-out; Sun, 18 Aug 1996 23:08:08 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA11000 for ; Sun, 18 Aug 1996 23:08:06 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02710 (mail destined for urn-ietf@services.bunyip.com); Sun, 18 Aug 96 23:08:04 -0400 Received: from legiron.acl.lanl.gov (transitory27.lanl.gov [128.165.7.173]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id VAA04229; Sun, 18 Aug 1996 21:07:59 -0600 (MDT) Message-Id: <2.2.32.19960819031320.006aef7c@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 18 Aug 1996 21:13:20 -0600 To: liberte@ncsa.uiuc.edu (Daniel LaLiberte) From: Ron Daniel Subject: [URN] Re: Iterative lookup Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Daniel LaLiberte (at least at 12:33 AM 8/17/96 CDT) >Thanks for the example, Ron. That makes it abundantly clear. Glad to do it. > > I think it is pretty rare that we will have a namespace that > > has such a mapping to DNS. > >The path scheme requires exactly this kind of iteration and reversal >of names to get DNS names. I didn't say we would *never* have such a namespace. :-) > > [...] I think most namespaces > > will very quickly point the user to a database that handles > > very large chunks of the namespace. > >Depends on what you mean by this. If you mean that after the NAPTR >resolution algorithm is done, the opaque string is handled >internally to a server, then I think this is the wrong approach >because it is unscalable for really large name spaces and large >numbers of users. That is what I mean, and I agree that it has some problems for some really large namespaces. However, some of the namespaces I have been investigating (the Intl. Std. Audiovisual Number in particular) are centrally assigned and they want them centrally resolved. Name spaces like the handle names space will probably also want to stop using NAPTRs very quickly and start talking the handle protocol. (I'm not so sure that there are problems for large numbers of users, we can replicate the resolver because of the SRV record). >It's OK with me that some name spaces work this way, but we should >not require it of all name spaces. I wouldn't dream of making everyone do it. I just think there will be a number of namespaces that are resolved that way. I also think that the more money is at stake, the more centralized the name assignment and resolution will be. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA24576 for urn-ietf-out; Sat, 17 Aug 1996 01:36:59 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA24571 for ; Sat, 17 Aug 1996 01:36:56 -0400 Received: from newton.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28884 (mail destined for urn-ietf@services.bunyip.com); Sat, 17 Aug 96 01:36:54 -0400 Received: from void.ncsa.uiuc.edu (void.ncsa.uiuc.edu [141.142.103.20]) by newton.ncsa.uiuc.edu (8.6.11/8.6.12) with SMTP id AAA14255; Sat, 17 Aug 1996 00:36:53 -0500 Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1) id AA14157; Sat, 17 Aug 96 00:33:18 CDT Date: Sat, 17 Aug 96 00:33:18 CDT From: liberte@ncsa.uiuc.edu (Daniel LaLiberte) Message-Id: <9608170533.AA14157@void.ncsa.uiuc.edu> To: Ron Daniel Cc: urn-ietf@bunyip.com Subject: [URN] Iterative lookup In-Reply-To: <2.2.32.19960816220043.006d34f4@acl.lanl.gov> References: <2.2.32.19960816220043.006d34f4@acl.lanl.gov> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: liberte@ncsa.uiuc.edu (Daniel LaLiberte) Errors-To: owner-urn-ietf@bunyip.com Thanks for the example, Ron. That makes it abundantly clear. Ron Daniel writes: > So, that is one way it could be done. I am not wild about the > number of lookups that are needed, but I like it better than > adding a non-standard flag to regexps. Most of the info will be cached locally if you are resolving a URN that is similar to previous URNs. This is proportional to the computational complexity and network/server load of gethostbyname for every single DNS lookup. So this should not be considered an argument against iteration. Yes, servers and DNS requests are optimized for gethostbyname lookups, but I think the difference is relatively minor. > I think it is pretty rare that we will have a namespace that > has such a mapping to DNS. The path scheme requires exactly this kind of iteration and reversal of names to get DNS names. > [...] I think most namespaces > will very quickly point the user to a database that handles > very large chunks of the namespace. Depends on what you mean by this. If you mean that after the NAPTR resolution algorithm is done, the opaque string is handled internally to a server, then I think this is the wrong approach because it is unscalable for really large name spaces and large numbers of users. The basic problem is that there is no way for clients to know about a subdivision of the name space, should subdivision become necessary in the future, without asking the server for every single name. What the client needs is a rule it can cache and use later to subdivide the space when resolving another name. This means that the previously opaque string is no longer opaque because clients must be responsible for resolving it using the rule. It's OK with me that some name spaces work this way, but we should not require it of all name spaces. dan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA21608 for urn-ietf-out; Fri, 16 Aug 1996 18:54:40 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA21603 for ; Fri, 16 Aug 1996 18:54:38 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27851 (mail destined for urn-ietf@services.bunyip.com); Fri, 16 Aug 96 18:54:35 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id QAA06155; Fri, 16 Aug 1996 16:54:31 -0600 (MDT) Message-Id: <2.2.32.19960816225947.006c6520@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Aug 1996 16:59:47 -0600 To: Lewis Girod From: Ron Daniel Subject: Re: [URN] nasty rewriting rules Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Lewis Girod (at least at 06:12 PM 8/16/96 -0400) >I think the question of what sorts of requirements are desirable has a >significant impact on the likelihood that new name schemes would be >servable by future systems. I had inferred some stronger requirements >than prevention of name reassignment from the framework document: [...] > . rules on how names are assigned, name assignment authority > delegation > (from draft-daigle-urnframework-00.txt) [...] >I interpret this as requiring a >specification of the ways in which collections can be delegated within >the syntax of the URNs. The only way I can see to make this work is >to somehow embed the rules of delegation into the URN syntax so that >they can be verified syntactically. Hmm. That is not how I interpreted it. I was thinking that it would be more of a definition of the business rules that would be followed when one organization 1) Authorized a sub-naming-authority or 2) Sold off some of their assigned names to some other organization. The case of (2) is the most problematic. Publishers sell off particular titles all the time, they also sell off whole blocks of titles (the works of an author, all the titles in one of their business units, ..). So, it seems important to be able to say things like urn:cid:moby-dick@classics.penguin.com is resolvable at foo.bar.com any other title from classics.penguin.com is resolvable at here.there.org and all other penguin titles are resolvable at catalog.penguin.com. Some sites (mine perhaps) might have titles like urn:cid:la-ur-96-0023@lanl.gov (la-ur is Los Alamos Unclassified Report. 96- is the year.) We might want to put the resolver for all reports before 1980 on one machine, all reports after 1980 on another. So, with regexps we can say pref = 10; s/^(urn:)?cid:la-ur-[4-7]*/old.lanl.gov/i pref = 100 new.lanl.gov The point of this example is that we have some hierarchy encoded in our "opaque string". That hierarchy can not be known to the namespace designer. However, being able to switch on it is (I think) important. I am opposed to any proposal which allows only the hierarchy set forth by the namespace designer. Lots of namespaces will be of the form . The string is not opaque if the namespace designer can tell the naming authorities what to do. I am not opposed to a modification of your proposal that essentially says "once you get to the opaque string, the rules of hierarchy may change, and naming authorities are free to give you a new set of rules by which you can follow the new hierarchy". >As I see it, the primary function >of my proposal is that the translation step and the limited nature of >the rules after that enforces a delegation structure based on a >definition at the top level. At the top level the delegation >hierarchy is ordered canonically and fixed; below that it cannot be >processed out of order [...] Right. That's just what I object to I'm afraid. > [...] except by escaping to a separate resolution >mechanism. OK, so what do you mean by this? Is a marker that allows a new program to canonicalize the opaque string OK, or do you just want to say that all opaque strings from a naming authority will remain opaque for all time? >I interpreted point one to imply something concrete in the way of a >``management system''. For example, demonstration of administrative >software that name assignment authorities would be given to maintain >the databases is a requirement I had in mind. Right, I was assuming something different - a legal contract that would say naming authorities would not re-issue names and that they would put the same requirement on any sub-naming authorities they authorized. >Because regexps allow a lot of flexibility downstream it is >hard to make requirements, and thus the potential exists for dowstream >administrators to make messes. Well, I think we have an instance of conservation of nightmares here. Being able to apply the regexp at every stage of the lookup can lead to messes. Not being able to change the rules at the opaque string boundaries leads to a ball-and-chain namespace that can't accomodate the reasonable desires of a lot of users. (The LA-UR example above is real. We have such a report series - actually we have several report series - and most of them put a year into the report number). But this is more than enough for a Friday afternoon. Best regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA21285 for urn-ietf-out; Fri, 16 Aug 1996 18:13:35 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA21280 for ; Fri, 16 Aug 1996 18:13:31 -0400 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27685 (mail destined for urn-ietf@services.bunyip.com); Fri, 16 Aug 96 18:13:24 -0400 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa27372; 16 Aug 96 18:12 EDT Received: by skadhwe.lcs.mit.edu; (5.65/1.1.8.2/15Aug95-0306PM) id AA04505; Fri, 16 Aug 1996 18:12:45 -0400 Date: Fri, 16 Aug 1996 18:12:45 -0400 Message-Id: <9608162212.AA04505@skadhwe.lcs.mit.edu> From: Lewis Girod To: rdaniel@acl.lanl.gov Cc: urn-ietf@bunyip.com In-Reply-To: <2.2.32.19960815142934.006a97b4@acl.lanl.gov> (message from Ron Daniel on Thu, 15 Aug 1996 08:29:34 -0600) Subject: Re: [URN] nasty rewriting rules Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com on Date: Thu, 15 Aug 1996 08:29:34 -0600 Ron Daniel wrote: Thus spoke Lewis Girod (at least at 03:54 PM 8/13/96 -0400): >Fair enough, although it is important to have agreement as to what >flavor of regexps are being used. The original plan was to just >execute sed, which solves both issues on UNIX platforms, but requires >a little more work otherwise. Um, no, that was not the plan. The plan was to use regexp libraries, the syntax of the regexps was "sed-style" rather than "perl-style" because we believe that sed-style is actually the version most regexp libraries support. OK. >There is some suggestion in the framework document that there be a set >of requirements of new name schemes Well, I thought that those requirements were going to be things like no reassigning of naming authorities, making sure that any naming authorities in a naming scheme require any sub-naming authorities to follow rules at lesat as restrictive as the ones they operate under, ... So, these really are requirements on naming schemes and the operations behing them. Such requiremnts can't be tested by validating the syntax of a URN - useful thought that might be. [...] >Humans are supposed to use the simple user-friendly >syntax that compiles into the terse form. With decent management >software the underlying terse form should be transparent to the >administrator -- in fact, if we can assume that everyone is using a >compiler it might be a good idea to make the terse form even more >compact. Those are pretty strong assumptions Lewis. Furthermore, this software also has to decompile the terse form into the friendly form so that people can debug existing records. This sort of friendly software rarely gets written and maintained. I think the question of what sorts of requirements are desirable has a significant impact on the likelihood that new name schemes would be servable by future systems. I had inferred some stronger requirements than prevention of name reassignment from the framework document: ---------------------------------------- Namespace Identifier Requirements and Administration ---------------------------------------- Some set of criteria must be established to govern what can and cannot be used as a (top-level) namespace (NID assignment). This can include: . demonstration of an established namespace management system (including an overview of mechanisms for preventing the duplication/reassignation of name identifiers. These mechanisms are particular to the individual namespaces). . multi-organization participation in the naming system . rules on how names are assigned, name assignment authority delegation . provision of escape clause (from draft-daigle-urnframework-00.txt) For example, consider the third point; I interpret this as requiring a specification of the ways in which collections can be delegated within the syntax of the URNs. The only way I can see to make this work is to somehow embed the rules of delegation into the URN syntax so that they can be verified syntactically. As I see it, the primary function of my proposal is that the translation step and the limited nature of the rules after that enforces a delegation structure based on a definition at the top level. At the top level the delegation hierarchy is ordered canonically and fixed; below that it cannot be processed out of order except by escaping to a separate resolution mechanism. An interesting property of my proposal is that there are no real syntactic requirements beyond those needed to re-order the URN. As you point out, this particular effect cannot be obtained using the regexp rules, even with an initial syntactic check at the beginning. I interpreted point one to imply something concrete in the way of a ``management system''. For example, demonstration of administrative software that name assignment authorities would be given to maintain the databases is a requirement I had in mind. That was why I was assuming that people would have a rule compiler (although it really is not that hard to implement!). A decompiler would be nice for emergencies, but I was thinking that the rules would be kept in and installed from the source format, so to debug things you would go back to the source file. Perhaps my interpretations are outside of the sense of the requirements, or perhaps the requirements simply haven't been specified clearly... in any case, I think we need to make sure that the requirements that we do want are at least partially enforced in a technical way by the system. (We may need to figure out what they are first?) Because regexps allow a lot of flexibility downstream it is hard to make requirements, and thus the potential exists for dowstream administrators to make messes. -lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA21158 for urn-ietf-out; Fri, 16 Aug 1996 17:55:35 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA21153 for ; Fri, 16 Aug 1996 17:55:33 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27505 (mail destined for urn-ietf@services.bunyip.com); Fri, 16 Aug 96 17:55:31 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id PAA27469; Fri, 16 Aug 1996 15:55:28 -0600 (MDT) Message-Id: <2.2.32.19960816220043.006d34f4@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Aug 1996 16:00:43 -0600 To: liberte@ncsa.uiuc.edu (Daniel LaLiberte) From: Ron Daniel Subject: Re: [URN] revision of NAPTR draft Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Daniel LaLiberte (at least at 03:26 PM 8/16/96 CDT) [Stuff on inability of regexps to revese order of components in an arbitrary length list deleted] >In previous discussion with Ron, he suggested that it might be >possible to use the resolution algorithm, as is but iteratively, to >bite off a component at a time and construct the reversed DNS name. >This sounds similar to what we recommend for the path scheme >resolution in the first place, so I would be happy to go with it - it >wouldnt require a list reversal extension. But I don't see how it can >be done. Could you give an example of how this works? Sure. Lets look at a semi-hypothetical name like janet:uk.ac.cam.eng:techrep-96-23 First, we extract the namespace identifier, janet, and lookup(NAPTR, janet.urn.net) => a regexp like "s/(urn:)?janet:(.[^\.])*\.*/\2/i" which matches everything after "janet:" but before the next "." Now we lookup(NAPTR, "uk") => a regexp like "s/(urn:)?janet:uk\.(.[\.])*\..*/\2.uk/" which matches everything after "janet.uk." but before the next ".". Now we lookup(NAPTR, "uk.ac") => a regexp like "s/(urn:)?janet:uk\.ac\.(.[^\.])*\..*/\2.ac.uk/" lookup(NAPTR, cam.ac.uk) => "s/(urn:)?janet:uk\.ac\.cam\.(.[^\.])*\..*/\2.cam.ac.uk/" lookup(NAPTR, eng.cam.ac.uk) => terminal naptr telling us to fetch the SRV record for something like _ftp._tcp.eng.cam.ac.uk, with the SRV and A records included as additional info. We pick one of those servers and ask it about techrep-96-23. So, that is one way it could be done. I am not wild about the number of lookups that are needed, but I like it better than adding a non-standard flag to regexps. I think it is pretty rare that we will have a namespace that has such a mapping to DNS. For instance, an OID namespace has its most significant components at the front of the name. However, there is no good way to map 1.3.6.1.4.1.2 to ibm.com and map 1.3.6.1.4.1.13 to utk.edu. I think most namespaces will very quickly point the user to a database that handles very large chunks of the namespace. This is certainly how names from schemes such as ISAN - Intl. Standard Audio-visual Number - would work. Handles are a namespace that comes close to this, but the mapping between handle naming authorities and domain names is far from exact, and we are likely to get instantly directed to G or to a local handle server whenever we encounter a name in the hdl: system. Well, that's enough for a Friday afternoon. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA20312 for urn-ietf-out; Fri, 16 Aug 1996 16:30:45 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA20307 for ; Fri, 16 Aug 1996 16:30:40 -0400 Received: from newton.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26851 (mail destined for urn-ietf@services.bunyip.com); Fri, 16 Aug 96 16:30:31 -0400 Received: from void.ncsa.uiuc.edu (void.ncsa.uiuc.edu [141.142.103.20]) by newton.ncsa.uiuc.edu (8.6.11/8.6.12) with SMTP id PAA23561; Fri, 16 Aug 1996 15:30:17 -0500 Received: by void.ncsa.uiuc.edu (4.1/NCSA-4.1) id AA07371; Fri, 16 Aug 96 15:26:41 CDT Date: Fri, 16 Aug 96 15:26:41 CDT From: liberte@ncsa.uiuc.edu (Daniel LaLiberte) Message-Id: <9608162026.AA07371@void.ncsa.uiuc.edu> To: Ron Daniel Cc: urn-ietf@bunyip.com Subject: [URN] revision of NAPTR draft In-Reply-To: <2.2.32.19960816195456.0069a130@acl.lanl.gov> References: <2.2.32.19960816195456.0069a130@acl.lanl.gov> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: liberte@ncsa.uiuc.edu (Daniel LaLiberte) Errors-To: owner-urn-ietf@bunyip.com Ron Daniel writes: > This draft does not incorporate Lewis Girod's suggested replacement > for regexps. I would like to see some more discussion on the list > of that topic. I don't have much to say about Lewis Girod's suggestion - I rather like regular expressions and don't think they will be a problem for what the do offer. However, I am concerned because of features I know regular expression lack. In particular, there is a need to be able to reverse a list of component names in the construction of a DNS name, because DNS uses one order for components (i.e. most specific component to most general, e.g. small.big.bigger.biggest.) whereas some names systems might order components in the other order (e.g. the path scheme). Regular expressions do not support the idea of reversing an arbitrary number of elements. One way around this obstacle is to add some features beyond (or outside of) normal regular expression. Three things are needed here. A way to specify the components of the list, a way to specify that the list should be reversed, and a way to concatenate the elements of the list with the "." separator. The list of elements might be specified by parentheses. E.g. #(/([^/])*)*# matches a path such as /a/b/c with the inner parentheses matching each of the components. To reverse the list, an "r" might be appended to the regular expression. The replacement might assume that the constructed DNS name takes the elements of the list, with the option of reversing them, and joins with the "." separator. There are some problems with this scheme that I'll let others point out - maybe they have solutions too. In previous discussion with Ron, he suggested that it might be possible to use the resolution algorithm, as is but iteratively, to bite off a component at a time and construct the reversed DNS name. This sounds similar to what we recommend for the path scheme resolution in the first place, so I would be happy to go with it - it wouldnt require a list reversal extension. But I don't see how it can be done. Could you give an example of how this works? -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA19801 for urn-ietf-out; Fri, 16 Aug 1996 15:49:53 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA19789 for ; Fri, 16 Aug 1996 15:49:45 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26560 (mail destined for urn-ietf@services.bunyip.com); Fri, 16 Aug 96 15:49:35 -0400 Received: from magenta.acl.lanl.gov (magenta.acl.lanl.gov [128.165.147.153]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id NAA22099 for ; Fri, 16 Aug 1996 13:49:34 -0600 (MDT) From: "Ronald E. Daniel" Received: (rdaniel@localhost) by magenta.acl.lanl.gov (8.6.9/8.6.4) id NAA07281 for urn-ietf@bunyip.com; Fri, 16 Aug 1996 13:49:33 -0600 Date: Fri, 16 Aug 1996 13:49:33 -0600 Message-Id: <199608161949.NAA07281@magenta.acl.lanl.gov> To: urn-ietf@bunyip.com Subject: [URN] revision 1 of the NAPTR draft Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ronald E. Daniel" Errors-To: owner-urn-ietf@bunyip.com INTERNET DRAFT Ron Daniel draft-daniel-naptr-01.txt Los Alamos National Laboratory Michael Mealling Georgia Institute of Technology 16 Aug, 1996 Resolution of Uniform Resource Identifiers using the Domain Name System Status of this Memo =================== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft expires 16 Feb., 1997. Abstract: ========= Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a replacement for URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. In addition to locating resolvers, the NAPTR provides for other naming systems to be grandfathered into the URN world, provides independence between the name assignment system and the resolution protocol system, and allows multiple services (Name to Location, Name to Description, Name to Resource, ...) to be offered. In conjunction with the SRV RR proposal [3], the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing. Introduction: ============= Uniform Resource Locators have been a significant advance in locating resources on the Internet. However, their brittle nature over time has been recognized for several years. The Uniform Resource Identifer working group proposed the development of Uniform Resource Names to serve as persistent, location-independent identifiers for Internet resources in order to overcome most of the problems with URLs. RFC-1737 [1] sets forth requirements on URNs. Even if URN systems were in place now, there would still be a tremendous number of URLs. It should be possible to develop a URN resolution system that can also provide location independance for those URLs. This is related to the requirement in [1] to be able to grandfather in names from other naming systems, such as ISO Formal Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, etc. The developers of various URN proposals have held a series of meetings, resulting in a compromise known as the Knoxville framework. The major principle behind the Knoxville framework is that any name assignment hierarchy should be seperate from the resolution hierarchy. This is in marked contrast to the Domain Name System, where the two are identical. Readers are referred to [2] for background on the Knoxville framework for additional information on the context and purpose of this proposal. For the reasons mentioned earlier, we want to be able to resolve URNs and URLs within the same framework. 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, we have the requirement mentioned above about grandfathering of other name systems. Therefore our approach is to use DNS to locate "resolvers" that can provide information on individual resources, potentially including the resource itself. To accomplish this, we "rewrite" the URI into a domain name following the rules provided in NAPTR records. Rewrite rules provide considerable power, which is important when trying to seperate the name assignment and resolution procedures. However, collections of rules can become difficult to understand. To lessen this problem, the NAPTR rules are *always* applied to the original URI, *never* to the output of previous rules. Locating a resolver through the rewrite procedure may take multiple steps, but the beginning is always the same. Every URI has a colon-delimited prefix. NAPTR resolution begins by taking this prefix, appending the well-known suffix ".urn.net", and querying DNS for NAPTR records at that domain name. Based on the results of this query, zero or more additional DNS queries may be needed to locate resolvers for the URI. Three brief examples of this procedure are given in the next section. The NAPTR RR provides the level of indirection needed to keep the naming system independent of the resolution system, its protocols, and services. Coupled with the new SRV resource record proposal[3] there is also the potential for replicating the resolver on multiple hosts, overcoming some of the most significant problems of URLs. This is an important and subtle point. Not only do the NAPTR and SRV records allow us to replicate the resource, we can replicate the resolvers that know about the replicated resource. Preventing a single point of failure at the resolver level is a significant benefit. Terminology =========== "Must" or "Shall" - Software that does not behave in the mannar that this document says it must is not conformant to this document. "Should" - Software that does not follow the behavior that this document says it should may still be conformant, but is probably broken in some fundamental way. "May" - Implementations may or may not provide the described behavior, while still remaining conformant to this document. Brief overview and examples of the NAPTR RR: ============================================ A detailed description of the NAPTR RR will be given later, but to give a flavor for the proposal we first give a simple description of the record and three examples of its use. The key fields in the NAPTR RR are order, preference, service, flags, replacement, and regexp: * The order field specifies the order in which records MUST be processed when multiple NAPTR records are returned in response to a single query. A naming authority may have delegated a portion of its namespace to another agency. Evaluating the NAPTR recors in the correct order is necessary for delegation to work properly. * The preference field specifies the order in which records SHOULD be processed when multiple NAPTR records have the same value of "order". This field lets a service provider specify the order in which resolvers are contacted, so that more capable machines are contacted in preference to less capable ones. * The service field specifies the resolution protocol and resolution service(s) that will be available if the rewrite specified by the regexp or replacement fields is applied. Resolution protocols are the protocols used to talk with a resolver, and will be specified in other documents. Resolution services are operations such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC), etc. These are discussed in the URN Framework document[2], and their behavior in a particular resolution protocol will be given in the specification for that protocol. * The flags field contains modifiers that affect what happens in the next DNS lookup, typically for optimizing the process. * The replacement field is one of two fields used for the rewrite rules. If the rewrite is a simple substitution of a domain name, that name is given in the replacement field. The replacement field is a domain name (subject to compression if a DNS sender knows that a given recipient is able to decompress names in this RR type's RDATA field). If the rewrite is more complex than a simple substitution of a domain name, the replacement field should be set to . and the regexp field used. * The regexp field is the other field that may be used for rewrite rules. The regexp field is a String containing sed-style substitution expressions. These are applied to the original URN and yield the next domain name to be queried. Note that the client applies all the substitutions and performs all lookups - this is not handled in DNS servers. Note also that there is no reason to provide values in both the replacement and regexp field. Only one should be specified. If a value is specified in both, the replacement name MUST be used and the regexp string MUST be ignored. It is the belief of the developers of this document that regexps should rarely be used. The replacement field seems adequate for the vast majority of situations. Example 1 --------- Consider a URN that uses the DUNS namespace. DUNS numbers are identifiers for approximately 30 million registered businesses around the world, assigned and maintained by Dunn and Bradstreet. The URN might look like: urn:duns:002372413:annual-report-1997 The first step in the resolution process is to find out about the DUNS namespace. The namespace identifier, duns, is extracted from the URN, prepended to urn.net, and the NAPTRs for duns.urn.net looked up. It might return records of the form: duns.urn.net ;; order pref flags service replacement regexp IN NAPTR 100 10 "s" "dunslink+N2L+N2C" _dunslink._udp.isi.dandb.com "" IN NAPTR 100 20 "s" "rcds+N2C" _rcds._udp.isi.dandb.com "" IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" _http._tcp.isi.dandb.com "" The order field contains equal values, indicating that no name delegation order has to be followed. The preference field indicates that the provider would like clients to use the special dunslink protocol, followed by the RCDS protocol, and that HTTP is offered as a last resort. All the records specify the "s" flag, which will be explained momentarily. The service fields say that if we speak dunslink, we will be able to issue either the N2L or N2C requests to obtain a URL or a URC (description) of the resource. The Resource Cataloging and Distribution Service (RCDS) could be used to get a URC for the resource, while HTTP could be used to get a URL, URC, or the resource itself. All the records supply the next domain name to query, none of them need to be rewritten with the aid of regular expressions. The general case might require multiple NAPTR rewrites to locate a resolver, but eventually we will come to the "terminal NAPTR". Once we have the terminal NAPTR, our next probe into the DNS will be for a SRV or A record instead of another NAPTR. Rather than probing for a non-existant NAPTR record to terminate the loop, the flags field is used to indicate a terminal lookup. If it has a value of "s", the next lookup should be for SRV RRs, "a" denotes that A records should sought. Since our example RR specified the "s" flag, it was terminal. Our next action is to lookup SRV RRs for _rcds._udp.isi.dandb.com, which will tell us hosts that can provide the necessary resolution service. That lookup might return: ;; Pref Weight Port Target rcds._udp.isi.dandb.com IN SRV 0 0 1000 defduns.isi.dandb.com IN SRV 0 0 1000 dbmirror.com.au IN SRV 0 0 1000 ukmirror.com.uk telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their RCDS server. (The reader is referred to the SRV proposal [3] for the interpretation of the fields above). Since a domain administrator knows certain NAPTRs are terminal, (s)he might include the corresponding SRV RRs as additional info. Further, the SRV RRs could include A records as additional info. While this recursive provision of additional information is not explicitly blessed in the DNS specifications, it is not forbidden, and BIND does take advantage of it [4]. This is a significant optimization. In conjunction with a long TTL for *.urn.net records, the average number of probes to DNS for resolving DUNS URNs would approach one. Records MUST be processed in the order specified by the order field. This allows administrators to say that "all records matching this pattern go to server1, all others go to server2". Records SHOULD be processed in the order specified in the preference field. However, clients may have a preference for particular protocols and resolution services that causes them to ignore the preference field, so resolver administrators cannot count on the preference field always being respected. Example 2 --------- Consider a URI namespace based on MIME Content-Ids. The URN might look like this: urn:cid:199606121851.1@mordred.gatech.edu The first step in the resolution process is to find out about the CID namespace. The namespace identifier, cid, is extracted from the URN, prepended to urn.net, and the NAPTR for cid.urn.net looked up. It might return records of the form: ;; order pref flags service replacement regexp cid.urn.net IN NAPTR 100 10 "" "" . "/.+@([^@]+)/\1/i" We have only one NAPTR response, so ordering the responses is not a problem. The replacement field is empty, so we check the regexp field and use the pattern provided there. We apply that regexp to the entire URN to see if it matches, which it does. The \1 part of the regexp returns the string "mordred.gatech.edu". Since the flags field is empty, the lookup is not terminal, and our next probe to DNS is for NAPTR records. The result might look something like: *.gatech.edu IN NAPTR ;; order pref flags service replacement regexp IN NAPTR 100 50 "s" "z39.50+N2L+N2C" _z3950._tcp.gatech.edu "" IN NAPTR 100 50 "s" "rcds+N2C" _rcds._udp.gatech.edu "" IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" _http._tcp.gatech.edu "" Note that a wildcard has been used so that the domain administrator at Georgia Tech has only a single NAPTR record to maintain. The values of the order and preference fields are equal in all records, so we are free to pick any record. The flags field tells us that this is the last NAPTR patterns we should see, and after the rewrite (a simple replacement in this case) we should look up SRV records to get information on the hosts that can provide the necessary service. Assuming we prefer the Z39.50 protocol, our lookup might return: ;; Pref Weight Port Target _z3950._tcp.gatech.edu IN SRV 0 0 1000 z3950.gatech.edu IN SRV 0 0 1000 z3950.cc.gatech.edu IN SRV 0 0 1000 z3950.uga.edu telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their Z39.50 server. Users of regular expressions should note that there is a significant caveat about the use of backslashes in DNS zone files. DNS treats backslashes as the escape character so that '.' can be escaped when necessary. This means that when a regular expression is entered into the zone file, the backslashes must be escaped by another backslash. For the case of the cid.urn.net record above, the regular expression entered into the zone file should be "/.+@([^@]+)/\\1/i". When the client code actually recieves the record, the pattern will have been converted to "/.+@([^@]+)/\1/i". Example 3 --------- As mentioned above, the NAPTR RR can also be used for URLs that have already been assigned. Assume we have the URL for a very popular piece of software that the publisher wishes to mirror at multiple sites around the world: http://www.foo.com/software/latest-beta.exe We extract the prefix, "http", and lookup NAPTR records for http.urn.net. This might return a record of the form http.urn.net IN NAPTR ;; order pref flags service replacement regexp 100 90 "" "" . "/.*\/\/([^\/:]+)/\1/i" This expression returns everything after the first double slash and before the next slash or colon. Backslashes are needed to escape the forward slash since the forward slash character is what seperates the components of the substitution pattern. (Recall from the previous example that in the zone file, this pattern actually needs to be entered as "/.*\\/\\/([^\\/:]+)/\\1/i"). Applying this pattern to the URL extracts "www.foo.com". Looking up NAPTR records for that might return: www.foo.com ;; order pref flags service replacement regexp IN NAPTR 100 100 "s" "http+L2R" _http._tcp.foo.com "" IN NAPTR 100 100 "s" "ftp+L2R" _ftp._tcp.foo.com "" Looking up SRV records for _http._tcp.foo.com would return information on the hosts that foo.com has designated to be its mirror sites. The client can then pick one for the user. NAPTR RR Format =============== The format of the NAPTR RR is given below. The DNS type code for NAPTR is 104. Domain TTL Class Order Preference Flags Service Replacement Regexp where: Domain The domain name this resource record refers to. TTL Standard DNS Time To Live field Class Standard DNS meaning Order A 16-bit integer specifying the order in which the NAPTR records MUST be processed to ensure correct delegation of portions of the namespace over time. Low numbers are processed before high numbers, and once a NAPTR is found that "matches" a URN, the client MUST NOT consider any NAPTRs with a higher value for order. Preference A 16-bit integer which specifies the order in which NAPTR records with equal "order" values SHOULD be processed, low numbers being processed before high numbers. This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. Flags A String giving flags to control aspects of the rewriting. Flags are single characters from the alphabet [A-Z0-9]. The case of the alphabetic characters is not significant. At this time only two flags, "S" and "A", are defined. "S" means that the next lookup should be for SRV records instead of NAPTR records. "A" means that the next lookup should be for A records. The S and A flags are mutually exclusive, and resolution libraries SHOULD signal and error so that bad NAPTRs can be quickly detected. The remaining alphabetic flags are reserved. The numeric flags may be used for local experimentation. Service Specifies the resolution service(s) available down this rewrite path. May also specify the particular protocol that is used to talk with a resolver. If a protocol is specified in the service field, the rewrite will almost certainly be terminal, although the flags field MUST still be considered the authoritative source of information on that subject. The service field may take any of the values below (using the Augmented BNF of RFC 822[5]): service_field = [ [protocol] *("+" rs)] protocol = "RCDS" / "HTTP" rs = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C" / "L2R" / "L2C" i.e. an optional protocol specification followed by 0 or more resolution services. Each resolution service is indicated by an initial '+' character. Note that the empty string is also a valid service field. This will typically be seen at the top levels of a namespace, when it is impossible to know what services and protocols will be offered by a particular publisher within that name space. At this time the known protocols are RCDS (a binary, UDP-based protocol) and HTTP (a textual, TCP-based protocol). More will be allowed later. At this time the allowed service requests are: N2L - Given a URN, return a URL N2Ls - Given a URN, return a set of URLs N2R - Given a URN, return an instance of the resource. N2Rs - Given a URN, return multiple instances of the resouce, typically encoded using multipart/alternative. N2C - Given a URN, return a collection of meta-information on the named resource. The format of this response is the subject of another document. L2R - Given a URL, return the resource. L2C - Given a URL, return a description of the resource. The actual format of the service request and response will be determined by the resolution protocol, and is the subject for other documents. Replacement The next NAME to query for NAPTR, SRV, or A records depending on the value of the flags field. Regexp A STRING containing a sed(1)-style substitution expression that is applied to the original URI in order to construct the next name to lookup. For example: "/^.*inet:([^:]+):*/\\1/i" Regular expression replacement. The URN will be searched from the beginning for the pattern "inet:". All characters after that colon, up to but not including the next colon, will form the next domain name to be looked up. The /i flag says that the match will be case-insensitive, so IneT, Inet, INET, ... would all be matched. The new search key would also be normalized to lower case. Advice to domain administrators: ================================ Beware of regular expressions. Not only are they a pain to get correct on their own, but there is the previously mentioned interaction with DNS. Any backslashes in a regexp must be entered twice in a zone file in order to appear once in a query response. More seriously, the need for double backslashes has probably not been tested by all implementors of DNS servers. We anticipate that urn.net will be the heaviest user of regexps. Only when delegating portions of namespaces should the typical domain administrator need to use regexps. On a related note, beware of interactions with the shell when manipulating regexps from the command line. Since '\' is a common escape character in shells, there is a good chance that when you think you are saying "\\" you are actually saying "\". Administrators are strongly encouraged to provide SRV records or A records as additional information in terminal NAPTR records. The "a" flag allows the next lookup to be for A records rather than SRV records. Since there is no place for a port specification in the NAPTR record, when the "A" flag is used the specified protocol must be running on its default port. Usage ===== Pseudocode for a client routine using NAPTRs is given below: // // findResolver(URN) // Given a URN, find a host that can resolve it. // findResolver(string URN) { sprintf(key, "%s.urn.net", extractNS(URN)); // prepend prefix to urn.net do { rewrite_flag = false; terminal = false; if (key has been seen) { quit with a loop detected error } add key to list of "seens" records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key' sort NAPTR records by "order" field and "preference" field. n_naptrs = number of NAPTR records in response. curr_order = records[j].order; max_order = records[n_naptrs-1].order; // Process current batch of NAPTRs according to "order" field. for (j=0; j < n_naptrs && records[j].order <= max_order; j++) { newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp); if (!newkey) // Skip to next record if the rewrite didn't match continue; // We did do a rewrite, shrink max_order to current value // so that delegation works properly max_order = naptr[j].order; // Will we know what to do with the protocol and services // specified in the NAPTR? If not, try next record. if(!isKnownProto(naptr[j].services)) { continue; } if(!isKnownService(naptr[j].services)) { continue; } // At this point we have a sucessful rewrite and we will know // how to speak the protocol and request a known resolution // service. Before we do the next lookup, check some // optimization possibilities. if (strcasecmp(flags, "S") || strcasecmp(flags, "A")) { terminal = true; services = naptr[j].services; addnl = any SRV and/or A records returned as additional info for naptr[j]. } key = newkey; rewriteflag = true; break; } } while (rewriteflag && !terminal); if (!addnl) { // No SRVs came in as additional info, look them up srvs = lookup(type=SRV, key); } sort SRV records by preference, weight, ... foreach (SRV record) { // in order of preference try contacting srv[j].target using the protocol and one of the resolution service requests from the "services" field of the last NAPTR record. if (successful) return (target, protocol, service); // Actually we would probably return a result, but this // code was supposed to just tell us a good host to talk to. } die with an "unable to find a host" error; } Notes: ====== - The "urn:" prefix is a matter of religious controversy. Client code should handle the cases when it is and is not present. Similarly, if regular expressions are used in NAPTR records, they should be immune to the presence or absence of "urn:". - A client MUST examine all the RRs in a reply, not just the first. The client MUST process them according to the value of the order field. Once a NAPTR has "matched" a URN, the client MUST NOT consider any NAPTRs with a higer value of order than that of the matching NAPTR, even if it does not know the protocols necessary to talk with the matching resolver. (A match is defined as: 1) The NAPTR provides a replacement domain name 2) The regular expression matches the URN ) - If a record at a particular order matches the URI, but the client doesn't know the specified protocol and service, the client should continue to examine records that have the same order. The client MUST NOT consider records with a higher value of order. This is necesary to make delegation of portions of the namespace work. - When multiple RRs have the same "order", the client should use the value of the preference field to select the next NAPTR to consider. However, because of preferred protocols or services, estimates of network distance and bandwidth, etc. clients may use different criteria to sort the records. - If the lookup after a rewrite fails, clients are strongly encouraged to report a failure, rather than backing up to pursue other rewrite paths. - Note that SRV RRs impose additional requirements on clients. Acknowledgements: ================= The authors would like to thank Keith Moore for all his consultations during the development of this draft. We would also like to thank Paul Vixie for his assistance in debugging our implementation, and his answers on our questions. References: =========== [1] RFC-1737 "Functional Requirements for Uniform Resource Names", Karen Sollins and Larry Masinter, Dec. 1994. [2] draft-daigle-urn-framework-00.txt "A Uniform Resource Naming Framework", Leslie Daigle and Patrik Faltstrom, June, 1996. [3] draft-gulbrandsen-dns-rr-srvcs-03.txt " A DNS RR for specifying the location of services (DNS SRV)", Arnt Gulbrandsen and Paul Vixie, March 1996. [4] Paul Vixie, personal communication. [5] RFC-822 "Standard for the Format of ARPA Internet Text Messages", Dave H. Crocker, August 1982. [6] Keith Moore, personal communication. Security Considerations ======================= The use of "urn.net" as the registry for URN namespaces is subject to denial of service attacks, as well as other DNS spoofing attacks. The interactions with DNSSEC are currently being studied. It is expected that NAPTR records will be signed with SIG records once the DNSSEC work is deployed. The rewrite rules make identifiers from other namespaces subject to the same attacks as normal domain names. Since they have not been easily resolvable before, this may or may not be considered a problem. Author Contact Information: =========================== Ron Daniel Los Alamos National Laboratory MS B287 Los Alamos, NM, USA, 87545 voice: +1 505 665 0597 fax: +1 505 665 4939 email: rdaniel@lanl.gov Michael Mealling Office of Information Technology, Network Services Georgia Institute of Technology Atlanta, GA, USA 30332-0730 voice: (404) 894-1712 fax: (404) 894 9548 michael.mealling@oit.gatech.edu This draft expires 16 Feb., 1997. Ron Daniel Jr. email: rdaniel@acl.lanl.gov 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 slogan: "Dump Navigator Now!" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA19800 for urn-ietf-out; Fri, 16 Aug 1996 15:49:52 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA19791 for ; Fri, 16 Aug 1996 15:49:47 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26569 (mail destined for urn-ietf@services.bunyip.com); Fri, 16 Aug 96 15:49:43 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id NAA22103 for ; Fri, 16 Aug 1996 13:49:41 -0600 (MDT) Message-Id: <2.2.32.19960816195456.0069a130@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 16 Aug 1996 13:54:56 -0600 To: urn-ietf@bunyip.com From: Ron Daniel Subject: [URN] revision of NAPTR draft Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Hi all, The next message from me will be the text of the revised NAPTR draft. The major changes are: 1) The pattern field has been split into two fields - replacement and regexp. If one particular domain name is to be the output of a rewrite, it is given in the replacement field. This allows domain name compression to be used. The change was made at the request of Paul Vixie. 2) The preference field has been split into "order" and "preference" fields. I was afraid that domain administrators would abuse the original preference field to state preferred resolvers, rather than follow the spec which stated that it should be used for evaluating NAPTRs in the correct order for name delegation to work. (The choice of names was probably not a big help either :-) Since there was no other way for resolver administrators to say "please contact this service if you can, only use this other one if you must" the change seems justified. This draft does not incorporate Lewis Girod's suggested replacement for regexps. I would like to see some more discussion on the list of that topic. Next week I will submit the revised draft to the Internet-drafts editor, but wanted to give people on this list some advance notice. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA14133 for urn-ietf-out; Thu, 15 Aug 1996 14:08:55 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA14119 for ; Thu, 15 Aug 1996 14:08:52 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13782 (mail destined for urn-ietf@services.bunyip.com); Thu, 15 Aug 96 14:08:50 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA07874; Thu, 15 Aug 1996 12:08:41 -0600 (MDT) Message-Id: <2.2.32.19960815181355.006a3774@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Aug 1996 12:13:55 -0600 To: Jon Knight From: Ron Daniel Subject: Re: [URN] nasty rewriting rules Cc: Harald.T.Alvestrand@uninett.no, urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Jon Knight (at least at 05:04 PM 8/15/96 +0100) >On Thu, 15 Aug 1996, Ron Daniel wrote: >> One difference is that sed-style regexps use \1 \2 etc. for inserting >> matches in substitution operations, while perl uses $1 $2 etc. > >Perl uses \1, \2, etc for substitutions within the regexp. The $1, $2, >etc is so that you can use the matched parts of regexp in the following >code. See page 104 of "Programming in Perl" (the Camel book) for details. Actually, that page says that \1 is only good in the pattern, and that for the replacement part of substitution operations, $1 should be used. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA07933 for urn-ietf-out; Thu, 15 Aug 1996 12:04:51 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA07920 for ; Thu, 15 Aug 1996 12:04:49 -0400 Received: from weeble.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12540 (mail destined for urn-ietf@services.bunyip.com); Thu, 15 Aug 96 12:04:46 -0400 Received: from jon by weeble.lut.ac.uk with local (Exim 0.54 #1) id E0ur4uC-0000UI-00; Thu, 15 Aug 1996 17:04:20 +0100 Date: Thu, 15 Aug 1996 17:04:19 +0100 (BST) From: Jon Knight X-Sender: jon@weeble.lut.ac.uk To: Ron Daniel Cc: Harald.T.Alvestrand@uninett.no, urn-ietf@bunyip.com Subject: Re: [URN] nasty rewriting rules In-Reply-To: <2.2.32.19960815150431.006fbd60@acl.lanl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Jon Knight Errors-To: owner-urn-ietf@bunyip.com On Thu, 15 Aug 1996, Ron Daniel wrote: > One difference is that sed-style regexps use \1 \2 etc. for inserting > matches in substitution operations, while perl uses $1 $2 etc. Perl uses \1, \2, etc for substitutions within the regexp. The $1, $2, etc is so that you can use the matched parts of regexp in the following code. See page 104 of "Programming in Perl" (the Camel book) for details. > Perl > also provides things like \w for matching words, \W for matching non-words, > etc. that I do not recall being in sed-style regexps. There are, no > doubt, many smaller differences. For example, in Perl, '.' does not > match a newline character. This is quite true. Perl regexp's are a superset of egrep's regexp's and so have lots of "nice" extra features (one of the reasons I love Perl so much!) Tatty bye, Jim'll -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA03800 for urn-ietf-out; Thu, 15 Aug 1996 10:59:27 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA03793 for ; Thu, 15 Aug 1996 10:59:25 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11658 (mail destined for urn-ietf@services.bunyip.com); Thu, 15 Aug 96 10:59:23 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id IAA01269; Thu, 15 Aug 1996 08:59:18 -0600 (MDT) Message-Id: <2.2.32.19960815150431.006fbd60@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Aug 1996 09:04:31 -0600 To: Harald.T.Alvestrand@uninett.no From: Ron Daniel Subject: Re: [URN] nasty rewriting rules Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Harald.T.Alvestrand@uninett.no (at least at 12:28 PM 8/15/96 +0200) >There's a regexp description in Appendix E of RFC 1801. >Note that this does NOT define substitution syntax, which URNs need, >and for which there are 2 main variants: PERL and SED; one uses >\( \) and the other uses ( ) as delimiters, I believe. One difference is that sed-style regexps use \1 \2 etc. for inserting matches in substitution operations, while perl uses $1 $2 etc. Perl also provides things like \w for matching words, \W for matching non-words, etc. that I do not recall being in sed-style regexps. There are, no doubt, many smaller differences. For example, in Perl, '.' does not match a newline character. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA01913 for urn-ietf-out; Thu, 15 Aug 1996 10:24:45 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA01908 for ; Thu, 15 Aug 1996 10:24:33 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11443 (mail destined for urn-ietf@services.bunyip.com); Thu, 15 Aug 96 10:24:30 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id IAA00942; Thu, 15 Aug 1996 08:24:20 -0600 (MDT) Message-Id: <2.2.32.19960815142934.006a97b4@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Aug 1996 08:29:34 -0600 To: Lewis Girod , jon@net.lut.ac.uk From: Ron Daniel Subject: Re: [URN] nasty rewriting rules Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Lewis Girod (at least at 03:54 PM 8/13/96 -0400): > On Tue, 13 Aug 1996 15:02:24 +0100 (BST) Jon Knight wrote > > Regexp interpreters are already available in source code format that you > can just plug and play on many current platforms and which will ease > porting to new architectures. > >Fair enough, although it is important to have agreement as to what >flavor of regexps are being used. The original plan was to just >execute sed, which solves both issues on UNIX platforms, but requires >a little more work otherwise. Um, no, that was not the plan. The plan was to use regexp libraries, the syntax of the regexps was "sed-style" rather than "perl-style" because we believe that sed-style is actually the version most regexp libraries support. >The fact remains that unless such >syntax-checking regexps are actually implemented at the top level, >there is no guarantee that a namespace will retain a set structure. We have not had any plans to use regexps that also validate the form of the URN and report errors. >There is some suggestion in the framework document that there be a set >of requirements of new name schemes Well, I thought that those requirements were going to be things like no reassigning of naming authorities, making sure that any naming authorities in a naming scheme require any sub-naming authorities to follow rules at lesat as restrictive as the ones they operate under, ... So, these really are requirements on naming schemes and the operations behing them. Such requiremnts can't be tested by validating the syntax of a URN - useful thought that might be. > Of course those of us that do > want regexp are still free to have a "NAPTRclassic" (:-) ) namespace > hived off using SRV records that does do regexp replacement, so maybe we > can all have our cake and eat it? No, the syntax and capabilitites of the rewrite rules are a property of the NAPTR record, not of individual namespaces. The question before the group is if NAPTR rewrite rules should be regexps or something else. Lewis' proposal is, so far at least, the only alternative that has been advanced. I don't think we can have both, we have to decide. >I am the first to say that the terse syntax is wretched, but it was >really easy to implement and it is terse enough to easily fit into a >DNS response. Being short enough to fit into a DNS response is quite important for efficiency considerations. Exceeding 512 bytes in a response shifts us from UDP to TCP. Also, we want to have plenty f room so that we can include SRV and A records as additional information to reduce the number of queries to DNS. >Humans are supposed to use the simple user-friendly >syntax that compiles into the terse form. With decent management >software the underlying terse form should be transparent to the >administrator -- in fact, if we can assume that everyone is using a >compiler it might be a good idea to make the terse form even more >compact. Those are pretty strong assumptions Lewis. Furthermore, this software also has to decompile the terse form into the friendly form so that people can debug existing records. This sort of friendly software rarely gets written and maintained. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA00221 for urn-ietf-out; Thu, 15 Aug 1996 06:29:02 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA00216 for ; Thu, 15 Aug 1996 06:28:58 -0400 From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10081 (mail destined for urn-ietf@services.bunyip.com); Thu, 15 Aug 96 06:28:56 -0400 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <24550-0@domen.uninett.no>; Thu, 15 Aug 1996 12:28:31 +0200 X-Mailer: exmh version 1.6.7 5/3/96 To: Lewis Girod Cc: jon@net.lut.ac.uk, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] nasty rewriting rules In-Reply-To: Your message of "Tue, 13 Aug 1996 15:54:34 EDT." <9608131954.AA03481@skadhwe.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Aug 1996 12:28:27 +0200 Message-Id: <24536.840104907@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com There's a regexp description in Appendix E of RFC 1801. Note that this does NOT define substitution syntax, which URNs need, and for which there are 2 main variants: PERL and SED; one uses \( \) and the other uses ( ) as delimiters, I believe. Harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA29056 for urn-ietf-out; Tue, 13 Aug 1996 15:55:41 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA29051 for ; Tue, 13 Aug 1996 15:55:36 -0400 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16249 (mail destined for urn-ietf@services.bunyip.com); Tue, 13 Aug 96 15:55:05 -0400 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa28941; 13 Aug 96 15:54 EDT Received: by skadhwe.lcs.mit.edu; (5.65/1.1.8.2/15Aug95-0306PM) id AA03481; Tue, 13 Aug 1996 15:54:34 -0400 Date: Tue, 13 Aug 1996 15:54:34 -0400 Message-Id: <9608131954.AA03481@skadhwe.lcs.mit.edu> From: Lewis Girod To: jon@net.lut.ac.uk Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com In-Reply-To: (message from Jon Knight on Tue, 13 Aug 1996 15:02:24 +0100 (BST)) Subject: Re: [URN] nasty rewriting rules Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com On Tue, 13 Aug 1996 15:02:24 +0100 (BST) Jon Knight wrote Regexp interpreters are already available in source code format that you can just plug and play on many current platforms and which will ease porting to new architectures. Fair enough, although it is important to have agreement as to what flavor of regexps are being used. The original plan was to just execute sed, which solves both issues on UNIX platforms, but requires a little more work otherwise. > There are two questions here. First, this statement is only true > given that the structure of the name scheme actually remains > consistent with this set stucture in the context of NAPTR (this gets > back to point (1) above). If they were resolved with NAPTR using > regexps little would prevent someone from changing the format of an > ISBN in various ways; there is no technical impediment to this, and if > the top level ISBN naming authority doesn't want it to happen their > only recourse is legal. Surely though as long as the end users are using "legal" ISBNs in their URNs, the rewriting that happens is just the business of the people "owning" that ISBN and their resolution agents (might be one and same thing in some cases). If the resolution agents at the top level of a naming authority reject "illegal" constructs in that scheme that they might get given, people will soon get the idea and stop using them. Oops, thanks for catching that bug. Yes, it is sufficient to reject malformed URNs at the top level, and as you say that fixes the problem. As a rule, this can be done using regexps (although I have heard of no plans to do so). The fact remains that unless such syntax-checking regexps are actually implemented at the top level, there is no guarantee that a namespace will retain a set structure. If the top level naming authority never see the "illegal" rewritten versions then that's fine as it means that the rewriting is happening in private lower down the resolution tree. Remember, the rewrite rules are rewriting URNs into domain names, not into other URNs -- so a URN is either legal or illegal from the start. The concern is that names could be added to the namespace which don't conform to the name scheme as defined, but which would still be resolved by the system. If unpleasant contortions are required to perform the resolution downstream it may make the name scheme harder to migrate as a whole. The question is whether the flexibility that makes this possible is neccessary. I'd say that "enforcement" is just a private thing within a particular naming scheme resolution tree and isn't something we should be dipping our toes into (not if we want URNs in this lifetime anyway). There is some suggestion in the framework document that there be a set of requirements of new name schemes; any ``enforcement'' is limited to that sort of thing. We have not yet figured out what requirements are to be applied, but clearly names will need to be verified somewhere to ensure that they are satisying them -- otherwise there might as well be no requirements. So the question becomes, what requirements do we want to set? One possible requirement for NAPTR classic might be that the syntax be defined and checked. What I am suggesting boils down to specifying the hierarchy scheme and ensuring that the NAPTR system escape names to alternate systems as soon as the hierarchy spec is invalidated. > This should make it easier for > people to learn and program in the ``language'' (if such a simple > thing can be called a language!!) while at the same time making syntax > errors less likely. For example, we could use S-expressions (pardon > my rough adherence to standard BNF form..): I can feel an Emacs mode coming on... :-) :-) But of course... :-) > So for example, given a canonical form email address mail:edu.mit.lcs@girod > > ((eat-including ":" &replace-with "") > (eat-until "@" ©) > (eat-including "@" &replace-with ".mail-urn")) > > Would ``compile'' to ``x":"+p"";x"@"-v;x"@"+p".mail-urn";'', and would > generate the pair ("mail-urn.lcs.mit.edu", "girod"). Note that the > translation took care of removing the ``urn:'' if it was there. This > or something like it should be simple enough to learn. And this is simpler that regexps? As a sysadmin I'd much rather use something I'm already used to (ie: regexps) rather than learning (and making mistakes in) another new syntax. Of course those of us that do want regexp are still free to have a "NAPTRclassic" (:-) ) namespace hived off using SRV records that does do regexp replacement, so maybe we can all have our cake and eat it? I am the first to say that the terse syntax is wretched, but it was really easy to implement and it is terse enough to easily fit into a DNS response. Humans are supposed to use the simple user-friendly syntax that compiles into the terse form. With decent management software the underlying terse form should be transparent to the administrator -- in fact, if we can assume that everyone is using a compiler it might be a good idea to make the terse form even more compact. As you say, you can always escape to some kind of proxy that does regexp stuff. The explanation in that message didn't really explain the language, mainly because the terse form is explained in more detail with examples in the proposal document. But conceptually it is pretty simple; each ``statement'' is executed in sequence, and each chops 0 or more chars off the front of the string and then produces a string to catenate into a domain name. The following specify what to chop off: * eat-including: chops right after the first character that appears in the specified delimiter set. * eat-until: chops off right before the first char that appears in the specified delimiter set. * eat-x-chars: eats a specified number of chars. * match-prefix: fails unless the specified string is a prefix of the string, and if it matches eats the prefix. (We may want a case- insensitive version of this as well..) * match-rest: fails unless the rest of the string is an exact match, if it matches eats the rest of the string. Once a prefix is chopped off, it can either be replaced with a specified string (&replace-with) or copied verbatim (©). The result strings is catenated in order and then the result is reversed to produce the domain name to look up. For example, continuing this lisp metaphor: The input is eaten in the following parts: mail: edu.mit.lcs @ girod ^ ^ ^ --> (dns-reverse (catenate "" "edu.mit.lcs" ".mail-urn")) --> (dns-reverse "edu.mit.lcs.mail-urn") --> "mail-urn.lcs.mit.edu" Hope this clarifies things, and thanks a lot for the comments, - Lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA14784 for urn-ietf-out; Tue, 13 Aug 1996 10:04:46 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA14778 for ; Tue, 13 Aug 1996 10:04:35 -0400 Received: from weeble.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10899 (mail destined for urn-ietf@services.bunyip.com); Tue, 13 Aug 96 10:04:05 -0400 Received: from jon by weeble.lut.ac.uk with local (Exim 0.54 #1) id E0uqK37-0005yG-00; Tue, 13 Aug 1996 15:02:25 +0100 Date: Tue, 13 Aug 1996 15:02:24 +0100 (BST) From: Jon Knight X-Sender: jon@weeble.lut.ac.uk To: Lewis Girod Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] nasty rewriting rules In-Reply-To: <9608130628.AA03241@skadhwe.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Jon Knight Errors-To: owner-urn-ietf@bunyip.com On Tue, 13 Aug 1996, Lewis Girod wrote: > (4) Regexp interpreters are hard to implement if they are not already > available on the target system, whereas the languages in my proposal > have been implemented quite easily. Regexp interpreters are already available in source code format that you can just plug and play on many current platforms and which will ease porting to new architectures. > There are two questions here. First, this statement is only true > given that the structure of the name scheme actually remains > consistent with this set stucture in the context of NAPTR (this gets > back to point (1) above). If they were resolved with NAPTR using > regexps little would prevent someone from changing the format of an > ISBN in various ways; there is no technical impediment to this, and if > the top level ISBN naming authority doesn't want it to happen their > only recourse is legal. Surely though as long as the end users are using "legal" ISBNs in their URNs, the rewriting that happens is just the business of the people "owning" that ISBN and their resolution agents (might be one and same thing in some cases). If the resolution agents at the top level of a naming authority reject "illegal" constructs in that scheme that they might get given, people will soon get the idea and stop using them. If the top level naming authority never see the "illegal" rewritten versions then that's fine as it means that the rewriting is happening in private lower down the resolution tree. I'd say that "enforcement" is just a private thing within a particular naming scheme resolution tree and isn't something we should be dipping our toes into (not if we want URNs in this lifetime anyway). > This should make it easier for > people to learn and program in the ``language'' (if such a simple > thing can be called a language!!) while at the same time making syntax > errors less likely. For example, we could use S-expressions (pardon > my rough adherence to standard BNF form..): I can feel an Emacs mode coming on... :-) :-) > So for example, given a canonical form email address mail:edu.mit.lcs@girod > > ((eat-including ":" &replace-with "") > (eat-until "@" ©) > (eat-including "@" &replace-with ".mail-urn")) > > Would ``compile'' to ``x":"+p"";x"@"-v;x"@"+p".mail-urn";'', and would > generate the pair ("mail-urn.lcs.mit.edu", "girod"). Note that the > translation took care of removing the ``urn:'' if it was there. This > or something like it should be simple enough to learn. And this is simpler that regexps? As a sysadmin I'd much rather use something I'm already used to (ie: regexps) rather than learning (and making mistakes in) another new syntax. Of course those of us that do want regexp are still free to have a "NAPTRclassic" (:-) ) namespace hived off using SRV records that does do regexp replacement, so maybe we can all have our cake and eat it? Tatty bye, Jim'll -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id CAA09508 for urn-ietf-out; Tue, 13 Aug 1996 02:29:19 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id CAA09501 for ; Tue, 13 Aug 1996 02:29:13 -0400 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08711 (mail destined for urn-ietf@services.bunyip.com); Tue, 13 Aug 96 02:29:07 -0400 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa23324; 13 Aug 96 2:28 EDT Received: by skadhwe.lcs.mit.edu; (5.65/1.1.8.2/15Aug95-0306PM) id AA03241; Tue, 13 Aug 1996 02:28:54 -0400 Date: Tue, 13 Aug 1996 02:28:54 -0400 Message-Id: <9608130628.AA03241@skadhwe.lcs.mit.edu> From: Lewis Girod To: rdaniel@acl.lanl.gov Cc: urn-ietf@bunyip.com In-Reply-To: <2.2.32.19960802212958.006cb04c@acl.lanl.gov> (message from Ron Daniel on Fri, 02 Aug 1996 15:29:58 -0600) Subject: Re: [URN] nasty rewriting rules Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com ******** NOTE: ******** * * This reply is written in reference to the document and code at * * http://ana-www.lcs.mit.edu/people/girod/translator.c (~40K) * * The file is mostly document, and explains in great detail with examples the * proposal discussed in this reply. * *********************** On Fri, 02 Aug 1996 15:29:58 -0600, Ron Daniel wrote: So, what *do* we want to avoid about regexps? [...] You said that your primary objection to them was that adopting them now might prevent future resolution systems that are not also based on general rewrite rules. With respect, I think that reason is a red herring. A1. What do we need to fix about Regexps? I didn't spend a lot of time explaining this clearly in the original proposal document, so I will summarize what I thought should be fixed: (1) We should enable specific namespace schemes to be enforceable. I think this is a better way of putting what I had said originally, i.e. preventing future name schemes from being contorted. While I agree that it would be a patently bad idea to _specify_ a contorted name scheme, with regexp rules at the basis of a resolution system the whole idea of a name scheme specification no longer applies. At any level of delegation some part of a URN is likely to be essentially opaque, and lower levels really can't be stopped from varying from the intended scheme. This can be seen as a bug or a feature; I consider it a bug. To me it is better to explicitly define a scheme and relegate things that do not fit to other schemes (see discussion in below in sections A4.1 and A3). You mentioned that one difficulty might be ``constructed OIDs'', which I am not familiar with... I would suspect that these could be just as easily constructed into a different name scheme (perhaps by prepending URN:oid-xyz: or something) rather than changing the previously defined format of OIDs. Further, part of this problem is caused by the present lack of a resolution system; once one exists people will make namespaces that fit it. How are constructed OIDs currently used and resolved? (2) We should simplify the construction of maintenance interfaces. Maintainers need to understand what is going on with the system and need to keep the rules working as new functionality is added to them. It would be nice if this can be done with a simple interface which could display the data in an easy to follow manner and which provides static and end-to-end checks to ensure that the system is working. Such an interface is sketched out below in section A2. The regexps are hard to follow and at each stage the whole string has to be processed to figure out what part is relevant. This makes them harder to fit into an interface. (3) We should try to keep the bulk of the data in a format that is easily convertible in the future. This might be a feature of the maintainance interface, since the maintenance interface could keep the data in a canonical form which is then compiled into rules (see section A2.3). It seems to me that this sort of processing is much more difficult to do with regexps than with a simpler rule language. But to the degree that name scheme hierarchy can be specified (depending on the details of each specific scheme) it may be possible to have a single canonical data format for an entire name scheme. (4) Regexp interpreters are hard to implement if they are not already available on the target system, whereas the languages in my proposal have been implemented quite easily. Currently, there are a variety of naming schemes in existence that I would like to be able to resolve as URNs. (ISBNs, OIDs, FPIs, etc). The structure of those names is already set, and the ability of future systems to crack that structure is not affected by what we allow in NAPTRs. There are two questions here. First, this statement is only true given that the structure of the name scheme actually remains consistent with this set stucture in the context of NAPTR (this gets back to point (1) above). If they were resolved with NAPTR using regexps little would prevent someone from changing the format of an ISBN in various ways; there is no technical impediment to this, and if the top level ISBN naming authority doesn't want it to happen their only recourse is legal. Second, I am curious to know how NAPTR would resolve these three name schemes. I can see how to do ISBN (if there are -'s in it), and OIDs shouldn't be a problem, even constructed ones as long as the constructions are in the set of things regexp rules can handle. Similarly, both of these can be dealt with by my proposal, although the set of interpretable constructions is more restricted. Since FPIs are the other space we want to handle, has anyone figured out how regexps would be used to resolve them? From what I can tell it seems tricky. I certainly don't want us to do something now with NAPTRs that is going to come back to haunt us. [...] 1) The distinction between the "program" that is used to canonicalize the order of any hierarchy in the URN, and the "rules" that are used to yank things off the front and make the next domain name, needs to be more explicit. Only the people at urn.net need to know a lot about the program. Site administrators only need to write the rules. Putting them both into the same RR may be confusing. This is true. I grafted them into the same record only to show how it fit into the original NAPTR framework. In fact, in section A2.1 I suggest using three records. 2) What I thought was one of the ameliorating influences in the NAPTR proposal was that the regexps would be applied to the original URN in its entirety. I think this is a much simpler conceptual model than your two-part approach, especially when the second part is rules that operate on the output of other rules. 3) One of the nasty bits about iterative rewrite rules is that upstream changes can affect the correctness of my rules. I forsee a class of errors arising where delimiters are not handled uniformly in upstream rules, making life a pain in the butt for downstream administrators. (Can you get rid of the + and - rules for handling delimiters and just say that if a character is matched, it is eaten?) 4) While error-prone, regexps are nonetheless familiar to a large number of people. The syntax of your proposal (which I understand you can change) does not seem to be an improvement on regexps, and is familiar to no-one. 5) "rules" in your model have two outputs - the domain name to be looked up and the tail of the canonicalized string to be left for subsequent rules. This is a bit warty, but seems unavoidable in rules that are meant to be applied to the output of other rules. I think that all four of these points can be addressed at the level of management software. Because of the simplification of the rules involved, the management software is easier to specify, and with a few added features I think it can ameliorate the issues with invisible breakage downstream. A2. A General Framework for Management Software A2.1 Records The management software described here is used to create and update a set of DNS records on a given server. There are four types of record involved here: (1) SRV records, providing pointers to terminal servers (2) NAPTR records, providing an order parameter and a ruleset decribing how to generate the next domain name (3) NIDSPEC records, which provide for a given name scheme a translation program for rendering URNs canonical and an initial ruleset that generates the next domain name (4) NADOC records, which contain documentation corresponding to a given NIDSPEC or NAPTR, as described below. The description of this management software is very sketchy right now but you should be able to see the intent and how it might work. I think there are some clever simplifications that can be made to the design (especially with respect to the storage and signing of ``agreements'') but I haven't thought it through enough to see them. I offer this mainly as a proof of concept, not as a final solution. To explain how this management software works, let us consider an example. A2.2 Contracts Between Clients and Administrators At a site below the top level, management is taking place over a collection of data that is referenced by domain name. Suppose our site is foo.com, and they are in the business of being a ``name authority'' (or at any rate providing one step of resolution for a name authority); then xxx.foo.com retrieves data (NAPTR, NADOC, SRV records, etc.) from foo.com's name server. The purpose of the management software is to generate foo.com's name database based on their clients' needs. The source data contains two logical types of record: (1) client-instance descriptors, which describe rules that have a fixed set of valid operations. For example, a rule might apply only to two specific clients who can be listed explicitly: the rule ``m"girod/"*p"edu.mit.lcs.skadhwe";'' would only apply to my URNs and would direct clients only to my machine. Other rules might apply to two or a hundred clients. (2) client-class descriptors, which describe a rule that is applied to an unspecified set of clients. For example, for a rule that locates a domain name in the text of the URN and appends ``.urn.net'', it might not be convenient to list all possible clients. The format of a client-instance descriptor is as follows: client-instance { client agreement list = list of client-agreement order = integer ruleset = string // in user-freindly form (see below) } client-agreement { // specification of expected input other info about referer (parent) = (implementation specific) domain name reference came from = string sample expected tail of canonical URN from above = string // specification of promised output other info about client = (implementation specific) domain name of client referring to = string tail expected by client at above domain name = string } Client-class descriptors need not be implemented separately; they can be implemented as trivial instances of client-instance descriptors by simply listing any relevant examples. These descriptors would be set up as a result of an agreement between the naming authority and the clients, and would be fixed. The source data is stored in NADOC records and can be retrieved as such by the clients. In the NADOC record the agreement (excepting the rule specification) can be signed by the agreeing parties so that the agreement used to check the rule can be verified. The site administrator can update the rules, etc, but before the database is actually updated, the software runs a static check against the input/output specifications to make sure they work. If so the database is modified and an end-to-end test is made. The explicit specification of agreements provides safety against the breakage problem and the data involved can be kept in a fairly canonical form (i.e. sets of client-instance records) which should be easier to migrate to new systems. A2.3 Canonical Data Storage for Automated Generation of Contracts For some name schemes, it will be possible to have an even more foolproof system, one which generates the rules directly from a lexical list of namespaces. This is easiest in name schemes with simple syntax. A list of namespaces (using the model of delegation specified in section 4 of our I-D, which is similar to that of the ``path'' scheme) such as urn:bar:foo/a/* --> a.com urn:bar:foo/c/* --> c.com urn:bar:foo/c/fg/* --> fg.com urn:bar:foo/x/* --> x.com urn:bar:foo/x/y/z/* --> z.com urn:bar:foo/x/yz/* --> yz.com could be used to automatically generate all of the rules and agreements involved, perhaps assuming that the tail string coming in begins right after ``urn:bar:foo/'' has been eaten (because at the previous level there was a namespace definition ``urn:bar:foo/* --> foo.com''). The various clients involved sign the agreements, and when changes are made most of the agreements stay the same, and any that change will need to be signed again. As a rule the agreements tend to remain pretty constant; mostly rules are added over time, not changed. A2.4 A User Friendly Rule Syntax Another important feature of this software should be a small rule compiler that translates an easy-to-understand language into the terse format transmitted to the browsers. This should make it easier for people to learn and program in the ``language'' (if such a simple thing can be called a language!!) while at the same time making syntax errors less likely. For example, we could use S-expressions (pardon my rough adherence to standard BNF form..): = ( * ) = ( eat-until ) | ( eat-including ) | ( eat-x-chars ) | ( match-prefix ) | ( match-rest ) = = &replace-with | © So for example, given a canonical form email address mail:edu.mit.lcs@girod ((eat-including ":" &replace-with "") (eat-until "@" ©) (eat-including "@" &replace-with ".mail-urn")) Would ``compile'' to ``x":"+p"";x"@"-v;x"@"+p".mail-urn";'', and would generate the pair ("mail-urn.lcs.mit.edu", "girod"). Note that the translation took care of removing the ``urn:'' if it was there. This or something like it should be simple enough to learn. 6) I am not so sure that your matching rules will continue to be simpler than the major ideas in regexps. Point 3 showed one case where optionality would be extremely helpful, so that upstream changes in matching on a delimiter would not kill us. The religious debate on "urn:" is another. FPIs are a namespace this group is supposed to try to accommodate. They use :: and // in broadly equivalent ways. So, alternation is another capability that probably needs to be in the rewriting language. If those go into your language, you are well on the way to regexps. At this time I have chosen to attack the upstream breakage problem differently; the URN: issue should be handled at the level of the canonical translation and won't affect the rulesets. In section 5 of the proposal document I discuss the issues that I see surrounding ``URN:''; I think that we should make an effort to resolve this debate sometime soon. FPIs are as yet still an unknown here, and indeed they may very well be difficult to handle. I was hoping to figure out how to do so after seeing a general plan for doing so with rewrite rules, mainly because it seems possible to me that the NAPTR system might be used to handle some sections of that namespace while relying on other mechanisms to handle the remainder. Another concern that I have is the growth of the number of rewrite rules over time as portions of collections are delegated to other agencies. This is a concern about rewriting, and applies to either your scheme or to regexps. This is true, and I see this as the central reason for making sure that NAPTR can be replaced by something that will still be efficient when partial delegations become more the rule than the exception. It is my opinion that the translation portion of this proposal will come in handy when a new system is implemented. A3. How Canonical Tranlsation Fits into the Future In the future, I think canonical translation will be a very useful thing. The main reason is that if the direction of hierarchy is consistent, information about prefixes can be cached (i.e. classes of URNs that share the same resolution information). Without a canonical hierarchy such cache systems would need to understand the hierarchy format of any name scheme from which prefixes will be cached, and URNs for which the hierarchy is not understood could only be cached individually. To my way of thinking the logical place to do this transform is at the client (if that is in fact possible..) so that URNs can be handled consistently within the resolution/caching mechanism until the terminal resolver is reached (which should operate on the original URN). This is a URN framework issue. Ignoring for the moment the question of whether name schemes should in fact be specified (see discussion in A4.1), a given translation language has a finite and _definite_ capacity to render URNs canonical. If we make a choice and specify a language it enables a system to process a subset of possible URNs in a consistent manner. Other schemes for URNs would need to be handled by a different system, which could be implemented later with a more capable translation language encompassing a different set of URNs, and so on. In the short term, the initial translation language would be coded into the browser, and it might be wise for browser implementations to leave room to plug new functionality into the translation language. My guess is that a translation language capable of dealing with the existing namespaces will provide sufficient flexibility that new namespaces will have no trouble fitting into the system. What I would like to see is some more analysis of what capabilities are needed (like the stuff above on why I think alternation and optionality are needed). A4. What Capabilities are Needed and Why? As we have seen, the basic theory in terms of what is needed is that by folding stuff into the translation layer the rules layer doesn't need much functionality at all. A4.1 Specification of Hierarchy on a Per-Name-Scheme Basis One potential problem with this proposal is its presupposition that the hierarchy for a name scheme can be specified, which may or may not be valid (i.e. constructed OIDs.) I think we need to establish whether this is a realistic problem. Given that there are namespaces that cannot be rendered canonical in a single preprocessing step, can we estimate the negative impact of escaping to another mechanism at the level at which the specification no longer holds (in the case of OIDs many of them would be in canonical form already)? One possible ameliorating factor here is that because the translation layer represents a partial specification of name scheme syntax, there may be a subsequent reduction in the bother associated with allowing new name schemes to be developed (the framework document suggested that there should be standards for admission, etc), does this then imply that names (such as constructed OIDs) that violate their ``default'' specification might instead be created in a (possibly new) name scheme for which they are structured according to spec? I am fairly convinced that the benefit gained by the canonical hierarchy well outweighs the problems it causes. The central benefits, which I have touched on elsewhere in this message, are (1) Simpler rules in the NAPTR scheme (2) Makes it easier for management software to store data canonically (3) Makes caching easier for future systems (4) Allows name schemes to specify a hierarchy and enables technical solutions to enforce that specification to a much greater degree The problems are: (1) Some existing namespaces may be incompatible and will need to escape to separate resolution technologies (2) Some future namespaces may be incompatible or may be compelled to maintain compatibility The question is: how many URNs and namespaces are we talking about, and is it a problem for them to make the (possibly minor) modifications required to be compatible? Assuming for the moment that the name schemes can be sufficiently specified, the next question is: what sorts of things will we need to handle after canonicalization and how powerful does the rule language have to be. Ron brought up optionality and alternation as two things we will need. In many cases this can be handled with the language currently specified. A4.2 Support for Alternation If we want to pull off a token delimited by either :: or // we can determine which of these cases we have using the match construct. For example, if the following two rules are tried on "foo::bar" and "foo//bar": ((eat-until ":/" ©) (match-prefix "::" &replace-with ".") (eat-until "" ©) (eat-x-chars 0 &replace-with ".colons")) ((eat-until ":/" ©) (match-prefix "//" &replace-with ".") (eat-until "" ©) (eat-x-chars 0 &replace-with ".slashes")) the results will be ("colons.bar.foo", "") and ("slashes.bar.foo", "") respectively. This is because the match-prefix construct fails if it doesn't match the specified string prefix exactly. Another way of handling this would be to replace the syntactic structures "::" and "//" with special marker characters in the translation step (that way the initial string can contain a colon or slash). In short, alternation is possible if the point of alternation can be recognised by either a set of possible characters or a pre-inserted marker. A4.3 Support for Optionality If we want to detect a port number in a URL if it is there (I suggest putting one in during the translation step however..), we can do something like this: ((eat-until ":/" ©) (match-prefix ":" &replace-with ".tcp_port_") (eat-until "/" ©) (eat-including "/" &replace-with "")) ((eat-until ":/" ©) (match-prefix "/" &replace-with ".tcp_port_80")) so, com.foo:8001/path generates ("tcp_port_8001.foo.com", "path") com.foo/path generates ("tcp_port_80.foo.com", "path") In short, optionality can be handled if the option can be recognised by either a set of possible characters or a pre-inserted marker. A4.4 Other Things? What else do we need? I'm not sure. I have by no means proved that this language is sufficient and don't know how I would go about doing that. However I believe the primary reason for needing functionality here is grandfathering; barring radical new technologies (which would probably come with their own radical new resolution mechanisms), new namespaces will likely make do with what is there if it is reasonably flexible. Consequently I am more concerned with specific counterexamples than I am with generalized ideas. That is, we look at the names we have to deal with and try to see how they would be handled by rulesets and by regexps. I would also like to see some info on the general problems of rewrite rules and what, if anything, we can do to overcome them. Some of the problems with rules are: 1) Confusion on how a result was obtained, typically due to successive applications of rules or to overly-capable rewrite languages. 2) Accretion of rules over time making a total rats nest of delegations. This is related to 1. I believe how a result is obtained can be determined by tracing the lookup process, similarly to the original NAPTR process. No doubt the trace may get confusing, and worse, long. As the number of servers in the path grows this can get to be a real problem. Also, the number of rulesets (or, equivalently, NAPTR regexps) returned from a given lookup may grow as delegations increase in number, meaning that more data is being transferred back to the client at a given step. Both of these issues concern me and affect both proposals in similar ways (however, as I indicated in section 3.0, the point of this proposal is more to make it easier to migrate forward later than it is to fix the long term problems with the resolution mechanism -- it is still really NAPTR at heart.) 3) Upstream changes invisibly breaking downstream results. 4) My site getting no requests / somebody else's requests due to upstream errors. As you point out, the regexp rules don't have that property of invisible breakage. Is the mgmt software solution indicated in section 2.0 a good enough fix for the ruleset proposal? Also, note that the limitations on rulesets severely limit the ways in which rulesets returned from the same lookup can interfere. It also makes it easier for mgmt software to be written to verify them. The point in starting this thread was to talk about rewrite rules and if they were a flaw or a feature. At the BOF, concern was raised about rewrite rules and someone said that if meeting the requirements requires the power of rewrite rules, and if we don't like that answer, do we want to change the requirements? Up to now I have not seen any convincing arguments that the requirements can be met without using rewriting. Nor have I seen any calls for us to change the requirements on URNs, at least not in any fashion that restricts the task to be accomplished. (If we were to simplify the requirements, it would be appropriate to reconsider the abilities of NAPTRs). I think there is a third alternative, which more accurately describes my proposal: _directly_ support all URN spaces with the exception of those for which the implementation requires a system of regexp rules. That is, balance the need to support URNs now and in the future with the relevant technical capabilities. For example, suppose sorting out a some subset of the URNs in use required a turing-complete language while the others could all be processed using a finite automaton; if the set of URNs gained by adding this functionality (and at the same time adding the potential to loop) is relatively insignificant, the best solution may be to escape and resolve them another way. If we assume for the moment that rewriting is necessary, then we get into discussing what capabilities are needed and how they will be expressed in the language that is used for the rewrite rules. This is where I think your proposal fits. It represents a noticeable reduction in the capabilities of the NAPTR system, since major rewriting can only happen at the namespace level when we canonicalize the URN. But that was the purpose of the proposal. True. I kind of like the notion of rules that eat off the front of the canonicalized name. However, I am not sure that only allowing that canonicalization to be performed at the namespace level is enough. Especially as collections of resources are delegated over time, I think we are going to see lots of URNs that are old URNs plus some new stuff. It seems impossible to canonicalize such things with the limited amount of information available at the namespace level. (See the stuff on "constructed OIDs" below for more info). [...] I am concerned about the "program" portion of the rewrite only being available at the namespace level. As a specific example, I came across "constructed OIDs" the day before yesterday. These seem to allow "other stuff" to be appended to an OID to make a new OID that does not follow the simple rules of integer name components. If we have an OID namespace, all it can possibly know about constructed OIDs is where the "other stuff" starts and ends. We can't provide a program at the namespace level that will canonicalize the order of all components. This gets at what me want to mean by name scheme specification (see sections A3, A4.1). Certainly the original specification of OIDs doesn't allow these additions? Do you have more information about constructed OIDs? >* It is already clear that there are some name schemes that cannot be >efficiently resolved by this new scheme and will need to be escaped >(just as some cannot be conveniently handled by NAPTR). To what >degree is it necessary to add flexibility beyond what is required to >grandfather in existing namespaces? Well, this sort of depends on what namespaces you want to grandfather in. :-) The regexps give us a set of tools to deal with new things as they arise, typically in the course of trying to grandfather in a new namespace. ^^^^^^^^^^^^^ By ``new namespace'' do you mean one that is recently invented or an existing namespace? I suspect it would be more likely that new namespaces be designed to fit into whatever structure is in place, rather than go through a lot of trouble to build an alternate resolution mechanism. It's easy to invent a namespace that can't be resolved effectively by NAPTR with regexps -- but is that our problem? Apologies for the length of this reply, but there were a lot of questions to answer. Thank you for your comments on the proposal, Regards, Lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA05323 for urn-ietf-out; Mon, 5 Aug 1996 00:04:45 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA05318 for ; Mon, 5 Aug 1996 00:04:43 -0400 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14369 (mail destined for urn-ietf@services.bunyip.com); Mon, 5 Aug 96 00:04:42 -0400 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa20267; 5 Aug 96 0:03 EDT Received: by skadhwe.lcs.mit.edu; (5.65/1.1.8.2/15Aug95-0306PM) id AA00976; Mon, 5 Aug 1996 00:03:12 -0400 Date: Mon, 5 Aug 1996 00:03:12 -0400 Message-Id: <9608050403.AA00976@skadhwe.lcs.mit.edu> From: Lewis Girod To: rdaniel@acl.lanl.gov Cc: urn-ietf@bunyip.com In-Reply-To: <2.2.32.19960802215459.006c6928@acl.lanl.gov> (message from Ron Daniel on Fri, 02 Aug 1996 15:54:59 -0600) Subject: Re: [URN] re NAPTR, URN-res-req Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com Ron Daniel wrote on Fri, 02 Aug 1996 15:54:59 -0600: >I guess I thought that one way that unofficial hints could >get into the system was by direct injection by users. I think >it is certainly outside the scope of NAPTRs, but is something to >keep in mind for the future. There might be a ComMentor-style >annotation set that was user-supplied resolution hints. Yes, users could inject unofficial hints as well as publishers. The end user trying to locate the resource would probably try (in the abscence of other knowledge about the resource) the official hint first, then any hints supplied by the owner of the namespace, then any hints that appear to be supplied by the author (if that person is known..), then whatever else is there (users? etc.). All of this is definitely outside the scope of NAPTR resolution.. an idea for the future. I have not had a chance to address your comments re. the rewrite rule stuff yet as I have been on vacation this past week and have had only sporadic net access.. - Lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA05222 for urn-ietf-out; Mon, 5 Aug 1996 00:02:46 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA05215 for ; Mon, 5 Aug 1996 00:02:41 -0400 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14348 (mail destined for urn-ietf@services.bunyip.com); Mon, 5 Aug 96 00:02:38 -0400 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa20264; 5 Aug 96 0:02 EDT Received: by skadhwe.lcs.mit.edu; (5.65/1.1.8.2/15Aug95-0306PM) id AA00929; Mon, 5 Aug 1996 00:02:20 -0400 Date: Mon, 5 Aug 1996 00:02:20 -0400 Message-Id: <9608050402.AA00929@skadhwe.lcs.mit.edu> From: Lewis Girod To: terry@ora.com Cc: urn-ietf@bunyip.com In-Reply-To: <199608031809.LAA01004@rock.west.ora.com> (message from Terry Allen on Sat, 3 Aug 1996 11:09:48 PDT) Subject: Re: [URN] re NAPTR, URN-res-req Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com On Sat, 3 Aug 1996 11:09:48 PDT, Terry Allen wrote: >Would you sketch a sample lookup sequence for a URN for which official >and unofficial hints have been injected into the system? Is it a matter >of user/client preferences as to which hints are heeded? (See the >Bobsnamespace example below.) It would be a matter of end client preferences which hints would be used first and which would be provided to the user at all. I envision the client requesting the official information as well as at most N unofficial hints from the system for any particular URN lookup. The browser would use the official hint info by default while at the same time pointing out that other information is available. There might be other types of preferences as well, I haven't thought about it too much. >I am imagining something like this: Bobsnamespace consists of the >names 1 through 8. Bob sells off from this name space 2, 4, 5, and 7, >rather than a block of names, and further he declines to resolve them >after he sells them (maybe he goes out of business). The result >will be (I think) that no one resolver handles the entire name space, >and that it is not possible to predict from the URN which of the >several resolvers for Bobsnamespace should be queried first. This is at the crux of the namespace migration problem. The generalized scheme I mentioned in the document involves two different methods of delegation. When Bob ``sells off'' names from his space, he has the option of ``officially'' delegating the names or of handling the delegation himself. The difference here is that an ``official'' delegation puts the delegation information up at the ``top'' level, in effect flattening the namespace, at least in terms of layers of resolution mechanism. For Bob's clients, this has advantages: (1) Bob has nothing to do with their resolution, because their URNs go direct to their specified resolution service, so they are not dependent on him, only on the top level (2) Depending on how the top level resolution system works, this may be faster since it may involve fewer steps of resolution. The disadvantages to official delegation are (1) a little bit more of the structure of your namespace is publicly known (2) the top level gets big as time goes on (but for this to work at all the system has to be able to scale in response!) (3) it will likely cost money to enter an official delegation, which is likely passed on to the client. In answer to Bob's conundrum, if the names are not easily generalized according to whatever rules exist (for example, simple string prefixes after a canonicalization process) it will cost a lot more to officially delegate the names, because in some cases there may simply be no generalization and official delegation would be commensurate with listing each URN. To the degree that the names are not officially delegated all bets are off when Bob goes out of business. Presumably, however, Bob or someone else could extort sufficient funds from of his clients to continue resolving the URNs.. ;-) In general, with such a system clients who intend to use their URNs for a long time would be wise to be sure that if something goes wrong with their service providers they can salvage their URNs in a cost-effective manner. >This will work for some, perhaps a great many, URN lookups, but not >all. Yes. Some URN lookups may want to use a secret or proprietary resolution process for example. No generalized system would be sufficient in all such cases >Further, it won't be possible to prevent people from inventing name >spaces that don't decompose nicely. The top-level URN name space >registry can't refuse to register such name spaces, or it ceases to >be useful. In addition to grandfathering, there's a requirement to >be able to "cousin-in" name spaces invented by people who weren't >aware they weren't following the rules preferred by the top-level >registry. These may have to be resolved by brute force (matching >the entire URN string) or use of other info. This is true; but if a certain type of service is provided by this system, it increases the likelihood that new namespaces fit themselves into it. To the degree that they don't or can't, they will need to be escaped to other systems from the top level. I guess it is a question of balancing the goal of keeping URNs alive with that of having a buildable system. The system I sketched in section 4 and the NAPTR proposal represent different points on this spectrum. With any system, there may be cases where a namespace is a real mess and can't be effectively split up; either it gets served in total by someone else or by some other technique, or parts of it are forced into the system and the remaining parts are lost. What we are really talking about here is having a dependable top level sevice, one that doesn't go out of business as we suspect Bob might. Presumably this dependability would stem from some kind of cooperative management in which a large number of interested parties run servers that serve a large distributed database. This database can escape to other similar systems if the need arises (or a new version of the software can be written which extends the capabilities for generalization exhibited by the original.) The controversy is over what basic services should be provided by this top level, and what services should be delegated to other (possibly less dependable) levels, and how this in fact affects the goals of long-lived URNs, of flexibility of namespace design, and of grandfathering in existing namespaces. Personally, I think that one simple way to fix a lot of these problems is to offer each person his/her own namespace (for a very reasonable fee), in a way that can be generalized so that their URNs are easily mapped to the resolution service of their choice. For example, URN:PEOPLE:unambiguous_name/* would be one syntax (perhaps it would be best to assign people numbers in order to cut down on lawsuits and trademark issues). Doing this guarantees a certain base level of stability, since people currently tend to keep a constant identity for say 50 years or so. Doing this adds a lot of stuff to the database initially, but the total amount is limited by other factors such as the availability of food and the asking price for slots in the database, so scaling issues should be controllable. How each person chooses to structure his namespace below this is not specified, but at least any damage is constrained to that individual's personal space. This sort of fix would occur after the system is in place (i.e. the future), and I bring it up mostly as an example of the sorts of namespace-design techniques that will likely help with these problems, after the top level system is implemented and the framework is essentially set in stone, at least for the short term. I doubt that any system can keep every URN alive, unless it is prepared to store the whole list of URNs. What is more important is getting most of them (this includes deciding what meaning of ``most'' satisfies you), and providing ways of setting things up that both satisfy the clients' requirements and ensure that their URNs will stick around. Those that choose not to follow these guidelines may get into trouble. I think this is true of any system that works on a principle of generalizing classes of URNs; for all systems, there is some generalization strategy is not efficient (for example, if all of your URNs are products of two large prime numbers... ;-) ) Regards, Lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA06131 for urn-ietf-out; Sat, 3 Aug 1996 14:14:15 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA06122 for ; Sat, 3 Aug 1996 14:14:13 -0400 Received: from rock.west.ora.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10762 (mail destined for urn-ietf@services.bunyip.com); Sat, 3 Aug 96 14:14:09 -0400 Received: (from terry@localhost) by rock.west.ora.com (8.6.13/8.6.11) id LAA01004; Sat, 3 Aug 1996 11:09:48 -0700 Message-Id: <199608031809.LAA01004@rock.west.ora.com> From: Terry Allen Date: Sat, 3 Aug 1996 11:09:48 PDT In-Reply-To: Lewis Girod "Re: [URN] re NAPTR, URN-res-req" (Aug 1, 7:22pm) X-Mailer: Mail User's Shell (7.2.0 10/31/90) To: Lewis Girod , terry@ora.com Subject: Re: [URN] re NAPTR, URN-res-req Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com (Slightly out of order.) Lewis Girod: | True. Our omission of an explanation of hints has caused a great deal | of confusion, which this reply has hopefully addressed to a degree. | Since we did not have a clear technical plan at the time of writing we | did not want to do into a lot of detail; we hoped to instead get out | some ideas we were plaing with and see what sort of reactions were | generated. As for the idea of `hints in reverse', the URN community | should decide if this is within the scope of our problem or whether we | want to declare it outside. My opinion is that it is outside; it | widens the problem and makes the primary technique for resolution | (i.e. precomputed lexical generalization of URNs) impossible. Okay with me if it is to be considered out of scope, although I think that for some classes of resources straight URN lookup will not be the most common method of retrieval. | We used the term ``hint'' to mean precisely the data formats used by | the system to transmit to the client information that aids in locating | a document given a URN. Much of our document was intended to be a set | of general issues and requirements that we thought were critical to | producing a working URN system; for this reason we did not want to | specify formats there. I don't think coming up with formats is too | difficult; it is more a question of what clients actually understand. | At the time of writing we had envisioned such formats as the proposed | NAPTR and SRV records as possible initial `hint' formats, since if the | NAPTR system was in use this would be the type of data the clients | would be expecting. It should be stated, however, that we were not | intending hints to solve the sorts of semantics-oriented search | problems you describe; we see this as a higher level of the problem | that should be kept separate from the straight URN->document(s) | mapping problem. Would you sketch a sample lookup sequence for a URN for which official and unofficial hints have been injected into the system? Is it a matter of user/client preferences as to which hints are heeded? (See the Bobsnamespace example below.) Regarding the "straight URN->document(s) mapping problem," I am suggesting that the real problem is document identification and retrieval, and that URNs are only one part of its solution. But if that's out of scope, okay. | These concerns are definitely something to think about. In terms of | naming authorities disappearing, I had envisioned the solution being | for the naming authority to transfer or sell off its namespace to | other entities before going away. For example, if you have some names | issued by shady.com, they might sell them to you before they go out of | business, at which point you would be responsible for telling the | resolution system where your authoritative server is. In our model I am imagining something like this: Bobsnamespace consists of the names 1 through 8. Bob sells off from this name space 2, 4, 5, and 7, rather than a block of names, and further he declines to resolve them after he sells them (maybe he goes out of business). The result will be (I think) that no one resolver handles the entire name space, and that it is not possible to predict from the URN which of the several resolvers for Bobsnamespace should be queried first. | Another issue that is parallel to this is that the resolution models | being discussed here all try to deal with URNs in groups in order to | cut down on the size of higher levels of the database. NAPTR does | this in a similar way to the DNS. The model I tend to think of tends | to assume that the top level of the directory is pretty big, but still | is based on the idea of sending all URNs starting with this prefix to | this particular resolver. In the end this is a good idea because it | allows changes to be made at a local level rather than having to | bother the top level every time. This means that the system we are | talking about does not deal with individual URNs under normal | circumstances; they will always be generalized somehow, in my mind | usually through the concept of a naming authority. This will work for some, perhaps a great many, URN lookups, but not all. Further, it won't be possible to prevent people from inventing name spaces that don't decompose nicely. The top-level URN name space registry can't refuse to register such name spaces, or it ceases to be useful. In addition to grandfathering, there's a requirement to be able to "cousin-in" name spaces invented by people who weren't aware they weren't following the rules preferred by the top-level registry. These may have to be resolved by brute force (matching the entire URN string) or use of other info. Regards, -- Terry Allen O'Reilly & Associates, Inc. terry@ora.com "In going on with these experiments, how many pretty systems do we build, which we soon find ourselves obliged to destroy?" - Benjamin Franklin A Davenport Group sponsor http://www.ora.com/davenport/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA26840 for urn-ietf-out; Fri, 2 Aug 1996 17:50:18 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA26835 for ; Fri, 2 Aug 1996 17:50:14 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08372 (mail destined for urn-ietf@services.bunyip.com); Fri, 2 Aug 96 17:50:12 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id PAA09114; Fri, 2 Aug 1996 15:50:09 -0600 (MDT) Message-Id: <2.2.32.19960802215459.006c6928@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 02 Aug 1996 15:54:59 -0600 To: Lewis Girod From: Ron Daniel Subject: Re: [URN] re NAPTR, URN-res-req Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Lewis Girod (at least at 07:22 PM 8/1/96 -0400) >At 12:32 PM 7/28/96 PDT, Terry Allen wrote: > >>Much is made here of "hints," [...] >It should be stated, however, that we were not >intending hints to solve the sorts of semantics-oriented search >problems you describe; we see this as a higher level of the problem >that should be kept separate from the straight URN->document(s) >mapping problem. This is a useful clarification, thanks Lewis. >>[...] ignores the power of supplying as input into the URN resolution >>system ancillary information about the URN (hints in reverse, so to speak). > >[...]As for the idea of `hints in reverse', the URN community >should decide if this is within the scope of our problem or whether we >want to declare it outside. My opinion is that it is outside; it >widens the problem and makes the primary technique for resolution >(i.e. precomputed lexical generalization of URNs) impossible. I guess I thought that one way that unofficial hints could get into the system was by direct injection by users. I think it is certainly outside the scope of NAPTRs, but is something to keep in mind for the future. There might be a ComMentor-style annotation set that was user-supplied resolution hints. >Under such a >system, [the canonicalization proposol for an alternative to regexps] >a name scheme designer can enforce certain policies about the >format and semantics of the names under that scheme, whereas according >to the original NAPTR model the top-level name scheme design had no >impact on the structure underneath. Something I left out of my previous message (hard to believe I left anything out, I know :-)... One of my concerns about the canonicalization proposal was that a single program at the namespace level could not deal with constructed names. How about allowing that program to insert a marker into the canonical form of a name. When the client sees the marker, it means that it would be legal for the incoming NAPTR to provide a program for dealing with the rest of the URN. This way we get the restrictions on permissable behavior that you want and can still handle constructed names, which I think will become an important thing to do. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA26638 for urn-ietf-out; Fri, 2 Aug 1996 17:25:27 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA26633 for ; Fri, 2 Aug 1996 17:25:23 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07136 (mail destined for urn-ietf@services.bunyip.com); Fri, 2 Aug 96 17:25:19 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id PAA08835; Fri, 2 Aug 1996 15:25:08 -0600 (MDT) Message-Id: <2.2.32.19960802212958.006cb04c@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 02 Aug 1996 15:29:58 -0600 To: Lewis Girod From: Ron Daniel Subject: Re: [URN] nasty rewriting rules Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com At 07:25 PM 8/1/96 -0400, Lewis Girod wrote: >This message is in response to a thread started a long time ago by >Ron, namely, what about rewrite rules? Thanks for picking up on that thread Lewis. I have mixed opinions about your proposal. You are right that we chose regexps in a very ad-hoc fashion. Once we decided that rewriting was the solution to the problem of separating resolution procedures from name assignment procedures, we needed to have a language for expressing the rewriting rules. Regexps appeared to have the power to do what was needed, we were all familiar with them, and we didn't have to spend a lot of time trying to define and implement our own rewrite language. The last point, of course, is a big part of why we settled on regexps. I'm happy to see that you have not flinched from the effort that we backed away from. However, I don't think your proposal is ready to replace regexps, for reasons I'll get into below. But it is a start and there are things I like about it. So, what *do* we want to avoid about regexps? You said that your primary objection to them was that adopting them now might prevent future resolution systems that are not also based on general rewrite rules. With respect, I think that reason is a red herring. I understand the concern, but don't think it holds up. Currently, there are a variety of naming schemes in existence that I would like to be able to resolve as URNs. (ISBNs, OIDs, FPIs, etc). The structure of those names is already set, and the ability of future systems to crack that structure is not affected by what we allow in NAPTRs. NAPTRs only interfere with future resolution systems if the developers of future namespaces look at the capabilities of regexps and create a contorted naming scheme to take advantage of them. I submit that such contortions are extremely unlikely. Furthermore, they could be handled in future systems through escape mechanisms similar to those that NAPTR will utilize for several of the above namespaces. I certainly don't want us to do something now with NAPTRs that is going to come back to haunt us. I am much more concerned about other modes of failure in the future than contorted namespaces. My first concern is that administrators creating NAPTRs will get them wrong. I'm the first to admit that regexps are prone to errors. However, I think that your proposal is no better on that front, and is quite possibly worse. 1) The distinction between the "program" that is used to canonicalize the order of any hierarchy in the URN, and the "rules" that are used to yank things off the front and make the next domain name, needs to be more explicit. Only the people at urn.net need to know a lot about the program. Site administrators only need to write the rules. Putting them both into the same RR may be confusing. 2) What I thought was one of the ameliorating influences in the NAPTR proposal was that the regexps would be applied to the original URN in its entirety. I think this is a much simpler conceptual model than your two-part approach, especially when the second part is rules that operate on the output of other rules. 3) One of the nasty bits about iterative rewrite rules is that upstream changes can affect the correctness of my rules. I forsee a class of errors arising where delimiters are not handled uniformly in upstream rules, making life a pain in the butt for downstream administrators. (Can you get rid of the + and - rules for handling delimiters and just say that if a character is matched, it is eaten?) 4) While error-prone, regexps are nonetheless familiar to a large number of people. The syntax of your proposal (which I understand you can change) does not seem to be an improvement on regexps, and is familiar to no-one. 5) "rules" in your model have two outputs - the domain name to be looked up and the tail of the canonicalized string to be left for subsequent rules. This is a bit warty, but seems unavoidable in rules that are meant to be applied to the output of other rules. 6) I am not so sure that your matching rules will continue to be simpler than the major ideas in regexps. Point 3 showed one case where optionality would be extremely helpful, so that upstream changes in matching on a delimiter would not kill us. The religious debate on "urn:" is another. FPIs are a namespace this group is supposed to try to accommodate. They use :: and // in broadly equivalent ways. So, alternation is another capability that probably needs to be in the rewriting language. If those go into your language, you are well on the way to regexps. Another concern that I have is the growth of the number of rewrite rules over time as portions of collections are delegated to other agencies. This is a concern about rewriting, and applies to either your scheme or to regexps. What I would like to see is some more analysis of what capabilities are needed (like the stuff above on why I think alternation and optionality are needed). I would also like to see some info on the general problems of rewrite rules and what, if anything, we can do to overcome them. Some of the problems with rules are: 1) Confusion on how a result was obtained, typically due to successive applications of rules or to overly-capable rewrite languages. 2) Accretion of rules over time making a total rats nest of delegations. This is related to 1. 3) Upstream changes invisibly breaking downstream results. 4) My site getting no requests / somebody else's requests due to upstream errors. What other problems with rewrites can we come up with? What tools can we provide to ease those problems? I would also like to know how regexps or alternative proposals such as yours impact the problems above. Regexps may be an overly general language to use to specify the rules. Your proposal may fall into the trap of confusing results due to applying rules to the output of other rules. Both are subject to errors such as 4. >All of this >can be found at > > http://ana-www.lcs.mit.edu/people/girod/translator.c (~40K) > >I am curious to see what you think. I will have some specific comments on that document later. >* I think that this addresses a major design flaw of the original >NAPTR system. Do you? Are the rewrite rules a flaw or a feature? If >they are a flaw does this address that flaw? The point in starting this thread was to talk about rewrite rules and if they were a flaw or a feature. At the BOF, concern was raised about rewrite rules and someone said that if meeting the requirements requires the power of rewrite rules, and if we don't like that answer, do we want to change the requirements? Up to now I have not seen any convincing arguments that the requirements can be met without using rewriting. Nor have I seen any calls for us to change the requirements on URNs, at least not in any fashion that restricts the task to be accomplished. (If we were to simplify the requirements, it would be appropriate to reconsider the abilities of NAPTRs). If we assume for the moment that rewriting is necessary, then we get into discussing what capabilities are needed and how they will be expressed in the language that is used for the rewrite rules. This is where I think your proposal fits. It represents a noticeable reduction in the capabilities of the NAPTR system, since major rewriting can only happen at the namespace level when we canonicalize the URN. But that was the purpose of the proposal. I kind of like the notion of rules that eat off the front of the canonicalized name. However, I am not sure that only allowing that canonicalization to be performed at the namespace level is enough. Especially as collections of resources are delegated over time, I think we are going to see lots of URNs that are old URNs plus some new stuff. It seems impossible to canonicalize such things with the limited amount of information available at the namespace level. (See the stuff on "constructed OIDs" below for more info). >* Can this two-step process handle everything we want it to handle? >If not, are there modifications to the languages that will enable it >to do so? (In general, we can increase the complexity of the >translation language as needed, but that makes it harder to implement >and inreases the probability of bugs or loops) I am concerned about the "program" portion of the rewrite only being available at the namespace level. As a specific example, I came across "constructed OIDs" the day before yesterday. These seem to allow "other stuff" to be appended to an OID to make a new OID that does not follow the simple rules of integer name components. If we have an OID namespace, all it can possibly know about constructed OIDs is where the "other stuff" starts and ends. We can't provide a program at the namespace level that will canonicalize the order of all components. I've already mentioned alternation and optionality as two capabilities that will probably be needed. >* It is already clear that there are some name schemes that cannot be >efficiently resolved by this new scheme and will need to be escaped >(just as some cannot be conveniently handled by NAPTR). To what >degree is it necessary to add flexibility beyond what is required to >grandfather in existing namespaces? Well, this sort of depends on what namespaces you want to grandfather in. :-) The regexps give us a set of tools to deal with new things as they arise, typically in the course of trying to grandfather in a new namespace. >How much flexiblity is needed >beyond what is provided by this system, and how much more does the >original NAPTR proposal provide? Optionality, alteration, and the ability to deal with constructed names are the ones that I can think of now. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 tautology:"Conformity is very popular" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA23060 for urn-ietf-out; Thu, 1 Aug 1996 19:26:40 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA23055 for ; Thu, 1 Aug 1996 19:26:38 -0400 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23200 (mail destined for urn-ietf@services.bunyip.com); Thu, 1 Aug 96 19:26:36 -0400 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa28939; 1 Aug 96 19:25 EDT Received: by skadhwe.lcs.mit.edu; (5.65/1.1.8.2/15Aug95-0306PM) id AA09843; Thu, 1 Aug 1996 19:25:10 -0400 Date: Thu, 1 Aug 1996 19:25:10 -0400 Message-Id: <9608012325.AA09843@skadhwe.lcs.mit.edu> From: Lewis Girod To: rdaniel@acl.lanl.gov Cc: urn-ietf@bunyip.com In-Reply-To: <2.2.32.19960708184016.006ecac4@acl.lanl.gov> (message from Ron Daniel on Mon, 08 Jul 1996 12:40:16 -0600) Subject: Re: [URN] nasty rewriting rules Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com Hi, This message is in response to a thread started a long time ago by Ron, namely, what about rewrite rules? I have this idea that the client side of the NAPTR system that currently uses the rewrite rules can be replaced by a two-step process which gives a better modularity and will make the data in the system easier to deal with (as well as making the creation of name scheme security policies much simpler.) The idea here is to divide the problem into two halves; first, put the URN into a canonical form in which the direction of hierarchy is fixed. For example, the domain name in http://lcs.mit.edu/girod/paper.ps would need to be reversed so that the hierarchy goes from biggest on the left to smallest on the right: http://edu.mit.lcs/girod/paper.ps Once the URN is in canonical form, the actual resolution process can begin. Because the hard part of sorting out the URN has already been done in the initial canonicalization phase, the rest of the resolution can be done using some very simple rules. These rules are very constrained in comparison to the unconstrained rewrite rules; they operate only by taking parts off the left hand side of the canonical string, and can either copy that data verbatim or replace it with a specific string. However, it appears that most stuff we want to do can be done this way. If such a scheme can work, there are two main benefits to the new modularity: (1) the vast majority of the data driving the resolution process is in a simplified and standardized form, which is easier to check and understand because there is less flexibility and because the hard stuff is done once at the beginning, (2) the format of the name scheme is specified at the top and deviation from this format is more difficult because of the restrictions placed on rules below the initial translation. I have invented two small languages (a translation language and a rule language) and written up a document that explains them and gives examples of how they can be used to do everything I could think of. I have also provided C code that implements the interpreters for these languages, and some pseudocode that shows how it can be used to operate the NAPTR resolution process. The syntax of the languages is terse and ugly but really easy to implement and at bottom very simple. The syntax can probably be cleaned up significantly... In total, I think this modification requires little in the way of modification to the server side of the existing NAPTR code, but it does modify the client significantly. The C code provided should be pretty portable and has even been tested to a degree... All of this can be found at http://ana-www.lcs.mit.edu/people/girod/translator.c (~40K) I am curious to see what you think. * I think that this addresses a major design flaw of the original NAPTR system. Do you? Are the rewrite rules a flaw or a feature? If they are a flaw does this address that flaw? * Can this two-step process handle everything we want it to handle? If not, are there modifications to the languages that will enable it to do so? (In general, we can increase the complexity of the translation language as needed, but that makes it harder to implement and inreases the probability of bugs or loops) * It is already clear that there are some name schemes that cannot be efficiently resolved by this new scheme and will need to be escaped (just as some cannot be conveniently handled by NAPTR). To what degree is it necessary to add flexibility beyond what is required to grandfather in existing namespaces? How much flexiblity is needed beyond what is provided by this system, and how much more does the original NAPTR proposal provide? - Lewis Girod (girod@lcs.mit.edu) Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA22791 for urn-ietf-out; Thu, 1 Aug 1996 19:23:01 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA22782 for ; Thu, 1 Aug 1996 19:22:57 -0400 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23192 (mail destined for urn-ietf@services.bunyip.com); Thu, 1 Aug 96 19:22:54 -0400 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa28913; 1 Aug 96 19:22 EDT Received: by skadhwe.lcs.mit.edu; (5.65/1.1.8.2/15Aug95-0306PM) id AA09845; Thu, 1 Aug 1996 19:22:43 -0400 Date: Thu, 1 Aug 1996 19:22:43 -0400 Message-Id: <9608012322.AA09845@skadhwe.lcs.mit.edu> From: Lewis Girod To: terry@ora.com Cc: urn-ietf@bunyip.com In-Reply-To: <199607291642.MAA06586@services.bunyip.com> (message from Terry Allen on Sun, 28 Jul 1996 12:32:18 PDT) Subject: Re: [URN] re NAPTR, URN-res-req Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com At 12:32 PM 7/28/96 PDT, Terry Allen wrote: >Much is made here of "hints," which I understand as heuristic instructions >that the client or intermediary can use to determine how to start >the URN resolution process. I think something like this is >essential, but it needs fleshing out. Can a syntax or format >of hints be generalized? (My guess is that it can't.) >Can the semantics of hints be generalized: "for anything >written by author={Jane Austen} see the Jane Austen Home Page"? (I think >this might be possible for well defined bibliographic data.) This was an area in which we were not very specific. In our private discussions while writing this we developed a concept we mean by ``hints'' which we unfortunately forgot to explain clearly in the document. We used the term ``hint'' to mean precisely the data formats used by the system to transmit to the client information that aids in locating a document given a URN. Much of our document was intended to be a set of general issues and requirements that we thought were critical to producing a working URN system; for this reason we did not want to specify formats there. I don't think coming up with formats is too difficult; it is more a question of what clients actually understand. At the time of writing we had envisioned such formats as the proposed NAPTR and SRV records as possible initial `hint' formats, since if the NAPTR system was in use this would be the type of data the clients would be expecting. It should be stated, however, that we were not intending hints to solve the sorts of semantics-oriented search problems you describe; we see this as a higher level of the problem that should be kept separate from the straight URN->document(s) mapping problem. >I may also wish to discover all resolvers for a given URN, because >(especially after the publisher has gone away) some may return a >better quality object than others--remember that "sameness" is defined >by the publisher or namer, and an URN doesn't necessarily resolve >to a unique object. Has this task been considered in either draft? In the models we are considering, this problem would typically be solved using unofficial hints. This is because there is an assumption that the URN in question falls into the domain of some naming authority, and they are providing (or not) official hints as to where the URN can be resolved. They may not provide or even be aware of all relevant resolvers; for this reason collections of unofficial hints may be provided by anyone that can direct people to alternate resolvers. In the long run unofficial hints are less efficient to maintain and are in general less certain (the models we consider do not guarantee that unofficial hints are provided with the accuracy accorded to official hints), so they should be considered to be temporary fixes for problematic situations. In answer to your question, in such a system all advertised resolvers would be determinable. >But in time, as NAs disappear, sometimes leaving large messes behind >them, there will be URNs for which no single authoritative resolver >exists; this problem is only compounded for hints, which offer fertile >... >Thus much of section 4.1 is moot. One cannot require that there be >authoritative URN resolution services; there will be simply services. >Whether they work for you or not is something you'll have to do your >homework on. The hints you'll find most valuable may be those >supplied by third parties, or discovered by your own desktop client >based on experience; and there may be no correlation with their >supposed authoritativeness. These concerns are definitely something to think about. In terms of naming authorities disappearing, I had envisioned the solution being for the naming authority to transfer or sell off its namespace to other entities before going away. For example, if you have some names issued by shady.com, they might sell them to you before they go out of business, at which point you would be responsible for telling the resolution system where your authoritative server is. In our model ``authoritative server'' does not imply much of anything in terms of authenticity -- it merely is the server that the naming authority owning the names says is authentic. This is another place where unofficial hints come into play; an unofficial hint may give information that contradicts the ``official'' information from the ``official'' naming authority. In the end it is up to the user to decide who is telling the truth; it is quite possible that the unofficial hints are written by the author of the eventual resource (and authenticatable) but to know that you need to know who the author is, etc. Note that our ideas of having unofficial hints integrated into the system do not preclude third party hint systems! In fact third party hint systems are a really good idea, but from my perspective it seems best to also try to integrate them into the official infrastructure in the interests of fairness (it may not succeed, of course... :-) ). Another issue that is parallel to this is that the resolution models being discussed here all try to deal with URNs in groups in order to cut down on the size of higher levels of the database. NAPTR does this in a similar way to the DNS. The model I tend to think of tends to assume that the top level of the directory is pretty big, but still is based on the idea of sending all URNs starting with this prefix to this particular resolver. In the end this is a good idea because it allows changes to be made at a local level rather than having to bother the top level every time. This means that the system we are talking about does not deal with individual URNs under normal circumstances; they will always be generalized somehow, in my mind usually through the concept of a naming authority. Note also that systems set up this way cannot deal with the semantic content of URNs because that radically changes the way they are hierarchicalized (For example, sorting on author and on title produce two very different search trees...) Since the data they are storing is really just a description of generalization, these systems always deal with just one hierarchy and stick to it. >4.1.2 describes as necessary a Hint Passing Interface, and says >that hints lie within given naming schemes. Gosh, this seems >simplistic. Why is this a requirement for URN resolution? Has >anything of the sort been attempted? Why must hints be restricted >to the NA vector ("anything written by author={Jane Austen}")? >This is not the way we locate most bibliographic information today. It should be noted that section 4 describes some ideas we had for a model or framework for URNs, more than it states requirements. The requirements we wanted to set are in section 2. >BTW, who owns the URN? the top-level NA, or the NA responsible for >actually associating the URN with something? If I offer resolution >for your URNs, can you object? especially if the URN denotes an >object neither of us owns rights in or that cannot be retrieved? >Pseudoexamples: >FPI:ISO:+ISO/IEC 8070/RA::A00002/Athens/Acropolis/Erectheum >PP:944940/Domesday Book/page 18 >USArchives:Nixon/tape/18.5-min-gap Interesting question.. in the end I suppose this is a legal issue, but in my opinion I would say no. Just because a URN is resolved to a location does not imply that (a) the location serves it to you, or (b) the location admits that it exists. I suppose that certain types of resolution process might be proprietary, and in that case executing the algorithm might be illegal even if it was independently derived. I have never agreed with this, but that probably has little bearing on reality. >4.2.1 "There is a need for an effective model of name delegation." >This form of words, "there is a need", is becoming all too common. >What is the need? if the need is not satisfied (and it never >will be fully satisfied in practice), does URN resolution become >impossible or merely messy? Well, to the degree that the need is not satisfied things may get messy and/or people may get annoyed. I don't think it is the end of the world, nor is it entirely avoidable, but I do believe that certain design choices can make a difference. In this section I was trying to analyse exactly what people want out of a name and how that interferes with the desired property of longevity. The essential problem is that in the short term people dont generally care about longevity so they do things that may screw them later. The fact is that if what gets built is pretty much good enough, people will use it even if it doesn't really do quite what they want, especially if it is the first thing that came along and everybody's browser understands it. For that reason I think that setting a few design limitations that happen to prevent certain types of predictable disaster might be a good thing overall. >4.2.2 states some obvious things that will be under the control of >NAs, which will do as they please. The behavior of NAs is not >within scope for the IETF, so long as they don't overlap each >other's namespaces. True, but these constraints only affect them if they choose to utilize the system that is being described in section 4. If they want to do something else, they are free to escape to their own entirely separate and unregulated resolution system. (Note that this is a problem for NAPTR as well, although it is not explicitly stated. There are namespaces which do not lend themselves to NAPTR-style decomposition and thus would need to be escaped.) The question is, how restrictive is this really? I have been thinking a lot about this and have found little in the way of problematic counterexamples. >But this admittedly "vague sketch" of strategies is simply too vague, >as it relies on the concept of hints but doesn't describe them, and >ignores the power of supplying as input into the URN resolution system >ancillary information about the URN (hints in reverse, so to speak). True. Our omission of an explanation of hints has caused a great deal of confusion, which this reply has hopefully addressed to a degree. Since we did not have a clear technical plan at the time of writing we did not want to do into a lot of detail; we hoped to instead get out some ideas we were plaing with and see what sort of reactions were generated. As for the idea of `hints in reverse', the URN community should decide if this is within the scope of our problem or whether we want to declare it outside. My opinion is that it is outside; it widens the problem and makes the primary technique for resolution (i.e. precomputed lexical generalization of URNs) impossible. In any case, thanks a lot for the comments. Yours are the first to address any of the ideas in section 4. I have been continuing to work on those ideas, in particular the stuff relating to canonical forms. Following this message I am forwarding a pointer to a small explanation of how various naespaces might be canonicalized on the client side enough to be taken apart by very simple rules. The canonicalization is done by a simple translation program that takes a little ``program'' as input. The idea is to rearrange the URN at the beginning so that the hierarchy goes in one consistent direction; the theory is that after the name is canonicalized the rest of the resolution can be done with very simple ``rules''. Essentially, where NAPTR allows arbitrary rewrite patterns, the simplified rules allow only a few very simple moves, removing characters from the front of the canonicalized string and copying them or replacing them with specified strings. This way most of the data driving the resolution are in this simplified format, which makes it easier to handle and easier to specify from above. Under such a system, a name scheme designer can enforce certain policies about the format and semantics of the names under that scheme, whereas according to the original NAPTR model the top-level name scheme design had no impact on the structure underneath. Such a modified NAPTR resolution mechanism will be able to resolve a very specific subset of all possible namespaces, and the rest will be escaped to other resolution mechanisms. The main difference here (as far as I can tell) is that using the simplified rules it becomes more obvious what naming schemes are possible and which are not. It is not clear that this modification results in any significant reduction in the universe of resolvable name schemes. In fact, NAPTR is not well suited to many types of namespaces. For example, a namespace of MD5 digests of documents could not efficiently be resolved by NAPTR, nor can it be efficiently resolved by this modified system. One name space that the original NAPTR plan can resolve that the modified one can't is a namespace in which there is no pre-defined hierarchy. For example, generalization can be based on flags: URN:flags:girod#paper.ps#about-translation#about-urns contains several #-delimited flags that could be matched (for example, all URNs of that type containing my name go to my resolver, etc.) However, for a number of reasons, this is not currently a useful way of structuring URNs, and if it becomes useful it seems reasonable to build a separate resolution mechanism. 1996-090000666000003600000100000001435706224271704010620 0ustar wwwrunwww Received: from cnri by ietf.org id aa06397; 25 Sep 96 16:14 EDT Received: from uscore.xtdl.com by CNRI.Reston.VA.US id aa01250; 25 Sep 96 16:14 EDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA22349 for ; Wed, 25 Sep 1996 16:12:47 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Sep 1996 16:10:50 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA22103 for pwg-outgoing; Wed, 25 Sep 1996 16:06:11 -0400 (EDT) Message-Id: X-Mailer: Novell GroupWise 4.1 Date: Wed, 25 Sep 1996 14:07:16 -0600 From: Scott Isaacson To: rturner@sharplabs.com Cc: pwg@pwg.org, harryl@vnet.ibm.com Subject: Re: Internet Printing meeting notes Sender: owner-pwg@pwg.org Randy I sent out the notes on the part of the meeting that I took. I sent these to the PWG mailing list. Did they never get distributed? I got a copy but assumed that was from the reflector not just me on the "copy to" list? Did anyone else see them? Scott:   Received: from cnri by ietf.org id aa21630; 25 Sep 96 23:59 EDT Received: from uscore.xtdl.com by CNRI.Reston.VA.US id aa29607; 25 Sep 96 23:59 EDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id XAA25982 for ; Wed, 25 Sep 1996 23:57:39 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 25 Sep 1996 23:55:55 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id XAA25730 for pwg-outgoing; Wed, 25 Sep 1996 23:53:20 -0400 (EDT) Message-Id: <9609260353.AA03801@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 25 Sep 1996 20:51:30 PDT To: Randy Turner From: Tom Hastings Subject: Re: NYC [need to work on the Printer MIB and the Job Monitoring MIB] Cc: "Harry Lewis " , pwg@pwg.org Sender: owner-pwg@pwg.org I'm planning to attend NYC and have my non-refundable tickets in hand. We need to all ping to the mailing list (as well as to Larry), so that we really know what all people's plans are. The first few defectors can start a tidal wave of defections. I'd like to see the Printer MIB finished and NYC looks like the last meeting to work face-to-face. Even if there isn't a hugh turn out, remember that the IETF policy is that nothing is final in a meeting; decisions have to be send to the DL and see what the mailing list actually thinks. So I think it is crucial that we have the NYC meeting for the Printer MIB to help Randy finish this year. Also I'd like to take what ever time is left to continue processing the Job Monitoring MIB document specification, continuing through each object. I was unable to attend San Diego because I was on vacation in Boston and you guys finished early, so that the teleconference that I set up for the afternoon on Friday afternoon to join you didn't happen. At 15:09 09/25/96 PDT, Randy Turner wrote: >In light of Lloyd's recent notes concerning a possible new chair of >the PMP, my own personal schedule for submitting a draft document >to the IETF was the latter part of October, which would give some >IESG review time prior to the December IETF Plenary in San Jose, >where I could receive any feedback face to face at the Network >Management Area Open Meeting. > >This would mean that NYC would be the last face-to-face PWG review >of the MIB document, with finalizing comments accepted only via >the mailing list. I don't know how this jives with what a possible >new WG chair would expect, but our 2 year deadline is up in March >and I don't think we have time to bring in a new chair that does >not have any experience with the MIB or semi-recent PWG experience. > >My time is kinda booked up starting in '97, and I really wanted to >get this submitted prior to the December IETF, it still looks like >a very convenient possibility to me. > >R. > > > >Harry Lewis wrote: >> >> I was anticipating that someone may begin to reach this conclusion: >> >> >You indicated that a "first" occurred after three years: significant poor >> >attendance of a large number of long time members attending. It would >> >be interesting to note why that event occurred. Is it a trend? Is it a >> >coincidence? Is it an indication as to the interest level of what is going >> >on? The location is bad (a given)? I don't know the reason. >> >> I can't speak for everyone, but I don't want anyone to interpret my difficulty >> in attending NYC is a trend or lack of commitment to the PWG or it's efforts. >> >> I don't particularly want to make a distinction between long term >> and recently participating members, either. Working, contributing, >> participating, productive members are ALL very important. >> >> It's no secret that NYC is not a popular location with many of the >> PWG members. Even though I have been one of the most vocal in this >> regard, I would hope it is not perceived that NYC didn't "come off" >> just due to location (as I've said, I've got my tickets in hand). >> >> We all have schedules which become unmanageable at times. I would >> expect any member to miss a meeting or two during a year full of >> 12 meetings. In the case of NYC, we are off to a bad start knowing >> that Jay and Dave can't make it (without rehashing Jay's plea to change >> the meeting). I guess, in this light, Jay's notion of a quorum is valid. >> >> When I made the query, I said I didn't want to collapse the meeting. >> It's beginning to look as if there wasn't much there in the first place. >> I certainly don't want to initiate the collapse of anything greater! >> >> I'm leaning toward not going to NYC. My greatest concern is Printer MIB. >> I feel is that Randy will have to "cut and run" at some point, or we >> miss the target and look for the next one. If someone explains to me >> that the life of the printer MIB is in grave danger if NYC doesn't happen >> then I'll most likely be there. >> >> It sounds like most of our other endeavours are basically on hold until >> November anyway, am I right? >> >> Harry Lewis - IBM Printing Systems > >-- >Randy Turner > >  1996-09.mail0000666000175200000100000004417111373041747011515 0ustar steveywww Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA05529 for urn-ietf-out; Tue, 10 Sep 1996 16:28:35 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA05502 for ; Tue, 10 Sep 1996 16:28:08 -0400 Received: from ns.incog.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16870 (mail destined for urn-ietf@services.bunyip.com); Tue, 10 Sep 96 16:27:01 -0400 Received: from osmosys.incog.com by incog.com (SMI-8.6/94082501) id NAA06179; Tue, 10 Sep 1996 13:21:00 -0700 Received: from spar.incog.com by osmosys.incog.com (SMI-8.6/SMI-SVR4) id NAA11651; Tue, 10 Sep 1996 13:21:32 -0700 Received: from spar by spar.incog.com (SMI-8.6/SMI-SVR4) id NAA22037; Tue, 10 Sep 1996 13:17:48 -0700 Message-Id: <199609102017.NAA22037@spar.incog.com> X-Mailer: exmh version 1.6.4 10/10/95 To: Ron Daniel Cc: "Dirk.vanGulik" , urn-ietf@bunyip.com Subject: Re: [URN] NAPTR to SRV In-Reply-To: Your message of "Mon, 09 Sep 1996 09:18:23 MDT." <2.2.32.19960909151823.006b8498@acl.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 10 Sep 1996 13:17:48 -0700 From: Erik Guttman Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Erik Guttman Errors-To: owner-urn-ietf@bunyip.com > Thus spoke Dirk.vanGulik (at least at 10:04 AM 9/9/96 +0200) > > >Whould it be an idea to insist on using the IANA registered > >service/protocol pairs ? > > > >And if this the case one could 'automagically' construct > >the _service._protocol.hostname query. > > The service/proto fields in SRVs may use either IANA assigned > or locally assigned identifiers. Since they can use locally > assigned names, we need to be able to cope with that, so I would > be very hesitant to impose such a restriction. For locally defined service types, or cases where there are multiple services which are not identical, the Service Location Protocol offers a resolution service. SLP is intended to be used within sites to allow lightweight registration and acquisition of service advertisments. Have you considered resolving some requests using SLP? Erik Guttman Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA28329 for urn-ietf-out; Mon, 9 Sep 1996 12:02:46 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA28324 for ; Mon, 9 Sep 1996 12:02:43 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02152 (mail destined for urn-ietf@services.bunyip.com); Mon, 9 Sep 96 12:02:41 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id JAA26297; Mon, 9 Sep 1996 09:12:18 -0600 (MDT) Message-Id: <2.2.32.19960909151823.006b8498@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 09 Sep 1996 09:18:23 -0600 To: "Dirk.vanGulik" , urn-ietf@bunyip.com From: Ron Daniel Subject: Re: [URN] NAPTR to SRV Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Dirk.vanGulik (at least at 10:04 AM 9/9/96 +0200) >Whould it be an idea to insist on using the IANA registered >service/protocol pairs ? > >And if this the case one could 'automagically' construct >the _service._protocol.hostname query. The service/proto fields in SRVs may use either IANA assigned or locally assigned identifiers. Since they can use locally assigned names, we need to be able to cope with that, so I would be very hesitant to impose such a restriction. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA26911 for urn-ietf-out; Mon, 9 Sep 1996 09:35:32 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA26906 for ; Mon, 9 Sep 1996 09:35:29 -0400 From: ulocat@esort2.recom.edu.ar Received: from mendieta.recyt.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29988 (mail destined for urn-ietf@services.bunyip.com); Mon, 9 Sep 96 09:33:14 -0400 Received: from recom by mendieta.recyt.net with UUCP id <176774-22329>; Mon, 9 Sep 1996 10:25:21 -0300 Received: from esort2 by recom.recom.edu.ar with uucp (Smail3.1.28.1 #2) id m0uzz2b-0002k6C; Mon, 9 Sep 96 08:37 ARG Received: by esort2.recom.edu.ar (UUPC/extended 1.11z); Fri, 06 Sep 1996 10:04:29 ARG Message-Id: <3230215e.esort2@esort2.recom.edu.ar> To: urn-ietf@bunyip.com Date: Fri, 6 Sep 1996 10:04:14 ARG3 Subject: [URN] Priority: normal X-Mailer: Pegasus Mail v3.30 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: ulocat@esort2.recom.edu.ar Errors-To: owner-urn-ietf@bunyip.com Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA11443 for urn-ietf-out; Mon, 9 Sep 1996 04:05:52 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA11436 for ; Mon, 9 Sep 1996 04:05:51 -0400 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29201 (mail destined for urn-ietf@services.bunyip.com); Mon, 9 Sep 96 04:05:43 -0400 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA23826; Mon, 9 Sep 96 10:10:09 +0200 Received: by jrc.it (5.x/EB-950213-L) id AA03740; Mon, 9 Sep 1996 10:04:51 +0200 Date: Mon, 9 Sep 1996 10:04:51 +0200 From: "Dirk.vanGulik" Message-Id: <9609090804.AA03740@ jrc.it> To: urn-ietf@bunyip.com Subject: [URN] NAPTR to SRV X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Dirk.vanGulik" Errors-To: owner-urn-ietf@bunyip.com I've been trying to get all integrated; the apache-module, a small mSQL based resolver and a little glue and display in html logic. I've ran into a couple of points. Whould it be an idea to insist on using the IANA registered service/protocol pairs ? And if this the case one could 'automagically' construct the _service._protocol.hostname query. I.e. Things get simplified to IN NAPTR 10 5 "s" "http+N2L" infoservices.webweaving.org "" IN NAPTR 10 5 "s" "sftp+N2L" infoservices.webweaving.org "" IN NAPTR 10 5 "s" "rcds+N2L" infoservices.webweaving.org "" _http._tcp.infoservices.webweaving.org IN SRV 0 0 80 wwww.infoservices.webweaving.org _rcds._udp.infoservices.webweaving.org IN SRV 0 0 1112 exp.infoservices.webweaving.org Just a thought; because I quite dislike the redundancy in the NAPTR pntr. Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA22445 for urn-ietf-out; Sun, 8 Sep 1996 12:12:27 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA22440 for ; Sun, 8 Sep 1996 12:12:25 -0400 Received: from gizmo.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26933 (mail destined for urn-ietf@services.bunyip.com); Sun, 8 Sep 96 12:12:23 -0400 Received: from mrrl.lut.ac.uk (martin@localhost.mrrl.lut.ac.uk [127.0.0.1]) by gizmo.lut.ac.uk (8.7.5/8.6.9) with ESMTP id RAA01233 for ; Sun, 8 Sep 1996 17:12:16 +0100 (BST) Message-Id: <199609081612.RAA01233@gizmo.lut.ac.uk> To: urn-ietf@bunyip.com X-Uri: Subject: [URN] terminating dots Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <1229.842199135.1@mrrl.lut.ac.uk> Date: Sun, 08 Sep 1996 17:12:15 +0100 From: Martin Hamilton Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin Hamilton Errors-To: owner-urn-ietf@bunyip.com The domain names in the sample NAPTR records from draft-daniel-naptr-01 are missing the closing dot ? Think it should be: _dunslink._udp.isi.dandb.com. rather than: _dunslink._udp.isi.dandb.com Just nitpicking, but it makes quite a difference if you leave that last dot out in the DNS server config... Martin Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA24293 for urn-ietf-out; Tue, 3 Sep 1996 14:07:21 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA24265 for ; Tue, 3 Sep 1996 14:05:55 -0400 Received: from rock.west.ora.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21405 (mail destined for urn-ietf@services.bunyip.com); Tue, 3 Sep 96 14:05:51 -0400 Received: (from terry@localhost) by rock.west.ora.com (8.6.13/8.6.11) id LAA19143; Tue, 3 Sep 1996 11:02:02 -0700 Message-Id: <199609031802.LAA19143@rock.west.ora.com> From: Terry Allen Date: Tue, 3 Sep 1996 11:02:02 PDT In-Reply-To: Ron Daniel "Re: [URN] more info on edits for NAPTR draft" (Sep 3, 10:34am) X-Mailer: Mail User's Shell (7.2.0 10/31/90) To: Ron Daniel , Harald.T.Alvestrand@uninett.no Subject: Re: [URN] more info on edits for NAPTR draft Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com >[POSIX] IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1); IEEE Std 1003.2-1992; ISBN:1-55937-255-9; The Institute of Electrical and Electronics Engineers; New York; 1993. >OK? Okay. I wonder if there is already an FPI for it. Will ask around. Regards, -- Terry Allen O'Reilly & Associates, Inc. terry@ora.com "In going on with these experiments, how many pretty systems do we build, which we soon find ourselves obliged to destroy?" - Benjamin Franklin A Davenport Group sponsor http://www.ora.com/davenport/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA22894 for urn-ietf-out; Tue, 3 Sep 1996 12:30:46 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA22868 for ; Tue, 3 Sep 1996 12:29:13 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20448 (mail destined for urn-ietf@services.bunyip.com); Tue, 3 Sep 96 12:29:12 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA25851; Tue, 3 Sep 1996 10:28:46 -0600 (MDT) Message-Id: <2.2.32.19960903163447.006a70c4@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 03 Sep 1996 10:34:47 -0600 To: Harald.T.Alvestrand@uninett.no From: Ron Daniel Subject: Re: [URN] more info on edits for NAPTR draft Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Harald.T.Alvestrand@uninett.no (at least at 01:08 PM 9/2/96 +0200) >I like EREs too. >The draft should probably cite POSIX by chapter, verse, month, day and >hour of publication about where REGEXP is defined; if we get confusion >about this, the whole thing falls down. Right, will do. The entry for the references section will look like [POSIX] IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1); IEEE Std 1003.2-1992; ISBN:1-55937-255-9; The Institute of Electrical and Electronics Engineers; New York; 1993. While the citation in the text will point people to section 2.8.4 "Extended Regular Expressions" of [POSIX]. OK? Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hypernym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA10787 for urn-ietf-out; Mon, 2 Sep 1996 16:44:02 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA10782 for ; Mon, 2 Sep 1996 16:44:00 -0400 Received: from rock.west.ora.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15164 (mail destined for urn-ietf@services.bunyip.com); Mon, 2 Sep 96 16:43:56 -0400 Received: (from terry@localhost) by rock.west.ora.com (8.6.13/8.6.11) id NAA20398 for urn-ietf@bunyip.com; Mon, 2 Sep 1996 13:41:41 -0700 Message-Id: <199609022041.NAA20398@rock.west.ora.com> From: Terry Allen Date: Mon, 2 Sep 1996 13:41:41 PDT X-Mailer: Mail User's Shell (7.2.0 10/31/90) To: urn-ietf@bunyip.com Subject: [URN] Re URN concerns Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com [lost my electronic copy, so typed in the quotes from printed version] Karen Sollins writes: "I have a couple of concerns ... It seems that in discussion, whether or not in the text of the documents, the authors of the NAPTR framework and proposal papers want to provide resolution for all possible namespace schemes." I hope so. That is the problem as I see it. Karen continues: "Perhaps we would all be better off and have a higher probability of success, if we identified a smaller set of namespaces to which we were addressing out attention." I don't see where there is lack of success brewing. - It is up to namespace resolvers to resolve URNs to something else such as URLs. The NAPTR scheme can't guarantee that will happen, only that the client gets pointed at the right resolver. - You can make a more elegant solution by restricting the problem, but then you haven't solved the real problem. Suggestions for how to create easily manageable name spaces are worth making, but people will do what they will do. Restricting the namespaces that the point-client-toward-resolver mechanism can use fails to solve the real world problem, and guarantees that the solution will fail to cover all real world cases, making it useless. - Instead of viewing opaque strings as a problem, it would be useful to accept that they exist and can be exploited; regexps (funky though they are) appear to this lost soul to be a way to exploit info that may be known to reside in opaque strings. - It's time to get the show on the road. I am looking forward to being able to provide hands-off resolution of Docbook DTD entities using NAPTR and the Docbook FPIs. When ANSI appoints a formal registration authority (currently thought to be the Graphic[al]? Communications Association, GCA), the registry that GCA has already set up can point to the Davenport site, which already exists, and we can resolve FPIs both registered and unregistered. Talking about how it would be nicer if we could constrain how naming schemes work is unrealistic (we can't, and no one has offered a counterargument that we can), and dilatory. Beyond that, SGML *is* coming to the Internet, and fairly soon. Modern SGML entity resolution depends on FPIs and catalogues containing them. FPIs are made up by humans, and beyond the owner identifier and the (nonhierarchically placed) field indicating (uselessly) whether an FPI applies to an element, entity, DTD, etc., there is a lot of opportunity (which has already been taken advantage of) for messiness. There is thus a practical need to be able to resolve any FPI anyone may assign or has already assigned. Constraining FPI construction beyond the rules in (I believe) ISO 9070 is a nonstarter. Regards, -- Terry Allen O'Reilly & Associates, Inc. terry@ora.com "In going on with these experiments, how many pretty systems do we build, which we soon find ourselves obliged to destroy?" - Benjamin Franklin A Davenport Group sponsor http://www.ora.com/davenport/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id HAA04399 for urn-ietf-out; Mon, 2 Sep 1996 07:09:29 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id HAA04394 for ; Mon, 2 Sep 1996 07:09:26 -0400 From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13525 (mail destined for urn-ietf@services.bunyip.com); Mon, 2 Sep 96 07:09:25 -0400 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <06282-0@domen.uninett.no>; Mon, 2 Sep 1996 13:08:54 +0200 X-Mailer: exmh version 1.6.7 5/3/96 To: Ron Daniel Cc: urn-ietf@bunyip.com Subject: Re: [URN] more info on edits for NAPTR draft In-Reply-To: Your message of "Thu, 29 Aug 1996 17:16:01 MDT." <2.2.32.19960829231601.006980e8@acl.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 02 Sep 1996 13:08:50 +0200 Message-Id: <6279.841662530@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com I like EREs too. The draft should probably cite POSIX by chapter, verse, month, day and hour of publication about where REGEXP is defined; if we get confusion about this, the whole thing falls down. harald A 1996-100000666000003600000100000005166106236437261010614 0ustar wwwrunwww Received: from cnri by ietf.org id aa19514; 2 Oct 96 1:52 EDT Received: from uscore.xtdl.com by CNRI.Reston.VA.US id aa02586; 2 Oct 96 1:52 EDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id BAA11031 for ; Wed, 2 Oct 1996 01:51:08 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 2 Oct 1996 01:47:26 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id BAA10094 for pwg-outgoing; Wed, 2 Oct 1996 01:37:18 -0400 (EDT) Message-Id: <9610020537.AB05463@zazen> X-Sender: hastings@zazen (Unverified) X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 1 Oct 1996 22:35:04 PDT To: JK Martin From: Tom Hastings Subject: Re: IEEE P1284.1 Ballot Resolution Committee Cc: don@lexmark.com, lstein@fapo.com, andyd@pogo.wv.tek.com, rturner@sharplabs.com, Gail.Songer@eng.efi.com, jkm@underscore.com, RoachDL@po3.pl.unisys.com, Private_User@lexmark.com, pwg@pwg.org Sender: owner-pwg@pwg.org Since Jay has "set the record straight" in previous mail abuot network printing pioneers, I thought I set the record straight about "network printing protocol standards". At 13:46 09/20/96 PDT, JK Martin wrote: >Don, > >After spending considerable time on the IEEE 1284.1 TIPSI spec, >I was very much looking forward to reviewing the public comments >that resulted from the IEEE ballot process. > >As it currently stands within the general printing industry, >IEEE 1284.1 (TIPSI) is the only network printing protocol that >can be considered truly standard (and open). ISO 10175 Document Printing Application (DPA) was approved as an ISO standard in the Spring of 1996, so it is already a network printing protocol that is truly standard (and open). DPA is not going through the final stages of reviewing public comments. That happened several years ago and the document took a year or more to incorporate the comments. These comments were submitted by companies implementing the drafts. At present ISO DPA is implemented in a number of products: IBM's PSM, Digital/Sun/Xerox Printxchange, Novell's NDPS, DAZEL's DAZEL, as well as a pulic domain prototype implemenation at MIT, called MIT Palladium, which should still be available via FTP from athena.mit.edu. See the /dpa subdirectory on the ftp://ftp.pwg.org/pub/pwg/snmpmib/dpa/ for information. When TIPSI is finished with its public comment period and the comments have been incorporated in IEEE 1284.1 then TIPSI can join the ranks with ISO DPA as a "network printing protocol that can be considered truly standard (and open)." Tom P.S. I also favor moving the TIPSI review to Wednesday so that more PWG folks can participate.   Received: from cnri by ietf.org id aa16115; 2 Oct 96 19:31 EDT Received: from uscore.xtdl.com by CNRI.Reston.VA.US id aa24994; 2 Oct 96 19:31 EDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA13721 for ; Wed, 2 Oct 1996 19:29:56 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Wed, 2 Oct 1996 19:27:22 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA13471 for pwg-outgoing; Wed, 2 Oct 1996 19:23:15 -0400 (EDT) Message-Id: <9610022323.AA04694@cayuga> X-Sender: stanmcc@cayuga X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 2 Oct 1996 08:20:56 PDT To: Tom Hastings From: Stan McConnell Subject: Re: IEEE P1284.1 Ballot Resolution Committee Cc: JK Martin , don@lexmark.com, lstein@fapo.com, andyd@pogo.wv.tek.com, rturner@sharplabs.com, Gail.Songer@eng.efi.com, jkm@underscore.com, RoachDL@po3.pl.unisys.com, Private_User@lexmark.com, pwg@pwg.org Sender: owner-pwg@pwg.org At 22:35 10/1/96 PDT, you wrote: >Since Jay has "set the record straight" in previous mail abuot network >printing pioneers, I thought I set the record straight about "network >printing protocol standards". > >. . . > >ISO 10175 Document Printing Application (DPA) was approved as an ISO standard >in the Spring of 1996, so it is already a network printing protocol >that is truly standard (and open). >. . . I have just received my complementary copy of ISO/IEC 10175-1 from the ISO Central Secretariat. So it is now *OFFICIAL*! [as well as standard (and open)] Stan . . .   Received: from cnri by ietf.org id aa02008; 7 Oct 96 10:51 EDT Received: from uscore.xtdl.com by CNRI.Reston.VA.US id aa11034; 7 Oct 96 10:51 EDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA19735 for ; Mon, 7 Oct 1996 10:50:10 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Mon, 7 Oct 1996 10:48:29 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA19466 for pwg-outgoing; Mon, 7 Oct 1996 10:46:58 -0400 (EDT) Message-Id: <01BBB42B.78142480@hpb15767.boi.hp.com> From: Bob Pentecost To: "pwg@pwg.org" , 'Randy Turner' Subject: Updated MIB spec Date: Mon, 7 Oct 1996 08:42:26 -0600 Encoding: 10 TEXT Sender: owner-pwg@pwg.org Randy, When do you plan to publish an updated "Printer MIB"? Am I correct in assuming that this next revision will be the one taken for approval in December? Bob Pentecost HP   Received: from cnri by ietf.org id aa09743; 15 Oct 96 10:34 EDT Received: from uscore.xtdl.com by CNRI.Reston.VA.US id aa11902; 15 Oct 96 10:34 EDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id KAA09712 for ; Tue, 15 Oct 1996 10:32:49 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Oct 1996 10:30:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id KAA09465 for pwg-outgoing; Tue, 15 Oct 1996 10:29:13 -0400 (EDT) Message-ID: <32639F2E.7DE14518@underscore.com> Date: Tue, 15 Oct 1996 10:26:54 -0400 From: Jeff Schnitzer Organization: Underscore, Inc. X-Mailer: Mozilla 3.0 (X11; I; SunOS 4.1.3_U1 sun4m) MIME-Version: 1.0 To: rturner@sharplabs.com CC: pwg@pwg.org Subject: Re: prtMagicCookie updated proposal References: <32634100.60D8@sharplabs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-pwg@pwg.org Randy Turner wrote: > > I uploaded a copy of my proposal to revise David Kellerman's > earlier prtMagicCookie channel fix. The document is in: > > ftp://ftp.pwg.org/pub/pwg/snmpmib/proposals/cookie_rev.doc > > I'm assuming this is one of the topics for the teleconference. > > R. I've put a plain text version of Randy's document on the server as ftp://ftp.pwg.org/pub/pwg/snmpmib/proposals/cookie_rev.txt And, since its only a bit over a page long, I'm taking the liberty to also append it to the end of this message. /Jeff --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- --Text of ftp://ftp.pwg.org/pub/pwg/snmpmib/proposals/cookie_rev.doc from Randy Turner , 15 Oct 1996: At the New York meeting of the PWG, the attendees decided that the prtMagicCookie string should be both human readable, as well as unambiguously machine parsable. This proposal seeks to elaborate on the earlier prtMagicCookie proposal with a mechanism to allow both of these features to be supported by the prtMagicCookie string. For purposes of clarity, I would like to suggest that the data type used to represent the prtMagicCookie string be a "DisplayString" object type. This forces implementers to make sure that this string is displayable and human readable. In addition, I would like to propose that a prtMagicCookie "grammar" be used to describe the contents of this string. The rationale behind the grammar is to solve the machine-parsability requirement decided on previously. This cookie grammar or syntax would also be human readable and could be stored in the MIB as an additional object within the channel group, or, it could be a requirement for registering channel types and associated applications in a global registry managed by IANA or other sanctioned organization. I would like to propose two solutions to the grammar/syntax string. The first proposal would be that we use a standard C language scanf/printf format string to describe the contents of the prtMagicCookie string. As an example, to describe an implementation of LPD within an agent that implements several control file extensions such as Sun or Xerox, the following syntax string could be used: "Line Printer Daemon (LPD) Vendor %s Version %d Port %d Options %s" In this example, an automated job delivery client attempting to discover how to send jobs to LPD would know that LPD is supported through the prtChannelType. It could then read the syntax string and discover which vendor's implementation is being used, the version number, the TCP port used for this implementation, as well as any extended control file options not specified by the RFC 1179 standard; this options string could consist of control file option letters like "W,Z,X" or some other string. Likewise, a Novell print server could utilize a grammar string like: "Novell PSERVER %s Fileserver %s Options %s" This would give potential print clients the PSERVER name for this printer, as well as a preferred file server on which the queues for this PSERVER reside. Other options could also be specified as well in the "Options" string. The syntax/grammar specification would be owned by the vendor or organization that is registering the channel type. Again, this proposal does not suggest whether this syntax/grammar string is implemented as an object within the MIB, or as a required field in a channel type registration form. The format of the grammar/syntax string can be taken verbatim from the standard ANSI C language description of the printf/scanf format descriptor. Another descriptor format that could be used would be a Backus-Naur Format (BNF) syntax for the grammar/syntax string. This is somewhat more powerful than the previous print/scanf format, and allows optional fields to be inserted in the string. Instead of BNF, a regular expression could be used/specified to describe the contents of the DisplayString fields. In my opinion, the C language printf/scanf format string would be easier to implement and meet most of our requirements. --   Received: from cnri by ietf.org id aa12103; 15 Oct 96 11:19 EDT Received: from uscore.xtdl.com by CNRI.Reston.VA.US id aa13422; 15 Oct 96 11:19 EDT Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id LAA10039 for ; Tue, 15 Oct 1996 11:17:24 -0400 (EDT) Received: by pwg.org (bulk_mailer v1.5); Tue, 15 Oct 1996 11:15:32 -0400 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id LAA09796 for pwg-outgoing; Tue, 15 Oct 1996 11:12:08 -0400 (EDT) Message-Id: <01BBBA78.9AD96180@hpb15767.boi.hp.com> From: Bob Pentecost To: 'Jeff Schnitzer' , "rturner@sharplabs.com" Cc: "pwg@pwg.org" Subject: RE: prtMagicCookie updated proposal Date: Tue, 15 Oct 1996 09:09:41 -0600 Encoding: 147 TEXT Sender: owner-pwg@pwg.org The title and first paragraph were missing from Jeff's version of Randy's proposal. I've added them below.Bob PentecostHP ---------- From: Jeff Schnitzer[SMTP:jds@underscore.com] Sent: Tuesday, October 15, 1996 8:27 AM To: rturner@sharplabs.com Cc: pwg@pwg.org Subject: Re: prtMagicCookie updated proposal Randy Turner wrote: > > I uploaded a copy of my proposal to revise David Kellerman's > earlier prtMagicCookie channel fix. The document is in: > > ftp://ftp.pwg.org/pub/pwg/snmpmib/proposals/cookie_rev.doc > > I'm assuming this is one of the topics for the teleconference. > > R. I've put a plain text version of Randy's document on the server as ftp://ftp.pwg.org/pub/pwg/snmpmib/proposals/cookie_rev.txt And, since its only a bit over a page long, I'm taking the liberty to also append it to the end of this message. /Jeff --------------------------------------------------------------- Jeffrey D. Schnitzer | Email: jds@underscore.com Underscore, Inc. | Voice: (603) 889-7000 41-C Sagamore Park Rd | Fax: (603) 889-2699 Hudson, NH 03051-4915 | Web: http://www.underscore.com --------------------------------------------------------------- --Text of ftp://ftp.pwg.org/pub/pwg/snmpmib/proposals/cookie_rev.doc from Randy Turner , 15 Oct 1996: Proposal to Printer Working Group Revisions to "PrtMagicCookie" Proposal The idea put forth in David Kellerman's earlier prtMagicCookie proposal was to simplify the mechanics of instrumenting the channels group for usability with minimal object additions. The prtMagicCookie string was a way to further extend the object type "prtChannelType" with whatever information was necessary to actual utilize a channel from a remote entity., i.e., if a channel type description was " a bidirectional TCP port used for print job delivery", then the prtMagicCookie string would contain the actual TCP port number upon which such a connection could be built. The prtMagicCookie was basically put forth as a way to include in one object any parameterization that might be required to actually utilize a particular prtChannelType. At the New York meeting of the PWG, the attendees decided that the prtMagicCookie string should be both human readable, as well as unambiguously machine parsable. This proposal seeks to elaborate on the earlier prtMagicCookie proposal with a mechanism to allow both of these features to be supported by the prtMagicCookie string. For purposes of clarity, I would like to suggest that the data type used to represent the prtMagicCookie string be a "DisplayString" object type. This forces implementers to make sure that this string is displayable and human readable. In addition, I would like to propose that a prtMagicCookie "grammar" be used to describe the contents of this string. The rationale behind the grammar is to solve the machine-parsability requirement decided on previously. This cookie grammar or syntax would also be human readable and could be stored in the MIB as an additional object within the channel group, or, it could be a requirement for registering channel types and associated applications in a global registry managed by IANA or other sanctioned organization. I would like to propose two solutions to the grammar/syntax string. The first proposal would be that we use a standard C language scanf/printf format string to describe the contents of the prtMagicCookie string. As an example, to describe an implementation of LPD within an agent that implements several control file extensions such as Sun or Xerox, the following syntax string could be used: "Line Printer Daemon (LPD) Vendor %s Version %d Port %d Options %s" In this example, an automated job delivery client attempting to discover how to send jobs to LPD would know that LPD is supported through the prtChannelType. It could then read the syntax string and discover which vendor's implementation is being used, the version number, the TCP port used for this implementation, as well as any extended control file options not specified by the RFC 1179 standard; this options string could consist of control file option letters like "W,Z,X" or some other string. Likewise, a Novell print server could utilize a grammar string like: "Novell PSERVER %s Fileserver %s Options %s" This would give potential print clients the PSERVER name for this printer, as well as a preferred file server on which the queues for this PSERVER reside. Other options could also be specified as well in the "Options" string. The syntax/grammar specification would be owned by the vendor or organization that is registering the channel type. Again, this proposal does not suggest whether this syntax/grammar string is implemented as an object within the MIB, or as a required field in a channel type registration form. The format of the grammar/syntax string can be taken verbatim from the standard ANSI C language description of the printf/scanf format descriptor. Another descriptor format that could be used would be a Backus-Naur Format (BNF) syntax for the grammar/syntax string. This is somewhat more powerful than the previous print/scanf format, and allows optional fields to be inserted in the string. Instead of BNF, a regular expression could be used/specified to describe the contents of the DisplayString fields. In my opinion, the C language printf/scanf format string would be easier to implement and meet most of our requirements. --   Received: from ietf.org by ietf.org id aa27243; 31 Oct 96 10:14 EST Received: from localhost by ietf.org id aa25602; 31 Oct 96 10:01 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: urn-ietf@bunyip.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-syntax-00.txt Date: Thu, 31 Oct 1996 10:01:29 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9610311001.aa25602@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : URN Syntax Author(s) : R. Moats Filename : draft-ietf-urn-syntax-00.txt Pages : 5 Date : 10/30/1996 Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers. This document presents the syntax for URNs. Support for existing legacy namespaces is discussed. URN transmission encoding requirements are presented. Finally, there is a discussion of URN equivalence and how to determine it. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-syntax-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-syntax-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961030141208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-syntax-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-syntax-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961030141208.I-D@ietf.org> --OtherAccess-- --NextPart--  1996-10.mail0000666000175200000100000243373011373042012011474 0ustar steveywww Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA22246 for urn-ietf-out; Thu, 31 Oct 1996 19:49:27 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA22241 for ; Thu, 31 Oct 1996 19:49:15 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01057 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 19:49:11 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id RAA11512; Thu, 31 Oct 1996 17:25:32 -0700 (MST) Message-Id: <2.2.32.19961101003319.00733d88@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Oct 1996 17:33:19 -0700 To: "Karen R. Sollins" , urn-ietf@bunyip.com From: Ron Daniel Subject: Re: [URN] some comments Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Karen R. Sollins (at least at 07:02 PM 10/29/96 -0500) >Now, my one other comment relates to an earlier topic - security. I >am in complete agreement with Ron (and whoever else) who said that >security (and let's make sure we include integrity of the information >in "security") that no one (user or publisher) should be required to >support security and integrity. But...if the infrastructure >supporting URN resolution (which IS the topic of discussion for this >WG) is to be able to provide security and integrity for anyone, there >may be some requirements it will place on its clients (users and >publishers). I would like to be confident that we are all in >agreement about the following: in the case where there are security >measures that must be in place within the infrastructure in order to >provide security (at some agreed upon level) to those who want it, >even if that imposes some security requirements on those who don't >want it, that the choice of having the security mechanisms in place >will take precedence over not have the mechanisms. Of course, within >that constraint, wherever security isolation can be provided, security >mechanisms should NOT be required. To paraphrase: 1) Karen agrees that we should not *require* users or publishers to support security but 2) If the resolution infrastructure is such that no-one can enjoy a high level of security unless some requirements are placed on all participants of the system then 3) We should go for requiring modest levels of security on all participants rather than precluding people from operating as securely as they want. I totally support the goal of allowing people to have high security if they want it. That is why I am in total, adamant, and unequivocal opposition to the assumption in part 2 - that there might be a URN resolution system with such poor isolation between security domains. I work at a place that is willing to spend lavishly on securing our information. Call us cowards, but we are unwilling to rely on the good will of millions of people around the world and the correct configuration of their machines. We are not alone in this fear. Consider Cogswell Cogs and Spacely Sprockets. Should either be willing to rely on the good behavior of their mortal competitor? A URN resolution system that can only achieve high levels of security for some sites and the parties to their security policy by assuming *any* security at sites outside that policy is broken. It is unprotected against insider attacks, because it makes everyone in the world an insider. You can't assume that all the systems around the world are participating in some friendly alliance. You have to assume that those people may be out to get you. Let's take the case of client software and integrity checking. Lets assume I am ParanoidPublishers, Inc. who will, with probability 99.9%, only give out the URLs for my publications to clients who can validate my signature on the URLs. That's my policy. SubversiveClients, Ltd. puts out a browser that says to me "sure, I do signature validation, you betcha". Should I believe them? I should send them a test and say, "Great, then you won't mind looking at these 10 URLs, each with a different signature, trying to validate them all, and then contacting the resolver that is at the only URL signed with my real key. BTW, all the other URLs set off an automated counter-attack". At the "real" resolver, the probability of the client lying to you is now 1 in 10. Repeat the process to make the probability 1 in 100, then 1 in 1000. Happy Halloween, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA19876 for urn-ietf-out; Thu, 31 Oct 1996 15:56:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA19871 for ; Thu, 31 Oct 1996 15:56:34 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28840 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 15:56:31 -0500 Message-Id: <9610312056.AA28840@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Thu Oct 31 14:55 CST 1996 From: "Ryan Moats" To: "Gregory J. Woodhouse" , "Martin J Duerst" Cc: "urn-ietf@bunyip.com" Date: Thu, 31 Oct 96 14:56:43 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] UTF-8/ASCII (was: New Syntax Draft) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Thu, 31 Oct 1996 05:54:38 -0800 (PST), Gregory J. Woodhouse wrote: >On Thu, 31 Oct 1996, Martin J Duerst wrote: > >> Gregory Woodhouse wrote: >> >> This difference is always absolutely clear! A string that only contains >> bytes with the high bit '0' (7-bit bytes) is ASCII. As soon as a high >> bit is set to '1', it's not ASCII anymore. It may be UTF-8, or may not. >> >I understand this point, but I'm not talking about UTF-8 itself, but UTF-8 >encoded into ASCII. At the risk of being obvious, any UTF-8 encoded to ASCII (according to the syntax doc) is going to have a leading octet encoded as something in the %80-%FF range. Anything in the %00-%7F range is an unsafe (based on one definition or another) ASCII character. However, I think this is somewhat moot (I think this argues for removing the UTF-8 decoding requirement.) Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA19791 for urn-ietf-out; Thu, 31 Oct 1996 15:53:05 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA19786 for ; Thu, 31 Oct 1996 15:53:03 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28793 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 15:52:58 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id MAA23504; Thu, 31 Oct 1996 12:51:25 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id MAA10123; Thu, 31 Oct 1996 12:51:48 -0800 (PST) Date: Thu, 31 Oct 1996 12:51:48 -0800 (PST) From: Terry Allen Message-Id: <199610312051.MAA10123@ishtar.fsc.fujitsu.com> To: leslie@bunyip.com, liberte@ncsa.uiuc.edu Subject: Re: Names and Locations (was [URN] some comments) Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com | > > You made the curious statement that URNs identify resources while URLs | > > identify locations. I'm not sure whether that was a slip, but to my | > > mind, a URL *IS* a location that identifies a resource. Now you also | > URLs identify a particular location for a resource. | OK, what is a location? Is it the bits on the disk that "has" the | resouce? (The disk might be shared by many servers, so the resource | has a different "location" for each server.) Is it the server running | at a particular IP address and port, that may share many disks with | other servers? (The server may be a virtual server that runs on many | machines, and the particular IP address is irrelevant.) Is it the | domain name of the server, together with the path within the server? | That's getting closer to the abstraction that URLs provide. Is the | location, in fact, the URL itself? No, the URL is neither the location nor the resource, but the name of a location, or a name of a location that may be resolved on the fly. The location is not the resource; the name of the location is not the name of the resource. | Consider caches. The resolution of a URL via a cache proxy may find | the resource in the cache rather than in some remote server. What is | "the location" of the resource in that case? What is "the resource"? Any copy of what you got back from resolution? then its location is both in the cache and on the remote server. Is it "the copy I got back from resolution"? then its location is in the cache. | Here is an example of how what is thought of as a location really | turns out to *be* a name (as in persistent location). Take a normal | http URL such as http://www.ncsa.uiuc.edu/. Instead of using normal | HTTP to resolve the URL, or to look it up in a cache, let's set up a | NAPTR-based "http" naming authority. Under that branch of the name | space, we could ask the appropriate DNS server to look up | 'www.ncsa.uiuc.edu' to find out where a server is currently located | and what "resolution protocols" are currently supported. That is a coincidence of naming: you made the name of the resource (qua URN) be the same as the name of its location. But urn:http://www.ncsa.uiuc.edu/ and url:http://www.ncsa.uiuc.edu/ name two different things. | We don't need to create a new kind of identifier to make a URL into a | persistent location. Which is not what you did in the example just given. You created a new name space and rules for using it that by design produce a name that looks like a URL which, when resolved, will give the same result. | To summarize, both URLs and URNs have the following abstract | resolution process in common: | 1. Do some client-specific processing of the URI - maybe end there. | 2. Look at the scheme name of the URI. If it says "URN:" drop it and repeat. No, you have to branch into your "find URN" subprocess. | 3. Look up the scheme in local table to find out what process should The local table will be different for URLs and URNs, will it not? | be invoked. E.g. news URIs may use NNTP, http URIs may use HTTP, | cid URIs may use NAPTR-protocol. | 4. Invoke the process identified by step 3. | 5. If error results, exit. | 6. If redirected to another URI, repeat whole process with that URI. | | An alternative to steps 2 and 3 would use more than just the scheme | name to determine what process to invoke. There are several other | varients possible in the whole process, and each client or each user | might do things differently. | | I hope I've made my postion very clear regarding names, locations, and | the resolution process. That you see no difference between objects and their locations? (apologies for the "ig" subject line in a previous post) Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA19771 for urn-ietf-out; Thu, 31 Oct 1996 15:52:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA19766 for ; Thu, 31 Oct 1996 15:52:13 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28783 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 15:52:09 -0500 Message-Id: <9610312052.AA28783@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Thu Oct 31 14:51 CST 1996 From: "Ryan Moats" To: "Gregory J. Woodhouse" , "Martin J Duerst" Cc: "urn-ietf@bunyip.com" Date: Thu, 31 Oct 96 14:52:22 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] More on UTF-8 Decoding (was: New syntax draft) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Thu, 31 Oct 1996 14:38:57 +0100 (MET), Martin J Duerst wrote: >Gregory Woodhouse wrote: > >>I'm also concerned because decoding requires knowledge that the string >>being decoded is UTF-8. > >Not exactly. It is very rare that a string that is not UTF-8 looks >like an UTF-8 string. > >>I said before that I wasn't terribly excited about >>using RFC 1522 style encodings, > >Me neither! "charset" is okay for long mails, and RFC 1522 was unavoidable >at the time it was created, but now we have better solutions. > I think this is a good argument for taking UTF-8 decoding out of the syntax document. Any reasons to leave it in? Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA19705 for urn-ietf-out; Thu, 31 Oct 1996 15:49:42 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA19698 for ; Thu, 31 Oct 1996 15:49:36 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28755 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 15:49:28 -0500 Message-Id: <9610312049.AA28755@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Thu Oct 31 14:48 CST 1996 From: "Ryan Moats" To: "Gregory J. Woodhouse" , "Martin J Duerst" Cc: "urn-ietf@bunyip.com" Date: Thu, 31 Oct 96 14:49:42 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] What is %encoding (was: New syntax draft) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Thu, 31 Oct 1996 05:15:43 -0800 (PST), Gregory J. Woodhouse wrote: >By %encoding I assume you mean hex encoding of non-ASCII or non-safe bytes. >Is there an official name for this encoding scheme? I've seen it called URL >encoding, but that hardly seems satisfactory. %encoding refers to %HH encoding of octets. I do make this point in section 1.2. As to the name, I've had it referred to as "%encoding" in several pieces of mail to me, so that is what I'm using. If somebody has a better name that is acceptable to folks, I'll be happy to change it. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA19391 for urn-ietf-out; Thu, 31 Oct 1996 15:29:10 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA19386 for ; Thu, 31 Oct 1996 15:29:08 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28199 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 15:29:04 -0500 Message-Id: <9610312029.AA28199@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Thu Oct 31 14:28 CST 1996 From: "Ryan Moats" To: "Martin J Duerst" Cc: "urn-ietf@bunyip.com" Date: Thu, 31 Oct 96 14:29:20 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] New syntax draft (was: no subject) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Thu, 31 Oct 1996 11:58:35 +0100 (MET), Martin J Duerst wrote: >> It should be noted that certain characters in the Namespace Specific >> String syntax may have special meaning in certain namespaces. >> Therefore, the process of registering a namespace identifier shall >> include publication of a definition of which characters have a >> special meaning and how to encode these characters if used in a >> literal sense. > >Can they be encoded with %HH? Or should we specifically request some >other mechanism in order to not confuse different things, and let >programs that deal with URNs in general change from %HH to 8-bit >and back? Well, I don't have a current opinion one way or the other. Thinking about it some more, I don't see how we can avoid %HH encoding, so why not just say that encoding must be specified if %HH isn't used. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA19360 for urn-ietf-out; Thu, 31 Oct 1996 15:27:53 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA19355 for ; Thu, 31 Oct 1996 15:27:48 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28185 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 15:27:35 -0500 Message-Id: <9610312027.AA28185@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Thu Oct 31 14:25 CST 1996 From: "Ryan Moats" To: "Martin J Duerst" Cc: "urn-ietf@bunyip.com" Date: Thu, 31 Oct 96 14:27:15 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] UTF-8 Decoding (was New syntax draft) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com I've found some time to answer this (at least in part...) On Thu, 31 Oct 1996 11:58:35 +0100 (MET), Martin J Duerst wrote: >> URN resolvers MUST be capable of accepting URNs that have been >> %encoded for either 8-bit clean or 7-bit transports. %encoding is >> removed first, then UTF-8 decoding is performed. URN resolvers MUST >> return identical results from ANY legally encoded form of the URN. > >I wonder about UTF-8 decoding. It somehow implies that resolvers >work with Unicode internally, which would be fine, but is not >necessary. For database lookup and equality checks, staying with >UTF-8 will also be okay. For things such as regular expressions, >some additional definitions are necessary as to what the regular >expressions are working on (i.e. characters or octets), but still >it could work in UTF-8. > >Also, what does UTF-8 decoding mean for an NSS that is not UTF-8? That is an interesting point. Let me go back and think about it. Maybe we can remove this requirement. We talk about equivalency at the UTF-8 level later so maybe we can remove the reference to UTF-8 decoding here... Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA19280 for urn-ietf-out; Thu, 31 Oct 1996 15:14:23 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA19269 for ; Thu, 31 Oct 1996 15:14:20 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27981 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 15:14:17 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id NAA06913; Thu, 31 Oct 1996 13:14:12 -0700 (MST) Message-Id: <2.2.32.19961031202159.00699568@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Oct 1996 13:21:59 -0700 To: Daniel LaLiberte , Larry Masinter From: Ron Daniel Subject: Re: [URN] HTTP resolution protocol Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Daniel LaLiberte (at least at 03:30 PM 10/30/96 -0600) >Larry Masinter writes: > > I think some people would say that > > > > GET / HTTP/1.0 > > > > is not valid HTTP. > >I was wondering about that. Maybe Ron meant: > > GET // HTTP/1.0 My mistake, I should have had the initial "/". > > New services need new methods. I have had some off-list mail about defining new HTTP methods for the various resolution service requests (N2C is the most frequent suggestion, but any of them could be handled this way). The draft did not clearly state my goal for the http resolution protocol, which was to have something that could be very easily deployed for initial tests. Backward compatability with existing servers was a goal. I wanted something where people could either add a script to their cgi-bin directory or even just create a new directory and plop files into it. It may be that the rest of the list thinks such a goal is inappropriate. Certainly there is the potential for conflict if a site already had "N2L" in its URLs. (Although an AltaVista search for url:N2L didn't find anything). A possible compromise position is: 1) N2R is encoded as GET uri, not GET /N2R/uri 2) new HTTP methods are defined for other resolution service requests, so we would issue requests like N2C uri HTTP/1.x (versioning of the HTTP protocol may be an issue here). 3) N2L is treated as a special case because of its importance and is still encoded as GET /N2L/uri HTTP/1.0 (or 1.1) Opinions? Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA19270 for urn-ietf-out; Thu, 31 Oct 1996 15:14:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA19262 for ; Thu, 31 Oct 1996 15:14:17 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27979 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 15:14:16 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id NAA06916; Thu, 31 Oct 1996 13:14:13 -0700 (MST) Message-Id: <2.2.32.19961031202200.0070afc8@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Oct 1996 13:22:00 -0700 To: Terry Allen , urn-ietf@bunyip.com From: Ron Daniel Subject: [URN] Re: ig Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Terry Allen (at least at 11:52 AM 10/31/96 -0800) >That's good, but I can't find any way to use Accept: to limit >the absolute number of resources that the client is willing >to receive. Have I missed it? No, Accept: was intended to be used for returning one and only one version of a resource. N2Rs is rather strange for HTTP, so none of its headers are going to be intended for such a context. (But they accomodate it easily, 200 OK is still 200 OK). >An image library might have scads of GIFs of the same object: >the Parthenon in 1932, the P in 1964, the P at sunrise, the P >under moonlight ... but it will be difficult to know in advance >how to twiddle the Accept: information so as not to be inundated >by Parthenons in response. They may have lots of images of the same object, but I doubt that those images will have identical URNs. More likely is where we have something like a Kodak PhotoCD with the same image at different resolutions. N2Rs would return a multipart with all those different resolutions. > Or maybe that's okay and users should >be warned that they may get more than the bargained for when they >use N2Rs? That's my attitude, but then I tend toward the "let them shoot their foot off" approach. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA18846 for urn-ietf-out; Thu, 31 Oct 1996 14:59:14 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA18841 for ; Thu, 31 Oct 1996 14:59:10 -0500 Received: from newton.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27671 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 14:57:53 -0500 Received: from carlyle.ncsa.uiuc.edu (carlyle.ncsa.uiuc.edu [141.142.230.144]) by newton.ncsa.uiuc.edu (8.6.11/8.6.12) with ESMTP id NAA16767; Thu, 31 Oct 1996 13:56:41 -0600 Received: from ncsa.uiuc.edu (void.ncsa.uiuc.edu [141.142.103.20]) by carlyle.ncsa.uiuc.edu (8.6.11/8.6.9) with ESMTP id NAA29904; Thu, 31 Oct 1996 13:56:40 -0600 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id NAA10608; Thu, 31 Oct 1996 13:51:04 -0600 (CST) Date: Thu, 31 Oct 1996 13:51:04 -0600 (CST) From: Daniel LaLiberte Message-Id: <199610311951.NAA10608@ncsa.uiuc.edu> To: leslie@bunyip.com (Leslie Daigle) Cc: urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: <199610310907.EAA11716@beethoven.bunyip.com> References: <199610310907.EAA11716@beethoven.bunyip.com> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Leslie Daigle writes: > > In general, each scheme, whether for a URL or URN, should be > > associated with some resolution protocol. > > I'm not sure I'm clear on what you're getting at here, and even if > we do agree, I think there is some potential for the above to be a > bit misleading. I'll try to be more clear below. If URLs and URNs are to be in the same name space of URI schemes, then we need to talk about them as the same kind of thing. This is not only possible, it is correct. BTW, emphasis in the following is not shouting. I'm very calm, now. > The point of the indirection in the URN naming is to abstract the > (final) resolution protocol so that no name space is specifically > associated with, say, HTTP, or Whois++. THe idea is that any URN > can be resolved using different protocols -- at one time, or at > different stages in its lifetime -- and this is a separate process > from determining the URN identifier string. This illustrates why I think the term "resolution protocol" is confusing. I mean something different than you and others do - and you qualified it parenthetically by saying "the (final) resolution protocol". More below. > However, there is a general mechanism for handling URNs to the > extent of extracting Naming Authority, etc etc etc, which is > standard across the URNs we define here. My point is that this mechanism for looking up the naming authority etc, as defined by the NAPTR spec (or other such specs), is only *part* of the WHOLE RESOLUTION PROCESS. (Calling it a "resolution process" may avoid the "protocol" issue, but it is not that simple, as I argued in previous mail.) The first part of the whole resolution process involves how you talk to DNS servers to lookup the naming authority etc. Note: HOW YOU TALK TO DNS IN THIS PARTICULAR WAY *IS* A PROTOCOL. If you like, it is a protocol layered on top of the raw DNS protocol. Note also that it is this lookup process that makes URNs into locations; You LOOK UP URNs starting AT A PARTICULAR LOCATION which is the root of the name space (urn.net or wherever). (Actually, just as for URLs, you can lookup up the very same URNs in different ways - see below.) Another part of the process is using the result of the first part, specifically the list of what is being called "resolution protocols". The client may then select one of these "resolution protocols" to continue with the resolution process. But note that this is not necessarily the end of the whole process. A resolution service might return an indirection to yet another URI, so the resolution process continues until you have what you want, whether that is the resource originally identified or some information about it, or you get an error. There may be other parts of the resolution process that are used *before* looking up naming authorities, such as trying to resolve the whole identifier from a local cache, or from a more global cache. It may not be necessary to do some of the above steps in the resolution process depending on what is found elsewhere via other protocols. Many protocols are involved in this whole resolution process, and to say that only some are the "resolution protocols" obscures the truth and so is misleading. > > You made the curious statement that URNs identify resources while URLs > > identify locations. I'm not sure whether that was a slip, but to my > > mind, a URL *IS* a location that identifies a resource. Now you also > > URLs identify a particular location for a resource. OK, what is a location? Is it the bits on the disk that "has" the resouce? (The disk might be shared by many servers, so the resource has a different "location" for each server.) Is it the server running at a particular IP address and port, that may share many disks with other servers? (The server may be a virtual server that runs on many machines, and the particular IP address is irrelevant.) Is it the domain name of the server, together with the path within the server? That's getting closer to the abstraction that URLs provide. Is the location, in fact, the URL itself? Consider caches. The resolution of a URL via a cache proxy may find the resource in the cache rather than in some remote server. What is "the location" of the resource in that case? Here is an example of how what is thought of as a location really turns out to *be* a name (as in persistent location). Take a normal http URL such as http://www.ncsa.uiuc.edu/. Instead of using normal HTTP to resolve the URL, or to look it up in a cache, let's set up a NAPTR-based "http" naming authority. Under that branch of the name space, we could ask the appropriate DNS server to look up 'www.ncsa.uiuc.edu' to find out where a server is currently located and what "resolution protocols" are currently supported. We don't need to create a new kind of identifier to make a URL into a persistent location. We *do* need new persistent services, such as the NAPTR records in DNS. How a URL is processed determines where the resource is really found, and the very same URL could be processed many different ways and the resource found many different places. And besides all that, a URL can be used to find other things associated with the resource, by completely different means, such as annotations or censorship ratings. The URL identifies all those things too, depending on how the URL is processed. The tight binding between http URLs and the HTTP protocol is an illusion created by frequent reinforcement and a transparent resolution process. (Similarly, many people feel they "visit" a web page, rather than bring a copy of the page back to their browser.) To summarize, both URLs and URNs have the following abstract resolution process in common: 1. Do some client-specific processing of the URI - maybe end there. 2. Look at the scheme name of the URI. If it says "URN:" drop it and repeat. 3. Look up the scheme in local table to find out what process should be invoked. E.g. news URIs may use NNTP, http URIs may use HTTP, cid URIs may use NAPTR-protocol. 4. Invoke the process identified by step 3. 5. If error results, exit. 6. If redirected to another URI, repeat whole process with that URI. An alternative to steps 2 and 3 would use more than just the scheme name to determine what process to invoke. There are several other varients possible in the whole process, and each client or each user might do things differently. I hope I've made my postion very clear regarding names, locations, and the resolution process. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA18748 for urn-ietf-out; Thu, 31 Oct 1996 14:53:42 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA18730 for ; Thu, 31 Oct 1996 14:53:39 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27644 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 14:53:37 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id LAA22604; Thu, 31 Oct 1996 11:52:05 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id LAA08639; Thu, 31 Oct 1996 11:52:21 -0800 (PST) Date: Thu, 31 Oct 1996 11:52:21 -0800 (PST) From: Terry Allen Message-Id: <199610311952.LAA08639@ishtar.fsc.fujitsu.com> To: rdaniel@acl.lanl.gov, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: [URN] ig Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Ron writes: | >| 3.4 N2Rs (URN to Resources): | >| This resolution service returns multiple instances of a resource, | >| for example, GIF and JPEG versions of an image. The judgment about | >| the resources being "the same" resides with the naming authority that | >| issued the URN. | > | >All the instances that suit the Accept info the client has sent? | >Does that leave us with nothing between asking for one instance | >(N2R) and all (N2Rs), or is there some way to quality the request | >so that one receives no more than, say, 13 instances? (Happy | >Halloween!) | | I will add some words to the effect that the resolver MAY restrict | the resources returned to those that match the Accept: header. That's good, but I can't find any way to use Accept: to limit the absolute number of resources that the client is willing to receive. Have I missed it? Is this perhaps an issue for HTTP and not this group? An image library might have scads of GIFs of the same object: the Parthenon in 1932, the P in 1964, the P at sunrise, the P under moonlight ... but it will be difficult to know in advance how to twiddle the Accept: information so as not to be inundated by Parthenons in response. Or maybe that's okay and users should be warned that they may get more than the bargained for when they use N2Rs? Regards, Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA18482 for urn-ietf-out; Thu, 31 Oct 1996 14:40:51 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA18470 for ; Thu, 31 Oct 1996 14:40:46 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27470 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 14:40:43 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA06593; Thu, 31 Oct 1996 12:40:39 -0700 (MST) Message-Id: <2.2.32.19961031194825.006e4228@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Oct 1996 12:48:25 -0700 To: "Gregory J. Woodhouse" , Fisher Mark From: Ron Daniel Subject: RE: [URN] HTTP resolution protocol Cc: "urn-ietf@bunyip.com" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Gregory J. Woodhouse (at least at 11:10 AM 10/31/96 -0800) >It seems to me that we should follow the same model as other requests and >use the status code to indicate a(n) (un)successful resolution and then use >the entity-body to provide either explanatory text or hyperlinks for old >browsers. For the most part, this is what I intended. I need to be more explicit on the Status codes that can be returned from successful or unsuccessful resolution attempts. One place where we seem to differ slightly is on the entity-body. I certainly think that it should be used most of the time. The one place where I think we should make an exception is the N2L request. If the new URL is returned in the Location: header, clients will automatically fetch the resource. If it is returned in the body, we get into the "click twice to access" model, which is a real pain in the rear. I will try to be more explicit on the various Status codes that should be returned. >Status 303 See Other seems a natural for our purposes--at least >N2L resoulution. Agreed, but it doesn't appear in my copy of RFC 1945 - the HTTP/1.0 spec. It is in the 1.1 spec, which is why I said it should be returned there. >For N2R resolution it would seem desirable to return the >entire resource in the entity-body, That is my intent, but I suppose I can try to tighten up my wording. "standard HTTP mechanisms" was used to cover all the Content-type, Status, ... material. > and for N2Rs, I'd like to see a >multipart/mixed or multipart/alternative entity containing each resource. Right. Here again I should be more precise. I said "multipart", I think "multipart/alternative" is probably the way to go. >Here, I'm a little unsure as to the best status code. One possibility is >200 OK for N2R, but I don't know about N2Rs. I think that as long as at least one version of a resource can be returned, 200 OK is the way to go for both N2R and N2Rs. There is the case to consider where we ask N2Rs but only one resource can be returned. Do we need to wrap it in a multipart even though there is only one part? I think not but don't have strong feelings on the subject. >Another question I have is >whether there should be any indication tht the content was returned as a >result of URN resolution. If so, a new status code may be necessary. Is there any need to make such a distinction? Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA18481 for urn-ietf-out; Thu, 31 Oct 1996 14:40:51 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA18472 for ; Thu, 31 Oct 1996 14:40:48 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27472 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 14:40:45 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA06596; Thu, 31 Oct 1996 12:40:39 -0700 (MST) Message-Id: <2.2.32.19961031194826.006a07f8@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Oct 1996 12:48:26 -0700 To: Fisher Mark From: Ron Daniel Subject: RE: [URN] HTTP resolution protocol Cc: "urn-ietf@bunyip.com" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Fisher Mark (at least at 01:44 PM 10/31/96 EST) [...] Mark asks "why text/plain instead of text/html or a new media type"? No really good reason, I'm afraid. How about: 1) We define text/uri-list as a new media type? 2) We allow the Accept: header to be used to pick between returning the result as text/html or text/uri-list. I think that the primary use of the lists will be for automated processing, thus the new media type allows us to launch those content handlers easily. Clients that don't support text/uri-list have a fallback that will allow humans to pick URI if necessary. New clients of the agent variety should use text/uri-list. Sound OK to you? If so I will add it to the draft, and also a note that recommends when HTML is returned that the items look like Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA17756 for urn-ietf-out; Thu, 31 Oct 1996 14:13:30 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA17751 for ; Thu, 31 Oct 1996 14:13:28 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27155 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 14:13:25 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA04704; Thu, 31 Oct 1996 12:13:18 -0700 (MST) Message-Id: <2.2.32.19961031192104.006e5d70@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Oct 1996 12:21:04 -0700 To: Terry Allen , urn-ietf@bunyip.com From: Ron Daniel Subject: Re: [URN] HTTP resolution protocol Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Terry Allen (at least at 10:37 AM 10/31/96 -0800) >A few comments, mostly re coordination with the Framework document: > >| 3.1 N2L (URN to URL): >| The request is encoded as above. The URL MUST be returned in a Location: >| header for the convienience of the most common case of wanting the resource. >| A 30X status line SHOULD be returned. HTTP/1.1 clients should be sent the >| 303 status code. HTTP/1.0 clients should be sent the 302 (Moved temporarily) >| status code unless the resolver has particular resons for using 301 >| (moved permanently) or 304 (not modified) codes. > >It would be nice to have a brief explanation of why these are >the right responses, perhaps recapping what will be in the >Framework document. No commitments on this one, but I will see what we can do. >| Simple format for returning multiple URLs >| >| [Do we need to have a continuation character for *very* long lines? >| I tend to think not.] > >Might be useful; there will be a significant proportion of long lines. Right, but that does not mean that the long lines have to be broken. I am unaware of any line length limitation for text/plain bodies. If we don't break the lines, things are simpler. >| 3.4 N2Rs (URN to Resources): >| This resolution service returns multiple instances of a resource, >| for example, GIF and JPEG versions of an image. The judgment about >| the resources being "the same" resides with the naming authority that >| issued the URN. > >All the instances that suit the Accept info the client has sent? >Does that leave us with nothing between asking for one instance >(N2R) and all (N2Rs), or is there some way to quality the request >so that one receives no more than, say, 13 instances? (Happy >Halloween!) I will add some words to the effect that the resolver MAY restrict the resources returned to those that match the Accept: header. >| 3.6 N2Ns (URN to URNs): >| ------------------------ >| >| While URNs are supposed to identify one and only one resource, that >| does not mean that a resource may have one and only one URN. For >| example, consider a resource that has something like >| "current-weather-map" for one URN and "weather-map-for-datetime-x" for >| another URN. The N2Ns service request lets us obtain lists of URNs that >| are believed equivalent at the time of the request. As the weathermap > >The example implies, "lists of URNs that are believed to name equivalent >resources at the time of the request", which agrees with the language >in the next para. Right. I will change the wording to be more precise. >| 3.8 L2Ls (URL to URLs): >| ------------------------ >| >| The request is encoded as described above. The result is a list of >| all the URLs that the resolver knows are associated with the resource >| located by the given URL. It is returned in a text/plain body encoded >| as described above. > >"Associated" is awfully broad. The Framework document will clear up >what associations are intended, right? Using "associations" was a mistake on my part. The intent here is that we return the locations of equivalent resources, analogous to the N2Ns request. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA17710 for urn-ietf-out; Thu, 31 Oct 1996 14:11:31 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA17700 for ; Thu, 31 Oct 1996 14:11:29 -0500 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27135 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 14:11:24 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id LAA22316; Thu, 31 Oct 1996 11:10:52 -0800 Date: Thu, 31 Oct 1996 11:10:52 -0800 (PST) From: "Gregory J. Woodhouse" To: Fisher Mark Cc: Ron Daniel , "urn-ietf@bunyip.com" Subject: RE: [URN] HTTP resolution protocol In-Reply-To: <3278F437@MSMAIL.INDY.TCE.COM> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com It seems to me that we should follow the same model as other requests and use the status code to indicate a(n) (un)successful resolution and then use the entity-body to provide either explanatory text or hyperlinks for old browsers. Status 303 See Other seems a natural for our purposes--at least N2L resoulution. For N2R resolution it would seem desirable to return the entire resource in the entity-body, and for N2Rs, I'd like to see a multipart/mixed or multipart/alternative entity containing each resource. Here, I'm a little unsure as to the best status code. One possibility is 200 OK for N2R, but I don't know about N2Rs. Another question I have is whether there should be any indication tht the content was returned as a result of URN resolution. If so, a new status code may be necessary. --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/ resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA17468 for urn-ietf-out; Thu, 31 Oct 1996 13:47:40 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA17463 for ; Thu, 31 Oct 1996 13:47:37 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26952 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 13:47:34 -0500 Received: by seawall with (8.6.12/) id NAA27232; Thu, 31 Oct 1996 13:47:30 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma027212; Thu Oct 31 13:47:16 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <3278F437@MSMAIL.INDY.TCE.COM>; Thu, 31 Oct 96 13:47:19 EST From: Fisher Mark To: Ron Daniel Cc: "urn-ietf@bunyip.com" Subject: RE: [URN] HTTP resolution protocol Date: Thu, 31 Oct 96 13:44:00 EST Message-Id: <3278F437@MSMAIL.INDY.TCE.COM> Encoding: 32 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com In sections 3.2 ("N2Ls (URN to URLs)"), 3.6 ("N2Ns (URN to URNs)"), 3.7 ("L2Ns (URL to URNs)"), and 3.8 ("L2Ls (URL to URLs)"), the entity body returned is of Internet Media Type type text/plain, and therefore is not directly usable by the current crop of UAs, but the other resolution services return responses or entity bodies that are directly usable. Why was text/plain chosen instead of a simple HTML list? As an example (drawn from draft-daniel-http-00.txt section 3.2): N2Ls Resolution of <URN:cid:foo@huh.org>

N2Ls Resolution of

Since we already have the tools to deal with HTML, why resort to text/plain? Or, like in section 3.5 ("N2C (URN to URC)"), why not assign an Internet Media Type to the response, so that UAs can know that the response is not just some random message? ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA17414 for urn-ietf-out; Thu, 31 Oct 1996 13:38:28 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA17409 for ; Thu, 31 Oct 1996 13:38:25 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26880 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 13:38:21 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id KAA21600; Thu, 31 Oct 1996 10:36:44 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id KAA06895; Thu, 31 Oct 1996 10:37:00 -0800 (PST) Date: Thu, 31 Oct 1996 10:37:00 -0800 (PST) From: Terry Allen Message-Id: <199610311837.KAA06895@ishtar.fsc.fujitsu.com> To: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] HTTP resolution protocol Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com A few comments, mostly re coordination with the Framework document: | 3.1 N2L (URN to URL): | The request is encoded as above. The URL MUST be returned in a Location: | header for the convienience of the most common case of wanting the resource. | A 30X status line SHOULD be returned. HTTP/1.1 clients should be sent the | 303 status code. HTTP/1.0 clients should be sent the 302 (Moved temporarily) | status code unless the resolver has particular resons for using 301 | (moved permanently) or 304 (not modified) codes. It would be nice to have a brief explanation of why these are the right responses, perhaps recapping what will be in the Framework document. | Figure 1 | Simple format for returning multiple URLs | | [Do we need to have a continuation character for *very* long lines? | I tend to think not.] Might be useful; there will be a significant proportion of long lines. | 3.4 N2Rs (URN to Resources): | This resolution service returns multiple instances of a resource, | for example, GIF and JPEG versions of an image. The judgment about | the resources being "the same" resides with the naming authority that | issued the URN. All the instances that suit the Accept info the client has sent? Does that leave us with nothing between asking for one instance (N2R) and all (N2Rs), or is there some way to quality the request so that one receives no more than, say, 13 instances? (Happy Halloween!) | 3.6 N2Ns (URN to URNs): | ------------------------ | | While URNs are supposed to identify one and only one resource, that | does not mean that a resource may have one and only one URN. For | example, consider a resource that has something like | "current-weather-map" for one URN and "weather-map-for-datetime-x" for | another URN. The N2Ns service request lets us obtain lists of URNs that | are believed equivalent at the time of the request. As the weathermap The example implies, "lists of URNs that are believed to name equivalent resources at the time of the request", which agrees with the language in the next para. | example shows, some of the equivalances will be transitory, so the | result should not be cached. | The request is encoded as above. The result is a list of all the | URNs, known to the resolver, which identify the same resource as the | input URN. The result shall be encoded as for the N2Ls request | above. The original URN may appear in the list of returned URNs. | 3.8 L2Ls (URL to URLs): | ------------------------ | | The request is encoded as described above. The result is a list of | all the URLs that the resolver knows are associated with the resource | located by the given URL. It is returned in a text/plain body encoded | as described above. "Associated" is awfully broad. The Framework document will clear up what associations are intended, right? Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA13905 for urn-ietf-out; Thu, 31 Oct 1996 10:21:33 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA13889 for ; Thu, 31 Oct 1996 10:21:30 -0500 Received: from ietf.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22808 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 10:21:27 -0500 Received: from localhost by ietf.org id aa25602; 31 Oct 96 10:01 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: urn-ietf@bunyip.com From: Internet-Drafts@ietf.org Subject: [URN] I-D ACTION:draft-ietf-urn-syntax-00.txt Date: Thu, 31 Oct 1996 10:01:29 -0500 Message-Id: <9610311001.aa25602@ietf.org> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org Errors-To: owner-urn-ietf@bunyip.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : URN Syntax Author(s) : R. Moats Filename : draft-ietf-urn-syntax-00.txt Pages : 5 Date : 10/30/1996 Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers. This document presents the syntax for URNs. Support for existing legacy namespaces is discussed. URN transmission encoding requirements are presented. Finally, there is a discussion of URN equivalence and how to determine it. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-syntax-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-syntax-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961030141208.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-syntax-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-syntax-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961030141208.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA12209 for urn-ietf-out; Thu, 31 Oct 1996 08:56:24 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA12204 for ; Thu, 31 Oct 1996 08:56:21 -0500 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21932 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 08:56:19 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id FAA26174; Thu, 31 Oct 1996 05:54:38 -0800 Date: Thu, 31 Oct 1996 05:54:38 -0800 (PST) From: "Gregory J. Woodhouse" To: Martin J Duerst Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com Subject: Re: [URN] New syntax draft (was: no subject) In-Reply-To: <"josef.ifi..493:31.09.96.13.39.00"@ifi.unizh.ch> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com On Thu, 31 Oct 1996, Martin J Duerst wrote: > Gregory Woodhouse wrote: > > This difference is always absolutely clear! A string that only contains > bytes with the high bit '0' (7-bit bytes) is ASCII. As soon as a high > bit is set to '1', it's not ASCII anymore. It may be UTF-8, or may not. > I understand this point, but I'm not talking about UTF-8 itself, but UTF-8 encoded into ASCII. --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/ resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA12102 for urn-ietf-out; Thu, 31 Oct 1996 08:41:34 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA12097 for ; Thu, 31 Oct 1996 08:41:31 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21856 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 08:41:26 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00846-0@josef.ifi.unizh.ch>; Thu, 31 Oct 1996 14:38:58 +0100 Subject: Re: [URN] New syntax draft (was: no subject) To: gjw@wnetc.com (Gregory J. Woodhouse) Date: Thu, 31 Oct 1996 14:38:57 +0100 (MET) Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com In-Reply-To: from "Gregory J. Woodhouse" at Oct 31, 96 05:15:43 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2937 From: Martin J Duerst Message-Id: <"josef.ifi..493:31.09.96.13.39.00"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Gregory Woodhouse wrote: >I'm also concerned because decoding requires knowledge that the string >being decoded is UTF-8. Not exactly. It is very rare that a string that is not UTF-8 looks like an UTF-8 string. >I said before that I wasn't terribly excited about >using RFC 1522 style encodings, Me neither! "charset" is okay for long mails, and RFC 1522 was unavoidable at the time it was created, but now we have better solutions. >but it seems essential in this case because >otherwise the UA has no way of knowing (except by guessing) that the string >is encoded UTF-8 and not just an ASCII string. This difference is always absolutely clear! A string that only contains bytes with the high bit '0' (7-bit bytes) is ASCII. As soon as a high bit is set to '1', it's not ASCII anymore. It may be UTF-8, or may not. >It is conceivable that some >URN schemes will allow the sequences like %20%1E or whatever, so this could >be a real problem. Well, %20 is a space, which is ASCII, but should be escaped. %1E is a control character (record separator), never appears in UTF-8, and strictly speaking is also not part of ASCII. >Another thought: What if someone wants to come along an >do %hhhh style encoding of UTF-16? Will this be mistaken for encoded UTF-8? Well, anybody can come along and propose new weird syntax rules for URNs. Hopefully, nobody will listen to him/her. And these rules won't comply with the official URN syntax we are working on here. Actually, I don't think that anybody will get the idea of using UTF-16 when UTF-8 is proposed. It's Unicode/ISO 10646 in both cases, the transform is easy, and people dealing with Unicode and stuff know that things such as URNs, with ASCII backwards compatibility requirements, are best handled using UTF-8. The things we have to worry about more are people that come along and say they want to use something else than Unicode/ISO 10646, or at least want to be able to use something else, because for some reasons, they are against Unicode, or they think it should just be one of many encodings. Also, what we have to worry about are cases where it's difficult to know what native character encoding is used, so that it is difficult to convert to Unicode and UTF-8 even if you wanted. ftp is a typical case of this. Anyway, even the two cases above are well handled in the draft. We tell them that if they really need to, they can use something else than UTF-8. Maybe we should tell them a little bit clearer that if they do that, they are not supposed to get any much of support by general tools, i.e. their URNs will just show up as %HH%HH..., and the users will have to type them in like this, and accidentally, some of it may be interpreted as UTF-8 and be displayed as such, but they cannot have their users type native characters into a browser and expect that the browser does the right thing (because it would in this case convert to UTF-8). Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA11990 for urn-ietf-out; Thu, 31 Oct 1996 08:16:32 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA11985 for ; Thu, 31 Oct 1996 08:16:25 -0500 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21785 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 08:16:23 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id FAA25128; Thu, 31 Oct 1996 05:15:43 -0800 Date: Thu, 31 Oct 1996 05:15:43 -0800 (PST) From: "Gregory J. Woodhouse" To: Martin J Duerst Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com Subject: Re: [URN] New syntax draft (was: no subject) In-Reply-To: <"josef.ifi..728:31.09.96.10.58.37"@ifi.unizh.ch> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com By %encoding I assume you mean hex encoding of non-ASCII or non-safe bytes. Is there an official name for this encoding scheme? I've seen it called URL encoding, but that hardly seems satisfactory. I'm also concerned because decoding requires knowledge that the string being decoded is UTF-8. I said before that I wasn't terribly excited about using RFC 1522 style encodings, but it seems essential in this case because otherwise the UA has no way of knowing (except by guessing) that the string is encoded UTF-8 and not just an ASCII string. It is conceivable that some URN schemes will allow the sequences like %20%1E or whatever, so this could be a real problem. Another thought: What if someone wants to come along an do %hhhh style encoding of UTF-16? Will this be mistaken for encoded UTF-8? --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/ resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA11907 for urn-ietf-out; Thu, 31 Oct 1996 08:02:13 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA11902 for ; Thu, 31 Oct 1996 08:02:11 -0500 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21754 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 08:02:09 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id FAA24510; Thu, 31 Oct 1996 05:00:28 -0800 Date: Thu, 31 Oct 1996 05:00:28 -0800 (PST) From: "Gregory J. Woodhouse" To: Daniel LaLiberte Cc: Ron Daniel , urn-ietf@bunyip.com Subject: Re: [URN] HTTP resolution protocol In-Reply-To: <199610302015.OAA12250@ncsa.uiuc.edu> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com On Wed, 30 Oct 1996, Daniel LaLiberte wrote: > (Why are people putting [URN] in the title if the recipients are > all on the urn-ietf list? Just curious.) > It's a feature of Majordomo and other listservers to allow a specific string to be prepended to a message subject if it's not already present. I find this feature very useful and have always used it wne running lists. For example, I now run an average of 100-300 messages in my in box. When I want to look at messages from this list I select all messages with "[URN]" in the subject and narrow my display to include only those messages. This is with Pine 3.95 which is fairly sophisticated in this regard. Other mailers are more limited but do allow sorting. This way, if there is a common prefix to all the messages they show up together after a sort. (I realize mail processing and UA characerisics has nothing to do with URNs. I left the list on the recipient list in case more people were wondereing about the prefixes, but if you want to discuss this further we might want to take it off list.) --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/ resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA11383 for urn-ietf-out; Thu, 31 Oct 1996 06:00:11 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA11378 for ; Thu, 31 Oct 1996 06:00:09 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21426 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 06:00:00 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00655-0@josef.ifi.unizh.ch>; Thu, 31 Oct 1996 11:58:36 +0100 Subject: Re: [URN] New syntax draft (was: no subject) To: jayhawk@ds.internic.net Date: Thu, 31 Oct 1996 11:58:35 +0100 (MET) Cc: internet-drafts@ietf.org, urn-ietf@bunyip.com In-Reply-To: <327762F6.3701@ds.internic.net> from "Ryan Moats" at Oct 30, 96 08:15:18 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2081 From: Martin J Duerst Message-Id: <"josef.ifi..728:31.09.96.10.58.37"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com >Internet-Draft Ryan Moats >draft-ietf-urn-syntax-00.txt AT&T >Expires in six months October 1996 >1.2 Namespace Specific String Syntax > > Depending on the rules governing a namespace, valid identifiers in a > namespace might contain characters that are reserved characters in > URI syntax or non-printable ASCII characters. To accommodate the > largest set of valid identifiers, the NSS portion of a URN shall use > UTF-8 representation of ISO 10646 as its character set. Namespaces > that do not currently use ISO 10646/UTF-8 are encouraged to migrate > to it. Very well put! > URN resolvers MUST be capable of accepting URNs that have been > %encoded for either 8-bit clean or 7-bit transports. %encoding is > removed first, then UTF-8 decoding is performed. URN resolvers MUST > return identical results from ANY legally encoded form of the URN. I wonder about UTF-8 decoding. It somehow implies that resolvers work with Unicode internally, which would be fine, but is not necessary. For database lookup and equality checks, staying with UTF-8 will also be okay. For things such as regular expressions, some additional definitions are necessary as to what the regular expressions are working on (i.e. characters or octets), but still it could work in UTF-8. Also, what does UTF-8 decoding mean for an NSS that is not UTF-8? > It should be noted that certain characters in the Namespace Specific > String syntax may have special meaning in certain namespaces. > Therefore, the process of registering a namespace identifier shall > include publication of a definition of which characters have a > special meaning and how to encode these characters if used in a > literal sense. Can they be encoded with %HH? Or should we specifically request some other mechanism in order to not confuse different things, and let programs that deal with URNs in general change from %HH to 8-bit and back? Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA11146 for urn-ietf-out; Thu, 31 Oct 1996 05:26:19 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA11141 for ; Thu, 31 Oct 1996 05:26:17 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21314 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 05:26:14 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00569-0@josef.ifi.unizh.ch>; Thu, 31 Oct 1996 11:25:44 +0100 Subject: Re: [URN] HTTP resolution protocol To: liberte@ncsa.uiuc.edu Date: Thu, 31 Oct 1996 11:25:43 +0100 (MET) Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com In-Reply-To: <199610302015.OAA12250@ncsa.uiuc.edu> from "Daniel LaLiberte" at Oct 30, 96 02:15:51 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 304 From: Martin J Duerst Message-Id: <"josef.ifi..439:31.09.96.10.25.46"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Daniel LaLiberte wrote: >(Why are people putting [URN] in the title if the recipients are >all on the urn-ietf list? Just curious.) Because most people are on more than one mailing list, and it is convenient to know from which list the mails come just from looking at the subjects. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA10480 for urn-ietf-out; Thu, 31 Oct 1996 04:07:27 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA10475 for ; Thu, 31 Oct 1996 04:07:25 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21124 (mail destined for urn-ietf@services.bunyip.com); Thu, 31 Oct 96 04:07:23 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id EAA11716; Thu, 31 Oct 1996 04:07:23 -0500 Message-Id: <199610310907.EAA11716@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Thu, 31 Oct 1996 04:07:22 -0500 In-Reply-To: Daniel LaLiberte's message as of Oct 30, 15:21 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Daniel LaLiberte , "Karen R. Sollins" Subject: Re: Names and Locations (was [URN] some comments) Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Dan, forgive me for using your message as an opportunity to write down some basic definitions to make sure we ae all on the same page here... [Dan LaLiberte wrote:] > I agree. But "a URN syntax" seems to imply that there must be just > one syntax for all URNs. Did you mean that? >From the perspective of the work this group is doing, we neeed _a_ URN syntax. Because we are attempting to accommodate a broad range of name spaces, the syntax is designed to be flexible -- ony specifying those things that must be in order to be able to write software that handles URNs. (E.g., acceptable character sets, how to handle escaping characters where necessary, etc). The URN syntax does not, however, have anything to say about what structure a particular namespace wishes to use in the NSS (i.e., namespace specific (opaque) string). I think Karen's point was that this syntax should be defined from the perspective of what we're trying to do with URNs, and not from the technological limitations or strengths of a particular implementation of the architecture. > We should state that name space identifiers and URI schemes are in the > same name space. Call them all the same thing: "URI Schemes". Perhaps a convenient (and maybe even necessary) approach, but it should be kept in mind that a URN name space is not the same thing as a URL protocol (see below) -- so this starts to be a collection of apples and oranges. > In general, each scheme, whether for a URL or URN, should be > associated with some resolution protocol. I'm not sure I'm clear on what you're getting at here, and even if we do agree, I think there is some potential for the above to be a bit misleading. The point of the indirection in the URN naming is to abstract the (final) resolution protocol so that no name space is specifically associated with, say, HTTP, or Whois++. THe idea is that any URN can be resolved using different protocols -- at one time, or at different stages in its lifetime -- and this is a separate process from determining the URN identifier string. However, there is a general mechanism for handling URNs to the extent of extracting Naming Authority, etc etc etc, which is standard across the URNs we define here. What _is_ associated with each name space is the particular means of extracting the necessary namespace ID to look up the naming authority (i.e., perhaps from the NSS, perhaps just based on the namespace, etc). So, CID URNs might have a mapping that describes how to pull a DNS name out of the string; LesliesNamespace might have a mapping based on the phase of the moon. All LesliesNamespace URNs will require the use of this mapping in order to find the Naming Authority, which will lead to a server speaking any of seaveral possible protocols for the final resolution. > You made the curious statement that URNs identify resources while URLs > identify locations. I'm not sure whether that was a slip, but to my > mind, a URL *IS* a location that identifies a resource. Now you also URLs identify a particular location for a resource. Mechanisms for migrating that resource without changing the URL are based on aliasing techniques that are external to the URL. It is therefore usually a problem when a particular resource is moved to another location. URNs identify a resource, independently of its location. The indirection mechanisms permit that a single resource may be in several locations at once, or may migrate, without changing the URN. This is handled within the URN support framework, and is therefore consistent across URNs. The idea is that, in general, it should not be a problem if a resource is moved. So, the URN identifies the resource; a URL identifies a location which is an instance of a resource, nd these are qualitatively different things (yes, I am feeling brave this morning!). Leslie. -- ---------------------------------------------------------------------------- "The light at the end of the tunnel Leslie Daigle is often the blindingly obvious..." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA05534 for urn-ietf-out; Wed, 30 Oct 1996 16:35:24 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA05527 for ; Wed, 30 Oct 1996 16:35:20 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17450 (mail destined for urn-ietf@services.bunyip.com); Wed, 30 Oct 96 16:35:18 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id PAA13997; Wed, 30 Oct 1996 15:30:33 -0600 (CST) Date: Wed, 30 Oct 1996 15:30:33 -0600 (CST) From: Daniel LaLiberte Message-Id: <199610302130.PAA13997@ncsa.uiuc.edu> To: Larry Masinter Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] HTTP resolution protocol In-Reply-To: <96Oct30.125412pst."2759"@golden.parc.xerox.com> References: <2.2.32.19961030185925.007445e0@acl.lanl.gov> <96Oct30.125412pst."2759"@golden.parc.xerox.com> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Larry Masinter writes: > Ron, > > I think some people would say that > > GET / HTTP/1.0 > > is not valid HTTP. I was wondering about that. Maybe Ron meant: GET // HTTP/1.0 > New services need new methods. Well... http is a "service". Should it be a "method"? dan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA05349 for urn-ietf-out; Wed, 30 Oct 1996 16:25:48 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA05344 for ; Wed, 30 Oct 1996 16:25:45 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17398 (mail destined for urn-ietf@services.bunyip.com); Wed, 30 Oct 96 16:25:42 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id PAA13844; Wed, 30 Oct 1996 15:21:08 -0600 (CST) Date: Wed, 30 Oct 1996 15:21:08 -0600 (CST) From: Daniel LaLiberte Message-Id: <199610302121.PAA13844@ncsa.uiuc.edu> To: "Karen R. Sollins" Cc: urn-ietf@bunyip.com Subject: Names and Locations (was [URN] some comments) In-Reply-To: <199610300002.TAA05714@lysithea.lcs.mit.edu> References: <199610300002.TAA05714@lysithea.lcs.mit.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Karen R. Sollins writes: > 1) There were a couple of almost parenthetical comments about the > NAPTR proposal that made me worry. It is important that we all agree > that a URN syntax is independent of the NAPTR or any other URN > resolution proposal. I agree. But "a URN syntax" seems to imply that there must be just one syntax for all URNs. Did you mean that? > 2) About "urn:", I don't know whether I come from the other > "religious" viewpoint, but unless we have additional requirements and > mechanisms in place, I think it would be a really bad idea to make the > "urn:" optional. Let's look at a few points here: > > a) I don't believe that there is anything in the URL or URN > requirements documents (or any other RFCs) that states that prefixes > for URNs (without the "urn:") and URLs cannot be the same. We should state that name space identifiers and URI schemes are in the same name space. Call them all the same thing: "URI Schemes". One way to avoid this is to make sure that the context for resolution is always clear. So when giving a URL in an HTML document you could use HTTP="scheme:opaque-string", and when giving a URN you could use a different tag, e.g. URN="nsi:opaque-string". This idea tends to pop up occasionally, but I think it not useful. > b) Given a random string (say foo://opaque_string) in some specific > situation, something needs to decide what it means and what to do with > it. If the string is a URN it identifies a resource, while, if it is > a URL it identifies a location (in other words, it identifies an > abstraction from the perspective of a transport protocol, in fact, the > "foo" transport protocol). So, now, without any specification of > urn-hood or url-hood, who makes a decision and how? In general, each scheme, whether for a URL or URN, should be associated with some resolution protocol. You made the curious statement that URNs identify resources while URLs identify locations. I'm not sure whether that was a slip, but to my mind, a URL *IS* a location that identifies a resource. Now you also qualified it by saying that locations are associated with transport protocols. I think maybe therein lies the rub for this name-location friction. The term "transport protocol" means, to me, a set of descriptions, rules, policies, etc for how data is transferred between two or more points. In contrast, the term "resolution protocol" is about how some identifier is resolved into something else, not necessarily the final "resource". (You didn't use "resolution protocol", but others have.) But consider HTTP. It is a resolution protocol in that http URLs are resolved into something else (sometimes the resource is returned, sometimes just data about it). The fact that something is returned as a result of the resolution process means that HTTP must deal with transport too. In fact, to make a resolution request, the request itself must be transported from the client to the server. A transport that is merely one-way, and doesn't involve a request could be considered to have a pure transport protocol. But most real transport protocols involve something like a request to send something followed by acknowledgment, refusal, etc. While I am at it, the term "protocol" seems to have gotten a too-specific meaning in the internet community. The general meaning of the term is rules for how things talk to each other. If the things that are talking are distributed across a network, this is very important to internet people, to the point that "protocol" means just over the network. But with the advent of distributed object technologies, it should become increasingly clear that, from a high-level perspective, it is irrelevant (except for performance, security and the like) whether communicating objects are co-located in the same process or distributed. "Applications" can execute within a single machine or be smeared across several. Sure there are protocols that are only really needed over the network, such as IP, but I bet someone somewhere is using IP within a process to "simulate" the network. Back to names. > c) Consider how one might build applications, with respect to URNs > (it's too late for URLs to solve this problem). Suppose five new > kinds of URNs are defined and five new kinds of URLs are defined. The > application starts seeing strings with these ten new prefixes. Now > the applications must have some mechanism for dealing with all these > new things. So, assume it makes some decision, perhaps to send all > unidentifiable strings to a proxy for URNs. What is wrong with sending each identifier to a possibly different proxy that is intended to resolve it? How does a client know which identifiers go to which proxy? Ah ha! We need a downloadable global resolution mapping table for all globally defined URI schemes. The client would use this table to look up the appropriate resolution mechanism. Local versions of the table could exist to, for example, map local identifiers to a faster private server. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA05025 for urn-ietf-out; Wed, 30 Oct 1996 15:58:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA05020 for ; Wed, 30 Oct 1996 15:58:48 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17193 (mail destined for urn-ietf@services.bunyip.com); Wed, 30 Oct 96 15:58:46 -0500 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <15146(5)>; Wed, 30 Oct 1996 12:54:35 PST Received: by golden.parc.xerox.com id <2759>; Wed, 30 Oct 1996 12:54:12 PST To: rdaniel@acl.lanl.gov Cc: urn-ietf@bunyip.com In-Reply-To: <2.2.32.19961030185925.007445e0@acl.lanl.gov> (message from Ron Daniel on Wed, 30 Oct 1996 10:59:25 PST) Subject: Re: [URN] HTTP resolution protocol From: Larry Masinter Message-Id: <96Oct30.125412pst."2759"@golden.parc.xerox.com> Date: Wed, 30 Oct 1996 12:54:12 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com Ron, I think some people would say that GET / HTTP/1.0 is not valid HTTP. In fact, I think there are a number of current products that offer (on the same port) both regular and proxy HTTP support would be confused by something that half looks like a URL but isn't really. New services need new methods. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA04945 for urn-ietf-out; Wed, 30 Oct 1996 15:46:54 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA04938 for ; Wed, 30 Oct 1996 15:46:52 -0500 Received: from newton.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17107 (mail destined for urn-ietf@services.bunyip.com); Wed, 30 Oct 96 15:46:50 -0500 Received: from carlyle.ncsa.uiuc.edu (carlyle.ncsa.uiuc.edu [141.142.230.144]) by newton.ncsa.uiuc.edu (8.6.11/8.6.12) with ESMTP id OAA08495 for ; Wed, 30 Oct 1996 14:21:29 -0600 Received: from ncsa.uiuc.edu (void.ncsa.uiuc.edu [141.142.103.20]) by carlyle.ncsa.uiuc.edu (8.6.11/8.6.9) with ESMTP id OAA26648 for ; Wed, 30 Oct 1996 14:21:27 -0600 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id OAA12250; Wed, 30 Oct 1996 14:15:51 -0600 (CST) Date: Wed, 30 Oct 1996 14:15:51 -0600 (CST) From: Daniel LaLiberte Message-Id: <199610302015.OAA12250@ncsa.uiuc.edu> To: Ron Daniel Cc: urn-ietf@bunyip.com Subject: [URN] HTTP resolution protocol In-Reply-To: <2.2.32.19961030185925.007445e0@acl.lanl.gov> References: <2.2.32.19961030185925.007445e0@acl.lanl.gov> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com (Why are people putting [URN] in the title if the recipients are all on the urn-ietf list? Just curious.) Ron Daniel writes: > Conventions for the Use of HTTP for URN Resolution Perhaps the whole document could be more specific on the fact that this is a particular kind of URN resolution, not the only way that HTTP might in fact be used (simultaneously) for URN resolution. For example, path URNs can be mapped directly to http URLs, which the client resolves normally via HTTP, using whatever services are supported via HTTP. (Additional http services might be metadata requests, for example.) > Abstract: > ========= > > One of the main purposes of the work on URNs is to allow resources > to be replicated onto multiple sites. I disagree with this. Replication should be considered orthogonal to naming and name resolution. Names are not required to offer just as much transparency in the replication process and resolution via replicas. An identifier (whether a "name" or "location") for a resource can be associated with many other identifiers of replicas, or alternatively, an identifier can be associated with many other services that *have* replicas of the resource. The main purpose of URNs is to provide an additional level indirection via a relatively long lived resolution service (e.g. DNS). Providing replica identifiers at the same time as providing this indirection seems like a reasonable thing to do (and it is) but it is the indirection which is the main purpose of names. You also have described several other services that the server would provide, so why focus on replication in the Abstract? > Obtaining a copy of such a > replicated resource procedes by contacting a "resolver" that knows the > locations of the replicated resource. An HTTP server could know the locations of a replicated resource identified by either an http URL or a URN. > 2.0 General Approach: > ===================== > > The general approach used to encode resolution service requests in HTTP > is quite simple: > > GET / HTTP/1.0 > > For example, if we have the URN "cid:foo@huh.com" and want a URL, > we would send the request: > > GET N2L/cid:foo@huh.com HTTP/1.0 What you propose works, but consider why not do: N2L cid:foo@huh.com HTTP/1.0 The "N2L/" prefix on the URI defines a name space within the server - the server might be used for other things simultaneously. Doing a GET request on this URI means (in current HTTP) that the result should be cachable, and as far as the client is concerned it looks like "N2L/whatever" is the identifier for a resource itself. The full URL for this resource is "http://wherever/N2L/whatever". Could we then request "N2L/N2L/whatever"? With a new "N2L" method, things would be different. Whether the result is cachable is not certain. Most servers cannot (yet) be configured to handle new methods. But otherwise, it might make more sense to keep the N2L service request out of the identifier of the real resource (the ). Folding the service (or method) request into an identifier is not a sin - in fact, I have suggested more of the same. I just want to point out that that is what you are doing. > One caveat should be kept in mind. The "urn:" prefix is still the > subject of controversy, so some URN documents advocate treating it > as optional. HTTP resolvers MUST return identical results for URIs > that do and do not contain the "urn:" prefix. Wouldn't it be simpler just to require that the "urn:" should be removed before submitting the request? -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA03163 for urn-ietf-out; Wed, 30 Oct 1996 14:03:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA03158 for ; Wed, 30 Oct 1996 14:03:35 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16156 (mail destined for urn-ietf@services.bunyip.com); Wed, 30 Oct 96 14:03:33 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id MAA10126; Wed, 30 Oct 1996 12:58:47 -0600 (CST) Date: Wed, 30 Oct 1996 12:58:47 -0600 (CST) From: Daniel LaLiberte Message-Id: <199610301858.MAA10126@ncsa.uiuc.edu> To: Larry Masinter Cc: urn-ietf@bunyip.com Subject: Re: [URN] What is equivalence? In-Reply-To: <96Oct23.004640pdt."2763"@golden.parc.xerox.com> References: <96Oct23.004640pdt."2763"@golden.parc.xerox.com> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Larry Masinter writes: > Do the namespaces 'define' equivalence, or do they 'implement' it? > > That is, would you want to assert that if > isbn:0-13-443672-5 and isbn:013443672-5 > are ever to be treated the 'same', then they must always be treated > the 'same'? Otherwise, a client which has 'knowledge about the > namespace' might find that knowledge out of date. I don't recall if anyone mentioned the idea of a client getting and caching general rules (e.g. regular expressions) for how to transform an identifier into a canonical, preferred form. Testing equivalence would then involve transforming all identifiers to cannonical form, and then comparing. One resolution service might be to answer a request for the canonical form of an identifier, perhaps along with the rule used to do the transformation. > On the other hand, you might want to allow > duns:ibm to be the same as duns:international-business-machines > but are you willing to allow that equivalence to be cached in clients > or wired into them? I gather the idea here is that "duns:ibm" is a prefix for a whole class of identifiers. Mapping 'duns:ibm' to 'duns:international-business-machines' (or vise versa) goes beyond a few general transformation rules to lots of specific cases (one for every company name with an acronym), but clients could and should certainly cache as many such specific rules as are useful, and still valid. But there is another notion of equivalence that should be considered: the equivalence of any two identifiers may be specified by a naming authority (or an associated resolution service). The identifiers may be in completely different name spaces, so some agreement must exist and be certifiable. This equivalence of two identifiers that applies to only these specific identifiers is a special case of the general transformation rule. In all cases, the identifier space (or some subauthority within it) specifies how equivalence is determined, either as a very general rule or as lots of specific rules. A few very general rules with very long life times may be wired into clients. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA03031 for urn-ietf-out; Wed, 30 Oct 1996 13:51:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA03026 for ; Wed, 30 Oct 1996 13:51:46 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15985 (mail destined for urn-ietf@services.bunyip.com); Wed, 30 Oct 96 13:51:42 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id LAA10056 for ; Wed, 30 Oct 1996 11:51:40 -0700 (MST) Message-Id: <2.2.32.19961030185925.007445e0@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 1996 11:59:25 -0700 To: urn-ietf@bunyip.com From: Ron Daniel Subject: [URN] HTTP resolution protocol Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Hi again, A rough draft of the HTTP resolution protocol is appended. This sets the conventions on how URN resolution service requests and responses should be encoded in HTTP requests and responses. It is the draft that specifies the meaning of the "http" resolution protocol that is mentioned in the NAPTR draft. ==== INTERNET DRAFT Ron Daniel draft-daniel-http-00.txt Los Alamos National Laboratory 30 Oct, 1996 Conventions for the Use of HTTP for URN Resolution Status of this Memo =================== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft expires 25 Feb., 1997. Abstract: ========= One of the main purposes of the work on URNs is to allow resources to be replicated onto multiple sites. Obtaining a copy of such a replicated resource procedes by contacting a "resolver" that knows the locations of the replicated resource. The resolver can then return one or more of those locations, and the client can use them to fetch the resource. The framework being developed in the URN-WG allows different resolution systems. This means that the resolvers may speak different protocols, and that there may be different ways of locating a resolver. This draft establishes conventions for encoding URN resolution requests and responses in HTTP 1.0 (and 1.1) requests and responses. HTTP provides a quick and easy way to begin resolving URNs. We expect that conventions for using more capable protocols to talk with URN resolvers will also be defined. 1.0 Introduction: ================== The NAPTR draft[1] describes a way of using DNS to locate resolvers for URIs. That draft provides places to specify the "resolution protocol" spoken by the resolver, as well as the "resolution services" it offers. As of this writing, the "resolution protocols" allowed by the NAPTR draft are HTTP, RCDS, HDL, and RWHOIS. (That list is expected to grow over time). The NAPTR draft also lists a variety of resolution services, such as N2L (given a URN, return a URL); N2R (Given a URN, return the named resource), etc. This draft specifies the conventions to follow to encode resolution service requests in the HTTP protocol, allowing widely available HTTP daemons to serve as URN resolvers. The reader is assumed to be familiar with the HTTP/1.0 [2] and 1.1 [3] specifications. 2.0 General Approach: ===================== The general approach used to encode resolution service requests in HTTP is quite simple: GET / HTTP/1.0 For example, if we have the URN "cid:foo@huh.com" and want a URL, we would send the request: GET N2L/cid:foo@huh.com HTTP/1.0 Because of the character set limitations on URIs, we might wish to encode the '@' character as its hex equivalent, thus the request would be GET N2L/cid:foo%40huh.com HTTP/1.0 The request could also be encoded as an HTTP 1.1 request. This would look like: GET N2L/cid:foo%40huh.com HTTP/1.1 Host: Handling these requests on the server side is easy to implement in a number of ways. The N2L request could be handled by a CGI script that took the incoming URN, looked it up in a database, and returned the URL as an HTTP redirect. Service requests like N2R or N2C could be set up so that the daemon answered the request by returning files out of N2R/ and N2C/ directories, or they could be handled by a script. One caveat should be kept in mind. The "urn:" prefix is still the subject of controversy, so some URN documents advocate treating it as optional. HTTP resolvers MUST return identical results for URIs that do and do not contain the "urn:" prefix. For example, the two request below must return identical results: GET N2L/cid:foo%40huh.com HTTP/1.0 GET N2L/urn:cid:foo%40huh.com HTTP/1.0 3.0 Service-specific details: ============================= This section goes through the various resolution services established in the URN Framework draft [4] and states how to encode each of them, how the results should be returned, and what error codes are most likely to arise [actually, error handling does not appear in this first draft]. Unless stated otherwise, the HTTP requests are formed according to the examples above, either for HTTP/1.0 or HTTP/1.1. 3.1 N2L (URN to URL): ---------------------- The request is encoded as above. The URL MUST be returned in a Location: header for the convienience of the most common case of wanting the resource. A 30X status line SHOULD be returned. HTTP/1.1 clients should be sent the 303 status code. HTTP/1.0 clients should be sent the 302 (Moved temporarily) status code unless the resolver has particular resons for using 301 (moved permanently) or 304 (not modified) codes. 3.2 N2Ls (URN to URLs): ------------------------ The request is encoded as above. The result is a list of 0 or more URLs. These should be returned in a text/plain document that first lists the number of URLs in the result, then lists the URLs, one per line. The URLs should be encoded according to the URI specification [5]. Comments may be placed in the returned file by starting a line with the '#' character. The URN for the request SHOULD be placed in a comment line that begins "# urn:". An example of such a result is shown below in figure 1. # urn:cid:foo@huh.org 3 http://www.huh.org/cid/foo.html http://www.huh.org/cid/foo.pdf ftp://ftp.foo.org/cid/foo.txt Figure 1 Simple format for returning multiple URLs [Do we need to have a continuation character for *very* long lines? I tend to think not.] 3.3 N2R (URN to Resource): --------------------------- The request is encoded as above. The resource is returned using standard HTTP mechanisms. The request may be modified using the Accept: header as in normal HTTP. 3.4 N2Rs (URN to Resources): ----------------------------- This resolution service returns multiple instances of a resource, for example, GIF and JPEG versions of an image. The judgment about the resources being "the same" resides with the naming authority that issued the URN. The request is encoded as above. The result is returned in a MIME multipart message. 3.5 N2C (URN to URC): ---------------------- The request is encoded as above. The result will have its own Internet Media Type, and should be handled as if returning any other instance of that type. [Do we need to do anything special with some of the extra headers?] 3.6 N2Ns (URN to URNs): ------------------------ While URNs are supposed to identify one and only one resource, that does not mean that a resource may have one and only one URN. For example, consider a resource that has something like "current-weather-map" for one URN and "weather-map-for-datetime-x" for another URN. The N2Ns service request lets us obtain lists of URNs that are believed equivalent at the time of the request. As the weathermap example shows, some of the equivalances will be transitory, so the result should not be cached. The request is encoded as above. The result is a list of all the URNs, known to the resolver, which identify the same resource as the input URN. The result shall be encoded as for the N2Ls request above. The original URN may appear in the list of returned URNs. 3.7 L2Ns (URL to URNs): ---------------------- The request is encoded as above. The result is returned as a text/plain body containing a list of URNs as described earlier. 3.8 L2Ls (URL to URLs): ------------------------ The request is encoded as described above. The result is a list of all the URLs that the resolver knows are associated with the resource located by the given URL. It is returned in a text/plain body encoded as described above. 3.9 L2C (URL to URC): ---------------------- The request is encoded as above, the response is the same as for the N2C request. Implementation Notes: ===================== This section gives an example of how to configure a web server to respond to the N2L resolution request. It is not intended to specify standard behavior, it is provided here merely as a courtesy for implementors. First, we assume the presence of a CGI script, n2l.pl, that processes the provided URN, converting it into a canonical format. It would remove any "urn:" prefix, decode any %encoded special characters, normalize case-insensitive parts of the URN to lower case, etc. It would then use the normalized URN as the key for a search in a database, which we assume returns the URL as a string. A sample of our implementation of that script is provided as Appendix A. We will further assume that the n2l.pl script is in the cgi-bin directory of the web server. The easiest way to invoke the n2l.pl script in response to N2L requests is to set up a Redirect directive in the srm.conf file. (This works for servers based on the original NCSA HTTP daemon, such as Apache.) The relevant Redirect directives might look like: Redirect /N2L http://urn.acl.lanl.gov/cgi-bin/n2l.pl Redirect /L2N http://urn.acl.lanl.gov/cgi-bin/l2n.pl Appendix A: n2l.pl script ========================== This is a simple perl script for the N2L resolution service. It assumes the presence of a DBM database to store the URN to URL mappings. #!/bin/perl # N2L - performs urn to url resolution $n2l_File = "...filename for DBM database..."; $urn = $ENV{'PATH_INFO'} ; if(length($urn)<3) { $error=1; } if(!$error) { $urn =~s/^(\/)(urn:)?(.*)/$3/i; # Additional canonicalization should be performed here dbmopen(%lu,$n2l_File,0444); if($lu{$urn}) { $url=$lu{$urn}; print STDOUT "Location: $url\n\n"; }else{ $error=2; } dbmclose(%lu); } if($error) { print "Content-Type: text/html \n\n"; print "\n"; print "URN Resolution: N2L\n"; print "\n"; print "

URN to URL resolution failed for the URN:

\n"; print "

$urn

\n"; print "\n"; print "\n"; } exit; References: =========== [1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", draft-ietf-urn-naptr-00.txt, October, 1996. [2] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May, 1996. [3] HTTP 1.1 draft [4] URN Framework draft [5] RFC 1630 Security Considerations ======================= Resolution requests may be of interest to traffic analysts. Resolution responses might be the target of spoofing, especially once electronic commerce takes hold and users would pay the server of a resource. The requests and responses used in this draft are amenable to encoding and signing in the manner of any other HTTP traffic. Author Contact Information: =========================== Ron Daniel Los Alamos National Laboratory MS B287 Los Alamos, NM, USA, 87545 voice: +1 505 665 0597 fax: +1 505 665 4939 email: rdaniel@lanl.gov This draft expires 5 May, 1997. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA02131 for urn-ietf-out; Wed, 30 Oct 1996 12:50:00 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA02126 for ; Wed, 30 Oct 1996 12:49:53 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15067 (mail destined for urn-ietf@services.bunyip.com); Wed, 30 Oct 96 12:49:45 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA09252 for ; Wed, 30 Oct 1996 10:49:42 -0700 (MST) Message-Id: <2.2.32.19961030175727.007123b0@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 30 Oct 1996 10:57:27 -0700 To: urn-ietf@bunyip.com From: Ron Daniel Subject: [URN] current version of NPATR draft Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Hi all, Some personal things have come up that have eaten most of my time, thus my relative quiet on the list. The WG charter calls for the NAPTR draft to be submitted this month. Earlier versions have been submitted, but here is the one that incorporates a lot of the feedback we have had up to now. I'm sending this to the ID editor today. This draft does not yet address the issue of how regexps might deal with international character sets, partly because we haven't finalized that but mostly because of lack of time to look into solutions to that problem. ------ INTERNET DRAFT Ron Daniel draft-ietf-urn-naptr-00.txt Los Alamos National Laboratory Michael Mealling Network Solutions, Inc. 30 Oct., 1996 Resolution of Uniform Resource Identifiers using the Domain Name System Status of this Memo =================== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft expires 05 May, 1997. Abstract: ========= Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. In addition to locating resolvers, the NAPTR provides for other naming systems to be grandfathered into the URN world, provides independence between the name assignment system and the resolution protocol system, and allows multiple services (Name to Location, Name to Description, Name to Resource, ...) to be offered. In conjunction with the SRV RR proposal [3], the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing. Introduction: ============= Uniform Resource Locators have been a significant advance in locating resources on the Internet. 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 to serve as persistent, location-independent identifiers for Internet resources in order to overcome most of the problems with URLs. RFC-1737 [1] 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 seperate from the way names are assigned. This is in marked contrast to most URLs, which identify the host to contact and the protocol to use. Readers are referred to [2] for background on the Knoxville framework and for additional information on the context and purpose of this proposal. Seperating 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 DNS to locate "resolvers" that can provide information on individual resources, potentially including the resource itself. To accomplish this, we "rewrite" the URI into a domain name following the rules provided in NAPTR records. Rewrite rules provide considerable power, which is important when trying to meet the goals listed above. However, collections of rules can become difficult to understand. To lessen this problem, the NAPTR rules are *always* applied to the original URI, *never* to the output of previous rules. Locating a resolver through the rewrite procedure may take multiple steps, but the beginning is always the same. Every URI has a colon-delimited prefix. NAPTR resolution begins by taking this prefix, appending the well-known suffix ".urn.net", and querying the DNS for NAPTR records at that domain name. Based on the results of this query, zero or more additional DNS queries may be needed to locate resolvers for the URI. The details of the conversation between the client and the resolver thus located are outside the bounds of this draft. Three brief examples of this procedure are given in the next section. The NAPTR RR provides the level of indirection needed to keep the naming system independent of the resolution system, its protocols, and services. Coupled with the new SRV resource record proposal[3] there is also the potential for replicating the resolver on multiple hosts, overcoming some of the most significant problems of URLs. This is an important and subtle point. Not only do the NAPTR and SRV records allow us to replicate the resource, we can replicate the resolvers that know about the replicated resource. Preventing a single point of failure at the resolver level is a significant benefit. Seperating the resolution procedure from the way names are constructed has additional benefits. Different resolution procedures can be used over time, and resolution procedures that are determined to be useful can be extended to deal with additional namespaces. Terminology =========== "Must" or "Shall" - Software that does not behave in the manner that this document says it must is not conformant to this document. "Should" - Software that does not follow the behavior that this document says it should may still be conformant, but is probably broken in some fundamental way. "May" - Implementations may or may not provide the described behavior, while still remaining conformant to this document. Brief overview and examples of the NAPTR RR: ============================================ A detailed description of the NAPTR RR will be given later, but to give a flavor for the proposal we first give a simple description of the record and three examples of its use. The key fields in the NAPTR RR are order, preference, service, flags, regexp, and replacement: * The order field specifies the order in which records MUST be processed when multiple NAPTR records are returned in response to a single query. A naming authority may have delegated a portion of its namespace to another agency. Evaluating the NAPTR records in the correct order is necessary for delegation to work properly. * The preference field specifies the order in which records SHOULD be processed when multiple NAPTR records have the same value of "order". This field lets a service provider specify the order in which resolvers are contacted, so that more capable machines are contacted in preference to less capable ones. * The service field specifies the resolution protocol and resolution service(s) that will be available if the rewrite specified by the regexp or replacement fields is applied. Resolution protocols are the protocols used to talk with a resolver. They will be specified in other documents. Resolution services are operations such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC), etc. These are discussed in the URN Framework document[2], and their behavior in a particular resolution protocol will be given in the specification for that protocol. * The flags field contains modifiers that affect what happens in the next DNS lookup, typically for optimizing the process. * The regexp field is one of two fields used for the rewrite rules, and is the core concept of the NAPTR record. The regexp field is a String containing a sed-like substitution expression. (The actual grammar for the substitution expressions is given later in this draft). The substitution expression is applied to the original URN to determine the next domain name to be queried. The regexp field should be used when the domain name to be generated is conditional on information in the URI. If the next domain name is always known, which is anticipated to be a common occurrence, the replacement field should be used instead. * The replacement field is the other field that may be used for the rewrite rule. It is an optimization of the rewrite process for the case where the next domain name is fixed instead of being conditional on the content of the URI. The replacement field is a domain name (subject to compression if a DNS sender knows that a given recipient is able to decompress names in this RR type's RDATA field). If the rewrite is more complex than a simple substitution of a domain name, the replacement field should be set to . and the regexp field used. Note that the client applies all the substitutions and performs all lookups - this is not handled in DNS servers. Note also that there is no reason to provide values in both the replacement and regexp field. Only one should be specified. If a value is specified in both, the replacement name MUST be used and the regexp string MUST be ignored. It is the belief of the developers of this document that regexps should rarely be used. The replacement field seems adequate for the vast majority of situations. Regexps are only necessary when portions of a namespace are to be delegated to different resolvers. Example 1 --------- Consider a URN that uses the hypothetical DUNS namespace. DUNS numbers are identifiers for approximately 30 million registered businesses around the world, assigned and maintained by Dunn and Bradstreet. The URN might look like: urn:duns:002372413:annual-report-1997 The first step in the resolution process is to find out about the DUNS namespace. The namespace identifier, duns, is extracted from the URN, prepended to urn.net, and the NAPTRs for duns.urn.net looked up. It might return records of the form: duns.urn.net ;; order pref flags service regexp replacement IN NAPTR 100 10 "s" "dunslink+N2L+N2C" "" _dunslink._udp.isi.dandb.com IN NAPTR 100 20 "s" "rcds+N2C" "" _rcds._udp.isi.dandb.com IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" "" _http._tcp.isi.dandb.com The order field contains equal values, indicating that no name delegation order has to be followed. The preference field indicates that the provider would like clients to use the special dunslink protocol, followed by the RCDS protocol, and that HTTP is offered as a last resort. All the records specify the "s" flag, which will be explained momentarily. The service fields say that if we speak dunslink, we will be able to issue either the N2L or N2C requests to obtain a URL or a URC (description) of the resource. The Resource Cataloging and Distribution Service (RCDS)[7] could be used to get a URC for the resource, while HTTP could be used to get a URL, URC, or the resource itself. All the records supply the next domain name to query, none of them need to be rewritten with the aid of regular expressions. The general case might require multiple NAPTR rewrites to locate a resolver, but eventually we will come to the "terminal NAPTR". Once we have the terminal NAPTR, our next probe into the DNS will be for a SRV or A record instead of another NAPTR. Rather than probing for a non-existent NAPTR record to terminate the loop, the flags field is used to indicate a terminal lookup. If it has a value of "s", the next lookup should be for SRV RRs, "a" denotes that A records should sought. A "p" flag is also provided to indicate that the next action is Protocol-specific, but that looking up another NAPTR will not be part of it. Since our example RR specified the "s" flag, it was terminal. Our next action is to lookup SRV RRs for _rcds._udp.isi.dandb.com, which will tell us hosts that can provide the necessary resolution service. That lookup might return: ;; Pref Weight Port Target _rcds._udp.isi.dandb.com IN SRV 0 0 1000 defduns.isi.dandb.com IN SRV 0 0 1000 dbmirror.com.au IN SRV 0 0 1000 ukmirror.com.uk telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their RCDS server. (The reader is referred to the SRV proposal [3] for the interpretation of the fields above). There is opportunity for significant optimization here. We can return the SRV records as additional information for terminal NAPTRs (and the A records as additional information for those SRVs). While this recursive provision of additional information is not explicitly blessed in the DNS specifications, it is not forbidden, and BIND does take advantage of it [4]. This is a significant optimization. In conjunction with a long TTL for *.urn.net records, the average number of probes to DNS for resolving DUNS URNs would approach one. Therefore, DNS server implementors SHOULD provide additional information with NAPTR responses. The additional information will be either SRV or A records. If SRV records are available, their A records may be provided as recursive additional information. Note that the example NAPTR records above are intended to represent the reply the client will see. They are not quite identical to what the domain administrator would put into the zone files. For one thing, the administrator should supply the trailing '.' character on replacement domain names. An additional difference will be illustrated later. Example 2 --------- Consider a URI namespace based on MIME Content-Ids. The URN might look like this: urn:cid:199606121851.1@mordred.gatech.edu The first step in the resolution process is to find out about the CID namespace. The namespace identifier, cid, is extracted from the URN, prepended to urn.net, and the NAPTR for cid.urn.net looked up. It might return records of the form: cid.urn.net ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "/.+@([^@]+)/\1/i" . We have only one NAPTR response, so ordering the responses is not a problem. The replacement field is empty, so we check the regexp field and use the pattern provided there. We apply that regexp to the entire URN to see if it matches, which it does. The \1 part of the substitution expression returns the string "mordred.gatech.edu". Since the flags field does not contain "s" or "a", the lookup is not terminal and our next probe to DNS is for more NAPTR records: lookup(query=NAPTR, "mordred.gatech.edu"). While mordred could have its very own NAPTR, maintaining those records on all the machines at a site as large as Georgia Tech would be an intolerable burden. Instead, a wildcard may be used so that the domain administrator at Georgia Tech has only a single NAPTR record to maintain. That record might look like: *.gatech.edu IN NAPTR ;; order pref flags service regexp replacement IN NAPTR 100 50 "s" "z3950+N2L+N2C" "" _z3950._tcp.gatech.edu. IN NAPTR 100 50 "s" "rcds+N2C" "" _rcds._udp.gatech.edu. IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" _http._tcp.gatech.edu. (Unlike all the other example records in this draft, the one above is the contents of a zone file, not the response received by the client. That is so that the wildcard can be seen.) Continuing with our example, we note that the values of the order and preference fields are equal in all records, so the client is free to pick any record. The flags field tells us that these are the last NAPTR patterns we should see, and after the rewrite (a simple replacement in this case) we should look up SRV records to get information on the hosts that can provide the necessary service. Assuming we prefer the Z39.50 protocol, our lookup might return: ;; Pref Weight Port Target _z3950._tcp.gatech.edu IN SRV 0 0 1000 z3950.gatech.edu IN SRV 0 0 1000 z3950.cc.gatech.edu IN SRV 0 0 1000 z3950.uga.edu telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their Z39.50 server. Recall that the regular expression used \1 to extract a domain name from the CID. There is a significant caveat about the use of backslashes in DNS zone files. DNS treats backslashes as the escape character so that '.' can be escaped when necessary. This means that when a regular expression is entered into the zone file, the backslashes must be escaped by another backslash. For the case of the cid.urn.net record above, the regular expression entered into the zone file should be "/.+@([^@]+)/\\1/i". When the client code actually receives the record, the pattern will have been converted to "/.+@([^@]+)/\1/i". Example 3 --------- Even if URN systems were in place now, there would still be a tremendous number of URLs. It should be possible to develop a URN resolution system that can also provide location independence for those URLs. This is related to the requirement in [1] to be able to grandfather in names from other naming systems, such as ISO Formal Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, etc. The NAPTR RR could also be used for URLs that have already been assigned. Assume we have the URL for a very popular piece of software that the publisher wishes to mirror at multiple sites around the world: http://www.foo.com/software/latest-beta.exe We extract the prefix, "http", and lookup NAPTR records for http.urn.net. This might return a record of the form http.urn.net IN NAPTR ;; order pref flags service regexp replacement 100 90 "" "" "/.*\/\/([^\/:]+)/\1/i" . This expression returns everything after the first double slash and before the next slash or colon. Backslashes are needed to escape the forward slash since the forward slash character is what separates the components of the substitution expression. (Recall from the previous example that in the zone file, this pattern actually needs to be entered as "/.*\\/\\/([^\\/:]+)/\\1/i"). Applying this pattern to the URL extracts "www.foo.com". Looking up NAPTR records for that might return: www.foo.com ;; order pref flags service regexp replacement IN NAPTR 100 100 "s" "http+L2R" "" _http._tcp.foo.com IN NAPTR 100 100 "s" "ftp+L2R" "" _ftp._tcp.foo.com Looking up SRV records for _http._tcp.foo.com would return information on the hosts that foo.com has designated to be its mirror sites. The client can then pick one for the user. NAPTR RR Format =============== The format of the NAPTR RR is given below. The DNS type code for NAPTR is 104 [this is being changed, we believe it will be assigned 35]. Domain TTL Class Order Preference Flags Service Regexp Replacement where: Domain The domain name this resource record refers to. TTL Standard DNS Time To Live field Class Standard DNS meaning Order A 16-bit integer specifying the order in which the NAPTR records MUST be processed to ensure correct delegation of portions of the namespace over time. Low numbers are processed before high numbers, and once a NAPTR is found that "matches" a URN, the client MUST NOT consider any NAPTRs with a higher value for order. Preference A 16-bit integer which specifies the order in which NAPTR records with equal "order" values SHOULD be processed, low numbers being processed before high numbers. This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. Flags A String giving flags to control aspects of the rewriting. Flags are single characters from the set [A-Z0-9]. The case of the alphabetic characters is not significant. At this time only three flags, "S", "A", and "P", are defined. "S" means that the next lookup should be for SRV records instead of NAPTR records. "A" means that the next lookup should be for A records. The "P" flag says that the remainder of the resolution shall be carried out in a Protocol-specific fashion, and we should not do any more DNS queries. The remaining alphabetic flags are reserved. The numeric flags may be used for local experimentation. The S, A, and P flags are all mutually exclusive, and resolution libraries MAY signal an error if more than one is given. (Experimental code and code for assiting in the creation of NAPTRs would be more likely to signal such an error than a client such as a browser). We anticipate that multiple flags will be allowed in the future, so implementors MUST NOT assume that the flags field can only contain 0 or 1 characters. Service Specifies the resolution service(s) available down this rewrite path. It may also specify the particular protocol that is used to talk with a resolver. A protocol MUST be specified if the flags field states that the NAPTR is terminal. If a protocol is specified, but the flags field does not state that the NAPTR is terminal, the next lookup MUST be for a NAPTR. The client MAY choose not to perform the next lookup if the protocol is unknown, but that behavior MUST NOT be relied upon. The service field may take any of the values below (using the Augmented BNF of RFC 822[5]): service_field = [ [protocol] *("+" rs)] protocol = "rcds" / "http" / "hdl" / "rwhois" rs = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C" / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C" i.e. an optional protocol specification followed by 0 or more resolution services. Each resolution service is indicated by an initial '+' character. Note that the empty string is also a valid service field. This will typically be seen at the top levels of a namespace, when it is impossible to know what services and protocols will be offered by a particular publisher within that name space. At this time the known protocols are rcds[7], hdl[8] (binary, UDP-based protocols), http[11] (a textual, TCP-based protocol), and rwhois[10] (textual, UDP or TCP based). More will be allowed later. The names of the protocols must be formed from the characters [a-Z0-9]. Case of the characters is not significant. The service requests currently allowed are: N2L - Given a URN, return a URL N2Ls - Given a URN, return a set of URLs N2R - Given a URN, return an instance of the resource. N2Rs - Given a URN, return multiple instances of the resouce, typically encoded using multipart/alternative. N2C - Given a URN, return a collection of meta-information on the named resource. The format of this response is the subject of another document. N2Ns - Given a URN, return all URNs that are also identifers for the resource. L2R - Given a URL, return the resource. L2Ns - Given a URL, return all the URNs that are identifiers for the resource. L2Ls - Given a URL, return all the URLs for instances of of the same resource. L2C - Given a URL, return a description of the resource. The actual format of the service request and response will be determined by the resolution protocol, and is the subject for other documents. Protocols need not offer all services. The labels for service requests shall be formed from the set of characters [A-Z0-9]. The case of the alphabetic characters is not significant. Regexp A STRING containing a substitution expression that is applied to the original URI in order to construct the next name to lookup. The grammar of the substitution expression is given in the next section. Replacement The next NAME to query for NAPTR, SRV, or A records depending on the value of the flags field. As mentioned above, this may be compressed. Substitution Expression Grammar: ================================ The content of the regexp field is a substitution expression. True sed(1) substitution expressions are not appropriate for use in this application for a variety of reasons, therefore the contents of the regexp field MUST follow the grammar below: subst_expr = "/" ere "/" repl "/" *flags ere = POSIX Extended Regular Expression (see [9], section 2.8.4) repl = dns_str / backref / repl dns_str / repl backref dns_str = ...... which RFC can I cite for this? 1035 seems obsolete ..... backref = "\" 1POS_DIGIT flags = "i" DNS_CHAR = "_" / "0" / "1" / ... / "9" / "a" / ... / "z" POS_DIGIT = "1" / "2" / ... / "9" ; 0 is not an allowed backref value The result of applying the substitution expression to the original URI shall be a legal domain name. Since it is possible for the regexp field to be improperly specified, such that a non-conforming domain name can be constructed, client software SHOULD verify that the result is a legal domain name before making queries on it. Backref expressions "\N" in the repl portion of the substitution expression are replaced by the (possibly empty) string of characters enclosed by '(' and ')' in the ERE portion of the substitution expression. N is a single digit from 1 through 9, inclusive. It specifies the N'th backref expression, the one that begins with the N'th '(' and continues to the matching ')'. For example, the ERE (A(B(C)DE)(F)G) has backref expressions: \1 = ABCDEFG \2 = BCDE \3 = C \4 = F \5..\9 = error - no matching subexpression The "i" flag indicates that the ERE matching SHALL be performed in a case-insensitive fashion. Furthermore, any backref replacements MAY be normalized to lower case when the "i" flag is given. Advice to domain administrators: ================================ Beware of regular expressions. Not only are they a pain to get correct on their own, but there is the previously mentioned interaction with DNS. Any backslashes in a regexp must be entered twice in a zone file in order to appear once in a query response. More seriously, the need for double backslashes has probably not been tested by all implementors of DNS servers. We anticipate that urn.net will be the heaviest user of regexps. Only when delegating portions of namespaces should the typical domain administrator need to use regexps. On a related note, beware of interactions with the shell when manipulating regexps from the command line. Since '\' is a common escape character in shells, there is a good chance that when you think you are saying "\\" you are actually saying "\". Similar caveats apply to characters such as '*', '(', etc. The URN-WG is discussing the use of international characters in URNs. The regexp package used may need to be changed from POSIX to one with the ability to handle UNICODE characters. The "a" flag allows the next lookup to be for A records rather than SRV records. Since there is no place for a port specification in the NAPTR record, when the "A" flag is used the specified protocol must be running on its default port. Usage ===== Pseudocode for a client routine using NAPTRs is given below: // // findResolver(URN) // Given a URN, find a host that can resolve it. // findResolver(string URN) { sprintf(key, "%s.urn.net", extractNS(URN)); // prepend prefix to urn.net do { rewrite_flag = false; terminal = false; if (key has been seen) { quit with a loop detected error } add key to list of "seens" records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key' sort NAPTR records by "order" field and "preference" field (with "order" being more significant than "preference"). n_naptrs = number of NAPTR records in response. curr_order = records[0].order; max_order = records[n_naptrs-1].order; // Process current batch of NAPTRs according to "order" field. for (j=0; j < n_naptrs && records[j].order <= max_order; j++) { newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp); if (!newkey) // Skip to next record if the rewrite didn't match continue; // We did do a rewrite, shrink max_order to current value // so that delegation works properly max_order = naptr[j].order; // Will we know what to do with the protocol and services // specified in the NAPTR? If not, try next record. if(!isKnownProto(naptr[j].services)) { continue; } if(!isKnownService(naptr[j].services)) { continue; } // At this point we have a sucessful rewrite and we will know // how to speak the protocol and request a known resolution // service. Before we do the next lookup, check some // optimization possibilities. if (strcasecmp(flags, "S") || strcasecmp(flags, "P")) || strcasecmp(flags, "A")) { terminal = true; services = naptr[j].services; addnl = any SRV and/or A records returned as additional info for naptr[j]. } key = newkey; rewriteflag = true; break; } } while (rewriteflag && !terminal); // Did we not find our way to a resolver? if (!rewrite_flag) { report an error return NULL; } // Leave rest to another protocol? if (strcasecmp(flags, "P")) { return key as host to talk to; } // If not, keep plugging if (!addnl) { // No SRVs came in as additional info, look them up srvs = lookup(type=SRV, key); } sort SRV records by preference, weight, ... foreach (SRV record) { // in order of preference try contacting srv[j].target using the protocol and one of the resolution service requests from the "services" field of the last NAPTR record. if (successful) return (target, protocol, service); // Actually we would probably return a result, but this // code was supposed to just tell us a good host to talk to. } die with an "unable to find a host" error; } Notes: ====== - The "urn:" prefix is a matter of religious controversy. Client code should handle the cases when it is and is not present. Similarly, if regular expressions are used in NAPTR records, they should be immune to the presence or absence of an initial "urn:". - A client MUST process multiple NAPTR records in the order specified by the "order" field, it MUST NOT simply use the first record that provides a known protocol and service combination. - If a record at a particular order matches the URI, but the client doesn't know the specified protocol and service, the client SHOULD continue to examine records that have the same order. The client MUST NOT consider records with a higher value of order. This is necessary to make delegation of portions of the namespace work. The order field is what lets site administrators say "all requests for URIs matching pattern x go to server 1, all others go to server 2". (A match is defined as: 1) The NAPTR provides a replacement domain name 2) The regular expression matches the URN ) - When multiple RRs have the same "order", the client should use the value of the preference field to select the next NAPTR to consider. However, because of preferred protocols or services, estimates of network distance and bandwidth, etc. clients may use different criteria to sort the records. - If the lookup after a rewrite fails, clients are strongly encouraged to report a failure, rather than backing up to pursue other rewrite paths. - When a namespace is to be delegated among a set of resolvers, regexps must be used. Each regexp appears in a separate NAPTR RR. Administrators should do as little delegation as possible, because of limitations on the size of DNS responses. - Note that SRV RRs impose additional requirements on clients. Acknowledgments: ================= The authors would like to thank Keith Moore for all his consultations during the development of this draft. We would also like to thank Paul Vixie for his assistance in debugging our implementation, and his answers on our questions. References: =========== [1] RFC-1737 "Functional Requirements for Uniform Resource Names", Karen Sollins and Larry Masinter, Dec. 1994. [2] draft-daigle-urn-framework-00.txt "A Uniform Resource Naming Framework", Leslie Daigle and Patrik Faltstrom, June, 1996. [3] draft-gulbrandsen-dns-rr-srvcs-03.txt " A DNS RR for specifying the location of services (DNS SRV)", Arnt Gulbrandsen and Paul Vixie, March 1996. [4] Paul Vixie, personal communication. [5] RFC-822 "Standard for the Format of ARPA Internet Text Messages", Dave H. Crocker, August 1982. [6] Keith Moore, personal communication. [7] Keith Moore, "Resource Cataloging and Distribution Service", ??? (insert as [4], renumber the others?) [8] Charles Orth, Bill Arms; Handle Resolution Protocol Specification, http://www.handle.net/docs/client_spec.html [9] IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1); IEEE Std 1003.2-1992; The Institute of Electrical and Electronics Engineers; New York; 1993. ISBN:1-55937-255-9 [10] ... rwhois spec ... [11] ... encoding resolution service requests in HTTP... Security Considerations ======================= The use of "urn.net" as the registry for URN namespaces is subject to denial of service attacks, as well as other DNS spoofing attacks. The interactions with DNSSEC are currently being studied. It is expected that NAPTR records will be signed with SIG records once the DNSSEC work is deployed. The rewrite rules make identifiers from other namespaces subject to the same attacks as normal domain names. Since they have not been easily resolvable before, this may or may not be considered a problem. Regular expressions should be checked for sanity, not blindly passed to something like PERL. Author Contact Information: =========================== Ron Daniel Los Alamos National Laboratory MS B287 Los Alamos, NM, USA, 87545 voice: +1 505 665 0597 fax: +1 505 665 4939 email: rdaniel@lanl.gov Michael Mealling Network Solutions 505 Huntmar Park Drive Herndon, VA 22070 voice: (703) 742-0400 fax: (703) 742-9552 email: michaelm@internic.net URL: http://www.netsol.com/ This draft expires 05 May, 1997. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA28136 for urn-ietf-out; Wed, 30 Oct 1996 09:17:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA28122 for ; Wed, 30 Oct 1996 09:17:16 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12632 (mail destined for urn-ietf@services.bunyip.com); Wed, 30 Oct 96 09:17:10 -0500 Received: by privateer.windrose.omaha.ne.us; Wed Oct 30 08:15 CST 1996 Message-Id: <327762F6.3701@ds.internic.net> Date: Wed, 30 Oct 1996 08:15:18 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: internet-drafts@ietf.org Cc: urn-ietf@bunyip.com Subject: [URN] (no subject) Content-Type: text/plain; charset=us-ascii; name="urn.syntax.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="urn.syntax.txt" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Internet-Draft Ryan Moats draft-ietf-urn-syntax-00.txt AT&T Expires in six months October 1996 URN Syntax Filename: draft-ietf-urn-syntax-00.txt Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document presents the syntax for Uniform Resource Names (URNs). More information on the purpose of URNs is available from [1]. NEED TO ADD ABSTRACT!!!! 1. Syntax All URNs have the following syntax: ::= ["urn:"] ":" is the Namespace Identifier, and is the Namespace Specific String. The leading "urn:" sequence is currently optional, as no closure on its definite presence or absence has been reached. The Namespace ID is used to determine the _syntactic_ interpretation of the Namespace Specific String (as discussed in [1]). RFC 1737 [2] suggests additional requirements on URN encoding, which Expires 4/97 [Page 1] INTERNET DRAFT URN Syntax October 1996 all have implications as far as limiting syntax. On the other hand, the requirement to support existing legacy naming systems has the effect of broadening syntax. Thus, we discuss the acceptable syntax for both the Namespace Identifier and the Namespace Specific String separately. 1.1 Namespace Identifier Syntax The following is the syntax for the Namespace Identifier. To (a) be consistent with all potential resolution schemes and (b) not put any undue constraints on any potential resolution scheme, the syntax for the Namespace Identifier is: ::= [ ] ::= | "-" ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case This is slightly more restrictive that what is stated in RFC 1738 [4] (which allows the period "."). Further, the Namespace Identifier is case insensitive, so that "ISBN" and "isbn" refer to the same namespace. To avoid confusion with the optional "urn:" identifier, the NID "urn" is reserved and may not be used. 1.2 Namespace Specific String Syntax Depending on the rules governing a namespace, valid identifiers in a namespace might contain characters that are reserved characters in URI syntax or non-printable ASCII characters. To accommodate the largest set of valid identifiers, the NSS portion of a URN shall use UTF-8 representation of ISO 10646 as its character set. Namespaces that do not currently use ISO 10646/UTF-8 are encouraged to migrate to it. Clients MUST be capable of %encoding the UTF-8 formatted NSS. %encoding, (as discussed in [3]) uses a percent sign "%" immediately followed by two hexadecimal digits (0-9, A-F) giving the binary code for that octet. The rules for %encoding presented in [3] apply with the following exceptions: 1. [3] states that occurrence of the '/' character in URIs must denote hierarchy, so that partial forms of a URI are possible. This restriction is unenforceable, and relative URLs do not have a scheme prefix, so we allow URNs to contain unescaped occurrences Expires 4/97 [Page 2] INTERNET DRAFT URN Syntax October 1996 of the '/' character that do not denote hierarchy. 2. As an optimization when the transport between systems is known to be 8-bit-clean, clients MAY omit the %encoding on 8-bit characters but MUST still %encode the reserved characters below. For historic reasons, the characters "#" (%23), "?" (%3F), "%" (%25), "*" (%2A), "!" (%21), "<" (%3C), ">" (%3E), and '"' (%22), are reserved and must be %encoded. Thus client implementers should accept URNs from users in an unencoded form but must encode them before sending them to a resolver. URN resolvers MUST be capable of accepting URNs that have been %encoded for either 8-bit clean or 7-bit transports. %encoding is removed first, then UTF-8 decoding is performed. URN resolvers MUST return identical results from ANY legally encoded form of the URN. It should be noted that certain characters in the Namespace Specific String syntax may have special meaning in certain namespaces. Therefore, the process of registering a namespace identifier shall include publication of a definition of which characters have a special meaning and how to encode these characters if used in a literal sense. 2. Support of existing legacy naming systems To allow for support existing legacy naming systems (as required by [2]), the Namespace Specific String shall be considered an "opaque string" in the sense of structure except as mentioned in Section 1. In addition, URN servers should be prepared to accept URNs that do not use ISO 10646/UTF-8 for those namespaces that currently use a different encoding. Note that this is not a general requirement on all resolvers, only resolvers that handle a namespace that is known not to use ISO 10646/UTF-8. 3. URN encoding for transmission Because the NSS of a URN is considered a series of octets of data, encoding URNs for transport is the responsibility of the transport mechanism and is not discussed here. Any mechanism that can handle arbitrary 8-bit data will successfully transport a URN. 4. Equivalence in URNs URNs are considered equivalent if they return the same result. For various purposes, such as caching, a test is necessary to determine equivalence without actually resolving the URNs and fetching/comparing Expires 4/97 [Page 3] INTERNET DRAFT URN Syntax October 1996 the underlying resources. "Lexical equivalence" is a stricter condition that the equivalence described above (functional equivalence). 4.1 Lexical Equivalence Lexical equivalence may be determined by comparing two URNs without making any network accesses. Two URNs are lexically equivalent if they are octet-by-octet equal after the following preprocessing 1. remove any %encoding that might be present 2. drop any preceding "urn:" token 3. normalize the case of the NID Some namespaces may define additional lexical equivalences, such as case-insensitivity of the NSS (or parts thereof). Additional lexical equivalences MUST be documented as part of namespace registration, MUST always have the effect of eliminating some of the false negatives obtained by the procedure above, and MUST NEVER says that two URNs are not equivalent if the procedure above says they are equivalent. 4.2 Functional Equivalence Resolvers determine functional equivalence based on specific rules for the namespace. Therefore, namespace registration must include documentation on how to determine functional equivalence for that namespace. 4.3 Examples The following URN comparisons highlight the difference between these types of equivalence: urn:isbn:1-23485-8-29, isbn:1-23485-8-29 are lexically equiv. urn:isbn:1-23485-8-29, ISBN:1-23485-8-29 are lexically equiv. urn:isbn:1-23485-8-29, isbn:123485829 are not lexically equiv. but may be functionally equivalent. 5. Security considerations Because of the number of potential namespaces, it must be restated that certain of the characters in the Namespace Specific String may have special meaning to certain namespace resolvers. The process of registering a namespace identifier shall therefore include publication of a definition of which characters have a special meaning and how to encode these characters if used in a literal sense. Expires 4/97 [Page 4] INTERNET DRAFT URN Syntax October 1996 6. Acknowledgments Thanks to various members of the URN working group and <> for comments on earlier drafts of this document. This document is partially supported by the National Science Foundation. 7. References Request For Comments (RFC) and Internet Draft documents are available from and numerous mirror sites. [1] L. L. Daigle, P. Faltstrom, R. Iannella. "A Frame- work for the Assignment and Resolution of Uniform Resource Names", Internet Draft (work in progress). June 1996. [2] K. Sollins, L. Masinter. "Functional Requirements for Uniform Resource Names", RFC 1737. December 1994. [3] T. Berners-Lee. "Universal Resource Identifiers in WWW", RFC 1630. June 1994. [4] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource Locators (URL)", RFC 1738. December 1994. 8. Author's address Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA Phone: +1 402 894-9456 EMail: jayhawk@ds.internic.net This Internet Draft expires April 1, 1997. Expires 4/97 [Page 5] Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA26031 for urn-ietf-out; Wed, 30 Oct 1996 04:58:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA26026 for ; Wed, 30 Oct 1996 04:58:33 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11003 (mail destined for urn-ietf@services.bunyip.com); Wed, 30 Oct 96 04:58:17 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00592-0@josef.ifi.unizh.ch>; Wed, 30 Oct 1996 10:57:55 +0100 Subject: Re: [URN] some comments To: sollins@LCS.MIT.EDU Date: Wed, 30 Oct 1996 10:57:53 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: <199610300002.TAA05714@lysithea.lcs.mit.edu> from "Karen R. Sollins" at Oct 29, 96 07:02:31 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5899 From: Martin J Duerst Message-Id: <"josef.ifi..197:30.09.96.09.57.56"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Karen Solins wrote: >Not being a big fan of character set wars, I've sat by the sidelines >for a while. Well, we didn't have a war of any kind, did we? Character set issues have to be discussed like other things, but why is nobody speaking about a "security war", or so :-?. >1) There were a couple of almost parenthetical comments about the >NAPTR proposal that made me worry. It is important that we all agree >that a URN syntax is independent of the NAPTR or any other URN >resolution proposal. If we find that there are decisions that we all >agree are important for URN syntax, for which we find that the NAPTR >proposal is ill-equipped to deal (e.g. the relationship between >character sets and regular expressions) then we should NOT remove >those from the syntax document, but rather modify the NAPTR proposal. In terms of relations between regural expressions and character sets, I guess things can work together even with UTF-8. But it is important to say on which representation the regular expressions should work: - On the %HH Representation (and exactly what is escaped, and what not). - On the 8-bit octet representation (needs an 8-bit proof implementation). - On the characters themselves (needs some additional conventions). Regular expressions for one of these representations can be transformed (even mechanically) to another one, usually with some expansion, of course. >2) About "urn:" >c) Consider how one might build applications, with respect to URNs >(it's too late for URLs to solve this problem). Suppose five new >kinds of URNs are defined and five new kinds of URLs are defined. The >application starts seeing strings with these ten new prefixes. Now >the applications must have some mechanism for dealing with all these >new things. So, assume it makes some decision, perhaps to send all >unidentifiable strings to a proxy for URNs. This is something that >acts a front end for URN resolution. For some large number of the >requests, the resolution will fail because truthfully, they were URLs. >Things could just as well have gone the other way if it was assumed >that the new strings are all URLs. Some decision must be made one way >or the other. The other alternative to the proxy is that the >application or some additional level of proxying does the >demultiplexing and is kept up to date with new kinds of URNs and >URLs. If the answer is that the application must do it, then new >versions of every application using URNs must be distributed. If the >answer is that there is a second level of proxying, we have now made >it take even longer to get an answer, by including another network >transit to the time to respond. While being one of the experts on internationalization (in this list, at least), I am still having problems with the difference between URLs and URNs. The above helped quite a bit, but I still wonder: Aren't URLs just in some way a subcategory of URNs? If I send an URL to a resolver, should it not just resolve to itself (instead of producing an error)? Of course, if the client iterates on this answer, an endless loop would result. But the resolver could have returned alternatives, which might be exploited. Couldn't some implementation send everything they get in terms of URL/URN to a resolver? Couldn't we start doing resolution on what up to now were plain URLs, i.e. that an older browser just goes directly (well, with DNS lookup and stuff, anyway) to a single location when seeing a http: URL, but a newer browser would contact a resolver first? Is it necessary to distinguish these two behaviours by urn:http:... and http:..., or mabye urnhttp:... and http:...? One reason for asking such questions is that I know that everybody here (except me:-) knows the conceptual and technical differences between URLs and URNs, but actual implementern will know less, resource creators even less, and plain users even less. >3) About those character set discussions, perhaps we should step back >a little. If I'm understanding the issues (and I certainly don't >claim to be an expert on character set issues), it seems to me that >the bottom line issue is that the thing to be avoided is false >positives when looking at equality or equivalence of URNs. The >problem arises when something concludes that two URNs, once >transcoded, transliterated, or whatever, are identifying the same >resource, when they were intended to identify different ones. False >negatives in this situation may cause additional work, additional >network traffic, and/or additional cost in other dimensions, but not >incorrect behavior. It is the incorrect behavior that must take the >front seat. With that in place, clearly the more effective we can be >at avoiding false negatives the nicer it is, but that must be >secondary. > >It seems to me if one keeps this in mind, some of the concerns that >were brought up may fall into place a little more easily. Such >questions as two encodings for "A grave" take a backseat to making >sure that the two encodings do not to get mapped into one, when in >some namespace they are considered distinct, thus allowing for >differentiation among resources. Having thought again about some earlier comments I have made, and also about some comments of Larry in a different list, I think this is a very valid point. Even if we would specify that A-Grave and A followed by combining-grave are equivalent, it would be difficult that not suddenly somebody creates e.g. two different files on an ftp server, only differing in this aspect, because his/her file system doesn't know about the way we have defined equivalence. Nevertheless, I think we should not completely ignore this problem, make an active and concious decision about it, give some guidelines for implementors about how to proceed, and put in some recommendation and/or warnings in the relevant document(s). Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA22121 for urn-ietf-out; Tue, 29 Oct 1996 20:02:39 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA22116 for ; Tue, 29 Oct 1996 20:02:37 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07434 (mail destined for urn-ietf@services.bunyip.com); Tue, 29 Oct 96 20:02:31 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id RAA26180; Tue, 29 Oct 1996 17:00:56 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id RAA21309; Tue, 29 Oct 1996 17:01:25 -0800 (PST) Date: Tue, 29 Oct 1996 17:01:25 -0800 (PST) From: Terry Allen Message-Id: <199610300101.RAA21309@ishtar.fsc.fujitsu.com> To: sollins@LCS.MIT.EDU, urn-ietf@bunyip.com Subject: Re: [URN] some comments Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Karen writes: | Not being a big fan of character set wars, I've sat by the sidelines I hope we haven't been warring. I just caught up on FTPEXT (where, incidentally, Unicode is also an issue), and *that's* war. | 1) There were a couple of almost parenthetical comments about the | NAPTR proposal that made me worry. It is important that we all agree | that a URN syntax is independent of the NAPTR or any other URN | resolution proposal. Absolutely. And, skipping the discussion of "urn:", I believe this is relevant to your last point: | Now, my one other comment relates to an earlier topic - security. I | am in complete agreement with Ron (and whoever else) who said that | security (and let's make sure we include integrity of the information | in "security") that no one (user or publisher) should be required to | support security and integrity. But...if the infrastructure | supporting URN resolution (which IS the topic of discussion for this | WG) is to be able to provide security and integrity for anyone, there | may be some requirements it will place on its clients (users and | publishers). I would like to be confident that we are all in | agreement about the following: in the case where there are security | measures that must be in place within the infrastructure in order to | provide security (at some agreed upon level) to those who want it, | even if that imposes some security requirements on those who don't | want it, that the choice of having the security mechanisms in place | will take precedence over not have the mechanisms. Of course, within | that constraint, wherever security isolation can be provided, security | mechanisms should NOT be required. You phrase this as a general matter, and we clearly cannot pretend to govern all resolutions methods. As a trivial example, one method of URN resolution is the publication of physical books containing URNs and other information. Some URNs may be resolvable only by such non-Internet means. Suppose the government were to insist that copies of such books that are sold to the government must be printed on tamper-resistant paper (someone wanting security). Is that something this group should concern itself with? I don't think so, I don't think that one can speak of *the* "infrastructure supporting URN resolution," and so I don't agree with your very general statement. Can you sharpen it up some? Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA21586 for urn-ietf-out; Tue, 29 Oct 1996 19:02:48 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA21579 for ; Tue, 29 Oct 1996 19:02:44 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06918 (mail destined for urn-ietf@services.bunyip.com); Tue, 29 Oct 96 19:02:34 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id TAA05714; Tue, 29 Oct 1996 19:02:31 -0500 Date: Tue, 29 Oct 1996 19:02:31 -0500 Message-Id: <199610300002.TAA05714@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: urn-ietf@bunyip.com Subject: [URN] some comments Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com Not being a big fan of character set wars, I've sat by the sidelines for a while. I just reread all the messages to this list for the last couple of weeks, trying to pick out places where there may be deeper issues. So, I have here a small list of somewhat disconnected comments and questions. For some of you this may not get to the heart of the problems - my apologies. Most of the discussion has centered around the URN syntex draft written by Ryan Moats, so I will comment on that subject first. 1) There were a couple of almost parenthetical comments about the NAPTR proposal that made me worry. It is important that we all agree that a URN syntax is independent of the NAPTR or any other URN resolution proposal. If we find that there are decisions that we all agree are important for URN syntax, for which we find that the NAPTR proposal is ill-equipped to deal (e.g. the relationship between character sets and regular expressions) then we should NOT remove those from the syntax document, but rather modify the NAPTR proposal. 2) About "urn:", I don't know whether I come from the other "religious" viewpoint, but unless we have additional requirements and mechanisms in place, I think it would be a really bad idea to make the "urn:" optional. Let's look at a few points here: a) I don't believe that there is anything in the URL or URN requirements documents (or any other RFCs) that states that prefixes for URNs (without the "urn:") and URLs cannot be the same. b) Given a random string (say foo://opaque_string) in some specific situation, something needs to decide what it means and what to do with it. If the string is a URN it identifies a resource, while, if it is a URL it identifies a location (in other words, it identifies an abstraction from the perspective of a transport protocol, in fact, the "foo" transport protocol). So, now, without any specification of urn-hood or url-hood, who makes a decision and how? c) Consider how one might build applications, with respect to URNs (it's too late for URLs to solve this problem). Suppose five new kinds of URNs are defined and five new kinds of URLs are defined. The application starts seeing strings with these ten new prefixes. Now the applications must have some mechanism for dealing with all these new things. So, assume it makes some decision, perhaps to send all unidentifiable strings to a proxy for URNs. This is something that acts a front end for URN resolution. For some large number of the requests, the resolution will fail because truthfully, they were URLs. Things could just as well have gone the other way if it was assumed that the new strings are all URLs. Some decision must be made one way or the other. The other alternative to the proxy is that the application or some additional level of proxying does the demultiplexing and is kept up to date with new kinds of URNs and URLs. If the answer is that the application must do it, then new versions of every application using URNs must be distributed. If the answer is that there is a second level of proxying, we have now made it take even longer to get an answer, by including another network transit to the time to respond. So, although I don't believe it is absolutely necessary, I do believe that, first, if we don't require the "urn:" prefix we MUST document in an RFC that URN and URL prefixes come from the same namespace and do not overlap, and, second, if we do that, we understand that we are potentially increasing the work to achieve new URN and URL resolution activities. 3) About those character set discussions, perhaps we should step back a little. If I'm understanding the issues (and I certainly don't claim to be an expert on character set issues), it seems to me that the bottom line issue is that the thing to be avoided is false positives when looking at equality or equivalence of URNs. The problem arises when something concludes that two URNs, once transcoded, transliterated, or whatever, are identifying the same resource, when they were intended to identify different ones. False negatives in this situation may cause additional work, additional network traffic, and/or additional cost in other dimensions, but not incorrect behavior. It is the incorrect behavior that must take the front seat. With that in place, clearly the more effective we can be at avoiding false negatives the nicer it is, but that must be secondary. It seems to me if one keeps this in mind, some of the concerns that were brought up may fall into place a little more easily. Such questions as two encodings for "A grave" take a backseat to making sure that the two encodings do not to get mapped into one, when in some namespace they are considered distinct, thus allowing for differentiation among resources. *** Now, my one other comment relates to an earlier topic - security. I am in complete agreement with Ron (and whoever else) who said that security (and let's make sure we include integrity of the information in "security") that no one (user or publisher) should be required to support security and integrity. But...if the infrastructure supporting URN resolution (which IS the topic of discussion for this WG) is to be able to provide security and integrity for anyone, there may be some requirements it will place on its clients (users and publishers). I would like to be confident that we are all in agreement about the following: in the case where there are security measures that must be in place within the infrastructure in order to provide security (at some agreed upon level) to those who want it, even if that imposes some security requirements on those who don't want it, that the choice of having the security mechanisms in place will take precedence over not have the mechanisms. Of course, within that constraint, wherever security isolation can be provided, security mechanisms should NOT be required. Cheers, Karen ___________________________________________________________________ Karen R. Sollins sollins@lcs.mit.edu Research Scientist Phone: 617/253-6006 M.I.T. Laboratory for Computer Science Fax: 617/253-2673 545 Technology Square Cambridge, MA 02139 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA28740 for urn-ietf-out; Mon, 28 Oct 1996 10:02:30 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA28733 for ; Mon, 28 Oct 1996 10:02:20 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21808 (mail destined for urn-ietf@services.bunyip.com); Mon, 28 Oct 96 10:02:12 -0500 Message-Id: <9610281502.AA21808@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Mon Oct 28 09:00 CST 1996 From: "Ryan Moats" To: "Martin J Duerst" , "masinter@parc.xerox.com" Cc: "urn-ietf@bunyip.com" Date: Sun, 27 Oct 96 18:10:51 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] URN Syntax thoughts Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Fri, 25 Oct 1996 21:31:30 +0100 (MET), Martin J Duerst wrote: >Larry Masenter wrote: > >>> Is it so much different to back away from the 10646/UTF-8 statement in >>> the syntax document and say "As part of the registration procedure, the >>> character set/encoding used by a namespace shall be documented, or some >>> such words to that effect." >> >>This is completely inadequate: the user and client need to be able to >>translate the thing that the user sees on the cereal boxtop (sequence >>of glyphs) into what gets transmitted over the network (sequence of >>octets) in an unambiguous way. The translation method can't vary >>depending on the the first part of what's translated. > >I definitely agree that we should not let things float too much. >In may view, it should run down to the following statements: > >- If you create something new, and deal with characters, use UTF-8. >- If you have something old, try to move towards UTF-8. >- If you don't do UTF-8, be aware that support is not guaranteed > (i.e. you will have to print %HH on your cardboard box,...). > [So this means that the translation method doesn't vary. > It's just not there in some cases :-).] >- If you use an octet sequence that is not UTF-8, we won't consider > that an outright error. > I need to think about this some more, but I think I can live with this. My concern about the UTF-8 discussion was not just that I wasn't seeing any closure, I wasn't seeing any direction of closure (and the discussion seem to be growing in scope) which is why I started the new thread... Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA02666 for urn-ietf-out; Fri, 25 Oct 1996 17:36:49 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA02654 for ; Fri, 25 Oct 1996 17:36:45 -0400 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09356 (mail destined for urn-ietf@services.bunyip.com); Fri, 25 Oct 96 17:36:35 -0400 Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id OAA14553; Fri, 25 Oct 1996 14:34:35 -0700 (PDT) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id OAA07165; Fri, 25 Oct 1996 14:34:58 -0700 (PDT) Date: Fri, 25 Oct 1996 14:34:58 -0700 (PDT) From: Terry Allen Message-Id: <199610252134.OAA07165@ishtar.fsc.fujitsu.com> To: jayhawk@ds.internic.net, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] URN Syntax thoughts Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Ron: | >I'm not seeing any closure on the UTF-8 issue, | | I'm willing to give this issue some more time. I have not seen any as am I. | strong opposition to using UTF-8. What I think is the outstanding | question on the use of UTF-8 is something like "what about namespaces | that want to provide octets that are not UTF-8?" | | My answer: Tough. If people want to ship around binary data as their | names, then they can encode it in a fashion similar to the data: | URL scheme where they have 2 choices: | 1) Base64 (which uses only safe characters) | 2) %encoding (which uses only safe characters) Suppose they don't, though? What is the effect of saying "tough"? What happens to people who contumaciously people promulgate URNs that (perhaps only in part) are not encoded in UTF-8 (and, perhaps, are not even in Unicode). Or who do this because their software is buggy or because their employers made them do it (think Dilbert)? What will break? The intuition of Joe Namespace is likely to be that he can construct a URN for his unique name (XXXXXX, not in UTF-8) by prefixing those hierarchical name space division markers he usually takes for granted (A/B/C/XXXXXX), prefixing the NIS for his top-level name space (sludge:A/B/C/XXXXXX), and depending on his religion (though we really should not use the term "religious issue" in a formal document ...), prefixing "urn:". Leaving aside the question of whether A/B/C is in UTF-8, is it plausible to believe that Joe Namespace will accept a regime in which his unique name is XXXXXX but appears in a URN as XYZXYZ (UTF-8 encoded)? I'm inclined to think that urn:sludge:A/B/C/XXXXXX should be allowed because it seems like common sense (to me, at the moment, still), and will occur (because it seems like common sense to Joe Namespace, or his employer, or because Joe lacks a tool that does UTF-8 conversion). What arguments are there that urn:sludge:A/B/C/XXXXXX cannot be resolved if urn:sludge:A/B/C/XYZXYZ can be? (as distinct from arguments that XYZXYZ can be resolved faster or more efficiently than XXXXXX.) And what of the two subcases: A/B/C/ is UTF-8 or is not? Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA00902 for urn-ietf-out; Fri, 25 Oct 1996 15:32:00 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA00897 for ; Fri, 25 Oct 1996 15:31:58 -0400 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07959 (mail destined for urn-ietf@services.bunyip.com); Fri, 25 Oct 96 15:31:53 -0400 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01036-0@josef.ifi.unizh.ch>; Fri, 25 Oct 1996 21:31:31 +0100 Subject: Re: [URN] URN Syntax thoughts To: masinter@parc.xerox.com Date: Fri, 25 Oct 1996 21:31:30 +0100 (MET) Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com In-Reply-To: <96Oct25.090902pdt."2759"@golden.parc.xerox.com> from "Larry Masinter" at Oct 25, 96 09:09:02 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3112 From: Martin J Duerst Message-Id: <"josef.ifi..739:25.09.96.20.31.46"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Larry Masenter wrote: >> Is it so much different to back away from the 10646/UTF-8 statement in >> the syntax document and say "As part of the registration procedure, the >> character set/encoding used by a namespace shall be documented, or some >> such words to that effect." > >This is completely inadequate: the user and client need to be able to >translate the thing that the user sees on the cereal boxtop (sequence >of glyphs) into what gets transmitted over the network (sequence of >octets) in an unambiguous way. The translation method can't vary >depending on the the first part of what's translated. I definitely agree that we should not let things float too much. In may view, it should run down to the following statements: - If you create something new, and deal with characters, use UTF-8. - If you have something old, try to move towards UTF-8. - If you don't do UTF-8, be aware that support is not guaranteed (i.e. you will have to print %HH on your cardboard box,...). [So this means that the translation method doesn't vary. It's just not there in some cases :-).] - If you use an octet sequence that is not UTF-8, we won't consider that an outright error. I repeat the main reasons for why I think this amount of flexibility is necessary. First, there are cases where you don't know what encoding is used. You could treat that like the data URL, but in some cases, this would mean that you would have to split functionality that now comes together. FTP is a typical example. It is very difficult to specify that servers that don't know the encodings of their filenames should use a data-like scheme, and those that know the encoding can use UTF-8. It is much more encouraging to say: If you know, convert to UTF-8; if you don't know, use raw octets. This gives a very smooth transition. The other reason for flexibility is political. Some people are, for some sometimes rather strange reasons, heavily against Unicode. It's much easier to deal with them if we don't "force everybody to use Unicode". Still, we want things to go in that direction, so simplify things, and so just saying "the namespaces take care" is of no use. A minor, but maybe serious, problem in this approach is the following: Assume at some point (either at entry or at some server) some general UTF-8 URN normalization/canonicalization is done. It's easy to say that no such thing should be done on octet sequences that are not legal UTF-8. But there is a slight possiblity that some arbitrary octet sequence is UTF-8 (and not pure ASCII). Here are the probabilities, derived mostly by simulation: Length of sequence approximate probability 1 0 2 1/32 3 1/28 4 1/35 5 1/48 6 1/70 7 1/107 8 1/175 9 1/287 10 1/465 15 1/6450 20 1/100000 Of course, the probabilities of octet sequences that would be affected by normalization is much much lower, esp. if this normalization is restricted to cases of the A-grave type. It might be possible to construct a RISK case out of this :-(. Still, I think a little bit of flexibility for backwards compatibility is desirable. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA00247 for urn-ietf-out; Fri, 25 Oct 1996 14:28:12 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA00242 for ; Fri, 25 Oct 1996 14:28:10 -0400 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07369 (mail destined for urn-ietf@services.bunyip.com); Fri, 25 Oct 96 14:28:05 -0400 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00862-0@josef.ifi.unizh.ch>; Fri, 25 Oct 1996 20:27:12 +0100 Subject: Re: [URN] Unicode for NSS query To: masinter@parc.xerox.com (Larry Masinter) Date: Fri, 25 Oct 1996 20:27:11 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: <96Oct24.182227pdt."2763"@golden.parc.xerox.com> from "Larry Masinter" at Oct 24, 96 06:22:27 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2336 From: Martin J Duerst Message-Id: <"josef.ifi..655:25.09.96.19.27.19"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Larry Masenter wrote: >The way that i think of this is that the constraints: > >1 'has a unique sequence of octets that can be unambiguously interpreted by a > system' > >2 'has a unique sequence of glyphs that can be unambiguously displayed > and subsequently entered by a user' > >cannot be mutually satisfied. The simplest way to think about this is >to have two kinds of representations of URNs: as a canonical sequence >of octets, and as a user-entered string. Every URN has a single >canonical representation, and the user entry method must map it to the >canonical representation. No embedded URN-as-protocol-element should >require canonicalization. The protocol for 'canonicalizing' a name may >not be the same as the protocol for 'resolving' a name or asking for >information about it. Larry, I have some difficulties understanding you. By user-entered string, do you mean the stuff on the cardboard box, and maybe the pixels on the screen that the user sees when typing it in? Or do you mean some kind of represenation that is moved around inside the computer? And why do you think that the two cannot be mutually satisfied? It works for ASCII, anyway. For some other scripts, it is a little bit more difficult, but some of these problems are similar to what we have currently when somebody confuses "O" and "0" or "l" and "1" and "I", and others, such as the A-grave case, could be defined by normalization, which would also be required for deriving your "canonical representation". The problem of embedding is of course a tough one. One way to interpret your statement is that it means that e.g. in an HTML document, URL/Ns would only appear in the %HH notation (because arbitrary octets would not usually pass the SGML parser). This would indeed be rather restricting. I could easily immagine that a Japanese document author constructs a document encoded in SJIS, and just writes down a Japanese URL/N from the cardbord box as is. It would technically be no problem for the browser to take this URL/N, interpret it as SJIS, convert it to UTF-8, maybe normalize it, and then pass it to some resolving mechanism. If you see some problems with this, please tell me. If you don't want to call the visible (e.g. in SJIS) form an URL/N, I can accept that, but users will soon call it that way anyway. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA29163 for urn-ietf-out; Fri, 25 Oct 1996 12:32:40 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA29153 for ; Fri, 25 Oct 1996 12:32:36 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06506 (mail destined for urn-ietf@services.bunyip.com); Fri, 25 Oct 96 12:32:33 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA02086; Fri, 25 Oct 1996 10:31:07 -0600 (MDT) Message-Id: <2.2.32.19961025163845.006a40d8@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 25 Oct 1996 10:38:45 -0600 To: jayhawk@ds.internic.net, "URN mailing list" From: Ron Daniel Subject: Re: [URN] URN Syntax thoughts Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke jayhawk@ds.internic.net (at least at 08:15 AM 10/25/96) >I'm not seeing any closure on the UTF-8 issue, I'm willing to give this issue some more time. I have not seen any strong opposition to using UTF-8. What I think is the outstanding question on the use of UTF-8 is something like "what about namespaces that want to provide octets that are not UTF-8?" My answer: Tough. If people want to ship around binary data as their names, then they can encode it in a fashion similar to the data: URL scheme where they have 2 choices: 1) Base64 (which uses only safe characters) 2) %encoding (which uses only safe characters) I say we go with UTF-8 as the interpretation of any 8-bit characters. Comments? Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA28926 for urn-ietf-out; Fri, 25 Oct 1996 12:10:15 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA28920 for ; Fri, 25 Oct 1996 12:10:08 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06305 (mail destined for urn-ietf@services.bunyip.com); Fri, 25 Oct 96 12:09:35 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16805(8)>; Fri, 25 Oct 1996 09:09:22 PDT Received: by golden.parc.xerox.com id <2759>; Fri, 25 Oct 1996 09:09:02 PDT To: jayhawk@ds.internic.net Cc: urn-ietf@bunyip.com In-Reply-To: <9610251310.AA16285@qsun2.ho.att.com.qsun2> (jayhawk@ds.internic.net) Subject: Re: [URN] URN Syntax thoughts From: Larry Masinter Message-Id: <96Oct25.090902pdt."2759"@golden.parc.xerox.com> Date: Fri, 25 Oct 1996 09:09:02 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com > Is it so much different to back away from the 10646/UTF-8 statement in > the syntax document and say "As part of the registration procedure, the > character set/encoding used by a namespace shall be documented, or some > such words to that effect." This is completely inadequate: the user and client need to be able to translate the thing that the user sees on the cereal boxtop (sequence of glyphs) into what gets transmitted over the network (sequence of octets) in an unambiguous way. The translation method can't vary depending on the the first part of what's translated. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA27378 for urn-ietf-out; Fri, 25 Oct 1996 09:12:19 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA27373 for ; Fri, 25 Oct 1996 09:12:17 -0400 From: jayhawk@ds.internic.net Received: from cagw2.att.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04877 (mail destined for urn-ietf@services.bunyip.com); Fri, 25 Oct 96 09:12:15 -0400 Received: from qsun.ho.att.com by caig2.att.att.com (SMI-8.6/EMS-1.2 sol2) id JAA01582; Fri, 25 Oct 1996 09:14:29 -0400 Received: from qsun2.ho.att.com.qsun2 by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS) id AA13672; Fri, 25 Oct 96 09:12:03 EDT Received: from sloop ([135.16.157.189]) by qsun2.ho.att.com.qsun2 (5.x/EMS-1.2 sol2) id AA16285; Fri, 25 Oct 1996 09:10:06 -0400 Message-Id: <9610251310.AA16285@qsun2.ho.att.com.qsun2> Original-From: "Ryan Moats" To: "URN mailing list" Date: Fri, 25 Oct 96 08:15:06 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] URN Syntax thoughts Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: jayhawk@ds.internic.net Errors-To: owner-urn-ietf@bunyip.com Folks- I'm not seeing any closure on the UTF-8 issue, and having seen some of the comments on allowing namespaces (either existing or new?) to use alternate things by including that information in their registration document, I see the situation that a URN resolver will have to know about schemes documented in many different documents. Is it so much different to back away from the 10646/UTF-8 statement in the syntax document and say "As part of the registration procedure, the character set/encoding used by a namespace shall be documented, or some such words to that effect." This really slams the lexical equivalence discussion at the client down to "remove %encoding and do octet by octet comparison to determine if the NSS is equivalent. If the NSSs are equivalent and the NIDs are equivalent (case insensitivity here), the URNs are deemed equivalent". It doesn't (in my mind) change the lexical equivalence discussion at the server and I think it simplifies the issue. We can put in a statement like "new namespaces SHOULD use 10646/UTF-8" somewhere. I know that somebody mentioned this (I can't find the mail right now...) I'm just asking the question over again (with a new subject thread so I can keep it seperate from the other discussions). Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA21564 for urn-ietf-out; Thu, 24 Oct 1996 21:26:24 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA21559 for ; Thu, 24 Oct 1996 21:26:17 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02433 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 21:25:35 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16491(3)>; Thu, 24 Oct 1996 18:22:37 PDT Received: by golden.parc.xerox.com id <2763>; Thu, 24 Oct 1996 18:22:27 PDT To: mduerst@ifi.unizh.ch Cc: urn-ietf@bunyip.com In-Reply-To: <"josef.ifi..582:24.09.96.20.47.43"@ifi.unizh.ch> (message from Martin J Duerst on Thu, 24 Oct 1996 13:47:41 PDT) Subject: Re: [URN] Unicode for NSS query From: Larry Masinter Message-Id: <96Oct24.182227pdt."2763"@golden.parc.xerox.com> Date: Thu, 24 Oct 1996 18:22:27 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com The way that i think of this is that the constraints: 1 'has a unique sequence of octets that can be unambiguously interpreted by a system' 2 'has a unique sequence of glyphs that can be unambiguously displayed and subsequently entered by a user' cannot be mutually satisfied. The simplest way to think about this is to have two kinds of representations of URNs: as a canonical sequence of octets, and as a user-entered string. Every URN has a single canonical representation, and the user entry method must map it to the canonical representation. No embedded URN-as-protocol-element should require canonicalization. The protocol for 'canonicalizing' a name may not be the same as the protocol for 'resolving' a name or asking for information about it. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA20416 for urn-ietf-out; Thu, 24 Oct 1996 18:45:25 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA20411 for ; Thu, 24 Oct 1996 18:45:18 -0400 Received: from h-207-1-145-102.netscape.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01465 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 18:45:16 -0400 Received: from didyma (localhost [127.0.0.1]) by didyma.mcom.com (8.7.3/8.7.3) with SMTP id PAA12927 for ; Thu, 24 Oct 1996 15:45:06 -0700 (PDT) Message-Id: <326FF172.581D@netscape.com> Date: Thu, 24 Oct 1996 15:45:06 -0700 From: "Frederick G.M. Roeber" Organization: Netscape X-Mailer: Mozilla 3.0b8Gold (X11; U; SunOS 5.5 sun4u) Mime-Version: 1.0 To: urn-ietf@bunyip.com Subject: [URN] Couple points about the draft.. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Frederick G.M. Roeber" Errors-To: owner-urn-ietf@bunyip.com 1) Under "NAPTR RR Format," under "Flags," second paragraph: "The S and A flags are mutually exclusive, and resolution libraries SHOULD signal an error so that bad NAPTRs can be quickly detected." I disagree with that SHOULD. It's fine for experimental code, but not for something I ship to customers: they're not going to expect or like receiving error messages for someone else's mistakes. I think it should be something more like, "The S and A flags are mutually exclusive, [and clients should cope]. Clients MAY point out this error so that bad NAPTRs might be quickly detected." 2) Without yet throwing my ante into the "`urn:' being optional" discussion, I'd like to point out an unclear statement: Under "Notes:," the first note: "The `urn:' prefix is a matter of religious controversy. Client code should handle...." Is that "should" a SHOULD? Ron pointed out privately that if the prefix is indeed optional, then the "should" has to be a MUST. -- Frederick G.M. Roeber Physicist in Residence, Netscape Communications Corporation Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA19325 for urn-ietf-out; Thu, 24 Oct 1996 17:02:28 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA19316 for ; Thu, 24 Oct 1996 17:02:23 -0400 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00362 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 17:02:13 -0400 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01664-0@josef.ifi.unizh.ch>; Thu, 24 Oct 1996 23:02:14 +0100 Subject: Re: [URN] Unicode for NSS query To: jayhawk@ds.internic.net Date: Thu, 24 Oct 1996 23:02:13 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: <9610242040.AA05679@qsun2.ho.att.com.qsun2> from "jayhawk@ds.internic.net" at Oct 24, 96 03:46:15 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5224 From: Martin J Duerst Message-Id: <"josef.ifi..881:24.09.96.22.02.15"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ryan wrote: > >On Thu, 24 Oct 1996 21:47:41 +0100 (MET), Martin J Duerst wrote: > >>> >>>On Thu, 24 Oct 1996, Martin J Duerst wrote: >>> >>>> >>>> I have suggested that we might be required to thing in terms of >>>> both characters and octets. For some things, similar to a data: >>>> URL, thinking in characters might be artificial. For some >>>> other things, such as URLs, thinking in octets may to some >>>> extent be necessary because of backwards compatibility issues >>>> (assume an URL scheme is extended and decides to use some >>>> weird RFC 1522-like method for encoding characters, and this >>>> would have to be grandfathered). >>>> >>> >>>I have thought about the same thing, and I admit that I am not altogether >>>enthusiastic about RFC 1522 style encoding of URNs, but it may be forced >>>upon us. >> >>Well, I didn't mean that this is currently the case. The ftp >>i18n extensions, for example, are happily going in the direction >>of UTF-8 and would very well fit together with our proposal. >> >>But I have made the experience that trying to specify UNicode only >>can meet quite some resistance. Some people, for whatever reasons, >>are strongly anti-unicode. If you specify something like >>"urns use Unicode and nothing else", they may start to complain. >>If you say "urns should use Unicode, and clients should interpret >>urns as Unicode if possible, but if really necessary, an NSS >>can use something else" then it's difficult to oppose, even >>if maybe in actual practice, there will not be a single NSS >>that ever specifies something else than Unicode. > >Huh? My "knee-jerk" reaction is that by saying that client should convert from >an NSS that isn't in Unicode(10646)/UTF-8 shall be converted before >being sent to the URN resolver handles this nicely. I include in this statement >the act of entering a NSS at an interface in some other encoding (ASCII, etc.) Yes, but sometimes you would just not know what charset the stuff is in. Note that there are two things: - The user types in an urn into an application that locally uses some other encoding, which then gets converted to UTF-8 at the moment the application knows this is an URN. - There is an NSS that for some reasons, and maybe for some of its namespace only, doesn't have a clue about what characters it's dealing with, or explicitly wants to have the relation between characters and octet values different that UTF-8 for some reason whatsoever. It is the later that I am speaking about, not the former. >>NSSs or URL shemes (I still have problems distingushing them) >>themselves might also do the same thing, namely saying that >>in general, character semantics should be ISO 10646/UTF-8, but >>that other things would be tolerated for backwards compatibility. >>This is exactly the case for ftp, where a lot of 8-bit filenames >>are already existing and in use, although not UTF-8. > >I'm not sure I'm comfortable with this. My view is that the documentation of the NID >would specify this as an exception to the syntax document and the syntax document >says "here's the syntax, but exceptions are allowed for namespaces that document >there exceptions elsewhere? Seems awfully kludgy to me... Yes, in some sense it is. But this is reality, which is not always simple and logic. Take ftp as an example. Although not officially standardised, a lot of ftp hosts have files with 8-bit octets in their names. Although you can make some guesses about what characters these octets stand for, you are really not sure. Even on the same server, or in the same URL, different files, or different parts, may have different encodings, because the encodings reflect the settings of the users that created these filenames. And it is impossible to force upon all existing ftp servers that they suddenly know what characters their filenames represent if up to now URLs have been octets and nothing else. The only thing we can hope for, and which we are working for in the ftp-wg, is a gradual transition towards UTF-8. >>It is also important because not every arbitrary sequence of >>8-bit octets is an UTF-8 sequence. What should browsers, resolvers, >>and all the other components of our URN arichitecture do with >>these? > >I expect that anything that tries to resolve a sequence of 8-bit octets that aren't a >UTF-8 sequence should fail, unless the namespace has provided information otherwise. That might be a solution, unless there are resolvers that do resolution without knowing much about specific namespaces. But for existing URL schemes, the assumption would have to be that they implicitly specify otherwise. >I see this as related to the above issue: The two basic choices are: > >(1) Allow things other than UTF-8 (and force the exceptions to be documented as >part of namespace registration). The resolvers then have to use the namespace >specific information (including exceptions). (2) Do not allow other than UTF-8 and >reject the arbitrary 8-bit octet sequence as unresolvable if it is unresolvable. > >The first is cleaner from the point of view of the end-users, the second from the point >of view of internal clenliness. The second, at any rate, is not very practical. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA19048 for urn-ietf-out; Thu, 24 Oct 1996 16:41:43 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA19042 for ; Thu, 24 Oct 1996 16:41:38 -0400 From: jayhawk@ds.internic.net Received: from cagw2.att.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29877 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 16:41:34 -0400 Received: from qsun.ho.att.com by caig2.att.att.com (SMI-8.6/EMS-1.2 sol2) id QAA07284; Thu, 24 Oct 1996 16:43:52 -0400 Received: from qsun2.ho.att.com.qsun2 by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS) id AA01126; Thu, 24 Oct 96 16:41:22 EDT Received: from sloop ([135.16.157.189]) by qsun2.ho.att.com.qsun2 (5.x/EMS-1.2 sol2) id AA05679; Thu, 24 Oct 1996 16:40:17 -0400 Message-Id: <9610242040.AA05679@qsun2.ho.att.com.qsun2> Original-From: "Ryan Moats" To: "Martin J Duerst" Cc: "URN mailing list" Date: Thu, 24 Oct 96 15:46:15 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] Unicode for NSS query Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: jayhawk@ds.internic.net Errors-To: owner-urn-ietf@bunyip.com On Thu, 24 Oct 1996 21:47:41 +0100 (MET), Martin J Duerst wrote: >> >>On Thu, 24 Oct 1996, Martin J Duerst wrote: >> >>> >>> I have suggested that we might be required to thing in terms of >>> both characters and octets. For some things, similar to a data: >>> URL, thinking in characters might be artificial. For some >>> other things, such as URLs, thinking in octets may to some >>> extent be necessary because of backwards compatibility issues >>> (assume an URL scheme is extended and decides to use some >>> weird RFC 1522-like method for encoding characters, and this >>> would have to be grandfathered). >>> >> >>I have thought about the same thing, and I admit that I am not altogether >>enthusiastic about RFC 1522 style encoding of URNs, but it may be forced >>upon us. > >Well, I didn't mean that this is currently the case. The ftp >i18n extensions, for example, are happily going in the direction >of UTF-8 and would very well fit together with our proposal. > >But I have made the experience that trying to specify UNicode only >can meet quite some resistance. Some people, for whatever reasons, >are strongly anti-unicode. If you specify something like >"urns use Unicode and nothing else", they may start to complain. >If you say "urns should use Unicode, and clients should interpret >urns as Unicode if possible, but if really necessary, an NSS >can use something else" then it's difficult to oppose, even >if maybe in actual practice, there will not be a single NSS >that ever specifies something else than Unicode. Huh? My "knee-jerk" reaction is that by saying that client should convert from an NSS that isn't in Unicode(10646)/UTF-8 shall be converted before being sent to the URN resolver handles this nicely. I include in this statement the act of entering a NSS at an interface in some other encoding (ASCII, etc.) >NSSs or URL shemes (I still have problems distingushing them) >themselves might also do the same thing, namely saying that >in general, character semantics should be ISO 10646/UTF-8, but >that other things would be tolerated for backwards compatibility. >This is exactly the case for ftp, where a lot of 8-bit filenames >are already existing and in use, although not UTF-8. I'm not sure I'm comfortable with this. My view is that the documentation of the NID would specify this as an exception to the syntax document and the syntax document says "here's the syntax, but exceptions are allowed for namespaces that document there exceptions elsewhere? Seems awfully kludgy to me... >It is also important because not every arbitrary sequence of >8-bit octets is an UTF-8 sequence. What should browsers, resolvers, >and all the other components of our URN arichitecture do with >these? I expect that anything that tries to resolve a sequence of 8-bit octets that aren't a UTF-8 sequence should fail, unless the namespace has provided information otherwise. I see this as related to the above issue: The two basic choices are: (1) Allow things other than UTF-8 (and force the exceptions to be documented as part of namespace registration). The resolvers then have to use the namespace specific information (including exceptions). (2) Do not allow other than UTF-8 and reject the arbitrary 8-bit octet sequence as unresolvable if it is unresolvable. The first is cleaner from the point of view of the end-users, the second from the point of view of internal clenliness. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA18854 for urn-ietf-out; Thu, 24 Oct 1996 16:32:34 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA18848 for ; Thu, 24 Oct 1996 16:32:31 -0400 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29626 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 16:32:28 -0400 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01606-0@josef.ifi.unizh.ch>; Thu, 24 Oct 1996 22:32:25 +0100 Subject: Re: [URN] re URN sytax To: tallen@fsc.fujitsu.com Date: Thu, 24 Oct 1996 22:32:25 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: <199610211940.MAA12063@ishtar.fsc.fujitsu.com> from "Terry Allen" at Oct 21, 96 12:40:59 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1079 From: Martin J Duerst Message-Id: <"josef.ifi..329:24.09.96.21.32.30"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Terry Allen writes: >Martin writes: >| So I think the spec should go more in the direction of: >| >| - If an NSS contains characters, these should be encoded using UTF-8. >| - If an NSS contains something else (e.g. pure data), this can be >| encoded directly using %HH. > >Just to keep myself clear on what you're saying, ISO 10646 mixes >glyphs and characters. By "characters" above, are you excluding >glyphs-that-are-not-themselves-characters? Are those glyphs >data? Or do you expect people not to use glyphs that aren't >characters? ISO 10646 in theory codes characters, not glyphs. In practice, the distinction is sometimes difficult to make, and sometimes, glyphs have sneaked in for backwards compatibility. Indeed, I expect a rather low use of glyphs that are not characters. For example, it is rare that any system produces an "fi" ligature (in the encoded text) if you type "f" and "i", and I don't think people will care about one or the other in something like an URN. The same applies for Arabic glyph variants and ligatures, and so on. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA18613 for urn-ietf-out; Thu, 24 Oct 1996 16:12:16 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA18608 for ; Thu, 24 Oct 1996 16:12:11 -0400 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29401 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 16:12:04 -0400 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01552-0@josef.ifi.unizh.ch>; Thu, 24 Oct 1996 22:12:00 +0100 Subject: Re: [URN] Pre release of URN Syntax document.... To: jayhawk@ds.internic.net Date: Thu, 24 Oct 1996 22:11:59 +0100 (MET) Cc: paf@swip.net, urn-ietf@bunyip.com In-Reply-To: <"josef.ifi..740:21.09.96.21.00.14"@ifi.unizh.ch> from "Ryan Moats" at Oct 21, 96 03:04:20 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2228 From: Martin J Duerst Message-Id: <"josef.ifi..921:24.09.96.21.12.01"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ryan Moats wrote: >On Mon, 21 Oct 1996 20:36:58 +0200 (MET DST), Patrik Faltstrom wrote: >> >>On Mon, 21 Oct 1996, Martin J Duerst wrote: >> >>> The other big problem is equivalence. For Unicode, character equivalence >>> is in some cases not the same as codepoint equivalence. Charecter >>> equivalence is well defined, but there is currently no standard >>> for normalization. >> >>What exists are the decomposition rules for Unicode. Those are well defined. Yes, but they define equivalence, not normalization. So every instance wanting to compare two urns would have it included. With normalization, it would only be those instances that "produce" urns, i.e. where resources are named or where urns are entered into a computer. >>> This does not concern things such as case, >>> where the user can easily distinguish lower case and upper case, >>> but cases such as A-with-Grave, which can be encoded both as >>> one single codepoint and as the sequence A, Grave. >> >>The casing is also defined in the Unicode spec. Yes, but it is clearly NSS-dependent, and language-dependent in addition. And in contrast to such things as the A-grave story, no user will be surprised that a lower case and an upper case character are not the same. >>> Another problem that should be considered are bidirectionality >>> for Hebrew and Arabic. >> >>It should be defined, just like in MIME, that characters are >>stored in the order they are stored, not displayed. (At least >>I remember that we discussed this with display order in the >>MIME community in an interesting meeting faaaar back in time, >>which was ended by looking at some example where two hebrew >>users, using the same computer, was using different display >>order...). > >I agree with Patrik. Regardless of glyph direction order, NSS octets >are in order of presentation ie. (for left->right, left most character first, >for right->left right most character first, etc.) It's not as easy as that. Are Bidi control characters allowed in urns? Overrides (overriding implicit reordering and thus basically specifying presentation order) are very convenient e.g. for part numbers, and there are quite some similarities between part numbers and urns. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA18586 for urn-ietf-out; Thu, 24 Oct 1996 16:10:30 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA18579 for ; Thu, 24 Oct 1996 16:10:27 -0400 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29395 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 16:10:25 -0400 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01505-0@josef.ifi.unizh.ch>; Thu, 24 Oct 1996 22:00:38 +0100 Subject: Re: [URN] What is equivalence? To: rdaniel@acl.lanl.gov Date: Thu, 24 Oct 1996 22:00:37 +0100 (MET) Cc: masinter@parc.xerox.com, paf@swip.net, urn-ietf@bunyip.com In-Reply-To: <2.2.32.19961023154245.006ac56c@acl.lanl.gov> from "Ron Daniel" at Oct 23, 96 09:42:45 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2742 From: Martin J Duerst Message-Id: <"josef.ifi..778:24.09.96.21.00.39"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ron Daniel wrote: >Thus spoke Larry Masinter (at least at 12:46 AM 10/23/96 PDT) > >[I'm responding to Larry's paragraphs in a different order than >he sent them] > >>While there's not much problem if two strings that are not equivalent >>now might be declared equivalent in the future, there's a serious >>problem if two strings that are equivalent now are determined to be >>non-equivalent later. Unless something like reshuffling the whole of ISO 10646 happens, this will not occur. It definitely does not occur when introducing new precombined characters, which is the main thing we have to worry about. >>The issue for Unicode decomposition is that it is possible to imagine >>Unicode adding some new composition rule in the future. Thus, the >>time scope of the equivalence relationship is limited: > >I asume that the character equivalances in ISO 10646 are set, and >that any additional equivalances would be under a new standard. ISO 10646 does not define any character equivalences. Unicode does. And new equivalences are added with the addition of new characters that can be decomposed. >So, while I agree that the equivalances could change over time, the >URN syntax draft (if we decide to do UNICODE character equivalents) >should probably say that the 10646 equivalants are the ones we do. >That set of equivalances would not change over time. To restrict ourselves to a particular version of Unicode/ISO 10646 would make sense if we decide that urns have to be normalized. We might then normalize on precombined up to version 2.0 (and the corresponding ISO amendments) and on decomposed for the rest. If we decide that normalization is done during comparison, then there is no great benefit in fixing a version; as Larry has pointed out, there might just be suboptimal equivalence in old implementations. >Personally, I have no opinion on UNICODE character equivalants. >Patrik presented the arguments for both sides. I like the implementation >ease of not doing equivalents, but then we are not doing "true" 10646 >so we have to very careful about the wording of the URN syntax draft. >Anyone out there with strong opinions one way or the other? We would actually do something like "true" 10646. But the main point is that if we don't do equivalence (e.g. in the A-grave case), it's going to surprise users a lot. If you are looking for a "O", and find out you typed an "0", you will probably blame yourself. If you are looking for A-grave, and find out you had to look for A-grave instead (only that there were two different encodings of it, on which you are not supposed to have any influence because they are equivalent), you will blame somebody else, either Unicode or ISO or the URN group. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA18528 for urn-ietf-out; Thu, 24 Oct 1996 16:07:26 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA18522 for ; Thu, 24 Oct 1996 16:07:23 -0400 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29376 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 16:06:51 -0400 Received: from nic.cafax.se (paf@nic.cafax.se [193.12.122.42]) by nic.cafax.se (8.8.2/8.8.2) with SMTP id WAA01816; Thu, 24 Oct 1996 22:03:27 +0200 (MET DST) Date: Thu, 24 Oct 1996 22:03:27 +0200 (MET DST) From: Patrik Faltstrom X-Sender: paf@nic.cafax.se To: "Gregory J. Woodhouse" Cc: Martin J Duerst , tallen@fsc.fujitsu.com, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] Unicode for NSS query In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com On Thu, 24 Oct 1996, Gregory J. Woodhouse wrote: > > I have thought about the same thing, and I admit that I am not altogether > enthusiastic about RFC 1522 style encoding of URNs, but it may be forced > upon us. > This is exactly why I think we should state that only one character set is used for urn:s which is to be used together with one kind of encoding. With 1522 you can use any character set and two different encodings. paf Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA18369 for urn-ietf-out; Thu, 24 Oct 1996 15:53:07 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA18364 for ; Thu, 24 Oct 1996 15:53:03 -0400 From: jayhawk@ds.internic.net Received: from cagw2.att.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29228 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 15:52:53 -0400 Received: from qsun.ho.att.com by caig2.att.att.com (SMI-8.6/EMS-1.2 sol2) id PAA23207; Thu, 24 Oct 1996 15:55:09 -0400 Received: from qsun2.ho.att.com.qsun2 by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS) id AA28010; Thu, 24 Oct 96 15:52:36 EDT Received: from sloop ([135.16.157.189]) by qsun2.ho.att.com.qsun2 (5.x/EMS-1.2 sol2) id AA22485; Thu, 24 Oct 1996 15:51:31 -0400 Message-Id: <9610241951.AA22485@qsun2.ho.att.com.qsun2> Original-From: "Ryan Moats" To: "rdaniel@acl.lanl.gov" , "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Date: Thu, 24 Oct 96 14:57:28 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] Unicode for NSS query Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: jayhawk@ds.internic.net Errors-To: owner-urn-ietf@bunyip.com On Thu, 24 Oct 1996 10:25:11 -0700 (PDT), Terry Allen wrote: >| (Note that the NAPTR resolution scheme is probably going to find >| it impossible to get people to resolvers if that decision has to be made >| on non-ASCII characters in the URN. Since NAPTR is intended for >| Experimental rather than standards track this may be OK. I will take a >| look at what can be done to deal with UNICODE in regexps.) > >Ah, I see. That part of the NSS that deals with its hierarchy >(and hence must be dealt with to get the client to a resolver) >presents a different problem than the rest of it; do I have that >right? E.g., > > urn:world.dynasties:ottomans/15th.century/Bursa/XXXXXXXXXX > >has to get to the "Bursa" resolver, but XXXXXXXXXX could be >anything? I would have put this a different way. My view of the NAPTR proposal is that the "resolver" is hit once the NID is looked up. The 'regexp' stuff is how the resolver handles the NSS string. Thus, what becomes impossible is not "getting to the resolver" in my view, it is either "extracting the naming authority" or "resolving the NSS". Ryan Moats Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA18285 for urn-ietf-out; Thu, 24 Oct 1996 15:48:38 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA18280 for ; Thu, 24 Oct 1996 15:48:36 -0400 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29165 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 15:48:02 -0400 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01466-0@josef.ifi.unizh.ch>; Thu, 24 Oct 1996 21:47:42 +0100 Subject: Re: [URN] Unicode for NSS query To: gjw@wnetc.com (Gregory J. Woodhouse) Date: Thu, 24 Oct 1996 21:47:41 +0100 (MET) Cc: tallen@fsc.fujitsu.com, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com In-Reply-To: from "Gregory J. Woodhouse" at Oct 24, 96 12:31:49 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2030 From: Martin J Duerst Message-Id: <"josef.ifi..582:24.09.96.20.47.43"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com > >On Thu, 24 Oct 1996, Martin J Duerst wrote: > >> >> I have suggested that we might be required to thing in terms of >> both characters and octets. For some things, similar to a data: >> URL, thinking in characters might be artificial. For some >> other things, such as URLs, thinking in octets may to some >> extent be necessary because of backwards compatibility issues >> (assume an URL scheme is extended and decides to use some >> weird RFC 1522-like method for encoding characters, and this >> would have to be grandfathered). >> > >I have thought about the same thing, and I admit that I am not altogether >enthusiastic about RFC 1522 style encoding of URNs, but it may be forced >upon us. Well, I didn't mean that this is currently the case. The ftp i18n extensions, for example, are happily going in the direction of UTF-8 and would very well fit together with our proposal. But I have made the experience that trying to specify UNicode only can meet quite some resistance. Some people, for whatever reasons, are strongly anti-unicode. If you specify something like "urns use Unicode and nothing else", they may start to complain. If you say "urns should use Unicode, and clients should interpret urns as Unicode if possible, but if really necessary, an NSS can use something else" then it's difficult to oppose, even if maybe in actual practice, there will not be a single NSS that ever specifies something else than Unicode. NSSs or URL shemes (I still have problems distingushing them) themselves might also do the same thing, namely saying that in general, character semantics should be ISO 10646/UTF-8, but that other things would be tolerated for backwards compatibility. This is exactly the case for ftp, where a lot of 8-bit filenames are already existing and in use, although not UTF-8. It is also important because not every arbitrary sequence of 8-bit octets is an UTF-8 sequence. What should browsers, resolvers, and all the other components of our URN arichitecture do with these? Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA18135 for urn-ietf-out; Thu, 24 Oct 1996 15:38:28 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA18126 for ; Thu, 24 Oct 1996 15:38:22 -0400 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29063 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 15:38:17 -0400 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01446-0@josef.ifi.unizh.ch>; Thu, 24 Oct 1996 21:38:20 +0100 Subject: Re: [URN] UNICODE or not UNICODE? To: paf@swip.net Date: Thu, 24 Oct 1996 21:38:19 +0100 (MET) Cc: urn-ietf@bunyip.com, splinter@bunyip.com In-Reply-To: from "Patrik Faltstrom" at Oct 24, 96 11:08:19 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4139 From: Martin J Duerst Message-Id: <"josef.ifi..471:24.09.96.20.38.21"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com > >Terry wrote >> - why care? the NSS is supposed to be opaque >> - does this imply that a) NSSs should be formed originally >> in Unicode, or that b) NSSs in other coded character sets >> must be translated/transliterated into Unicode in forming >> URNs, or c) something else? > >The problem with not defining a character set is that it will >be impossible to do any comparison between two URNs. We need to have >some ability to do comparisons, and the only reasonable way of doing that >is to use _one_ character set. > >To answer the second question, you have to have a urn in a different >character set in some cases, for example in a client which does not >use UNICODE. You then have to do translation. > >What we did in Digger, the Whois++ server Bunyip has, was using the >rules for comparison (decomposition + sorting) and translation rules >that the UINCODE consortium have defined. > >The UNICODE tables include for each character one kind of equivalence >which is the rule for decomposition of that code point in UNICODE >into more than one other code point. One example, the letter '=C4'. > >In UNICODE, this character is defined as: > >00C4;LATIN CAPITAL LETTER A WITH DIAERESIS;Lu;0;L;0041 0308;;;;N; > LATIN CAPITAL LETTER A DIAERESIS;;;00E4; > >One can here see that the codepoint, U+00C4, is equivalent to U+0041 >followed by U+0308. One can also see that the lower case version of this >character is U+00E4 (among other things). > >When comparing two strings, and one of them include "U+00C4" >and the other one the sequence "U+0041"+"U+0308" these strings >should be considered equal in the sense of the UNICODE spec. > >Note that I am not talking about ISO-10646 here, as I am not at all >familiar with what parts of this is included in the 10646 spec. This >is UNICODE 2.0 we are talking about! ISO 10646 does not define any such equivalences, but also in other cases defines much less charcter properties and semantics. >This means that before comparing the strings that include "U+00C4" >and "U+0041"+"U+0308", all code points have to be decomposed into its >maximal decomposition possible. I.e. "U+00C4" have to be changed to >"U+0041"+"U+0308", and these have to be sorted (i.e. one can know >from the code tables that "U+0041" is to be before "U+0308" in >a composed character). Sorting really only occurs on diacritics; the base character (A or U+0041 here) is not involved. Sorting is necessary becaus you can have A with X on top and Y below, which you can encode as AXY or AYX. Sorting is restricted because you can have X and Z with both go on top, and in this case AXZ means Z atop X (atop A), and AZX means X atop Z, and these two are not equivalent. >THEN we do the comparison codepoint by codepoint. > >If we wanted to do case insensitive matching, we use the information >from the UNICODE consortium about what is a lower case character. Well, with case we get into problems, as the correspondences supplied by Unicode work for almost all languages, but have some exceptions (e.g. Turkish). But case equivalence is not needed in the general urn syntax. >>or use Unicode code points that >>indicate glyph variants of a letter, such as 06AA, "Arabic >>Letter Swash Kaf," which is lexically the same as 0643, >>"Arabic Letter Kaf`" or specify some ligatures). > >I don't know Arabic, but I am just following the rules that >UNICODE consortioum have set up, and according to these >rules, U+06AA and U+0643 is not equivalent characters >when comparing: > >06AA;ARABIC LETTER SWASH KAF;Lo;0;R;;;;;N;ARABIC LETTER SWASH CAF;;;; >0643;ARABIC LETTER KAF;Lo;0;R;;;;;N;ARABIC LETTER CAF;;;; > >I am not arguing if this descision by the UNICODE consortium >was correct or not, but _someone_ that they trusted must have >told them these are different characters. I don't know the use of swash kaf either, but I would assume that it is used as a special character in some languages, in some specific cases or to denote a different sound. This would mean that people who really want to use swash kaf in their unrs would not have a problem distinguishing it from the normal kaf. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA18019 for urn-ietf-out; Thu, 24 Oct 1996 15:33:30 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA18014 for ; Thu, 24 Oct 1996 15:33:27 -0400 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29015 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 15:33:26 -0400 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id MAA17796; Thu, 24 Oct 1996 12:31:49 -0700 Date: Thu, 24 Oct 1996 12:31:49 -0700 (PDT) From: "Gregory J. Woodhouse" To: Martin J Duerst Cc: tallen@fsc.fujitsu.com, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] Unicode for NSS query In-Reply-To: <"josef.ifi..192:24.09.96.20.15.32"@ifi.unizh.ch> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com On Thu, 24 Oct 1996, Martin J Duerst wrote: > > I have suggested that we might be required to thing in terms of > both characters and octets. For some things, similar to a data: > URL, thinking in characters might be artificial. For some > other things, such as URLs, thinking in octets may to some > extent be necessary because of backwards compatibility issues > (assume an URL scheme is extended and decides to use some > weird RFC 1522-like method for encoding characters, and this > would have to be grandfathered). > I have thought about the same thing, and I admit that I am not altogether enthusiastic about RFC 1522 style encoding of URNs, but it may be forced upon us. --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/ resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA17901 for urn-ietf-out; Thu, 24 Oct 1996 15:27:15 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA17896 for ; Thu, 24 Oct 1996 15:27:13 -0400 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28975 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 15:27:07 -0400 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id MAA17278 for ; Thu, 24 Oct 1996 12:26:53 -0700 Date: Thu, 24 Oct 1996 12:26:53 -0700 (PDT) From: "Gregory J. Woodhouse" To: urn-ietf@bunyip.com Subject: Re: [URN] Unicode for NSS query In-Reply-To: <199610241845.LAA06947@ishtar.fsc.fujitsu.com> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com It seems to me that since URNs are not just protocol elements, but also function as user interface elements that it is not sufficient to regard the NSS part of the URN as a string of octets. This would be fine, I suppose if URNs only appeared in (say) HTTP requests, but since users will enter URNs int controls in user agents, and since URNs will be published in readable form (e.g., in bibliographies) we are forced to regard them as being encoded in a character set (such as Unicode). I know this is basically just a matteer of stating a tacit assumption, but I believe someone did ask why we couldn't treat it as an octet stream. --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/ resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA17697 for urn-ietf-out; Thu, 24 Oct 1996 15:15:51 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA17691 for ; Thu, 24 Oct 1996 15:15:47 -0400 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28846 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 15:15:44 -0400 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01391-0@josef.ifi.unizh.ch>; Thu, 24 Oct 1996 21:15:31 +0100 Subject: Re: [URN] Unicode for NSS query To: tallen@fsc.fujitsu.com Date: Thu, 24 Oct 1996 21:15:30 +0100 (MET) Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com In-Reply-To: <199610241725.KAA04756@ishtar.fsc.fujitsu.com> from "Terry Allen" at Oct 24, 96 10:25:11 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6937 From: Martin J Duerst Message-Id: <"josef.ifi..192:24.09.96.20.15.32"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Terry Allen wrote: >Thanks to Patrik and Ron. I think I need to go out and buy >those Unicode books today. Some clarifications: Version 2.0 is out now, and it's only one book. Addison-Wesley, urn:isbn:0-201-48345-9 :-). >| > - why care? the NSS is supposed to be opaque >| Which means? I think it means we can't go around inferring >| structure in arbitrary namespaces. Opaque does not mean >| that we have to take whatever comes. There can be particular >| requirements on the characters allowed. >| I think this WG should make >| an explicit decision on trying to go to UNICODE rather than >| just defaulting to ASCII. The reasons for doing so: >| 1) The IAB workshop tells us to try to do so. >| 2) Not all the namespaces in the world use the Latin alphabet >| without accents. >| 3) Isn't it time we start getting away from the US-ASCII assumption? > >I don't want to assume ASCII, but I was wondering, why think in terms >of characters and not octets? I have suggested that we might be required to thing in terms of both characters and octets. For some things, similar to a data: URL, thinking in characters might be artificial. For some other things, such as URLs, thinking in octets may to some extent be necessary because of backwards compatibility issues (assume an URL scheme is extended and decides to use some weird RFC 1522-like method for encoding characters, and this would have to be grandfathered). >If the NSS is thought of as a series >of octets, and the meaning of those octets is defined by the scheme, >the resolver should have no problem. You give one reason below >(getting to the resolver). What else am I missing? (transcribability?) Transcribability is definitely an issue. Assume there is some very well established tradition >| > - does this imply that a) NSSs should be formed originally >| > in Unicode, or that b) NSSs in other coded character sets >| > must be translated/transliterated into Unicode in forming >| > URNs, or c) something else? >| >| What I assume happens is that namespaces are defined in terms of >| glyphs, not coded character sets. Terry here and below makes many comments about what we want to encode not being glyphs but characters. I agree. I think Ron Daniel used the term glyph with the meaning "character without assigned encoding". To clear up terminology, a character by itself does not enclude a code. It is something like a small logical text component. A glyph (in standard terminology) is the appearance of a character. With Latin letters, this distinction only turns up with e.g. "a" or "g", where the "g" can be closed at the bottom or not, and these would be two glyphs for the same character. So replacing all the occurrences of "glyph" in Ron's comment by "character", things become much more clear. It's then basically a discussion of whether: - Namespaces appear as characters, without specific encoding, or - Namespaces appear as characters with their encoding already defined and, for the later, whether: - They would have to be reencoded to Unicode - They should be left as is My personal oppinion is that namespaces will appear in both variants, both already encoded and not yet encoded, and also as encoded entities without any relation to characters. As for reencoding, I would propose to suggest in the document that NSS define a reencoding if possible and appropriate, and do so if possible by referring to existing documents (Unicode has mapping tables between e.g. ISO 8859-6 (Latin/Arabic) and Unicode). I would also suggest that the document propose that NSS or URL schemes that have not yet defined character semantics beyond ASCII, but that would like to do so, strongly consider to do so in accordance with URN name syntax (i.e. using UTF-8). >| >As an example, suppose that I have an existing name space, >| >well ordered in every respect, in ISO 8859-6 (Latin/Arabic). >| >I want this name space to be used for URNs, and (supposing >| >that the coded character set is not an obstacle at this >| >point) get it registered. As the upper half of 8859-6 is >| >not a subset of Unicode, per the present syntax draft, >All the *characters* of the upper half of 8859-6 can be represented >by various combinations of Unicode glyphs, as I understand matters. Yes. But all the ligatures and contextual forms are in the compatibility section. The mapping is really straightforward and well-defined. >| Right. We have been assuming that the user enters a URN into >| a browser using their local language/script/... and the browser >| has the job of making it into UNICODE/UTF-8/%encoded. > >Terminological question: is the URN as entered a URN? or does >it become a URN only when translated? Interesting question. But really only terminology. I don't assume anybody will publish an URN with %HH notation in e.g. a Japanese newspaper. So even if we terminologically specify that only the entered and translated URN is an URN, users will thing differently. >| Are there guidelines already in place on how, when a user wants >| an "A" plus "grave" (or whatever), that is to be encoded? Is it >| reasonable for us to cite such guidelines as the way namespaces >| should be encoded? (Also, is it SHOULD be encoded or MUST be >| encoded). > >That I can't answer (yet). I have posted a question to this respect to the unicore (unicode specialists) list. The answer is that: - Unicode defines that A-Grave and A followed by combining Grave are equivalent. - Unicode does not give any preference to any one of these forms. I see the main reason for this state in the fact that up to now, Unicode was mainly designed with text editing in mind, and it was assumed that each text editor could convert incomming stuff to whatever it preferred. For things such as URNs, it would definitely be nice to have a set of clear preferences. SHOULD be encoded would not help much, because it would not take any burden from servers/resolvers (unless we want to put the burden on the user, which in the case of A-grave would be a really bad idea). >| > Say >| >I can have outcomes A, B, and C, all of them legitimate >| >representations of my 8859-6 name in Unicode. Are >| >urn:mynamespace:A, urn:mynamespace:B, and urn:mynamespace:C >| >equivalent? >| >| I think that we can't mandate that they be lexically equivalent. >| That requires FAR too much knowledge on the part of all URN software. >| It may be that a resolver can be made smart enough that, when >| dealing with a particular language and alphabet, it can recognize >| "A with grave" as equivalent to "A" and "grave". I think that is outside >| the bounds of what we standardize. > >Fine by me. I think that for Arabic and similar cases, with lots of compatibility codes, it would be nice to say that compatibility codes SHOULD not be used in URNs. This is not a problem of 8859-6 -> Unicode conversion, but just of Arabic in general. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA17172 for urn-ietf-out; Thu, 24 Oct 1996 14:46:15 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA17163 for ; Thu, 24 Oct 1996 14:46:12 -0400 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28390 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 14:46:09 -0400 Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id LAA06682; Thu, 24 Oct 1996 11:44:33 -0700 (PDT) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id LAA06947; Thu, 24 Oct 1996 11:45:01 -0700 (PDT) Date: Thu, 24 Oct 1996 11:45:01 -0700 (PDT) From: Terry Allen Message-Id: <199610241845.LAA06947@ishtar.fsc.fujitsu.com> To: rdaniel@acl.lanl.gov, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] Unicode for NSS query Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Having bought the book (The Unicode Standard, Version 2.0, with CD, $55 at Computer Literacy), and without working out the whole problem, I can see that 8859-6 > Unicode is a well defined path. The Arabic block is divided into a range "Based on ISO 8859-6," a range "Points [diacritical marks] from ISO 8859-6", a range "Arabic-Indic digits" corresponding to the digits in 8859-6 (which are doubled up on their Latin equivalents in 8859-6), and some other ranges. So coming from 8859-6 there is only one choice for each character conversion, and given the resolver's context when receiving a Unicode URN, backconversion to 8859-6 should also be unambiguous. I won't be able to read the CD for a couple weeks, but the print answers the question I was asking. I'll just admire the cover (the front cover uses the Rosetta Stone as background, including hieroglyphs that can't be encoded in Unicode ...). Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA15955 for urn-ietf-out; Thu, 24 Oct 1996 13:26:21 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA15948 for ; Thu, 24 Oct 1996 13:26:18 -0400 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27509 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 13:26:15 -0400 Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id KAA04453; Thu, 24 Oct 1996 10:24:43 -0700 (PDT) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id KAA04756; Thu, 24 Oct 1996 10:25:11 -0700 (PDT) Date: Thu, 24 Oct 1996 10:25:11 -0700 (PDT) From: Terry Allen Message-Id: <199610241725.KAA04756@ishtar.fsc.fujitsu.com> To: rdaniel@acl.lanl.gov, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] Unicode for NSS query Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Thanks to Patrik and Ron. I think I need to go out and buy those Unicode books today. Some clarifications: | > - why care? the NSS is supposed to be opaque | Which means? I think it means we can't go around inferring | structure in arbitrary namespaces. Opaque does not mean | that we have to take whatever comes. There can be particular | requirements on the characters allowed. | I think this WG should make | an explicit decision on trying to go to UNICODE rather than | just defaulting to ASCII. The reasons for doing so: | 1) The IAB workshop tells us to try to do so. | 2) Not all the namespaces in the world use the Latin alphabet | without accents. | 3) Isn't it time we start getting away from the US-ASCII assumption? I don't want to assume ASCII, but I was wondering, why think in terms of characters and not octets? If the NSS is thought of as a series of octets, and the meaning of those octets is defined by the scheme, the resolver should have no problem. You give one reason below (getting to the resolver). What else am I missing? (transcribability?) | It may be that the group decides not to do UNICODE because of technical | objections. That would be fine with me, I just want the decision to be | explicit. I'm not arguing either way on Unicode (for this purpose). | > - does this imply that a) NSSs should be formed originally | > in Unicode, or that b) NSSs in other coded character sets | > must be translated/transliterated into Unicode in forming | > URNs, or c) something else? | | What I assume happens is that namespaces are defined in terms of | glyphs, not coded character sets. Browsers have the job of taking | some coded representation of the glyph and translating it (if necessary) | to a 10646 coded version of the glyph. Then they do UTF-8 and %encoding | before sending it on the wire to a resolver. But many name spaces *are* defined in terms of [un]coded character sets. I didn't give a full example framing my question about Arabic Kaf, but 8859-6 doesn't define glyphs, it defines characters. | (Note that the NAPTR resolution scheme is probably going to find | it impossible to get people to resolvers if that decision has to be made | on non-ASCII characters in the URN. Since NAPTR is intended for | Experimental rather than standards track this may be OK. I will take a | look at what can be done to deal with UNICODE in regexps.) Ah, I see. That part of the NSS that deals with its hierarchy (and hence must be dealt with to get the client to a resolver) presents a different problem than the rest of it; do I have that right? E.g., urn:world.dynasties:ottomans/15th.century/Bursa/XXXXXXXXXX has to get to the "Bursa" resolver, but XXXXXXXXXX could be anything? | >As an example, suppose that I have an existing name space, | >well ordered in every respect, in ISO 8859-6 (Latin/Arabic). | | Is this assumption of characterset appropriate? Is it not more | likely that the namespace will say "names are formed from the | set of glyphs [x-y]" (where x and y are denoting arbitrary glyphs, not | the Latin letters x and y) leaving the problem of how to code those | things as bits up to someone else? For many existing name spaces, the current definition will be in terms of letters or ideographs, not tied to any set of glyphs. (I'll bet that even ISBNs may not be defined in terms of ASCII.) Should some binding to a glyphset be made in the registration process? | >I want this name space to be used for URNs, and (supposing | >that the coded character set is not an obstacle at this | >point) get it registered. As the upper half of 8859-6 is | >not a subset of Unicode, per the present syntax draft, | | Do you mean that: | a) The glyphs in the upper half of 8859-6 are not in UNICODE | b) The glyphs are there but the bit patterns of their coded representation | differ | c) (B) + non-unique mappings from 8859-6 to same glyph in UNICODE All the *characters* of the upper half of 8859-6 can be represented by various combinations of Unicode glyphs, as I understand matters. (Digression: There are additional noncharacter glyphs in the "Arabic" section of Unicode, some of them more like SGML entities than glyphs, e.g., a rosette glyph for the start of a Qur'anic verse, for which no standard glyph has ever been used in Arabic printing. These are pretty questionable, but not at issue in the 8859-6>Unicode direction.) | >I can't use it directly in an URN (although doing so would | >pose no problem I can think of, supposing that it is a rule | >of the name space that its names are in 8859-6). | > | >When I translate that 8859-6 name into Unicode I have more | >than one possible outcome (depending on whether I keep it | >simple, using 0621--064A or use Unicode code points that | >include diacritical marks or use Unicode code points that | >indicate glyph variants of a letter, such as 06AA, "Arabic | >Letter Swash Kaf," which is lexically the same as 0643, | >"Arabic Letter Kaf`" or specify some ligatures). [Patrik says it isn't equivalent per Unicode; must investigate.] | Right. We have been assuming that the user enters a URN into | a browser using their local language/script/... and the browser | has the job of making it into UNICODE/UTF-8/%encoded. Terminological question: is the URN as entered a URN? or does it become a URN only when translated? | Are there guidelines already in place on how, when a user wants | an "A" plus "grave" (or whatever), that is to be encoded? Is it | reasonable for us to cite such guidelines as the way namespaces | should be encoded? (Also, is it SHOULD be encoded or MUST be | encoded). That I can't answer (yet). | > Say | >I can have outcomes A, B, and C, all of them legitimate | >representations of my 8859-6 name in Unicode. Are | >urn:mynamespace:A, urn:mynamespace:B, and urn:mynamespace:C | >equivalent? | | I think that we can't mandate that they be lexically equivalent. | That requires FAR too much knowledge on the part of all URN software. | It may be that a resolver can be made smart enough that, when | dealing with a particular language and alphabet, it can recognize | "A with grave" as equivalent to "A" and "grave". I think that is outside | the bounds of what we standardize. Fine by me. | The place to attack this problem of A, B, and C all being legitimate | UNICODE representations of some sequence of glyphs is when the | glyphs are first translated to UNICODE. If there are recommendations | on preferred encodings, we should cite those. If not, then we should | decide on which is more important - UNICODE's capabilities or | unambiguous encoding. Right. Onward to the bookstore. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA14257 for urn-ietf-out; Thu, 24 Oct 1996 11:27:31 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA14247 for ; Thu, 24 Oct 1996 11:27:27 -0400 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26272 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 11:27:02 -0400 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01165-0@josef.ifi.unizh.ch>; Thu, 24 Oct 1996 17:21:54 +0100 Subject: Re: [URN] What is equivalence? To: jtauber@library.uwa.edu.au Date: Thu, 24 Oct 1996 17:21:53 +0100 (MET) Cc: tallen@fsc.fujitsu.com, masinter@parc.xerox.com, paf@swip.net, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com In-Reply-To: <199610240416.MAA12337@docker.library.uwa.edu.au> from "James K. Tauber" at Oct 24, 96 12:17:32 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 733 From: Martin J Duerst Message-Id: <"josef.ifi..655:24.09.96.16.21.56"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com James K. Tauber wrote: >The full name of "10646-1" is: > >ISO/IEC 10646-1:1993 Information technology -- Universal Multiple-Octet >Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual >Plane > >The "-1" refers to the part number and the 1993 to the version. > >Note that there have been two amendments (for UTF-16 and UTF-8) and one >technical corrigendum to 10646-1:1993. What is more important, several amendments are in preparation and have advanced through the voting process. Of particular interest is amendment 5, which completely redefines the Hangul (Korean) composed syllables. It is the first, last, and only (so everybody assures) case that things actually have been moved around. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA13819 for urn-ietf-out; Thu, 24 Oct 1996 11:18:31 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA13812 for ; Thu, 24 Oct 1996 11:18:20 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26156 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 11:18:18 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id JAA05603; Thu, 24 Oct 1996 09:18:12 -0600 (MDT) Message-Id: <2.2.32.19961024152549.006b6fac@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Oct 1996 09:25:49 -0600 To: Terry Allen , urn-ietf@bunyip.com From: Ron Daniel Subject: Re: [URN] Unicode for NSS query Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Terry Allen (at least at 03:52 PM 10/23/96 -0700) [on the subject of UNICODE, aka 10646, for URNs] > - why care? the NSS is supposed to be opaque Which means? I think it means we can't go around inferring structure in arbitrary namespaces. Opaque does not mean that we have to take whatever comes. There can be particular requirements on the characters allowed. I think this WG should make an explicit decision on trying to go to UNICODE rather than just defaulting to ASCII. The reasons for doing so: 1) The IAB workshop tells us to try to do so. 2) Not all the namespaces in the world use the Latin alphabet without accents. 3) Isn't it time we start getting away from the US-ASCII assumption? It may be that the group decides not to do UNICODE because of technical objections. That would be fine with me, I just want the decision to be explicit. > - does this imply that a) NSSs should be formed originally > in Unicode, or that b) NSSs in other coded character sets > must be translated/transliterated into Unicode in forming > URNs, or c) something else? What I assume happens is that namespaces are defined in terms of glyphs, not coded character sets. Browsers have the job of taking some coded representation of the glyph and translating it (if necessary) to a 10646 coded version of the glyph. Then they do UTF-8 and %encoding before sending it on the wire to a resolver. (Note that the NAPTR resolution scheme is probably going to find it impossible to get people to resolvers if that decision has to be made on non-ASCII characters in the URN. Since NAPTR is intended for Experimental rather than standards track this may be OK. I will take a look at what can be done to deal with UNICODE in regexps.) >As an example, suppose that I have an existing name space, >well ordered in every respect, in ISO 8859-6 (Latin/Arabic). Is this assumption of characterset appropriate? Is it not more likely that the namespace will say "names are formed from the set of glyphs [x-y]" (where x and y are denoting arbitrary glyphs, not the Latin letters x and y) leaving the problem of how to code those things as bits up to someone else? >I want this name space to be used for URNs, and (supposing >that the coded character set is not an obstacle at this >point) get it registered. As the upper half of 8859-6 is >not a subset of Unicode, per the present syntax draft, Do you mean that: a) The glyphs in the upper half of 8859-6 are not in UNICODE b) The glyphs are there but the bit patterns of their coded representation differ c) (B) + non-unique mappings from 8859-6 to same glyph in UNICODE >I can't use it directly in an URN (although doing so would >pose no problem I can think of, supposing that it is a rule >of the name space that its names are in 8859-6). > >When I translate that 8859-6 name into Unicode I have more >than one possible outcome (depending on whether I keep it >simple, using 0621--064A or use Unicode code points that >include diacritical marks or use Unicode code points that >indicate glyph variants of a letter, such as 06AA, "Arabic >Letter Swash Kaf," which is lexically the same as 0643, >"Arabic Letter Kaf`" or specify some ligatures). Right. We have been assuming that the user enters a URN into a browser using their local language/script/... and the browser has the job of making it into UNICODE/UTF-8/%encoded. Are there guidelines already in place on how, when a user wants an "A" plus "grave" (or whatever), that is to be encoded? Is it reasonable for us to cite such guidelines as the way namespaces should be encoded? (Also, is it SHOULD be encoded or MUST be encoded). > Say >I can have outcomes A, B, and C, all of them legitimate >representations of my 8859-6 name in Unicode. Are >urn:mynamespace:A, urn:mynamespace:B, and urn:mynamespace:C >equivalent? I think that we can't mandate that they be lexically equivalent. That requires FAR too much knowledge on the part of all URN software. It may be that a resolver can be made smart enough that, when dealing with a particular language and alphabet, it can recognize "A with grave" as equivalent to "A" and "grave". I think that is outside the bounds of what we standardize. The place to attack this problem of A, B, and C all being legitimate UNICODE representations of some sequence of glyphs is when the glyphs are first translated to UNICODE. If there are recommendations on preferred encodings, we should cite those. If not, then we should decide on which is more important - UNICODE's capabilities or unambiguous encoding. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA10929 for urn-ietf-out; Thu, 24 Oct 1996 09:01:39 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA10924 for ; Thu, 24 Oct 1996 09:01:37 -0400 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24887 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 09:01:34 -0400 Received: from [192.71.220.137] (zap.swip.net [192.71.220.137]) by nic.cafax.se (8.8.2/8.8.2) with ESMTP id PAA01189; Thu, 24 Oct 1996 15:01:24 +0200 (MET DST) X-Sender: m-3329@mailbox.swip.net Message-Id: In-Reply-To: <9610241221.AA03038@qsun2.ho.att.com.qsun2> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 24 Oct 1996 14:44:44 +0200 To: "Ryan Moats" , "urn-ietf@bunyip.com" From: Patrik Faltstrom Subject: Re: [URN] UNICODE or not UNICODE? Cc: "splinter@bunyip.com" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com At 07.27 +0200 96-10-24, jayhawk@ds.internic.net wrote: >>To answer the second question, you have to have a urn in a different >>character set in some cases, for example in a client which does not >>use UNICODE. You then have to do translation. > >You are assuming translation at the resolver here? No. The URN is passed in UTF-8 from the client to the resolver. The translation I am talking about is done within the client. I.e. the client have to change it's internal representation to UNICODE before sending the URN over the wire to the resolution server. On the other hand, depending on the resolution protocol itself, different character sets might be used. In Whois++ for example, the client can specify what character set it is using. In Z39.50, I don't have a clue how to specify the character set. What we say with UTF-8 in the URN spec is that the generic format for a URN is in UTF-8, and because of that all glyphs available in UNICODE 2.0 is available for use in a URN. I.e. you just reminded me that I am mixing resolution protocol and URN specification...yak... A resolution protocol for URNs must be able to handle the UTF-8 encoding of UNICODE, i.e. be 8-bit clean, and/or handle %encoding of the UTF-8 bytes that have to be protected according to the URI spec. If using HTML as resolution protocol for example, the string that is passed is in UTF-8, not ISO-8859-1. That is what I would like. (I think ;-) Help...I am almost lost in a cloud of logic...!) Patrik Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA10639 for urn-ietf-out; Thu, 24 Oct 1996 08:23:14 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA10634 for ; Thu, 24 Oct 1996 08:23:12 -0400 From: jayhawk@ds.internic.net Received: from cagw1.att.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24737 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 08:23:10 -0400 Received: from qsun.ho.att.com by caig1.att.att.com (SMI-8.6/EMS-1.2 sol2) id IAA15536; Thu, 24 Oct 1996 08:19:28 -0400 Received: from qsun2.ho.att.com.qsun2 by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS) id AA02850; Thu, 24 Oct 96 08:22:32 EDT Received: from rickslap.ho.att.com by qsun2.ho.att.com.qsun2 (5.x/EMS-1.2 sol2) id AA03038; Thu, 24 Oct 1996 08:21:26 -0400 Message-Id: <9610241221.AA03038@qsun2.ho.att.com.qsun2> Original-From: "Ryan Moats" To: "Patrik Faltstrom" , "urn-ietf@bunyip.com" Cc: "splinter@bunyip.com" Date: Thu, 24 Oct 96 07:27:29 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] UNICODE or not UNICODE? Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: jayhawk@ds.internic.net Errors-To: owner-urn-ietf@bunyip.com On Thu, 24 Oct 1996 11:08:19 +0200, Patrik Faltstrom wrote: >Terry wrote >> - why care? the NSS is supposed to be opaque >> - does this imply that a) NSSs should be formed originally >> in Unicode, or that b) NSSs in other coded character sets >> must be translated/transliterated into Unicode in forming >> URNs, or c) something else? > >The problem with not defining a character set is that it will >be impossible to do any comparison between two URNs. We need to have >some ability to do comparisons, and the only reasonable way of doing that >is to use _one_ character set. > >To answer the second question, you have to have a urn in a different >character set in some cases, for example in a client which does not >use UNICODE. You then have to do translation. Patrik- You are assuming translation at the resolver here? Ryan P.S. The rest of the discussion I am still digesting. I plan on revamping the equivalence section of the syntax doc on the plane tomorrow (10/25) and seeing if I can't submit it to the "editors" next week. If we want to change it before San Jose, we can, otherwise we have something to go with... Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA08944 for urn-ietf-out; Thu, 24 Oct 1996 05:10:14 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA08939 for ; Thu, 24 Oct 1996 05:10:12 -0400 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24239 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 05:09:38 -0400 Received: from [192.71.220.137] (zap.swip.net [192.71.220.137]) by nic.cafax.se (8.8.2/8.8.2) with ESMTP id LAA00967; Thu, 24 Oct 1996 11:09:34 +0200 (MET DST) X-Sender: m-3329@mailbox.swip.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 24 Oct 1996 11:08:19 +0200 To: urn-ietf@bunyip.com From: Patrik Faltstrom Subject: [URN] UNICODE or not UNICODE? Cc: splinter@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com Terry wrote > - why care? the NSS is supposed to be opaque > - does this imply that a) NSSs should be formed originally > in Unicode, or that b) NSSs in other coded character sets > must be translated/transliterated into Unicode in forming > URNs, or c) something else? The problem with not defining a character set is that it will be impossible to do any comparison between two URNs. We need to have some ability to do comparisons, and the only reasonable way of doing that is to use _one_ character set. To answer the second question, you have to have a urn in a different character set in some cases, for example in a client which does not use UNICODE. You then have to do translation. What we did in Digger, the Whois++ server Bunyip has, was using the rules for comparison (decomposition + sorting) and translation rules that the UINCODE consortium have defined. The UNICODE tables include for each character one kind of equivalence which is the rule for decomposition of that code point in UNICODE into more than one other code point. One example, the letter '=C4'. In UNICODE, this character is defined as: 00C4;LATIN CAPITAL LETTER A WITH DIAERESIS;Lu;0;L;0041 0308;;;;N; LATIN CAPITAL LETTER A DIAERESIS;;;00E4; One can here see that the codepoint, U+00C4, is equivalent to U+0041 followed by U+0308. One can also see that the lower case version of this character is U+00E4 (among other things). When comparing two strings, and one of them include "U+00C4" and the other one the sequence "U+0041"+"U+0308" these strings should be considered equal in the sense of the UNICODE spec. Note that I am not talking about ISO-10646 here, as I am not at all familiar with what parts of this is included in the 10646 spec. This is UNICODE 2.0 we are talking about! When comparing strings, one have to do decomposition, and the definition of decomposition is: >Decomposition. > (1) the process of separating or analyzing a text element into > component units. These component units may not > have any functional status, but may be simply formal units, i.e.= , > abstract shapes; (2) the process of replacing a > code element with multiple code elements, which, together, > represent the original code element in some > manner, e.g., the shapes associated with the resulting > code elements may combine to form the shape associated > with the original code element. This means that before comparing the strings that include "U+00C4" and "U+0041"+"U+0308", all code points have to be decomposed into its maximal decomposition possible. I.e. "U+00C4" have to be changed to "U+0041"+"U+0308", and these have to be sorted (i.e. one can know from the code tables that "U+0041" is to be before "U+0308" in a composed character). THEN we do the comparison codepoint by codepoint. If we wanted to do case insensitive matching, we use the information from the UNICODE consortium about what is a lower case character. Terry continues: >When I translate that 8859-6 name into Unicode I have more >than one possible outcome (depending on whether I keep it >simple, using 0621--064A or use Unicode code points that >include diacritical marks If one have a look at the UNICODE tables, one can see that for example U+0621 is a final form of a whole series of other glyphs, for example =46E80;ARABIC LETTER HAMZA ISOLATED FORM;Lo;0;R; 0621;;;;N; GLYPH FOR ISOLATE ARABIC HAMZAH;;;; which is the special glyph used in isolated form. You see that U+FE08 should be equivalent to U+0621, so when using the decomposition rules before comparing strings, U+FE80 and U+0621 are considered equivalent. This is exactly why decomposition is needed. >or use Unicode code points that >indicate glyph variants of a letter, such as 06AA, "Arabic >Letter Swash Kaf," which is lexically the same as 0643, >"Arabic Letter Kaf`" or specify some ligatures). I don't know Arabic, but I am just following the rules that UNICODE consortioum have set up, and according to these rules, U+06AA and U+0643 is not equivalent characters when comparing: 06AA;ARABIC LETTER SWASH KAF;Lo;0;R;;;;;N;ARABIC LETTER SWASH CAF;;;; 0643;ARABIC LETTER KAF;Lo;0;R;;;;;N;ARABIC LETTER CAF;;;; I am not arguing if this descision by the UNICODE consortium was correct or not, but _someone_ that they trusted must have told them these are different characters. >Say >I can have outcomes A, B, and C, all of them legitimate >representations of my 8859-6 name in Unicode. Are >urn:mynamespace:A, urn:mynamespace:B, and urn:mynamespace:C >equivalent? Once the URN is passed to the resolver, is >it contemplated that the resolver will translate the URN's >NSS back into 8859-6? When mapping to/from ISO-8859-6 and UNICODE, the consortium have a table which one should use. In that table I can read out that U+0643 in ISO-8859-6 is 0xE3, but that U+06AA is missing from ISO-8859-6. A client have because of this know that UNICODE is what the URN is specified in, and do appropriate mappings -- i.e. if a URN have U+06AA as one of the characters, that URN can not be entered directly on a client working in ISO-8859-6 (and neither on a client working in ISO-8859-1 or US-ASCII). In this case %encoding can be used. Patrik -------------------------------------------------------------------- Senior Researcher, Tele2/SwipNet Stockholm, Sweden paf@swip.net Phone: +46-8-56264000 urn:inet:urn.paf.se In theory, there's no difference between theory and practice, but in practice, there is. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA06350 for urn-ietf-out; Thu, 24 Oct 1996 00:24:17 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA06345 for ; Thu, 24 Oct 1996 00:24:09 -0400 Received: from docker.library.uwa.edu.au by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22851 (mail destined for urn-ietf@services.bunyip.com); Thu, 24 Oct 96 00:24:01 -0400 Received: from dehquhp.library.uwa.edu.au (dehquhp.library.uwa.edu.au [130.95.106.230]) by docker.library.uwa.edu.au (8.8.0/8.8.0) with ESMTP id MAA12337; Thu, 24 Oct 1996 12:16:50 +0800 (WST) Message-Id: <199610240416.MAA12337@docker.library.uwa.edu.au> From: "James K. Tauber" To: "Terry Allen" , , , Cc: Subject: Re: [URN] What is equivalence? Date: Thu, 24 Oct 1996 12:17:32 +0800 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "James K. Tauber" Errors-To: owner-urn-ietf@bunyip.com > ISO 10646 comes in versions. There was 10646-1 and now (as I > understand it) there is 10646-2. If the syntax doc is to > talk about 10646 it should refer to a specific version; then > if the rules change in say, 10646-3, one can adopt the > changes or not, but there will be no ambiguity. > > "10646-1" is what I see in Unicode Technical Report #4; > I'm not sure that's the formal identifying string, especially > as SGML uses a different format for identifying versions: > 8879:1986, giving the date of the revision rather than a > number. The number following the hyphen is not a version number but a part number where it is decided to release the standard in separate parts (cf ISO 8859-n where different n doesn't mean different editions but separately released parts of the same standard) The full name of "10646-1" is: ISO/IEC 10646-1:1993 Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane The "-1" refers to the part number and the 1993 to the version. Note that there have been two amendments (for UTF-16 and UTF-8) and one technical corrigendum to 10646-1:1993. James -- James K. Tauber / jtauber@library.uwa.edu.au University CWIS Coordination Officer The University of Western Australia Room 2.42, Scholars' Centre, Reid Library Phone: +61 9 380 7136 FAX: +61 9 380 1128 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA03072 for urn-ietf-out; Wed, 23 Oct 1996 18:54:00 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA03067 for ; Wed, 23 Oct 1996 18:53:58 -0400 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21522 (mail destined for urn-ietf@services.bunyip.com); Wed, 23 Oct 96 18:53:56 -0400 Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id PAA23013; Wed, 23 Oct 1996 15:52:26 -0700 (PDT) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id PAA17274; Wed, 23 Oct 1996 15:52:54 -0700 (PDT) Date: Wed, 23 Oct 1996 15:52:54 -0700 (PDT) From: Terry Allen Message-Id: <199610232252.PAA17274@ishtar.fsc.fujitsu.com> To: urn-ietf@bunyip.com Cc: tallen@fsc.fujitsu.com Subject: [URN] Unicode for NSS query Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com The syntax draft says that Unicode shall be used for the name-specific string part of a URN. I find myself wondering about some questions, which I ask for sake of information, not as objections: - why care? the NSS is supposed to be opaque - does this imply that a) NSSs should be formed originally in Unicode, or that b) NSSs in other coded character sets must be translated/transliterated into Unicode in forming URNs, or c) something else? As an example, suppose that I have an existing name space, well ordered in every respect, in ISO 8859-6 (Latin/Arabic). I want this name space to be used for URNs, and (supposing that the coded character set is not an obstacle at this point) get it registered. As the upper half of 8859-6 is not a subset of Unicode, per the present syntax draft, I can't use it directly in an URN (although doing so would pose no problem I can think of, supposing that it is a rule of the name space that its names are in 8859-6). When I translate that 8859-6 name into Unicode I have more than one possible outcome (depending on whether I keep it simple, using 0621--064A or use Unicode code points that include diacritical marks or use Unicode code points that indicate glyph variants of a letter, such as 06AA, "Arabic Letter Swash Kaf," which is lexically the same as 0643, "Arabic Letter Kaf`" or specify some ligatures). Say I can have outcomes A, B, and C, all of them legitimate representations of my 8859-6 name in Unicode. Are urn:mynamespace:A, urn:mynamespace:B, and urn:mynamespace:C equivalent? Once the URN is passed to the resolver, is it contemplated that the resolver will translate the URN's NSS back into 8859-6? This problem arises even with digits-only Arabic NSSs, as Unicode provides two ranges of numerals, Arabic-Indic and Eastern Arabic-Indic, which (I presume, not being able to find my all-the-glyphs document) represent exactly the same characters. But maybe it's not a problem? Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA28487 for urn-ietf-out; Wed, 23 Oct 1996 14:50:50 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA28480 for ; Wed, 23 Oct 1996 14:50:39 -0400 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19026 (mail destined for urn-ietf@services.bunyip.com); Wed, 23 Oct 96 14:50:37 -0400 Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id LAA18091; Wed, 23 Oct 1996 11:49:06 -0700 (PDT) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id LAA08055; Wed, 23 Oct 1996 11:49:34 -0700 (PDT) Date: Wed, 23 Oct 1996 11:49:34 -0700 (PDT) From: Terry Allen Message-Id: <199610231849.LAA08055@ishtar.fsc.fujitsu.com> To: masinter@parc.xerox.com, paf@swip.net, rdaniel@acl.lanl.gov Cc: urn-ietf@bunyip.com Subject: Re: [URN] What is equivalence? Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com ISO 10646 comes in versions. There was 10646-1 and now (as I understand it) there is 10646-2. If the syntax doc is to talk about 10646 it should refer to a specific version; then if the rules change in say, 10646-3, one can adopt the changes or not, but there will be no ambiguity. "10646-1" is what I see in Unicode Technical Report #4; I'm not sure that's the formal identifying string, especially as SGML uses a different format for identifying versions: 8879:1986, giving the date of the revision rather than a number. Either way, the same goes for name space specifications: refer to them by version or date of publication, and you avoid problems when they are revised. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA27938 for urn-ietf-out; Wed, 23 Oct 1996 14:05:59 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA27933 for ; Wed, 23 Oct 1996 14:05:57 -0400 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18386 (mail destined for urn-ietf@services.bunyip.com); Wed, 23 Oct 96 14:05:54 -0400 Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id LAA17048; Wed, 23 Oct 1996 11:04:23 -0700 (PDT) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id LAA05817; Wed, 23 Oct 1996 11:04:51 -0700 (PDT) Date: Wed, 23 Oct 1996 11:04:51 -0700 (PDT) From: Terry Allen Message-Id: <199610231804.LAA05817@ishtar.fsc.fujitsu.com> To: paf@swip.net, urn-ietf@bunyip.com Subject: Re: [URN] What is equivalence? Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com | Now, if we only look at the urn equivalence rules, what do we | want byte-by-byte or character by character matchings? In | UNICODE we can write characters like "A-With-Grave" or | "A"+"COMPOSING GRAVE". For some groups of characters, | especially Arabic, one UNICODE character might expand | (decompose) into not two or three, but up to 32 characters. No. There is one Unicode code point (which I cannot find at the moment) that maps to a pious phrase as represented by a single glyph (think "piece of cold type"), which may be what you're thinking of. That Unicode Arabic code point does not represent the phrase as written out in letters, it represents the single glyph. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA27704 for urn-ietf-out; Wed, 23 Oct 1996 13:28:27 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA27699 for ; Wed, 23 Oct 1996 13:28:25 -0400 Received: from info.cren.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17995 (mail destined for urn-ietf@services.bunyip.com); Wed, 23 Oct 96 13:28:21 -0400 Received: from [198.76.81.108] (cr002-05.bn3.cren.net [198.76.81.106]) by info.cren.net (8.6.6/8.6.4 (CREN)) with SMTP id MAA13063; Wed, 23 Oct 1996 12:37:33 -0400 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Oct 1996 12:38:19 -0500 To: Ron Daniel , jch@netscape.com From: conklin@info.cren.net (Jim Conklin) Subject: Re: [URN] Pre release of URN Syntax document.... Cc: URN Mailing list Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: conklin@info.cren.net (Jim Conklin) Errors-To: owner-urn-ietf@bunyip.com At 10:12 AM 10/23/96, Ron Daniel wrote: > ... >What I would like to see happen is that a URN resolution algorithm >becomes the "unknown scheme" error handler in browsers. ... I think that makes a lot of sense, Ron. Jim Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA26911 for urn-ietf-out; Wed, 23 Oct 1996 12:05:38 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA26905 for ; Wed, 23 Oct 1996 12:05:35 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17213 (mail destined for urn-ietf@services.bunyip.com); Wed, 23 Oct 96 12:05:31 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA21086; Wed, 23 Oct 1996 10:05:07 -0600 (MDT) Message-Id: <2.2.32.19961023161244.006aa8d8@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Oct 1996 10:12:44 -0600 To: "James K. Tauber" , "Larry Masinter" , From: Ron Daniel Subject: Re: [URN] Pre release of URN Syntax document.... Cc: Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke James K. Tauber (at least at 11:56 AM 10/23/96 +0800) > >I haven't got ISO/IEC 9070 in front of me at the moment but my notes give >the canonical public identifier owner name form of ISBNs as being hyphen >separated. Sounds good to me. >While I'm on the subject of ISO/IEC 9070... > >Is there an argument for using the ISO/IEC 9070 scheme for grandfathering* >ISBNs in? Can you give us a brief synopsis of the scheme? My (probably faulty) understanding is that 9070 uses the "publisher id" part of an ISBN to identify naming authorities, but that they can then assign their own strings to make the rest of an identifier. Is that true? >Also, do people think it worthwhile for the IETF (or whoever) to get an ISO >identified organisation authority prefix? This would allow the trivial >assignment of an ISO/IEC 9070 identifier for every URN, regardless of >namespace. If it is just a matter of buying a small block of ISBN space and only using the prefix, I don't see any serious objections. I'm not sure of the cost and where the funds would come from. I'll ask our area directors. While I don't have serious objections, I don't see the benefits. Do we NEED to be able to assign 9070 identifiers for any URN? Why? Does 9070 allow other registries for naming authorities? Specifically, does it allow ISO Object Identifiers? Since the IETF already does a lot with OIDs, and OIDs are a lot closer to arbitrary scalability than ISBN publisher IDs, I would tend to prefer that approach if it is possible. "Constructed OIDs" are another possible way to make a valid identifier in some ISO scheme out of an arbitrary URN. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA26544 for urn-ietf-out; Wed, 23 Oct 1996 11:36:25 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA26531 for ; Wed, 23 Oct 1996 11:35:23 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16941 (mail destined for urn-ietf@services.bunyip.com); Wed, 23 Oct 96 11:35:21 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id JAA20491; Wed, 23 Oct 1996 09:35:08 -0600 (MDT) Message-Id: <2.2.32.19961023154245.006ac56c@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Oct 1996 09:42:45 -0600 To: Larry Masinter , paf@swip.net From: Ron Daniel Subject: Re: [URN] What is equivalence? Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Larry Masinter (at least at 12:46 AM 10/23/96 PDT) [I'm responding to Larry's paragraphs in a different order than he sent them] >While there's not much problem if two strings that are not equivalent >now might be declared equivalent in the future, there's a serious >problem if two strings that are equivalent now are determined to be >non-equivalent later. Agreed. >The issue for Unicode decomposition is that it is possible to imagine >Unicode adding some new composition rule in the future. Thus, the >time scope of the equivalence relationship is limited: I asume that the character equivalances in ISO 10646 are set, and that any additional equivalances would be under a new standard. (Can anyone confirm or deny this?) So, while I agree that the equivalances could change over time, the URN syntax draft (if we decide to do UNICODE character equivalents) should probably say that the 10646 equivalants are the ones we do. That set of equivalances would not change over time. Personally, I have no opinion on UNICODE character equivalants. Patrik presented the arguments for both sides. I like the implementation ease of not doing equivalents, but then we are not doing "true" 10646 so we have to very careful about the wording of the URN syntax draft. Anyone out there with strong opinions one way or the other? >Do the namespaces 'define' equivalence, or do they 'implement' it? > >That is, would you want to assert that if > isbn:0-13-443672-5 and isbn:013443672-5 >are ever to be treated the 'same', then they must always be treated >the 'same'? Otherwise, a client which has 'knowledge about the >namespace' might find that knowledge out of date. If the rules of a namespace change, it should probably be considered a new namespace and get a new namespace ID. If the change is such that names that used to be considered equivalant can no longer be considered such, then a new ID is certainly called for. I think this means that namespaces "define" equivalence. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA26303 for urn-ietf-out; Wed, 23 Oct 1996 11:05:08 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA26298 for ; Wed, 23 Oct 1996 11:05:06 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16561 (mail destined for urn-ietf@services.bunyip.com); Wed, 23 Oct 96 11:05:05 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id JAA19847; Wed, 23 Oct 1996 09:05:03 -0600 (MDT) Message-Id: <2.2.32.19961023151239.00693c30@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Oct 1996 09:12:39 -0600 To: jch@netscape.com From: Ron Daniel Subject: Re: [URN] Pre release of URN Syntax document.... Cc: URN Mailing list Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke YON - Jan C. Hardenbergh (at least at 07:06 AM 10/23/96 -0400) >Ron Daniel wrote: >> Thus spoke Daniel LaLiberte (at least at 11:54 AM 10/21/96 -0500) >> >Is the intent that "urn:" be optional within more contexts, such >> >as within HTML documents following "HREF="? >> >> That is *my* intent, although I would be interested in feedback >> from the list on the subject. >>From a VRML point of view, we need it to be there. While we have not >quite written it in to the spec, yet. There is a notion that one can >create extenions to VRML and have them defined by a URN. The browser >can then use native implementations for URNs it recognizes. This is to solve the generic telephone problem? Can you please give an example of the URNs you are thinking of? >I don't understand how it can be optional. Is it that it is the >URN resolution is the default protocol? How do we know that there >is not an isbn: protocol? The URN syntax says [urn:] NID ':' NSS In other words, the urn: is *always* followed by a Namespace Identifier. It is my thinking (which I believe is shared by many others on this list) that new namespaces go through the same sort of review process as new URL schemes do. Therefore, we would have a mechanism for ensuring that URN namespace IDs did not use the same character string as a URL protocol. That is how we would know there is not an isbn: protocol, as opposed to an isbn: namespace. Given that URNs have to provide a namespace ID, and that the namespace ID will be distinct from URL protocols, the urn: prefix does not add a great deal of information. Since it has been the source of religious controversy in the past, I suggested making it optional. (I also like using isbn: as an example, rather than urn:isbn:). What I would like to see happen is that a URN resolution algorithm becomes the "unknown scheme" error handler in browsers. Browsers continue to have a lookup table of schemes and function pointers to handle those schemes. When an unknown scheme is encountered, they can assume it is a new URN namespace and try to resolve it that way. The URN resolver would then report an unknown namespace error, or send back info on "speak HTTP to this resolver to get the resource". Later, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA25709 for urn-ietf-out; Wed, 23 Oct 1996 10:13:12 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA25704 for ; Wed, 23 Oct 1996 10:13:09 -0400 Received: from h-205-217-237-33.netscape.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16068 (mail destined for urn-ietf@services.bunyip.com); Wed, 23 Oct 96 10:13:08 -0400 Received: from jch-isdn.mcom.com ([205.217.243.40]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id HAA00560; Wed, 23 Oct 1996 07:06:20 -0700 (PDT) Message-Id: <326DFC2A.664C@netscape.com> Date: Wed, 23 Oct 1996 07:06:18 -0400 From: "YON - Jan C. Hardenbergh" Organization: Netscape Communications X-Mailer: Mozilla 3.0b6Gold (Win95; I) Mime-Version: 1.0 To: Ron Daniel Cc: Daniel LaLiberte , Ian Higgs +44 171 542 8595 , URN Mailing list , Ryan Moats Subject: Re: [URN] Pre release of URN Syntax document.... References: <2.2.32.19961022163134.0070dd30@acl.lanl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "YON - Jan C. Hardenbergh" Errors-To: owner-urn-ietf@bunyip.com Ron Daniel wrote: > > Thus spoke Daniel LaLiberte (at least at 11:54 AM 10/21/96 -0500) > > >Is the intent that "urn:" be optional within more contexts, such > >as within HTML documents following "HREF="? > > That is *my* intent, although I would be interested in feedback > from the list on the subject. The bit about the urn: being optional > is because its presence or absence has always degenerated into > a religious war. I think you are the one who described it as > "unnecessary, but harmless". I think allowing it can ease the > transition period, since Navigator clients will send things starting > with urn: to the HTTP proxy instead of reporting an unknown protocol > error. Other than that I agree with your statement. >From a VRML point of view, we need it to be there. While we have not quite written it in to the spec, yet. There is a notion that one can create extenions to VRML and have them defined by a URN. The browser can then use native implementations for URNs it recognizes. I don't understand how it can be optional. Is it that it is the URN resolution is the default protocol? How do we know that there is not an isbn: protocol? -- YON - Jan C. Hardenbergh, jch@netscape.com, www.netscape.com/people/jch "Imagination is more important than knowledge" A. Einstein Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA24335 for urn-ietf-out; Wed, 23 Oct 1996 08:26:43 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA24330 for ; Wed, 23 Oct 1996 08:26:41 -0400 From: jayhawk@ds.internic.net Received: from cagw1.att.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15276 (mail destined for urn-ietf@services.bunyip.com); Wed, 23 Oct 96 08:26:40 -0400 Received: from qsun.ho.att.com by caig1.att.att.com (SMI-8.6/EMS-1.2 sol2) id IAA25828; Wed, 23 Oct 1996 08:14:23 -0400 Received: from qsun2.ho.att.com.qsun2 by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS) id AA03921; Wed, 23 Oct 96 08:17:40 EDT Received: from rickslap by qsun2.ho.att.com.qsun2 (5.x/EMS-1.2 sol2) id AB05666; Wed, 23 Oct 1996 08:16:34 -0400 Message-Id: <9610231216.AB05666@qsun2.ho.att.com.qsun2> Original-From: "Ryan Moats" To: "Terry Allen" , "urn-ietf@bunyip.com" Date: Tue, 22 Oct 96 18:52:50 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] re urn: optional Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: jayhawk@ds.internic.net Errors-To: owner-urn-ietf@bunyip.com On Tue, 22 Oct 1996 10:06:59 -0700 (PDT), Terry Allen wrote: >Within appropriate markup, urn: may add no information, e.g., > > A Complete History of Algiers > ... > sbn:8371-3613-X > > >(yes, this book identifies iteself by SBN, not ISBN). > >It might be desireable to cat on "URN:" when using this >information in some contexts, and to avoid confusion, >"URN" should not be used as the name space identifier >for any naming scheme registered as an URN scheme, that >is, no URN:URN:something. > Does anybody have a problem with this? Should this be in the framework document or the syntax document (my first reaction is that the syntax doc is not the place to handle this). Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA24249 for urn-ietf-out; Wed, 23 Oct 1996 08:17:55 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA24243 for ; Wed, 23 Oct 1996 08:17:53 -0400 From: jayhawk@ds.internic.net Received: from cagw1.att.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15181 (mail destined for urn-ietf@services.bunyip.com); Wed, 23 Oct 96 08:17:51 -0400 Received: from qsun.ho.att.com by caig1.att.att.com (SMI-8.6/EMS-1.2 sol2) id IAA25797; Wed, 23 Oct 1996 08:14:21 -0400 Received: from qsun2.ho.att.com.qsun2 by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS) id AA03918; Wed, 23 Oct 96 08:17:38 EDT Received: from rickslap.ho.att.com by qsun2.ho.att.com.qsun2 (5.x/EMS-1.2 sol2) id AA05666; Wed, 23 Oct 1996 08:16:32 -0400 Message-Id: <9610231216.AA05666@qsun2.ho.att.com.qsun2> Original-From: "Ryan Moats" To: "URN mailing list" Date: Tue, 22 Oct 96 18:50:53 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] Pre release of URN Syntax document.... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: jayhawk@ds.internic.net Errors-To: owner-urn-ietf@bunyip.com On Tue, 22 Oct 96 12:27:42, Ryan Moats wrote: >Hmmm, that's an interesting concept. I have been considering >"lexical equivalence" at the client and what you call "functionally equivalent" >at the server to be the same thing. Basically, my definition of lexical equivalence >is that "two URNs are considered lexical equivalent at a machine if that machine >can determine unequivically USING ONLY LOCAL KNOWLEDGE that the two >URNs will return in the same resource." > >(Of course, I can change this given a good enough reason). > >Thus, Ian's example above (with/without urn:) is one where the two URN's >are lexically equivalent at both a client and a URN resolver. However, >Patrik's example is one where the two URN's are not lexically equivalent >at a client but would be lexically equivalent at a URN resolver. > >The bottom line is that I view lexical equivalence as a local phenomenom, rather >than a global one. It dawns on me that I should probably add words to that affect >(and possibly use these examples to highlight this) in the draft. > Ok. Based on all the discussion, I will add some text to the lexical equivalence section that discusses the fact that lexical equivalence is a local phenomenon. (Amazing what happens when you are on a plane!) Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id DAA21950 for urn-ietf-out; Wed, 23 Oct 1996 03:46:58 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id DAA21945 for ; Wed, 23 Oct 1996 03:46:56 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14366 (mail destined for urn-ietf@services.bunyip.com); Wed, 23 Oct 96 03:46:54 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16010(3)>; Wed, 23 Oct 1996 00:46:50 PDT Received: by golden.parc.xerox.com id <2763>; Wed, 23 Oct 1996 00:46:40 PDT To: paf@swip.net Cc: urn-ietf@bunyip.com In-Reply-To: (message from Patrik Faltstrom on Tue, 22 Oct 1996 22:50:39 PDT) Subject: Re: [URN] What is equivalence? From: Larry Masinter Message-Id: <96Oct23.004640pdt."2763"@golden.parc.xerox.com> Date: Wed, 23 Oct 1996 00:46:40 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com Do the namespaces 'define' equivalence, or do they 'implement' it? That is, would you want to assert that if isbn:0-13-443672-5 and isbn:013443672-5 are ever to be treated the 'same', then they must always be treated the 'same'? Otherwise, a client which has 'knowledge about the namespace' might find that knowledge out of date. On the other hand, you might want to allow duns:ibm to be the same as duns:international-business-machines but are you willing to allow that equivalence to be cached in clients or wired into them? In general, when you talk about 'equivalence', even for names of global scope in place, you have to define the time scope too. The issue for Unicode decomposition is that it is possible to imagine Unicode adding some new composition rule in the future. Thus, the time scope of the equivalence relationship is limited: While there's not much problem if two strings that are not equivalent now might be declared equivalent in the future, there's a serious problem if two strings that are equivalent now are determined to be non-equivalent later. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA21192 for urn-ietf-out; Wed, 23 Oct 1996 01:58:44 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA21187 for ; Wed, 23 Oct 1996 01:58:42 -0400 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13861 (mail destined for urn-ietf@services.bunyip.com); Wed, 23 Oct 96 01:58:39 -0400 Received: from [192.71.220.137] (zap.swip.net [192.71.220.137]) by nic.cafax.se (8.8.2/8.8.2) with ESMTP id HAA27373 for ; Wed, 23 Oct 1996 07:58:35 +0200 (MET DST) X-Sender: m-3329@mailbox.swip.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 23 Oct 1996 07:50:39 +0200 To: urn-ietf@bunyip.com From: Patrik Faltstrom Subject: [URN] What is equivalence? Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com First, sorry for not turning on my brain before starting to explain what I really wanted to say about equivalence regarding URNs. My point is that we have two different levels of equivalence to define: 1) Equivalence that is defined in the urn syntax paper 2) Equivalence that the namespace define We should here only talk about (1), and I will first try to explain why, and then talk about the specifik questions that arises when talking about (1) and at the same time UNICODE. When the client compares to URNs, we have to use the comparison algorithms we define in the framework or syntax document for urns. They can only be based on character-by-character comparisons (or byte-by-byte). The questions is which of these methods we use. Especially when using UTF-8 we have exactly the same comparison problems with decomposition in UNICODE that Bunyip have been working on for years with the Digger server (see proceeding from the last UNICODE conference where I and Philippe Boucher did have a paper which describes the UNICODE decomposition library developed for the Whois++/Digger server). Then, on the namespace level, you have a different comparison algorithm. With knowledge about the namespace (which the client _might_ have) equivalence might be defined as something completely different. For example, for ISBNs the ISBNs 0-13-443672-5 and 013443672-5 and even 13443672-5 or 0134436725 can be treated as "same" (yes, I did not type the leading "0" in the third example -- in Sweden it is very common to skip the leading "91"). But, these equivalence rules are something that we can not incorporate into the urn equivalence rules, only into the namespace specific equivalence rules. Now, if we only look at the urn equivalence rules, what do we want byte-by-byte or character by character matchings? In UNICODE we can write characters like "A-With-Grave" or "A"+"COMPOSING GRAVE". For some groups of characters, especially Arabic, one UNICODE character might expand (decompose) into not two or three, but up to 32 characters. How one character should be decomposed are defined in the UNICODE spec. The basic comparison rules in UNICODE say that before comparing two characters they have to be decomposed maximally and then all characters they decompose into have to be sorted according to given rules. After these two steps, byte-by-byte comparison can be done. All of this is "simple" to code because all of these operations are just table lookups. The problem is that the tables are large... BUT we can also just say that we on the urn level are looking at simpler equivalence, which means that "A"+"Combining Grave" is not the same as "A With Grave" even though the UNICODE spec states that so is the case. I.e. we say that equivalence is based on character by character without decomposition. The former is better, the latter is _much_ simpler to implement, and who needs that refined comparison algorithms on the urn level when the namespace probably define it's own rules anyway? Patrik -------------------------------------------------------------------- Senior Researcher, Tele2/SwipNet Stockholm, Sweden paf@swip.net Phone: +46-8-56264000 urn:inet:urn.paf.se In theory, there's no difference between theory and practice, but in practice, there is. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA19535 for urn-ietf-out; Tue, 22 Oct 1996 23:57:24 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA19522 for ; Tue, 22 Oct 1996 23:56:47 -0400 Received: from docker.library.uwa.edu.au by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13075 (mail destined for urn-ietf@services.bunyip.com); Tue, 22 Oct 96 23:56:42 -0400 Received: from dehquhp.library.uwa.edu.au (dehquhp.library.uwa.edu.au [130.95.106.230]) by docker.library.uwa.edu.au (8.8.0/8.8.0) with ESMTP id LAA24221; Wed, 23 Oct 1996 11:56:09 +0800 (WST) Message-Id: <199610230356.LAA24221@docker.library.uwa.edu.au> From: "James K. Tauber" To: "Ron Daniel" , "Larry Masinter" , Cc: Subject: Re: [URN] Pre release of URN Syntax document.... Date: Wed, 23 Oct 1996 11:56:50 +0800 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "James K. Tauber" Errors-To: owner-urn-ietf@bunyip.com I haven't got ISO/IEC 9070 in front of me at the moment but my notes give the canonical public identifier owner name form of ISBNs as being hyphen separated. While I'm on the subject of ISO/IEC 9070... Is there an argument for using the ISO/IEC 9070 scheme for grandfathering* ISBNs in? *a word that my Australian ears learnt from IETF WG discussions :-) Also, do people think it worthwhile for the IETF (or whoever) to get an ISO identified organisation authority prefix? This would allow the trivial assignment of an ISO/IEC 9070 identifier for every URN, regardless of namespace. -- James K. Tauber / jtauber@library.uwa.edu.au University CWIS Coordination Officer The University of Western Australia Room 2.42, Scholars' Centre, Reid Library Phone: +61 9 380 7136 FAX: +61 9 380 1128 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA16892 for urn-ietf-out; Tue, 22 Oct 1996 18:31:51 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA16877 for ; Tue, 22 Oct 1996 18:31:46 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11419 (mail destined for urn-ietf@services.bunyip.com); Tue, 22 Oct 96 18:31:43 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id QAA14249; Tue, 22 Oct 1996 16:31:34 -0600 (MDT) Message-Id: <2.2.32.19961022223910.0071aa38@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Oct 1996 16:39:10 -0600 To: Patrik Faltstrom , Larry Masinter From: Ron Daniel Subject: Re: [URN] Pre release of URN Syntax document.... Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Patrik Faltstrom (at least at 11:31 PM 10/22/96 +0200) >On Tue, 22 Oct 1996, Larry Masinter wrote: >> For example, the NAPTR resolution scheme depends on regular expression >> patterns which will not work well if all of the different syntactic >> variations of URNs might be allowed. >So far in the >NAPTR proposal, _no_ regular expression is operating on the >opaque string, even though that is possible, and interesting, >in some namespaces. Sorry Patrik, but the CID example and HTTP example both extract a domain name from the opaque (NSS) portion of the URN. Larry is correct that allowing lots of legal syntactic variants can cause problems for the NAPTR scheme. (Although the particular example of ISBNs would almost certainly not be one of the cases where a problem arises. But I digress). However, we are not talking about the same problems here. One problem is that of lexical equivalance - the mappings all clients need to know in order to answer the question "is it safe to regard URN1 and URN2 as identifying the same resource". The second problem is that of "is this URN a legal name from namespace foo"? The second problem can't be solved in general by clients without adopting extraordinary means, means that we have not in the past been willing to require and I have no desire to start requiring now. I agree that we need to define the legal form for names from namespaces like ISBN. I think that will happen by someone preparing drafts with titles like "The ISBN: Namespace" and we run them through review. Those documents will have to define what are legal encodings of names, and I think there should be as little variation as possible. But since a client can't answer the question of "is this name legal" all it can do is start following a resolution procedure. Resolution procedures that try to support namespace foo MUST be able to handle the legal encodings of names from that namespace. If that procedure wants to attempt some sophisticated error recovery, to handle names that have a different encoding, I say let it. If the sense of the list is to prohibit sophisticated error recovery, well, then any documents I edit will say that it is prohibited behavior. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA16886 for urn-ietf-out; Tue, 22 Oct 1996 18:31:49 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA16876 for ; Tue, 22 Oct 1996 18:31:45 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11418 (mail destined for urn-ietf@services.bunyip.com); Tue, 22 Oct 96 18:31:43 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id QAA14246; Tue, 22 Oct 1996 16:31:34 -0600 (MDT) Message-Id: <2.2.32.19961022223910.006f60a4@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Oct 1996 16:39:10 -0600 To: Larry Masinter , paf@swip.net From: Ron Daniel Subject: Re: [URN] Pre release of URN Syntax document.... Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Larry Masinter (at least at 01:51 PM 10/22/96 PDT) >Patrik Falstrom wrote: >So I disagree with the assertion: > ># For an ISBN, the followings should be equivalent: ># isbn:0-201-10174-2 ># isbn:0201101742 I believe Patrik was saying that clients should *NOT* regard the two as equivalent. The difference is whether some server, that deals with ISBNs on a regular basis, may use a comparison algorithm that is more accurate than the one clients have. >which sounds like, but isn't the same as, what we wrote for the 'URN >requirements' document in RFC 1737: > >> o Simple comparison: A comparison algorithm for URNs is simple, >> local, and deterministic. That is, there is a single algorithm for >> comparing two URNs that does not require contacting any external >> server, is well specified and simple. I think we all agree that clients need a simple algorithm, which will probably be character-by-character comparison after we have removed any %encoding, normalized any lexical equivalances (like the case of the NID), etc. Patrik has raised one issue - should the "decomposition rules in UNICODE [...] be part of these lexical equivalence rules". I need to know more about those decomposition rules before I can have an opinion on the subject, but it appears as if those decomposition rules are going to be fixed across all namespaces. As for the ISBN example above, decomposition rules or not, the presence of hypens in one identifier and their absence in another will cause the clients to say that the two identifiers are not the same, although we happen to know they really do identify the same resource. That's OK, the consequences of a false negative are much milder than the conseqences of a false positive, so a simple comparison procedure errs on the side of safety. An issue that is open right now is if we happen to be running a server dealing with lots of ISBNs, are we allowed to run a better equivalance algorithm that exploits our greater knowledge of the ISBN namespace? Personally, I think that is a reasonable thing to do. So, if such a server *somehow* gets two consecutive requests, one for an ISBN with hypens and another for an ISBN without hyphens, can it return the same resource or does it have to signal an error in one of those cases? I think it should be able to return the resource in either case, although there may be some way of indicating that a particular form of ISBN is preferred in the future. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA16686 for urn-ietf-out; Tue, 22 Oct 1996 18:13:34 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA16681 for ; Tue, 22 Oct 1996 18:13:25 -0400 From: jayhawk@ds.internic.net Received: from cagw1.att.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11164 (mail destined for urn-ietf@services.bunyip.com); Tue, 22 Oct 96 18:13:17 -0400 Received: from qsun.ho.att.com by caig1.att.att.com (SMI-8.6/EMS-1.2 sol2) id SAA14629; Tue, 22 Oct 1996 18:09:51 -0400 Received: from qsun2.ho.att.com.qsun2 by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS) id AA07208; Tue, 22 Oct 96 18:13:03 EDT Received: from [135.46.192.226] by qsun2.ho.att.com.qsun2 (5.x/EMS-1.2 sol2) id AB13120; Tue, 22 Oct 1996 18:11:54 -0400 Message-Id: <9610222211.AB13120@qsun2.ho.att.com.qsun2> Original-From: "Ryan Moats" To: "Ian Higgs +44 171 542 8595" , "Patrik Faltstrom" Cc: "URN Mailing list" Date: Tue, 22 Oct 96 12:27:42 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] Pre release of URN Syntax document.... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: jayhawk@ds.internic.net Errors-To: owner-urn-ietf@bunyip.com On Tue, 22 Oct 1996 07:40:45 +0200 (MET DST), Patrik Faltstrom wrote (>): On Tue, 22 Oct 1996 11:25:46 -0400 (EDT), Ian Higgs +44 171 542 8595 replied (!): > >On Mon, 21 Oct 1996, Ian Higgs +44 171 542 8595 wrote: >> >> ] 3. Lexical Equivalence >> >> Are the following lexically equivalent? >> urn:isbn:0-201-10174-2 >> isbn:0-201-10174-2 >> >> If so - add an example to highlighht this. > >It is even worse. For an ISBN, the followings should be equivalent: > >isbn:0-201-10174-2 >isbn:0201101742 !Maybe part of the registration process should include a definition of !the canonical representation of the Namespace Specific String. ! !In practice, I would assume that the 'resource server' would accept a !range of formats for the NSS and would treat them as equivalent. !This is not strictly 'lexically equivalent' - just 'functionally !equivalent' and would depend on the specific resource server. ! !Aside: Do we have a generic term for the creature that returns the !actual resource? Is 'resource server' OK? Hmmm, that's an interesting concept. I have been considering "lexical equivalence" at the client and what you call "functionally equivalent" at the server to be the same thing. Basically, my definition of lexical equivalence is that "two URNs are considered lexical equivalent at a machine if that machine can determine unequivically USING ONLY LOCAL KNOWLEDGE that the two URNs will return in the same resource." (Of course, I can change this given a good enough reason). Thus, Ian's example above (with/without urn:) is one where the two URN's are lexically equivalent at both a client and a URN resolver. However, Patrik's example is one where the two URN's are not lexically equivalent at a client but would be lexically equivalent at a URN resolver. The bottom line is that I view lexical equivalence as a local phenomenom, rather than a global one. It dawns on me that I should probably add words to that affect (and possibly use these examples to highlight this) in the draft. Ryan P.S. BTW, Anybody know the deadline for I-D submission for San Jose? I am planning on incorperating as many of the comments as I've gotten on the syntax draft before submitting for publication before Dec., and I haven't seen a date (and I'm stuck on a plane right now, so I don't have access to our mirror sites of this type of information). Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA16270 for urn-ietf-out; Tue, 22 Oct 1996 17:32:01 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA16265 for ; Tue, 22 Oct 1996 17:31:59 -0400 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10822 (mail destined for urn-ietf@services.bunyip.com); Tue, 22 Oct 96 17:31:57 -0400 Received: from nic.cafax.se (paf@nic.cafax.se [193.12.122.42]) by nic.cafax.se (8.8.2/8.8.2) with SMTP id XAA25263; Tue, 22 Oct 1996 23:31:48 +0200 (MET DST) Date: Tue, 22 Oct 1996 23:31:48 +0200 (MET DST) From: Patrik Faltstrom X-Sender: paf@nic.cafax.se To: Larry Masinter Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] Pre release of URN Syntax document.... In-Reply-To: <96Oct22.135155pdt."2759"@golden.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com On Tue, 22 Oct 1996, Larry Masinter wrote: > > o Simple comparison: A comparison algorithm for URNs is simple, > > local, and deterministic. That is, there is a single algorithm for > > comparing two URNs that does not require contacting any external > > server, is well specified and simple. > > This was discussed at length. It's true that it would be useful for > those who know about ISBNs to allow both isbn:0-201-10174-2 and > isbn:0210101742, but having a large variety of syntactic equivalences > has a large cost. What I am trying to say is that the general URN comparison algorithm must define a case of equivalence which is useful for some applications, but not for other. It can only deal with lexical equivalence, and what we are discussing are things like if the decomposition rules in UNICODE should be part of these lexical equivalence rules. On a different level, the namespace itself can define a kind of equivalence which makes it possible for example to use the urn "urn:isbn:0-201-10174-2" or "urn:isbn:0210101742" and get the same object. They are syntactical equivalent, but not lexical. > For example, the NAPTR resolution scheme depends on regular expression > patterns which will not work well if all of the different syntactic > variations of URNs might be allowed. The NAPTR proposal does only say that you can use regular expressions to find the resolution service. When you have found that service, you always pass the full URN to that service (if nothing special is specified as a protocol specific functionality). So far in the NAPTR proposal, _no_ regular expression is operating on the opaque string, even though that is possible, and interesting, in some namespaces. You have to remember that the regular expression is constructed and stored by the owner of the URN which the expression is operating on, so that person knows what target the expression is operating on. Just like the fact that one namespace might have its own ways of defining the word equivalence when accessing the final resolution service. > So I disagree with the assertion: > > # For an ISBN, the followings should be equivalent: > # isbn:0-201-10174-2 > # isbn:0201101742 > > If you're going to 'grandfather' ISBN numbers, you should do so in a > single unambiguous way. You have to differ between what result you get when you "just" compare the lexical equivalence between the two urns and what you get when you try to resolve the two urns in the final resolver which knows about isbns. I.e. one thing is the equivalence when looking at them as urns, and then they are different, but later, when having knowledge about the isbn namespace, they should be equivalent. One thing is defined in the urn paper, and one in the paper which describes the isbn namespace. I don't think the urn paper and the namespace papers have to have the same definition of "equivalent". Patrik Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA15863 for urn-ietf-out; Tue, 22 Oct 1996 16:55:09 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA15858 for ; Tue, 22 Oct 1996 16:55:02 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10411 (mail destined for urn-ietf@services.bunyip.com); Tue, 22 Oct 96 16:54:30 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16592(3)>; Tue, 22 Oct 1996 13:54:11 PDT Received: by golden.parc.xerox.com id <2759>; Tue, 22 Oct 1996 13:51:55 PDT To: paf@swip.net Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com In-Reply-To: (message from Patrik Faltstrom on Tue, 22 Oct 1996 09:32:54 PDT) Subject: Re: [URN] Pre release of URN Syntax document.... From: Larry Masinter Message-Id: <96Oct22.135155pdt."2759"@golden.parc.xerox.com> Date: Tue, 22 Oct 1996 13:51:55 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com Patrik Falstrom wrote: # Exactly my point, but I was not explicit. Lexical equivalence must # be something that is handled by the resource server for that specific # namespace. On the URN "level" we can only state some kind of # very, very simple comparison methods and point out that it is # the resource service for that namespace that handles the real # comparison. which sounds like, but isn't the same as, what we wrote for the 'URN requirements' document in RFC 1737: > o Simple comparison: A comparison algorithm for URNs is simple, > local, and deterministic. That is, there is a single algorithm for > comparing two URNs that does not require contacting any external > server, is well specified and simple. This was discussed at length. It's true that it would be useful for those who know about ISBNs to allow both isbn:0-201-10174-2 and isbn:0210101742, but having a large variety of syntactic equivalences has a large cost. For example, the NAPTR resolution scheme depends on regular expression patterns which will not work well if all of the different syntactic variations of URNs might be allowed. So I disagree with the assertion: # For an ISBN, the followings should be equivalent: # isbn:0-201-10174-2 # isbn:0201101742 If you're going to 'grandfather' ISBN numbers, you should do so in a single unambiguous way. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA12466 for urn-ietf-out; Tue, 22 Oct 1996 13:25:55 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA12460 for ; Tue, 22 Oct 1996 13:25:51 -0400 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07654 (mail destined for urn-ietf@services.bunyip.com); Tue, 22 Oct 96 13:25:50 -0400 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id MAA14340; Tue, 22 Oct 1996 12:21:28 -0500 (CDT) Date: Tue, 22 Oct 1996 12:21:28 -0500 (CDT) From: Daniel LaLiberte Message-Id: <199610221721.MAA14340@ncsa.uiuc.edu> To: Ron Daniel Cc: URN Mailing list Subject: Re: [URN] Pre release of URN Syntax document.... In-Reply-To: <2.2.32.19961022163134.0070dd30@acl.lanl.gov> References: <2.2.32.19961022163134.0070dd30@acl.lanl.gov> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Ron Daniel writes: > I think you are the one who described it as "unnecessary, but harmless". "Unnecessary and insufficient, but harmless." is a good paraphrase of my WWW4 panel presentation '"URN:" is neither necessary nor sufficient - but it's OK' If anyone wants to continue this, email me. dan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA12142 for urn-ietf-out; Tue, 22 Oct 1996 13:08:11 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA12137 for ; Tue, 22 Oct 1996 13:08:09 -0400 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07505 (mail destined for urn-ietf@services.bunyip.com); Tue, 22 Oct 96 13:08:02 -0400 Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id KAA24233 for ; Tue, 22 Oct 1996 10:06:30 -0700 (PDT) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id KAA04767 for urn-ietf@bunyip.com; Tue, 22 Oct 1996 10:06:59 -0700 (PDT) Date: Tue, 22 Oct 1996 10:06:59 -0700 (PDT) From: Terry Allen Message-Id: <199610221706.KAA04767@ishtar.fsc.fujitsu.com> To: urn-ietf@bunyip.com Subject: [URN] re urn: optional Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Within appropriate markup, urn: may add no information, e.g., A Complete History of Algiers ... sbn:8371-3613-X (yes, this book identifies iteself by SBN, not ISBN). It might be desireable to cat on "URN:" when using this information in some contexts, and to avoid confusion, "URN" should not be used as the name space identifier for any naming scheme registered as an URN scheme, that is, no URN:URN:something. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA11798 for urn-ietf-out; Tue, 22 Oct 1996 12:35:47 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA11793 for ; Tue, 22 Oct 1996 12:35:41 -0400 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07149 (mail destined for urn-ietf@services.bunyip.com); Tue, 22 Oct 96 12:35:37 -0400 Received: from [192.71.220.137] (zap.swip.net [192.71.220.137]) by nic.cafax.se (8.8.2/8.8.2) with ESMTP id SAA24715; Tue, 22 Oct 1996 18:35:22 +0200 (MET DST) X-Sender: m-3329@mailbox.swip.net Message-Id: In-Reply-To: <2.2.32.19961022154632.006fec6c@acl.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Oct 1996 18:32:54 +0200 To: Ron Daniel , URN Mailing list From: Patrik Faltstrom Subject: Re: [URN] Pre release of URN Syntax document.... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com At 09.46 -0600 96-10-22, Ron Daniel wrote: >>] It is even worse. For an ISBN, the followings should be equivalent: >>] >>] isbn:0-201-10174-2 >>] isbn:0201101742 > >This sort of lexical equivalance cannot be determined in general. It >is specific to the namespace. A client without special knowledge of >the isbn: namespace cannot be expected to compare >isbn:0-201-10174-2 to isbn:0210101742 and conclude they are equivalent. Exactly my point, but I was not explicit. Lexical equivalence must be something that is handled by the resource server for that specific namespace. On the URN "level" we can only state some kind of very, very simple comparison methods and point out that it is the resource service for that namespace that handles the real comparison. paf -------------------------------------------------------------------- Senior Researcher, Tele2/SwipNet Stockholm, Sweden paf@swip.net Phone: +46-8-56264000 urn:inet:urn.paf.se In theory, there's no difference between theory and practice, but in practice, there is. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA11664 for urn-ietf-out; Tue, 22 Oct 1996 12:24:53 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA11636 for ; Tue, 22 Oct 1996 12:24:12 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06959 (mail destined for urn-ietf@services.bunyip.com); Tue, 22 Oct 96 12:24:10 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA08187; Tue, 22 Oct 1996 10:23:55 -0600 (MDT) Message-Id: <2.2.32.19961022163134.0070dd30@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Oct 1996 10:31:34 -0600 To: Daniel LaLiberte , Ian Higgs +44 171 542 8595 From: Ron Daniel Subject: Re: [URN] Pre release of URN Syntax document.... Cc: URN Mailing list , Ryan Moats Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Daniel LaLiberte (at least at 11:54 AM 10/21/96 -0500) >Is the intent that "urn:" be optional within more contexts, such >as within HTML documents following "HREF="? That is *my* intent, although I would be interested in feedback from the list on the subject. The bit about the urn: being optional is because its presence or absence has always degenerated into a religious war. I think you are the one who described it as "unnecessary, but harmless". I think allowing it can ease the transition period, since Navigator clients will send things starting with urn: to the HTTP proxy instead of reporting an unknown protocol error. Other than that I agree with your statement. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA10995 for urn-ietf-out; Tue, 22 Oct 1996 11:39:03 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA10990 for ; Tue, 22 Oct 1996 11:39:01 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04653 (mail destined for urn-ietf@services.bunyip.com); Tue, 22 Oct 96 11:38:59 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id JAA07469 for ; Tue, 22 Oct 1996 09:38:56 -0600 (MDT) Message-Id: <2.2.32.19961022154632.006fec6c@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 22 Oct 1996 09:46:32 -0600 To: URN Mailing list From: Ron Daniel Subject: Re: [URN] Pre release of URN Syntax document.... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Ian Higgs +44 171 542 8595 (at least at 11:25 AM 10/22/96 -0400) >Then Patrik Faltstrom wrote: > >] It is even worse. For an ISBN, the followings should be equivalent: >] >] isbn:0-201-10174-2 >] isbn:0201101742 This sort of lexical equivalance cannot be determined in general. It is specific to the namespace. A client without special knowledge of the isbn: namespace cannot be expected to compare isbn:0-201-10174-2 to isbn:0210101742 and conclude they are equivalent. A resolver or resource server may have such knowledge, since if they deal with any ISBNs, they probably deal with a lot of them. I think this example illustrates just what the syntax draft is talking about when it makes a distinction between the equivalance procedure that can be applied at a client and at a server. The client procedure is going to give a lot of false negatives, the server procedure will be able to give fewer false negatives. >Maybe part of the registration process should include a definition of >the canonical representation of the Namespace Specific String. Sounds reasonable. >In practice, I would assume that the 'resource server' would accept a >range of formats for the NSS and would treat them as equivalent. >This is not strictly 'lexically equivalent' - just 'functionally >equivalent' and would depend on the specific resource server. Yes, but this will be up to the people running the resource servers. >Aside: Do we have a generic term for the creature that returns the >actual resource? Is 'resource server' OK? I have been calling it the "repository" in off-list communication, but "resource server" is OK. Either way. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA07748 for urn-ietf-out; Tue, 22 Oct 1996 06:25:50 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA07743 for ; Tue, 22 Oct 1996 06:25:43 -0400 Received: from ritig1.rit.reuters.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01806 (mail destined for urn-ietf@services.bunyip.com); Tue, 22 Oct 96 06:25:42 -0400 Received: from ritig4.rit.reuters.com by ritig1.rit.reuters.com; (5.65v3.2/1.1.8.2/14Sep94-0947PM) id AA05771; Tue, 22 Oct 1996 06:30:51 -0400 Received: from mr.rit.reuters.com by RITIG4.RIT.REUTERS.COM (PMDF V5.0-7 #7805) id <01IAXMLCZK34004YPW@RITIG4.RIT.REUTERS.COM>; Tue, 22 Oct 1996 06:26:24 -0400 (EDT) Received: with PMDF-MR; Tue, 22 Oct 1996 11:25:46 -0400 (EDT) Mr-Received: by mta REC.MUAS; Relayed; Tue, 22 Oct 1996 11:25:46 -0400 Mr-Received: by mta RE5; Relayed; Tue, 22 Oct 1996 11:25:50 -0400 Mr-Received: by mta RITIG4; Relayed; Tue, 22 Oct 1996 11:26:20 -0400 Disclose-Recipients: prohibited Date: Tue, 22 Oct 1996 11:25:46 -0400 (EDT) From: Ian Higgs +44 171 542 8595 Subject: Re: [URN] Pre release of URN Syntax document.... In-Reply-To: To: Patrik Faltstrom Cc: URN Mailing list , Ryan Moats Message-Id: <8146251122101996/A24314/RE5/11AAB2D92E00*@MHS> Autoforwarded: false Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Importance: normal Priority: urgent Sensitivity: Company-Confidential Ua-Content-Id: 11AAB2D92E00 X400-Mts-Identifier: [;8146251122101996/A24314/RE5] Hop-Count: 2 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ian Higgs +44 171 542 8595 Errors-To: owner-urn-ietf@bunyip.com ] On Mon, 21 Oct 1996, Ian Higgs +44 171 542 8595 wrote: ] > Are the following lexically equivalent? ] > urn:isbn:0-201-10174-2 ] > isbn:0-201-10174-2 Then Patrik Faltstrom wrote: ] It is even worse. For an ISBN, the followings should be equivalent: ] ] isbn:0-201-10174-2 ] isbn:0201101742 Maybe part of the registration process should include a definition of the canonical representation of the Namespace Specific String. In practice, I would assume that the 'resource server' would accept a range of formats for the NSS and would treat them as equivalent. This is not strictly 'lexically equivalent' - just 'functionally equivalent' and would depend on the specific resource server. Aside: Do we have a generic term for the creature that returns the actual resource? Is 'resource server' OK? /Ian Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA05266 for urn-ietf-out; Tue, 22 Oct 1996 01:40:56 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA05261 for ; Tue, 22 Oct 1996 01:40:50 -0400 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00673 (mail destined for urn-ietf@services.bunyip.com); Tue, 22 Oct 96 01:40:49 -0400 Received: from nic.cafax.se (paf@nic.cafax.se [193.12.122.42]) by nic.cafax.se (8.8.2/8.8.2) with SMTP id HAA23739; Tue, 22 Oct 1996 07:40:45 +0200 (MET DST) Date: Tue, 22 Oct 1996 07:40:45 +0200 (MET DST) From: Patrik Faltstrom X-Sender: paf@nic.cafax.se To: Ian Higgs +44 171 542 8595 Cc: URN Mailing list , Ryan Moats Subject: Re: [URN] Pre release of URN Syntax document.... In-Reply-To: <8336171721101996/A16366/RE5/11AAAC512400*@MHS> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com On Mon, 21 Oct 1996, Ian Higgs +44 171 542 8595 wrote: > > ] 3. Lexical Equivalence > > Are the following lexically equivalent? > urn:isbn:0-201-10174-2 > isbn:0-201-10174-2 > > If so - add an example to highlighht this. It is even worse. For an ISBN, the followings should be equivalent: isbn:0-201-10174-2 isbn:0201101742 paf Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA28934 for urn-ietf-out; Mon, 21 Oct 1996 15:59:43 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA28927 for ; Mon, 21 Oct 1996 15:59:40 -0400 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23206 (mail destined for urn-ietf@services.bunyip.com); Mon, 21 Oct 96 15:59:38 -0400 Message-Id: <9610211959.AA23206@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Mon Oct 21 15:01 CDT 1996 From: "Ryan Moats" To: "Martin J Duerst" , "Patrik Faltstrom" Cc: "urn-ietf@bunyip.com" Date: Mon, 21 Oct 96 15:04:20 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] Pre release of URN Syntax document.... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Mon, 21 Oct 1996 20:36:58 +0200 (MET DST), Patrik Faltstrom wrote: > >On Mon, 21 Oct 1996, Martin J Duerst wrote: > >> The other big problem is equivalence. For Unicode, character equivalence >> is in some cases not the same as codepoint equivalence. Charecter >> equivalence is well defined, but there is currently no standard >> for normalization. > >What exists are the decomposition rules for Unicode. Those are well defined. True, but I should probably add some stuff to section 3 about this. >> This does not concern things such as case, >> where the user can easily distinguish lower case and upper case, >> but cases such as A-with-Grave, which can be encoded both as >> one single codepoint and as the sequence A, Grave. > >The casing is also defined in the Unicode spec. > >What you do is to first decompose the string (i.e. change >A-with-Grave into A, Grave), and then do the case insensitive >comparison (if you want to). > >All of this is implemented in the Digger Whois++ server from >Bunyip. It is doable! Ah, yes but in the server, rather than in the client... >> Another problem that should be considered are bidirectionality >> for Hebrew and Arabic. > >It should be defined, just like in MIME, that characters are >stored in the order they are stored, not displayed. (At least >I remember that we discussed this with display order in the >MIME community in an interesting meeting faaaar back in time, >which was ended by looking at some example where two hebrew >users, using the same computer, was using different display >order...). I agree with Patrik. Regardless of glyph direction order, NSS octets are in order of presentation ie. (for left->right, left most character first, for right->left right most character first, etc.) >> It would be a good idea if URN resolvers could alos care about >> UNicode character equivalence. But maybe some schemes would do >> that easier than others? > >It is the resolution service that have to care about character >equivalence. The URN spec should only say UTF-8 from my point of >view. It could though be noted that A-with-grave and A, Grave in >Unicode is regarded as an example of equivalent characters. I agree with Patrik again. I have added the note. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA28848 for urn-ietf-out; Mon, 21 Oct 1996 15:53:22 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA28843 for ; Mon, 21 Oct 1996 15:53:16 -0400 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23123 (mail destined for urn-ietf@services.bunyip.com); Mon, 21 Oct 96 15:53:08 -0400 Message-Id: <9610211953.AA23123@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Mon Oct 21 14:54 CDT 1996 From: "Ryan Moats" To: "Martin J Duerst" Cc: "urn-ietf@bunyip.com" Date: Mon, 21 Oct 96 14:57:48 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] Pre release of URN Syntax document.... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com Since I've seen Patrik's comments, I'll only comment on things that he didn't and then add mine in a reply to his comments in a minute... On Mon, 21 Oct 1996 19:38:53 +0100 (MET), Martin J Duerst wrote: >Ryan Moats wrote: > >Well, first a great scream of joy and congratulations that you have >made it with iso10646/UTF-8. More comments on that below. I'll admit that it was a last minute addition, and did hold things up a bit while some issues were sorted out. However, might as well get things going now... >>1.1 Namespace Identifier Syntax >> >> The following is the syntax for the Namespace Identifier. To (a) be >> consistent with all potential resolution schemes and (b) not put any >> undue constraints on any potential resolution scheme, the syntax for >> the Namespace Identifier is: >> >> ::= [ ] >> >> ::= | "-" >> >> ::= any one of the 52 alphabetic characters A through Z >> in upper case and a through z in lower case >> >> This is slightly more restrictive that what is stated in RFC 1738 [4] >> (which allows the period "."). Further, the Namespace Identifier is >> case insensitive, so that "ISBN" and "isbn" refer to the same >> namespace. > >Kind of disappointed that i18n didn't make it for NIS. But it's probably >not necessary. And if it becomes necessary, we could just create a new >NIS, "i" for short, and could prefix it. Or am I stretching my understanding >of URN syntax too much? I don't like this, because it precludes freedom in the resolving scheme. >One main problem is that while the URL/URI didn't specify any >character semantics, this proposal defines everything in terms >of characters. >For URL/URIs, it was not defined what character, or part of a >character, bytes above 0x7F were denoting, nor was one even sure, >after reading the specs, that an "A" in an URL was supposed to be >the character "A". One only got a certain confidence in such >coincidences after having a look at some actual examples. >This had some advantages, as it left open any decisions for >the individual protocols, and it also considered cases where >the information in the URL did not have anything to do with >characters (e.g. something like the data URL). >So I think the spec should go more in the direction of: > >- If an NSS contains characters, these should be encoded using UTF-8. >- If an NSS contains something else (e.g. pure data), this can be > encoded directly using %HH. >- If an NSS, for some reasons, decides to use a different encoding > for characters, this is not prohibited (but not suggested). > >When the second point is introduced, the third cannot be avoided >anyway, because a NSS scheme may just define that it does %HH encoding >on its own, using a different character syntax, and the NSS encoding >of the characters in that scheme would only trivially encode >ASCII characters (with lots of "%" in it). > >This will also mean that NSS are not limited to be correct UTF-8 >sequences. I'll have to think about all of this, but my first reaction is that I don't like it. The rest will come in the next mail message... >>2. Grand-fathering >> >> To allow for grand-fathering of existing naming systems (as required >> by [2]), the Namespace Specific String shall be considered an "opaque >> string" in the sense of structure except as mentioned in Section 1. > >Just the fact that it is considered a string of characters in all cases >is somewhat restricting. Oh, I see. I wasn't thinking in terms of strings of characters, I was thinking in terms of string of octets. Guess I should change this, then. Lexica Equivalence will come in the next message. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA28726 for urn-ietf-out; Mon, 21 Oct 1996 15:42:07 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA28720 for ; Mon, 21 Oct 1996 15:42:06 -0400 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22976 (mail destined for urn-ietf@services.bunyip.com); Mon, 21 Oct 96 15:42:02 -0400 Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id MAA00110 for ; Mon, 21 Oct 1996 12:40:32 -0700 (PDT) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id MAA12063 for urn-ietf@bunyip.com; Mon, 21 Oct 1996 12:40:59 -0700 (PDT) Date: Mon, 21 Oct 1996 12:40:59 -0700 (PDT) From: Terry Allen Message-Id: <199610211940.MAA12063@ishtar.fsc.fujitsu.com> To: urn-ietf@bunyip.com Subject: [URN] re URN sytax Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Martin writes: | So I think the spec should go more in the direction of: | | - If an NSS contains characters, these should be encoded using UTF-8. | - If an NSS contains something else (e.g. pure data), this can be | encoded directly using %HH. Just to keep myself clear on what you're saying, ISO 10646 mixes glyphs and characters. By "characters" above, are you excluding glyphs-that-are-not-themselves-characters? Are those glyphs data? Or do you expect people not to use glyphs that aren't characters? Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA28576 for urn-ietf-out; Mon, 21 Oct 1996 15:33:07 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA28571 for ; Mon, 21 Oct 1996 15:33:05 -0400 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22865 (mail destined for urn-ietf@services.bunyip.com); Mon, 21 Oct 96 15:33:02 -0400 Message-Id: <9610211933.AA22865@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Mon Oct 21 14:34 CDT 1996 From: "Ryan Moats" To: "Daniel LaLiberte" Cc: "URN Mailing list" Date: Mon, 21 Oct 96 14:37:43 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] Pre release of URN Syntax document.... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Mon, 21 Oct 1996 11:54:35 -0500 (CDT), Daniel LaLiberte wrote: >Regarding grandfathering (a clear definition would be useful), I just >want to point out that when incorporating existing names from a name >scheme into another scheme, there is almost always some translation >that is required. The translation might just be to mapping to a >different character set, or it might involve a more radical >restructuring of the syntax. The important thing to preserve in a >name scheme is the semantics, or the higher-level structure. For >example, if a name scheme supports a hierarchy of naming authorities, >then the notation for expressing the hierarchy in a name might be >different (e.g. different delimiter or reverse the order of >components), but the hierarchy should still be accessible. Since grandfathering is meant as supporting existing legacy naming systems, I want to minimize the amount of translation necessary. I also feel that the structure is required at the resolver, but not the client. Thinking about syntax, the previous sentence has become an important consideration, not only for grandfathering (sorry, american colloquialism) but also for lexical equivalence (see forthcoming message)... "I see discussion, lots of discussion"... Ryan Moats Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA28503 for urn-ietf-out; Mon, 21 Oct 1996 15:27:41 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA28498 for ; Mon, 21 Oct 1996 15:27:39 -0400 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22762 (mail destined for urn-ietf@services.bunyip.com); Mon, 21 Oct 96 15:27:27 -0400 Message-Id: <9610211927.AA22762@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Mon Oct 21 14:28 CDT 1996 From: "Ryan Moats" To: "Ian Higgs +44 171 542 8595" , "URN Mailing list" Date: Mon, 21 Oct 96 14:32:05 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] Pre release of URN Syntax document.... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com >] Abstract >] 1. Syntax >] requirement to grandfather existing naming systems has the effect of > >"grandfather" as a verb? There is no definition of what that means here. American colloquialism strikes again. I will replace "grandfather existing naming systems" with "support existing legacy naming systems", as that is the connotation wanted here. >RFC1630 allows URI scheme names to include all letters and digits, >as well as a whole bunch of punctuation. Hosts names also include digits. > >Why not digits in namespace identifiers? They should be harmless enough. >(We could probably allow some punctuation too.) Well, this is where it starts to get a little more difficult. I can live with numbers and some other characters, but punctuation is not acceptable. The problem is supporting the broadest range of potential resolution scheme (the "let a million flowers bloom concept"). >] 1.2 Namespace Specific String Syntax >] Therefore, each namespace shall indicate which characters have >] special meaning and how (if possible) to encode those characters if >] used in a literal sense. > >Where and how shall a namespace indicate this? Include the BNF in the NID? > >Do you mean something like ... > > The process of registering a namespace identifier shall included > publication of a definition of which characters have a special > meaning and how to encode those characters if used in a literal sense. Yes, this is what I meant. I have replaced my wording with yours. >] 2. Grand-fathering > >It may be well understood by the URI/URN regulars, but please define here >what is meant by "Grand-fathering". The term is not defined in RFC1737. See my above comment about "grandfathering". >] 3. Lexical Equivalence > >Are the following lexically equivalent? > urn:isbn:0-201-10174-2 > isbn:0-201-10174-2 > >If so - add an example to highlighht this. Yes, they are, and I have added an example. >] 4. Security considerations >] ... Each namespace shall therefore indicate which characters ... > >How? Where? This is a restatement of the stuff in section 1.2. I have used the replacement text here, also. >] 6. References >] [1] L. L. Diagle, P. Falstrom, R. Iannella. "A Frame- >] work for the Assignment and Resolution of Uniform >] Resource Names", Internet Draft (work in progress). >] June 1996. > >URL? I didn't get this... >Should this document make any reference to the process for registering >namespace identifiers? I don't think so. I think that should be part of the framework document (MHO). Ryan Moats Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA27830 for urn-ietf-out; Mon, 21 Oct 1996 14:37:24 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA27825 for ; Mon, 21 Oct 1996 14:37:21 -0400 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22179 (mail destined for urn-ietf@services.bunyip.com); Mon, 21 Oct 96 14:37:10 -0400 Received: from nic.cafax.se (paf@nic.cafax.se [193.12.122.42]) by nic.cafax.se (8.8.2/8.8.2) with SMTP id UAA20724; Mon, 21 Oct 1996 20:36:59 +0200 (MET DST) Date: Mon, 21 Oct 1996 20:36:58 +0200 (MET DST) From: Patrik Faltstrom X-Sender: paf@nic.cafax.se To: Martin J Duerst Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com, leslie@bunyip.com, michaelm@internic.net, rdaniel@acl.lanl.gov Subject: Re: [URN] Pre release of URN Syntax document.... In-Reply-To: <"josef.ifi..310:21.09.96.18.38.55"@ifi.unizh.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com On Mon, 21 Oct 1996, Martin J Duerst wrote: > The other big problem is equivalence. For Unicode, character equivalence > is in some cases not the same as codepoint equivalence. Charecter > equivalence is well defined, but there is currently no standard > for normalization. What exists are the decomposition rules for Unicode. Those are well defined. > This does not concern things such as case, > where the user can easily distinguish lower case and upper case, > but cases such as A-with-Grave, which can be encoded both as > one single codepoint and as the sequence A, Grave. The casing is also defined in the Unicode spec. What you do is to first decompose the string (i.e. change A-with-Grave into A, Grave), and then do the case insensitive comparison (if you want to). All of this is implemented in the Digger Whois++ server from Bunyip. It is doable! > Another problem that should be considered are bidirectionality > for Hebrew and Arabic. It should be defined, just like in MIME, that characters are stored in the order they are stored, not displayed. (At least I remember that we discussed this with display order in the MIME community in an interesting meeting faaaar back in time, which was ended by looking at some example where two hebrew users, using the same computer, was using different display order...). > It would be a good idea if URN resolvers could alos care about > UNicode character equivalence. But maybe some schemes would do > that easier than others? It is the resolution service that have to care about character equivalence. The URN spec should only say UTF-8 from my point of view. It could though be noted that A-with-grave and A, Grave in Unicode is regarded as an example of equivalent characters. Patrik Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA27465 for urn-ietf-out; Mon, 21 Oct 1996 13:39:55 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA27460 for ; Mon, 21 Oct 1996 13:39:51 -0400 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21595 (mail destined for urn-ietf@services.bunyip.com); Mon, 21 Oct 96 13:39:01 -0400 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01070-0@josef.ifi.unizh.ch>; Mon, 21 Oct 1996 19:38:54 +0100 Subject: Re: [URN] Pre release of URN Syntax document.... To: jayhawk@ds.internic.net Date: Mon, 21 Oct 1996 19:38:53 +0100 (MET) Cc: urn-ietf@bunyip.com, leslie@bunyip.com, michaelm@internic.net, rdaniel@acl.lanl.gov, paf@swip.net In-Reply-To: <9610181749.AA07976@mocha.bunyip.com> from "Ryan Moats" at Oct 18, 96 12:52:34 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6658 From: Martin J Duerst Message-Id: <"josef.ifi..310:21.09.96.18.38.55"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ryan Moats wrote: >Well folks, we've reached the point where this is ready for the list >to scream about (semi :-) ). Well, first a great scream of joy and congratulations that you have made it with iso10646/UTF-8. More comments on that below. >Internet-Draft Ryan Moats >draft-ietf-urn-syntax-00.txt AT&T >Expires in six months October 1996 >Abstract > > This document presents the syntax for Uniform Resource Names (URNs). > More information on the purpose of URNs is available from [1]. > >1. Syntax > > All URNs have the following syntax: > > > ::= ["urn:"] ":" > > is the Namespace IDentifier, and is the Namespace > Specific String. The Namespace ID is used to determine the > _syntactic_ interpretation of the Namespace Specific String to the > extent of extracting the Naming Authority information (as discussed > in [1]). >1.1 Namespace Identifier Syntax > > The following is the syntax for the Namespace Identifier. To (a) be > consistent with all potential resolution schemes and (b) not put any > undue constraints on any potential resolution scheme, the syntax for > the Namespace Identifier is: > > ::= [ ] > > ::= | "-" > > ::= any one of the 52 alphabetic characters A through Z > in upper case and a through z in lower case > > This is slightly more restrictive that what is stated in RFC 1738 [4] > (which allows the period "."). Further, the Namespace Identifier is > case insensitive, so that "ISBN" and "isbn" refer to the same > namespace. Kind of disappointed that i18n didn't make it for NIS. But it's probably not necessary. And if it becomes necessary, we could just create a new NIS, "i" for short, and could prefix it. Or am I stretching my understanding of URN syntax too much? >1.2 Namespace Specific String Syntax > > Depending on the rules governing a namespace, valid identifiers in a > namespace might contain characters that are reserved characters in > URI syntax or non-printable ASCII characters. To accommodate the > largest set of valid identifiers, the NSS portion of a URN shall use > UTF-8 representation of ISO 10646 as its character set. This is really what I have waited for for a long time. As I wrote in a different mail, I have discussed that with many people on many occasions. It is definitely the right direction to go. But it needs a few refinements to assure it will work nicely, and to assure it won't be getting unnecessary opposition. Hopefully, these things can be integrated in this document; maybe another document is needed. One main problem is that while the URL/URI didn't specify any character semantics, this proposal defines everything in terms of characters. For URL/URIs, it was not defined what character, or part of a character, bytes above 0x7F were denoting, nor was one even sure, after reading the specs, that an "A" in an URL was supposed to be the character "A". One only got a certain confidence in such coincidences after having a look at some actual examples. This had some advantages, as it left open any decisions for the individual protocols, and it also considered cases where the information in the URL did not have anything to do with characters (e.g. something like the data URL). So I think the spec should go more in the direction of: - If an NSS contains characters, these should be encoded using UTF-8. - If an NSS contains something else (e.g. pure data), this can be encoded directly using %HH. - If an NSS, for some reasons, decides to use a different encoding for characters, this is not prohibited (but not suggested). When the second point is introduced, the third cannot be avoided anyway, because a NSS scheme may just define that it does %HH encoding on its own, using a different character syntax, and the NSS encoding of the characters in that scheme would only trivially encode ASCII characters (with lots of "%" in it). This will also mean that NSS are not limited to be correct UTF-8 sequences. The other big problem is equivalence. For Unicode, character equivalence is in some cases not the same as codepoint equivalence. Charecter equivalence is well defined, but there is currently no standard for normalization. This does not concern things such as case, where the user can easily distinguish lower case and upper case, but cases such as A-with-Grave, which can be encoded both as one single codepoint and as the sequence A, Grave. Another problem that should be considered are bidirectionality for Hebrew and Arabic. > URN resolvers MUST be capable of accepting URNs that have been > %encoded for either 8-bit clean or 7-bit transports. %encoding is > removed first, then UTF-8 decoding is performed. URN resolvers MUST > return identical results from ANY legally encoded form of the URN. It would be a good idea if URN resolvers could alos care about UNicode character equivalence. But maybe some schemes would do that easier than others? > It should be noted that certain characters in the Namespace Specific > String syntax may have special meaning in certain namespaces. > Therefore, each namespace shall indicate which characters have > special meaning and how (if possible) to encode those characters if > used in a literal sense. Rather a great requirement on implementors, because they have to know new things for every new namespace. But maybe it cannot be avoided. The question here is: How to escape a character beyond ASCII? Would it be possible to specify that all characters in ASCII, if in %HH form, are to be considered escaped? >2. Grand-fathering > > To allow for grand-fathering of existing naming systems (as required > by [2]), the Namespace Specific String shall be considered an "opaque > string" in the sense of structure except as mentioned in Section 1. Just the fact that it is considered a string of characters in all cases is somewhat restricting. >3. Lexical Equivalence > Lexical equivalence at the server is dependent on the namespace, and > thus each namespace shall indicate how lexical equivalence may be > determined by servers for URNs specifying resources in that > namespace. As said, some general help or suggestions for Unicode character equivalence might be in order here. This does not restrict individual namespaces to go further in declaring equivalences. That's it, for the moment. Looking forward to interesting discussions. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA27016 for urn-ietf-out; Mon, 21 Oct 1996 12:59:01 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA27011 for ; Mon, 21 Oct 1996 12:58:58 -0400 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21192 (mail destined for urn-ietf@services.bunyip.com); Mon, 21 Oct 96 12:58:55 -0400 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id LAA03361; Mon, 21 Oct 1996 11:54:35 -0500 (CDT) Date: Mon, 21 Oct 1996 11:54:35 -0500 (CDT) From: Daniel LaLiberte Message-Id: <199610211654.LAA03361@ncsa.uiuc.edu> To: Ian Higgs +44 171 542 8595 Cc: URN Mailing list , Ryan Moats Subject: Re: [URN] Pre release of URN Syntax document.... In-Reply-To: <8336171721101996/A16366/RE5/11AAAC512400*@MHS> References: <9610181749.AA07976@mocha.bunyip.com> <8336171721101996/A16366/RE5/11AAAC512400*@MHS> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Ian Higgs writes: > ] 3. Lexical Equivalence > > Are the following lexically equivalent? > urn:isbn:0-201-10174-2 > isbn:0-201-10174-2 Good question. I think the answer must be "yes". I noticed that the syntax made "urn:" optional, but nothing more was said about it. Since it is optional, it is much like the "URL:" prefix that is also optional in some circumstances, usually within arbitrary text. Is the intent that "urn:" be optional within more contexts, such as within HTML documents following "HREF="? Regarding grandfathering (a clear definition would be useful), I just want to point out that when incorporating existing names from a name scheme into another scheme, there is almost always some translation that is required. The translation might just be to mapping to a different character set, or it might involve a more radical restructuring of the syntax. The important thing to preserve in a name scheme is the semantics, or the higher-level structure. For example, if a name scheme supports a hierarchy of naming authorities, then the notation for expressing the hierarchy in a name might be different (e.g. different delimiter or reverse the order of components), but the hierarchy should still be accessible. This probably raises more questions than it answers. That was my intent. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA26543 for urn-ietf-out; Mon, 21 Oct 1996 12:17:39 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA26538 for ; Mon, 21 Oct 1996 12:17:33 -0400 Received: from ritig1.rit.reuters.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20730 (mail destined for urn-ietf@services.bunyip.com); Mon, 21 Oct 96 12:17:26 -0400 Received: from ritig4.rit.reuters.com by ritig1.rit.reuters.com; (5.65v3.2/1.1.8.2/14Sep94-0947PM) id AA23852; Mon, 21 Oct 1996 12:22:34 -0400 Received: from mr.rit.reuters.com by RITIG4.RIT.REUTERS.COM (PMDF V5.0-7 #7805) id <01IAWKL6AIC00048QL@RITIG4.RIT.REUTERS.COM>; Mon, 21 Oct 1996 12:18:10 -0400 (EDT) Received: with PMDF-MR; Mon, 21 Oct 1996 17:17:36 -0400 (EDT) Mr-Received: by mta REC.MUAS; Relayed; Mon, 21 Oct 1996 17:17:36 -0400 Mr-Received: by mta RE5; Relayed; Mon, 21 Oct 1996 17:17:38 -0400 Mr-Received: by mta RITIG4; Relayed; Mon, 21 Oct 1996 17:18:05 -0400 Disclose-Recipients: prohibited Date: Mon, 21 Oct 1996 17:17:36 -0400 (EDT) From: Ian Higgs +44 171 542 8595 Subject: Re: [URN] Pre release of URN Syntax document.... In-Reply-To: <9610181749.AA07976@mocha.bunyip.com> To: URN Mailing list Cc: Ryan Moats Message-Id: <8336171721101996/A16366/RE5/11AAAC512400*@MHS> Autoforwarded: false Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Importance: normal Priority: urgent Sensitivity: Company-Confidential Ua-Content-Id: 11AAAC512400 X400-Mts-Identifier: [;8336171721101996/A16366/RE5] Hop-Count: 2 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ian Higgs +44 171 542 8595 Errors-To: owner-urn-ietf@bunyip.com ] Well folks, we've reached the point where this is ready for the list ] to scream about (semi :-) ). ] Have at it.... I have a few gentle comments - no screams (as yet) +++START+++ ] Abstract ] 1. Syntax ] requirement to grandfather existing naming systems has the effect of "grandfather" as a verb? There is no definition of what that means here. ] 1.1 Namespace Identifier Syntax ] ::= [ ] ] ::= | "-" RFC1630 allows URI scheme names to include all letters and digits, as well as a whole bunch of punctuation. Hosts names also include digits. Why not digits in namespace identifiers? They should be harmless enough. (We could probably allow some punctuation too.) ] 1.2 Namespace Specific String Syntax ] Therefore, each namespace shall indicate which characters have ] special meaning and how (if possible) to encode those characters if ] used in a literal sense. Where and how shall a namespace indicate this? Include the BNF in the NID? Do you mean something like ... The process of registering a namespace identifier shall included publication of a definition of which characters have a special meaning and how to encode those characters if used in a literal sense. ] 2. Grand-fathering It may be well understood by the URI/URN regulars, but please define here what is meant by "Grand-fathering". The term is not defined in RFC1737. ] 3. Lexical Equivalence Are the following lexically equivalent? urn:isbn:0-201-10174-2 isbn:0-201-10174-2 If so - add an example to highlighht this. ] 4. Security considerations ] ... Each namespace shall therefore indicate which characters ... How? Where? ] 6. References ] [1] L. L. Diagle, P. Falstrom, R. Iannella. "A Frame- ] work for the Assignment and Resolution of Uniform ] Resource Names", Internet Draft (work in progress). ] June 1996. URL? +++END+++ Should this document make any reference to the process for registering namespace identifiers? Regards /Ian Higgs ------------------------------------------------- Ian Higgs Reuters Limited, Email: ian.higgs@reuters.com 85 Fleet Street, Fax: +44 171 542 8314 London EC4P 4AJ, Phone: +44 171 542 8595 England ------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA22040 for urn-ietf-out; Fri, 18 Oct 1996 13:50:23 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA22035 for ; Fri, 18 Oct 1996 13:50:19 -0400 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07976 (mail destined for urn-ietf@services.bunyip.com); Fri, 18 Oct 96 13:49:33 -0400 Message-Id: <9610181749.AA07976@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Fri Oct 18 12:49 CDT 1996 From: "Ryan Moats" To: "URN mailing list" Cc: "Leslie Daigle" , "Michael Mealling" , "Ron Daniel" , "Martin J Duerst" , "Patrik Faltstrom" Date: Fri, 18 Oct 96 12:52:34 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] Pre release of URN Syntax document.... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com Well folks, we've reached the point where this is ready for the list to scream about (semi :-) ). Have at it.... Ryan Moats InterNIC Directory and Database Services jayhawk@ds.internic.net =================================================== Internet-Draft Ryan Moats draft-ietf-urn-syntax-00.txt AT&T Expires in six months October 1996 URN Syntax Filename: draft-ietf-urn-syntax-00.txt Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document presents the syntax for Uniform Resource Names (URNs). More information on the purpose of URNs is available from [1]. 1. Syntax All URNs have the following syntax: ::= ["urn:"] ":" is the Namespace IDentifier, and is the Namespace Specific String. The Namespace ID is used to determine the _syntactic_ interpretation of the Namespace Specific String to the extent of extracting the Naming Authority information (as discussed in [1]). RFC 1737 [2] puts additional requirements on URN encoding, which all Expires 4/97 [Page 1] INTERNET DRAFT URN Syntax October 1996 have implications as far as limiting syntax. On the other hand, the requirement to grandfather existing naming systems has the effect of broadening syntax. Thus, we discuss the acceptable syntax for both the Namespace Identifier and the Namespace Specific String separately. 1.1 Namespace Identifier Syntax The following is the syntax for the Namespace Identifier. To (a) be consistent with all potential resolution schemes and (b) not put any undue constraints on any potential resolution scheme, the syntax for the Namespace Identifier is: ::= [ ] ::= | "-" ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case This is slightly more restrictive that what is stated in RFC 1738 [4] (which allows the period "."). Further, the Namespace Identifier is case insensitive, so that "ISBN" and "isbn" refer to the same namespace. 1.2 Namespace Specific String Syntax Depending on the rules governing a namespace, valid identifiers in a namespace might contain characters that are reserved characters in URI syntax or non-printable ASCII characters. To accommodate the largest set of valid identifiers, the NSS portion of a URN shall use UTF-8 representation of ISO 10646 as its character set. Clients MUST be capable of %encoding the UTF-8 formatted NSS, according the rules in [3] with the following exceptions: 1. [3] states that occurrence of the '/' character in URIs must denote hierarchy, so that partial forms of a URI are possible. This restriction is unenforceable, and relative URLs do not have a scheme prefix, so we allow URNs to contain unescaped occurrences of the '/' character that do not denote hierarchy. 2. As an optimization when the transport between systems is known to be 8-bit-clean, clients MAY omit the %encoding on 8-bit characters but MUST still %encode the reserved characters below. For historic reasons, the characters "#", "?", "%", "*", "!", "<", ">", and '"', are reserved and must be encoded with '%'. Thus client Expires 4/97 [Page 2] INTERNET DRAFT URN Syntax October 1996 implementers should accept URNs from users in an unencoded form but must encode them before sending them to a resolver. URN resolvers MUST be capable of accepting URNs that have been %encoded for either 8-bit clean or 7-bit transports. %encoding is removed first, then UTF-8 decoding is performed. URN resolvers MUST return identical results from ANY legally encoded form of the URN. It should be noted that certain characters in the Namespace Specific String syntax may have special meaning in certain namespaces. Therefore, each namespace shall indicate which characters have special meaning and how (if possible) to encode those characters if used in a literal sense. 2. Grand-fathering To allow for grand-fathering of existing naming systems (as required by [2]), the Namespace Specific String shall be considered an "opaque string" in the sense of structure except as mentioned in Section 1. 3. Lexical Equivalence As discussed previously, Namespace Identifiers are to be considered case-insensitive. That is, the following two URNs are lexically equivalent: urn:isbn:0-201-10174-2 urn:ISBN:0-201-10174-2 Lexical equivalence at the client is restricted to unencoding '%' sequences, with other comparisons being considered case sensitive. That is, the following two URNs are lexically equivalent at a client: urn:foo:John DeSilva urn:foo:John%20DeSilva but the following two URNs are NOT lexically equivalent at a client: urn:foo:John%20DeSilva urn:foo:John%20deSilva Lexical equivalence at the server is dependent on the namespace, and thus each namespace shall indicate how lexical equivalence may be determined by servers for URNs specifying resources in that namespace. Expires 4/97 [Page 3] INTERNET DRAFT URN Syntax October 1996 4. Security considerations Because of the number of potential namespaces, it must be restated that certain of the characters in the Namespace Specific String may have special meaning to certain namespace resolvers. Each namespace shall therefore indicate which characters have special meaning and how (if possible) to encode those characters if used in a literal sense. 5. Acknowledgments Thanks to various members of the URN working group and <> for comments on earlier drafts of this document. This work was partially supported by the National Science Foundation. 6. References Request For Comments (RFC) and Internet Draft documents are available from and numerous mirror sites. [1] L. L. Diagle, P. Falstrom, R. Iannella. "A Frame- work for the Assignment and Resolution of Uniform Resource Names", Internet Draft (work in progress). June 1996. [2] K. Sollins, L. Masinter. "Functional Requirements for Uniform Resource Names", RFC 1737. December 1994. [3] T. Berners-Lee. "Universal Resource Identifiers in WWW", RFC 1630. June 1994. [4] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource Locators (URL)", RFC 1738. December 1994. 7. Author's address Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA Phone: +1 402 894-9456 EMail: jayhawk@ds.internic.net Expires 4/97 [Page 4] INTERNET DRAFT URN Syntax October 1996 This Internet Draft expires April 1, 1997. Expires 4/97 [Page 5] Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA09100 for urn-ietf-out; Thu, 17 Oct 1996 17:05:35 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA09094 for ; Thu, 17 Oct 1996 17:05:32 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28816 (mail destined for urn-ietf@services.bunyip.com); Thu, 17 Oct 96 17:05:29 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id PAA22540; Thu, 17 Oct 1996 15:05:24 -0600 (MDT) Message-Id: <2.2.32.19961017211251.0075097c@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Oct 1996 15:12:51 -0600 To: Larry Masinter From: Ron Daniel Subject: Re: [URN] a possible security architecture for URNs Cc: liberte@ncsa.uiuc.edu, urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Larry Masinter (at least at 10:37 AM 10/17/96 PDT) [And I said:] >> We shouldn't define an all-encompassing >> security policy for URNs. > >I agree with that. However, I had interpreted some messages (not from >you, but from Michael and Terry) a different position, e.g., that the >URN working group shouldn't worry about security. Yeah, I meant to quibble a bit with Terry's message and say that we should ensure the tools are available, but I thought his main point was that we can't mandate the policy. I just never got that message sent. (Hey, I'm still working on my reply in our off-list thread. :-) >My primary technical concern about using DNS security for NAPTR is >the issue of the granularity of authority. For example, it's likely >that any authority with the ability to change ONE of the NAPTR entries >for 'duns.urn.net' will have the ability to change all of the rest of >the records. I think that the entity that writes the check to have the "foo.urn.net" namespace gets to decide what NAPTR records go there, and bears any legal responsibility for what they do and do not put there. >Is this the right granularity of authority? Seems OK to me. Further, it seems isomorphic to the Rivest paper. The owner of a naming context decides what names to put there. If they make their naming context public, and someone doesn't like what they have done, they can sue. Not a technical issue. >Let's suppose that >'duns.urn.net' has replicated resolution services around the world, >one in the US, one in Japan, one in Australia, one in Russia: > >duns.urn.net >;; order pref flags service replacement regexp > IN NAPTR 100 10 "s" "dunslink+N2L+N2C" _dunslink._udp.isi.dandb.com "" > IN NAPTR 100 20 "s" "rcds+N2C" _rcds._udp.duns.com.au "" > IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" _http._tcp.dandb.co.jp "" > IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" _http._tcp.duns.co.ru "" > >but that the Russian operator needs to change the domain name. Or >wants to. Then they can communicate that desire to the owners of the duns.urn.net domain, who will or will not honor the request, and should accept the consequences. {As a correction to your example, which does not change the thrust of your question, you had a couple of entries of the form: > IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" _http._tcp.dandb.co.jp "" > IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" _http._tcp.duns.co.ru "" where the same service (same resolution protocol and same resolution services) would be available from two different domain names. We expect the SRV record to handle that. The NAPTR would have one entry of the form IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" _http._tcp.duns.com and the SRV record for _http._tcp.duns.com would list names like whatever.duns.co.ru and something.dandb.co.jp. } The contents of that SRV record are still at the discretion of whoever owns _http._tcp.duns.com. >Or that the Australian operator of the resolution service disputes the >Japanese operator over the spelling of a DUNS name that is in tradmark >dispute in the two countries. I don't understand this example, but I still think it is the case that if I am paying the money for a domain name, I get to say what goes into records for that domain name, and I bear the legal consequences for inclusion or ommision of information. > Are you >presuming (as is presumed with MX records for mail, which I'm assuming >is the model for NAPTR) that the operators of the resolution services >for a single global name space are the same commercial entity? No, but I think we have a terminology clash. As above, I assume there is some entity that is "responsible" for a namespace (or at least its top level). That entity may have contracted with some other entity (or entities) for the day-to-day operation of resolution services. Presumably the contract spells out what the operators will do for the owner, but that's not our problem. >The URN Framework document says only that [...] >but I think that any URN _resolution mechanism_ must be much more >explicit to be credible I think you are merging issues that the framework wants to keep seperate. The framework is based on the notion that we want to seperate name assignment from resolution, so that different resolution mechanisms can be used over time for the same namespace, and so that the same resolution mechanism can be used for different namespaces (Grandfathering support is the most obvious example of why we would want to do this, but I think it is a really good idea in general). >it is absolutely imperative that any system of naming that is >intended to be permanent (a prime URN requirements) must explicitly >deal with the issue of how the _resolution mechanism_ deals with >organizational change: not just the introduction of new organizations >but also mergers and divestitures. I agree with the sentiment but disagree with the details. I think that proposals for namespaces that are intended to be permanent should deal with the issues of how organizational change and conflict are handled in that namespace, and how the *results* of that process can be made available to resolution systems. The resolution mechanisms should be told "OK, entity X is now authoritative for portion Y of namespace Z", and it is their problem how to do the resolution once they have that knowledge. They should not get involved in the struggles that lead up to such a decision. The rest of the message was a reply to Jon Knight's material. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA06653 for urn-ietf-out; Thu, 17 Oct 1996 13:37:45 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA06648 for ; Thu, 17 Oct 1996 13:37:42 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26944 (mail destined for urn-ietf@services.bunyip.com); Thu, 17 Oct 96 13:37:39 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <14785(3)>; Thu, 17 Oct 1996 10:37:29 PDT Received: by golden.parc.xerox.com id <2770>; Thu, 17 Oct 1996 10:37:07 PDT To: rdaniel@acl.lanl.gov Cc: liberte@ncsa.uiuc.edu, urn-ietf@bunyip.com In-Reply-To: <2.2.32.19961017163113.006ff770@acl.lanl.gov> (message from Ron Daniel on Thu, 17 Oct 1996 09:31:13 PDT) Subject: Re: [URN] a possible security architecture for URNs From: Larry Masinter Message-Id: <96Oct17.103707pdt."2770"@golden.parc.xerox.com> Date: Thu, 17 Oct 1996 10:37:07 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com > We shouldn't define an all-encompassing > security policy for URNs. I agree with that. However, I had interpreted some messages (not from you, but from Michael and Terry) a different position, e.g., that the URN working group shouldn't worry about security. > As far as the NAPTR proposal goes, those tools come from DNSSEC. My primary technical concern about using DNS security for NAPTR is the issue of the granularity of authority. For example, it's likely that any authority with the ability to change ONE of the NAPTR entries for 'duns.urn.net' will have the ability to change all of the rest of the records. Is this the right granularity of authority? Let's suppose that 'duns.urn.net' has replicated resolution services around the world, one in the US, one in Japan, one in Australia, one in Russia: duns.urn.net ;; order pref flags service replacement regexp IN NAPTR 100 10 "s" "dunslink+N2L+N2C" _dunslink._udp.isi.dandb.com "" IN NAPTR 100 20 "s" "rcds+N2C" _rcds._udp.duns.com.au "" IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" _http._tcp.dandb.co.jp "" IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" _http._tcp.duns.co.ru "" but that the Russian operator needs to change the domain name. Or wants to. Or that the Australian operator of the resolution service disputes the Japanese operator over the spelling of a DUNS name that is in tradmark dispute in the two countries. Without having actually worked out the framework of authority in the URN framework, there are no guidelines for how the implementation should either control or evolve authority on the participants. Are you presuming (as is presumed with MX records for mail, which I'm assuming is the model for NAPTR) that the operators of the resolution services for a single global name space are the same commercial entity? The URN Framework document says only that > Some set of criteria must be established to govern what can and cannot > be used as a (top-level) namespace (NID assignment). This can include: > . demonstration of an established namespace management system > (including an overview of mechanisms for preventing the > duplication/reassignation of name identifiers. These mechanisms > are particular to the individual namespaces). > . multi-organization participation in the naming system > . rules on how names are assigned, name assignment authority > delegation > . provision of escape clause but I think that any URN _resolution mechanism_ must be much more explicit to be credible: "multi-organization participation in the naming system" must deal with not just cooperation but contention. And it is absolutely imperative that any system of naming that is intended to be permanent (a prime URN requirements) must explicitly deal with the issue of how the _resolution mechanism_ deals with organizational change: not just the introduction of new organizations but also mergers and divestitures. (How do you deal with the split of AT&T and Bell Labs in the NAPTR records for tpc.urn.net? What happens to duns.urn.net if Duns has a big argument with Bradstreet?) > As far as I can see, all you get from their > scheme's _naming_ technique (as distinct from their security architecture) > that is different from a NAPTR style URN is the ability to refer to things > as relative to yourself. This doesn't appear to be too useful as if you > distribute this name widely, people will either have to be given it in a > global form or be told where you are in the global scheme of things and > how your local namespace works. You can't use somebody else's relative > names without either having their principle name in your local namespace > or just using their global name rooted at one of the special root names > (Rivest and Lampson explicitly point this out in the paper, "The > principal you call alice-smith may be different from the principal I call > alice-smith.". So putting just "alice-smith" in a the bibliography of > another document wouldn't be much use to anyone bar the creator). Well, no. If I'm going to write a bibliography for publication, I'll put in references that are relative to an authority that we mutually recognize. That's the whole point of putting 'publisher' in the references anyway: the publisher is the authority. ACM's Larry Masinter's article. The publication itself forms the context, and peer reviewers are expected to note references. Let's look at the references in draft-daniel-naptr-01.txt # [1] RFC-1737 "Functional Requirements for Uniform Resource Names", Karen # Sollins and Larry Masinter, Dec. 1994. IETF's RFC's 1737 # [2] draft-daigle-urn-framework-00.txt "A Uniform Resource Naming # Framework", Leslie Daigle and Patrik Faltstrom, June, 1996. IETF's drafts' daigle-urn-framework-00 # [4] Paul Vixie, personal communication. # author's Paul Vixie with some assertion at the top that author = (LANL's Ron Daniel) + (Georgia Tech's Micahel Mealling) How would _you_ write URNs for those references? What are the authorities involved in assigning those references, and what would necessary for someone 50 years from now to be able to follow those references? Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA03604 for urn-ietf-out; Thu, 17 Oct 1996 12:24:40 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA03597 for ; Thu, 17 Oct 1996 12:24:05 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25994 (mail destined for urn-ietf@services.bunyip.com); Thu, 17 Oct 96 12:24:00 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA17262; Thu, 17 Oct 1996 10:23:46 -0600 (MDT) Message-Id: <2.2.32.19961017163113.006ff770@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Oct 1996 10:31:13 -0600 To: Larry Masinter , liberte@ncsa.uiuc.edu From: Ron Daniel Subject: Re: [URN] a possible security architecture for URNs Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Larry Masinter (at least at 02:21 AM 10/17/96 PDT) >[...] the best we get from NAPTR is >a hand-wave and protests that security isn't important because it >might be expensive to implement. That misrepresents my position on security. But before I can boil down my position to a single statement, let me establish some background. Security is not a binary property of a system. There is no such thing as a "secure" system or a "non-secure" system. Systems can be secured against particular forms of attack. That does not make those attacks impossible, it makes them more difficult and expensive to mount, lowers their probability of success, increases the probability of detection and response, etc. Systems cannot be made invulnerable to all possible forms of attack. Furthermore, each threat that must be countered raises the cost of constructing and operating the system. There is no point in spending more on securing the system than the value of the information in the system, the profit that can be derived from its operation, etc. The forms of attack that might be mounted, the resources available to an attacker, the costs of the measures required to defend against them, *and the decision on whether or not to implement those measures* cannot be evaluated in general. The likely threats and countermeasures to employ will depend on the information in the system and the resources available to the publisher of that information. *We cannot make that decision for them*. Of course, all these caveats are too tedious to mention in normal conversation, so we tend to say things like "secure system" when we really mean "a system that is hard to subvert using some common attacks, but still not too expensive to operate". With that background established, I can now state my position on URN security as: We shouldn't define an all-encompassing security policy for URNs. Not only does this mean that we should not establish a policy that requires everyone to implement defenses against many forms of attack, it also means that we should not prevent people from implementing those defenses. I will object to any standards-track proposal for a URN resolution proposal that does not provide the tools to allow people to implement defenses against common attacks. Not "all known tools" or "all possible attacks", but what in my best technical judgement are basic tools against common attacks. I am not a security expert, just an informed layman, so my technical judgement in such cases will rely on people who are expert in the area. This means people from the security area of the IETF, and some of my co-workers. As far as the NAPTR proposal goes, those tools come from DNSSEC. This toolkit does not include arbitrary encryption, but it does include key management, signatures, and some authentication. Arbitrary encryption would be nice, but it is unexportable. It appears to be the rough consensus of the DNSSEC-WG that the tools in the DNSSEC proposal are as much as can be provided at this time. How do those tools affect the NAPTR proposal? The NAPTR resource records themselves will, in all but the most unusual cases, be things like: If the URI you are trying to resolve contains "foo", ask server "bar" how to procede. or just ask server "baz", and talk to them using protocol X, Y, or Z. Although it is possible that such information could be highly confidential, it is not likely. Therefore the lack of arbitrary encyption does not, in my best techincal opinion, greatly concern me. Other attacks, such as spoofing responses, seem much more likely. However, those are precisely the attacks that DNSSEC counters. Once it comes time to talk with the resolver and actually put the URN onto the wire (it has not left the client up to this point) then we are no longer using DNS, we will be using one of the "resolution protocols" such as HTTP, HDL, RWHOIS, RCDS, etc. The security capabilities of these protocols are outside the bounds of the NAPTR proposal, but I will note that allowing the resolver to use different protocols allows the publisher to pick one suited to their security needs. Finally, note that the NAPTR proposal is targeted for an Experimental RFC, not a proposed standard. Using it, along with the capabilities of DNSSEC, allows those who care to gain experience with operating "secure" resolvers. That experience can then be used when it comes time to evaluate the security tools provided by standards-track URN resolution proposals. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id HAA01194 for urn-ietf-out; Thu, 17 Oct 1996 07:57:37 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id HAA01189 for ; Thu, 17 Oct 1996 07:57:34 -0400 Received: from weeble.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23440 (mail destined for urn-ietf@services.bunyip.com); Thu, 17 Oct 96 07:55:11 -0400 Received: from jon by weeble.lut.ac.uk with smtp (Exim 0.55 #1) id E0vDqy3-0005QF-00; Thu, 17 Oct 1996 12:50:27 +0100 Date: Thu, 17 Oct 1996 12:50:26 +0100 (BST) From: Jon Knight X-Sender: jon@weeble.lut.ac.uk To: Larry Masinter Cc: liberte@ncsa.uiuc.edu, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] a possible security architecture for URNs In-Reply-To: <96Oct17.022129pdt."2771"@golden.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Jon Knight Errors-To: owner-urn-ietf@bunyip.com On Thu, 17 Oct 1996, Larry Masinter wrote: > I want to be able to transition from > > Herman Melville's Moby Dick > to > LOC's Herman Melville's Moby Dick > or > OCLC's Herman Melville's Moby Dick > > The naming scheme in SDSI not only allows relative names, but some way > of merging the trees (or not, as you choose). Er, but surely these are just different instances (locations) of the same resource? So the URN will return a number of pointers to possible resources? Or am I misunderstanding what you mean? > As long as you have a completely global name space, you don't have a > way to talk about migration. By adding relative paths and later > identity, you can deal with migration by asserting that there are some > authorities YOU are willing to trust to assert name bindings for other > entities who are no longer in the name binding game. I don't understand this at all, and I've just read the Rivest and Lampson paper from top to tail. As far as I can see, all you get from their scheme's _naming_ technique (as distinct from their security architecture) that is different from a NAPTR style URN is the ability to refer to things as relative to yourself. This doesn't appear to be too useful as if you distribute this name widely, people will either have to be given it in a global form or be told where you are in the global scheme of things and how your local namespace works. You can't use somebody else's relative names without either having their principle name in your local namespace or just using their global name rooted at one of the special root names (Rivest and Lampson explicitly point this out in the paper, "The principal you call alice-smith may be different from the principal I call alice-smith.". So putting just "alice-smith" in a the bibliography of another document wouldn't be much use to anyone bar the creator). In fact, I'd say that they just describe a "LISPy" way of making a user interface allowing short cuts for commonly used parts of global namespaces. As they specifically say that their object names are just Octet strings, there's no reason why you couldn't use their security structure with the currently defined URN naming schemes. Cool, a ready made security architecture that will work with URNs and that's been written by crypto big boys for free. But I've probably misunderstood it all. Tatty bye, Jim'll -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA29923 for urn-ietf-out; Thu, 17 Oct 1996 05:21:48 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA29918 for ; Thu, 17 Oct 1996 05:21:46 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22903 (mail destined for urn-ietf@services.bunyip.com); Thu, 17 Oct 96 05:21:44 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <14941(5)>; Thu, 17 Oct 1996 02:21:41 PDT Received: by golden.parc.xerox.com id <2771>; Thu, 17 Oct 1996 02:21:29 PDT To: liberte@ncsa.uiuc.edu Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com In-Reply-To: <199610162154.QAA08668@ncsa.uiuc.edu> (message from Daniel LaLiberte on Wed, 16 Oct 1996 14:54:11 PDT) Subject: Re: [URN] a possible security architecture for URNs From: Larry Masinter Message-Id: <96Oct17.022129pdt."2771"@golden.parc.xerox.com> Date: Thu, 17 Oct 1996 02:21:29 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com I want to be able to transition from Herman Melville's Moby Dick to LOC's Herman Melville's Moby Dick or OCLC's Herman Melville's Moby Dick The naming scheme in SDSI not only allows relative names, but some way of merging the trees (or not, as you choose). As long as you have a completely global name space, you don't have a way to talk about migration. By adding relative paths and later identity, you can deal with migration by asserting that there are some authorities YOU are willing to trust to assert name bindings for other entities who are no longer in the name binding game. > I don't see how they have thought it out any more than we have. > What are we missing? I think 'thought' is the wrong term. They've 'written' it out more than you have. The Rivest & Lampson paper at least a *sketch* of how authority and naming and delegation might work, while the best we get from NAPTR is a hand-wave and protests that security isn't important because it might be expensive to implement. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA21492 for urn-ietf-out; Wed, 16 Oct 1996 17:58:44 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA21487 for ; Wed, 16 Oct 1996 17:58:42 -0400 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18868 (mail destined for urn-ietf@services.bunyip.com); Wed, 16 Oct 96 17:58:39 -0400 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id QAA08668; Wed, 16 Oct 1996 16:54:11 -0500 (CDT) Date: Wed, 16 Oct 1996 16:54:11 -0500 (CDT) From: Daniel LaLiberte Message-Id: <199610162154.QAA08668@ncsa.uiuc.edu> To: Larry Masinter Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] a possible security architecture for URNs In-Reply-To: <96Oct16.141925pdt."2764"@golden.parc.xerox.com> References: <2.2.32.19961015164822.006c4494@acl.lanl.gov> <96Oct16.141925pdt."2764"@golden.parc.xerox.com> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Larry Masinter writes: > > Linked local name spaces. SDSI does not utilize a global name > > space, Don't be fooled by that statement. They do utilize a global name space, as they later admit. > With this background, we come to the part that I think represents a > viable URN framework for uniform universal names that can be > implemented in a distributed resolution framework with adequate > security: > > > Accomodation for ``standard roots'' and global name spaces: We recognize > > that there are likely to be a set of standard ``special root'' principals > > that are ``universally'' recognized. These principals have SDSI reserved > > names ending with double exclamation marks (!!): > > > VeriSign!! > > IAPR!! > > USPS!! > > DNS!! > > > There will be very few of these special roots, and their names > > are bound to the same principal in every name space. That's the only way to get a global name space with the same meaning for everyone, as I have been arguing all along. > > This is > > arranged with suitable procedures (appropriate publicity, manual > > installation, cross-checking, etc.); we do not try to describe > > this in more detail. This gives SDSI access to ``standard'' name > > spaces: > > > VeriSign!!'s MicroSoft's Encarta-Division's Susan-Smith > > DNS!!'s edu's mit's lcs's theory's Silvio-Micali > > USPS!!'s USA's DOD's DCI > > IAPR!!'s PCA-commerce's DEC's SRC's abadi > > VeriSign!!'s Visa's account-234156742 > > > Each of these should be viewed as global names that evaluates to > > the same principal in every name space, since the first name > > (e.g. VeriSign!!) always evaluates to the same principal, and all > > of the subsequent names are relative. > > > Although SDSI provides for special roots within a set of linked > > name spaces, this does not imply that each principal has a unique > > ``global name.'' A principal will have multiple global names if > > there are multiple paths from special roots to that > > principal. Thus, > > > VeriSign!!'s MicroSoft's CEO > > DNS!!'s com's microsoft's "Bill Gates" > > > may refer to the same principal. (Of course, one can check > > whether these two names evaluate to give the same public key, if > > one wishes.) This is all fine. But how is it any different architecturally from the path scheme and the NAPTR scheme? All are hierarchical, and within each nested name space, local names can be defined to map to another name space. So we could use path:/DNS!!/com/microsoft/"Bill Gates" The NAPTR scheme is much the same with a different notation and resolution mechanism. > I hope this clarifies what I was asking people to "check out", namely: > a system of hierarchical naming where the issues of identity and > authority have been actually thought out. I don't see how they have thought it out any more than we have. What are we missing? -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA21424 for urn-ietf-out; Wed, 16 Oct 1996 17:56:27 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA21418 for ; Wed, 16 Oct 1996 17:56:22 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18822 (mail destined for urn-ietf@services.bunyip.com); Wed, 16 Oct 96 17:56:12 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id PAA10831; Wed, 16 Oct 1996 15:56:03 -0600 (MDT) Message-Id: <2.2.32.19961016220329.0070707c@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 16 Oct 1996 16:03:29 -0600 To: Larry Masinter From: Ron Daniel Subject: Re: [URN] a possible security architecture for URNs Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Larry Masinter (at least at 02:19 PM 10/16/96 PDT) >Ron, I think I might not have been clear about what part of that >document I thought you should check out. It isn't the particular >security mechanism that I was pointing to, but rather to the naming >method that was contained within the paper that had the important >property that it ALLOWED a security structure to be built that >accomodated it. What I found most compelling was how the authors had >thought through the issues of naming authority. Ah, sorry for the misunderstanding. I will take another look at the naming ideas in the paper. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA21316 for urn-ietf-out; Wed, 16 Oct 1996 17:51:20 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA21311 for ; Wed, 16 Oct 1996 17:50:47 -0400 Received: from aun.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18757 (mail destined for urn-ietf@services.bunyip.com); Wed, 16 Oct 96 17:50:45 -0400 Received: from dale.uninett.no (actually trhm4.or.uninett.no) by aun.uninett.no with SMTP (PP); Wed, 16 Oct 1996 23:50:07 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id VAA08661; Wed, 16 Oct 1996 21:52:29 +0200 From: Harald.T.Alvestrand@uninett.no To: Ron Daniel Cc: Larry Masinter , urn-ietf@bunyip.com Subject: Re: [URN] a possible security architecture for URNs In-Reply-To: Your message of "Tue, 15 Oct 1996 10:48:22 MDT." <2.2.32.19961015164822.006c4494@acl.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <8657.845495546.1@dale.uninett.no> Date: Wed, 16 Oct 1996 21:52:27 +0200 Message-Id: <8659.845495547@dale.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com Just a brief note.... the TIS DNSSEC implementation is released with an "all but Cuba" style export license. You can get an RSAREF workalike from Europe and run it anywhere in the world (except Cuba and so on). So code (beta) for secure DNS exists. Harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA21007 for urn-ietf-out; Wed, 16 Oct 1996 17:27:33 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA21002 for ; Wed, 16 Oct 1996 17:27:30 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18288 (mail destined for urn-ietf@services.bunyip.com); Wed, 16 Oct 96 17:27:24 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <15662(2)>; Wed, 16 Oct 1996 14:23:50 PDT Received: by golden.parc.xerox.com id <2764>; Wed, 16 Oct 1996 14:19:25 PDT To: rdaniel@acl.lanl.gov Cc: urn-ietf@bunyip.com In-Reply-To: <2.2.32.19961015164822.006c4494@acl.lanl.gov> (message from Ron Daniel on Tue, 15 Oct 1996 09:48:22 PDT) Subject: Re: [URN] a possible security architecture for URNs From: Larry Masinter Message-Id: <96Oct16.141925pdt."2764"@golden.parc.xerox.com> Date: Wed, 16 Oct 1996 14:19:25 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com >Thus spoke Larry Masinter (at least at 01:01 AM 10/15/96 PDT) >>Check out >>Rivest & Lampson, "A Simple Distributed Security Infrastructure" >> http://theory.lcs.mit.edu/~rivest/sdsi10.html > Thanks for the citation. The paper is interesting. Unfortunately, > we (the URN-WG) are not competent to judge the merits of this > proposal relative to the SPKI work already going on in the IETF. Ron, I think I might not have been clear about what part of that document I thought you should check out. It isn't the particular security mechanism that I was pointing to, but rather to the naming method that was contained within the paper that had the important property that it ALLOWED a security structure to be built that accomodated it. What I found most compelling was how the authors had thought through the issues of naming authority. Let me excerpt the 'naming' part of the Rivest & Lampson paper, so that it's clear that I'm talking about naming and not 'security' when I say that this is an important paper to read: > Egalitarian design-no global hierarchy necessary. Our proposal is > egalitarian: each principal can make (signed) statements and requests on the > same basis as any other principal. No hierarchical global infrastructure is > required. Of course, in practice some principals would be more important > than others, and SDSI allows for some principals to have special status as > ``special roots,'' allowing SDSI to accomodate ``global names.'' But that is > for convenience rather than necessity. URNs are 'global names'. Any URN framework should clearly lay out how the authority for naming gets delegated to sub-authorities in a way that accomodates a wide variety of real world situations. The current URN proposals lack the kind of flexibility that is contained in the Rivest & Lampson document; that Rivest & Lampson have also laid out a way in which authorization and name resolution can be distributed in a trusted way is just an additional reason to pay attention to their proposal. > Local name spaces. Each principal can create his own local names with which > he can refer to other principals. These local names arbitrarily chosen; they > may be derived from nicknames, email addresses, account numbers, etc.: > jim > "Bob Jones, Jr." > account-314568901387 > WebCo-Vice-President-John-Smith > joe@penguin.lcs.mit.edu > ( Accounting Bob-Smith ) >There is no fixed ``global'' name space giving a unique name for principals. >The principal you call alice-smith may be different from the principal I >call alice-smith. An exception is made for a small set of ``special root'' >principals, whom everyone calls by the same name. Just as URLs needed "relative URLs", I think that this is an important element of a global naming system. And the 'special root' principals are indeed the top level of the URN hierarcies. ... > Linked local name spaces. SDSI does not utilize a global name space, but > rather provides means for conveniently linking local name spaces. Each > principal can ``export'' his name/value bindings to others, by issuing > name/value certificates. Thus, if my local name bob refers to some > principal, then I can refer to the principal that bob calls alice as > ( ref: bob alice ) . > We suggest that the user interface supply a bit of syntactic sugar to > represent this as > bob's alice ... > One can also have longer references, such as > bob's alice's mother , > which is the syntactically sugared version of > ( ref: bob alice mother ) . > This reference is well-defined (for me) if I have bound bob to some > principal, who in turn has bound alice to some second principal, who in turn > has bound mother to some third principal. Other examples of extended > references (with syntactic sugar) are: > Visa's account-314568901387 > mit's lcs's rivest > cmu's eecs-dept's search-committee's chairman > GE's lighting-division's vp-of-marketing's secretary's assistant ... With this background, we come to the part that I think represents a viable URN framework for uniform universal names that can be implemented in a distributed resolution framework with adequate security: > Accomodation for ``standard roots'' and global name spaces: We recognize > that there are likely to be a set of standard ``special root'' principals > that are ``universally'' recognized. These principals have SDSI reserved > names ending with double exclamation marks (!!): > VeriSign!! > IAPR!! > USPS!! > DNS!! > There will be very few of these special roots, and their names are bound to > the same principal in every name space. This is arranged with suitable > procedures (appropriate publicity, manual installation, cross-checking, > etc.); we do not try to describe this in more detail. This gives SDSI access > to ``standard'' name spaces: > VeriSign!!'s MicroSoft's Encarta-Division's Susan-Smith > DNS!!'s edu's mit's lcs's theory's Silvio-Micali > USPS!!'s USA's DOD's DCI > IAPR!!'s PCA-commerce's DEC's SRC's abadi > VeriSign!!'s Visa's account-234156742 > Each of these should be viewed as global names that evaluates to the same > principal in every name space, since the first name (e.g. VeriSign!!) always > evaluates to the same principal, and all of the subsequent names are > relative. > Although SDSI provides for special roots within a set of linked name spaces, > this does not imply that each principal has a unique ``global name.'' A > principal will have multiple global names if there are multiple paths from > special roots to that principal. Thus, > VeriSign!!'s MicroSoft's CEO > DNS!!'s com's microsoft's "Bill Gates" > may refer to the same principal. (Of course, one can check whether these two > names evaluate to give the same public key, if one wishes.) > DNS names have a special status. By special dispensation from its designers, > SDSI includes custom treatment for DNS (Internet email) names, so that > Bob.Smith@penguin.microsoft.com > is equivalent to: > DNS!!'s com's microsoft's penguin's Bob.Smith > -that is, to: > ( ref: DNS!! com microsoft penguin Bob.Smith ) . > How this works is described later on. I hope this clarifies what I was asking people to "check out", namely: a system of hierarchical naming where the issues of identity and authority have been actually thought out. I'll respond to other points in your message separately. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA15907 for urn-ietf-out; Wed, 16 Oct 1996 13:10:06 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA15902 for ; Wed, 16 Oct 1996 13:10:01 -0400 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15261 (mail destined for urn-ietf@services.bunyip.com); Wed, 16 Oct 96 13:09:56 -0400 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01096-0@josef.ifi.unizh.ch>; Wed, 16 Oct 1996 19:09:52 +0100 Subject: Re: [URN] Internationalization! To: masinter@parc.xerox.com Date: Wed, 16 Oct 1996 19:09:51 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: <96Oct12.233126pdt."2765"@golden.parc.xerox.com> from "Larry Masinter" at Oct 12, 96 11:31:26 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5564 From: Martin J Duerst Message-Id: <"josef.ifi..001:16.09.96.18.09.52"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com When I received the anoucement for the new URN mailing list some time ago, I thought that one point would definitely turn up, namely internationalization. I had this expectation because in an earlier discussion on the uri mailing list, I was told that I came at a bad time, but that this could be dealt with with URNs. After following the discussion for some time, I realized that a lot of issues have come up, but internationalization was never mentionned. This is not a good sign, and I want to change it herewith. Internationalization, for those that don't know it, means support for different scripts and languages as they are used around the world. Internationalization is often abbreviated I18N. Why is internationalization of URLs and URNs an issue? - In some cases, URL/N contents is per definition international. Think about a query to a Japanese->English dictionary server. - In some cases, resource locations (e.g. file names) contain non-ASCII characters. On some OSs, there is absolutely nothing strange about such things. - Many names of resources (think about book titles) are inherently in various languages. - Company names, product names, and so on, are much better known to local users in their local form. It is tedious and error-prone, and maybe very difficult, to remember the ascii equivalent. Why are URNs affected? - URNs advertise such things as grandfathering of namespaces. Maybe grandfathering could be a mechanism to deal with some internationalization issues. - URNs are names. Names are intrinsically meaningful, and therefore need internationalization to be meaningful in the right context. - URNs look a lot like URLs, so they may be affected in the same way as URLs by internationalization issues. - Time is now. The earlier the direction for URL/N i18n is established, the easier it is to make it work consistently, and the less legacy issues have to be dealt with. - Internationalization is an important issue in general, and not considering it nowadays is definitely not good practice. What people might say agaist the internationalization of URL/Ns, but is just not true: - International URL/Ns create ambiguity. The ambiguity is about the same as with 0/O or 1/l/I. - URL/Ns are just like phone numbers. Even for phone numbers, people try to create easy ways to remember them. And even if 99% of the URL/Ns are like phone numbers, not designed to be understod by any human reader, it's the rest of 1% that is important. - Everybody should be able to type in an URL/N, everywhere. A lot of people have problems to type standard URLs on their keyboards because they are not used to the Latin alphabet. And does it matter whether you can type an URL/N, if you can't understand the contents of the resource it is pointing to anyway? If you understand the URL/N, but can't type it at the place you are, web servers can easily be constructed that provide such an input service. And finally, the information providers will be mature enough to decide what their audience prefers. What are the problems for URL/N internationalization? - Decide on character encoding and semantics. URLs currently allow to represent arbitrary octets (bytes). An octet 01000010 is represented as "B", an octet 10001111 is represented as "%8F". Nothing in the URL spec says clearly that a "B" in an URL is actually supposed to mean a "B" in a context where one could ask what character that octet is representing (this means in almost all contexts, except e.g. for the data: URL). Hovewer, in fact the situation is much different for the "B" and the "%8F". The "B" is, although the spec does not require it, always just a "B". And the character "B" never turns up in another form in an URL than as a "B". For the "%8F", however, things are completely different. There is no standard or custom whatsoever saying what character (or part of a character) the octet represented by "%8F" could or should be, or by which octet or octets certain characters should be encoded. To some degree, such octets are used to denote some i18n characters, but if this works, it is only due to a lot of assumptions and guesswork on both client and server side. Some proposals tried to encode the relation between characters and octets as part of the URL itself (e.g. aka RFC 1522), which lead to very clumsy syntax and lots of other problems (esp. where exactly to put it and what it should apply to). An IMHO much better solution is to use an uniform encoding. Using UNicode/ISO 10646 and UTF-8, this could be done in a clear fashion, without affecting any ASCII URL/Ns, with large reserves for the future (2 Giga codepoints!), and with lots of other benefits. - Specify in which cases which notation is to be used. E.g. on paper: International notation or %HH notation if unavoidable, on the line: preferably raw UTF-8, but %HH if a protocol prefers it,... - Recommend ways for upgrades for the various schemes/ protocols. - Encourage browser and server implementors to go on with it. Anyway, this is just a first mail to make you aware of the issues. I look forward to an interesting and fruitful discussion. Regards, Martin. ---- Dr.sc. Martin J. Du"rst ' , . p y f g c R l / = Institut fu"r Informatik a o e U i D h T n S - der Universita"t Zu"rich ; q j k x b m w v z Winterthurerstrasse 190 (the Dvorak keyboard) CH-8057 Zu"rich-Irchel Tel: +41 1 257 43 16 S w i t z e r l a n d Fax: +41 1 363 00 35 Email: mduerst@ifi.unizh.ch ---- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA14527 for urn-ietf-out; Wed, 16 Oct 1996 11:48:51 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA14517 for ; Wed, 16 Oct 1996 11:48:16 -0400 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14265 (mail destined for urn-ietf@services.bunyip.com); Wed, 16 Oct 96 11:48:14 -0400 Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id IAA02764; Wed, 16 Oct 1996 08:46:42 -0700 (PDT) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id IAA19439; Wed, 16 Oct 1996 08:47:05 -0700 (PDT) Date: Wed, 16 Oct 1996 08:47:05 -0700 (PDT) From: Terry Allen Message-Id: <199610161547.IAA19439@ishtar.fsc.fujitsu.com> To: masinter@parc.xerox.com, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] a possible security architecture for URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com I agree with Ron that security is not our concern at this point. And I say again that all matters related to security, authority, and the like related to URNs will be determined by lawyers and the world's legal systems. Nothing we could do or write would have the least effect on the outcome. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA00547 for urn-ietf-out; Tue, 15 Oct 1996 12:41:27 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA00542 for ; Tue, 15 Oct 1996 12:41:23 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA05733 (mail destined for urn-ietf@services.bunyip.com); Tue, 15 Oct 96 12:41:19 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA21184; Tue, 15 Oct 1996 10:40:52 -0600 (MDT) Message-Id: <2.2.32.19961015164822.006c4494@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 15 Oct 1996 10:48:22 -0600 To: Larry Masinter , urn-ietf@bunyip.com From: Ron Daniel Subject: Re: [URN] a possible security architecture for URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Larry Masinter (at least at 01:01 AM 10/15/96 PDT) >Check out >Rivest & Lampson, "A Simple Distributed Security Infrastructure" > http://theory.lcs.mit.edu/~rivest/sdsi10.html Thanks for the citation. The paper is interesting. Unfortunately, we (the URN-WG) are not competent to judge the merits of this proposal relative to the SPKI work already going on in the IETF. Larry has raised the issue of security in a few different places: first he said that the lack of security and administration tools in DNS made NAPTRs unacceptable, later he made a similar criticism of the framework. However, the URN requirements draft does not mandate that any particular level of security must be provided. That RFC says: "...there are several issues dealing with support for replication of resources and security that have been discussed; however, the problems are not well enough understood at this time to include specific requirements in those areas here." I am unaware of any changes to that status. Security has its costs. While it would be nice to have URN resolution systems that met a requirements statement like: URN resolution systems shall be invulnerable to forged responses, shall ensure that only authorized accesses are possible, shall provide for the complete confidentiality of the resource, and shall be immune to traffic analysis and denial of service attacks" who is going to pay for such high levels of security? Such measures are not appropriate for all the resources people will identify with URNs. My contention is that such objections should not slow the NAPTR draft from going to experimental status. Here are my reasons: 1) As shown above, the URN requirements RFC has no requirement for security. This was not an oversight, it was because we were not ready to impose security requirements on all URN systems. 2) Experimental RFCs are not standards-track documents. The goal is to gain experience with a new protocol with the explicit understanding that it is an experiment and may never go to the standards track. We actually have some useful things to learn from NAPTRs. URNs are supposed to be long-lived, location-independent identifiers. The NAPTR draft gives us a way to look at location independence in action. Michael has mentioned on this list that he is working on an rwhois-based alternative to NAPTRs. He has stated to me that he would like to see NAPTRs deployed and running so that he can learn from that system while he continues to develop his. Experimental status seems perfectly appropriate for this purpose. 3) While it is easy to ask for security, it is hard to deploy. The DNSSEC work is actually rather far along. The main impediment to further progress appears to be the difficulty in fielding implementations. This difficulty is due to export control issues surrounding the crypto code, and is a difficulty that *any* resolution system with strong security would face. Allowing the NAPTR draft to procede as an Experimental RFC will let us get the operational experiance with resource replication that the URN Requirements RFC says we need. The possibility also exists that the export control problems associated with DNSSEC will be overcome during the experimental period. We can then experiment with the SIG resource record and gain experience with the security issues that the requirents document says we need. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA25270 for urn-ietf-out; Tue, 15 Oct 1996 04:01:50 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA25265 for ; Tue, 15 Oct 1996 04:01:48 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02362 (mail destined for urn-ietf@services.bunyip.com); Tue, 15 Oct 96 04:01:16 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <17873(6)>; Tue, 15 Oct 1996 01:01:12 PDT Received: by golden.parc.xerox.com id <2760>; Tue, 15 Oct 1996 01:01:08 PDT To: urn-ietf@bunyip.com Subject: [URN] a possible security architecture for URNs From: Larry Masinter Message-Id: <96Oct15.010108pdt."2760"@golden.parc.xerox.com> Date: Tue, 15 Oct 1996 01:01:08 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com Check out Rivest & Lampson, "A Simple Distributed Security Infrastructure" http://theory.lcs.mit.edu/~rivest/sdsi10.html for a proposal for security of name bindings that allows for delegation. It may be that the only way to have both secure and long-lived names is by resorting to an authority that asserts name-bindings where the authority has a longer lifetime than the binding, e.g., LOC's Melville's MobyDick With a suitable syntax, there's even a place for 'relative URNs'. Regards, Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id CAA28362 for urn-ietf-out; Sun, 13 Oct 1996 02:32:21 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id CAA28357 for ; Sun, 13 Oct 1996 02:32:14 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22597 (mail destined for urn-ietf@services.bunyip.com); Sun, 13 Oct 96 02:31:41 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <15369(5)>; Sat, 12 Oct 1996 23:31:37 PDT Received: by golden.parc.xerox.com id <2765>; Sat, 12 Oct 1996 23:31:26 PDT To: urn-ietf@bunyip.com Subject: [URN] suggestions for "A Framework for the Assignment and Resolution ..." From: Larry Masinter Message-Id: <96Oct12.233126pdt."2765"@golden.parc.xerox.com> Date: Sat, 12 Oct 1996 23:31:26 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com We were asked to keep the discussion of 'NAPTR vs PURL' offline, and keep the mailing list focused on the framework document. The Framework document needs references; clearly, after such a very long period of discussions of what URNs are and are not, it would help to distinguish this framework from, say, the approaches of Winograd, "Stable Network File URLs as a Mechanism for Uniform Naming", 1993: Kahn & Wilensky, "A Framework for Distributed Digital Object Services", cnri.dlib/tn95-01, or even mention the background in Arms et al, "Uniform Resource Names", D-Lib Magazine, February 1996, even though almost all of the authors of that article are listed in the framework acknowledgements. The framework document has a section labeled "Authority Over Name Strings", but the section doesn't actually go into any details about the difficult elements of name migration. It says "Rules for individual namespaces are determined by the owners of the namespace before they are registered in the NID registry", but this kind of analysis omits the important element of what omits any mention of the difficult problems that arise when namespace owners themselves disappear. This is a rather old song, but I will sing it again: draft-daigle-urnframework-00.txt is inadequate because it does not deal with any of the issues of administration & security & migration & longevity that are the entire motivation for having 'URNs' instead of 'URLs'. You might argue that those issues are social issues and not technical ones, and that this is an engineering group, not a social policy group. However, engineering solutions are often advanced as solutions to social policy questions. For example, for better or worse, several mechanisms for 'key recovery' have been advanced as an engineering solution to the social policy question of balancing between police investigative capabilities and personal privacy. Those same mechanisms might be used, for example, as a way of allowing the 'owner' of a name to have the exclusive right to assign metadata or location information by signing such assignments with the owner's private key, but also allowing the infrastructure to recover when an owner disappears or is unresponsive by resorting to some form of key recovery or delegation. I don't think the framework needs to specify the mechanism by which an name's authority might assert a relationship between the name and various pieces of metadata and location information, but the nature of the assertions made, the roles of third parties in either verifying the assertions or providing clients the means of verifying, the ways in which authority can either migrate to different organizations or be supplanted by the moral equivalent of "trusted librarians" needs to be addressed in far more detail than appears here. Regards, Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA26568 for urn-ietf-out; Thu, 10 Oct 1996 23:43:35 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA26563 for ; Thu, 10 Oct 1996 23:43:29 -0400 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11829 (mail destined for urn-ietf@services.bunyip.com); Thu, 10 Oct 96 23:43:27 -0400 Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id UAA20531; Thu, 10 Oct 1996 20:41:56 -0700 (PDT) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id UAA10936; Thu, 10 Oct 1996 20:42:25 -0700 (PDT) Date: Thu, 10 Oct 1996 20:42:25 -0700 (PDT) From: Terry Allen Message-Id: <199610110342.UAA10936@ishtar.fsc.fujitsu.com> To: masinter@parc.xerox.com, rdaniel@acl.lanl.gov Cc: michaelm@internic.net, urn-ietf@bunyip.com Subject: Re: [URN] advantages of NAPTR over PURLs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Larry: | NAPTR suddenly | intertwines name resolution with one of the most obscure parts of the | Internet infrastructure. Only *one means* of URN (not URL) resolution. NAPTR is not obviously the one shiningly best means of URN resolution, but PURLs very obviously are not (if, for example, you have a business disagreement with OCLC). I don't *have* to use NAPTR to resolve URNs, and in a well developed landscape I'll have other choices. Some URNs may never be resolved through NAPTR. But with PURLs I'm chained to purl.org. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA26435 for urn-ietf-out; Thu, 10 Oct 1996 23:33:03 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA26430 for ; Thu, 10 Oct 1996 23:32:55 -0400 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11786 (mail destined for urn-ietf@services.bunyip.com); Thu, 10 Oct 96 23:32:52 -0400 Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id UAA20394; Thu, 10 Oct 1996 20:31:20 -0700 (PDT) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id UAA10769; Thu, 10 Oct 1996 20:31:38 -0700 (PDT) Date: Thu, 10 Oct 1996 20:31:38 -0700 (PDT) From: Terry Allen Message-Id: <199610110331.UAA10769@ishtar.fsc.fujitsu.com> To: masinter@parc.xerox.com, tallen@fsc.fujitsu.com Cc: michaelm@internic.net, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] advantages of NAPTR over PURLs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Yes, your quotation supports entirely my claim that PURLs are not an implementation of URNs. Please make the following thought experiment: Write a sentence using a URN, then the same using a PURL. Imagine that 20 years hence, urn.net and purl.org have gone away. With URNs: "Foobar says blort in blart:baz/far/bomb." With PURLs: "Foobar says blort in [something pointed to by the HTTP URL <...>]." I can have some hope of still resolving the URN, because, Larry, it's a name; I have little hope of resolving the ancient reference to a reference that no longer exists, because it's a pointer, and not a name. I still have a sentence that makes sense in the first case, whereas in the second I have a sentence with a blank waiting to be filled in. PURLs are "item number 32 on page 153 of K's manuscript catalogue of Mozart's works." URNs are "K. 459". URNs do not require resolution by the naming authority. That's the point here. >From masinter@parc.xerox.com Wed Oct 9 18:59 PDT 1996 To: tallen@fsc.fujitsu.com CC: michaelm@internic.net, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] advantages of NAPTR over PURLs From: Larry Masinter Date: Wed, 9 Oct 1996 18:59:34 PDT > But PURLs are not an implementation of URNs... Please review http://purl.oclc.org/OCLC/PURL/INET96 : > PURLs are a direct result of OCLC's work in the Uniform Resource Name > (URN) standards and library cataloging communities. The assignment of > PURLs is an intermediate step towards the time when URNs are an > integral part of the Internet information architecture. The eventual > syntax of URNs is clear enough at this time to afford confidence that > the syntax of PURLs can be inexpensively and mechanically translated > to the eventual URN form. For instance, the PURL > http://purl.oclc.org/keith/home > ---- ------------- ---------- > / | \ > protocol resolver address name > could be written something like the following using the Path URN syntax: > URN:/org/oclc/purl/keith/home > ------------- ---------- > | | > naming authority name > where the URN is essentially a hierarchical name with the first > portion representing the naming authority and the second portion > signifying the local name. Note that the naming authority in this > example is merely the resolver address of the corresponding PURL > written backwards (with slashes instead of dots) and the local name > is the same. > Syntax aside, one way to think of URNs and PURLs is to consider what > it would take to turn a PURL Server into a URN Server: very > little. If Web browsers were changed to recognize the syntax > URN:/org/oclc/purl/keith/home and could then connect to the resolver > at purl.oclc.org, the resolver could then resolve the name > /keith/home. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA12118 for urn-ietf-out; Thu, 10 Oct 1996 08:20:11 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA12113 for ; Thu, 10 Oct 1996 08:20:09 -0400 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03649 (mail destined for urn-ietf@services.bunyip.com); Thu, 10 Oct 96 08:20:08 -0400 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id IAA03411 for urn-ietf@bunyip.com; Thu, 10 Oct 1996 08:20:07 -0400 Message-Id: <199610101220.IAA03411@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Thu, 10 Oct 1996 08:20:07 -0400 In-Reply-To: Larry Masinter's message as of Oct 9, 19:16 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: urn-ietf@bunyip.com Subject: [WGC] Re: [URN] advantages of NAPTR over PURLs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Okay, I think this thread is starting to lose its focus. It started off using PURLs as an example to illustrate areas of the Framework that need to be better documented. A lot of good material has been generated on that front. But, as it has aged, it seems to have taken on more of the characteristics of a debate about which "is better" -- PURLs or NAPTR-based URNs. In fact, that's not what we are here to discuss. We have on the table a proposed approach to URNs -- the Framework -- and a first round implementation of a system based on that approach -- NAPTR. We should discuss things to move those forward -- that is what we've been chartered to do. Since it now seems to have reached the stage where there is more about NAPTR-vs-PURL, and less about What should the Framework say, I believe it is time for this thread to be stopped, and material generated thus far will be addressed in a revision of the Framework document. If anyone has specific issues relating to the Framework _document_, that's fine. If people still have things they wish to get off their chests on the subject of PURLs-as-URNs, I would appreciate it very much if they could sort out the details off-line, and bring back to the list whatever is generated in terms of concrete proposals for the Framework. Thanks! Leslie. -- ---------------------------------------------------------------------------- "The light at the end of the tunnel Leslie Daigle is often the blindingly obvious..." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id CAA08991 for urn-ietf-out; Thu, 10 Oct 1996 02:44:09 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id CAA08960 for ; Thu, 10 Oct 1996 02:44:07 -0400 Received: from aun.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02911 (mail destined for urn-ietf@services.bunyip.com); Thu, 10 Oct 96 02:44:05 -0400 Received: from dale.uninett.no by aun.uninett.no with SMTP (PP); Thu, 10 Oct 1996 08:43:54 +0200 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id XAA00794; Wed, 9 Oct 1996 23:54:04 +0200 From: Harald.T.Alvestrand@uninett.no To: Ron Daniel Cc: Larry Masinter , urn-ietf@bunyip.com Subject: Re: [URN] advantages of NAPTR over PURLs In-Reply-To: Your message of "Tue, 08 Oct 1996 14:46:20 MDT." <2.2.32.19961008204620.0069812c@acl.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <789.844898039.1@dale.uninett.no> Date: Wed, 09 Oct 1996 23:54:00 +0200 Message-Id: <791.844898040@dale.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com Ron said: >Both registries should be mentioned in the framework draft. We need a >really good lawyer to look at the language. Anyone know of a likely >candidate who would do it pro-bono? The IETF has a relationship with a law firm (I forget the name) that does pro bono work for us. Once we have language that needs checking, and we're reasonably sure it means what WE want it to say, we can use some of their time for it. The good thing about these guys is that they know us by now, so they kind of know what kinds of trouble we're afraid of. Harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA08570 for urn-ietf-out; Thu, 10 Oct 1996 01:59:10 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA08565 for ; Thu, 10 Oct 1996 01:59:08 -0400 Received: from shell1.aimnet.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02849 (mail destined for urn-ietf@services.bunyip.com); Thu, 10 Oct 96 01:59:06 -0400 Received: (from dwm@localhost) by shell1.aimnet.com (8.7.3/SHELL) id WAA08247; Wed, 9 Oct 1996 22:59:04 -0700 (PDT) Date: Wed, 9 Oct 1996 22:59:02 -0700 (PDT) From: "David W. Morris" X-Sender: dwm@shell1.aimnet.com To: urn-ietf@bunyip.com Subject: Re: [URN] advantages of NAPTR over PURLs In-Reply-To: <96Oct9.223036pdt."2764"@golden.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "David W. Morris" Errors-To: owner-urn-ietf@bunyip.com On Wed, 9 Oct 1996, Larry Masinter wrote: > > One point though: adminisration and security are two things you do AFTER > > you have a system that can scale and function. If you don't have > > something that works then all the security and administration in the > > world won't get you squat. > > This just doesn't hold water. Most of the issues we have to deal with > in 'scalability' are administration and security. We can't design > protocols that way any more. It is completely unacceptable that after > three years of talking about URNs and meeting about URNs that the > first 'URN implementation' doesn't have a credible story about > administration and security. My response was a lot less polite than Larry's. Operational scalability is the whole problem. If we are not to worry about administaration and security, there is no point to URNs ... URLs scale just fine ... but they are hell to administer when one gets down to little issues like persistence. Dave Morris Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA08413 for urn-ietf-out; Thu, 10 Oct 1996 01:31:01 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA08408 for ; Thu, 10 Oct 1996 01:30:58 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02752 (mail destined for urn-ietf@services.bunyip.com); Thu, 10 Oct 96 01:30:56 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16998(4)>; Wed, 9 Oct 1996 22:30:51 PDT Received: by golden.parc.xerox.com id <2764>; Wed, 9 Oct 1996 22:30:36 PDT To: gjw@wnetc.com Cc: michaelm@rwhois.net, michaelm@internic.net, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com In-Reply-To: (gjw@wnetc.com) Subject: Re: [URN] advantages of NAPTR over PURLs From: Larry Masinter Message-Id: <96Oct9.223036pdt."2764"@golden.parc.xerox.com> Date: Wed, 9 Oct 1996 22:30:36 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com > Actually, the fact that the NAPTR proposal uses DNS as part of its > infrastructure doesn't seem to me to be a huge issue. Oh, I think it's the source of most of its problems. If it were in some application protocol rather than DNS -- something that had a reasonable administrative & security model and a distributed implementation that actually dealt with updates -- most of the problems I have with it would go away. > One point though: adminisration and security are two things you do AFTER > you have a system that can scale and function. If you don't have > something that works then all the security and administration in the > world won't get you squat. This just doesn't hold water. Most of the issues we have to deal with in 'scalability' are administration and security. We can't design protocols that way any more. It is completely unacceptable that after three years of talking about URNs and meeting about URNs that the first 'URN implementation' doesn't have a credible story about administration and security. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA05443 for urn-ietf-out; Thu, 10 Oct 1996 00:14:55 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA05438 for ; Thu, 10 Oct 1996 00:14:48 -0400 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02236 (mail destined for urn-ietf@services.bunyip.com); Thu, 10 Oct 96 00:14:46 -0400 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id VAA13920; Wed, 9 Oct 1996 21:14:17 -0700 Date: Wed, 9 Oct 1996 21:14:17 -0700 (PDT) From: "Gregory J. Woodhouse" To: Michael Mealling Cc: Larry Masinter , michaelm@internic.net, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] advantages of NAPTR over PURLs In-Reply-To: <325C6353.474E@rwhois.net> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com Actually, the fact that the NAPTR proposal uses DNS as part of its infrastructure doesn't seem to me to be a huge issue. The reason is that under the NAPTR proposal namespaces are completely abstract, and it would be possible to implement those same namespaces using an entirely different mechanism. In fact, with a judicious use of replication, I don't see why it wouldn't be possible to smoothly transition to a new URN resolution scheme and have the process be completely transparent to users. Of course, this is conceptually possible with PURLs (because http://www.purl.org/* could be treated as an abstract namespace) but it does tie us to namespaces of a rather restrictive form. Incidentally, I find this whole thread rather useful. I had originally planned to give a 1 hour brownbag presentation to some of my co-workers on URNs an the NAPTR proposal. Basically, this would have been part 2 of the DNS class I gave last week. Anyway, it was postponed/cancelled because of other priorities, but preparing for this presentation was an interesting experience. One reason is that I was forced to consider how I would respond to the question: "What is it about this resolution scheme that justifies its complexity?" Of course, I never actually had to answer that question, but I was certainly dreading it. One final comment: I agree that there is no real need for a large number of resolution protocols, but I don't see this as a problem with the NAPTR proposal. Rather, I prefer to think of the proposal as purposely not specifying the actual protocol(s). This doesn't seem to me to be a design flaw, but just the opposite. In general, it i just good software engineering to keep the various components of a system a loosely coupled as possible, and this is just what the proposal does. --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/ resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA05067 for urn-ietf-out; Wed, 9 Oct 1996 23:52:32 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA05062 for ; Wed, 9 Oct 1996 23:52:28 -0400 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02108 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 23:52:26 -0400 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id UAA12211; Wed, 9 Oct 1996 20:51:48 -0700 Date: Wed, 9 Oct 1996 20:51:48 -0700 (PDT) From: "Gregory J. Woodhouse" To: Michael Mealling Cc: Larry Masinter , rdaniel@acl.lanl.gov, michaelm@internic.net, urn-ietf@bunyip.com Subject: Re: [URN] advantages of NAPTR over PURLs In-Reply-To: <325C6EBF.1A1@rwhois.net> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com On Wed, 9 Oct 1996, Michael Mealling wrote: > Larry Masinter wrote: > > > > > Sorry, but SRV records cannot be used for HTTP without changing all > > > implementations of HTTP. The spec would also need to be changed to > > > say if SRV requests or A requests should occur first, because > > > behavior will differ. > > > > Did SMTP implementations change with the introduction of MX records, > > or was it done at some other level? > > Yes. In order to take advantage of MX records ALL implementations of > SMTP had to know to look up that RR instead of just getting the A > record. > Well, mail routing is actually descibed in RFC 974. RFC 821 only describes a single transaction (okay, perhaps a poor choice of words). But on the other hand, if SMTP made the assumption that it was only necesary to give a userename to identify a mail recipient and only used RCPT To: then the MX mechnism could not work without modifying the protocol. --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/ resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA04919 for urn-ietf-out; Wed, 9 Oct 1996 23:30:49 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA04914 for ; Wed, 9 Oct 1996 23:30:46 -0400 Received: from SMTP1.ABRAXIS.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01971 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 23:30:43 -0400 Received: from [206.155.199.8] by smtp1.abraxis.com (NTMail 3.01.03) id na052299; Wed, 9 Oct 1996 23:34:21 -0400 Message-Id: <325C6EBF.1A1@rwhois.net> Date: Wed, 09 Oct 1996 23:35:38 -0400 From: Michael Mealling Organization: Network Solutions X-Mailer: Mozilla 3.0b7 (X11; I; SunOS 5.5 i86pc) Mime-Version: 1.0 To: Larry Masinter Cc: rdaniel@acl.lanl.gov, michaelm@internic.net, urn-ietf@bunyip.com Subject: Re: [URN] advantages of NAPTR over PURLs References: <96Oct9.195703pdt."2759"@golden.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Michael Mealling Errors-To: owner-urn-ietf@bunyip.com Larry Masinter wrote: > > > Sorry, but SRV records cannot be used for HTTP without changing all > > implementations of HTTP. The spec would also need to be changed to > > say if SRV requests or A requests should occur first, because > > behavior will differ. > > Did SMTP implementations change with the introduction of MX records, > or was it done at some other level? Yes. In order to take advantage of MX records ALL implementations of SMTP had to know to look up that RR instead of just getting the A record. > > > You are not talking abut PURLs as set forth by OCLC. You are > > talking about something that is halfway between the original Handle > > proposal and PURLs. The idea of a global resolver (on replicated servers) > > that would handle all resolution requests was the key feature of the > > original Handle proposal. It was found unacceptable for several reasons, > > two of which were: > > 1) Potential for surgical denial of sevice attacks > > You'll have to convince me that NAPTR implementations are less > succeptable than PURL implementations. Why should that be so? There > are still replicated services. Because of two reasons: a) the root doesn't change very often. Therefore it is cacheable and therefore doesn't need to be queried. b) all other queries are to delegated servers. A denial of service attack can take out one but not ALL of those delegated servers. Its very difficult if not impossible to cause all DNS server to just stop working. This does not take into account the possiblity of corrupting the records at the root so that everyone goes down a dead-end path. We hope that DNSSEC will fix that. Or that another protocol will come along that does this job better than DNS. -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA04530 for urn-ietf-out; Wed, 9 Oct 1996 23:03:55 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA04525 for ; Wed, 9 Oct 1996 23:03:53 -0400 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01852 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 23:03:51 -0400 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa08950; 9 Oct 96 23:03 EDT Received: by skadhwe.lcs.mit.edu; (5.65v3.2/1.1.8.2/15Aug95-0306PM) id AA22822; Wed, 9 Oct 1996 23:03:16 -0400 Date: Wed, 9 Oct 1996 23:03:16 -0400 Message-Id: <9610100303.AA22822@skadhwe.lcs.mit.edu> From: Lewis Girod To: rdaniel@acl.lanl.gov Cc: urn-ietf@bunyip.com In-Reply-To: <2.2.32.19961009145007.006ae9ec@acl.lanl.gov> (message from Ron Daniel on Wed, 09 Oct 1996 08:50:07 -0600) Subject: Re: [URN] advantages of NAPTR over PURLs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com Date: Wed, 09 Oct 1996 08:50:07 -0600 From: Ron Daniel [One difference is...] The PURL-like approaches send the entire request, document-id and all, to the root resolver. This allows fun little things like surgical denial of service and usage tracking which tend to get people excited. This is a valid concern, and NAPTR is superior in terms of privacy. However even with NAPTR surgical denial of service is possible (to a limited extent) if a regexp rule upstream of the client misdirects resolution conditionally on matching specific stuff in that client's URNs. And, as you point out, a PURL-type system would make this sort of thing easier and more transparent. NAPTR and PURL resolution are very different. All NAPTR does is get us to a resolver, without requiring that the location of the resolver be buried in the URN or that we have a global resolver that is fixed for all time. PURLs get us to the resolver by putting its location into the identifier. Larry has suggested some modifications to PURLs where we don't put the location of the resolver into the identifier, but everyone knows that purl.org (or whatever) is the place to go to start resolution. It is a question of how much indirection is really necessary... I don't think anyone is proposing to use a PURL-type architecture for eternity. However, it is a simple technique that provides a reasonable amount of indirection and persistence, if it is set up properly. The only location that _must_ appear in a PURL is that of the top-level resolver (or should we say redirector), which in the case of NAPTR is ``buried'' in the browser rather than in the URN. >and if your names were originally delegated from foo.com, >you will probably end up going through foo.com forever, even if the >resolution is actually done by someone else. That depends on the namespace that is used. For namespaces like CID or INET, that is true. For namespaces like ISBN, resolution will probably be accomplished by an organization like Bowker, even if the name was originally assigned by Prentice-Hall. Just out of curiosity, in the case of ISBN, would the initial rule then point directly to Bowker's resolver? It could also be done by pulling out publisher codes, I suppose... - Lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA04260 for urn-ietf-out; Wed, 9 Oct 1996 22:57:23 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA04255 for ; Wed, 9 Oct 1996 22:57:21 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01802 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 22:57:19 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16832(5)>; Wed, 9 Oct 1996 19:57:17 PDT Received: by golden.parc.xerox.com id <2759>; Wed, 9 Oct 1996 19:57:03 PDT To: rdaniel@acl.lanl.gov Cc: michaelm@internic.net, urn-ietf@bunyip.com In-Reply-To: <2.2.32.19961009161808.006a0204@acl.lanl.gov> (message from Ron Daniel on Wed, 9 Oct 1996 09:18:08 PDT) Subject: Re: [URN] advantages of NAPTR over PURLs From: Larry Masinter Message-Id: <96Oct9.195703pdt."2759"@golden.parc.xerox.com> Date: Wed, 9 Oct 1996 19:57:03 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com > Sorry, but SRV records cannot be used for HTTP without changing all > implementations of HTTP. The spec would also need to be changed to > say if SRV requests or A requests should occur first, because > behavior will differ. Did SMTP implementations change with the introduction of MX records, or was it done at some other level? > You are not talking abut PURLs as set forth by OCLC. You are > talking about something that is halfway between the original Handle > proposal and PURLs. The idea of a global resolver (on replicated servers) > that would handle all resolution requests was the key feature of the > original Handle proposal. It was found unacceptable for several reasons, > two of which were: > 1) Potential for surgical denial of sevice attacks You'll have to convince me that NAPTR implementations are less succeptable than PURL implementations. Why should that be so? There are still replicated services. > 2) Organizations such as mine, who cannot put information about > some of our documents into a system that is not cleared for > handling classified work. (Company proprietary information is > an analogous problem). This works with NAPTR? That documents don't need a new name when they get declassified? Or that a company can have a selective release of confidential information on a 'need to know' basis without renaming? > Every time I have heard the OCLC people talk about PURLs, they have > been careful to say that they are not URNs. Their focus was to do as > much as possible without changing client-side code. There are changes and then there are changes. It's one thing to change the protocol that is implemented to open another connection, do an indirection, look in a cache, etc. However, most of HTTP is completely independent of DNS or TCP or even the Internet. NAPTR suddenly intertwines name resolution with one of the most obscure parts of the Internet infrastructure. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA04154 for urn-ietf-out; Wed, 9 Oct 1996 22:46:08 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA04149 for ; Wed, 9 Oct 1996 22:46:06 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01764 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 22:46:04 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16713(1)>; Wed, 9 Oct 1996 19:45:57 PDT Received: by golden.parc.xerox.com id <2764>; Wed, 9 Oct 1996 19:45:40 PDT To: rdaniel@acl.lanl.gov Cc: michaelm@internic.net, urn-ietf@bunyip.com In-Reply-To: <2.2.32.19961009161808.006a0204@acl.lanl.gov> (message from Ron Daniel on Wed, 9 Oct 1996 09:18:08 PDT) Subject: Re: [URN] advantages of NAPTR over PURLs From: Larry Masinter Message-Id: <96Oct9.194540pdt."2764"@golden.parc.xerox.com> Date: Wed, 9 Oct 1996 19:45:40 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com I'm really dismayed though by the amount of narrow defensiveness that's been shown here, though. Every protocol has problems. I certainly don't believe that PURLs actually solve the Internet naming problem. People are acting like I'm saying their puppy is ugly, just because I'm pushing on the NAPTR proposal. > These topics are very young, so nobody has had anything to say on them > yet. How about you? Honestly, I don't think you can really fault me for not being vocal. Earlier in an interchange, someone defended NAPTRs as having been the topic of discussion of many meetings. > Does my suggestion of using the flags field overcome your concern > about versioning? I didn't think you were seriously proposing that the version of NAPTR record elements be restricted to a number between 0 and 9. What happens when you make the 10th revision? > Do you have any further arguments on why a version field should be > needed when we cannot change the number, type, or order of fields in a > DNS record once it is out there? Oh, no! I never suggested that you needed version numbers! My problem was that you were using tokens "dun-and-bradstreet-lookup" without any control on the meaning of the name! > When clients and servers are not required to understand and support all > the N2C, N2L, ... requests? What? Clients don't have to understand what N2C means? Or how to do one? > I assume you have more knowledge of the Z39.50 URL schemes than I, > is my concern about using URL standards-track documents as the > "registry" misplaced? What about an IMT-style registry instead? I don't actually think the world NEEDS a large number of resolution protocols, any more than the world NEEDS a zillion HTML tags. The only reason why we might see all of dun-and-bradstreet-lookup and z39.50 lookup and NAPTR lookup and ISBN-Bowker-lookup is a combination of ignorance ("oh, they already had a protocol?"), vanity ("mine! my protocol!") and greed ("they'll have to either pay me or see my advertising"). Allowing lots of resolution protocols and a registry is really counter-productive. At least there's some REASON why some applications need audio/basic and not image/gif (even though there's no good reason why we need both image/png and image/tiff). Why don't we just fight it out now and save everyone grief later? Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA04118 for urn-ietf-out; Wed, 9 Oct 1996 22:42:45 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA04112 for ; Wed, 9 Oct 1996 22:42:12 -0400 Received: from SMTP1.ABRAXIS.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01754 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 22:42:09 -0400 Received: from [206.155.199.12] by smtp1.abraxis.com (NTMail 3.01.03) id ba052287; Wed, 9 Oct 1996 22:45:54 -0400 Message-Id: <325C6353.474E@rwhois.net> Date: Wed, 09 Oct 1996 22:47:08 -0400 From: Michael Mealling Organization: Network Solutions X-Mailer: Mozilla 3.0b7 (X11; I; SunOS 5.5 i86pc) Mime-Version: 1.0 To: Larry Masinter Cc: michaelm@internic.net, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] advantages of NAPTR over PURLs References: <96Oct9.191647pdt."2759"@golden.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Michael Mealling Errors-To: owner-urn-ietf@bunyip.com Larry Masinter wrote: > > > Do you see where you're going Larry? You are putting everything > > we've already got in the URN framework and the NAPTR proposal > > into PURLs. > > A new NAPTR DNS record type with protocol names & syntax that requires > parsing and interpretation as a 'regular expression' isn't part of the > PURL proposal. Right. PURLs have hidden that 'rule' inside the server where noone but the server knows what it is. Whether that 'rule' is based on a direct mapping from a database or is a rule based on some language that can be generalized isn't the point. It has to be done somewhere. What NAPTR does is make that rule visible to the client so it can cache it. If it never sees that rule it can't cache it. > PURLs don't relegate the security issues to DNS > security but rather rely on HTTP security. But PURLs relegate it to someone. We never said that DNS' security was better than anyone elses. Its rather dismal. But its the easiest thing to implement to right now. > PURLs don't require that > application clients know anything about DNS other than 'Connect me to > some machine that goes by this name'. And that its problem: the client application know nothing. Therefore you have to go to that huge database. > I think that _relying_ on parsing data out of DNS records is very > fragile, and most of purported advantages for NAPTRs are mainly vapor. You suggest a beter system that gives us all of the advantages that NAPTR has over PURLs. > > But you ARE changing the intent and current design of PURLS. > > I think we read different papers about PURLs; the paper I read made it > seem like it was intended as a low-cost implementation of URNs. I read it as a low-cost hack that when URNs are finished can be shoe-horned into the URN proposal. Also that at the time it was talking about URNs as implemented by the PATH scheme which noone is using or is even advocating anymore. (If someone is advocating its use then I apologize for not being aware of it.) > > If you can come up with a DISTRIBUTED database that has is as large > > and as widespread as DNS that we can test the framework on then by all > > means let us know cause we'll build the framework on that too. > > I think this is misleading, since the NAPTR proposal doesn't > distribute resolution services widely. Huh? It distributed resolution services to whatever degree you want. Down to the character level. Back when I was at Tech I was intending on setting up a NAPTR based service that distributed resolution services down to the arbitrary unit level within departments. I could have gone deeper but I let the departments decide that. In any case, your saying that a single replicated PURL database is more or less equally as distributed as DNS? > > > If you've got a problem with NAPTR then you either have a problem > > with the framework or DNS. > > No, I have a problem with THAT particular USE of DNS. Do you have a better solution that fits the framework? > Let me get down to the basics, though: > > DNS updates are unreliable. No argument there! ;-) > DNS administration is a nightmare. No argument there either! ;-) > The PURL proposal has worked out many of the issues of administration and > security that are necessary for actual deployment of URNs, Because its based on a single database on a single machine. I could build adminstrative tools on that fairly easily. On a system like that with one point of update it should be fairly easy to have secure updates. I'm actually kind of dissapointed that they aren't using SSL for secure updates on their web pages..... One point though: adminisration and security are two things you do AFTER you have a system that can scale and function. If you don't have something that works then all the security and administration in the world won't get you squat. > and the NAPTR proposal has only a wave at DNSSEC. DNS security is the business of another working group. What would you have us do? Override them and implement our own security? > > I hope that won't be the case very soon. I'm building a > > parallel registry in rwhois. It doesn't have the restrictions > > that DNS does. Its more generalized and doesn't need to > > be re-written everytime you add a field. > > That's great! If you're building a parallel registry in rwhois, I hope > that you address the administrative and update issues that were worked > out in the PURL paper and that we can leave NAPTR behind. Actually, ours are better. We have complete security for on the fly updates. If you can put up with the security and management issues that the InterNic has to put with then you should be happy with what we have. -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@rwhois.net Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA03937 for urn-ietf-out; Wed, 9 Oct 1996 22:17:01 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA03932 for ; Wed, 9 Oct 1996 22:16:58 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01697 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 22:16:56 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16731(4)>; Wed, 9 Oct 1996 19:16:54 PDT Received: by golden.parc.xerox.com id <2759>; Wed, 9 Oct 1996 19:16:47 PDT To: michaelm@internic.net Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com In-Reply-To: <325BB8BC.1248@internic.net> (message from Michael Mealling on Wed, 9 Oct 1996 07:37:48 PDT) Subject: Re: [URN] advantages of NAPTR over PURLs From: Larry Masinter Message-Id: <96Oct9.191647pdt."2759"@golden.parc.xerox.com> Date: Wed, 9 Oct 1996 19:16:47 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com > Do you see where you're going Larry? You are putting everything > we've already got in the URN framework and the NAPTR proposal > into PURLs. A new NAPTR DNS record type with protocol names & syntax that requires parsing and interpretation as a 'regular expression' isn't part of the PURL proposal. PURLs don't relegate the security issues to DNS security but rather rely on HTTP security. PURLs don't require that application clients know anything about DNS other than 'Connect me to some machine that goes by this name'. I think that _relying_ on parsing data out of DNS records is very fragile, and most of purported advantages for NAPTRs are mainly vapor. > But you ARE changing the intent and current design of PURLS. I think we read different papers about PURLs; the paper I read made it seem like it was intended as a low-cost implementation of URNs. > If you can come up with a DISTRIBUTED database that has is as large > and as widespread as DNS that we can test the framework on then by all > means let us know cause we'll build the framework on that too. I think this is misleading, since the NAPTR proposal doesn't distribute resolution services widely. > If you've got a problem with NAPTR then you either have a problem > with the framework or DNS. No, I have a problem with THAT particular USE of DNS. Let me get down to the basics, though: DNS updates are unreliable. DNS administration is a nightmare. The PURL proposal has worked out many of the issues of administration and security that are necessary for actual deployment of URNs, and the NAPTR proposal has only a wave at DNSSEC. > I hope that won't be the case very soon. I'm building a > parallel registry in rwhois. It doesn't have the restrictions > that DNS does. Its more generalized and doesn't need to > be re-written everytime you add a field. That's great! If you're building a parallel registry in rwhois, I hope that you address the administrative and update issues that were worked out in the PURL paper and that we can leave NAPTR behind. Regards, Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA03782 for urn-ietf-out; Wed, 9 Oct 1996 22:00:20 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA03777 for ; Wed, 9 Oct 1996 22:00:16 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01634 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 21:59:45 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16464(8)>; Wed, 9 Oct 1996 18:59:43 PDT Received: by golden.parc.xerox.com id <2764>; Wed, 9 Oct 1996 18:59:34 PDT To: tallen@fsc.fujitsu.com Cc: michaelm@internic.net, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com In-Reply-To: <199610091421.HAA12054@ishtar.fsc.fujitsu.com> (message from Terry Allen on Wed, 9 Oct 1996 07:21:50 PDT) Subject: Re: [URN] advantages of NAPTR over PURLs From: Larry Masinter Message-Id: <96Oct9.185934pdt."2764"@golden.parc.xerox.com> Date: Wed, 9 Oct 1996 18:59:34 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com > But PURLs are not an implementation of URNs... Please review http://purl.oclc.org/OCLC/PURL/INET96 : > PURLs are a direct result of OCLC's work in the Uniform Resource Name > (URN) standards and library cataloging communities. The assignment of > PURLs is an intermediate step towards the time when URNs are an > integral part of the Internet information architecture. The eventual > syntax of URNs is clear enough at this time to afford confidence that > the syntax of PURLs can be inexpensively and mechanically translated > to the eventual URN form. For instance, the PURL > http://purl.oclc.org/keith/home > ---- ------------- ---------- > / | \ > protocol resolver address name > could be written something like the following using the Path URN syntax: > URN:/org/oclc/purl/keith/home > ------------- ---------- > | | > naming authority name > where the URN is essentially a hierarchical name with the first > portion representing the naming authority and the second portion > signifying the local name. Note that the naming authority in this > example is merely the resolver address of the corresponding PURL > written backwards (with slashes instead of dots) and the local name > is the same. > Syntax aside, one way to think of URNs and PURLs is to consider what > it would take to turn a PURL Server into a URN Server: very > little. If Web browsers were changed to recognize the syntax > URN:/org/oclc/purl/keith/home and could then connect to the resolver > at purl.oclc.org, the resolver could then resolve the name > /keith/home. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA19223 for urn-ietf-out; Wed, 9 Oct 1996 12:11:59 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA19217 for ; Wed, 9 Oct 1996 12:11:21 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26857 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 12:11:17 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA14137; Wed, 9 Oct 1996 10:10:59 -0600 (MDT) Message-Id: <2.2.32.19961009161808.006a0204@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 09 Oct 1996 10:18:08 -0600 To: Larry Masinter , michaelm@internic.net From: Ron Daniel Subject: Re: [URN] advantages of NAPTR over PURLs Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Larry Masinter (at least at 02:13 AM 10/9/96 PDT) >Presumably if you have SRV records, you could use them for HTTP >servers too, including http://www.purl.org. Sorry, but SRV records cannot be used for HTTP without changing all implementations of HTTP. The spec would also need to be changed to say if SRV requests or A requests should occur first, because behavior will differ. >> Because it has "purl.org" in it which is OWNED by OCLC. They pay the >> bill. > >Look, every place I've said "purl.org", change it to "purl.net" and >register "purl.net" in a standards track document, 'owned' by IANA. > >If you did that, what would distinguishes 'urn.net' and 'purl.net' in >terms of longevity? Nothing. But there are distinctions other than longevity that are important, starting with the overall design of the system. You are not talking abut PURLs as set forth by OCLC. You are talking about something that is halfway between the original Handle proposal and PURLs. The idea of a global resolver (on replicated servers) that would handle all resolution requests was the key feature of the original Handle proposal. It was found unacceptable for several reasons, two of which were: 1) Potential for surgical denial of sevice attacks 2) Organizations such as mine, who cannot put information about some of our documents into a system that is not cleared for handling classified work. (Company proprietary information is an analogous problem). >> Because we don't to be tied to DNS. The URN framework (not NAPTR) >> works in all situations no matter if you have DNS or not. You >> can run the service in an OSI world using X.500 (everyone scream). > >I'm sorry, I was trying to establish the advantage of the NAPTR >implementation against the PURL implementation of URNs, [...] Every time I have heard the OCLC people talk about PURLs, they have been careful to say that they are not URNs. Their focus was to do as much as possible without changing client-side code. >> 3) Other available protocols. The PURL doesn't tell me what other >> protocols are available and which one it considers the best. > >If the 303 response from HTTP includes multiple Location: results, you >could pick the one you liked the best. And 10 years from now, when HTTP has been supplanted by 2 generations of further work in protocols, we are still supposed to start off all resolution requests by sending an HTTP GET to something.purl.net? I'm sorry, but this doesn't sound like a solution that will gracefully adapt to the future. >> There is not ONE killer reason why the URN framework is better than >> PURLs. There are alot of smaller ones.... > >I think you misunderstood: I'm not questioning the 'URN >framework'. I'm questioning the NAPTR implementation of the framework. Oh, that has not been clear to me. I thought you were looking for a comparison between NAPTRs and PURLs. Since OCLC's PURLs are not an implementation of the URN framework, and NAPTRs are supposed to be, explaining some of the differences between them requires that we make reference to the URN framework. >I'm dubious about these DNS records with 'dblookup+N2C' in the middle >of them and the idea that just because the syntax is embedded in DNS >as a transmission mechanism that it isn't a 'protocol'. I could be wrong about this, but I don't recall anyone ever saying that NAPTRs were not a 'protocol', but please correct me if I am wrong about that. You say you are "dubious" about the proposal. That's fine, lets talk about your areas of concern. Yesterday you raised a couple of concrete objections to the NAPTR "protocol", namely that there was no versioning and that there was no change control over the resolution protocols (rcds, rcds2, ..). I pointed out how we could accomodate versioning in the flags field. I also said that we should discuss change control on the protocols, and that your suggestion that they be registered as URL schemes was a reasonable starting point for the discussion. To begin that discussion I also said that I was unsure this was the best thing to do, since in the past some protocols (Z39.50 in particular) have had trouble mapping all their capabilities into a URL. However, I don't have any better suggestions at this time. Perhaps we should look to a registry like the media type registry as our model? These topics are very young, so nobody has had anything to say on them yet. How about you? Does my suggestion of using the flags field overcome your concern about versioning? If not, why not? Do you have any further arguments on why a version field should be needed when we cannot change the number, type, or order of fields in a DNS record once it is out there? When clients and servers are not required to understand and support all the N2C, N2L, ... requests? Your point on versioning of the resolution protocols is well-taken. I agree we should address that somehow - probably in the framework document, but the NAPTR draft should, at least, cite the framework draft as the source of information on that topic. We should discuss ow to do it, so lets discuss it. I assume you have more knowledge of the Z39.50 URL schemes than I, is my concern about using URL standards-track documents as the "registry" misplaced? What about an IMT-style registry instead? Do you have any further concrete areas of concern about the NAPTR implementation of the framework? Later, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA17948 for urn-ietf-out; Wed, 9 Oct 1996 10:43:31 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA17943 for ; Wed, 9 Oct 1996 10:43:29 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25860 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 10:43:26 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id IAA12685; Wed, 9 Oct 1996 08:42:59 -0600 (MDT) Message-Id: <2.2.32.19961009145007.006ae9ec@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 09 Oct 1996 08:50:07 -0600 To: Lewis Girod From: Ron Daniel Subject: Re: [URN] advantages of NAPTR over PURLs Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Lewis Girod (at least at 08:08 PM 10/8/96 -0400) [Lewis talks about having a PURL-like resolver forward resolution requests] >While it is true that the client's resolutions would continue to go >``through'' whatever.resolver.purl.org, this is really because that is >the naming authority that delegated the names. NAPTR has this very >same property -- all resolutions go through the root (cached) >registry, [...] Actually, no. The PURL-like approaches send the entire request, document-id and all, to the root resolver. This allows fun little things like surgical denial of service and usage tracking which tend to get people excited. The NAPTR appoach does not send the entire resolution request to the root (urn.net). All we ask of it is "how do I resolve names from namespace X?". NAPTR and PURL resolution are very different. All NAPTR does is get us to a resolver, without requiring that the location of the resolver be buried in the URN or that we have a global resolver that is fixed for all time. PURLs get us to the resolver by putting its location into the identifier. Larry has suggested some modifications to PURLs where we don't put the location of the resolver into the identifier, but everyone knows that purl.org (or whatever) is the place to go to start resolution. >and if your names were originally delegated from foo.com, >you will probably end up going through foo.com forever, even if the >resolution is actually done by someone else. That depends on the namespace that is used. For namespaces like CID or INET, that is true. For namespaces like ISBN, resolution will probably be accomplished by an organization like Bowker, even if the name was originally assigned by Prentice-Hall. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA17788 for urn-ietf-out; Wed, 9 Oct 1996 10:33:03 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA17783 for ; Wed, 9 Oct 1996 10:32:58 -0400 Received: from SMTP1.ABRAXIS.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25734 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 10:32:54 -0400 Received: from [206.155.199.11] by smtp1.abraxis.com (NTMail 3.01.03) id ba052079; Wed, 9 Oct 1996 10:36:35 -0400 Message-Id: <325BB8BC.1248@internic.net> Date: Wed, 09 Oct 1996 10:37:48 -0400 From: Michael Mealling Organization: Network Solutions X-Mailer: Mozilla 3.0b7 (X11; I; SunOS 5.5 i86pc) Mime-Version: 1.0 To: Larry Masinter Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] advantages of NAPTR over PURLs References: <96Oct9.021303pdt."2765"@golden.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Michael Mealling Errors-To: owner-urn-ietf@bunyip.com Larry Masinter wrote: > > > The only way to do this is with a new record. That record is the > > SRV record which a lot of people are planning on using. A records > > only have the IP address, nothing else. > > Presumably if you have SRV records, you could use them for HTTP > servers too, including http://www.purl.org. So the fact that this is a > general mechanism means that 'priority' is no longer an advantage of > NAPTR vs. PURL. Do you see where you're going Larry? You are putting everything we've already got in the URN framework and the NAPTR proposal into PURLs. > > Because it has "purl.org" in it which is OWNED by OCLC. They pay the > > bill. As far as the NIC is concerned they can do with it whatever > > they want and we can't do squat about it. NAPTR should eventually > > be a TLD all its own that is not 'owned' by anyone but the IANA (which > > has its own problems but I won't go into that). > > Look, every place I've said "purl.org", change it to "purl.net" and > register "purl.net" in a standards track document, 'owned' by IANA. > > If you did that, what would distinguishes 'urn.net' and 'purl.net' in > terms of longevity? Nothing. But you ARE changing the intent and current design of PURLS. > > Because we don't to be tied to DNS. The URN framework (not NAPTR) > > works in all situations no matter if you have DNS or not. You > > can run the service in an OSI world using X.500 (everyone scream). > > I'm sorry, I was trying to establish the advantage of the NAPTR > implementation against the PURL implementation of URNs, not against > the 'framework'. NAPTR is just one implementation. Its not the best because of limitations of DNS. If you've got problems with NAPTR because of that then take them up with Paul Vixie. If you can come up with a DISTRIBUTED database that has is as large and as widespread as DNS that we can test the framework on then by all means let us know cause we'll build the framework on that too. If you've got a problem with NAPTR then you either have a problem with the framework or DNS. > > 1) Areas of Authority. purl.org is authoritative for everything. I doubt > > if that scales. If its not authoritative how do I find the authoritative > > server? > > Who is the authority of "urn.net"? The authority for purl.net can be > delegated in the same way that NAPTR delegates the authority for > urn.net. Huh? How can purl.net delegate authority without having to go through purl.net first? Who the authority is for urn.net is the IANA hopefully. The IANA could also be the authority for purl.net. That's not the issue. I'm talking about subdelegation of entire naming authority spaces such as "ibm", "compuserve", "thompson publishing", etc. > > 2) Services. I don't want just the URL. I want a URC. But I want it in > > SGML and not MARC. How can I get that out of a PURL? > > This is really speculative, of course, since there's never quite been > agreement on exactly what a 'URC' might be. But I'd conjecture that > the way you get something out of a resource other than the resource > itself is by applying some other method than GET. Ok. Granted. URCs don't exist. What happens when the resource itself on one server and the metadata is on another. To find both I have to go to purl.net. Larry, I don't know if you've got some awsome machine up your sleave but if you've got a database that can a) handle HTTP b) be replicated reliably and quickly around all of the SRV replicated PURL servers and c) handle the millions of queries a second that are going to come to purl.net because it is the one place that knows where all of the URNs and URLs and URCs are then you've got something truly amazing. Who the hells gonna pay for it? > > > 3) Other available protocols. The PURL doesn't tell me what other > > protocols are available and which one it considers the best. > > If the 303 response from HTTP includes multiple Location: results, you > could pick the one you liked the best. It's true that the results > don't rank order them, but is that actually practical? Yes. If I'm serving SGML based something or others then I want you to use Z39.50 or some other deep search tool. You should know that even though you like HTTP its not going to get you the information that I know is in that database. Plus, I still have to go to one of those big purl database machines even to find out what protocols are available. You've done nothing more than stick the hidden the re-write rules inside the PURL database and made everyone go to it in order to do the mapping. You've basically collapsed the NAPTR proposal into one BIG PURL database by forcing everyone to go to it in order to find out what the URLs are for the authoritative resources. That just won't scale. > > 4) Equivalence. How do I match equivalence? Do I just match on > > the part after the hostname? If so then authority areas cannot > > exist. If not then your protocol is indistinquishable from the > > rest of the authority area. > > I'm not sure where the 'equivalence' requirement came from, since it > was specifically not a URN requirement. It wasn't a URN requirement > primarily because it was considered impossible. One server gives me a document called URN:FOO. Another services gives another document called URN:FOO. I know that for their purposes those organizations think those two things are the same. If I have http://foobar.purl.net/saldkfasldkfjsldfj and http://barbaz.purl.net/saldkfasldkfjsldfj. Are they byte equal? > > > There is not ONE killer reason why the URN framework is better than > > PURLs. There are alot of smaller ones.... > > I think you misunderstood: I'm not questioning the 'URN > framework'. The framework specifies everything that NAPTR must do. DNS specifies everything that NAPTR can do. How would you build something that follows the framework that doesn't require everyone to go to one HUGE replicated database? The only widely available distributed database we have right now is DNS. I hope that won't be the case very soon. I'm building a parallel registry in rwhois. It doesn't have the restrictions that DNS does. Its more generalized and doesn't need to be re-written everytime you add a field. > I'm questioning the NAPTR implementation of the framework. > I'm dubious about these DNS records with 'dblookup+N2C' in the middle > of them and the idea that just because the syntax is embedded in DNS > as a transmission mechanism that it isn't a 'protocol'. Noone ever said it wasn't a protocol. Its a distributed database for looking up the rules for finding the authoritative servers and services for a given URN. The NAPTR proposal gives the algorithm for interpreting the records in that database. Of course in order to use that database you have to access it somehow and thats a protocol. -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@internic.net Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA17693 for urn-ietf-out; Wed, 9 Oct 1996 10:23:39 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA17688 for ; Wed, 9 Oct 1996 10:23:03 -0400 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25638 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 10:23:00 -0400 Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id HAA02062; Wed, 9 Oct 1996 07:21:25 -0700 (PDT) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id HAA12054; Wed, 9 Oct 1996 07:21:50 -0700 (PDT) Date: Wed, 9 Oct 1996 07:21:50 -0700 (PDT) From: Terry Allen Message-Id: <199610091421.HAA12054@ishtar.fsc.fujitsu.com> To: masinter@parc.xerox.com, michaelm@internic.net Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] advantages of NAPTR over PURLs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Larry: | I'm sorry, I was trying to establish the advantage of the NAPTR | implementation against the PURL implementation of URNs, not against | the 'framework'. But PURLs are not an implementation of URNs. They do not grandfather in existing name spaces, for example. They are a clever use of indirection with URLs. I think you're comparing apples and oranges, Larry. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA15667 for urn-ietf-out; Wed, 9 Oct 1996 05:13:28 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA15662 for ; Wed, 9 Oct 1996 05:13:25 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24003 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 05:13:23 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16360(2)>; Wed, 9 Oct 1996 02:13:17 PDT Received: by golden.parc.xerox.com id <2765>; Wed, 9 Oct 1996 02:13:03 PDT To: michaelm@internic.net Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com In-Reply-To: <325A5C0C.5D13@internic.net> (message from Michael Mealling on Tue, 8 Oct 1996 06:50:04 PDT) Subject: Re: [URN] advantages of NAPTR over PURLs From: Larry Masinter Message-Id: <96Oct9.021303pdt."2765"@golden.parc.xerox.com> Date: Wed, 9 Oct 1996 02:13:03 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com > The only way to do this is with a new record. That record is the > SRV record which a lot of people are planning on using. A records > only have the IP address, nothing else. Presumably if you have SRV records, you could use them for HTTP servers too, including http://www.purl.org. So the fact that this is a general mechanism means that 'priority' is no longer an advantage of NAPTR vs. PURL. > No. It has to do with the allowable packets size for DNS via UDP. > If it goes over then the packet is truncated causing the client > to have to reconnect via TCP. IF the part that is truncated > though is in the additional information field then the user > is NOT given an error. This is a problem with DNS that > cannot be fixed. Even if you consider it a problem.... I'm really confused why long A records are a problem and long SRV records aren't a problem, but I suppose I can take your word for it. > Because it has "purl.org" in it which is OWNED by OCLC. They pay the > bill. As far as the NIC is concerned they can do with it whatever > they want and we can't do squat about it. NAPTR should eventually > be a TLD all its own that is not 'owned' by anyone but the IANA (which > has its own problems but I won't go into that). Look, every place I've said "purl.org", change it to "purl.net" and register "purl.net" in a standards track document, 'owned' by IANA. If you did that, what would distinguishes 'urn.net' and 'purl.net' in terms of longevity? > Because we don't to be tied to DNS. The URN framework (not NAPTR) > works in all situations no matter if you have DNS or not. You > can run the service in an OSI world using X.500 (everyone scream). I'm sorry, I was trying to establish the advantage of the NAPTR implementation against the PURL implementation of URNs, not against the 'framework'. > 1) Areas of Authority. purl.org is authoritative for everything. I doubt > if that scales. If its not authoritative how do I find the authoritative > server? Who is the authority of "urn.net"? The authority for purl.net can be delegated in the same way that NAPTR delegates the authority for urn.net. > 2) Services. I don't want just the URL. I want a URC. But I want it in > SGML and not MARC. How can I get that out of a PURL? This is really speculative, of course, since there's never quite been agreement on exactly what a 'URC' might be. But I'd conjecture that the way you get something out of a resource other than the resource itself is by applying some other method than GET. > 3) Other available protocols. The PURL doesn't tell me what other > protocols are available and which one it considers the best. If the 303 response from HTTP includes multiple Location: results, you could pick the one you liked the best. It's true that the results don't rank order them, but is that actually practical? > 4) Equivalence. How do I match equivalence? Do I just match on > the part after the hostname? If so then authority areas cannot > exist. If not then your protocol is indistinquishable from the > rest of the authority area. I'm not sure where the 'equivalence' requirement came from, since it was specifically not a URN requirement. It wasn't a URN requirement primarily because it was considered impossible. > There is not ONE killer reason why the URN framework is better than > PURLs. There are alot of smaller ones.... I think you misunderstood: I'm not questioning the 'URN framework'. I'm questioning the NAPTR implementation of the framework. I'm dubious about these DNS records with 'dblookup+N2C' in the middle of them and the idea that just because the syntax is embedded in DNS as a transmission mechanism that it isn't a 'protocol'. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id DAA14692 for urn-ietf-out; Wed, 9 Oct 1996 03:15:17 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id DAA14686 for ; Wed, 9 Oct 1996 03:15:05 -0400 Received: from trapdoor.dstc.edu.au by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23582 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 03:15:02 -0400 Received: from fatcat.dstc.edu.au (fatcat.dstc.edu.au [130.102.176.7]) by trapdoor.dstc.edu.au (8.6.9/8.6.12) with ESMTP id RAA05356; Wed, 9 Oct 1996 17:14:51 +1000 Received: (from renato@localhost) by fatcat.dstc.edu.au (8.6.10/8.6.12) id RAA08853; Wed, 9 Oct 1996 17:14:46 +1000 From: Renato Iannella Message-Id: <199610090714.RAA08853@fatcat.dstc.edu.au> Date: Wed, 9 Oct 1996 17:14:46 +1000 (EST) To: masinter@parc.xerox.com Cc: michaelm@internic.net, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re[4]: [URN] advantages of NAPTR over PURLs In-Reply-To: <96Oct8.221522pdt."2759"@golden.parc.xerox.com> X-Mailer: Ishmail 1.3-960829-osf1 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Renato Iannella Errors-To: owner-urn-ietf@bunyip.com Larry Masinter wrote: > > Extensions to actually retrieving metadata for resources shouldn't be > restricted to any URN implementation, should it? Not exclusive for URNs, but I can see the increasing overloading of the use of URLs becoming epidemic! In resolving a URN, we need to be able to specify a range of options (eg: format/part of URC, best/cheapest or closest place to resolve this, etc). PURLs are great for those who need to move resources around within an organisation. We need URNs (and NAPTRs) for more sophisticated uses (as Ron and others have outlined). Cheers... Renato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dr Renato Iannella http://www.dstc.edu.au/RDU/staff/ri Research Data Network CRC urn:inet:dstc.edu.au:renato:home DSTC Pty Ltd, Uni Qld, 4072, AUSTRALIA phone/fax: +61 7 3365 4310/11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Australian WWW Technical Conference '97 -> http://www.dstc.edu.au/aw3tc Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA14231 for urn-ietf-out; Wed, 9 Oct 1996 01:58:17 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA14226 for ; Wed, 9 Oct 1996 01:58:13 -0400 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23339 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 01:58:10 -0400 Received: from nic.cafax.se (paf@nic.cafax.se [193.12.122.42]) by nic.cafax.se (8.8.Beta.2/8.8.Beta.2) with SMTP id HAA08001; Wed, 9 Oct 1996 07:57:23 +0200 (MET DST) Date: Wed, 9 Oct 1996 07:57:22 +0200 (MET DST) From: Patrik Faltstrom X-Sender: paf@nic.cafax.se To: Larry Masinter Cc: renato@dstc.edu.au, michaelm@internic.net, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: Re[2]: [URN] advantages of NAPTR over PURLs In-Reply-To: <96Oct8.221522pdt."2759"@golden.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com On Tue, 8 Oct 1996, Larry Masinter wrote: > Many people want metadata from URLs too. A simple way to add metadata > would be to add a new operation (GETMETA) where the format of the > metadata is returned according to the Accept: headers. > > Extensions to actually retrieving metadata for resources shouldn't be > restricted to any URN implementation, should it? No, but in the case of having this as a new operation that means that the metadata (basically) have to be stored where the target of the URL is stored, or one have to have special functions in giving redirects when doing this command and not giving back the target itself -- and update this redirect table where the URL points (here we come back to what Ron was talking about administrative responsibility for information). I am not saying that metadata should only exist when dealing with URNs. I am only saying that it is easier to use a scheme like NAPTR where you do the DNS query and immediately know where to go when asking for the metadata, and when asking for the target. One save at least one TCP connection. That is not peanuts on todays internet -- if it was only traffic we were talking about. The biggest advantage is that one organization can have one document, have a URN to that resourse and then outsource the resolution service for the metadata and the data (including replication) from a service provider. The owner of the information creates a couple of NAPTR records pointing to this service providers services. The service provider is having some SRV records translating this abstract names into the actual host/port number where the service is running. The result is information about where the document is stored, where the metadata is stored etc. This distiction between what the owner of the document is doing and what the service provider is doing is very important and needed from my point of view. Patrik Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA13981 for urn-ietf-out; Wed, 9 Oct 1996 01:15:50 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA13976 for ; Wed, 9 Oct 1996 01:15:47 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23213 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 01:15:45 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16217(6)>; Tue, 8 Oct 1996 22:15:39 PDT Received: by golden.parc.xerox.com id <2759>; Tue, 8 Oct 1996 22:15:22 PDT To: renato@dstc.edu.au Cc: michaelm@internic.net, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com In-Reply-To: <199610090439.OAA06585@fatcat.dstc.edu.au> (message from Renato Iannella on Tue, 8 Oct 1996 21:39:11 PDT) Subject: Re: Re[2]: [URN] advantages of NAPTR over PURLs From: Larry Masinter Message-Id: <96Oct8.221522pdt."2759"@golden.parc.xerox.com> Date: Tue, 8 Oct 1996 22:15:22 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com Many people want metadata from URLs too. A simple way to add metadata would be to add a new operation (GETMETA) where the format of the metadata is returned according to the Accept: headers. Extensions to actually retrieving metadata for resources shouldn't be restricted to any URN implementation, should it? Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA13362 for urn-ietf-out; Wed, 9 Oct 1996 00:40:35 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA13324 for ; Wed, 9 Oct 1996 00:39:23 -0400 Received: from trapdoor.dstc.edu.au by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22800 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 00:39:20 -0400 Received: from fatcat.dstc.edu.au (fatcat.dstc.edu.au [130.102.176.7]) by trapdoor.dstc.edu.au (8.6.9/8.6.12) with ESMTP id OAA28222; Wed, 9 Oct 1996 14:39:12 +1000 Received: (from renato@localhost) by fatcat.dstc.edu.au (8.6.10/8.6.12) id OAA06585; Wed, 9 Oct 1996 14:39:12 +1000 From: Renato Iannella Message-Id: <199610090439.OAA06585@fatcat.dstc.edu.au> Date: Wed, 9 Oct 1996 14:39:11 +1000 (EST) To: michaelm@internic.net Cc: masinter@parc.xerox.com, rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re[2]: [URN] advantages of NAPTR over PURLs In-Reply-To: <325A5C0C.5D13@internic.net> X-Mailer: Ishmail 1.3-960829-osf1 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Renato Iannella Errors-To: owner-urn-ietf@bunyip.com Michael Mealling wrote: > This doesn't give you several things: > 2) Services. I don't want just the URL. I want a URC. But I want it in > SGML and not MARC. How can I get that out of a PURL? I agree strongly here with Michael on this point. PURLs can give you URLs, but we need the metadata (URCs) to create _smarter_ and more _efficient_ internet clients. Cheers... Renato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dr Renato Iannella http://www.dstc.edu.au/RDU/staff/ri Research Data Network CRC urn:inet:dstc.edu.au:renato:home DSTC Pty Ltd, Uni Qld, 4072, AUSTRALIA phone/fax: +61 7 3365 4310/11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Australian WWW Technical Conference '97 -> http://www.dstc.edu.au/aw3tc Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA13284 for urn-ietf-out; Wed, 9 Oct 1996 00:37:05 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA13279 for ; Wed, 9 Oct 1996 00:37:02 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22795 (mail destined for urn-ietf@services.bunyip.com); Wed, 9 Oct 96 00:37:01 -0400 Received: from legiron.acl.lanl.gov (transitory4.lanl.gov [128.165.7.196]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id WAA10320; Tue, 8 Oct 1996 22:36:53 -0600 (MDT) Message-Id: <2.2.32.19961009044401.006b7ee8@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 08 Oct 1996 22:44:01 -0600 To: Terry Allen From: Ron Daniel Subject: Re: [URN] advantages of NAPTR over PURLs Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Terry Allen (at least at 03:38 PM 10/8/96 -0700) >Which are the two registries? The namespace registry (urn.net) and the protocol registry (URL schemes ala Larry's suggestion). Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA10795 for urn-ietf-out; Tue, 8 Oct 1996 20:08:59 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA10790 for ; Tue, 8 Oct 1996 20:08:57 -0400 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21415 (mail destined for urn-ietf@services.bunyip.com); Tue, 8 Oct 96 20:08:55 -0400 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa26346; 8 Oct 96 20:08 EDT Received: by skadhwe.lcs.mit.edu; (5.65v3.2/1.1.8.2/15Aug95-0306PM) id AA20845; Tue, 8 Oct 1996 20:08:35 -0400 Date: Tue, 8 Oct 1996 20:08:35 -0400 Message-Id: <9610090008.AA20845@skadhwe.lcs.mit.edu> From: Lewis Girod To: rdaniel@acl.lanl.gov Cc: masinter@parc.xerox.com, urn-ietf@bunyip.com In-Reply-To: <2.2.32.19961008204620.0069812c@acl.lanl.gov> (message from Ron Daniel on Tue, 08 Oct 1996 14:46:20 -0600) Subject: Re: [URN] advantages of NAPTR over PURLs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com From: Ron Daniel [...] Larry is correct that a great level of indirection can be achieved by changing the set of IP addresses that are returned when looking up some domain name, such as "resolver.purl.org". But all this indirection is simply changing the list of machines that are part of some business agreement with one organization. PURLs do not provide the indirection that is necessary to switch resolution from one organization to another. Assume we start with purl.org doing our resolution, and now want to do it ourselves. Maybe we want to go into competition with purl.org. Or maybe we are affiliated with the US Government and they mandate that all resources paid for by US tax dollars shall be resolved at gpo.gov. There are a number of believable scenarios where we want resolution to occur on machines that *cannot* be pointed to by the domain name purl.org. (Or any other single domain name). One part of this argument is that PURL provides a ``direct'' resolution service, while NAPTR points the client _to_ a resolution service. However, a (differently implemented) server operating within the same basic architecture as the existing PURL server could redirect an arbitrary set of a client's PURLs to some other PURL server, ad nauseum, thus gaining the desired property of pointing to other resolvers. (Essentially this might involve extending the notion of a ``partial redirect''.) While it is true that the client's resolutions would continue to go ``through'' whatever.resolver.purl.org, this is really because that is the naming authority that delegated the names. NAPTR has this very same property -- all resolutions go through the root (cached) registry, and if your names were originally delegated from foo.com, you will probably end up going through foo.com forever, even if the resolution is actually done by someone else. The main difference is that NAPTR requires modifications to the client side and requires the client to execute the rewrite rules (which is part of the work involved in the resolution). In the PURL architecture all that work would be done on the server, and it could be arbitrarily complex (even more powerful than regexps ;-). There are cases in which each of these options is the more efficient one: * In the case of NAPTR all of the information for locating resolvers can be cached, whereas with PURL only information pertaining to specific PURLs can be cached. * In the case of NAPTR, if the _right_ answer(s) are readily computed it is faster to have the client compute it than to look it up from a server, as it would work with PURL. * However, if the computation results in a number of matches that each have to be tried, then it might be more efficient to do that work on the server side. One thing that has long worried me about NAPTR is that as the namespace gets more fragmented the lookup to the DNS that originally brought back one or two records might end up returning hordes of records pointing where each individual fragment went. In any case, yes, the PURL server as implemented has the properties Ron stated, but the architecture _can_ support those indirection features, without client-side changes. - Lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA09802 for urn-ietf-out; Tue, 8 Oct 1996 18:41:24 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA09784 for ; Tue, 8 Oct 1996 18:40:49 -0400 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21129 (mail destined for urn-ietf@services.bunyip.com); Tue, 8 Oct 96 18:40:46 -0400 Received: from ishtar.fsc.fujitsu.com (ishtar.fsc.fujitsu.com [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id PAA14008; Tue, 8 Oct 1996 15:37:35 -0700 (PDT) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id PAA24249; Tue, 8 Oct 1996 15:38:05 -0700 (PDT) Date: Tue, 8 Oct 1996 15:38:05 -0700 (PDT) From: Terry Allen Message-Id: <199610082238.PAA24249@ishtar.fsc.fujitsu.com> To: masinter@parc.xerox.com, rdaniel@acl.lanl.gov Cc: urn-ietf@bunyip.com Subject: Re: [URN] advantages of NAPTR over PURLs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Ron writes: | More contentious will be the registry for the namespaces. This is | a place where we stand a good chance of repeating the TLD battle | that is making life unpleasant for some of our colleagues. My current | rules for what should be allowed to be registered as namespaces are: | 1) Is it a namespace established by a recognized international | standards body? (ISBN, ISSN, SICI, ISAN, ISWC, FPI, OID, and | a few others fit here). | 2) Is it a namespace estabished by an industry standards body with | broad particiation? (SMPTE, IEEE, EIA,... are examples of the | groups I am thinking of). | 3) This one is harder - is it a namespace established by a | commercial organization for the use of any organization following | normal business practices? (This is to allow namespaces such as | DUNS (30 million identified organizations), some of the Barcode | registries (each can accomodate a few 10s of thousands of companies), | etc. It is intended to disallow vanity namespaces. This may be | impossible. For "established," above, I think "maintained" would be better, or perhaps "supervised, audited, licensed". And this should apply only to name spaces that these organizations themselves count as eligible. | | Both registries should be mentioned in the framework draft. We need a | really good lawyer to look at the language. Anyone know of a likely | candidate who would do it pro-bono? | Which are the two registries? Regards, (at a new address) Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA08528 for urn-ietf-out; Tue, 8 Oct 1996 16:39:51 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA08515 for ; Tue, 8 Oct 1996 16:39:33 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20125 (mail destined for urn-ietf@services.bunyip.com); Tue, 8 Oct 96 16:39:21 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id OAA06559; Tue, 8 Oct 1996 14:39:13 -0600 (MDT) Message-Id: <2.2.32.19961008204620.0069812c@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 08 Oct 1996 14:46:20 -0600 To: Larry Masinter From: Ron Daniel Subject: Re: [URN] advantages of NAPTR over PURLs Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com I'm going to try to summarize the last batch of messages from Larry, Patrik, Michael, and myself. A key point of contention seems to be shown when Larry says (at 07:10 PM 10/7/96 PDT) >The DNS entries for resolver.purl.org already give you all the >indirection you need. Why add more? I (and I assume Michael and Patrik) do not agree with the assertion that this is all the indirection that is needed. Let me try to show why, and Larry can let us know if the reasons are convincing or if he wants to try and change our minds. Larry is correct that a great level of indirection can be achieved by changing the set of IP addresses that are returned when looking up some domain name, such as "resolver.purl.org". But all this indirection is simply changing the list of machines that are part of some business agreement with one organization. PURLs do not provide the indirection that is necessary to switch resolution from one organization to another. Assume we start with purl.org doing our resolution, and now want to do it ourselves. Maybe we want to go into competition with purl.org. Or maybe we are affiliated with the US Government and they mandate that all resources paid for by US tax dollars shall be resolved at gpo.gov. There are a number of believable scenarios where we want resolution to occur on machines that *cannot* be pointed to by the domain name purl.org. (Or any other single domain name). Several of Larry's other questions, such as > I don't understand why www.purl.org must have a shorter lifetime than > any NAPTR name. You just vow to not reassign the name. are answered by the above. It is not just that www.purl.org might go away, it is that we might want to move resolution of our identifiers off of any machines that can be identified by www.purl.org and onto machines identified by the domain name of a competitor to purl.org, while purl.org still exists. So, that is why we believe that changing IP addresses under a fixed domain name is not sufficient *indirection* capabilities. In responding to the same point, Patrik said that > it does not give the information about priority and > protocol that is needed. and Larry asked for the justification for the need for priority information. Let me take a stab at that as well. Assume we have a set of N machines which are providing the service for scheme.purl.com. There is no reason to assume that all these machines are equally capable. Some will be very capable hosts, others not so able. The priority field is used to preferentially direct resolution requests towards the more capable machines, while still allowing some requests to be sent to the less powerful ones. NAPTRs themselves do not provide this field, we rely on the SRV record for that. There were some other questions about A records and bugs, Michael has addressed those. Other arguments, both technical and business, can be made against the notion of having the IETF standardize a resolution procedure that says "map : to http://.purl.org/". The technical arguments are analogous to those that were raised against the original version of the handle protocol. Business arguments show up when Larry quotes me: > > For PURLs, we not only have to know the identifier, we have to know > > what resolver to contact. We end up with things like: > > http://purl.bowker.com/isbn/1-56604-355-7 > > http://purl.agicoa.com/isan/9961231234567891 > > oh no! Clearly you only want to use the resolver.purl.org name. Saying that all resolution requests go to .purl.org mandates that all organizations like Bowker, AGICOA, ASCAP, BMI, etc. (who have the databases of identifiers and resources for particular schemes) establish a business relationship with OCLC (*and any unspecified party that OCLC allows to take over purl.org at any point in the future, no matter what their policies*). This is not an acceptable solution. In a later message, (Tue, 8 Oct 1996 00:59:24 PDT) Larry raises a good point about the NAPTR resolution procedure not having version information, so how do we know about: 1) N2L, N2C, ... meaning the same things across time 2) how to handle protocol changes such as rcds going to rcds2 First, changes in rcds (or other protocols) can be handled by naming those protocols as rcds, rcds2, rcds3, ... in the protocol portion of the services field. If the group is concerned about versioning of the NAPTR record contents and semantics, we have a couple of choices. One is that we define a new RR at some point in the future. The second choice is that we use the "flags" field. Currently we are allowing the digits 0-9 in the flags field to be used for local experimentation (although I have no idea what those experiments might be). We could reserve 2-9 for versions of the interpretation of the fields of the NAPTR record. (The actual number, type, and order of the fields in a DNS RR cannot be changed once established, new RRs have to be defined to replace them). I am not convinced that adding a new resolution request (call it N2X for argument) mandates a new "version" of the NAPTR record. The services field can easily accomodate it, it has no backward incompatabilitites, clients and servers are not required to support all resolution services. Adding a new request will require that all protocols that want to support it specify how the request and result will be mapped into their protocol, but if necessary the protocols themselves can be versioned as noted above. Larry also raise a good point when he says that: >if you force people to register "dunslink" and "rcds" as new >URL schemes, we'll have a mechanism for dealing with those tokens in a >standards-track way. As you've specified it, there's no change-control >on what those tokens might mean: if there are two versions of >rcds, should NAPTR records upgrade all their records when the resolver >upgrades from rcds1 to rcds2? If there's a version skew between the >client rcds and the server rcds such that the server rcds can't >respond to the client's ancient rcds implementation, should the >rejection influence the handling of priorities? We do need some registry for the protocols to have a degree of change control. I am not sure that URL schemes are the best way to do it, because of difficulties some protocols (Z39.50 for example) have had in the past with making all their capabilities show up in a URL. However, it is a reasonable starting point for discussion. More contentious will be the registry for the namespaces. This is a place where we stand a good chance of repeating the TLD battle that is making life unpleasant for some of our colleagues. My current rules for what should be allowed to be registered as namespaces are: 1) Is it a namespace established by a recognized international standards body? (ISBN, ISSN, SICI, ISAN, ISWC, FPI, OID, and a few others fit here). 2) Is it a namespace estabished by an industry standards body with broad particiation? (SMPTE, IEEE, EIA,... are examples of the groups I am thinking of). 3) This one is harder - is it a namespace established by a commercial organization for the use of any organization following normal business practices? (This is to allow namespaces such as DUNS (30 million identified organizations), some of the Barcode registries (each can accomodate a few 10s of thousands of companies), etc. It is intended to disallow vanity namespaces. This may be impossible. Both registries should be mentioned in the framework draft. We need a really good lawyer to look at the language. Anyone know of a likely candidate who would do it pro-bono? Enough for now, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA02422 for urn-ietf-out; Tue, 8 Oct 1996 09:47:54 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA02405 for ; Tue, 8 Oct 1996 09:47:51 -0400 Received: from gizmo.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15132 (mail destined for urn-ietf@services.bunyip.com); Tue, 8 Oct 96 09:47:38 -0400 Received: from mrrl.lut.ac.uk (martin@localhost.mrrl.lut.ac.uk [127.0.0.1]) by gizmo.lut.ac.uk (8.8.0/8.6.9) with ESMTP id OAA25010 for ; Tue, 8 Oct 1996 14:45:57 +0100 (BST) Message-Id: <199610081345.OAA25010@gizmo.lut.ac.uk> To: urn-ietf@bunyip.com X-Uri: Subject: [URN] NAPTR time, folks Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <25006.844782356.1@mrrl.lut.ac.uk> Date: Tue, 08 Oct 1996 14:45:56 +0100 From: Martin Hamilton Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin Hamilton Errors-To: owner-urn-ietf@bunyip.com For info - I just noticed the latest BIND test release (4.9.5-T6B) has support for NAPTR records. Martin Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA02389 for urn-ietf-out; Tue, 8 Oct 1996 09:45:37 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA02377 for ; Tue, 8 Oct 1996 09:45:03 -0400 Received: from SMTP1.ABRAXIS.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15112 (mail destined for urn-ietf@services.bunyip.com); Tue, 8 Oct 96 09:45:01 -0400 Received: from [206.155.199.11] by smtp1.abraxis.com (NTMail 3.01.03) id za051713; Tue, 8 Oct 1996 09:48:49 -0400 Message-Id: <325A5C0C.5D13@internic.net> Date: Tue, 08 Oct 1996 09:50:04 -0400 From: Michael Mealling Organization: Network Solutions X-Mailer: Mozilla 3.0b7 (X11; I; SunOS 5.5 i86pc) Mime-Version: 1.0 To: Larry Masinter Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] advantages of NAPTR over PURLs References: <96Oct7.191009pdt."2771"@golden.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Michael Mealling Errors-To: owner-urn-ietf@bunyip.com Larry Masinter wrote: > Re replication: > > > We can provide multiple A records for www.purl.org, but there is no > > way to do smart prioritization between the more and less capable > > hosts. > > Why is this easier to do with NAPTR records than A records? Could we > extend A records for HTTP servers so that you could do smart > prioritization? ("If this is such a great idea, why save it for > URNS"). The only way to do this is with a new record. That record is the SRV record which a lot of people are planning on using. A records only have the IP address, nothing else. > > Depending on how the multiple A records are provided, there may also > > be an obscure error that truncates the list of responses. The NAPTR > > proposal will not suffer that error. > > Is this a bug in the implementation of DNS? If the bug is there for A > records, why wouldn't it be there for NAPTR records? Is this a design > error that could be fixed? No. It has to do with the allowable packets size for DNS via UDP. If it goes over then the packet is truncated causing the client to have to reconnect via TCP. IF the part that is truncated though is in the additional information field then the user is NOT given an error. This is a problem with DNS that cannot be fixed. Even if you consider it a problem.... > > The real point of the NAPTR proposal is that it gives us a way to cope > > with names, such as www.purl.org, that should be long-lived but aren't. > > I don't understand why www.purl.org must have a shorter lifetime than > any NAPTR name. You just vow to not reassign the name. If you can't do > that with ".org", then pick a new top level domain. Because it has "purl.org" in it which is OWNED by OCLC. They pay the bill. As far as the NIC is concerned they can do with it whatever they want and we can't do squat about it. NAPTR should eventually be a TLD all its own that is not 'owned' by anyone but the IANA (which has its own problems but I won't go into that). > >>Well, www.purl.org can migrate, too, can't it? > > I'm sorry I wasn't clear. By "migrating a resolver" I mean moving it onto > > a machine that cannot be identified by the domain name that was used > > for the earlier resolver, and terminating service on the original machine, > > even if that machine remains up and running for other purposes. > > So, no, www.purl.org cannot migrate according to my definition. (Better > > terminology welcomed). > > If you want to be able to migrate PURL resolvers to other machines, > you just assign a new IP address to the PURL resolver name. This is > completely flexible. Don't use that DNS name for anything other than > PURL resolution service. E.g., call it .resolver.purl.org > instead of just www.purl.org. > > The DNS entries for resolver.purl.org already give you all the > indirection you need. Why add more? Because we don't to be tied to DNS. The URN framework (not NAPTR) works in all situations no matter if you have DNS or not. You can run the service in an OSI world using X.500 (everyone scream). > >>> and the resolution process allows multiple protocols > >>The URL in the 'Location:' header of purl.org's response need not be > >>'http:'. > > >We are not talking about the same thing. One could assign PURLs such as > > ftp://purl.foo.com/whatever > >but once that PURL is assigned, we have to use FTP to resolve it. Since > >the NAPTR draft doesn't require the resolution protocol to be embedded in > >the identifier, we are free to offer multiple resolution protocols and to > >change them over time. This is an important point, since over time we > >will have increasingly efficient protocols. > > In the "PURL" method, the "resolution" is accomplished by using HTTP > to talk to the resolution service and (if what you do is a GET) > getting back a "303" response with a Location: header to do the > URN->URL mapping. This doesn't give you several things: 1) Areas of Authority. purl.org is authoritative for everything. I doubt if that scales. If its not authoritative how do I find the authoritative server? 2) Services. I don't want just the URL. I want a URC. But I want it in SGML and not MARC. How can I get that out of a PURL? 3) Other available protocols. The PURL doesn't tell me what other protocols are available and which one it considers the best. 4) Equivalence. How do I match equivalence? Do I just match on the part after the hostname? If so then authority areas cannot exist. If not then your protocol is indistinquishable from the rest of the authority area. There is not ONE killer reason why the URN framework is better than PURLs. There are alot of smaller ones.... -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@internic.net Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA01814 for urn-ietf-out; Tue, 8 Oct 1996 09:07:12 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA01809 for ; Tue, 8 Oct 1996 09:07:09 -0400 Received: from SMTP1.ABRAXIS.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14607 (mail destined for urn-ietf@services.bunyip.com); Tue, 8 Oct 96 09:07:06 -0400 Received: from [206.155.199.11] by smtp1.abraxis.com (NTMail 3.01.03) id sa051706; Tue, 8 Oct 1996 09:10:53 -0400 Message-Id: <325A5322.77B8@internic.net> Date: Tue, 08 Oct 1996 09:12:02 -0400 From: Michael Mealling Organization: Network Solutions X-Mailer: Mozilla 3.0b7 (X11; I; SunOS 5.5 i86pc) Mime-Version: 1.0 To: urn-ietf@bunyip.com Subject: [URN] [Fwd: 4.9.5 T6B] NAPTR/SRV beta support in bind available Content-Type: multipart/mixed; boundary="------------31DA64A630DE" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Michael Mealling Errors-To: owner-urn-ietf@bunyip.com This is a multi-part message in MIME format. --------------31DA64A630DE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I just received this from Paul Vixie. This is a beta release so be careful if really depend on your DNS server. Enjoy! Thanks Paul! -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@internic.net --------------31DA64A630DE Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from [130.207.166.135] by smtp1.abraxis.com (NTMail 3.01.03) id mmealling; Tue, 8 Oct 1996 08:29:50 -0400 Received: from gw.home.vix.com (gw.home.vix.com [192.5.5.1]) by oit.gatech.edu (8.7.6/8.7.3) with ESMTP id IAA16683 for ; Tue, 8 Oct 1996 08:25:50 -0400 (EDT) Received: by gw.home.vix.com id DAA24663; Tue, 8 Oct 1996 03:30:02 -0700 (PDT) X-btw: vix.com is also gw.home.vix.com and vixie.sf.ca.us Received: by gw.home.vix.com id VAA25980; Mon, 7 Oct 1996 21:56:21 -0700 (PDT) Received: by wisdom.home.vix.com id AA10196; Mon, 7 Oct 1996 21:56:20 -0700 Message-Id: <9610080456.AA10196@wisdom.home.vix.com> To: bind-workers@vix.com Subject: 4.9.5 T6B Date: Mon, 07 Oct 1996 21:56:20 -0700 From: Paul A Vixie Sender: Precedence: bulk Reply-To: Paul A Vixie -----BEGIN PGP SIGNED MESSAGE----- This fixes all the nits reported for T4B. It adds NAPTR support. It is a release candidate. A complete revision history since 4.9.4-P1 is included below. Location: POSIX Checksum: 2039359057 2203287 MD5 Checksum: 5f7f9304bfe341493f5778baf25c14cb PGP Signature: - -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUAMlnd53cdkq6JcsfBAQEe5QQAkFtt+geItsx7XheeCF2YU0SHvw1iEQ7m LgH5/nWKyDhJHtjXZ4reuR06HwBnagrmEij4BBHRSsePKDCUhUp2uE3KFund9qfy Suul9poyinMPinpMVkImKFetTOJirNUrglUw8oA/0LBZrl2VV9GGcIX3a9XldybR EJX1Tm74CNo= =6Imd - -----END PGP MESSAGE----- --- 4.9.5-t6b released --- 740. [bug] dangling cname checking had a few memory leaks. 739. [func] SRV support made more complete; NAPTR support added. 738. [protocol] dangling CNAMEs are no longer considered format errors. 737. [bug] owner domain names like "*." were not considered valid. 736. [contrib] new version of contrib/host included. 735. [doc] added some text to shres/solaris/INSTALL. 734. [bug] loading a zone with a single line SOA RR killed following line. 733. [bug] priming could deadlock in odd cases. 732. [bug] SIGHUP now caught before initial zone load. 731. [bug] IP/TCP session logging now controlled by #ifdef DEBUG. 730. [port] untested HPUX 10 support added to top level Makefile. 729. [port] ultrix vs. _res_close(); ultrix wins. 728. [bug] several d_rcode references weren't #ifdef'd NCACHE. 727. [bug] SOA timer warnings now consistently logged at LOG_WARNING. 726. [protocol] added T_NAPTR as RR type 35, hoping the IANA concurs. --- 4.9.5-t5b released --- 725. [port] shared libraries should work on Linux now. 724. [bug] "dig @0 VERSION.BIND TXT CHAOS" had never been tested. 723. [port] Solaris 2.6 has AF_LINK but not sa_len. 722. [protocol] verify RdLength of A and AAAA RRs. 721. [port] missing include directories will be made during "install". 720. [port] solaris and sunos should use native assemblers with gcc. 719. [port] cleaned up some A/UX linkages. 718. [func] some SOA sanity checks were changed from errors to warnings. 717. [port] BSD/named/Makefile needed to have dmalloc.c reference removed. 716. [protocol] cnames and referrals were generating spurious log messages. 715. [port] ultrix PCC didn't like a =&, said it was ambigious somehow. --- 4.9.5-t4b released --- 714. [port] contrib/os2-emx now contains files nec'y for OS/2 (EMX). 713. [func] gethostbyname2(x, AF_INET6) now accepts address literals. 712. [bug] gethostbyname() wasn't seeing RES_USE_INET6 early enough. 711. [bug] nslookup was printing IPv6 addresses improperly. 710. [port] an alignment bug was found and fixed by Cray. 709. [bug] named-xfer was dumping core on incoming LOC RRs. 708. [protocol] primary zones are edited to make rrset ttl's coherent during loading. 707. [protocol] rrsets with coherent ttl's won't be overridden by new rrsets with incoherent ttl's. 706. [port] Ultrix portability restored. 705. [func] added "limit files XXX" to boot file. 704. [bug] trace generation code was getting unaligned accesses. 703. [contrib] added contrib/getkeyby, from gnu@toad.com. 702. [func] MAXDNAME is now 4*256+1 to allow for \000 and the NUL. 701. [bug] samedomain() wasn't paying attention to escapes. 700. [func] allow long text strings in T_X25 RRs. 699. [port] added base64.c to shres/*/Makefile. 698. [port] picked some lint out of tools/nslookup/getinfo.c. 697. [bug] we were calling isupper() without calling isascii() first. 696. [protocol] a new kind of bad referral is now caught and ignored. --- 4.9.5-t3b released --- 695. [func] Use delete_stale() in preference to delete_all() more often. 694. [func] DATUMREFCNT is no longer an option. 693. [port] fixed up the CPPFLAGS usage in the top level Makefile. 692. [port] fixed up the __ defines (for POSIX.3) in include/resolv.h. 691. [port] removed all uses of "ssize_t", the world is not ready for it. (fixed two latent signed/unsigned code bugs in the process.) --- 4.9.5-t3a released --- 690. [bug] the stale() and delete_all() calls in finddata() weren't respectful toward T_ANY and C_ANY queries. 689. [lint] miscellaneous compiler warnings were disappeared. 688. [func] handles insane/unreachable root servers a little better now. 687. [bug] T1A's core dumps from bad databufs should be all fixed now. 686. [func] overlong TXT strings should work again. 685. [port] updated compat/include/sys/cdefs.h to BSD 4.4-Lite (8.7) vers. 684. [doc] doc/i-d/* added. 683. [contrib] "nslint" added to contrib/. 682. [protocol] irrelevant authority information is now correctly ignored. 681. [func] DO_RELOAD Is no longer optional. 680. [cleanup] ALLOW_UPDATES is gone. 679. [port] some systems need _res to be in text rather than bss. 678. [port] -Dssize_t=int is gone; see portability.h. 677. [contrib] outdates #671; update to contrib/host version 960808. 676. [doc] formatting fix to man/named.man8. --- 4.9.5-t2a released --- 675. [lint] various. 674. [feature] support added for SRV RR (untested). 673. [protocol] added definitions for EID, NIMLOC, SRV, ATMA, and IXFR. 672. [bug] fixed decoding problem wrt AAAA in tools/nslookup/debug.c. 671. [bug] fixed formatting problem wrt TXT in contrib/host/host.c. --- 4.9.5-t1a released --- 670. [feature] added SIG and KEY RR support (without signature or verification). 669. [internal] name/number translations are now mostly table driven. 668. [feature] nslookup now has better[/different] error messages. 667. [feature] inet_neta(), inet_net_ntop(), inet_net_pton() added. 666. [bug] parent zone will be reloaded when a child zone changes. 665. [protocol] RETURNSOA logic has been refined, and now ships "enabled." 664. [protocol] cached RRsets are now completely flushed when new data arrives. 663. [port] IRIX shared libraries are now supported. 662. [port] SCO OSE5 support has been upgraded slightly. 661. [bug] insane root servers will now be handled correctly. 660. [bug] TXT RRs are now parsed and displayed in full RFC1035 form. 659. [port] UXP/DS is now supported in the top level Makefile. 658. [feature] BIND now checks that UDP checksums are enabled in the kernel. --- 4.9.4-p1 released --- -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBMlne33cdkq6JcsfBAQFeJgQA1cQhNKDYL6MJuZkKCyxUhcLlawwfbIDn acZOXkme0o/EYcAKQOvY1kaq5kx5V4HvWGdbrPqOaG0S/0QSuU04Fef7ZwIn3pl6 A1bNYPHQP+WZDb4kzWwE20jbWSXH7ZEl4N5XJxb+gPA6xKv0W9pNln6U9mK/+FRb KuPFNi474F8= =l3Ld -----END PGP SIGNATURE----- --------------31DA64A630DE-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA01576 for urn-ietf-out; Tue, 8 Oct 1996 08:36:59 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA01571 for ; Tue, 8 Oct 1996 08:36:56 -0400 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14095 (mail destined for urn-ietf@services.bunyip.com); Tue, 8 Oct 96 08:36:53 -0400 Received: from [192.71.220.107] (zap.swip.net [192.71.220.107]) by nic.cafax.se (8.8.Beta.2/8.8.Beta.2) with ESMTP id OAA23610; Tue, 8 Oct 1996 14:35:09 +0200 (MET DST) X-Sender: m-3329@mailbox.swip.net Message-Id: In-Reply-To: <96Oct8.005924pdt."2768"@golden.parc.xerox.com> References: (message from Patrik Faltstrom on Mon, 7 Oct 1996 21:30:40 PDT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 8 Oct 1996 14:33:55 +0200 To: Larry Masinter From: Patrik Faltstrom Subject: Re: [URN] advantages of NAPTR over PURLs Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com At 00.59 -0700 96-10-08, Larry Masinter wrote: >> The A record does not have a priority. MX-records do have that, >> A records does not. You can not change the spec of A-records. > >Tell me again why replicated services need to have 'a priority'. >What requirements does it help satisfy? Because the cost, performance or other issues. When using A-records the servers _have_ to be the same. When talking about URNs I personally would like to be able to host these kind of requirements, even though (or especially because of the fact that) we don't know everything about all future protocols or resolution services. >Are you saying that you'd expect NIS to work with NAPTR but not to >work with long A records? No, I don't expect to use NAPTR to be used in NIS. This was an example of a broken resolver system which have to be replaced. Because it has to be replaced anyway, it shows that the requirement of choosing PURLs because you can use existing resolver implementations is not always true. If you have to change the resolver anyway because of bugs, you can change to something that supports SRV and NAPTR. >PURLs >handle renaming of resources by letting you go to the PURL server and >tell the PURL server where the resource is now. > PURL -> URL -> resource >If the resource gets renamed, you change the PURL -> URL mapping. No >second level abstraction needed. It is needed if the service moves from one resolution protocol (HTTP) to something else because the resolution protocol is part of the PURL, which is not the fact with the NAPTR proposal. >This protocol uses DNS, but it is still a protocol. It has a syntax, >the syntax must be parsed, the syntax has no version information, the >syntax is not in itself widely implemented, might need to be changed, >etc. > >The PURL system also has a single protocol for finding an appropriate >resolution service. That protocol consists of doing a DNS A record >lookup on duns.resolver.purl.org, then picking one of the IP addresses >you get, and doing a HTTP request. You need both DNS and HTTP. Not only DNS. I trust the lifespan for DNS more than the lifespan for HTTP (i.e. not that HTTP will go away but might be replace with something else like LIFN resolvers). >While HTTP might not be 'long-lived', are you claiming that this >design of NAPTR is longer-lived, or should be? How long? On what >grounds to you evaluate longevity of protocols? There is "N2L", "N2C" >and "N2R", will there not be another kind of category of "N2X" for 20 >years? The only thing I claim is that the NAPTR proposal follows the URN requirements RFC better than the PURLs. Of course some of this is depending on what "trust" each one of us personally have for each one of the protocols that are used. I have just stated my personal opinion. >I'm just asking you to write down what the advantage actually is. >I understand and I'm willing to trust that there advantages, but you >should say. Let's say that I have a Whois++ server with all metadata of all documents we have on our www-server. That server is replicated into a LDAPv3 server so it also can be accessed via LDAPv3, and not only Whois++. Because of schema-definition problems, the Whois++ server is the primary server, so the Whois++ server should have higher priority than the LDAPv3 one (or vice versa). I.e. when mirroring data between servers -- especially when mirroring between servers with different access protocols which I think will be more and more common -- loss of data will happen. You also might loose data if you have a primary server and a secondary one outside a firewall etc. Just as with MX records, you should first try to access the internal server, and then the external one. >To reiterate a bit on the 'protocol' issue: it's always possible to >delegate to some other protocol in a 303 Location: response; at least, >though, if you force people to register "dunslink" and "rcds" as new >URL schemes, we'll have a mechanism for dealing with those tokens in a >standards-track way. This is true, but you do need then: DNS -> HTTP -> new_protocol Instead of DNS -> new_protocol >As you've specified it, there's no change-control >on what those tokens might mean: if there are two versions of >rcds, should NAPTR records upgrade all their records when the resolver >upgrades from rcds1 to rcds2? If there's a version skew between the >client rcds and the server rcds such that the server rcds can't >respond to the client's ancient rcds implementation, should the >rejection influence the handling of priorities? This should be something the one designing (choosing) the protocol used in the NAPTR records. If the rcds protocol is not backward compatible in future versions, that is obviously a bad choice for the use as resolution protocol. This is not something that should be part of the NAPTR framework. What the URN framework is, is a way of describing what the NAPTR framework have to handle, which in turn sets limitations and recommendations on the resolution protocols used. When using PURL, you have to use HTTP, which already today is changed. With NAPTR (and rcds for example) you have something that can use UDP for the whole resolution process which is more effective than using TCP and HTTP. > z3950r://isite.bogus.com/0123@ab125212312xx0A >and you refer to it with > urn:duns:002372413:annual-report-1997 > >you can still use PURLs to do it, by looking up > http://duns.resolver.purl.org/002372413:annual-report-1997 > >and getting back a > 303 > Location: z3950r://isite.bogus.com/0123@ab125212312xx0A Yes, _if_ you have both DNS and HTTP protocols part from the Z39.50 protocol. >Maybe one way to improve PURLs would be to have the 'redirect' message >in HTTP allow pattern-redirects. This is from my point of view something that might be needed anyway, but is an implementation problem and not a HTTP problem. Note that I am not saying that PURLs should go away, die or something like that. It works perfectly in some environments and solve tons of problem todays version of usage of URLs have. You have though to use HTTP and you have no priority (as two things missing). With NAPTR and SRV records, you can change the protocols aswell without using HTTP, i.e. with only the use of DNS, and that is for me something that is very important. DNS have been around some 7 years longer than HTTP. Regards, Patrik Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id DAA29158 for urn-ietf-out; Tue, 8 Oct 1996 03:59:51 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id DAA29153 for ; Tue, 8 Oct 1996 03:59:43 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12430 (mail destined for urn-ietf@services.bunyip.com); Tue, 8 Oct 96 03:59:41 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16670(5)>; Tue, 8 Oct 1996 00:59:39 PDT Received: by golden.parc.xerox.com id <2768>; Tue, 8 Oct 1996 00:59:24 PDT To: paf@swip.net Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com In-Reply-To: (message from Patrik Faltstrom on Mon, 7 Oct 1996 21:30:40 PDT) Subject: Re: [URN] advantages of NAPTR over PURLs From: Larry Masinter Message-Id: <96Oct8.005924pdt."2768"@golden.parc.xerox.com> Date: Tue, 8 Oct 1996 00:59:24 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com This sounds a bit more like a diatribe than I'd like.... I started out trying to get some explicit description of the advantages of NAPTR over what seems like a far simpler method (PURLs). > The A record does not have a priority. MX-records do have that, > A records does not. You can not change the spec of A-records. Tell me again why replicated services need to have 'a priority'. What requirements does it help satisfy? > This is just how things are implemented, especially when one > start using things that is not really DNS (NIS for example). > To be able to get around this problem -- we need a new resource > record type. Are you saying that you'd expect NIS to work with NAPTR but not to work with long A records? I vaguely remember a patch several years ago to the Sun NIS implementation to fix the problem with a server (merit.edu?) that had more A records than before. I think that to get around a bug in implementations of DNS, you need to fix the bug. >> I don't understand why www.purl.org must have a shorter lifetime than >> any NAPTR name. You just vow to not reassign the name. If you can't do >> that with ".org", then pick a new top level domain. > Because the NAPTR record is the second abstraction level you really > need to be able to handle renaming of resources on the net. I've stared at this, but it seems like you're saying that "you need it because you really need it". Why do you need a second abstraction level to be able to handle renaming of resources on the net? PURLs handle renaming of resources by letting you go to the PURL server and tell the PURL server where the resource is now. PURL -> URL -> resource If the resource gets renamed, you change the PURL -> URL mapping. No second level abstraction needed. > You also can handle other protocols than HTTP which makes the NAPTR > proposal (NAPTR records together with SRV records) much more long > lived. The NAPTR proposal has a single protocol for finding an appropriate resolution service. The NAPTR protocol suggests that looking up urn:duns:002372413:annual-report-1997 means a DNS NAPTR lookup on duns.urn.net, examining the syntax for tokens N2L/N2C/N2R, followed by another DNS lookup for the SRV record. This protocol uses DNS, but it is still a protocol. It has a syntax, the syntax must be parsed, the syntax has no version information, the syntax is not in itself widely implemented, might need to be changed, etc. The PURL system also has a single protocol for finding an appropriate resolution service. That protocol consists of doing a DNS A record lookup on duns.resolver.purl.org, then picking one of the IP addresses you get, and doing a HTTP request. While HTTP might not be 'long-lived', are you claiming that this design of NAPTR is longer-lived, or should be? How long? On what grounds to you evaluate longevity of protocols? There is "N2L", "N2C" and "N2R", will there not be another kind of category of "N2X" for 20 years? >> The DNS entries for resolver.purl.org already give you all the >> indirection you need. Why add more? > No, it does not give the information about priority and > protocol that is needed. We should not at all of the meetings > we had last year still be talking about NAPTR records which > forces everyone to change their resolvers if it was not needed. On 'priority', you haven't actually said why you need priority. In this paragraph you assert that you had a meeting where everyone agreed that priority was needed, but it's not apparent why URN resolution needs priority. That you talked about NAPTR records and decided you needed priority then still doesn't explain WHY you thought you needed it. I'm just asking you to write down what the advantage actually is. I understand and I'm willing to trust that there advantages, but you should say. To reiterate a bit on the 'protocol' issue: it's always possible to delegate to some other protocol in a 303 Location: response; at least, though, if you force people to register "dunslink" and "rcds" as new URL schemes, we'll have a mechanism for dealing with those tokens in a standards-track way. As you've specified it, there's no change-control on what those tokens might mean: if there are two versions of rcds, should NAPTR records upgrade all their records when the resolver upgrades from rcds1 to rcds2? If there's a version skew between the client rcds and the server rcds such that the server rcds can't respond to the client's ancient rcds implementation, should the rejection influence the handling of priorities? > The PURL methods do work for locating HTTP servers, IF you > name your resources exactly the way you point it out Larry, > i.e. that you do have a special namespace allocated for the > PURL names which does not have anything in common with the > hostname namespace. a) Are you claiming that PURL is limited to "locating HTTP servers"? The PURL method could work for locating any resource that can be located by a URL. The PURL method happens to use HTTP to do the location. However, if you have a report stored in a z39.50 server with URL z3950r://isite.bogus.com/0123@ab125212312xx0A and you refer to it with urn:duns:002372413:annual-report-1997 you can still use PURLs to do it, by looking up http://duns.resolver.purl.org/002372413:annual-report-1997 and getting back a 303 Location: z3950r://isite.bogus.com/0123@ab125212312xx0A b) "IF you name your resources exactly the way you point it out" This is the rub: PURLs don't have regular expression matching. And the DNS caching allows caching of patterns. > When coming to this conclusion, we did also think about the > need for different resolution protocols (to handle the case > when someone is running a resolution service for a publisher, > and who is responsible for what in the resolution process) The purl system is potentially recursive. You could redirect from one URL to another. So it allows multiple roles or a single one. NAPTR however seems to have only two roles: you either own the DNS entry and manipulate that, or else you own the resolver. That's an advantage, I suppose, but it seems less flexible. There's a performance issue, in that DNS records cache better, although TTL seems as risky as max-age in HTTP. Maybe one way to improve PURLs would be to have the 'redirect' message in HTTP allow pattern-redirects. Regards, Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA27517 for urn-ietf-out; Tue, 8 Oct 1996 00:31:56 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA27512 for ; Tue, 8 Oct 1996 00:31:17 -0400 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10993 (mail destined for urn-ietf@services.bunyip.com); Tue, 8 Oct 96 00:31:10 -0400 Received: from nic.cafax.se (paf@nic.cafax.se [193.12.122.42]) by nic.cafax.se (8.8.Beta.2/8.8.Beta.2) with SMTP id GAA23257; Tue, 8 Oct 1996 06:30:41 +0200 (MET DST) Date: Tue, 8 Oct 1996 06:30:40 +0200 (MET DST) From: Patrik Faltstrom X-Sender: paf@nic.cafax.se To: Larry Masinter Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] advantages of NAPTR over PURLs In-Reply-To: <96Oct7.191009pdt."2771"@golden.parc.xerox.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com On Mon, 7 Oct 1996, Larry Masinter wrote: > > > We can provide multiple A records for www.purl.org, but there is no > > way to do smart prioritization between the more and less capable > > hosts. > > Why is this easier to do with NAPTR records than A records? Could we > extend A records for HTTP servers so that you could do smart > prioritization? ("If this is such a great idea, why save it for > URNS"). The A record does not have a priority. MX-records do have that, A records does not. You can not change the spec of A-records. > > Depending on how the multiple A records are provided, there may also > > be an obscure error that truncates the list of responses. The NAPTR > > proposal will not suffer that error. > > Is this a bug in the implementation of DNS? If the bug is there for A > records, why wouldn't it be there for NAPTR records? Is this a design > error that could be fixed? This is just how things are implemented, especially when one start using things that is not really DNS (NIS for example). To be able to get around this problem -- we need a new resource record type. > > The real point of the NAPTR proposal is that it gives us a way to cope > > with names, such as www.purl.org, that should be long-lived but aren't. > > I don't understand why www.purl.org must have a shorter lifetime than > any NAPTR name. You just vow to not reassign the name. If you can't do > that with ".org", then pick a new top level domain. Because the NAPTR record is the second abstraction level you really need to be able to handle renaming of resources on the net. You also can handle other protocols than HTTP which makes the NAPTR proposal (NAPTR records together with SRV records) much more long lived. > The DNS entries for resolver.purl.org already give you all the > indirection you need. Why add more? No, it does not give the information about priority and protocol that is needed. We should not at all of the meetings we had last year still be talking about NAPTR records which forces everyone to change their resolvers if it was not needed. The PURL methods do work for locating HTTP servers, IF you name your resources exactly the way you point it out Larry, i.e. that you do have a special namespace allocated for the PURL names which does not have anything in common with the hostname namespace. When coming to this conclusion, we did also think about the need for different resolution protocols (to handle the case when someone is running a resolution service for a publisher, and who is responsible for what in the resolution process) and especially for priority between different servers with different access protocols. I.e. PURLS solves tons of problems with URLs that we have today, but it does not solve the requirements in the URN requirements paper. We have some people thinking that not even the NAPTR proposal does that -- and we have not claimed that NAPTR solves the URN naming problem. The URN's do solve the problem by later having functionality of grandfathering the NAPTR scheme into some other scheme later on -- when DNS is replaced :-) > >We are not talking about the same thing. One could assign PURLs such as > > ftp://purl.foo.com/whatever > >but once that PURL is assigned, we have to use FTP to resolve it. Since > >the NAPTR draft doesn't require the resolution protocol to be embedded in > >the identifier, we are free to offer multiple resolution protocols and to > >change them over time. This is an important point, since over time we > >will have increasingly efficient protocols. > > In the "PURL" method, the "resolution" is accomplished by using HTTP > to talk to the resolution service and (if what you do is a GET) > getting back a "303" response with a Location: header to do the > URN->URL mapping. This is exactly what one of the problems is. We think that DNS that have been around for some years is more stable than HTTP. What do you do with PURLs if HTTP is replaced with something else? Or if you have one primary server handling FTP and a secondary one using HTTP and a third HTTP++ (whatever that can be?). In the PURL scheme you _HAVE_ to have one primary protocol which is served on each one of the servers: ftp://purl.acme.com/ ===> Use FTP to connect to purl.acme.com purl.acme.com. IN A foo.acme.com purl.acme.com. IN A bar.acme.com Both of these servers _have_ to have ftp access and both _have_ to have the ability (if needed) to give a redirect to the protocol which is needed to access that perticular server. In the NAPTR proposal, each one of foo.acme.com and bar.acme.com can, part from being prioritized also use different access protocols. > > For PURLs, we not only have to know the identifier, we have to know > > what resolver to contact. We end up with things like: > > http://purl.bowker.com/isbn/1-56604-355-7 > > http://purl.agicoa.com/isan/9961231234567891 > > oh no! Clearly you only want to use the resolver.purl.org name. Or rather: http://purl.bowker.se/isbn/91-46-14140-5 http://purl.bowker.se/isbn/46-14140-5 http://purl.bowker.se/isbn/4614140-5 http://purl.bowker.se/isbn/46141405 http://purl.bowker.se/isbn/9146141405 ...which all might have to be supported if you use HTTP as access protocol (with todays HTTP backends which PURL uses). If you allow a different "ISBN-resolution-protocol" to be the access for ISBNs, which we can handle in the NAPTR proposal, we solving naming problems on the right level of the stack. Patrik Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA25760 for urn-ietf-out; Mon, 7 Oct 1996 22:11:08 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA25754 for ; Mon, 7 Oct 1996 22:10:59 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09898 (mail destined for urn-ietf@services.bunyip.com); Mon, 7 Oct 96 22:10:27 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <15478(7)>; Mon, 7 Oct 1996 19:10:23 PDT Received: by golden.parc.xerox.com id <2771>; Mon, 7 Oct 1996 19:10:09 PDT To: rdaniel@acl.lanl.gov Cc: urn-ietf@bunyip.com In-Reply-To: <2.2.32.19961007170633.006b019c@acl.lanl.gov> (message from Ron Daniel on Mon, 7 Oct 1996 10:06:33 PDT) Subject: [URN] advantages of NAPTR over PURLs From: Larry Masinter Message-Id: <96Oct7.191009pdt."2771"@golden.parc.xerox.com> Date: Mon, 7 Oct 1996 19:10:09 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com Ron & I have been offline, but I thought I'd move the discussion back onto list... It's not that I'm a PURL bigot, but I think www.purl.org has an interesting simplicity and that pushing on PURL vs. NAPTR really gets at what the _actual_ advantages might be. Re replication: > We can provide multiple A records for www.purl.org, but there is no > way to do smart prioritization between the more and less capable > hosts. Why is this easier to do with NAPTR records than A records? Could we extend A records for HTTP servers so that you could do smart prioritization? ("If this is such a great idea, why save it for URNS"). > Depending on how the multiple A records are provided, there may also > be an obscure error that truncates the list of responses. The NAPTR > proposal will not suffer that error. Is this a bug in the implementation of DNS? If the bug is there for A records, why wouldn't it be there for NAPTR records? Is this a design error that could be fixed? > The real point of the NAPTR proposal is that it gives us a way to cope > with names, such as www.purl.org, that should be long-lived but aren't. I don't understand why www.purl.org must have a shorter lifetime than any NAPTR name. You just vow to not reassign the name. If you can't do that with ".org", then pick a new top level domain. >>Well, www.purl.org can migrate, too, can't it? > I'm sorry I wasn't clear. By "migrating a resolver" I mean moving it onto > a machine that cannot be identified by the domain name that was used > for the earlier resolver, and terminating service on the original machine, > even if that machine remains up and running for other purposes. > So, no, www.purl.org cannot migrate according to my definition. (Better > terminology welcomed). If you want to be able to migrate PURL resolvers to other machines, you just assign a new IP address to the PURL resolver name. This is completely flexible. Don't use that DNS name for anything other than PURL resolution service. E.g., call it .resolver.purl.org instead of just www.purl.org. The DNS entries for resolver.purl.org already give you all the indirection you need. Why add more? >>> and the resolution process allows multiple protocols >>The URL in the 'Location:' header of purl.org's response need not be >>'http:'. >We are not talking about the same thing. One could assign PURLs such as > ftp://purl.foo.com/whatever >but once that PURL is assigned, we have to use FTP to resolve it. Since >the NAPTR draft doesn't require the resolution protocol to be embedded in >the identifier, we are free to offer multiple resolution protocols and to >change them over time. This is an important point, since over time we >will have increasingly efficient protocols. In the "PURL" method, the "resolution" is accomplished by using HTTP to talk to the resolution service and (if what you do is a GET) getting back a "303" response with a Location: header to do the URN->URL mapping. If you want "PURL" resolution to not be embedded in the URN, then define a translation from URN notation to PURL by, for example, defining that: : is (currently) implemented by translating it into http://.resolver.purl.org/' and now you have a resolution implementation that doesn't embed the resolution protocol in the name. Of course, you are free to offer other resolution protocols besides HTTP and change them over time. E.g., define that isbn:1-56604-355-7 => http://isbn.resolver.purl.org/1-56604-355-7 issn:1077-2014 => http://issn.resolver.purl.org/1077-2014 > For PURLs, we not only have to know the identifier, we have to know > what resolver to contact. We end up with things like: > http://purl.bowker.com/isbn/1-56604-355-7 > http://purl.agicoa.com/isan/9961231234567891 oh no! Clearly you only want to use the resolver.purl.org name. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA18126 for urn-ietf-out; Mon, 7 Oct 1996 11:55:28 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA18121 for ; Mon, 7 Oct 1996 11:55:24 -0400 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03947 (mail destined for urn-ietf@services.bunyip.com); Mon, 7 Oct 96 11:55:19 -0400 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id LAA01692; Mon, 7 Oct 1996 11:55:16 -0400 Message-Id: <199610071555.LAA01692@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Mon, 7 Oct 1996 11:55:15 -0400 In-Reply-To: Ron Daniel's message as of Oct 6, 21:45 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Ron Daniel , Larry Masinter Subject: Re: [URN] Re: The WG is putative no longer... Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com I think Larry brings up an important point about needing to make it clear what _this_ approach has going for it. [Ron wrote:] > I will make the mention of the benefits of the approach less subtle, but > I don't think the NAPTR spec should get into a comparison with PURLs. NAPTR > resolution achieves the benefits mentioned above because it follows the > principle of separating the design of the namespace from the resolution > procedure. This principle is part of the framework draft, and any > resolution mechanism that follows it can achieve equivalent benefits. > So, if we *have* to do a comparison with PURLs, I think the framework > draft is the place to do so. I agree that the NAPTR document is not the place to discuss PURLs directly - the purpose of the NAPTR document is to describe an implementation, not make a salespitch for the approach. If the framework document is written will, it definitely should make clear what problems this approach solves that PURLs do not solve by themselves. This is, perhaps, best addressed by making it increasingly clear what problem this approach does solve. Leslie. -- ------------------------------------------------------------------------------ Leslie Daigle "Learn and live." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ------------------------------------------------------------------------------ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA12465 for urn-ietf-out; Sun, 6 Oct 1996 23:39:11 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA12460 for ; Sun, 6 Oct 1996 23:38:39 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01259 (mail destined for urn-ietf@services.bunyip.com); Sun, 6 Oct 96 23:38:37 -0400 Received: from legiron.acl.lanl.gov (transitory55.lanl.gov [128.165.7.145]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id VAA15050; Sun, 6 Oct 1996 21:38:32 -0600 (MDT) Message-Id: <2.2.32.19961007034537.006b551c@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 06 Oct 1996 21:45:37 -0600 To: Larry Masinter From: Ron Daniel Subject: Re: [URN] Re: The WG is putative no longer... Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Larry Masinter (at least at 11:30 AM 10/5/96 PDT) >Ron & Michael: > >I'd like somewhere (either in this document or a separate one) for an >elaboration of what this mechanism brings over and above the simple >mechanism already deployed by www.purl.org. Hi Larry, I think the benefits of the NAPTR mechanism over PURLs are in the document, but they are not pulled together into a "benefits" section and there is no comparison with PURLs. The draft currently mentions that the NAPTR approach allows the resolvers, as well as the resources, to be replicated. (It is mentioned as a subtle but important point). The resolver(s) can also be migrated, and the resolution process allows multiple protocols. Migration is not explicitly mentioned. If memory serves, the abstract and intro call out the multi-protocol capability as a benefit, and also mention the ability to accommodate a variety of namespaces. I see all of these as advantages of the NAPTR approach over PURLs. (Backward compatibility with existing browsers is the advantage of PURLs over the NAPTR approach). I will make the mention of the benefits of the approach less subtle, but I don't think the NAPTR spec should get into a comparison with PURLs. NAPTR resolution achieves the benefits mentioned above because it follows the principle of separating the design of the namespace from the resolution procedure. This principle is part of the framework draft, and any resolution mechanism that follows it can achieve equivalent benefits. So, if we *have* to do a comparison with PURLs, I think the framework draft is the place to do so. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA09759 for urn-ietf-out; Sun, 6 Oct 1996 15:39:23 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA09754 for ; Sun, 6 Oct 1996 15:39:19 -0400 Received: from SMTP1.ABRAXIS.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00179 (mail destined for urn-ietf@services.bunyip.com); Sun, 6 Oct 96 15:39:17 -0400 Received: from [206.155.199.8] by smtp1.abraxis.com (NTMail 3.01.03) id aa051272; Sun, 6 Oct 1996 15:43:03 -0400 Message-Id: <32580C14.5DF3@internic.net> Date: Sun, 06 Oct 1996 15:44:20 -0400 From: Michael Mealling Organization: Network Solutions X-Mailer: Mozilla 3.0b7 (X11; I; SunOS 5.5 i86pc) Mime-Version: 1.0 To: Larry Masinter Cc: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] Re: The WG is putative no longer... References: <96Oct5.113050pdt."2757"@golden.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Michael Mealling Errors-To: owner-urn-ietf@bunyip.com Larry Masinter wrote: > I'd like somewhere (either in this document or a separate one) for an > elaboration of what this mechanism brings over and above the simple > mechanism already deployed by www.purl.org. > > Could you please elaborate either in this document or a companion? Umm...I'm writing several at this point. You'll have to remind me which one your talking about. If you're talking about the NAPTR draft then I doubt if it'd be appropriate since that's just an implementation of the framework. I think it would be more appropriate for the framework document myself. Is that an acceptable place to approach the subject? -MM -- ------------------------------------------------------------------------------ Michael Mealling | 505 Huntmar Park Drive | Phone: (703)742-0400 Software Engineer | Herndon, VA 22070 | Fax: (703)742-9552 Network Solutions | | michaelm@internic.net Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA29201 for urn-ietf-out; Sat, 5 Oct 1996 14:31:19 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA29196 for ; Sat, 5 Oct 1996 14:31:17 -0400 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27543 (mail destined for urn-ietf@services.bunyip.com); Sat, 5 Oct 96 14:31:15 -0400 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <14992(2)>; Sat, 5 Oct 1996 11:31:07 PDT Received: by golden.parc.xerox.com id <2757>; Sat, 5 Oct 1996 11:30:50 PDT To: rdaniel@acl.lanl.gov Cc: urn-ietf@bunyip.com In-Reply-To: <2.2.32.19961004190537.00706e48@acl.lanl.gov> (message from Ron Daniel on Fri, 4 Oct 1996 12:05:37 PDT) Subject: Re: [URN] Re: The WG is putative no longer... From: Larry Masinter Message-Id: <96Oct5.113050pdt."2757"@golden.parc.xerox.com> Date: Sat, 5 Oct 1996 11:30:50 PDT Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com Ron & Michael: I'd like somewhere (either in this document or a separate one) for an elaboration of what this mechanism brings over and above the simple mechanism already deployed by www.purl.org. Could you please elaborate either in this document or a companion? Thanks, Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA20445 for urn-ietf-out; Fri, 4 Oct 1996 14:59:24 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA20440 for ; Fri, 4 Oct 1996 14:58:56 -0400 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23342 (mail destined for urn-ietf@services.bunyip.com); Fri, 4 Oct 96 14:58:44 -0400 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA03429 for ; Fri, 4 Oct 1996 12:58:37 -0600 (MDT) Message-Id: <2.2.32.19961004190537.00706e48@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 04 Oct 1996 13:05:37 -0600 To: urn-ietf@bunyip.com From: Ron Daniel Subject: [URN] Re: The WG is putative no longer... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Putative no more ... yippie! Thus spoke Leslie Daigle (at least at 11:09 AM 10/4/96 -0400) > [...] documents that need to be revised/created [...] > . The NAPTR document. Ron promises another draft real soon. The current state of the draft is appended. The previous version is available from the Internet-drafts index as draft-daniel-naptr-01.txt. The working version will be available from http://www.acl.lanl.gov/URN/naptr.txt I'd like some discussion before submitting it to the Internet drafts editor. (I also need to clean up the references section). --------- INTERNET DRAFT Ron Daniel draft-ietf-urn-naptr-00.txt Los Alamos National Laboratory Michael Mealling Network Solutions, Inc. 4 Oct., 1996 [revisions since draft-daniel-naptr-01.txt: 1) Added substitution expression grammar and reference to POSIX Extended Regular Expressions instead of sentence saying "sed(1)-style substitution expression". 2) Added "hdl" and "rwhois" to list of known protocols. 3) Minor editing cleanups. 4) Added "P" flag 5) Added N2Ns 6) Changed order of "repl" and "regexp" fields to ease computation of compressed vs. uncompressed NAME sizes. 7) Changed name to reflect new WG status of URN effort. 8) Updated Michael's contact info 9) Added brief security consideration about checking regexps instead of blindly executing them. 10) Added note about why trailing '.' does not appear in examples but should be in the zone files. 11) Clarified stuff on provision of additional info 12) Clarified wildcard example ] Resolution of Uniform Resource Identifiers using the Domain Name System Status of this Memo =================== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft expires 7 April, 1997. Abstract: ========= Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. In addition to locating resolvers, the NAPTR provides for other naming systems to be grandfathered into the URN world, provides independence between the name assignment system and the resolution protocol system, and allows multiple services (Name to Location, Name to Description, Name to Resource, ...) to be offered. In conjunction with the SRV RR proposal [3], the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing. Introduction: ============= Uniform Resource Locators have been a significant advance in locating resources on the Internet. 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 to serve as persistent, location-independent identifiers for Internet resources in order to overcome most of the problems with URLs. RFC-1737 [1] sets forth requirements on URNs. Even if URN systems were in place now, there would still be a tremendous number of URLs. It should be possible to develop a URN resolution system that can also provide location independence for those URLs. This is related to the requirement in [1] to be able to grandfather in names from other naming systems, such as ISO Formal Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, etc. The developers of various URN proposals have held a series of meetings, resulting in a compromise known as the Knoxville framework. The major principle behind the Knoxville framework is that any name assignment hierarchy should be separate from the resolution hierarchy. This is in marked contrast to the Domain Name System, where the two are identical. Readers are referred to [2] for background on the Knoxville framework and for additional information on the context and purpose of this proposal. For the reasons mentioned earlier, we want to be able to resolve URNs and URLs within the same framework. 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, we have the requirement mentioned above about grandfathering of other name systems. Therefore our approach is to use DNS to locate "resolvers" that can provide information on individual resources, potentially including the resource itself. To accomplish this, we "rewrite" the URI into a domain name following the rules provided in NAPTR records. Rewrite rules provide considerable power, which is important when trying to meet the goals listed above. However, collections of rules can become difficult to understand. To lessen this problem, the NAPTR rules are *always* applied to the original URI, *never* to the output of previous rules. Locating a resolver through the rewrite procedure may take multiple steps, but the beginning is always the same. Every URI has a colon-delimited prefix. NAPTR resolution begins by taking this prefix, appending the well-known suffix ".urn.net", and querying the DNS for NAPTR records at that domain name. Based on the results of this query, zero or more additional DNS queries may be needed to locate resolvers for the URI. Three brief examples of this procedure are given in the next section. The NAPTR RR provides the level of indirection needed to keep the naming system independent of the resolution system, its protocols, and services. Coupled with the new SRV resource record proposal[3] there is also the potential for replicating the resolver on multiple hosts, overcoming some of the most significant problems of URLs. This is an important and subtle point. Not only do the NAPTR and SRV records allow us to replicate the resource, we can replicate the resolvers that know about the replicated resource. Preventing a single point of failure at the resolver level is a significant benefit. Terminology =========== "Must" or "Shall" - Software that does not behave in the manner that this document says it must is not conformant to this document. "Should" - Software that does not follow the behavior that this document says it should may still be conformant, but is probably broken in some fundamental way. "May" - Implementations may or may not provide the described behavior, while still remaining conformant to this document. Brief overview and examples of the NAPTR RR: ============================================ A detailed description of the NAPTR RR will be given later, but to give a flavor for the proposal we first give a simple description of the record and three examples of its use. The key fields in the NAPTR RR are order, preference, service, flags, regexp, and replacement: * The order field specifies the order in which records MUST be processed when multiple NAPTR records are returned in response to a single query. A naming authority may have delegated a portion of its namespace to another agency. Evaluating the NAPTR records in the correct order is necessary for delegation to work properly. * The preference field specifies the order in which records SHOULD be processed when multiple NAPTR records have the same value of "order". This field lets a service provider specify the order in which resolvers are contacted, so that more capable machines are contacted in preference to less capable ones. * The service field specifies the resolution protocol and resolution service(s) that will be available if the rewrite specified by the regexp or replacement fields is applied. Resolution protocols are the protocols used to talk with a resolver. They will be specified in other documents. Resolution services are operations such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC), etc. These are discussed in the URN Framework document[2], and their behavior in a particular resolution protocol will be given in the specification for that protocol. * The flags field contains modifiers that affect what happens in the next DNS lookup, typically for optimizing the process. * The regexp field is one of two fields used for the rewrite rules, and is the core concept of the NAPTR record. The regexp field is a String containing a sed-like substitution expression. (The actual grammar for the substitution expressions is given later in this draft). The substitution expression is applied to the original URN to determine the next domain name to be queried. The regexp field should be used when the domain name to be generated is conditional on information in the URI. If the next domain name is always known, which is anticipated to be a common occurrence, the replacement field should be used instead. * The replacement field is the other field that may be used for the rewrite rule. It is an optimization of the rewrite process for the case where the next domain name is fixed instead of being conditional on the content of the URI. The replacement field is a domain name (subject to compression if a DNS sender knows that a given recipient is able to decompress names in this RR type's RDATA field). If the rewrite is more complex than a simple substitution of a domain name, the replacement field should be set to . and the regexp field used. Note that the client applies all the substitutions and performs all lookups - this is not handled in DNS servers. Note also that there is no reason to provide values in both the replacement and regexp field. Only one should be specified. If a value is specified in both, the replacement name MUST be used and the regexp string MUST be ignored. It is the belief of the developers of this document that regexps should rarely be used. The replacement field seems adequate for the vast majority of situations. Regexps are only necessary when portions of a namespace are to be delegated to different resolvers. Example 1 --------- Consider a URN that uses the hypothetical DUNS namespace. DUNS numbers are identifiers for approximately 30 million registered businesses around the world, assigned and maintained by Dunn and Bradstreet. The URN might look like: urn:duns:002372413:annual-report-1997 The first step in the resolution process is to find out about the DUNS namespace. The namespace identifier, duns, is extracted from the URN, prepended to urn.net, and the NAPTRs for duns.urn.net looked up. It might return records of the form: duns.urn.net ;; order pref flags service regexp replacement IN NAPTR 100 10 "s" "dunslink+N2L+N2C" "" _dunslink._udp.isi.dandb.com IN NAPTR 100 20 "s" "rcds+N2C" "" _rcds._udp.isi.dandb.com IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" "" _http._tcp.isi.dandb.com The order field contains equal values, indicating that no name delegation order has to be followed. The preference field indicates that the provider would like clients to use the special dunslink protocol, followed by the RCDS protocol, and that HTTP is offered as a last resort. All the records specify the "s" flag, which will be explained momentarily. The service fields say that if we speak dunslink, we will be able to issue either the N2L or N2C requests to obtain a URL or a URC (description) of the resource. The Resource Cataloging and Distribution Service (RCDS)[7] could be used to get a URC for the resource, while HTTP could be used to get a URL, URC, or the resource itself. All the records supply the next domain name to query, none of them need to be rewritten with the aid of regular expressions. The general case might require multiple NAPTR rewrites to locate a resolver, but eventually we will come to the "terminal NAPTR". Once we have the terminal NAPTR, our next probe into the DNS will be for a SRV or A record instead of another NAPTR. Rather than probing for a non-existent NAPTR record to terminate the loop, the flags field is used to indicate a terminal lookup. If it has a value of "s", the next lookup should be for SRV RRs, "a" denotes that A records should sought. A "p" flag is also provided to indicate that the next action is Protocol-specific. Since our example RR specified the "s" flag, it was terminal. Our next action is to lookup SRV RRs for _rcds._udp.isi.dandb.com, which will tell us hosts that can provide the necessary resolution service. That lookup might return: ;; Pref Weight Port Target rcds._udp.isi.dandb.com IN SRV 0 0 1000 defduns.isi.dandb.com IN SRV 0 0 1000 dbmirror.com.au IN SRV 0 0 1000 ukmirror.com.uk telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their RCDS server. (The reader is referred to the SRV proposal [3] for the interpretation of the fields above). There is opportunity for significant optimization here. We can return the SRV records as additional information for terminal NAPTRs (and the A records as additional information for those SRVs). While this recursive provision of additional information is not explicitly blessed in the DNS specifications, it is not forbidden, and BIND does take advantage of it [4]. This is a significant optimization. In conjunction with a long TTL for *.urn.net records, the average number of probes to DNS for resolving DUNS URNs would approach one. Therefore, DNS server implementors SHOULD provide additional information with NAPTR responses. The additional information will be either SRV or A records. If SRV records are available, their A records may be provided as recursive additional information. Note that the example NAPTR records above are intended to represent the reply the client will see. They are not quite identical to what the domain administrator would put into the zone files. For one thing, the administrator should supply the trailing '.' character on replacement domain names. Example 2 --------- Consider a URI namespace based on MIME Content-Ids. The URN might look like this: urn:cid:199606121851.1@mordred.gatech.edu The first step in the resolution process is to find out about the CID namespace. The namespace identifier, cid, is extracted from the URN, prepended to urn.net, and the NAPTR for cid.urn.net looked up. It might return records of the form: cid.urn.net ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "/.+@([^@]+)/\1/i" . We have only one NAPTR response, so ordering the responses is not a problem. The replacement field is empty, so we check the regexp field and use the pattern provided there. We apply that regexp to the entire URN to see if it matches, which it does. The \1 part of the substitution expression returns the string "mordred.gatech.edu". Since the flags field does not contain "s" or "a", the lookup is not terminal and our next probe to DNS is for more NAPTR records: lookup(query=NAPTR, "mordred.gatech.edu"). While mordred could have its very own NAPTR, maintaining those records on all the machines at a site as large as Georgia Tech would be an intolerable burden. Instead, a wildcard may be used so that the domain administrator at Georgia Tech has only a single NAPTR record to maintain. That record might look like: *.gatech.edu IN NAPTR ;; order pref flags service regexp replacement IN NAPTR 100 50 "s" "z3950+N2L+N2C" "" _z3950._tcp.gatech.edu. IN NAPTR 100 50 "s" "rcds+N2C" "" _rcds._udp.gatech.edu. IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" _http._tcp.gatech.edu. (Unlike all the other example records in this draft, the one above is the contents of a zone file, not the response received by the client). Continuing with our example, we note that the values of the order and preference fields are equal in all records, so the client is free to pick any record. The flags field tells us that these are the last NAPTR patterns we should see, and after the rewrite (a simple replacement in this case) we should look up SRV records to get information on the hosts that can provide the necessary service. Assuming we prefer the Z39.50 protocol, our lookup might return: ;; Pref Weight Port Target _z3950._tcp.gatech.edu IN SRV 0 0 1000 z3950.gatech.edu IN SRV 0 0 1000 z3950.cc.gatech.edu IN SRV 0 0 1000 z3950.uga.edu telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their Z39.50 server. Users of regular expressions should note that there is a significant caveat about the use of backslashes in DNS zone files. DNS treats backslashes as the escape character so that '.' can be escaped when necessary. This means that when a regular expression is entered into the zone file, the backslashes must be escaped by another backslash. For the case of the cid.urn.net record above, the regular expression entered into the zone file should be "/.+@([^@]+)/\\1/i". When the client code actually receives the record, the pattern will have been converted to "/.+@([^@]+)/\1/i". Example 3 --------- As mentioned above, the NAPTR RR can also be used for URLs that have already been assigned. Assume we have the URL for a very popular piece of software that the publisher wishes to mirror at multiple sites around the world: http://www.foo.com/software/latest-beta.exe We extract the prefix, "http", and lookup NAPTR records for http.urn.net. This might return a record of the form http.urn.net IN NAPTR ;; order pref flags service regexp replacement 100 90 "" "" "/.*\/\/([^\/:]+)/\1/i" . This expression returns everything after the first double slash and before the next slash or colon. Backslashes are needed to escape the forward slash since the forward slash character is what separates the components of the substitution expression. (Recall from the previous example that in the zone file, this pattern actually needs to be entered as "/.*\\/\\/([^\\/:]+)/\\1/i"). Applying this pattern to the URL extracts "www.foo.com". Looking up NAPTR records for that might return: www.foo.com ;; order pref flags service regexp replacement IN NAPTR 100 100 "s" "http+L2R" "" _http._tcp.foo.com IN NAPTR 100 100 "s" "ftp+L2R" "" _ftp._tcp.foo.com Looking up SRV records for _http._tcp.foo.com would return information on the hosts that foo.com has designated to be its mirror sites. The client can then pick one for the user. NAPTR RR Format =============== The format of the NAPTR RR is given below. The DNS type code for NAPTR is 104. Domain TTL Class Order Preference Flags Service Regexp Replacement where: Domain The domain name this resource record refers to. TTL Standard DNS Time To Live field Class Standard DNS meaning Order A 16-bit integer specifying the order in which the NAPTR records MUST be processed to ensure correct delegation of portions of the namespace over time. Low numbers are processed before high numbers, and once a NAPTR is found that "matches" a URN, the client MUST NOT consider any NAPTRs with a higher value for order. Preference A 16-bit integer which specifies the order in which NAPTR records with equal "order" values SHOULD be processed, low numbers being processed before high numbers. This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. Flags A String giving flags to control aspects of the rewriting. Flags are single characters from the set [A-Z0-9]. The case of the alphabetic characters is not significant. At this time only three flags, "S", "A", and "P", are defined. "S" means that the next lookup should be for SRV records instead of NAPTR records. "A" means that the next lookup should be for A records. The "P" flag says that the remainder of the resolution shall be carried out in a Protocol-specific fashion, and we should not do any more DNS queries. The remaining alphabetic flags are reserved. The numeric flags may be used for local experimentation. The S, A, and P flags are all mutually exclusive, and resolution libraries MAY signal an error if more than one is given. We anticipate that multiple flags will be allowed in the future, so implementors MUST NOT assume that the flags field can only contain 0 or 1 characters. Service Specifies the resolution service(s) available down this rewrite path. It may also specify the particular protocol that is used to talk with a resolver. A protocol MUST be specified if the flags field states that the NAPTR is terminal. If a protocol is specified, but the flags field does not state that the NAPTR is terminal, the next lookup MUST be for a NAPTR. The client MAY choose not to perform the next lookup if the protocol is unknown, but that behavior MUST NOT be relied upon. The service field may take any of the values below (using the Augmented BNF of RFC 822[5]): service_field = [ [protocol] *("+" rs)] protocol = "rcds" / "http" / "hdl" / "rwhois" rs = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C" / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C" i.e. an optional protocol specification followed by 0 or more resolution services. Each resolution service is indicated by an initial '+' character. Note that the empty string is also a valid service field. This will typically be seen at the top levels of a namespace, when it is impossible to know what services and protocols will be offered by a particular publisher within that name space. At this time the known protocols are rcds[7], hdl[8] (binary, UDP-based protocols), http[11] (a textual, TCP-based protocol), and rwhois[10] (textual, UDP or TCP based). More will be allowed later. The names of the protocols must be formed from the characters [a-Z0-9]. Case of the characters is not significant. The service requests currently allowed are: N2L - Given a URN, return a URL N2Ls - Given a URN, return a set of URLs N2R - Given a URN, return an instance of the resource. N2Rs - Given a URN, return multiple instances of the resouce, typically encoded using multipart/alternative. N2C - Given a URN, return a collection of meta-information on the named resource. The format of this response is the subject of another document. N2Ns - Given a URN, return all URNs that are also identifers for the resource. L2R - Given a URL, return the resource. L2Ns - Given a URL, return all the URNs that are identifiers for the resource. L2Ls - Given a URL, return all the URLs for instances of of the same resource. L2C - Given a URL, return a description of the resource. The actual format of the service request and response will be determined by the resolution protocol, and is the subject for other documents. Protocols need not offer all services. Regexp A STRING containing a substitution expression that is applied to the original URI in order to construct the next name to lookup. The grammar of the substitution expression is given in the next section. Replacement The next NAME to query for NAPTR, SRV, or A records depending on the value of the flags field. As mentioned above, this may be compressed. Substitution Expression Grammar: ================================ The content of the regexp field is a substitution expression. True sed(1) substitution expressions are not appropriate for use in this application for a variety of reasons, therefore the contents of the regexp field MUST follow the grammar below: subst_expr = "/" ere "/" repl "/" *flags ere = POSIX Extended Regular Expression (see [9], section 2.8.4) repl = dns_str / backref / repl dns_str / repl backref dns_str = ...... which RFC can I cite for this? 1035 seems obsolete ..... backref = "\" 1POS_DIGIT flags = "i" DNS_CHAR = "_" / "0" / "1" / ... / "9" / "a" / ... / "z" POS_DIGIT = "1" / "2" / ... / "9" ; 0 is not an allowed backref value The result of applying the substitution expression to the original URI shall be a legal domain name. Since it is possible for the regexp field to be improperly specified, such that a non-conforming domain name can be constructed, client software SHOULD verify that the result is a legal domain name before making queries on it. Backref expressions "\N" in the repl portion of the substitution expression are replaced by the (possibly empty) string of characters enclosed by '(' and ')' in the ERE portion of the substitution expression. N is a single digit from 1 through 9, inclusive. It specifies the N'th backref expression, the one that begins with the N'th '(' and continues to the matching ')'. For example, the ERE (A(B(C)DE)(F)G) has backref expressions: \1 = ABCDEFG \2 = BCDE \3 = C \4 = F \5..\9 = error - no matching subexpression The "i" flag indicates that the ERE matching SHALL be performed in a case-insensitive fashion. Furthermore, any backref replacements MAY be normalized to lower case when the "i" flag is given. Advice to domain administrators: ================================ Beware of regular expressions. Not only are they a pain to get correct on their own, but there is the previously mentioned interaction with DNS. Any backslashes in a regexp must be entered twice in a zone file in order to appear once in a query response. More seriously, the need for double backslashes has probably not been tested by all implementors of DNS servers. We anticipate that urn.net will be the heaviest user of regexps. Only when delegating portions of namespaces should the typical domain administrator need to use regexps. On a related note, beware of interactions with the shell when manipulating regexps from the command line. Since '\' is a common escape character in shells, there is a good chance that when you think you are saying "\\" you are actually saying "\". Similar caveats apply to characters such as '*', '(', etc. The "a" flag allows the next lookup to be for A records rather than SRV records. Since there is no place for a port specification in the NAPTR record, when the "A" flag is used the specified protocol must be running on its default port. Usage ===== Pseudocode for a client routine using NAPTRs is given below: // // findResolver(URN) // Given a URN, find a host that can resolve it. // findResolver(string URN) { sprintf(key, "%s.urn.net", extractNS(URN)); // prepend prefix to urn.net do { rewrite_flag = false; terminal = false; if (key has been seen) { quit with a loop detected error } add key to list of "seens" records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key' sort NAPTR records by "order" field and "preference" field. n_naptrs = number of NAPTR records in response. j = 0; curr_order = records[j].order; max_order = records[n_naptrs-1].order; // Process current batch of NAPTRs according to "order" field. for (j=0; j < n_naptrs && records[j].order <= max_order; j++) { newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp); if (!newkey) // Skip to next record if the rewrite didn't match continue; // We did do a rewrite, shrink max_order to current value // so that delegation works properly max_order = naptr[j].order; // Will we know what to do with the protocol and services // specified in the NAPTR? If not, try next record. if(!isKnownProto(naptr[j].services)) { continue; } if(!isKnownService(naptr[j].services)) { continue; } // At this point we have a sucessful rewrite and we will know // how to speak the protocol and request a known resolution // service. Before we do the next lookup, check some // optimization possibilities. if (strcasecmp(flags, "S") || strcasecmp(flags, "P")) || strcasecmp(flags, "A")) { terminal = true; services = naptr[j].services; addnl = any SRV and/or A records returned as additional info for naptr[j]. } key = newkey; rewriteflag = true; break; } } while (rewriteflag && !terminal); // Did we not find our way to a resolver? if (!rewrite_flag) { report an error return NULL; } // Leave rest to another protocol? if (strcasecmp(flags, "P")) { return key as host to talk to; } // If not, keep plugging if (!addnl) { // No SRVs came in as additional info, look them up srvs = lookup(type=SRV, key); } sort SRV records by preference, weight, ... foreach (SRV record) { // in order of preference try contacting srv[j].target using the protocol and one of the resolution service requests from the "services" field of the last NAPTR record. if (successful) return (target, protocol, service); // Actually we would probably return a result, but this // code was supposed to just tell us a good host to talk to. } die with an "unable to find a host" error; } Notes: ====== - The "urn:" prefix is a matter of religious controversy. Client code should handle the cases when it is and is not present. Similarly, if regular expressions are used in NAPTR records, they should be immune to the presence or absence of an initial "urn:". - A client MUST process multiple NAPTR records in the order specified by the "order" field, it MUST NOT simply use the first record that provides a known protocol and service combination. - If a record at a particular order matches the URI, but the client doesn't know the specified protocol and service, the client SHOULD continue to examine records that have the same order. The client MUST NOT consider records with a higher value of order. This is necessary to make delegation of portions of the namespace work. The order field is what lets site administrators say "all requests for URIs matching pattern x go to server 1, all others go to server 2". (A match is defined as: 1) The NAPTR provides a replacement domain name 2) The regular expression matches the URN ) - When multiple RRs have the same "order", the client should use the value of the preference field to select the next NAPTR to consider. However, because of preferred protocols or services, estimates of network distance and bandwidth, etc. clients may use different criteria to sort the records. - If the lookup after a rewrite fails, clients are strongly encouraged to report a failure, rather than backing up to pursue other rewrite paths. - When a namespace is to be delegated among a set of resolvers, regexps must be used. Each regexp appears in a separate NAPTR RR. Administrators should do as little delegation as possible, because of limitations on the size of DNS responses. - Note that SRV RRs impose additional requirements on clients. Acknowledgments: ================= The authors would like to thank Keith Moore for all his consultations during the development of this draft. We would also like to thank Paul Vixie for his assistance in debugging our implementation, and his answers on our questions. References: =========== [1] RFC-1737 "Functional Requirements for Uniform Resource Names", Karen Sollins and Larry Masinter, Dec. 1994. [2] draft-daigle-urn-framework-00.txt "A Uniform Resource Naming Framework", Leslie Daigle and Patrik Faltstrom, June, 1996. [3] draft-gulbrandsen-dns-rr-srvcs-03.txt " A DNS RR for specifying the location of services (DNS SRV)", Arnt Gulbrandsen and Paul Vixie, March 1996. [4] Paul Vixie, personal communication. [5] RFC-822 "Standard for the Format of ARPA Internet Text Messages", Dave H. Crocker, August 1982. [6] Keith Moore, personal communication. [7] Keith Moore, "Resource Cataloging and Distribution Service", ??? (insert as [4], renumber the others?) [8] Charles Orth, Bill Arms; Handle Resolution Protocol Specification, http://www.handle.net/docs/client_spec.html [9] IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1); IEEE Std 1003.2-1992; The Institute of Electrical and Electronics Engineers; New York; 1993. ISBN:1-55937-255-9 [10] ... rwhois spec ... [11] ... encoding resolution service requests in HTTP... Security Considerations ======================= The use of "urn.net" as the registry for URN namespaces is subject to denial of service attacks, as well as other DNS spoofing attacks. The interactions with DNSSEC are currently being studied. It is expected that NAPTR records will be signed with SIG records once the DNSSEC work is deployed. The rewrite rules make identifiers from other namespaces subject to the same attacks as normal domain names. Since they have not been easily resolvable before, this may or may not be considered a problem. Regular expressions should be checked for sanity, not blindly passed to something like PERL. Author Contact Information: =========================== Ron Daniel Los Alamos National Laboratory MS B287 Los Alamos, NM, USA, 87545 voice: +1 505 665 0597 fax: +1 505 665 4939 email: rdaniel@lanl.gov Michael Mealling Network Solutions 505 Huntmar Park Drive Herndon, VA 22070 voice: (703) 742-0400 fax: (703) 742-9552 email: michaelm@internic.net URL: http://www.netsol.com/ This draft expires 7 April, 1997. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA18220 for urn-ietf-out; Fri, 4 Oct 1996 11:10:05 -0400 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA18215 for ; Fri, 4 Oct 1996 11:10:01 -0400 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20916 (mail destined for urn-ietf@services.bunyip.com); Fri, 4 Oct 96 11:09:59 -0400 From: Leslie Daigle Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id LAA00559 for urn-ietf@bunyip.com; Fri, 4 Oct 1996 11:09:59 -0400 Date: Fri, 4 Oct 1996 11:09:59 -0400 Message-Id: <199610041509.LAA00559@beethoven.bunyip.com> To: urn-ietf@bunyip.com Subject: [URN] The WG is putative no longer... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Leslie Daigle Errors-To: owner-urn-ietf@bunyip.com Well, the rate of subscription to the mailing list has dropped off, so it seems like a good time to get the ball rolling under our new _official_ guise as the IETF URN Working Group. I've attached the announcement in case anyone missed it -- it includes our official charter. (I will also be updating the web page, http://www.bunyip.com/research/ietf/urn-ietf/, just as soon as I get a few minutes to swap in the scanty shreds of basic HTML that I know...). After the Montreal BOF, the draft WG charter was submitted for consideration by the Area Directors, and refinements (per the usual criteria of achievability and viability) followed. The resultant charter holds the spirit of what was in the Montreal BOF, but has the further benefit of addressing a few issues raised by the IESG. [Hey, I wasn't _at_ the discussions, I can blissfully assume it was only a few :-) ] To recap briefly, what we have on the table is an abstract framework, or architecture, for URN resolution. It identifies basic system components and their responsibilities in the process, with a view to being able to accommodate as many namespaces as possible, while applying the minimal amount of interoperability infrastructure necessary to be able to call these names "uniform". Separately, we also have one concrete proposal for one system that implements this abstract architecture -- the NAPTR work. This is a flagship implementation to demonstrate that URNs can work _today_. Also, we have a separate paper that was prepared independently of the above work, which provides some important considerations for any system attempting to do URN resolution -- some of which have already been discussed (at the BOF, on this list, etc). The purpose of this working group, then, is to refine the description of the abstract framework, see one system specified (NAPTR), and enough component pieces to demonstrate the concept. To that end, there are 3 documents that need to be revised/created nownow: . The framework document. This document needs to be fleshed out. . The NAPTR document. Ron promises another draft real soon. . The syntax document. Any volunteers to write up what should be a very short document outlining the components of the URN syntax? Anyone who wishes to volunteer, send me an e-mail. In general, the documents that we're chartered to write are as follows: URN Framework document: Overview of the basic components necessary to support this approach to URN resolution/management. In addition to sketching out the basic architecture, this includes descriptions of the minimal requirements of the components (including namespaces). NAPTR proposal: A specific proposal for an implementation of the approach. Syntax document: The URN syntax, so that we have agreement about what is opaque and what is not. This should be a _real_ short document. N2L/N2R/etc document: What gets returned upon reslution of URNs. New Namespace document: While the Framework document lays out the requirements of namespaces, each namespace that will be used in URNs needs to be formally described in terms of how it meets the requirements, and how it is used in the URN space. The first step, then, is to present a sample new namespace (e.g., "inet"). Grandfathered Namespace document: One of the goals of URNs is to be able to support existing namespaces. Thus, we need to demonstrate the feasibility by writing out the spec for including one such existing namespace in URN form. While we get rolling on refinements of the system documents, it's worth determining which new/old namespaces we'll address (and volunteers!). That's pretty much it, and the layout of the work ahead... Sound like a plan? Cheers! Leslie. ====================================== Uniform Resource Names (urn) ---------------------------- Chair(s): Leslie Daigle John Curran Applications Area Director(s): Keith Moore Harald Alvestrand Area Advisor Harald Alvestrand Mailing lists: General Discussion:urn-ietf@bunyip.com To Subscribe: majordomo@bunyip.com In Body: In body of message: subscribe urn-ietf Archive: ftp://ftp.bunyip.com/pub/mailing-lists/urn-ietf.archive Description of Working Group: The goal of this working group is to define both a Uniform Resource Name (URN) framework and an initial set of components that fit this framework. URNs are persistent identifiers for information resources. The output of this Working Group will comply with RFC 1737, which defines URNs and gives requirements for them. The framework will define the mechanics for enabling global scope, persistence, and legacy support requirements of URNs; requirements for namespaces to support this structure will also be defined. Although the framework will allow URNs to be defined that vary in terms of degree of scalability and persistance, ensuring "user friendliness" of all resultant identifiers is beyond the scope of this group. This WG will define the framework for URNs, at least one resolution registry system, and at least one namespace. RFCs describing additional material will also be developed (per the milestones, below). Input documents: o A Framework for the Assignment and Resolution of Uniform Resource Names o Resolution of Uniform Resource Identifiers using the Domain Name System o Requirements for URN Resolution Systems Goals and Milestones: Oct 96 Submit revision of URN Framework document as Internet-Draft. Oct 96 Submit revised version of the NAPTR proposal as an Internet-Draft. Oct 96 Submit Syntax document as an Internet-Draft. Oct 96 Submit document detailing the N2L/N2R/etc resolution results as an Internet-Draft. Nov 96 Submit document describing one (new) namespace as an Internet-Draft. Dec 96 Submit paper outlining grandfathering one namespace into the framework as an Internet-Draft. Dec 96 Submit revised N2L/N2R/etc document as an Internet-Draft. Dec 96 Submit NAPTR proposal to IESG as Experimental RFC. Submit Framework document to IESG for publication as an RFC. Submit syntax paper to IESG for publication as an RFC. Feb 97 Submit revised new Namespace document as Internet-Draft. Feb 97 Submit revised grandfather namespace document as Internet-Draft. Feb 97 Submit N2L/N2R/etc document to IESG for publication as RFC. Mar 97 Submit grandfathered namespace paper to IESG for publication as RFC. Submit new namespace proposal to IESG for publication as RFC. -- ------------------------------------------------------------------------------ Leslie Daigle "Learn and live." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ------------------------------------------------------------------------------ ------------------------------------------------------------------------------ Leslie Daigle "Learn and live." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ------------------------------------------------------------------------------ 1996-110000666000003600000100000011347306251045403010603 0ustar wwwrunwww Received: from cnri by ietf.org id aa11347; 4 Nov 96 13:35 EST Received: from uscore.xtdl.com by CNRI.Reston.VA.US id aa17633; 4 Nov 96 13:35 EST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA05733 for ; Mon, 4 Nov 1996 13:33:27 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 4 Nov 1996 13:30:13 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA05492 for pwg-outgoing; Mon, 4 Nov 1996 13:27:09 -0500 (EST) Message-Id: <01BBCA43.0011B280@hpb15767.boi.hp.com> From: Bob Pentecost To: "'Wright, Don PWG'" , "'Hastings, Tom (PWG)'" , "'Young, Lloyd PWG'" , "'Turner, Randy (PWG)'" Cc: 'PWG' Subject: Printer MIB Date: Mon, 4 Nov 1996 11:26:18 -0700 Encoding: 87 TEXT Sender: owner-pwg@pwg.org Thanks to Randy for getting the Printer MIB updated. I looked for a change that I expected and found that it had not been made. When I checked the October meeting minutes, I couldn't find a record of the discussion I had in my own notes. From my notes I have: Input Switching Group This is a new group of objects that was added to provide timeouts for manual feed operations. The group will be generalized to provide timeouts for all media load requests. InputManualFeedTimeout will become InputMediaLoadTimeout. Tom H. will post the changes. Does anyone recall this discussion? Looking further I found that the items covered at the October meeting didn't make it into the document. Specifically, from the meeting minutes: Discussion Items: Pentecost/HP The following is from a MIB review held at HP. ------------------- 1. 2.2.13.4, third paragraph: After "... it removes the corresponding leading edge event." add "Removing the leading edge entry may cause the unary change event alertRemovalOfBinaryChangeEntry to be added to the ta ble."2. Appendix A: Add definitions for: spot color, process color, impressions. 3. Appendix E: Update authors & addresses; add Binnur Al-Kazily as an author.4. Appendix A: Collation description should read "...placing the pages from separate copies into separate ordered sets, ready for binding." By including "separate output bins" the definition is unnecessarily restrictive. 5. Item deleted (already fixed). 6. prtInputMediaType: The object "prtInputMediaColor" indicates that the implementor is free to add additional string values as long as they follow a certain naming convention. This object makes no such mention. Does this imply that the implementor may NOT add additional strings? 7. prtOutputPageCollated: Description should be continued with "Collation is the process by which multiple copy output places the pages from separate copies into separate ordered sets, ready for binding". 8. prtOutputOffsetStacking: Description should be continued with "Offset stacking is the process by which output pages are physically displaced in order to separate them" 9. prtMediaPathMaxSpeed: If using "impressions per hour" unit of measure, there is no indication of the size of paper that will deliver that performance. This number is meaningful only for a specific (but unspecified) size of paper. 10. prtInterpreterLangFamily: Remove the sentence "This type 2 list of enumerations requires review before additional entries are made." -------------------- The following are the results/decision relating to the above items: #1. Approved, add sentence after 3rd sentence in 2.2.13.4. #2. Approved, Spot Color, Process Color and Impressions will be written by Tom Hastings and sent to the mailing list. #3. Approved, authors and participants will be updated by Don Wright and forwarded to the editor. #4, Approved #5. Already done. #6. Approved. Add workding about ISO9070 from prtInputMediaColor to prtInputMediatype something like "Implementors may add additional string values. The naming conventions in ISO 9070 are recommended in order to avoid potential name clashes." to end of prtInputMediaType description. #7. Approved. Add definition of collation from the glossary. #8. Approved. Add definition of offset stacking from the glossary. #9. Rejected. Good idea but impractical to implement differently. Most implementors will spec this based on Letter or A4 paper. #10. Approved because this information is already stated elsewhere. The following are considered to be typos and will be fixed by the editor unless he discovers them to be otherwise. ----------------------------- I didn't check the complete list of typos, but it appeared that some were fixed and some were not. While these changes are of a clarifying nature I believe that they should be in the document, especially in light of the fact that we spent meeting time to approve them. Bob Pentecost HP   Received: from cnri by ietf.org id aa04031; 5 Nov 96 13:08 EST Received: from uscore.xtdl.com by CNRI.Reston.VA.US id aa15881; 5 Nov 96 13:08 EST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA08066 for ; Tue, 5 Nov 1996 13:04:40 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 5 Nov 1996 13:00:26 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id MAA07822 for pwg-outgoing; Tue, 5 Nov 1996 12:56:07 -0500 (EST) Message-Id: <9611051757.AA17461@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Nov 1996 09:54:19 PST To: rturner@sharplabs.com From: Tom Hastings Subject: Re: Printer MIB Draft Cc: pwg@pwg.org Sender: owner-pwg@pwg.org Randy, I can read the .pdf file fine. However, when I tried to open the .doc file that you posted and got the error message that WORD could not open the file. Any chance of re-saving the .doc file as word version 6.0, so that those of us with windows 3.1 can see the revision marks? Thanks, Tom At 16:02 11/01/96 PST, you wrote: >I will post a new version of the MIB draft on the PWG FTP server >over the weekend. It should be ready for download actually on >Sunday 11/3 (P.M.) > >The document is formatted as an internet-draft (I-D) so don't be >alarmed about formatting. The base content is still the same. > >However, internet-draft format requires that I add an abstract >(a quick 1 to 3 paragraphs) about what this document is. We >really don't have a quick description of this in our MIB document >already, so I have taken the liberty (actually editorial license) >to add one. Please review the text of this abstract but don't >spend alot of time on it since it will not show up in the final >draft standard RFC anyway. This is just to meet Internet-Draft >guidelines. > >All the changes from the August and September meeting minutes >will be included in this document, including the results of the >teleconferences. > >Again, the draft will be uploaded by noon Sunday 11/3. > >Happy reviewing > >Rt. > >   Received: from cnri by ietf.org id aa08771; 5 Nov 96 13:54 EST Received: from uscore.xtdl.com by CNRI.Reston.VA.US id aa16929; 5 Nov 96 13:54 EST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id NAA09004 for ; Tue, 5 Nov 1996 13:52:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 5 Nov 1996 13:50:27 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id NAA08757 for pwg-outgoing; Tue, 5 Nov 1996 13:46:30 -0500 (EST) Message-Id: <9611051846.AA17503@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Nov 1996 10:44:01 PST To: Bob Pentecost From: Tom Hastings Subject: Re: Printer MIB [and my action item on InputSwitchingGroup] Cc: "'Wright, Don PWG'" , "'Young, Lloyd PWG'" , "'Turner, Randy (PWG)'" , 'PWG' Sender: owner-pwg@pwg.org At 10:26 11/04/96 PST, Bob Pentecost wrote: >Thanks to Randy for getting the Printer MIB updated. > >I looked for a change that I expected and found that it had not been made. >When I checked the October meeting minutes, I couldn't find a record of the >discussion I had in my own notes. From my notes I have: > >Input Switching Group > >This is a new group of objects that was added to provide timeouts for >manual feed operations. The group will be generalized to provide timeouts >for all media load requests. InputManualFeedTimeout will become >InputMediaLoadTimeout. Tom H. will post the changes. My notes also show the we changed the name of the prtInputManualFeedTimeout object to prtInputMediaLoadTimeout, but the name of the group remains Input Switching Group. I think we can also delete the phrase: which translates to 'this input subunit doesn't support manual feed'" in the sentences: The event which causes the printer to enter the waiting state is product specific. A value of (-1) implies 'other' or 'infinite" which translates to 'this input subunit doesn't support manual feed'. A value of (-2) implies 'unknown'. I was unable to open either the August or the current draft, since I suspect that it is WORD version 7.0 and I am running windows 6.0 on 3.11 windows. I'm sorry that I was unable to submit the actual changes as agreed in NYC. I hope that the above helps. Randy, If you could use SAVE AS and save the .doc as word version 6.0 then I could make the changes (in this section only) and re-post this section separately. Or you can make the edits. Tom > > >Does anyone recall this discussion? > > >Looking further I found that the items covered at the October meeting >didn't make it into the document. Specifically, from the meeting minutes: > >Discussion Items: Pentecost/HP >The following is from a MIB review held at HP. >------------------- >1. 2.2.13.4, third paragraph: After "... it removes the corresponding leading edge event." add "Removing the leading edge entry may cause the unary change event alertRemovalOfBinaryChangeEntry to be added to the ta ble." 2. Appendix A: Add definitions for: spot color, process color, impressions. > 3. Appendix E: Update authors & addresses; add Binnur Al-Kazily as an author. 4. Appendix A: Collation description should read "...placing the pages from >separate copies into separate ordered sets, ready for binding." By including "separate output bins" the definition is unnecessarily restrictive. >5. Item deleted (already fixed). > >6. prtInputMediaType: The object "prtInputMediaColor" indicates that the >implementor is free to add additional string values as long as they follow >a certain naming convention. This object makes no such mention. Does this >imply that the implementor may NOT add additional strings? > >7. prtOutputPageCollated: Description should be continued with "Collation >is the process by which multiple copy output places the pages from separate >copies into separate ordered sets, ready for binding". > >8. prtOutputOffsetStacking: Description should be continued with "Offset >stacking is the process by which output pages are physically displaced in >order to separate them" > >9. prtMediaPathMaxSpeed: If using "impressions per hour" unit of measure, >there is no indication of the size of paper that will deliver that >performance. This number is meaningful only for a specific (but >unspecified) size of paper. > >10. prtInterpreterLangFamily: Remove the sentence "This type 2 list of >enumerations requires review before additional entries are made." >-------------------- > >The following are the results/decision relating to the above items: >#1. Approved, add sentence after 3rd sentence in 2.2.13.4. >#2. Approved, Spot Color, Process Color and Impressions will be written by >Tom Hastings and sent to the mailing list. >#3. Approved, authors and participants will be updated by Don Wright and >forwarded to the editor. >#4, Approved >#5. Already done. >#6. Approved. Add workding about ISO9070 from prtInputMediaColor to >prtInputMediatype something like "Implementors may add additional string >values. The naming conventions in ISO 9070 are recommended in order to >avoid potential name clashes." to end of prtInputMediaType description. >#7. Approved. Add definition of collation from the glossary. >#8. Approved. Add definition of offset stacking from the glossary. >#9. Rejected. Good idea but impractical to implement differently. Most >implementors will spec this based on Letter or A4 paper. >#10. Approved because this information is already stated elsewhere. > >The following are considered to be typos and will be fixed by the editor >unless he discovers them to be otherwise. > >----------------------------- > > >I didn't check the complete list of typos, but it appeared that some were >fixed and some were not. > > >While these changes are of a clarifying nature I believe that they should >be in the document, especially in light of the fact that we spent meeting >time to approve them. > >Bob Pentecost >HP > > > > > >   Received: from cnri by ietf.org id aa23803; 7 Nov 96 21:34 EST Received: from uscore.xtdl.com by CNRI.Reston.VA.US id aa28680; 7 Nov 96 21:34 EST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id VAA14867 for ; Thu, 7 Nov 1996 21:32:45 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Thu, 7 Nov 1996 21:31:06 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id VAA14627 for pwg-outgoing; Thu, 7 Nov 1996 21:29:18 -0500 (EST) From: Yuki@kei-ca.ccmail.compuserve.com Date: 07 Nov 96 21:28:15 EST To: pwg@pwg.org, rturner@sharplabs.com, lpyoung@lexmark.com MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Subject: Request for modification on the draft Message-ID: <961108022814_702420.204300_BHD50-11@CompuServe.COM> Sender: owner-pwg@pwg.org Please add one line to the following on page 29. langPrescribe(50), -- Page description and printer control -- language. It can be described with -- ordinary ASCII characters. -- Technical reference manual: -- "PRESCRIBE II Programming Manual" To langPrescribe(50), -- Page description and printer control -- language. It can be described with -- ordinary ASCII characters. -- Technical reference manual: -- "PRESCRIBE II Programming Manual" -- Kyocera Corporation Thank you Atsushi Yuki Kyocera   Received: from cnri by ietf.org id aa05060; 12 Nov 96 16:17 EST Received: from uscore.xtdl.com by CNRI.Reston.VA.US id aa22667; 12 Nov 96 16:17 EST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id QAA12380 for ; Tue, 12 Nov 1996 16:15:13 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 12 Nov 1996 16:13:02 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id QAA12125 for pwg-outgoing; Tue, 12 Nov 1996 16:10:49 -0500 (EST) Date: Wed, 13 Nov 1996 13:26:34 -0800 Message-Id: <199611132126.NAA10398@gate.dpc.com> From: rbergma@dpc.com To: "GATE pwg@pwg.org"@gate.dpc.com, "GATE rturner@sharplabs.com"@gate.dpc.com Subject: PWG Open Issues with Printer MIB Internet-Draft Sender: owner-pwg@pwg.org Randy, The following items were not corrected in the November internet- draft of the Printer MIB. I have not seen any discussion on these issues, so I assume that they were not rejected. (The page numbers are relative to the draft document without revisions indicated.) page #13: There are now two definitions of Busy. page #17: The title of 2.2.13.3 should be "Alert Table" (no "s") The second sentence of 2.2.13.2 should read "This section provides an overview..." (not "...and overview...") page #18: The title of 2.2.13.5 should be "Traversing the Alert Table". Also, the text for this paragraph is missing. page #33,34: The following PrtChannelTypeTC enums were to be removed since they do not fit (even our kitchen sink) definition of a channel type. (This was the conclusion in the Montreal meeting.) chDCERemoteProcCall(22) chONCRemoteProcCall(23) chOLE(24) chNamedPipe(25) chDLLAPI(29) chVxDAPI(30) page #38: The following two entries were to be removed, since they were not a part of RFC 1759. interpreterContextSavingOn(1512), interpreterContextSavingOff(1513), page #77: There is a blank line in the description for the object prtConsoleDisplayBufferEntry. page #77: The end of the description of prtConsoleDisplayBufferIndex should read: "...values are normally expected to remain stable across successive power cycles." page #78: Same as above for prtConsoleLightIndex Ron Bergman Dataproducts Corp rbergma@dpc.com   Received: from cnri by ietf.org id aa08266; 15 Nov 96 17:07 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa21640; 15 Nov 96 17:07 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA19101 for uri-out; Fri, 15 Nov 1996 16:17:02 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA19092; Fri, 15 Nov 1996 16:16:59 -0500 Received: from ns.alis.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01031 (mail destined for urn-ietf@services.bunyip.com); Fri, 15 Nov 96 16:16:42 -0500 Received: from fyergeau.alis.com ([207.81.28.17]) by genstar.alis.ca (8.7.5/8.7.3) with SMTP id QAA28482; Fri, 15 Nov 1996 16:16:05 -0500 (EST) Message-Id: <2.2.32.19961115211148.006eb9e0@genstar.alis.ca> X-Sender: yergeau@genstar.alis.ca X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 15 Nov 1996 16:11:48 -0500 To: Ron Daniel From: Francois Yergeau Subject: Re: [URN] URI internationalization Cc: urn-ietf@bunyip.com, uri@bunyip.com Content-Transfer-Encoding: quoted-printable Sender: owner-uri@bunyip.com Precedence: bulk [Cross-posted to URI list, from URN-IETF list] =C0 09:05 15-11-96 -0700, Ron Daniel a =E9crit : >I think I18N for URLs is a more difficult problem than it has been for >URNs. We have a large number of existing URLs in a variety of character >sets. Well, no, it appears we don't really have that. I made a search for non-ASCII URLs last spring (both 8-bit octets and %XY with X>=3D8), and f= ound very few out on the Web (cf. ). Less than 0.25% in fact, and then some were typos (divide signs instead of tilde, f= or instance) that didn't work until corrected by hand. Furthermore, compatibility is made easier by the fact that UTF-8 data can= be quite reliably recognized as such. Given a UR*, a server can test it for UTF-8 validity; if it fails, it's some 'old' UR* in some encoding other t= han UTF-8, the server can process as it did before and nothing is broken; if = it passes, just process as UTF-8. A little experimentation (need more) show= s that false positives are unlikely, provided one takes care of 7-bit ISO-2022-like encodings that look like ASCII (and thus UTF-8) but are not. As for complexity, a UTF-8 validator fits in about 20 lines of C. >While I18N for URLs is a legitimate issue, it is not an issue for the >URN-WG (IMHO). The URI list is still alive, that might be the proper >place to begin discussions. Agreed, I cross-posted there. Please limit replies to the URI list. Regards, --=20 Fran=E7ois Yergeau Alis Technologies Inc., Montr=E9al T=E9l : +1 (514) 747-2547 Fax : +1 (514) 747-2561   Received: from ietf.org by ietf.org id aa23971; 19 Nov 96 10:21 EST Received: from ietf.org by ietf.org id aa15734; 19 Nov 96 10:03 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: urn-ietf@bunyip.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-syntax-01.txt Date: Tue, 19 Nov 1996 10:03:40 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611191003.aa15734@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : URN Syntax Author(s) : R. Moats Filename : draft-ietf-urn-syntax-01.txt Pages : 6 Date : 11/18/1996 Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers. This document sets forward the canonical syntax for URNs. Support for both existing legacy and new namespaces is discussed. Requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-syntax-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-syntax-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118171343.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-syntax-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-syntax-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118171343.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa01776; 22 Nov 96 10:27 EST Received: from ietf.org by ietf.org id aa27563; 22 Nov 96 9:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: urn-ietf@bunyip.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-http-conv-00.txt Date: Fri, 22 Nov 1996 09:41:23 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611220941.aa27563@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Conventions for the Use of HTTP for URN Resolution Author(s) : R. Daniel Filename : draft-ietf-urn-http-conv-00.txt Pages : 6 Date : 11/21/1996 The URN-WG was formed to specify persistent, location-independent names for network accessible resources, and resolution mechanisms to retrive the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal [1]. That proposal does not get the client software all the way from the URN to the resource. Instead, it gets the client from a URN to a "resolver", which is a system that can then tell the client where the resource is. The NAPTR draft defines a "resolution protocol" to be the protocol used to speak to a resolver in order to obtain the resource, its location(s), or other information about the resource. The NAPTR proposal allows different resolution protocols to be used for commuicating with resolvers. This draft establishes conventions for encoding URN resolution requests and responses in HTTP 1.0 (and 1.1) requests and responses. The primary goal of this draft is to define a convention that is simple to implement and will allow existing HTTP servers to easily add support for URNresolution. We expect that the resolution databases that arise will be useful when more sophisticated resolution protocols are developed later. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-http-conv-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-http-conv-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-http-conv-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121163444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-http-conv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-http-conv-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121163444.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa01783; 22 Nov 96 10:27 EST Received: from ietf.org by ietf.org id aa27580; 22 Nov 96 9:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: urn-ietf@bunyip.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-naptr-01.txt Date: Fri, 22 Nov 1996 09:41:32 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611220941.aa27580@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Resolution of Uniform Resource Identifiers using the Domain Name System Author(s) : R. Daniel, M. Mealling Filename : draft-ietf-urn-naptr-01.txt Pages : 13 Date : 11/21/1996 Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. In addition to locating resolvers, the NAPTR provides for other naming systems to be grandfathered into the URN world, provides independence between the name assignment system and the resolution protocol system, and allows multiple services (Name to Location, Name to Description, Name to Resource, ...) to be offered. In conjunction with the SRV RR proposal [3], the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-naptr-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-naptr-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121163946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-naptr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-naptr-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121163946.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa23174; 26 Nov 96 9:32 EST Received: from ietf.org by ietf.org id aa19547; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: urn-ietf@bunyip.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-req-frame-00.txt Date: Tue, 26 Nov 1996 09:20:46 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9611260920.aa19547@ietf.org> --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Requirements and a Framework for URN Resolution Systems Author(s) : K. Sollins Filename : draft-ietf-urn-req-frame-00.txt Pages : 17 Date : 11/25/1996 This document addresses the issues of the discovery of local URN resolution services that in turn will directly translate URNs into URLs and URCs. The document falls into three major parts, the assumptions underlying the work, the requirements in order to be a viable URN-resolution-service discovery service or UDS, and a framework for designing UDSs. The requirements fall into three major areas: evolvability, usability, and security and privacy. A UDS that is compliant with the framework will not necessarily be compliant with the requirements. Compliance with the requirements will need to be validated separately. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-req-frame-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-req-frame-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-req-frame-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125154650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-req-frame-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-req-frame-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125154650.I-D@ietf.org> --OtherAccess-- --NextPart--  1996-11.mail0000666000175200000100000340045511373045025011503 0ustar steveywww Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA24422 for urn-ietf-out; Fri, 29 Nov 1996 21:15:13 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA24417 for ; Fri, 29 Nov 1996 21:15:07 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12817 (mail destined for urn-ietf@services.bunyip.com); Fri, 29 Nov 96 21:15:02 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id SAA01368; Fri, 29 Nov 1996 18:13:27 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id SAA29904; Fri, 29 Nov 1996 18:13:46 -0800 (PST) Date: Fri, 29 Nov 1996 18:13:46 -0800 (PST) From: Terry Allen Message-Id: <199611300213.SAA29904@ishtar.fsc.fujitsu.com> To: sollins@LCS.MIT.EDU, urn-ietf@bunyip.com Subject: Re: [URN] URN resolution requirements and framework Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com I trust the following will not be taken as a rotten egg or a tomato (much less a gas-green tomato): Summary: The case for unfriendly/meaningless/semantic-free naming is made much more strongly in the framework doc than in RFC 1737, and inappropriately so in view of recent discussions on the issue here. Please suppress. Details: | The Uniform Resource Identifier Working Group defined a naming | architecture, as demonstrated in a series of three RFCs 1736[RFC1736], | 1737{RFC1737}, and 1738[RFC1738]. Although several further documents | are needed to complete the description of that architecture, it | incorporates three core functions often associated with "naming": | identification, location, and mnemonics or semantics. Names may provide | the ability to distinguish one resource from another, by distinguishing | their "names". Names may help to provide access to a resource by | including "location" information. Lastly, names may have other semantic | or mnemonic information that either helps human users remember or figure | out the names, or include other semantic information about the resource | being named. The URI working group concluded that there was need for | persistent, globally unique identifiers, distinct from location or other | semantic information; these "names" provide identity, in that if two of | them are "the same" (under some simple rule of canonicalization), they | identify the same resource. Furthermore, the group decided that these | "names" were generally to be for machine, rather than human consumption. Where does it say that in the RFCs you refer to? I find in RFC 1737 only the assertion that URNs should be machine-parseable. There is a weak sentence claiming that on the assumption that semantic drift is a problem for names, naming authorities should be discouraged from using meaningful names (actually, names that employ information about the resource; meaningful names are not advised against *per se*). That's far short of what you're saying here, now. | One can imagine a variety human-friendly naming (HFN) schemes supporting | different suites of applications and user communities. These will need | to provide mappings to URNs in tighter or looser couplings, depending on | the namespace. It is these that will be mnemonic, content-full, and | perhaps mutable, to track changes in use and semantics. They may Or they will be URNs themselves. I can imagine that, too. This is a document on URNs, not HFNs. The general mechanism of "hints" can cover HFNs; there is no need to assert that the future will instantiate your views on meaningful naming. Especially if consensus is desired. The argument below, about URLs, is not about separation of semantics from identification, as claimed, it's about the different utilities of naming and pointing. | Today we see the problem most clearly with the use of URLs for | identification. When a web page moves, its URL becomes invalid. | Suppose such a URL is embedded in some page, stored in long term | storage. There are three possible outcomes to this scenario. One | possibility is that the client is left high and dry with some message | saying that the page cannot be found. Alternatively, a "forwarding | pointer" may be left behind, in the form of an explicit page requesting | the client to click on a new URL. Although this will allow the client | to find the intended page, the broken link cannot be fixed because the | URL is embedded in a file outside of the client's control. A third | alternative is that the target server supplies an HTTP redirect so that | the new page is provided for the client automatically. In this case, | the client may not even realize that the URL is no longer correct. The | real problem with both of these latter two situations is that they only | work as long as the forwarding pointer can be found at the old URL. So far, so good. And no mention of semantics. | Semantics, in this case location information, was embedded in the | identifier, and the resolution system was designed to depend on the | semantics being correct. There are few cases in which we can expect That's one way of thinking of it; it depends on the URL and the resolution system. This is not a strong argument that it's semantics that make URLs fragile; "http://192.240.3.1/nnnnn/zzzzz" is just as fragile. | semantics of any sort to remain valid for a long time, but in many cases | references need to have long lifespans. Most documents are only useful | while their references still function. You are arguing that semantic drift in naming is so great that it affects some appreciable number of documents during their useful lifetime. I don't buy it. Take out the semantics part and you have a good argument for why we need URNs; isn't that why it's here? What follows by way of "postulation re scope of evolution" might better be replaced with a less controversial example just as apt to the point. Or just leave it out: these aliases are nothing but hints, right? | We expect the evolution to separation of semantics from identification | to move along at least three paths. The first will be to develop | temporary aliases to capture the semantics currently embedded in | identifiers. This will require additional translation, but it will | allow for the development of semantics-free URNs. Second, we expect | locally shared or private aliases to arise, again supported by a | translation mechanism and allowing for the long-term storage of global, | semantics-free URNs. Such an aliasing scheme may be used to permit | local aliases for named resources as well as to present these aliases to | users in lieu of the URNs themselves. Lastly, we expect there may be a | development of global aliases. These will be more user friendly "names" | that would be shared on a much larger scale, and might be defined in | some global registry. This may include trademarked names as well as | names in extremely common use. As with the other alias systems, a | facility for translation is needed. However, in this case, since the | system of aliases is of global scope, the translation facility will be | very slow if each time an alias is translated it needs to query a | centralized or even reasonably distributed global registry. In order to | achieve acceptable speeds, the translation facility will need to | maintain a local cache, possibly in cooperation with other nearby alias | caches. Clearly this is all postulation at present, but it is provided | here to demonstrate some of the scope of evolution for which we must be | prepared. That it may be, but it is also declaring a position on human-friendly naming that we do not agree upon. Stu Weibel gave us good advice: take no position on the issue. | In summary, the requirements in the area of evolvability are: | * To support evolution of mechanisms, specifically for | a) a growing set of URN schemes; | b) new local URN resolution schemes; | c) new authentication schemes; | d) alternative UDS schemes active simultaneously; | * To support and encourage the evolution toward the separation of | global identification from short-lived, locally useful, or human | friendly semantics; "To permit" is sufficient; or, in the language used in every other point in this list, "To support". Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA18582 for urn-ietf-out; Fri, 29 Nov 1996 10:43:52 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA18577 for ; Fri, 29 Nov 1996 10:43:44 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09022 (mail destined for urn-ietf@services.bunyip.com); Fri, 29 Nov 96 10:43:37 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <25229-0@josef.ifi.unizh.ch>; Fri, 29 Nov 1996 16:42:11 +0100 Date: Fri, 29 Nov 1996 16:42:08 +0100 (MET) From: "Martin J. Duerst" To: Leslie Daigle Cc: Ryan Moats , URN mailing list Subject: Re: [URN] Collecting open issue information on the syntax draft... In-Reply-To: <199611221942.OAA21503@beethoven.bunyip.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Fri, 22 Nov 1996, Leslie Daigle wrote: > [Ryan brought up:] > > 4. human readability for new namespaces: MUST/SHOULD? > > If that is the case, I would propose the following change to the syntax > draft: > > > 3. Support of existing legacy naming systems and new naming systems > > > URN-aware applications MAY accept as input other resource identifiers > > from existing legacy namespaces. If such identifiers contain > > characters that are not members of the URN character set specified in > > section 2.2, the identifier MUST be translated to canonical format as > > discussed in section 2.2. > > > > Some existing name spaces that have the properties of the URN-space > > contain some human-significant components, and these exist in a wide > > variety of languages. However, URNs are NOT intended to convey > > information that is significant to humans. While the translation > > rule in section 2.2 is provided for existing namespaces, new > > namespaces, as part of their registration documentation, MUST define > > a discipline for assigning new URNs that does not simplify the > > generation of human-significant names. > > would become: > > > 3. Support of existing legacy naming systems and new naming systems > > Any namespace (existing or newly-devised) that is proposed as a > URN-namespace and fulfills the criteria of URN-namespaces must > be expressed in this syntax. If names in these spaces contain > characters other than those defined for the URN character set, > they must be translated into canonical format as discussed in > section 2.2. I can only support Leslie's proposal (just change "spaces" on line 3 to "name spaces" and "canonical format" to "canonical form".) Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA07752 for urn-ietf-out; Thu, 28 Nov 1996 13:37:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA07746 for ; Thu, 28 Nov 1996 13:37:51 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04761 (mail destined for urn-ietf@services.bunyip.com); Thu, 28 Nov 96 13:37:46 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <08949-0@josef.ifi.unizh.ch>; Thu, 28 Nov 1996 19:37:51 +0100 Date: Thu, 28 Nov 1996 19:37:49 +0100 (MET) From: "Martin J. Duerst" To: Ryan Moats Cc: URN mailing list Subject: Re: [URN] Collecting open issue information on the syntax draft... In-Reply-To: <9611221640.AA24257@mocha.bunyip.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Fri, 22 Nov 1996, Ryan Moats wrote: > Folks- > > I've been going back over the open issues with the syntax draft > and trying to ensure that I have all of them before I start thinking > about slides for San Jose. > When does a URN end? > --------------------------------------- > > It has also been pointed out to me that the syntax draft does not indicate > when a URN ends. Some statement should be added to indicate this > situation. My current preference is to state that a "On the line, the > URN ends with an octet that is not a member of the URN charset", > or something like that, but what about other formats? If you think about SGML public identifiers, which are quite long, or if you consider narrow columns in newspapers, having all of an URN on one line may not be possible. You may find a solution in draft-fielding-url-syntax-00.txt, but maybe there is none (I quickly scanned it and didn't find any). Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA25916 for urn-ietf-out; Wed, 27 Nov 1996 15:09:56 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA25911 for ; Wed, 27 Nov 1996 15:09:54 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27995 (mail destined for urn-ietf@services.bunyip.com); Wed, 27 Nov 96 15:09:52 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id NAA03343 for ; Wed, 27 Nov 1996 13:09:49 -0700 (MST) Message-Id: <2.2.32.19961127201825.00d31a90@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Nov 1996 13:18:25 -0700 To: urn-ietf@bunyip.com From: Ron Daniel Subject: [URN] some more NAPTR edits Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Hi, I've been looking some more at security for NAPTR resolution and think there may be times when people will want to provide encrypted info in a NAPTR record. I'm considering some changes to the draft to accomodate this - the main part of those changes is appended. I'll wait until after San Jose to actually make the edits to the draft and resubmit, because these changes may be controversial. Regards, Ron =============== Flags A String giving flags to control aspects of the rewriting. Flags are characters from the set [0-9A-Z]. The case of the alphabetic characters is not significant. Multiple flags may appear in the flags field. The flags A-Z are reserved, 0-9 are available for local experimentation. At this time there are 5 defined flags: A, S, P, R and E. S, A, and P all indicate that the NAPTR is terminal and the next lookup should be for A records, SRV records, or protocol-known records, respectively. The A, S, and P flags are mutually exclusive. The "R" flag indicates that the regexp field is to be treated as a Raw string, not as a substitution expression. The interpretation to be placed on that string will be set by other flags. When the "R" flag is given, there MUST be a value in the regexp field. There MAY be a value in the replacement field, in which case that shall be the next domain name to be contacted. The "R" flag may be combined with one of the "A", "S", or "P" flags. Specifying the "R" flag is the only time it is not an error to have a value in both the regexp and replacement fields. The "E" flag specifies that the regexp field holds an encrypted string. The "R" flag must be specified if the "E" flag is given. Further details on the encryption protocol will be specified in subsequent releases of this draft. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA13817 for urn-ietf-out; Tue, 26 Nov 1996 15:34:56 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA13794 for ; Tue, 26 Nov 1996 15:34:24 -0500 Received: from iberia-c.it.earthlink.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18685 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 15:34:21 -0500 Received: from [153.35.78.27] (Cust27.Max18.Boston.MA.MS.UU.NET [153.35.78.27]) by iberia.it.earthlink.net (8.7.5/8.7.3) with ESMTP id MAA11660; Tue, 26 Nov 1996 12:33:10 -0800 (PST) X-Sender: tows@mail.earthlink.net Message-Id: In-Reply-To: <96Nov26.063616pdt."135"@palimpsest.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Nov 1996 03:37:05 -0500 To: Larry Masinter From: Towsner Subject: Re: [URN] Persistence as part of URN framework Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Towsner Errors-To: owner-urn-ietf@bunyip.com At 8:36am -0500 11/26/96, Larry Masinter wrote: ># All I wanted was an *optional* persistence value to be possible, so that the ># URN resolution service could indicate the longevity of the resolver (not the ># URN), at least until the longevity was extended once the people managing it ># were willing to commit to a longer running service. > >... > ># No-one seems to be able to get their head round the fact that such expiry ># times are meaningless if you don't know how long you will be able to resolve ># URNs which end up pointing to HTTP, but might point to another scheme later ># to keep them alive. I think the problem is that people just aren't thinking ># in terms of how much the world will change in the decades ahead. All I'm ># trying to propose is a way to avoid having to poll for broken resolution ># services in the future. > ># I give up. > >No URN resolution protocol that doesn't explicitly deal with the >issues of what happens when providers quit, merge, or split can >seriously claim to address URN requirements. > >A protocol can be marked as 'Experimental', but even Experimental >drafts can be marked to clearly indicate what parts of the problem >they're not handling. The experiment then can help determine how >serious, in practice, the problem really is. I think some type of persistance check is important. The ability to mark information as transient should definately be part of the URN framework. -- -Henry Towsner Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA13802 for urn-ietf-out; Tue, 26 Nov 1996 15:34:42 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA13797 for ; Tue, 26 Nov 1996 15:34:40 -0500 Received: from iberia-c.it.earthlink.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18690 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 15:34:38 -0500 Received: from [153.35.78.27] (Cust27.Max18.Boston.MA.MS.UU.NET [153.35.78.27]) by iberia.it.earthlink.net (8.7.5/8.7.3) with ESMTP id MAA11548; Tue, 26 Nov 1996 12:32:02 -0800 (PST) X-Sender: tows@mail.earthlink.net Message-Id: In-Reply-To: <2.2.32.19961126154635.00d18aa0@acl.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Nov 1996 03:34:47 -0500 To: Ron Daniel , Fisher Mark , urn-ietf From: Towsner Subject: Re: [URN] Collecting open issue information on the syntaxdraft... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Towsner Errors-To: owner-urn-ietf@bunyip.com >What I want to >see first is the use of internationally standardized namespaces such >as ISBN for on-line access to books, ISSN/SICI for access to magazine, >journal, and newspaper articles; ISAN for access to video programs and >movies; ISWC/ASCAP/BMI identifiers for access to music; UPC for access >to product descriptions, etc. National Standards bodies, such as ANSI, >and industry associations, such as the EIA, may also have developed >namespaces we could support. > >The Fortune 500 already make use of one or more of these namespaces >for particular purposes (especially UPC). From what I've read of the proposals, it seems to me that URN's are not intended as a replacement for URL's. They are intended to be used to locate *resources,* such as product descriptions or documents. URL's are capable of locating some company's web page, URN's, however, are better suited for locateing RFC 112 anywhere on the internet. -- -Henry Towsner Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA13107 for urn-ietf-out; Tue, 26 Nov 1996 14:51:47 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA13101 for ; Tue, 26 Nov 1996 14:51:44 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18308 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 14:51:40 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA22304; Tue, 26 Nov 1996 12:51:33 -0700 (MST) Message-Id: <2.2.32.19961126200009.00d30be8@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Nov 1996 13:00:09 -0700 To: Bob Briscoe From: Ron Daniel Subject: Re: [URN] Persistence as part of URN framework Cc: "urn-ietf@bunyip.com" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Bob Briscoe (at least at 10:27 AM 11/26/96 +0000) >[...] No-one seems to be able to get their head round the fact that [...] I'm trying to understand your point, and am sorry that its taking so much time. Lets try again. >All I wanted was an *optional* persistence value to be possible, Because of the limitations on DNS response sizes, there is a strong incentive not to put in any fields that are not needed. If we can agree that what you are asking for is necessary functionality not achievable by other means, then we will modify the NAPTR proposal to allow it. But I have not yet been convinced on that point. In fact, during the course of preparing this reply, I am more firmly of the view that the combination of DNS TTLs and the "Expires:" header of the HTTP resolution protocol (and equivalant features in other protocols) can achieve enough of what you are asking for that a seperate "lifetime" field is not justified. Let me try again to state what I think you are asking for and why. Then I will explain what it won't achieve. Finally I will explain what it will achieve beyond the combo of DNS TTL and "Expires:"-type info, and why I think the additional benefit is not significant. What I think you want: ======================= A way to determine the minimum remaining lifetime of a resolver without contacting that resolver to ask it. In other words, a new "lifetime" field in the NAPTR record. Why I think you want it: ======================== In an earlier message you indicated that one application of such a capability would be to automate the maintenance of links in HTML-like resources without continual polling, where a poll would probably be the wasteful operation of fetching the resource then throwing it away. In another message you said that this information will help in the migration from one resolution protocol to another. Why what you are asking for does not achieve at least some of what you want: =========================================================== Imagine that today (11/26/96) a customer signs a contract with a Resolution Service Provider (RSP) for one year's worth of service. You seem to be asking that the RSP be capable of updating their NAPTR record to indicate that the HTTP resolver they run will be available until at least 11/26/97. But of course, new customers come along and sign new contracts, again for a year's service. The NAPTR record could be continually updated to reflect that the RSP is now contractually bound to provide the HTTP resolver for a year after the most recent agreement with a customer. But why? It does not mean that the the original customer's URNs will still be resolvable there. Their contract was only for one year. Maybe they have decided to contract with a different RSP that can offer the spiffy new X2Y service. This is why I think that a special "lifetime" field in the NAPTR record does not achieve what you want from the "link maintenence" example. If I write a paper and use a URN to link to someone else's resource, the lifetime of the resolver does not necessarily tell me the lifetime of their resolution info on that resolver. However, if I go ahead and ask the resolver about that particular URN (assuming the approach in the HTTP Conventions draft), the HTTP Expires: header can be used to provide the detailed information on just how long one particular URN will continue to be resolvable on one particular resolution server under a particular resolution protocol. (This will be the minimum of the time remaining on that customer's contract, the time until the resolution service provider wants to scrap a particular resolution protocol, and the time remaining on the resolution service provider's contract with whoever they got their domain name from). When that time has expired I can try to resolve the name again and see what happens. What it *would* achieve over existing capabilities and why I think the additional benefit is not significant: ================================================================= >I've been off-line with Ron Daniel who is happy that schemes such as HTTP >which have expiry headers can get this information to you once you have >resolved how to speak to HTTP. > >No-one seems to be able to get their head round the fact that such expiry >times are meaningless if you don't know how long you will be able to resolve >URNs which end up pointing to HTTP, but might point to another scheme later >to keep them alive. I think the problem is that people just aren't thinking >in terms of how much the world will change in the decades ahead. All I'm >trying to propose is a way to avoid having to poll for broken resolution >services in the future. Let's look at a case where a resolution service provider (RSP) wants to swap from HTTP to some other resolution protocol - Z39.50 for example. We will also look at a couple of clients and how the swap affect them. RSP: ---- When the RSP starts offering HTTP_based resolution, they might say "OK, we will try this HTTP thing for 6 months as see how it goes". Their N2L, N2C, ... scripts generate an Expires: header that clocks down to that 6 month deadline. The NAPTR record for their HTTP-based resolver has a TTL that is considerably shorter - 1 week perhaps - to allow them to change the resolution services offered during the initial experimental period with only the week's advance notice. Client 1: --------- Somewhere along the way, a smart link manager is given a URN and starts to resolve it. It gets the Expires: header from the RSP's HTTP-based resolver and caches the expiry data with the URN. Its job as a "smart" link manager will be to recheck the availability of the resource and flag an error when it is no longer resolvable. It should do this in the least intrusive fashion possible. RSP: ---- Sometime later, the RSP decides that they don't like the HTTP-based approach and want to switch to a Z39.50-based approach. They will wait until the 6-month period expires before killing off the HTTP daemon, but in the meantime they bring up their Z39.50-based server and install a NAPTR record to point to it. They also decide that they want the NAPTR record for their HTTP server to disappear about a week before the server itself is killed. So, they start clocking down the TTL on the HTTP server's NAPTR record to that T=6mo-1week deadline. At that time the HTTP daemon's NAPTR record will be removed. Client 2: --------- Before that T=6mo-1week deadline, a different user agent attempts to resolve the URN and now encounters 2 terminal NAPTR records - one for the HTTP resolver and one for the Z39.50 resolver. It picks which one to talk to based on the protocols it knows how to speak, the services they offer, etc. If it knows both resolution protocols, it MAY make the decision based on the TTL of the NAPTR records. Once it has contacted the resolver the client will know how long the resolver guarrantees to provide resolution for that URN. As shown in the "contract" example earlier, this can be a considerably shorter time than the lifetime of the resolver. Client 1: --------- The 6 month expiry date comes along, and a random time later the link manager wants to recheck the URN. It starts a new NAPTR resolution which, some number of DNS probes later, gets it to the terminal NAPTR records. There is now a new terminal NAPTR record for a Z39.50-based resolver, but no HTTP-based record. If the client knows Z39.50 it can do something like N2Ls and get new expiry info. If not, it can use the TTL as a provisional expiry date and do more frequent checks of the DNS records in the hopes that a known resolution protocol will be offered at some time in the future. When it is, a more accurate expiry time can be obtained. Your request for a resolver lifetime field would modify the scenario above in two places. In the Client 2 paragraph, in the case where the client could speak more than one of the resolution protocols that were offered, it could make the decision on which one to pursue based on the resolver lifetime rather than the NAPTR TTL. However, as the "contract" example shows, this does not guarantee that the resolver with the longer minimum guaranteed lifetime actually will resolve that resource longer than the other one. So, the difference here does not seem all that significant. The second place where the "lifetime" field would change the scenario is in the last step where Client 1 does not know the new protocol. Rather than marking the URN provisionally resolvable with the NAPTR TTL as the time for the next check, it could mark it provisionally resolvable with the Z39.50 resolver lifetime as the time for the next check. The TTL is never longer than the resolver lifetime, so the TTL is the safer choice although it will lead to more "polls". In this case, however, a "poll" is fairly light weight - some DNS probes to see if the terminal NAPTR for the unknown protocol still exits (in which case we retain the provisionally resolvable status and check back later) or if new NAPTRs exist that we can follow. These could be introduced at any time so checking for them periodically is not a bad thing. Here again, the benefit from the new field does not seem so clear-cut that I'm not convinced it is necessary. I'm willing to be convinced of the necessity for such a field. However, since it requires extra space in the records and changes to running code you have to make a good case for it. If you can show me where the combination of DNS TTLs and resolution-specific Expiry info does not provide enough info to handle an important case, and the new field would, I'll change the spec. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA10668 for urn-ietf-out; Tue, 26 Nov 1996 11:51:04 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA10663 for ; Tue, 26 Nov 1996 11:50:53 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16766 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 11:50:02 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id LAA17893; Tue, 26 Nov 1996 11:50:00 -0500 Date: Tue, 26 Nov 1996 11:50:00 -0500 Message-Id: <199611261650.LAA17893@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: urn-ietf@bunyip.com Subject: [URN] resending Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com Don't know what happened, but here's the whole document...Thanks to those of you who pointed this out to me. Karen ______________________________ Internet Draft Karen R. Sollins draft-ietf-urn-req-frame-00.txt MIT/LCS Expires May 26, 1997 November 26, 1996 Requirements and a Framework for URN Resolution Systems Status of this draft This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract: This document addresses the issues of the discovery of local URN resolution services that in turn will directly translate URNs into URLs and URCs. The document falls into three major parts, the assumptions underlying the work, the requirements in order to be a viable URN-resolution-service discovery service or UDS, and a framework for designing UDSs. The requirements fall into three major areas: evolvability, usability, and security and privacy. A UDS that is compliant with the framework will not necessarily be compliant with the requirements. Compliance with the requirements will need to be validated separately. 1. Introduction The purpose of this document is to lay out the engineering criteria for what we will call here a URN-resolution-service discovery service (UDS). __________ Acknowledgments Foremost acknowledgment for this document goes to Lewis Girod, as my co-author on a previous URN requirements document and for his insightful comments on this version of the document. In addition, I recognize the contributors to a previous URN framework document, the "Knoxville" group. There are too many of you to acknowledge here individually, but thank you. Finally, I must thank the contributors to the URN working group mailing list (urn-ietf@bunyip.com), for their animated discussions on these and related topics. URN Resolution Requirements Page 1 This is a component of the realization of an information infrastructure. In the case of this work, that infrastructure is to be available, "in the Internet" or globally, and hence the solutions to the problems we are addressing must globally scalable. In this work, we are focussing specifically on naming of resources and resolution of those names to the exclusion of other problems such as typing, resource access and availability, security of the resources, etc. Those are all important problems, but not part of this effort. The Uniform Resource Identifier Working Group defined a naming architecture, as demonstrated in a series of three RFCs 1736[RFC1736], 1737{RFC1737}, and 1738[RFC1738]. Although several further documents are needed to complete the description of that architecture, it incorporates three core functions often associated with "naming": identification, location, and mnemonics or semantics. Names may provide the ability to distinguish one resource from another, by distinguishing their "names". Names may help to provide access to a resource by including "location" information. Lastly, names may have other semantic or mnemonic information that either helps human users remember or figure out the names, or include other semantic information about the resource being named. The URI working group concluded that there was need for persistent, globally unique identifiers, distinct from location or other semantic information; these "names" provide identity, in that if two of them are "the same" (under some simple rule of canonicalization), they identify the same resource. Furthermore, the group decided that these "names" were generally to be for machine, rather than human consumption. One can imagine a variety human-friendly naming (HFN) schemes supporting different suites of applications and user communities. These will need to provide mappings to URNs in tighter or looser couplings, depending on the namespace. It is these that will be mnemonic, content-full, and perhaps mutable, to track changes in use and semantics. They may provide nicknaming and other aliasing, relative or short names, context sensitive names, descriptive names, etc. The URI naming architecture as described in the introductions to RFCs 1736 and 1737 lays out three sorts of components to the naming architecture: identifiers called Uniform Resource Names (URNs), locators called Uniform Resource Locators (URLs) and semantic meta-information called Uniform Resource Characteristics (URCs). This document focusses on part of the problem of the translation from URN to URL and/or URC. Within the URI community there has been a concept used frequently that for lack of a better term we will call a _hint_. A hint is something that helps in the resolution of a URN. Examples of hints are: 1) the name of a resolution service that may further resolve the URN, 2) the address of such a service, 3) a location at which the resource was previously found. The defining feature of hints is that they are only hints; they may be out of date, temporarily invalid, or only applicable within a specific locality. They do not provide a guarantee of access, but they probably will help in the resolution process. Wemust assume that most resolutions of URNs will be provided by the use of locally stored hints, because maintaining a database of globally available, completely up-to-date location information is infeasible for performance reasons. There are a number of circumstances in which one can imagine that hints become invalid, either because a resource has moved or because a different URN resolution service has taken over the URN Resolution Requirements Page 2 responsibility for resolution of the URN. Hints may be found in a variety of places. It is generally assumed that a well engineered system will maintain a set of hints for each URN at each location where that URN is found. In addition, for those situations in which those hints found locally fail, a well-engineered system will provide a fall-back mechanism for discovering further hints. It is this fall-back mechanism, a UDS, that is being addressed in this document. As with all hints, there can never be a guarantee that access to a resource will be available to all clients, even if the resource is accessible to some. However, a UDS is expected to work with reasonably high reliability, and, hence, may result in increased response time. The remainder of this document falls into three sections. The first identifies several sets of assumptions underlying this work. The next lays out the requirements for a URN-resolution-service discovery service. This section is probably the most critical of the document, because it is this that provides the metric for whether or not a proposed scheme for a UDS is adequate or not. For the reader short on time, each of the three major subsections of the requirements section concludes with a summary list of the requirements identified in that section. The final section of the document lays out a framework for such UDSs. The purpose of this last section is to bound the search space for UDS schemes. One must be careful not to assume that because a UDS scheme fits within the framework that it necessarily meets the requirements. As will be discussed further in this last section, designing within the framework does not guarantee compliance, so compliance evaluation must also be part of the process of evaluation of a scheme. 2. Assumptions Based on previous internet drafts and discussion in both the URN BOFs and on the URN WG mailing list, three major areas of assumptions are apparent: longevity, delegation, and independence. Each will be discussed separately. The URN requirements state that a URN is to be a "persistent identifier". It is probably the case that nothing will last forever, but in the time frame of resources, users of those resources, and the systems to support the resources, the identifier should be considered to be persistent or have a longer lifetime than those other entities. There are two assumptions that are implied by longevity of URNs: mobility and evolution. "Mobility" assumes that. everything will move over the life of a URN. For example, resources will move from one machine to another, because individual machines have a much shorter lifetime than resources, generally measured in a number of years less than a decade. Owners of resources may move and wish their resources to follow them. The services themselves will move. "Evolutions" assumes that the supporting infrastructure will evolve. This may take the form of entirely new transport protocols or new versions of existing protocols. Furthermore, services such as storage services may evolve; it is even possible that within a human lifetime the Unix file system model may no longer be in use! Clearly there will be evolution of and improvement in supporting authentication and security mechanisms. These are only examples. In general, we must assume that almost any piece of the supporting infrastructure of URN resolution will evolve. In order to deal with both the mobility and evolution assumptions that derive URN Resolution Requirements Page 3 from the assumption of longevity, we must assume that users and their applications can remain independent of these mutating details of the supporting infrastructure. The second and third assumptions are two forms of modularity, delegation and isolation. The delegation assumption is that an entity may partition and pass off some of its authority or responsibility. One of those responsibilities is for assigning URNs; practically speaking, there cannot be only a single authority for assigning URNs. We expect that there will be a multi-tiered naming authority delegation. Furthermore, it is difficult to imagine a non-partitioned and delegated global UDS, meaning that hint discovery and resolution will be partitioned and delegated. In some UDS schemes, the delegation of naming authority will form a basis for delegating the management and dispensing of location information. The third assumption is independence or isolation of one authority from another and, at least to some extent from its parent. Underlying much of the thinking and discussion in the URI and URN working groups has been the assumption that when a component delegates authority to another component, the delegatee can operate in that domain independently of its peers and within bounds specified by the delegation, independently of the delegator. This isolation is critically important in order to allow for independence of policy and mechanism. There are a number of more specific assumptions that fall under this rubric of isolation. First, we assume that the publisher of a resource can choose resolution services, independently of choices made by others. At any given time, the owner of a namespace may choose a particular URN resolution service for that delegated namespace. Such a URN resolution service may be outside the UDS service model, and just identified or located by the UDS service. Second, it must be possible to make a choice among UDS services, perhaps based on different underlying internal architectures. The reason that this is an assumption is that there must be an evolutionary path through a sequence of core UDS services. Although at any given time there is likely to be only one or a small set of such services, the number is likely to increase during a transition period from one architecture to another. Thus, it must be assumed that clients can make a choice among a probably very small set of UDSs. Third, there must be independence in the choice about levels and models of security and authenticity required. This choice may be made by the owner of a naming subspace, in controlling who can modify hints in that subspace. A naming authority may delegate this choice to the owners of the resources named by the names it has assigned. There may be limitations on this freedom of choice in order to allow other participants to have the level of security and authenticity they require, for example, in order to maintain the integrity of the UDS infrastructure as a whole. Fourth, there is an assumption of independence of choice of the rule of canonicalization of URNs within a namespace, limited by any restrictions or constraints that may have been set by its parent namespace. This is a choice held by naming authorities over their own subnamespaces. Rules for canonicalization will be discussed further in the framework section below. Thus, there are assumptions of independence and isolation to allow for delegated, independent authority in a variety of domains. URN Resolution Requirements Page 4 The modularity assumptions of delegation and isolation imply independence of decision and implementation, leading to a decentralization that provides a certain degree of safety from denial of service. Based on these these assumptions in conjunction with that of longevity and those for URLs and URNs as detailed in RFCs 1736 and 1737, we can now turn to the requirements for a URN services delegation service. 3. Requirements The requirements applying to a URN-resolution-service discovery service or UDS center around three important design goals: evolvability, usability, and security and privacy. At its core the function of a UDS is to provide hints for accessing a resource given a URN for it. These hints may range in applicability from local to global, and from short-lived to long-lived. They also may vary in their degree of verifiable authenticity. While it may be neither feasible nor necessary that initial implementations support every requirement, every implementation must support evolution to systems that do support every requirement. It is also important to note that there are other requirements, not applicable specifically to a UDS that must also be met. A whole URN system will consist of namespaces, the resolution information for them, and the mapping from names in the namespaces to resolution information (or hints). URN schemes must meet the requirements of RFC 1737. Resolution information, to the extent it is expressed as URLs must meet the requirements of RFC 1736. But this does not tell the whole story. Although the URN working group will identify several acceptable namespaces and the rules binding them, such as how delegation occurs, how it is expressed in the names, how and to what extent binding to hint information will be constrained by the namespace, in the long run a document will be needed to guide the evaluation criteria for acceptance of new namespaces. These are not included in the list of requirements below because they are not requirements for a UDS, but rather for naming schemes themselves. 3.1 Evolution One of the lessons of the Internet that we must incorporate into the development of mechanisms for resolving URNs is that we must be prepared for change. Such changes may happen slowly enough to be considered evolutionary modifications of existing services or dramatically enough to be considered revolutionary. They may permeate the Internet universe bit by bit, living side by side with earlier services or they may take the Internet by storm, causing an apparent complete transformation over a short period of time. There are several directions in which we can predict the need for evolution, even at this time, prior to the deployment of any such service. At the very least, the community and the mechanisms proposed should be prepared for these. First, we expect there to be additions and changes to the mechanisms. The community already understands that there must be a capacity for new URN schemes. A URN scheme will define a set of URNs that meet the URN requirements[RFC1737], but may have further constraints on the internal URN Resolution Requirements Page 5 structure of the URN. The requirements document would allow for an overall plan in which URN schemes are free to specify parts of the URN that are left opaque in the larger picture. In fact, a URN scheme may choose to make public the algorithms for any such "opaque" part of the URN. For example, although it may be unnecessary to know the structure of an ISBN, the algorithm for understanding the structure of an ISBN has been made public. Other schemes may either choose not to make their algorithms public, or choose a scheme in which knowledge of the scheme does not provide any significant semantics to the user. In any case, we must be prepared for a growing number of URN schemes. Often in conjunction with a new URN scheme, but possibly independently of any particular URN scheme, new resolution services may evolve. For example, one can imagine a specialized resolution service based on the particular structure of ISBNs that improves the efficiency of finding documents given their ISBNs. Alternatively, one can also imagine a general purpose resolution service that trades performance for generality; although it exhibits only average performance resolving ISBNs, it makes up for this weakness by understanding all existing URN schemes, so that its clients can use the same service to resolve URNs regardless of naming scheme. In this context, there will always be room for improvement of services, through improved performance, better adaptability to new URN schemes, or lower cost. In any case, new models for URN resolution will evolve and we must be prepared to allow for their participation in the overall resolution of URNs. If we begin with one overall plan for URN resolution, into which the enhancements described above may fit, we must also be prepared for an evolution in the authentication schemes that will be considered either useful or necessary in the future. There is no single globally accepted authentication scheme, and there may never be one. Even if one does exist at some point in time, there will always be threats to it, and so we must always be prepared to move on to newer and better schemes, as the old ones become too easily spoofed or guessed. Lastly, in terms of mechanism, although we may develop and deploy a single UDS scheme initially, we must be prepared for that top level model to evolve. Thus, if the UDS model supports an apparently centralized (from a policy standpoint) scheme for inserting and modifying authoritative information, over time we must be prepared to evolve to a different model, perhaps one that has a more distributed model of authority and authenticity. If the model has no core but rather a cascaded partial discovery of information, we may find that this becomes unmanageable with an increase in scaling. Whatever the core of the model, we must be prepared for it to evolve with changes in scaling, performance, and policy constraints such as security and cost. Second, in addition to the evolution of resolution mechanisms, we expect that the community will follow an evolutionary path towards the separation of semantics from identification. The URN requirements document suggested this path as well, and there has been general agreement in much of the community that such a separation is desirable. This is a problem that the public at large has generally not understood. Today we see the problem most clearly with the use of URLs for identification. When a web page moves, its URL becomes invalid. URN Resolution Requirements Page 6 Suppose such a URL is embedded in some page, stored in long term storage. There are three possible outcomes to this scenario. One possibility is that the client is left high and dry with some message saying that the page cannot be found. Alternatively, a "forwarding pointer" may be left behind, in the form of an explicit page requesting the client to click on a new URL. Although this will allow the client to find the intended page, the broken link cannot be fixed because the URL is embedded in a file outside of the client's control. A third alternative is that the target server supplies an HTTP redirect so that the new page is provided for the client automatically. In this case, the client may not even realize that the URL is no longer correct. The real problem with both of these latter two situations is that they only work as long as the forwarding pointer can be found at the old URL. Semantics, in this case location information, was embedded in the identifier, and the resolution system was designed to depend on the semantics being correct. There are few cases in which we can expect semantics of any sort to remain valid for a long time, but in many cases references need to have long lifespans. Most documents are only useful while their references still function. We expect the evolution to separation of semantics from identification to move along at least three paths. The first will be to develop temporary aliases to capture the semantics currently embedded in identifiers. This will require additional translation, but it will allow for the development of semantics-free URNs. Second, we expect locally shared or private aliases to arise, again supported by a translation mechanism and allowing for the long-term storage of global, semantics-free URNs. Such an aliasing scheme may be used to permit local aliases for named resources as well as to present these aliases to users in lieu of the URNs themselves. Lastly, we expect there may be a development of global aliases. These will be more user friendly "names" that would be shared on a much larger scale, and might be defined in some global registry. This may include trademarked names as well as names in extremely common use. As with the other alias systems, a facility for translation is needed. However, in this case, since the system of aliases is of global scope, the translation facility will be very slow if each time an alias is translated it needs to query a centralized or even reasonably distributed global registry. In order to achieve acceptable speeds, the translation facility will need to maintain a local cache, possibly in cooperation with other nearby alias caches. Clearly this is all postulation at present, but it is provided here to demonstrate some of the scope of evolution for which we must be prepared. A third evolutionary requirement is even more mechanical than the others. At any point in time, the community is likely to be supporting a compromise position with respect to resolution. We will probably be operating in a situation balanced between feasibility and the ideal, perhaps with policy controls used to help stabilize the service. Ideally, the service would be providing exactly what the customers wanted and they in turn would not request more support than they need. Since we will always be in a situation in which some service provision resources will be in short supply, some form of policy controls will always be necessary. For example, suppose hint entries are being submitted in such volume that the hint servers are using up their excess URN Resolution Requirements Page 7 capacity and need more disk space. An effective solution to this problem would be a mechanism such as a pricing policy. This pricing policy has the dual effect of both encouraging conservative use of resources and collecting revenue for the improvement and maintenance of the system. As technology changes and the balance of which resources are in short supply changes, the mechanisms and policies for controlling their use must evolve as well. In summary, the requirements in the area of evolvability are: * To support evolution of mechanisms, specifically for a) a growing set of URN schemes; b) new local URN resolution schemes; c) new authentication schemes; d) alternative UDS schemes active simultaneously; * To support and encourage the evolution toward the separation of global identification from short-lived, locally useful, or human friendly semantics; * To support the development and deployment of pricing models to manage human behavior with respect to limited resources. 3.2 Usability and Feature Set Requirements Usability can be evaluated from three distinct perspectives: those of a publisher wishing to make a piece of information public, those of a client requesting URN resolution, and those of the provider or manager of resolution information. We will separately address the usability requirements from each of these three perspectives. It is worth noting that there are two additional sorts of participants in the whole naming process, as discussed in the URN WG. They are the naming authorities which choose and assign names, and the authors who include URNs in their resources. These two are not relevant to the design of a UDS and hence are not discussed further here. 3.2.1 The Publisher The publisher must be able to make URNs known to potential customers. >From the perspective of a publisher, it is of primary importance that URNs be correctly and efficiently resolvable by potential clients. Publishers also stand to gain from long-lived URNs, since they increase the chance that references continue to point to their published resources. The publisher must also be able to choose easily among a variety of potential services that might translate URNs to location information. In order to allow for this mobility among resolution services, the architecture for resolution services specified within the IETF should not result in a scenario in which changing from one resolution service to another is an expensive operation. The publisher should be able to arrange for multiple access points to a published resource. For this to be useful, resolution services should be prepared to provide different resolution or hint information to different clients, based on a variety of information including location and the various access privileges the client might have. For example, companies might arrange for locally replicated copies of popular URN Resolution Requirements Page 8 resources, and would like to provide access to the local copies only for their own employees. This is distinct from access control on the resource as a whole, and may be applied differently to different copies. The publisher should be able to provide both long and short term information about accessing the resource. Long term information is likely to be such information as the long term location of the resource or the location or identity of a resolution service with which the publisher has a long term relationship. One can imagine that the arrangement with such a long term "authoritative" resolution service might be a guarantee of reliability, resiliency to failure, and atomic updates. Shorter term information is useful for short term changes in services or to avoid short lived congestion or failure problems. For example, if the actual repository of the resource is temporarily inaccessible, the resource might be made available from another repository. This short term information can be viewed as temporary refinements of the longer term information, and as such should be more easily and quickly made available, but may be less reliable. Lastly, the publishers will be the source of much hint information that will be stored and served by the manager of the infrastructure. Despite the fact that many publishers will not understand the details of the UDS mechanism, it must be easy and straightforward to install hint information. The publisher must be able not only to express hints, but also to verify that what is being served by the manager is correct. Furthermore, to the extent that there are security constraints on hint information, the publisher must be able to both express them and verify compliance to them easily. 3.2.2 The Client >From the perspective of the client, simplicity and usability are paramount. Of critical importance to serving clients effectively is that there be an efficient protocol through which the client can acquire hint information. Since resolving the name is only the first step on the way to getting access to a resource, the amount of time spent on it must be minimized. Furthermore, it will be important to be able to build simple, standard interfaces to the UDS so that both the client and applications on the client's behalf can interpret hints and subsequently make informed choices. The client, perhaps with the assistance of the application, must be able to specify preferences and priorities and then apply them. If the ordering of hints is only partial, the client may become directly involved in the choice and interpretation of them and hence they must be understandable to that client. On the other hand, in general it should be possible to configure default preferences, with individual preferences viewed as overriding any defaults. >From the client's perspective, although URNs will provide important functionality, the client is most likely to interact directly only with human friendly names (HFNs). As in direct human interaction (not computer mediated), the sharing of names will be on a small,private, or domain specific scale. HFNs will be the sorts of references and names that are easy to remember, type, choose among, assign, etc. There will URN Resolution Requirements Page 9 also need to be a number of mechanisms for mapping HFNs to URNs. Such services as "yellow pages" or "search tools" fall into this category. Although we are mentioning HFNs here, it is important to recognize that HFNs and the mappings from HFNs to URNs is and must remain a separate functionality from a UDS. Hence, although HFNs will be critical to clients, they do not fall into the domain of this document. 3.2.3 The Management Finally, we must address the usability concerns with respect to the management of the hint infrastructure itself. What we are terming "management" is a service that is distinct from publishing; it is the core of a UDS. It involves the storage and provision of hints to the clients, so that they can find published resources. It also provides security to the extent that there is a commitment for provision of such security; this is addressed below. The management of hints must be as unobtrusive as possible. First, its infrastructure (hint storage servers and distribution protocols) should have as little impact as possible on other network activities. It must be remembered that this is an auxiliary activity and must remain in the background. Second, in order to make hint management feasible, there will need to be a system for economic incentives and disincentives. Recovering the cost of running the system is only one reason for levying charges. The introduction of payments often has a beneficial impact on social behavior. It may be necessary to discourage certain forms of behavior that when out of control have serious negative impact on the whole community. At the same time, payment policies should encourage behavior that benefits the community as a whole. Thus, for example, a small one-time charge for authoritatively storing a hint will encourage conservative use of hints. If we assume that there is a fixed cost for managing a hint, then the broader its applicability across the URN space, the more cost effective it is. That is, when one hint can serve for a whole collection of URNs, there will be an incentive to submit one general hint over a large number of more specific hints. Similar policies can be instituted to discourage the frequent changing of hints. In these ways and others, cost effective behavior can be encouraged. Lastly, symmetric to issues of usability for publishers, it must also be simple for the management to configure the mapping of URNs to hints. It must be easy both to understand the configuration and to verify that configuration is correct. With respect to management, this requirement may have an impact not only on the information itself but also on how it is partitioned among network servers that collaboratively provide the management service or UDS. For example, it should be straightforward to bring up a server and verify that the data it is managing is correct. Since we are discussing a global and probably growing service, encouraging volunteer participants requires that, as with the DNS, such volunteers can feel confident about the service they are providing and its benefit to both themselves and the rest of the community. URN Resolution Requirements Page 10 To summarize, the usability requirements fall into three areas based on participation in hint management and discovery: * The publisher a) URN to hint resolution must be correct and efficient; b) Publishers must be able to select among URN resolution services to locate their resources; c) Publishers must be able to arrange for multiple access points for their location information; d) Publishers must be able to provide for both long-lived and short-lived hints; e) It must be relatively easy for publishers to install and observer their hint information and any security constraints they need for their hints. * The client a) The interface to the UDS must be simple, effective, and efficient; b) The client and client applications must be able to understand the information stored in and provided by the UDS, in order to be able to make informed choices. * The management a) The management of hints must be as unobtrusive as possible, avoiding using too many network resources; b) A pricing scheme may be necessary to provide not only cost recovery, but also social incentives and disincentives to encourage certain sorts of behavior deemed necessary to meet other requirements; c) The configuration and verification of configuration of individual UDS servers must be simple enough not to discourage configuration and verification. 3.3 Security and Privacy Requirements Although much of the information we are discussing in this document might be considered "meta-information", there are some important security and privacy concerns that must be addressed by a service supporting that information. By first considering the sorts of attacks that are of concern, we can then focus on the security and privacy issues that are important. The reader will notice that integrity plays less of a role here than might be expected. To the extent that servers provide access control, the information they manage will have certain integrity guarantees. Beyond that we must recognize that we are dealing merely with hint information about the location of possibly interesting resources. Therefore we believe that the benefit of providing integrity guarantees beyond those provided by the servers themselves does not outweigh the cost. Because the majority of the activity will be the distribution of hint information, the threats of concern are those affecting the maintenance of correct information to distribute and the availability of the sources of information. The first approach to URN resolution is to discover local hints. By being local, they will be as widely distributed as possible. The drawback of such wide distribution is the inability to update them; therefore, they will become out of date with time. An alternative or backup mechanism would concentrate hint information in URN Resolution Requirements Page 11 servers, thus requiring that update information only be distributed to these servers. Hence the vulnerable points are the sources of the information and the distribution network among them. If one assumes that there will be principals of some sort that are responsible for the information about each URN entry in the URN resolution service, then one major threat is an attacker that masquerades as a valid principal and inserts incorrect information into the service. A second threat vector results from the fact that the service itself will be implemented by a set of servers that collaborate and share the hint information critical to their activities. By masquerading as a valid server in this pool, an attacker can both provide incorrect information to clients and provide incorrect information to other servers, which those servers will then distribute. A third threat is that if the resolution service is too centralized, service can be denied by a variety of network attacks ranging from flooding the service with queries to causing various network problems that will reduce access to the service. The more centralized a service is the more vulnerable is the community that trusts it not to be compromised. We can turn each of these into a security goal. * ACCESS CONTROL ON HINTS: There needs to be an authoritative version of each hint, and it must support change control limited only to those principals with the right to modify it. The choice of who those principals are or whether they are unlimited must be made by the publisher of a hint. * SERVER AUTHENTICITY: Servers and clients must be able to learn the identity of the servers with which they communicate. This will be a matter of degree and it is possible that there will be more trustworthy, but less accessible servers, supported by a larger cluster of less authenticatable servers that are more widely available. In the worst case, if the client receives what appears to be invalid information, the client should assume that the hint may be inaccurate and confirmation of the data should be sought from more reliable but less accessible data. * SERVER DISTRIBUTION: Broad availability will provide resistance to denial of service. It is only to the extent that the services are available that they provide any degree of trustworthiness. In addition, the distribution of services will reduce to vulnerability of the whole community, by reducing the trust put in any single server. This must be mitigated by the fact that to the extent trust is based on a linked set of servers, if any one fails, the whole chain of trust fails; the more elements there are in such a chain, the more vulnerable it may become. _Ensuring_ privacy for clients and publishers is in some respects essentially impossible. Fortunately, assuring a reasonable degree of privacy for those who want it is possible. The privacy of clients is primarily threatened by packet sniffers and servers that log requests. A server or a packet sniffer can without much difficulty record the contents of queries as they pass by and compile the information into a relation between URNs and clients. This can be combatted by anonymizing queries through a trusted, fairly local gateway, although it involves an URN Resolution Requirements Page 12 extra step and another potential bottleneck. The additional step can be mitigated by caching responses in the gateway, thus often avoiding the need to forward requests beyond it. A second alternative is to send only partial queries. As will be discussed further in the framework section, there may be two reasons for transformation of a URN, first to canonicalize it and second to extract the identity of another server to which to send a further request. This second alternative of sending partial queries would be achieved by also extracting some partial URN to further resolve at each stage. This would not anonymize the queries, but might make them more difficult to chain together into a complete story for logging. On the other hand, to the degree that the search process is distributed, packet sniffing at a single point is less likely to reveal data about a specific person, and is hence less threatening to privacy. Furthermore, if clients have flexibility in terms of the specific services they choose to use, they can regularly switch services in the hopes of foiling a packet sniffer watching their usual access point. The privacy of publishers is much easier to safeguard. Since they are trying to publish something, in some situations privacy is probably not desired. However, publishers do have information that they might like to keep private: information about who their clients are, and information about what names exist in their namespace. The information about who their clients are may be difficult to collect depending on the implementation of the resolution system. For example, if the resolution information relating to a given publisher is widely replicated, the hits to _each_ replicated copy will need to be recorded. Of course, determining if a specific client is requesting a given name can be approached from the other direction, by watching the client as we saw above. The other privacy issue for publishers has to do with access control over URN resolution. This issue is dependent on the implementation of the publisher's authoritative URN resolution server. URN resolution servers can be designed to require proof of identity in order to be issued resolution information; if the client does not have permission to access the URN requested, the service denies that such a URN exists. An encrypted protocol can also be used so that both the request and the response are obscured. Encryption is possible in this case because the identity of the final recipient is known (i.e. the URN server). In summary, security and privacy requirements can be identified as some degree of protection from threats: * It must be possible to create authoritative versions of a hint with access to modification privileges controlled; * It must be possible to determine the identity of servers or avoid contact with unauthenticated servers; * Broad availability of servers will reduce the thread to denial of service; * Client privacy is threatened by packet sniffing and server logging. It is desirable to reduce these threats as much as possible; * It should be feasible for publishers to keep private certain URN Resolution Requirements Page 13 information such as an overall picture of the resources they are publishing and the identity of their clients; * Publishers should be able to restrict access to the resolution of the URNs for the resources they publish, if they wish. 4. The Framework With these assumptions and requirements in mind, one can conclude with a general framework within which UDS designs will fall. As stated earlier, although this framework is put forth as a suggested guide for UDS designers, compliance with it will in no way guarantee compliance with the requirements. Such an evaluation must be performed separately. It is also understood that there may be UDS services that do not meet the requirements in clearly identified ways. This may be true especially with early plans and experiments. For example, although a careful threat analysis may have been done to understand security requirements, not all those security requirements may be addressed, in order to use existing facilities to allow for early deployment for experimentation purposes. All such lack of compliance should be clearly documented. The design of the framework is based on a simple assumption about the syntax of a URN. This assumed syntax is: URN:: where URN: is a prefix on all URNs, NID is the namespace identifier, and NSS is the namespace specific string. The prefix identifies each URN as such. The NID determines the general syntax for all URNs within its namespace. The NSS is probably partitioned into a set of delegated and subdelegated namespaces, and this is probably reflected in further syntax specifications. In the more complex environments, each delegated namespace will be permitted to choose the syntax of the variable part of the namespace that has been delegated to it. In simpler namespaces, the syntax will be restricted completely by the parent namespace. For example, although the DNS does not meet all the requirements for URNs, it has a completely restricted syntax, such that any further structuring must be done only by adding further refinements to the left, maintaining the high order to low order, right to left structure. A delegated syntax might be one in which a host is named by the DNS, but to the right of that and separated by an "@" is a string whose internal ordering is defined by the file system on the host, which may be defined high order to low order, left to right. Of course, much more complex and nested syntaxes should be possible, especially given the need to grandfather namespaces. In order to resolve URNs, rules will be needed for two reasons. One is simply to canonicalize those namespaces that do not fall into a straightforward (probably right to left or left to right) ordering of the components of a URN, as determined by the delegated naming authorities involved. It is also possible that rules will be needed in order to derive from URNs the names of UDS servers to be used in stages. The NID defines a top level syntax. This syntax will determine whether the NID alone or in conjunction with some extraction from the NSS (for the top level naming authority name) to identify the first level server URN Resolution Requirements Page 14 to be contacted. Each stage of the lookup either a new rule for generating the strings used in yet another lookup (the strings being the identify of another UDS server and possibly a string to be resolved if it is different than the original URN) or a reference outside the UDS to a private URN resolution service, sidestepping any furthere use of the UDS scheme. Figure 1 depicts this process. URN: | | | | v +-------------------+ |Global NID registry| +-------------------+ | | | (return rule or URN resolution service reference) | +----------------------------------+ | | +->(apply rule to determine UDS server) | | | | | | | | | | | +----------+ | | |UDS server| +-----------------+ | +----------+ | | | | v | | | (set of choices) | | +----+----------(...)--------+ | (rule) | | | | | | | | | | +------+ | | v v +----------+ +----------+ |private | |private | |URN | |URN | |resolution| |resolution| |service | |service | +----------+ +----------+ Figure 1: A UDS framework There are several points worth noting about the UDS framework. First, it leaves open the determination of the protocols and data organization, distribution and replication needed to support a particular UDS scheme. Second, it leaves open the location of the computations engendered by URN Resolution Requirements Page 15 the rules. Third, it leaves open the possibility that partitioning (distribution) of the UDS database need not be on the same boundaries as the name delegation. This may seem radical to some, but if the information is stored in balanced B-trees for example, the partitioning may not be along those naming authority delegation boundaries. Lastly, it leaves open access to the Global NID Registry. Is this distributed to every client, or managed in widely distributed servers? One concept that has not been addressed in Figure 1 is that there may be more than one UDS available at any given time, in order to allow for evolution to new schemes. Thus, the picture should probably look more like Figure 2. URN:: | | +-----------+-------(...)-------+ | | | | | | v v +---------------------+ +---------------------+ |Global NID registry 1| |Global NID registry N| +---------------------+ +---------------------+ . . . . . . Figure 2: More than one co-existing UDS scheme If we are to support more than one co-existing UDS scheme, there will need to be coordination between them with respect to storage and propagation of information and modifications. The issue is that generally it should be assumed that all information should be available through any operational UDS scheme. One cannot expect potential publishers to submit updates to N UDS schemes. Hence there will need to be a straightforward mapping of information from one to the other of these schemes. It is possible that that transformation will only go in one direction, because a newer UDS service is replacing an older one, which is not kept up to date, in order to encourage transfer to the newer one. Thus, at some point, updates may be made only to the newer one and not be made available to the older one. Such a situation should probably be avoided, if possible. This framework is presented in order to suggest to UDS scheme designers a direction in which to start designing. It is obvious to the reader that adherence to this framework will in no way guarantee compliance with the requirements or even assumption described in Sections 2 and 3. These must be reviewed independently as part of the design process. There is no single correct design that will meet these requirements. Furthermore, it is assumed that preliminary proposals may not meet all the requirements, but should be expected to itemized and justify any lack of compliance. URN Resolution Requirements Page 16 5. References [RFC1736] Kunze, J., "Functional Recommendations for Internet Resource Locators", RFC 1736, February, 1995. [RFC1737] Sollins, K. and Masinter, L., "Functional Requirements for Uniform Resource Names", RFC 1738, December, 1994. [RFC1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource Locators (URL)", RFC 1738, December, 1994. 6. Contact information: Karen Sollins MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139 Tel: +1 617 253 6006 Email: sollins@lcs.mit.edu This InternetDraft expires on May 26, 1997. URN Resolution Requirements Page 17 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA10454 for urn-ietf-out; Tue, 26 Nov 1996 11:44:26 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA10449 for ; Tue, 26 Nov 1996 11:44:24 -0500 Received: from gizmo.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16695 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 11:44:13 -0500 Received: from mrrl.lut.ac.uk (martin@localhost.mrrl.lut.ac.uk [127.0.0.1]) by gizmo.lut.ac.uk (8.8.3/8.6.9) with ESMTP id QAA18687 for ; Tue, 26 Nov 1996 16:43:46 GMT Message-Id: <199611261643.QAA18687@gizmo.lut.ac.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: urn-ietf Subject: Re: [URN] Collecting open issue information on the syntaxdraft... X-Uri: In-Reply-To: Your message of "Tue, 26 Nov 1996 08:46:35 MST." <2.2.32.19961126154635.00d18aa0@acl.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Nov 1996 16:43:46 +0000 From: Martin Hamilton Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin Hamilton Errors-To: owner-urn-ietf@bunyip.com Ron Daniel writes: | What I want to | see first is the use of internationally standardized namespaces such | as ISBN for on-line access to books, ISSN/SICI for access to magazine, | journal, and newspaper articles; ISAN for access to video programs and | movies; ISWC/ASCAP/BMI identifiers for access to music; UPC for access | to product descriptions, etc. National Standards bodies, such as ANSI, | and industry associations, such as the EIA, may also have developed | namespaces we could support. How about RFCs for starters ? :-) Martin Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA09376 for urn-ietf-out; Tue, 26 Nov 1996 10:45:09 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA09371 for ; Tue, 26 Nov 1996 10:45:07 -0500 Received: from ietf.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15902 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 10:45:03 -0500 Received: from ietf.org by ietf.org id aa19547; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: urn-ietf@bunyip.com From: Internet-Drafts@ietf.org Subject: [URN] I-D ACTION:draft-ietf-urn-req-frame-00.txt Date: Tue, 26 Nov 1996 09:20:46 -0500 Message-Id: <9611260920.aa19547@ietf.org> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org Errors-To: owner-urn-ietf@bunyip.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Requirements and a Framework for URN Resolution Systems Author(s) : K. Sollins Filename : draft-ietf-urn-req-frame-00.txt Pages : 17 Date : 11/25/1996 This document addresses the issues of the discovery of local URN resolution services that in turn will directly translate URNs into URLs and URCs. The document falls into three major parts, the assumptions underlying the work, the requirements in order to be a viable URN-resolution-service discovery service or UDS, and a framework for designing UDSs. The requirements fall into three major areas: evolvability, usability, and security and privacy. A UDS that is compliant with the framework will not necessarily be compliant with the requirements. Compliance with the requirements will need to be validated separately. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-req-frame-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-req-frame-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-req-frame-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125154650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-req-frame-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-req-frame-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125154650.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA09290 for urn-ietf-out; Tue, 26 Nov 1996 10:38:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA09284 for ; Tue, 26 Nov 1996 10:38:12 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15756 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 10:38:08 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id IAA17468; Tue, 26 Nov 1996 08:37:59 -0700 (MST) Message-Id: <2.2.32.19961126154635.00d18aa0@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Nov 1996 08:46:35 -0700 To: Fisher Mark , urn-ietf From: Ron Daniel Subject: Re: [URN] Collecting open issue information on the syntaxdraft... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Fisher Mark (at least at 08:03 AM 11/26/96 EST) >I am curious as to how you see URNs being used. From my perspective as an >Intranet service provider, I could well see URNs in use by at least (almost) >each Fortune 500 company, as well as many academic and research >organizations, with each one having their own namespace. This is exactly what I do NOT want to see happen early on, although such namespaces are going to occur in the fullness of time. What I want to see first is the use of internationally standardized namespaces such as ISBN for on-line access to books, ISSN/SICI for access to magazine, journal, and newspaper articles; ISAN for access to video programs and movies; ISWC/ASCAP/BMI identifiers for access to music; UPC for access to product descriptions, etc. National Standards bodies, such as ANSI, and industry associations, such as the EIA, may also have developed namespaces we could support. The Fortune 500 already make use of one or more of these namespaces for particular purposes (especially UPC). Until we come up with the procedures for registering company-specific namespaces and dealing with the inevitable conflicts over trademark-style issues, I want to err on the side of caution. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA08760 for urn-ietf-out; Tue, 26 Nov 1996 09:37:32 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA08755 for ; Tue, 26 Nov 1996 09:36:55 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15310 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 09:36:53 -0500 Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <16862(1)>; Tue, 26 Nov 1996 06:36:30 PST Received: by palimpsest.parc.xerox.com id <135>; Tue, 26 Nov 1996 06:36:16 PDT To: rbriscoe@jungle.bt.co.uk Cc: FisherM@is3.indy.tce.com, Harald.T.Alvestrand@uninett.no, urn-ietf@bunyip.com Subject: Re: [URN] Persistence as part of URN framework From: Larry Masinter Message-Id: <96Nov26.063616pdt."135"@palimpsest.parc.xerox.com> Date: Tue, 26 Nov 1996 05:36:16 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com # All I wanted was an *optional* persistence value to be possible, so that the # URN resolution service could indicate the longevity of the resolver (not the # URN), at least until the longevity was extended once the people managing it # were willing to commit to a longer running service. ... # No-one seems to be able to get their head round the fact that such expiry # times are meaningless if you don't know how long you will be able to resolve # URNs which end up pointing to HTTP, but might point to another scheme later # to keep them alive. I think the problem is that people just aren't thinking # in terms of how much the world will change in the decades ahead. All I'm # trying to propose is a way to avoid having to poll for broken resolution # services in the future. # I give up. No URN resolution protocol that doesn't explicitly deal with the issues of what happens when providers quit, merge, or split can seriously claim to address URN requirements. A protocol can be marked as 'Experimental', but even Experimental drafts can be marked to clearly indicate what parts of the problem they're not handling. The experiment then can help determine how serious, in practice, the problem really is. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA08375 for urn-ietf-out; Tue, 26 Nov 1996 09:12:45 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA08370 for ; Tue, 26 Nov 1996 09:12:43 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15222 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 09:12:41 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id JAA23138; Tue, 26 Nov 1996 09:12:41 -0500 Message-Id: <199611261412.JAA23138@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Tue, 26 Nov 1996 09:12:40 -0500 In-Reply-To: Fisher Mark's message as of Nov 26, 8:03 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Fisher Mark , Ron Daniel , urn-ietf Subject: Re: [URN] Collecting open issue information on the syntaxdraft... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com [Mark Fisher wrote:] > I am curious as to how you see URNs being used. From my perspective as an > Intranet service provider, I could well see URNs in use by at least (almost) > each Fortune 500 company, as well as many academic and research > organizations, with each one having their own namespace. Sounds like an > awful lot of work to me for those of us on the mailing list to have to vet > each of those namespaces... In the running terminology, "a namespace" refers to a particular name assignment/resolution structuring -- e.g., ISBNs might be "a namespace". While there will be some kind of overall governing of individual namespaces, assignment of subspaces is expected/needed. I think your examples are really about individual companies/institutions/ISPs wanting to have a piece of a space to control, adn that is definitely expected (e.g., top-level domains are individually controlled and partitioned in DNS; but the "owner" of a domain name can assign as many subdomains as they want, subject to the rules of DNS, not the domain-assigner). I think that, given one or two "inet"-type URN namespaces, what the organizations you've cited will want is the ability to assign names in (some part of) those spaces. Leslie. -- ---------------------------------------------------------------------------- "The light at the end of the tunnel Leslie Daigle is often the blindingly obvious..." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA07970 for urn-ietf-out; Tue, 26 Nov 1996 08:19:49 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA07965 for ; Tue, 26 Nov 1996 08:19:47 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15077 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 08:19:45 -0500 Received: by seawall with (8.6.12/) id IAA10989; Tue, 26 Nov 1996 08:19:42 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma010979; Tue Nov 26 08:19:27 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <329AEF40@MSMAIL.INDY.TCE.COM>; Tue, 26 Nov 96 08:23:12 EST From: Fisher Mark To: Ron Daniel , urn-ietf Subject: Re: [URN] Collecting open issue information on the syntaxdraft... Date: Tue, 26 Nov 96 08:03:00 EST Message-Id: <329AEF40@MSMAIL.INDY.TCE.COM> Encoding: 21 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com >I recommend that, for some time, new namespaces receieve standards-track >review, rather like new URL schemes currently do. That review process >is the place where we can address concerns such as limited longevity or >legal liability due to the inclusion of particular attempts at >"friendliness". The syntax draft does not have to address that issue one >way or the other. I am curious as to how you see URNs being used. From my perspective as an Intranet service provider, I could well see URNs in use by at least (almost) each Fortune 500 company, as well as many academic and research organizations, with each one having their own namespace. Sounds like an awful lot of work to me for those of us on the mailing list to have to vet each of those namespaces... (The "Fortune 500", for non-U.S. listmembers, is the top 500 companies in the U.S. as rated by the U.S. magazine "Fortune". Lots of namespaces to check out...) ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA06514 for urn-ietf-out; Tue, 26 Nov 1996 05:27:29 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA06509 for ; Tue, 26 Nov 1996 05:27:14 -0500 Received: from [132.146.5.1] by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12468 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 05:27:11 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 26 Nov 1996 10:26:29 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 26 Nov 1996 10:26:06 +0000 Received: from by kaa.jungle.bt.co.uk; Tue, 26 Nov 96 10:24:45 GMT Message-Id: <2.2.32.19961126102739.006cf950@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Nov 1996 10:27:39 +0000 To: Fisher Mark From: Bob Briscoe Subject: Re: [URN] Persistence as part of URN framework Cc: "Harald.T.Alvestrand@uninett.no" , "urn-ietf@bunyip.com" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com Mark, Many apologies for such a long time replying. I had to get some work delivered, which translates to "ignore mailing lists". All I wanted was an *optional* persistence value to be possible, so that the URN resolution service could indicate the longevity of the resolver (not the URN), at least until the longevity was extended once the people managing it were willing to commit to a longer running service. If the people running the resolver weren't willing to think about persistence, a default longevity value of 0 could be sent out in the NAPTR records. However, I can find no-one else who considers this important, so I'll drop out. I've been off-line with Ron Daniel who is happy that schemes such as HTTP which have expiry headers can get this information to you once you have resolved how to speak to HTTP. No-one seems to be able to get their head round the fact that such expiry times are meaningless if you don't know how long you will be able to resolve URNs which end up pointing to HTTP, but might point to another scheme later to keep them alive. I think the problem is that people just aren't thinking in terms of how much the world will change in the decades ahead. All I'm trying to propose is a way to avoid having to poll for broken resolution services in the future. I give up. Bob At 09:53 07/11/96 EST, Fisher Mark wrote: > >>Using DNS TTL records for this is just broken; DNS TTLs are used >>to limit caching of name->address mapping, and in the NAPTR proposal, >>they should be a fraction of the time one expects to have advance >>warning of a server relocation or mapping restructure. >>Normal TTLs are on the order of 3 days, and are usually reduced to less >>than 1 day before serious network reorganizations. > >And if you are changing your resolution services faster than that, you are >changing them too fast (IMHO). Perhaps the key idea TimBL came up with in >devising the Web was that, unlike other hypertext systems (including the >Dexter model), links could be broken, i.e. nonfunctional. This single idea >was perhaps above all others important in spreading the Web far and wide, as >perfectly reliable systems as difficult to construct (even for an >appropriately low value of "perfect"). Under the Dexter model, an >application will die or limp on after reporting an internal error upon >encountering a broken hyperlink. In the Web, the UA just keeps surfing on >to the next link. > >All that URNs can do is assist in persistence; persistence itself must be >maintained outside the URN architecture, as persistence is ultimately a >political/economic quality, not a technical quality. We would expect a BT >URN to persist because of our trust in BT, not because there is some >technical solution to persistence. Persistence is assisted in URNs by the >ability to hand off resolution duties automagically to successor resolution >entities. I would regard measures of persistence to be an optional but >necessary part of the metadata for a URN, not as mandatory metadata. It is >quite possible that URN will see incredibly wide use, as much or more as >URLs are now ("every person a URN namespace owner"). Many of these >namespaces may just persist for a few years or months, with the owner not >caring about measures of persistence. Persistence is ultimately up to the >creating/resolving entity(s). > >Uniqueness is an easier problem than persistence, although uniqueness has a >strong political/economic component. One can certainly imagine the case of >URNs for government materials that, after they are first created for public >consumption, are found to be embarrassing to that government and the URNs >are silently, suddenly changed to refer to much more innocuous materials. > Uniqueness, also, is ultimately up to the creating/resolving entity. >====================================================================== >Mark Leighton Fisher Thomson Consumer Electronics >fisherm@indy.tce.com Indianapolis, IN > > Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA24916 for urn-ietf-out; Mon, 25 Nov 1996 12:06:02 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA24907 for ; Mon, 25 Nov 1996 12:05:47 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06863 (mail destined for urn-ietf@services.bunyip.com); Mon, 25 Nov 96 12:05:27 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id MAA17730; Mon, 25 Nov 1996 12:05:22 -0500 Date: Mon, 25 Nov 1996 12:05:22 -0500 Message-Id: <199611251705.MAA17730@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: urn-ietf@bunyip.com Subject: [URN] URN resolution requirements and framework Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com Hi! Attached is the first draft of a proposed document on requirements and a framework for URN resolution. It is based on the internet drafts presented at the URN BOF in Montreal separately on requirements (without the discussion of various schemes) and the framework document by Leslie, Patrik, and Renato. I have added an additional preliminary section on assumptions, which seems important in light of some of the discussions on this list. I've also tried to enhance the requirements, again based on discussions and broaden the framework a little, to make it less specific to the NAPTR proposal, in order to extend its utility. We will talk about it in San Jose, but in the meantime comments and discussion (no rotten eggs or tomatoes, please:-) are welcome. Karen PS: To the Americans on the list, have a nice Thanksgiving! ______________________________ Internet Draft Karen R. Sollins draft-ietf-urn-req-frame-00.txt MIT/LCS Expires May 26, 1997 November 26, 1996 Requirements and a Framework for URN Resolution Systems Status of this draft This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract: This document addresses the issues of the discovery of local URN resolution services that in turn will directly translate URNs into URLs and URCs. The document falls into three major parts, the assumptions underlying the work, the requirements in order to be a viable URN-resolution-service discovery service or UDS, and a framework for designing UDSs. The requirements fall into three major areas: evolvability, usability, and security and privacy. A UDS that is compliant with the framework will not necessarily be compliant with the requirements. Compliance with the requirements will need to be validated separately. 1. Introduction The purpose of this document is to lay out the engineering criteria for what we will call here a URN-resolution-service discovery service (UDS). __________ Acknowledgments Foremost acknowledgment for this document goes to Lewis Girod, as my co-author on a previous URN requirements document and for his insightful comments on this version of the document. In addition, I recognize the contributors to a previous URN framework document, the "Knoxville" group. There are too many of you to acknowledge here individually, but thank you. Finally, I must thank the contributors to the URN working group mailing list (urn-ietf@bunyip.com), for their animated discussions on these and related topics. URN Resolution Requirements Page 1 This is a component of the realization of an information infrastructure. In the case of this work, that infrastructure is to be available, "in the Internet" or globally, and hence the solutions to the problems we are addressing must globally scalable. In this work, we are focussing specifically on naming of resources and resolution of those names to the exclusion of other problems such as typing, resource access and availability, security of the resources, etc. Those are all important problems, but not part of this effort. The Uniform Resource Identifier Working Group defined a naming architecture, as demonstrated in a series of three RFCs 1736[RFC1736], 1737{RFC1737}, and 1738[RFC1738]. Although several further documents are needed to complete the description of that architecture, it incorporates three core functions often associated with "naming": identification, location, and mnemonics or semantics. Names may provide the ability to distinguish one resource from another, by distinguishing their "names". Names may help to provide access to a resource by including "location" information. Lastly, names may have other semantic or mnemonic information that either helps human users remember or figure out the names, or include other semantic information about the resource being named. The URI working group concluded that there was need for persistent, globally unique identifiers, distinct from location or other semantic information; these "names" provide identity, in that if two of them are "the same" (under some simple rule of canonicalization), they identify the same resource. Furthermore, the group decided that these "names" were generally to be for machine, rather than human consumption. One can imagine a variety human-friendly naming (HFN) schemes supporting different suites of applications and user communities. These will need to provide mappings to URNs in tighter or looser couplings, depending on the namespace. It is these that will be mnemonic, content-full, and perhaps mutable, to track changes in use and semantics. They may provide nicknaming and other aliasing, relative or short names, context sensitive names, descriptive names, etc. The URI naming architecture as described in the introductions to RFCs 1736 and 1737 lays out three sorts of components to the naming architecture: identifiers called Uniform Resource Names (URNs), locators called Uniform Resource Locators (URLs) and semantic meta-information called Uniform Resource Characteristics (URCs). This document focusses on part of the problem of the translation from URN to URL and/or URC. Within the URI community there has been a concept used frequently that for lack of a better term we will call a _hint_. A hint is something that helps in the resolution of a URN. Examples of hints are: 1) the name of a resolution service that may further resolve the URN, 2) the address of such a service, 3) a location at which the resource was previously found. The defining feature of hints is that they are only hints; they may be out of date, temporarily invalid, or only applicable within a specific locality. They do not provide a guarantee of access, but they probably will help in the resolution process. Wemust assume that most resolutions of URNs will be provided by the use of locally stored hints, because maintaining a database of globally available, completely up-to-date location information is infeasible for performance reasons. There are a number of circumstances in which one can imagine that hints become invalid, either because a resource has moved or because a different URN resolution service has taken over the URN Resolution Requirements Page 2 responsibility for resolution of the URN. Hints may be found in a variety of places. It is generally assumed that a well engineered system will maintain a set of hints for each URN at each location where that URN is found. In addition, for those situations in which those hints found locally fail, a well-engineered system will provide a fall-back mechanism for discovering further hints. It is this fall-back mechanism, a UDS, that is being addressed in this document. As with all hints, there can never be a guarantee that access to a resource will be available to all clients, even if the resource is accessible to some. However, a UDS is expected to work with reasonably high reliability, and, hence, may result in increased response time. The remainder of this document falls into three sections. The first identifies several sets of assumptions underlying this work. The next lays out the requirements for a URN-resolution-service discovery service. This section is probably the most critical of the document, because it is this that provides the metric for whether or not a proposed scheme for a UDS is adequate or not. For the reader short on time, each of the three major subsections of the requirements section concludes with a summary list of the requirements identified in that section. The final section of the document lays out a framework for such UDSs. The purpose of this last section is to bound the search space for UDS schemes. One must be careful not to assume that because a UDS scheme fits within the framework that it necessarily meets the requirements. As will be discussed further in this last section, designing within the framework does not guarantee compliance, so compliance evaluation must also be part of the process of evaluation of a scheme. 2. Assumptions Based on previous internet drafts and discussion in both the URN BOFs and on the URN WG mailing list, three major areas of assumptions are apparent: longevity, delegation, and independence. Each will be discussed separately. The URN requirements state that a URN is to be a "persistent identifier". It is probably the case that nothing will last forever, but in the time frame of resources, users of those resources, and the systems to support the resources, the identifier should be considered to be persistent or have a longer lifetime than those other entities. There are two assumptions that are implied by longevity of URNs: mobility and evolution. "Mobility" assumes that. everything will move over the life of a URN. For example, resources will move from one machine to another, because individual machines have a much shorter lifetime than resources, generally measured in a number of years less than a decade. Owners of resources may move and wish their resources to follow them. The services themselves will move. "Evolutions" assumes that the supporting infrastructure will evolve. This may take the form of entirely new transport protocols or new versions of existing protocols. Furthermore, services such as storage services may evolve; it is even possible that within a human lifetime the Unix file system model may no longer be in use! Clearly there will be evolution of and improvement in supporting authentication and security mechanisms. These are only examples. In general, we must assume that almost any piece of the supporting infrastructure of URN resolution will evolve. In order to deal with both the mobility and evolution assumptions that derive URN Resolution Requirements Page 3 from the assumption of longevity, we must assume that users and their applications can remain independent of these mutating details of the supporting infrastructure. The second and third assumptions are two forms of modularity, delegation and isolation. The delegation assumption is that an entity may partition and pass off some of its authority or responsibility. One of those responsibilities is for assigning URNs; practically speaking, there cannot be only a single authority for assigning URNs. We expect that there will be a multi-tiered naming authority delegation. Furthermore, it is difficult to imagine a non-partitioned and delegated global UDS, meaning that hint discovery and resolution will be partitioned and delegated. In some UDS schemes, the delegation of naming authority will form a basis for delegating the management and dispensing of location information. The third assumption is independence or isolation of one authority from another and, at least to some extent from its parent. Underlying much of the thinking and discussion in the URI and URN working groups has been the assumption that when a component delegates authority to another component, the delegatee can operate in that domain independently of its peers and within bounds specified by the delegation, independently of the delegator. This isolation is critically important in order to allow for independence of policy and mechanism. There are a number of more specific assumptions that fall under this rubric of isolation. First, we assume that the publisher of a resource can choose resolution services, independently of choices made by others. At any given time, the owner of a namespace may choose a particular URN resolution service for that delegated namespace. Such a URN resolution service may be outside the UDS service model, and just identified or located by the UDS service. Second, it must be possible to make a choice among UDS services, perhaps based on different underlying internal architectures. The reason that this is an assumption is that there must be an evolutionary path through a sequence of core UDS services. Although at any given time there is likely to be only one or a small set of such services, the number is likely to increase during a transition period from one architecture to another. Thus, it must be assumed that clients can make a choice among a probably very small set of UDSs. Third, there must be independence in the choice about levels and models of security and authenticity required. This choice may be made by the owner of a naming subspace, in controlling who can modify hints in that subspace. A naming authority may delegate this choice to the owners of the resources named by the names it has assigned. There may be limitations on this freedom of choice in order to allow other participants to have the level of security and authenticity they require, for example, in order to maintain the integrity of the UDS infrastructure as a whole. Fourth, there is an assumption of independence of choice of the rule of canonicalization of URNs within a namespace, limited by any restrictions or constraints that may have been set by its parent namespace. This is a choice held by naming authorities over their own subnamespaces. Rules for canonicalization will be discussed further in the framework section below. Thus, there are assumptions of independence and isolation to allow for delegated, independent authority in a variety of domains. URN Resolution Requirements Page 4 The modularity assumptions of delegation and isolation imply independence of decision and implementation, leading to a decentralization that provides a certain degree of safety from denial of service. Based on these these assumptions in conjunction with that of longevity and those for URLs and URNs as detailed in RFCs 1736 and 1737, we can now turn to the requirements for a URN services delegation service. 3. Requirements The requirements applying to a URN-resolution-service discovery service or UDS center around three important design goals: evolvability, usability, and security and privacy. At its core the function of a UDS is to provide hints for accessing a resource given a URN for it. These hints may range in applicability from local to global, and from short-lived to long-lived. They also may vary in their degree of verifiable authenticity. While it may be neither feasible nor necessary that initial implementations support every requirement, every implementation must support evolution to systems that do support every requirement. It is also important to note that there are other requirements, not applicable specifically to a UDS that must also be met. A whole URN system will consist of namespaces, the resolution information for them, and the mapping from names in the namespaces to resolution information (or hints). URN schemes must meet the requirements of RFC 1737. Resolution information, to the extent it is expressed as URLs must meet the requirements of RFC 1736. But this does not tell the whole story. Although the URN working group will identify several acceptable namespaces and the rules binding them, such as how delegation occurs, how it is expressed in the names, how and to what extent binding to hint information will be constrained by the namespace, in the long run a document will be needed to guide the evaluation criteria for acceptance of new namespaces. These are not included in the list of requirements below because they are not requirements for a UDS, but rather for naming schemes themselves. 3.1 Evolution One of the lessons of the Internet that we must incorporate into the development of mechanisms for resolving URNs is that we must be prepared for change. Such changes may happen slowly enough to be considered evolutionary modifications of existing services or dramatically enough to be considered revolutionary. They may permeate the Internet universe bit by bit, living side by side with earlier services or they may take the Internet by storm, causing an apparent complete transformation over a short period of time. There are several directions in which we can predict the need for evolution, even at this time, prior to the deployment of any such service. At the very least, the community and the mechanisms proposed should be prepared for these. First, we expect there to be additions and changes to the mechanisms. The community already understands that there must be a capacity for new URN schemes. A URN scheme will define a set of URNs that meet the URN requirements[RFC1737], but may have further constraints on the internal URN Resolution Requirements Page 5 structure of the URN. The requirements document would allow for an overall plan in which URN schemes are free to specify parts of the URN that are left opaque in the larger picture. In fact, a URN scheme may choose to make public the algorithms for any such "opaque" part of the URN. For example, although it may be unnecessary to know the structure of an ISBN, the algorithm for understanding the structure of an ISBN has been made public. Other schemes may either choose not to make their algorithms public, or choose a scheme in which knowledge of the scheme does not provide any significant semantics to the user. In any case, we must be prepared for a growing number of URN schemes. Often in conjunction with a new URN scheme, but possibly independently of any particular URN scheme, new resolution services may evolve. For example, one can imagine a specialized resolution service based on the particular structure of ISBNs that improves the efficiency of finding documents given their ISBNs. Alternatively, one can also imagine a general purpose resolution service that trades performance for generality; although it exhibits only average performance resolving ISBNs, it makes up for this weakness by understanding all existing URN schemes, so that its clients can use the same service to resolve URNs regardless of naming scheme. In this context, there will always be room for improvement of services, through improved performance, better adaptability to new URN schemes, or lower cost. In any case, new models for URN resolution will evolve and we must be prepared to allow for their participation in the overall resolution of URNs. If we begin with one overall plan for URN resolution, into which the enhancements described above may fit, we must also be prepared for an evolution in the authentication schemes that will be considered either useful or necessary in the future. There is no single globally accepted authentication scheme, and there may never be one. Even if one does exist at some point in time, there will always be threats to it, and so we must always be prepared to move on to newer and better schemes, as the old ones become too easily spoofed or guessed. Lastly, in terms of mechanism, although we may develop and deploy a single UDS scheme initially, we must be prepared for that top level model to evolve. Thus, if the UDS model supports an apparently centralized (from a policy standpoint) scheme for inserting and modifying authoritative information, over time we must be prepared to evolve to a different model, perhaps one that has a more distributed model of authority and authenticity. If the model has no core but rather a cascaded partial discovery of information, we may find that this becomes unmanageable with an increase in scaling. Whatever the core of the model, we must be prepared for it to evolve with changes in scaling, performance, and policy constraints such as security and cost. Second, in addition to the evolution of resolution mechanisms, we expect that the community will follow an evolutionary path towards the separation of semantics from identification. The URN requirements document suggested this path as well, and there has been general agreement in much of the community that such a separation is desirable. This is a problem that the public at large has generally not understood. Today we see the problem most clearly with the use of URLs for identification. When a web page moves, its URL becomes invalid. URN Resolution Requirements Page 6 Suppose such a URL is embedded in some page, stored in long term storage. There are three possible outcomes to this scenario. One possibility is that the client is left high and dry with some message saying that the page cannot be found. Alternatively, a "forwarding pointer" may be left behind, in the form of an explicit page requesting the client to click on a new URL. Although this will allow the client to find the intended page, the broken link cannot be fixed because the URL is embedded in a file outside of the client's control. A third alternative is that the target server supplies an HTTP redirect so that the new page is provided for the client automatically. In this case, the client may not even realize that the URL is no longer correct. The real problem with both of these latter two situations is that they only work as long as the forwarding pointer can be found at the old URL. Semantics, in this case location information, was embedded in the identifier, and the resolution system was designed to depend on the semantics being correct. There are few cases in which we can expect semantics of any sort to remain valid for a long time, but in many cases references need to have long lifespans. Most documents are only useful while their references still function. We expect the evolution to separation of semantics from identification to move along at least three paths. The first will be to develop temporary aliases to capture the semantics currently embedded in identifiers. This will require additional translation, but it will allow for the development of semantics-free URNs. Second, we expect locally shared or private aliases to arise, again supported by a translation mechanism and allowing for the long-term storage of global, semantics-free URNs. Such an aliasing scheme may be used to permit local aliases for named resources as well as to present these aliases to users in lieu of the URNs themselves. Lastly, we expect there may be a development of global aliases. These will be more user friendly "names" that would be shared on a much larger scale, and might be defined in some global registry. This may include trademarked names as well as names in extremely common use. As with the other alias systems, a facility for translation is needed. However, in this case, since the system of aliases is of global scope, the translation facility will be very slow if each time an alias is translated it needs to query a centralized or even reasonably distributed global registry. In order to achieve acceptable speeds, the translation facility w Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA27284 for urn-ietf-out; Fri, 22 Nov 1996 17:35:04 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA27273 for ; Fri, 22 Nov 1996 17:34:54 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26813 (mail destined for urn-ietf@services.bunyip.com); Fri, 22 Nov 96 17:34:48 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id OAA19698; Fri, 22 Nov 1996 14:33:14 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id OAA23886; Fri, 22 Nov 1996 14:33:35 -0800 (PST) Date: Fri, 22 Nov 1996 14:33:35 -0800 (PST) From: Terry Allen Message-Id: <199611222233.OAA23886@ishtar.fsc.fujitsu.com> To: jayhawk@ds.internic.net, leslie@bunyip.com, urn-ietf@bunyip.com Subject: Re: [URN] Collecting open issue information on the syntax draft... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com (Apologies for being out of touch recently while at SGML 96.) > Any namespace (existing or newly-devised) that is proposed as a URN-namespace and fulfills the criteria of URN-namespaces must be expressed in this syntax. If names in these spaces contain characters other than those defined for the URN character set, they must be translated into canonical format as discussed in section 2.2. I agree with Leslie's proposed emendation and the reasons she expressed for it. EXCEPT, that the name space itself need not be expressed in this syntax, only the URN represntation of that name space. So perhaps "must be expressed" should be "must have rules for expressing its names". Regards, Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA25105 for urn-ietf-out; Fri, 22 Nov 1996 15:27:43 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA25100 for ; Fri, 22 Nov 1996 15:27:40 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25951 (mail destined for urn-ietf@services.bunyip.com); Fri, 22 Nov 96 15:27:33 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id NAA15209; Fri, 22 Nov 1996 13:27:30 -0700 (MST) Message-Id: <2.2.32.19961122203559.0073a20c@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Nov 1996 13:35:59 -0700 To: leslie@bunyip.com (Leslie Daigle), "URN mailing list" From: Ron Daniel Subject: Re: [URN] Collecting open issue information on the syntax draft... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Leslie Daigle (at least at 02:42 PM 11/22/96 -0500) >Once we've settled on a syntax and handling mechanisms, we have nothing >further to say about what people do within those constraints. Hear! Hear! I recommend that, for some time, new namespaces receieve standards-track review, rather like new URL schemes currently do. That review process is the place where we can address concerns such as limited longevity or legal liability due to the inclusion of particular attempts at "friendliness". The syntax draft does not have to address that issue one way or the other. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA24537 for urn-ietf-out; Fri, 22 Nov 1996 14:42:06 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA24532 for ; Fri, 22 Nov 1996 14:42:03 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25620 (mail destined for urn-ietf@services.bunyip.com); Fri, 22 Nov 96 14:42:02 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id OAA21503; Fri, 22 Nov 1996 14:42:01 -0500 Message-Id: <199611221942.OAA21503@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Fri, 22 Nov 1996 14:42:00 -0500 In-Reply-To: "Ryan Moats"'s message as of Nov 22, 10:41 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Ryan Moats" , "URN mailing list" Subject: Re: [URN] Collecting open issue information on the syntax draft... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com This touches on something I asked Ryan about in the draft, and wanted to bring up here. In reading through the recent thread on character sets and URNs (admittedly, slightly out of step with real-time), it seemed to come to a reasoned and reasonable conclusion about handling character sets other than US-ASCII in URNs. I didn't feel that this was completely represented in the syntax draft, although I'm not sure whether it was because my reading of the thread was at fault. [Ryan brought up:] > 4. human readability for new namespaces: MUST/SHOULD? This is in reference to the paragraph, in the syntax draft: Some existing name spaces that have the properties of the URN-space contain some human-significant components, and these exist in a wide variety of languages. However, URNs are NOT intended to convey information that is significant to humans. While the translation rule in section 2.2 is provided for existing namespaces, new namespaces, as part of their registration documentation, MUST define a discipline for assigning new URNs that does not simplify the generation of human-significant names. The way I read this, the only thing the syntax draft is recognizing is that there may be existing namespaces that have things that happen to be human-readable, and these may be in character sets other than US-ASCII, so UTF-8 is proposed as a mechanism of handling these anomalies -- but that these namespaces should ensure that future names assigned should not suffer from human-readability. (Admittedly, a "strong" reading of the statement, but I'm trying to illustrate the point). I just don't see the point of such a statement. The syntax draft defines how to formally express a URN -- in US-ASCII or UTF-8. Period. What things a namespace-proposer chooses to use in their namespace is not relevant, as long as they can be carried in this syntax, and otherwise meet the requirements of namespaces (uniqueness of names, etc). So, if someone proposes a namespace that happens to be human-friendly (_whatever_ that means!) in spite of meeting all these requirements, cool! What was intended in the charter was to avoid having the syntax and handling mechanisms' design _driven_ by a need to keep things "human-friendly" (e.g., shorter than URLs, no funny punctuation, whatever). Once we've settled on a syntax and handling mechanisms, we have nothing further to say about what people do within those constraints. I bring all of this up because it is not clear to me that particular paragraph adequately represented what _seemed_ to be consensus on the matter on the list. If that is the case, I would propose the following change to the syntax draft: > 3. Support of existing legacy naming systems and new naming systems > URN-aware applications MAY accept as input other resource identifiers > from existing legacy namespaces. If such identifiers contain > characters that are not members of the URN character set specified in > section 2.2, the identifier MUST be translated to canonical format as > discussed in section 2.2. > > Some existing name spaces that have the properties of the URN-space > contain some human-significant components, and these exist in a wide > variety of languages. However, URNs are NOT intended to convey > information that is significant to humans. While the translation > rule in section 2.2 is provided for existing namespaces, new > namespaces, as part of their registration documentation, MUST define > a discipline for assigning new URNs that does not simplify the > generation of human-significant names. would become: 3. Support of existing legacy naming systems and new naming systems Any namespace (existing or newly-devised) that is proposed as a URN-namespace and fulfills the criteria of URN-namespaces must be expressed in this syntax. If names in these spaces contain characters other than those defined for the URN character set, they must be translated into canonical format as discussed in section 2.2. Well, it's not the most inspired wording, but can people live with this? Leslie. -- ---------------------------------------------------------------------------- "The light at the end of the tunnel Leslie Daigle is often the blindingly obvious..." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA18932 for urn-ietf-out; Fri, 22 Nov 1996 11:40:13 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA18927 for ; Fri, 22 Nov 1996 11:40:11 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24257 (mail destined for urn-ietf@services.bunyip.com); Fri, 22 Nov 96 11:40:08 -0500 Message-Id: <9611221640.AA24257@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Fri Nov 22 10:39 CST 1996 From: "Ryan Moats" To: "URN mailing list" Date: Fri, 22 Nov 96 10:41:13 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] Collecting open issue information on the syntax draft... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com Folks- I've been going back over the open issues with the syntax draft and trying to ensure that I have all of them before I start thinking about slides for San Jose. The open issues as I see them with this document at this moment in time are: 1. "urn:" tag: YES/NO? 2. URN char set: additions/deletions? 3. %escaping: just octets outside char set or reserve/literal chars as well? 4. human readability for new namespaces: MUST/SHOULD? 5. equivalency: needs some more work (as you pointed out above) 6. How do we know when a URN ends? I don't want to necessarily discuss them now, but want to be sure that I haven't missed anything before San Jose. Ryan P.S. I'm providing a short synopsis of the issue for those that aren't straightforward: %escaping ---------------- The issue here (as I see it) is that the current rules for URN syntax reserve % for escaping characters outside the URN char set. A namespace identifier that use % to escape the literal use of a character that also has a special meaning for that namespace can not be made into a valid URN. I happen to think this requires fixing, or at least more thought. equivalency ------------------ It has been pointed out to me that saying "two URNs are equivalent if they return the same resource" is not quite an accurate statement. This statement requires some improvement, and such will be discussed. When does a URN end? --------------------------------------- It has also been pointed out to me that the syntax draft does not indicate when a URN ends. Some statement should be added to indicate this situation. My current preference is to state that a "On the line, the URN ends with an octet that is not a member of the URN charset", or something like that, but what about other formats? Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA18679 for urn-ietf-out; Fri, 22 Nov 1996 11:07:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA18674 for ; Fri, 22 Nov 1996 11:07:35 -0500 Received: from ietf.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23928 (mail destined for urn-ietf@services.bunyip.com); Fri, 22 Nov 96 11:07:33 -0500 Received: from ietf.org by ietf.org id aa27563; 22 Nov 96 9:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: urn-ietf@bunyip.com From: Internet-Drafts@ietf.org Subject: [URN] I-D ACTION:draft-ietf-urn-http-conv-00.txt Date: Fri, 22 Nov 1996 09:41:23 -0500 Message-Id: <9611220941.aa27563@ietf.org> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org Errors-To: owner-urn-ietf@bunyip.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Conventions for the Use of HTTP for URN Resolution Author(s) : R. Daniel Filename : draft-ietf-urn-http-conv-00.txt Pages : 6 Date : 11/21/1996 The URN-WG was formed to specify persistent, location-independent names for network accessible resources, and resolution mechanisms to retrive the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal [1]. That proposal does not get the client software all the way from the URN to the resource. Instead, it gets the client from a URN to a "resolver", which is a system that can then tell the client where the resource is. The NAPTR draft defines a "resolution protocol" to be the protocol used to speak to a resolver in order to obtain the resource, its location(s), or other information about the resource. The NAPTR proposal allows different resolution protocols to be used for commuicating with resolvers. This draft establishes conventions for encoding URN resolution requests and responses in HTTP 1.0 (and 1.1) requests and responses. The primary goal of this draft is to define a convention that is simple to implement and will allow existing HTTP servers to easily add support for URNresolution. We expect that the resolution databases that arise will be useful when more sophisticated resolution protocols are developed later. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-http-conv-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-http-conv-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-http-conv-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121163444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-http-conv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-http-conv-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121163444.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA18627 for urn-ietf-out; Fri, 22 Nov 1996 11:05:28 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA18622 for ; Fri, 22 Nov 1996 11:05:25 -0500 Received: from ietf.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23894 (mail destined for urn-ietf@services.bunyip.com); Fri, 22 Nov 96 11:05:17 -0500 Received: from ietf.org by ietf.org id aa27580; 22 Nov 96 9:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: urn-ietf@bunyip.com From: Internet-Drafts@ietf.org Subject: [URN] I-D ACTION:draft-ietf-urn-naptr-01.txt Date: Fri, 22 Nov 1996 09:41:32 -0500 Message-Id: <9611220941.aa27580@ietf.org> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org Errors-To: owner-urn-ietf@bunyip.com --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Resolution of Uniform Resource Identifiers using the Domain Name System Author(s) : R. Daniel, M. Mealling Filename : draft-ietf-urn-naptr-01.txt Pages : 13 Date : 11/21/1996 Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. In addition to locating resolvers, the NAPTR provides for other naming systems to be grandfathered into the URN world, provides independence between the name assignment system and the resolution protocol system, and allows multiple services (Name to Location, Name to Description, Name to Resource, ...) to be offered. In conjunction with the SRV RR proposal [3], the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-naptr-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-naptr-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121163946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-naptr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-naptr-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121163946.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA09656 for urn-ietf-out; Thu, 21 Nov 1996 21:17:32 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA09651 for ; Thu, 21 Nov 1996 21:17:30 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20265 (mail destined for urn-ietf@services.bunyip.com); Thu, 21 Nov 96 21:17:29 -0500 From: Leslie Daigle Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id VAA20575 for urn-ietf@bunyip.com; Thu, 21 Nov 1996 21:17:29 -0500 Date: Thu, 21 Nov 1996 21:17:29 -0500 Message-Id: <199611220217.VAA20575@beethoven.bunyip.com> To: urn-ietf@bunyip.com Subject: [URN] Status Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Leslie Daigle Errors-To: owner-urn-ietf@bunyip.com Okay, on the brink of the SJ IETF meeting, it seems a good time to review the progress of this Fall, particularly with respect to our charter. So, first of all, congratulations to everybody for a very productive Fall; the document editors have been working _very_ hard, and people have been unstinting in their generous, and constructive, commentary. We now have drafts of: . URN Framework and Requirements (soon to be published) . URN Syntax . NAPTR proposed implementation . HTTP resolution conventions we are _that_ close to having something that can actually be deployed in a test-fashion. Ah, yes, there is one thing missing: a namespace. On previous occasions, one or more people have suggested that they would be willing to work on the definition of a new namespace, or on the use of an existing namespace in the URN context ("grandfathering"). Now that the syntax is settling down, I would appreciate volunteers and proposals for namespaces -- please send mail to me, and I will summarize to the list. The agenda for the San Jose meeting is pretty straightforward -- there will be time to talk about specific issues with individual drafts, assessing where we are, and determining how to tackle the remaining required drafts (read: flushing out volunteers, if none are evident before then :-) Thanks! Leslie. P.S.: By the way -- it has been pointed out to me that the URL I circulated a couple of weeks ago was wrong (although our kindly web-maintainers have aliased around my gaffe). The proper URL is: http://www.bunyip.com/research/ietf/urn-ietf/ I have updated the page to include our charter and the pointers to other work that people proposed. I will include pointers to the new crop of I-D's, as soon as things settle down (i.e.: after Tuesday, 5pm!). ---------------------------------------- IETF URN Working Group ---------------------------------------- Agenda for Thursday, December 12, 1996, San Jose, California. Status review: . Status of documents . Progress on WG milestones Discussion of document-specific issues: . URN Framework and Requirements . URN Syntax . NAPTR proposal . HTTP conventions Where to go from here: . addressing remaining documents ---------------------------------------------------------------------------- "The light at the end of the tunnel Leslie Daigle is often the blindingly obvious..." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA08349 for urn-ietf-out; Wed, 20 Nov 1996 15:34:32 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA08342 for ; Wed, 20 Nov 1996 15:34:18 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08321 (mail destined for urn-ietf@services.bunyip.com); Wed, 20 Nov 96 15:34:00 -0500 Received: from magenta.acl.lanl.gov (rdaniel@magenta.acl.lanl.gov [128.165.147.153]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id NAA29873 for ; Wed, 20 Nov 1996 13:33:58 -0700 (MST) From: "Ronald E. Daniel" Received: (rdaniel@localhost) by magenta.acl.lanl.gov (8.7.5/8.6.4) id NAA29364 for urn-ietf@bunyip.com; Wed, 20 Nov 1996 13:33:58 -0700 (MST) Date: Wed, 20 Nov 1996 13:33:58 -0700 (MST) Message-Id: <199611202033.NAA29364@magenta.acl.lanl.gov> To: urn-ietf@bunyip.com Subject: [URN] NAPTR revision Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ronald E. Daniel" Errors-To: owner-urn-ietf@bunyip.com Hi, I've revised the NAPTR draft to allow characters other than '/' to be used as the delimiters in the regexp field. I will send this in to the ID editor later today. The new version is appended. Regards, Ron === INTERNET DRAFT Ron Daniel draft-ietf-urn-naptr-01.txt Los Alamos National Laboratory Michael Mealling Network Solutions, Inc. 19 Nov., 1996 Resolution of Uniform Resource Identifiers using the Domain Name System [Edits since -00: 1) Changed SRV citation to RFC from ID 2) Pulled underscores from SRV names. 3) Changed syntax of substitution expression to allow delimiter characters other than '/'. ] Status of this Memo =================== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft expires 19 May, 1997. Abstract: ========= Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. In addition to locating resolvers, the NAPTR provides for other naming systems to be grandfathered into the URN world, provides independence between the name assignment system and the resolution protocol system, and allows multiple services (Name to Location, Name to Description, Name to Resource, ...) to be offered. In conjunction with the SRV RR proposal [3], the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing. Introduction: ============= Uniform Resource Locators have been a significant advance in locating resources on the Internet. 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 to serve as persistent, location-independent identifiers for Internet resources in order to overcome most of the problems with URLs. RFC-1737 [1] 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 seperate from the way names are assigned. This is in marked contrast to most URLs, which identify the host to contact and the protocol to use. Readers are referred to [2] for background on the Knoxville framework and for additional information on the context and purpose of this proposal. Seperating 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 DNS to locate "resolvers" that can provide information on individual resources, potentially including the resource itself. To accomplish this, we "rewrite" the URI into a domain name following the rules provided in NAPTR records. Rewrite rules provide considerable power, which is important when trying to meet the goals listed above. However, collections of rules can become difficult to understand. To lessen this problem, the NAPTR rules are *always* applied to the original URI, *never* to the output of previous rules. Locating a resolver through the rewrite procedure may take multiple steps, but the beginning is always the same. Every URI has a colon-delimited prefix. NAPTR resolution begins by taking this prefix, appending the well-known suffix ".urn.net", and querying the DNS for NAPTR records at that domain name. Based on the results of this query, zero or more additional DNS queries may be needed to locate resolvers for the URI. The details of the conversation between the client and the resolver thus located are outside the bounds of this draft. Three brief examples of this procedure are given in the next section. The NAPTR RR provides the level of indirection needed to keep the naming system independent of the resolution system, its protocols, and services. Coupled with the new SRV resource record proposal[3] there is also the potential for replicating the resolver on multiple hosts, overcoming some of the most significant problems of URLs. This is an important and subtle point. Not only do the NAPTR and SRV records allow us to replicate the resource, we can replicate the resolvers that know about the replicated resource. Preventing a single point of failure at the resolver level is a significant benefit. Seperating the resolution procedure from the way names are constructed has additional benefits. Different resolution procedures can be used over time, and resolution procedures that are determined to be useful can be extended to deal with additional namespaces. Terminology =========== "Must" or "Shall" - Software that does not behave in the manner that this document says it must is not conformant to this document. "Should" - Software that does not follow the behavior that this document says it should may still be conformant, but is probably broken in some fundamental way. "May" - Implementations may or may not provide the described behavior, while still remaining conformant to this document. Brief overview and examples of the NAPTR RR: ============================================ A detailed description of the NAPTR RR will be given later, but to give a flavor for the proposal we first give a simple description of the record and three examples of its use. The key fields in the NAPTR RR are order, preference, service, flags, regexp, and replacement: * The order field specifies the order in which records MUST be processed when multiple NAPTR records are returned in response to a single query. A naming authority may have delegated a portion of its namespace to another agency. Evaluating the NAPTR records in the correct order is necessary for delegation to work properly. * The preference field specifies the order in which records SHOULD be processed when multiple NAPTR records have the same value of "order". This field lets a service provider specify the order in which resolvers are contacted, so that more capable machines are contacted in preference to less capable ones. * The service field specifies the resolution protocol and resolution service(s) that will be available if the rewrite specified by the regexp or replacement fields is applied. Resolution protocols are the protocols used to talk with a resolver. They will be specified in other documents. Resolution services are operations such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC), etc. These are discussed in the URN Framework document[2], and their behavior in a particular resolution protocol will be given in the specification for that protocol. * The flags field contains modifiers that affect what happens in the next DNS lookup, typically for optimizing the process. * The regexp field is one of two fields used for the rewrite rules, and is the core concept of the NAPTR record. The regexp field is a String containing a sed-like substitution expression. (The actual grammar for the substitution expressions is given later in this draft). The substitution expression is applied to the original URN to determine the next domain name to be queried. The regexp field should be used when the domain name to be generated is conditional on information in the URI. If the next domain name is always known, which is anticipated to be a common occurrence, the replacement field should be used instead. * The replacement field is the other field that may be used for the rewrite rule. It is an optimization of the rewrite process for the case where the next domain name is fixed instead of being conditional on the content of the URI. The replacement field is a domain name (subject to compression if a DNS sender knows that a given recipient is able to decompress names in this RR type's RDATA field). If the rewrite is more complex than a simple substitution of a domain name, the replacement field should be set to . and the regexp field used. Note that the client applies all the substitutions and performs all lookups - this is not handled in DNS servers. Note also that there is no reason to provide values in both the replacement and regexp field. Only one should be specified. If a value is specified in both, the replacement name MUST be used and the regexp string MUST be ignored. It is the belief of the developers of this document that regexps should rarely be used. The replacement field seems adequate for the vast majority of situations. Regexps are only necessary when portions of a namespace are to be delegated to different resolvers. Example 1 --------- Consider a URN that uses the hypothetical DUNS namespace. DUNS numbers are identifiers for approximately 30 million registered businesses around the world, assigned and maintained by Dunn and Bradstreet. The URN might look like: urn:duns:002372413:annual-report-1997 The first step in the resolution process is to find out about the DUNS namespace. The namespace identifier, duns, is extracted from the URN, prepended to urn.net, and the NAPTRs for duns.urn.net looked up. It might return records of the form: duns.urn.net ;; order pref flags service regexp replacement IN NAPTR 100 10 "s" "dunslink+N2L+N2C" "" dunslink.udp.isi.dandb.com IN NAPTR 100 20 "s" "rcds+N2C" "" rcds.udp.isi.dandb.com IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" "" http.tcp.isi.dandb.com The order field contains equal values, indicating that no name delegation order has to be followed. The preference field indicates that the provider would like clients to use the special dunslink protocol, followed by the RCDS protocol, and that HTTP is offered as a last resort. All the records specify the "s" flag, which will be explained momentarily. The service fields say that if we speak dunslink, we will be able to issue either the N2L or N2C requests to obtain a URL or a URC (description) of the resource. The Resource Cataloging and Distribution Service (RCDS)[7] could be used to get a URC for the resource, while HTTP could be used to get a URL, URC, or the resource itself. All the records supply the next domain name to query, none of them need to be rewritten with the aid of regular expressions. The general case might require multiple NAPTR rewrites to locate a resolver, but eventually we will come to the "terminal NAPTR". Once we have the terminal NAPTR, our next probe into the DNS will be for a SRV or A record instead of another NAPTR. Rather than probing for a non-existent NAPTR record to terminate the loop, the flags field is used to indicate a terminal lookup. If it has a value of "s", the next lookup should be for SRV RRs, "a" denotes that A records should sought. A "p" flag is also provided to indicate that the next action is Protocol-specific, but that looking up another NAPTR will not be part of it. Since our example RR specified the "s" flag, it was terminal. Our next action is to lookup SRV RRs for rcds.udp.isi.dandb.com, which will tell us hosts that can provide the necessary resolution service. That lookup might return: ;; Pref Weight Port Target rcds.udp.isi.dandb.com IN SRV 0 0 1000 defduns.isi.dandb.com IN SRV 0 0 1000 dbmirror.com.au IN SRV 0 0 1000 ukmirror.com.uk telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their RCDS server. (The reader is referred to the SRV proposal [3] for the interpretation of the fields above). There is opportunity for significant optimization here. We can return the SRV records as additional information for terminal NAPTRs (and the A records as additional information for those SRVs). While this recursive provision of additional information is not explicitly blessed in the DNS specifications, it is not forbidden, and BIND does take advantage of it [4]. This is a significant optimization. In conjunction with a long TTL for *.urn.net records, the average number of probes to DNS for resolving DUNS URNs would approach one. Therefore, DNS server implementors SHOULD provide additional information with NAPTR responses. The additional information will be either SRV or A records. If SRV records are available, their A records may be provided as recursive additional information. Note that the example NAPTR records above are intended to represent the reply the client will see. They are not quite identical to what the domain administrator would put into the zone files. For one thing, the administrator should supply the trailing '.' character on replacement domain names. An additional difference will be illustrated later. Example 2 --------- Consider a URI namespace based on MIME Content-Ids. The URN might look like this: urn:cid:199606121851.1@mordred.gatech.edu The first step in the resolution process is to find out about the CID namespace. The namespace identifier, cid, is extracted from the URN, prepended to urn.net, and the NAPTR for cid.urn.net looked up. It might return records of the form: cid.urn.net ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "/.+@([^@]+)/\1/i" . We have only one NAPTR response, so ordering the responses is not a problem. The replacement field is empty, so we check the regexp field and use the pattern provided there. We apply that regexp to the entire URN to see if it matches, which it does. The \1 part of the substitution expression returns the string "mordred.gatech.edu". Since the flags field does not contain "s" or "a", the lookup is not terminal and our next probe to DNS is for more NAPTR records: lookup(query=NAPTR, "mordred.gatech.edu"). While mordred could have its very own NAPTR, maintaining those records on all the machines at a site as large as Georgia Tech would be an intolerable burden. Instead, a wildcard may be used so that the domain administrator at Georgia Tech has only a single NAPTR record to maintain. That record might look like: *.gatech.edu IN NAPTR ;; order pref flags service regexp replacement IN NAPTR 100 50 "s" "z3950+N2L+N2C" "" z3950.tcp.gatech.edu. IN NAPTR 100 50 "s" "rcds+N2C" "" rcds.udp.gatech.edu. IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" http.tcp.gatech.edu. (Unlike all the other example records in this draft, the one above is the contents of a zone file, not the response received by the client. That is so that the wildcard can be seen.) Continuing with our example, we note that the values of the order and preference fields are equal in all records, so the client is free to pick any record. The flags field tells us that these are the last NAPTR patterns we should see, and after the rewrite (a simple replacement in this case) we should look up SRV records to get information on the hosts that can provide the necessary service. Assuming we prefer the Z39.50 protocol, our lookup might return: ;; Pref Weight Port Target z3950.tcp.gatech.edu IN SRV 0 0 1000 z3950.gatech.edu IN SRV 0 0 1000 z3950.cc.gatech.edu IN SRV 0 0 1000 z3950.uga.edu telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their Z39.50 server. Recall that the regular expression used \1 to extract a domain name from the CID. There is a significant caveat about the use of backslashes in DNS zone files. DNS treats backslashes as the escape character so that '.' can be escaped when necessary. This means that when a regular expression is entered into the zone file, the backslashes must be escaped by another backslash. For the case of the cid.urn.net record above, the regular expression entered into the zone file should be "/.+@([^@]+)/\\1/i". When the client code actually receives the record, the pattern will have been converted to "/.+@([^@]+)/\1/i". Example 3 --------- Even if URN systems were in place now, there would still be a tremendous number of URLs. It should be possible to develop a URN resolution system that can also provide location independence for those URLs. This is related to the requirement in [1] to be able to grandfather in names from other naming systems, such as ISO Formal Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, etc. The NAPTR RR could also be used for URLs that have already been assigned. Assume we have the URL for a very popular piece of software that the publisher wishes to mirror at multiple sites around the world: http://www.foo.com/software/latest-beta.exe We extract the prefix, "http", and lookup NAPTR records for http.urn.net. This might return a record of the form http.urn.net IN NAPTR ;; order pref flags service regexp replacement 100 90 "" "" "/.*\/\/([^\/:]+)/\1/i" . This expression returns everything after the first double slash and before the next slash or colon. Backslashes are needed to escape the forward slash since the forward slash character is what separates the components of the substitution expression. (Recall from the previous example that in the zone file, this pattern actually needs to be entered as "/.*\\/\\/([^\\/:]+)/\\1/i"). Applying this pattern to the URL extracts "www.foo.com". Looking up NAPTR records for that might return: www.foo.com ;; order pref flags service regexp replacement IN NAPTR 100 100 "s" "http+L2R" "" http.tcp.foo.com IN NAPTR 100 100 "s" "ftp+L2R" "" ftp.tcp.foo.com Looking up SRV records for http.tcp.foo.com would return information on the hosts that foo.com has designated to be its mirror sites. The client can then pick one for the user. NAPTR RR Format =============== The format of the NAPTR RR is given below. The DNS type code for NAPTR is 104 [this is being changed, we believe it will be assigned 35]. Domain TTL Class Order Preference Flags Service Regexp Replacement where: Domain The domain name this resource record refers to. TTL Standard DNS Time To Live field Class Standard DNS meaning Order A 16-bit integer specifying the order in which the NAPTR records MUST be processed to ensure correct delegation of portions of the namespace over time. Low numbers are processed before high numbers, and once a NAPTR is found that "matches" a URN, the client MUST NOT consider any NAPTRs with a higher value for order. Preference A 16-bit integer which specifies the order in which NAPTR records with equal "order" values SHOULD be processed, low numbers being processed before high numbers. This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. Flags A String giving flags to control aspects of the rewriting. Flags are single characters from the set [A-Z0-9]. The case of the alphabetic characters is not significant. At this time only three flags, "S", "A", and "P", are defined. "S" means that the next lookup should be for SRV records instead of NAPTR records. "A" means that the next lookup should be for A records. The "P" flag says that the remainder of the resolution shall be carried out in a Protocol-specific fashion, and we should not do any more DNS queries. The remaining alphabetic flags are reserved. The numeric flags may be used for local experimentation. The S, A, and P flags are all mutually exclusive, and resolution libraries MAY signal an error if more than one is given. (Experimental code and code for assiting in the creation of NAPTRs would be more likely to signal such an error than a client such as a browser). We anticipate that multiple flags will be allowed in the future, so implementors MUST NOT assume that the flags field can only contain 0 or 1 characters. Service Specifies the resolution service(s) available down this rewrite path. It may also specify the particular protocol that is used to talk with a resolver. A protocol MUST be specified if the flags field states that the NAPTR is terminal. If a protocol is specified, but the flags field does not state that the NAPTR is terminal, the next lookup MUST be for a NAPTR. The client MAY choose not to perform the next lookup if the protocol is unknown, but that behavior MUST NOT be relied upon. The service field may take any of the values below (using the Augmented BNF of RFC 822[5]): service_field = [ [protocol] *("+" rs)] protocol = "rcds" / "http" / "hdl" / "rwhois" rs = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C" / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C" i.e. an optional protocol specification followed by 0 or more resolution services. Each resolution service is indicated by an initial '+' character. Note that the empty string is also a valid service field. This will typically be seen at the top levels of a namespace, when it is impossible to know what services and protocols will be offered by a particular publisher within that name space. At this time the known protocols are rcds[7], hdl[8] (binary, UDP-based protocols), http[11] (a textual, TCP-based protocol), and rwhois[10] (textual, UDP or TCP based). More will be allowed later. The names of the protocols must be formed from the characters [a-Z0-9]. Case of the characters is not significant. The service requests currently allowed are: N2L - Given a URN, return a URL N2Ls - Given a URN, return a set of URLs N2R - Given a URN, return an instance of the resource. N2Rs - Given a URN, return multiple instances of the resouce, typically encoded using multipart/alternative. N2C - Given a URN, return a collection of meta-information on the named resource. The format of this response is the subject of another document. N2Ns - Given a URN, return all URNs that are also identifers for the resource. L2R - Given a URL, return the resource. L2Ns - Given a URL, return all the URNs that are identifiers for the resource. L2Ls - Given a URL, return all the URLs for instances of of the same resource. L2C - Given a URL, return a description of the resource. The actual format of the service request and response will be determined by the resolution protocol, and is the subject for other documents. Protocols need not offer all services. The labels for service requests shall be formed from the set of characters [A-Z0-9]. The case of the alphabetic characters is not significant. Regexp A STRING containing a substitution expression that is applied to the original URI in order to construct the next name to lookup. The grammar of the substitution expression is given in the next section. Replacement The next NAME to query for NAPTR, SRV, or A records depending on the value of the flags field. As mentioned above, this may be compressed. Substitution Expression Grammar: ================================ The content of the regexp field is a substitution expression. True sed(1) substitution expressions are not appropriate for use in this application for a variety of reasons, therefore the contents of the regexp field MUST follow the grammar below: subst_expr = delim-char ere delim-char repl delim-char *flags delim-char = "/" / "!" / ... (Any non-digit or non-flag character other than backslash '\'. All occurances of a delim_char in a subst_expr must be the same character.) ere = POSIX Extended Regular Expression (see [9], section 2.8.4) repl = dns_str / backref / repl dns_str / repl backref dns_str = ...... which RFC can I cite for this? 1035 seems obsolete ..... backref = "\" 1POS_DIGIT flags = "i" DNS_CHAR = "_" / "0" / "1" / ... / "9" / "a" / ... / "z" POS_DIGIT = "1" / "2" / ... / "9" ; 0 is not an allowed backref value The result of applying the substitution expression to the original URI shall be a legal domain name. Since it is possible for the regexp field to be improperly specified, such that a non-conforming domain name can be constructed, client software SHOULD verify that the result is a legal domain name before making queries on it. Backref expressions "\N" in the repl portion of the substitution expression are replaced by the (possibly empty) string of characters enclosed by '(' and ')' in the ERE portion of the substitution expression. N is a single digit from 1 through 9, inclusive. It specifies the N'th backref expression, the one that begins with the N'th '(' and continues to the matching ')'. For example, the ERE (A(B(C)DE)(F)G) has backref expressions: \1 = ABCDEFG \2 = BCDE \3 = C \4 = F \5..\9 = error - no matching subexpression The "i" flag indicates that the ERE matching SHALL be performed in a case-insensitive fashion. Furthermore, any backref replacements MAY be normalized to lower case when the "i" flag is given. The first character in the substitution expression shall be used as the character that delimits the components of the substitution expression. There must be exactly three non-escaped occurances of the delimiter character in a substitution expression. Since escaped occurances of the delimiter character will be interpreted as occurances of that character, digits MUST NOT be used as delimiters. Backrefs would be confused with literal digits were this allowed. Similarly, if flags are specified in the substitution expression, the delimiter character must not also be a flag character. Advice to domain administrators: ================================ Beware of regular expressions. Not only are they a pain to get correct on their own, but there is the previously mentioned interaction with DNS. Any backslashes in a regexp must be entered twice in a zone file in order to appear once in a query response. More seriously, the need for double backslashes has probably not been tested by all implementors of DNS servers. We anticipate that urn.net will be the heaviest user of regexps. Only when delegating portions of namespaces should the typical domain administrator need to use regexps. On a related note, beware of interactions with the shell when manipulating regexps from the command line. Since '\' is a common escape character in shells, there is a good chance that when you think you are saying "\\" you are actually saying "\". Similar caveats apply to characters such as '*', '(', etc. The "a" flag allows the next lookup to be for A records rather than SRV records. Since there is no place for a port specification in the NAPTR record, when the "A" flag is used the specified protocol must be running on its default port. The URN-WG is discussing the use of international characters in URNs. The regexp package used may need to be changed from POSIX to one with the ability to handle UNICODE characters. Usage ===== Pseudocode for a client routine using NAPTRs is given below: // // findResolver(URN) // Given a URN, find a host that can resolve it. // findResolver(string URN) { sprintf(key, "%s.urn.net", extractNS(URN)); // prepend prefix to urn.net do { rewrite_flag = false; terminal = false; if (key has been seen) { quit with a loop detected error } add key to list of "seens" records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key' sort NAPTR records by "order" field and "preference" field (with "order" being more significant than "preference"). n_naptrs = number of NAPTR records in response. curr_order = records[0].order; max_order = records[n_naptrs-1].order; // Process current batch of NAPTRs according to "order" field. for (j=0; j < n_naptrs && records[j].order <= max_order; j++) { newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp); if (!newkey) // Skip to next record if the rewrite didn't match continue; // We did do a rewrite, shrink max_order to current value // so that delegation works properly max_order = naptr[j].order; // Will we know what to do with the protocol and services // specified in the NAPTR? If not, try next record. if(!isKnownProto(naptr[j].services)) { continue; } if(!isKnownService(naptr[j].services)) { continue; } // At this point we have a sucessful rewrite and we will know // how to speak the protocol and request a known resolution // service. Before we do the next lookup, check some // optimization possibilities. if (strcasecmp(flags, "S") || strcasecmp(flags, "P")) || strcasecmp(flags, "A")) { terminal = true; services = naptr[j].services; addnl = any SRV and/or A records returned as additional info for naptr[j]. } key = newkey; rewriteflag = true; break; } } while (rewriteflag && !terminal); // Did we not find our way to a resolver? if (!rewrite_flag) { report an error return NULL; } // Leave rest to another protocol? if (strcasecmp(flags, "P")) { return key as host to talk to; } // If not, keep plugging if (!addnl) { // No SRVs came in as additional info, look them up srvs = lookup(type=SRV, key); } sort SRV records by preference, weight, ... foreach (SRV record) { // in order of preference try contacting srv[j].target using the protocol and one of the resolution service requests from the "services" field of the last NAPTR record. if (successful) return (target, protocol, service); // Actually we would probably return a result, but this // code was supposed to just tell us a good host to talk to. } die with an "unable to find a host" error; } Notes: ====== - The "urn:" prefix is a matter of religious controversy. Client code should handle the cases when it is and is not present. Similarly, if regular expressions are used in NAPTR records, they should be immune to the presence or absence of an initial "urn:". - A client MUST process multiple NAPTR records in the order specified by the "order" field, it MUST NOT simply use the first record that provides a known protocol and service combination. - If a record at a particular order matches the URI, but the client doesn't know the specified protocol and service, the client SHOULD continue to examine records that have the same order. The client MUST NOT consider records with a higher value of order. This is necessary to make delegation of portions of the namespace work. The order field is what lets site administrators say "all requests for URIs matching pattern x go to server 1, all others go to server 2". (A match is defined as: 1) The NAPTR provides a replacement domain name 2) The regular expression matches the URN ) - When multiple RRs have the same "order", the client should use the value of the preference field to select the next NAPTR to consider. However, because of preferred protocols or services, estimates of network distance and bandwidth, etc. clients may use different criteria to sort the records. - If the lookup after a rewrite fails, clients are strongly encouraged to report a failure, rather than backing up to pursue other rewrite paths. - When a namespace is to be delegated among a set of resolvers, regexps must be used. Each regexp appears in a separate NAPTR RR. Administrators should do as little delegation as possible, because of limitations on the size of DNS responses. - Note that SRV RRs impose additional requirements on clients. Acknowledgments: ================= The authors would like to thank Keith Moore for all his consultations during the development of this draft. We would also like to thank Paul Vixie for his assistance in debugging our implementation, and his answers on our questions. References: =========== [1] RFC-1737, "Functional Requirements for Uniform Resource Names", Karen Sollins and Larry Masinter, Dec. 1994. [2] draft-daigle-urn-framework-00.txt "A Uniform Resource Naming Framework", Leslie Daigle and Patrik Faltstrom, June, 1996. [3] RFC 2052, "A DNS RR for specifying the location of services (DNS SRV)", A. Gulbrandsen and P. Vixie, October 1996. [4] Paul Vixie, personal communication. [5] RFC-822, "Standard for the Format of ARPA Internet Text Messages", Dave H. Crocker, August 1982. [6] Keith Moore, personal communication. [7] Keith Moore, "Resource Cataloging and Distribution Service", ??? (insert as [4], renumber the others?) [8] Charles Orth, Bill Arms; Handle Resolution Protocol Specification, http://www.handle.net/docs/client_spec.html [9] IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1); IEEE Std 1003.2-1992; The Institute of Electrical and Electronics Engineers; New York; 1993. ISBN:1-55937-255-9 [10] ... rwhois spec ... [11] ... encoding resolution service requests in HTTP... Security Considerations ======================= The use of "urn.net" as the registry for URN namespaces is subject to denial of service attacks, as well as other DNS spoofing attacks. The interactions with DNSSEC are currently being studied. It is expected that NAPTR records will be signed with SIG records once the DNSSEC work is deployed. The rewrite rules make identifiers from other namespaces subject to the same attacks as normal domain names. Since they have not been easily resolvable before, this may or may not be considered a problem. Regular expressions should be checked for sanity, not blindly passed to something like PERL. Author Contact Information: =========================== Ron Daniel Los Alamos National Laboratory MS B287 Los Alamos, NM, USA, 87545 voice: +1 505 665 0597 fax: +1 505 665 4939 email: rdaniel@lanl.gov Michael Mealling Network Solutions 505 Huntmar Park Drive Herndon, VA 22070 voice: (703) 742-0400 fax: (703) 742-9552 email: michaelm@internic.net URL: http://www.netsol.com/ This draft expires 19 May, 1997. Ron Daniel Jr. email: rdaniel@acl.lanl.gov 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 obscure_term: "hypernym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA08321 for urn-ietf-out; Wed, 20 Nov 1996 15:32:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA08316 for ; Wed, 20 Nov 1996 15:32:10 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08307 (mail destined for urn-ietf@services.bunyip.com); Wed, 20 Nov 96 15:32:01 -0500 Received: from magenta.acl.lanl.gov (rdaniel@magenta.acl.lanl.gov [128.165.147.153]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id NAA29850 for ; Wed, 20 Nov 1996 13:31:58 -0700 (MST) From: "Ronald E. Daniel" Received: (rdaniel@localhost) by magenta.acl.lanl.gov (8.7.5/8.6.4) id NAA29358 for urn-ietf@bunyip.com; Wed, 20 Nov 1996 13:31:57 -0700 (MST) Date: Wed, 20 Nov 1996 13:31:57 -0700 (MST) Message-Id: <199611202031.NAA29358@magenta.acl.lanl.gov> To: urn-ietf@bunyip.com Subject: [URN] HTTP conventions draft Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ronald E. Daniel" Errors-To: owner-urn-ietf@bunyip.com Hi, I've changed the conventions draft to remove the integer from the text/uri-list media type. The new version is appended. I will send this to the ID editor later today. Regards, Ron ==== INTERNET DRAFT Ron Daniel draft-ietf-urn-http-conventions-00.txt Los Alamos National Laboratory 13 Nov, 1996 Conventions for the Use of HTTP for URN Resolution Status of this Memo =================== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft expires 15 May, 1997. Abstract: ========= The URN-WG was formed to specify persistent, location-independent names for network accessible resources, and resolution mechanisms to retrive the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal. That proposal does not get the client software all the way from the URN to the resource. Instead, it gets the client from a URN to a "resolver", which is a system that can then tell the client where the resource is. The NAPTR draft defines a "resolution protocol" to be the protocol used to speak to a resolver in order to obtain the resource, its location(s), or other information about the resource. The NAPTR proposal allows different resolution protocols to be used for commuicating with resolvers. This draft establishes conventions for encoding URN resolution requests and responses in HTTP 1.0 (and 1.1) requests and responses. The primary goal of this draft is to define a convention that is simple to implement and will allow existing HTTP servers to easily add support for URN resolution. We expect that the resolution databases that arise will be useful when more sophisticated resolution protocols are developed later. 1.0 Introduction: ================== The NAPTR draft[1] describes a way of using DNS to locate resolvers for URIs. That draft provides places to specify the "resolution protocol" spoken by the resolver, as well as the "resolution services" it offers. As of this writing, the "resolution protocols" allowed by the NAPTR draft are HTTP, RCDS, HDL, and RWHOIS. (That list is expected to grow over time). The NAPTR draft also lists a variety of resolution services, such as N2L (given a URN, return a URL); N2R (Given a URN, return the named resource), etc. This draft specifies the conventions to follow to encode resolution service requests in the HTTP protocol, allowing widely available HTTP daemons to serve as URN resolvers. The reader is assumed to be familiar with the HTTP/1.0 [2] and 1.1 [3] specifications. 2.0 General Approach: ===================== The general approach used to encode resolution service requests in HTTP is quite simple: GET /uri-res// HTTP/1.0 For example, if we have the URN "cid:foo@huh.com" and want a URL, we would send the request: GET /uri-res/N2L/cid:foo@huh.com HTTP/1.0 Because of the character set limitations on URIs, we might wish to encode the '@' character as its hex equivalent, thus the request would be GET /uri-res/N2L/cid:foo%40huh.com HTTP/1.0 The request could also be encoded as an HTTP 1.1 request. This would look like: GET /uri-res/N2L/cid:foo%40huh.com HTTP/1.1 Host: Handling these requests on the server side is easy to implement in a number of ways. The N2L request could be handled by a CGI script that took the incoming URN, looked it up in a database, and returned the URL as an HTTP redirect. Service requests like N2R or N2C could be set up so that the daemon answered the request by returning files out of N2R/ and N2C/ directories, or they could be handled by a script. One caveat should be kept in mind. The "urn:" prefix is still the subject of controversy, so some URN documents advocate treating it as optional. HTTP resolvers MUST return identical results for URIs that do and do not contain the "urn:" prefix. For example, the two request below must return identical results: GET /uri-res/N2L/cid:foo%40huh.com HTTP/1.0 GET /uri-res/N2L/urn:cid:foo%40huh.com HTTP/1.0 Responses from the HTTP server follow standard HTTP practice. Status codes, such as 200 (OK) or 404 (Not Found) shall be returned. The normal rules for determining cachability, negotiating formats, etc. apply. 3.0 Service-specific details: ============================= This section goes through the various resolution services established in the URN Framework draft [4] and states how to encode each of them, how the results should be returned, and any special status codes that are likely to arise. Unless stated otherwise, the HTTP requests are formed according to the simple convention above, either for HTTP/1.0 or HTTP/1.1. The response is assumed to be an entity with normal headers and body unless stated otherwise. (N2L is the only request that does not return a body). 3.1 N2L (URN to URL): ---------------------- The request is encoded as above. The URL MUST be returned in a Location: header for the convienience of the most common case of wanting the resource. A 30X status line SHOULD be returned. HTTP/1.1 clients should be sent the 303 status code. HTTP/1.0 clients should be sent the 302 (Moved temporarily) status code unless the resolver has particular resons for using 301 (moved permanently) or 304 (not modified) codes. 3.2 N2Ls (URN to URLs): ------------------------ The request is encoded as above. The result is a list of 0 or more URLs. The Internet Media Type (aka ContentType) of the result may be negotiated using standard HTTP mechanisms if desired. At a minimum the resolver should support the text/uri-list media type. (See Appendix A for the definition of this media type). That media type is suitable for machine-processing of the list of URLs. Resolvers may also return the results as text/html, text/plain, or any other media type they deem suitable. No matter what the particular media type, the result MUST be a list of the URLs which may be used to obtain an instance of the resource identified by the URN. All URIs shall be encoded according to the URI specification [5]. If the client has requested the result be returned as text/html or application/html, the result should be encoded as: where the strings ...url n... are replaced by the n'th URL in the list. 3.3 N2R (URN to Resource): --------------------------- The request is encoded as above. The resource is returned using standard HTTP mechanisms. The request may be modified using the Accept: header as in normal HTTP to specify that the result be given in a preferred Internet Media Types. 3.4 N2Rs (URN to Resources): ----------------------------- This resolution service returns multiple instances of a resource, for example, GIF and JPEG versions of an image. The judgment about the resources being "the same" resides with the naming authority that issued the URN. The request is encoded as above. The result shall be a MIME multipart/alternative message with the alternative versions of the resource in seperate body parts. If there is only one version of the resource identified by the URN, it MAY be returned without the multipart/alternative wrapper. Resolver software SHOULD look at the Accept: header, if any, and only return versions of the resource that are acceptable according to that header. 3.5 N2C (URN to URC): ---------------------- URCs (Uniform Resource Characteristics) are descriptions of other resources. This request allows us to obtain a description of the resource identified by a URN, as opposed to the resource itself. The description might be a bibliographic citation, a digital signature, a revision history, etc. This draft does not specify the content of any response to a URC request. That content is expected to vary from one resolver to another. The format of any response to a N2C request MUST be communicated using the ContentType header, as is standard HTTP practice. The Accept: header SHOULD be honored. 3.6 N2Ns (URN to URNs): ------------------------ While URNs are supposed to identify one and only one resource, that does not mean that a resource may have one and only one URN. For example, consider a resource that has something like "current-weather-map" for one URN and "weather-map-for-datetime-x" for another URN. The N2Ns service request lets us obtain lists of URNs that are believed equivalent at the time of the request. As the weathermap example shows, some of the equivalances will be transitory, so the standard HTTP mechanisms for communicating cachability MUST be honored. The request is encoded as above. The result is a list of all the URNs, known to the resolver, which identify the same resource as the input URN. The result shall be encoded as for the N2Ls request above (text/uri-list unless specified otherwise by an Accept: header). 3.7 L2Ns (URL to URNs): ---------------------- The request is encoded as above. The response is a list of any URNs known to be assigned to the resource at the given URL. The result shall be encoded as for the N2Ls and N2Ns requests. 3.8 L2Ls (URL to URLs): ------------------------ The request is encoded as described above. The result is a list of all the URLs that the resolver knows are associated with the resource located by the given URL. This is encoded as for the N2Ls, N2Ns, and L2Ns requests. 3.9 L2C (URL to URC): ---------------------- The request is encoded as above, the response is the same as for the N2C request. Implementation Notes: ===================== This section gives an example of how to configure a web server to respond to the N2L resolution request. It is not intended to specify standard behavior, it is provided here merely as a courtesy for implementors. First, we assume the presence of a CGI script, n2l.pl, that processes the provided URN, converting it into a canonical format. It would remove any "urn:" prefix, decode any %encoded special characters, normalize case-insensitive parts of the URN to lower case, etc. It would then use the normalized URN as the key for a search in a database, which we assume returns the URL as a string. A sample of our implementation of that script is provided as Appendix B. We will further assume that the n2l.pl script is in the cgi-bin directory of the web server. The easiest way to invoke the n2l.pl script in response to N2L requests is to set up a Redirect directive in the srm.conf file. (This works for servers based on the original NCSA HTTP daemon, such as Apache.) The relevant Redirect directives might look like: Redirect /uri-res/N2L http://urn.acl.lanl.gov/cgi-bin/n2l.pl Redirect /uri-res/L2N http://urn.acl.lanl.gov/cgi-bin/l2n.pl Appendix A: The text/uri-list Internet Media Type ================================================= [This appendix will be augmented or replaced by the registration of the text/uri-list IMT once that registration has been performed]. Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns, L2Ls, result in a list of URIs being returned to the client. The text/uri-list Internet Media Type is defined to provide a simple format for the automatic processing of such lists of URIs. The format of text/uri-list resources is: 1) Any lines beginning with the '#' character are comment lines and are ignored during processing. (Note that '#' is a character that may appear in URIs, so it only denotes a comment when it is the first character on a line). 2) The remaining non-comment lines MUST be URIs (URNs or URLs), encoded according to the URI specification RFC[5]. Each URI shall appear on one and only one line. 3) As for all text/* formats, lines are terminated with a CR LF pair. In applications where one URI has been mapped to a list of URIs, such as in response to the N2Ls request, the first line of the text/uri-list response SHOULD be a comment giving the original URI. An example of such a result for the N2L request is shown below in figure 1. # urn:cid:foo@huh.org http://www.huh.org/cid/foo.html http://www.huh.org/cid/foo.pdf ftp://ftp.foo.org/cid/foo.txt Figure 1: Example of the text/uri-list format Appendix B: n2l.pl script ========================== This is a simple perl script for the N2L resolution service. It assumes the presence of a DBM database to store the URN to URL mappings. #!/bin/perl # N2L - performs urn to url resolution $n2l_File = "...filename for DBM database..."; $urn = $ENV{'PATH_INFO'} ; if(length($urn)<3) { $error=1; } if(!$error) { $urn =~s/^(\/)(urn:)?(.*)/$3/i; # Additional canonicalization should be performed here dbmopen(%lu,$n2l_File,0444); if($lu{$urn}) { $url=$lu{$urn}; print STDOUT "Location: $url\n\n"; }else{ $error=2; } dbmclose(%lu); } if($error) { print "Content-Type: text/html \n\n"; print "\n"; print "URN Resolution: N2L\n"; print "\n"; print "

URN to URL resolution failed for the URN:

\n"; print "

$urn

\n"; print "\n"; print "\n"; } exit; References: =========== [1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", draft-ietf-urn-naptr-00.txt, October, 1996. [2] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May, 1996. [3] HTTP 1.1 draft [4] URN Framework draft [5] RFC 1630 Security Considerations ======================= Communications with a resolver may be of a sensitive nature. Some resolvers will hold information that should only be released to authorized users. The results from resolvers may be the target of spoofing, especially once electronic commerce transactions are common and ther is money to be made by directing users to pirate repositories rather than repositories which pay royalties to rightsholders. Resolution requests may be of interest to traffic analysts. The requests may also be subject to spoofing. The requests and responses in this draft are amenable to encoding, signing, and authentication in the manner of any other HTTP traffic. Author Contact Information: =========================== Ron Daniel Los Alamos National Laboratory MS B287 Los Alamos, NM, USA, 87545 voice: +1 505 665 0597 fax: +1 505 665 4939 email: rdaniel@lanl.gov This draft expires 15 May, 1997. Ron Daniel Jr. email: rdaniel@acl.lanl.gov 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 obscure_term: "hypernym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA04409 for urn-ietf-out; Wed, 20 Nov 1996 12:01:12 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA04403 for ; Wed, 20 Nov 1996 12:01:09 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04944 (mail destined for urn-ietf@services.bunyip.com); Wed, 20 Nov 96 12:01:05 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA26282; Wed, 20 Nov 1996 10:00:53 -0700 (MST) Message-Id: <2.2.32.19961120170919.0070b3dc@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 20 Nov 1996 10:09:19 -0700 To: Bob Briscoe , urn-ietf@bunyip.com From: Ron Daniel Subject: Re: [URN] Resolution Services (N2L etc) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Trolling back through my mail, I discovered that I had a few partially-completed replies to the issues raised by Bob Briscoe, but had not sent any of them. sigh. Here are some semi-random notes on the things he raised. Thus spoke Bob Briscoe (at least at 10:01 AM 11/5/96 +0000) >Comments on draft-ietf-urn-naptr-00.txt: >1.2 It strikes me that specifying available service requests (N2L, N2R etc) >should not be the job of DNS or any URN resolution mechanism. You are adding >metadata about the address that the name resolves to (i.e. allowed methods). >NAPTR should simply get you to the place you asked for by mapping names to >addresses. The problem with this is that different places may offer different services. The various resolution services offered by a resolver are is information about the resolver and its capabilitities, not about the names on that resolver. In another message lurking somewhere in my extremely well-organized mail archives, I recall Bob saying that N2L was the only essential service, all the others could either be reduced to it or were not important. I disagree, not that this will surprise anyone. :-) For the user, N2L and N2R are equivalent, but N2R can avoid a round trip. N2C is very different from N2L or N2R. Furthermore, I happen to think it is very important, and I already have several exmples of where it might be used in early URN experiments. The ISBN and UPC namespaces are both cases where we can obtain a description of the resource (book or product) a lot easier than we can obtain a copy of the resource. I have things going on at work where we want tobe able to use N2C. >IOW, the client should already know >what it is going to do with the address it gets out of the URN service, or >if it doesn't it should be prepared to find out. That is not inconsistent with advertising the resolution services in a NAPTR record. The clients know what they want to do - typically, get the resource or at least a location for the resource. They can do this in several fashions. However, what the client wants to do may not be supported by the resolver. If not, advertising those services in the NAPTR record lets the client discover that early, and try contacting another resolver if possible. At 10:02 AM 11/5/96 +0000, Bob wrote: >2. Substitution expression grammar >2.1 You claim to be copying sed ERE syntax (with the caveat it may all >change to cover UTF-8). Not exactly. Sed uses Basic Regular Expression syntax, I suggest that we use Extended Regular Expression syntax. > To avoid confusion for sed gits like me, could you >consider using the escaped parentheses \( and \) to do back refs, rather >than the one character ones ( and ) which simply imply grouping in POSIX >EREs by my understanding. This is the big difference between BRE and ERE syntax. I suggested using ERE because I think it is going to be simpler for people to use () than \\(\\). At the time there was some agreement with this argument, and I don't recall any disagreement. However, if others come forward to ask for BREs I will certainly consider changing the draft. >2.2 Also, it would be friendly to allow any delimiter, like sed does, not >just "/" (e.g. "!.*//\([^/:]+\)!\1!i" is a lot more readable than >"/.*\/\/\([^\/:]+\)/\1/i"). Agreed. I'll change the draft on this point to say something like: "The first character of the substitution expression will be used as the delimiter character. There MUST be exactly three non-escaped occurrances of that character in the substitution expression. Because escaped digits in the replacement portion of the substitution expression are backrefs, the delimiter character MUST NOT be a digit. Similarly, the delimiter character MUST NOT be a flag character if that flag is used in the substitution expression. I believe Bob's main objection to the NAPTR draft was that there was no way of indicating the lifetime of a resolver. I'll take that up with him off-list because I am still not clear on aspects of that objection. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA00848 for urn-ietf-out; Wed, 20 Nov 1996 09:06:01 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA00843 for ; Wed, 20 Nov 1996 09:05:54 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02166 (mail destined for urn-ietf@services.bunyip.com); Wed, 20 Nov 96 09:05:52 -0500 Message-Id: <9611201405.AA02166@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Wed Nov 20 08:04 CST 1996 From: "Ryan Moats" To: "Franz J. Hauck" , "urn-ietf@bunyip.com" Date: Wed, 20 Nov 96 08:06:18 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] URN Syntax Draft, NSS character set Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Wed, 20 Nov 1996 09:49:07 +0100, Franz J. Hauck wrote: >Hi, > >I'm new to the list and I just read draft-ietf-urn-syntax-01.txt. At the >definition of the character set for the NSS, there is probably some part >of a line missing; it looks somehow truncated: > > ::= "(" | ")" | "+" | " > ":" | "=" | "?" | "@" > Ugh, well that guarantees there will be an -02 ;-) The missing part (and I just realized why it's missing, grrrrrrrr) is (if you concatenate this with the first line of other you'll have a repeated '"'. "\\" | "," | "-" | "." | "/" | Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id DAA27963 for urn-ietf-out; Wed, 20 Nov 1996 03:49:40 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id DAA27958 for ; Wed, 20 Nov 1996 03:49:38 -0500 Received: from faui40.informatik.uni-erlangen.de by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01045 (mail destined for urn-ietf@services.bunyip.com); Wed, 20 Nov 96 03:49:28 -0500 Received: from faui40n.informatik.uni-erlangen.de (root@faui40n.informatik.uni-erlangen.de [131.188.34.71]) by immd4.informatik.uni-erlangen.de with ESMTP id JAA13316 (8.7.6/7.5b-FAU); for ; Wed, 20 Nov 1996 09:49:09 +0100 (MET) Message-Id: <3292C603.6E0E@informatik.uni-erlangen.de> Date: Wed, 20 Nov 1996 09:49:07 +0100 From: "Franz J. Hauck" Organization: IMMD 4, Univ. Erlangen-Nuernberg X-Mailer: Mozilla 3.01 (X11; I; SunOS 5.5.1 sun4u) Mime-Version: 1.0 To: urn-ietf@bunyip.com Subject: [URN] URN Syntax Draft, NSS character set Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Franz J. Hauck" Errors-To: owner-urn-ietf@bunyip.com Hi, I'm new to the list and I just read draft-ietf-urn-syntax-01.txt. At the definition of the character set for the NSS, there is probably some part of a line missing; it looks somehow truncated: ::= "(" | ")" | "+" | " ":" | "=" | "?" | "@" My question: Which are the missing characters here? Thanks - Franz J. Hauck Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA16547 for urn-ietf-out; Tue, 19 Nov 1996 11:17:01 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA16523 for ; Tue, 19 Nov 1996 11:16:56 -0500 Received: from ietf.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22465 (mail destined for urn-ietf@services.bunyip.com); Tue, 19 Nov 96 11:16:55 -0500 Received: from ietf.org by ietf.org id aa15734; 19 Nov 96 10:03 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: urn-ietf@bunyip.com From: Internet-Drafts@ietf.org Subject: [URN] I-D ACTION:draft-ietf-urn-syntax-01.txt Date: Tue, 19 Nov 1996 10:03:40 -0500 Message-Id: <9611191003.aa15734@ietf.org> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org Errors-To: owner-urn-ietf@bunyip.com --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : URN Syntax Author(s) : R. Moats Filename : draft-ietf-urn-syntax-01.txt Pages : 6 Date : 11/18/1996 Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers. This document sets forward the canonical syntax for URNs. Support for both existing legacy and new namespaces is discussed. Requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-syntax-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-syntax-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961118171343.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-syntax-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-syntax-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961118171343.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA14563 for urn-ietf-out; Tue, 19 Nov 1996 09:05:58 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA14558 for ; Tue, 19 Nov 1996 09:05:54 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21059 (mail destined for urn-ietf@services.bunyip.com); Tue, 19 Nov 96 09:05:38 -0500 Message-Id: <9611191405.AA21059@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Tue Nov 19 08:04 CST 1996 From: "Ryan Moats" To: "Towsner" , "urn-ietf@bunyip.com" Date: Tue, 19 Nov 96 08:06:27 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] URN Syntax -01 i-d submission Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Mon, 18 Nov 1996 06:58:26 -0500, Towsner wrote: >NSS can have letters, numbers, but a NID can only have letters. Why? It >seems to me that things should be defined as similarly as possible to avoid >confusion. > >-- > >-Henry Towsner When the syntax draft started, I remember some off list discussion on whether the NID should have letters/numbers or just letters. As I remember it, the descision was "take letters for now, and we can always add in numbers later". Guess later is starting to think about arriving ;-) Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA06906 for urn-ietf-out; Mon, 18 Nov 1996 19:50:12 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA06901 for ; Mon, 18 Nov 1996 19:50:08 -0500 Received: from spain-c.it.earthlink.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17912 (mail destined for urn-ietf@services.bunyip.com); Mon, 18 Nov 96 19:49:56 -0500 Received: from [153.35.79.120] (Cust120.Max20.Boston.MA.MS.UU.NET [153.35.79.120]) by spain.it.earthlink.net (8.7.5/8.7.3) with ESMTP id QAA03832 for ; Mon, 18 Nov 1996 16:49:19 -0800 (PST) X-Sender: tows@mail.earthlink.net Message-Id: In-Reply-To: <3290DCA4.28AC@ds.internic.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Nov 1996 06:58:26 -0500 To: urn-ietf@bunyip.com From: Towsner Subject: Re: [URN] URN Syntax -01 i-d submission Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Towsner Errors-To: owner-urn-ietf@bunyip.com.This.strikes.me.as.being.needlessly.inconsistant.For.example.an NSS can have letters, numbers, but a NID can only have letters. Why? It seems to me that things should be defined as similarly as possible to avoid confusion. -- -Henry Towsner Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA04463 for urn-ietf-out; Mon, 18 Nov 1996 17:03:28 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA04456 for ; Mon, 18 Nov 1996 17:03:23 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16770 (mail destined for urn-ietf@services.bunyip.com); Mon, 18 Nov 96 17:03:14 -0500 Received: by privateer.windrose.omaha.ne.us; Mon Nov 18 16:01 CST 1996 Message-Id: <3290DCA4.28AC@ds.internic.net> Date: Mon, 18 Nov 1996 16:01:08 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: internet-drafts@ietf.org Cc: urn-ietf@bunyip.com Subject: [URN] URN Syntax -01 i-d submission Content-Type: text/plain; charset=us-ascii; name="urn.syntax.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="urn.syntax.txt" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Internet-Draft Ryan Moats draft-ietf-urn-syntax-01.txt AT&T Expires in six months November 1996 URN Syntax Filename: draft-ietf-urn-syntax-01.txt Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers. This document sets forward the canonical syntax for URNs. Support for both existing legacy and new namespaces is discussed. Requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. 1. Introduction Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space. The URN syntax therefore provides a means to encode character data in a form that can be sent in existing protocols, transcribed on most keyboards, etc. Expires 5/19/97 [Page 1] INTERNET DRAFT URN Syntax November 1996 2. Syntax All URNs have the following syntax: ::= ["urn:"] ":" is the Namespace Identifier, and is the Namespace Specific String. The leading case-insensitive "urn:" sequence is currently optional, as no closure on its definite presence or absence has been reached. The Namespace ID is used to determine the _syntactic_ interpretation of the Namespace Specific String (as discussed in [1]). RFC 1737 [2] presents additional requirements on URN encoding, which all have implications as far as limiting syntax. On the other hand, the requirement to support existing legacy naming systems has the effect of broadening syntax. Thus, we discuss the acceptable syntax for both the Namespace Identifier and the Namespace Specific String separately. 2.1 Namespace Identifier Syntax The following is the syntax for the Namespace Identifier. To (a) be consistent with all potential resolution schemes and (b) not put any undue constraints on any potential resolution scheme, the syntax for the Namespace Identifier is: ::= [ ] ::= | "-" | ::= any one of the 52 alphabetic characters A through Z in upper case and a through z in lower case This is slightly more restrictive that what is stated in RFC 1738 [4] (which allows the period "."). Further, the Namespace Identifier is case insensitive, so that "ISBN" and "isbn" refer to the same namespace. To avoid confusion with the optional "urn:" identifier, the NID "urn" is reserved and may not be used. 2.2 Namespace Specific String Syntax As required by 1737, there is a single canonical representation of the NSS portion of an URN. The format of this single canonical form follows: Expires 5/19/97 [Page 2] INTERNET DRAFT URN Syntax November 1996 ::= * ::= | "%" ::= | | | ::= | "A" | "B" | "C" | "D" | "E" | "F" ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ::= "(" | ")" | "+" | " ":" | "=" | "?" | "@" Depending on the rules governing a namespace, valid identifiers in a namespace might contain characters that are not members of the URN character set above (). Such strings MUST be translated into canonical NSS format before using them as protocol elements or otherwise passing them on to other applications. Translation is done by encoding each character outside the URN character set as a sequence of one to six octets using UTF-8 encoding, and the encoding of each of those octets as "%" followed by two characters from the character set above. The two characters give the hexadecimal representation of that octet. Namespaces MAY designate one or more characters from the URN character set as having special meaning for that namespace. If the namespace also uses that character in a literal sense as well, the character used in a literal sense must be encoded with "%" followed by the hexadecimal representation of that octet. Therefore, the process of registering a namespace identifier shall include publication of a definition of which characters have a special meaning and how to encode these characters if used in a literal sense. Expires 5/19/97 [Page 3] INTERNET DRAFT URN Syntax November 1996 3. Support of existing legacy naming systems and new naming systems URN-aware applications MAY accept as input other resource identifiers from existing legacy namespaces. If such identifiers contain characters that are not members of the URN character set specified in section 2.2, the identifier MUST be translated to canonical format as discussed in section 2.2. Some existing name spaces that have the properties of the URN-space contain some human-significant components, and these exist in a wide variety of languages. However, URNs are NOT intended to convey information that is significant to humans. While the translation rule in section 2.2 is provided for existing namespaces, new namespaces, as part of their registration documentation, MUST define a discipline for assigning new URNs that does not simplify the generation of human-significant names. 4. URN presentation and transport URN-aware applications MAY support "natural" display of URNs which contain characters encoded using "%" notation. However, they MUST provide for display of URNs in canonical form (i.e. in a format suitable for transcription). URNs may only be transported in canonical format. 5. Equivalence in URNs URNs are considered equivalent if they return the same resource. For various purposes, such as caching, a test is necessary to determine equivalence without actually resolving the URNs and fetching/comparing the underlying resources. "Lexical equivalence" is a stricter condition that the equivalence described above (functional equivalence). 5.1 Lexical Equivalence Lexical equivalence may be determined by comparing two URNs without making any network accesses. Two URNs are lexically equivalent if they are octet-by-octet equal after the following preprocessing 1. drop any preceding "urn:" token 2. normalize the case of the NID Some namespaces may define additional lexical equivalences, such as case-insensitivity of the NSS (or parts thereof). Additional lexical equivalences MUST be documented as part of namespace registration, MUST always have the effect of eliminating some of the false negatives obtained by the procedure above, and MUST NEVER says that Expires 5/19/97 [Page 4] INTERNET DRAFT URN Syntax November 1996 two URNs are not equivalent if the procedure above says they are equivalent. 5.2 Functional Equivalence Resolvers determine functional equivalence based on specific rules for the namespace. Therefore, namespace registration must include documentation on how to determine functional equivalence for that namespace. 5.3 Examples The following URN comparisons highlight the difference between these types of equivalence: urn:isbn:1-23485-8-29, isbn:1-23485-8-29 are lexically equiv. urn:isbn:1-23485-8-29, ISBN:1-23485-8-29 are lexically equiv. urn:isbn:1-23485-8-29, isbn:123485829 are not lexically equiv. but may be functionally equivalent. 6. Security considerations Because of the number of potential namespaces, it must be restated that certain of the characters in the Namespace Specific String may have special meaning to certain namespace resolvers. The process of registering a namespace identifier shall therefore include publication of a definition of which characters have a special meaning. 7. Acknowledgments Thanks to various members of the URN working group and <> for comments on earlier drafts of this document. This document is partially supported by the National Science Foundation. 8. References Request For Comments (RFC) and Internet Draft documents are available from and numerous mirror sites. [1] L. L. Daigle, P. Faltstrom, R. Iannella. "A Frame- work for the Assignment and Resolution of Uniform Resource Names," Internet Draft (work in progress). June 1996. [2] K. Sollins, L. Masinter. "Functional Requirements for Uniform Resource Names," RFC 1737. December Expires 5/19/97 [Page 5] INTERNET DRAFT URN Syntax November 1996 1994. [3] T. Berners-Lee. "Universal Resource Identifiers in WWW," RFC 1630. June 1994. [4] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource Locators (URL)," RFC 1738. December 1994. 9. Editor's address Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA Phone: +1 402 894-9456 EMail: jayhawk@ds.internic.net This Internet Draft expires May 19, 1997. Expires 5/19/97 [Page 6] Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA28465 for urn-ietf-out; Mon, 18 Nov 1996 12:07:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA28460 for ; Mon, 18 Nov 1996 12:07:29 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14031 (mail destined for urn-ietf@services.bunyip.com); Mon, 18 Nov 96 12:07:21 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA01591; Mon, 18 Nov 1996 10:07:06 -0700 (MST) Message-Id: <2.2.32.19961118171528.007065ec@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 18 Nov 1996 10:15:28 -0700 To: Terry Allen , urn-ietf@bunyip.com From: Ron Daniel Subject: Re: [URN] text/uri-list registration Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Terry Allen (at least at 08:26 AM 11/17/96 -0800) >As a nonprogrammer I'm probably missing the obvious, but in the >interest of clarity, why > >>2) The first non-comment line shall be an integer giving the number of > URIs in the list. > >so the parser of a uri-list can know when it will have reached >the end of the list? to allow error recovery if the uri-list is >malformed? something else? The intention was so that the parser could know how many URIs to expect. However, as has been pointed out in some off-list mail, this is not necessary and it introduces the potential for errors when the number of URLs does not agree with the value of the integer. I'll revise the format to remove that integer. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA18588 for urn-ietf-out; Sun, 17 Nov 1996 11:28:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA18583 for ; Sun, 17 Nov 1996 11:28:34 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08559 (mail destined for urn-ietf@services.bunyip.com); Sun, 17 Nov 96 11:28:28 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id IAA09453; Sun, 17 Nov 1996 08:26:49 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id IAA06194; Sun, 17 Nov 1996 08:26:54 -0800 (PST) Date: Sun, 17 Nov 1996 08:26:54 -0800 (PST) From: Terry Allen Message-Id: <199611171626.IAA06194@ishtar.fsc.fujitsu.com> To: rdaniel@acl.lanl.gov, urn-ietf@bunyip.com Subject: Re: [URN] text/uri-list registration Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com As a nonprogrammer I'm probably missing the obvious, but in the interest of clarity, why >2) The first non-comment line shall be an integer giving the number of URIs in the list. so the parser of a uri-list can know when it will have reached the end of the list? to allow error recovery if the uri-list is malformed? something else? Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA19287 for urn-ietf-out; Fri, 15 Nov 1996 16:18:42 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA19092; Fri, 15 Nov 1996 16:16:59 -0500 Received: from ns.alis.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01031 (mail destined for urn-ietf@services.bunyip.com); Fri, 15 Nov 96 16:16:42 -0500 Received: from fyergeau.alis.com ([207.81.28.17]) by genstar.alis.ca (8.7.5/8.7.3) with SMTP id QAA28482; Fri, 15 Nov 1996 16:16:05 -0500 (EST) Message-Id: <2.2.32.19961115211148.006eb9e0@genstar.alis.ca> X-Sender: yergeau@genstar.alis.ca X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 15 Nov 1996 16:11:48 -0500 To: Ron Daniel From: Francois Yergeau Subject: Re: [URN] URI internationalization Cc: urn-ietf@bunyip.com, uri@bunyip.com Content-Transfer-Encoding: quoted-printable Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Francois Yergeau Errors-To: owner-urn-ietf@bunyip.com [Cross-posted to URI list, from URN-IETF list] =C0 09:05 15-11-96 -0700, Ron Daniel a =E9crit : >I think I18N for URLs is a more difficult problem than it has been for >URNs. We have a large number of existing URLs in a variety of character >sets. Well, no, it appears we don't really have that. I made a search for non-ASCII URLs last spring (both 8-bit octets and %XY with X>=3D8), and f= ound very few out on the Web (cf. ). Less than 0.25% in fact, and then some were typos (divide signs instead of tilde, f= or instance) that didn't work until corrected by hand. Furthermore, compatibility is made easier by the fact that UTF-8 data can= be quite reliably recognized as such. Given a UR*, a server can test it for UTF-8 validity; if it fails, it's some 'old' UR* in some encoding other t= han UTF-8, the server can process as it did before and nothing is broken; if = it passes, just process as UTF-8. A little experimentation (need more) show= s that false positives are unlikely, provided one takes care of 7-bit ISO-2022-like encodings that look like ASCII (and thus UTF-8) but are not. As for complexity, a UTF-8 validator fits in about 20 lines of C. >While I18N for URLs is a legitimate issue, it is not an issue for the >URN-WG (IMHO). The URI list is still alive, that might be the proper >place to begin discussions. Agreed, I cross-posted there. Please limit replies to the URI list. Regards, --=20 Fran=E7ois Yergeau Alis Technologies Inc., Montr=E9al T=E9l : +1 (514) 747-2547 Fax : +1 (514) 747-2561 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA17324 for urn-ietf-out; Fri, 15 Nov 1996 15:33:05 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA17319 for ; Fri, 15 Nov 1996 15:33:03 -0500 Received: from ns.alis.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00667 (mail destined for urn-ietf@services.bunyip.com); Fri, 15 Nov 96 15:32:57 -0500 Received: from fyergeau.alis.com ([207.81.28.17]) by genstar.alis.ca (8.7.5/8.7.3) with SMTP id PAA28227; Fri, 15 Nov 1996 15:32:27 -0500 (EST) Message-Id: <2.2.32.19961115202810.0071e124@genstar.alis.ca> X-Sender: yergeau@genstar.alis.ca X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 15 Nov 1996 15:28:10 -0500 To: Ron Daniel From: Francois Yergeau Subject: Re: [URN] Re: I18N does not belong in URNs Cc: urn-ietf@bunyip.com Content-Transfer-Encoding: quoted-printable Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Francois Yergeau Errors-To: owner-urn-ietf@bunyip.com =C0 09:27 15-11-96 -0700, Ron Daniel a =E9crit : >A couple of points here. First, the URI RFC (1630) says that 8-bit >values should be %encoded. RFC 1630 is informational, and clearly does not address internationalizat= ion issues. This has plagued URLs for a long time, as 8-bit octets have no defined meaning. >Not all of the transports through which >URNs will be sent are 8-bit. An unfortunate fact of life. True, but of limited relevance. I'm not calling for forbidding %-encodin= g, only for not making it compulsory and burden the whole world *forever* wi= th the present-day limitations of basically one Internet "transport" (mail). If you need to mail an UTF-8 URN, please go ahead and %-encode it, or use one of the MIME encodings that were designed exactly for that. >Second, Ryan's "URN Syntax" draft essentially says that, as an optimizat= ion, >if a sender and reciever know that they are using an 8-bit clean transpo= rt, >then they could sent UTF-8 as octets instead of %HH. This optimization >may become commonly used, but for compatability with existing software >we are much safer saying that the standard is %encoded. This should be exactly the other way around: if you are afraid of a 7-bit transport, then you MAY %-encode everything. >Making %encoding the standard seems (to me at least) to be perfectly >in line with the homily about being conservative in what you send. The homily is about sending *exactly* what the spec says, not about makin= g the spec overly conservative and precluding progress. Moreover, "Be conservative in what you send" would mean that with %HH the standard, 8-b= it would be effectively forbidden even with 8-bit transports, contradicting = the paragraph above. A useless layer of encoding, plus bandwidth and storage waste forever. Not sound design IMHO, there are better ways to deal with the occasional 7-bit transport than to mandate 7 bits everywhere for all times; providing a way out for those cases is sufficient. Regards, --=20 Fran=E7ois Yergeau Alis Technologies Inc., Montr=E9al T=E9l : +1 (514) 747-2547 Fax : +1 (514) 747-2561 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA16096 for urn-ietf-out; Fri, 15 Nov 1996 14:03:06 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA16088 for ; Fri, 15 Nov 1996 14:02:55 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29813 (mail destined for urn-ietf@services.bunyip.com); Fri, 15 Nov 96 14:02:09 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00965-0@josef.ifi.unizh.ch>; Fri, 15 Nov 1996 20:01:44 +0100 Subject: Re: [URN] URI internationalization To: rdaniel@acl.lanl.gov (Ron Daniel) Date: Fri, 15 Nov 1996 20:01:43 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: <2.2.32.19961115160551.006f3f5c@acl.lanl.gov> from "Ron Daniel" at Nov 15, 96 09:05:51 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3556 From: Martin J Duerst Message-Id: <"josef.ifi..656:15.10.96.19.01.46"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Hello Ron - Many thanks for your comments. Hope to get more of these from others in this group. >Thus spoke Martin J Duerst (at least at 03:57 PM 11/15/96 +0100) > >>The internationalization of URNs, URLs, and URIs in general has been >>raised as a problem or topic in many different places. Given the >>various recent discussions and the progress made in particular in >>this group, I think that time has come to address this issue in a >>more formal way, inside an existing ietf working group or by creating >>a specific working group for it. > >I think I18N for URLs is a more difficult problem than it has been for >URNs. We have a large number of existing URLs in a variety of character >sets. Saying "thou shalt use 10646" will meet more resistance than it >has in this WG, due to backward compatability considerations. I am very aware of this problem. A lot of it has been discussed e.g. in the ftp-wg. The basic idea is to have each protocol (and within that each server) stay with what they have used, but to convert to using e.g. UTF-8 if and when identification of characters (as opposed to raw octets) is desired. Awareness of this fact is why I was repeatedly adressing the question of what happens with URNs if they don't form correct UTF-8 sequences. >The first >question that has to be answered is "Is an I18N scheme for URLs that >breaks existing URLs acceptable or unacceptable?". If the answer is >"unacceptable" you have a tremendous technical problem. If the answer >is "acceptable" you have a MUCH bigger social problem. Call me a >coward, but I want no part of the second battle. I want to get on to >URCs before *all* my hair turns grey. By getting aware of the fact that correct UTF-8 sequences are really rare in current URLs, you get more than you would expect. >While I18N for URLs is a legitimate issue, it is not an issue for the >URN-WG (IMHO). The URI list is still alive, that might be the proper >place to begin discussions. I suggest that you wait until the recent >agreements on UTF-8, %HH, ... for URNs have been codified in the >Syntax draft, but that is only a suggestion. Many thanks for these suggestions. One reason of why I wanted to initiate some discussion now is because next week, there will be a meeting on WWW i18n in Sevilla, and URI i18n will be one important topic. >>The aim would be to produce a document that would include: >[specific points deleted for brevity] > >What you have outlined appears reasonable, but may be best >handled as a series of documents. As you have outlined it, >I think you are talking about a 100 page informational RFC. I guess it will be smaller. I guess we might start with one document, and split when it gets too large. >>- What is the best framework/place/list to host this activity. > >Your friendly area directors can advise you on this. I suggest >you come up with an outline of your solution and then ask them if >it needs a WG or if they want to do a special "last-call" to the >URI list and some selected experts. At present, it looks to me like the solution is more or less defined. Writing the document(s) of course will take some more time. >Peer-review of a concrete >proposal seems to work much better than design by committee. The reason why I would like to have a WG, or do the work in the context of a WG, is that I don't want to submit drafts and RFC in person. Discussions always bring up points that would have been forgotten, and the work of a WG has (hopefully) more influence that the work of one or two individuals. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA15446 for urn-ietf-out; Fri, 15 Nov 1996 13:42:31 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA15437 for ; Fri, 15 Nov 1996 13:42:28 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29572 (mail destined for urn-ietf@services.bunyip.com); Fri, 15 Nov 96 13:41:39 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00924-0@josef.ifi.unizh.ch>; Fri, 15 Nov 1996 19:40:39 +0100 Subject: Re: [URN] Re: I18N does not belong in URNs To: yergeau@alis.com Date: Fri, 15 Nov 1996 19:40:38 +0100 (MET) Cc: dgd@cs.bu.edu, urn-ietf@bunyip.com In-Reply-To: <2.2.32.19961115155024.007169c0@genstar.alis.ca> from "Francois Yergeau" at Nov 15, 96 10:50:24 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4755 From: Martin J Duerst Message-Id: <"josef.ifi..890:15.10.96.18.40.40"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Francois Yergeau wrote: >I fail to see why the %-encoded URN should be the reference. This is a >fallback to the bad old 7-bit days, and results in a needless waste of >bandwidth and storage resources. Reading the recent report of the IAB >Character Set Workshop (draft-weider-iab-char-wrkshop-00.txt) It's nice to have this available finally. >, I find in >section 8.2 (Recommendations for new Internet protocols): > > "New protocols do not suffer from the need to be compatible > with old 7-bit pipes. New protocol specifications SHOULD > use ISO 10646 as the base charset unless there is an > overriding need to use a different base charset." That's indeed what we are doing. Pipe width and base charset are not directly related. >Elsewhere (3.4.3), UTF-8 is recommended as the encoding and use of escape >mechanisms is warned against ("...must be weighed very carefully"). This warns against techniques such as SGML &#nnn;. %HH is not on the character level, it is on the octet level. And it is already well established for URLs. >> We can define the standard as %-encoded UTF-8, and if people implement >>this other ways, they are implementing convenience features in the >>interface: the software will always have the %-encoded URN available. Much software will probably do so anyway, despite what the standard says, and without creating a conflict, because storing and comparing is more efficient on the 8-bit form. >As if 8-bit octets on-the-wire were something evil! It is much wiser, IMHO, >to have the real UTF-8 as the reference value, and have the %-encoding as >the convenience feature (it must be there anyway for reserved and unsafe >characters, so there is no risk that an application will not support it). >If a user needs ASCII-only, let *his* software do the %-encoding for him, >but let's not force a 9-byte encoding on CJK characters when 3 are enough. > >There should be a good reason to burden the whole world forever with >%-encoding of all 8-bit octets, and I see none at all, except for a visceral >and unwarranted fear of 8-bit octets. I think we have to be careful, because there are at least two ways in which URNs can be transferred/stored: - In "dedicated" protocols and databases. An example is the header of an HTTP request. - In text. An example is HTML. For the former, raw 8-bit (i.e. UTF-8) can be used. According to the standards, officially HTTP headers are limited to ASCII, but in practice, they will pass 8 bits without problems. (If not, please don't make a long discussion out of this. It only serves as an example of a (part of) a protocol that up to now transmitted "raw" data without consideration to character set issues. For the later, as Francois probably knows even better than I do from his work on URL internationalization, putting an URN with 10646 characters into a HTML document written in iso-8859-1 in raw 8-bit form will produce bad results. Without extremely clever tool support, it will neither be possible to input such an URN, nor will an URN show up with the characters it represents. Transcoding, as well as other operations such as cut-and-paste, will also not do what everybody would hope for. Just saying "use 8 bits, use 8 bits" could however give the impression to some implementors that the UTF-8 8-bit octets should appear as such in an HTML document in iso-8859-1. Whatever we make the "standard" or "base" form, or whether we such a form or not, we should therefore clearly say that URNs - Can be transmitted/stored in 8-bit form in protocols/databases that accomodate URNs as such, and not as part of text and/or associated with character encoding information. - Have to be interpreted and treated as characters when transmitted as part of an encoded text with (explicitly or implicitly) associated character encoding information. Those characters that cannot be represented in the choosen encoding, as well as %HH sequences that do not form valid UTF-8 sequences (and of course reserved characters) have to stay in %HH form. I know that the last point may again frighten some of you. It seems to introduce a new representation. But if you think about URLs in EBCDIC, you will see that it is nothing new. Personally, I think that the second paragraph above could be amended with a sentence saying that to avoid eventual misinterpretations due to lack of appropriate information about character encoding, and to make the URN transcribable to the widest audience, full %HH encoding can/should be choosen. We may have to discuss about how strong this wording should be. But we definitely have to include something that avoids misunderstandings so that raw 8-bit UTF-8 will never turn up as such in e.g. iso-8859-1 documents. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA11066 for urn-ietf-out; Fri, 15 Nov 1996 11:19:51 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA11061 for ; Fri, 15 Nov 1996 11:19:49 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28291 (mail destined for urn-ietf@services.bunyip.com); Fri, 15 Nov 96 11:19:47 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id JAA04311; Fri, 15 Nov 1996 09:19:41 -0700 (MST) Message-Id: <2.2.32.19961115162755.006f5b14@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Nov 1996 09:27:55 -0700 To: Francois Yergeau From: Ron Daniel Subject: Re: [URN] Re: I18N does not belong in URNs Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Francois Yergeau (at least at 10:50 AM 11/15/96 -0500) >=C0 12:13 14-11-96 -0500, David G. Durand a =E9crit : >> We can define the standard as %-encoded UTF-8, and if people implement >>this other ways, they are implementing convenience features in the >>interface: the software will always have the %-encoded URN available. > >I fail to see why the %-encoded URN should be the reference. This is a >fallback to the bad old 7-bit days, and results in a needless waste of >bandwidth and storage resources. A couple of points here. First, the URI RFC (1630) says that 8-bit values should be %encoded. Not all of the transports through which URNs will be sent are 8-bit. An unfortunate fact of life. Second, Ryan's "URN Syntax" draft essentially says that, as an optimization, if a sender and reciever know that they are using an 8-bit clean transport, then they could sent UTF-8 as octets instead of %HH. This optimization may become commonly used, but for compatability with existing software we are much safer saying that the standard is %encoded. Making %encoding the standard seems (to me at least) to be perfectly in line with the homily about being conservative in what you send. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA10549 for urn-ietf-out; Fri, 15 Nov 1996 10:58:04 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA10544 for ; Fri, 15 Nov 1996 10:58:01 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28097 (mail destined for urn-ietf@services.bunyip.com); Fri, 15 Nov 96 10:58:00 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id IAA04144; Fri, 15 Nov 1996 08:57:37 -0700 (MST) Message-Id: <2.2.32.19961115160551.006f3f5c@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 15 Nov 1996 09:05:51 -0700 To: Martin J Duerst From: Ron Daniel Subject: Re: [URN] URI internationalization Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Martin J Duerst (at least at 03:57 PM 11/15/96 +0100) >The internationalization of URNs, URLs, and URIs in general has been >raised as a problem or topic in many different places. Given the >various recent discussions and the progress made in particular in >this group, I think that time has come to address this issue in a >more formal way, inside an existing ietf working group or by creating >a specific working group for it. I think I18N for URLs is a more difficult problem than it has been for URNs. We have a large number of existing URLs in a variety of character sets. Saying "thou shalt use 10646" will meet more resistance than it has in this WG, due to backward compatability considerations. The first question that has to be answered is "Is an I18N scheme for URLs that breaks existing URLs acceptable or unacceptable?". If the answer is "unacceptable" you have a tremendous technical problem. If the answer is "acceptable" you have a MUCH bigger social problem. Call me a coward, but I want no part of the second battle. I want to get on to URCs before *all* my hair turns grey. While I18N for URLs is a legitimate issue, it is not an issue for the URN-WG (IMHO). The URI list is still alive, that might be the proper place to begin discussions. I suggest that you wait until the recent agreements on UTF-8, %HH, ... for URNs have been codified in the Syntax draft, but that is only a suggestion. >The aim would be to produce a document that would include: [specific points deleted for brevity] What you have outlined appears reasonable, but may be best handled as a series of documents. As you have outlined it, I think you are talking about a 100 page informational RFC. Splitting it not only makes it easier to read, it makes it faster to produce since contentious parts don't delay non-contentious parts. >- What is the best framework/place/list to host this activity. Your friendly area directors can advise you on this. I suggest you come up with an outline of your solution and then ask them if it needs a WG or if they want to do a special "last-call" to the URI list and some selected experts. Peer-review of a concrete proposal seems to work much better than design by committee. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA10506 for urn-ietf-out; Fri, 15 Nov 1996 10:55:27 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA10501 for ; Fri, 15 Nov 1996 10:55:25 -0500 Received: from ns.alis.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28075 (mail destined for urn-ietf@services.bunyip.com); Fri, 15 Nov 96 10:55:18 -0500 Received: from fyergeau.alis.com ([207.81.28.17]) by genstar.alis.ca (8.7.5/8.7.3) with SMTP id KAA26667; Fri, 15 Nov 1996 10:54:40 -0500 (EST) Message-Id: <2.2.32.19961115155024.007169c0@genstar.alis.ca> X-Sender: yergeau@genstar.alis.ca X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 15 Nov 1996 10:50:24 -0500 To: dgd@cs.bu.edu (David G. Durand) From: Francois Yergeau Subject: Re: [URN] Re: I18N does not belong in URNs Cc: urn-ietf@bunyip.com Content-Transfer-Encoding: quoted-printable Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Francois Yergeau Errors-To: owner-urn-ietf@bunyip.com =C0 12:13 14-11-96 -0500, David G. Durand a =E9crit : >On the other hand, if the reference >string is the %-encoded UTF-8 value, then we should be OK for >transcribability. The issue of user-friendly software that hides %-encod= ing >is not part of the protocol, so its _possibility_ shouldn't unduly >influence us. > We can define the standard as %-encoded UTF-8, and if people implemen= t >this other ways, they are implementing convenience features in the >interface: the software will always have the %-encoded URN available. I fail to see why the %-encoded URN should be the reference. This is a fallback to the bad old 7-bit days, and results in a needless waste of bandwidth and storage resources. Reading the recent report of the IAB Character Set Workshop (draft-weider-iab-char-wrkshop-00.txt) , I find in section 8.2 (Recommendations for new Internet protocols): "New protocols do not suffer from the need to be compatible with old 7-bit pipes. New protocol specifications SHOULD=20 use ISO 10646 as the base charset unless there is an=20 overriding need to use a different base charset." Elsewhere (3.4.3), UTF-8 is recommended as the encoding and use of escape mechanisms is warned against ("...must be weighed very carefully"). > We can define the standard as %-encoded UTF-8, and if people implemen= t >this other ways, they are implementing convenience features in the >interface: the software will always have the %-encoded URN available. As if 8-bit octets on-the-wire were something evil! It is much wiser, IM= HO, to have the real UTF-8 as the reference value, and have the %-encoding as the convenience feature (it must be there anyway for reserved and unsafe characters, so there is no risk that an application will not support it). If a user needs ASCII-only, let *his* software do the %-encoding for him, but let's not force a 9-byte encoding on CJK characters when 3 are enough. There should be a good reason to burden the whole world forever with %-encoding of all 8-bit octets, and I see none at all, except for a visce= ral and unwarranted fear of 8-bit octets. --=20 Fran=E7ois Yergeau Alis Technologies Inc., Montr=E9al T=E9l : +1 (514) 747-2547 Fax : +1 (514) 747-2561 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA07976 for urn-ietf-out; Fri, 15 Nov 1996 09:59:24 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA07967 for ; Fri, 15 Nov 1996 09:59:20 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27696 (mail destined for urn-ietf@services.bunyip.com); Fri, 15 Nov 96 09:58:37 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00662-0@josef.ifi.unizh.ch>; Fri, 15 Nov 1996 15:57:12 +0100 Subject: [URN] URI internationalization To: rdaniel@acl.lanl.gov Date: Fri, 15 Nov 1996 15:57:11 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: <2.2.32.19961114191535.007244b4@acl.lanl.gov> from "Ron Daniel" at Nov 14, 96 12:15:35 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3217 From: Martin J Duerst Message-Id: <"josef.ifi..108:15.10.96.14.57.24"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ron Daniel wrote: >Hi, > >One of the changes to the "conventions" draft was using text/uri-list >instead of text/plain as the media type for lists of URIs that would >be returned by requests such as N2Ls. Here is my first stab at the info >required to register that type. Any comments before I send it in? > >===================== > >1. MIME type name: text > > >2. MIME subtype name: uri-list > > >3. Required Parameters: None > > >4. Optional Parameters: charset > > Charset handling for URIs is currently being discussed. This > registration shall be updated with a discussion of the interaction > of the charset parameter and the upcoming URI charset rules once > that interaction is understood. Several people I am in contact with, and myself, already understand how this will have to interact. With this mail, I don't want to force anything into the current draft at a undue time, but I would like to take this as a chance to address a general topic: The internationalization of URNs, URLs, and URIs in general has been raised as a problem or topic in many different places. Given the various recent discussions and the progress made in particular in this group, I think that time has come to address this issue in a more formal way, inside an existing ietf working group or by creating a specific working group for it. The aim would be to produce a document that would include: - - A general way to encode the characters used worldwide in URIs. - Guidelines as to when and how the above general way should be used, and what can or should be done if they can or do not apply. - Specifications and guidelines for the use of various forms and derivations of the above general way in various representations of URIs, e.g. on paper, on screen, in text documents, in protocols. - Guidelines to scheme and protocol designers/implementors about how to take worldwide character issues into account, and about what to speicify for particular URI schemes. Delineation of responsibilites between URIs in general and protocols/schemes (so called protocol autonomy). - Specifications and/or guidelines for particular issues related to worldwide characters and URIs, such as bidirectionality, equivalence, and others. For this work, I would like suggestions and advice on: - What is the best framework/place/list to host this activity. - How to do this (both formal ietf procedure and actual tips). - What other lists/groups have come upon similar problems, should be contacted,... - Who would be interested to contribute, as wg chair, or whatever. - What topics have been forgotten in the above list. - What people generally think about URI internationalisation, what ideas they have of how to solve the problem, and so on (maybe better save this for the actual discussion). Many thanks in advance for all your kind help. Regards, Martin. ---- Dr.sc. Martin J. Du"rst ' , . p y f g c R l / = Institut fu"r Informatik a o e U i D h T n S - der Universita"t Zu"rich ; q j k x b m w v z Winterthurerstrasse 190 (the Dvorak keyboard) CH-8057 Zu"rich-Irchel Tel: +41 1 257 43 16 S w i t z e r l a n d Fax: +41 1 363 00 35 Email: mduerst@ifi.unizh.ch ---- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA03277 for urn-ietf-out; Fri, 15 Nov 1996 06:20:31 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA03272 for ; Fri, 15 Nov 1996 06:20:28 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26721 (mail destined for urn-ietf@services.bunyip.com); Fri, 15 Nov 96 06:20:21 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00484-0@josef.ifi.unizh.ch>; Fri, 15 Nov 1996 12:18:17 +0100 Subject: Re: [URN] Re: I18N does not belong in URNs To: dgd@cs.bu.edu Date: Fri, 15 Nov 1996 12:18:16 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: from "David G. Durand" at Nov 14, 96 12:13:21 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2314 From: Martin J Duerst Message-Id: <"josef.ifi..298:15.10.96.11.18.26"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com David G. Durand wrote: [Sorry: In an earlier mail, I attributed a quote to Mark Fischer when it indeed came from David G. Durand.] > UTF-8, with >%encoding for characters over 127, is a unique transcribable byte sequence >capable of grandfathering all of the namespaces we have discussed. As long >as we require naming authorities to use well-defined Unicode names, we can >even handle non-Unicode characters, by making authorities that need them >define a policy for their application of the private-use area. consistent >use of private use characters will guarantee uniqueness, so we are all set! The mentioning of the private-use area tuches the following problems: - What to do with characters not in ISO 10646/Unicode. - What to do with namespaces not defined in terms of characters. - What to do with URNs that are not valid %HH encoded UTF-8 sequences. As for characters not in Unicode, this is really a case that should appear extremely rarely. Unicode already contains an enormous amount of characters from all kinds of international, national, and corporate standards. And new scripts and characters are still being added. The use of the private area(s) should definitely not be openly suggested, but be downplayed as much as possible. As for namespaces not defined in terms of characters, we can either require that they define a solution in terms of ISO 10646 characters, or we can allow them to define their own solution in terms of octets. For space and other considerations, they ideally will choose something similar to the data: URL, but we have to clearly specify what we tolerate and what not. If we tolerate direct encoding of arbitrary octets with %HH, then we have to address the issue of URNs where the %HH ecodings do not reperesent a correct UTF-8 sequence. Mainly for reasons of cross/backwards compatibility with URLs, I would suggest that we clearly specify that software transporting, storing, and manipulating URNs should take them as they are, even if they are not interpretable as UTF-8. In user-friendly environments, octets that do not form a valid UTF-8 sequence, as well as UTF-8 combinations that do not represent characters (the Unicode code position is undefined) or that cannot be displayed (lack of fonts,...) should be displayed in %HH notation. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA03016 for urn-ietf-out; Fri, 15 Nov 1996 05:45:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA03010 for ; Fri, 15 Nov 1996 05:45:34 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26632 (mail destined for urn-ietf@services.bunyip.com); Fri, 15 Nov 96 05:45:32 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00450-0@josef.ifi.unizh.ch>; Fri, 15 Nov 1996 11:44:35 +0100 Subject: Re: [URN] Re: I18N does (somehow) belong in URNs To: moore@cs.utk.edu Date: Fri, 15 Nov 1996 11:44:34 +0100 (MET) Cc: dgd@cs.bu.edu, urn-ietf@bunyip.com In-Reply-To: <199611150306.WAA19223@ig.cs.utk.edu> from "Keith Moore" at Nov 14, 96 10:06:36 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 759 From: Martin J Duerst Message-Id: <"josef.ifi..652:15.10.96.10.44.38"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore answered Mark Fisher: >> We can define the standard as %-encoded UTF-8, and if people implement >> this other ways, they are implementing convenience features in the >> interface: the software will always have the %-encoded URN available. This >> might hurt me in typing in Japanese URNs from a Japanese-language paper >> publication, but the scenarios where non-Japanese speakers will be doing >> such tasks are pretty contrived. > >This all sounds reasonable to me. Maybe we've arrived at the best >possible compromise. I sounds very reasonable to me too. I hope with can go forward with this solution. I also think it can serve as a guideline for other, similar problems, in particular the internationalization of URLs. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA29418 for urn-ietf-out; Thu, 14 Nov 1996 22:09:26 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA29413 for ; Thu, 14 Nov 1996 22:09:24 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24895 (mail destined for urn-ietf@services.bunyip.com); Thu, 14 Nov 96 22:09:07 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id WAA19223; Thu, 14 Nov 1996 22:06:36 -0500 (EST) Message-Id: <199611150306.WAA19223@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: dgd@cs.bu.edu (David G. Durand) Cc: urn-ietf@bunyip.com, moore@cs.utk.edu Subject: [URN] Re: I18N does not belong in URNs In-Reply-To: Your message of "Thu, 14 Nov 1996 12:13:21 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 14 Nov 1996 22:06:36 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > This means the human meaningfulness is not a requirement of URNs. This is > probably good. But it is _not_ as you have claimed, a requirement that URNs > _not_ be human-readable. I agree, the charter does not prevent the existence of human-readable URNs. > As I have repeatedly pointed out, compatibility with existing > persistent namespaces will require that at least some human-meaningful > names be included. The notion of requiring users of FPIs (for instance) to > hex-encode 50+ character ascii strings stil strikes me a ludicrous. But > once we allow ASCII, we have to meet the questions of the international > community. My feeling is that transcribability is a more serious problem > than the UTF-8 advocates are admitting. On the other hand, if the reference > string is the %-encoded UTF-8 value, then we should be OK for > transcribability. The issue of user-friendly software that hides %-encoding > is not part of the protocol, so its _possibility_ shouldn't unduly > influence us. > > We can define the standard as %-encoded UTF-8, and if people implement > this other ways, they are implementing convenience features in the > interface: the software will always have the %-encoded URN available. This > might hurt me in typing in Japanese URNs from a Japanese-language paper > publication, but the scenarios where non-Japanese speakers will be doing > such tasks are pretty contrived. This all sounds reasonable to me. Maybe we've arrived at the best possible compromise. -Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA26505 for urn-ietf-out; Thu, 14 Nov 1996 14:09:00 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA26500 for ; Thu, 14 Nov 1996 14:08:57 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21876 (mail destined for urn-ietf@services.bunyip.com); Thu, 14 Nov 96 14:07:38 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA08538 for ; Thu, 14 Nov 1996 12:07:21 -0700 (MST) Message-Id: <2.2.32.19961114191535.007244b4@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Nov 1996 12:15:35 -0700 To: urn-ietf@bunyip.com From: Ron Daniel Subject: [URN] text/uri-list registration Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Hi, One of the changes to the "conventions" draft was using text/uri-list instead of text/plain as the media type for lists of URIs that would be returned by requests such as N2Ls. Here is my first stab at the info required to register that type. Any comments before I send it in? ===================== 1. MIME type name: text 2. MIME subtype name: uri-list 3. Required Parameters: None 4. Optional Parameters: charset Charset handling for URIs is currently being discussed. This registration shall be updated with a discussion of the interaction of the charset parameter and the upcoming URI charset rules once that interaction is understood. 5. Encoding Considerations: URI encodings are already specified in RFC 1630, ... The URIs in the text/uri-list shall conform to those documents. The URI encoding rules allow for URIs to be made mail-safe, so additional encoding should not be necessary. 6. Security Considerations: Client software should be aware of the security considerations of URIs. For example, accessing some URIs can result in sending a death threat to a head of state, perhaps spurring a visit from the relevant protective service. Accessing other URIs may result in financial obligations. While the legitimate provider of a uri-list can exploit these properties for good or ill, they make uri-lists an attractive target for spoofing. Further, the lookup and reverse lookup potential of the uri-list may be attractive to traffic analysts. URI lists may also reveal confidential information, such as the location of sensitive information. Because of these considerations, external confidentiality measures should be available to protect uri-list responses when appropriate. 7. Interoperability considerations: none? 8. Published Specification: Uniform Resource Locators (URLs) and Uniform Resource Names (URNs) are two instances of the more general class of identifiers known as Uniform Resource Identifiers (URIs). URN resolution methods typically wish to return lists of URLs for a resource so that fault-tolerance and load balancing can be achieved. The text/uri-list format is intended to be a very simple format for communicating such lists of URLs (and URNs) in a form suitable for automatic processing. The format of text/uri-list resources is: 1) Any lines beginning with the '#' character are comment lines and are ignored during processing. 2) The first non-comment line shall be an integer giving the number of URIs in the list. 3) The remaining non-comment lines shall be URIs (URNs or URLs), encoded according to the URI specification (RFC 1630). Each URI shall appear on one and only one line. 4) As for all text/* formats, lines are terminated with a CRLF pair. In applications where one URI has been mapped to a list of URIs, the first line of the text/uri-list response SHOULD be a comment giving the original URI. An example of the format is given below: # urn:cid:foo@huh.org 3 http://www.huh.org/cid/foo.html http://www.huh.org/cid/foo.pdf ftp://ftp.foo.org/cid/foo.txt 9. Applications which use this media type: URN resolvers are the initial applications. Web clients and proxies are applications that are likely to support this format in the future. 10. Additional Information: a) magic number(s) none presently b) file extension(s) .uris or .uri recommended c) Macintish File Type Code(s) none presently - "URIs" recommended if no conflict with existing codes? d) Object Identifier(s) or OID(s) none presently (Should we try to get one or blow it off for now?) 11. Person to contact for further information: Name) Ron Daniel [Of course if someone else wants this...] email) rdaniel@lanl.gov 12. Intended usage: Common? Limited use? [I'm asking for advice here] 13. Author/change controller Ron Daniel, rdaniel@lanl.gov [Of course if someone else wants this...] ======== Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA26494 for urn-ietf-out; Thu, 14 Nov 1996 14:08:13 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA26489 for ; Thu, 14 Nov 1996 14:08:09 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21875 (mail destined for urn-ietf@services.bunyip.com); Thu, 14 Nov 96 14:07:36 -0500 Received: by seawall with (8.6.12/) id OAA14295; Thu, 14 Nov 1996 14:07:00 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma014285; Thu Nov 14 14:06:58 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <328B6DF5@MSMAIL.INDY.TCE.COM>; Thu, 14 Nov 96 14:07:33 EST From: Fisher Mark To: "dgd@cs.bu.edu" , Martin J Duerst , "moore@cs.utk.edu" Cc: "stu_weibel@oclc.org" , "urn-ietf@bunyip.com" Subject: Re: [URN] Re: I18N does not belong in URNs Date: Thu, 14 Nov 96 14:05:00 EST Message-Id: <328B6DF5@MSMAIL.INDY.TCE.COM> Encoding: 48 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com Martin J Duerst writes: >I have stopped proposing adding i18n support for meaningfulness. >This argument is not necessary. But I think it is necessary that >the same amount of meaningfulness is allowed or disallowed to >users of any language around the globe. This is only guaranteed >by either radically restricting the character set or completely >opening it up. I would further propose that if "meaninglessness" is a requirement, only random identifiers will do. If there is a meaning present, people will use it. I do not, however, think that URNs must necessarily have no meaning to humans -- they may, or they may not. It is up to namespace designer. (And there may be a _lot_ of those!) Meanwhile, David Durand writes: >At 5:17 PM 11/13/96, Keith Moore wrote: >>was imprecise and possibly misleading. A better statement is: >> >> "URNs aren't intended to serve as human meaningful names". >> >>Keith > >This means the human meaningfulness is not a requirement of URNs. This is >probably good. But it is _not_ as you have claimed, a requirement that URNs >_not_ be human-readable. > > As I have repeatedly pointed out, compatibility with existing >persistent namespaces will require that at least some human-meaningful >names be included. The notion of requiring users of FPIs (for instance) to >hex-encode 50+ character ascii strings stil strikes me a ludicrous. But >once we allow ASCII, we have to meet the questions of the international >community. My feeling is that transcribability is a more serious problem >than the UTF-8 advocates are admitting. On the other hand, if the reference >string is the %-encoded UTF-8 value, then we should be OK for >transcribability. The issue of user-friendly software that hides %-encoding >is not part of the protocol, so its _possibility_ shouldn't unduly >influence us. Although UTF-8 is not perfect, it is by far the closest system now existing that represents most characters in use today. If we are to permit but not require that URNs have human meanings, and we are not going to force grandfathered namespaces to translate their IDs, then UTF-8 is likely the best choice for a character encoding scheme, with the reference string as the %-encoded UTF-8 value. ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA25197 for urn-ietf-out; Thu, 14 Nov 1996 12:08:10 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA25192 for ; Thu, 14 Nov 1996 12:08:08 -0500 Received: from CS.BU.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20785 (mail destined for urn-ietf@services.bunyip.com); Thu, 14 Nov 96 12:08:06 -0500 Received: by cs.bu.edu (8.6.10/Spike-2.1) id MAA27144; Thu, 14 Nov 1996 12:07:59 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Nov 1996 12:13:21 -0500 To: urn-ietf@bunyip.com From: dgd@cs.bu.edu (David G. Durand) Subject: Re: [URN] Re: I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: dgd@cs.bu.edu (David G. Durand) Errors-To: owner-urn-ietf@bunyip.com At 5:17 PM 11/13/96, Keith Moore wrote: >was imprecise and possibly misleading. A better statement is: > > "URNs aren't intended to serve as human meaningful names". > >Keith This means the human meaningfulness is not a requirement of URNs. This is probably good. But it is _not_ as you have claimed, a requirement that URNs _not_ be human-readable. As I have repeatedly pointed out, compatibility with existing persistent namespaces will require that at least some human-meaningful names be included. The notion of requiring users of FPIs (for instance) to hex-encode 50+ character ascii strings stil strikes me a ludicrous. But once we allow ASCII, we have to meet the questions of the international community. My feeling is that transcribability is a more serious problem than the UTF-8 advocates are admitting. On the other hand, if the reference string is the %-encoded UTF-8 value, then we should be OK for transcribability. The issue of user-friendly software that hides %-encoding is not part of the protocol, so its _possibility_ shouldn't unduly influence us. We can define the standard as %-encoded UTF-8, and if people implement this other ways, they are implementing convenience features in the interface: the software will always have the %-encoded URN available. This might hurt me in typing in Japanese URNs from a Japanese-language paper publication, but the scenarios where non-Japanese speakers will be doing such tasks are pretty contrived. I think Martin's argument that if we let in ASCII, we have let the rest in, has a lot of merit. And I _know_ that one of the best candidates for initial URN namespace (FPIs) is ASCII-subset based. So we need to find a harmless way of having a unique, 7-bit clean bytesequence. UTF-8, with %encoding for characters over 127, is a unique transcribable byte sequence capable of grandfathering all of the namespaces we have discussed. As long as we require naming authorities to use well-defined Unicode names, we can even handle non-Unicode characters, by making authorities that need them define a policy for their application of the private-use area. consistent use of private use characters will guarantee uniqueness, so we are all set! -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA25166 for urn-ietf-out; Thu, 14 Nov 1996 12:01:48 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA25161 for ; Thu, 14 Nov 1996 12:01:44 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20742 (mail destined for urn-ietf@services.bunyip.com); Thu, 14 Nov 96 12:01:31 -0500 Message-Id: <9611141701.AA20742@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Thu Nov 14 11:00 CST 1996 From: "Ryan Moats" To: "Ron Daniel" , "Toby Speight" Cc: "urn-ietf@bunyip.com" Date: Thu, 14 Nov 96 11:02:05 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] UTF encodings - why UTF-8? (was: I18N does not belong ...) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Thu, 14 Nov 1996 08:37:03 -0700, Ron Daniel wrote: >Thus spoke Toby Speight (at least at 02:48 PM 11/14/96 +0000) > >>Would somebody care to explain to me why this double encoding is >>preferable to, say, UTF-7, > >We looked at UTF-7 awhile back. Our conclusion at that time was that >UTF-8 would be preferable since UTF-7 would make us add '+' to the list >of reserved characters and, depending on the context, would affect the >handling of the '-' character as well. > Ron is correct. We will probably already have % encoding and it didn't seem to net us much to add '+' encoding as well. Sorry to be lagging, but keeping up with mail and my real job is starting to be difficult... Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA24415 for urn-ietf-out; Thu, 14 Nov 1996 11:32:08 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA24410 for ; Thu, 14 Nov 1996 11:32:06 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20551 (mail destined for urn-ietf@services.bunyip.com); Thu, 14 Nov 96 11:31:25 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00775-0@josef.ifi.unizh.ch>; Thu, 14 Nov 1996 17:30:29 +0100 Subject: Re: [URN] Re: I18N does not belong in URNs To: moore@cs.utk.edu Date: Thu, 14 Nov 1996 17:30:27 +0100 (MET) Cc: stu_weibel@oclc.org, urn-ietf@bunyip.com In-Reply-To: <199611132012.PAA20767@ig.cs.utk.edu> from "Keith Moore" at Nov 13, 96 03:12:48 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2997 From: Martin J Duerst Message-Id: <"josef.ifi..483:14.10.96.16.30.30"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore writes: >But when people propose adding I18N support to URNs to make them human >meaningful, I view this as adding a great deal of extra complexity in >an attempt to make URNs solve a completely different problem than they >were designed to solve. (And given the history of various "information >infrastructure" groups at failing to narrow their scope to a problem that's >solvable in finite time, I get very nervous.) I have stopped proposing adding i18n support for meaningfulness. This argument is not necessary. But I think it is necessary that the same amount of meaningfulness is allowed or disallowed to users of any language around the globe. This is only guaranteed by either radically restricting the character set or completely opening it up. >By contrast, when people propose adding I18N support to URNs to allow them >to incorporate URN-like names that happen to include one or two non-universal >characters, I wonder things like "Is it really worth the complexity?" The complexity is low. The only thing you are required to do in the present proposal is convert between 8-bit and %HH form of URNs (or normalize mixed forms to one or the other). 8-bit and %HH forms can easily be distinguished. Conversion is easy. Comparison is easy. If we change the proposal to say that we only have the %HH form, then everything is even much more easy. Presentation as a Unicode string with nice characters is an user interface issue. Either the browser or the OS/Window system will implement it anyway (to some degree), or you won't do it. >and >"Which is more important, global scope and transcribability and single >encoding or the ability to easily grandfather all URN-like systems?" If we restrict URNs to the %HH form (disallow 8-bit), but still define how the %HH-encoded octets represent characters, we indeed would get both. Existing namespaces could easily be grandfathered in a straight- forward way, and we would have a single, transcribable encoding. Even if we stay with the current syntax proposal, the encoding issue only gets slightly more complex (see above), and average transcribability will probably be improved. As I have explained in a previous message, transcribability is a relative issue. If we look at examples such as transcribing a Japanese account number on a payment slip to an URN and type it in, allowing the majority of Japanese users to do it the way they are used and not forcing them to do namespace- specific calculations on paper is a big win. This win won't in any way disadvantage a Western user in this case; it will still be easier for him/her to try to select the character printed on the payment slip directly with an point-and-click interface than to try to figure out its namespace-specific coding. Global scope, of course, depends on the interpretation of the word "global". I would prefer if this would be done in the sense of Global Diversity and not in the sense of Global Common Denominator :-). Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA24054 for urn-ietf-out; Thu, 14 Nov 1996 10:59:21 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA24033 for ; Thu, 14 Nov 1996 10:58:47 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20260 (mail destined for urn-ietf@services.bunyip.com); Thu, 14 Nov 96 10:58:05 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00675-0@josef.ifi.unizh.ch>; Thu, 14 Nov 1996 16:50:15 +0100 Subject: Re: [URN] UTF encodings - why UTF-8? (was: I18N does not belong ...) To: tms@ansa.co.uk (Toby Speight) Date: Thu, 14 Nov 1996 16:50:14 +0100 (MET) Cc: Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: from "Toby Speight" at Nov 14, 96 02:48:03 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3165 From: Martin J Duerst Message-Id: <"josef.ifi..285:14.10.96.15.50.26"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Toby Speight wrote: >Martin> The mapping from the large character set in (2) to the small >Martin> character set in (1) has to be defined. The one and only >Martin> existing and reasonable proposal for this is to use UTF-8 and >Martin> combined with some octet encoding such as %HH. > >Would somebody care to explain to me why this double encoding is >preferable to, say, UTF-7, whose motivation > says: > >UTF-7> ... using UTF-FSS together with the Quoted-Printable content >UTF-7> transfer encoding of MIME represents US-ASCII characters in one >UTF-7> octet, but other characters may require up to nine octets. > >[MIME Q-P is almost the same as %HH, only with a different escape >char. UTF-7 also has the advantage of leaving %HH free for encoding >reserved characters, if they exist] Sorry, I was maybe a little too definitive when I said "only existing and reasonable". And the main disadvantage of using UTF-8 is indeed that URNs may expand in length. This issue was discussed in this list before. I have also discussed the issue of UTF-7 vs. UTF-8 (for URLs in that case) with the creator of UTF-7, David Goldsmith, recently. Under the premise that we would prefer URN syntax to be reasonably compatible with URL syntax (not reinvent the weel, reuse code and functionality, not confuse implementors and users), UTF-7 has serious problems: - A "+", the character introducing an UTF-7 sequence, is allowed in scheme names and some URLs (in particular Gopher+). I also seemed to remember a convention that it was used to escape a space, but I didn't find that in RFC 1738. - A "/", used in UTF-7, is a very significant character in URLs, and would probably have to be replaced, creating a UTF-7 variant. The basic problem is that UTF-8 is fully compatible with ASCII, whereas UTF-7 is not. An additional problem is that UTF-7 can only represent characters of UCS-4 up to 0x10FFFF, using UTF-16. The full set goes up to 0x7FFFFFFF. Currently, this is a theoretical difference, but one never knows. As for size, the difference may not be that large: max hex UTF-7 UTF-8 UTF-8 value length length length raw %HH 0x0000007F 1 or more 1 1 0x000007FF 8/3 + 2 6 0x0000FFFF 8/3 + 3 9 0x0010FFFF 16/3 + 4 12 0x001FFFFF -- 4 12 0x03FFFFFF -- 5 15 0x7FFFFFFF -- 5 15 As an example, to encode a single character from extended Latin (Latin-1,...), Cyrillic, Greek, Arabic, Hebrew, or Armenian, one needs a "+", three positions for Base64, and usually a "-" at the end, which makes 5 positions as long as we don't have to escape "+". If "+" has to be escaped in its "start UTF-7" meaning, it will be more. UTF-8 needs 6 positions in %HH form. For URNs in particular (not for URLs), we can assume that the occurrence of characters outside ASCII is rather low. This helps making UTF-8 look somewhat better. Even if we decide that an URN always has to be in %HH form, and that anything else would just be GUI sugar, they can alwasy be transparently converted to raw form e.g. for storage in a database or for transmission in a suitably designed protocol. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA23913 for urn-ietf-out; Thu, 14 Nov 1996 10:28:59 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA23908 for ; Thu, 14 Nov 1996 10:28:57 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20045 (mail destined for urn-ietf@services.bunyip.com); Thu, 14 Nov 96 10:28:55 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id IAA05578; Thu, 14 Nov 1996 08:28:49 -0700 (MST) Message-Id: <2.2.32.19961114153703.006de064@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 14 Nov 1996 08:37:03 -0700 To: Toby Speight From: Ron Daniel Subject: Re: [URN] UTF encodings - why UTF-8? (was: I18N does not belong ...) Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Toby Speight (at least at 02:48 PM 11/14/96 +0000) >Would somebody care to explain to me why this double encoding is >preferable to, say, UTF-7, We looked at UTF-7 awhile back. Our conclusion at that time was that UTF-8 would be preferable since UTF-7 would make us add '+' to the list of reserved characters and, depending on the context, would affect the handling of the '-' character as well. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA23710 for urn-ietf-out; Thu, 14 Nov 1996 09:51:01 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA23690 for ; Thu, 14 Nov 1996 09:49:58 -0500 Received: from yscydion.ansa.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19709 (mail destined for urn-ietf@services.bunyip.com); Thu, 14 Nov 96 09:49:56 -0500 Received: by yscydion.ansa.co.uk; Thu, 14 Nov 96 14:48:05 GMT Received: by plato.ansa.co.uk; Thu, 14 Nov 96 14:48:04 GMT To: Martin J Duerst Cc: Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: [URN] UTF encodings - why UTF-8? (was: I18N does not belong ...) References: <"josef.ifi..786:14.10.96.13.51.59"@ifi.unizh.ch> From: Toby Speight Mime-Version: 1.0 (generated by *modified* tm-edit 7.43) Content-Type: text/x-pgp; charset=US-ASCII Date: 14 Nov 1996 14:48:03 +0000 In-Reply-To: Martin J Duerst's message of Thu, 14 Nov 1996 14:51:52 +0100 (MET) Message-Id: Lines: 42 Organization: ANSA - APM Ltd. X-Mailer: Gnus v5.3/Emacs 19.32 X-Author-Info: X-Pgp-Id: 0xABBDC46D (from servers or author-info) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Toby Speight Errors-To: owner-urn-ietf@bunyip.com -----BEGIN PGP SIGNED MESSAGE----- Martin> Martin J Duerst >>>>> In article <"josef.ifi..786:14.10.96.13.51.59"@ifi.unizh.ch>, >>>>> Martin wrote: Martin> What we need for URNs is at least: Martin> (1) URNs are represented by characters (on paper, in ASCII,...) Martin> from the same set as used in URLs. Martin> (2) URNs (in general) represent characters (from UCS-4). Martin> The mapping from the large character set in (2) to the small Martin> character set in (1) has to be defined. The one and only Martin> existing and reasonable proposal for this is to use UTF-8 and Martin> combined with some octet encoding such as %HH. Would somebody care to explain to me why this double encoding is preferable to, say, UTF-7, whose motivation says: UTF-7> ... using UTF-FSS together with the Quoted-Printable content UTF-7> transfer encoding of MIME represents US-ASCII characters in one UTF-7> octet, but other characters may require up to nine octets. [MIME Q-P is almost the same as %HH, only with a different escape char. UTF-7 also has the advantage of leaving %HH free for encoding reserved characters, if they exist] -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBMosxHudsuUurvcRtAQErWQL+MmRoOeUqbLYzqsi7oXCUKx5gm6ix9LaH 9zeo7bu7Ex7qJ/lJB5lmyNlHGyNLFj7ZU+d2Fl07pcu6g/lCEixnOoZQD1ivLILa Ktk+WzVE6XzvOScVJVFVdIS1PBZBdFsY =xyYt -----END PGP SIGNATURE----- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA23126 for urn-ietf-out; Thu, 14 Nov 1996 08:55:31 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA23116 for ; Thu, 14 Nov 1996 08:54:45 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19360 (mail destined for urn-ietf@services.bunyip.com); Thu, 14 Nov 96 08:54:05 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00564-0@josef.ifi.unizh.ch>; Thu, 14 Nov 1996 14:51:53 +0100 Subject: Re: [URN] I18N does not belong in URNs To: Dirk.vanGulik@jrc.it Date: Thu, 14 Nov 1996 14:51:52 +0100 (MET) Cc: FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <9611141038.AA01418@ jrc.it> from "Dirk vanGulik" at Nov 14, 96 11:38:37 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 10713 From: Martin J Duerst Message-Id: <"josef.ifi..786:14.10.96.13.51.59"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Dirk.vanGulik wrote: >> Dirk.vanGulik wrote: > >> >Or they use a naming scheme dependent interpretation. You could for >> >example simply limit the representation of the URN to the glyphs >> >A-Z, 0-9 and say the dot, dash, and colon. >> >> Too much in favor of English users (+Hawaiian and Suwaheli)! > >Well as a dutch person working in italy in a swiss building; I >can quite live with it :-) No just kidding, but seriously why >does this 'favour' ? And where does it come in ? This has been mentionned before: name spaces in the English-speaking world usually contain letters and numbers, and their mapping to the URN syntax you propose above would be straightforward. Neither the designer of an URN namespace nor the actual users would have to think much about it. Name spaces in countries that use other scripts quite often contain letters in these scripts. Mapping to the URN syntax you propose above would not directly be possible. Namespace designers would invent their own schemes, and namespace users would have to learn all kinds of different conventions for different namespaces. I hope that you see that this favors English-speaking users (and to a lesser extent other users of the Latin script). >> > I recently came across a specific scheme, say 'crdis' which has a lot of >> > LocalControlIdentfiers which can (only be fully) expressed in 2-byte octets. >> > This obviously gave problems as some of our z39.50 servers and HTTP/URN >> > resolving code did not quite like this. A pragmatic solution was to simply >> > base64 encode the identfication string. > >> > A specialist GUI could now base64-decode the string to arrive >> > at something meaningfull for a human. But it does not have to. >> > And it does keep things simple. > >> I have mentionned earlier the possibility that some namespaces may >> contain arbitrary data, as opposed to characters, and I have therefore > >Hold on, I was trying to convey that these strings did _INDEED_ contain >meaningfull text; You only said they contained 2-byte octets. This could be the resource number of a system icon, or whatever. >auctually the various 'strings' where short >titles in the 19 european languages; carefully protected. Probably you have to explain more details for us to get the full picture of this example. Anyway, if they originally were short titles, i.e. character strings, why invent a complicated name space specific mapping to URNs? Why not just define a default mapping (i.e. UTF-8 + %HH) for all possible characters (i.e. the full ISO 10646 UCS-4)? >The same could be said of my phone number > > +39 332 78 0014 > >Which tells a local here that it is me, living in Ispra(78), near Varse >(33*)in italy(39). But for most people those digits make no sense all, >nor have to. And my local phone technician might even tell me more by >just looking at it. We are not really talking about meaning here. What we are talking about is the mapping of existing namespaces (however meaningful or meaningless they are to whoever) to URNs. >> >I really would like to roll up the charset discussion; I agree that for a lot >> >of scheme's, in particular those to be grandfathered in, one will need very >> >flexible encodings. > >> They need to be very flexible in the sense that they have to be >> able to accomodate a very large set of characters, and something >> else than characters in some cases. > >Well, that is a requirement I do not find in the functional RQ RFC at >all. Should that be re-written ? I agree that publishers and maintainers >might like to 'overload' the content; but that is a different issue. The RQ RFC clearly states that we have to be able to grandfather existing namespaces. We can do this mainly in two ways: - Not defining a mapping from arbitrary characters of the universal character set to our URN syntax, and just tell namespace designers: Solve the problem for yourself. In theory, the grandfathering requirement is satisfied (even if we restrict syntax to only two different characters). The problem is that namespace implementors have to come up with their own ideas of how to map characters to URNs, resulting in chaos and inconvenience for everybody. With this, we get rid of the grandfathering requirement by delegating it, but we do not really do our job. - Defining a mapping from the characters of the universal character set (UCS) to URN syntax. This will make implementing existing namespaces in URNs much easier. We really deal with the grandfathering requirement, we don't just pass it around like a hot potato (it's not hot and quite easy to handle anyway). We seriously do our job as well as we are possibly able to do it. We avoid chaos where there is absolutely no need for chaos. >Hmm, I think we have a slight terminology clash; much like the problems >we have had with the URL rfc. There are several layers, which their >own dimensions. In URLs (correct me if I am wrong Larry) this is solved >by saying that the acutal URL is an octet-stream. These 8-bit encoded >values are all there is. However by 'pure coincidence' they can be >treated as indexes into a charset such as US-Asicc or latin-1 and >actually yeild something which humans can interpret quite easily. > >But for example the first 5 values (say http:) are not the glyph >'h', 't', p'p and ':' but the values 68747470 or 4854545. (Upper/ >lowercase), You got it the wrong way round; please reread RFC 1738 if you don't believe me. URLs are defined as strings of characters that can exist on paper or iside a computer (in ASCII or EBCDIC or whatever). This means that in the URL RFC, the "is" is used for the representING side. The representED side are indeed octets that appear in a protocol. The fact that you got terminology wrong while you did not say much that was actually wrong (if one is restricted to ASCII, which is the case more often than not) shows that writing what URL/Ns "are" can lead to a lot of confusion. The fact that you mention several layers also indicates that it is dangerous to make one of these layers special by using the verb "to be". Different people tend to identify different layers as the most important one. In my terminology, RFC 1738 says: (1) URLs are represented by characters (on paper, in ASCII, in EBCDIC, or whatever). (2) URLs represent octets of some protocols. RFC 1738 also defines the mapping from the octets in (2) to the characters in (1). What we need for URNs is at least: (1) URNs are represented by characters (on paper, in ASCII,...) from the same set as used in URLs. (2) URNs (in general) represent characters (from UCS-4). The mapping from the large character set in (2) to the small character set in (1) has to be defined. The one and only existing and reasonable proposal for this is to use UTF-8 and combined with some octet encoding such as %HH. >So what I was saying is that the URN is an octet stream; and the >allowed values are from ox30 to 0x39, 0x41--0x5a etc. Which happen >to represent indexes into latin-1, UTF-8 or ascii. But not EBCDIC. For those that have difficulties separating the different layers, and have difficulties immagining something such as Japanese, there is an easy trick: Think about EBCDIC. If you don't at least think about how to handle things in EBCDIC, the chances are big that you will forget some important aspect of the problem. >Now a clever administrator (and a clever GUI) can use something like >base64 to get a nice UniCode string in. We don't want the administrator to have to come up with such a mapping, and we don't want or need to have many different mappings. By just a little bit of effort from our side, we don't need administrators to be overly 'clever', and we need GUIs to only support exactly one kind of presentation conversion (which will really soon be available in the average Web browser) instead of dozens, hundreds, or thousands of them (which no Web browser will ever support). I could live with the definition that an URN "is" an octet stream if we add (as we have in the current version of the syntax draft) a specification for how characters from the universal character set (UCS) should be encoded into URN octets. >> > 3. And keep a few chars (say the %) in stock, for the future. > >> > 4. And remember, one can always make something like a next generation >> > URN+:das:asd which can only be transcribed properly using say UTF8. > >> There is absolutely no need to wait any longer for UTF-8. > >Well, I can agree; but not for the premisse; I do not see the need >for the charset flexibilit. I know people can get quite religious about >their names; so you have a point that we should be flexible to accomodate, >but on the other hand it does make implementation harder whilst the >functionality does not increase a bit. It's not about peoples' names, unless you consider that a namespace suitable for URNs. It's about actually existing namespaces that contain characters beyond the set you are proposing. As for implementation, you are free to provide your browser with a %HH interface only. For the current syntax draft, you would have to add a routine that checks for the occurrence of 8-bit bytes, and you would have to convert them to %HH before comparison. That's about five lines of C code, not really a hard thing to do. As for implementing a user interface that allows input and rendering of the full universal character set (UCS), that indeed is quite some work, but (1) there is no need to provide full implementation of all characters, (2) as far as it is needed, it will be done anyway in the average browser because of requirements from other protocols and formats (such as HTML), and (3) implementing this is still tremendously simpler than implementing GUIs for all the 'clever' encoding systems that all those 'clever' administrators have come up with. >> All your requirements can be fulfilled by: > >> - Allowing non-character namespaces to create their own non UTF-8 encodings >> (as I have suggested previously). >> - Require that internally, all 8-bit octets resulting from UTF-8 encoding >> of characters beyond ASCII (+some in ASCII) be encoded with >> %HH, so that there is no 8-bit from of URNs. > >> Although I have good reasons to think that the second point is not needed, >> I could live with it. But giving up a convention such as UTF-8 to map >> arbitrary characters in namespaces to URNs would be a great loss. > >Well I think I do not see those requirements; but perhaps we should look >at the RQ RFC again, to see what possibly is missing. The above requirements are possible refinements of the general requirements for grandfathering and transcribability. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA21979 for urn-ietf-out; Thu, 14 Nov 1996 05:39:44 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA21973 for ; Thu, 14 Nov 1996 05:39:37 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18908 (mail destined for urn-ietf@services.bunyip.com); Thu, 14 Nov 96 05:39:29 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA12722; Thu, 14 Nov 96 11:44:01 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA01418; Thu, 14 Nov 1996 11:38:37 +0100 Date: Thu, 14 Nov 1996 11:38:37 +0100 From: Dirk vanGulik Message-Id: <9611141038.AA01418@ jrc.it> To: Dirk.vanGulik@jrc.it, mduerst@ifi.unizh.ch Subject: Re: [URN] I18N does not belong in URNs Cc: FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Dirk vanGulik Errors-To: owner-urn-ietf@bunyip.com > Dirk.vanGulik wrote: > >Or they use a naming scheme dependent interpretation. You could for > >example simply limit the representation of the URN to the glyphs > >A-Z, 0-9 and say the dot, dash, and colon. > > Too much in favor of English users (+Hawaiian and Suwaheli)! Well as a dutch person working in italy in a swiss building; I can quite live with it :-) No just kidding, but seriously why does this 'favour' ? And where does it come in ? > > I recently came across a specific scheme, say 'crdis' which has a lot of > > LocalControlIdentfiers which can (only be fully) expressed in 2-byte octets. > > This obviously gave problems as some of our z39.50 servers and HTTP/URN > > resolving code did not quite like this. A pragmatic solution was to simply > > base64 encode the identfication string. > > A specialist GUI could now base64-decode the string to arrive > > at something meaningfull for a human. But it does not have to. > > And it does keep things simple. > I have mentionned earlier the possibility that some namespaces may > contain arbitrary data, as opposed to characters, and I have therefore Hold on, I was trying to convey that these strings did _INDEED_ contain meaningfull text; auctually the various 'strings' where short titles in the 19 european languages; carefully protected. So we are not talking arbitrary strings here; although they *function* as an arbritary handle. But for the expert their actual content conveys more than just a number. The same could be said of my phone number +39 332 78 0014 Which tells a local here that it is me, living in Ispra(78), near Varse (33*)in italy(39). But for most people those digits make no sense all, nor have to. And my local phone technician might even tell me more by just looking at it. > suggested that the requirement that all URNs be UTF-8 should be > relaxed. I have given the data: URL as an example. Here we have > an obvious second examlpe. > > >I really would like to roll up the charset discussion; I agree that for a lot > >of scheme's, in particular those to be grandfathered in, one will need very > >flexible encodings. > They need to be very flexible in the sense that they have to be > able to accomodate a very large set of characters, and something > else than characters in some cases. Well, that is a requirement I do not find in the functional RQ RFC at all. Should that be re-written ? I agree that publishers and maintainers might like to 'overload' the content; but that is a different issue. > But there is absolutely no reason to have arbitrary flexibility > for those cases where indeed characters have to be represented. > For this case, it is much easier to specify that UTF-8 be used > (optionally or even mandatorily with %HH encoding). > >But the internet transfer mechanisms are not quite up to > >that yet. So I would suggest: > > 1. Limit the URNs to just a few chars (along the lines of DNS) This > > also makes comparing URNs easy. > As for the character set *representing* URNs, I can agree. This would > basically mean that everything has to be %HH encoded. Hmm, I think we have a slight terminology clash; much like the problems we have had with the URL rfc. There are several layers, which their own dimensions. In URLs (correct me if I am wrong Larry) this is solved by saying that the acutal URL is an octet-stream. These 8-bit encoded values are all there is. However by 'pure coincidence' they can be treated as indexes into a charset such as US-Asicc or latin-1 and actually yeild something which humans can interpret quite easily. But for example the first 5 values (say http:) are not the glyph 'h', 't', p'p and ':' but the values 68747470 or 4854545. (Upper/ lowercase), So what I was saying is that the URN is an octet stream; and the allowed values are from ox30 to 0x39, 0x41--0x5a etc. Which happen to represent indexes into latin-1, UTF-8 or ascii. Now a clever administrator (and a clever GUI) can use something like base64 to get a nice UniCode string in. > > 2. Allow, or perhaps even force, each registered naming scheme > > to suggest a possible encoding/escape sequencing to derive > > nice human names from the URN. This can be used by the more > > advanced GUIs. > The greatest majority of naming schemes will have identical problems, > namely how to represent characters in namespaces. And a single and > very simple GUI can provide nice human representations for these > cases (modulo available fonts). And a single and widely applicable > convention should be used by all naming schemes dealing with > characters. > > 3. And keep a few chars (say the %) in stock, for the future. > > 4. And remember, one can always make something like a next generation > > URN+:das:asd which can only be transcribed properly using say UTF8. > There is absolutely no need to wait any longer for UTF-8. Well, I can agree; but not for the premisse; I do not see the need for the charset flexibilit. I know people can get quite religious about their names; so you have a point that we should be flexible to accomodate, but on the other hand it does make implementation harder whilst the functionality does not increase a bit. > >I know that such an encoding essentially wastes space; but that is a tradeoff > >I am willing to make for simplfied storage, encoding and comparing. > All your requirements can be fulfilled by: > - Allowing non-character namespaces to create their own non UTF-8 encodings > (as I have suggested previously). > - Require that internally, all 8-bit octets resulting from UTF-8 encoding > of characters beyond ASCII (+some in ASCII) be encoded with > %HH, so that there is no 8-bit from of URNs. > Although I have good reasons to think that the second point is not needed, > I could live with it. But giving up a convention such as UTF-8 to map > arbitrary characters in namespaces to URNs would be a great loss. Well I think I do not see those requirements; but perhaps we should look at the RQ RFC again, to see what possibly is missing. Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id DAA20991 for urn-ietf-out; Thu, 14 Nov 1996 03:09:06 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id DAA20986 for ; Thu, 14 Nov 1996 03:09:03 -0500 Received: from aun.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18566 (mail destined for urn-ietf@services.bunyip.com); Thu, 14 Nov 96 03:09:01 -0500 Received: from dale.uninett.no by aun.uninett.no with SMTP (PP); Thu, 14 Nov 1996 09:08:47 +0100 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id XAA03343; Wed, 13 Nov 1996 23:42:34 +0100 From: Harald.T.Alvestrand@uninett.no To: Martin J Duerst Cc: Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] Please avoid "URNs are" In-Reply-To: Your message of "Wed, 13 Nov 1996 19:16:55 +0100." <"josef.ifi..391:13.10.96.18.16.57"@ifi.unizh.ch> Content-Id: <3340.847924954.1@dale.uninett.no> Date: Wed, 13 Nov 1996 23:42:34 +0100 Message-Id: <3341.847924954@dale.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com Martin, I very deliberately used "URNs are". IMHO, we *have* to have agreement on what the basic element of an URN is; then we can encode to our hearts' content. The phrase "X is represented by" presupposes (in my mind) that X *is* something ("das ding an sich") that can be represented by something else ("das ding f=FCr mich") (apologies to Kant for mutilating his philosophy!); the representation of the object presupposes the existence in some "space of ideas" of that object. For URNs, I believe that we want all representations of an URN to be such that a computer can check them for equality; this, I believe, is best achieved by saying that there has to exist some "ideal URN" in a form that is representable inside a computer, and that all representations can be turned back into this "ideal representation", whatever that is. So yes, I believe that the URN syntax document has to say "URNs are". Harald A (for Amateur-philosopher :-) Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA14254 for urn-ietf-out; Wed, 13 Nov 1996 17:18:54 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA14249 for ; Wed, 13 Nov 1996 17:18:52 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16245 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 17:18:45 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id RAA23489; Wed, 13 Nov 1996 17:17:16 -0500 (EST) Message-Id: <199611132217.RAA23489@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Terry Allen Cc: moore@cs.utk.edu, stu_weibel@oclc.org, urn-ietf@bunyip.com Subject: Re: [URN] Re: I18N does not belong in URNs In-Reply-To: Your message of "Wed, 13 Nov 1996 13:30:23 PST." <199611132130.NAA19036@ishtar.fsc.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Nov 1996 17:17:16 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > Keith writes: > | As to the former statement, in case there's any doubt as to "URNs aren't > | supposed to be human meaningful", I refer interested parties to the group's > | charter > | (http://www.ietf.org/html.charters/urn-charter.html) and to RFC 1737, > | the requirements of which the charter incorporates by reference. > > Please cite specific passages in support of your position. In writing my response to this note (which was just sent to Terry and Stu, but I'll send a copy to anyone who asks), I realized that my statement "URNs aren't supposed to be human meaningful" was imprecise and possibly misleading. A better statement is: "URNs aren't intended to serve as human meaningful names". Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA13977 for urn-ietf-out; Wed, 13 Nov 1996 16:55:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA13972 for ; Wed, 13 Nov 1996 16:55:34 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15665 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 16:53:47 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id QAA21609; Wed, 13 Nov 1996 16:53:22 -0500 (EST) Message-Id: <199611132153.QAA21609@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Terry Allen Cc: moore@cs.utk.edu, stu_weibel@oclc.org, urn-ietf@bunyip.com Subject: Re: [URN] Re: I18N does not belong in URNs In-Reply-To: Your message of "Wed, 13 Nov 1996 13:30:23 PST." <199611132130.NAA19036@ishtar.fsc.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Nov 1996 16:53:22 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > Keith writes: > | As to the former statement, in case there's any doubt as to "URNs aren't > | supposed to be human meaningful", I refer interested parties to the group's > | charter > | (http://www.ietf.org/html.charters/urn-charter.html) and to RFC 1737, > | the requirements of which the charter incorporates by reference. > > Please cite specific passages in support of your position. I'll cite them in private mail. I think the list has seen enough of this. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA13775 for urn-ietf-out; Wed, 13 Nov 1996 16:32:54 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA13770 for ; Wed, 13 Nov 1996 16:32:35 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15176 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 16:32:23 -0500 Received: from magenta.acl.lanl.gov (rdaniel@magenta.acl.lanl.gov [128.165.147.153]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id OAA19022 for ; Wed, 13 Nov 1996 14:32:12 -0700 (MST) From: "Ronald E. Daniel" Received: (rdaniel@localhost) by magenta.acl.lanl.gov (8.7.5/8.6.4) id OAA19320 for urn-ietf@bunyip.com; Wed, 13 Nov 1996 14:32:11 -0700 (MST) Date: Wed, 13 Nov 1996 14:32:11 -0700 (MST) Message-Id: <199611132132.OAA19320@magenta.acl.lanl.gov> To: urn-ietf@bunyip.com Subject: [URN] next version of HTTP Conventions draft Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ronald E. Daniel" Errors-To: owner-urn-ietf@bunyip.com Here is the revised version of the draft on "Conventions for the Use of HTTP for URN Resolution". It changes the convention from GET / HTTP/1.x to GET /uri-res// HTTP/1.x Some other changes have been made as a result of feedback from the list. I'll send it to the ID editors next week after people on this list have had another chance to comment on it. Ron Daniel ----------------- INTERNET DRAFT Ron Daniel draft-daniel-http-00.txt Los Alamos National Laboratory 13 Nov, 1996 Conventions for the Use of HTTP for URN Resolution [Edits made since last version was sent to the list: 1) Initial "/" 2) Additional info on status codes. 3) Accept header may limit N2Rs results 4) multipart/alternative as type for N2Rs results 5) text/uri-list instead of text/plain, use Accept: to allow text/http 6) GET /uri-res// ] Status of this Memo =================== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft expires 15 May, 1997. Abstract: ========= The URN-WG was formed to specify persistent, location-independent names for network accessible resources, and resolution mechanisms to retrive the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal. That proposal does not get the client software all the way from the URN to the resource. Instead, it gets the client from a URN to a "resolver", which is a system that can then tell the client where the resource is. The NAPTR draft defines a "resolution protocol" to be the protocol used to speak to a resolver in order to obtain the resource, its location(s), or other information about the resource. The NAPTR proposal allows different resolution protocols to be used for commuicating with resolvers. This draft establishes conventions for encoding URN resolution requests and responses in HTTP 1.0 (and 1.1) requests and responses. The primary goal of this draft is to define a convention that is simple to implement and will allow existing HTTP servers to easily add support for URN resolution. We expect that the resolution databases that arise will be useful when more sophisticated resolution protocols are developed later. 1.0 Introduction: ================== The NAPTR draft[1] describes a way of using DNS to locate resolvers for URIs. That draft provides places to specify the "resolution protocol" spoken by the resolver, as well as the "resolution services" it offers. As of this writing, the "resolution protocols" allowed by the NAPTR draft are HTTP, RCDS, HDL, and RWHOIS. (That list is expected to grow over time). The NAPTR draft also lists a variety of resolution services, such as N2L (given a URN, return a URL); N2R (Given a URN, return the named resource), etc. This draft specifies the conventions to follow to encode resolution service requests in the HTTP protocol, allowing widely available HTTP daemons to serve as URN resolvers. The reader is assumed to be familiar with the HTTP/1.0 [2] and 1.1 [3] specifications. 2.0 General Approach: ===================== The general approach used to encode resolution service requests in HTTP is quite simple: GET /uri-res// HTTP/1.0 For example, if we have the URN "cid:foo@huh.com" and want a URL, we would send the request: GET /uri-res/N2L/cid:foo@huh.com HTTP/1.0 Because of the character set limitations on URIs, we might wish to encode the '@' character as its hex equivalent, thus the request would be GET /uri-res/N2L/cid:foo%40huh.com HTTP/1.0 The request could also be encoded as an HTTP 1.1 request. This would look like: GET /uri-res/N2L/cid:foo%40huh.com HTTP/1.1 Host: Handling these requests on the server side is easy to implement in a number of ways. The N2L request could be handled by a CGI script that took the incoming URN, looked it up in a database, and returned the URL as an HTTP redirect. Service requests like N2R or N2C could be set up so that the daemon answered the request by returning files out of N2R/ and N2C/ directories, or they could be handled by a script. One caveat should be kept in mind. The "urn:" prefix is still the subject of controversy, so some URN documents advocate treating it as optional. HTTP resolvers MUST return identical results for URIs that do and do not contain the "urn:" prefix. For example, the two request below must return identical results: GET /uri-res/N2L/cid:foo%40huh.com HTTP/1.0 GET /uri-res/N2L/urn:cid:foo%40huh.com HTTP/1.0 Responses from the HTTP server follow standard HTTP practice. Status codes, such as 200 (OK) or 404 (Not Found) shall be returned. The normal rules for determining cachability, negotiating formats, etc. apply. 3.0 Service-specific details: ============================= This section goes through the various resolution services established in the URN Framework draft [4] and states how to encode each of them, how the results should be returned, and any special status codes that are likely to arise. Unless stated otherwise, the HTTP requests are formed according to the simple convention above, either for HTTP/1.0 or HTTP/1.1. The response is assumed to be an entity with normal headers and body unless stated otherwise. (N2L is the only request that does not return a body). 3.1 N2L (URN to URL): ---------------------- The request is encoded as above. The URL MUST be returned in a Location: header for the convienience of the most common case of wanting the resource. A 30X status line SHOULD be returned. HTTP/1.1 clients should be sent the 303 status code. HTTP/1.0 clients should be sent the 302 (Moved temporarily) status code unless the resolver has particular resons for using 301 (moved permanently) or 304 (not modified) codes. 3.2 N2Ls (URN to URLs): ------------------------ The request is encoded as above. The result is a list of 0 or more URLs. The Internet Media Type (aka ContentType) of the result may be negotiated using standard HTTP mechanisms if desired. At a minimum the resolver should support the text/uri-list media type. (See Appendix A for the definition of this media type). That media type is suitable for machine-processing of the list of URLs. Resolvers may also return the results as text/html, text/plain, or any other media type they deem suitable. No matter what the particular media type, the result SHOULD contain the following information: 1) An optional comment giving the original URN 2) An integer giving the number of URLs in the response 3) The URLs in the response, one per line. These shall be encoded according to the URI specification [5]. If the client has requested the result be returned as text/html or application/html, the result should be encoded as: where the strings ...url n... are replaced by the n'th URL in the list. 3.3 N2R (URN to Resource): --------------------------- The request is encoded as above. The resource is returned using standard HTTP mechanisms. The request may be modified using the Accept: header as in normal HTTP to specify that the result be given in a preferred Internet Media Types. 3.4 N2Rs (URN to Resources): ----------------------------- This resolution service returns multiple instances of a resource, for example, GIF and JPEG versions of an image. The judgment about the resources being "the same" resides with the naming authority that issued the URN. The request is encoded as above. The result shall be a MIME multipart/alternative message with the alternative versions of the resource in seperate body parts. If there is only one version of the resource identified by the URN, it MAY be returned without the multipart/alternative wrapper. Resolver software SHOULD look at the Accept: header, if any, and only return versions of the resource that are acceptable according to that header. 3.5 N2C (URN to URC): ---------------------- URCs (Uniform Resource Characteristics) are descriptions of other resources. This request allows us to obtain a description of the resource identified by a URN, as opposed to the resource itself. The description might be a bibliographic citation, a digital signature, a revision history, etc. This draft does not specify the content of any response to a URC request. That content is expected to vary from one resolver to another. The format of any response to a N2C request MUST be communicated using the ContentType header, as is standard HTTP practice. The Accept: header SHOULD be honored. 3.6 N2Ns (URN to URNs): ------------------------ While URNs are supposed to identify one and only one resource, that does not mean that a resource may have one and only one URN. For example, consider a resource that has something like "current-weather-map" for one URN and "weather-map-for-datetime-x" for another URN. The N2Ns service request lets us obtain lists of URNs that are believed equivalent at the time of the request. As the weathermap example shows, some of the equivalances will be transitory, so the standard HTTP mechanisms for communicating cachability MUST be honored. The request is encoded as above. The result is a list of all the URNs, known to the resolver, which identify the same resource as the input URN. The result shall be encoded as for the N2Ls request above (text/uri-list unless specified otherwise by an Accept: header). 3.7 L2Ns (URL to URNs): ---------------------- The request is encoded as above. The response is a list of any URNs known to be assigned to the resource at the given URL. The result shall be encoded as for the N2Ls and N2Ns requests. 3.8 L2Ls (URL to URLs): ------------------------ The request is encoded as described above. The result is a list of all the URLs that the resolver knows are associated with the resource located by the given URL. This is encoded as for the N2Ls, N2Ns, and L2Ns requests. 3.9 L2C (URL to URC): ---------------------- The request is encoded as above, the response is the same as for the N2C request. Implementation Notes: ===================== This section gives an example of how to configure a web server to respond to the N2L resolution request. It is not intended to specify standard behavior, it is provided here merely as a courtesy for implementors. First, we assume the presence of a CGI script, n2l.pl, that processes the provided URN, converting it into a canonical format. It would remove any "urn:" prefix, decode any %encoded special characters, normalize case-insensitive parts of the URN to lower case, etc. It would then use the normalized URN as the key for a search in a database, which we assume returns the URL as a string. A sample of our implementation of that script is provided as Appendix B. We will further assume that the n2l.pl script is in the cgi-bin directory of the web server. The easiest way to invoke the n2l.pl script in response to N2L requests is to set up a Redirect directive in the srm.conf file. (This works for servers based on the original NCSA HTTP daemon, such as Apache.) The relevant Redirect directives might look like: Redirect /uri-res/N2L http://urn.acl.lanl.gov/cgi-bin/n2l.pl Redirect /uri-res/L2N http://urn.acl.lanl.gov/cgi-bin/l2n.pl Appendix A: The text/uri-list Internet Media Type ================================================= [This appendix will be augmented or replaced by the registration of the text/uri-list IMT once that registration has been performed]. Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns, L2Ls, result in a list of URIs being returned to the client. The text/uri-list Internet Media Type is defined to provide a simple format for the automatic processing of such lists of URIs. The format of text/uri-list resources is: 1) Any lines beginning with the '#' character are comment lines and are ignored during processing. 2) The first non-comment line MUST be an integer giving the number of URIs in the list. 3) The remaining non-comment lines MUST be URIs (URNs or URLs), encoded according to the URI specification RFC[5]. Each URI shall appear on one and only one line. 4) As for all text/* formats, lines are terminated with a CR LF pair. In applications where one URI has been mapped to a list of URIs, such as in response to the N2Ls request, the first line of the text/uri-list response SHOULD be a comment giving the original URI. An example of such a result for the N2L request is shown below in figure 1. # urn:cid:foo@huh.org 3 http://www.huh.org/cid/foo.html http://www.huh.org/cid/foo.pdf ftp://ftp.foo.org/cid/foo.txt Figure 1: Example of the text/uri-list format Appendix B: n2l.pl script ========================== This is a simple perl script for the N2L resolution service. It assumes the presence of a DBM database to store the URN to URL mappings. #!/bin/perl # N2L - performs urn to url resolution $n2l_File = "...filename for DBM database..."; $urn = $ENV{'PATH_INFO'} ; if(length($urn)<3) { $error=1; } if(!$error) { $urn =~s/^(\/)(urn:)?(.*)/$3/i; # Additional canonicalization should be performed here dbmopen(%lu,$n2l_File,0444); if($lu{$urn}) { $url=$lu{$urn}; print STDOUT "Location: $url\n\n"; }else{ $error=2; } dbmclose(%lu); } if($error) { print "Content-Type: text/html \n\n"; print "\n"; print "URN Resolution: N2L\n"; print "\n"; print "

URN to URL resolution failed for the URN:

\n"; print "

$urn

\n"; print "\n"; print "\n"; } exit; References: =========== [1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", draft-ietf-urn-naptr-00.txt, October, 1996. [2] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May, 1996. [3] HTTP 1.1 draft [4] URN Framework draft [5] RFC 1630 Security Considerations ======================= Communications with a resolver may be of a sensitive nature. Some resolvers will hold information that should only be released to authorized users. The results from resolvers may be the target of spoofing, especially once electronic commerce transactions are common and ther is money to be made by directing users to pirate repositories rather than repositories which pay royalties to rightsholders. Resolution requests may be of interest to traffic analysts. The requests may also be subject to spoofing. The requests and responses in this draft are amenable to encoding, signing, and authentication in the manner of any other HTTP traffic. Author Contact Information: =========================== Ron Daniel Los Alamos National Laboratory MS B287 Los Alamos, NM, USA, 87545 voice: +1 505 665 0597 fax: +1 505 665 4939 email: rdaniel@lanl.gov This draft expires 15 May, 1997. Ron Daniel Jr. email: rdaniel@acl.lanl.gov 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 obscure_term: "hypernym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA13751 for urn-ietf-out; Wed, 13 Nov 1996 16:32:01 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA13745 for ; Wed, 13 Nov 1996 16:31:59 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15170 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 16:31:58 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id NAA06896; Wed, 13 Nov 1996 13:30:12 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id NAA19036; Wed, 13 Nov 1996 13:30:23 -0800 (PST) Date: Wed, 13 Nov 1996 13:30:23 -0800 (PST) From: Terry Allen Message-Id: <199611132130.NAA19036@ishtar.fsc.fujitsu.com> To: moore@cs.utk.edu, stu_weibel@oclc.org Subject: Re: [URN] Re: I18N does not belong in URNs Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Keith writes: | As to the former statement, in case there's any doubt as to "URNs aren't | supposed to be human meaningful", I refer interested parties to the group's | charter | (http://www.ietf.org/html.charters/urn-charter.html) and to RFC 1737, | the requirements of which the charter incorporates by reference. Please cite specific passages in support of your position. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA13616 for urn-ietf-out; Wed, 13 Nov 1996 16:28:01 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA13608 for ; Wed, 13 Nov 1996 16:27:57 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15103 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 16:27:44 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <02106-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 22:24:54 +0100 Subject: Re: [URN] Please avoid "URNs are" To: moore@cs.utk.edu (Keith Moore) Date: Wed, 13 Nov 1996 22:24:53 +0100 (MET) Cc: moore@cs.utk.edu, Harald.T.Alvestrand@uninett.no, Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611132031.PAA21010@ig.cs.utk.edu> from "Keith Moore" at Nov 13, 96 03:31:47 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4775 From: Martin J Duerst Message-Id: <"josef.ifi..528:13.10.96.21.24.55"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore wrote: >> >Also, we can't assume that the transcription of a URN from paper to >> >keyboard will be through an intelligent tool that understands how to >> >translate URNs from display format to some other format. >> >> You need a reasonably intelligent human user, of course. As for >> keyboarding tools, in the worst case you would need a Unicode >> book (cheaper than most keyboards themselves, but unfortunately >> heavy), a piece of paper, and a code table for the 16 hex digits. >> As an alternative, I suggest some nice site programmed in Java, >> or whatever. > >Sorry, I just don't buy it. > >People aren't going to carry around Unicode books, and they're not >going to be willing to poke through several pages or screenfuls of >glphys to find the one matching a particular character in a URN. The Unicode book was of course meant more as a joke. But it shows that the minimal requirement, in terms of software, is really very low. I don't say that it should be done that way. On the other hand, what are you going to do if you get a traditional payment slip with a Japanese postal transfer account number on it, and are requested to send some money electronically to that account? If you have nothing but a US keyboard and lynx for Web access, would you prefer to look up the relevant character in an Unicode book and do the UCS-2 => UTF-8 => %HH calculations according to a well-established convention, or would you prefer to have to search for a document defining how the Japanese postal transfer account number namespace is mapped to the GCD character set, and then to get whatever specific standard you need to determine the encoding of that character, and then go through a similar encoding procedure? As another example, if you go to a library in China that uses some ideographs in their catalog numbers, do you want to require that the thousands of daily Chinese users learn how to convert from their traditional catalog numbering system to what the library has arbitrarily decided to use for encoding it into URNs (other than some straightforward prefixing), just that in the rare case that such an URN finds its way to some Western ignorant, he is able to type it in without even the slightest effort? By defining UTF-8 to be used in URNs, we can make life easier for all Japanese typing in postal transfer account numbers, and all Chinese users of such catalogs, and many others in large numbers, while not giving the accidental outside user much more work than what he might have had anyway. And we still can rest assured that when you get an URN from a friend in Japan or China, and that friend is indeed aware of your ignorance about ideographs, (s)he can send it in a form (namely %HH) that you will feel sure will not get mutilated. [In general, an integrated browser/mail handling system will not have problems to handle the URN even if it is Japanese characters (assumed the encoding is correctly labeled, a requirement which we need anyway). But your friend may be so kind and take into account your disbelief in these matters.] >Pen-style PDAs have enough trouble analyzing latin letters; they >aren't going to support the ability to enter arbitrary Unicode >characters anytime soon -- especially not from people who aren't used >to writing those characters.** Arbitrary Unicode contains lots of similar-looking instances, and indeed would be difficult. But if characters from the usual subsets are used in context, pen input covering pretty much full Unicode is not so difficult. Please note that for writers knowing how to write the characters, pen input actually works better for ideographs than for English. >From reading RFC 1737, URNs were obviously intended to be composed of >a small set of characters. Trying to incorporate all of Unicode into >URNs is just too big a stretch. >From reading some parts for RFC 1737, one may definitely get that impression, in particular if one has never really imagined that something else could be possible. But there is nothing in RFC 1737 that requires that we do not define how other characters are represented in case they need to be represented. We do not "incorporate all of Unicode" in the sense that we require every URN to contain at least an Arabic and a Hebrew character and a CJK Ideograph and so on. We just make it possible that such characters can be represented by URLs for those namespaces that have such a requirement. We also make it possible for namespaces that contain characters from the base Latin alphabet to be represented in URLs. To be fair to (almost) all really existing namespaces, we have to either restrict ourselves to just the digits or so, or to allow for any character from the universal character set to be representable. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA12430 for urn-ietf-out; Wed, 13 Nov 1996 15:40:47 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA12425 for ; Wed, 13 Nov 1996 15:40:14 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14350 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 15:39:45 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id PAA21010; Wed, 13 Nov 1996 15:31:47 -0500 (EST) Message-Id: <199611132031.PAA21010@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: moore@cs.utk.edu (Keith Moore), Harald.T.Alvestrand@uninett.no, Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] Please avoid "URNs are" In-Reply-To: Your message of "Wed, 13 Nov 1996 20:54:21 +0100." <"josef.ifi..262:13.10.96.19.54.32"@ifi.unizh.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Nov 1996 15:31:47 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > >> > o Single encoding: The encoding for presentation for people in clear > >> > text, electronic mail and the like is the same as the encoding in > >> > other transmissions. > >> > >> This requirement makes sense in the sense that the number of different > >> representations and encoding should be as low as possible. > > > >I hope that "as low as possible" is equivalent to "one". > > Well, with EBCDIC and ASCII, you will certainly have two :-). Not if we think of URNs as being composed of characters :) > >> But it does not say anything about how URNs are noted on paper. > > > >No it doesn't. But it seems reasonable to expect that people will > >transcribe URNs from their screens to paper, and from that paper to > >keyboard. The result of doing so had better produce the same URN. > > Of course. Modulo some problems of the kind of O/0 and l/1/I, it > will, for all of i18n. Not if my keyboard doesn't support the characters in the URN. > >Also, we can't assume that the transcription of a URN from paper to > >keyboard will be through an intelligent tool that understands how to > >translate URNs from display format to some other format. > > You need a reasonably intelligent human user, of course. As for > keyboarding tools, in the worst case you would need a Unicode > book (cheaper than most keyboards themselves, but unfortunately > heavy), a piece of paper, and a code table for the 16 hex digits. > As an alternative, I suggest some nice site programmed in Java, > or whatever. Sorry, I just don't buy it. People aren't going to carry around Unicode books, and they're not going to be willing to poke through several pages or screenfuls of glphys to find the one matching a particular character in a URN. Pen-style PDAs have enough trouble analyzing latin letters; they aren't going to support the ability to enter arbitrary Unicode characters anytime soon -- especially not from people who aren't used to writing those characters.** >From reading RFC 1737, URNs were obviously intended to be composed of a small set of characters. Trying to incorporate all of Unicode into URNs is just too big a stretch. Keith **(And while voice-recognition technology is already good enough to distinguish latin letters and digits pronounced by random people in random dialects, it will never be good enough to let people "speak in" random characters that they've never seen before and don't know how to prononuce. I mention this because it seems obvious to me that personal computers, especially portable ones, are going to support voice recognition -- a microphone is a lot more portable than either a keyboard or a writing surface.) Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA11982 for urn-ietf-out; Wed, 13 Nov 1996 15:22:14 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA11977; Wed, 13 Nov 1996 15:22:12 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14120 (mail destined for find@services.bunyip.com); Wed, 13 Nov 96 15:22:07 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id PAA20999; Wed, 13 Nov 1996 15:16:58 -0500 (EST) Message-Id: <199611132016.PAA20999@ig.cs.utk.edu> To: apps-working-group-list:; Subject: [URN] reminder of Internet-Draft cutoff date Date: Wed, 13 Nov 1996 15:16:58 -0500 From: Keith Moore Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com This is just a reminder that the cutoff for Internet-Draft submissions prior to the San Jose IETF meeting is Tuesday, November 26, 1996 at 1700 Eastern Standard US time. (I think that's 2200 UTC) Proposals to be discussed at IETF WG meetings must be submitted as Internet-Drafts prior to discussion. So if you want to have a proposal discussed at the San Jose IETF, you need to get it in before this deadline. Please also note that due to the the large number of last-minute internet-draft submissions, last-minute drafts require more time to appear in the Internet-Drafts repositories. Given the US Thanksgiving holidays on 28-29 November, I wouldn't expect last-minute drafts to be generally available before 2-3 December or so. So to give other working group members more time to review drafts, I encourage people to submit their drafts a few days before the deadline. For information on how to submit an Internet-Draft, look at ftp://ftp.ietf.org/ietf/1id-guidelines.txt Keith Moore APPS AD Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA11959 for urn-ietf-out; Wed, 13 Nov 1996 15:20:26 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA11953 for ; Wed, 13 Nov 1996 15:20:23 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14036 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 15:13:19 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id PAA20767; Wed, 13 Nov 1996 15:12:48 -0500 (EST) Message-Id: <199611132012.PAA20767@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: stu_weibel@oclc.org (Stu Weibel) Cc: urn-ietf@bunyip.com, moore@cs.utk.edu Subject: [URN] Re: I18N does not belong in URNs In-Reply-To: Your message of "Mon, 11 Nov 1996 13:56:14 EST." <199611111856.NAA20145@orc.NISOR> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Nov 1996 15:12:48 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com Stu writes: > Keith Moore writes: > > > URNs aren't supposed to be human-meaningful. Making them human-meaningful > > defeats the purpose of having them be long-term stable. > > This reflects a philosophy, an attitude, a point of view that is NOT > shared in anything like a consensus in this group. As to the latter statement, I agree with you. Many people do not believe (or are not yet convinced) that human-meaningful URNs are inherently nonpersistent over the long term. Even I will concede that there might be a way out. Tim Berners-Lee and others have suggested adding low-precision dates to URNs. So (e.g.) the "199610" in the URN urn:inet:kodak.com/199610/gibberish would fix the meaning of "kodak.com" and any other human-readable strings within the URN to "the meaning of these words in the tenth month of 1996". Maybe that would be sufficient. There's no way to know for sure, since it depends on what people do in the future. As to the former statement, in case there's any doubt as to "URNs aren't supposed to be human meaningful", I refer interested parties to the group's charter (http://www.ietf.org/html.charters/urn-charter.html) and to RFC 1737, the requirements of which the charter incorporates by reference. Actually, I recommend that everyone here re-read RFC 1737, with particular emphasis on the Introduction. It is a good description of the problem that this group was created to solve. > I say again... > this WG should adopt the *least restrictive* solution that is technologically > sound and let people do with it what their communities choose. That sounds reasonable, but by itself, it's not good engineering sense. Here's an alternative view for consideration: This WG should adopt the *least complex* solution which meets the various requirements of its charter, and which does not impose unnecessary restrictions beyond those inherent in the problem space. Of course, both of these positions are extreme. Usually we want a solution that is not too complex to implement, but still has some extra flexibility to allow the solution, once deployed, to adapt to unanticipated uses. But when people propose adding I18N support to URNs to make them human meaningful, I view this as adding a great deal of extra complexity in an attempt to make URNs solve a completely different problem than they were designed to solve. (And given the history of various "information infrastructure" groups at failing to narrow their scope to a problem that's solvable in finite time, I get very nervous.) By contrast, when people propose adding I18N support to URNs to allow them to incorporate URN-like names that happen to include one or two non-universal characters, I wonder things like "Is it really worth the complexity?" and "Which is more important, global scope and transcribability and single encoding or the ability to easily grandfather all URN-like systems?" Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA10723 for urn-ietf-out; Wed, 13 Nov 1996 14:57:11 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA10718 for ; Wed, 13 Nov 1996 14:56:58 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13771 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 14:55:22 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01921-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 20:54:22 +0100 Subject: Re: [URN] Please avoid "URNs are" To: moore@cs.utk.edu (Keith Moore) Date: Wed, 13 Nov 1996 20:54:21 +0100 (MET) Cc: moore@cs.utk.edu, Harald.T.Alvestrand@uninett.no, Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611131905.OAA15428@ig.cs.utk.edu> from "Keith Moore" at Nov 13, 96 02:05:06 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4344 From: Martin J Duerst Message-Id: <"josef.ifi..262:13.10.96.19.54.32"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore wrote: >> >> PLEASE avoid saying "URNs are XXX". Please use wording such >> >> as "URNs are noted on paper as XXX", "URNs are represented >> >> on computers in the following forms...", or "URNs represent >> >> characters from the following set..." or whatever. >> > >> >I'm not sure how much difference it makes. RFC 1737 requires >> >the following: >> > >> > o Single encoding: The encoding for presentation for people in clear >> > text, electronic mail and the like is the same as the encoding in >> > other transmissions. >> >> This requirement makes sense in the sense that the number of different >> representations and encoding should be as low as possible. > >I hope that "as low as possible" is equivalent to "one". Well, with EBCDIC and ASCII, you will certainly have two :-). >> But it does not say anything about how URNs are noted on paper. > >No it doesn't. But it seems reasonable to expect that people will >transcribe URNs from their screens to paper, and from that paper to >keyboard. The result of doing so had better produce the same URN. Of course. Modulo some problems of the kind of O/0 and l/1/I, it will, for all of i18n. >Also, we can't assume that the transcription of a URN from paper to >keyboard will be through an intelligent tool that understands how to >translate URNs from display format to some other format. You need a reasonably intelligent human user, of course. As for keyboarding tools, in the worst case you would need a Unicode book (cheaper than most keyboards themselves, but unfortunately heavy), a piece of paper, and a code table for the 16 hex digits. As an alternative, I suggest some nice site programmed in Java, or whatever. >A URN could >certainly be sent via email, transcribed to paper, and typed back into >plain text email by someone else. For Japanese postal transfer accounts, that would work without problems, even if the Kanji character appears as such, and not mutilated to some ASCII-compatible form. The only thing you have to make sure is that if you cut/paste something from/to your URN field in a browser, the underlying encoding is changed appropriately (from ISO-2022-JP in the case of email to UTF-8, with or without the additional %HH depending on what is needed). Browsers such as Netscape do conversions correctly in other instances, so I have no doubt they would get it right as soon as they know what to do. >For grandfathering other URN schemes, non-universal characters will >need to be converted into sequences of universal characters. International standards use the term "universal character set" to denote an encompassing set of characters. In order to avoid misunderstanding by less informed readers, why not use "greatest-common-denominator characters" or GCD characters for short. >That way >there can be a well-defined conversion from {j.random.naming.scheme} >to URN, but only one format for the URN once it's converted. It's >fine if smart software recognizes certain types of URNs and undoes the >conversion, so long as the unconverted form is displayed as an >identifier from {j.random.naming.scheme} and NOT as a URN. We have been at this point before. It is mainly a naming issue, and to some extent a protocol encoding issue. You are requesting that things that don't appear %HH-encoded, but with the origina characters they represent, are not called URNs. You are also requesting that there be no 8-bit transfer form. >As for URNs encoded in EBCDIC: we should probably define URNs as >sequences of characters, Here wording really matters. To be clear, it is best to say that URNs are *represented by* sequences of characters. They *are* abstract, permanent identifiers or something along these lines. >which can be represented in any character >encoding scheme, so long as: > >+ that encoding scheme is clearly labeled (e.g. MIME charset) whenever >multiple encodings can appear in the same context, and > >+ there is a unique encoding in that scheme for each character that >can appear in a URN. > >So URN character sequences could be encoded in ASCII or EBCDIC or >UCS-32 or whatever and still be URNs. A small detail: What you mean by UCS-32 is called UCS-4. It might have been called UCS-31, but not UCS-32, because in the 4-byte form, the uppermost bit (sign bit) is not used. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA10076 for urn-ietf-out; Wed, 13 Nov 1996 14:17:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA10067 for ; Wed, 13 Nov 1996 14:17:03 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13374 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 14:16:57 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01896-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 20:16:13 +0100 Subject: Re: [URN] I18N does not belong in URNs To: Dirk.vanGulik@jrc.it (Dirk.vanGulik) Date: Wed, 13 Nov 1996 20:16:12 +0100 (MET) Cc: FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <9611111313.AA04245@ jrc.it> from "Dirk.vanGulik" at Nov 11, 96 02:13:30 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3530 From: Martin J Duerst Message-Id: <"josef.ifi..120:13.10.96.19.16.30"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Dirk.vanGulik wrote: >Or they use a naming scheme dependent interpretation. You could for >example simply limit the representation of the URN to the glyphs >A-Z, 0-9 and say the dot, dash, and colon. Too much in favor of English users (+Hawaiian and Suwaheli)! >I recently came across a specific scheme, say 'crdis' which has a lot of >LocalControlIdentfiers which can (only be fully) expressed in 2-byte octets. >This obviously gave problems as some of our z39.50 servers and HTTP/URN resolving >code did not quite like this. A pragmatic solution was to simply base64 >encode the identfication string. > >A specialist GUI could now base64-decode the string to arrive >at something meaningfull for a human. But it does not have to. >And it does keep things simple. I have mentionned earlier the possibility that some namespaces may contain arbitrary data, as opposed to characters, and I have therefore suggested that the requirement that all URNs be UTF-8 should be relaxed. I have given the data: URL as an example. Here we have an obvious second examlpe. >I really would like to roll up the charset discussion; I agree that for a lot >of scheme's, in particular those to be grandfathered in, one will need very >flexible encodings. They need to be very flexible in the sense that they have to be able to accomodate a very large set of characters, and something else than characters in some cases. But there is absolutely no reason to have arbitrary flexibility for those cases where indeed characters have to be represented. For this case, it is much easier to specify that UTF-8 be used (optionally or even mandatorily with %HH encoding). >But the internet transfer mechanisms are not quite up to >that yet. So I would suggest: > > 1. Limit the URNs to just a few chars (along the lines of DNS) This > also makes comparing URNs easy. As for the character set *representing* URNs, I can agree. This would basically mean that everything has to be %HH encoded. > 2. Allow, or perhaps even force, each registered naming scheme > to suggest a possible encoding/escape sequencing to derive > nice human names from the URN. This can be used by the more > advanced GUIs. The greatest majority of naming schemes will have identical problems, namely how to represent characters in namespaces. And a single and very simple GUI can provide nice human representations for these cases (modulo available fonts). And a single and widely applicable convention should be used by all naming schemes dealing with characters. > 3. And keep a few chars (say the %) in stock, for the future. > > 4. And remember, one can always make something like a next generation > URN+:das:asd which can only be transcribed properly using say UTF8. There is absolutely no need to wait any longer for UTF-8. >I know that such an encoding essentially wastes space; but that is a tradeoff >I am willing to make for simplfied storage, encoding and comparing. All your requirements can be fulfilled by: - Allowing non-character namespaces to create their own non UTF-8 encodings (as I have suggested previously). - Require that internally, all 8-bit octets resulting from UTF-8 encoding of characters beyond ASCII (+some in ASCII) be encoded with %HH, so that there is no 8-bit from of URNs. Although I have good reasons to think that the second point is not needed, I could live with it. But giving up a convention such as UTF-8 to map arbitrary characters in namespaces to URNs would be a great loss. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA10001 for urn-ietf-out; Wed, 13 Nov 1996 14:10:33 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA09995 for ; Wed, 13 Nov 1996 14:10:27 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13304 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 14:10:18 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id OAA15428; Wed, 13 Nov 1996 14:05:06 -0500 (EST) Message-Id: <199611131905.OAA15428@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: moore@cs.utk.edu (Keith Moore), Harald.T.Alvestrand@uninett.no, Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] Please avoid "URNs are" In-Reply-To: Your message of "Wed, 13 Nov 1996 19:41:54 +0100." <"josef.ifi..077:13.10.96.18.41.56"@ifi.unizh.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Nov 1996 14:05:06 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > >> PLEASE avoid saying "URNs are XXX". Please use wording such > >> as "URNs are noted on paper as XXX", "URNs are represented > >> on computers in the following forms...", or "URNs represent > >> characters from the following set..." or whatever. > > > >I'm not sure how much difference it makes. RFC 1737 requires > >the following: > > > > o Single encoding: The encoding for presentation for people in clear > > text, electronic mail and the like is the same as the encoding in > > other transmissions. > > This requirement makes sense in the sense that the number of different > representations and encoding should be as low as possible. I hope that "as low as possible" is equivalent to "one". > But it does not say anything about how URNs are noted on paper. No it doesn't. But it seems reasonable to expect that people will transcribe URNs from their screens to paper, and from that paper to keyboard. The result of doing so had better produce the same URN. Also, we can't assume that the transcription of a URN from paper to keyboard will be through an intelligent tool that understands how to translate URNs from display format to some other format. A URN could certainly be sent via email, transcribed to paper, and typed back into plain text email by someone else. For grandfathering other URN schemes, non-universal characters will need to be converted into sequences of universal characters. That way there can be a well-defined conversion from {j.random.naming.scheme} to URN, but only one format for the URN once it's converted. It's fine if smart software recognizes certain types of URNs and undoes the conversion, so long as the unconverted form is displayed as an identifier from {j.random.naming.scheme} and NOT as a URN. As for URNs encoded in EBCDIC: we should probably define URNs as sequences of characters, which can be represented in any character encoding scheme, so long as: + that encoding scheme is clearly labeled (e.g. MIME charset) whenever multiple encodings can appear in the same context, and + there is a unique encoding in that scheme for each character that can appear in a URN. So URN character sequences could be encoded in ASCII or EBCDIC or UCS-32 or whatever and still be URNs. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA09902 for urn-ietf-out; Wed, 13 Nov 1996 14:01:51 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA09884 for ; Wed, 13 Nov 1996 14:00:12 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13195 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 14:00:08 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01830-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 19:41:55 +0100 Subject: Re: [URN] Please avoid "URNs are" To: moore@cs.utk.edu (Keith Moore) Date: Wed, 13 Nov 1996 19:41:54 +0100 (MET) Cc: Harald.T.Alvestrand@uninett.no, Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611131825.NAA15239@ig.cs.utk.edu> from "Keith Moore" at Nov 13, 96 01:25:05 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1086 From: Martin J Duerst Message-Id: <"josef.ifi..077:13.10.96.18.41.56"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore wrote: >> PLEASE avoid saying "URNs are XXX". Please use wording such >> as "URNs are noted on paper as XXX", "URNs are represented >> on computers in the following forms...", or "URNs represent >> characters from the following set..." or whatever. > >I'm not sure how much difference it makes. RFC 1737 requires >the following: > > o Single encoding: The encoding for presentation for people in clear > text, electronic mail and the like is the same as the encoding in > other transmissions. This requirement makes sense in the sense that the number of different representations and encoding should be as low as possible. But it does not say anything about how URNs are noted on paper. It also does not say something about how people may finally see it (the encoding used for presentation could well be %HH, with an intelligent tool showing Chinese or whatever). In addition, when considering EBCDIC, it would either forbid URNs to be transmitted with EBCDIC, or would garble URNs encoded in EBCDIC for the sake of preserving the encoding. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA09901 for urn-ietf-out; Wed, 13 Nov 1996 14:01:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA09881 for ; Wed, 13 Nov 1996 14:00:08 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13192 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 14:00:01 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01807-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 19:27:49 +0100 Subject: Re: [URN] I18N does not belong in URNs To: conklin@info.cren.net (Jim Conklin) Date: Wed, 13 Nov 1996 19:27:48 +0100 (MET) Cc: Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: from "Jim Conklin" at Nov 11, 96 11:59:15 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2020 From: Martin J Duerst Message-Id: <"josef.ifi..611:13.10.96.18.27.55"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Jim Conklin wrote: > I've been trying to decide how one might allow human-meaningful URNs for >multiple languages and encodings, and it seems to me that this would be >possible if and only if the URN identifier itself includes character-set >information. Jim - The current proposal implicitly includes character-set information. This is done by choosing the Universal Character Set (ISO 10646), which assures that any character in any existing and reasonably used character set can be used. If you don't know about ISO 10646, also known under the name Unicode, I can point you to additional information. Including character set information explicitly would make the URNs more clumsy, would require applications to handle more and more character sets, and would have some other disadvantages. This is independent of whether URNs should/could/should not be meaningful. > Would it make sense to include in the definition of the URN format (yes, >I know, this is past history!) an optional language and encoding >specification which could then be used by sufficiently intelligent clients >to display the URN in the specified language using the specified character >encoding? As for encoding, I have given you the answer above. You now also mention language. I do not think that language information is necessary for URNs. If you think it is necessary, can you please explain your reasons, so that I can answer specifically? >Even the language and encoding could, in that way, be rendered >in the specified language and, with a (relatively) small number of >predefined languages and encodings, those could be specified in a small, >universal symbol set, since they'd normally not be seen by the end user >with a smart client. As for "small number of encodings", we have a solution with only one encoding. That should be small enough a number. As for "small number of languages", if language information should indeed be needed, restricting the number of languages would be very unfair indeed. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA09770 for urn-ietf-out; Wed, 13 Nov 1996 13:47:07 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA09765 for ; Wed, 13 Nov 1996 13:47:04 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13034 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 13:46:31 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id NAA15239; Wed, 13 Nov 1996 13:25:05 -0500 (EST) Message-Id: <199611131825.NAA15239@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: Harald.T.Alvestrand@uninett.no, Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] Please avoid "URNs are" In-Reply-To: Your message of "Wed, 13 Nov 1996 19:16:55 +0100." <"josef.ifi..391:13.10.96.18.16.57"@ifi.unizh.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Nov 1996 13:25:05 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > PLEASE avoid saying "URNs are XXX". Please use wording such > as "URNs are noted on paper as XXX", "URNs are represented > on computers in the following forms...", or "URNs represent > characters from the following set..." or whatever. I'm not sure how much difference it makes. RFC 1737 requires the following: o Single encoding: The encoding for presentation for people in clear text, electronic mail and the like is the same as the encoding in other transmissions. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA09372 for urn-ietf-out; Wed, 13 Nov 1996 13:22:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA09361 for ; Wed, 13 Nov 1996 13:21:53 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12793 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 13:21:21 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01775-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 19:16:56 +0100 Subject: Re: [URN] Please avoid "URNs are" To: Harald.T.Alvestrand@uninett.no Date: Wed, 13 Nov 1996 19:16:55 +0100 (MET) Cc: Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <25174.847734044@dale.uninett.no> from "Harald.T.Alvestrand@uninett.no" at Nov 11, 96 06:40:44 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1535 From: Martin J Duerst Message-Id: <"josef.ifi..391:13.10.96.18.16.57"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Harald Alvestran wrote: >There are about 3 alternatives I can see: > >- The URN syntax doc says that URNs are sequences of ASCII > characters (or some subset thereof) >- The URN syntax doc says that URNs are sequences of OCTETS, > with no meaning assigned by the URN syntax doc after the > second : >- The URN syntax doc says that URNs are sequences of CHARACTERS, > drawn from the ISO 10646 set. > >The tradeoffs are different for the 3 cases. I have followed the followups to this message, but only have been confused more. PLEASE avoid saying "URNs are XXX". Please use wording such as "URNs are noted on paper as XXX", "URNs are represented on computers in the following forms...", or "URNs represent characters from the following set..." or whatever. Except for octet values coinciding with encoded ASCII characters coinciding with the notation of these same characters on paper and actually representing these same characters, the distinctions made above matter very much both to have a clear and working proposal, and to have this proposal being understood by those that will need to do so. When you start to think about i18n issues, it is difficult to get avay from the simple ASCII world where "representing" and "represented" are just fillers because everything looks the same. As Ryan Moats has said earlier, changing your thinking to accomodate the complexities outside ASCII can be painful. He at least understands that it has to be done. So in future messages, please avoid saying "URNs are". Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA09167 for urn-ietf-out; Wed, 13 Nov 1996 13:10:45 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA09158 for ; Wed, 13 Nov 1996 13:10:13 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12681 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 13:10:09 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01757-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 19:02:03 +0100 Subject: Re: [URN] I18N does not belong in URNs To: masinter@parc.xerox.com (Larry Masinter) Date: Wed, 13 Nov 1996 19:02:02 +0100 (MET) Cc: FisherM@is3.indy.tce.com, Dirk.vanGulik@jrc.it, girod@LCS.MIT.EDU, Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <96Nov12.090844pst."2695"@golden.parc.xerox.com> from "Larry Masinter" at Nov 12, 96 09:08:44 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 799 From: Martin J Duerst Message-Id: <"josef.ifi..026:13.10.96.18.02.18"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Larry Masinter wrote: ># If (as an example) a Chinese information provider wished to make ># available their resources to English speakers as URNs, I would ># suspect they would want to provide "English-compatible" URNs, ># rather than long, seemingly random %XX-encoded strings. > >So the library of China should assign chinese URNs to the information >they think only Chinese readers will want to read, and ASCII URNs to >the texts they think might also be of interest to people who don't >read Chinese? Probably they shouldn't, but they might. They indeed might already have some naming scheme for their complete library that includes Chinese characters and that they want to grandfather. And there is no rule that for a given resource, there can only be one single URN. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA09116 for urn-ietf-out; Wed, 13 Nov 1996 13:07:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA09105 for ; Wed, 13 Nov 1996 13:06:49 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12661 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 13:06:39 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01765-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 19:06:06 +0100 Subject: Re: [URN] I18N does not belong in URNs To: masinter@parc.xerox.com (Larry Masinter) Date: Wed, 13 Nov 1996 19:06:05 +0100 (MET) Cc: FisherM@is3.indy.tce.com, Dirk.vanGulik@jrc.it, girod@LCS.MIT.EDU, Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <96Nov12.090844pst."2695"@golden.parc.xerox.com> from "Larry Masinter" at Nov 12, 96 09:08:44 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 792 From: Martin J Duerst Message-Id: <"josef.ifi..121:13.10.96.18.06.07"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Larry Masinter wrote: >So the library of China should assign chinese URNs to the information >they think only Chinese readers will want to read, and ASCII URNs to >the texts they think might also be of interest to people who don't >read Chinese? Just some additional comment: In case they decide to assign anything meaningful (which we will tell them not to do, but they still might do), please note that for many classic texts (as well as for many other things such as place names, countries, names of persons) there are established conventions that differ from language to language. This means that it could be very difficult for a Chinese to identify a hint to some text in an ASCII URN, although he/she might know the name of the text, and the text itself, very well. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA23052 for urn-ietf-out; Tue, 12 Nov 1996 13:24:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA23047 for ; Tue, 12 Nov 1996 13:24:54 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03711 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 13:24:51 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id LAA09242; Tue, 12 Nov 1996 11:24:21 -0700 (MST) Message-Id: <2.2.32.19961112183238.0070c654@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 11:32:38 -0700 To: Harald.T.Alvestrand@uninett.no From: Ron Daniel Subject: Re: [URN] HTTP resolution protocol Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com I'm revising the "Conventions for the Use of HTTP for URN Resolution" draft that I sent to the list awhile back. Before I do so I wanted to ask the list about one point in Harald's last message on the subject. Thus spoke Harald.T.Alvestrand@uninett.no (at least at 02:44 PM 11/4/96 +0100) >(Warning: I'm coming into this without reading the entire debate...) > >I like the idea that HTTP GET is an URI to MIME object resolution >protocol. It either fails or returns a MIME object. > >But the scheme of service:/uri would IMHO require registering >N2L, N2Ls, N2C and so on as URI types; this sounds wrong to me. Agreed. > >If we want a resolution CONVENTION, it seems to me that the right >convention is "GET /resolve/N2L/" (mimicking a CGI-BIN script). >If we want a resolution STANDARD, it seems to me that the right >thing is "N2L HTTP/1.1" I tend to agree that a true resolution STANDARD should define the new HTTP Methods. However, I was shooting for a simple CONVENTION for people to follow. The primary goal was to make it easy to retrofit URN resolution onto existing web servers. That is the tack that I will continue to follow if there is not a massive outpouring of derision from the list. I will change Harald's suggestion from GET /resolve// to GET /uri-res// because an Alta Vista search turned up some instances of /resolve in existing URLs, but no instances of /uri-res. >For handing back lists of things, mimic the responses that were put >into HTTP/1.1 for content negotiation (putting up a header for thte >machine processible version and HTML for the human-readable version). Will do. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA21428 for urn-ietf-out; Tue, 12 Nov 1996 12:09:25 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA21423 for ; Tue, 12 Nov 1996 12:09:22 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02419 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 12:09:15 -0500 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16915(3)>; Tue, 12 Nov 1996 09:09:03 PST Received: by golden.parc.xerox.com id <2695>; Tue, 12 Nov 1996 09:08:44 PST To: FisherM@is3.indy.tce.com Cc: Dirk.vanGulik@jrc.it, girod@LCS.MIT.EDU, Harald.T.Alvestrand@uninett.no, mduerst@ifi.unizh.ch, moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <32888C2E@MSMAIL.INDY.TCE.COM> (message from Fisher Mark on Tue, 12 Nov 1996 06:37:00 PST) Subject: Re: [URN] I18N does not belong in URNs From: Larry Masinter Message-Id: <96Nov12.090844pst."2695"@golden.parc.xerox.com> Date: Tue, 12 Nov 1996 09:08:44 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com # If (as an example) a Chinese information provider wished to make # available their resources to English speakers as URNs, I would # suspect they would want to provide "English-compatible" URNs, # rather than long, seemingly random %XX-encoded strings. So the library of China should assign chinese URNs to the information they think only Chinese readers will want to read, and ASCII URNs to the texts they think might also be of interest to people who don't read Chinese? Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA21389 for urn-ietf-out; Tue, 12 Nov 1996 12:01:06 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA21384 for ; Tue, 12 Nov 1996 12:01:03 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02342 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 12:01:01 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id LAA17005; Tue, 12 Nov 1996 11:57:44 -0500 (EST) Message-Id: <199611121657.LAA17005@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Fisher Mark Cc: "Dirk.vanGulik" , "girod@LCS.MIT.EDU" , "Harald.T.Alvestrand@uninett.no" , "mduerst@ifi.unizh.ch" , "moore@cs.utk.edu" , "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Tue, 12 Nov 1996 09:37:00 EST." <32888C2E@MSMAIL.INDY.TCE.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Nov 1996 11:57:43 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > >The reason for _not_ allowing any octet in the string after urn: is to > >avoid entering into the dark realm of having to retrive MIB like display > >strings whenever you encounter a URN you've not seen before; and which > >you would like to display to a human in such a way he/she can still > >transcribe it. Just showing a list of two digit hex numbers would not do. > > Realistically, how often should we expect a resource that we _can_ read to > be expressed by a URN that we can't read (i.e. the URN needs the %XX > encoding convention)? I would maintain that this would be the > unusual case. I disagree, for several reasons: 1. many resources don't require a particular language. 2. even if you can read the language, you might not be able to type in the characters on your keyboard. 3. machines are getting better at automatic language translation. it's entirely possible, perhaps likely, that in a few years your web browser will have plugins that let it translate from other languages to the one you read best. it might not be as good as being able to read the original language, but it will be good enough to understand most of what's being said. URNs are defined to have global scope. A name that is usable only by a Chinese speaker (or for that matter, an English speaker) isn't a URN. The reason you assign a URN to something is to make it usable by a potentially global audience for a potentially long time. (That doesn't mean that it's usable by anybody -- there can always be access controls-- but it does mean that who can use the resource isn't pre-determined when the name is assigned.) If you don't want your resource to be globally usable, don't give it a URN. Or conversely, if you want to prevent someone who doesn't speak your language from trying to read your resources, URNs aren't the right mechanism for doing this. > Otherwise, we might as well go with sequences of random digits. Yes, that's much closer to what URNs are (IMHO) supposed to be. It also has the advantage of being much easier to implement. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA21067 for urn-ietf-out; Tue, 12 Nov 1996 11:50:29 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA21061 for ; Tue, 12 Nov 1996 11:50:27 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02231 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 11:50:24 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id JAA08316; Tue, 12 Nov 1996 09:50:21 -0700 (MST) Message-Id: <2.2.32.19961112165834.006e96d4@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 09:58:34 -0700 To: stu_weibel@oclc.org (Stu Weibel), urn-ietf@bunyip.com From: Ron Daniel Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Stu Weibel (at least at 01:56 PM 11/11/96 -0500) >I say again... >this WG should adopt the *least restrictive* solution that is technologically >sound and let people do with it what their communities choose. Amen. I recommend: 1) New namespace proposals get standards-track review (or at least come out as experimental RFCs). This will allow namespaces that are obviously bad to be weeded out. 2) We develop an informational RFC on recommended practices for namespaces. This can discuss the problems that arise with persistence for friendly names. Namespaces that want to allow friendly, persistent names can then look to this guide for the questions they will have to answer when their namespace proposal comes up for standards-track review. (Someone else suggested this earlier). Issues of allowed characters are essentially orthogonal to friendliness. We have the example of the Japanese bank account. We also have the example of things like Library of Congress call numbers, which contain a subset of the Latin letters, digits, and some punctuation. (LCCNs are probably not going to make a good URN namespace, but its not due to issues of friendliness). I'm not at all thrilled by proposals to restrict URNs to digits. That seems overly restrictive. The place to prevent crappy namespaces is when they come up for review, not (IMHO) trying to forestall their appearance by restricting the character set. This still leaves us with the ASCII-only vs. 10646-only vs. multiple charset positions. I'll take that up in another message. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA20848 for urn-ietf-out; Tue, 12 Nov 1996 11:42:41 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA20840 for ; Tue, 12 Nov 1996 11:42:32 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02088 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 11:42:28 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA09612; Tue, 12 Nov 96 17:47:29 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA05351; Tue, 12 Nov 1996 17:41:34 +0100 Date: Tue, 12 Nov 1996 17:41:34 +0100 From: "Dirk.vanGulik" Message-Id: <9611121641.AA05351@ jrc.it> To: Dirk.vanGulik@jrc.it, Harald.T.Alvestrand@uninett.no, jayhawk@ds.internic.net Subject: [URN] Re: Harald's syntax proposals [Somewhat Long] (was I18N does not belong in URNs) Cc: FisherM@is3.indy.tce.com, girod@LCS.MIT.EDU, mduerst@ifi.unizh.ch, moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Dirk.vanGulik" Errors-To: owner-urn-ietf@bunyip.com "Ryan Moats" wrote > On Tue, 12 Nov 1996 16:50:36 +0100, Dirk.vanGulik wrote: > > >> To me, the extension (as written) has a couple of holes. The URN has to have > >> information about the namespace so that the resolver can resolve the URN > >> correctly (it took me a while to realize that the proper parsing of option B is > >> the second ":"). Therefore, having no meaning after the optional "urn:" > >> doesn't work. > > > >I realized this as well; but was (and still am) unsure how to effectuate this; > >because is implies that the bit between the first to ':' is really limited in > >encoding. Something which has bothered me in the syntax document. But I have > >no immediate solution for it. > > This is on purpose. The more you free up the NID encoding, the more you restrict > potential implementations. > > >Well: (Which each char actualy being an octet, etc..) > > > > [<] urn:NS:OPS [>] > > > > NS consists of A..Z, 0..9 > > OPS consists of A..Z, 0..9, '-', '_' and '.' > > > > The '-','_','.' are kept in reserve for the NS > > > > Whitespace is allowed > > > >Would be kind of simple. > > Yes, and we may reach something like this eventually (there would > have to be more characters added to the NSS to support grandfathered > spaces. There are just some tradeoffs that we would have to agree upon. Well the whole point was to 'fudge' this grandfathering; and force (almost) all of it to use an encoding scheme of some kind; but naturally they _ONLY_ have to know about this encoding when they want to go in- or out- to the old grandfathered in scheme; and then quite naturally they know what the secret encoding trick is. One of the main points I would like to get across is that all this grand- fathering only matters on the interface between the grandfather and this new born URN daughter; and exactly on that interface there is all the room in the world to do say a base64 to XYZ decoding. > >> >A > >> >> - The URN syntax doc says that URNs are sequences of ASCII > >> >> characters (or some subset thereof) > >> > >> This is of course, the simplest. A minimum of transport encoding would be > >> involved. There may be some reserved characters that would be need to be > >> encoded on a namespace specific basis but those could be done with > >> %HH encoding. > > > >Which would imply namespace specific encapsulation needs; which kind of imposes > >external NS knowledge on arbritary clients. > > Somebody will have to know this anyway. I'm not saying that all the reserved characters > have to be in the syntax document (in fact I'm saying they can't). I'm saying that any > reserved character should be encoded with %HH, which is slightly different. Yes; and I woudl really like to argue that there should be NO encoding on this level at all; the syntax document should be entirely free of it. It might be that in a document which details how some kind of differnt scheme is grandfathered into a certain NS, one will have to detail all this; but that is completely outside the URN syntax document I hope. As a conclusion; I think we quite agree; but compared to you I would prefer the encoding to be pushed away further from the URN, and actually not be a part of it; whereas you would actually allow the URN to consist of arbitrary octets which are encoded with a limited set ? Or am I wrong again ? > >> >B > >> >> - The URN syntax doc says that URNs are sequences of OCTETS, > >> >> with no meaning assigned by the URN syntax doc after the > >> >> second ':' > >> > >> I've modified the above to point up the ':' character. This is the "opaque string" > >> option. This option would require some transport encoding for 8-bit unclean pipes. > >> I see presentation as the major trade-off here. For 8-bit unfriendly schemes, > >> something like the %HH scheme would be needed. For others, the %HH scheme > >> could be mixed with actual glyphs that are representation of that octet (or sequence > >> of octets) in that presentation scheme. However, THIS IS ONLY FOR THE > >> CONVIENCE OF THE PRESENTATION SCHEME, NOT THE USER!!!! > >> The other difficulty is that reserved characters have to be limited to > >> a subset of ASCII or there is the possibility for encoding collisions that would require > >> the syntax doc to specify its own encoding scheme. > >Somehow not very practical ? IMHO. > I didn't say it was practical, just tried to state what the tradeoffs are. Point taken. I was trying to state a point as well :-) Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA20237 for urn-ietf-out; Tue, 12 Nov 1996 11:19:24 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA20217 for ; Tue, 12 Nov 1996 11:19:09 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01726 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 11:19:03 -0500 Message-Id: <9611121619.AA01726@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Tue Nov 12 10:18 CST 1996 From: "Ryan Moats" To: "Dirk.vanGulik@jrc.it" , "Harald.T.Alvestrand@uninett.no" Cc: "FisherM@is3.indy.tce.com" , "girod@LCS.MIT.EDU" , "mduerst@ifi.unizh.ch" , "moore@cs.utk.edu" , "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Date: Tue, 12 Nov 96 10:19:43 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] Re: Harald's syntax proposals [Somewhat Long] (was I18N does not belong in URNs) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Tue, 12 Nov 1996 16:50:36 +0100, Dirk.vanGulik wrote: >> To me, the extension (as written) has a couple of holes. The URN has to have >> information about the namespace so that the resolver can resolve the URN >> correctly (it took me a while to realize that the proper parsing of option B is >> the second ":"). Therefore, having no meaning after the optional "urn:" >> doesn't work. > >I realized this as well; but was (and still am) unsure how to effectuate this; >because is implies that the bit between the first to ':' is really limited in >encoding. Something which has bothered me in the syntax document. But I have >no immediate solution for it. This is on purpose. The more you free up the NID encoding, the more you restrict potential implementations. >Well: (Which each char actualy being an octet, etc..) > > [<] urn:NS:OPS [>] > > NS consists of A..Z, 0..9 > OPS consists of A..Z, 0..9, '-', '_' and '.' > > The '-','_','.' are kept in reserve for the NS > > Whitespace is allowed > >Would be kind of simple. Yes, and we may reach something like this eventually (there would have to be more characters added to the NSS to support grandfathered spaces. There are just some tradeoffs that we would have to agree upon. >> >A >> >> - The URN syntax doc says that URNs are sequences of ASCII >> >> characters (or some subset thereof) >> >> This is of course, the simplest. A minimum of transport encoding would be >> involved. There may be some reserved characters that would be need to be >> encoded on a namespace specific basis but those could be done with >> %HH encoding. > >Which would imply namespace specific encapsulation needs; which kind of imposes >external NS knowledge on arbritary clients. Somebody will have to know this anyway. I'm not saying that all the reserved characters have to be in the syntax document (in fact I'm saying they can't). I'm saying that any reserved character should be encoded with %HH, which is slightly different. >> >B >> >> - The URN syntax doc says that URNs are sequences of OCTETS, >> >> with no meaning assigned by the URN syntax doc after the >> >> second ':' >> >> I've modified the above to point up the ':' character. This is the "opaque string" >> option. This option would require some transport encoding for 8-bit unclean pipes. >> I see presentation as the major trade-off here. For 8-bit unfriendly schemes, >> something like the %HH scheme would be needed. For others, the %HH scheme >> could be mixed with actual glyphs that are representation of that octet (or sequence >> of octets) in that presentation scheme. However, THIS IS ONLY FOR THE >> CONVIENCE OF THE PRESENTATION SCHEME, NOT THE USER!!!! >> The other difficulty is that reserved characters have to be limited to >> a subset of ASCII or there is the possibility for encoding collisions that would require >> the syntax doc to specify its own encoding scheme. >> > >Somehow not very practical ? IMHO. I didn't say it was practical, just tried to state what the tradeoffs are. Ryan P.S. Sorry folks, I think I was in such a hurry to send the last comment off that I didn't admit who wrote it. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA19931 for urn-ietf-out; Tue, 12 Nov 1996 10:52:18 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA19926 for ; Tue, 12 Nov 1996 10:52:14 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01325 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 10:51:56 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA08366; Tue, 12 Nov 96 16:56:56 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA05330; Tue, 12 Nov 1996 16:50:36 +0100 Date: Tue, 12 Nov 1996 16:50:36 +0100 From: "Dirk.vanGulik" Message-Id: <9611121550.AA05330@ jrc.it> To: Dirk.vanGulik@jrc.it, Harald.T.Alvestrand@uninett.no, jayhawk@ds.internic.net Subject: [URN] Re: Harald's syntax proposals [Somewhat Long] (was I18N does not belong in URNs) Cc: FisherM@is3.indy.tce.com, girod@LCS.MIT.EDU, mduerst@ifi.unizh.ch, moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Dirk.vanGulik" Errors-To: owner-urn-ietf@bunyip.com > To me, the extension (as written) has a couple of holes. The URN has to have > information about the namespace so that the resolver can resolve the URN > correctly (it took me a while to realize that the proper parsing of option B is > the second ":"). Therefore, having no meaning after the optional "urn:" > doesn't work. I realized this as well; but was (and still am) unsure how to effectuate this; because is implies that the bit between the first to ':' is really limited in encoding. Something which has bothered me in the syntax document. But I have no immediate solution for it. > The second hole is that while having an interpretation for a specific namespace > defined in a separate namespace document is reasonable (in fact I don't see > how to avoid it) defining general castings in external documents doesn't No, the MIB refernce was meant half in yest; and in fact I hope it will not come to this; i.e. that most generic clients using URNs will simply hardly ever show them to the user. However for very specialist (and also for practical reasons) people close to the data might like specific castings a lot; especialy when the keys in your mother database are easily derivable. But the rest of the world should not care; and the references in external document to the display encoding is really only there to satisfy the curiosity and the very specialist users of that NS. > strike me as a big win. I still believe we can keep the syntax doc reasonably > short while solving the small problem in front of us. Well: (Which each char actualy being an octet, etc..) [<] urn:NS:OPS [>] NS consists of A..Z, 0..9 OPS consists of A..Z, 0..9, '-', '_' and '.' The '-','_','.' are kept in reserve for the NS Whitespace is allowed Would be kind of simple. > This being said, if the holes are plugged up, option D could be a reasonable > alternative > > Now, back to Harald's proposals, I'll try to synopsize them with my thoughts > on the tradeoffs > > >A > >> - The URN syntax doc says that URNs are sequences of ASCII > >> characters (or some subset thereof) > > This is of course, the simplest. A minimum of transport encoding would be > involved. There may be some reserved characters that would be need to be > encoded on a namespace specific basis but those could be done with > %HH encoding. Which would imply namespace specific encapsulation needs; which kind of imposes external NS knowledge on arbritary clients. > >B > >> - The URN syntax doc says that URNs are sequences of OCTETS, > >> with no meaning assigned by the URN syntax doc after the > >> second ':' > > I've modified the above to point up the ':' character. This is the "opaque string" > option. This option would require some transport encoding for 8-bit unclean pipes. > I see presentation as the major trade-off here. For 8-bit unfriendly schemes, > something like the %HH scheme would be needed. For others, the %HH scheme > could be mixed with actual glyphs that are representation of that octet (or sequence > of octets) in that presentation scheme. However, THIS IS ONLY FOR THE > CONVIENCE OF THE PRESENTATION SCHEME, NOT THE USER!!!! > The other difficulty is that reserved characters have to be limited to > a subset of ASCII or there is the possibility for encoding collisions that would require > the syntax doc to specify its own encoding scheme. > Somehow not very practical ? IMHO. Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA19591 for urn-ietf-out; Tue, 12 Nov 1996 10:22:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA19586 for ; Tue, 12 Nov 1996 10:22:17 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01013 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 10:22:11 -0500 Message-Id: <9611121522.AA01013@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Tue Nov 12 09:21 CST 1996 From: "Ryan Moats" To: "Dirk.vanGulik@jrc.it" , "Harald.T.Alvestrand@uninett.no" Cc: "FisherM@is3.indy.tce.com" , "girod@LCS.MIT.EDU" , "mduerst@ifi.unizh.ch" , "moore@cs.utk.edu" , "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Date: Tue, 12 Nov 96 09:22:43 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] Re: Harald's syntax proposals [Somewhat Long] (was I18N does not belong in URNs) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Tue, 12 Nov 1996 14:09:34 +0100, Dirk.vanGulik wrote: >Harald wrote: >> There are about 3 alternatives I can see: > >A >> - The URN syntax doc says that URNs are sequences of ASCII >> characters (or some subset thereof) > >B >> - The URN syntax doc says that URNs are sequences of OCTETS, >> with no meaning assigned by the URN syntax doc after the >> second : > >C >> - The URN syntax doc says that URNs are sequences of CHARACTERS, >> drawn from the ISO 10646 set. > >> The tradeoffs are different for the 3 cases. > >To extend on this, IMHO very sensible, concept: as it gives room >to sensible wire definitions: > >D. Augmenting, case 'B'; > >The URN syntax docs says the URNs are sequences of >OCTETS, whose value comes from a specific range '*' with no meaning >assigned by the URN sysntax doc after the first four octets (which >are the indexes of the glyphs 'u','r','n' and ':' in charset-XYZ.) > >Where the range '*' is; when each octed is taken as in index into >charset-XYZ, is from the range (say) A-Z, 0-9, '_', '-', ":' and '.' > >I'd suggest ISO-8859, US-ASCII, NISO, etc for charset-XYZ. > >For each naming scheme an interpretation/casting can be defined for >the part of the URN after the name-scheme-identifier. > >For the 'inet' (or x-dns-2) name-schme; the suggested interpretation is >as indexes into 8 bit encoded 7bit ASCII (or ISO-8859-1 or whatever). > >Would that be of (some) use? > >The reason for _not_ allowing any octet in the string after urn: is to >avoid entering into the dark realm of having to retrive MIB like display >strings whenever you encounter a URN you've not seen before; and which >you would like to display to a human in such a way he/she can still >transcribe it. Just showing a list of two digit hex numbers would not do. > >Although overloading yet another DNS query type to get the display string >could be fun on the 'display-string'.name-scheme.urn.net level :-) > >Dw. To me, the extension (as written) has a couple of holes. The URN has to have information about the namespace so that the resolver can resolve the URN correctly (it took me a while to realize that the proper parsing of option B is the second ":"). Therefore, having no meaning after the optional "urn:" doesn't work. The second hole is that while having an interpretation for a specific namespace defined in a separate namespace document is reasonable (in fact I don't see how to avoid it) defining general castings in external documents doesn't strike me as a big win. I still believe we can keep the syntax doc reasonably short while solving the small problem in front of us. This being said, if the holes are plugged up, option D could be a reasonable alternative Now, back to Harald's proposals, I'll try to synopsize them with my thoughts on the tradeoffs >A >> - The URN syntax doc says that URNs are sequences of ASCII >> characters (or some subset thereof) This is of course, the simplest. A minimum of transport encoding would be involved. There may be some reserved characters that would be need to be encoded on a namespace specific basis but those could be done with %HH encoding. >B >> - The URN syntax doc says that URNs are sequences of OCTETS, >> with no meaning assigned by the URN syntax doc after the >> second ':' I've modified the above to point up the ':' character. This is the "opaque string" option. This option would require some transport encoding for 8-bit unclean pipes. I see presentation as the major trade-off here. For 8-bit unfriendly schemes, something like the %HH scheme would be needed. For others, the %HH scheme could be mixed with actual glyphs that are representation of that octet (or sequence of octets) in that presentation scheme. However, THIS IS ONLY FOR THE CONVIENCE OF THE PRESENTATION SCHEME, NOT THE USER!!!! The other difficulty is that reserved characters have to be limited to a subset of ASCII or there is the possibility for encoding collisions that would require the syntax doc to specify its own encoding scheme. >C >> - The URN syntax doc says that URNs are sequences of CHARACTERS, >> drawn from the ISO 10646 set. > >> The tradeoffs are different for the 3 cases. This last one has most of the issues above. There are probably others that I haven't thought of, mainly because I don't claim to be an expert in the ins and outs of 7-bit and 8-bit friendliness. Having synopsized the plusses and minuses of these, there are some common issues: If we restrict the range of octets for the NSS (this is option A and option D) then a lot of the trasnport encoding, reserved character encoding and related issues go away. If we allow any octet (option B and C) then transport encoding becomes a minor issue and reserved character encoding must be considered. Everything else (to me right now at least) is related to presentation and meta-interpretation (by humans) of the NSS. I'm not sure if these should intrude into the syntax doc. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA19325 for urn-ietf-out; Tue, 12 Nov 1996 09:50:05 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA19320 for ; Tue, 12 Nov 1996 09:50:03 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00786 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 09:49:55 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA06815; Tue, 12 Nov 96 15:54:58 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA05259; Tue, 12 Nov 1996 15:49:40 +0100 Date: Tue, 12 Nov 1996 15:49:40 +0100 From: "Dirk.vanGulik" Message-Id: <9611121449.AA05259@ jrc.it> To: Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com Subject: Re: [URN] I18N does not belong in URNs Cc: urn-ietf@bunyip.com X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Dirk.vanGulik" Errors-To: owner-urn-ietf@bunyip.com > >The reason for _not_ allowing any octet in the string after urn: is to > >avoid entering into the dark realm of having to retrive MIB like display > >strings whenever you encounter a URN you've not seen before; and which > >you would like to display to a human in such a way he/she can still > >transcribe it. Just showing a list of two digit hex numbers would not do. > Realistically, how often should we expect a resource that we _can_ read to > be expressed by a URN that we can't read (i.e. the URN needs the %XX > encoding convention)? I would maintain that this would be the unusual case. > If (as an example) a Chinese information provider wished to make available > their resources to English speakers as URNs, I would suspect they would want > to provide "English-compatible" URNs, rather than long, seemingly random > %XX-encoded strings. Conversely (and for example), an Austrailian > information provider that wants to market their information to native Arabic > speakers (who are not necessarily English speakers) would want to provide > their URNs in an "Arabic-compatible" form, rather than the foreign-looking > English alphabet. Well, that would be an expectation of something which resembles 'URL's on steroids; my, personal, take on this is a bit different. We are seeing all sorts of collections being opened up; each with some kind of local identifier or control number; often closely tied to the language and habits of the -original- maintainers. A lot of the 'objects' in these collections have different views, depending on who you are, what you have paid, what your preferences and access permisisons are. So quite quickly you end up with the identifier of say a Technical Maintenance document of a, say, phillips KT52 TV frame or a the left wing SPL bolt installation a manual of a MD123 aeroplane. Which just happens to be avaible in quite a few languages. Although for the original maintainers there might be a language in which the local control identifier beared some relevance, but for most users that relation is gone (and it was based on obsuce 8 char abbreviattions anyway). > Although I would expect content-negotiation to be used on URNs, if the URN > resource is to be used widely by the native speaker of a language, it would > be better expressed in a form compatible with their native language. Yes; that is a common human desire; worth allowing for. Which means some kind of transcription of a reasonable number of languages and charset. Which still are compatible with all others. Hence my simplified (and optional) Base64 kind of encoding for name-schemes which need this. > Otherwise, we might as well go with sequences of random digits. Well; that is certainly what they conceptually could be to an 'alien' from Mars; or a native japanese only speaker. And there is nothign wrong with that. Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA19157 for urn-ietf-out; Tue, 12 Nov 1996 09:39:38 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA19152 for ; Tue, 12 Nov 1996 09:39:35 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00713 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 09:39:33 -0500 Received: by seawall with (8.6.12/) id JAA07356; Tue, 12 Nov 1996 09:39:27 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma007344; Tue Nov 12 09:39:09 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <32888C2E@MSMAIL.INDY.TCE.COM>; Tue, 12 Nov 96 09:39:42 EST From: Fisher Mark To: "Dirk.vanGulik" Cc: "girod@LCS.MIT.EDU" , "Harald.T.Alvestrand@uninett.no" , "mduerst@ifi.unizh.ch" , "moore@cs.utk.edu" , "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Subject: Re: [URN] I18N does not belong in URNs Date: Tue, 12 Nov 96 09:37:00 EST Message-Id: <32888C2E@MSMAIL.INDY.TCE.COM> Encoding: 26 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com >The reason for _not_ allowing any octet in the string after urn: is to >avoid entering into the dark realm of having to retrive MIB like display >strings whenever you encounter a URN you've not seen before; and which >you would like to display to a human in such a way he/she can still >transcribe it. Just showing a list of two digit hex numbers would not do. Realistically, how often should we expect a resource that we _can_ read to be expressed by a URN that we can't read (i.e. the URN needs the %XX encoding convention)? I would maintain that this would be the unusual case. If (as an example) a Chinese information provider wished to make available their resources to English speakers as URNs, I would suspect they would want to provide "English-compatible" URNs, rather than long, seemingly random %XX-encoded strings. Conversely (and for example), an Austrailian information provider that wants to market their information to native Arabic speakers (who are not necessarily English speakers) would want to provide their URNs in an "Arabic-compatible" form, rather than the foreign-looking English alphabet. Although I would expect content-negotiation to be used on URNs, if the URN resource is to be used widely by the native speaker of a language, it would be better expressed in a form compatible with their native language. Otherwise, we might as well go with sequences of random digits. ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA18370 for urn-ietf-out; Tue, 12 Nov 1996 08:12:35 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA18365 for ; Tue, 12 Nov 1996 08:12:32 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00226 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 08:12:28 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA03848; Tue, 12 Nov 96 14:17:28 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA05166; Tue, 12 Nov 1996 14:09:34 +0100 Date: Tue, 12 Nov 1996 14:09:34 +0100 From: "Dirk.vanGulik" Message-Id: <9611121309.AA05166@ jrc.it> To: Dirk.vanGulik@jrc.it, Harald.T.Alvestrand@uninett.no Subject: Re: [URN] I18N does not belong in URNs Cc: FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, mduerst@ifi.unizh.ch, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Dirk.vanGulik" Errors-To: owner-urn-ietf@bunyip.com Harald wrote: > There are about 3 alternatives I can see: A > - The URN syntax doc says that URNs are sequences of ASCII > characters (or some subset thereof) B > - The URN syntax doc says that URNs are sequences of OCTETS, > with no meaning assigned by the URN syntax doc after the > second : C > - The URN syntax doc says that URNs are sequences of CHARACTERS, > drawn from the ISO 10646 set. > The tradeoffs are different for the 3 cases. To extend on this, IMHO very sensible, concept: as it gives room to sensible wire definitions: D. Augmenting, case 'B'; The URN syntax docs says the URNs are sequences of OCTETS, whose value comes from a specific range '*' with no meaning assigned by the URN sysntax doc after the first four octets (which are the indexes of the glyphs 'u','r','n' and ':' in charset-XYZ.) Where the range '*' is; when each octed is taken as in index into charset-XYZ, is from the range (say) A-Z, 0-9, '_', '-', ":' and '.' I'd suggest ISO-8859, US-ASCII, NISO, etc for charset-XYZ. For each naming scheme an interpretation/casting can be defined for the part of the URN after the name-scheme-identifier. For the 'inet' (or x-dns-2) name-schme; the suggested interpretation is as indexes into 8 bit encoded 7bit ASCII (or ISO-8859-1 or whatever). Would that be of (some) use? The reason for _not_ allowing any octet in the string after urn: is to avoid entering into the dark realm of having to retrive MIB like display strings whenever you encounter a URN you've not seen before; and which you would like to display to a human in such a way he/she can still transcribe it. Just showing a list of two digit hex numbers would not do. Although overloading yet another DNS query type to get the display string could be fun on the 'display-string'.name-scheme.urn.net level :-) Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA14044 for urn-ietf-out; Mon, 11 Nov 1996 22:54:59 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA14039 for ; Mon, 11 Nov 1996 22:54:55 -0500 Received: from docker.library.uwa.edu.au by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27904 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 22:54:50 -0500 Received: from dehquhp.library.uwa.edu.au (dehquhp.library.uwa.edu.au [130.95.106.230]) by docker.library.uwa.edu.au (8.8.0/8.8.0) with ESMTP id LAA00225; Tue, 12 Nov 1996 11:54:27 +0800 (WST) Message-Id: <199611120354.LAA00225@docker.library.uwa.edu.au> From: "James K. Tauber" To: "David G. Durand" , Subject: Re: [URN] Readable Names (was: I18N does not belong in URNs) Date: Tue, 12 Nov 1996 11:55:20 +0800 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "James K. Tauber" Errors-To: owner-urn-ietf@bunyip.com > I think James Tauber (of Sun?) already has an FPI resolution > prototype operating. Formerly of Sun. Now back at the University of Western Australia. The fact that SP supports FPI resolution means that we now have a robust (human readable) namespace that is widely deployed, has a registration procedure (that's also widely deployed if you count ISBN owner identifiers) AND is resolvable here and now. James -- James K. Tauber / jtauber@library.uwa.edu.au University CWIS Coordination Officer The University of Western Australia Room 2.42, Scholars' Centre, Reid Library Phone: +61 9 380 7136 FAX: +61 9 380 1128 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA13396 for urn-ietf-out; Mon, 11 Nov 1996 21:49:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA13391 for ; Mon, 11 Nov 1996 21:49:18 -0500 Received: from CS.BU.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27663 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 21:49:17 -0500 Received: by cs.bu.edu (8.6.10/Spike-2.1) id VAA29804; Mon, 11 Nov 1996 21:49:11 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Nov 1996 21:54:29 -0500 To: urn-ietf@bunyip.com From: dgd@cs.bu.edu (David G. Durand) Subject: [URN] Readable Names (was: I18N does not belong in URNs) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: dgd@cs.bu.edu (David G. Durand) Errors-To: owner-urn-ietf@bunyip.com >Jim, > >URNs aren't supposed to be human-meaningful. Making them human-meaningful >defeats the purpose of having them be long-term stable. > >Keith Please, stop saying this. Repeating the same thing over and over again does not make it true. Read ISO 9070, or any book on SGML, for an example, of a namespace that falsifies your claim. You may prefer another style of URN, and no one will stop you from doing so, but the repeated _false_ assertion that such a namespace cannot exist is annoying. The fact that there is a namespace already deployed with reasonable social mechanisms to guarantee uniqueness and persistence is what really bugs me about this repeated assertion. The argument that typing the meaningful ASCII-subset string in FPIs as a hex-encoded byte sequence will improve reliability falls on its own merits, as far as I can see. I think James Tauber (of Sun?) already has an FPI resolution prototype operating. You have shown one thing in your previous arguments: that long-term persistence may impair long-term human-friendliness. Since this problem is as old as recorded history (Cuneiform was reader-friendly, once), I'm neither excited, surprised, or worried, about it. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA10935 for urn-ietf-out; Mon, 11 Nov 1996 16:48:51 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA10930 for ; Mon, 11 Nov 1996 16:48:32 -0500 Received: from aun.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26249 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 16:48:30 -0500 Received: from dale.uninett.no (actually trhm1.or.uninett.no) by aun.uninett.no with SMTP (PP); Mon, 11 Nov 1996 22:48:14 +0100 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id SAA25176; Mon, 11 Nov 1996 18:40:44 +0100 From: Harald.T.Alvestrand@uninett.no To: "Dirk.vanGulik" Cc: FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, mduerst@ifi.unizh.ch, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Mon, 11 Nov 1996 14:13:30 +0100." <9611111313.AA04245@ jrc.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <25172.847734044.1@dale.uninett.no> Date: Mon, 11 Nov 1996 18:40:44 +0100 Message-Id: <25174.847734044@dale.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com There are about 3 alternatives I can see: - The URN syntax doc says that URNs are sequences of ASCII characters (or some subset thereof) - The URN syntax doc says that URNs are sequences of OCTETS, with no meaning assigned by the URN syntax doc after the second : - The URN syntax doc says that URNs are sequences of CHARACTERS, drawn from the ISO 10646 set. The tradeoffs are different for the 3 cases. Harald Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA10902 for urn-ietf-out; Mon, 11 Nov 1996 16:47:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA10897 for ; Mon, 11 Nov 1996 16:47:18 -0500 Received: from info.cren.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26243 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 16:47:14 -0500 Received: from [192.52.179.12] (conklin-180c.cren.net [192.52.179.12]) by info.cren.net (8.6.6/8.6.4 (CREN)) with SMTP id QAA10245; Mon, 11 Nov 1996 16:45:17 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Nov 1996 16:46:28 -0500 To: Keith Moore , urn-ietf@bunyip.com From: conklin@info.cren.net (Jim Conklin) Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: conklin@info.cren.net (Jim Conklin) Errors-To: owner-urn-ietf@bunyip.com At 1:05 PM 11/11/96, Keith Moore wrote: >Jim, > >URNs aren't supposed to be human-meaningful. Making them human-meaningful >defeats the purpose of having them be long-term stable. > >Keith Keith, It may be just my slowness, but you haven't convinced me of that yet. Jim Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA09890 for urn-ietf-out; Mon, 11 Nov 1996 15:24:32 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA09885 for ; Mon, 11 Nov 1996 15:24:28 -0500 Received: from fssun10.dev.oclc.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25687 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 15:24:20 -0500 Received: from orc.NISOR (orc.dev.oclc.org) by oclc.org (4.1/SMI-4.1) id AA00924; Mon, 11 Nov 96 13:55:10 EST Received: by orc.NISOR (SMI-8.6/SMI-SVR4) id NAA20145; Mon, 11 Nov 1996 13:56:14 -0500 Date: Mon, 11 Nov 1996 13:56:14 -0500 From: stu_weibel@oclc.org (Stu Weibel) Message-Id: <199611111856.NAA20145@orc.NISOR> To: urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: stu_weibel@oclc.org (Stu Weibel) Errors-To: owner-urn-ietf@bunyip.com > From owner-urn-ietf@bunyip.com Mon Nov 11 13:22:32 1996 > Errors-To: owner-urn-ietf@bunyip.com > Errors-To: owner-urn-ietf@bunyip.com Keith Moore writes: > URNs aren't supposed to be human-meaningful. Making them human-meaningful > defeats the purpose of having them be long-term stable. This reflects a philosophy, an attitude, a point of view that is NOT shared in anything like a consensus in this group. I say again... this WG should adopt the *least restrictive* solution that is technologically sound and let people do with it what their communities choose. This group has no business enforcing naming philosophy on the applications or systems that will deploy URN solutions. stu Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA08599 for urn-ietf-out; Mon, 11 Nov 1996 13:11:01 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA08594 for ; Mon, 11 Nov 1996 13:10:58 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24677 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 13:10:54 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id NAA16172; Mon, 11 Nov 1996 13:05:41 -0500 (EST) Message-Id: <199611111805.NAA16172@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: conklin@info.cren.net (Jim Conklin) Cc: "Dirk.vanGulik" , FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, mduerst@ifi.unizh.ch, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Mon, 11 Nov 1996 11:59:15 EST." Date: Mon, 11 Nov 1996 13:05:41 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com Jim, URNs aren't supposed to be human-meaningful. Making them human-meaningful defeats the purpose of having them be long-term stable. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA08035 for urn-ietf-out; Mon, 11 Nov 1996 12:01:30 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA08028 for ; Mon, 11 Nov 1996 12:01:22 -0500 Received: from info.cren.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24143 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 12:01:18 -0500 Received: from [192.52.179.12] (conklin-180c.cren.net [192.52.179.12]) by info.cren.net (8.6.6/8.6.4 (CREN)) with SMTP id LAA09181; Mon, 11 Nov 1996 11:58:19 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Nov 1996 11:59:15 -0500 To: "Dirk.vanGulik" , FisherM@is3.indy.tce.com, moore@cs.utk.edu From: conklin@info.cren.net (Jim Conklin) Subject: Re: [URN] I18N does not belong in URNs Cc: girod@LCS.MIT.EDU, mduerst@ifi.unizh.ch, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: conklin@info.cren.net (Jim Conklin) Errors-To: owner-urn-ietf@bunyip.com.I've.been.trying.to.decide.how.one.might.allow.human-meaningful.URNs.for multiple languages and encodings, and it seems to me that this would be possible if and only if the URN identifier itself includes character-set information. Would it make sense to include in the definition of the URN format (yes, I know, this is past history!) an optional language and encoding specification which could then be used by sufficiently intelligent clients to display the URN in the specified language using the specified character encoding? Even the language and encoding could, in that way, be rendered in the specified language and, with a (relatively) small number of predefined languages and encodings, those could be specified in a small, universal symbol set, since they'd normally not be seen by the end user with a smart client. Jim Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA05578 for urn-ietf-out; Mon, 11 Nov 1996 08:14:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA05564 for ; Mon, 11 Nov 1996 08:14:24 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22095 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 08:14:15 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA14174; Mon, 11 Nov 96 14:19:03 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA04245; Mon, 11 Nov 1996 14:13:30 +0100 Date: Mon, 11 Nov 1996 14:13:30 +0100 From: "Dirk.vanGulik" Message-Id: <9611111313.AA04245@ jrc.it> To: FisherM@is3.indy.tce.com, moore@cs.utk.edu Subject: Re: [URN] I18N does not belong in URNs Cc: girod@LCS.MIT.EDU, mduerst@ifi.unizh.ch, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Dirk.vanGulik" Errors-To: owner-urn-ietf@bunyip.com > > > So, I see only 2 basic directions URN identifiers can go: > > > > 1) Totally opaque, random numeric strings; or > > > > 2) I18N character strings with appropriate encoding, > > preferably (IMHO) as UTF-8. > > > > There really is no middle ground -- if there is a pattern there, people will > > make use of it and screw up the system. > > As an example that there *is* middle ground, I suggest: > > 3) URNs are assigned by the "system" without regard to the content > that they name. (in other words, totally opaque, but not restricted to > numerals) > > This way, they can be composed of a larger character set without being > human meaningful. > > We can't restrict character sets too much because of the need to > grandfather existing URN spaces. > Or they use a naming scheme dependent interpretation. You could for example simply limit the representation of the URN to the glyphs A-Z, 0-9 and say the dot, dash, and colon. I recently came across a specific scheme, say 'crdis' which has a lot of LocalControlIdentfiers which can (only be fully) expressed in 2-byte octets. This obviously gave problems as some of our z39.50 servers and HTTP/URN resolving code did not quite like this. A pragmatic solution was to simply base64 encode the identfication string. A specialist GUI could now base64-decode the string to arrive at something meaningfull for a human. But it does not have to. And it does keep things simple. I really would like to roll up the charset discussion; I agree that for a lot of scheme's, in particular those to be grandfathered in, one will need very flexible encodings. But the internet transfer mechanisms are not quite up to that yet. So I would suggest: 1. Limit the URNs to just a few chars (along the lines of DNS) This also makes comparing URNs easy. 2. Allow, or perhaps even force, each registered naming scheme to suggest a possible encoding/escape sequencing to derive nice human names from the URN. This can be used by the more advanced GUIs. 3. And keep a few chars (say the %) in stock, for the future. 4. And remember, one can always make something like a next generation URN+:das:asd which can only be transcribed properly using say UTF8. or has its own charset/encoding/language triple. I know that such an encoding essentially wastes space; but that is a tradeoff I am willing to make for simplfied storage, encoding and comparing. Just my twohundred lires worth. Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA09891 for urn-ietf-out; Fri, 8 Nov 1996 09:26:29 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA09886 for ; Fri, 8 Nov 1996 09:26:27 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04842 (mail destined for urn-ietf@services.bunyip.com); Fri, 8 Nov 96 09:26:25 -0500 Message-Id: <9611081426.AA04842@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Fri Nov 8 08:24 CST 1996 From: "Ryan Moats" To: "Martin J Duerst" Cc: "moore@cs.utk.edu" , "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Date: Fri, 08 Nov 96 08:26:17 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] Almost an encoding agreement?! (was: I18N does not belong in Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Fri, 8 Nov 1996 15:18:59 +0100 (MET), Martin J Duerst wrote: >Ryan Moats wrote: > >>This look very similar to what is in the syntax draft now, with one exception >>(i.e. I like it but I see one "small" problem) >> >>If you go down this path, you need to ensure that if the namespace uses >>some octet in a reserved fasion, the character corresponding to the octet >>in ASCII would need to be %XX escaped when used in a literal sense. >>Further, unless you want real problems, we need to restrict the set of >>reserved characters to printable ASCII (minus some exceptions that get >>escaped already). > >We have been speaking about escaping characters before. Now you >speak about escaping octets. For ASCII, this may be the same, >but for UTF-8, it isn't. Oops, it looks like this was sloppy wording/thinking on my part... Octet == character above, but I got momentarily confused (so what else is new?) Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA09827 for urn-ietf-out; Fri, 8 Nov 1996 09:21:52 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA09822 for ; Fri, 8 Nov 1996 09:21:50 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04802 (mail destined for urn-ietf@services.bunyip.com); Fri, 8 Nov 96 09:21:28 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01030-0@josef.ifi.unizh.ch>; Fri, 8 Nov 1996 15:19:01 +0100 Subject: Re: [URN] Almost an encoding agreement?! (was: I18N does not belong in To: jayhawk@ds.internic.net Date: Fri, 8 Nov 1996 15:18:59 +0100 (MET) Cc: moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <9611072150.AA26126@mocha.bunyip.com> from "Ryan Moats" at Nov 7, 96 03:50:23 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1049 From: Martin J Duerst Message-Id: <"josef.ifi..836:08.10.96.14.19.09"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ryan Moats wrote: >This look very similar to what is in the syntax draft now, with one exception >(i.e. I like it but I see one "small" problem) > >If you go down this path, you need to ensure that if the namespace uses >some octet in a reserved fasion, the character corresponding to the octet >in ASCII would need to be %XX escaped when used in a literal sense. >Further, unless you want real problems, we need to restrict the set of >reserved characters to printable ASCII (minus some exceptions that get >escaped already). We have been speaking about escaping characters before. Now you speak about escaping octets. For ASCII, this may be the same, but for UTF-8, it isn't. Anyway, I guess it is okay to restrict reserved characters to an ASCII subset plus those characters that don't appear in the namespace in question and therefore don't have to be escaped. As an example for the later, "-" might be called a reserved character for ISBNs, but there is no need to escape it, because it doesn't appear in the ISBN proper. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA09100 for urn-ietf-out; Fri, 8 Nov 1996 08:22:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA09095 for ; Fri, 8 Nov 1996 08:22:12 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04531 (mail destined for urn-ietf@services.bunyip.com); Fri, 8 Nov 96 08:22:06 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00933-0@josef.ifi.unizh.ch>; Fri, 8 Nov 1996 14:20:17 +0100 Subject: Re: [URN] I18N does not belong in URNs To: moore@cs.utk.edu Date: Fri, 8 Nov 1996 14:20:16 +0100 (MET) Cc: tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611072109.QAA20758@ig.cs.utk.edu> from "Keith Moore" at Nov 7, 96 04:09:28 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5560 From: Martin J Duerst Message-Id: <"josef.ifi..453:08.10.96.13.20.21"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore wrote: >> >> So for grandfathering, we have two choices. >> >> >> >> 1) We interpret it as "direct grandfathering of characters", >> >> in which case we have to allow a really wide range >> >> of characters (i.e. ISO 10646). >> >> 2) We interpret it as "indirect grandfathering", in which >> >> case the digits, or whatever small set, will be >> >> enough. >> > >> >I suspect there will be some of each. >> >> I wouldn't mind "some of each", if this means "about the same >> amount for everybody on the world". If it comes to mean "a lot >> for English-speaking, but very little for the rest of the world", >> I would have to strongly disagree. > >Martin, > >Please accept that I agree with you here. I don't want Internet >information access protocols to be significantly biased in favor of >English speakers (or anybody else). > >I say "please accept" because if you accept that we substantially >agree on the above, it's a lot easier to understand the rest of what >I'm saying. I have no problems if you agree, of course :-). I just wanted to make sure that there was no misunderstanding. As for the rest of your mail, I agree to much of it. I am indifferent on the point of meaningfulness, but I leave the decision on that to those that care about it either way. >> You may agree with the above point, or you may disagree. But >> either way, ASCII only is unfair. If you think that naming >> schemes, protocols, standards, some review board, or whatever, >> can assure that no meaningful stuff is created, then there >> is no reason to restrict to ASCII. > >The working group needs to decide which is more important -- being >able to grandfather in existing URN-like name spaces from everywhere >on the planet, or having all URNs be transcribable by anyone on the >planet. I could certainly make a case for a subset of ASCII-only >based on the latter consideration. As I said, I would be ready to accept that, if it is a tight restriction of ASCII. The most of letters I would probably be ready to accept is A-F if we are going Hex. Of course, I would prefer it, for the benefit of everyone, if direct grandfathering would be choosen. >Perhaps the right thing to do is to define a mapping to be used when >grandfathering existing non-ASCII namespaces to URNs, i.e. to encode >the non-ASCII characters as UTF-8 and then encode each octet not >printable in ASCII using %XX notation. That way, people could still >type in resource names like they're accustomed to doing, but the >program they type them in to would convert them to canonical URN >format (by prepending URN:namespace: and doing the UTF-8 and %XX >encoding). For purposes of resolution, URNs would always be >transmitted in canonical format, but programs could decode the %XX and >UTF-8 for the purposes of display to humans. "always transmitted in canonical format" is a bit frightening, because it can make URNs unduely long in some cases. But in principle, I agree, and as Ryan has said, your proposal is just about the same as what the syntaxt draft currently says. >There's probably more than one organization in the world named ICRC. >The one your brother works for got ICRC.COM first, but the name is >still ambiguous. You could have as easily found the a different ICRC >than the one you were looking for. It's icrc.ORG. It is a true organization, not a company. Its name and especially its "logo", the red cross, are protected by special international treaties. It may be less known in the more peaceful regions of the world, though. Anyway, there was a chance that I would hit something else. But if I estimate that the chance is lower than 10%, and that it takes me 10 times more time to go through a search service, I will take the bet easily. For 10 things I look at, I will spend 20 time units that way. If I start with a search service just because I *might* be wrong, I will spend 100 time units for 10 lookups. >> If it can be that human-friendly, and that unambiguous, I don't know why >> I should go to a search service to find the ICRC. And I don't know >> why people that use other scripts should go though a serach service, >> while English speaking users don't have to do so. > >All names are unambiguous only within a limited context. When the net >was small, the context was inherently limited, so it didn't cause a >problem to have only one host for any given name. But now that the >net is much larger, it is a big problem. > >The whole huge mess over ownership of domain names, the InterNIC's >capriciousness in deciding who gets what domain within .COM, and all >of the hair-brained proposals to add tons of vanity-plate top-level >domains -- ALL of this is caused by the lack of support for >human-friendly names in the Internet infrastructure, and the resulting >misuse of DNS to do a job it wasn't designed to do. We're not going >to misuse URNs in the same way. I don't want URNs to be misused that way. But I, and many others, want something that can be used that way, without having to go through a search service when I see something on a cardboard box. >> No, but English can be used in URLs, and I get an unambigous >> result if there is one, in due time. In Japanese, even if the >> result would be unambiguous, I currently can't get it fast and >> easily. > >Which is better - an ambiguous result which is usually correct, or an >unambiguous result which is often incorrect? An unambiguous result which is often correct. This is what we have now. And I have made the calculations above. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA07587 for urn-ietf-out; Fri, 8 Nov 1996 04:10:27 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA07582 for ; Fri, 8 Nov 1996 04:10:25 -0500 From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03277 (mail destined for urn-ietf@services.bunyip.com); Fri, 8 Nov 96 04:10:19 -0500 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <03924-0@domen.uninett.no>; Fri, 8 Nov 1996 10:08:35 +0100 X-Mailer: exmh version 1.6.7 5/3/96 To: Daniel LaLiberte Cc: leslie@bunyip.com (Leslie Daigle), "Karen R. Sollins" , urn-ietf@bunyip.com Subject: Re: [URN] some comments In-Reply-To: Your message of "Thu, 07 Nov 1996 09:18:17 CST." <199611071518.JAA05599@ncsa.uiuc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Nov 1996 10:08:31 +0100 Message-Id: <3920.847444111@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com liberte@ncsa.uiuc.edu said: > Had I known we were going to be held to the details of the charter, I > would have spoken up at that time. But, honestly, would it have > mattered? You would certainly have gotten feedback, which might have led you to not bringing up this question now. I don't know if the charter would have changed. liberte@ncsa.uiuc.edu said: > But my whole point is that *because* the supposed difference between > URLs and URNs (the identifiers, not the resolution mechanisms) does > not exist, it is irrelevant to creating a solution, except for syntax > and other arbitrary constraints. The status quo is that unless the URN WG is able to do something about it, URLs are all that exist, and people will do what they have to do with them. So if you're right, you win by default. liberte@ncsa.uiuc.edu said: > >One of the things that we have to do, unfortunately, to get a > >solution to that limited problem, is to ask those who want to work on > >a different problem to leave. > So it has come to that, eh? As I've stated, we'll continue the > discussion off-line. But are you saying we shouldn't bother? No reason to go off-line; I suggest the former URI WG's list as a nice place to discuss the meta-issue of whether URNs are the right thing or not. If, in some other forum, the participants in this forum agree that what they are doing here won't work - fine; I'm sure I'll hear about it. But here - we are discussing how to make them work, and discussions on whether they are the right thing or not are not appropriate. liberte@ncsa.uiuc.edu said: > You should know that many experiments turn into standard practice. > If you want it to really be "just an experiment", perhaps you should > consider finding a way to kill it off afterwards so it doesn't escape > from the lab. :-) In the case of NAPTR, there's a simple way: Remove the urn.net domain from the root nameservers :-) But if it becomes standard practice, the experiment kind of succeeded, didn't it? Harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id DAA07499 for urn-ietf-out; Fri, 8 Nov 1996 03:49:18 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id DAA07494 for ; Fri, 8 Nov 1996 03:49:15 -0500 From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03184 (mail destined for urn-ietf@services.bunyip.com); Fri, 8 Nov 96 03:49:13 -0500 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <03364-0@domen.uninett.no>; Fri, 8 Nov 1996 09:46:58 +0100 X-Mailer: exmh version 1.6.7 5/3/96 To: Bob Briscoe Cc: Fisher Mark , "urn-ietf@bunyip.com" Subject: Re: [URN] Persistence as part of URN framework In-Reply-To: Your message of "Wed, 06 Nov 1996 17:39:57 GMT." <2.2.32.19961106173957.009f6a14@sherekhan.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Nov 1996 09:46:46 +0100 Message-Id: <3361.847442806@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com OK - I see what you mean. Five roles, all different: - URN assigner (guarantees uniqueness of URNs) - URN buyer (gets an URN to apply to his work) - URN referer (puts references to others' work using URN) - URN user (clicks on the URN reference) - URN resolver (makes magic happen for the URN user) The assigner and the buyer have to have some agreement; if the buyer assigns his own URL, the agreement should be easy :-) The resolver may be the assigner, or someone the assigner has an agreement with, or it may be someone (reference.com? archive.org? oclc?) that does the resolution without bothering to ask anyone about it. What you're looking for is some kind of "minimum guarantee" from the assigner/buyer to the referer about the quality of resolution services that will be present in the future. Right? Harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA04318 for urn-ietf-out; Thu, 7 Nov 1996 18:41:04 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA04313 for ; Thu, 7 Nov 1996 18:40:58 -0500 Received: from trapdoor.dstc.edu.au by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00245 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 18:40:54 -0500 Received: from fatcat.dstc.edu.au (fatcat.dstc.edu.au [130.102.176.7]) by trapdoor.dstc.edu.au (8.6.9/8.6.12) with ESMTP id JAA09556; Fri, 8 Nov 1996 09:40:51 +1000 Received: (from renato@localhost) by fatcat.dstc.edu.au (8.6.10/8.6.12) id JAA26466; Fri, 8 Nov 1996 09:40:51 +1000 From: Renato Iannella Message-Id: <199611072340.JAA26466@fatcat.dstc.edu.au> Date: Fri, 8 Nov 1996 09:40:50 +1000 (EST) To: rbriscoe@jungle.bt.co.uk Cc: urn-ietf@bunyip.com Subject: Re[4]: [URN] Resolution Services (N2L etc) In-Reply-To: <2.2.32.19961107093626.006c2f7c@sherekhan.jungle.bt.co.uk> X-Mailer: Ishmail 1.3-960829-osf1 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Renato Iannella Errors-To: owner-urn-ietf@bunyip.com Bob Briscoe wrote: > > So now, the URN resolution service is doing authentication of metadata too! You seem to have made the assumption that a URC is a big massive set of metadata (authenticated, secure etc) when in reality, a URC can be whatever _your_ organisation decides (ie BT = Happy) The URN stuff will support its resolution - the client will then do all the hard work. > > What I was complaining about is the apparent assumption that the same URN > would be used for both URN and URC and one would have to say N2C if you > wanted the former, and N2L for the latter. If you have a URC - which only has a URL in it - then doing either N2C or N2L will return that single URL. This will enable you to have a URN pointing directly to the resource (albeit, via a small URC), then a trusted-third party can provide the full descriptions etc... Cheers... Renato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dr Renato Iannella http://www.dstc.edu.au/RDU/staff/ri Research Data Network CRC urn:inet:dstc.edu.au:renato:home DSTC Pty Ltd, Uni Qld, 4072, AUSTRALIA phone/fax: +61 7 3365 4310/11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Australian WWW Technical Conference '97 -> http://www.dstc.edu.au/aw3tc Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA04045 for urn-ietf-out; Thu, 7 Nov 1996 18:02:35 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA04040 for ; Thu, 7 Nov 1996 18:02:31 -0500 Received: from CS.BU.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26943 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 18:02:28 -0500 Received: by cs.bu.edu (8.6.10/Spike-2.1) id SAA28165; Thu, 7 Nov 1996 18:02:24 -0500 Date: Thu, 7 Nov 1996 18:02:24 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: urn-ietf@bunyip.com From: dgd@cs.bu.edu (David G. Durand) Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: dgd@cs.bu.edu (David G. Durand) Errors-To: owner-urn-ietf@bunyip.com At 4:09 PM 11/7/96, Keith Moore wrote: >Please accept that I agree with you here. I don't want Internet >information access protocols to be significantly biased in favor of >English speakers (or anybody else). > >I say "please accept" because if you accept that we substantially >agree on the above, it's a lot easier to understand the rest of what >I'm saying. > >For the case of URNs, I have no problem with the idea that they should >not be friendly to English speakers -- because they really shouldn't >be freindly to anybody, except to be transcribable! > >On the other hand, we can hardly prohibit some rare and occasional >misuse of URNs such that human-friendly meaning creeps in. And we've >long since established the need to grandfather in existing name spaces >that have the characteristics of URNs. Some of those name spaces are >going to have some minimal human-friendliness, some degree of meaning >exposed in the names. But there won't be much human-friendliness in >any name space that gets grandfathered in, as any naming scheme which >tries to embed lots of meaning in the names will inherently have poor >persistence and thus be unsuitable for URNs. I am tired of your repeating this. I have pointed out that the URN space of ISO Formal public identifiers is human-friendly (to English speakers, and you can bet the revision will be to the rest of the world). Those identifiers are assigned according to rules that are supposed to guarantee uniqueness. As they are in common productive use in the SGML world (which certainly has a significant relationship to the WWW) is a reason that they will be grandfathered in. So your assertion is simply _false_. So, now given that FPIs will be English-speaker friendly, and grandfathered into URN-space, what do you propose to do about it? I have worries about I18N becuase it seems to fail the transcribability test (for arbitrary transcribers) -- but I don't want to be a cultural imperialist, and I don't see any special virtue in ASCII other than omnipresence. Creating "unfriendly" namespaces may seem good practice to you, but I don't see how it can be mandatory, no matter how much you wish it to be so. >I agree that it may be difficult to get most people to understand that >URNs are not human-friendly names (since it's been difficult to do >even within this WG). I think it's an unreasonable requirement. That's why it's so hard to convince people of it. >Perhaps the right thing to do is to define a mapping to be used when >grandfathering existing non-ASCII namespaces to URNs, i.e. to encode >the non-ASCII characters as UTF-8 and then encode each octet not >printable in ASCII using %XX notation. That way, people could still >type in resource names like they're accustomed to doing, but the >program they type them in to would convert them to canonical URN >format (by prepending URN:namespace: and doing the UTF-8 and %XX >encoding). For purposes of resolution, URNs would always be >transmitted in canonical format, but programs could decode the %XX and >UTF-8 for the purposes of display to humans. So what does this get other than harder-to-debug network protocols? If we define a standard translation, and make sure that it's an equivalence relation (as seems to be required), then why not just transmit it the normal way. Once it can be seen in meaningful form, it _will_ be transmitted that way from human to human, regardless of any numericalization we try to impose. > >There's probably more than one organization in the world named ICRC. >The one your brother works for got ICRC.COM first, but the name is >still ambiguous. You could have as easily found the a different ICRC >than the one you were looking for. But once the name is assigned, you will never get the other ICRC.COM, so it doesn't matter. Even if one of the ICRCs goes out of business, ICRC.COM will not be reassigned. So no problem! The ISO naming rules (simple hierarchy, with well known roots) already can ensure this. >All names are unambiguous only within a limited context. When the net >was small, the context was inherently limited, so it didn't cause a >problem to have only one host for any given name. But now that the >net is much larger, it is a big problem. The only context that matters is the policies that we set up of URN management. Once a subset of the namespace is assigned it can't be reassigned. >Part of this is because you'll already be restricting the context of >the search -- if you're looking for the name of a business >organization, you'll go to a service that matches user-friendly names >against names of businesses. If you're looking for a person's name, >you'll use a different service. If URNs are assigned to have the properties of URNs they will still be persistent. No-one is arguing that URNs should be designed to be meaningfully searched, just that they may be designed to be meaningfully remembered. If your memory fails or your attempt to deduce things from other names you have seen fails, then you just have to find the right name (maybe via some kind of directory search). Obscure names are obscure, but they are not any more reliable for that. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA03946 for urn-ietf-out; Thu, 7 Nov 1996 17:48:44 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA03941 for ; Thu, 7 Nov 1996 17:48:42 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26677 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 17:48:36 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id RAA14420; Thu, 7 Nov 1996 17:48:34 -0500 Message-Id: <199611072248.RAA14420@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Thu, 7 Nov 1996 17:48:33 -0500 In-Reply-To: Daniel LaLiberte's message as of Nov 7, 15:25 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: urn-ietf@bunyip.com Subject: [URN] Enough, already. Cc: Harald.T.Alvestrand@uninett.no Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Okay, all else has failed... I would like ot request that anyone who has the interests of seeing this work move forward take a BREATHER from this topic -- call it an early weekend. There is much left to be discussed about a number of different issues -- of the things that have been discussed, some bear relevance to the work of this group and should be dealt with in an orderly fashion. As Karen mentioned, she is working on revised framework and requirements material, and that should provide a good focus for meaty discussions, when it is available. Let's wait a bit, rather than just chasing the theoretical around in circles -- that does not do justice to the opinions and viewpoints of anyone. Leslie. URN WG Co-Chair. -- ---------------------------------------------------------------------------- "The light at the end of the tunnel Leslie Daigle is often the blindingly obvious..." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA03508 for urn-ietf-out; Thu, 7 Nov 1996 16:50:09 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA03503 for ; Thu, 7 Nov 1996 16:50:07 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26126 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 16:50:03 -0500 Message-Id: <9611072150.AA26126@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Thu Nov 7 15:48 CST 1996 From: "Ryan Moats" To: "Keith Moore" , "Martin J Duerst" Cc: "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Date: Thu, 07 Nov 96 15:50:23 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] Almost an encoding agreement?! (was: I18N does not belong in URNs) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Thu, 07 Nov 1996 16:09:28 -0500, Keith Moore wrote: >Perhaps the right thing to do is to define a mapping to be used when >grandfathering existing non-ASCII namespaces to URNs, i.e. to encode >the non-ASCII characters as UTF-8 and then encode each octet not >printable in ASCII using %XX notation. That way, people could still >type in resource names like they're accustomed to doing, but the >program they type them in to would convert them to canonical URN >format (by prepending URN:namespace: and doing the UTF-8 and %XX >encoding). For purposes of resolution, URNs would always be >transmitted in canonical format, but programs could decode the %XX and >UTF-8 for the purposes of display to humans. Keith- This look very similar to what is in the syntax draft now, with one exception (i.e. I like it but I see one "small" problem) If you go down this path, you need to ensure that if the namespace uses some octet in a reserved fasion, the character corresponding to the octet in ASCII would need to be %XX escaped when used in a literal sense. Further, unless you want real problems, we need to restrict the set of reserved characters to printable ASCII (minus some exceptions that get escaped already). Is this acceptable? Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA03462 for urn-ietf-out; Thu, 7 Nov 1996 16:44:40 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA03457 for ; Thu, 7 Nov 1996 16:44:37 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26068 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 16:44:29 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id QAA06044; Thu, 7 Nov 1996 16:43:31 -0500 (EST) Message-Id: <199611072143.QAA06044@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Daniel LaLiberte Cc: Keith Moore , "Gregory J. Woodhouse" , urn-ietf@bunyip.com, uri@union.ncsa.uiuc.edu Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: Your message of "Thu, 07 Nov 1996 15:25:35 CST." <199611072125.PAA13247@ncsa.uiuc.edu> Date: Thu, 07 Nov 1996 16:43:31 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > > I believe the URN: prefix is essential, but not for this reason. As > > I've said before, the difference between URNs and URLs should have > > more to do with the properties of each name space than how they are > > resolved. > > But the properties of an identifier that are visible to a client (from > the user's perspective, that's all that matters) really come from the > properties of the resolution service. No, the properties of URNs have more to do with the way the name is *assigned* and the discipline that's used to bind the name to the resource, than with how the name is resolved. The resolution services can be substantially the same for URNs and URLs. > Declared properties don't > matter if they end up being untrue. If a URL can be made to behave > persistently by using the URI resolution service as you described (not > me this time!), then is it not behaving like a name (at least > regarding persistence)? Yes. You can have URLs that happen to be persistent. But you can't define a part of URL-space to be persistent. You can have a resolution service that returns a "persistence" bit, but that's not the same thing, because that bit could be turned on or off at any time. The persistence property of a URN cannot be changed; that's why the fact that the name is persistent is encoded in the name itself. To some degree, all of these are social conventions. We want to visually distinguish URNs from URLs because we want humans to use them differently. This requires that they realize that they are (at least in how they are used) very different things. > But if a URL has been made to behave persistently by using the URI > resolution service, isn't it just as good as a URN? Furthermore, I > would think it would be advantageous for everyone to start registering > their http URLs (or servers) in the URI tree, so eventually there > would no longer be a question about whether http URLs are persistent - > they all would be. No, there will always be resources and resource names that aren't guaranteed to be persistent. URNs are the special case, not the general case. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA03343 for urn-ietf-out; Thu, 7 Nov 1996 16:31:06 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA03338 for ; Thu, 7 Nov 1996 16:31:04 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25915 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 16:30:59 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id PAA13247; Thu, 7 Nov 1996 15:25:35 -0600 (CST) Date: Thu, 7 Nov 1996 15:25:35 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611072125.PAA13247@ncsa.uiuc.edu> To: Keith Moore Cc: "Gregory J. Woodhouse" , Daniel LaLiberte , urn-ietf@bunyip.com, uri@union.ncsa.uiuc.edu Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: <199611071956.OAA03504@ig.cs.utk.edu> References: <199611071956.OAA03504@ig.cs.utk.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Hey, you guys are still at it. I don't mind, but apparently others do. I'll be brief and again refer the reader to http://union.ncsa.uiuc.edu/HyperNews/get/www/URIs.html. Keith Moore writes: > I think there's a problem with terminology here. A glossary would help, but here is my standard warning: don't let definitions box you in a corner conceptually. > I believe the URN: prefix is essential, but not for this reason. As > I've said before, the difference between URNs and URLs should have > more to do with the properties of each name space than how they are > resolved. But the properties of an identifier that are visible to a client (from the user's perspective, that's all that matters) really come from the properties of the resolution service. Declared properties don't matter if they end up being untrue. If a URL can be made to behave persistently by using the URI resolution service as you described (not me this time!), then is it not behaving like a name (at least regarding persistence)? > But human beings need to be able to distinguish between a URN and a > URL. That way, they can tell a stable, persistent resource identifier > from a resource location. But if a URL has been made to behave persistently by using the URI resolution service, isn't it just as good as a URN? Furthermore, I would think it would be advantageous for everyone to start registering their http URLs (or servers) in the URI tree, so eventually there would no longer be a question about whether http URLs are persistent - they all would be. But during the transition, how hard would it be for the user-author of a document referencing another document to find out if one URL is persistent whereas another one is not? -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA03233 for urn-ietf-out; Thu, 7 Nov 1996 16:18:23 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA03228 for ; Thu, 7 Nov 1996 16:18:20 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25777 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 16:18:04 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id QAA04987; Thu, 7 Nov 1996 16:16:56 -0500 (EST) Message-Id: <199611072116.QAA04987@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Fisher Mark Cc: "girod@LCS.MIT.EDU" , Martin J Duerst , "moore@cs.utk.edu" , "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Thu, 07 Nov 1996 10:00:00 EST." <3281FA09@MSMAIL.INDY.TCE.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Nov 1996 16:16:56 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > So, I see only 2 basic directions URN identifiers can go: > > 1) Totally opaque, random numeric strings; or > > 2) I18N character strings with appropriate encoding, > preferably (IMHO) as UTF-8. > > There really is no middle ground -- if there is a pattern there, people will > make use of it and screw up the system. As an example that there *is* middle ground, I suggest: 3) URNs are assigned by the "system" without regard to the content that they name. (in other words, totally opaque, but not restricted to numerals) This way, they can be composed of a larger character set without being human meaningful. And there are other ways of providng the same feature. We can't restrict character sets too much because of the need to grandfather existing URN spaces. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA03181 for urn-ietf-out; Thu, 7 Nov 1996 16:15:17 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA03176 for ; Thu, 7 Nov 1996 16:15:13 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25756 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 16:14:43 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id QAA20758; Thu, 7 Nov 1996 16:09:28 -0500 (EST) Message-Id: <199611072109.QAA20758@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Thu, 07 Nov 1996 18:15:34 +0100." <"josef.ifi..235:07.10.96.17.15.36"@ifi.unizh.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Nov 1996 16:09:28 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > >> So for grandfathering, we have two choices. > >> > >> 1) We interpret it as "direct grandfathering of characters", > >> in which case we have to allow a really wide range > >> of characters (i.e. ISO 10646). > >> 2) We interpret it as "indirect grandfathering", in which > >> case the digits, or whatever small set, will be > >> enough. > > > >I suspect there will be some of each. > > I wouldn't mind "some of each", if this means "about the same > amount for everybody on the world". If it comes to mean "a lot > for English-speaking, but very little for the rest of the world", > I would have to strongly disagree. Martin, Please accept that I agree with you here. I don't want Internet information access protocols to be significantly biased in favor of English speakers (or anybody else). I say "please accept" because if you accept that we substantially agree on the above, it's a lot easier to understand the rest of what I'm saying. For the case of URNs, I have no problem with the idea that they should not be friendly to English speakers -- because they really shouldn't be freindly to anybody, except to be transcribable! On the other hand, we can hardly prohibit some rare and occasional misuse of URNs such that human-friendly meaning creeps in. And we've long since established the need to grandfather in existing name spaces that have the characteristics of URNs. Some of those name spaces are going to have some minimal human-friendliness, some degree of meaning exposed in the names. But there won't be much human-friendliness in any name space that gets grandfathered in, as any naming scheme which tries to embed lots of meaning in the names will inherently have poor persistence and thus be unsuitable for URNs. Still, it's a judgement call as to whether a particular name space fits in URN space. In making such a judgement, what matters is the overall characteristics of the name space, not which characters are and aren't allowed. > >> Choosing ASCII only as for URLs would be very unfair cheating. > > > >If the names aren't human meaningful, I don't see what you're > >complaining about. > > If I were sure the names would not be meaningful, I would not > have much reason to complain. But the URL example shows that > restricting people from becomming meaningful is very hard if > not impossible. A lot of people "publish" things on the web by simply editing files in a particular directory; the URLs for those files are derived from their filenames. We can hardly expect people to assign meaningless names to files that they edit, and few people (outside the information sciences world) understand the virtue in using meaningless resource names. I agree that it may be difficult to get most people to understand that URNs are not human-friendly names (since it's been difficult to do even within this WG). This is part of why I think the URN: prefix is important (so that URNs are easily distinguished from URLs). It's also important to promote early use of the URN: prefix for existing non-friendly name spaces (so people get used to seeing URN: followed by gibberish). Finally, new URN spaces are going to require some restrictions about how those URNs are defined. (In both RCDS and the CNRI handle system, resource names aren't chosen by users -- you ask the system to create one and it gives it back to you.) Despite all of this, I'm sure that a few human-friendly URNs will creep in somewhere. But what's important is that URNs won't be generally useful as a means to define human-friendly names -- the case where a URN is human-friendly will be the odd exception rather than the rule. (I'm reminded of RFC numbers which are generally assigned in sequence, but occasionally are chosen to be easily remembered -- so RFC XX00 is often an "assigned numbers" RFC. My favorite example is RFC 1984.) > You may agree with the above point, or you may disagree. But > either way, ASCII only is unfair. If you think that naming > schemes, protocols, standards, some review board, or whatever, > can assure that no meaningful stuff is created, then there > is no reason to restrict to ASCII. The working group needs to decide which is more important -- being able to grandfather in existing URN-like name spaces from everywhere on the planet, or having all URNs be transcribable by anyone on the planet. I could certainly make a case for a subset of ASCII-only based on the latter consideration. Perhaps the right thing to do is to define a mapping to be used when grandfathering existing non-ASCII namespaces to URNs, i.e. to encode the non-ASCII characters as UTF-8 and then encode each octet not printable in ASCII using %XX notation. That way, people could still type in resource names like they're accustomed to doing, but the program they type them in to would convert them to canonical URN format (by prepending URN:namespace: and doing the UTF-8 and %XX encoding). For purposes of resolution, URNs would always be transmitted in canonical format, but programs could decode the %XX and UTF-8 for the purposes of display to humans. > One should assume that Japanese, Russians, Chinese, or whoever, can > be as disciplined, or as tighly controlled, as the English-speaking > part of the world. On the other hand, if you think that namespaces > will get meaningful because of people's nature, and you think it is > a bad thing that has to be avoided, there is no other choice but to > limit ourselves to the decimal digits and maybe two or three other > characters. We can discourage putting human-friendly names in URNs by the methods I mentioned above. Also, since URI resolution will work for either URNs or URLs, there will be no reason to insist that a name be in URN space just so it can have resolution. So the only people who will assign URNs will be those who really want long-term persistent and ugly resource names. (At least this is what I hope will happen.) > But there can be a great deal of human-friendliness, > without any need for ambiguity. URLs such as http://www.ibm.com > or http://www.icrc.org are examples. My brother, who works at ICRC in > Geneva, recently called me. Before he was able to tell me how I could > reach him by email, I had the ICRC home page on my browser, and had > found the generic email address explanations, and had sent him a mail. There's probably more than one organization in the world named ICRC. The one your brother works for got ICRC.COM first, but the name is still ambiguous. You could have as easily found the a different ICRC than the one you were looking for. (I keep getting tripped up when I visit the web page of Global Business Network -- which is www.gbn.ORG. www.GBN.COM is somebody else.) This is only going to get worse as more companies get on the Internet. > If it can be that human-friendly, and that unambiguous, I don't know why > I should go to a search service to find the ICRC. And I don't know > why people that use other scripts should go though a serach service, > while English speaking users don't have to do so. All names are unambiguous only within a limited context. When the net was small, the context was inherently limited, so it didn't cause a problem to have only one host for any given name. But now that the net is much larger, it is a big problem. The whole huge mess over ownership of domain names, the InterNIC's capriciousness in deciding who gets what domain within .COM, and all of the hair-brained proposals to add tons of vanity-plate top-level domains -- ALL of this is caused by the lack of support for human-friendly names in the Internet infrastructure, and the resulting misuse of DNS to do a job it wasn't designed to do. We're not going to misuse URNs in the same way. > > >> And I don't want to have to search through long lists > >> of possible answers just because I use Japanese, whereas > >> I will get one immediate answer for English. > > > >The point is that you will often get multiple answers for English. > >English names are no more precise than names in other languages. > > No, but English can be used in URLs, and I get an unambigous > result if there is one, in due time. In Japanese, even if the > result would be unambiguous, I currently can't get it fast and > easily. Which is better - an ambiguous result which is usually correct, or an unambiguous result which is often incorrect? The number of names you get back from a search of a user-friendly name is related to how ambiguous the name is. If the name you give is relatively unambiguous, you'll only get a few names back. "Kodak" (a name explicitly chosen to be globally unique) will give you relatively few hits, while "Acme" (a very common brand name) will give you far more. Part of this is because you'll already be restricting the context of the search -- if you're looking for the name of a business organization, you'll go to a service that matches user-friendly names against names of businesses. If you're looking for a person's name, you'll use a different service. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA02084 for urn-ietf-out; Thu, 7 Nov 1996 14:57:44 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA02077 for ; Thu, 7 Nov 1996 14:57:34 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24765 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 14:57:01 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id OAA03504; Thu, 7 Nov 1996 14:56:34 -0500 (EST) Message-Id: <199611071956.OAA03504@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Gregory J. Woodhouse" Cc: Daniel LaLiberte , Keith Moore , urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: Your message of "Thu, 07 Nov 1996 09:47:38 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Nov 1996 14:56:33 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > It still seems to me that the issues is one of mechanics. It seems fine to > specify that the namespaces http:, ftp:, gopher:, etc. are reserved for > URLs so that a client knows a priori that when it sees > > http://foo.bar.com/ > > it knows it only need connect to foo.bar.com and retrieve the resource. > But without doing such a check, the client would have to assume the above > URI *could* be a URN and attempt to resolve it. I think there's a problem with terminology here. We have essentially two separate efforts going on here: (1) defining what URNs look like and how they are used, and (2) defining a mechanism for URI resolution. 1. URNs are a name space with the properties defined in RFC 1737. Strictly speaking, an http URL can never be a URN, since http as a name space isn't constrained to have those properties. 2. The URI resolution mechanism isn't limited to URNs -- it can also be used to resolve many types of URLs. So in the example above, the client doesn't have to know whether http://foo.bar.com/ is a URN or not to know if it can resolve the name. The client can simply attempt to apply URI resolution to the URL. If it succeeds, it can use any of the services returned by the resolution process. If the URI resolution fails, it can fall back to talking to the http server at foo.bar.com. > A separate issue is whether the above URI could represent different > resources when interpereted as a URL or a URN. A URI is either a URL or URN or something; it cannot be both a URL or a URN. As for "interpretation" of an http URL under URI resolution, this isn't a problem: a URL beginning with "http:" will always be resolved the same way. Of course it is "possible" for the resource pointed to by a URL and the resource you get from resolving that URL with URI resolution will be different. But this is no different from the situation we have today -- if the domain in a URL has multiple IP addresses pointing to multiple servers and those servers are not in synch. > Finally, a possible design is to have the above URI be both a URL and a > URN. By this, I mean that whatever service is responsible for resolving URNs > will recognize and deal appropriately with namespaces such as http:. But it > is obviously desirable not to have to go through the process of resolving a > URN just to get back a URL that is identical to the original URN. Well, this seems wasteful, but I submit that it really is desirable. The client doesn't know in advance whether resolution is available for a particular URL; it has to do a DNS lookup (or consult some other resolution service) to find out. As long as the client is attempting to do resolution anyway, it doesn't hurt for the resolution server to return a single URL - even one that matches the original. And there is a major win here -- if the demand for the resource named by the URL increases, the provider can simply replicate the resource on additional servers, tell the resolution server about it, and clients will find them. > Now, if I'm missing something fundamental, by all means tell me, but this > seems like a real issue to me. It seems that omitting the urn: prefix would > not break anything (unless of course a URI is allowed to have different > referents depending upon whether or not it is a URN), but it may still be > useful, just as it may be useful to have a url: prefix for URIs that are in > fact URLs. I believe the URN: prefix is essential, but not for this reason. As I've said before, the difference between URNs and URLs should have more to do with the properties of each name space than how they are resolved. That is, we need similar resolution mechanisms for URNs (to provide persistence, longevity, global scope) as for URLs (to provide redundancy, scalability, and fault-tolerance...which are desirable for URNs as well). But human beings need to be able to distinguish between a URN and a URL. That way, they can tell a stable, persistent resource identifier from a resource location. For instance, if you're writing a paper and you need to put references to other works, those references should be URNs, rather than URLs, whenever possible. Advertising a URL for a resource says nothing about its longevity or persistence; advertising a URN for a resource is an indication that the URN will always point to that resource (if the resource is available). Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA01593 for urn-ietf-out; Thu, 7 Nov 1996 14:07:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA01588 for ; Thu, 7 Nov 1996 14:07:17 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24191 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 14:06:45 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01228-0@josef.ifi.unizh.ch>; Thu, 7 Nov 1996 20:04:04 +0100 Subject: [URN] Re: Comments on "I18N does not belong in URNs" To: jayhawk@ds.internic.net (Ryan Moats) Date: Thu, 7 Nov 1996 20:04:03 +0100 (MET) Cc: moore@cs.utk.edu, urn-ietf@bunyip.com, tallen@fsc.fujitsu.com, girod@LCS.MIT.EDU In-Reply-To: <3280B0E8.6AF9@ds.internic.net> from "Ryan Moats" at Nov 6, 96 09:38:16 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1982 From: Martin J Duerst Message-Id: <"josef.ifi..635:07.10.96.19.04.05"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ryan Moats wrote: >Terry Allen commented (|): > >|That's an argument specifically against using UTF-8 at all. I'd >|like to hear more on this point from the UTF-8 proponents. > >Martin Duerst replied (@): > >@Also, the URN syntax draft clearly specifies how URNs are >@transported over 7-bit channels (using %HH). This works for >@URLs, there is no reason it shouldn't work for URNs. >@ >@So I really wonder where there should be a problem. > >Well, this is not exactly the way I interpret the syntax draft. >Section 3 of the draft states that encoding URNs for transport >is the responsibility of the transport protocol. The implied statement >is that the transport protocol is responsible for undoing the >encoding. I guess you should better make this more explicit. Anyway, %HH escaping is always available, and will work with email and other 7-bit-challenged protocols. >The encoding section is there in the case of encoding >that the URN resolver has to undo itself. What I wonder (and >am looking for some consesus on) is: "Is this necessary?" >Also, the %HH escaping technique does have some problems with UTF-8 >as Martin has pointed out on another thread... If we really want to focus on non-meaningful, ISBN-like stuff, then there is no problem, because the namespace itself will always be restricted to a fairly small character set, even if this is drawn from full Unicode/ISO 10646. This point can be slightly extended: Because Unicode/ISO 10646 is such a huge collection of characters, the chances that a namespace has to use all of them PLUS some more for structure are much smaller than with ASCII. They will only occur in those cases that we already have with ASCII, i.e. when we speak about devices (computers) that represent characters with Unicode. Real-world namespaces, such as the names of emperors or plays, or whatever, even in native notation for each of these, never will use such oddities as Zapf Dingbats in their names. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA01271 for urn-ietf-out; Thu, 7 Nov 1996 13:36:42 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA01237 for ; Thu, 7 Nov 1996 13:36:39 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23912 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 13:36:38 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id NAA10430; Thu, 7 Nov 1996 13:36:37 -0500 Date: Thu, 7 Nov 1996 13:36:37 -0500 Message-Id: <199611071836.NAA10430@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: Harald.T.Alvestrand@uninett.no, urn-ietf@bunyip.com In-Reply-To: <26912.847376443@domen.uninett.no> (Harald.T.Alvestrand@uninett.no) Subject: Re: [URN] some comments Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com Let me follow up Harald's comment with a note about the IRTF. Abel Weinrib is the chair of the IRTF and is very open to suggestions for new WGs in that context that want to explore more open ended questions. In fact there were 2 WGs formed last year on related topics. The one I chair is on an Internet Information Architecture. It is a closed group at present, but one of our threads of discussion is about how to open up the process to a wider community. I will certainly report further on that as we make progress. The other group is chaired by Cecilia Preston and my recollection is that the focus of that is metadata. I have no idea about the nature of their work. But, let me urge you, if you would like to form a group to work on something related to IETF activities, but more open-ended, to talk with Abel about it. I also recommend to you the recent RFC 2014 on the subject of the IRTF. Karen Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA01085 for urn-ietf-out; Thu, 7 Nov 1996 13:29:26 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA01077 for ; Thu, 7 Nov 1996 13:29:23 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23814 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 13:29:21 -0500 Message-Id: <9611071829.AA23814@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Thu Nov 7 12:27 CST 1996 From: "Ryan Moats" To: "Daniel LaLiberte" , "Harald.T.Alvestrand@uninett.no" , "Peter Deutsch" Cc: "Karen R. Sollins" , "Leslie Daigle" , "urn-ietf@bunyip.com" Date: Thu, 07 Nov 96 12:29:08 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] some comments Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Thu, 7 Nov 1996 11:50:05 -0500, Peter Deutsch wrote: >I think I understand the thrust of your argument, and if >not for the past four or five years of history, I'd agree >wholeheartedly that we need to remain open to change. > >Unfortunately, as someone who has been monitoring and >(before I was called away by my accountants) participating >in this debate pretty much since its inception, I'd have >to echo Karen's concerns. > >You are right - if bits or pieces turn out to be broken in >RFC 1737, then they should to be fixed. That's simply good >engineering. The problem I see, and I suspect that Karen >was attempting to address, is that there exist the danger >that in leaving open the possibility of modifying RFC >1737, at least some people will take it a mandate to fix >not just broken specifics, but the conceptual model >itself. This has been happening since the beginning of >this work and it's getting old. I fully agree with this. It was not my intent to break the whole structure, just fiddle with bits of it if necssary as we move forward. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA00853 for urn-ietf-out; Thu, 7 Nov 1996 13:12:22 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA00848 for ; Thu, 7 Nov 1996 13:12:16 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23650 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 13:12:15 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id NAA10377; Thu, 7 Nov 1996 13:12:14 -0500 Date: Thu, 7 Nov 1996 13:12:14 -0500 Message-Id: <199611071812.NAA10377@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: urn-ietf@bunyip.com Subject: [URN] requirements - see draft-girod-urn-res-req-00.txt Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com I suggest that you consider draft-girod-urn-res-req-00.txt, in which we identify a number of requirments for URN resolution services. For some reason it didn't make it onto the web page for the URN WG set up by the IETF. In addition, the framework paper suggests a few requirements, but is not explicit enough. I am now working a requirements/framework paper based on both of these, plus what I can cull from the discussions since the group has been set up. The requirements paper is the one we presented at the BOF in Montreal. The later sections of the paper discuss particular resolution schemes and are at this point outdated, but I believe that what we said in the requirements section is important for this group and must be said in some document we publish. Without stating explicitly the requirements for URN resolution services it is impossible to evaluate whether or not any particular scheme is what is needed. (Bob Briscoe you seem to be asking for this especially.) In addition to its being available from internet drafts it is also available from our anonymous ftp server (mercury.lcs.mit.edu:/pub/sollins/draft-girod-urn-res-req-00.txt). Karen Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA00691 for urn-ietf-out; Thu, 7 Nov 1996 13:04:14 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA00686 for ; Thu, 7 Nov 1996 13:04:12 -0500 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23567 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 13:04:10 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.8.2/8.7.3) with SMTP id JAA16220; Thu, 7 Nov 1996 09:47:38 -0800 (PST) Date: Thu, 7 Nov 1996 09:47:38 -0800 (PST) From: "Gregory J. Woodhouse" To: Daniel LaLiberte Cc: Keith Moore , urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: <199611071646.KAA07336@ncsa.uiuc.edu> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com It still seems to me that the issues is one of mechanics. It seems fine to specify that the namespaces http:, ftp:, gopher:, etc. are reserved for URLs so that a client knows a priori that when it sees http://foo.bar.com/ it knows it only need connect to foo.bar.com and retrieve the resource. But without doing such a check, the client would have to assume the above URI *could* be a URN and attempt to resolve it. In a sense, this isn't a huge restriction because the client needs to know how to retrieve resources specified by a URL, anyway, so it must know which namespaces are possible. A separate issue is whether the above URI could represent different resources when interpereted as a URL or a URN. This is, of course, only possible if the same namespace can have multiple semantics, and my understanding is that this is not the case, but to be honest, I don't see where this is spelled out. Finally, a possible design is to have the above URI be both a URL and a URN. By this, I mean that whatever service is responsible for resolving URNs will recognize and deal appropriately with namespaces such as http:. But it is obviously desirable not to have to go through the process of resolving a URN just to get back a URL that is identical to the original URN. (In the case of NAPTR we could have an N2R resolution, but then scalability issues come to mind.) Now, if I'm missing something fundamental, by all means tell me, but this seems like a real issue to me. It seems that omitting the urn: prefix would not break anything (unless of course a URI is allowed to have different referents depending upon whether or not it is a URN), but it may still be useful, just as it may be useful to have a url: prefix for URIs that are in fact URLs. --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/home.html resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA00212 for urn-ietf-out; Thu, 7 Nov 1996 12:18:10 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA00207 for ; Thu, 7 Nov 1996 12:18:08 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23013 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 12:17:24 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00910-0@josef.ifi.unizh.ch>; Thu, 7 Nov 1996 18:15:35 +0100 Subject: Re: [URN] I18N does not belong in URNs To: moore@cs.utk.edu Date: Thu, 7 Nov 1996 18:15:34 +0100 (MET) Cc: tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611062032.PAA10773@ig.cs.utk.edu> from "Keith Moore" at Nov 6, 96 03:32:28 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5192 From: Martin J Duerst Message-Id: <"josef.ifi..235:07.10.96.17.15.36"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore wrote: >Perhaps. I don't have as big a problem with this, as long as >there's a discipline about how they are assigned that prevents >URNs from being used as search strings. That's my main worry. >(URNs are also supposed to be transcribable, but I recognize that >only a very small set of characters is transcribable by everyone >on the planet.) For "everyone", you might have to limit it to X and O, or even X and XX :-). Just an additional example: Think about number plates of cars. Lots of non-ASCII characters there all over Asia. >> So for grandfathering, we have two choices. >> >> 1) We interpret it as "direct grandfathering of characters", >> in which case we have to allow a really wide range >> of characters (i.e. ISO 10646). >> 2) We interpret it as "indirect grandfathering", in which >> case the digits, or whatever small set, will be >> enough. > >I suspect there will be some of each. I wouldn't mind "some of each", if this means "about the same amount for everybody on the world". If it comes to mean "a lot for English-speaking, but very little for the rest of the world", I would have to strongly disagree. In theory, I could immagine making a worldwide search of suitable namespaces, and limiting the characters to those appearing in such namespaces. But I guess we would quickly end up with all the major alphabets completed, and the work deciding which of the ~20,000 CJK ideographs is used in a naming scheme, and which not, would not be very rewarding. >But we want the transformations >from "old identifier" to URN to be simple and easy to remember. Back to user-friendliness, in some sense. I have no problems about this. But again, I wouldn't like it if "simple and easy to remember" means that English speaking people just have to type them in, whereas people in the rest of the world, for namespaces that are currently in use there, need list of correspondences they have to look up or remember constantly. >> Choosing ASCII only as for URLs would be very unfair cheating. > >If the names aren't human meaningful, I don't see what you're >complaining about. If I were sure the names would not be meaningful, I would not have much reason to complain. But the URL example shows that restricting people from becomming meaningful is very hard if not impossible. You may agree with the above point, or you may disagree. But either way, ASCII only is unfair. If you think that naming schemes, protocols, standards, some review board, or whatever, can assure that no meaningful stuff is created, then there is no reason to restrict to ASCII. One should assume that Japanese, Russians, Chinese, or whoever, can be as disciplined, or as tighly controlled, as the English-speaking part of the world. On the other hand, if you think that namespaces will get meaningful because of people's nature, and you think it is a bad thing that has to be avoided, there is no other choice but to limit ourselves to the decimal digits and maybe two or three other characters. >> >> I definitely hate to see i18n just being moved around and delayed >> >> by some people. With UTF-8 in URNs, we have made great progress. >> > >> >No, this is a big step backward. Just because there is a new layer >> >being defined doesn't mean that I18N belongs there. >> > >> >I18N *is* important -- and I'd be happy to see a draft document or >> >draft charter for a working group to define a protocol (say an extension >> >of http/html) to resolve human-friendly names into URNs or URLs. >> >> Why is there a need for an additional protocol layer? >> There is no need currently for English, is it? > >Yes, there is. Human-friendly names are inherently ambiguous, >and have ambiguous meanings which require a human being to untangle. [examples removed] >URNs should be precise enough that a human isn't required to >disambiguate the result. I know your examples. But there can be a great deal of human-friendliness, without any need for ambiguity. URLs such as http://www.ibm.com or http://www.icrc.org are examples. My brother, who works at ICRC in Geneva, recently called me. Before he was able to tell me how I could reach him by email, I had the ICRC home page on my browser, and had found the generic email address explanations, and had sent him a mail. Of course, I'm an expert, but there are many people with less Web experience and technical expertise who could do that. If it can be that human-friendly, and that unambiguous, I don't know why I should go to a search service to find the ICRC. And I don't know why people that use other scripts should go though a serach service, while English speaking users don't have to do so. >> And I don't want to have to search through long lists >> of possible answers just because I use Japanese, whereas >> I will get one immediate answer for English. > >The point is that you will often get multiple answers for English. >English names are no more precise than names in other languages. No, but English can be used in URLs, and I get an unambigous result if there is one, in due time. In Japanese, even if the result would be unambiguous, I currently can't get it fast and easily. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA29723 for urn-ietf-out; Thu, 7 Nov 1996 11:52:21 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA29718 for ; Thu, 7 Nov 1996 11:52:19 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22778 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 11:52:17 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id KAA07336; Thu, 7 Nov 1996 10:46:58 -0600 (CST) Date: Thu, 7 Nov 1996 10:46:58 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611071646.KAA07336@ncsa.uiuc.edu> To: Keith Moore Cc: urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: <199611060416.XAA28069@ig.cs.utk.edu> References: <199611050616.AAA21984@ncsa.uiuc.edu> <199611060416.XAA28069@ig.cs.utk.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Keith Moore writes: > [...] But the difference between URNs and URLs has > almost nothing to do with how they are resolved (indeed, I hope they > use the same resolution mechanisms), and a lot to do with how the > names are assigned and maintained. This is at least a different view, especially regarding URLs, than other people hold. But I am under a restraining order :-) not to pursue this here, so I've created a new list uri@union.ncsa.uiuc.edu. To subscribe (this is not Majordomo), see the web page at: http://union.ncsa.uiuc.edu/HyperNews/get/www/URIs.html > This is why URNs need a URN: prefix -- because a lot of the value in > having a URN name space with those properties is so *humans* can > recognize a URN when they see it. The issue of whether the "urn:" prefix should be optional or required is still open. Since this issue relates directly to whether URNs can or should be distinguished from URLs, I'm open to having it discussed on uri@union.ncsa.uiuc.edu. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA29641 for urn-ietf-out; Thu, 7 Nov 1996 11:50:22 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA29635 for ; Thu, 7 Nov 1996 11:50:19 -0500 Received: from expresso.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22752 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 11:50:16 -0500 Received: by expresso.bunyip.com (NX5.67c/NX3.0S) id AA24400; Thu, 7 Nov 96 11:50:11 -0500 Message-Id: <9611071650.AA24400@expresso.bunyip.com> From: Peter Deutsch Date: Thu, 7 Nov 1996 11:50:05 -0500 In-Reply-To: Daniel LaLiberte's message as of Nov 7, 9:18 X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: Daniel LaLiberte , Harald.T.Alvestrand@uninett.no Subject: Re: [URN] some comments Cc: leslie@bunyip.com (Leslie Daigle), "Karen R. Sollins" , urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Peter Deutsch Errors-To: owner-urn-ietf@bunyip.com Hi all, It's been some time since I posted in this forum (actually, I think my last shout in this problem space was back during the lifetime of the previous URI list). I've been busy, other people have been carrying the flag and I've tried to let sleeping dogs lie. This morning, I composed a reply to a message opening the possibility of reworking RFC1737. I then had the good sense to shelve the posting until I'd had time to view the rest of the thread, and was about to congratulate myself on the wisdom of my advancing years when I reached the subsequent exchange between Dan and Harald. Now, that exchange may be enough to close this debate, but given past history, I suspect it will instead open again the meta-discussion about conceptual models, process and so on. Because of Dan's specific concerns about process, I've decided to go ahead and send my missive. Harald obviously speaks with the weight of the Area Director and I applaud his remarks. I offer my complemetary message as someone who was a founding co-chair of the original URI working group and as someone who has been watching similar exchanges for something like five years now. There is no offense intended for any specific indvidual. I hope none is taken. ------------------------------ [* WARNING CONTAINS FREE DIATRIBES AND MEASURABLE RANTINGS. *] [* SOME EXPERTS BELIEVE THAT CONSUMING SUCH DIATRIBES AND *] [* RANTINGS LEADS TO IRRITABILITY, CROSS-POSTING AND FLAMES. *] [* CONSUME AT YOUR OWN RISK..... *] [ jayhawk@@dsm0.ds.internic.net wrote: ] . . . } First I have to apologize, because I should have added an indication that } that wasn't an entirely serious remark. } } } Having said that, I still claim that as we move forward, we have the right } to realize that something in 1737 isn't optimal or doesn't work etc. My } opinion is that if there is rough consensus in the WG, then saying "but } 1737 says that's a no-no" doesn't cut it. } I think I understand the thrust of your argument, and if not for the past four or five years of history, I'd agree wholeheartedly that we need to remain open to change. Unfortunately, as someone who has been monitoring and (before I was called away by my accountants) participating in this debate pretty much since its inception, I'd have to echo Karen's concerns. You are right - if bits or pieces turn out to be broken in RFC 1737, then they should to be fixed. That's simply good engineering. The problem I see, and I suspect that Karen was attempting to address, is that there exist the danger that in leaving open the possibility of modifying RFC 1737, at least some people will take it a mandate to fix not just broken specifics, but the conceptual model itself. This has been happening since the beginning of this work and it's getting old. I believe that this debate has been struggling on for so long because we have two basic belief systems (okay, two engineering models), and rather than divide into two groups to pursue alternate development paths, adherents of the two models have remained together and continued to debate essentially the same arguments and beliefs continuously for years. Yes, we've probably made some progress (there is a requirement document, there are some experimental systems deployed, the terminology seems to have stabilized, etc) but I'm really rather concerned that we don't yet have that essential working consensus on the underlying conceptual model. I'm seeing postings go by that echo pretty much exactly what was being posted several years ago in earlier forums (fora?). Because of that, I think leaving open the possibility of going back to rejig RFC 1737 sends the wrong message at this time. Yes, if you think something specific is broken, it's responsible to say so. But if someone's problem is with the conceptual model, then you should probably unsubscribe and leave the rest of us to our misconceptions. Please understand that I'm not taking a shot at your posting and I hope I don't offend you. From your tone you seem aware of the possibilities I'm warning against. It's just that I'm a little tired of the continual debate on questions which have been "asked and answered" and I fear that others may misconstrue your comments to mean that it's okay to continue fighting the good fight to "fix" the model. I'd like to remind people who have joined this debate within the past year or two that when we first formed the URI working group way back when, we had two camps. One camp thought everything could be done with URLs, and didn't accept that the semantics of URNs were different, or if they were, that meant we could or should implement them. The basic thrust seems to be "they're not real, or not needed. We can do the same things with URLs and building these other things would be harmful." The other camp believed that the differing semantics indicated the existance of a different class of identifiers and these should be designed, standardized and used separately from URLs. Such people believed that in doing so, URNs would prove useful in ways that URLs are not, and if some people didn't see this, that's fine as it would become clear who was right as URNs became widely deployed. Darwinian selection would do its thing. Since then a conceptual model was proposed (I think Karen captured its broad outlines well), URN requirements were teased out and written down, the framework document was promulgated and a few experimental systems were designed and deployed. Yes, that's measurable progress. But gosh, it's been a slog. And we still see people arguing against the model, or the necessity, or the functional requirements as already agreed. That was probably appropriate back in the URI group, when the conceptual model was being hammered out. Today, I personally believe that the model-related debates are hurting us all, as it's having a chilling effect on the testing, deployment and eventual acceptance of URNs. I think URNs are real and are badly needed, and we're running way behind schedule. We have a model and this group has a specific mandate to implement a component of that model. If you disagree with that model, please take your concerns to the Area Directors, the plenary sessions, the IETF mailing list or simply ignore the workings of this group. If you're right we will do no harm. If you're wrong you're holding up progress. If you agree with the model and disagree with the implementation, then that's fair game, but folks, life's too short. If you don't buy the model, please leave this work to those who do. - peterd -- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA29561 for urn-ietf-out; Thu, 7 Nov 1996 11:48:56 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA29555 for ; Thu, 7 Nov 1996 11:48:54 -0500 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22725 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 11:48:06 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.8.2/8.7.3) with SMTP id IAA09540; Thu, 7 Nov 1996 08:43:01 -0800 (PST) Date: Thu, 7 Nov 1996 08:43:01 -0800 (PST) From: "Gregory J. Woodhouse" To: Jim Conklin Cc: Terry Allen , urn-ietf@bunyip.com Subject: Re: [URN] Re meaningful names In-Reply-To: Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com Much of the software we release is in source code form. If someone werwe to argue that the code should not be commnted or well structured, perhaps even arguing tht algorithms should specifically be chosen because they are hard to follow, and then claim tht woul enhance software quality in that it would make it less tempting for customers to modify the code and possibly break it, I would say they were quite wrong. Software quality is enhanced by having clean, understandable and maintainable code. Now, why should URNs be any different? On Thu, 7 Nov 1996, Jim Conklin wrote: > Like Terry Allen, and for the same reasons, I will (again, as I did months > ago when we previously had this discussion) enter my vote for the ability > to use meaningful names. > > Jim > > --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/home.html resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA29180 for urn-ietf-out; Thu, 7 Nov 1996 11:35:09 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA29175 for ; Thu, 7 Nov 1996 11:35:07 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22622 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 11:34:12 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00889-0@josef.ifi.unizh.ch>; Thu, 7 Nov 1996 17:30:38 +0100 Subject: Re: [URN] I18N does not belong in URNs To: girod@LCS.MIT.EDU Date: Thu, 7 Nov 1996 17:30:37 +0100 (MET) Cc: tallen@fsc.fujitsu.com, moore@cs.utk.edu, urn-ietf@bunyip.com In-Reply-To: <9611062348.AA06182@skadhwe.lcs.mit.edu> from "Lewis Girod" at Nov 6, 96 06:48:00 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2326 From: Martin J Duerst Message-Id: <"josef.ifi..250:07.10.96.16.30.39"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Lewis Girod wrote: > this group seriously would agree to restrict URNs to digits > only for this reason, I would understand. > But with ASCII as a "restricted" character set, we will definitely > get cruftiness, and I see no reason to allow cruftiness for > English, but to deny it for most other languages. > >One idea we were experimenting with here was to use a subset of ASCII >that included only numerals, punctuation and consonants, which would >make most words hard to express (at least in some languages). There are some languages that use mostly consonants, esp. some of the Slavic languages. Arabic and Hebrew in principle write only consonants. But I am less worried about these aspects. What I am worried about is that we just exclude 5 letters from 26. This may not be noticed by some people, who happily will use AEIOU also. We have this now, as for example "~" seems to be unsafe or excluded, but still is used all the time. Also, many accronyms contain only consonants (e.g. HTML and HTTP), and if somebody wants to use words with vowels stripped, it will unduely give advantages to some and disadvantages to others. For example, compare mcrsft, ppl, bm, dgtl, hp, sn, and so on. So just cutting out the vowels is not enough if we want to go that way; for a small set, my preference would still be for 0123456789#* (phone keys). Of course, my general preference is for full i18n with UTF-8. > The interesting thing is that we already have that, in the current > syntax draft. Just call the readable form of it UFNs, and call > the encoded form, %HH-escaped, URNs. I have proposed similar > names for these things, namely IRNs (internationalized ...). > >True, those strings are hard to read but it doesn't solve the problem >because the URN and the UFN are tightly coupled -- the whole point of >UFNs is that they are nicknames with a short lifespan. A UFN should >be allowed to change over time without ever changing the aliased URN. I didn't want to stress that the %HH strings are difficult to read. What I a looking for in UFNs is that they are user friendly, i.e. easy to understand and type in by somebody e.g. in Japan or so, and that they are tightly coupled to something else, e.g. URNs or URLs, so that they can be resolved quickly and deterministically. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA28955 for urn-ietf-out; Thu, 7 Nov 1996 11:23:52 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA28949 for ; Thu, 7 Nov 1996 11:23:50 -0500 Received: from info.cren.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22459 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 11:23:48 -0500 Received: from [192.52.179.12] (conklin-180c.cren.net [192.52.179.12]) by info.cren.net (8.6.6/8.6.4 (CREN)) with SMTP id LAA22632; Thu, 7 Nov 1996 11:23:23 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Nov 1996 11:24:09 -0500 To: Terry Allen , urn-ietf@bunyip.com From: conklin@info.cren.net (Jim Conklin) Subject: Re: [URN] Re meaningful names Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: conklin@info.cren.net (Jim Conklin) Errors-To: owner-urn-ietf@bunyip.com Like Terry Allen, and for the same reasons, I will (again, as I did months ago when we previously had this discussion) enter my vote for the ability to use meaningful names. Jim Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA28179 for urn-ietf-out; Thu, 7 Nov 1996 10:23:19 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA28173 for ; Thu, 7 Nov 1996 10:23:16 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21932 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 10:22:55 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id JAA05599; Thu, 7 Nov 1996 09:18:17 -0600 (CST) Date: Thu, 7 Nov 1996 09:18:17 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611071518.JAA05599@ncsa.uiuc.edu> To: Harald.T.Alvestrand@uninett.no Cc: Daniel LaLiberte , leslie@bunyip.com (Leslie Daigle), "Karen R. Sollins" , urn-ietf@bunyip.com Subject: Re: [URN] some comments In-Reply-To: <26912.847376443@domen.uninett.no> References: <199611070635.AAA01984@ncsa.uiuc.edu> <26912.847376443@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Harald T. Alvestrand writes: > liberte@ncsa.uiuc.edu said: > > Standing on premise and charter as an argument is legalistic and > > dogmatic. That's dangerous, although it may lead to short term > > productivity. > > Actually, I asked for the WG to be run in exactly this fashion. Had I known we were going to be held to the details of the charter, I would have spoken up at that time. But, honestly, would it have mattered? > One reason why we wrote a rather narrow charter for this working > group, which DID include assumptions like "there is a difference > between URLs and URNs", was that we wanted to see if it was > possible to create a solution to a limited problem. But my whole point is that *because* the supposed difference between URLs and URNs (the identifiers, not the resolution mechanisms) does not exist, it is irrelevant to creating a solution, except for syntax and other arbitrary constraints. > One of the things that we have to do, unfortunately, to get a > solution to that limited problem, is to ask those who want to work > on a different problem to leave. So it has come to that, eh? As I've stated, we'll continue the discussion off-line. But are you saying we shouldn't bother? > The output of this working group is supposed to be a set of > Experimental documents. These don't form the be-all and end-all > of the Internet information architecture; they're just an experiment. You should know that many experiments turn into standard practice. If you want it to really be "just an experiment", perhaps you should consider finding a way to kill it off afterwards so it doesn't escape from the lab. :-) -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA27908 for urn-ietf-out; Thu, 7 Nov 1996 10:05:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA27903 for ; Thu, 7 Nov 1996 10:05:34 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21738 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 10:05:31 -0500 Received: by seawall with (8.6.12/) id KAA07429; Thu, 7 Nov 1996 10:05:29 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma007417; Thu Nov 7 10:05:10 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <3281FAD6@MSMAIL.INDY.TCE.COM>; Thu, 07 Nov 96 10:05:58 EST From: Fisher Mark To: Bob Briscoe , Terry Allen Cc: "urn-ietf@bunyip.com" Subject: RE: [URN] Persistence as part of URN framework Date: Thu, 07 Nov 96 10:05:00 EST Message-Id: <3281FAD6@MSMAIL.INDY.TCE.COM> Encoding: 19 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com >Final comment: >If you accept that pragmatically, URNs don't exist for ever (because they >only exist as long as anyone can prove they exist), you can still have the >"no reassignment" rule for people to keep to on best effort. IOW, just >because urn:duns:001234567:Dunn&Bradstreet_Collapse.report stops being >resolvable, anyone who knew of broken references to it well into the >future, >shouldn't deliberately re-use it for something else. Well, unless they can somehow take over resolution of the "duns" namespace, they _can't_ re-use it. That is why URNs were partitioned into namespaces -- so that each namespace resolver could control their namespace. If any party can perform the resolutions for a particular namespace (rather than the assigned resolution party), then a whole big can of worms is opened up -- security issues, reliability, liability, etc. ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA27878 for urn-ietf-out; Thu, 7 Nov 1996 10:02:30 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA27873 for ; Thu, 7 Nov 1996 10:02:26 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21704 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 10:02:23 -0500 Received: by seawall with (8.6.12/) id KAA07323; Thu, 7 Nov 1996 10:02:11 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma007316; Thu Nov 7 10:01:45 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <3281FA09@MSMAIL.INDY.TCE.COM>; Thu, 07 Nov 96 10:02:33 EST From: Fisher Mark To: "girod@LCS.MIT.EDU" , Martin J Duerst Cc: "moore@cs.utk.edu" , "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Subject: Re: [URN] I18N does not belong in URNs Date: Thu, 07 Nov 96 10:00:00 EST Message-Id: <3281FA09@MSMAIL.INDY.TCE.COM> Encoding: 26 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com >But with ASCII as a "restricted" character set, we will definitely >get cruftiness, and I see no reason to allow cruftiness for >English, but to deny it for most other languages. Even purely numeric schemes can be crufty. Here at TCE we are transitioning from a meaningful component naming scheme to one where the only meaningful part is a prefix indicating the site where the number was assigned -- the rest of the number is random. If there is some way for people to assign a meaning or pattern to a character sequence, this meaning will be used. Sometimes patterns will be detected even when there is no actual pattern (this is how some optical illusions work) -- humans are pattern-detecting animals. So, I see only 2 basic directions URN identifiers can go: 1) Totally opaque, random numeric strings; or 2) I18N character strings with appropriate encoding, preferably (IMHO) as UTF-8. There really is no middle ground -- if there is a pattern there, people will make use of it and screw up the system. ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA27820 for urn-ietf-out; Thu, 7 Nov 1996 09:57:35 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA27815 for ; Thu, 7 Nov 1996 09:57:33 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21634 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 09:57:31 -0500 Received: by seawall with (8.6.12/) id JAA07179; Thu, 7 Nov 1996 09:57:18 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma007150; Thu Nov 7 09:56:30 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <3281F8CE@MSMAIL.INDY.TCE.COM>; Thu, 07 Nov 96 09:57:18 EST From: Fisher Mark To: "Harald.T.Alvestrand@uninett.no" , Bob Briscoe Cc: "urn-ietf@bunyip.com" Subject: Re: [URN] Persistence as part of URN framework Date: Thu, 07 Nov 96 09:53:00 EST Message-Id: <3281F8CE@MSMAIL.INDY.TCE.COM> Encoding: 42 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com >Using DNS TTL records for this is just broken; DNS TTLs are used >to limit caching of name->address mapping, and in the NAPTR proposal, >they should be a fraction of the time one expects to have advance >warning of a server relocation or mapping restructure. >Normal TTLs are on the order of 3 days, and are usually reduced to less >than 1 day before serious network reorganizations. And if you are changing your resolution services faster than that, you are changing them too fast (IMHO). Perhaps the key idea TimBL came up with in devising the Web was that, unlike other hypertext systems (including the Dexter model), links could be broken, i.e. nonfunctional. This single idea was perhaps above all others important in spreading the Web far and wide, as perfectly reliable systems as difficult to construct (even for an appropriately low value of "perfect"). Under the Dexter model, an application will die or limp on after reporting an internal error upon encountering a broken hyperlink. In the Web, the UA just keeps surfing on to the next link. All that URNs can do is assist in persistence; persistence itself must be maintained outside the URN architecture, as persistence is ultimately a political/economic quality, not a technical quality. We would expect a BT URN to persist because of our trust in BT, not because there is some technical solution to persistence. Persistence is assisted in URNs by the ability to hand off resolution duties automagically to successor resolution entities. I would regard measures of persistence to be an optional but necessary part of the metadata for a URN, not as mandatory metadata. It is quite possible that URN will see incredibly wide use, as much or more as URLs are now ("every person a URN namespace owner"). Many of these namespaces may just persist for a few years or months, with the owner not caring about measures of persistence. Persistence is ultimately up to the creating/resolving entity(s). Uniqueness is an easier problem than persistence, although uniqueness has a strong political/economic component. One can certainly imagine the case of URNs for government materials that, after they are first created for public consumption, are found to be embarrassing to that government and the URNs are silently, suddenly changed to refer to much more innocuous materials. Uniqueness, also, is ultimately up to the creating/resolving entity. ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA27494 for urn-ietf-out; Thu, 7 Nov 1996 09:36:07 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA27489 for ; Thu, 7 Nov 1996 09:36:05 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21314 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 09:36:01 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00725-0@josef.ifi.unizh.ch>; Thu, 7 Nov 1996 15:33:12 +0100 Subject: Re: [URN] Re meaningful names To: girod@LCS.MIT.EDU Date: Thu, 7 Nov 1996 15:33:11 +0100 (MET) Cc: tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <9611070152.AA06320@skadhwe.lcs.mit.edu> from "Lewis Girod" at Nov 6, 96 08:52:18 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2002 From: Martin J Duerst Message-Id: <"josef.ifi..915:07.10.96.14.33.19"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Lewis Girod wrote: > Date: Wed, 6 Nov 1996 16:35:41 -0800 (PST) > From: Terry Allen > | Of course, as you point out there is no way to stop people from > | putting semantics into names; the most effective way to deal with the > | issue is to implement a system of user friendly names over the top of > | URNs; 99% of the time the user would see and type only a UFN, and > | these UFNs would be resolved to the URNs that could then be used as > | long-lived references. > > Twice the work or more, doesn't deal with grandfathering, prone > to error; the most effective way to deal with the issue is to > drop your objection to meaningful names. > >It is more work (though how much more is hard to say), but it might >prove really useful. I don't think it would impact grandfathering at >all; grandfathered names could have a UFN alias or they might just be >typed in as URNs. Prone to error? UFNs wouldn't have the longevity >characteristics that URNs hopefully would have, if that's what you >mean -- that's why you don't use them in published links. If you look at what is currently published in terms of URLs, most of them try to be as user-friendly as possible. Non-userfriendlyness may be okay for some official publications, but for publishing things in newspapers and on cardboard boxes, user-friendliness is on great demand. Another aspect of user-friendliness is deterministic behaviour (maybe only shorttime): If you read something in a newspaper, you want to go to that site/document directly, and not have to go through search lists, and so on. The side which publishes a reference likewise wants you to go there directly, and not be detracted. This may not affect URN internationalization, but it definitely affects URL internationalization, because for all of the above, URLs are currently used, with the only restriction that the advantages the users look for are limited to English plus a few other rare languages. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA27394 for urn-ietf-out; Thu, 7 Nov 1996 09:31:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA27389 for ; Thu, 7 Nov 1996 09:31:32 -0500 Received: from fssun10.dev.oclc.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21257 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 09:31:26 -0500 Received: from orc.NISOR (orc.dev.oclc.org) by oclc.org (4.1/SMI-4.1) id AA26579; Thu, 7 Nov 96 09:31:21 EST Received: by orc.NISOR (SMI-8.6/SMI-SVR4) id JAA12243; Thu, 7 Nov 1996 09:32:24 -0500 Date: Thu, 7 Nov 1996 09:32:24 -0500 From: stu_weibel@oclc.org (Stu Weibel) Message-Id: <199611071432.JAA12243@orc.NISOR> To: urn-ietf@bunyip.com Subject: [URN] Semantically meaningful URNs X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: stu_weibel@oclc.org (Stu Weibel) Errors-To: owner-urn-ietf@bunyip.com The philosophical debate about whether URNs will be human transcribable, semantically meaningful, etc., is unproductive. This group should take no stand on this issue. Some naming authorities will choose one approach, others will choose another. The only constraint that is relevant here is that the Locally-Unique-Identifier assigned by a naming authority is not reassigned. There is a technical issue involved having to do with character encodings, of course. The mandate of this group should be to adopt the least restrictive approach that is supportable technically. stu Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA27343 for urn-ietf-out; Thu, 7 Nov 1996 09:21:59 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA27338 for ; Thu, 7 Nov 1996 09:21:57 -0500 From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21090 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 09:21:41 -0500 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <26916-0@domen.uninett.no>; Thu, 7 Nov 1996 15:20:45 +0100 X-Mailer: exmh version 1.6.7 5/3/96 To: Daniel LaLiberte Cc: leslie@bunyip.com (Leslie Daigle), "Karen R. Sollins" , urn-ietf@bunyip.com Subject: Re: [URN] some comments In-Reply-To: Your message of "Thu, 07 Nov 1996 00:35:39 CST." <199611070635.AAA01984@ncsa.uiuc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==!Exmh_1839892962P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 07 Nov 1996 15:20:43 +0100 Message-Id: <26912.847376443@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com --==!Exmh_1839892962P Content-Type: text/plain; charset=us-ascii Daniel, some words about process. liberte@ncsa.uiuc.edu said: > Standing on premise and charter as an argument is legalistic and > dogmatic. That's dangerous, although it may lead to short term > productivity. Actually, I asked for the WG to be run in exactly this fashion. One reason why we wrote a rather narrow charter for this working group, which DID include assumptions like "there is a difference between URLs and URNs", was that we wanted to see if it was possible to create a solution to a limited problem. One of the things that we have to do, unfortunately, to get a solution to that limited problem, is to ask those who want to work on a different problem to leave. We've got a process in place for forming working groups that are not about solving limited problems, called the Internet Research Task Force, and Karen Sollins is, I believe, chairing a group there that is chartered to look at wider problems; my mailbox is always open to suggestions for chartering other WGs for attacking concrete problems that need concrete solutions. The output of this working group is supposed to be a set of Experimental documents. These don't form the be-all and end-all of the Internet information architecture; they're just an experiment. But we need to get these documents out, and to get an experiment going; to that end, I've specifically asked the WG chair to make sure the WG sticks to its charter, and does NOT try to investigate other problems. Then this WG closes, and we have the chance to create a new one, with a new charter, with or without a new name, to revise the solution or to create a new one. But with THIS WG, I've asked it to stick to its charter. Harald T. Alvestrand Applications AD --==!Exmh_1839892962P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.i iQBVAgUBMoHwOTPwVTwXXgE5AQHpXwH+M0GnpcFcbVDgnFhbcfg1XKuisXTclz2g E8JFdHfMbVCfWdUPdPF4CnDQ+yPk8NxQ0xYL1/GhH8xYbOEDP8fF/w== =F9pb -----END PGP MESSAGE----- --==!Exmh_1839892962P-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA27308 for urn-ietf-out; Thu, 7 Nov 1996 09:17:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA27303 for ; Thu, 7 Nov 1996 09:17:47 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21057 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 09:17:44 -0500 Message-Id: <9611071417.AA21057@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Thu Nov 7 08:16 CST 1996 From: "Ryan Moats" To: "Karen R. Sollins" Cc: "urn-ietf@bunyip.com" Date: Thu, 07 Nov 96 08:18:09 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] Comments on "I18N does not belong in URNs" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Wed, 6 Nov 1996 20:46:17 -0500, Karen R. Sollins wrote: > > First I have to apologize, because I should have added an indication that > that wasn't an entirely serious remark. > >Apology accepted. Truthfully, I was at least as concerned that the >group as a whole not take your comment seriously:-) > > In a more directed vein, syntax draft already breaks 1737. Specifically, I'm > refering to the "case insensitivity" requirement (the draft current > has the NSS being case sensitive). "Case-insensitivity" is itself > tied up in what character set we use. If we treat the NSS as a series of > octets, then we can't have case insensitivity, because we haven't set > a character set (ho boy am I digressing...) > >We ALSO spent many hours arguing over this one. There were three >camps, those who thought case sensitivity was important, those who >thought that case insensitivity was important and those who thought we >just needed a single decision on it. As I remember it, the consensus >really went with the third group and we just had to go one way or the >other. So, although I'd really like not to have those discussions >again, I believe that the majority didn't feel strongly one way or the >other (unlike many of the other issue in that document:-) Sorry to be delayed in answering this, but I finally got the code I was working on last night to work, so I went back to my real life... Thanks for the information, it's useful for a historical (hysterical? ;-) ) perspective. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA26404 for urn-ietf-out; Thu, 7 Nov 1996 08:35:40 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA26399 for ; Thu, 7 Nov 1996 08:35:38 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20764 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 08:35:36 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00695-0@josef.ifi.unizh.ch>; Thu, 7 Nov 1996 14:34:53 +0100 Subject: Re: [URN] I18N does not belong in URNs To: dgd@cs.bu.edu Date: Thu, 7 Nov 1996 14:34:52 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: from "David G. Durand" at Nov 6, 96 12:27:54 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1008 From: Martin J Duerst Message-Id: <"josef.ifi..408:07.10.96.13.35.03"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com David Durand wrote: > I am not advocating either side at the moment -- I tend to agree that >transcribability of I18N names will be hellish and error prone. On the >other hand, eliminating almost all languages in the world from URNs is a >big hit. Every script or language has some characters that are easily confused. In ASCII, this is 0 and O, and l and I and 1. After some time of learning, such characters get eliminated where necessary, or used only where they are clearly identifiable from context. Foreign users tend to be more confused, for example it is customary in Japan to add a horizontal bar to the stem of a D to distinguish it from O. Transcribing will be a problem for those that don't know a script. But I assume that those who designed a naming system e.g. for Buddhist texts, made the assumption that a minimal knowledge of the script the texts are in could be assumed. Also, if they choose kanji, they will have choosen them so that they are easily disambiguated. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA26388 for urn-ietf-out; Thu, 7 Nov 1996 08:35:03 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA26383 for ; Thu, 7 Nov 1996 08:35:01 -0500 Received: from goggins.bath.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20752 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 08:34:54 -0500 Received: from ukoln.ac.uk (actually host lamin.bath.ac.uk) by goggins.bath.ac.uk with SMTP (PP); Thu, 7 Nov 1996 13:11:38 +0000 Date: Thu, 7 Nov 1996 13:11:18 +0000 (GMT) From: Andy Powell X-Sender: lisap@lamin.bath.ac.uk To: Leslie Daigle Cc: Larry Masinter , urn-ietf@bunyip.com Subject: Re: [URN] URN-WG home page w/references In-Reply-To: <199611051140.GAA13431@beethoven.bunyip.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Andy Powell Errors-To: owner-urn-ietf@bunyip.com On Tue, 5 Nov 1996, Leslie Daigle wrote: > Yes, there is a homepage for the group, although I have not had time to > update it since we became a working group. > > It lives at: > > http://www.bunyip.com/research/urn-ietf/ > > Suggestions for content are welcomed... In a slightly wider context... As part of a European project that we're working on here I've been building a (somewhat unstructured) list of resources related to the identification of 'electronic publications'. http://www.ukoln.ac.uk/BIBLINK/wp2/links.html It includes pointers to information about URNs, PURLs and various schemes either currently in use by or proposed by the publishing/library communities (ISBN, ISSN, PII, SICI, DOI, CIS, ISWC...). Andy. -- UK Office for Library and Information Networking University of Bath, Bath, BA2 7AY, UK Voice: +44 1225 323933 http://homes.ukoln.ac.uk/~lisap/ Fax: +44 1225 826838 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA25374 for urn-ietf-out; Thu, 7 Nov 1996 06:28:12 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA25369 for ; Thu, 7 Nov 1996 06:28:09 -0500 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20047 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 06:28:07 -0500 Received: from [193.12.104.243] (paf-hemma.swip.net [193.12.104.243]) by nic.cafax.se (8.8.2/8.8.2) with ESMTP id MAA05625; Thu, 7 Nov 1996 12:26:35 +0100 (MET) X-Sender: m-3329@mailbox.swip.net Message-Id: In-Reply-To: References: <"josef.ifi..460:06.10.96.10.44.08"@ifi.unizh.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Nov 1996 10:53:40 +0100 To: Jon Knight , Martin J Duerst From: Patrik Faltstrom Subject: Re: [URN] I18N does not belong in URNs Cc: moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com At 11.36 +0000 96-11-06, Jon Knight wrote: >> ISBNs don't qualify. They are not persistent. > >Aren't they? Crumbs, that means that the one scheme everyone is always >going on about grandfathering in URNs can't be grandfathered. Bummer. I >wonder if that will stuff up our library OPAC? How long does an ISBN >exist for until it gets reassigned to another publisher? It is at least in Sweden (ISBN series that start with 91) the case that it is the publisher that decides how persistent the ISBN is. For most books, most publishers do keep the ISBN very long lived, and does not reassign them. A new ISBN is given to a new version of a book, but not a new printing. For educational materials, pens, paper (yes, most things that a publisher or bookstore sells can because of the billing system most easily be handled if the "thing" have a ISBN) the ISBNs are more temporary. I know at least one publisher in Sweden that only had one ISBN allocated during one print of a book. I.e. assigned a new ISBN for a new print. They also reused ISBNs after about a year. So, to conclude, even inside the namespace of ISBNs, each organization giving out ISBNs do decide themselves what persistence is regardless of what rules there is globally for "global" ISBNs. This is _exactly_ why bookstores exists that have very advanced databases to be able to handle an order of an ISBN that have been replaced 15 times with new number because of reprints and the case that the publisher uses the ISBN as an identifier for the specification of that very print of the book, not the contents. But, I am not saying that ISBNs can not be used as URNs. In most cases, for _real_ books, an ISBN is persistent information about a book. Probably a new ISBN for each edition, but library cards include information about all possible ISBNs for one book, if you know one of them. My point is that local descisions for local parts of the namespace can have local rules for things like persistance. Patrik -------------------------------------------------------------------- Senior Researcher, Tele2/SwipNet Stockholm, Sweden paf@swip.net Phone: +46-8-56264000 urn:inet:urn.paf.se In theory, there's no difference between theory and practice, but in practice, there is. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA25253 for urn-ietf-out; Thu, 7 Nov 1996 06:04:10 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA25248 for ; Thu, 7 Nov 1996 06:04:08 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19965 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 06:03:44 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA20001; Thu, 7 Nov 96 12:08:42 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA01299; Thu, 7 Nov 1996 12:03:31 +0100 Date: Thu, 7 Nov 1996 12:03:31 +0100 From: "Dirk.vanGulik" Message-Id: <9611071103.AA01299@ jrc.it> To: urn-ietf@bunyip.com Subject: [URN] Pending Messages, reboot of elec/139.191.71.138 X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Dirk.vanGulik" Errors-To: owner-urn-ietf@bunyip.com Pending Message: uucp/11 days, 2 left; postmaster@jrc.it, dirkx@elec, postmaster@elec.isei.jrc.it --- Ron, About the last URN HTTP-alike resoving GET / HTTP/1.0 GET N2L/cid:foo%40huh.com HTTP/1.0 GET N2L/cid:foo%40huh.com HTTP/1.1 As expressed before, I am quite unhappy with using a 'fudged' (partial) URI in the request, rather than a proper METHOD or a real different syntax easy to recognize. Althoug I now agree that the META method I was advocating in the past in nowhere near flexible enough. If you look at the way the proxy requests and current 'full' urls in http 1.1 got squeezed in, I think we have a clear example of what a mess this gives in the long run when new protocols are added. RFC1738-> ; HTTP httpurl = "http://" hostport [ "/" hpath [ "?" search ]] hpath = hsegment *[ "/" hsegment ] hsegment = *[ uchar | ";" | ":" | "@" | "&" | "=" ] search = *[ uchar | ";" | ":" | "@" | "&" | "=" ] Looking at RFC1738 I realize that the use of the '/' before the colon and the absense of the initial '/' should perhaps give enough of a guarantee that both a partial is very easy, especially for proxies; and overloding such a little 'hole' in the specification for extension seems bad practice to me; the future will bring more and more proxies en-route, mixed 1.0, 1.1 and 1.x server/client combinations of different vendors. And a lot f servers are moving away from being essential unix file based into database retrival engines; for whom the bit after the '/' is just a token. So why not really split dimensions, and make it a separate method: N2L, N2C or N2N, ... I can assure you that, if this is the way to go; servers like apache can be augmentated to pass on the method, and to accept handlers for arbitrary methods. For testing purposes, there is a copy of a module in Contrib/incoming. And while on the subject; the HTTP\/(\d+)\.(\d+) string; do we _really_ want that ? given that with the above will need an add-on. How about URNRESOLV/version.version. :-) Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA24682 for urn-ietf-out; Thu, 7 Nov 1996 04:38:35 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA24677 for ; Thu, 7 Nov 1996 04:38:32 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18638 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 04:38:25 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Thu, 7 Nov 1996 09:37:38 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Thu, 7 Nov 1996 09:37:19 +0000 Received: from Ant.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Thu, 7 Nov 96 09:36:25 GMT Message-Id: <2.2.32.19961107093626.006c2f7c@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Nov 1996 09:36:26 +0000 To: Renato Iannella From: Bob Briscoe Subject: Re: Re[2]: [URN] Resolution Services (N2L etc) Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com At 10:13 07/11/96 +1000, Renato Iannella wrote: >Bob Briscoe wrote: >> If you insist, for instance, that the URC and the resource both have the >> same URN, you are mandating that a URC must be authored with the permission >> of the same domain of authority as the author of the resource itself (or >> vice versa). This stops people *independently* publishing URCs about other >> people's resources. Now where would the Web be today if you had to get >> someone's permission to link to them? > >I get a good feeling knowing that if I resolve a URN, I will >get back a URC describing that resource, created and maintained >by the owners (or their agents) - and not a third party >review of the resource. If I wanted that, then I would go >to such a service provider. > >If I publish a URN like >which points to a Technical Report at the DSTC - you can >quote it in a Web Page - and like everything - I can only >guarantee that it will last the lifetime of the DSTC. > >If you wish to provide a review of that Technical Report >(via a URC or whatever) then you are free to, and to allocate >you own URN, say . > So now, the URN resolution service is doing authentication of metadata too! Whoaaaa! There are so many assumptions flying around this working group that aren't documented in the framework. Hadn't you better look at your security if this is a goal? What if my URC describes my payment service and says it only charges 2% commission when in fact it charges 20%? Would the user be able to claim that this unsigned information misled them into using your payment service on the basis that it was the authentic metadata tied to the payment service via DNS (rather than someone else's possibly innocently out of date information)? Would a good lawyer be able to prove DNS could have been compromised and get the payment service operator off the hook? Yes. Why don't you just keep it simple. URNs are a base building block. If you just stick to name to address mapping, it's less likely to break in the future. If you want to authenticate metadata, the (now expired) drafts on URCs (e.g. Ron Daniel's URC Scenarios and requirements http://www.acl.lanl.gov/URI/Scenarios/scenarios_3.asc ) proposes signing the metadata which would also be able to tie the resource to the URC by reference so you could find it from the URC's name). >I don't wish to allocate a URN _directly_ to the Technical >Report - because I reserve the right to move it around our >network and to change its form. Don't see the problem - that's what URNs are for. 1. If you had a URN for the URC and an URN for the resource, the URC would just have to refer to the resource's URN. 2. You could just have a URN for the URC which would refer to the resource addresses directly and be the thing you update if the resources move around 3. You could just have a URN for the resources of you didn't want to bother with URCs What I was complaining about is the apparent assumption that the same URN would be used for both URN and URC and one would have to say N2C if you wanted the former, and N2L for the latter. What if BT want to sub-contract our resource description to a trusted third party so customers find it *more* believable than our own advertisements? The TTP might be willing to take liability for their descriptions but don't want the hassle of co-ordinating every URN registration with me? Ron's proposal: DSTC happy, BT happy. Your proposal: DSTC happy, BT sad. I would prefer there to be as near to zero assumptions as to how people might want to use URNs as possible. Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA23455 for urn-ietf-out; Thu, 7 Nov 1996 01:40:14 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA23450 for ; Thu, 7 Nov 1996 01:40:11 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17992 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 01:40:07 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id AAA01984; Thu, 7 Nov 1996 00:35:39 -0600 (CST) Date: Thu, 7 Nov 1996 00:35:39 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611070635.AAA01984@ncsa.uiuc.edu> To: leslie@bunyip.com (Leslie Daigle) Cc: Daniel LaLiberte , "Karen R. Sollins" , urn-ietf@bunyip.com Subject: Re: [URN] some comments In-Reply-To: <199611032218.RAA12973@beethoven.bunyip.com> References: <199611032218.RAA12973@beethoven.bunyip.com> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com With all the activity on the URN list in just the last couple days, it seems like ancient history to bring up the name-location issue again. (You may have thought it was in the first place, but I think that is the wrong perspective to take. See below.) Instead, I'll just clarify a couple things here (and I'll respond briefly to a couple other postings later), and perhaps more importantly I'll make some meta-comments on the process. After that Leslie and I and anyone else who wants to participate will thrash it out off of this list and bring the result back. Email me if you are interested. I do this not with resignation, but because I hope it will be more effective. I expect you will consider the issue "on hold" in the meantime rather than decided by default. Leslie Daigle writes: > > Dan, > > For all the words that have flown about on this mailing list in the past > few days, I don't really think you've made it clear what you want out > of this particular thread. The issue came up when Karen expressed concern over the optional "urn:" prefix. Apparently, it doesn't help to make "urn:" optional in an attempt to avoid the problems and subsequent discussion. > Let me be fairly blunt in my interpretation > here, and you can tell me on which counts I have misunderstood you. > > I think there are 2 separate things in what you have been saying: > > . whether or not URNs are any different than URLs Yes, that is the main thing we have been discussing. Note: this is equivalent to whether or not URLs are any different than URNs. The issue also has to do with whether and how you bind an identifier with its resolution mechanism. So it is intimately related to (not separate from) the second question: > . whether or not URNs can be implemented using URL mechanisms No, not exactly. In fact, I have said several times that I believe we need the persistence being designed into the URN mechanisms, so it is more pertinent to ask whether URLs can be resolved with URN mechanisms. (But there is more to it than that.) > Let me say, as co-chair of this working > group, that this WG starts from the premise that there _is_ a difference > between URNs and URLs, and that our chartered purpose is ... This is largely a meta-comment: Standing on premise and charter as an argument is legalistic and dogmatic. That's dangerous, although it may lead to short term productivity. If the IETF actually works this way now, it is in danger of losing the valuable process which has made it work so well so far. Documented consensus should not be used as a wedge on future possibilities but as a foundation upon which to build. If it turns out the foundation is flawed, do we attempt to fix it or build on it anyway? Even standards are revised over time, so why should a charter be held up to be obeyed with more rigor? > ... To stick to our charter ... is a reflection of the fact that > this is a directed effort. That has a positive ring to it. All I'm trying to do is redirect the effort a bit. I wouldn't be here if I didn't think there was merit in most of the effort. How many people believe the "waterfall" approach to software development should be followed strictly with never a revision or retraction of the earlier steps along the way? We are following the waterfall model by establishing a charter, and similarly, by establishing URN requirements, and then sticking to these earlier decisions as if they were written in concrete. I think a big part of the problem with this whole process is reflected in partly why some IETF working groups have been dissolved. Remember "Rough consensus and working code". We seem to be forgetting about the working code part. The value of the working code is that it forces the issue of what makes sense in the real world. Requirements may crumble in the face of practical realities. So how do we make progress while the foundation may be shifting? It is done in practice all the time, so I wouldn't worry about that too much. We may waste more time arguing over whether we should allow a change in the foundation than just deciding what needs to be changed. Karen has repeatedly expressed concern about making progress, and I share that concern, but is coming to an understanding of the issues not making progress? > > This is not a matter of just agreeing on a definition - it is a matter > > of having definitions that make sense. > > A relative term -- I think the definitions make perfect sense. I'm willing to argue with you about what makes sense. I'm not willing to argue legalities. Nor do I believe this is a religious issue in the sense that it comes down to a matter of opinions. There is very little religion in mathematics. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA21135 for urn-ietf-out; Wed, 6 Nov 1996 20:52:27 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA21130 for ; Wed, 6 Nov 1996 20:52:25 -0500 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16212 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 20:52:23 -0500 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa26936; 6 Nov 96 20:52 EST Received: by skadhwe.lcs.mit.edu; (5.65v3.2/1.1.8.2/15Aug95-0306PM) id AA06320; Wed, 6 Nov 1996 20:52:18 -0500 Date: Wed, 6 Nov 1996 20:52:18 -0500 Message-Id: <9611070152.AA06320@skadhwe.lcs.mit.edu> From: Lewis Girod To: tallen@fsc.fujitsu.com Cc: urn-ietf@bunyip.com In-Reply-To: <199611070035.QAA22323@ishtar.fsc.fujitsu.com> (message from Terry Allen on Wed, 6 Nov 1996 16:35:41 -0800 (PST)) Subject: Re: [URN] Re meaningful names Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com Date: Wed, 6 Nov 1996 16:35:41 -0800 (PST) From: Terry Allen Well, no. The name is the name; if you come to dislike it or think it doesn't mean the right thing you can map something else onto it in a new name space. If an existing name space uses "Mainframes", so be it; it will still work just fine as part of an unambiguous identifier (even if users have to be told "what name space FOO calls Mainframes we now call Enterprise Systems"). Right, that was what I meant by ``overall cruftiness''. At any given time large portions of the namespace are providing backwards compatibility for out-of-date semantics. | Of course, as you point out there is no way to stop people from | putting semantics into names; the most effective way to deal with the | issue is to implement a system of user friendly names over the top of | URNs; 99% of the time the user would see and type only a UFN, and | these UFNs would be resolved to the URNs that could then be used as | long-lived references. Twice the work or more, doesn't deal with grandfathering, prone to error; the most effective way to deal with the issue is to drop your objection to meaningful names. It is more work (though how much more is hard to say), but it might prove really useful. I don't think it would impact grandfathering at all; grandfathered names could have a UFN alias or they might just be typed in as URNs. Prone to error? UFNs wouldn't have the longevity characteristics that URNs hopefully would have, if that's what you mean -- that's why you don't use them in published links. Lewis: | One idea we were experimenting with here was to use a subset of ASCII | that included only numerals, punctuation and consonants, which would | make most words hard to express (at least in some languages). I cannot imagine that such an approach would find favor in the real world. Outside of the context of a UFN infrastructure, no; but the real world has found utility in many namespaces as unfriendly as that... as long as people don't have to get too involved with them. As for whether such a scheme would ever gain real world acceptance, that probably depends largely on the implementation of a UFN scheme, and whether the real world finds it to be sufficient for their purposes. This discussion of UFNs is probably getting off the topic -- the part of this opinion that is relevant to the topic is that in the backs of our minds we should remember that semantics in names and longevity seem to be at cross purposes, and it would be nice if at some time in the future most new names were free of semantics. Given that, should we build in additional mechanisms specifically to support semantics in URNs? -lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA21088 for urn-ietf-out; Wed, 6 Nov 1996 20:46:23 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA21083 for ; Wed, 6 Nov 1996 20:46:20 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16165 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 20:46:19 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id UAA08973; Wed, 6 Nov 1996 20:46:17 -0500 Date: Wed, 6 Nov 1996 20:46:17 -0500 Message-Id: <199611070146.UAA08973@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: jayhawk@dsm0.ds.internic.net Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com In-Reply-To: <9611070116.AA15963@mocha.bunyip.com> (jayhawk@dsm0.ds.internic.net) Subject: Re: [URN] Comments on "I18N does not belong in URNs" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com First I have to apologize, because I should have added an indication that that wasn't an entirely serious remark. Apology accepted. Truthfully, I was at least as concerned that the group as a whole not take your comment seriously:-) In a more directed vein, syntax draft already breaks 1737. Specifically, I'm refering to the "case insensitivity" requirement (the draft current has the NSS being case sensitive). "Case-insensitivity" is itself tied up in what character set we use. If we treat the NSS as a series of octets, then we can't have case insensitivity, because we haven't set a character set (ho boy am I digressing...) We ALSO spent many hours arguing over this one. There were three camps, those who thought case sensitivity was important, those who thought that case insensitivity was important and those who thought we just needed a single decision on it. As I remember it, the consensus really went with the third group and we just had to go one way or the other. So, although I'd really like not to have those discussions again, I believe that the majority didn't feel strongly one way or the other (unlike many of the other issue in that document:-) Karen Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA21045 for urn-ietf-out; Wed, 6 Nov 1996 20:35:51 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA21040 for ; Wed, 6 Nov 1996 20:35:49 -0500 From: jayhawk@dsm0.ds.internic.net Received: from dsm0.ds.internic.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16106 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 20:35:48 -0500 Message-Id: <9611070135.AA16106@mocha.bunyip.com> Date: Wed, 6 Nov 96 20:35 EST To: moore@cs.utk.edu, sollins@LCS.MIT.EDU Cc: urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs Content-Length: 1716 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: jayhawk@dsm0.ds.internic.net Errors-To: owner-urn-ietf@bunyip.com >I would like to be more specific about Keith Moore's statement: > > URNs should be precise enough that a human isn't required to > disambiguate the result. > >In particular, in light of the following requirement from RFC 1737 > > o Global uniqueness: The same URN will never be assigned to two > different resources. > >the URN will refer to exactly one resource from the perspective of > ^^^^^^^^^^^^^^^^^^^^^^^ >that naming authority assigning the name. This is actually a >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >complicated problem having to do with who believes which things are >"the same" by what definition. This was carefully crafted after >lengthy and heated discussion. Before we launch into another lengthy >discussion about this, I recommend to all of you who were not involved >in the first round of this that you think about it VERY hard. Each >naming authority is making a declaration about its own model of >"sameness". This is not in the eye of the beholder, but in the eye of >the namer. And it is that that we are expressing in URNs. We are >saying that if you have two URNs and they are "the same" under some >simple rules for canonicalizing them (also mentioned in 1737), then by >some definition known to the naming authority (although not >necessarily known to the holder of the URN) they identify and always >will the same resource. Having thought about this in the specific context of the syntax draft, I am in complete agreement with the statement as I have quoted it. I would note that simple here implies (in my mind) very limited knowledge (read none) of the namespace itself. I don't think we want to change that. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA20903 for urn-ietf-out; Wed, 6 Nov 1996 20:16:44 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA20898 for ; Wed, 6 Nov 1996 20:16:42 -0500 From: jayhawk@dsm0.ds.internic.net Received: from dsm0.ds.internic.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15963 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 20:16:41 -0500 Message-Id: <9611070116.AA15963@mocha.bunyip.com> Date: Wed, 6 Nov 96 20:16 EST To: jayhawk@ds.internic.net, sollins@LCS.MIT.EDU Cc: urn-ietf@bunyip.com Subject: Re: [URN] Comments on "I18N does not belong in URNs" Content-Length: 2341 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: jayhawk@dsm0.ds.internic.net Errors-To: owner-urn-ietf@bunyip.com Karen R. Sollins said: >Ryan Moats said: > > Well, RFC 1737 is informational so we can break it IF WE HAVE GOOD > REASON and consensus. (This is a null statement, but I wanted to make > it anyway). > >It is informational because it is neither the specification of a >protocol nor the specification of protocol payload, and therefore >cannot be standardized. Beyond that, consider it a standard. It is >the base from which we are working. We went over all much of the >ground be rediscovered here and more and reached consensus in order to >produce 1737. If we are always in a state of flux where we cannot >make assumptions based on previous consensus reached, we will NEVER >make progress and this is a futile exercise. I'm sure we all have >better things to do. So, take it as a given that RFC 1737 stands. If >there is consensus that it doesn't, this working group must be >disolved. > First I have to apologize, because I should have added an indication that that wasn't an entirely serious remark. Having said that, I still claim that as we move forward, we have the right to realize that something in 1737 isn't optimal or doesn't work etc. My opinion is that if there is rough consensus in the WG, then saying "but 1737 says that's a no-no" doesn't cut it. In a more directed vein, syntax draft already breaks 1737. Specifically, I'm refering to the "case insensitivity" requirement (the draft current has the NSS being case sensitive). "Case-insensitivity" is itself tied up in what character set we use. If we treat the NSS as a series of octets, then we can't have case insensitivity, because we haven't set a character set (ho boy am I digressing...) I do have an issue that folks either haven't been thinking about or have tabled until other things get settled, and that is the whole escaping issue. Will we ever want to escape octets of the URN at the client? Now, I discount transport encoding with the assumption that the transport mechanism has to unencode the URN before passing it up. The syntax draft was written assuming that we would, but that seems to create all sorts of troubles if we allow namespaces to set up their own escape mechanisms (and allow non restricted octets in the URN). Does anybody have an opinion on this? Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA20869 for urn-ietf-out; Wed, 6 Nov 1996 20:13:32 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA20864 for ; Wed, 6 Nov 1996 20:13:30 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15932 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 20:13:25 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id UAA15866; Wed, 6 Nov 1996 20:12:46 -0500 (EST) Message-Id: <199611070112.UAA15866@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Karen R. Sollins" Cc: moore@cs.utk.edu, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Wed, 06 Nov 1996 20:06:02 EST." <199611070106.UAA09788@lysithea.lcs.mit.edu> Date: Wed, 06 Nov 1996 20:12:46 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > I would like to be more specific about Keith Moore's statement: > > URNs should be precise enough that a human isn't required to > disambiguate the result. > > In particular, in light of the following requirement from RFC 1737 > > o Global uniqueness: The same URN will never be assigned to two > different resources. > > the URN will refer to exactly one resource from the perspective of > ^^^^^^^^^^^^^^^^^^^^^^^ > that naming authority assigning the name. Yes, this is exactly correct. But what this means is that if you ask the naming authority to do resolution on a URN, you won't get back references to multiple resources. Contrast this with a search for matches to a user-friendly string, which always has the potential for multiple hits. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA20775 for urn-ietf-out; Wed, 6 Nov 1996 20:07:02 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA20765 for ; Wed, 6 Nov 1996 20:06:59 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15871 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 20:06:58 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id UAA09788; Wed, 6 Nov 1996 20:06:02 -0500 Date: Wed, 6 Nov 1996 20:06:02 -0500 Message-Id: <199611070106.UAA09788@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: moore@cs.utk.edu Cc: urn-ietf@bunyip.com In-Reply-To: <199611062032.PAA10773@ig.cs.utk.edu> (message from Keith Moore on Wed, 06 Nov 1996 15:32:28 -0500) Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com I would like to be more specific about Keith Moore's statement: URNs should be precise enough that a human isn't required to disambiguate the result. In particular, in light of the following requirement from RFC 1737 o Global uniqueness: The same URN will never be assigned to two different resources. the URN will refer to exactly one resource from the perspective of ^^^^^^^^^^^^^^^^^^^^^^^ that naming authority assigning the name. This is actually a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ complicated problem having to do with who believes which things are "the same" by what definition. This was carefully crafted after lengthy and heated discussion. Before we launch into another lengthy discussion about this, I recommend to all of you who were not involved in the first round of this that you think about it VERY hard. Each naming authority is making a declaration about its own model of "sameness". This is not in the eye of the beholder, but in the eye of the namer. And it is that that we are expressing in URNs. We are saying that if you have two URNs and they are "the same" under some simple rules for canonicalizing them (also mentioned in 1737), then by some definition known to the naming authority (although not necessarily known to the holder of the URN) they identify and always will the same resource. For those of us who believe that semantics and mnemonics for humans should be handled elsewhere, this is the sum total of the semantics embodied in URNs and that is completely intentional. Note that this says nothing about what happens when you hold two different URNs. All bets are off in that case:-) Karen Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA20485 for urn-ietf-out; Wed, 6 Nov 1996 19:37:19 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA20470 for ; Wed, 6 Nov 1996 19:37:15 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15700 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 19:37:12 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id QAA29668; Wed, 6 Nov 1996 16:34:30 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id QAA22296; Wed, 6 Nov 1996 16:34:47 -0800 (PST) Date: Wed, 6 Nov 1996 16:34:47 -0800 (PST) From: Terry Allen Message-Id: <199611070034.QAA22296@ishtar.fsc.fujitsu.com> To: dgd@cs.bu.edu, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA20472 for urn-ietf-out; Wed, 6 Nov 1996 19:37:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA20465 for ; Wed, 6 Nov 1996 19:37:13 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15698 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 19:37:02 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id QAA29690 for ; Wed, 6 Nov 1996 16:35:19 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id QAA22323 for urn-ietf@bunyip.com; Wed, 6 Nov 1996 16:35:41 -0800 (PST) Date: Wed, 6 Nov 1996 16:35:41 -0800 (PST) From: Terry Allen Message-Id: <199611070035.QAA22323@ishtar.fsc.fujitsu.com> To: urn-ietf@bunyip.com Subject: [URN] Re meaningful names Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com [subject line changed to decouple Unicode from meaningful naming] I wrote: | Our longest-lived names actually are meaningful to humans; to support | your argument you have to establish that semantic drift affects | names specifically (Moby Dick, Julius Caesar, Assurnasirpal) and | that using them in the context of a defined name space does not ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | insulate them from semantic drift. Lewis Girod replied: | The names you are using as examples are all long lived because they | refer to conceptually immutable objects. This is the case in which | names are afforded some protection from semantic drift, although it | does not necessarily protect them completely. Out of context, I can't | tell if you mean Julius Caesar the guy who got stabbed or Julius | Caesar the play (and that was not an issue when JC was around!,) but | in the context of a namespace of people or plays that problem would be | resolved. Either way the name refers to a piece of history that, | whether or not it is well defined, people have an idea of what you | mean that doesn't change too much. Exactly. urn:roman.emperors:julius.caesar is not ambiguous. | However, I think what Keith was getting at was a problem that arises | when semantics is embedded in names in an attept to structure | hierarchical namespaces. The sort of semantic mechanism involved with | categorizing things is much more likely to drift over time; a | collection of companies originally categorized under ``Mainframes'' | might want to recategorize under ``Enterprise systems''. (Over longer | spans of time spellings and meanings of words change -- Julius Caesar | was originally filed under playes perhaps.) In the context of URNs, | every move we make we are stuck with forever... which eventually leads | to silly results and overall cruftiness. There is little point in | having semantically significant names unless you retain semantics that | makes sense as time goes on. Well, no. The name is the name; if you come to dislike it or think it doesn't mean the right thing you can map something else onto it in a new name space. If an existing name space uses "Mainframes", so be it; it will still work just fine as part of an unambiguous identifier (even if users have to be told "what name space FOO calls Mainframes we now call Enterprise Systems"). | Of course, as you point out there is no way to stop people from | putting semantics into names; the most effective way to deal with the | issue is to implement a system of user friendly names over the top of | URNs; 99% of the time the user would see and type only a UFN, and | these UFNs would be resolved to the URNs that could then be used as | long-lived references. Twice the work or more, doesn't deal with grandfathering, prone to error; the most effective way to deal with the issue is to drop your objection to meaningful names. Keith: | > Few people on this planet can accurately transcribe anything. | That's not true. People regularly transcribe telephone numbers, | email addresses, ISBNs, URLs, credit card numbers, etc. with | sufficient accuracy for their purposes. But ask people to Actually, they regularly mistranscribe them. In the past two weeks I have mistranscribed my VISA number and the VIN of my newly acquired used car, precisely because they are inherently meaningless. Martin, I think it was, pointed out the value of meaning for correct transcriptions. I think he's right. But I also think it's an issue this group should not legislate on: tell inventors of new name spaces what you like in the way of good practice, but don't prescribe. | > Your | > last point would have merit were it not that we absolutely must | > be able to grandfather in existing name spaces. | | Yes, we must be able to grandfather existing name spaces *that serve | similar purposes to URNs*. ISBNs qualify. Handles qualify. | Usenet message-ids qualify. But URNs don't have to handle existing | name spaces that don't have the characteristics that URNs have. This is circular argument unless it's grounding in the group's charter. What I find in the charter as Leslie posted it is: "Although the framework will allow URNs to be defined that vary in terms of degree of scalability and persistance, ensuring "user friendliness" of all resultant identifiers is beyond the scope of this group." That's far from saying that URNs shall not be meaningful, legible, or user-friendly. And RFC 1737 (section 5) explicitly takes no position on use of meaningful semantics. I don't find grounding for your argument. | I don't think this is a problem, because I don't think existing URN-like | name spaces are likely to be human friendly in the first place. (If someone | knows of a counterexample, please tell us.) Circular reasoning again. "Human friendliness" is not a defined property of URNs at the moment. Lewis: | One idea we were experimenting with here was to use a subset of ASCII | that included only numerals, punctuation and consonants, which would | make most words hard to express (at least in some languages). I cannot imagine that such an approach would find favor in the real world. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA20425 for urn-ietf-out; Wed, 6 Nov 1996 19:36:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA20420 for ; Wed, 6 Nov 1996 19:36:33 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15687 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 19:36:30 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id TAA09761; Wed, 6 Nov 1996 19:36:27 -0500 Date: Wed, 6 Nov 1996 19:36:27 -0500 Message-Id: <199611070036.TAA09761@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: jayhawk@ds.internic.net Cc: urn-ietf@bunyip.com In-Reply-To: <3280B0E8.6AF9@ds.internic.net> (message from Ryan Moats on Wed, 06 Nov 1996 09:38:16 -0600) Subject: Re: [URN] Comments on "I18N does not belong in URNs" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com Ryan Moats said: Well, RFC 1737 is informational so we can break it IF WE HAVE GOOD REASON and consensus. (This is a null statement, but I wanted to make it anyway). It is informational because it is neither the specification of a protocol nor the specification of protocol payload, and therefore cannot be standardized. Beyond that, consider it a standard. It is the base from which we are working. We went over all much of the ground be rediscovered here and more and reached consensus in order to produce 1737. If we are always in a state of flux where we cannot make assumptions based on previous consensus reached, we will NEVER make progress and this is a futile exercise. I'm sure we all have better things to do. So, take it as a given that RFC 1737 stands. If there is consensus that it doesn't, this working group must be disolved. Just so you understand, although you are reading a great deal of unanimity (not complete) from those involved in that earlier work, there was a great deal of contention then also. Karen Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA20161 for urn-ietf-out; Wed, 6 Nov 1996 19:14:00 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA20156 for ; Wed, 6 Nov 1996 19:13:54 -0500 Received: from trapdoor.dstc.edu.au by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15494 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 19:13:51 -0500 Received: from fatcat.dstc.edu.au (fatcat.dstc.edu.au [130.102.176.7]) by trapdoor.dstc.edu.au (8.6.9/8.6.12) with ESMTP id KAA29639; Thu, 7 Nov 1996 10:13:48 +1000 Received: (from renato@localhost) by fatcat.dstc.edu.au (8.6.10/8.6.12) id KAA07870; Thu, 7 Nov 1996 10:13:48 +1000 From: Renato Iannella Message-Id: <199611070013.KAA07870@fatcat.dstc.edu.au> Date: Thu, 7 Nov 1996 10:13:47 +1000 (EST) To: rbriscoe@jungle.bt.co.uk Cc: urn-ietf@bunyip.com Subject: Re[2]: [URN] Resolution Services (N2L etc) In-Reply-To: <2.2.32.19961106143106.006dd1d8@sherekhan.jungle.bt.co.uk> X-Mailer: Ishmail 1.3-960829-osf1 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Renato Iannella Errors-To: owner-urn-ietf@bunyip.com Bob Briscoe wrote: > If you insist, for instance, that the URC and the resource both have the > same URN, you are mandating that a URC must be authored with the permission > of the same domain of authority as the author of the resource itself (or > vice versa). This stops people *independently* publishing URCs about other > people's resources. Now where would the Web be today if you had to get > someone's permission to link to them? I get a good feeling knowing that if I resolve a URN, I will get back a URC describing that resource, created and maintained by the owners (or their agents) - and not a third party review of the resource. If I wanted that, then I would go to such a service provider. If I publish a URN like which points to a Technical Report at the DSTC - you can quote it in a Web Page - and like everything - I can only guarantee that it will last the lifetime of the DSTC. If you wish to provide a review of that Technical Report (via a URC or whatever) then you are free to, and to allocate you own URN, say . I don't wish to allocate a URN _directly_ to the Technical Report - because I reserve the right to move it around our network and to change its form. Cheers... Renato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dr Renato Iannella http://www.dstc.edu.au/RDU/staff/ri Research Data Network CRC urn:inet:dstc.edu.au:renato:home DSTC Pty Ltd, Uni Qld, 4072, AUSTRALIA phone/fax: +61 7 3365 4310/11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Australian WWW Technical Conference '97 -> http://www.dstc.edu.au/aw3tc Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA20068 for urn-ietf-out; Wed, 6 Nov 1996 18:48:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA20062 for ; Wed, 6 Nov 1996 18:48:43 -0500 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15393 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 18:48:41 -0500 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa26036; 6 Nov 96 18:48 EST Received: by skadhwe.lcs.mit.edu; (5.65v3.2/1.1.8.2/15Aug95-0306PM) id AA06182; Wed, 6 Nov 1996 18:48:00 -0500 Date: Wed, 6 Nov 1996 18:48:00 -0500 Message-Id: <9611062348.AA06182@skadhwe.lcs.mit.edu> From: Lewis Girod To: mduerst@ifi.unizh.ch Cc: tallen@fsc.fujitsu.com, moore@cs.utk.edu, urn-ietf@bunyip.com In-Reply-To: <"josef.ifi..893:06.10.96.10.21.51"@ifi.unizh.ch> (message from Martin J Duerst on Wed, 6 Nov 1996 11:21:49 +0100 (MET)) Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com Date: Wed, 6 Nov 1996 11:21:49 +0100 (MET) From: Martin J Duerst It is very clear that you can't retain semantics as time goes on. "mainframe" may mean something completely different in 5 years, or in 100 years, and it is impossible to predict. If people on Agreed; certainly some names will last longer than others but on the whole ``semantic drift'' is a fact of life. this group seriously would agree to restrict URNs to digits only for this reason, I would understand. But with ASCII as a "restricted" character set, we will definitely get cruftiness, and I see no reason to allow cruftiness for English, but to deny it for most other languages. One idea we were experimenting with here was to use a subset of ASCII that included only numerals, punctuation and consonants, which would make most words hard to express (at least in some languages). The interesting thing is that we already have that, in the current syntax draft. Just call the readable form of it UFNs, and call the encoded form, %HH-escaped, URNs. I have proposed similar names for these things, namely IRNs (internationalized ...). True, those strings are hard to read but it doesn't solve the problem because the URN and the UFN are tightly coupled -- the whole point of UFNs is that they are nicknames with a short lifespan. A UFN should be allowed to change over time without ever changing the aliased URN. -lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA17065 for urn-ietf-out; Wed, 6 Nov 1996 15:52:05 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA17059 for ; Wed, 6 Nov 1996 15:51:56 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13528 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 15:51:38 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id PAA10773; Wed, 6 Nov 1996 15:32:28 -0500 (EST) Message-Id: <199611062032.PAA10773@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: moore@cs.utk.edu (Keith Moore), tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Wed, 06 Nov 1996 18:02:19 +0100." <"josef.ifi..172:06.10.96.17.02.21"@ifi.unizh.ch> Date: Wed, 06 Nov 1996 15:32:28 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > >> >> Your > >> >> last point would have merit were it not that we absolutely must > >> >> be able to grandfather in existing name spaces. > >> > > >> >Yes, we must be able to grandfather existing name spaces *that serve > >> >similar purposes to URNs*. ISBNs qualify. Handles qualify. > >> >Usenet message-ids qualify. But URNs don't have to handle existing > >> >name spaces that don't have the characteristics that URNs have. > > >> And the fact that you > >> don't know about any such namespaces doesn't guarantee that there > >> are no such namespaces. > > I thought I didn't know any such namespaces when I wrote this mail. > But I have become aware that my postal savings account number in > Japan contains a kanji. The set of kanji in this case is limited > to one each for each of the central offices that keeps track of > postal savings accounts. I am very sure also that there are lots > of other examlpes that fit the requirements of URNs at least as > well as ISBNs that contain kanji or other non-ASCII characters. Perhaps. I don't have as big a problem with this, as long as there's a discipline about how they are assigned that prevents URNs from being used as search strings. That's my main worry. (URNs are also supposed to be transcribable, but I recognize that only a very small set of characters is transcribable by everyone on the planet.) Sorry, I can't make heads or tails of this. > So for grandfathering, we have two choices. > > 1) We interpret it as "direct grandfathering of characters", > in which case we have to allow a really wide range > of characters (i.e. ISO 10646). > 2) We interpret it as "indirect grandfathering", in which > case the digits, or whatever small set, will be > enough. I suspect there will be some of each. But we want the transformations from "old identifier" to URN to be simple and easy to remember. Ideally, you just prepend a URN:namespace: string. In some cases it may be necessary to remove punctuation; for instance, we might want to remove '-' characters from ISBNs. But that gets specified on a per-namespace basis. > Choosing ASCII only as for URLs would be very unfair cheating. If the names aren't human meaningful, I don't see what you're complaining about. > >> I definitely hate to see i18n just being moved around and delayed > >> by some people. With UTF-8 in URNs, we have made great progress. > > > >No, this is a big step backward. Just because there is a new layer > >being defined doesn't mean that I18N belongs there. > > > >I18N *is* important -- and I'd be happy to see a draft document or > >draft charter for a working group to define a protocol (say an extension > >of http/html) to resolve human-friendly names into URNs or URLs. > > Why is there a need for an additional protocol layer? > There is no need currently for English, is it? Yes, there is. Human-friendly names are inherently ambiguous, and have ambiguous meanings which require a human being to untangle. (If I ask for "Julius Caesar", do I mean the Shakespeare play or the person or what? Most people would think the name is unambiguous-- after all, they already know what they have in mind and the other meanings will not occur to them. But if you feed "Julius Caesar" to a library catalog, you will get back large numbers of hits. By contrast, if you feed ) URNs should be precise enough that a human isn't required to disambiguate the result. > And I don't want to have to search through long lists > of possible answers just because I use Japanese, whereas > I will get one immediate answer for English. The point is that you will often get multiple answers for English. English names are no more precise than names in other languages. > >> Some protocols (notably FTP) are also going in the direction of > >> UTF-8. Ideally, we will have a uniform solution for both URLs > >> and URNs, based on UTF-8. > > > >No. Ideally, if we figure out how to do this, we will have a > >uniform solution for all URLs. I18N (and even E8H :) absolutely > >doesn't belong in URNs. > > Well, if URLs are uniformly internationalized, I wouldn't > mind about URNs. But I know that there are people, and > this probably includes you, that claim that URLs also > are not designed to be human-friendly. They weren't *designed* to be human-friendly, and they don't do a very good job of it (if nothing else, they're hard to type and you can't easily say them out loud). But URLs tend to reflect their underlying file and directory structures, which *are* (sort of) human-friendly. (really they're more author-friendly) > >For URNs, human-friendliness will be excluded by design. > > I18N and human-friendliness are not the same thing. > For direct grandfathering, I18N is needed. If you are > sure human-friendliness will not sneak into URNs > with ASCII, it will also not sneak into URNs with > UTF-8. I think URNs need restrictions on human-friendliness in either case. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA13984 for urn-ietf-out; Wed, 6 Nov 1996 12:39:38 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA13979 for ; Wed, 6 Nov 1996 12:39:36 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11684 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 12:39:34 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 17:38:43 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 17:38:36 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Wed, 6 Nov 96 17:37:48 GMT Message-Id: <2.2.32.19961106173957.009f6a14@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Nov 1996 17:39:57 +0000 To: Harald.T.Alvestrand@uninett.no From: Bob Briscoe Subject: Re: [URN] Persistence as part of URN framework Cc: Fisher Mark , "urn-ietf@bunyip.com" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com At 15:58 06/11/96 +0100, Harald.T.Alvestrand@uninett.no wrote: >rbriscoe@jungle.bt.co.uk said: >> A URN user is not just someone who clicks on one. It could also be >> someone who publishes one (that you have published) to refer to your >> work in their work. They need to know how long they should reliably >> use your URN. Meta-data that any party might need is a proper >> candidate for holding in infrastructure. > >That's what I called an "URN buyer" >When I get an URN from someone, and apply it to my resources, >I would figure that I "own" that URN. No, no, no. I don't mean the owner of the URN. I mean someone who incorporates someone else's URN string in their work, just like I could stick urn:mailto:Harald.T.Alvestrand@uninett.no in here if you had published that as a URN. Then you are the 'URN buyer' or 'URN owner' I am the 'URN referrer' (inventing a word because quoter, citer etc. sound wobbly) And whoever clicks on the thing once they read this with a URN enabled mail client is the 'URN user'. If I put such an HREF to a URN in a WEB page, for instance, I might want to know how often to check it was still resolvable. > >rbriscoe@jungle.bt.co.uk said: >> Get my drift? >No. I still think the information publisher ("URN buyer) is the one >for which this information is vital, and that the information should >be part of the business contract between the provider of the URN >namespace and the information publisher. >The URN user (the one who looks up the information) should have no >need to know or care. Does this extra clarity change your view? Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA13887 for urn-ietf-out; Wed, 6 Nov 1996 12:23:13 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA13881 for ; Wed, 6 Nov 1996 12:23:11 -0500 Received: from CS.BU.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11543 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 12:23:07 -0500 Received: by cs.bu.edu (8.6.10/Spike-2.1) id MAA25270; Wed, 6 Nov 1996 12:22:49 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 6 Nov 1996 12:27:54 -0500 To: urn-ietf@bunyip.com From: dgd@cs.bu.edu (David G. Durand) Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: dgd@cs.bu.edu (David G. Durand) Errors-To: owner-urn-ietf@bunyip.com At 9:32 PM 11/5/96, Keith Moore wrote: >I don't think this is a problem, because I don't think existing URN-like >name spaces are likely to be human friendly in the first place. (If someone >knows of a counterexample, please tell us.) ISO Formal Public identitfiers are are semi-friendly (human-readable strings in the roman alphabet, assigned by users according to a prescribed organizational protocol). They are also in active, productive use in the SGML community, even without a global resolution service. >(Please note that assuming we can define I18N'ed URLs -- and there is >certainly a better case to be made for these then I18N'ed URNs -- I >would have no problem with this group defining resolution protocols that >can be used with them. It's just that I18N isn't appropriate for the >URN name-space. And I18N'ed URLs aren't in scope for this group.) Well, FPIs don't have that problem (the character set is _very_ restrictive), but, since we have human-readable URNs and they will continue to exist (good idea or not) the issue of I18N is relevant. I am not advocating either side at the moment -- I tend to agree that transcribability of I18N names will be hellish and error prone. On the other hand, eliminating almost all languages in the world from URNs is a big hit. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA13705 for urn-ietf-out; Wed, 6 Nov 1996 12:07:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA13700 for ; Wed, 6 Nov 1996 12:07:35 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11378 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 12:07:28 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01028-0@josef.ifi.unizh.ch>; Wed, 6 Nov 1996 18:02:20 +0100 Subject: Re: [URN] I18N does not belong in URNs To: moore@cs.utk.edu (Keith Moore) Date: Wed, 6 Nov 1996 18:02:19 +0100 (MET) Cc: moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611061542.KAA07371@ig.cs.utk.edu> from "Keith Moore" at Nov 6, 96 10:42:18 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3407 From: Martin J Duerst Message-Id: <"josef.ifi..172:06.10.96.17.02.21"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore wrote: >> >> Your >> >> last point would have merit were it not that we absolutely must >> >> be able to grandfather in existing name spaces. >> > >> >Yes, we must be able to grandfather existing name spaces *that serve >> >similar purposes to URNs*. ISBNs qualify. Handles qualify. >> >Usenet message-ids qualify. But URNs don't have to handle existing >> >name spaces that don't have the characteristics that URNs have. >> And the fact that you >> don't know about any such namespaces doesn't guarantee that there >> are no such namespaces. I thought I didn't know any such namespaces when I wrote this mail. But I have become aware that my postal savings account number in Japan contains a kanji. The set of kanji in this case is limited to one each for each of the central offices that keeps track of postal savings accounts. I am very sure also that there are lots of other examlpes that fit the requirements of URNs at least as well as ISBNs that contain kanji or other non-ASCII characters. Think about a library that collects Buddhist texts. For a specific bidirectionality feature, overriding, the use for part numbers is always cited. This means that there must be part numbers (a typical URN-like example again) that contain Arabic or Hebrew, mixed with numbers and Latin. So for grandfathering, we have two choices. 1) We interpret it as "direct grandfathering of characters", in which case we have to allow a really wide range of characters (i.e. ISO 10646). 2) We interpret it as "indirect grandfathering", in which case the digits, or whatever small set, will be enough. Choosing ASCII only as for URLs would be very unfair cheating. >> I definitely hate to see i18n just being moved around and delayed >> by some people. With UTF-8 in URNs, we have made great progress. > >No, this is a big step backward. Just because there is a new layer >being defined doesn't mean that I18N belongs there. > >I18N *is* important -- and I'd be happy to see a draft document or >draft charter for a working group to define a protocol (say an extension >of http/html) to resolve human-friendly names into URNs or URLs. Why is there a need for an additional protocol layer? There is no need currently for English, is it? And I don't want to have to search through long lists of possible answers just because I use Japanese, whereas I will get one immediate answer for English. >> Some protocols (notably FTP) are also going in the direction of >> UTF-8. Ideally, we will have a uniform solution for both URLs >> and URNs, based on UTF-8. > >No. Ideally, if we figure out how to do this, we will have a >uniform solution for all URLs. I18N (and even E8H :) absolutely >doesn't belong in URNs. Well, if URLs are uniformly internationalized, I wouldn't mind about URNs. But I know that there are people, and this probably includes you, that claim that URLs also are not designed to be human-friendly. >> For URNs, it will be by design, for >> URLs, it will be more by retrofitting, because according to >> the URL syntax document, the individual schemes have full >> autonomy. > >For URNs, human-friendliness will be excluded by design. I18N and human-friendliness are not the same thing. For direct grandfathering, I18N is needed. If you are sure human-friendliness will not sneak into URNs with ASCII, it will also not sneak into URNs with UTF-8. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA13458 for urn-ietf-out; Wed, 6 Nov 1996 11:44:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA13453 for ; Wed, 6 Nov 1996 11:44:34 -0500 Received: from weeble.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11113 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 11:43:45 -0500 Received: from jon by weeble.lut.ac.uk with smtp (Exim 0.55 #1) id E0vLAuZ-0006bD-00; Wed, 6 Nov 1996 16:33:07 +0000 Date: Wed, 6 Nov 1996 16:33:07 +0000 (GMT) From: Jon Knight X-Sender: jon@weeble.lut.ac.uk To: Bob Briscoe Cc: Terry Allen , FisherM@is3.indy.tce.com, urn-ietf@bunyip.com Subject: RE: [URN] Persistence as part of URN framework In-Reply-To: <2.2.32.19961106143207.006bdbbc@sherekhan.jungle.bt.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Jon Knight Errors-To: owner-urn-ietf@bunyip.com On Wed, 6 Nov 1996, Bob Briscoe wrote: > I'm saying the framework should require that any solution (like NAPTR) > should allow the option of specifying the longevity of the ability to > resolve the name. > > If you don't allow this, the only people who will ever use this will be > non-commercial organisations who think they are free to say "for ever" > without regard to the consequences. No commercial organisation would enter > into anything which included any commitment "for ever". Great, so this means that we can "commerce-proof" URNs from day one. Definately a +ve feature... :-) Tatty bye, Jim'll -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA13295 for urn-ietf-out; Wed, 6 Nov 1996 11:30:21 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA13290 for ; Wed, 6 Nov 1996 11:30:18 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10923 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 11:29:03 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00995-0@josef.ifi.unizh.ch>; Wed, 6 Nov 1996 17:26:44 +0100 Subject: Re: [URN] I18N does not belong in URNs To: moore@cs.utk.edu Date: Wed, 6 Nov 1996 17:26:43 +0100 (MET) Cc: girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611061530.KAA07042@ig.cs.utk.edu> from "Keith Moore" at Nov 6, 96 10:30:15 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1675 From: Martin J Duerst Message-Id: <"josef.ifi..590:06.10.96.16.26.45"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore wrote: >> If people on >> this group seriously would agree to restrict URNs to digits >> only for this reason, I would understand. > >Except for grandfathering, we could do this. As it is, I think >URNs can generally be restricted so that they're unlikely to be >human-friendly. Existing human-friendly namespaces are unlikely >to meet the requirements for URNs. Namespaces that do meet the >URN requirements will have their own disciplines for assigning names, >which URNs for those namespaces will inherit. New URN schemes >must have a specified discipline for assigning names. I understand what you want. And if everybody that will go to define namespaces and that will use URNs would understand it, too, it might work. But I am realistic in that I don't think things will stay restricted unless the syntax is very strictly restricted. It may be the 10 digits only, or it may be one or two more characters for separation and structure. But if you make it the whole Latin alphabet, even just upper case, people will break your intentions. What about saying that we have the digits plus "-" and "."? Or maybe "*" and "#", because then you can type URNs even on some telephones (don't believe these keys are on all telephones of the world, though). An ISBN namespace would define that "X" is substituted by ".". Other namespaces would need more difficult substitutions. The same types of substitutions would apply to namespaces using latin letters as well as namespaces using characters from other alphabets. Grandfathering would still work, although of course it would be very clumsy. But it would be the same clumsiness for everybody. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12738 for urn-ietf-out; Wed, 6 Nov 1996 10:43:47 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12733 for ; Wed, 6 Nov 1996 10:43:45 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10431 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 10:43:39 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id KAA07371; Wed, 6 Nov 1996 10:42:18 -0500 (EST) Message-Id: <199611061542.KAA07371@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Wed, 06 Nov 1996 11:44:05 +0100." <"josef.ifi..460:06.10.96.10.44.08"@ifi.unizh.ch> Date: Wed, 06 Nov 1996 10:42:18 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > >That's not true. People regularly transcribe telephone numbers, > >email addresses, ISBNs, URLs, credit card numbers, etc. with > >sufficient accuracy for their purposes. But ask people to > >transcribe identifiers in (say) Klingon, or to type them in > >on a keyboard not designed for such, and you'll get much lower > >accuracy. > > Most telephone numbers of companies are meaningful. Really? I don't find that to be true in practice. Looking through my personal phone book, only two out of thirty-one business phone numbers had any string or substring I could recognize as meaningful. > Most > email addresses are meaningful. Many URLs are meaningful. > Transcribability is aided by meaninfulness; there is a smaller > chance to make a mistake if one of these things is meaninful > than without meaningfulness. Yes. But long-term persistance is damaged by meaningfulness. > And Klingon is a VERY bad example. Nobody speaks Klingon. > Nobody grew up with Klingon. Nobody learned Klingon in > school as we learn the Latin script, and others learn > their traditional scripts. And Klingon isn't even in > Unicode. Klingon is a fancy of some SF enthusiasts, > and not a script used by millions every day to express > and exchange their thoughts and feelings. It's not a perfect example. I picked it because it is a foreign language to nearly everybody. > >> Your > >> last point would have merit were it not that we absolutely must > >> be able to grandfather in existing name spaces. > > > >Yes, we must be able to grandfather existing name spaces *that serve > >similar purposes to URNs*. ISBNs qualify. Handles qualify. > >Usenet message-ids qualify. But URNs don't have to handle existing > >name spaces that don't have the characteristics that URNs have. > >Offhand, I don't know of any name spaces that have such characteristics, > >that attempt to be human friendly. > > ISBNs don't qualify. They are not persistent. My understanding is that they're supposed to be persistent, though they are not always so in practice because some countries have too-little ISBN space so they must reassign them. > And the fact that you > don't know about any such namespaces doesn't guarantee that there > are no such namespaces. No, it doesn't. > About 30 years ago, some people said "I don't know of anybody > that would want to use anything else than English on computers". > And then they went on to design protocols :-(. > > > >> We should be building the big tent that everyone can live under, > >> not trying to close out name spaces we don't like. > > > >Yes, and we should also be restricting the problem to something that has > >a hope of a reasonable solution. They're not mutually exclusive, but > >over-reliance on the "one big tent" theory has caused the failure of > >many protocols. > > > >(Please note that assuming we can define I18N'ed URLs -- and there is > >certainly a better case to be made for these then I18N'ed URNs -- I > >would have no problem with this group defining resolution protocols that > >can be used with them. It's just that I18N isn't appropriate for the > >URN name-space. And I18N'ed URLs aren't in scope for this group.) > > When I participated in several attempts and discussions to > internationalize URLs, I was told by several people that have > also shown up on this list that for URLs, i18n would be difficult, > but that it would be solved for URNs. People had different understandings of what URNs are for. > I definitely hate to see i18n just being moved around and delayed > by some people. With UTF-8 in URNs, we have made great progress. No, this is a big step backward. Just because there is a new layer being defined doesn't mean that I18N belongs there. I18N *is* important -- and I'd be happy to see a draft document or draft charter for a working group to define a protocol (say an extension of http/html) to resolve human-friendly names into URNs or URLs. > Some protocols (notably FTP) are also going in the direction of > UTF-8. Ideally, we will have a uniform solution for both URLs > and URNs, based on UTF-8. No. Ideally, if we figure out how to do this, we will have a uniform solution for all URLs. I18N (and even E8H :) absolutely doesn't belong in URNs. > For URNs, it will be by design, for > URLs, it will be more by retrofitting, because according to > the URL syntax document, the individual schemes have full > autonomy. For URNs, human-friendliness will be excluded by design. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12531 for urn-ietf-out; Wed, 6 Nov 1996 10:41:35 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12526 for ; Wed, 6 Nov 1996 10:41:27 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10395 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 10:41:23 -0500 Received: by privateer.windrose.omaha.ne.us; Wed Nov 6 09:38 CST 1996 Message-Id: <3280B0E8.6AF9@ds.internic.net> Date: Wed, 06 Nov 1996 09:38:16 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Keith Moore , URN Mailing List Cc: Terry Allen , Lewis Girod , Martin J Duerst Subject: [URN] Comments on "I18N does not belong in URNs" References: <199611052333.SAA17528@ig.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com All- I'm going to try to munge my replies together to lots of mail that I saw this AM.... Keith Moore wrote (>): > > Support for UTF-8 in URNs is a gross layering violation. It also > violates the requirements of RFC 1737 in several ways: Well, RFC 1737 is informational so we can break it IF WE HAVE GOOD REASON and consensus. (This is a null statement, but I wanted to make it anyway). [Stuff snipped because I smell a rathole] > URNs need to have global scope and to be transcribable. Few people on > this planet could accurately transcribe more than a small percentage > of UTF-8. Even those that could transcribe it could probably not type > most UTF-8 characters on their keyboards. It's also completely > unacceptable to expect people to have a graphical display and hunt > through character menus just to type in a URN. This gets close to the encoding issue, so I postpone comments to below. > UTF-8 cannot be transported unmodified in common Internet protocols. > Even if some of those protocols are being upgraded to support more > charsets, it will be many years before UTF-8 can be transported safely > by these tools. Terry Allen commented (|): |That's an argument specifically against using UTF-8 at all. I'd |like to hear more on this point from the UTF-8 proponents. Martin Duerst replied (@): @The internet as such (TCP/IP) transports any kind of octets whatsoever. @Some of the higher level protocols fail in this respect because @of the short-sightedness of their designers. The worst is E-Mail, @because it works not only on the internet, but also with other @networks. But this is known, and with MIME, it is no problem @anymore. @Also, the URN syntax draft clearly specifies how URNs are @transported over 7-bit channels (using %HH). This works for @URLs, there is no reason it shouldn't work for URNs. @ @So I really wonder where there should be a problem. Well, this is not exactly the way I interpret the syntax draft. Section 3 of the draft states that encoding URNs for transport is the responsibility of the transport protocol. The implied statement is that the transport protocol is responsible for undoing the encoding. The encoding section is there in the case of encoding that the URN resolver has to undo itself. What I wonder (and am looking for some consesus on) is: "Is this necessary?" Also, the %HH escaping technique does have some problems with UTF-8 as Martin has pointed out on another thread... [more stuff snipped because I smell another rathole] > But incorporating UTF-8 in an attempt to make URNs human-readable is > an absolute showstopper. Well, I'll let the folks who asked for it defend why they wanted it, but I know I don't make any mention of human readability in the URN syntax draft. In fact, I view human readability as a namespace feature/bug/design goal and independent of the decision to support UTF-8 in the syntax doc. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12428 for urn-ietf-out; Wed, 6 Nov 1996 10:31:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12423 for ; Wed, 6 Nov 1996 10:31:31 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10288 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 10:31:28 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id KAA07042; Wed, 6 Nov 1996 10:30:16 -0500 (EST) Message-Id: <199611061530.KAA07042@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, moore@cs.utk.edu, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Wed, 06 Nov 1996 11:21:49 +0100." <"josef.ifi..893:06.10.96.10.21.51"@ifi.unizh.ch> Date: Wed, 06 Nov 1996 10:30:15 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > If people on > this group seriously would agree to restrict URNs to digits > only for this reason, I would understand. Except for grandfathering, we could do this. As it is, I think URNs can generally be restricted so that they're unlikely to be human-friendly. Existing human-friendly namespaces are unlikely to meet the requirements for URNs. Namespaces that do meet the URN requirements will have their own disciplines for assigning names, which URNs for those namespaces will inherit. New URN schemes must have a specified discipline for assigning names. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12361 for urn-ietf-out; Wed, 6 Nov 1996 10:24:27 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12356 for ; Wed, 6 Nov 1996 10:24:25 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10219 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 10:24:20 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id KAA06852; Wed, 6 Nov 1996 10:18:33 -0500 (EST) Message-Id: <199611061518.KAA06852@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: tallen@fsc.fujitsu.com, moore@cs.utk.edu, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Wed, 06 Nov 1996 11:04:14 +0100." <"josef.ifi..610:06.10.96.10.04.17"@ifi.unizh.ch> Date: Wed, 06 Nov 1996 10:18:33 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > >That's an argument specifically against using UTF-8 at all. I'd > >like to hear more on this point from the UTF-8 proponents. > > The internet as such (TCP/IP) transports any kind of octets whatsoever. > Some of the higher level protocols fail in this respect because > of the short-sightedness of their designers. The worst is E-Mail, > because it works not only on the internet, but also with other > networks. But this is known, and with MIME, it is no problem > anymore. Disagree. Many people do not have MIME mailers; many of those who do have MIME mailers do not have the ability to send or receive UTF-8 in MIME. This isn't going to change anytime soon. Even when it does change, people still won't be able to effectively transcribe arbitrary UTF-8 characters. This idea is a non-starter. > Also, the URN syntax draft clearly specifies how URNs are > transported over 7-bit channels (using %HH). This works for > URLs, there is no reason it shouldn't work for URNs. It doesn't work for URLs either if people see Kanji (or whatever) on their screens (or business cards) but can't type it in. > >| URNs should not be in any language, not even English. I would > >| enthusiastically support requiring all URNs to be in a restricted > >| character set or otherwise discourage human friendliness (though due > >| to grandfathering requirements, each URN scheme would need its own > >| rules for ensuring this). > > > >That's an absolute show-stopper, if you are asking that existing > >naming schemes develop encryption methods to transform their names > >into unreadable strings. People just won't do it because they > >will see it as unreasonable and unnecessary. > > Exactly. And it is also an absolute show-stopper if the "restricted > character set" still allows to use meaningful English, or if the > restricted character set contains characters such as ~[]{}^<>\#|` > ("unsafe" or not) that don't appear on the average non-US keyboard, > or the "$" that can easily be seen as a demonstration of US "superiority". My idea is that each URN scheme should specify its own rules for how to make its part of the name space transcribable. Using odd characters such as those you mention would rule it out. And each URN scheme would also specify the discipline to be used for assigning new names, such that they would not use meaningful English or anything else. As for the '$' and US superiority, get real. I realize lots of people are sensitive about such things, but hopefully we all know that when viewed > Keith, why don't you make an URN syntax proposal that only allows > the characters "0" and "1"? It can easily be shown that with > appropriate, protocol-or-whatever-specific encoding mechanisms, > that will be enough to grandfather whatever has to be grandfathered. I'm not going to dignify this with an answer. > Or why don't you define a specific URN subspace, in which only > numerical digits are allowed, and then see how well it gets populated > in comparison with spaces that allow i18n? You mean like ISBNs? (oh sorry, they use digits '-' and 'X') If you want long-term stable resource identifiers, you don't assign them according to what's popular. > >We should be building the big tent that everyone can live under, > >not trying to close out name spaces we don't like. If we were > >to discourage readability we would find URNs ignored by > >users of at least some name spaces, and we would no longer have > >the unified noncolliding name space we presently contemplate. > > Exactly. URLs were supposedly designed to not be human-readable, > or so I was told by some people that are now on this group. > Current practice shows that this design aim was failed by > a wide margin. URLs inherently reflect the naming structure of their underlying filesystems. That design goal overrode any notions of readability or non-readability for URLs. But URNs should not be bound by such constraints. > Some people have learned something from this > failure, namely that users want readability and meaning. Absolutely they do. But human-friendly identifiers are inherently ambiguous -- if not when they are assigned, then they become ambiguous over time. This is inherent in the way we usually name things -- we borrow meaning from elsewhere and lend it to something new. Names are nearly always imprecise. > They even put it into telephone numbers, which, by the proponents > of non-meaningful URLs/URNs, are cited as examples for well- > working non-meaningful schemes. > > The conclusion is very clear: To deny readability and meaningfulness > is to ignore human nature. Except that URNs aren't really designed for human consumption. (other than transcribability, which isn't really consumption) The spaces to be grandfathered under URNs aren't designed for human consumption either. They do turn out to be useful -- they're just not useful for what you have in mind. > Anyway, incorporating UTF-8 into URNs is not an absolute > showstopper at all. It is the first attempt at recognizing > from the beginnig that i18n is an issue that is important, > and designing a sound solution for it from the beginning. Agreed that I18N is important. But putting UTF-8 in URNs is technically unsound. The sound solution is to put I18N (and all human friendly names) in a layer above URNs. That way, there is a clean separation between searching and fuzzy matching of (inherently ambiguous) human-friendly names, and resolution of computer-friendly resource identifiers. > All other attempts at i18n on the internet were done as > after-thoughts, a fact that lead to many clumsy and suboptimal > solutions. Let's not make this mistake again. Absolutely. Let's therefore not put I18N in a layer where it doesn't belong, and where it cannot work well, and concentrate on building a layer where it will work well. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12346 for urn-ietf-out; Wed, 6 Nov 1996 10:24:09 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12341 for ; Wed, 6 Nov 1996 10:23:37 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10214 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 10:23:05 -0500 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <17119(6)>; Wed, 6 Nov 1996 07:22:42 PST Received: by golden.parc.xerox.com id <2696>; Wed, 6 Nov 1996 07:22:15 PST To: mduerst@ifi.unizh.ch Cc: girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, moore@cs.utk.edu, urn-ietf@bunyip.com In-Reply-To: <"josef.ifi..893:06.10.96.10.21.51"@ifi.unizh.ch> (message from Martin J Duerst on Wed, 6 Nov 1996 02:21:49 PST) Subject: Re: [URN] I18N does not belong in URNs From: Larry Masinter Message-Id: <96Nov6.072215pst."2696"@golden.parc.xerox.com> Date: Wed, 6 Nov 1996 07:22:15 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com # But with ASCII as a "restricted" character set, we will definitely # get cruftiness, and I see no reason to allow cruftiness for # English, but to deny it for most other languages. You say you see 'no reason' yet a simple reason seems compelling: The upper-case ASCII character set is available to computer users in any language, even when the native language does not use ASCII. For the same reason, many otherwise useful ASCII characters were excluded from URLs because they do not appear in some 'national' character sets: {}|~ etc. Regards, Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA11713 for urn-ietf-out; Wed, 6 Nov 1996 10:00:52 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA11708 for ; Wed, 6 Nov 1996 10:00:50 -0500 From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10059 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 10:00:48 -0500 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <07869-0@domen.uninett.no>; Wed, 6 Nov 1996 15:58:16 +0100 X-Mailer: exmh version 1.6.7 5/3/96 To: Bob Briscoe Cc: Fisher Mark , "urn-ietf@bunyip.com" Subject: Re: [URN] Persistence as part of URN framework In-Reply-To: Your message of "Wed, 06 Nov 1996 14:31:36 GMT." <2.2.32.19961106143136.006e2924@sherekhan.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 15:58:12 +0100 Message-Id: <7866.847292292@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com rbriscoe@jungle.bt.co.uk said: > A URN user is not just someone who clicks on one. It could also be > someone who publishes one (that you have published) to refer to your > work in their work. They need to know how long they should reliably > use your URN. Meta-data that any party might need is a proper > candidate for holding in infrastructure. That's what I called an "URN buyer" When I get an URN from someone, and apply it to my resources, I would figure that I "own" that URN. rbriscoe@jungle.bt.co.uk said: > Get my drift? No. I still think the information publisher ("URN buyer) is the one for which this information is vital, and that the information should be part of the business contract between the provider of the URN namespace and the information publisher. The URN user (the one who looks up the information) should have no need to know or care. Harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA09129 for urn-ietf-out; Wed, 6 Nov 1996 09:31:43 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA09124 for ; Wed, 6 Nov 1996 09:31:40 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09823 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 09:31:29 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:31:04 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:30:46 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Wed, 6 Nov 96 14:29:57 GMT Message-Id: <2.2.32.19961106143207.006bdbbc@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Nov 1996 14:32:07 +0000 To: Terry Allen From: Bob Briscoe Subject: RE: [URN] Persistence as part of URN framework Cc: FisherM@is3.indy.tce.com, urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com Apologies. I had better explain myself better - I've used terminology from a different planet (ISO Open Distributed Processing Reference Model) and been sloppy with it. I'll stick to URN terminology, and be more strict... I'll answer the general point at the end first. >I don't see where you get the idea that a URN has a TTL at all. Where >does the NAPTR proposal say it does? (maybe I missed something) NAPTR doesn't. I said I was criticising the URN framework, not NAPTR, which I just mentioned as an example of what you get if you follow the framework. I'm saying the framework should require that any solution (like NAPTR) should allow the option of specifying the longevity of the ability to resolve the name. If you don't allow this, the only people who will ever use this will be non-commercial organisations who think they are free to say "for ever" without regard to the consequences. No commercial organisation would enter into anything which included any commitment "for ever". At 11:40 05/11/96 -0800, Terry Allen wrote: >Bob Briscoe writes: > >| The point I'm making is that if we (BT) sell or give away a URN (in our role >| as an Internet Service Provider), to give our customers the ability to > >Your role as ISP does not mean that you have to take on the role of >name space owner. I meant that as an ISP we might want to also operate a name space resolver service for a delegated portion of a scheme name space (without necessarily owning the name space itself). As this dual role is obviously causing confusion, lets say BT NSR are the name space resolver and BT ISP wants to be a customer of the resolver service because they consider it commercially advantageous to attract customers in by proving they have a route out if they want. > >| switch suppliers but keep their resource names, we will contract with them >| to do this for a certain time. The URN service should be able to reflect > >You will contract with them to do what for a certain time? Resolve >URNs from a name space you control? I wouldn't want to contract with >a name space owner that promised to resolve my URNs only so long as >I used them as my ISP. Am I missing something? I meant exactly the opposite. That BT ISP would be "retailing" the URN from BT NSR (the "URN wholesaler") to BT ISP's customer, Jo Blow, so she could switch to a different ACME ISP but still keep her URNs. Then ACME ISP might pay the annual URN maintenance fees to BT NSR, and pass the cost on to Jo Blow. > >| this contractual fact so that other independent systems can know how long >| they can rely on that person's URN (e.g. so the third party's content >| management system can re-check HREFs as they are about to become obsolete >| rather than by polling). > >What would make them obsolete? Or do you mean nonresolvable? Sorry, I meant unresolvable. I accept that a URN would never be obsolete if you disallow re-use (but see below as to why this distinction is irrelevant). > >| Once we have contracted to do this, we will *have to* ensure the URN is >| still accessible in terms of network infrastructure and servers. If the user > >And in the same way as before; if your client moves a resource to >another URL, he has to tell you so. What changes about that when >your client moves his resources to another system? Nothing. I'm just saying we need to lay down how long our commitment is before we start. If BT NSR commit to 50 years, while the International Chamber of Commerce NSR commits to 200 years and Dodgy NSR commits to 5 years, Jo Blow, would have a market differentiator for her to decide which ISP she wanted, by which NSR they backed if name longevity was important to her. All I'm saying is that for a multi-collaborative project like the Web, this meta-data (longevity) about a resolution service for a portion of a name scheme is the most useful characteristic to tag URNs with, so that other services that use URNs it resolves can know when to re-check their validity (resolvability). I should clarify that I'm talking about the longevity of the resolution service for a portion of the name space, not of the whole naming scheme itself. The eventuality I envisage is that if this whole idea gets superceded, so we've got very few resolution requests coming in for our portion, we want to be able to wind up without jarring everyone off by surprising them with a notice to quit. Effectively it's putting the principles of ISO9000 (Quality and all that) into even the very long term committments we make. By saying in advance we're going to stop at a certain time, we can always extend it if the thing is still useful, but we have the option not to. This scenario assumes it is unlikely that we will be able to find someone else to take over resolving our bit of the name space - if we don't see a benefit in doing it ourselves, it's unlikely someone else will. > >| has thrown away their Web browser and got SuperCrap5 instead, that's not our >| concern. I'm not saying we are planning doing this, I'm just laying out the >| processes a commercial company would go through before marketing URNs. > >I don't get the point about the user changing browsers. My reply was to Mark Fisher's posting, in particular his phrase: >>>Even then, the data would only >>>persist as long as technical means remained to read the persistent data. I was saying BT NSR can commit to providing service and comms infrastructure for a set length of time, but if the user throws away the hardware or software they used to access BT NSR's service, that's not BT NSR's problem. The phrase "throws away" includes the them breaking it (e.g. by installing an incompatible OS). > >| That's just PURLs - saying certain names are more persistent than others. >| What I'm saying is that for URNs to mean anything, you need the *optional* >| capability to say *how* persistent you mean when you say "pretty persistent" >| because "for ever" is just meaningless. It must be optional because some > >Well, no it isn't. URNs are not to be reassigned; is that more meaningful >for you than "forever"? There are no guarantees (nor can there be any) >that a URN will be resolvable over the Internet forever. Sorry, yes, URNs are superficially better than PURLs in this respect. However, the "no reassignment" rule is unenforceable unless a resolver is available to test whether the URN has already been assigned (this resolver might be a wodge of print-out printed at the point that the on-line resolver was shut down for ever, but this would only be useful in proving a URN had been reassigned after the event). So pragmatically, the "no reassignment" rule amounts to "no reassignment for the life of the resolver", which leads back to my request for a TTL specified for the resolver. > >| people don't want to think about how long "persistent" means. Others might >| not want anyone to infer how long they expect to be in business from the >| length of their TTLs! >| >| A naming service should at minimum deal with the characteristics that you >| can hang on a name >| - persistence of the name > >The *name* is persistent, period. Resolution is another matter. Prove it (see previous comment)! >I don't know what you mean to refer to when you write "naming service". Sorry, I mean "name space resolver service". Final comment: If you accept that pragmatically, URNs don't exist for ever (because they only exist as long as anyone can prove they exist), you can still have the "no reassignment" rule for people to keep to on best effort. IOW, just because urn:duns:001234567:Dunn&Bradstreet_Collapse.report stops being resolvable, anyone who knew of broken references to it well into the future, shouldn't deliberately re-use it for something else. Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA09106 for urn-ietf-out; Wed, 6 Nov 1996 09:31:28 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA09101 for ; Wed, 6 Nov 1996 09:31:26 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09820 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 09:31:20 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:30:37 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:30:17 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Wed, 6 Nov 96 14:29:26 GMT Message-Id: <2.2.32.19961106143136.006e2924@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Nov 1996 14:31:36 +0000 To: Harald.T.Alvestrand@uninett.no From: Bob Briscoe Subject: Re: [URN] Persistence as part of URN framework Cc: Fisher Mark , "urn-ietf@bunyip.com" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com At 10:10 06/11/96 +0100, Harald.T.Alvestrand@uninett.no wrote: >Bob, >your point is well made that there needs to be some mechanism >which allows an URN buyer to make a guess at how long the resolution >service will stay in place. >This is, I believe, properly part of a business arrangement. > >For an URN *user*, this may be interesting, but not vital. A URN user is not just someone who clicks on one. It could also be someone who publishes one (that you have published) to refer to your work in their work. They need to know how long they should reliably use your URN. Meta-data that any party might need is a proper candidate for holding in infrastructure. >It could easily(?) be solved as part of "metadata" on an URN, >together with properties like the changability of the resource >(the URN for "today's weather in Trondheim" has different properties >than the URN for "the weather in Trondheim on Nov 6, 1996 around 10:07" >(cloudy, rainy and about 3 degrees Celsius, BTW)). >But I don't see it as a vital part of the infrastructure. Certainly, I agree it could be metadata held somewhere else. However, because it is meta-data owned directly by the URN (to be precise, the portion of the name space the URN is part of) and because it has important utility, if it *isn't* going to be held in the infrastructure, I believe it is the job of this working group to say how it *would* be held. If you leave this for 'ron (later on) as you suggest, you'll end up having to have a URC for a URN resolution when URCs get sorted, then what URN do you give the new URC? Then you'll need to hold the longevity of the resolution for the new URN somewhere... how about another URC? Get my drift? > >Using DNS TTL records for this is just broken; DNS TTLs are used >to limit caching of name->address mapping, and in the NAPTR proposal, >they should be a fraction of the time one expects to have advance >warning of a server relocation or mapping restructure. >Normal TTLs are on the order of 3 days, and are usually reduced to less >than 1 day before serious network reorganizations. I didn't mean that. I used the term TTL to mean a new Time To Live (of the resolution availability), not the specific TTL that DNS uses. Sorry again for being sloppy with my terminology. Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA09099 for urn-ietf-out; Wed, 6 Nov 1996 09:31:24 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA09094 for ; Wed, 6 Nov 1996 09:31:20 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09817 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 09:30:56 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:30:10 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:29:44 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Wed, 6 Nov 96 14:28:56 GMT Message-Id: <2.2.32.19961106143106.006dd1d8@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Nov 1996 14:31:06 +0000 To: Keith Moore From: Bob Briscoe Subject: Re: [URN] Resolution Services (N2L etc) Cc: urn-ietf@bunyip.com, moore@cs.utk.edu Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com At 23:27 05/11/96 -0500, Keith Moore wrote: >> 1.2 It strikes me that specifying available service requests (N2L, N2R etc) >> should not be the job of DNS or any URN resolution mechanism. You are adding >> metadata about the address that the name resolves to (i.e. allowed methods). >> NAPTR should simply get you to the place you asked for by mapping names to >> addresses. > >Not clear. DNS is the place to store name-to-IP-address bindings. If >the different services (methods) are at different IP-addresses, the >mappings between the names of the machines where the services reside, >and their IP addresses will be managed by DNS. And there's >potentially a big efficiency win to having the name-to-service mapping >lookup occur as a side-effect of an lookup that returns NAPTR records >with an /s flag. As long as everyone is clear that this is an efficiency hack, not a core requirement, and of the potential consequential problems, the purpose of my posting has been met. However, I would like to propose a far cleaner alternative (backed up by a load more words in the paper on URCs I'm about to put out) which doesn't need any efficiency hacks because it removes the need to differentiate between N2C, N2R etc. (and makes multi-collaborative working as easy as single domain - I'll explain why this is a problem below)... Lets take N2* first: N2C: I would propose, that each address mapping you would intend to give as a reply to an N2C or an N2L request, should each be given a different URN. URNs are cheap. As soon as you tie any two things (that are not the same thing) together under one name, you are doing the job of URCs not URNs. If you insist, for instance, that the URC and the resource both have the same URN, you are mandating that a URC must be authored with the permission of the same domain of authority as the author of the resource itself (or vice versa). This stops people *independently* publishing URCs about other people's resources. Now where would the Web be today if you had to get someone's permission to link to them? N2R: I'm much less clear why there is a need to differentiate between N2L and N2R in the first place. The name resolution service will give back a location whatever. It's then up to the client to use it and the protocol it specifies to access the resource if it wants, or not if it doesn't. Nothing else would scale, and any protocol schemes that needed the name resolver service to get resources for it should be killed at birth. Am I missing something? N2Ls & N2Rs: The plural versions are, IMHO, something that should be the default for all clients using URNs, with singular responses just a special case. All DNS BIND clients since some time in 1994 included round robin if they got a list of responses back, so if your user-agent asked BIND for an address it would get just one, but BIND would feed it another one if it asked again. If the user-agent wanted the list directly, there would be nothing stopping it implementing BIND internally. I think I've now reduced all the N2* options to a singular case for each URN - that is "N2Ls". Moving on to the L2* options. L2R, as I said under N2L & N2R (unless I'm missing something) is not the job of URNs. L2N is valid, but DNS already has a far more scalable solution by building a reverse mapping tree topped by a well known name (in-addr.arpa). This could be bent to do reverse NAPTR lookups. Effectively this makes and L2N into an N2Ls. L2L could be done with a reverse then a forward lookup. L2C would be useful, but in practice is unattainable if you want to allow multi-collaborative creation of URCs separate from resources. I have resigned myself to losing this capability in my work on URCs. The only way to do this is to rely on a harvester (like you have to do to find everyone who links to you on the Web today - you put in the URL of your resource as a query to the search engine). So that's thrown out all the proposed L2* opions or reduced them to "N2Ls". The bottom line is, you only need N2Ls or there are better ways to do this, IMHO. > >> Other systems (service discovery or navigation) should allow you to >> determine what you *should* ask for from the address once you get it, and >> once you have the address each protocol scheme might provide a well-known >> method for querying what methods you *can* do if that is what the scheme >> needs (e.g. HTTP/1.1 OPTIONS method). > >Only if all possible methods for a service are available at every >service location. You don't want to have to ask each service location >which methods are available at that server. See above. > >> IOW, the client should already know >> what it is going to do with the address it gets out of the URN service, or >> if it doesn't it should be prepared to find out. > >The client knows what it wants to do. But how the client does what it >wants to do may depend on what services are available. If there are >multiple resolution services available for a particular chunk of name >space, it might be that several of them will do what the client wants. >For example, if all a client wants is a URL, N2L might be more >efficient than N2C. Yes, you get efficiency, but at the expense of independence of collaboration. It would be valid to take the N2* approach to identify the "trusted" URCs if you wanted to do this, and still allow others to independently have other URCs. > >> OK, it may be *easier* to hack it this way, but that's not the point. You >> are embedding a duplication of meta-information in DNS which will always be >> prone to being out of date, unreliable, etc. Especially if the world moves >> to be much more dynamic in this area in the decades you envisage this >> lasting. More importantly, this information potentially has a different TTL >> than the address itself, so it will break your caching. > >I don't see what the problem is. DNS can specify TTLs on a >per-resource-record basis. The problem is that the decision on the *value* for the TTL is easy if it only relates to the life of the mapping. If it relates to the life of the mapping *and* the life of all the resolution services within those mappings, any potential for the automation of the generation of the TTL value has multiple dependencies. The more complexity you introduce, the more problems you get with distributed two phase commits, fraud modes etc. etc. > >At any rate, we should view the use of DNS for resolution as a >short-term experiment rather than a long-term solution. Viewed in >that context, it's not important that we get every little detail >right. Architecture isn't detail. I'm having to define BT's Future Commercial Internet Service Architecture on top of whatever you folks do. If I thought this wasn't important, I would have just kept schtumm and continued to listen to the URN stuff in read-only mode. Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA07668 for urn-ietf-out; Wed, 6 Nov 1996 06:39:31 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA07663 for ; Wed, 6 Nov 1996 06:39:24 -0500 Received: from weeble.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09231 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 06:38:39 -0500 Received: from jon by weeble.lut.ac.uk with smtp (Exim 0.55 #1) id E0vL6HX-0006Kl-00; Wed, 6 Nov 1996 11:36:31 +0000 Date: Wed, 6 Nov 1996 11:36:31 +0000 (GMT) From: Jon Knight X-Sender: jon@weeble.lut.ac.uk To: Martin J Duerst Cc: moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: <"josef.ifi..460:06.10.96.10.44.08"@ifi.unizh.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Jon Knight Errors-To: owner-urn-ietf@bunyip.com On Wed, 6 Nov 1996, Martin J Duerst wrote: > Most telephone numbers of companies are meaningful. Are they? How are they meaningful to anything other than the telcos switching system? (Hint: alphabetic mappings don't work in most of the world and increasingly "area" codes don't tell you anything about the area that the call is destined for or its cost unless you happen to be a telco computer). > Most email addresses are meaningful. Many URLs are meaningful. Granted. And look at the hassle its caused; domain name wars, lawsuits in the States, etc, etc. Nasty. > Transcribability is aided by meaninfulness; there is a smaller > chance to make a mistake if one of these things is meaninful > than without meaningfulness. I disagree; transcribability would be aided by check digits and error correcting codes. Meaning is a red herring, especially as meaning is in people, not in words (as one of my old school textbooks used to say). Other naming schemes (eg ISBNs) have the check digits and aren't meaningful and yet work well. I've just seen too many URLs misprinted in books and newspapers (the UK's Guardian newspaper is the worst offender IMHO) leading to confused and annoyed users (especially when the misprinted URL is itself valid but for a different resource). IMHO this is an a priori proof that meaning does not aid transcribability. I'd like to see some URN schemes appear that are specifically designed to survive mis-transcription. Having said that, I'm easy and if people want to use broken "meaningful" names for URNs, I think that's up to them. Let the buyer beware, etc. > ISBNs don't qualify. They are not persistent. Aren't they? Crumbs, that means that the one scheme everyone is always going on about grandfathering in URNs can't be grandfathered. Bummer. I wonder if that will stuff up our library OPAC? How long does an ISBN exist for until it gets reassigned to another publisher? Tatty bye, Jim'll -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA07466 for urn-ietf-out; Wed, 6 Nov 1996 05:45:18 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA07459 for ; Wed, 6 Nov 1996 05:45:16 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09116 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 05:45:11 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00576-0@josef.ifi.unizh.ch>; Wed, 6 Nov 1996 11:44:06 +0100 Subject: Re: [URN] I18N does not belong in URNs To: moore@cs.utk.edu Date: Wed, 6 Nov 1996 11:44:05 +0100 (MET) Cc: tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611060233.VAA20653@ig.cs.utk.edu> from "Keith Moore" at Nov 5, 96 09:32:59 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3278 From: Martin J Duerst Message-Id: <"josef.ifi..460:06.10.96.10.44.08"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore answers Terry Allen: >> Keith Moore writes: >That's not true. People regularly transcribe telephone numbers, >email addresses, ISBNs, URLs, credit card numbers, etc. with >sufficient accuracy for their purposes. But ask people to >transcribe identifiers in (say) Klingon, or to type them in >on a keyboard not designed for such, and you'll get much lower >accuracy. Most telephone numbers of companies are meaningful. Most email addresses are meaningful. Many URLs are meaningful. Transcribability is aided by meaninfulness; there is a smaller chance to make a mistake if one of these things is meaninful than without meaningfulness. And Klingon is a VERY bad example. Nobody speaks Klingon. Nobody grew up with Klingon. Nobody learned Klingon in school as we learn the Latin script, and others learn their traditional scripts. And Klingon isn't even in Unicode. Klingon is a fancy of some SF enthusiasts, and not a script used by millions every day to express and exchange their thoughts and feelings. >> Your >> last point would have merit were it not that we absolutely must >> be able to grandfather in existing name spaces. > >Yes, we must be able to grandfather existing name spaces *that serve >similar purposes to URNs*. ISBNs qualify. Handles qualify. >Usenet message-ids qualify. But URNs don't have to handle existing >name spaces that don't have the characteristics that URNs have. >Offhand, I don't know of any name spaces that have such characteristics, >that attempt to be human friendly. ISBNs don't qualify. They are not persistent. And the fact that you don't know about any such namespaces doesn't guarantee that there are no such namespaces. About 30 years ago, some people said "I don't know of anybody that would want to use anything else than English on computers". And then they went on to design protocols :-(. >> We should be building the big tent that everyone can live under, >> not trying to close out name spaces we don't like. > >Yes, and we should also be restricting the problem to something that has >a hope of a reasonable solution. They're not mutually exclusive, but >over-reliance on the "one big tent" theory has caused the failure of >many protocols. > >(Please note that assuming we can define I18N'ed URLs -- and there is >certainly a better case to be made for these then I18N'ed URNs -- I >would have no problem with this group defining resolution protocols that >can be used with them. It's just that I18N isn't appropriate for the >URN name-space. And I18N'ed URLs aren't in scope for this group.) When I participated in several attempts and discussions to internationalize URLs, I was told by several people that have also shown up on this list that for URLs, i18n would be difficult, but that it would be solved for URNs. I definitely hate to see i18n just being moved around and delayed by some people. With UTF-8 in URNs, we have made great progress. Some protocols (notably FTP) are also going in the direction of UTF-8. Ideally, we will have a uniform solution for both URLs and URNs, based on UTF-8. For URNs, it will be by design, for URLs, it will be more by retrofitting, because according to the URL syntax document, the individual schemes have full autonomy. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA07183 for urn-ietf-out; Wed, 6 Nov 1996 05:23:11 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA07178 for ; Wed, 6 Nov 1996 05:23:03 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09062 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 05:22:54 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00546-0@josef.ifi.unizh.ch>; Wed, 6 Nov 1996 11:21:50 +0100 Subject: Re: [URN] I18N does not belong in URNs To: girod@LCS.MIT.EDU Date: Wed, 6 Nov 1996 11:21:49 +0100 (MET) Cc: tallen@fsc.fujitsu.com, moore@cs.utk.edu, urn-ietf@bunyip.com In-Reply-To: <9611060236.AA05648@skadhwe.lcs.mit.edu> from "Lewis Girod" at Nov 5, 96 09:36:55 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1929 From: Martin J Duerst Message-Id: <"josef.ifi..893:06.10.96.10.21.51"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Lewis Girod wrote: >However, I think what Keith was getting at was a problem that arises >when semantics is embedded in names in an attept to structure >hierarchical namespaces. The sort of semantic mechanism involved with >categorizing things is much more likely to drift over time; a >collection of companies originally categorized under ``Mainframes'' >might want to recategorize under ``Enterprise systems''. (Over longer >spans of time spellings and meanings of words change -- Julius Caesar >was originally filed under playes perhaps.) In the context of URNs, >every move we make we are stuck with forever... which eventually leads >to silly results and overall cruftiness. There is little point in >having semantically significant names unless you retain semantics that >makes sense as time goes on. It is very clear that you can't retain semantics as time goes on. "mainframe" may mean something completely different in 5 years, or in 100 years, and it is impossible to predict. If people on this group seriously would agree to restrict URNs to digits only for this reason, I would understand. But with ASCII as a "restricted" character set, we will definitely get cruftiness, and I see no reason to allow cruftiness for English, but to deny it for most other languages. >Of course, as you point out there is no way to stop people from >putting semantics into names; the most effective way to deal with the >issue is to implement a system of user friendly names over the top of >URNs; 99% of the time the user would see and type only a UFN, and >these UFNs would be resolved to the URNs that could then be used as >long-lived references. The interesting thing is that we already have that, in the current syntax draft. Just call the readable form of it UFNs, and call the encoded form, %HH-escaped, URNs. I have proposed similar names for these things, namely IRNs (internationalized ...). Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA07096 for urn-ietf-out; Wed, 6 Nov 1996 05:09:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA07091 for ; Wed, 6 Nov 1996 05:09:43 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09038 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 05:08:32 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00516-0@josef.ifi.unizh.ch>; Wed, 6 Nov 1996 11:04:16 +0100 Subject: Re: [URN] I18N does not belong in URNs To: tallen@fsc.fujitsu.com Date: Wed, 6 Nov 1996 11:04:14 +0100 (MET) Cc: moore@cs.utk.edu, urn-ietf@bunyip.com In-Reply-To: <199611060057.QAA25635@ishtar.fsc.fujitsu.com> from "Terry Allen" at Nov 5, 96 04:57:00 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4413 From: Martin J Duerst Message-Id: <"josef.ifi..610:06.10.96.10.04.17"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Terry Allen writes: >Keith Moore writes: >| UTF-8 cannot be transported unmodified in common Internet protocols. >| Even if some of those protocols are being upgraded to support more >| charsets, it will be many years before UTF-8 can be transported safely >| by these tools. > >That's an argument specifically against using UTF-8 at all. I'd >like to hear more on this point from the UTF-8 proponents. The internet as such (TCP/IP) transports any kind of octets whatsoever. Some of the higher level protocols fail in this respect because of the short-sightedness of their designers. The worst is E-Mail, because it works not only on the internet, but also with other networks. But this is known, and with MIME, it is no problem anymore. Also, the URN syntax draft clearly specifies how URNs are transported over 7-bit channels (using %HH). This works for URLs, there is no reason it shouldn't work for URNs. So I really wonder where there should be a problem. >| URNs should not be in any language, not even English. I would >| enthusiastically support requiring all URNs to be in a restricted >| character set or otherwise discourage human friendliness (though due >| to grandfathering requirements, each URN scheme would need its own >| rules for ensuring this). > >That's an absolute show-stopper, if you are asking that existing >naming schemes develop encryption methods to transform their names >into unreadable strings. People just won't do it because they >will see it as unreasonable and unnecessary. Exactly. And it is also an absolute show-stopper if the "restricted character set" still allows to use meaningful English, or if the restricted character set contains characters such as ~[]{}^<>\#|` ("unsafe" or not) that don't appear on the average non-US keyboard, or the "$" that can easily be seen as a demonstration of US "superiority". Keith, why don't you make an URN syntax proposal that only allows the characters "0" and "1"? It can easily be shown that with appropriate, protocol-or-whatever-specific encoding mechanisms, that will be enough to grandfather whatever has to be grandfathered. Or why don't you define a specific URN subspace, in which only numerical digits are allowed, and then see how well it gets populated in comparison with spaces that allow i18n? >We should be building the big tent that everyone can live under, >not trying to close out name spaces we don't like. If we were >to discourage readability we would find URNs ignored by >users of at least some name spaces, and we would no longer have >the unified noncolliding name space we presently contemplate. Exactly. URLs were supposedly designed to not be human-readable, or so I was told by some people that are now on this group. Current practice shows that this design aim was failed by a wide margin. Some people have learned something from this failure, namely that users want readability and meaning. They even put it into telephone numbers, which, by the proponents of non-meaningful URLs/URNs, are cited as examples for well- working non-meaningful schemes. The conclusion is very clear: To deny readability and meaningfulness is to ignore human nature. >| But incorporating UTF-8 in an attempt to make URNs human-readable is >| an absolute showstopper. > >I didn't understand that to be the point of it; I would agree >that if the only reason for using Unicode were to make URNs >readable that wouldn't be a sufficient reason for using it; >but I'm not sure that we can't just append existing names in >their natural coded character set as the NSS part of a URN, >which would have mixed results for readability. (But then >I feel sure I haven't understood all the implications >of that approach.) The problem is that for namespaces that currently only exist on paper, there is no "natural" coded character set. And definitely, as Terry mentionnes, mixing various character encodings in different parts of URNs would make handling software extremely complicated. Anyway, incorporating UTF-8 into URNs is not an absolute showstopper at all. It is the first attempt at recognizing from the beginnig that i18n is an issue that is important, and designing a sound solution for it from the beginning. All other attempts at i18n on the internet were done as after-thoughts, a fact that lead to many clumsy and suboptimal solutions. Let's not make this mistake again. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA06632 for urn-ietf-out; Wed, 6 Nov 1996 04:12:52 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA06627 for ; Wed, 6 Nov 1996 04:12:45 -0500 From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08918 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 04:12:43 -0500 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <03736-0@domen.uninett.no>; Wed, 6 Nov 1996 10:10:24 +0100 X-Mailer: exmh version 1.6.7 5/3/96 To: Bob Briscoe Cc: Fisher Mark , "urn-ietf@bunyip.com" Subject: Re: [URN] Persistence as part of URN framework In-Reply-To: Your message of "Tue, 05 Nov 1996 15:54:31 GMT." <2.2.32.19961105155431.006d63e0@sherekhan.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 10:10:11 +0100 Message-Id: <3693.847271411@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com Bob, your point is well made that there needs to be some mechanism which allows an URN buyer to make a guess at how long the resolution service will stay in place. This is, I believe, properly part of a business arrangement. For an URN *user*, this may be interesting, but not vital. It could easily(?) be solved as part of "metadata" on an URN, together with properties like the changability of the resource (the URN for "today's weather in Trondheim" has different properties than the URN for "the weather in Trondheim on Nov 6, 1996 around 10:07" (cloudy, rainy and about 3 degrees Celsius, BTW)). But I don't see it as a vital part of the infrastructure. Using DNS TTL records for this is just broken; DNS TTLs are used to limit caching of name->address mapping, and in the NAPTR proposal, they should be a fraction of the time one expects to have advance warning of a server relocation or mapping restructure. Normal TTLs are on the order of 3 days, and are usually reduced to less than 1 day before serious network reorganizations. harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA04904 for urn-ietf-out; Wed, 6 Nov 1996 00:16:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA04899 for ; Wed, 6 Nov 1996 00:16:12 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07927 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 00:16:10 -0500 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16211(7)>; Tue, 5 Nov 1996 21:16:06 PST Received: by golden.parc.xerox.com id <2696>; Tue, 5 Nov 1996 21:15:50 PST To: FisherM@is3.indy.tce.com Cc: rbriscoe@jungle.bt.co.uk, urn-ietf@bunyip.com In-Reply-To: <327F3294@MSMAIL.INDY.TCE.COM> (message from Fisher Mark on Tue, 5 Nov 1996 04:26:00 PST) Subject: Re: [URN] Persistence as part of URN framework From: Larry Masinter Message-Id: <96Nov5.211550pst."2696"@golden.parc.xerox.com> Date: Tue, 5 Nov 1996 21:15:50 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com # But there are no technical hooks to guarantee persistence. On the # cypherpunks list a few months ago, there was a discussion of what it would # take to encrypt a message now, save it away for 100 years, then let the # recipient decrypt the message. The conclusion I drew from that discussion # was that this was a hard problem without a technical solution short of # deploying on every desktop and in every data center a persistent OS that # stored copies of all persistent data. Even then, the data would only # persist as long as technical means remained to read the persistent data. # (How many of us could read a 600 bpi 9-track tape or punched card deck even # if we had to?) Jerry Saltzer & a grad student wrote some papers about long term document retention and the issues of system design for storage that was to last longer than 'mean time between site failure'. (Site failure = flood, earthquake, insurrection, war company bankruptcy, etc.) Their system didn't require global replication, but it was important to be careful, and also not to be to complicated about your replication algorithms. Look for 'Library 2000' somewhere at www.lcs.mit.edu. >From http://www.parc.xerox.com/masinter/www5stds.html: > Some unsolved problems > - stuff goes away > Material behind URLs disappears > - pimples.com > vanity domains for billboard use > - Apple Computer and Apple Music > conflicts over short names > - urn:hdl:MTV/I_quit > how does authority migrate? > - http://www.mitro.paris.fr/mitro > Non-ASCII names Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA04188 for urn-ietf-out; Tue, 5 Nov 1996 23:27:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA04181 for ; Tue, 5 Nov 1996 23:27:42 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07683 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 23:27:40 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id XAA28250; Tue, 5 Nov 1996 23:27:21 -0500 (EST) Message-Id: <199611060427.XAA28250@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bob Briscoe Cc: urn-ietf@bunyip.com, moore@cs.utk.edu Subject: Re: [URN] Resolution Services (N2L etc) In-Reply-To: Your message of "Tue, 05 Nov 1996 10:01:53 GMT." <2.2.32.19961105100153.006d0998@sherekhan.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Nov 1996 23:27:21 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > 1.2 It strikes me that specifying available service requests (N2L, N2R etc) > should not be the job of DNS or any URN resolution mechanism. You are adding > metadata about the address that the name resolves to (i.e. allowed methods). > NAPTR should simply get you to the place you asked for by mapping names to > addresses. Not clear. DNS is the place to store name-to-IP-address bindings. If the different services (methods) are at different IP-addresses, the mappings between the names of the machines where the services reside, and their IP addresses will be managed by DNS. And there's potentially a big efficiency win to having the name-to-service mapping lookup occur as a side-effect of an lookup that returns NAPTR records with an /s flag. > Other systems (service discovery or navigation) should allow you to > determine what you *should* ask for from the address once you get it, and > once you have the address each protocol scheme might provide a well-known > method for querying what methods you *can* do if that is what the scheme > needs (e.g. HTTP/1.1 OPTIONS method). Only if all possible methods for a service are available at every service location. You don't want to have to ask each service location which methods are available at that server. > IOW, the client should already know > what it is going to do with the address it gets out of the URN service, or > if it doesn't it should be prepared to find out. The client knows what it wants to do. But how the client does what it wants to do may depend on what services are available. If there are multiple resolution services available for a particular chunk of name space, it might be that several of them will do what the client wants. For example, if all a client wants is a URL, N2L might be more efficient than N2C. > OK, it may be *easier* to hack it this way, but that's not the point. You > are embedding a duplication of meta-information in DNS which will always be > prone to being out of date, unreliable, etc. Especially if the world moves > to be much more dynamic in this area in the decades you envisage this > lasting. More importantly, this information potentially has a different TTL > than the address itself, so it will break your caching. I don't see what the problem is. DNS can specify TTLs on a per-resource-record basis. At any rate, we should view the use of DNS for resolution as a short-term experiment rather than a long-term solution. Viewed in that context, it's not important that we get every little detail right. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA04135 for urn-ietf-out; Tue, 5 Nov 1996 23:16:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA04130 for ; Tue, 5 Nov 1996 23:16:44 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07658 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 23:16:40 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id XAA28069; Tue, 5 Nov 1996 23:16:17 -0500 (EST) Message-Id: <199611060416.XAA28069@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Daniel LaLiberte Cc: Patrik Faltstrom , urn-ietf@bunyip.com, moore@cs.utk.edu Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: Your message of "Tue, 05 Nov 1996 00:16:00 CST." <199611050616.AAA21984@ncsa.uiuc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Nov 1996 23:16:17 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > Instead, perhaps you are trying to say that the name is not tightly > bound to information associated with the resource, that the > information can change and still the name is the name of the resource. > For example, the "resolution protocol" can change. I have no problem > with that, and never have. But this is still not abstractly different > from what happens to a URL. You're right, it's not. But the difference between URNs and URLs has almost nothing to do with how they are resolved (indeed, I hope they use the same resolution mechanisms), and a lot to do with how the names are assigned and maintained. That is, some people think it's very useful to have a class of names for which certain properties (long-term persistence, global scope, ..., and the rest of those named in RFC 1737) hold. Those names are called URNs. Yes, they're a lot like URLs in how they are handled. But the whole point in having URNs as a separate name space is: if you know that a particular name is a URN, you know that the RFC 1737 properties hold. (Or if you prefer, an assertion that a name is a URN implies that the RFC 1737 properties hold.) This is why URNs need a URN: prefix -- because a lot of the value in having a URN name space with those properties is so *humans* can recognize a URN when they see it. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA03958 for urn-ietf-out; Tue, 5 Nov 1996 22:22:40 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA03953 for ; Tue, 5 Nov 1996 22:22:38 -0500 Received: from docker.library.uwa.edu.au by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07292 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 22:22:34 -0500 Received: from dehquhp.library.uwa.edu.au (dehquhp.library.uwa.edu.au [130.95.106.230]) by docker.library.uwa.edu.au (8.8.0/8.8.0) with ESMTP id LAA13045; Wed, 6 Nov 1996 11:22:13 +0800 (WST) Message-Id: <199611060322.LAA13045@docker.library.uwa.edu.au> From: "James K. Tauber" To: "Stu Weibel" , , Subject: Re: [URN] URN-WG home page w/references Date: Wed, 6 Nov 1996 11:23:03 +0800 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "James K. Tauber" Errors-To: owner-urn-ietf@bunyip.com > I think pointers to the PURL page and to the HANDLE page are > certainly in order as the only deployed approaches to persistent > naming at the present time. James Clark's SGML parsing library, SP, and included tools do FPI resolution via the delegating catalogue proposal. So there's another deployed approach. James -- James K. Tauber / jtauber@library.uwa.edu.au University CWIS Coordination Officer The University of Western Australia Room 2.42, Scholars' Centre, Reid Library Phone: +61 9 380 7136 FAX: +61 9 380 1128 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA03782 for urn-ietf-out; Tue, 5 Nov 1996 21:47:43 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA03777 for ; Tue, 5 Nov 1996 21:47:41 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07182 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 21:47:28 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id VAA23245; Tue, 5 Nov 1996 21:47:13 -0500 (EST) Message-Id: <199611060247.VAA23245@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Lewis Girod Cc: tallen@fsc.fujitsu.com, moore@cs.utk.edu, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Tue, 05 Nov 1996 21:36:55 EST." <9611060236.AA05648@skadhwe.lcs.mit.edu> Date: Tue, 05 Nov 1996 21:47:12 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > Of course, as you point out there is no way to stop people from > putting semantics into names; the most effective way to deal with the > issue is to implement a system of user friendly names over the top of > URNs; 99% of the time the user would see and type only a UFN, and > these UFNs would be resolved to the URNs that could then be used as > long-lived references. Yes. Precisely. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA03706 for urn-ietf-out; Tue, 5 Nov 1996 21:38:08 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA03701 for ; Tue, 5 Nov 1996 21:38:06 -0500 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07139 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 21:38:04 -0500 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa17675; 5 Nov 96 21:36 EST Received: by skadhwe.lcs.mit.edu; (5.65v3.2/1.1.8.2/15Aug95-0306PM) id AA05648; Tue, 5 Nov 1996 21:36:55 -0500 Date: Tue, 5 Nov 1996 21:36:55 -0500 Message-Id: <9611060236.AA05648@skadhwe.lcs.mit.edu> From: Lewis Girod To: tallen@fsc.fujitsu.com Cc: moore@cs.utk.edu, urn-ietf@bunyip.com In-Reply-To: <199611060057.QAA25635@ishtar.fsc.fujitsu.com> (message from Terry Allen on Tue, 5 Nov 1996 16:57:00 -0800 (PST)) Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com Date: Tue, 5 Nov 1996 16:57:00 -0800 (PST) From: Terry Allen Our longest-lived names actually are meaningful to humans; to support your argument you have to establish that semantic drift affects names specifically (Moby Dick, Julius Caesar, Assurnasirpal) and that using them in the context of a defined name space does not insulate them from semantic drift. The names you are using as examples are all long lived because they refer to conceptually immutable objects. This is the case in which names are afforded some protection from semantic drift, although it does not necessarily protect them completely. Out of context, I can't tell if you mean Julius Caesar the guy who got stabbed or Julius Caesar the play (and that was not an issue when JC was around!,) but in the context of a namespace of people or plays that problem would be resolved. Either way the name refers to a piece of history that, whether or not it is well defined, people have an idea of what you mean that doesn't change too much. However, I think what Keith was getting at was a problem that arises when semantics is embedded in names in an attept to structure hierarchical namespaces. The sort of semantic mechanism involved with categorizing things is much more likely to drift over time; a collection of companies originally categorized under ``Mainframes'' might want to recategorize under ``Enterprise systems''. (Over longer spans of time spellings and meanings of words change -- Julius Caesar was originally filed under playes perhaps.) In the context of URNs, every move we make we are stuck with forever... which eventually leads to silly results and overall cruftiness. There is little point in having semantically significant names unless you retain semantics that makes sense as time goes on. Of course, as you point out there is no way to stop people from putting semantics into names; the most effective way to deal with the issue is to implement a system of user friendly names over the top of URNs; 99% of the time the user would see and type only a UFN, and these UFNs would be resolved to the URNs that could then be used as long-lived references. -lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA03645 for urn-ietf-out; Tue, 5 Nov 1996 21:33:25 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA03640 for ; Tue, 5 Nov 1996 21:33:22 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07127 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 21:33:18 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id VAA20653; Tue, 5 Nov 1996 21:33:00 -0500 (EST) Message-Id: <199611060233.VAA20653@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Terry Allen Cc: moore@cs.utk.edu, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Tue, 05 Nov 1996 16:57:00 PST." <199611060057.QAA25635@ishtar.fsc.fujitsu.com> Date: Tue, 05 Nov 1996 21:32:59 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > Keith Moore writes: > | Support for UTF-8 in URNs is a gross layering violation. It also > | violates the requirements of RFC 1737 in several ways: > | > | URNs are not intended to be meaningful to humans. Rather, the desire > | for URNs to have a long lifetime indicates that they should not be > | human-friendly; otherwise, semantic drift will cause those names to > | need to be changed over time. > > Our longest-lived names actually are meaningful to humans; to support > your argument you have to establish that semantic drift affects > names specifically (Moby Dick, Julius Caesar, Assurnasirpal) and > that using them in the context of a defined name space does not > insulate them from semantic drift. Names like those you quote are ambiguous. There are different works named Moby Dick (not just the book by Melville; there are plays, screen plays, radio plays, parodies) and Julius Caesar (not just the play by Shakespeare, but also biographies, screen plays, and at least one symphony). Ambiguous names aren't suitable as URNs. > | URNs need to have global scope and to be transcribable. Few people on > | this planet could accurately transcribe more than a small percentage > | of UTF-8. Even those that could transcribe it could probably not type > | most UTF-8 characters on their keyboards. It's also completely > | unacceptable to expect people to have a graphical display and hunt > | through character menus just to type in a URN. > > Few people on this planet can accurately transcribe anything. That's not true. People regularly transcribe telephone numbers, email addresses, ISBNs, URLs, credit card numbers, etc. with sufficient accuracy for their purposes. But ask people to transcribe identifiers in (say) Klingon, or to type them in on a keyboard not designed for such, and you'll get much lower accuracy. > Your > last point would have merit were it not that we absolutely must > be able to grandfather in existing name spaces. Yes, we must be able to grandfather existing name spaces *that serve similar purposes to URNs*. ISBNs qualify. Handles qualify. Usenet message-ids qualify. But URNs don't have to handle existing name spaces that don't have the characteristics that URNs have. Offhand, I don't know of any name spaces that have such characteristics, that attempt to be human friendly. > | URNs should not be in any language, not even English. I would > | enthusiastically support requiring all URNs to be in a restricted > | character set or otherwise discourage human friendliness (though due > | to grandfathering requirements, each URN scheme would need its own > | rules for ensuring this). > > That's an absolute show-stopper, if you are asking that existing > naming schemes develop encryption methods to transform their names > into unreadable strings. People just won't do it because they > will see it as unreasonable and unnecessary. I don't think this is a problem, because I don't think existing URN-like name spaces are likely to be human friendly in the first place. (If someone knows of a counterexample, please tell us.) > We should be building the big tent that everyone can live under, > not trying to close out name spaces we don't like. Yes, and we should also be restricting the problem to something that has a hope of a reasonable solution. They're not mutually exclusive, but over-reliance on the "one big tent" theory has caused the failure of many protocols. (Please note that assuming we can define I18N'ed URLs -- and there is certainly a better case to be made for these then I18N'ed URNs -- I would have no problem with this group defining resolution protocols that can be used with them. It's just that I18N isn't appropriate for the URN name-space. And I18N'ed URLs aren't in scope for this group.) Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA03031 for urn-ietf-out; Tue, 5 Nov 1996 19:58:21 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA03026 for ; Tue, 5 Nov 1996 19:58:18 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06729 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 19:58:16 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id QAA01084; Tue, 5 Nov 1996 16:56:43 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id QAA25635; Tue, 5 Nov 1996 16:57:00 -0800 (PST) Date: Tue, 5 Nov 1996 16:57:00 -0800 (PST) From: Terry Allen Message-Id: <199611060057.QAA25635@ishtar.fsc.fujitsu.com> To: moore@cs.utk.edu, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Keith Moore writes: | Support for UTF-8 in URNs is a gross layering violation. It also | violates the requirements of RFC 1737 in several ways: | | URNs are not intended to be meaningful to humans. Rather, the desire | for URNs to have a long lifetime indicates that they should not be | human-friendly; otherwise, semantic drift will cause those names to | need to be changed over time. Our longest-lived names actually are meaningful to humans; to support your argument you have to establish that semantic drift affects names specifically (Moby Dick, Julius Caesar, Assurnasirpal) and that using them in the context of a defined name space does not insulate them from semantic drift. However, I'm still undecided on using Unicode at all, as I'm sure I don't understand some of the issues. I'll be meeting with Ron tomorrow and will hope to be wiser after that. | URNs need to have global scope and to be transcribable. Few people on | this planet could accurately transcribe more than a small percentage | of UTF-8. Even those that could transcribe it could probably not type | most UTF-8 characters on their keyboards. It's also completely | unacceptable to expect people to have a graphical display and hunt | through character menus just to type in a URN. Few people on this planet can accurately transcribe anything. Your last point would have merit were it not that we absolutely must be able to grandfather in existing name spaces. | UTF-8 cannot be transported unmodified in common Internet protocols. | Even if some of those protocols are being upgraded to support more | charsets, it will be many years before UTF-8 can be transported safely | by these tools. That's an argument specifically against using UTF-8 at all. I'd like to hear more on this point from the UTF-8 proponents. | URNs should not be in any language, not even English. I would | enthusiastically support requiring all URNs to be in a restricted | character set or otherwise discourage human friendliness (though due | to grandfathering requirements, each URN scheme would need its own | rules for ensuring this). That's an absolute show-stopper, if you are asking that existing naming schemes develop encryption methods to transform their names into unreadable strings. People just won't do it because they will see it as unreasonable and unnecessary. We should be building the big tent that everyone can live under, not trying to close out name spaces we don't like. If we were to discourage readability we would find URNs ignored by users of at least some name spaces, and we would no longer have the unified noncolliding name space we presently contemplate. Some name spaces will turn out not to work well, whether on the Internet, in general, or after several centuries. Users of those name spaces will have to cope or convert to other name spaces with better characteristics. That's life. | But incorporating UTF-8 in an attempt to make URNs human-readable is | an absolute showstopper. I didn't understand that to be the point of it; I would agree that if the only reason for using Unicode were to make URNs readable that wouldn't be a sufficient reason for using it; but I'm not sure that we can't just append existing names in their natural coded character set as the NSS part of a URN, which would have mixed results for readability. (But then I feel sure I haven't understood all the implications of that approach.) Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA02378 for urn-ietf-out; Tue, 5 Nov 1996 18:33:31 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA02373 for ; Tue, 5 Nov 1996 18:33:29 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06273 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 18:33:27 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id SAA17528; Tue, 5 Nov 1996 18:33:21 -0500 (EST) Message-Id: <199611052333.SAA17528@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ To: urn-ietf@bunyip.com Subject: [URN] I18N does not belong in URNs Cc: moore@cs.utk.edu From: Keith Moore Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Nov 1996 18:33:21 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com Support for UTF-8 in URNs is a gross layering violation. It also violates the requirements of RFC 1737 in several ways: URNs are not intended to be meaningful to humans. Rather, the desire for URNs to have a long lifetime indicates that they should not be human-friendly; otherwise, semantic drift will cause those names to need to be changed over time. URNs need to have global scope and to be transcribable. Few people on this planet could accurately transcribe more than a small percentage of UTF-8. Even those that could transcribe it could probably not type most UTF-8 characters on their keyboards. It's also completely unacceptable to expect people to have a graphical display and hunt through character menus just to type in a URN. UTF-8 cannot be transported unmodified in common Internet protocols. Even if some of those protocols are being upgraded to support more charsets, it will be many years before UTF-8 can be transported safely by these tools. URNs should not be in any language, not even English. I would enthusiastically support requiring all URNs to be in a restricted character set or otherwise discourage human friendliness (though due to grandfathering requirements, each URN scheme would need its own rules for ensuring this). But incorporating UTF-8 in an attempt to make URNs human-readable is an absolute showstopper. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA22019 for urn-ietf-out; Tue, 5 Nov 1996 14:42:21 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA22013 for ; Tue, 5 Nov 1996 14:42:14 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04304 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 14:42:06 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id LAA24073; Tue, 5 Nov 1996 11:40:26 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id LAA14040; Tue, 5 Nov 1996 11:40:32 -0800 (PST) Date: Tue, 5 Nov 1996 11:40:32 -0800 (PST) From: Terry Allen Message-Id: <199611051940.LAA14040@ishtar.fsc.fujitsu.com> To: FisherM@is3.indy.tce.com, rbriscoe@jungle.bt.co.uk Subject: RE: [URN] Persistence as part of URN framework Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Bob Briscoe writes: | The point I'm making is that if we (BT) sell or give away a URN (in our role | as an Internet Service Provider), to give our customers the ability to Your role as ISP does not mean that you have to take on the role of name space owner. | switch suppliers but keep their resource names, we will contract with them | to do this for a certain time. The URN service should be able to reflect You will contract with them to do what for a certain time? Resolve URNs from a name space you control? I wouldn't want to contract with a name space owner that promised to resolve my URNs only so long as I used them as my ISP. Am I missing something? | this contractual fact so that other independent systems can know how long | they can rely on that person's URN (e.g. so the third party's content | management system can re-check HREFs as they are about to become obsolete | rather than by polling). What would make them obsolete? Or do you mean nonresolvable? | Once we have contracted to do this, we will *have to* ensure the URN is | still accessible in terms of network infrastructure and servers. If the user And in the same way as before; if your client moves a resource to another URL, he has to tell you so. What changes about that when your client moves his resources to another system? | has thrown away their Web browser and got SuperCrap5 instead, that's not our | concern. I'm not saying we are planning doing this, I'm just laying out the | processes a commercial company would go through before marketing URNs. I don't get the point about the user changing browsers. | That's just PURLs - saying certain names are more persistent than others. | What I'm saying is that for URNs to mean anything, you need the *optional* | capability to say *how* persistent you mean when you say "pretty persistent" | because "for ever" is just meaningless. It must be optional because some Well, no it isn't. URNs are not to be reassigned; is that more meaningful for you than "forever"? There are no guarantees (nor can there be any) that a URN will be resolvable over the Internet forever. | people don't want to think about how long "persistent" means. Others might | not want anyone to infer how long they expect to be in business from the | length of their TTLs! | | A naming service should at minimum deal with the characteristics that you | can hang on a name | - persistence of the name The *name* is persistent, period. Resolution is another matter. I don't know what you mean to refer to when you write "naming service". | - ownership | - address mapping | - persistence of the address mapping | - I would say "etc." but that's about it! My complaint is that two items | from even this minimal list of four aren't covered by the framework (whereas | the NAPTR proposal starts introducing gratuitous characteristics that are | owned by the resource the name points at, not the name itself). | | I would be happy if we came down on a solution which just optionally | specified the longevity of the name (not the DNS NAPTR TTL because this is | the longevity of the mapping, not the name itself). You could potentially | have name TTLs of 10 years (or more). So a sensible discussion could now | ensue as to whether this is practical - to expect any descendant of DNS to | inherit any long lived TTLs from within DNS. I would say yes. I don't see where you get the idea that a URN has a TTL at all. Where does the NAPTR proposal say it does? (maybe I missed something) Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA19183 for urn-ietf-out; Tue, 5 Nov 1996 10:54:41 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA19178 for ; Tue, 5 Nov 1996 10:54:39 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02105 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 10:54:25 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 15:54:06 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 15:53:46 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Tue, 5 Nov 96 15:52:59 GMT Message-Id: <2.2.32.19961105155506.006d9050@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Nov 1996 15:55:06 +0000 To: Fisher Mark From: Bob Briscoe Subject: RE: [URN] Resolution Services (N2L etc) Cc: "urn-ietf@bunyip.com" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com At 07:41 05/11/96 EST, Fisher Mark wrote: > >>1.2 It strikes me that specifying available service requests (N2L, N2R etc) >>should not be the job of DNS or any URN resolution mechanism. You are >>adding >>metadata about the address that the name resolves to (i.e. allowed >>methods). >>NAPTR should simply get you to the place you asked for by mapping names to >>addresses. >[...] >>OK, it may be *easier* to hack it this way, but that's not the point. You >>are embedding a duplication of meta-information in DNS which will always be >>prone to being out of date, unreliable, etc. Especially if the world moves >>to be much more dynamic in this area in the decades you envisage this >>lasting. More importantly, this information potentially has a different TTL >>than the address itself, so it will break your caching. > >But this is meta-information that is not easy to change. It is not like, >"oh, from midnight to 6am I'll support HTTP, then from 6am to 8am I'll >support HTTP and our experimental Z39.50-2000, then from 8am-6pm I'll only >support whois++", etc. Rapidly changing what final resolution services are >supported is not a particularly easy task, or a desirable task even when it >is made easy. I'm not throwing out the resolution service, as you appear to think I am saying. I'm throwing out the service requests supported by that service (N2L, N2Ls, N2R, N2Rs, N2C etc.). This is one level of indirection too far. It's irrelevant whether they are likely to change *often*. What is important is that they will change at potentially *different* times to the resolution service. This is what breaks the meaning of the TTL. Once you have the resolution service you can find the service requests it supports, so this is unnecessary complexity. > >Could one (or more) of the DNS wizards on the list speak as to what the >average TTL tends to be? From what Bob is saying, it sounds like he expects >the TTL of the NAPTR record to be a longer time than the expected time >between final resolution service changes. >====================================================================== >Mark Leighton Fisher Thomson Consumer Electronics >fisherm@indy.tce.com Indianapolis, IN > > ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA19174 for urn-ietf-out; Tue, 5 Nov 1996 10:54:12 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA19167 for ; Tue, 5 Nov 1996 10:54:09 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02081 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 10:53:56 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 15:53:26 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 15:53:11 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Tue, 5 Nov 96 15:52:24 GMT Message-Id: <2.2.32.19961105155431.006d63e0@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Nov 1996 15:54:31 +0000 To: Fisher Mark From: Bob Briscoe Subject: RE: [URN] Persistence as part of URN framework Cc: "urn-ietf@bunyip.com" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com At 07:26 05/11/96 EST, Fisher Mark wrote: > >>Persistence is a contractual >>thing which needs a technical hook to hang the contract on. > >But there are no technical hooks to guarantee persistence. On the >cypherpunks list a few months ago, there was a discussion of what it would >take to encrypt a message now, save it away for 100 years, then let the >recipient decrypt the message. The conclusion I drew from that discussion >was that this was a hard problem without a technical solution short of >deploying on every desktop and in every data center a persistent OS that >stored copies of all persistent data. Even then, the data would only >persist as long as technical means remained to read the persistent data. > (How many of us could read a 600 bpi 9-track tape or punched card deck even >if we had to?) The point I'm making is that if we (BT) sell or give away a URN (in our role as an Internet Service Provider), to give our customers the ability to switch suppliers but keep their resource names, we will contract with them to do this for a certain time. The URN service should be able to reflect this contractual fact so that other independent systems can know how long they can rely on that person's URN (e.g. so the third party's content management system can re-check HREFs as they are about to become obsolete rather than by polling). Once we have contracted to do this, we will *have to* ensure the URN is still accessible in terms of network infrastructure and servers. If the user has thrown away their Web browser and got SuperCrap5 instead, that's not our concern. I'm not saying we are planning doing this, I'm just laying out the processes a commercial company would go through before marketing URNs. The same issues come up with phone number portability between suppliers. > >The important point about URNs is that there is an extra level of >indirection built into the resolution process, such that the URN -> URL -> >resource resolution (in the N2L case) can transparently (at the user agent >level) change the URL(s) associated with that URN, without changing the URN. > Kind of a superpowered 30x redirect, in a way. This technical detail (the >extra level of indirection) is what will give URNs additional capability to >persist. That's just PURLs - saying certain names are more persistent than others. What I'm saying is that for URNs to mean anything, you need the *optional* capability to say *how* persistent you mean when you say "pretty persistent" because "for ever" is just meaningless. It must be optional because some people don't want to think about how long "persistent" means. Others might not want anyone to infer how long they expect to be in business from the length of their TTLs! A naming service should at minimum deal with the characteristics that you can hang on a name - persistence of the name - ownership - address mapping - persistence of the address mapping - I would say "etc." but that's about it! My complaint is that two items from even this minimal list of four aren't covered by the framework (whereas the NAPTR proposal starts introducing gratuitous characteristics that are owned by the resource the name points at, not the name itself). I would be happy if we came down on a solution which just optionally specified the longevity of the name (not the DNS NAPTR TTL because this is the longevity of the mapping, not the name itself). You could potentially have name TTLs of 10 years (or more). So a sensible discussion could now ensue as to whether this is practical - to expect any descendant of DNS to inherit any long lived TTLs from within DNS. I would say yes. Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA18387 for urn-ietf-out; Tue, 5 Nov 1996 09:38:07 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA18382 for ; Tue, 5 Nov 1996 09:38:05 -0500 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01399 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 09:38:03 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id GAA07931; Tue, 5 Nov 1996 06:37:15 -0800 Date: Tue, 5 Nov 1996 06:37:14 -0800 (PST) From: "Gregory J. Woodhouse" To: Bob Briscoe Cc: urn-ietf@bunyip.com Subject: Re: [URN] Resolution Services (N2L etc) In-Reply-To: <2.2.32.19961105100153.006d0998@sherekhan.jungle.bt.co.uk> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com I'm sure I'm saying the same thing tht others will say, but while I think NAPTR will likely be replaced with some other mechanism, I do think the extra layer of indirections serves several very important purposes: Most importantly, it makes the underlying mechanism truly distributed and scalable. It also decentralizes URN administration provides a smooth transition path to new technologies. No other mechanism that I've seen proposed can make these claims. --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/home.html resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA18364 for urn-ietf-out; Tue, 5 Nov 1996 09:37:13 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA18359 for ; Tue, 5 Nov 1996 09:37:10 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01389 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 09:37:08 -0500 Message-Id: <9611051437.AA01389@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Tue Nov 5 08:36 CST 1996 From: "Ryan Moats" To: "Martin J Duerst" , "Patrik Faltstrom" Cc: "urn-ietf@bunyip.com" Date: Tue, 05 Nov 96 08:37:29 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax draft) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Tue, 5 Nov 1996 10:46:17 +0100 (MET), Patrik Faltstrom wrote: > >On Mon, 4 Nov 1996, Martin J Duerst wrote: > >> - Specify that protocols may only reserve 1-octet UTF-8 characters >> (i.e. ASCII). > >This is kind of stupid from my point of view. We do not win >anything by doing this, do we? > >> - Specify that protocols have to define their own escaping mechanisms >> for things beyond ASCII. > >This is better, much better. We say that native URNs are 8-bit >following the UTF-8 specification and that the protocol have >to come up with its own escaping mechanism. This is ok, so long as we are talking about transport protocol escaping which is removed before the URN is resolved. What we are talking about here (in my mind at least) is escaping that the URN resolver "sees" and has to remove before resolving a URN. Now, there is are some folks who have commented to me that there shouldn't be any escaping that the URN resolver should have to handle. If so, then the portions of the draft covering escaping can be removed. However, if we decide that the URN resolver must handle escaping, then I claim that the types of escaping it handles should be specified in the syntax document, not somewhere else. I should note that there has not been enough comment either way on the preceding paragraph to claim "rough consensus"... Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA17824 for urn-ietf-out; Tue, 5 Nov 1996 08:27:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA17819 for ; Tue, 5 Nov 1996 08:27:18 -0500 Received: from fssun10.dev.oclc.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01106 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 08:27:15 -0500 Received: from orc.NISOR (orc.dev.oclc.org) by oclc.org (4.1/SMI-4.1) id AA16003; Tue, 5 Nov 96 08:27:13 EST Received: by orc.NISOR (SMI-8.6/SMI-SVR4) id IAA04028; Tue, 5 Nov 1996 08:28:15 -0500 Date: Tue, 5 Nov 1996 08:28:15 -0500 From: weibel@oclc.org (Stu Weibel) Message-Id: <199611051328.IAA04028@orc.NISOR> To: leslie@bunyip.com, urn-ietf@bunyip.com Subject: Re: [URN] URN-WG home page w/references X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: weibel@oclc.org (Stu Weibel) Errors-To: owner-urn-ietf@bunyip.com I think pointers to the PURL page and to the HANDLE page are certainly in order as the only deployed approaches to persistent naming at the present time. http://purl.org http://www.handle.net thanks, stu > Yes, there is a homepage for the group, although I have not had time to > update it since we became a working group. > > It lives at: > > http://www.bunyip.com/research/urn-ietf/ > > Suggestions for content are welcomed... > > Leslie. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA17731 for urn-ietf-out; Tue, 5 Nov 1996 08:17:07 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA17726 for ; Tue, 5 Nov 1996 08:17:05 -0500 Received: from fssun10.dev.oclc.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01071 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 08:17:03 -0500 Received: from orc.NISOR (orc.dev.oclc.org) by oclc.org (4.1/SMI-4.1) id AA15140; Tue, 5 Nov 96 08:16:52 EST Received: by orc.NISOR (SMI-8.6/SMI-SVR4) id IAA03246; Tue, 5 Nov 1996 08:17:53 -0500 Date: Tue, 5 Nov 1996 08:17:53 -0500 From: weibel@oclc.org (Stu Weibel) Message-Id: <199611051317.IAA03246@orc.NISOR> To: urn-ietf@bunyip.com, FisherM@is3.indy.tce.com Subject: RE: [URN] Persistence as part of URN framework X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: weibel@oclc.org (Stu Weibel) Errors-To: owner-urn-ietf@bunyip.com Mark Fisher writes, > The important point about URNs is that there is an extra level of > indirection built into the resolution process, such that the URN -> URL -> > resource resolution (in the N2L case) can transparently (at the user agent > level) change the URL(s) associated with that URN, without changing the URN. > Kind of a superpowered 30x redirect, in a way. This technical detail (the > extra level of indirection) is what will give URNs additional capability to > persist. This is the part of the problem that PURLs address very well: one additional level of indirection that allows the management (contractural or otherwise) of URLs by an organization with the committment to maintain persistent access. I have argued for in the past and continue to believe that persistence is only to a small extent a function of the underlying technology: persistence is a function of *organizational committment*. Another essential element of some (but not all) varieties of URN is assurance that the object that is named is exactly the same as it was at the time of name assignment. PURLs do not address this issue, but can be used as a layer in such a solution (OCLC and CNRI have, together, demonstrated such a solution with PURL-HANDLE resolution, but there can clearly be other solutions). The third major element, protocol independence, is highly desirable but less urgent: We can live with the current protocols for the time while the necessary infrastructure (NAPTR for example) is developed and deployed. stu Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id HAA17578 for urn-ietf-out; Tue, 5 Nov 1996 07:40:51 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id HAA17573 for ; Tue, 5 Nov 1996 07:40:45 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00898 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 07:40:39 -0500 Received: by seawall with (8.6.12/) id HAA15012; Tue, 5 Nov 1996 07:40:38 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma015008; Tue Nov 5 07:40:13 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <327F35D5@MSMAIL.INDY.TCE.COM>; Tue, 05 Nov 96 07:40:53 EST From: Fisher Mark To: Bob Briscoe , "urn-ietf@bunyip.com" Subject: RE: [URN] Resolution Services (N2L etc) Date: Tue, 05 Nov 96 07:41:00 EST Message-Id: <327F35D5@MSMAIL.INDY.TCE.COM> Encoding: 30 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com >1.2 It strikes me that specifying available service requests (N2L, N2R etc) >should not be the job of DNS or any URN resolution mechanism. You are >adding >metadata about the address that the name resolves to (i.e. allowed >methods). >NAPTR should simply get you to the place you asked for by mapping names to >addresses. [...] >OK, it may be *easier* to hack it this way, but that's not the point. You >are embedding a duplication of meta-information in DNS which will always be >prone to being out of date, unreliable, etc. Especially if the world moves >to be much more dynamic in this area in the decades you envisage this >lasting. More importantly, this information potentially has a different TTL >than the address itself, so it will break your caching. But this is meta-information that is not easy to change. It is not like, "oh, from midnight to 6am I'll support HTTP, then from 6am to 8am I'll support HTTP and our experimental Z39.50-2000, then from 8am-6pm I'll only support whois++", etc. Rapidly changing what final resolution services are supported is not a particularly easy task, or a desirable task even when it is made easy. Could one (or more) of the DNS wizards on the list speak as to what the average TTL tends to be? From what Bob is saying, it sounds like he expects the TTL of the NAPTR record to be a longer time than the expected time between final resolution service changes. ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id HAA17492 for urn-ietf-out; Tue, 5 Nov 1996 07:26:48 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id HAA17487 for ; Tue, 5 Nov 1996 07:26:46 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00859 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 07:26:44 -0500 Received: by seawall with (8.6.12/) id HAA14740; Tue, 5 Nov 1996 07:26:38 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma014736; Tue Nov 5 07:26:20 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <327F3294@MSMAIL.INDY.TCE.COM>; Tue, 05 Nov 96 07:27:00 EST From: Fisher Mark To: Bob Briscoe , "urn-ietf@bunyip.com" Subject: RE: [URN] Persistence as part of URN framework Date: Tue, 05 Nov 96 07:26:00 EST Message-Id: <327F3294@MSMAIL.INDY.TCE.COM> Encoding: 25 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com >Persistence is a contractual >thing which needs a technical hook to hang the contract on. But there are no technical hooks to guarantee persistence. On the cypherpunks list a few months ago, there was a discussion of what it would take to encrypt a message now, save it away for 100 years, then let the recipient decrypt the message. The conclusion I drew from that discussion was that this was a hard problem without a technical solution short of deploying on every desktop and in every data center a persistent OS that stored copies of all persistent data. Even then, the data would only persist as long as technical means remained to read the persistent data. (How many of us could read a 600 bpi 9-track tape or punched card deck even if we had to?) The important point about URNs is that there is an extra level of indirection built into the resolution process, such that the URN -> URL -> resource resolution (in the N2L case) can transparently (at the user agent level) change the URL(s) associated with that URN, without changing the URN. Kind of a superpowered 30x redirect, in a way. This technical detail (the extra level of indirection) is what will give URNs additional capability to persist. ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA17086 for urn-ietf-out; Tue, 5 Nov 1996 06:40:34 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA17081 for ; Tue, 5 Nov 1996 06:40:32 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00703 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 06:40:31 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id GAA13431; Tue, 5 Nov 1996 06:40:30 -0500 Message-Id: <199611051140.GAA13431@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Tue, 5 Nov 1996 06:40:30 -0500 In-Reply-To: Larry Masinter's message as of Nov 4, 16:52 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Larry Masinter , urn-ietf@bunyip.com Subject: Re: [URN] URN-WG home page w/references Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Larry, > Is there a 'home page' for the URN working group? It would be really > useful to collect together the references & previous work. There was a > home page for URI that was (and still is) really useful, but lately > I've had to search for URN & URC references. Yes, there is a homepage for the group, although I have not had time to update it since we became a working group. It lives at: http://www.bunyip.com/research/urn-ietf/ Suggestions for content are welcomed... Leslie. -- ---------------------------------------------------------------------------- "The light at the end of the tunnel Leslie Daigle is often the blindingly obvious..." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA16516 for urn-ietf-out; Tue, 5 Nov 1996 05:02:10 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA16509 for ; Tue, 5 Nov 1996 05:02:08 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00444 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 05:01:35 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 10:01:23 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 10:01:06 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Tue, 5 Nov 96 10:00:21 GMT Message-Id: <2.2.32.19961105100228.006d9db8@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Nov 1996 10:02:28 +0000 To: urn-ietf@bunyip.com From: Bob Briscoe Subject: [URN] NAPTR substitution expression grammar Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com Comments on draft-ietf-urn-naptr-00.txt (cont.): 2. Substitution expression grammar 2.1 You claim to be copying sed ERE syntax (with the caveat it may all change to cover UTF-8). To avoid confusion for sed gits like me, could you consider using the escaped parentheses \( and \) to do back refs, rather than the one character ones ( and ) which simply imply grouping in POSIX EREs by my understanding. 2.2 Also, it would be friendly to allow any delimiter, like sed does, not just "/" (e.g. "!.*//\([^/:]+\)!\1!i" is a lot more readable than "/.*\/\/\([^\/:]+\)/\1/i"). Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA16491 for urn-ietf-out; Tue, 5 Nov 1996 05:01:38 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA16486 for ; Tue, 5 Nov 1996 05:01:36 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00435 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 05:01:29 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 10:01:17 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 10:00:58 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Tue, 5 Nov 96 10:00:07 GMT Message-Id: <2.2.32.19961105100213.006c3a98@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Nov 1996 10:02:13 +0000 To: urn-ietf@bunyip.com From: Bob Briscoe Subject: [URN] Persistence as part of URN framework Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com Comments on draft-daigle-urnframework-00.txt: On 12-Oct-96 in "[URN] suggestions for "A Framework for the Assignment and Resolution ..."" Larry Masinter said: This is a rather old song, but I will sing it again: draft-daigle-urnframework-00.txt is inadequate because it does not deal with any of the issues of administration & security & migration & longevity that are the entire motivation for having 'URNs' instead of 'URLs'. I couldn't agree more. If the only difference between a name and a location is persistence, can you really get away with defining a whole framework that doesn't mention even an optional capability to define how persistent a name is (or at least a best estimate)? You've chosen the DNS which has TTL in there as a given, but your framework doesn't put any requirements on this. For instance, we might want to sell persistent names, but if there's no way of telling how persistent they are, you've got nothing to prove anything, and the client has got nothing to buy into. Persistence is a contractual thing which needs a technical hook to hang the contract on. I believe defining persistence fits your charter too. Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA16453 for urn-ietf-out; Tue, 5 Nov 1996 05:01:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA16448 for ; Tue, 5 Nov 1996 05:01:12 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00429 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 05:01:09 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 10:00:46 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 10:00:34 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Tue, 5 Nov 96 09:59:46 GMT Message-Id: <2.2.32.19961105100153.006d0998@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Nov 1996 10:01:53 +0000 To: urn-ietf@bunyip.com From: Bob Briscoe Subject: [URN] Resolution Services (N2L etc) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com Strong comments on draft-ietf-urn-naptr-00 draft below. I've just joined this mail-list as I'm working on URCs and wanted to make sure I was up to date on back-ground. I have read all the drafts that I think are relevant (URN urnframework-00, urn-naptr-00, urn-syntax-00) and the last couple of months mail archives to get up to date. I have tried not to cover old ground, but please pull me up if I stray. In fact it's homely to note the same old arguments about URNs are still being re-cycled. I admire your collective sticking power. I haven't read daniel-http because it relies so heavily on the resolution service capability of NAPTR to which I have big objections (below). Comments on draft-ietf-urn-naptr-00.txt: 1. Resolution Services 1.1 Under Brief overview and examples, it says, "Resolution services are operations such as N2R... These are discussed in the URN framework document[2]..." They aren't (and below I say why I think they shouldn't be, other than to exclude them). 1.2 It strikes me that specifying available service requests (N2L, N2R etc) should not be the job of DNS or any URN resolution mechanism. You are adding metadata about the address that the name resolves to (i.e. allowed methods). NAPTR should simply get you to the place you asked for by mapping names to addresses. Other systems (service discovery or navigation) should allow you to determine what you *should* ask for from the address once you get it, and once you have the address each protocol scheme might provide a well-known method for querying what methods you *can* do if that is what the scheme needs (e.g. HTTP/1.1 OPTIONS method). IOW, the client should already know what it is going to do with the address it gets out of the URN service, or if it doesn't it should be prepared to find out. OK, it may be *easier* to hack it this way, but that's not the point. You are embedding a duplication of meta-information in DNS which will always be prone to being out of date, unreliable, etc. Especially if the world moves to be much more dynamic in this area in the decades you envisage this lasting. More importantly, this information potentially has a different TTL than the address itself, so it will break your caching. IMHO, what you *can* do with the URN should normally be put in with the advert for the URN (e.g. the mailing, the cereal box, the web page) that the service provider shouts about to get the thing used, and other people pass on in the normal way this gossip spreads. It is up to the service providers to promulgate the URN in such a way that when the client uses it, the correct method is invoked (e.g. if you want U2L, not U2R on a Web page, you just type the URN, rather than HREF'ing it). Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA16345 for urn-ietf-out; Tue, 5 Nov 1996 04:48:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA16340 for ; Tue, 5 Nov 1996 04:48:33 -0500 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00389 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 04:48:29 -0500 Received: from nic.cafax.se (paf@nic.cafax.se [193.12.122.42]) by nic.cafax.se (8.8.2/8.8.2) with SMTP id KAA06251; Tue, 5 Nov 1996 10:46:18 +0100 (MET) Date: Tue, 5 Nov 1996 10:46:17 +0100 (MET) From: Patrik Faltstrom X-Sender: paf@nic.cafax.se To: Martin J Duerst Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax draft) In-Reply-To: <"josef.ifi..324:04.10.96.10.50.51"@ifi.unizh.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com On Mon, 4 Nov 1996, Martin J Duerst wrote: > - Specify that protocols may only reserve 1-octet UTF-8 characters > (i.e. ASCII). This is kind of stupid from my point of view. We do not win anything by doing this, do we? > - Specify that protocols have to define their own escaping mechanisms > for things beyond ASCII. This is better, much better. We say that native URNs are 8-bit following the UTF-8 specification and that the protocol have to come up with its own escaping mechanism. Just because the US-ASCII characters are represented by themselves in an UTF-8 string, and these octets can not occur in any other UTF-8 sequence, I can not see that we have problems with the normal "dangerous" characters in for example a URL, i.e. space, percent, plus etc. A space can only occur in a UTF-8 string as a space, representing a space, so it has to be %encoded. It should because of this be quite easy :-) for each protocol to check what happens when a UTF-8 string is passed. My experience is that UTF-8 strings behaves like ISO-8859-1 strings, if you don't start inserting linebreaks, counting characters etc. Patrik Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA15027 for urn-ietf-out; Tue, 5 Nov 1996 01:20:54 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA15022 for ; Tue, 5 Nov 1996 01:20:50 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29641 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 01:20:47 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id AAA21984; Tue, 5 Nov 1996 00:16:00 -0600 (CST) Date: Tue, 5 Nov 1996 00:16:00 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611050616.AAA21984@ncsa.uiuc.edu> To: Patrik Faltstrom Cc: urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: References: <199611030651.AAA25490@ncsa.uiuc.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Patrik Faltstrom writes: > A URL refers to a location which though a caching mechanism, a proxy > cache, an interceptor with cache, multiple A-records in DNS or whatever > ends up refering to more than one occurance of the same resource. But those multiple occurances of the resource are at multiple locations, are they not? (BTW, the point of this particular line of argument is simply that the binding between URL and location is not as clear as people are making it sound. This, by itself, does not imply that URLs are persistent, as URNs are intended to be.) > A URN is a _name_ of a resource which have absolutely _NOTHING_ > to do with the resolution protocol, the different versions of > the resource that exist (text, postscript etc), the different > protocols used to locate and later fetch the resource or the > metadata for the resource. I'm not sure who else would agree with you that a name is so abstract that it has nothing to do with any of the information associated with the resource. If there is no association, how is that the name can even be used as a name of the resource? How would you ever get to the resource? Instead, perhaps you are trying to say that the name is not tightly bound to information associated with the resource, that the information can change and still the name is the name of the resource. For example, the "resolution protocol" can change. I have no problem with that, and never have. But this is still not abstractly different from what happens to a URL. What is happening when an HTTP server gives you a redirect to an ftp URL? Compare that to a DNS server for a naming authority giving you a redirect to an http URL. If you want to get from a URN to a resource, you must begin to look up some information starting with the URN. If you don't look up anything associated with the URN, you can't continue with the resolution, so there is something essential going on there, you must admit. The particular way you go about looking up the information is a process that involves protocols itself. (BTW, the point of this particular line of argument is simply that if URLs have a protocol associated with them, then so do URNs. But in fact, different protocols can be used to resolve either URNs or URLs.) > On Sun, 3 Nov 1996, Daniel LaLiberte wrote: > > But the very same URL was used to retrieve the resource either from a > > cache or from a remote server. So what "location" is the URL > > identifying when the resource actually lives in multiple places - the > > very same URL may be used to fetch the resource from any of those > > places? Notice you first say that a URL identifies (or names) the > > location of a resource, and then we find out that there are really > > multiple locations identified by the URL. But that is supposed to be > > the job of URNs. So why do we need URNs? (BTW, my "So why do we need URNs?" is somewhat rhetorical. I believe we do need more persistent resolution services, in case that is not clear. The point of the above line of argument is, again, that the binding between URLs and locations is not so clear. There is more to this argument that hasn't come out yet.) ... > Dan, you _have_ to start to differ between multiple locations > of a resource which is addressed by a URL - i.e. it's original > location, Is your view that a URL *is* the "original" location of the resource and also the URL "addresses" multiple locations of the resource? This is different from the definition that a URL identifies (or names) the location of the resource. > and the functionality that is built into the system > when a _name_ is assigned to a resource. As long as you have not > seen this difference that many of us others have seen, it is > a little bit hard to have a meaningful discussion. I see a difference, but it is not the difference you think it is. There is a difference in the functionality that can be provided by a new service, but it is not a difference because we call something a "name" vs a "location". The proof is that the things you call "locations" (i.e. URLs) can use this new service too. > Sorry for being harsh and short, but I am now a little bit tired > of having to try to come up with exactly the same arguments we > have been having since the UR* discussions started. We have > to move forward! I don't think these are exactly the same arguments - at least I havent seen my arguments before. But I didn't perceive harshness in your words, or it didn't bother me anyway. I am being patiently persistent - I only hope that my readers are being persistent enough to understand my arguments. > > A client can resolve > > "http://www.ncsa.uiuc.edu/" using HTTP or using the NAPTR protocol, or > > something else. This is the very same identifier, not two identifiers > > with the same character representation. Calling it two identifiers > > and saying one is a name and the other is [the name of] a location is > > missing the whole point. > > No, _you_ are missing the point. By saying that > "urn:http://www.ncsa.uiuc.edu/" is a _name_, one know that this > namespace called HTTP can grandfather other namespaces, this > _name_ can stay as it is even if the resource moves, the metadata > for this resource can be fetched etc etc all according to the URN > spec that was written down years ago. I'm not missing that point - I agree with it. I helped create all this, by the way, so I know what is going on here. But I am not talking about "urn:http://www.ncsa.uiuc.edu/", I am talking about "http://www.ncsa.uiuc.edu". If the "urn:" prefix is optional on URNs, then those two identifiers are equivalent. Answer this: do you agree with the previous statement? > If you have a URL, like "http://www.ncsa.uiuc.edu/", what do you do > if you have to move this resource from the host www.ncsa.uiuc.edu? > Change things in the DNS? But of course that works. But, if you move > the information from staying only on an http server to also stay in > a Z39.50 database and want the clients to be able to use both, or > [...] If "http://www.ncsa.uiuc.edu/" is in the "http" branch of the urn.net tree, then you could do any of these things. If some other name resolution mechanism is created in the future, then "http://www.ncsa.uiuc.edu/" could be registered there too. > There are thousands of things you _can_not_do_ with the name of a > location of something, that you only can do with a _name_ of a > resource which is resolved to one or many alternative locations. If *you* define an identifier as a location and therefore limit what you do with it based on that definition, then that's your choice. But anyone else is still free to use it as a name, if they can find a resolution service that treats it as a name, in the sense of providing persistent resolution, or any of the other thousands of things one might associate with names. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA13211 for urn-ietf-out; Mon, 4 Nov 1996 20:53:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA13206 for ; Mon, 4 Nov 1996 20:53:31 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28443 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 20:52:59 -0500 Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <14402(6)>; Mon, 4 Nov 1996 17:52:47 PST Received: by palimpsest.parc.xerox.com id <130>; Mon, 4 Nov 1996 17:52:43 PDT To: urn-ietf@bunyip.com In-Reply-To: <199611042006.PAA08313@lysithea.lcs.mit.edu> (sollins@lcs.mit.edu) Subject: [URN] URN-WG home page w/references From: Larry Masinter Message-Id: <96Nov4.175243pdt."130"@palimpsest.parc.xerox.com> Date: Mon, 4 Nov 1996 16:52:43 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com Is there a 'home page' for the URN working group? It would be really useful to collect together the references & previous work. There was a home page for URI that was (and still is) really useful, but lately I've had to search for URN & URC references. Regards, Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA08830 for urn-ietf-out; Mon, 4 Nov 1996 15:06:47 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA08825 for ; Mon, 4 Nov 1996 15:06:40 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25851 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 15:06:38 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id PAA08313; Mon, 4 Nov 1996 15:06:37 -0500 Date: Mon, 4 Nov 1996 15:06:37 -0500 Message-Id: <199611042006.PAA08313@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: urn-ietf@bunyip.com Subject: Re: [URN] some comments Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com Let me try once more... There are three core functions that are generally provided by "names": identification, location, and mnemonics or semantics. Let me describe each separate. In this context, all have meaning only with respect to resources. Identification allows the assigner of the name to declare the distinctiveness of a resource from other resources, from the perspective of the assigner of the name. This allows someone else to recognize this distinction or lack thereof as intended by the name assigner. Generally, all naming schemes provide this in some form or other. Location allows the assigner to declare something about how to locate or find the resource. In an abstract sense it can be seen as "location", but the meaning of location is left to the interpretation of the supporting infrastructure. A different way of saying this is that it is the input to the supporting protocol elements. Again, generally, at least in computer systems, all naming schemes provide this in some form or other. Mnemonics or semantics allows the assigner to include something "meaningful" to potential clients, such as ways to remember the name, or perhaps something about the nature of the resource (an extension defining the language in which the resource is encoded, an algorithm that was used in it, it's functionality, or perhaps its relationship to other resources, e.g. versioning). Not all naming schemes provide this. Human friendly schemes tend to do much more than machine friendly ones. Now, let's step back and look at our environment. We are talking about a situation in which there are "layers of abstraction". At "our" layer, the entities to be named are resources. Resources will be supported by an infrastructural suite, including (although I may have missed some) storage services (file systems, oodbms, object repositories, etc.), computation engines, access methods, access constraint methods, communications protocols, and perhaps others. So, for example, at the present the infrastructure may be provided by publicly accessible unix file systems, NT file systems, etc, as well as a collection of transport protocols such as HTTP, NNTP, FTP, Z39.50, etc. These are not part of our layer of abstraction, but rather are what we use to realize them. These things in turn are themselves supported by lower level abstractions. The same issues of naming listed above apply to each of the layers. After much more than 2 yrs we have chosen by consensus a particular model with respect to naming within our layer. That model for the most part separates the three functions and realizes them separately. In the URI architecture (not Tim B-L's idea of URIs, but that of the URI WG consensus), these functions are separately provided by three components of the architecture. Identification is provided by URNs, location by URLs, and semantics by URCs. That is what was agreed to by consensus of the working group. That is what is laid out in the introductions to both the URN and URL requirements documents that were also agreed to by the WG. Such a layering architecture also recognizes that there are different layers of abstraction and that at least abstractly one goes through the exercise repeatedly (and not just at the layers at which we are working) of taking an identifier and using it to either learn something about distinctions or lack thereof in the intention of the name assigner or perhaps semantics, and/or alternatively "resolving" or "binding" it, by translating it into something for which the only intention is that it be handed to some piece of the infrastructure to "do its thing" on. For this resolution or binding process one might use similar mechanisms at different layers of abstraction, such as table lookup or recourse to servers using the same query protocol in order to request resolution. But that in no way means that the same abstractions are being identified, learned about or resolved. Given our choice of separation, we, in this working group, have set about to design a first mechanism to provide the binding of name to location. Let me recommend to you an extremely well-written short paper on the subject, "On the Naming and Binding of Network Destinations" by Jerry Saltzer. This was originally published in 1983 (yes, that was long before the URI WG was formed :-), so its examples are from that era. The concepts are completely applicable to this discussion. This is not a new problem, nor is the model of distinguishing between name and address a new solution. It was issued as RFC 1498 (informational) in 1993. Two additional relevant references (from Saltzer's paper) that I also recommend to you are: Shoch, John F., "Inter-Network Naming, Addressing, and Routing," IEEE Proc. COMPCON Fall 1978, pp. 72-79. Also in Thurber, K. (ed.), Tutorial: Distributed Processor Communication Architecture, IEEE Publ. #EHO 152-9, 1979, pp. 280-287. Sunshine, Carl A., "Addressing Problems in Multi-Network Systems", to appear in Proc. IEEE INFOCOM 82, Las Vegas, Nevada, March 30 - April 1, 1982. Karen Sollins Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA05581 for urn-ietf-out; Mon, 4 Nov 1996 12:57:40 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA05576 for ; Mon, 4 Nov 1996 12:57:36 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24362 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 12:57:33 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id LAA10291; Mon, 4 Nov 1996 11:53:09 -0600 (CST) Date: Mon, 4 Nov 1996 11:53:09 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611041753.LAA10291@ncsa.uiuc.edu> To: Leslie Daigle Cc: urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: References: <199610311951.NAA10608@ncsa.uiuc.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Leslie Daigle writes: > A URL (location) is a point in 4-space, as defined by: > > . machine (aliased through DNS mechanisms) > . port number (default per protocol) > . protocol to speak on that port and at that machine > . string to use within that protocol > > A basic URN (name) has nothing to do with these 4 dimensions -- it is > independent of any machine identifier, port, or protocol. The string > associated with it is a _label_ that is unique across the specified > namespace. The URN being proposed to be resolved with the NAPTR mechanism has everything to do with these 4 dimensions. Specifically: . machine: urn.net (or whatever is decided) . port: DNS protocol port . protocol: DNS on top of UDP or TCP . string: nsi:opaque-string Furthermore, it is an iterative protocol, making several requests to DNS. But similarly, HTTP is iterative. You might respond that this is just one URN resolution mechanism and others are possible. Absolutely true. But the same is true of URLs. A URL is *not* necessarily resolved through the mechanism suggested by its components. An http URL can be resolved by the NAPTR mechansm, for example. Or it may be resolved through a cache. > [Dan LaLiberte wrote:] > > Consider caches. The resolution of a URL via a cache proxy may find > > the resource in the cache rather than in some remote server. What is > > "the location" of the resource in that case? > > Caches are external to either URN or URL systems. They may choose > to use the URL string as a label that identifies a particular > resource, and use that label to lookup contents of the cache. Stop right there for a moment. Note that the location of the resource found in the cache is *not* the location you described above that is suggested by the components of the URL. You say that caches are external to URIs, but the URL is in fact used to look up the resource. That is not external - that is part of the process of resolving the URL. > But, caches break when the label does not change, but the contents > of the location does. You mean "location of the contents", I presume. I understand what you are saying, and I believed the same once - I couldnt figure out why Tim Berner-Lee argued that URLs could work just fine for caching. I thought he was missing something. But the problem, as I understand it now, is not in the identifiers, it is in the resolution process. Identifiers, whether URLs or URNs, are *always* interpreted by some resolution process. And it is the resolution process that provides the persistence of reference, not the identifiers themselves. Take out the NAPTR resolution service (and provide no substitute resolution service) and URNs will be useless (except for unique identification which needs no resolution service). Yes, HTTP fails to provide persistent resolution because servers move and there is no way to redirect a whole service. Note that within a still existing server, a redirect can be used to provide persistent resolution. The PURL idea is to just make sure the purl server continues to exist, and people may or may not believe it will. Abstractly, there is no difference between depending on the continued existence of a purl server and depending on the continued existence of the DNS root service, and NAPTR resolution will depend on that, and on 'net' and 'urn.net'. The practical difference is that DNS probably will continue to exist even if all the purl servers vanish. > If you cache based on URN, your cache will > not break, because the content associated with the identifier > does not change. You seem to be jumping here to content-based identifiers. That is not in the requirements, as I understand it. The content of a resource may in fact change and still be identified by the same URI. Perhaps, you are talking about the uniqueness property of URNs such that a URN will always map to the *same* resource, as long as the resource exists, even though it may be a dynamically changing resource. But note that, like persistence, uniqueness is also (partly) a property of the resolution services, not the URN itself. The naming authority must make sure that a URN is only used once, but the resolution service must also behave such that it always associates a particular URN with the same resource, otherwise the URN is effectively *not* unique. But URLs could have that same uniqueness property. There is no guarantee that all http URLs will be unique, and we will never be able to get that guarantee, but a cache could find out from a server whether a URL is unique for the resource that was returned. > > We don't need to create a new kind of identifier to make a URL into a > > persistent location. We *do* need new persistent services, such as > > the NAPTR records in DNS. > > I'm not sure I understand the point you are making here. Access to NAPTR records in DNS is (will be) provided by a service, a DNS service. This NAPTR service might be limited to just parts of the DNS tree, under urn.net. I am suggesting that http URLs could be resolved through that limited service, by setting up an http branch under urn.net. Therefore, http URLs resolved this way could have exactly the same persistence as any other URN. It is the resolution service that provides the persistence, not the identifier itself. > It sounds like > you are saying -- forget everything else about all this stuff, let's > do NAPTR as a service, and then people can build in persistence using > whichever mechansisms strike their fancy? That is an interesting idea, if I understand what you are thinking, but it is not what I was suggesting. > I have a problem with that approach, for (at least) two reasons: > > . implementing a persistent location means adding much overhead > in systems that were not built for it. Yes, there is overhead in providing persistent resolution services. But not as much as you suggest, depending on how it is done. > . there are then no mechanisms to distinguish between things that > are meant to be persistent, and things that are expected not > to be. Time-to-live data would indicate how persistent things are. Why should we assume that URLs are not persistent? Why should we assume that URNs last forever? It is resolution services and the organizations that provide them that make URLs or URNs persist, or not. (BTW, throughout this discussion, I've slighted the guarantees of uniqueness of identifiers (i.e. not used for another resource), but that is a trivially easy problem to solve, so I am not particularly worried about it. In addition to providing persistent resolution services, we would need to know that particular URIs are unique, if that is important for some particular application. This information can be provided by servers along with the resource or separately. We don't *need* to create a new kind of identifier to know that particular identifiers are unique, although it is convenient to know that all identifiers with the same prefix are intended to be unique.) > > To summarize, both URLs and URNs have the following abstract > > resolution process in common: ... > It is definitely interesting to look at the surface similarities in > mechanics between URL resolution and the NAPTR approach to URN > handling. This abstraction is not a surface similarity - this is a fundamentally deep similarity. Both URLs and URNs have the same abstract mechanism - it is the details of exactly which processes are used that is at the surface. > What still is not clear to me is what you are suggesting > to _do_ with this. If you are suggesting that there is nothing > more to do with URN work than to define different steps in 2 and 3, > I have a problem with that... The "nothing more" involves setting up a persistent resolution service which is not exactly trivial, especially when it hopes to be applicable to all names, past and future. But yes, this resolution service fits right into this general URI resolution mechanism. The problem you might have with it is that it makes URLs and URNs look too much alike, which collapses the view that they must be different. Let me return to my claim that: It is the resolution service that provides the persistence, not the identifier itself. Something similar applies to any properties of identifiers. The only properties that are inherent in an identifier itself are properties of its actual representation. Any other properties *associated* with the identifier are derived from how it actually behaves, or is promised to behave when used in a particular context. But note that the same identifier can be used in different contexts, so it can "have" different properties in each. This is just a mathematical truth. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA05350 for urn-ietf-out; Mon, 4 Nov 1996 12:33:16 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA05345 for ; Mon, 4 Nov 1996 12:33:14 -0500 Received: from CS.BU.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23964 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 12:33:09 -0500 Received: by cs.bu.edu (8.6.10/Spike-2.1) id MAA01846; Mon, 4 Nov 1996 12:32:53 -0500 Date: Mon, 4 Nov 1996 12:32:53 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: urn-ietf@bunyip.com From: "David G. Durand" (David G. Durand) Subject: Re: Names and Locations (was [URN] some comments) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "David G. Durand" (David G. Durand) Errors-To: owner-urn-ietf@bunyip.com.Another.way.to.see.the.difference.between.URNs.and.URLs.is.to.look.at binding time: a URL has a resolution mechanism defined at the time that it is created. A URN is explicitly defined to have multiple potential resolution mechanisms, as long as they work (i.e. lead to right resource). You can use any kind of indentifier as a URL (even one that was originally assigned as a URL), but such use implies a contract by the name assigner, establishes the bounds of variation on the resource (usually, that the resource be immutable). URNs are supposed _not_ to have a privileged resolution mechanism, thus allowing the identifiers to outlive URN resolutin mechanisms. Now, it is true that we will need to have at least one mechanism for URL resolution, but the strategy for defining identifiers and that for resolving them should _not_ be tightly coupled because we _know_ that the mechnisms will change, but the URNs cannot change. It is the point of URNs that the _client_ can decide how to resolve them, while URLs require that the _URL creator_ prescribe how they should be resolved. That's also why a URN prefix makes URNs more useful, since it is a tip-off to a client that it may have a choice as to resolution strategy. It also signals that the assigner of the name claims to meet the contract for URN persistence. Mixing URN authorities with HTTP protocols is technically workable, but it makes the deployment of new naming authorities interact closely with the completely unrelated issue of protocols for HTTP resolution. It is much simpler to ensure that there is a requirement for syntactic differentiation of URNs _in contexts where both URLs and URNs can occur_. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA05110 for urn-ietf-out; Mon, 4 Nov 1996 12:05:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA05104 for ; Mon, 4 Nov 1996 12:05:54 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23564 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 12:05:52 -0500 Message-Id: <9611041705.AA23564@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Mon Nov 4 11:04 CST 1996 From: "Ryan Moats" To: "Martin J Duerst" Cc: "urn-ietf@bunyip.com" Date: Mon, 04 Nov 96 11:06:14 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Mon, 4 Nov 1996 17:37:06 +0100 (MET), Martin J Duerst wrote: >Ryan Moats wrote: > >>>- Specify that protocols may only reserve 1-octet UTF-8 characters >>> (i.e. ASCII). >>>- Specify that protocols have to define their own escaping mechanisms >>> for things beyond ASCII. >> >>Having had the weekend to mull this over some more (and seeing that my >>mulling was in the right direction...), here are my thoughts: >> >>I would add a third solution to the above-- That the syntax draft defines its >>own escaping mechanism for things beyond ASCII. This ensures that URN >>resolvers don't have to be re-written just because some new namespace comes >>along that wants to reserve some character in some totally different scheme >>then all the others currently used. >> >>Having said that, I currently lean strongly towards the first solution >>that Martin has >>proposed, as it keeps the syntax document short, doesn't add a new >>escaping mechanism (and all the complexity that adds). To sum up, it just >>strikes me as being CLEANER than any other solution. Does anybody >>have problems with it being written into the syntax draft? > >It looks cleaner to me, too, maybe even a subset of ASCII, as Jon >Knight has suggested, because as I have explained, even now %7E >is used in some parts of the world to escape a "~" that is not >a reserved character. I can live with a subset of ASCII, say from %20 to %7D. >Also, I think we will never be able to fully exclude the second >solution, and we may even say in the draft that it is allowed, >but of course there will be no support from any generic handling >software. I'd word it differently, but I can add such text as well. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA04734 for urn-ietf-out; Mon, 4 Nov 1996 11:37:58 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA04729 for ; Mon, 4 Nov 1996 11:37:51 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23341 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 11:37:24 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01465-0@josef.ifi.unizh.ch>; Mon, 4 Nov 1996 17:37:07 +0100 Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax To: jayhawk@ds.internic.net Date: Mon, 4 Nov 1996 17:37:06 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: <"josef.ifi..017:04.10.96.15.15.19"@ifi.unizh.ch> from "Ryan Moats" at Nov 4, 96 09:14:28 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1839 From: Martin J Duerst Message-Id: <"josef.ifi..168:04.10.96.16.37.08"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ryan Moats wrote: >On Mon, 4 Nov 1996 11:50:36 +0100 (MET), Martin J Duerst wrote: >It wasn't your explanation, it was getting my brain to stop thinking in ASCII >mode and start thinking in more general character mode. I'll probably still >slip back and forth, since it isn't natural yet... I see. I'm probably too much into i18n mode to realize such things anymore. >>- Specify that protocols may only reserve 1-octet UTF-8 characters >> (i.e. ASCII). >>- Specify that protocols have to define their own escaping mechanisms >> for things beyond ASCII. > >Having had the weekend to mull this over some more (and seeing that my >mulling was in the right direction...), here are my thoughts: > >I would add a third solution to the above-- That the syntax draft defines its >own escaping mechanism for things beyond ASCII. This ensures that URN >resolvers don't have to be re-written just because some new namespace comes >along that wants to reserve some character in some totally different scheme >then all the others currently used. > >Having said that, I currently lean strongly towards the first solution >that Martin has >proposed, as it keeps the syntax document short, doesn't add a new >escaping mechanism (and all the complexity that adds). To sum up, it just >strikes me as being CLEANER than any other solution. Does anybody >have problems with it being written into the syntax draft? It looks cleaner to me, too, maybe even a subset of ASCII, as Jon Knight has suggested, because as I have explained, even now %7E is used in some parts of the world to escape a "~" that is not a reserved character. Also, I think we will never be able to fully exclude the second solution, and we may even say in the draft that it is allowed, but of course there will be no support from any generic handling software. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA29455 for urn-ietf-out; Mon, 4 Nov 1996 10:22:56 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA29444 for ; Mon, 4 Nov 1996 10:22:53 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22581 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 10:22:51 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01422-0@josef.ifi.unizh.ch>; Mon, 4 Nov 1996 16:22:20 +0100 Subject: Re: [URN] New syntax draft To: jon@net.lut.ac.uk (Jon Knight) Date: Mon, 4 Nov 1996 16:22:19 +0100 (MET) Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com In-Reply-To: from "Jon Knight" at Nov 4, 96 03:15:56 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1597 From: Martin J Duerst Message-Id: <"josef.ifi..204:04.10.96.15.22.21"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Jon Knight wrote: >On Mon, 4 Nov 1996, Martin J Duerst wrote: >> Yes. But now immagine that some of these French/German/Nordic/Icelandic >> letters, or whatever else, is reserved, but that somebody was not able >> to represent them directly, and used %-escaping. What are you going to do? > >But nobody is suggesting making the Nordic runes reserved characters are >they? I was thinking that reserved characters would be a very well >defined, small subset of the ASCII range, just as with URLs. Nobody is explicitly suggesting to make the Nordic runes reserved characters at the moment. They would first have to be included in Unicode/ISo 10646, for which work is still progressing. But the current draft does not say reserved characters are restricted to ASCII, or even a subset of it. >> >And anyway, URLs don't use UTF-8 so this isn't going to be a problem >> >(we're talking URNs here right?). >> >> I just explained the problems using URL examples. Just because >> they problems might not apply to URLs, that still does not help >> for URNs. > >Which means that URLs are maybe doing something right and we should take >notice whilst doing URNs...? Such as only having a relatively small >number of reserved characters. It may well be that this is the right way to go. On the other hand, what does "grandfathering" exactly mean? If there is a namespace that already has e.g. some Nordic rune as reserved character, and we limit ourselves to a subset of ASCII, then although the namespace as such can be grandfathered, the reserved characters will have to be changed. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA29379 for urn-ietf-out; Mon, 4 Nov 1996 10:17:12 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA29374 for ; Mon, 4 Nov 1996 10:17:10 -0500 Received: from weeble.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22488 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 10:16:35 -0500 Received: from jon by weeble.lut.ac.uk with smtp (Exim 0.55 #1) id E0vKQkm-00043B-00; Mon, 4 Nov 1996 15:15:56 +0000 Date: Mon, 4 Nov 1996 15:15:56 +0000 (GMT) From: Jon Knight X-Sender: jon@weeble.lut.ac.uk To: Martin J Duerst Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com Subject: Re: [URN] New syntax draft In-Reply-To: <"josef.ifi..248:04.10.96.10.46.47"@ifi.unizh.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Jon Knight Errors-To: owner-urn-ietf@bunyip.com On Mon, 4 Nov 1996, Martin J Duerst wrote: > Yes. But now immagine that some of these French/German/Nordic/Icelandic > letters, or whatever else, is reserved, but that somebody was not able > to represent them directly, and used %-escaping. What are you going to do? But nobody is suggesting making the Nordic runes reserved characters are they? I was thinking that reserved characters would be a very well defined, small subset of the ASCII range, just as with URLs. > >And anyway, URLs don't use UTF-8 so this isn't going to be a problem > >(we're talking URNs here right?). > > I just explained the problems using URL examples. Just because > they problems might not apply to URLs, that still does not help > for URNs. Which means that URLs are maybe doing something right and we should take notice whilst doing URNs...? Such as only having a relatively small number of reserved characters. Tatty bye, Jim'll -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA29344 for urn-ietf-out; Mon, 4 Nov 1996 10:14:52 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA29337 for ; Mon, 4 Nov 1996 10:14:40 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22469 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 10:14:38 -0500 Message-Id: <9611041514.AA22469@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Mon Nov 4 09:13 CST 1996 From: "Ryan Moats" To: "Martin J Duerst" Cc: "urn-ietf@bunyip.com" Date: Mon, 04 Nov 96 09:14:28 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax draft) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Mon, 4 Nov 1996 11:50:36 +0100 (MET), Martin J Duerst wrote: >Ryan Moats wrote: > >> >>My brain hurts, but I think I finally understand the issue. > >Sorry for my long explanations. It wasn't your explanation, it was getting my brain to stop thinking in ASCII mode and start thinking in more general character mode. I'll probably still slip back and forth, since it isn't natural yet... >>Allow me to restate it to see if I'm right: >> >>The problem you are talking about arrises if the reserved character has >>a UTF-8 representation of more than 1 octet. Then, if we use %encoding >>to represent the character in a literal use, there is no way of determining >>from the URN whether the character is being used as a literal character >>or not. > >Exactly. > > >- Specify that protocols may only reserve 1-octet UTF-8 characters > (i.e. ASCII). >- Specify that protocols have to define their own escaping mechanisms > for things beyond ASCII. Having had the weekend to mull this over some more (and seeing that my mulling was in the right direction...), here are my thoughts: I would add a third solution to the above-- That the syntax draft defines its own escaping mechanism for things beyond ASCII. This ensures that URN resolvers don't have to be re-written just because some new namespace comes along that wants to reserve some character in some totally different scheme then all the others currently used. Having said that, I currently lean strongly towards the first solution that Martin has proposed, as it keeps the syntax document short, doesn't add a new escaping mechanism (and all the complexity that adds). To sum up, it just strikes me as being CLEANER than any other solution. Does anybody have problems with it being written into the syntax draft? Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA28449 for urn-ietf-out; Mon, 4 Nov 1996 08:47:34 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA28444 for ; Mon, 4 Nov 1996 08:47:32 -0500 From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21674 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 08:47:30 -0500 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <03479-0@domen.uninett.no>; Mon, 4 Nov 1996 14:44:28 +0100 X-Mailer: exmh version 1.6.7 5/3/96 To: Larry Masinter Cc: rdaniel@acl.lanl.gov, liberte@ncsa.uiuc.edu, urn-ietf@bunyip.com Subject: Re: [URN] HTTP resolution protocol In-Reply-To: Your message of "Mon, 04 Nov 1996 00:19:43 PST." <96Nov4.001943pst."2696"@golden.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 14:44:25 +0100 Message-Id: <3476.847115065@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com (Warning: I'm coming into this without reading the entire debate...) I like the idea that HTTP GET is an URI to MIME object resolution protocol. It either fails or returns a MIME object. But the scheme of service:/uri would IMHO require registering N2L, N2Ls, N2C and so on as URI types; this sounds wrong to me. If we want a resolution CONVENTION, it seems to me that the right convention is "GET /resolve/N2L/" (mimicking a CGI-BIN script). If we want a resolution STANDARD, it seems to me that the right thing is "N2L HTTP/1.1" For handing back lists of things, mimic the responses that were put into HTTP/1.1 for content negotiation (putting up a header for thte machine processible version and HTML for the human-readable version). Just my NOK 0.50.... Harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA27406 for urn-ietf-out; Mon, 4 Nov 1996 05:51:04 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA27401 for ; Mon, 4 Nov 1996 05:51:02 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21183 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 05:51:00 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00908-0@josef.ifi.unizh.ch>; Mon, 4 Nov 1996 11:50:37 +0100 Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax draft) To: jayhawk@ds.internic.net Date: Mon, 4 Nov 1996 11:50:36 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: <9611011512.AA05839@mocha.bunyip.com> from "Ryan Moats" at Nov 1, 96 09:12:22 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1322 From: Martin J Duerst Message-Id: <"josef.ifi..324:04.10.96.10.50.51"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ryan Moats wrote: >>Now for UTF-8, things are quite different. 8-bit bytes will >>on many occasions be escaped because it may be difficult to >>represent them otherwise. Having some character beyond ASCII >>represented with %HH (usually %HH%HH or %HH%HH%HH) can in no >>way imply that this is a special character. >>This means that any tools dealing with URNs in general will >>have no clue about where to keep the escaping, and where >>to remove it. A very exact knowledge of each NSS syntax >>would be needed. > >My brain hurts, but I think I finally understand the issue. Sorry for my long explanations. >Allow me to restate it to see if I'm right: > >The problem you are talking about arrises if the reserved character has >a UTF-8 representation of more than 1 octet. Then, if we use %encoding >to represent the character in a literal use, there is no way of determining >from the URN whether the character is being used as a literal character >or not. Exactly. >I'll save a discussion of potential solution directions to this until I'm sure >I understand the issue. I have already mentionned two possibilities: - Specify that protocols may only reserve 1-octet UTF-8 characters (i.e. ASCII). - Specify that protocols have to define their own escaping mechanisms for things beyond ASCII. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA27337 for urn-ietf-out; Mon, 4 Nov 1996 05:47:58 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA27325 for ; Mon, 4 Nov 1996 05:47:25 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21177 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 05:47:22 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00897-0@josef.ifi.unizh.ch>; Mon, 4 Nov 1996 11:46:39 +0100 Subject: Re: [URN] New syntax draft To: jon@net.lut.ac.uk Date: Mon, 4 Nov 1996 11:46:38 +0100 (MET) Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com In-Reply-To: from "Jon Knight" at Nov 1, 96 01:44:31 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3326 From: Martin J Duerst Message-Id: <"josef.ifi..248:04.10.96.10.46.47"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Jon Knight wrote: >On Fri, 1 Nov 1996, Martin J Duerst wrote: >> When going from ASCII to UTF-8, there are some new problems. >> For ASCII, the general assumption is that only those charcters >> that need escaping are actually escaped, and therefore that >> escaping, e.g. for "/" or whatever, shouldn't be undone. >> The above is not exactly true, indeed the "~" is often escaped >> as %7E in Europe because it is difficult to type on European >> keyboards, but still I assume there are a lot of tools around >> working on URLs in general that work along the rule "if ASCII >> is escaped, don't remove the escaping, because this is a special >> character. > >Hmm, I don't really understand this; URL percent escaping is just away of >dealing with characters that you can't represent directly, either because >they're in the reserved set of characters or because they're not easy to >type (the French/German/Nordic/Icelandic letters in ISO-8859-1 for >example). If you're unescaping things, one would assume that you've >already parsed any reserved characters to extract any structuring >information that the provide. Yes. But now immagine that some of these French/German/Nordic/Icelandic letters, or whatever else, is reserved, but that somebody was not able to represent them directly, and used %-escaping. What are you going to do? Also, according to the syntax draft, intermediate software migth %-escape some UTF-8 part to pass the thing through a 7-bit channel. It will %-escape reserved and unreserved characters all alike. >Percent escaped characters aren't just >restricted to the reserved characters that need to be escaped; you can >percent escape your entire URL's path if you like. Any software that just >expects reserved characters to be percent escaped is going out of its way >to be braindead IMHO. The problem is with software that expects reserved charcters NOT to be escaped. >And anyway, URLs don't use UTF-8 so this isn't going to be a problem >(we're talking URNs here right?). I just explained the problems using URL examples. Just because they problems might not apply to URLs, that still does not help for URNs. And URLs don't use UTF-8 YET. They don't even use ASCII, in the sense we are proposing to use UTF-8 here. They just encode octets. For the benefit of us all, fortunately, there are some coincidences in most of the URL schemes, so that it actually looks as if URLs would use ASCII. If you currently see an URL with octets in the 8-bit range, there is not much of a chance to guess what characters it could represent. But steadily, the number of cases where there are chances that you get the characters if you interpret the octests as UTF-8 will be increasing. One example is ftp: The ftp-wg agreed on going into the direction of using UTF-8 as the common character encoding. According to the URL spec, that's up to ftp to decide. Because it is a very reasonable decision, it will hopefully be followed by others. The remaining formal difference between URL syntax and URN syntaxt would then be that the later officially allows the URN to be represented with characters/glyphs outside the ASCII range (on things such as cardboard boxes), but the former officially disallows such a behaviour. In practice, I guess this difference will vanish rather quickly. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id DAA26111 for urn-ietf-out; Mon, 4 Nov 1996 03:20:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id DAA26106 for ; Mon, 4 Nov 1996 03:20:35 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20672 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 03:20:03 -0500 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <15465(3)>; Mon, 4 Nov 1996 00:20:01 PST Received: by golden.parc.xerox.com id <2696>; Mon, 4 Nov 1996 00:19:43 PST To: Harald.T.Alvestrand@uninett.no Cc: rdaniel@acl.lanl.gov, liberte@ncsa.uiuc.edu, urn-ietf@bunyip.com In-Reply-To: <8499.847019598@dale.uninett.no> (Harald.T.Alvestrand@uninett.no) Subject: Re: [URN] HTTP resolution protocol From: Larry Masinter Message-Id: <96Nov4.001943pst."2696"@golden.parc.xerox.com> Date: Mon, 4 Nov 1996 00:19:43 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com # GET service:/uri HTTP/1.1 is certainly valid. Well, Request-Line = Method SP Request-URI SP HTTP-Version CRLF Request-URI = "*" | absoluteURI | abs_path and 'service:/uri' doesn't look like an 'abs_path', so it must be an 'absoluteURI'. While the HTTP spec doesn't explicitly limit Request-URIs to be URLs, I think it was the intent that they be resource identifiers of some sort. So now you're left with the idea that 'service' is really a kind of URL/URN scheme. You could do it, sure, and probably not break any existing HTTP servers either, but it's really odd to think of 'N2L' as a URI scheme, since it doesn't really locate a resource. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id CAA25882 for urn-ietf-out; Mon, 4 Nov 1996 02:58:11 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id CAA25877 for ; Mon, 4 Nov 1996 02:58:09 -0500 Received: from aun.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20595 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 02:58:06 -0500 Received: from dale.uninett.no by aun.uninett.no with SMTP (PP); Mon, 4 Nov 1996 08:57:46 +0100 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id MAA08501; Sun, 3 Nov 1996 12:13:18 +0100 From: Harald.T.Alvestrand@uninett.no To: Ron Daniel Cc: Daniel LaLiberte , Larry Masinter , urn-ietf@bunyip.com Subject: Re: [URN] HTTP resolution protocol In-Reply-To: Your message of "Thu, 31 Oct 1996 13:21:59 MST." <2.2.32.19961031202159.00699568@acl.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <8497.847019598.1@dale.uninett.no> Date: Sun, 03 Nov 1996 12:13:18 +0100 Message-Id: <8499.847019598@dale.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com GET service:/uri HTTP/1.1 is certainly valid. Harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA25384 for urn-ietf-out; Mon, 4 Nov 1996 01:47:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA25379 for ; Mon, 4 Nov 1996 01:47:12 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20288 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 01:47:10 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id BAA27792; Mon, 4 Nov 1996 01:46:45 -0500 (EST) Message-Id: <199611040646.BAA27792@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Gregory J. Woodhouse" Cc: Leslie Daigle , Daniel LaLiberte , "Karen R. Sollins" , urn-ietf@bunyip.com, moore@cs.utk.edu Subject: Re: [URN] some comments In-Reply-To: Your message of "Sun, 03 Nov 1996 18:19:58 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 01:46:45 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > Look at it from the point of view of implementation: Is > http://foo.bar.com/ a URL or a URN? Is there any conceptual reason why > http: cannot be a valid URN scheme? Yes. It's already well-established as a name space which does not have the properties desired for URNs. Now, if you ask a slightly different question: "can the protocols used to resolve URNs also be used to resolve some kinds of URLs?" ...then the answer is yes. This group needs to solve two problems: 1) how to provide long-term stable and resolvable resource identifiers. These are called URNs. 2. how to resolve many kinds of resource identifiers (not just URNs) to find multiple service locations etc. There is a lot of overlap between the solutions of these two problems, but they're not the same thing. We need to be careful that we don't confuse the two. Once the resolution system exists, the main difference between a URL and a URN is not the protocol used to perform resolution, but the discipline by which the name is assigned and used. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA25122 for urn-ietf-out; Mon, 4 Nov 1996 01:02:01 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA25117 for ; Mon, 4 Nov 1996 01:01:58 -0500 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20136 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 01:01:46 -0500 Received: from nic.cafax.se (paf@nic.cafax.se [193.12.122.42]) by nic.cafax.se (8.8.2/8.8.2) with SMTP id HAA03068; Mon, 4 Nov 1996 07:01:26 +0100 (MET) Date: Mon, 4 Nov 1996 07:01:25 +0100 (MET) From: Patrik Faltstrom X-Sender: paf@nic.cafax.se To: "Gregory J. Woodhouse" Cc: Leslie Daigle , Daniel LaLiberte , "Karen R. Sollins" , urn-ietf@bunyip.com Subject: Re: [URN] some comments In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com On Sun, 3 Nov 1996, Gregory J. Woodhouse wrote: > > Look at it from the point of view of implementation: Is > http://foo.bar.com/ a URL or a URN? http://foo.bar.com/ is a URL urn:http://foo.bar.com/ is a URN > Is there any conceptual reason why > http: cannot be a valid URN scheme? If it is possible for this to be a URN, > then under the NAPTR proposal it would be first necessary to do a DNS query > and receive and address for a service which will either resolve it for us > or tell us that it corresponds to the URL http://foo.bar.com/. Armed with > the information that this latter URI is a URL it is then possible to use > HTTP to retrieve the resource. >From an implementation standpoint the big difference is that when you have a URN scheme, the resolution protocol have to be able to change over time (in the NAPTR proposal from DNS to something else), the protocol used to fetch the data have to be able to be different between different locations of the resource (see the NAPTR and SRV records the NAPTR proposal uses) and the namespace have to be able to both grandfather and be grandfathered later on. All of the above without changing the name. One of the methods of doing a N2R, N2L, N2C etc. fetch for a URN after resolution is to use the http URL scheme, but that is definitely _after_ all of the URN abstraction levels have been resolved. Patrik Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA23495 for urn-ietf-out; Sun, 3 Nov 1996 21:20:45 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA23489 for ; Sun, 3 Nov 1996 21:20:38 -0500 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19465 (mail destined for urn-ietf@services.bunyip.com); Sun, 3 Nov 96 21:20:36 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id SAA25761; Sun, 3 Nov 1996 18:19:59 -0800 Date: Sun, 3 Nov 1996 18:19:58 -0800 (PST) From: "Gregory J. Woodhouse" To: Leslie Daigle Cc: Daniel LaLiberte , "Karen R. Sollins" , urn-ietf@bunyip.com Subject: Re: [URN] some comments In-Reply-To: <199611032218.RAA12973@beethoven.bunyip.com> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com On Sun, 3 Nov 1996, Leslie Daigle wrote: > Dan, > > For all the words that have flown about on this mailing list in the past > few days, I don't really think you've made it clear what you want out > of this particular thread. Let me be fairly blunt in my interpretation > here, and you can tell me on which counts I have misunderstood you. > > I think there are 2 separate things in what you have been saying: > > . whether or not URNs are any different than URLs > . whether or not URNs can be implemented using URL mechanisms > > These are 2 very separate issues. Let me say, as co-chair of this working > group, that this WG starts from the premise that there _is_ a difference > between URNs and URLs, and that our chartered purpose is to refine an > architecture and experimental implementation that does not centre on > starting from URL mechanisms. > Look at it from the point of view of implementation: Is http://foo.bar.com/ a URL or a URN? Is there any conceptual reason why http: cannot be a valid URN scheme? If it is possible for this to be a URN, then under the NAPTR proposal it would be first necessary to do a DNS query and receive and address for a service which will either resolve it for us or tell us that it corresponds to the URL http://foo.bar.com/. Armed with the information that this latter URI is a URL it is then possible to use HTTP to retrieve the resource. --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/home.html resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA22518 for urn-ietf-out; Sun, 3 Nov 1996 17:18:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA22512 for ; Sun, 3 Nov 1996 17:18:12 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18485 (mail destined for urn-ietf@services.bunyip.com); Sun, 3 Nov 96 17:18:10 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id RAA12973; Sun, 3 Nov 1996 17:18:09 -0500 Message-Id: <199611032218.RAA12973@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Sun, 3 Nov 1996 17:18:08 -0500 In-Reply-To: Daniel LaLiberte's message as of Nov 3, 1:48 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Daniel LaLiberte , "Karen R. Sollins" Subject: Re: [URN] some comments Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Dan, For all the words that have flown about on this mailing list in the past few days, I don't really think you've made it clear what you want out of this particular thread. Let me be fairly blunt in my interpretation here, and you can tell me on which counts I have misunderstood you. I think there are 2 separate things in what you have been saying: . whether or not URNs are any different than URLs . whether or not URNs can be implemented using URL mechanisms These are 2 very separate issues. Let me say, as co-chair of this working group, that this WG starts from the premise that there _is_ a difference between URNs and URLs, and that our chartered purpose is to refine an architecture and experimental implementation that does not centre on starting from URL mechanisms. That purpose was selected after a process of consideration and consensus gathering (i.e., not unanimity, but a bulk of people suggesting they thought it had merit). To stick to our charter need not demonstrate the dogmatism or close-mindedness that I felt you were suggesting in your last mail to Karen -- it is a reflection of the fact that this is a directed effort. >From that standpoint, it is quite useful to consider other viewpoints and implementation mechanism insofar as the contribute a positive step towards defining, refining, explaining, or implementing the goal -- a sanity check, even. But, if you want to sit back and discuss the relative merits of different ways of how URIs could (have) be(en) implemented, you need to find a different discussional forum. I.e., I'm not saying it isn't valid/interesting discussional material -- I'm saying it's not for this space. > tomorrow. But I want to challenge the notion that we shouldn't rethink the > work of the last several years. For one thing, for the last 2 years, I > (and a few others) have been arguing against the split in names vs locations, > so why should that work be ignored? Dan, I think your frustration is misplaced. It is not that it "_is_" being ignored -- it is not being discussed _here_, because the starting premise for this WG is that it is not applicable. If you accept the basic premise of this working group, _and_ you still feel this is important, then the problem is that you have not adequately communicated to the people on this list _how_ your position is _not_ just completely at odds with everything we're trying to do (and, by the way, I would point out that it was in one of _your_ postings that you referred to "what you guys are doing" or some such terminology). > This is not a matter of just agreeing on a definition - it is a matter > of having definitions that make sense. A relative term -- I think the definitions make perfect sense. > But it is something that the client gets to decide! And the reason is > that "identifier of resource" vs "identifier of location of resource" > doesn't make sense. It is the chosen resolution mechanism that > determines how you get from an identifier to the resource. The > identifier does *not* determine the resolution mechanism, although > there may be conventions and globally agreed on mechanisms available. > The client *can* make the choice of how to resolve an identifier. It > is a fact of life in a free society that clients can do whatever they > want. (They can't always get away with it, though.) Without talking about resolution mechanisms, let me say this: a client _cannot_ decide, for any given string, "I want the thing this identifies", or "I want the thing at this location". Quite simply, if the client has the identifier of a location, it does not know _what_ the (intended) content is. This is _not_ a client decision. Consider this completely abstract example: . Location identifier: "the third thing from the right on the fourth shelf down" . Content identifier: "Moby Dick" If I am a client, holding the string "the third thing...", the only content I can refer to is whatever is there now -- I have no clue about what was there when location identifier was written down (included in an electronic document, beamed to my Newton, _whatever_). If the shelf has been re-arranged since this location was made, I will get whatever is there now. On the other hand, if I have "Moby Dick", I don't _care_ where it is now, where it was before, where it will be in the future or what I might have to do to get hold of it. The premise of this WG is that there is the need to be able to identify _what_ (i.e., content) one is looking for, as a separate task from identifying the location from which one wants content. If I have understood your position correctly, you are saying that there is no need for a new mechanism for retrieving things from shelves by name -- we'll just build new URL schemes wherein it is promised that shelves are never re-ordered (or at least, if they are, transparent pointers are used to continue the process to find the content that used to be located on a particular position), and thus the location description can be used as a unique, naming identifier. Here's my view on what has happened: to follow the above analogy a bit further, URLs are used to retrieve content by instructing something (call it a librarian in this case; in electronic terms, it is a scheme resolution process) to retrieve the content from a particular shelf and position. The URN proposal says "get me Moby Dick", and identifies a process whereby the librarian can figure out which shelf and object to retrieve. Because these (currently) look like much the same process, except for the implied longevity of the identifier, you are saying they are the same. I disagree. I think the URN approach is based on fundamentally different principles -- that it shall continue to be relevant long after shelves and objects are no longer useful mechanisms, and therefore they should _not_ play _any_ role in the naming process. I don't care if current URL and URN resolution mechanisms are isomorphic -- I am interested in defining the baseline implementation for the first generation of content identification strings -- divorced from location identification. I furthermore believe that the client (user or program) must be able to determine by some non-network-based mechanism, whether or not the identifier in hand is that of a location or of content. So, to sum up, the basic premises of this working group: . there is a difference between content identification and location identification . we have one proposed architecture for supporting the creation of effective content identifiers, and the use of these to determine content/location at any given point in time (resolution), and this is what we are working to refine. Dan, please tell me where I have missed your point... Leslie. -- ---------------------------------------------------------------------------- "The light at the end of the tunnel Leslie Daigle is often the blindingly obvious..." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA17886 for urn-ietf-out; Sun, 3 Nov 1996 09:50:09 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA17881 for ; Sun, 3 Nov 1996 09:50:07 -0500 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17382 (mail destined for urn-ietf@services.bunyip.com); Sun, 3 Nov 96 09:50:04 -0500 Received: from nic.cafax.se (paf@nic.cafax.se [193.12.122.42]) by nic.cafax.se (8.8.2/8.8.2) with SMTP id PAA00892; Sun, 3 Nov 1996 15:49:51 +0100 (MET) Date: Sun, 3 Nov 1996 15:49:50 +0100 (MET) From: Patrik Faltstrom X-Sender: paf@nic.cafax.se To: Daniel LaLiberte Cc: Terry Allen , urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: <199611030651.AAA25490@ncsa.uiuc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com On Sun, 3 Nov 1996, Daniel LaLiberte wrote: > and perhaps it is irrelevant semantics. What is relevant is that you > guys make a distinction between URLs and URNs, and it is a > distinction founded on a misunderstanding. I've been trying to dig > through to get to the heart of that misunderstanding. This is not a misunderstanding at all. There _is_ a difference between a URN and a URL which from my point of view _you_ have not understood. A URL refers to a location which though a caching mechanism, a proxy cache, an interceptor with cache, multiple A-records in DNS or whatever ends up refering to more than one occurance of the same resource. A URN is a _name_ of a resource which have absolutely _NOTHING_ to do with the resolution protocol, the different versions of the resource that exist (text, postscript etc), the different protocols used to locate and later fetch the resource or the metadata for the resource. There are a couple of us that during all of the years so far has only been talking about this difference being very very important. If you don't understand this difference...well...what are _we_ supposed to do about that. The difference is needed! > But the very same URL was used to retrieve the resource either from a > cache or from a remote server. So what "location" is the URL > identifying when the resource actually lives in multiple places - the > very same URL may be used to fetch the resource from any of those > places? Notice you first say that a URL identifies (or names) the > location of a resource, and then we find out that there are really > multiple locations identified by the URL. But that is supposed to be > the job of URNs. So why do we need URNs? Please Dan! There is a difference between having two A-records pointing to two different IP-addresses, and when you later connect to that hostname (which is resolved to one of the two addresses) you will end up at one of the two locations. You can use this technique in for example the hostname in a URL of course. You can also use a proxy cache or an interceptor to see that you pick the copy of the resource that is the most convinient for you. BUT, you are still refering to _one_ location where the resource is located. If you happen to have a local copy, well, let's use that one. It's the same thing as if you do an lseek() in the filesystem and want to read some bytes from a file. If the filesystem have cached those diskblocks, and give you the copies of the bits that happened to sit in RAM and not on the physical disk, are you not using an lseek() anyway? Dan, you _have_ to start to differ between multiple locations of a resource which is addressed by a URL - i.e. it's original location, and the functionality that is built into the system when a _name_ is assigned to a resource. As long as you have not seen this difference that many of us others have seen, it is a little bit hard to have a meaningful discussion. Sorry for being harsh and short, but I am now a little bit tired of having to try to come up with exactly the same arguments we have been having since the UR* discussions started. We have to move forward! > I used "http://www.ncsa.uiuc.edu/" for both, no "urn:" or "url:" for > either. (BTW, If "urn:" is optional, then > "urn:http://www.ncsa.uiuc.edu/" has identically the same meaning - it > is an equivalent identifier). A client can resolve > "http://www.ncsa.uiuc.edu/" using HTTP or using the NAPTR protocol, or > something else. This is the very same identifier, not two identifiers > with the same character representation. Calling it two identifiers > and saying one is a name and the other is [the name of] a location is > missing the whole point. No, _you_ are missing the point. By saying that "urn:http://www.ncsa.uiuc.edu/" is a _name_, one know that this namespace called HTTP can grandfather other namespaces, this _name_ can stay as it is even if the resource moves, the metadata for this resource can be fetched etc etc all according to the URN spec that was written down years ago. If you have a URL, like "http://www.ncsa.uiuc.edu/", what do you do if you have to move this resource from the host www.ncsa.uiuc.edu? Change things in the DNS? But of course that works. But, if you move the information from staying only on an http server to also stay in a Z39.50 database and want the clients to be able to use both, or if the resolution from www.ncsa.uiuc.edu to a hostname, which later is turned into an IP-address in DNS is not done in DNS for some reason in the future? What if the resource is mirrored to a different site? There are thousands of things you _can_not_do_ with the name of a location of something, that you only can do with a _name_ of a resource which is resolved to one or many alternative locations. > The point is a single identifier can, in fact, be resolved many > different ways by clients. Some ways are more direct (e.g. HTTP) and > some are more indirect (e.g. NAPTR). They are all resolution > mechanisms. They all result, eventually, in the resource, or whatever > is being requested. You _have_ to start to look at what kind of resolutions you do, and can do. Just because you can have one A-record point to a list of IP-addresses, that doesn't help you because the way the zones in DNS are delegated. You _have_ to look at who owns what part of the information used in the resolution process! > I see no difference between *names* and *locations* at least > regarding the identifiers themselves. I can see that. There seems to, though, to be a number of people that do, and I am one of them. Patrik Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id CAA15922 for urn-ietf-out; Sun, 3 Nov 1996 02:52:34 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id CAA15917 for ; Sun, 3 Nov 1996 02:52:31 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16743 (mail destined for urn-ietf@services.bunyip.com); Sun, 3 Nov 96 02:52:29 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id BAA25657; Sun, 3 Nov 1996 01:48:05 -0600 (CST) Date: Sun, 3 Nov 1996 01:48:05 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611030748.BAA25657@ncsa.uiuc.edu> To: "Karen R. Sollins" Cc: urn-ietf@bunyip.com Subject: Re: [URN] some comments In-Reply-To: <199611020043.TAA07540@lysithea.lcs.mit.edu> References: <199611020043.TAA07540@lysithea.lcs.mit.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Karen R. Sollins writes: > This is a response to several responses to my message (each time I sit > down to respond I'm interrupted and by the time I get back to it there > has been more mail:-) I know what you mean. I have to wait til the quiet hours to get real work done. > First, I want to echo what Leslie has been saying. Unless we are > going to rethink all the work of the last 3 or more years, URNs > identify resources and URLs identify locations of resources and these > are different abstractions. They could be chosen from the same set of > names, but they have different requirements on the names (see RFC1736 > and RFC1737). Enough said on that topic; for any more, see Leslie's > lucid comments. I'll comment on Leslie's comments, perhaps tomorrow. But I want to challenge the notion that we shouldn't rethink the work of the last several years. For one thing, for the last 2 years, I (and a few others) have been arguing against the split in names vs locations, so why should that work be ignored? This is not a matter of just agreeing on a definition - it is a matter of having definitions that make sense. For much longer, Tim Berners-Lee has argued against this name-location split. Most, if not all, of the W3C staff agree with this, and I don't think it is because they were tested on this point before being hired. I didn't agree with Tim at first, but it wasn't out of respect for him that I changed my mind. It takes a decision not to be dogmatic, though, to be open to honest rethinking. > From: Daniel LaLiberte > > One way to avoid this is to make sure that the context for resolution > is always clear. So when giving a URL in an HTML document you could > use HTTP="scheme:opaque-string", and when giving a URN you could use a > different tag, e.g. URN="nsi:opaque-string". This idea tends to pop > up occasionally, but I think it not useful. > > Leslie responded to most of this message, but this point surprised > me. You are suggesting that in HTML we label URNs as such. My suggestion was hypothetical. I am *not* suggesting we do it. > I am left with two questions. First, why is that only in HTML > should they be labelled? Where did I say only HTML? It was an example. > Second, why is it that the holder of a string (the principle > putting the string into the HTML document in this case) is the one > to decide which string is a URN and which is not? Good point. And this is a good reason *not* to do it. > Shouldn't that be decided by whoever did the name assignment? Yes and no. The creator of the identifier could use a name space associated with a resolution mechanism that provides name properties. But the author of the document containing the identifier *could* also suggest a resolution mechanism that provides name properties. Also, the client itself *could* use a resolution mechanism that provides name properties. The identifier itself does not provide name properties - the resolution mechanism does. > So, my conclusion is that, if it is really important to > label URNs (which I happen to believe is true, and it seems you are > suggesting) I am not suggesting that - to the contrary, I am arguing for the opposite of that. (Maybe you forgot who you were replying to.) I raised the idea of labelling identifiers as URNs within the context of their use precisely so it could be shot down. Thanks. > and if the assigner of an identifier should be the > determiner of whether the identifier is identifying a resource or a > location for a resource, the assigner of the identifier should clarify > that fact by including it in the identifier for all to know. This is > not something that the "client" gets to decide. But it is something that the client gets to decide! And the reason is that "identifier of resource" vs "identifier of location of resource" doesn't make sense. It is the chosen resolution mechanism that determines how you get from an identifier to the resource. The identifier does *not* determine the resolution mechanism, although there may be conventions and globally agreed on mechanisms available. The client *can* make the choice of how to resolve an identifier. It is a fact of life in a free society that clients can do whatever they want. (They can't always get away with it, though.) -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA15524 for urn-ietf-out; Sun, 3 Nov 1996 01:56:31 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA15517 for ; Sun, 3 Nov 1996 01:56:23 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16634 (mail destined for urn-ietf@services.bunyip.com); Sun, 3 Nov 96 01:56:20 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id AAA25490; Sun, 3 Nov 1996 00:51:41 -0600 (CST) Date: Sun, 3 Nov 1996 00:51:41 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611030651.AAA25490@ncsa.uiuc.edu> To: Terry Allen Cc: urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: <199610312051.MAA10123@ishtar.fsc.fujitsu.com> References: <199610312051.MAA10123@ishtar.fsc.fujitsu.com> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Daniel LaLiberte writes: > | OK, what is a location? > | ... Is it the > | domain name of the server, together with the path within the server? > | That's getting closer to the abstraction that URLs provide. Is the > | location, in fact, the URL itself? Terry Allen writes: > No, the URL is neither the location nor the resource, but the > name of a location, or a name of a location that may be resolved > on the fly. The location is not the resource; the name of the > location is not the name of the resource. On the face of it, this is sounding rather strange. First, I agree that the URL is not the resource itself (who would say that it is? from your comment at the end, I think you think I said that). Saying a URL is "the name of a location" is almost the same as "a URL identifies a location". The extra indirection of going from URL to identifier to location, rather than URL to location, seems unnecessary, and perhaps it is irrelevant semantics. What is relevant is that you guys make a distinction between URLs and URNs, and it is a distinction founded on a misunderstanding. I've been trying to dig through to get to the heart of that misunderstanding. > | Consider caches. The resolution of a URL via a cache proxy may find > | the resource in the cache rather than in some remote server. What is > | "the location" of the resource in that case? > > What is "the resource"? Any copy of what you got back from resolution? > then its location is both in the cache and on the remote server. > Is it "the copy I got back from resolution"? then its location > is in the cache. But the very same URL was used to retrieve the resource either from a cache or from a remote server. So what "location" is the URL identifying when the resource actually lives in multiple places - the very same URL may be used to fetch the resource from any of those places? Notice you first say that a URL identifies (or names) the location of a resource, and then we find out that there are really multiple locations identified by the URL. But that is supposed to be the job of URNs. So why do we need URNs? > | Here is an example of how what is thought of as a location really > | turns out to *be* a name (as in persistent location). Take a normal > | http URL such as http://www.ncsa.uiuc.edu/. Instead of using normal > | HTTP to resolve the URL, or to look it up in a cache, let's set up a > | NAPTR-based "http" naming authority. Under that branch of the name > | space, we could ask the appropriate DNS server to look up > | 'www.ncsa.uiuc.edu' to find out where a server is currently located > | and what "resolution protocols" are currently supported. > > That is a coincidence of naming: you made the name of the resource > (qua URN) be the same as the name of its location. But > urn:http://www.ncsa.uiuc.edu/ > and > url:http://www.ncsa.uiuc.edu/ > name two different things. I used "http://www.ncsa.uiuc.edu/" for both, no "urn:" or "url:" for either. (BTW, If "urn:" is optional, then "urn:http://www.ncsa.uiuc.edu/" has identically the same meaning - it is an equivalent identifier). A client can resolve "http://www.ncsa.uiuc.edu/" using HTTP or using the NAPTR protocol, or something else. This is the very same identifier, not two identifiers with the same character representation. Calling it two identifiers and saying one is a name and the other is [the name of] a location is missing the whole point. The point is a single identifier can, in fact, be resolved many different ways by clients. Some ways are more direct (e.g. HTTP) and some are more indirect (e.g. NAPTR). They are all resolution mechanisms. They all result, eventually, in the resource, or whatever is being requested. > | We don't need to create a new kind of identifier to make a URL > | into a persistent location. > Which is not what you did in the example just given. It is so. > You created a new name space and rules for using it that by design > produce a name that looks like a URL which, when resolved, will > give the same result. The name space is just a vehicle for resolving the identifier. Consider how a cache creates a name space for looking up resources given http URLs (usually it's just a hash table, but imagine it creates a similar hierarchy to model DNS and filesystems within servers). Would you claim that the cache is somehow making new identifiers? Here is, perhaps, the missing point: The persistence of a name space is not a property of the identifiers - it is a property of the mechanism used to resolve the identifiers. You seem to be saying that the persistence is a property of URNs, and thus names are obviously different from locations. I am saying that the persistence of URNs is due to resolution mechanisms such as the NAPTR mechanism. (It is also due to the naming authorities guaranteeing that the names will behave properly if the appropriate resolution mechanism is used.) Since different mechanisms can be used to resolve the very same identifiers, and since some mechanisms might provide persistence while others do not, there is no point in distinguishing the identifiers as either names or locations. There is nothing inherent in identifiers themselves that makes them have different properties, whether name-like or location-like. It is how the identifiers are created and used that gives them those properties. >From that standpoint, http URLs are different from new classes of identifiers that will be created under the URN name space(s). I certainly recognize that we need more persistence in the resolution process, and that is why we created the "path" resolution mechanism. (In fact, I believe the NAPTR mechanism doesn't go quite far enough, and agree with Larry in that regard.) But it is not the identifiers themselves that need to be distinguished based on the properties of the resolution mechanism. For one class of identifier, there might be two resolution mechanisms available, one supports persistence and the other does not. So are the identifiers names or locations? Irrelevant question. > | To summarize, both URLs and URNs have the following abstract > | resolution process in common: > | 1. Do some client-specific processing of the URI - maybe end there. > | 2. Look at the scheme name of the URI. If it says "URN:" drop it and repeat. > > No, you have to branch into your "find URN" subprocess. You could handle everything with "URN:" prefix with the same process, but it is not required - you could just as well handle each URN subscheme differently. Or you could handle parts of a single name space differently from the rest. > | 3. Look up the scheme in local table to find out what process should > > The local table will be different for URLs and URNs, will it not? Not necessarily. Each URL or URN scheme might have a different process associated with it, or we could use just one process for all schemes. > | be invoked. E.g. news URIs may use NNTP, http URIs may use HTTP, > | cid URIs may use NAPTR-protocol. > | 4. Invoke the process identified by step 3. > | 5. If error results, exit. > | 6. If redirected to another URI, repeat whole process with that URI. > | > | An alternative to steps 2 and 3 would use more than just the scheme > | name to determine what process to invoke. There are several other > | varients possible in the whole process, and each client or each user > | might do things differently. > | > | I hope I've made my postion very clear regarding names, locations, and > | the resolution process. > > That you see no difference between objects and their locations? I really don't see how you got that. When did I talk about the difference between objects and their locations? I see no difference between *names* and *locations* at least regarding the identifiers themselves. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA01925 for urn-ietf-out; Fri, 1 Nov 1996 19:43:24 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA01907 for ; Fri, 1 Nov 1996 19:43:21 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11306 (mail destined for urn-ietf@services.bunyip.com); Fri, 1 Nov 96 19:43:18 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id TAA07540; Fri, 1 Nov 1996 19:43:18 -0500 Date: Fri, 1 Nov 1996 19:43:18 -0500 Message-Id: <199611020043.TAA07540@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: urn-ietf@bunyip.com Subject: Re: [URN] some comments Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com This is a response to several responses to my message (each time I sit down to respond I'm interrupted and by the time I get back to it there has been more mail:-) First, I want to echo what Leslie has been saying. Unless we are going to rethink all the work of the last 3 or more years, URNs identify resources and URLs identify locations of resources and these are different abstractions. They could be chosen from the same set of names, but they have different requirements on the names (see RFC1736 and RFC1737). Enough said on that topic; for any more, see Leslie's lucid comments. Let me respond (hopefully briefly) to various different responders to me: From: Terry Allen You phrase this as a general matter, and we clearly cannot pretend to govern all resolutions methods. As a trivial example, one method of URN resolution is the publication of physical books containing URNs and other information. Some URNs may be resolvable only by such non-Internet means. Suppose the government were to insist that copies of such books that are sold to the government must be printed on tamper-resistant paper (someone wanting security). Is that something this group should concern itself with? I don't think so, I don't think that one can speak of *the* "infrastructure supporting URN resolution," and so I don't agree with your very general statement. Can you sharpen it up some? Let's just stick to the Internet. I didn't realize that I needed to qualify what I was saying with this statement, but I hope it helps. In fact we have even less say over what happens outside the Internet than we do on the inside:-) From: Daniel LaLiberte One way to avoid this is to make sure that the context for resolution is always clear. So when giving a URL in an HTML document you could use HTTP="scheme:opaque-string", and when giving a URN you could use a different tag, e.g. URN="nsi:opaque-string". This idea tends to pop up occasionally, but I think it not useful. Leslie responded to most of this message, but this point surprised me. You are suggesting that in HTML we label URNs as such. I am left with two questions. First, why is that only in HTML should they be labelled? If it is useful to label URNs as distinct from other things, this is probably the case everywhere. And I certainly don't expect that everything will be in HTML. Second, why is it that the holder of a string (the principle putting the string into the HTML document in this case) is the one to decide which string is a URN and which is not? Shouldn't that be decided by whoever did the name assignment? So, my conclusion is that, if it is really important to label URNs (which I happen to believe is true, and it seems you are suggesting) and if the assigner of an identifier should be the determiner of whether the identifier is identifying a resource or a location for a resource, the assigner of the identifier should clarify that fact by including it in the identifier for all to know. This is not something that the "client" gets to decide. From: Ron Daniel I totally support the goal of allowing people to have high security if they want it. That is why I am in total, adamant, and unequivocal opposition to the assumption in part 2 - that there might be a URN resolution system with such poor isolation between security domains. I'm afraid you lost me in all the companies that do and don't want the same or different things, but I think we are really having an agreement. Let me give you a simple example of what I had in mind. For the sake of making things concrete, suppose we are using name resolution scheme NS_TRANS (made up) that manages a widely distributed core of translation information that allows for lookup of particular URNs and provides pointers to final stage URN resolution (probably URN to URL translation) servers managed by naming authorities. Then also suppose there is some naming authority NAT_SEC_CO that would like to cause the names it is assigning to be resolved as it believes is correct. NAT_SEC_CO would like to be confident that the information it provides to NS_TRANS is what will be distributed to potential customers and no one who is not authorized can change that information. At the same time, another naming authority NON_SEC_CO believes that the best way for information to be kept up to date is for it to be updatable by anyone, because it is the customers who will discover problems in the resolution information, and will be most motivated to make the corrections (I've heard this position taken by a very reputable person in a security conscious company in a slightly different context.) The position I take on this is that NS_TRANS had better have security mechanisms available to protect NAT_SEC_CO information and furthermore, anyone who wants to have access to it including NON_SEC_CO will have to play the right security game to get access to NAT_SEC_CO's information for modification. At the same time NAT_SEC_CO is given free and open access to NON_SEC_CO's information, as is the case for anyone else. The security infrastructure needs to be there in this case and anyone wanting access to controlled parts will have to play the game properly. It does not mean that the whole infrastructure or even the security provided for those that want it should in any way be dependent on untrustworthy components. That's nonsense, as you rightly point out. But it will depend on the infrastructure providing some security functionality for those that want it and imposing that on everyone who wants service in that corner of the infrastructure space. If we could not depend on the infrastructure for anything, how could we depend on supposed implementations of DNSSEC either? It will only work if the infrastructure is playing the game. Of course, each peer server in the infrastructure will also need to be defensive to protect against incorrectly behaving peers. But that's true in the DNS as well. So, Ron, I believe we are on the same side of this one:-) Karen PS: My apologies - I had planned to keep this short, but it got away from me. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA27704 for urn-ietf-out; Fri, 1 Nov 1996 10:58:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA27699 for ; Fri, 1 Nov 1996 10:58:47 -0500 Received: from workstation1.swip.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06202 (mail destined for urn-ietf@services.bunyip.com); Fri, 1 Nov 96 10:58:45 -0500 Received: (from leslie@localhost) by pluto.swip.net (8.7.6/8.6.12) id QAA06560; Fri, 1 Nov 1996 16:58:41 +0100 (MET) Date: Fri, 1 Nov 1996 16:58:41 +0100 (MET) From: Leslie Daigle X-Sender: leslie@pluto.swip.net To: Daniel LaLiberte Cc: urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: <199610311951.NAA10608@ncsa.uiuc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Leslie Daigle Errors-To: owner-urn-ietf@bunyip.com [Dan LaLiberte wrote:] > OK, what is a location? Is it the bits on the disk that "has" the Well, here's my perspective: A URL (location) is a point in 4-space, as defined by: =09. machine (aliased through DNS mechanisms) =09. port number (default per protocol) =09. protocol to speak on that port and at that machine =09. string to use within that protocol A basic URN (name) has nothing to do with these 4 dimensions -- it is=20 independent of any machine identifier, port, or protocol. The string associated with it is a _label_ that is unique across the specified namespace. > Consider caches. The resolution of a URL via a cache proxy may find > the resource in the cache rather than in some remote server. What is > "the location" of the resource in that case? Caches are external to either URN or URL systems. They may choose to use the URL string as a label that identifies a particular resource, and use that label to lookup contents of the cache. But, caches break when the label does not change, but the contents of the location does. If you cache based on URN, your cache will not break, because the content associat= ed with the identifier does not change. > Here is an example of how what is thought of as a location really > turns out to *be* a name (as in persistent location). Take a normal > http URL such as http://www.ncsa.uiuc.edu/. Instead of using normal > HTTP to resolve the URL, or to look it up in a cache, let's set up a > NAPTR-based "http" naming authority. Under that branch of the name > space, we could ask the appropriate DNS server to look up > 'www.ncsa.uiuc.edu' to find out where a server is currently located > and what "resolution protocols" are currently supported. >=20 > We don't need to create a new kind of identifier to make a URL into a > persistent location. We *do* need new persistent services, such as > the NAPTR records in DNS. I'm not sure I understand the point you are making here. It sounds like you are saying -- forget everything else about all this stuff, let's=20 do NAPTR as a service, and then people can build in persistence using whichever mechansisms strike their fancy? I have a problem with that approach, for (at least) two reasons: =09. implementing a persistent location means adding much overhead =09 in systems that were not built for it. =09. there are then no mechanisms to distinguish between things that =09 are meant to be persistent, and things that are expected not =09 to be. =20 > To summarize, both URLs and URNs have the following abstract > resolution process in common: >=20 > 1. Do some client-specific processing of the URI - maybe end there. > 2. Look at the scheme name of the URI. If it says "URN:" drop it and rep= eat. > 3. Look up the scheme in local table to find out what process should > be invoked. E.g. news URIs may use NNTP, http URIs may use HTTP, > cid URIs may use NAPTR-protocol. > 4. Invoke the process identified by step 3.=20 > 5. If error results, exit. > 6. If redirected to another URI, repeat whole process with that URI. >=20 It is definitely interesting to look at the surface similarities in mechani= cs between URL resolution and the NAPTR approach to URN handling. What still is not clear to me is what you are suggesting to _do_ with this. If you are suggesting that there is nothing more to do with URN work than to define different steps in 2 and 3, I have a problem with that... Leslie. ---------------------------------------------------------------------------= - Leslie Daigle "Min sv=E4vare =E4r full av =E5lar!" Vice President, Research Bunyip Information System= s -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------= - Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA27189 for urn-ietf-out; Fri, 1 Nov 1996 10:12:16 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA27184 for ; Fri, 1 Nov 1996 10:12:14 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA05839 (mail destined for urn-ietf@services.bunyip.com); Fri, 1 Nov 96 10:12:11 -0500 Message-Id: <9611011512.AA05839@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Fri Nov 1 09:11 CST 1996 From: "Ryan Moats" To: "jayhawk@ds.internic.net" , "Martin J Duerst" Cc: "urn-ietf@bunyip.com" Date: Fri, 01 Nov 96 09:12:22 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] %encoding for reserved UTF-8 characters (was: New syntax draft) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com Sorry folks, but I need to keep the threads separate to keep my sanity [at least whatever remains of it.... ;-)] On Fri, 1 Nov 1996 12:11:37 +0100 (MET), Martin J Duerst wrote: >When going from ASCII to UTF-8, there are some new problems. >For ASCII, the general assumption is that only those charcters >that need escaping are actually escaped, and therefore that >escaping, e.g. for "/" or whatever, shouldn't be undone. >The above is not exactly true, indeed the "~" is often escaped >as %7E in Europe because it is difficult to type on European >keyboards, but still I assume there are a lot of tools around >working on URLs in general that work along the rule "if ASCII >is escaped, don't remove the escaping, because this is a special >character. >Now for UTF-8, things are quite different. 8-bit bytes will >on many occasions be escaped because it may be difficult to >represent them otherwise. Having some character beyond ASCII >represented with %HH (usually %HH%HH or %HH%HH%HH) can in no >way imply that this is a special character. >This means that any tools dealing with URNs in general will >have no clue about where to keep the escaping, and where >to remove it. A very exact knowledge of each NSS syntax >would be needed. My brain hurts, but I think I finally understand the issue. Allow me to restate it to see if I'm right: The problem you are talking about arrises if the reserved character has a UTF-8 representation of more than 1 octet. Then, if we use %encoding to represent the character in a literal use, there is no way of determining from the URN whether the character is being used as a literal character or not. I'll save a discussion of potential solution directions to this until I'm sure I understand the issue. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA25992 for urn-ietf-out; Fri, 1 Nov 1996 08:48:19 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA25987 for ; Fri, 1 Nov 1996 08:48:16 -0500 Received: from weeble.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04787 (mail destined for urn-ietf@services.bunyip.com); Fri, 1 Nov 96 08:45:36 -0500 Received: from jon by weeble.lut.ac.uk with smtp (Exim 0.55 #1) id E0vJJtg-0000iI-00; Fri, 1 Nov 1996 13:44:32 +0000 Date: Fri, 1 Nov 1996 13:44:31 +0000 (GMT) From: Jon Knight X-Sender: jon@weeble.lut.ac.uk To: Martin J Duerst Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com Subject: Re: [URN] New syntax draft In-Reply-To: <"josef.ifi..673:01.10.96.11.11.39"@ifi.unizh.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Jon Knight Errors-To: owner-urn-ietf@bunyip.com On Fri, 1 Nov 1996, Martin J Duerst wrote: > When going from ASCII to UTF-8, there are some new problems. > For ASCII, the general assumption is that only those charcters > that need escaping are actually escaped, and therefore that > escaping, e.g. for "/" or whatever, shouldn't be undone. > The above is not exactly true, indeed the "~" is often escaped > as %7E in Europe because it is difficult to type on European > keyboards, but still I assume there are a lot of tools around > working on URLs in general that work along the rule "if ASCII > is escaped, don't remove the escaping, because this is a special > character. Hmm, I don't really understand this; URL percent escaping is just away of dealing with characters that you can't represent directly, either because they're in the reserved set of characters or because they're not easy to type (the French/German/Nordic/Icelandic letters in ISO-8859-1 for example). If you're unescaping things, one would assume that you've already parsed any reserved characters to extract any structuring information that the provide. Percent escaped characters aren't just restricted to the reserved characters that need to be escaped; you can percent escape your entire URL's path if you like. Any software that just expects reserved characters to be percent escaped is going out of its way to be braindead IMHO. And anyway, URLs don't use UTF-8 so this isn't going to be a problem (we're talking URNs here right?). Tatty bye, Jim'll -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA25071 for urn-ietf-out; Fri, 1 Nov 1996 06:13:13 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA25066 for ; Fri, 1 Nov 1996 06:13:11 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03771 (mail destined for urn-ietf@services.bunyip.com); Fri, 1 Nov 96 06:13:09 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01729-0@josef.ifi.unizh.ch>; Fri, 1 Nov 1996 12:11:38 +0100 Subject: Re: [URN] New syntax draft To: jayhawk@ds.internic.net Date: Fri, 1 Nov 1996 12:11:37 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: <9610312029.AA28199@mocha.bunyip.com> from "Ryan Moats" at Oct 31, 96 02:29:20 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1952 From: Martin J Duerst Message-Id: <"josef.ifi..673:01.10.96.11.11.39"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ryan Moats wrote: >On Thu, 31 Oct 1996 11:58:35 +0100 (MET), Martin J Duerst wrote: > >>> It should be noted that certain characters in the Namespace Specific >>> String syntax may have special meaning in certain namespaces. >>> Therefore, the process of registering a namespace identifier shall >>> include publication of a definition of which characters have a >>> special meaning and how to encode these characters if used in a >>> literal sense. >> >>Can they be encoded with %HH? Or should we specifically request some >>other mechanism in order to not confuse different things, and let >>programs that deal with URNs in general change from %HH to 8-bit >>and back? > >Well, I don't have a current opinion one way or the other. Thinking about >it some more, I don't see how we can avoid %HH encoding, so why not >just say that encoding must be specified if %HH isn't used. When going from ASCII to UTF-8, there are some new problems. For ASCII, the general assumption is that only those charcters that need escaping are actually escaped, and therefore that escaping, e.g. for "/" or whatever, shouldn't be undone. The above is not exactly true, indeed the "~" is often escaped as %7E in Europe because it is difficult to type on European keyboards, but still I assume there are a lot of tools around working on URLs in general that work along the rule "if ASCII is escaped, don't remove the escaping, because this is a special character. Now for UTF-8, things are quite different. 8-bit bytes will on many occasions be escaped because it may be difficult to represent them otherwise. Having some character beyond ASCII represented with %HH (usually %HH%HH or %HH%HH%HH) can in no way imply that this is a special character. This means that any tools dealing with URNs in general will have no clue about where to keep the escaping, and where to remove it. A very exact knowledge of each NSS syntax would be needed. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA24927 for urn-ietf-out; Fri, 1 Nov 1996 05:41:54 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA24922 for ; Fri, 1 Nov 1996 05:41:51 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03675 (mail destined for urn-ietf@services.bunyip.com); Fri, 1 Nov 96 05:41:49 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01687-0@josef.ifi.unizh.ch>; Fri, 1 Nov 1996 11:40:58 +0100 Subject: Re: [URN] More on UTF-8 Decoding (was: New syntax draft) To: jayhawk@ds.internic.net Date: Fri, 1 Nov 1996 11:40:57 +0100 (MET) Cc: gjw@wnetc.com, urn-ietf@bunyip.com In-Reply-To: <9610312052.AA28783@mocha.bunyip.com> from "Ryan Moats" at Oct 31, 96 02:52:22 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 775 From: Martin J Duerst Message-Id: <"josef.ifi..598:01.10.96.10.41.13"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ryan Moats wrote: >On Thu, 31 Oct 1996 14:38:57 +0100 (MET), Martin J Duerst wrote: > >>Gregory Woodhouse wrote: >> >>>I'm also concerned because decoding requires knowledge that the string >>>being decoded is UTF-8. >> >>Not exactly. It is very rare that a string that is not UTF-8 looks >>like an UTF-8 string. > >I think this is a good argument for taking UTF-8 decoding out >of the syntax document. Any reasons to leave it in? No, because if you "decode" UTF-8, you get characters, without saying of how exactly they are represented, and so "decode" is definitely the wrong name. You might consider replacing it with "interpretation", but this is only necessary in some cases (e.g. when trying to represent these things on sceen), and not in others. Regards, Martin. 1996-120000666000003600000100000021165606264265720010620 0ustar wwwrunwww Received: from cnri by ietf.org id aa22951; 2 Dec 96 14:22 EST Received: from uscore.xtdl.com by CNRI.Reston.VA.US id aa12750; 2 Dec 96 14:22 EST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id OAA11394 for ; Mon, 2 Dec 1996 14:20:24 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Mon, 2 Dec 1996 14:18:29 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id OAA10901 for pwg-outgoing; Mon, 2 Dec 1996 14:15:58 -0500 (EST) Message-Id: <9612021916.AA14195@zazen> X-Sender: hastings@zazen X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 2 Dec 1996 11:14:15 PST To: rturner@sharplabs.com From: Tom Hastings Subject: PWG> Re: Word doc --> IETF formatted text Cc: scott_isaacson@novell.com, pwg@pwg.org, ipp@pwg.org Sender: owner-pwg@pwg.org Randy, Scott's IPP I-D .txt file did have some long lines in it too. I never got a chance to see what caused them. Scott did set his lines to less than 6 inches. But I didn't think that was necessary. The generic text driver seems to not output trailing blanks on lines (WORD SAVE AS text does output trailing blank lines which cause files to exceed 72 characters, but trailing blank lines are easy to remove.). Make sure that the table of contents doesn't have leader so that overstriking doesn't happen with just a CR. See if this tool helps you locate the long lines. I've put up two tools, courtesy of Ira McDonald, to help make sure that our .txt file meet IETF requirements: ftp://pwg.org/pub/pwg/tools/ -rw-r--r-- 1 pwg pwg 27376 Dec 2 18:58 cscan.exe -rw-r--r-- 1 pwg pwg 26256 Dec 2 19:03 maxln.exe -rw-r--r-- 1 pwg pwg 1089 Dec 2 19:04 readme-maxln-cscan.txt Here is the contents of the readme file: Files: maxln.txt and cscan.txt readme files In order to be able to produc IETF plain text files, I've contributed two tools, courtesy of Ira McDonald, for checking the results of producing plain text files according to IETF rules: - 72-char max line length - simple ASCII graphics only, plus CRLF and FF The two tools are maxln and cscan. ftp://pub/pwg/tools/maxln.exe ftp://pub/pwg/tools/cscan.exe 'maxln.exe' is a DOS utlity that searches for long lines (default is 72 characters). 'cscan.exe' is a DOS utlility that counts the number of characters of each type in the file: DOS print, control, graphic char scanning utility These are both 16-bit MS-DOS executables. To learn their command line switches, execute them without parameters - they each print a program synopsis with an example. For example, to search for lines LONGER than 72 columns in prtmib, and list EACH overlength line number, use the following command line: maxln -72 -v prtmib.txt >prtmib.max (Notice the output redirection used above). Tom Hastings At 09:30 12/02/96 PST, Randy Turner wrote: >Hi guys, > >I received a comment from Cynthia Clark on my internet draft >submission saying that one of the drawings (and some other text) >exceeded 72 columns. I reformatted the document using the >directions that Tom included in a previous message and I still >did not get quite the results I think Cynthia is looking for. > >I have put the document up on the FTP server in Word 2.0 format: > >ftp://ftp.pwg.org/pub/pwg/snmpmib/internet-drafts/mib-120296.doc > >I reformatted the entire document into 10 point font via Tom's >instructions, and I also created a custom paragraph style called >"IETF" which we can quickly edit and reformat the entire document >style easily. I just haven't found the correct combination of >attributes (page setup, paragraph style) that comes out just right >when I print to file using "generic/text printer". > >Since you guys seem to have the conversion process down, any >pointers or conversion help would be appreciated. > >Thanks > >Randy > >-- >Randy Turner >Network Architect >Sharp Laboratories of America >rturner@sharplabs.com > >   Received: from cnri by ietf.org id aa04473; 10 Dec 96 19:44 EST Received: from uscore.xtdl.com by CNRI.Reston.VA.US id aa25936; 10 Dec 96 19:44 EST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id TAA18144 for ; Tue, 10 Dec 1996 19:41:34 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Tue, 10 Dec 1996 19:39:30 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id TAA17623 for pwg-outgoing; Tue, 10 Dec 1996 19:27:19 -0500 (EST) Message-Id: <01BBE6BF.2866FA40@hpb15767.boi.hp.com> From: Bob Pentecost To: 'PWG' Cc: "'Young, Lloyd PWG'" , "'Turner, Randy (PWG)'" Subject: PWG> Missing MIB changes Date: Tue, 10 Dec 1996 17:25:35 -0700 Encoding: 80 TEXT Sender: owner-pwg@pwg.org The change of InputManualFeedTimeout to InputMediaLoadTimeout that has been discussed at the last two meetings failed to get into the Internet Draft of the Printer MIB. How and when will this get done? The relevant minutes and messages are posted below. Bob Pentecost HP ================================ Printer Working Group Meeting Minutes November 7-8, 1996 New Orleans, Louisiana Printer MIB/MIF Project (PMP) A brief discussion was conducted on the changes to the Input Switching Group, as documented in mailing list postings by Bob Pentecost. It was agreed that Bob's comments were accurate, and that the MIB draft should be updated to include his changes. ... The pertinent part of the mail messages follow: At 10:26 11/04/96 PST, Bob Pentecost wrote: >Thanks to Randy for getting the Printer MIB updated. > >I looked for a change that I expected and found that it had not been made. >When I checked the October meeting minutes, I couldn't find a record of the >discussion I had in my own notes. From my notes I have: > >Input Switching Group > >This is a new group of objects that was added to provide timeouts for >manual feed operations. The group will be generalized to provide timeouts >for all media load requests. InputManualFeedTimeout will become >InputMediaLoadTimeout. Tom H. will post the changes. My notes also show the we changed the name of the prtInputManualFeedTimeout object to prtInputMediaLoadTimeout, but the name of the group remains Input Switching Group. I think we can also delete the phrase: which translates to 'this input subunit doesn't support manual feed'" in the sentences: The event which causes the printer to enter the waiting state is product specific. A value of (-1) implies 'other' or 'infinite" which translates to 'this input subunit doesn't support manual feed'. A value of (-2) implies 'unknown'. I was unable to open either the August or the current draft, since I suspect that it is WORD version 7.0 and I am running windows 6.0 on 3.11 windows. I'm sorry that I was unable to submit the actual changes as agreed in NYC. I hope that the above helps. Randy, If you could use SAVE AS and save the .doc as word version 6.0 then I could make the changes (in this section only) and re-post this section separately. Or you can make the edits. Tom   Received: from ietf.org by ietf.org id aa19910; 16 Dec 96 18:49 EST Received: from cornpuffs.cisco.com by ietf.org id aa19802; 16 Dec 96 18:45 EST Received: (dhaval@localhost) by cornpuffs.cisco.com (8.6.12/8.6.5) id PAA20292; Mon, 16 Dec 1996 15:37:25 -0800 Sender:ietf-request@ietf.org From: Dhaval Shah Message-Id: <199612162337.PAA20292@cornpuffs.cisco.com> Subject: Re: Article re San Jose IETF in Sunday San Francisco paper To: TurnerX Rentz Date: Mon, 16 Dec 1996 15:37:24 -0800 (PST) Cc: ietf@ietf.org In-Reply-To: from "TurnerX Rentz" at Dec 16, 96 03:06:00 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 393 Source-Info: From (or Sender) name not authenticated. > Text item: > > > This URL does not work. You may have mistyped it. > TR The URL works fine for me. You may want to try again. Dhaval > > > > Atricle from the business section available on-line at > > http://www.sfgate.com/cgi-bin/examiner/article.cgi?year=1996&month=12&day=15&ar > ticle=BUSINESS14992.dtl > > if anyone cares to read what was said. > > // marc >   Received: from ietf.org by ietf.org id aa25772; 16 Dec 96 20:42 EST Received: from [192.148.160.10] by ietf.org id aa25630; 16 Dec 96 20:37 EST Received: (from uucp@localhost) by mail.telstra.com.au (8.8.2/8.6.9) id LAA07311; Tue, 17 Dec 1996 11:56:16 +1100 (EST) Received: from mail_gw.fwall.telecom.com.au(192.148.147.10) by mail via smap (V1.3) id sma005171; Tue Dec 17 11:43:07 1996 Received: (from uucp@localhost) by mail_gw.fwall.telecom.com.au (8.8.2/8.6.9) id LAA26290; Tue, 17 Dec 1996 11:43:05 +1100 (EST) Received: from cdn_mail.dn.itg.telecom.com.au(144.135.109.134) by mail_gw.telecom.com.au via smap (V1.3) id sma026171; Tue Dec 17 11:42:33 1996 Received: from otcgpo.isg.otc.com.au (otcgpo.isg.otc.com.au [134.159.16.100]) by cdn-mail.telecom.com.au (8.8.2/8.6.9) with SMTP id LAA29534; Tue, 17 Dec 1996 11:42:32 +1100 (EST) Received: from msmailhost.isg.otc.com.au by otcgpo.isg.otc.com.au (4.1/OTC_GPO.2.9) id AA18660; Tue, 17 Dec 96 00:42:30 GMT Received: by msmailhost.isg.otc.com.au with Microsoft Mail id <32B5ECD6@msmailhost.isg.otc.com.au>; Tue, 17 Dec 96 11:44:06 EST Sender:ietf-request@ietf.org From: "Kortegast, Ann" To: "ietf@ietf.org" , TurnerX Rentz Subject: Re: Article re San Jose IETF in Sunday San Francisco paper Date: Tue, 17 Dec 96 11:54:00 EST Message-Id: <32B5ECD6@msmailhost.isg.otc.com.au> Return-Receipt-To: Encoding: 64 TEXT X-Mailer: Microsoft Mail V3.0 Source-Info: From (or Sender) name not authenticated. Another way to find it is to go to the sfgate site, choose index, business, then Examiner Business News and the article is called "Keeping Net safe for democracy" by Tom Abate! :) Long-windedly, Ann > > This URL does not work. You may have mistyped it. > TR > > > > Atricle from the business section available on-line at > > http://www.sfgate.com/cgi-bin/examiner/article.cgi?year=1996&month=12&day=15 > &ar > ticle=BUSINESS14992.dtl > > if anyone cares to read what was said. > > // marc > > Text item: External Message Header > > The following mail header is for administrative use > and may be ignored unless there are problems. > > ***IF THERE ARE PROBLEMS SAVE THESE HEADERS***. > > Source-Info: From (or Sender) name not authenticated. > From: Marco S Hyman > Sender: ietf-request@ietf.org > Message-Id: <17954.850775172@dumbcat.codewright.com> > Date: Mon, 16 Dec 1996 14:26:12 -0800 > Content-Type: text/plain; charset=us-ascii > Mime-Version: 1.0 > Subject: Article re San Jose IETF in Sunday San Francisco paper > To: ietf@ietf.org > Received: from localhost.codewright.com by dumbcat.codewright.com > (4.1/smail-24M > ay90) > id AA17956; Mon, 16 Dec 96 14:26:13 PST > Received: from dumbcat.codewright.com by ietf.org id aa16022; > 16 Dec 96 17:27 EST > Received: from ietf.org by ietf.org id aa16160; 16 Dec 96 17:34 EST > Received: from ietf.org (ietf.org [132.151.1.19]) by mailbag.jf.intel.com > (8.8.4 > /8.7.3) with SMTP id OAA01456; Mon, 16 Dec 1996 14:40:53 -0800 (PST) > Received: from mailbag.jf.intel.com (root@mailbag.jf.intel.com > [134.134.248.4]) > by relay.jf.intel.com (8.8.2/8.7.3) with ESMTP id OAA07379; Mon, 16 Dec > 1996 14: > 38:29 -0800 (PST) > Return-Path: ietf-request@ietf.org >   Received: from ietf.org by ietf.org id aa27392; 16 Dec 96 21:21 EST Received: from presence.lglobal.com by ietf.org id aa27320; 16 Dec 96 21:18 EST Received: from [207.107.12.75] (voyager10.lglobal.com [207.107.12.75]) by presence.lglobal.com (8.6.12/8.6.12) with SMTP id VAA05662; Mon, 16 Dec 1996 21:38:10 -0500 X-Sender: wtv@lglobal.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 16 Jul 1996 21:17:23 -0500 To: "Kortegast, Ann" , "ietf@ietf.org" , TurnerX Rentz Sender:ietf-request@ietf.org From: Bob Allisat Subject: Re: Article re San Jose IETF in Sunday San Francisco paper Source-Info: From (or Sender) name not authenticated. And you people are information professionals? We are in deep trouble... BA   Received: from ietf.org by ietf.org id aa05037; 17 Dec 96 11:49 EST Received: from black-ice.cc.vt.edu by ietf.org id aa04389; 17 Dec 96 11:40 EST Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.4/8.8.4) with ESMTP id LAA59946; Tue, 17 Dec 1996 11:36:16 -0500 Message-Id: <199612171636.LAA59946@black-ice.cc.vt.edu> X-Mailer: exmh version 2.0alpha 12/3/96 To: TurnerX Rentz Cc: ietf@ietf.org Subject: Re: Protocols and Platforms - (cont.) In-Reply-To: Your message of "Mon, 16 Dec 1996 22:51:00 PST." Sender:ietf-request@ietf.org From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_-1589561266P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 17 Dec 1996 11:36:13 -0500 Source-Info: From (or Sender) name not authenticated. --==_Exmh_-1589561266P Content-Type: text/plain; charset=us-ascii On Mon, 16 Dec 1996 22:51:00 PST, you said: > We might one day be able to build applications like we build > networks, assembling high-quality, reliable parts from time > tested procedures, using analytical methods instead of rote. Umm.. Actually.. at most sites, networks *do* get built by rote, and arcane incantations, and "I saw it posted once that this was a bad idea..". Anybody who doubts this should look at the widespread incidence of Clue Deficit Disorder among all the marginal ISPs that have sprung up in the last 2 years or so.... Some days I think the only reason the net works at *all* is because the vendors have managed to get things somewhere close to idiot-proof (modulo the true idiot savant idiots, of course ;) -- Valdis Kletnieks Computer Systems Engineer Virginia Tech --==_Exmh_-1589561266P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCUAwUBMrbL+NQBOOoptg9JAQE0awP49iydSJ8OWrE2wYxePnm7xAlddgftBUKv QyiUerQ5YQMkwIAxEaWYM0hFltmYx36R5CBqIo8RIJI19yTHy3BvIwB9GbZB5jx+ AEtrQoPAX1zdu7bYJ0ol/nbOvVh4F77Um8cpxMTeeE5/bXPmdFjzWwNhWWx3hxEY UkQ8JbRbcQ== =1bAe -----END PGP MESSAGE----- --==_Exmh_-1589561266P--   Received: from cnri by ietf.org id aa21678; 18 Dec 96 11:01 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa14857; 18 Dec 96 11:01 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12725 for uri-out; Wed, 18 Dec 1996 10:13:31 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12704; Wed, 18 Dec 1996 10:12:44 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01880 (mail destined for uri@services.bunyip.com); Wed, 18 Dec 96 10:12:42 -0500 Received: by privateer.windrose.omaha.ne.us; Wed Dec 18 09:11 CST 1996 Message-Id: <32B80993.5785@ds.internic.net> Date: Wed, 18 Dec 1996 09:11:15 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: uri@bunyip.com Cc: urn-ietf@bunyip.com Subject: Potential inconsistency between URL and URN syntaxes... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-uri@bunyip.com Precedence: bulk Folks- I was reminded this morning that there is a potential inconsistency between the URL and URN syntax specifications (draft-fielding-url-syntax-02.txt and draft-ietf-urn-syntax-01.txt). Because of this, I am cross-posting this to both lists, so I apologize to those folks that will see this multiple times (I know I will...) The inconsistency arises from the following: In the URL syntax draft the following statement is made: > 1.1. URL, URN, and URI > > URLs are a subset of Uniform Resource Identifiers (URI), which also > includes the notion of Uniform Resource Names (URN). A URN differs > from a URL in that it identifies a resource in a location-independent > fashion (see RFC 1737, [10]). URNs are defined by a separate set of > specifications. > > Although this specification restricts its discussion to URLs, the > syntax defined is that of URI in general. Any requirements placed on > the URL syntax also apply to the URI syntax. This uniform syntax for > all resource identifiers allows a URN to be used in any data field > that might otherwise hold a URL. However, in the latest draft URN syntax spec (circulating on the urn mailing list), the syntax for a URN is > "urn:" ":" I don't beleive that the URN specification "can be used in any data field that might otherwise hold a URL" as it currently stands (If somebody thinks otherwise, please let me know). Therefore, either the syntax specs need to be aligned or the statements about the URL specification refering to the URI syntax need to be modulated (neither of which are pleasant topics...). My current preference is to modulate the URL syntax specification to support the URN syntax and move forward. Ryan Moats InterNIC Directory and Database Services   Received: from cnri by ietf.org id aa23902; 18 Dec 96 11:34 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa17129; 18 Dec 96 11:34 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA13428 for uri-out; Wed, 18 Dec 1996 11:05:06 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA13402; Wed, 18 Dec 1996 11:04:47 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02444 (mail destined for uri@services.bunyip.com); Wed, 18 Dec 96 11:04:41 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.2/8.8.2) with ESMTP id KAA01432; Wed, 18 Dec 1996 10:03:59 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id JAA04091; Wed, 18 Dec 1996 09:59:50 -0600 (CST) Date: Wed, 18 Dec 1996 09:59:50 -0600 (CST) Message-Id: <199612181559.JAA04091@void.ncsa.uiuc.edu> To: Ryan Moats Cc: uri@bunyip.com, urn-ietf@bunyip.com Subject: [URN] Potential inconsistency between URL and URN syntaxes... In-Reply-To: <32B80993.5785@ds.internic.net> References: <32B80993.5785@ds.internic.net> Sender: owner-uri@bunyip.com Precedence: bulk Ryan Moats writes: > However, in the latest draft URN syntax spec (circulating on the urn > mailing list), the syntax for a URN is > > > "urn:" ":" > > I don't beleive that the URN specification "can be used in any data > field that might otherwise hold a URL" as it currently stands (If > somebody thinks otherwise, please let me know). I think otherwise. I don't see anything wrong with this syntax - consider that the scheme name for this whole class of URNs is called "urn", and thus "urn:" preceeds the rest of the identifier. You were not specific about what the nature of the conflict is. If "urn:" were optional (which is a subject still open for debate, I presume), we may have a conflict. The general URI syntax allows the ":" prefix to be optional, and more of the prefix can be left out, but then we might have a relative URI, which has different semantics. With no "urn:", the would actually function as the scheme name since it indicates how to interpret the . But this is true even with a required "urn:" prefix since we want URNs to be independent of the resolution mechanism. I'm not clear whether you believe URNs *should* be used in any data field that might otherwise hold a URL, independent of whether they in fact can. I believe they should. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/   Received: from cnri by ietf.org id aa03819; 18 Dec 96 14:01 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa20818; 18 Dec 96 14:01 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA15015 for uri-out; Wed, 18 Dec 1996 13:22:24 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA15010; Wed, 18 Dec 1996 13:22:21 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03878 (mail destined for urn-ietf@services.bunyip.com); Wed, 18 Dec 96 13:22:06 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <02348-0@josef.ifi.unizh.ch>; Wed, 18 Dec 1996 19:21:07 +0100 Date: Wed, 18 Dec 1996 19:21:06 +0100 (MET) From: "Martin J. Duerst" To: Ryan Moats Cc: uri@bunyip.com, urn-ietf@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... In-Reply-To: <32B80993.5785@ds.internic.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-uri@bunyip.com Precedence: bulk On Wed, 18 Dec 1996, Ryan Moats wrote: > Folks- > > I was reminded this morning that there is a potential inconsistency > between the URL and URN syntax specifications > (draft-fielding-url-syntax-02.txt and draft-ietf-urn-syntax-01.txt). > Because of this, I am cross-posting this to both lists, so I apologize > to those folks that will see this multiple times (I know I will...) I have noticed this inconsistency, too, and am glad Ryan brought it up. > The inconsistency arises from the following: > > In the URL syntax draft the following statement is made: > > > 1.1. URL, URN, and URI > > > > URLs are a subset of Uniform Resource Identifiers (URI), which also > > includes the notion of Uniform Resource Names (URN). A URN differs > > from a URL in that it identifies a resource in a location-independent > > fashion (see RFC 1737, [10]). URNs are defined by a separate set of > > specifications. > > > > Although this specification restricts its discussion to URLs, the > > syntax defined is that of URI in general. Any requirements placed on > > the URL syntax also apply to the URI syntax. This uniform syntax for > > all resource identifiers allows a URN to be used in any data field > > that might otherwise hold a URL. > > However, in the latest draft URN syntax spec (circulating on the urn > mailing list), the syntax for a URN is > > > "urn:" ":" > > I don't beleive that the URN specification "can be used in any data > field that might otherwise hold a URL" as it currently stands (If > somebody thinks otherwise, please let me know). Therefore, either the > syntax specs need to be aligned or the statements about the URL > specification refering to the URI syntax need to be modulated > (neither of which are pleasant topics...). My current preference > is to modulate the URL syntax specification to support the URN syntax > and move forward. I think there is very much to be gained from URLs and URNs being syntactically alligned. Currenty, it looks to me as if this is the case; the "urn" part is a , and everything after that is scheme-specific. The greedy algorithm (Section 4.4) and the exclusion of ":" in schemes assures that this parsing will be done correctly. The treatment of reserved characters could cause some problems, however. To allow substitution of "%7E" by "~" (URL, 2.2/2.3.2) while that character is not available on many keyboards is problematic. Therefore, that aspect has to be reconsidered anyway. The URL draft also does not agree with the URN draft on i18n issues. I18N in URLs is a large topic, and I hope to get the time tomorrow to comment on its treatment in the URL draft. In the context of this thread, it is at least required that consequences in these differences are analysed/understood, and that there is language in the URL draft (given it is kept to be responsible for URIs in general) that the syntax alignement does not include these issues. This most probably should be done with a general statement explaining what exactly is covered, and what not, by "uniform syntax". Regards, Martin.   Received: from cnri by ietf.org id aa13098; 18 Dec 96 18:42 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa27877; 18 Dec 96 18:42 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA18316 for uri-out; Wed, 18 Dec 1996 18:24:28 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA18298; Wed, 18 Dec 1996 18:24:20 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06453 (mail destined for uri@services.bunyip.com); Wed, 18 Dec 96 18:24:19 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id SAA04077; Wed, 18 Dec 1996 18:24:18 -0500 Message-Id: <199612182324.SAA04077@beethoven.bunyip.com> From: Leslie Daigle Date: Wed, 18 Dec 1996 18:24:18 -0500 In-Reply-To: Ryan Moats's message as of Dec 18, 9:11 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Ryan Moats , uri@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... Cc: urn-ietf@bunyip.com Sender: owner-uri@bunyip.com Precedence: bulk It looks like the following questions are on the table: . should URN and URL syntaxes be consistent? . if yes, which should now change: . URLs cannot, because of legacy support, although there is the issue of "I18N" . URNs "can", except that the existing syntax was built for specific reasons to address issues that have concerned URNs more than URLs (e.g., bringing in other namespaces and addressing multiple language issues). Is it "desirable" that URN syntax be compliant with URL syntax, or "required"? What _breaks_ if it is not? [Ryan quotes from the URL draft:] > > > > Although this specification restricts its discussion to URLs, the > > syntax defined is that of URI in general. Any requirements placed on > > the URL syntax also apply to the URI syntax. This uniform syntax for > > all resource identifiers allows a URN to be used in any data field > > that might otherwise hold a URL. This draft is for the _URL_ syntax, and this is the only paragraph that lays claim to all of URI syntaxes. It was written before there was a concrete proposal for URNs. I think the URL syntax RFC would be quite complete _without_ this paragraph. The URL syntax is going to face its own battles as the issues of character sets and languages are brought up -- it seems like now is a logical time to separate out the evolution of these two things, _unless_ there are some very concrete things that will break if they are not kept consistent. Cheers! Leslie. -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ----------------------------------------------------------------------------   Received: from cnri by ietf.org id aa03339; 19 Dec 96 10:32 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa11658; 19 Dec 96 10:32 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA26248 for uri-out; Thu, 19 Dec 1996 09:56:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA26243; Thu, 19 Dec 1996 09:56:34 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09870 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 09:55:13 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <11442-0@josef.ifi.unizh.ch>; Thu, 19 Dec 1996 15:26:52 +0100 Date: Thu, 19 Dec 1996 15:26:51 +0100 (MET) From: "Martin J. Duerst" To: Leslie Daigle Cc: Ryan Moats , uri@bunyip.com, urn-ietf@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... In-Reply-To: <199612182324.SAA04077@beethoven.bunyip.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-uri@bunyip.com Precedence: bulk On Wed, 18 Dec 1996, Leslie Daigle wrote: > It looks like the following questions are on the table: > > . should URN and URL syntaxes be consistent? I guess we have to ask "to what extent should they be consistent". Definitely, allowing something such as ">" in URNs, while they are used to delimit URLs, would be a very bad idea. On the other hand, the fact that the octets represented (with %HH in the canonical form) in URNs are interpreted as UTF-8 should not at the moment force URLs to suddenly convert to UTF-8 (quite difficult), but should not on the other hand scare URLs away from making the necessary preparations to get better i18n facilities and try to move in the direction of UTF-8. (more on that later). > . if yes, which should now change: > > . URLs cannot, because of legacy support, although > there is the issue of "I18N" > > . URNs "can", except that the existing syntax was > built for specific reasons to address issues that > have concerned URNs more than URLs (e.g., bringing > in other namespaces and addressing multiple language > issues). > > > Is it "desirable" that URN syntax be compliant with URL syntax, or "required"? > What _breaks_ if it is not? We don't want a HTML parser or something similar to need separate code for parsing URLs and URNs. It should be able to deal with URNs as one URL scheme, syntactically. It looks like that is possible, but I have to admit that I am no regex expert. > [Ryan quotes from the URL draft:] > > > > > > Although this specification restricts its discussion to URLs, the > > > syntax defined is that of URI in general. Any requirements placed on > > > the URL syntax also apply to the URI syntax. This uniform syntax for > > > all resource identifiers allows a URN to be used in any data field > > > that might otherwise hold a URL. > > This draft is for the _URL_ syntax, and this is the only paragraph that > lays claim to all of URI syntaxes. But it lays claims for all of the URL document, or at least a large part of it. Regards, Martin.   Received: from cnri by ietf.org id aa05864; 19 Dec 96 11:19 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa13010; 19 Dec 96 11:19 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA27233 for uri-out; Thu, 19 Dec 1996 10:36:55 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA27131; Thu, 19 Dec 1996 10:35:54 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10263 (mail destined for uri@services.bunyip.com); Thu, 19 Dec 96 10:35:48 -0500 Received: by privateer.windrose.omaha.ne.us; Thu Dec 19 09:34 CST 1996 Message-Id: <32B9606C.702E@ds.internic.net> Date: Thu, 19 Dec 1996 09:34:04 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: "Martin J. Duerst" Cc: Leslie Daigle , uri@bunyip.com, urn-ietf@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-uri@bunyip.com Precedence: bulk Martin J. Duerst wrote: > > We don't want a HTML parser or something similar to need separate code > for parsing URLs and URNs. It should be able to deal with URNs as one > URL scheme, syntactically. It looks like that is possible, but I have > to admit that I am no regex expert. > While I am not a regex expert either, there seem to me some obvious issues here, which I have tried to address with comments on where changes need to be made: 1. Can a URL parser handle the "urn::" leader for URNs properly? Having looked at the "greedy" algorithm and the Regular Expression in the URL draft, I can say that the first part is sufficient to pick up the scheme as "urn:". If we take the approach in comment 3 below, then the URL spec should note that (a) schemes may well have ":" in them or (b) a scheme beginning with "urn:" is treated as an opaque URL because it is really a URN (ITEM FOR URL DRAFT). 2. The URN and URL character sets are not currently aligned well. ("Well" means that there are characters allowed for URLs that are not allowed for URNs). There are currently (by my counting), two characters allowed in the URN char set that are not allowed in the URL char set: "\" and "%". I don't have a problem with moving the "\" to the excluded set for URNs (ITEM FOR URN DRAFT) "%" is also part of the URN char set only to ensure that the definition for the end of a URN is clean. It's sole purpose is to introduce an escape sequence for an octet (a literal "%" must be encoded as %25). I am strengthening the language in the URN syntax draft with respect to the "%" issue. (ITEM FOR URN DRAFT) 3. There is no specification of structure for a URN NSS. The only way to handle this through a URL parser is for the URL parser to declare the URN as an "opaque-URL" and do no processing on it. This specification (if done) must be done in the URL document (ITEM FOR URL DRAFT). If we do these things, I think we've cleaned up the problem. I am currently moving the "\" character to the excluded region of the URN character set. Ryan   Received: from cnri by ietf.org id aa08298; 20 Dec 96 8:47 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa09488; 20 Dec 96 8:47 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA21313 for uri-out; Fri, 20 Dec 1996 08:14:48 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA21297; Fri, 20 Dec 1996 08:14:30 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18882 (mail destined for uri@services.bunyip.com); Fri, 20 Dec 96 08:13:52 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <06235-0@josef.ifi.unizh.ch>; Fri, 20 Dec 1996 14:13:27 +0100 Date: Fri, 20 Dec 1996 14:13:25 +0100 (MET) From: "Martin J. Duerst" To: Towsner Cc: Larry Masinter , leslie@bunyip.com, tme@casa.usno.navy.mil, urn-ietf@bunyip.com, jcurran@bbn.com, uri@bunyip.com Subject: Re: [URN] Checksums in URNs In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-uri@bunyip.com Precedence: bulk On Thu, 19 Dec 1996, Towsner wrote: > >Checksums and other kinds of decorations can be done outside the > >URL. Think of it as a metascheme: > > ck: > > e.g. ck:A3Bd:http://www.parc.xerox.com/masinter >=20 > =09I like the idea of having the checksum be optional, as a > meta-scheme. Same for me. >I also think the checksum should be limited to alpha-numeric > characters, to avoid confusion. What do you mean by "limited to alpha-numeric characters"? Can you be more precise. >Perhaps this should be part of the URL > scheme as well. If it is a metascheme, then it is a new URI scheme. It doesn't have to be discussed either in URL nor in URN syntax. It would go into a separate draft. It has to make sure, on its own, that it is compatible with the URL/URN syntax. Perhaps the URL syntax draft, where it speaks about URIs, could be generalized in the direction of metaschemes. From=20the syntax viewpoint, we already have two metaschemes (urn: and ck:), which can even be combined together, as ck:urn:namespace:NSS. Regards,=09Martin.   Received: from cnri by ietf.org id aa10972; 20 Dec 96 10:06 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa11218; 20 Dec 96 10:06 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA22308 for uri-out; Fri, 20 Dec 1996 09:34:56 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA22301; Fri, 20 Dec 1996 09:34:23 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19208 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 09:34:20 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 20 08:32 CST 1996 Message-Id: <32BAA368.4FD2@ds.internic.net> Date: Fri, 20 Dec 1996 08:32:08 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: "Martin J. Duerst" Cc: Towsner , Larry Masinter , leslie@bunyip.com, tme@casa.usno.navy.mil, urn-ietf@bunyip.com, jcurran@bbn.com, uri@bunyip.com Subject: Re: [URN] Checksums in URNs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-uri@bunyip.com Precedence: bulk My turn to add my two cents worth... Martin J. Duerst wrote: > > On Thu, 19 Dec 1996, Towsner wrote: > > > >Checksums and other kinds of decorations can be done outside the > > >URL. Think of it as a metascheme: > > > ck: > > > e.g. ck:A3Bd:http://www.parc.xerox.com/masinter > > > > I like the idea of having the checksum be optional, as a > > meta-scheme. > > Same for me. I'll make three... > >I also think the checksum should be limited to alpha-numeric > > characters, to avoid confusion. > > What do you mean by "limited to alpha-numeric characters"? Can you be > more precise. How about just hex characters to keep it simple... > >Perhaps this should be part of the URL > > scheme as well. > > If it is a metascheme, then it is a new URI scheme. It doesn't > have to be discussed either in URL nor in URN syntax. It would > go into a separate draft. It has to make sure, on its own, > that it is compatible with the URL/URN syntax. I agree with Martin, and if we use ck: then we are already compatible with the URL/URN character sets. How to generate the hex sequence is another headache altogether... > Perhaps the URL syntax draft, where it speaks about URIs, > could be generalized in the direction of metaschemes. > From the syntax viewpoint, we already have two metaschemes > (urn: and ck:), which can even be combined together, > as ck:urn:namespace:NSS. Martin is correct here as well. Ryan   Received: from cnri by ietf.org id aa14145; 26 Dec 96 10:11 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa09273; 26 Dec 96 10:11 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA16686 for uri-out; Thu, 26 Dec 1996 09:52:21 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA16647; Thu, 26 Dec 1996 09:51:56 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18416 (mail destined for uri@services.bunyip.com); Thu, 26 Dec 96 09:51:52 -0500 Received: by privateer.windrose.omaha.ne.us; Thu Dec 26 08:51 CST 1996 Message-Id: <32C290D3.790B@ds.internic.net> Date: Thu, 26 Dec 1996 08:50:59 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Larry Masinter Cc: uri@bunyip.com, urn-ietf@bunyip.com Subject: Comments on url-syntax-draft... References: <96Dec26.011608pst."2694"@golden.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-uri@bunyip.com Precedence: bulk Larry- I've looked through your new draft especially with a view to meshing with the URN syntax and I still have two major issues. Fortunately, I believe that a single solution will handle both. I also have an editorial issue. Once these are taken care of, I believe that both drafts have been aligned on this issue. 1. Given the current URN spec, the "greedy" algorith in Appendix B will pick up the urn scheme as "urn:". For example the URN urn:isbn:1-32456-78902-X will be parsed as being scheme "urn:isbn". 2. There is no general specification of structure for a URN NSS, it is determined on a namespace by namespace basis. I can see two solutions to item 1: (a) modify the scheme syntax in Section 4.1 to include ":" or (b) add a section for URN handling that states that a scheme including the "urn:" token should be treated as an opaque URL because it is really a URN. I propose that option (b) be followed because the easiest solution to item 2 is for the URL parser to declare a URN as an "opaque-URL" and do no processing on it. This would ensure that the NSS structure doesn't confuse the URL parser. I believe that an appendix for this would work the best, and I add it below... My editorial issue is that the section paragraph in section 1.1 is potentially confusing. There are requirements in the URL syntax that do not apply to the URN syntax. I would prefer to see the following paragraph in its place: "This specification restricts its discussion to URLs. URN syntax is specified in [URN Syntax Ref]. URN and URL syntax have been specified so that a URN may be used in any data field that might otherwise hold a URL. Details of how to handle a URN are provided in Appendix X." Ryan Moats =======================Appendix on URN handling in a URL parser Appendix X. URN Handling in URL parsers URN syntax is specified in [URN Syntax Ref]. URNs include a leading tag "urn:". Thus, the "greedy" algorithm in Appendix B will return a scheme that includes this tag. In addition, URNs do not require any determinist strcuture to the URN. Rather, this is assigned on a namespace-by-namespace basis. To enable a URL parser to handle a URN properly, A URL parser that detects a scheme that includes the "urn:" tag MUST treat the URL as an opaque URL to be handed to a URN resolver for further processing.   Received: from cnri by ietf.org id aa29706; 27 Dec 96 2:49 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa03363; 27 Dec 96 2:49 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id CAA08650 for uri-out; Fri, 27 Dec 1996 02:18:38 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id CAA08645; Fri, 27 Dec 1996 02:18:36 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21422 (mail destined for urn-ietf@services.bunyip.com); Fri, 27 Dec 96 02:18:34 -0500 Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <16709(4)>; Thu, 26 Dec 1996 23:18:30 PST Received: by palimpsest.parc.xerox.com id <248>; Thu, 26 Dec 1996 23:18:20 PDT To: jayhawk@ds.internic.net Cc: uri@bunyip.com, urn-ietf@bunyip.com In-Reply-To: <32C290D3.790B@ds.internic.net> (message from Ryan Moats on Thu, 26 Dec 1996 06:50:59 PST) Subject: Re: Comments on url-syntax-draft... From: Larry Masinter Message-Id: <96Dec26.231820pdt."248"@palimpsest.parc.xerox.com> Date: Thu, 26 Dec 1996 22:18:20 PST Sender: owner-uri@bunyip.com Precedence: bulk Ryan, I don't think we intend for 'a:b:c:d' to be parsed as belonging to scheme 'a:b:c', so I think we should fix the regular expression in appendix B to treat 'urn:isbn:1-32456-78902-X' as belonging to scheme 'urn' and not scheme 'urn:isbn'. I don't know how to proceed on the issue of changing the URL draft to describe URNs and URN parsing. I think if we're going to proceed from Proposed Standard to Draft Standard that we are not supposed to add functionality, and that the only changes we can make are those that are consistent with current practice. I don't know why URNs don't require any determinist structure to URNs while it seemed important that URLs require such a structure for URLs. (Actually, URLs don't make such a requirement, they just don't guarantee that relative URLs work if you don't use it.) Larry   Received: from cnri by ietf.org id aa19199; 27 Dec 96 11:54 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa11571; 27 Dec 96 11:54 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA13627 for uri-out; Fri, 27 Dec 1996 11:41:31 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA13607; Fri, 27 Dec 1996 11:40:43 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22473 (mail destined for uri@services.bunyip.com); Fri, 27 Dec 96 11:40:37 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 27 10:39 CST 1996 Message-Id: <32C3FBD2.7FA0@ds.internic.net> Date: Fri, 27 Dec 1996 10:39:46 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Larry Masinter Cc: uri@bunyip.com, urn-ietf@bunyip.com Subject: Re: Comments on url-syntax-draft... References: <96Dec26.231820pdt."248"@palimpsest.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-uri@bunyip.com Precedence: bulk Larry Masinter wrote: > > Ryan, > > I don't think we intend for 'a:b:c:d' to be parsed as belonging to > scheme 'a:b:c', so I think we should fix the regular expression in > appendix B to treat 'urn:isbn:1-32456-78902-X' as belonging to > scheme 'urn' and not scheme 'urn:isbn'. > > I don't know how to proceed on the issue of changing the URL draft to > describe URNs and URN parsing. I think if we're going to proceed from > Proposed Standard to Draft Standard that we are not supposed to add > functionality, and that the only changes we can make are those that > are consistent with current practice. In my mind you have two options: (1) Delete the text in Section 1.1 relating to URNs and URIs or (2) Change the Appendixes and elsewhere to fix the problem above. I forsee problems in the URL draft with any potential "meta-scheme", an example of which is providing checksums for a URx if it maintains its current section 1.1 language. The point is that the current draft is unacceptable in its making a statement about URNs without realizing that URNs are a superset of URLs and should not be bound by the URL syntax (in fact one could argue the reverse). > I don't know why URNs don't require any determinist structure to URNs > while it seemed important that URLs require such a structure for URLs. One reason is that URNs are more general than URLs. Another is that URN syntax pushes the deterministic structure off to the namespace resolver. Another is that URLs are inherently tied to the underlying filesystem structure. There are more, but this should be a start. > (Actually, URLs don't make such a requirement, they just don't > guarantee that relative URLs work if you don't use it.) ??? I don't see this. I see that absolute URLs have a definite structured syntax throughout the draft. Ryan   Received: from cnri by ietf.org id aa09678; 28 Dec 96 4:55 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa05050; 28 Dec 96 4:55 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA29006 for uri-out; Sat, 28 Dec 1996 04:37:39 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA29000; Sat, 28 Dec 1996 04:37:37 -0500 Received: from paris.ics.uci.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25738 (mail destined for urn-ietf@services.bunyip.com); Sat, 28 Dec 96 04:37:35 -0500 Received: from liege.ics.uci.edu by paris.ics.uci.edu id aa05581; 28 Dec 96 1:30 PST To: Ryan Moats Cc: uri@bunyip.com, urn-ietf@bunyip.com Subject: Re: Comments on url-syntax-draft... In-Reply-To: Your message of "Fri, 27 Dec 1996 10:39:46 CST." <32C3FBD2.7FA0@ds.internic.net> Date: Sat, 28 Dec 1996 01:30:19 -0800 From: "Roy T. Fielding" Message-Id: <9612280130.aa05581@paris.ics.uci.edu> Sender: owner-uri@bunyip.com Precedence: bulk > I forsee problems in the URL draft with any potential "meta-scheme", > an example of which is providing checksums for a URx if it maintains > its current section 1.1 language. I see no such problems. For one thing, there is no such thing as a "meta-scheme" which would have separate requirements from any "normal" scheme. If it can't be parsed by the generic-URL syntax, then it can't be used in any context in which URLs are found, which would place it well outside the bounds of the URN charter's definition of URNs. > The point is that the current draft is unacceptable in its making a > statement about URNs without realizing that URNs are a superset of URLs > and should not be bound by the URL syntax (in fact one could argue the > reverse). Both points are in error. URNs are not a superset of URLs -- both are subsets of URI. There does not exist a URN that cannot be *parsed* as a URL. In fact, the URL syntax is much less restrictive than the proposed URN syntax. Claims that such a URI syntax is "too restrictive" are not useful without an example of a legal URN which would be disallowed by the URL syntax. Personally, I have yet to even imagine one. > One reason is that URNs are more general than URLs. How so? > Another is that > URN syntax pushes the deterministic structure off to the namespace > resolver. No it doesn't. In order to parse a URN, you need to know where it begins and where it ends. That is the definition of an opaque URI. > Another is that URLs are inherently tied to the underlying > filesystem structure. That is totally misinformed -- there is nothing in an http URL which is inherently tied to any filesystem, and the same goes for news, mid, cid, telnet, wais, etc. The URL document contains the wording about URI in general because there currently does not exist a standard reference for URI, which is the thing that HTTP and HTML use in references. Without that wording, the HTML and HTTP specifications will have to restrict themselves to using URLs, thus making an artificial distinction created for political reasons part of the official standard. Since I assume you want to actually use URNs in HTML and HTTP and other areas where URLs are currently found (I certainly do), it would be pretty stupid for us to remove any mention of the URI syntax from the URL standard. Waiting for URNs to achieve the same standard status as URLs is not reasonable. I included only the most basic of requirements in defining the URI syntax. If the URN WG cannot live with the requirements as stated, then I cannot possibly imagine that URNs can be used in the ways intended by your own requirements documents. But that can't be the case, since your own syntax document is *more* restrictive than the URL spec. I can only assume that you need to read it again and point the actual problems and not presuppositions. ....Roy   Received: from cnri by ietf.org id aa25566; 29 Dec 96 14:56 EST Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa12508; 29 Dec 96 14:56 EST Received: (from majordomo@localhost) by academ2.academ.com (8.8.4/8.7.3) id NAA08055 for ietf-nntp-outgoing; Sun, 29 Dec 1996 13:53:09 -0600 (CST) X-Authentication-Warning: academ2.academ.com: majordomo set sender to owner-ietf-nntp using -f Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by academ2.academ.com (8.8.4/8.7.3) with ESMTP id NAA08050 for ; Sun, 29 Dec 1996 13:53:07 -0600 (CST) Received: from lyra.csx.cam.ac.uk (news@lyra.csx.cam.ac.uk [131.111.8.36]) by academ.com (8.8.4/8.7.1) with SMTP id NAA08420 for ; Sun, 29 Dec 1996 13:53:05 -0600 (CST) Received: by lyra.csx.cam.ac.uk (SMI-8.6/MDTG-V1.1.8@lyra.csx.cam.ac.uk) id TAA20939; Sun, 29 Dec 1996 19:52:47 GMT Message-Id: <199612291952.TAA20939@lyra.csx.cam.ac.uk> Subject: Re: ietf-nntp New wording on article numbers To: Chris Hall Date: Sun, 29 Dec 1996 19:52:46 +0000 (GMT) Cc: ietf-nntp@academ.com In-Reply-To: from "Chris Hall" at Dec 29, 96 06:58:26 pm From: USENET news manager X-Mailer: ELM [version 2.4 PL22] Content-Type: text Sender: owner-ietf-nntp@academ.com Precedence: bulk Chris Hall wrote: > >In article <851804656.27539.0@office.demon.net>, "Clive D.W. Feather" > writes >>Jeff Coffler said: >>> I can guarentee consistent behavior >>> for commands like LAST, NEXT, and ARTICLE commands (if the "current" >>> article number would go out of range of my saved values, then I will >>> give an appropriate response code). >>> >>> Now, we can't require this (since it wasn't in the original spec, and >>> since many servers today don't enforce this), but: shouldn't we recommend >>> this behavior (so that, at least if recommendations are followed, NNTP >>> behavior is nice and consistent across commands)? > >>For my next draft, I've added wording to NEXT saying: >> >> A server MIGHT, but SHOULD NOT return an article number greater than >> the "last" value from the most recent GROUP command for this client. >> >>How does this look to people ? > >And similar words for LAST, I assume, to cope with the case of an >article being reinstated ! That all sounds reasonable, but the reference to "consistent behaviour" is misleading - consistent in the sense that LAST/NEXT wouldn't exceed the range returned by GROUP, but I don't see that as very useful when (for example) five NEXT commands and then five LAST commands may see very different sets of articles due to cancellation or expiry. To a client, seeing a consistent set of articles when moving to and fro (which is unrealistic) would be far more useful! >If LAST and NEXT are allowed to wander outside the range "first".."last" >returned by GROUP, then the "arts" figure returned by GROUP could be >exceeded -- which is a bit chewy. Mind you, I don't see much use for >the "arts" figure. I may be wrong, but it seems unlikely (to me) that clients which (for example) allocate arrays sized according to the article number estimate would then use LAST/NEXT to find articles rather than XOVER and ARTICLE, etc. Indeed, with the trend to threaded newsreaders I can't see many uses for LAST/NEXT (for online reading, maybe useful for "suck feed" implementation). >For clients that remember the state of newsgroups, it's the value of >"last" that matters, so that each time the client looks at a newsgroup >it doesn't need to worry about stuff from the previous highest article >number back. The client can do that using the previous "last" figure, >so the suggested recommendation is helpful. However, since this cannot >be depended on, the client is wiser to note the article number returned >by the last ARTICLE, BODY or HEAD command. If the client is using NEXT, then the highest article number actually seen is the appropriate one to record - no assumptions can be made about higher numbered articles, and it might be higher than GROUP returned. If the client is using XOVER and ARTICLE (with article number), etc., then the highest article seen (for example) in the XOVER data is the relevant one. In either case, of course, the client is likely to record rather more information, typically which articles have been read, and articles before the high article seen in an earlier session may well still be relevant if they are not yet marked as read. A client using NEXT could always ignore an article received with a higher article number than expected, and stop NEXTing. Mmm... in spite of saying, above, that the recommendation seems reasonable, I'm now starting to wonder about that. If it's only a recommendation, clients still have to cope with servers NEXTing to articles beyond those mentioned by GROUP. It can't be mandatory since it conflicts with existing implementations. Therefore - are there any situations where there would be any significant benefits from limiting the LAST/NEXT range to match the range from GROUP (given that it's trivial for the client to behave as though the server had done it)? John Line -- Cambridge University Computing Service - USENET news manager. Usually John Line newsmaster@ucs.cam.ac.uk (alias {newsmaster,news,usenet}@news.cam.ac.uk)   Received: from cnri by ietf.org id aa26646; 29 Dec 96 15:30 EST Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa13005; 29 Dec 96 15:29 EST Received: (from majordomo@localhost) by academ2.academ.com (8.8.4/8.7.3) id OAA08163 for ietf-nntp-outgoing; Sun, 29 Dec 1996 14:26:10 -0600 (CST) X-Authentication-Warning: academ2.academ.com: majordomo set sender to owner-ietf-nntp using -f Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by academ2.academ.com (8.8.4/8.7.3) with ESMTP id OAA08158 for ; Sun, 29 Dec 1996 14:26:07 -0600 (CST) Received: from lyra.csx.cam.ac.uk (news@lyra.csx.cam.ac.uk [131.111.8.36]) by academ.com (8.8.4/8.7.1) with SMTP id OAA08611 for ; Sun, 29 Dec 1996 14:26:05 -0600 (CST) Received: by lyra.csx.cam.ac.uk (SMI-8.6/MDTG-V1.1.8@lyra.csx.cam.ac.uk) id UAA21882; Sun, 29 Dec 1996 20:26:00 GMT Message-Id: <199612292026.UAA21882@lyra.csx.cam.ac.uk> Subject: Re: ietf-nntp Issue: reinstatement To: Chris Hall Date: Sun, 29 Dec 1996 20:26:00 +0000 (GMT) Cc: ietf-nntp@academ.com In-Reply-To: from "Chris Hall" at Dec 29, 96 06:58:07 pm From: USENET news manager X-Mailer: ELM [version 2.4 PL22] Content-Type: text Sender: owner-ietf-nntp@academ.com Precedence: bulk Chris Hall wrote: >In article <851805333.28095.0@office.demon.net>, "Clive D.W. Feather" > writes >>[clarification about intended meaning of backfilling] >> >>My definition of reinstatement: an article is removed (either because of a >>cancel or expiry), and then the server operator decides that this removal >>was an error and reinstates the article *with the same number*. >> >>In earlier discussion, I was under the impression that people wanted to >>allow this behaviour; the alternative is to state explicitly that, once an >>article has been removed, it will never reappear. > >Which seems unnecessarily severe. > >>Jon Ribbens: >>>... >>> Even if you do want >>> this stuff in, I don't see a need for the condition that the article >>> number MUST be no less than the first article number. > >>Without that condition, the low water mark might decrease. Everyone was >>against that. > >If the minimum article number is never to decrease, then it's not >possible in every case to reinstate an article -- it's obviously not >possible to reinstate an article that had the previous minimum article >number [unless it can be guaranteed that no client ever said GROUP >between the removal and the reinstatement !]. > >Either one lives with the curious limitation on reinstatement, or one of >reinstatement or increasing minimum article number has to go. > >What difference does it make if the "first" article number in one GROUP >command is less than it was in the previous GROUP command ? I can't see that it's a problem, as long as it happens only for reinstatement of a previously-existing article with its original article number - as a more-or-less rare event, done to reduce the impact of (e.g.) malicious cancels, not to add new articles which some readers would miss. >From the client's perspective the only thing that matters is that new >articles available from the server have higher article numbers than old >articles. So the client can, *without* missing articles, start from the >highest article number it saw last time (provided that is within the >"first".."last" range). That's the important distinction between the consequences of reinstatement and backfilling... >>I don't know what the concensus mechanism is for this list; when someone >>tells me we have a consensus one way or the other on this issue, I'll >>adjust the wording as needed. > >The choices appear to be: > > 1. ban reinstatement, >... > This doesn't seem right. Agreed. > 2. reinstate with its original article number, > > assuming there's some mechanism at the server to do that ! For > NEWNEWS purposes the article would have to be reinstated with its > original "timestamp". With INN, unless you'd run "makehistory" to rebuild the history database from the current spool contents in the meantime, the history entry (which includes the timestamps) will remain until the article would have expired (or possibly longer, for groups with very short expiry), so reinstating the article file should plus "ctlinnd renumber " should do it. [Just an example to show that it's not necessarily difficult to do.] > For clients that remember the state of newsgroups (eg. those that > use NEWNEWS), there is a problem here. Clients that look at a > group in the interval between removal and reinstatement may well > never see the article ! The longer the delay between removal and > reinstatement, the greater the number of people who will miss the > article. Yes, but if reinstatement is used only to minimise the effects of accidental or malicious loss, it will benefit those people who see the reinstated article, and the effect is no worse for others than if the article had not been reinstated. > Reinstatement is a subtle form of back-fill, against which faces > have been set. Yes and no... They have properties in common, but backfilling requires clients to locate newly arrived but lower-numbered articles or their users will see a very patchy feed, missing a lot of articles. Reinstatement is a "best efforts" fixup for loss of previously-existing articles. > 3. reinstate with a new article number (and new "timestamp"), > > which means that no client should miss the article, but some may > see the article twice ! > > Duplicating articles is anathema. Nevertheless, I expect clients > cover themselves against it, and simply ignore duplicates. But, if > the delay between removal and reinstatement is long, then there is > the risk that the client has expired its memory of the article-id, > and not be able to detect the duplication. Clients using article numbers wouldn't know if a reinstated article with a new number was a duplicate of one they'd shown the user previously (as when broken gateways spew duplicates with new message IDs). Clients (if there are any?) which saved message IDs for all articles seen recently (could be many megabytes) should be safe against duplicates, *except* that with a history database (underlying lookup by message ID, and NEWNEWS) like INN's, articles reinstated with a different article number could not be added to the history database in any straightforward and non-disruptive way, and it would retain the original details including article file number (hence also number) - so the reinstated article would never be seen (and the reinstated article would never be expired, since the history database is used by expiry to derive the list of files to unlink). >Looks like a choice between evils to me :-(. For anyone using INN, the choice is an easy one - reinstatement with the original article number is the only practical option! >If reinstating articles is a common requirement, then there is a serious >problem here. The client either has to be able to tolerate a form of >back-fill, or it has to tolerate duplicate articles. Only if you consider it essential for such articles never to be missed by clients, rather than viewing it as minimising the effects of losing the articles. Unless you could reinstate a copy of the article as it appeared on your server (and if it's been deleted, that would be fiddly), other problems could arise (e.g. Xref: header not matching reality on your server, Path: misleading, etc.) so it seems unlikely to be done very often, anyway. I've only ever needed to do it when something was posted in a local group which looked seriously inappropriate, when I mv'd it elsewhere until I'd checked that it was OK, then mv'd it back. John Line -- Cambridge University Computing Service - USENET news manager. Usually John Line newsmaster@ucs.cam.ac.uk (alias {newsmaster,news,usenet}@news.cam.ac.uk)   Received: from cnri by ietf.org id aa26284; 30 Dec 96 15:57 EST Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa17835; 30 Dec 96 15:57 EST Received: (from majordomo@localhost) by academ2.academ.com (8.8.4/8.7.3) id OAA11232 for ietf-nntp-outgoing; Mon, 30 Dec 1996 14:54:19 -0600 (CST) X-Authentication-Warning: academ2.academ.com: majordomo set sender to owner-ietf-nntp using -f Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by academ2.academ.com (8.8.4/8.7.3) with ESMTP id OAA11227 for ; Mon, 30 Dec 1996 14:54:13 -0600 (CST) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by academ.com (8.8.4/8.7.1) with ESMTP id OAA20203 for ; Mon, 30 Dec 1996 14:54:09 -0600 (CST) Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Mon, 30 Dec 1996 15:47:45 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Mon, 30 Dec 1996 15:47:45 -0500 Message-Id: <3.0.32.19961230155216.0076102c@lacroix> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 30 Dec 1996 15:52:16 -0500 To: Chris Hall , ietf-nntp@academ.com From: Jack De Winter Subject: Re: ietf-nntp New wording on article numbers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-nntp@academ.com Precedence: bulk >>Mmm... in spite of saying, above, that the recommendation seems reasonable, >>I'm now starting to wonder about that. If it's only a recommendation, >>clients still have to cope with servers NEXTing to articles beyond those >>mentioned by GROUP. > >....and yes, since the client cannot depend on the server not to step >NEXT beyond "last" (or LAST beyond "first"), then the client has to cope >whatever the RFC says. > >> It can't be mandatory since it conflicts with existing >>implementations. Therefore - are there any situations where there would be >>any significant benefits from limiting the LAST/NEXT range to match the >>range from GROUP (given that it's trivial for the client to behave as though >>the server had done it)? > >I understand that the objective is to tidy up the wording to reflect >reality, rather than tighten up the design. In that spirit one could >include two recommendations: My understanding is that we were supposed to make the 977bis reflect reality and fix any bugs that we have noticed since 977. Is this correct? For example, the AUTHINFO GENERIC is something that is not yet inreality, but it looks like current consensus is to move it towards John Meyer's SASL security spec. This is a 'it was not fully specified in 977, but we need to specify it now' thing. regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail(95/NT) (http://www.seattlelab.com/) and other great products.  1996-12.mail0000666000175200000100000103617211373051760011506 0ustar steveywww Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA29018 for urn-ietf-out; Sat, 28 Dec 1996 04:37:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA29000; Sat, 28 Dec 1996 04:37:37 -0500 Received: from paris.ics.uci.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25738 (mail destined for urn-ietf@services.bunyip.com); Sat, 28 Dec 96 04:37:35 -0500 Received: from liege.ics.uci.edu by paris.ics.uci.edu id aa05581; 28 Dec 96 1:30 PST To: Ryan Moats Cc: uri@bunyip.com, urn-ietf@bunyip.com Subject: [URN] Re: Comments on url-syntax-draft... In-Reply-To: Your message of "Fri, 27 Dec 1996 10:39:46 CST." <32C3FBD2.7FA0@ds.internic.net> Date: Sat, 28 Dec 1996 01:30:19 -0800 From: "Roy T. Fielding" Message-Id: <9612280130.aa05581@paris.ics.uci.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Roy T. Fielding" Errors-To: owner-urn-ietf@bunyip.com > I forsee problems in the URL draft with any potential "meta-scheme", > an example of which is providing checksums for a URx if it maintains > its current section 1.1 language. I see no such problems. For one thing, there is no such thing as a "meta-scheme" which would have separate requirements from any "normal" scheme. If it can't be parsed by the generic-URL syntax, then it can't be used in any context in which URLs are found, which would place it well outside the bounds of the URN charter's definition of URNs. > The point is that the current draft is unacceptable in its making a > statement about URNs without realizing that URNs are a superset of URLs > and should not be bound by the URL syntax (in fact one could argue the > reverse). Both points are in error. URNs are not a superset of URLs -- both are subsets of URI. There does not exist a URN that cannot be *parsed* as a URL. In fact, the URL syntax is much less restrictive than the proposed URN syntax. Claims that such a URI syntax is "too restrictive" are not useful without an example of a legal URN which would be disallowed by the URL syntax. Personally, I have yet to even imagine one. > One reason is that URNs are more general than URLs. How so? > Another is that > URN syntax pushes the deterministic structure off to the namespace > resolver. No it doesn't. In order to parse a URN, you need to know where it begins and where it ends. That is the definition of an opaque URI. > Another is that URLs are inherently tied to the underlying > filesystem structure. That is totally misinformed -- there is nothing in an http URL which is inherently tied to any filesystem, and the same goes for news, mid, cid, telnet, wais, etc. The URL document contains the wording about URI in general because there currently does not exist a standard reference for URI, which is the thing that HTTP and HTML use in references. Without that wording, the HTML and HTTP specifications will have to restrict themselves to using URLs, thus making an artificial distinction created for political reasons part of the official standard. Since I assume you want to actually use URNs in HTML and HTTP and other areas where URLs are currently found (I certainly do), it would be pretty stupid for us to remove any mention of the URI syntax from the URL standard. Waiting for URNs to achieve the same standard status as URLs is not reasonable. I included only the most basic of requirements in defining the URI syntax. If the URN WG cannot live with the requirements as stated, then I cannot possibly imagine that URNs can be used in the ways intended by your own requirements documents. But that can't be the case, since your own syntax document is *more* restrictive than the URL spec. I can only assume that you need to read it again and point the actual problems and not presuppositions. ....Roy Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA26807 for urn-ietf-out; Fri, 27 Dec 1996 22:58:02 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA26802 for ; Fri, 27 Dec 1996 22:58:00 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24750 (mail destined for urn-ietf@services.bunyip.com); Fri, 27 Dec 96 22:57:24 -0500 Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <16866(6)>; Fri, 27 Dec 1996 19:57:19 PST Received: by palimpsest.parc.xerox.com id <248>; Fri, 27 Dec 1996 19:57:08 PDT To: jayhawk@windrose.omaha.ne.us Cc: urn-ietf@bunyip.com In-Reply-To: <9612271934.AA23259@mocha.bunyip.com> (jayhawk@windrose.omaha.ne.us) Subject: Re: [URN] Re: Comments on url-syntax-draft... From: Larry Masinter Message-Id: <96Dec27.195708pdt."248"@palimpsest.parc.xerox.com> Date: Fri, 27 Dec 1996 18:57:08 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com URLs aren't required to be a slash-separated hierarchy of symbolic elements, it's just that relative URLs don't work with the ones that aren't. # If a namespace wants to define such a structure, that's OK. URLs (on # the other hand) do imply this structure across all non-opaque URL # schemes. Right. "urn:" can be thought of as an opaque URL scheme. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA17854 for urn-ietf-out; Fri, 27 Dec 1996 14:34:44 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA17847 for ; Fri, 27 Dec 1996 14:34:41 -0500 From: jayhawk@windrose.omaha.ne.us Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23259 (mail destined for urn-ietf@services.bunyip.com); Fri, 27 Dec 96 14:34:39 -0500 Message-Id: <9612271934.AA23259@mocha.bunyip.com> Date: Fri, 27 Dec 96 13:33 CST To: urn-ietf@bunyip.com Subject: [URN] Re: Comments on url-syntax-draft... References: <01IDI6JYSI8O003M9A@SCI.WFBR.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1684 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: jayhawk@windrose.omaha.ne.us Errors-To: owner-urn-ietf@bunyip.com Foteos Macrides wrote: > > Ryan Moats wrote: > >[..] > >One reason is that URNs are more general than URLs. Another is that > >URN syntax pushes the deterministic structure off to the namespace > >resolver. Another is that URLs are inherently tied to the underlying > >filesystem structure. There are more, but this should be a start. > >[...] > > I don't understand your claim that URLs are inherently tied > to the underlying filesystem strucure. The path field in a generic > URL is a "slash-separated hierarchy of symbolic elements" (*not* Unix > filesystem paths 8-). Each "symbolic element" and/or the overall > path field can have mappings to the the local filesystem structure, > (e.g., by server mappings and/or local system enviroment variables or > symbolic links) but the URL syntax, itself, is platform/filesystem > independent. I'll grant your point for the sake of argument (I don't necessarily agree with it, as I never said UNIX%C2%AE), but the point of prime importance (from my previous discussion) is EXACTLY that 'The path field in a generic URL is a "slash-separated hierarchy of symbolic elements."' It is this hierarchy (or, otherwise put, implied structure) that is one of the major (IMO) syntactical differences between URNs and URLs. URNs should not (and currently do not) impose such structure across all namespaces. If a namespace wants to define such a structure, that's OK. URLs (on the other hand) do imply this structure across all non-opaque URL schemes. Removing that argument from the above discussion by no means changes my assertion that URNs and URLs should have different syntactical structure. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA13612 for urn-ietf-out; Fri, 27 Dec 1996 11:40:45 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA13607; Fri, 27 Dec 1996 11:40:43 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22473 (mail destined for uri@services.bunyip.com); Fri, 27 Dec 96 11:40:37 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 27 10:39 CST 1996 Message-Id: <32C3FBD2.7FA0@ds.internic.net> Date: Fri, 27 Dec 1996 10:39:46 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Larry Masinter Cc: uri@bunyip.com, urn-ietf@bunyip.com Subject: [URN] Re: Comments on url-syntax-draft... References: <96Dec26.231820pdt."248"@palimpsest.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Larry Masinter wrote: > > Ryan, > > I don't think we intend for 'a:b:c:d' to be parsed as belonging to > scheme 'a:b:c', so I think we should fix the regular expression in > appendix B to treat 'urn:isbn:1-32456-78902-X' as belonging to > scheme 'urn' and not scheme 'urn:isbn'. > > I don't know how to proceed on the issue of changing the URL draft to > describe URNs and URN parsing. I think if we're going to proceed from > Proposed Standard to Draft Standard that we are not supposed to add > functionality, and that the only changes we can make are those that > are consistent with current practice. In my mind you have two options: (1) Delete the text in Section 1.1 relating to URNs and URIs or (2) Change the Appendixes and elsewhere to fix the problem above. I forsee problems in the URL draft with any potential "meta-scheme", an example of which is providing checksums for a URx if it maintains its current section 1.1 language. The point is that the current draft is unacceptable in its making a statement about URNs without realizing that URNs are a superset of URLs and should not be bound by the URL syntax (in fact one could argue the reverse). > I don't know why URNs don't require any determinist structure to URNs > while it seemed important that URLs require such a structure for URLs. One reason is that URNs are more general than URLs. Another is that URN syntax pushes the deterministic structure off to the namespace resolver. Another is that URLs are inherently tied to the underlying filesystem structure. There are more, but this should be a start. > (Actually, URLs don't make such a requirement, they just don't > guarantee that relative URLs work if you don't use it.) ??? I don't see this. I see that absolute URLs have a definite structured syntax throughout the draft. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id CAA08662 for urn-ietf-out; Fri, 27 Dec 1996 02:19:14 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id CAA08645; Fri, 27 Dec 1996 02:18:36 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21422 (mail destined for urn-ietf@services.bunyip.com); Fri, 27 Dec 96 02:18:34 -0500 Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <16709(4)>; Thu, 26 Dec 1996 23:18:30 PST Received: by palimpsest.parc.xerox.com id <248>; Thu, 26 Dec 1996 23:18:20 PDT To: jayhawk@ds.internic.net Cc: uri@bunyip.com, urn-ietf@bunyip.com In-Reply-To: <32C290D3.790B@ds.internic.net> (message from Ryan Moats on Thu, 26 Dec 1996 06:50:59 PST) Subject: [URN] Re: Comments on url-syntax-draft... From: Larry Masinter Message-Id: <96Dec26.231820pdt."248"@palimpsest.parc.xerox.com> Date: Thu, 26 Dec 1996 22:18:20 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com Ryan, I don't think we intend for 'a:b:c:d' to be parsed as belonging to scheme 'a:b:c', so I think we should fix the regular expression in appendix B to treat 'urn:isbn:1-32456-78902-X' as belonging to scheme 'urn' and not scheme 'urn:isbn'. I don't know how to proceed on the issue of changing the URL draft to describe URNs and URN parsing. I think if we're going to proceed from Proposed Standard to Draft Standard that we are not supposed to add functionality, and that the only changes we can make are those that are consistent with current practice. I don't know why URNs don't require any determinist structure to URNs while it seemed important that URLs require such a structure for URLs. (Actually, URLs don't make such a requirement, they just don't guarantee that relative URLs work if you don't use it.) Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA21562 for urn-ietf-out; Thu, 26 Dec 1996 13:21:21 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA21555 for ; Thu, 26 Dec 1996 13:21:18 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18793 (mail destined for urn-ietf@services.bunyip.com); Thu, 26 Dec 96 13:21:12 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <18710-0@josef.ifi.unizh.ch>; Thu, 26 Dec 1996 19:21:05 +0100 Date: Thu, 26 Dec 1996 19:21:03 +0100 (MET) From: "Martin J. Duerst" To: Ryan Moats Cc: Dirk.vanGulik@jrc.it, urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: <32BED0A0.5215@ds.internic.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Mon, 23 Dec 1996, Ryan Moats wrote: > Dirk.vanGulik@jrc.it wrote: > > Ok, here is a real example; P-R document references; > > > > Country They type (the keys/display on the screen) > > France #PEL/77124 > > UK *PEL/77124 (Where the * is the oblique L > > pound sign) > > Greece $PEL/77l24 (Note the 'l' instead of '1') > > Holland FlPEL/77l24 (Where fl is the florin symbol) > > > > Luckily however the _wire_ format is perfectly sensible and > > the same; But the fun bit is that they all happily print and > > fax each other those references; and all know how to cope > > with them just fine :-) > > > > The point I am trying to make is that for some namespaces to > > be grandfathered in have a stronger relation to their wire > > octed stream than to the glyph/symbolic representation; so for > > those you really want to ignore all you learned about really > > neat UTF8 symbol encoding :-) Yes, this is true. I proposed some text to take this into account. But for the examples above, I guess there are other possibilities. First, note that the "1" vs. "l" issue is really just a glyph issue, it's a difference you see frequently between Europe and the US, for example. Only the #/*/$/Fl is an octet issue. For this, just taking the octet representation (# and * suggest it's %23, but I might be wrong), resulting in urn:vangulikexample:%24PEL/77124, is one solution. Because this happens to be a valid UTF-8 sequence, URN interfaces may display that as #PEL/77124 or as %24PEL/77124. Another is the one I have mentionned earlier, and which Ryan gives the details below, namely accepting all different "spellings" and defining namespacesspecific equivalence between them. This works as long as there is no character that can lead to different octets in different countries. It looks like this is not the case for the example above, as otherwise faxes would lead to heavy confusion. Another solution might be to drop the initial letter altogether, leading to PEL/77124. This works in particular if the initial letter is the same all the time and serves as a kind of namespace identificator that would be replaced by the NIS anyway. Another solution might be to decide on a new or improved scheme for numbering for the first letter, e.g. replacing all the above with "@" or "X" or whatever. The best solution really depends on all kinds of details, and is up to those that are responsible for the namespace. All solutions are possible within the current syntax draft. The first solution is the most technical, easiest to interface with the current system. The others are more human- and future-oriented. While it is true that humans can easily deal with the current #/*/$/Fl mess, it should be clearly noted that this is an artefact produced by limitations of early computers, and there is no strong reason to perpetuate it. > I think somebody is confused (probably me), but I don't see what the > problem with this example is. All of those P-R document references > do not have to map to the same URN. In fact, based on how they are > described above, the shouldn't. Rather, the namespace that holds > the above resource (call it foobar), will have the following > 4 URNs (I'll probably get this wrong, bear with me): > > urn:foobar:%23PEL/77124 > urn:foobar:%C2%A3PEL/77124 > urn:foobar:%24PEL/77l24 > urn:foobar:%E0%86%92PEL/77l24 > > My main point having gotten here is this: > > It's up to the namespace resolver for foobar to understand that these > may all refer to the same resource, not the syntax. Therefore > "wire-coding should be more important that glyph/symbolic > representation" becomes a resolver issue, not a syntax issue. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA16652 for urn-ietf-out; Thu, 26 Dec 1996 09:51:59 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA16647; Thu, 26 Dec 1996 09:51:56 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18416 (mail destined for uri@services.bunyip.com); Thu, 26 Dec 96 09:51:52 -0500 Received: by privateer.windrose.omaha.ne.us; Thu Dec 26 08:51 CST 1996 Message-Id: <32C290D3.790B@ds.internic.net> Date: Thu, 26 Dec 1996 08:50:59 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Larry Masinter Cc: uri@bunyip.com, urn-ietf@bunyip.com Subject: [URN] Comments on url-syntax-draft... References: <96Dec26.011608pst."2694"@golden.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Larry- I've looked through your new draft especially with a view to meshing with the URN syntax and I still have two major issues. Fortunately, I believe that a single solution will handle both. I also have an editorial issue. Once these are taken care of, I believe that both drafts have been aligned on this issue. 1. Given the current URN spec, the "greedy" algorith in Appendix B will pick up the urn scheme as "urn:". For example the URN urn:isbn:1-32456-78902-X will be parsed as being scheme "urn:isbn". 2. There is no general specification of structure for a URN NSS, it is determined on a namespace by namespace basis. I can see two solutions to item 1: (a) modify the scheme syntax in Section 4.1 to include ":" or (b) add a section for URN handling that states that a scheme including the "urn:" token should be treated as an opaque URL because it is really a URN. I propose that option (b) be followed because the easiest solution to item 2 is for the URL parser to declare a URN as an "opaque-URL" and do no processing on it. This would ensure that the NSS structure doesn't confuse the URL parser. I believe that an appendix for this would work the best, and I add it below... My editorial issue is that the section paragraph in section 1.1 is potentially confusing. There are requirements in the URL syntax that do not apply to the URN syntax. I would prefer to see the following paragraph in its place: "This specification restricts its discussion to URLs. URN syntax is specified in [URN Syntax Ref]. URN and URL syntax have been specified so that a URN may be used in any data field that might otherwise hold a URL. Details of how to handle a URN are provided in Appendix X." Ryan Moats =======================Appendix on URN handling in a URL parser Appendix X. URN Handling in URL parsers URN syntax is specified in [URN Syntax Ref]. URNs include a leading tag "urn:". Thus, the "greedy" algorithm in Appendix B will return a scheme that includes this tag. In addition, URNs do not require any determinist strcuture to the URN. Rather, this is assigned on a namespace-by-namespace basis. To enable a URL parser to handle a URN properly, A URL parser that detects a scheme that includes the "urn:" tag MUST treat the URL as an opaque URL to be handed to a URN resolver for further processing. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA16641 for urn-ietf-out; Thu, 26 Dec 1996 09:51:48 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA16634 for ; Thu, 26 Dec 1996 09:51:44 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18412 (mail destined for urn-ietf@services.bunyip.com); Thu, 26 Dec 96 09:51:38 -0500 Received: by privateer.windrose.omaha.ne.us; Thu Dec 26 08:50 CST 1996 Message-Id: <32C290CE.2193@ds.internic.net> Date: Thu, 26 Dec 1996 08:50:54 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: urn-ietf@bunyip.com Subject: [URN] Second pre-release of 3rd syntax draft. Content-Type: multipart/mixed; boundary="------------76D545817A4" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com This is a multi-part message in MIME format. --------------76D545817A4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Howdy, everybody- As promised, here is the second pre-release of the 3rd syntax draft (-02). Changes from the previous pre-release: 1. Added a paragraph on the "%" character to align with the URL syntax and clear up misconceptions about its presence in the URL character set. 2. Moved the "\" character to the excluded character set. This also aligns the URN syntax with the URL syntax The current schedule is to send this to the I-D editors 1/6/97. Have a happy new year! Ryan --------------76D545817A4 Content-Type: text/plain; charset=us-ascii; name="urn.syntax.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="urn.syntax.txt" Internet-Draft Ryan Moats draft-ietf-urn-syntax-02.txt AT&T Expires in six months December 1996 URN Syntax Filename: draft-ietf-urn-syntax-02.txt Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers. This document sets forward the canonical syntax for URNs. Support for both existing legacy and new namespaces is discussed. Requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. 1. Introduction Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space. The URN syntax therefore provides a means to encode character data in a form that can be sent in existing protocols, transcribed on most keyboards, etc. Expires 5/19/97 [Page 1] INTERNET DRAFT URN Syntax December 1996 2. Syntax All URNs have the following syntax: ::= "urn:" ":" is the Namespace Identifier, and is the Namespace Specific String. The leading case-insensitive "urn:" sequence is required. The Namespace ID is used to determine the _syntactic_ interpretation of the Namespace Specific String (as discussed in [1]). RFC 1737 [2] presents additional requirements on URN encoding, which all have implications as far as limiting syntax. On the other hand, the requirement to support existing legacy naming systems has the effect of broadening syntax. Thus, we discuss the acceptable syntax for both the Namespace Identifier and the Namespace Specific String separately. 2.1 Namespace Identifier Syntax The following is the syntax for the Namespace Identifier. To (a) be consistent with all potential resolution schemes and (b) not put any undue constraints on any potential resolution scheme, the syntax for the Namespace Identifier is: ::= [ * ] ::= | | | "-" ::= | | ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" This is slightly more restrictive that what is stated in [3] (which Expires 5/19/97 [Page 2] INTERNET DRAFT URN Syntax December 1996 allows the characters "." and "+"). Further, the Namespace Identifier is case insensitive, so that "ISBN" and "isbn" refer to the same namespace. To avoid confusion with the "urn:" identifier, the NID "urn" is reserved and MUST NOT be used. 2.2 Namespace Specific String Syntax As required by 1737, there is a single canonical representation of the NSS portion of an URN. The format of this single canonical form follows: ::= 1* ::= | "%" ::= | | | ::= | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" ::= "(" | ")" | "+" | "," | "-" | "." | "/" | ":" | "=" | "?" | "@" | "%" Depending on the rules governing a namespace, valid identifiers in a namespace might contain characters that are not members of the URN character set above (). Such strings MUST be translated into canonical NSS format before using them as protocol elements or otherwise passing them on to other applications. Translation is done by encoding each character outside the URN character set as a sequence of one to six octets using UTF-8 encoding, and the encoding of each of those octets as "%" followed by two characters from the character set above. The two characters give the hexadecimal representation of that octet. The "%" character is reserved in the URN syntax for introducing the escape sequence for an octet. Literal use of the "%" character in a namespace must be encoded using "%25" in URNs for that namespace. The prescence of an "%" character in a URN MUST be followed by two characters from the character set. Namespaces MAY designate one or more characters from the URN character set as having special meaning for that namespace. If the namespace also uses that character in a literal sense as well, the character used in a literal sense MUST be encoded with "%" followed by the hexadecimal representation of that octet. Therefore, the process of registering a namespace identifier shall include Expires 5/19/97 [Page 3] INTERNET DRAFT URN Syntax December 1996 publication of a definition of which characters have a special meaning to that namespace. 2.3 Excluded characters The following list is included only for the sake of completeness. Any octets/characters on this list are explicitly NOT part of the URN character set, and if used in a URN, MUST be %encoded: ::= octets 0-32 (0-20 hex) | "\" | "!" | """ | "#" | "$" | "&" | "'" | "*" | ";" | "<" | ">" | "[" | "]" | "^" | "_" | "`" | "{" | "|" | "}" | "~" | octets 127-255 (7F-FF hex) A URN ends when an octet/character from the excluded character set () is encountered. The character from the excluded character set is NOT part of the URN. 3. Support of existing legacy naming systems and new naming systems Any namespace (existing or newly-devised) that is proposed as a URN- namespace and fulfills the criteria of URN-namespaces MUST be expressed in this syntax. If names in these namespaces contain characters other than those defined for the URN character set, they MUST be translated into canonical form as discussed in section 2.2. 4. URN presentation and transport URN-aware applications MAY support "natural" display of URNs which contain characters encoded using "%" notation. However, they MUST provide for display of URNs in canonical form (i.e. in a format suitable for transcription). URNs MUST be transported in canonical format. 5. Lexical Equivalence in URNs For various purposes, such as caching, it is necessary to determine equivalence without actually resolving the URN. This done by testing for "lexical equivalence". Two URNs are lexically equivalent if they are octet-by-octet equal after the following preprocessing 1. normalize the case of the leading "urn:" token 2. normalize the case of the NID 3. normalizing the case of any "%" escaping Some namespaces may define additional lexical equivalences, such as case-insensitivity of the NSS (or parts thereof). Additional lexical Expires 5/19/97 [Page 4] INTERNET DRAFT URN Syntax December 1996 equivalences MUST be documented as part of namespace registration, MUST always have the effect of eliminating some of the false negatives obtained by the procedure above, and MUST NEVER say that two URNs are not equivalent if the procedure above says they are equivalent. 6. Functional Equivalence in URNs Functional equivalence is determined by URN resolvers and is therefore outside the scope of this document. Namespace registration MUST include documentation on how to determine functional equivalence for that namespace. 7. Examples of equivalence The following URN comparisons highlight the difference between these types of equivalence: urn:isbn:1-23485-8-29, urn:isbn:1-23485-8-29 are lexically equiv. urn:isbn:1-23485-8-29, URN:ISBN:1-23485-8-29 are lexically equiv. urn:isbn:1-23485-8-29, urn:isbn:123485829 are not lexically equiv. but may be functionally equivalent. 8. Security considerations This document specifies the syntax for URNs. While some namespaces resolvers may assign special meaning to certain of the characters of the Namespace Specific String, any security consideration resulting from such assignment are outside the scope of this document. It is strongly recommended that the process of registering a namespace identifier include any such considerations. 9. Acknowledgments Thanks to various members of the URN working group and <> for comments on earlier drafts of this document. This document is partially supported by the National Science Foundation, Cooperative Agreement NCR-9218179. 10. References Request For Comments (RFC) and Internet Draft documents are available from and numerous mirror sites. [1] K. R. Sollins. "Requorements and a Framework for URN Resolution Systems" Internet Draft (work in progress). November 1996. Expires 5/19/97 [Page 5] INTERNET DRAFT URN Syntax December 1996 [2] K. Sollins, L. Masinter. "Functional Requirements for Uniform Resource Names," RFC 1737. December 1994. [3] T. Berners-Lee, R. Fielding, L. Masinter. "Uniform Resource Locators (URL)," Internet Draft (work in progress). December 1996. 11. Editor's address Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA Phone: +1 402 894-9456 EMail: jayhawk@ds.internic.net This Internet Draft expires May 19, 1997. Expires 5/19/97 [Page 6] --------------76D545817A4-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA04975 for urn-ietf-out; Mon, 23 Dec 1996 13:41:39 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA04964 for ; Mon, 23 Dec 1996 13:41:36 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07581 (mail destined for urn-ietf@services.bunyip.com); Mon, 23 Dec 96 13:41:20 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id NAA01369; Mon, 23 Dec 1996 13:41:18 -0500 Message-Id: <199612231841.NAA01369@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Mon, 23 Dec 1996 13:41:16 -0500 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: minutes@ietf.org Subject: [URN] Re: DRAFT URN Meeting Minutes Cc: jcurran@bbn.com, urn-ietf@bunyip.com, hta@uninett.no, moore@cs.utk.edu Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Minutes of the URN Working Group 37th IETF, San Jose, December 12, 1996 Group Co-Chairs: Leslie Daigle, leslie@bunyip.com John Curran, jcurran@bbn.com Minute-Meister: Sally Hambridge, Intel Leslie opened the meeting by reviewing the Charter and Milestones. Hot Spots in the milestones are: we lack a draft detailing N2L/N2R/etc resolution results. We will probably use Ron Daniel's HTTP conventions draft as a start on this milestone. We also need to submit a document describing one new namespace and a document which describes grandfathering in older naming schemes, as well as the Frameworks and Requirements draft. Karen Sollins presented the open issues with the current Frameworks and Requirements document: The document discusses the assumptions of longevity, delegation, and independence. The requirements fall in 3 major areas: Evolution, Usability, and Security. The framework looks like this: URN: | | Global NID registry | | | | | Private URN resolution service UDS server | | Private URN resolution service Karen includes a definition section which defines Local Resolution service - what transforms URNs into access to resources; Hints - information that helps to access the information; UDS - URN Resolution Service Discovery Service - how to find the right URN resolution service; HFN - Human friendly names. The Security area will discuss access control on hints; server authenticity; Server distribution (a countermeasure on denial of service attacks) and Privacy - the users from resolution services and for publishers for their clients and publications lists. Issues: - Encouragement of separation of URNs from semantics - Efficiency as a goal or a requirement is in several places (documents) which need to be aggregated. - Whether there is a useful distinction to be made between long- term and short-term hints - Acceptance by potential providers of UDS services. Karen asked what's missing from the list of issues: Internationalization (i18n) should be covered one way or another. Name space ID - needs to be in a document but probably not this document. Ryan Moats presented the issues with the URN syntax ID: URN: should this be optional. Please see the later discussion on this for the consensus. NID syntax: Why not use numbers and "-". No reason - Ryan will change the draft. There was a suggestion for following the RFC for URLs on this, but it was pointed out that this document is currently undergoing a revision. NID namespace will have case insensitivity and add %escaping. The NSS may be case sensitive. URN Character set adds/deletes: Add "%" to the allowed character set and add a list of characters NOT part of the set to the draft. %escaping: Will be allowed for escaping of reserved characters in addition to characters outside the URN character set; and allow for %HH escaping to use either upper or lower case. Where does a URN end? At the first non-URN character set character. Equivalency: Are things the same when they point to the same resource? (Equivalency of resources was deemed to be a rathole). Leslie offered that a URN could point to a specific day's weather and another could refer to today's weather, and these were pointing to the same thing but were not equivalent. ROUGH CONSENSUS was reached that ONLY lexical equivalency will be covered in the draft. Each namespace may have its own rules. For the Human readability - MUST/SHOULD the following text is being substituted: Any namespace (existing or newly-devised) that is proposed as a URN-namespace must be expressed in this syntax. If names in these namespaces contain characters other than those defined for the URN character set they must be translated into canonical form as discussed in section 2.2 Ron Daniel discussed the NAPTR draft. - There will be verbiage to state that records with unknown flags must be ignored. - The Pseudo-code will get a strong disclaimer. - "R" Flag for treating Regex as "Raw" - Don't do "E" flag for encrypting Raw fields. - Flag field reserves 0-9 for experimentation. ROUGH CONSENSUS was to allow people to create new flags however they want, but that if you see a flag you don't recognize you ignore it. Ron is going to revise the wording of the draft so that people may place any interpretation they want on the various fields as long as they define a flag for it. There was a question of the references to other drafts, and John Curran said he would find out if the text RFC xxx could be written and if the RFC editor would insert the correct numbers. This draft will be going as an Experimental RFC. There was discussion about how the experimental status will effect DNS and the regex substitutions. We need to be explicit. We need to say how this doesn't overload DNS and how DNS security will help and where it won't. Also, there will probably be more than one discover service in the future and we don't want this one to be "The Standard". We need operational experience. The requiring resolution problem is not part of this draft. We will have one more revision on the mailing list, then this goes to Experimental. HTTP Conventions: Ron took this one too. We need a simple resolver for testing, the goal is not Standards track. The goal is to use the conventions on encoding on requests and responses on http: GET /uri-res// HTTP 1.0 Open Discussion: URN: There was a question of rough consensus on the problem of whether to require urn:. The room seems to indicate that urn: should be required on any part of the urn that was shipped around the Internet. Whether or not implementors would use urn: was left up to them for their own local products, but in transmission the urn: would be required. The problem with urn: seems to be at the user interface and user services level. Don't confuse human friendly names with internal representation. Documents: We need a URN dereferencing document to discuss the resolution service and the resolution system. These need the syntax (which is close) and the system requirements needs the framework (which is also close.) Assign URN - needs everything! We need namespace requirements. Renato Iannella was volunteered to create a first draft of this document. We need to have one new namespace and we need to bring in 1 existing namespace. We need to pay some attention to potential lawsuit issue. It is important for someone who has authority for the namespace to say how it works in URN. The proposal is for these to be experimental. Dun and Bradstreet is interested in working on this as soon as the syntax is ready. Clifford Lynch said that the NISO bibliographic IDs could move en masse. We can create a resolution system which can be used outside the URN space, but we need to make it work there first. Charter directions: * We need to get a grip on bringing in an existing namespace * We need a new namespace scheme * We need the Name space requirements document (to see whether DNS-based namespace will or won't work, and if not, what we can do about a generically-accessible namespace) * We need to look at the process of creating new namespaces -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA04420 for urn-ietf-out; Mon, 23 Dec 1996 13:35:44 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA04413 for ; Mon, 23 Dec 1996 13:35:41 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07521 (mail destined for urn-ietf@services.bunyip.com); Mon, 23 Dec 96 13:35:38 -0500 Received: by privateer.windrose.omaha.ne.us; Mon Dec 23 12:34 CST 1996 Message-Id: <32BED0A0.5215@ds.internic.net> Date: Mon, 23 Dec 1996 12:34:08 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Dirk.vanGulik@jrc.it Cc: "Martin J. Duerst" , urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Dirk.vanGulik@jrc.it wrote: > Ok, here is a real example; P-R document references; > > Country They type (the keys/display on the screen) > France #PEL/77124 > UK *PEL/77124 (Where the * is the oblique L > pound sign) > Greece $PEL/77l24 (Note the 'l' instead of '1') > Holland FlPEL/77l24 (Where fl is the florin symbol) > > Luckily however the _wire_ format is perfectly sensible and > the same; But the fun bit is that they all happily print and > fax each other those references; and all know how to cope > with them just fine :-) > > The point I am trying to make is that for some namespaces to > be grandfathered in have a stronger relation to their wire > octed stream than to the glyph/symbolic representation; so for > those you really want to ignore all you learned about really > neat UTF8 symbol encoding :-) > I think somebody is confused (probably me), but I don't see what the problem with this example is. All of those P-R document references do not have to map to the same URN. In fact, based on how they are described above, the shouldn't. Rather, the namespace that holds the above resource (call it foobar), will have the following 4 URNs (I'll probably get this wrong, bear with me): urn:foobar:%23PEL/77124 urn:foobar:%C2%A3PEL/77124 urn:foobar:%24PEL/77l24 urn:foobar:%E0%86%92PEL/77l24 My main point having gotten here is this: It's up to the namespace resolver for foobar to understand that these may all refer to the same resource, not the syntax. Therefore "wire-coding should be more important that glyph/symbolic representation" becomes a resolver issue, not a syntax issue. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA27555 for urn-ietf-out; Mon, 23 Dec 1996 04:40:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA27550 for ; Mon, 23 Dec 1996 04:40:50 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04776 (mail destined for urn-ietf@services.bunyip.com); Mon, 23 Dec 96 04:40:36 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA25034; Mon, 23 Dec 96 10:45:34 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA17045; Mon, 23 Dec 1996 10:39:39 +0100 Date: Mon, 23 Dec 1996 10:39:39 +0100 (MET) From: Dirk.vanGulik@jrc.it X-Sender: dirkx@elect6.jrc.it To: "Martin J. Duerst" Cc: Dirk.vanGulik@jrc.it, Ryan Moats , urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: Message-Id: Reply-Path: Dirk.vanGulik@jrc.it Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Dirk.vanGulik@jrc.it Errors-To: owner-urn-ietf@bunyip.com On Sat, 21 Dec 1996, Martin J. Duerst wrote: > On Sat, 21 Dec 1996 Dirk.vanGulik@jrc.it wrote: > > > Ryan wrote: > > > Dirk.vanGulik@jrc.it wrote: > > > > > > > > 3. suggested escape hatch for (grandfathered in) namespaces > > > > where the glyph representation is confirmed ambigious. (For > > > > example the $, #, pound and yen sign). > > > > > > This is already taken care of by the character set. The only > > > way to put a character from this set in a URN is to use "%" encoding. > > > Otherwise, the character terminates the URN. > > > > > It dawns on me that you may be talking about what hex value to use > > > for the "%" encoding. My current position is that it is the > > > UNICODE/10646 value via UTF-8. > > > > No Actually not, What I meant is that I've seen people in the document > > and library world using quite a few naming schemes where in different > > places they use say the '$' and '$' with two lines through it and the '#' > > and the L-shaped pound sign interchangably, depending on what keyboard > > and machine they are working. So in these spaces the glyph-to-wire > > encoding (using the % utf-8 encoding) is no longer trivial, as it is no > > longer the shape of the symbol which matters. > > I start to understand. Real examples always make it easier. Ok, here is a real example; P-R document references; Country They type (the keys/display on the screen) France #PEL/77124 UK *PEL/77124 (Where the * is the oblique L pound sign) Greece $PEL/77l24 (Note the 'l' instead of '1') Holland FlPEL/77l24 (Where fl is the florin symbol) Luckily however the _wire_ format is perfectly sensible and the same; But the fun bit is that they all happily print and fax each other those references; and all know how to cope with them just fine :-) The point I am trying to make is that for some namespaces to be grandfathered in have a stronger relation to their wire octed stream than to the glyph/symbolic representation; so for those you really want to ignore all you learned about really neat UTF8 symbol encoding :-) Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA23468 for urn-ietf-out; Sat, 21 Dec 1996 16:41:12 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA23462 for ; Sat, 21 Dec 1996 16:41:09 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28546 (mail destined for urn-ietf@services.bunyip.com); Sat, 21 Dec 96 16:41:07 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <12447-0@josef.ifi.unizh.ch>; Sat, 21 Dec 1996 22:41:22 +0100 Date: Sat, 21 Dec 1996 22:41:21 +0100 (MET) From: "Martin J. Duerst" To: Dirk.vanGulik@jrc.it Cc: Ryan Moats , urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Sat, 21 Dec 1996 Dirk.vanGulik@jrc.it wrote: > Ryan wrote: > > Dirk.vanGulik@jrc.it wrote: > > > > > > 3. suggested escape hatch for (grandfathered in) namespaces > > > where the glyph representation is confirmed ambigious. (For > > > example the $, #, pound and yen sign). > > > > This is already taken care of by the character set. The only > > way to put a character from this set in a URN is to use "%" encoding. > > Otherwise, the character terminates the URN. > > > It dawns on me that you may be talking about what hex value to use > > for the "%" encoding. My current position is that it is the > > UNICODE/10646 value via UTF-8. > > No Actually not, What I meant is that I've seen people in the document > and library world using quite a few naming schemes where in different > places they use say the '$' and '$' with two lines through it and the '#' > and the L-shaped pound sign interchangably, depending on what keyboard > and machine they are working. So in these spaces the glyph-to-wire > encoding (using the % utf-8 encoding) is no longer trivial, as it is no > longer the shape of the symbol which matters. I start to understand. Real examples always make it easier. For the two cases above, the $ with | or || is not a problem, as for them there is only one codepoint in UNicode. For the '#' and the pound sign, they both have a codepoint in UNicode/10646. What I think you should do for your namespace would be that you define that '#' and pound sign are lexically equivalent. The users can type whichever they want, and some component in the architecture that will be built will equate them, as for other namespaces, it would equate lower-case and upper-case. So if all the problematic cases you had in mind have the same structure, it turns out we already have taken care of that in the syntax draft :-). > Well this still does not quite solve it; but I think the underlying issue > is about what is the 'real' thing, a sequene of sybols or a sequence of > octeds. There are several "real" things. The best defined is the URN as such, a string of characters from a limited set. It is used to represent a string of characters from a wider set, along certain rules, or in some exceptions something else, which will have to be defined separately. There are also, at some point, octets. They are an intermediate stage when mapping from *represented* characters to *representing* characters. And they can be a "point of attachment" when a namespace exists in digital form only, and has to be brougt into an URN. The question of what is the "real" thing is a question of philosophy, not a question of protocol specification. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA23212 for urn-ietf-out; Sat, 21 Dec 1996 16:26:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA23203 for ; Sat, 21 Dec 1996 16:26:46 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28476 (mail destined for urn-ietf@services.bunyip.com); Sat, 21 Dec 96 16:26:43 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <12300-0@josef.ifi.unizh.ch>; Sat, 21 Dec 1996 22:26:49 +0100 Date: Sat, 21 Dec 1996 22:26:48 +0100 (MET) From: "Martin J. Duerst" To: Dirk.vanGulik@jrc.it Cc: Larry Masinter , jayhawk@ds.internic.net, urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com > On Fri, 20 Dec 1996, Larry Masinter wrote: > > > I've come to understand that %XX encoding of UTF8 is particularly > > ugly, and that some variation of UTF7 (if not UTF7 itself) would be > > better for contexts where 7-bit-safe channels should be assumed. On Sat, 21 Dec 1996 Dirk.vanGulik@jrc.it wrote: > yes, you are quite right; but this was brought up before, and there > was some good reasoining as why to go UTF8 anyway. > > Martin, could you re-elaborate ? - The main reason we have a limited character set and %HH is transcribability, not 7-bit channels. - The basic syntactical equivalence between URLs and URNs is very important. URLs have %HH. - Other parallels between URLs and URNs are also valuable. URLs, hopefully, will move towards UTF-8. (The ftp URL scheme is already moving in that direction). There have been a lot of discussions about other alternatives, but UTF-8 is generally viewed as the best solution. - 7-bit channels are still existing, but getting fewer and fewer. They are ugly by themselves, and don't "deserve" beauty. If we design something that looks "nice" for the remaining 7-bit channels, it will look ugly for 8-bit channels and so forever. - Once we are reasonably sure that i18n text, and URLs/URNs in i18n text, are treated decently, we can move on to allow a text to include as such those URN *represended* characters it can represent, and only use %HH for characters that cannot be represented and non-character %HH. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA23040 for urn-ietf-out; Sat, 21 Dec 1996 16:04:09 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA23033 for ; Sat, 21 Dec 1996 16:04:05 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28424 (mail destined for urn-ietf@services.bunyip.com); Sat, 21 Dec 96 16:04:02 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA18737; Sat, 21 Dec 96 22:09:28 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA16198; Sat, 21 Dec 1996 22:03:39 +0100 Date: Sat, 21 Dec 1996 22:03:33 +0100 (MET) From: Dirk.vanGulik@jrc.it X-Sender: dirkx@elect6.jrc.it To: Ryan Moats Cc: Dirk.vanGulik@jrc.it, urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: <32BAE705.7E75@ds.internic.net> Message-Id: Reply-Path: Dirk.vanGulik@jrc.it Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Dirk.vanGulik@jrc.it Errors-To: owner-urn-ietf@bunyip.com Ryan wrote: > Dirk.vanGulik@jrc.it wrote: > > > > I think you may have missed my mail on URN/URL potential > incompatibilities. The current text of the draft on the "%" issue > is the following: > > "...Translation is done by encoding each character outside the URN > character set as a sequence of one to six octets using UTF-8 encoding, > and the encoding of each of those octets as "%" followed by two > characters from the character set above. The two characters give > the hexadecimal representation of that octet. > > The "%" character is reserved in the URN syntax for introducing the > escape sequence for an octet. Literal use of the "%" character in a > namespace must be encoded using %25 in URNs for that namespace. The > precence of an "%" character in a URN MUST be followed by two characters > from the character set. Sorry about that; I should have double checked wether I used the last draft, I apoliogize !. > > 3. suggested escape hatch for (grandfathered in) namespaces > > where the glyph representation is confirmed ambigious. (For > > example the $, #, pound and yen sign). > > This is already taken care of by the character set. The only > way to put a character from this set in a URN is to use "%" encoding. > Otherwise, the character terminates the URN. > It dawns on me that you may be talking about what hex value to use > for the "%" encoding. My current position is that it is the > UNICODE/10646 value via UTF-8. No Actually not, What I meant is that I've seen people in the document and library world using quite a few naming schemes where in different places they use say the '$' and '$' with two lines through it and the '#' and the L-shaped pound sign interchangably, depending on what keyboard and machine they are working. So in these spaces the glyph-to-wire encoding (using the % utf-8 encoding) is no longer trivial, as it is no longer the shape of the symbol which matters. > > 4. suggested escape hatch for namespaces where the identifiers > > have no meaningfull representation in the urn syntax (at > > least meaningfull in the sense that a UA could gain > > something by showing it to the user) such as spaces which > > have a purely binary object identifiers; base64 is the > > _should_ wannabe. > > I don't have a problem with this, so long as such information > is included in the namespace registration documentation. > Yes, I had hoped I made that clear in the remainder of the doc. > > If a proposed namespace identifier is already in use as a protocol > > specifier in the URI space, such as for example ftp, http or email, > > the proposal for this identifier should justify this choise; i.e > > > > urn:email:dirk.vangulik@jrc.it or > > urn:ftp:someplace:abc.efg > > urn:ftp://someplace/abcd.efg > > Now this makes some sense to me. I'm wondering if we want to > make the statement stronger... > > > Now this kind of 'clashes' with the needs to grandfather in various > > schemes as their glyfh encoding might *NOT* be an unambigious character > > index. For example if the indexes or local control identifiers are > > collected over various contries; which each use their own (say latin) > > charset, but the actual LCI is just the sequence of the character index > > number _ITSELF_ into the various charsets. So encoding the glyf using > > UTF8 it represents in one charset display mapping would most certainly > > wrong for another one; and if the people interoperate you have broken the > > LCI scheme. The reverse also happens; and on top of that normalizing in > > UTF8 makes it even more fun. > > The last portion of the last sentence has gone away and so the last > sentence now reads: > > "Therefore, the process of registering a namespace identifier > shall include publication of a definition of which characters have > a special meaning to that namespace". Well this still does not quite solve it; but I think the underlying issue is about what is the 'real' thing, a sequene of sybols or a sequence of octeds. > I don't see a case of glyph ambiguity in the URN character set > itself, however your following sentence: > > > ++ Likewise if glyph ambiguity does not allow for UTF8 encoding > > ++ the publication should outline the possible ambiguity and > > ++ representations possible for display. > > I like and am willing to add. > > > ++ The URN is a sequence of glyphs taken from the . It is > > ++ represented by an octet stream with the only the values of the > > ++ indexes of the glyphs in UTF-8. A glyph or symbol encoded, > > ++ entered, stored, displayed or conveyed which is not in this limited > > ++ range, for examply with an UTF-8 encoding, is purely based on the > > ++ mutual understanding of the publishing and utilizing party; but is > > ++ not to be used to represent the URN. > > > > The above needs to be tackled anyway, somewhere; unless I missed the > > place in the current draft which tells us which is really the authorative > > representation (between machines :-) of the beast. (Ignoring > > normalziaiton,etc). > > I thought (probably incorrectly) that this had been closed going into > San Jose. The URN's canonical form (for transmission between > machines) is the sequence of characters from . Well it that is your understanding as well; then I am very happy; I'll wait and see the next version of the draft to see how this was worded. > Now Martin and Keith can tell me I'm wrong, but I thought this was > closed. Well I hope it is indeed closed with this. > Other things: > > If a namespace wants to be opaque and use base-64, that's fine, but > I don't see where the syntax document must specify that. Well this was more to stay in line with the UTF8 suggestion; because _IF_ you say that the cannonical for discussion is closed and it is the wire octed stream which counts; than the UTF8 and Base64 suggestions for encodings become exactly that; and thus needs to be specified in the documents which describe them. Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA22969 for urn-ietf-out; Sat, 21 Dec 1996 15:52:29 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA22964 for ; Sat, 21 Dec 1996 15:52:25 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28385 (mail destined for urn-ietf@services.bunyip.com); Sat, 21 Dec 96 15:52:18 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA18716; Sat, 21 Dec 96 21:57:06 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA16180; Sat, 21 Dec 1996 21:51:06 +0100 Date: Sat, 21 Dec 1996 21:51:06 +0100 (MET) From: Dirk.vanGulik@jrc.it X-Sender: dirkx@elect6.jrc.it To: Larry Masinter Cc: mduerst@ifi.unizh.ch, jayhawk@ds.internic.net, Dirk.vanGulik@jrc.it, urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: <96Dec20.235708pst."2695"@golden.parc.xerox.com> Message-Id: Reply-Path: Dirk.vanGulik@jrc.it Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Dirk.vanGulik@jrc.it Errors-To: owner-urn-ietf@bunyip.com yes, you are quite right; but this was brought up before, and there was some good reasoining as why to go UTF8 anyway. Martin, could you re-elaborate ? Dw. http://ewse.ceo.org http://enrm.ceo.org DWvGulik@Dialis.xs4all.nl Dirk.vanGulik@jrc.it +39 332 78 0014 +39 332 78 9549 fax +39 332 78 9185 ISEI/ESBA; The Center For Earth Observation Joint Research Centre of the European Communities, Ispra, Italy On Fri, 20 Dec 1996, Larry Masinter wrote: > I've come to understand that %XX encoding of UTF8 is particularly > ugly, and that some variation of UTF7 (if not UTF7 itself) would be > better for contexts where 7-bit-safe channels should be assumed. > > Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA22012 for urn-ietf-out; Sat, 21 Dec 1996 13:32:07 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA22007 for ; Sat, 21 Dec 1996 13:32:04 -0500 Received: from mail.bbnplanet.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28037 (mail destined for urn-ietf@services.bunyip.com); Sat, 21 Dec 96 13:32:01 -0500 Received: from jcurran-ppp.near.net by mail.bbnplanet.com id aa17567; 21 Dec 96 13:38 EST X-Sender: jcurran@mail.bbnplanet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Phone: (617) 873-4398 Usmail: 150 CambridgePark Drive, Cambridge, MA, 02140 Date: Sat, 21 Dec 1996 13:31:58 -0500 To: Leslie Daigle From: John Curran Subject: Re: [URN] Checksums in URNs Cc: "David W. Morris" , urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: John Curran Errors-To: owner-urn-ietf@bunyip.com At 15:37 12/20/96, Leslie Daigle wrote: >... >Unless someone (that could mean you, David Morris :-) can come up with >concrete answers to the questions I asked earlier (see below), I think >we can sum up _consensus_ by saying: there is obvious merit in having >mechanisms to test the integrity of URNs. We don't yet know what the >best mechanism to handle that is (we don't even yet have any real-life >experience with them), so we can't answer it now, and will leave it as >a future problem. A very reasonable position... my own more critical viewpoint is that given the complete lack of existing experimentation in deploying checksums in URx enviroments (read: absence of running code) and the multiple requirements one might have (single error detection, multiple error detection, correction, etc.), I would claim that we're far removed from the realm of standardization and have entered the realm of creeping featurism. By all means,folks should explore using checksums (and this is readily possible both on a namespace-specific basis and via meta approaches), but none of this requires inclusion of checksums in the underlying URN or UR* frameworks. To look to mandating such in the absence of running code is not how we try to do things in the IETF. /John Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id CAA11461 for urn-ietf-out; Sat, 21 Dec 1996 02:59:49 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id CAA11428 for ; Sat, 21 Dec 1996 02:59:41 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26266 (mail destined for urn-ietf@services.bunyip.com); Sat, 21 Dec 96 02:59:35 -0500 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <15954(6)>; Fri, 20 Dec 1996 23:59:28 PST Received: by golden.parc.xerox.com id <2695>; Fri, 20 Dec 1996 23:57:08 PST To: mduerst@ifi.unizh.ch Cc: jayhawk@ds.internic.net, Dirk.vanGulik@jrc.it, urn-ietf@bunyip.com In-Reply-To: (mduerst@ifi.unizh.ch) Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt From: Larry Masinter Message-Id: <96Dec20.235708pst."2695"@golden.parc.xerox.com> Date: Fri, 20 Dec 1996 23:57:08 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com I've come to understand that %XX encoding of UTF8 is particularly ugly, and that some variation of UTF7 (if not UTF7 itself) would be better for contexts where 7-bit-safe channels should be assumed. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA04280 for urn-ietf-out; Fri, 20 Dec 1996 16:07:39 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA04275 for ; Fri, 20 Dec 1996 16:07:37 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23386 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 16:07:31 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id NAA09274 for ; Fri, 20 Dec 1996 13:07:33 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id NAA00011 for urn-ietf@bunyip.com; Fri, 20 Dec 1996 13:06:12 -0800 (PST) Date: Fri, 20 Dec 1996 13:06:12 -0800 (PST) From: Terry Allen Message-Id: <199612202106.NAA00011@ishtar.fsc.fujitsu.com> To: urn-ietf@bunyip.com Subject: Re: [URN] Checksums in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Seems to me that checksums are metadata about the URN. Certainly for name spaces that don't include checksums in their names. So checksums should go outside URNs, either in the manner Larry suggested or in some more generalized way (like the checksums you might want to use for other URIs and divers objects). Happy Solstice. Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA04171 for urn-ietf-out; Fri, 20 Dec 1996 15:56:07 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA04166 for ; Fri, 20 Dec 1996 15:56:03 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23262 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 15:55:50 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <25054-0@josef.ifi.unizh.ch>; Fri, 20 Dec 1996 21:55:38 +0100 Date: Fri, 20 Dec 1996 21:55:36 +0100 (MET) From: "Martin J. Duerst" To: Ryan Moats Cc: Dirk.vanGulik@jrc.it, urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: <32BAE705.7E75@ds.internic.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Fri, 20 Dec 1996, Ryan Moats wrote: > Dirk.vanGulik@jrc.it wrote: > The "%" character is reserved in the URN syntax for introducing the > escape sequence for an octet. Literal use of the "%" character in a > namespace must be encoded using %25 in URNs for that namespace. The > precence of an "%" character in a URN MUST be followed by two characters > from the character set. Very good. Wanted to suggest to mention %25 myself. Saying that one has to use the %HH-encoding of the UTF-8 representation of "%" is the same thing, but the first is a little more direct. > > 3. suggested escape hatch for (grandfathered in) namespaces > > where the glyph representation is confirmed ambigious. (For > > example the $, #, pound and yen sign). > > This is already taken care of by the character set. The only > way to put a character from this set in a URN is to use "%" encoding. > Otherwise, the character terminates the URN. > > It dawns on me that you may be talking about what hex value to use > for the "%" encoding. My current position is that it is the > UNICODE/10646 value via UTF-8. I also have difficulties grasping what Dirk exactly means. For me, it could be one of two things: (1) It's the problem that under some transfers, the # can change into a pound sign. If this is the thing, then we dealt with it on the "represented characters" side by using UTF-8 (where both # and pound have their well-defined positions) and on the "representing characters" side by not having it in . (2) It's the problem that e.g. the $ exists in several variants, in particular with one and two vertical bars, and that a namespace would, for some reason I currently ignore, need to distinguish between those two. Unicode/ISO 10646 and therefore UTF-8 don't make such a distinction, as they encode characters, and not glyphs. If this is what Dirk is worrying about, I would like to answer as follows: The kinds of namespaces that we immagined to be mapped from the real world, such as ISBN, car numbers, account numbers, and so on, really won't use such subtleties of typography. It would be too easy to mix up the two repre- sentations for the people that use them. I think that such cases are so special that it is not necessary to mention them in detail. They are best lumped together with the cases where "characters represented" don't make sense. > > 4. suggested escape hatch for namespaces where the identifiers > > have no meaningfull representation in the urn syntax (at > > least meaningfull in the sense that a UA could gain > > something by showing it to the user) such as spaces which > > have a purely binary object identifiers; base64 is the > > _should_ wannabe. > > I don't have a problem with this, so long as such information > is included in the namespace registration documentation. I always suggested such an escape hatch, but I would like to keep it generic. For clarification, I propose to *add* after Depending on the rules governing a namespace, valid identifiers in a namespace might contain characters that are not members of the URN character set above (). Such strings MUST be translated into canonical NSS format before using them as protocol elements or otherwise passing them on to other applications. Translation is done by encoding each character outside the URN character set as a sequence of one to six octets using UTF-8 encoding, and the encoding of each of those octets as "%" followed by two characters from the character set above. The two characters give the hexadecimal representation of that octet. a new paragraph saying + Namespaces that cannot be interpreted in terms of characters + may define their own mapping to syntactically + conforming NSSs. If a widespread and reliable digital form exists, they + may make use of octet encoding using the "%" character. Please note that + therefore, URNs can contain encoded octet sequences that are not valid + URN sequences. Such namespaces may also use other means for encoding + digital data, such as base64. > > 6. Some extra requiments on the NSI if it is one of the URI > > prefixes. I can see valid reasons to do this; but also > > can see easy confusion with the UA interface; so if one > > proposes such a NSI idenfier she'd better address/defend > > it in the publication right away. Quick example: > > > > urn:email:dirk.vangulik@jrc.it > > urn:smtp:Marcel-1.08-1111165644-064SrPH@snoopy.ant.co.uk > > urn:nntp:some-message-id-as-above > > Oog. I'm gonna take a pass on this one also for now (I have to > think about it some more)... My thoughts (not finished yet): - What about new URL schemes? Do we need a common registration? - If we have a common registration, isn't there the danger that the urn: prefix will be dropped, for which finally agreement seems to have been found? > > ... > > Now this kind of 'clashes' with the needs to grandfather in various > > schemes as their glyfh encoding might *NOT* be an unambigious character > > index. For example if the indexes or local control identifiers are > > collected over various contries; which each use their own (say latin) > > charset, but the actual LCI is just the sequence of the character index > > number _ITSELF_ into the various charsets. So encoding the glyf using > > UTF8 it represents in one charset display mapping would most certainly > > wrong for another one; and if the people interoperate you have broken the > > LCI scheme. The reverse also happens; and on top of that normalizing in > > UTF8 makes it even more fun. If there is a namespace that encodes using different "charset"s for different identifiers, then either the information about each "charset" used is still available, somewhere in the identifier or elsewhere, and the identifiers can be converted to UTF8 and treated as everything else. Otherwise, if the information about which "charset" is used in each identifier is not available, or too difficult to get (e.g. needing a connection to ask for it from some remote site), the characters are lost, and there is no other solution to treat this as if they never had been there. (i.e. use base64 or such). In this case, there is no need to speak about glyphs. If glyphs are indeed an issue (e.g. a namespace indeed has to distinguish between $ with one and with | and with ||), then if this is a general problem for many of the characters/glyphs used, we can't very well speak about characters anymore, and a special mapping has to be designed. If it's only one or two glyphs, among many where chararacters are well suited, the private zone might be used, or some character might be substituted that is not otherwise used in the namespace. > I don't see a case of glyph ambiguity in the URN character set > itself, however your following sentence: > > > ++ Likewise if glyph ambiguity does not allow for UTF8 encoding > > ++ the publication should outline the possible ambiguity and > > ++ representations possible for display. > > I like and am willing to add. Ryan, does this sentence refer to the preceeding or the following paragraph? I think the preceeding paragraph is not necessary. URNs in general are displayed in their cannonical form. We introduced UTF-8 so that we can construct nice interfaces for the display of character-based URNs. It would be strange to specify that in the context of a certain namespace, a $ has to be represented with ||. It would also be daring by a namespace encoding icons to request or require that the icons are displayed as such. > > ++ The URN is a sequence of glyphs taken from the . It is > > ++ represented by an octet stream with the only the values of the > > ++ indexes of the glyphs in UTF-8. A glyph or symbol encoded, > > ++ entered, stored, displayed or conveyed which is not in this limited > > ++ range, for examply with an UTF-8 encoding, is purely based on the > > ++ mutual understanding of the publishing and utilizing party; but is > > ++ not to be used to represent the URN. > > > > The above needs to be tackled anyway, somewhere; unless I missed the > > place in the current draft which tells us which is really the authorative > > representation (between machines :-) of the beast. (Ignoring > > normalziaiton,etc). > > I thought (probably incorrectly) that this had been closed going into > San Jose. The URN's canonical form (for transmission between > machines) is the sequence of characters from . > Now Martin and Keith can tell me I'm wrong, but I thought this was > closed. Yes, it had been closed. It is represented by: 4. URN presentation and transport URN-aware applications MAY support "natural" display of URNs which contain characters encoded using "%" notation. However, they MUST provide for display of URNs in canonical form (i.e. in a format suitable for transcription). URNs MUST be transported in canonical format. Please note that this does not specify octet representation of the canonical format. Octet representation may look differently if the URN is in an EBCDIC file or an ASCII file or a UNicode file (the later with every second octet being a NULL). I don't think there is a need to reopen this. It's a fair and safe, although not extremely efficient, compromize. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA03904 for urn-ietf-out; Fri, 20 Dec 1996 15:47:08 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA03899 for ; Fri, 20 Dec 1996 15:47:06 -0500 Received: from fssun10.dev.oclc.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23200 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 15:47:05 -0500 Received: from orc.NISOR (orc.dev.oclc.org) by oclc.org (4.1/SMI-4.1) id AA15255; Fri, 20 Dec 96 15:46:54 EST Received: by orc.NISOR (SMI-8.6/SMI-SVR4) id PAA03039; Fri, 20 Dec 1996 15:48:11 -0500 Date: Fri, 20 Dec 1996 15:48:11 -0500 From: weibel@oclc.org (Stu Weibel) Message-Id: <199612202048.PAA03039@orc.NISOR> To: urn-ietf@bunyip.com Subject: [URN] checksums X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: weibel@oclc.org (Stu Weibel) Errors-To: owner-urn-ietf@bunyip.com Leslie is right... this thread is not critical to the success of URN deployment and can be handled elsewhere. Creeping featurism is the bane of this group. Solve one problem at a time. stu Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA03804 for urn-ietf-out; Fri, 20 Dec 1996 15:37:43 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA03799 for ; Fri, 20 Dec 1996 15:37:37 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23139 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 15:37:19 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 20 14:35 CST 1996 Message-Id: <32BAF8A8.5324@ds.internic.net> Date: Fri, 20 Dec 1996 14:35:52 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Daniel LaLiberte Cc: Dirk.vanGulik@jrc.it, urn-ietf@bunyip.com Subject: Re: structured NIDs [was Re: [URN] Pre-release of draft-ietf-...] References: <32BAE705.7E75@ds.internic.net> <199612202013.OAA23521@void.ncsa.uiuc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Daniel LaLiberte wrote: > > Ryan Moats writes: > > Dirk.vanGulik@jrc.it wrote: > > > I only recently realized this when we where making an updated version > > > of a namespace; and we actually federated the namespace identification > > > itself for a little test; i.e. > > > > > > urn:v2.inet:some.where:somestring > > > > Ok, now we talk about the "." in the NID. I don't have a strong opinion > > as to whether it should be included or not. Anybody else what to > > comment on this? > > Whether we do this or not, I don't consider it a silly question. > It affects performance as well as human factor issues such as how > organizations tend to arrange themselves (i.e. in hierarchies). > > Structuring the NID is not strictly necessary because any > substructure *could* be pushed off to the NSS. But substructure in the > NSS would not be as easily visible to clients and thus caching would > be more difficult. > > For example, if urn:inet:v2:some.where:somestring were handled one way > and urn:inet:v8:some.where:somestring were handled another, then the > V2 vs V8 is in the NSS. But the NAPTR data for inet could specify a > regex that matches on this part of the NSS and thus different > resolvers could be specified, but it is more work for the client. Hang on. The NID cannot have ":" in it. Therefore, the NID for both of these cases is inet. Now, if the inet namespace wants to have substructure, that's fine. However, the questions are: (1) Should the NID have substrcuture? (2) If yes, how do we do it? I deleted the rest of the mail because it gets into implementation (question 2) without discussing question 1. Thinking about this some more, I'm wondering what structure in the NID gives me. The NID is used to (a) help find a namespace resolver and (b) maybe help find NA information from the NSS. Structure in the NID would only be used to solve (a) or (b) which are already being done without the strucutre. Unless somebody has a (c), (d) or etc. that NID structure gives me, why complicate the syntax? Note: I'm punting on (2), because I'm leaning toward the answer to (1) being "no". Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA03787 for urn-ietf-out; Fri, 20 Dec 1996 15:37:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA03782 for ; Fri, 20 Dec 1996 15:37:18 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23136 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 15:37:17 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id PAA00458; Fri, 20 Dec 1996 15:37:14 -0500 Message-Id: <199612202037.PAA00458@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Fri, 20 Dec 1996 15:37:13 -0500 In-Reply-To: "David W. Morris"'s message as of Dec 20, 11:33 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "David W. Morris" , Ryan Moats Subject: Re: [URN] Checksums in URNs Cc: "Ron Daniel Jr." , urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Okay, I think this is losing focus... The question is not simply whether having the ability to checksum URNs would be a good thing or not -- there is much merit in the suggestion, because the problems it tries to solve are very real. However, there _is_ the question of whether or not it should be moved into the general URN syntax/structure. There are reasons to do this (it'll be built in and usable by all schemes), and reasons not to (creeping featurism, trying to pick _one_ way to solve the problem for _all time_). There seem to be more questions popping up -- how to handle white spaces, what this is really intended to do, how it should be represented, etc. There are alternative mechanisms -- the external wrapper/service, as Larry suggested, or even incorporating it into individual namespaces -- or coming up with a standardized way that new namespaces could _all_ adopt. Unless someone (that could mean you, David Morris :-) can come up with concrete answers to the questions I asked earlier (see below), I think we can sum up _consensus_ by saying: there is obvious merit in having mechanisms to test the integrity of URNs. We don't yet know what the best mechanism to handle that is (we don't even yet have any real-life experience with them), so we can't answer it now, and will leave it as a future problem. Cheers! Leslie. [From my earlier message:] Things that need to be made clear: . whether this can be defined across _all_ URNs or is better hanlded by individual namespaces . is there _one_ checksumming standard that could be considered acceptable across _all_ URNs, now and forever, or else how do we identify which system was used for which URN? . how this would be handled in the rest of the URN resolution system (e.g., impacts on how NAPTR would handle URNs, etc) . how this would fit into the proposed syntax If somebody wants to propose concrete answers to these issues, we can see about getting consensus about moving on this... Specifically, rather than defining what "MUST" be done "by URNs", I'm looking for some _concrete_ proposed adaptations to the drafts that would do what is wanted. -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA03755 for urn-ietf-out; Fri, 20 Dec 1996 15:34:53 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA03750 for ; Fri, 20 Dec 1996 15:34:50 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23120 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 15:34:47 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id NAA04420; Fri, 20 Dec 1996 13:34:33 -0700 (MST) Message-Id: <3.0.32.19961220133010.006cb3f0@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 20 Dec 1996 13:44:00 -0700 To: "David W. Morris" From: "Ron Daniel Jr." Subject: Re: [URN] Checksums in URNs Cc: Ryan Moats , urn-ietf@bunyip.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com Thus spoke David W. Morris (at least at 11:54 AM 12/20/96 -0800) >is some form of self validation a >necessary precondition for the long term utility and success of >URNs. If the answer is yes, then the self-validation should be >specified as part of the URN, even if only to say that a conforming >URN implemenation must support ck:. If the answer is no, then the >URN specification can ignore the issue and allow the perhaps never >to be designed and specified other means to be used. Actually, you are asking for something a bit stronger than a self-validation ability. Lots of namespaces already provide check-digit calculations of one form or another. However, their calculations are not the same, so a user agent can't validate the URNs. You are asking for the one-true-way to do check digits in URNs, which would allow clients to do a sanity check on the URN even if they were disconnected from the rest of the world. While this would be nice, I am NOT convinced that it is mandatory. I AM concerned about any attempts to say "this one aspect of URNs must be immutable for all time". If protocols, machines, filenames, resolution mechanisms, ... are all assumed subject to change over time and therefore discouraged from appearing in the URN, what makes us think that any arbitrary check digit calculation will also be immutable? There is at least one counter-example. The DUNS number system changed its check digit calculation, and coming up with a new one that would not invalidate the old numbers had to be fun. The reasons they made that change, to fit more numbers into their fixed-size identifier, are not so important to URNs but my point is that we should avoid making requirements for immutable procedures in a system that is expected to live a long time in a mutable environment. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA03539 for urn-ietf-out; Fri, 20 Dec 1996 15:18:43 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA03534 for ; Fri, 20 Dec 1996 15:18:41 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22933 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 15:18:39 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.2/8.8.2) with ESMTP id OAA22671; Fri, 20 Dec 1996 14:17:50 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id OAA23521; Fri, 20 Dec 1996 14:13:41 -0600 (CST) Date: Fri, 20 Dec 1996 14:13:41 -0600 (CST) Message-Id: <199612202013.OAA23521@void.ncsa.uiuc.edu> To: Ryan Moats Cc: Dirk.vanGulik@jrc.it, urn-ietf@bunyip.com Subject: structured NIDs [was Re: [URN] Pre-release of draft-ietf-...] In-Reply-To: <32BAE705.7E75@ds.internic.net> References: <32BAE705.7E75@ds.internic.net> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Ryan Moats writes: > Dirk.vanGulik@jrc.it wrote: > > I only recently realized this when we where making an updated version > > of a namespace; and we actually federated the namespace identification > > itself for a little test; i.e. > > > > urn:v2.inet:some.where:somestring > > Ok, now we talk about the "." in the NID. I don't have a strong opinion > as to whether it should be included or not. Anybody else what to > comment on this? Whether we do this or not, I don't consider it a silly question. It affects performance as well as human factor issues such as how organizations tend to arrange themselves (i.e. in hierarchies). Structuring the NID is not strictly necessary because any substructure *could* be pushed off to the NSS. But substructure in the NSS would not be as easily visible to clients and thus caching would be more difficult. For example, if urn:inet:v2:some.where:somestring were handled one way and urn:inet:v8:some.where:somestring were handled another, then the V2 vs V8 is in the NSS. But the NAPTR data for inet could specify a regex that matches on this part of the NSS and thus different resolvers could be specified, but it is more work for the client. By the way, if the components of the structured NID were reversed and separated by "/", then we would have something strongly resembling the "path" scheme. The reversal to reconstruct a DNS name (e.g. inet/v2 -> v2.inet.urn.net) could be done explicitly by clients rather than rely on a sequence of regex substitutions and DNS lookups proportional in length to the number of components. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA03290 for urn-ietf-out; Fri, 20 Dec 1996 15:03:42 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA03285 for ; Fri, 20 Dec 1996 15:03:40 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22836 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 15:03:31 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id NAA04136; Fri, 20 Dec 1996 13:03:23 -0700 (MST) Message-Id: <3.0.32.19961220131241.006cd914@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 20 Dec 1996 13:12:49 -0700 To: "David W. Morris" , Ryan Moats From: "Ron Daniel Jr." Subject: Re: [URN] Checksums in URNs Cc: urn-ietf@bunyip.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com Thus spoke David W. Morris (at least at 11:33 AM 12/20/96 -0800) [on the subject of white space] >the real world fact is that >URNs will be 'typed' into plain text mail, printed, etc. For ease >of handling, line breaks, etc. will creep in. Any verification scheme >should, I think, allow for the possiblity. I think this is a "user-interface" issue. When one system sends a URN to another system, white space characters are not allowed. If a user, OCR system, ... somehow comes up with a bunch of whitespace characters when they try to specify a URN to a user-agent, then it is that user-agent's responsibility to make it legal or refuse it. We can and should provide some "advice to imlpementors" that they should expect to see illegal characters in URNs, especially when a user is providing the URN, but that they MUST not send an illegal URN, they SHOULD try obvious cleanups, and the MAY try to be very smart indeed about how they make up a legal URN from an illegal one. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA03202 for urn-ietf-out; Fri, 20 Dec 1996 14:58:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA03197 for ; Fri, 20 Dec 1996 14:58:43 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22792 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 14:58:41 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 20 13:57 CST 1996 Message-Id: <32BAEF94.7EC3@ds.internic.net> Date: Fri, 20 Dec 1996 13:57:08 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: "David W. Morris" Cc: "Ron Daniel Jr." , urn-ietf@bunyip.com Subject: Re: [URN] Checksums in URNs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com David W. Morris wrote: > > On Fri, 20 Dec 1996, Ryan Moats wrote: > > [rest-deleted...] > > > BTW, just as a final note, the current URN syntax does not allow > > arbitrary white space to be added in an unescaped form (just for > > those inquiring minds) > > And I am not proposing changing that ... but the real world fact is that > URNs will be 'typed' into plain text mail, printed, etc. For ease > of handling, line breaks, etc. will creep in. Any verification scheme > should, I think, allow for the possiblity. Any verification scheme "built into the URN itself" cannot handle that possibility, because the unescaped white-space terminates the URN. A verification scheme that can't handle the possibility is not acceptable (I think we agree on this). So, build the verification scheme into something that can handle the white-space (a new meta-scheme). Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA03185 for urn-ietf-out; Fri, 20 Dec 1996 14:57:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA03175 for ; Fri, 20 Dec 1996 14:57:54 -0500 Received: from shell1.aimnet.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22767 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 14:57:48 -0500 Received: from localhost (dwm@localhost) by shell1.aimnet.com (8.8.4/SHELL) with SMTP id LAA23429; Fri, 20 Dec 1996 11:54:07 -0800 (PST) Date: Fri, 20 Dec 1996 11:54:07 -0800 (PST) From: "David W. Morris" X-Sender: dwm@shell1.aimnet.com To: "Ron Daniel Jr." Cc: Ryan Moats , urn-ietf@bunyip.com Subject: Re: [URN] Checksums in URNs In-Reply-To: <3.0.32.19961220125706.006cb8d8@acl.lanl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "David W. Morris" Errors-To: owner-urn-ietf@bunyip.com On Fri, 20 Dec 1996, Ron Daniel Jr. wrote: > I agree with Ryan. I am not in favor of adding more stuff > to the URN syntax, especially when it can be accomplished by > other means. My base concern is only ... is some form of self validation a necessary precondition for the long term utility and success of URNs. If the answer is yes, then the self-validation should be specified as part of the URN, even if only to say that a conforming URN implemenation must support ck:. If the answer is no, then the URN specification can ignore the issue and allow the perhaps never to be designed and specified other means to be used. If in practice, URNs are perceived as as fragile as today's URLs, then the effort to design URNs will have been wasted. One aspect of today's fragility is typographic error of on entry. Dave Morris Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA03074 for urn-ietf-out; Fri, 20 Dec 1996 14:49:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA03069 for ; Fri, 20 Dec 1996 14:49:44 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22699 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 14:49:42 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 20 13:48 CST 1996 Message-Id: <32BAEDA2.4940@ds.internic.net> Date: Fri, 20 Dec 1996 13:48:50 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: urn-ietf@bunyip.com Subject: [URN] Syntax Draft Plans... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Folks- There have been some good comments about the syntax draft and some good stuff coming out of meshing it with the URL syntax, so I am planning the following (i.e. you have been warned!). There will be another pre-release of syntax-02 coming out on 12/26 ( Holidays, what are Holidays ;-} ). The target is to have -02 be sent to the i-d editors on 1/6/97. This way folks (who don't have anything else to do between 12/25 and 1/1) can read the new version... Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA03059 for urn-ietf-out; Fri, 20 Dec 1996 14:49:22 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA03054 for ; Fri, 20 Dec 1996 14:49:20 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22695 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 14:49:18 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA03994; Fri, 20 Dec 1996 12:49:08 -0700 (MST) Message-Id: <3.0.32.19961220125706.006cb8d8@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 20 Dec 1996 12:58:34 -0700 To: Ryan Moats , "David W. Morris" From: "Ron Daniel Jr." Subject: Re: [URN] Checksums in URNs Cc: urn-ietf@bunyip.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com I agree with Ryan. I am not in favor of adding more stuff to the URN syntax, especially when it can be accomplished by other means. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA02917 for urn-ietf-out; Fri, 20 Dec 1996 14:37:04 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA02912 for ; Fri, 20 Dec 1996 14:37:02 -0500 Received: from shell1.aimnet.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22626 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 14:36:56 -0500 Received: from localhost (dwm@localhost) by shell1.aimnet.com (8.8.4/SHELL) with SMTP id LAA19558; Fri, 20 Dec 1996 11:33:27 -0800 (PST) Date: Fri, 20 Dec 1996 11:33:26 -0800 (PST) From: "David W. Morris" X-Sender: dwm@shell1.aimnet.com To: Ryan Moats Cc: "Ron Daniel Jr." , urn-ietf@bunyip.com Subject: Re: [URN] Checksums in URNs In-Reply-To: <32BAE83F.5574@ds.internic.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "David W. Morris" Errors-To: owner-urn-ietf@bunyip.com On Fri, 20 Dec 1996, Ryan Moats wrote: > Yes, but if it is encased in a meta-scheme, the URN syntax draft doesn't > (and shouldn't care about it). If it is embedded in the URN itself, > then the ck: scheme is redundant. Why invent the wheel twice? Because ck: can apply to any URL but since it isn't part of the URL it would be hard to require ... it would be an internet standard way to validate things with no home to require its use. > > As to the discussion of white space, etc. that's a different topic than > what I'm going on about... > > Ryan > > BTW, just as a final note, the current URN syntax does not allow > arbitrary white space to be added in an unescaped form (just for > those inquiring minds) And I am not proposing changing that ... but the real world fact is that URNs will be 'typed' into plain text mail, printed, etc. For ease of handling, line breaks, etc. will creep in. Any verification scheme should, I think, allow for the possiblity. Dave Morris Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA02799 for urn-ietf-out; Fri, 20 Dec 1996 14:26:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA02794 for ; Fri, 20 Dec 1996 14:26:43 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22576 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 14:26:41 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 20 13:25 CST 1996 Message-Id: <32BAE83F.5574@ds.internic.net> Date: Fri, 20 Dec 1996 13:25:51 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: "David W. Morris" Cc: "Ron Daniel Jr." , urn-ietf@bunyip.com Subject: Re: [URN] Checksums in URNs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com David W. Morris wrote: > > On Fri, 20 Dec 1996, Ron Daniel Jr. wrote: > > > My preference would be to NOT require checksums in all URNs. > > I rather like Larry's suggestion of a wrapper like > > ck:the-checksum:the-uri > > I like the clean elegance of the checksum wrapper as a general > solution ... but I'm having a hard shaking the notion that having > a checksum built in to the URN would vastly improve the reliability > of URNs over time. On the other hand, I don't see where it would help... > My current feeling is that ck: is good and should be done as it can > apply for URLs of all kinds.... No problem so far... >AND URNs should have provision for > a built in checksum which MUST be supported by all conforming UAs, > Transfer Agents, etc. but MAY be used in any specific URN. I have a problem with this, in that it adds optional structure to the URN. This optional structure make the URN syntax dirtier (IMHO) and could create more headaches in resolving with the URL syntax (and I'm at my limit of various pain medications already...)... > In either case, part of the design MUST consider how the feature will > be used by humans ... I think that means that the syntax of ck: and > a URN form if allowed needs to support linear white space insertion > in the URL/URN at arbitrary points. Yes, but if it is encased in a meta-scheme, the URN syntax draft doesn't (and shouldn't care about it). If it is embedded in the URN itself, then the ck: scheme is redundant. Why invent the wheel twice? As to the discussion of white space, etc. that's a different topic than what I'm going on about... Ryan BTW, just as a final note, the current URN syntax does not allow arbitrary white space to be added in an unescaped form (just for those inquiring minds) Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA02675 for urn-ietf-out; Fri, 20 Dec 1996 14:22:08 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA02666 for ; Fri, 20 Dec 1996 14:22:00 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22554 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 14:21:56 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 20 13:20 CST 1996 Message-Id: <32BAE705.7E75@ds.internic.net> Date: Fri, 20 Dec 1996 13:20:37 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Dirk.vanGulik@jrc.it Cc: urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Dirk.vanGulik@jrc.it wrote: > > Just some comments on grandfathering and the % changes. The quick summary > > 0. A plea to make the representation the real > thing; while still urging for the UA's to display/enter/... > then with effective UTF8 decoding. I'll take a pass on this for the moment... > > 1. suggested removal of the '%' sign from the list. > > 2. suggested a utf-8 glyph encoding of '%' as a > octed for the char itself (%25 I think) I think you may have missed my mail on URN/URL potential incompatibilities. The current text of the draft on the "%" issue is the following: "...Translation is done by encoding each character outside the URN character set as a sequence of one to six octets using UTF-8 encoding, and the encoding of each of those octets as "%" followed by two characters from the character set above. The two characters give the hexadecimal representation of that octet. The "%" character is reserved in the URN syntax for introducing the escape sequence for an octet. Literal use of the "%" character in a namespace must be encoded using %25 in URNs for that namespace. The precence of an "%" character in a URN MUST be followed by two characters from the character set. Namespaces MAY designate one or more characters from the URN character set as having special meaning for that namespace. If the namespace also uses that character in a literal sense as well, the character used in a literal sense MUST be encoded with "%" followed by the hexadecimal representation of that octet. Therefore, the process of registering a namespace identifier shall include publication of a definition of which characters have a special meaning." This takes care of the above issues, as well as your "...%is..." example below... > 3. suggested escape hatch for (grandfathered in) namespaces > where the glyph representation is confirmed ambigious. (For > example the $, #, pound and yen sign). This is already taken care of by the character set. The only way to put a character from this set in a URN is to use "%" encoding. Otherwise, the character terminates the URN. It dawns on me that you may be talking about what hex value to use for the "%" encoding. My current position is that it is the UNICODE/10646 value via UTF-8. > 4. suggested escape hatch for namespaces where the identifiers > have no meaningfull representation in the urn syntax (at > least meaningfull in the sense that a UA could gain > something by showing it to the user) such as spaces which > have a purely binary object identifiers; base64 is the > _should_ wannabe. I don't have a problem with this, so long as such information is included in the namespace registration documentation. > 5. Some very SILLY suggestion about leaving the '.' in the > NSS reserverd for future version or expansion. I agree that I think it is silly. I got confused here as to whether you were talking about the NID or the NSS. Reserving "." in the NSS is the thing I think is silly. I'll talk about the NID later... > 6. Some extra requiments on the NSI if it is one of the URI > prefixes. I can see valid reasons to do this; but also > can see easy confusion with the UA interface; so if one > proposes such a NSI idenfier she'd better address/defend > it in the publication right away. Quick example: > > urn:email:dirk.vangulik@jrc.it > urn:smtp:Marcel-1.08-1111165644-064SrPH@snoopy.ant.co.uk > urn:nntp:some-message-id-as-above Oog. I'm gonna take a pass on this one also for now (I have to think about it some more)... > -- This is slightly more restrictive that what is stated in RFC 1738 [3] > -- (which allows the period "."). Further, the Namespace Identifier is > -- case insensitive, so that "ISBN" and "isbn" refer to the same > -- namespace. > > I only recently realized this when we where making an updated version > of a namespace; and we actually federated the namespace identification > itself for a little test; i.e. > > urn:v2.inet:some.where:somestring Ok, now we talk about the "." in the NID. I don't have a strong opinion as to whether it should be included or not. Anybody else what to comment on this? > -- To avoid confusion with the "urn:" identifier, the NID "urn" is > -- reserved and MUST NOT be used. > > After some confusion here; I would like to add something along the > lines of: > > If a proposed namespace identifier is already in use as a protocol > specifier in the URI space, such as for example ftp, http or email, > the proposal for this identifier should justify this choise; i.e > > urn:email:dirk.vangulik@jrc.it or > urn:ftp:someplace:abc.efg > urn:ftp://someplace/abcd.efg Now this makes some sense to me. I'm wondering if we want to make the statement stronger... > ... > This means that a '%' followed by a non-hex encodes itself, but so > > urn:abc:jan%is%gek and Not any more, see my discussion above. > ... > Now this kind of 'clashes' with the needs to grandfather in various > schemes as their glyfh encoding might *NOT* be an unambigious character > index. For example if the indexes or local control identifiers are > collected over various contries; which each use their own (say latin) > charset, but the actual LCI is just the sequence of the character index > number _ITSELF_ into the various charsets. So encoding the glyf using > UTF8 it represents in one charset display mapping would most certainly > wrong for another one; and if the people interoperate you have broken the > LCI scheme. The reverse also happens; and on top of that normalizing in > UTF8 makes it even more fun. The last portion of the last sentence has gone away and so the last sentence now reads: "Therefore, the process of registering a namespace identifier shall include publication of a definition of which characters have a special meaning to that namespace". I don't see a case of glyph ambiguity in the URN character set itself, however your following sentence: > ++ Likewise if glyph ambiguity does not allow for UTF8 encoding > ++ the publication should outline the possible ambiguity and > ++ representations possible for display. I like and am willing to add. > ++ The URN is a sequence of glyphs taken from the . It is > ++ represented by an octet stream with the only the values of the > ++ indexes of the glyphs in UTF-8. A glyph or symbol encoded, > ++ entered, stored, displayed or conveyed which is not in this limited > ++ range, for examply with an UTF-8 encoding, is purely based on the > ++ mutual understanding of the publishing and utilizing party; but is > ++ not to be used to represent the URN. > > The above needs to be tackled anyway, somewhere; unless I missed the > place in the current draft which tells us which is really the authorative > representation (between machines :-) of the beast. (Ignoring > normalziaiton,etc). I thought (probably incorrectly) that this had been closed going into San Jose. The URN's canonical form (for transmission between machines) is the sequence of characters from . Now Martin and Keith can tell me I'm wrong, but I thought this was closed. Other things: If a namespace wants to be opaque and use base-64, that's fine, but I don't see where the syntax document must specify that. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA01599 for urn-ietf-out; Fri, 20 Dec 1996 13:53:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA01592 for ; Fri, 20 Dec 1996 13:53:11 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22339 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 13:52:54 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA12960; Fri, 20 Dec 96 19:58:19 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA15610; Fri, 20 Dec 1996 19:52:29 +0100 Date: Fri, 20 Dec 1996 19:52:28 +0100 (MET) From: Dirk.vanGulik@jrc.it X-Sender: dirkx@elect6.jrc.it To: Ryan Moats Cc: urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: <32B56D9D.7B96@ds.internic.net> Message-Id: Reply-Path: Dirk.vanGulik@jrc.it Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Dirk.vanGulik@jrc.it Errors-To: owner-urn-ietf@bunyip.com Just some comments on grandfathering and the % changes. The quick summary 0. A plea to make the representation the real thing; while still urging for the UA's to display/enter/... then with effective UTF8 decoding. 1. suggested removal of the '%' sign from the list. 2. suggested a utf-8 glyph encoding of '%' as a octed for the char itself (%25 I think) 3. suggested escape hatch for (grandfathered in) namespaces where the glyph representation is confirmed ambigious. (For example the $, #, pound and yen sign) 4. suggested escape hatch for namespaces where the identifiers have no meaningfull representation in the urn syntax (at least meaningfull in the sense that a UA could gain something by showing it to the user) such as spaces which have a purely binary object identifiers; base64 is the _should_ wannabe. 5. Some very SILLY suggestion about leaving the '.' in the NSS reserverd for future version or expansion. 6. Some extra requiments on the NSI if it is one of the URI prefixes. I can see valid reasons to do this; but also can see easy confusion with the UA interface; so if one proposes such a NSI idenfier she'd better address/defend it in the publication right away. Quick example: urn:email:dirk.vangulik@jrc.it urn:smtp:Marcel-1.08-1111165644-064SrPH@snoopy.ant.co.uk urn:nntp:some-message-id-as-above Although one might think these are a bad idea; the syntax and resolution allows for them; the do make a bit of sense and I can image people with actually have brains dreaming up persitant names for resources they already have avaible under a well know url. Have fun. Dw. -- URN Syntax -- Filename: draft-ietf-urn-syntax-02.txt -- -- 2.1 Namespace Identifier Syntax -- -- The following is the syntax for the Namespace Identifier. To (a) be -- consistent with all potential resolution schemes and (b) not put any -- undue constraints on any potential resolution scheme, the syntax for -- the Namespace Identifier is: -- -- ::= [ * ] -- -- ::= | | | "-" -- -- ::= | | -- -- ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | -- "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | -- "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | -- "Y" | "Z" -- -- ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | -- "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | -- "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | -- "y" | "z" -- -- ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | -- "8" | "9" -- -- This is slightly more restrictive that what is stated in RFC 1738 [3] -- (which allows the period "."). Further, the Namespace Identifier is -- case insensitive, so that "ISBN" and "isbn" refer to the same -- namespace. I only recently realized this when we where making an updated version of a namespace; and we actually federated the namespace identification itself for a little test; i.e. urn:v2.inet:some.where:somestring Which obviously works with the v2.inet.urn.net lookup. I am not sure wether this is fluff functionality; and I feel that I am going down a slipperly slope; but you 'might' want to reserve the dot somehow for future expansion if you need an extra dimension; say because we do not have the syntax right now; you could do something like urn:duns.2:gorbaglobinrealniceunicode I.e. have an escape option. -- To avoid confusion with the "urn:" identifier, the NID "urn" is -- reserved and MUST NOT be used. After some confusion here; I would like to add something along the lines of: If a proposed namespace identifier is already in use as a protocol specifier in the URI space, such as for example ftp, http or email, the proposal for this identifier should justify this choise; i.e urn:email:dirk.vangulik@jrc.it or urn:ftp:someplace:abc.efg urn:ftp://someplace/abcd.efg Because I can see people wanting to re-use some of the existing well know protocol specifiers; but that would _really_ cause confusion esspecially when the User agent allow you to type 'ibm' and really turn it into http://www.ibm.com:80/home.html these days :-) -- As required by 1737, there is a single canonical representation of -- the NSS portion of an URN. The format of this single canonical form -- follows: -- -- ::= * -- -- ::= | "%" -- -- ::= | | | -- -- ::= | "A" | "B" | "C" | "D" | "E" | "F" | -- "a" | "b" | "c" | "d" | "e" | "f" -- -- ::= "(" | ")" | "+" | "" | "," | "-" | "." | "/" | -- ":" | "=" | "?" | "@" | "%" This means that a '%' followed by a non-hex encodes itself, but so urn:abc:jan%is%gek and is no problem. But than suppose you _want_ to replace the 'is' by a 'ef' which looks like hex (though you did not intend it. So I would propose to re-formulate it as: ++ ::= "(" | ")" | "+" | "" | "," | "-" | "." | "/" | ++ ":" | "=" | "?" | "@" And in the text -- Depending on the rules governing a namespace, valid identifiers in a -- namespace might contain characters that are not members of the URN -- character set above (). Such strings MUST be translated -- into canonical NSS format before using them as protocol elements or -- otherwise passing them on to other applications. Translation is done -- by encoding each character outside the URN character set as a -- sequence of one to six octets using UTF-8 encoding, and the encoding -- of each of those octets as "%" followed by two characters from the -- character set above. The two characters give the hexadecimal ++ representation of that octet. The percentage sign _itself_ is encoded ++ as an octed index into its UTF-8 representation -- Namespaces MAY designate one or more characters from the URN -- character set as having special meaning for that namespace (An -- example of this is the "%" character in the URN syntax itself). If -- the namespace also uses that character in a literal sense as well, -- the character used in a literal sense MUST be encoded with "%" -- followed by the hexadecimal representation of that octet. Therefore, -- the process of registering a namespace identifier shall include -- publication of a definition of which characters have a special -- meaning and how to encode these characters if used in a literal -- sense. Now this kind of 'clashes' with the needs to grandfather in various schemes as their glyfh encoding might *NOT* be an unambigious character index. For example if the indexes or local control identifiers are collected over various contries; which each use their own (say latin) charset, but the actual LCI is just the sequence of the character index number _ITSELF_ into the various charsets. So encoding the glyf using UTF8 it represents in one charset display mapping would most certainly wrong for another one; and if the people interoperate you have broken the LCI scheme. The reverse also happens; and on top of that normalizing in UTF8 makes it even more fun. So for this reason I suggest the follwing change of wording -- Depending on the rules governing a namespace, valid identifiers in a -- namespace might contain character indexes that are not members of the ++ URN character set above or have a different glyph represenation in the ++ above charset. (). Such strings MUST be translated -- into canonical NSS format before using them as protocol elements or -- otherwise passing them on to other applications. Translation is done -- by encoding each character index outside the URN character and/or ++ with a different glyph interpretation. If the glyph and indexes ++ representation is unambigious then it SHOULD be encoded as a ++ sequence of one to six octets using UTF-8 encoding, and the encoding -- of each of those octets as "%" followed by two characters from the -- character set above. The two characters give the hexadecimal ++ representation of that octet. The percentage glyph _itself_ is encoded ++ as an octed index into the UTF-8 representation. As an aside; could someone more knowledgable than me add something about normalization of the UTF-8 string; as this does aid the encoding when a user is allowed to enter a URN from a keyword with other keys than than those corresponding to the symbols of . -- Namespaces whose object identifiers do not have a mapping to an -- information conveying representation SHOULD use a base64 encoding -- of the binary encoded identifier. -- Namespaces MAY designate one or more characters from the URN -- character set as having special meaning for that namespace (An -- example of this is the "%" character in the URN syntax itself). If -- the namespace also uses that character in a literal sense as well, -- the character used in a literal sense MUST be encoded with "%" -- followed by the hexadecimal representation of that octet. Therefore, -- the process of registering a namespace identifier shall include -- publication of a definition of which characters have a special -- meaning and how to encode these characters if used in a literal ++ sense. Likewise if glyph ambiguity does not allow for UTF8 encoding ++ the publication should outline the possible ambiguity and ++ representations possible for display. By the way; I do feel quite strong about glyph ambiguity and the ability to encode arbritary strings. I would even be happier if each name scheme essnetially defined _ITSELF_ what glyph encoding it uses; and only suggest extremly strongly that UTF is the way to go. But that the bottom line is that: ++ The URN is a sequence of glyphs taken from the . It is ++ represented by an octed stream with the only the values of the ++ indexes of the glyphs in UTF-8. A glyph or symbol encoded, ++ entered, stored, displayed or conveyed which is not in this limited ++ range, for examply with an UTF-8 encoding, is purely based on the ++ mutual understanding of the publishing and utilizing party; but is ++ not to be used to represent the URN. The above needs to be tackled anyway, somewhere; unless I missed the place in the current draft which tells us which is really the authorative representation (between machines :-) of the beast. (Ignoring normalziaiton,etc). Well, Merry Chrismass, Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA00538 for urn-ietf-out; Fri, 20 Dec 1996 13:19:54 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA00533 for ; Fri, 20 Dec 1996 13:19:51 -0500 Received: from shell1.aimnet.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22003 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 13:19:49 -0500 Received: from localhost (dwm@localhost) by shell1.aimnet.com (8.8.4/SHELL) with SMTP id KAA16026; Fri, 20 Dec 1996 10:16:10 -0800 (PST) Date: Fri, 20 Dec 1996 10:16:10 -0800 (PST) From: "David W. Morris" X-Sender: dwm@shell1.aimnet.com To: "Ron Daniel Jr." Cc: urn-ietf@bunyip.com Subject: Re: [URN] Checksums in URNs In-Reply-To: <199612201718.KAA02118@acl.lanl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "David W. Morris" Errors-To: owner-urn-ietf@bunyip.com On Fri, 20 Dec 1996, Ron Daniel Jr. wrote: > My preference would be to NOT require checksums in all URNs. > I rather like Larry's suggestion of a wrapper like > ck:the-checksum:the-uri I like the clean elegance of the checksum wrapper as a general solution ... but I'm having a hard shaking the notion that having a checksum built in to the URN would vastly improve the reliability of URNs over time. My current feeling is that ck: is good and should be done as it can apply for URLs of all kinds. AND URNs should have provision for a built in checksum which MUST be supported by all conforming UAs, Transfer Agents, etc. but MAY be used in any specific URN. In either case, part of the design MUST consider how the feature will be used by humans ... I think that means that the syntax of ck: and a URN form if allowed needs to support linear white space insertion in the URL/URN at arbitrary points. Dave Morris Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA29886 for urn-ietf-out; Fri, 20 Dec 1996 12:41:49 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA29881 for ; Fri, 20 Dec 1996 12:41:47 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21692 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 12:41:41 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AB12310; Fri, 20 Dec 96 18:47:06 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA15559; Fri, 20 Dec 1996 18:41:13 +0100 Date: Fri, 20 Dec 1996 18:41:13 +0100 (MET) From: Dirk.vanGulik@jrc.it X-Sender: dirkx@elect6.jrc.it To: "Ron Daniel Jr." Cc: urn-ietf@bunyip.com Subject: Re: [URN] Checksums in URNs In-Reply-To: <199612201718.KAA02118@acl.lanl.gov> Message-Id: Reply-Path: Dirk.vanGulik@jrc.it Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Dirk.vanGulik@jrc.it Errors-To: owner-urn-ietf@bunyip.com Although I can see the appeal of checksummed URN's; I would be more interested implemeting them with a (commercial:-) type of referall system; say the 'nice and easy' service peole urn:nae:580064875 to just give an example of a 9-code protected string. This URN can be N2N-ed by a nice-and-easy service (currently sitting on port 6080 of elect6.jrc.it) which will either give you the URN lodged with it (through elect6.jrc.it:8080/nae.html) or an HTML page explaining that you've got it wrong and the most likely alternative(s). As URNs mature I do thing there is room for the 'friendly-name- lodger' service and I do not know how many other people perfectly willing to service you with nice namespaces which just have that competive edge to your company/project. This is what is made possible in the URN architecture (or at least in my private idea of it) it; and this is what thus should be used to 'grandfather' in such ideas. Merry Chrismass to yee al by the way Dw. -- Live is fair to dutchmen; Sinterklaas comes round it on the fifth http://ewse.ceo.org http://enrm.ceo.org DWvGulik@Dialis.xs4all.nl Dirk.vanGulik@jrc.it +39 332 78 0014 +39 332 78 9549 fax +39 332 78 9185 ISEI/ESBA; The Center For Earth Observation Joint Research Centre of the European Communities, Ispra, Italy On Fri, 20 Dec 1996, Ron Daniel Jr. wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > Mime-Version: 1.0 > Content-Type: text/plain > Content-Transfer-Encoding: 7bit > > To: urn-ietf@bunyip.com > Date: Fri Dec 20 10:28:01 1996 > My preference would be to NOT require checksums in all URNs. > I rather like Larry's suggestion of a wrapper like > ck:the-checksum:the-uri > > > Ron Daniel Jr. email: rdaniel@lanl.gov > Advanced Computing Lab, MS B287 voice: +1 505 665 0597 > Los Alamos National Laboratory fax: +1 505 665 4939 > Los Alamos, NM, USA 87545 http://www.acl.lanl.gov/~rdaniel > Want to buy: "Five Laws of Library Science" by S.R. Ranganathan > -----BEGIN PGP SIGNATURE----- > Version: 2.6.2 > > iQB1AwUBMrrMoTOY2EydG1XFAQHdlgMA20ZcisvDDGG4yz4AJ7c4wMtiz4kwE1R5 > uzWotqHhTTgrkjuUPe0r38bxlFiyu5W+lgaHsSFbrnS+IpfMRclpgwmrW3sNclYc > x/4+Yz8d0u/4qomFaMRJcyZMwQNKLyuY > =7+Oc > -----END PGP SIGNATURE----- > > Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA29665 for urn-ietf-out; Fri, 20 Dec 1996 12:18:47 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA29660 for ; Fri, 20 Dec 1996 12:18:41 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21515 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 12:18:39 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA02118 for ; Fri, 20 Dec 1996 10:18:36 -0700 (MST) Date: Fri, 20 Dec 1996 10:18:36 -0700 (MST) Message-Id: <199612201718.KAA02118@acl.lanl.gov> From: "Ron Daniel Jr." To: urn-ietf@bunyip.com X-Priority: Normal Subject: Re: [URN] Checksums in URNs X-Mailer: Pronto Secure [Ver 1.12] X-Prontosecureinfo: T=signed, P=x-pgp Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com -----BEGIN PGP SIGNED MESSAGE----- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: urn-ietf@bunyip.com Date: Fri Dec 20 10:28:01 1996 My preference would be to NOT require checksums in all URNs. I rather like Larry's suggestion of a wrapper like ck:the-checksum:the-uri Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab, MS B287 voice: +1 505 665 0597 Los Alamos National Laboratory fax: +1 505 665 4939 Los Alamos, NM, USA 87545 http://www.acl.lanl.gov/~rdaniel Want to buy: "Five Laws of Library Science" by S.R. Ranganathan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMrrMoTOY2EydG1XFAQHdlgMA20ZcisvDDGG4yz4AJ7c4wMtiz4kwE1R5 uzWotqHhTTgrkjuUPe0r38bxlFiyu5W+lgaHsSFbrnS+IpfMRclpgwmrW3sNclYc x/4+Yz8d0u/4qomFaMRJcyZMwQNKLyuY =7+Oc -----END PGP SIGNATURE----- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA22341 for urn-ietf-out; Fri, 20 Dec 1996 09:35:19 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA22301; Fri, 20 Dec 1996 09:34:23 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19208 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 09:34:20 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 20 08:32 CST 1996 Message-Id: <32BAA368.4FD2@ds.internic.net> Date: Fri, 20 Dec 1996 08:32:08 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: "Martin J. Duerst" Cc: Towsner , Larry Masinter , leslie@bunyip.com, tme@CasA.usno.navy.mil, urn-ietf@bunyip.com, jcurran@bbn.com, uri@bunyip.com Subject: Re: [URN] Checksums in URNs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com My turn to add my two cents worth... Martin J. Duerst wrote: > > On Thu, 19 Dec 1996, Towsner wrote: > > > >Checksums and other kinds of decorations can be done outside the > > >URL. Think of it as a metascheme: > > > ck: > > > e.g. ck:A3Bd:http://www.parc.xerox.com/masinter > > > > I like the idea of having the checksum be optional, as a > > meta-scheme. > > Same for me. I'll make three... > >I also think the checksum should be limited to alpha-numeric > > characters, to avoid confusion. > > What do you mean by "limited to alpha-numeric characters"? Can you be > more precise. How about just hex characters to keep it simple... > >Perhaps this should be part of the URL > > scheme as well. > > If it is a metascheme, then it is a new URI scheme. It doesn't > have to be discussed either in URL nor in URN syntax. It would > go into a separate draft. It has to make sure, on its own, > that it is compatible with the URL/URN syntax. I agree with Martin, and if we use ck: then we are already compatible with the URL/URN character sets. How to generate the hex sequence is another headache altogether... > Perhaps the URL syntax draft, where it speaks about URIs, > could be generalized in the direction of metaschemes. > From the syntax viewpoint, we already have two metaschemes > (urn: and ck:), which can even be combined together, > as ck:urn:namespace:NSS. Martin is correct here as well. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA22265 for urn-ietf-out; Fri, 20 Dec 1996 09:30:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA22260 for ; Fri, 20 Dec 1996 09:30:47 -0500 Received: from yscydion.ansa.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19191 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 09:30:44 -0500 Received: by yscydion.ansa.co.uk; Fri, 20 Dec 96 14:30:01 GMT Received: by plato.ansa.co.uk; Fri, 20 Dec 96 14:30:00 GMT To: dirkx%elect2@dicsmss1.jrc.it Cc: "Ronald E. Daniel" , urn-ietf@bunyip.com Subject: Re: [URN] HTTP conventions draft References: From: Toby Speight Mime-Version: 1.0 (generated by *modified* tm-edit 7.43) Content-Type: text/plain (PGP signed); charset=US-ASCII Date: 20 Dec 1996 14:29:59 +0000 In-Reply-To: dirkx%elect2@dicsmss1.jrc.it's message of Thu, 19 Dec 1996 17:21:59 +0100 (MET) Message-Id: Lines: 49 Organization: ANSA - APM Ltd. X-Mailer: Gnus v5.3/Emacs 19.32 X-Author-Info: X-Pgp-Id: 0xABBDC46D (from servers or author-info) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Toby Speight Errors-To: owner-urn-ietf@bunyip.com -----BEGIN PGP SIGNED MESSAGE----- Dirkx> dirkx >>>>> In article , >>>>> Dirkx wrote: Dirkx> On Wed, 20 Nov 1996, Ronald E. Daniel wrote: Ron> If the client has requested the result be returned as text/html Ron> or application/html, the result should be encoded as: Ron> Ron> where the strings ...url n... are replaced by the n'th URL in the Ron> list. Dirkx> Given the fact that you can ask for a machine parsable list, the Dirkx> above seems superfluous and tooo easy to get wrong. I would prefer Dirkx> to just kill it; as it does little extra in (machine parsable) Dirkx> functionality. I think we should keep a recommendation that servers ought to be prepared to return types other than a URI list (text/html and text/plain, perhaps?) even if the format isn't specified. IOW, we ought to ensure that we can send something human-parsable, at least until text/uri-list is ubiquitous. I think Ron's suggestion is fine, if the word "should" is used in the usual IETF strict sense of "not broken if it doesn't do this, and shouldn't be relied upon, but ought to do it if there's no good reason not to." -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBMrqi2+dsuUurvcRtAQFrPwMAj1uY12LYIis9/ChPKw3w0zKqej2liFI1 GkE/6CX4/wt3Lz4aPNCSftCWCX8ml3hTPbws3jMEbJD8dQAso5J5cB0PJwhVwn49 8tghQ6Q7t9gMeGuSXFghnm5Tb/0xDuhY =9skI -----END PGP SIGNATURE----- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA21302 for urn-ietf-out; Fri, 20 Dec 1996 08:14:32 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA21297; Fri, 20 Dec 1996 08:14:30 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18882 (mail destined for uri@services.bunyip.com); Fri, 20 Dec 96 08:13:52 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <06235-0@josef.ifi.unizh.ch>; Fri, 20 Dec 1996 14:13:27 +0100 Date: Fri, 20 Dec 1996 14:13:25 +0100 (MET) From: "Martin J. Duerst" To: Towsner Cc: Larry Masinter , leslie@bunyip.com, tme@CasA.usno.navy.mil, urn-ietf@bunyip.com, jcurran@bbn.com, uri@bunyip.com Subject: Re: [URN] Checksums in URNs In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Thu, 19 Dec 1996, Towsner wrote: > >Checksums and other kinds of decorations can be done outside the > >URL. Think of it as a metascheme: > > ck: > > e.g. ck:A3Bd:http://www.parc.xerox.com/masinter >=20 > =09I like the idea of having the checksum be optional, as a > meta-scheme. Same for me. >I also think the checksum should be limited to alpha-numeric > characters, to avoid confusion. What do you mean by "limited to alpha-numeric characters"? Can you be more precise. >Perhaps this should be part of the URL > scheme as well. If it is a metascheme, then it is a new URI scheme. It doesn't have to be discussed either in URL nor in URN syntax. It would go into a separate draft. It has to make sure, on its own, that it is compatible with the URL/URN syntax. Perhaps the URL syntax draft, where it speaks about URIs, could be generalized in the direction of metaschemes. From=20the syntax viewpoint, we already have two metaschemes (urn: and ck:), which can even be combined together, as ck:urn:namespace:NSS. Regards,=09Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA13062 for urn-ietf-out; Thu, 19 Dec 1996 20:36:04 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA13057 for ; Thu, 19 Dec 1996 20:36:02 -0500 Received: from germany-c.it.earthlink.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15769 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 20:36:00 -0500 Received: from [153.35.78.27] (Cust15.Max18.Boston.MA.MS.UU.NET [153.35.78.15]) by germany.it.earthlink.net (8.7.5/8.7.3) with ESMTP id RAA18448; Thu, 19 Dec 1996 17:35:28 -0800 (PST) X-Sender: tows@mail.earthlink.net Message-Id: In-Reply-To: <96Dec19.160759pdt."150"@palimpsest.parc.xerox.com> References: <199612192243.RAA04511@beethoven.bunyip.com> (leslie@bunyip.com) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Dec 1996 20:41:24 -0500 To: Larry Masinter , leslie@bunyip.com From: Towsner Subject: Re: [URN] Checksums in URNs Cc: tme@CasA.usno.navy.mil, urn-ietf@bunyip.com, jcurran@bbn.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Towsner Errors-To: owner-urn-ietf@bunyip.com >Checksums and other kinds of decorations can be done outside the >URL. Think of it as a metascheme: > ck: > e.g. ck:A3Bd:http://www.parc.xerox.com/masinter I like the idea of having the checksum be optional, as a meta-scheme. I also think the checksum should be limited to alpha-numeric characters, to avoid confusion. Perhaps this should be part of the URL scheme as well. -- -Henry Towsner Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA12030 for urn-ietf-out; Thu, 19 Dec 1996 19:08:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA12025 for ; Thu, 19 Dec 1996 19:08:18 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15356 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 19:08:15 -0500 Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <14488(8)>; Thu, 19 Dec 1996 16:08:09 PST Received: by palimpsest.parc.xerox.com id <150>; Thu, 19 Dec 1996 16:07:59 PDT To: leslie@bunyip.com Cc: tme@CasA.usno.navy.mil, urn-ietf@bunyip.com, jcurran@bbn.com In-Reply-To: <199612192243.RAA04511@beethoven.bunyip.com> (leslie@bunyip.com) Subject: Re: [URN] Checksums in URNs From: Larry Masinter Message-Id: <96Dec19.160759pdt."150"@palimpsest.parc.xerox.com> Date: Thu, 19 Dec 1996 15:07:59 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com Checksums and other kinds of decorations can be done outside the URL. Think of it as a metascheme: ck: e.g. ck:A3Bd:http://www.parc.xerox.com/masinter Does anyone have a 2 character (or, perhaps a 4 character, 24-bit base64) checksum scheme they'd propose? To interpret a checksum URL, just strip off the ck & checksum. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA10805 for urn-ietf-out; Thu, 19 Dec 1996 17:43:32 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA10800 for ; Thu, 19 Dec 1996 17:43:29 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14701 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 17:43:18 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id RAA04511; Thu, 19 Dec 1996 17:43:17 -0500 Message-Id: <199612192243.RAA04511@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Thu, 19 Dec 1996 17:43:17 -0500 In-Reply-To: marshall eubanks's message as of Dec 18, 12:12 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: marshall eubanks , urn-ietf@bunyip.com Subject: [URN] Checksums in URNs Cc: jcurran@bbn.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com [Was: Re: [URN] Re[2]: Article re San Jose IETF in Sunday San Francisco paper] [Marshall Eubanks wrote:] > > Maybe URN's should include a check-sum or the like to make sure that > > it has been copied/typed correctly, much as crdit cards numbers, etc., > > do. This could even be in the URN label (as in, URN[XX]:yyyy, where > > XX is a 2 character ascii code based on the yyyy field). The web > > engine could then compare yyyy with XX and complain if they > > don't match. [...] > A reasonable goal might be to be able to detect 2 character errors, > and to correct one character errors. In principle, being able to distinguish between wrong names and evaporated resources seems like a good thing. I haven't seen any comments (yet) that suggest that it is felt to be out of scope. We are now on the verge of finalizing the URN syntax, etc, so we should evaluate whether this seems like a solid, reasonably-implemented idea. Things that need to be made clear: . whether this can be defined across _all_ URNs or is better hanlded by individual namespaces . is there _one_ checksumming standard that could be considered acceptable across _all_ URNs, now and forever, or else how do we identify which system was used for which URN? . how this would be handled in the rest of the URN resolution system (e.g., impacts on how NAPTR would handle URNs, etc) . how this would fit into the proposed syntax If somebody wants to propose concrete answers to these issues, we can see about getting consensus about moving on this... Leslie. -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA00836 for urn-ietf-out; Thu, 19 Dec 1996 11:24:10 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA00829 for ; Thu, 19 Dec 1996 11:24:00 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10744 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 11:23:56 -0500 Received: from jrc.it (elect2.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA21953; Thu, 19 Dec 96 17:29:21 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA13570; Thu, 19 Dec 1996 17:21:59 +0100 Date: Thu, 19 Dec 1996 17:21:59 +0100 (MET) From: dirkx%elect2@dicsmss1.jrc.it To: "Ronald E. Daniel" Cc: urn-ietf@bunyip.com Subject: Re: [URN] HTTP conventions draft In-Reply-To: <199611202031.NAA29358@magenta.acl.lanl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: dirkx%elect2@dicsmss1.jrc.it Errors-To: owner-urn-ietf@bunyip.com On Wed, 20 Nov 1996, Ronald E. Daniel wrote: > I've changed the conventions draft to remove the integer from the > text/uri-list media type. The new version is appended. I will > send this to the ID editor later today. > > INTERNET DRAFT Ron Daniel > draft-ietf-urn-http-conventions-00.txt Los Alamos National Laboratory > 13 Nov, 1996 > > > Conventions for the Use of HTTP for URN Resolution > ... > If the client has requested the result be returned as text/html or > application/html, the result should be encoded as: > > where the strings ...url n... are replaced by the n'th URL in the list. > Given the fact that you can ask for a machine parsable list, the above seems superfluous and tooo easy to get wrong. I would prefer to just kill it; as it does little extra in (machine parsable) functionality. Just a minor one :-) Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA27145 for urn-ietf-out; Thu, 19 Dec 1996 10:36:03 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA27131; Thu, 19 Dec 1996 10:35:54 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10263 (mail destined for uri@services.bunyip.com); Thu, 19 Dec 96 10:35:48 -0500 Received: by privateer.windrose.omaha.ne.us; Thu Dec 19 09:34 CST 1996 Message-Id: <32B9606C.702E@ds.internic.net> Date: Thu, 19 Dec 1996 09:34:04 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: "Martin J. Duerst" Cc: Leslie Daigle , uri@bunyip.com, urn-ietf@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Martin J. Duerst wrote: > > We don't want a HTML parser or something similar to need separate code > for parsing URLs and URNs. It should be able to deal with URNs as one > URL scheme, syntactically. It looks like that is possible, but I have > to admit that I am no regex expert. > While I am not a regex expert either, there seem to me some obvious issues here, which I have tried to address with comments on where changes need to be made: 1. Can a URL parser handle the "urn::" leader for URNs properly? Having looked at the "greedy" algorithm and the Regular Expression in the URL draft, I can say that the first part is sufficient to pick up the scheme as "urn:". If we take the approach in comment 3 below, then the URL spec should note that (a) schemes may well have ":" in them or (b) a scheme beginning with "urn:" is treated as an opaque URL because it is really a URN (ITEM FOR URL DRAFT). 2. The URN and URL character sets are not currently aligned well. ("Well" means that there are characters allowed for URLs that are not allowed for URNs). There are currently (by my counting), two characters allowed in the URN char set that are not allowed in the URL char set: "\" and "%". I don't have a problem with moving the "\" to the excluded set for URNs (ITEM FOR URN DRAFT) "%" is also part of the URN char set only to ensure that the definition for the end of a URN is clean. It's sole purpose is to introduce an escape sequence for an octet (a literal "%" must be encoded as %25). I am strengthening the language in the URN syntax draft with respect to the "%" issue. (ITEM FOR URN DRAFT) 3. There is no specification of structure for a URN NSS. The only way to handle this through a URL parser is for the URL parser to declare the URN as an "opaque-URL" and do no processing on it. This specification (if done) must be done in the URL document (ITEM FOR URL DRAFT). If we do these things, I think we've cleaned up the problem. I am currently moving the "\" character to the excluded region of the URN character set. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA26267 for urn-ietf-out; Thu, 19 Dec 1996 09:57:13 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA26243; Thu, 19 Dec 1996 09:56:34 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09870 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 09:55:13 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <11442-0@josef.ifi.unizh.ch>; Thu, 19 Dec 1996 15:26:52 +0100 Date: Thu, 19 Dec 1996 15:26:51 +0100 (MET) From: "Martin J. Duerst" To: Leslie Daigle Cc: Ryan Moats , uri@bunyip.com, urn-ietf@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... In-Reply-To: <199612182324.SAA04077@beethoven.bunyip.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Wed, 18 Dec 1996, Leslie Daigle wrote: > It looks like the following questions are on the table: > > . should URN and URL syntaxes be consistent? I guess we have to ask "to what extent should they be consistent". Definitely, allowing something such as ">" in URNs, while they are used to delimit URLs, would be a very bad idea. On the other hand, the fact that the octets represented (with %HH in the canonical form) in URNs are interpreted as UTF-8 should not at the moment force URLs to suddenly convert to UTF-8 (quite difficult), but should not on the other hand scare URLs away from making the necessary preparations to get better i18n facilities and try to move in the direction of UTF-8. (more on that later). > . if yes, which should now change: > > . URLs cannot, because of legacy support, although > there is the issue of "I18N" > > . URNs "can", except that the existing syntax was > built for specific reasons to address issues that > have concerned URNs more than URLs (e.g., bringing > in other namespaces and addressing multiple language > issues). > > > Is it "desirable" that URN syntax be compliant with URL syntax, or "required"? > What _breaks_ if it is not? We don't want a HTML parser or something similar to need separate code for parsing URLs and URNs. It should be able to deal with URNs as one URL scheme, syntactically. It looks like that is possible, but I have to admit that I am no regex expert. > [Ryan quotes from the URL draft:] > > > > > > Although this specification restricts its discussion to URLs, the > > > syntax defined is that of URI in general. Any requirements placed on > > > the URL syntax also apply to the URI syntax. This uniform syntax for > > > all resource identifiers allows a URN to be used in any data field > > > that might otherwise hold a URL. > > This draft is for the _URL_ syntax, and this is the only paragraph that > lays claim to all of URI syntaxes. But it lays claims for all of the URL document, or at least a large part of it. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA25509 for urn-ietf-out; Thu, 19 Dec 1996 09:10:44 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA25504 for ; Thu, 19 Dec 1996 09:10:41 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09579 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 09:10:39 -0500 Received: by privateer.windrose.omaha.ne.us; Thu Dec 19 08:09 CST 1996 Message-Id: <32B94C92.AA7@ds.internic.net> Date: Thu, 19 Dec 1996 08:09:22 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Michael Carroll Cc: urn-ietf@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... References: <9612190027.AA06740@mocha.bunyip.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Michael Carroll wrote: > > It might be better for us to describe the current task as specifying > *a* syntax for URNs, rather than *the* syntax for URNs. This would > clearly suggest the possibility that there will be other syntaxes > later. The other syntaxes may use characters from nonroman > character sets; perhaps mappings will be specified from one syntax > to another. Wait a minute. We've hashed this out already. Nonroman character sets are handled via UTF-8 and %encoding. I really don't want to re-open this. Having multiple syntax definitions (IMHO) can be considered a root of a lot of the current URL troubles. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA21360 for urn-ietf-out; Thu, 19 Dec 1996 01:11:52 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA21355 for ; Thu, 19 Dec 1996 01:11:49 -0500 Received: from proxy2.ba.best.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08196 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 01:11:47 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.8.4/8.8.3) with SMTP id WAA24552 for ; Wed, 18 Dec 1996 22:09:36 -0800 (PST) Date: Wed, 18 Dec 1996 22:09:35 -0800 (PST) From: "Gregory J. Woodhouse" To: urn-ietf@bunyip.com Subject: [URN] permanence Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com I've mostly kept silent on this matter because it seems rather late in the game to discuss this kind of issue, but I have to agree that permanence is best viewed as an implementation decision rather than a matter of policy. Okay, that calls for some explanation. Ideally, I would like to think of URNs as *abstract* names for resources, and I have to think that is what they are intended to be. URLs encode specific information about which servers store the information and wht specific requests are necessary to retriewve the resource. URNs, on the other hand, encode no such information, and this is the sense in which they are abstract. Of course, permanence is a side effect of abstractness (and very much an intended one!) By analogy, if the implementation of a class is modified, objects which instantiate that class or its descendants need not be aware of the change. Similarly, if a resource is moved, documents which reference it via a URN need not be modified. Okay, okay, that's all very obvious, and it may seem pointless say as much here, but it seems that using permanence as the defining characteristic of URNs has been the source of a lot of confusion. --- gjw@wnetc.com / http://www.wnetc.com/home.html If you're going to reinvent the wheel, at least try to come to come up with a better one. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA21109 for urn-ietf-out; Thu, 19 Dec 1996 00:36:00 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA21104 for ; Thu, 19 Dec 1996 00:35:52 -0500 Received: from shell1.aimnet.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07859 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 00:35:48 -0500 Received: from localhost (dwm@localhost) by shell1.aimnet.com (8.8.4/SHELL) with SMTP id VAA02042; Wed, 18 Dec 1996 21:31:39 -0800 (PST) Date: Wed, 18 Dec 1996 21:30:57 -0800 (PST) From: "David W. Morris" X-Sender: dwm@shell1.aimnet.com To: "Martin J. Duerst" Cc: marshall eubanks , urn-ietf@bunyip.com Subject: Re: [URN] Re: Re[2]: Article re San Jose IETF in Sunday San Francisco paper In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "David W. Morris" Errors-To: owner-urn-ietf@bunyip.com On Wed, 18 Dec 1996, Martin J. Duerst wrote: > On Wed, 18 Dec 1996, marshall eubanks wrote: > > know that it is typo free if it comes back as "not found." Credit > > card numbers and the like include redundancy for exactly that reason. > > A reasonable goal might be to be able to detect 2 character errors, > > and to correct one character errors. > > As far as I understand URNs (I was mainly involved in their i18n > aspects), their most important property is permanence. This means > that if you have an URN that is "not found", by the virtue of > knowing it being an URN, you know that it's misspelled. That is a circular argument .... permanence is a point of design here not a point of policy. Hence, while the mechanism will allow a URN to be resolved forever, it doesn't guarantee that it will be. So I think the suggestion is quite useful. You really can't tell if it is misspelled or the archives burned down. If you knew it was mispelled, it might be worth attempting other means to figure out what was meant while if it wasn't mispelled, then the resource is gone and one is out of luck. Having a URN checksum/crc/md5 to detect typos and an internal self checking feature is redundancy but so what. The internet protocols are rampant with examples of redundancy between layers and I surely wouldn't expect a client to know how to validate every variation of ISBN but it could be expected to validate a URN. Dave Morris Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA18792 for urn-ietf-out; Wed, 18 Dec 1996 19:27:19 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA18787 for ; Wed, 18 Dec 1996 19:27:17 -0500 Received: from rlg.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06740 (mail destined for urn-ietf@services.bunyip.com); Wed, 18 Dec 96 19:27:12 -0500 Message-Id: <9612190027.AA06740@mocha.bunyip.com> Date: Wed, 18 Dec 96 16:27:02 PST From: "Michael Carroll" To: urn-ietf@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Michael Carroll" Errors-To: owner-urn-ietf@bunyip.com It might be better for us to describe the current task as specifying *a* syntax for URNs, rather than *the* syntax for URNs. This would clearly suggest the possibility that there will be other syntaxes later. The other syntaxes may use characters from nonroman character sets; perhaps mappings will be specified from one syntax to another. If we look at it this way, I think it's not even desirable that all syntaxes for URNs comply with requirements on "the" (existing) syntax for URLs. It's just desirable that the first URN syntax comply. I don't know of anything that breaks if it doesn't. I agree "now is a logical time" to separate these things out. Michael -- Michael Carroll Research Libraries Group br.mjc@rlg.org To: URN-IETF@BUNYIP.COM Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA18303 for urn-ietf-out; Wed, 18 Dec 1996 18:24:22 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA18298; Wed, 18 Dec 1996 18:24:20 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06453 (mail destined for uri@services.bunyip.com); Wed, 18 Dec 96 18:24:19 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id SAA04077; Wed, 18 Dec 1996 18:24:18 -0500 Message-Id: <199612182324.SAA04077@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Wed, 18 Dec 1996 18:24:18 -0500 In-Reply-To: Ryan Moats's message as of Dec 18, 9:11 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Ryan Moats , uri@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com It looks like the following questions are on the table: . should URN and URL syntaxes be consistent? . if yes, which should now change: . URLs cannot, because of legacy support, although there is the issue of "I18N" . URNs "can", except that the existing syntax was built for specific reasons to address issues that have concerned URNs more than URLs (e.g., bringing in other namespaces and addressing multiple language issues). Is it "desirable" that URN syntax be compliant with URL syntax, or "required"? What _breaks_ if it is not? [Ryan quotes from the URL draft:] > > > > Although this specification restricts its discussion to URLs, the > > syntax defined is that of URI in general. Any requirements placed on > > the URL syntax also apply to the URI syntax. This uniform syntax for > > all resource identifiers allows a URN to be used in any data field > > that might otherwise hold a URL. This draft is for the _URL_ syntax, and this is the only paragraph that lays claim to all of URI syntaxes. It was written before there was a concrete proposal for URNs. I think the URL syntax RFC would be quite complete _without_ this paragraph. The URL syntax is going to face its own battles as the issues of character sets and languages are brought up -- it seems like now is a logical time to separate out the evolution of these two things, _unless_ there are some very concrete things that will break if they are not kept consistent. Cheers! Leslie. -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA15029 for urn-ietf-out; Wed, 18 Dec 1996 13:23:05 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA15010; Wed, 18 Dec 1996 13:22:21 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03878 (mail destined for urn-ietf@services.bunyip.com); Wed, 18 Dec 96 13:22:06 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <02348-0@josef.ifi.unizh.ch>; Wed, 18 Dec 1996 19:21:07 +0100 Date: Wed, 18 Dec 1996 19:21:06 +0100 (MET) From: "Martin J. Duerst" To: Ryan Moats Cc: uri@bunyip.com, urn-ietf@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... In-Reply-To: <32B80993.5785@ds.internic.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Wed, 18 Dec 1996, Ryan Moats wrote: > Folks- > > I was reminded this morning that there is a potential inconsistency > between the URL and URN syntax specifications > (draft-fielding-url-syntax-02.txt and draft-ietf-urn-syntax-01.txt). > Because of this, I am cross-posting this to both lists, so I apologize > to those folks that will see this multiple times (I know I will...) I have noticed this inconsistency, too, and am glad Ryan brought it up. > The inconsistency arises from the following: > > In the URL syntax draft the following statement is made: > > > 1.1. URL, URN, and URI > > > > URLs are a subset of Uniform Resource Identifiers (URI), which also > > includes the notion of Uniform Resource Names (URN). A URN differs > > from a URL in that it identifies a resource in a location-independent > > fashion (see RFC 1737, [10]). URNs are defined by a separate set of > > specifications. > > > > Although this specification restricts its discussion to URLs, the > > syntax defined is that of URI in general. Any requirements placed on > > the URL syntax also apply to the URI syntax. This uniform syntax for > > all resource identifiers allows a URN to be used in any data field > > that might otherwise hold a URL. > > However, in the latest draft URN syntax spec (circulating on the urn > mailing list), the syntax for a URN is > > > "urn:" ":" > > I don't beleive that the URN specification "can be used in any data > field that might otherwise hold a URL" as it currently stands (If > somebody thinks otherwise, please let me know). Therefore, either the > syntax specs need to be aligned or the statements about the URL > specification refering to the URI syntax need to be modulated > (neither of which are pleasant topics...). My current preference > is to modulate the URL syntax specification to support the URN syntax > and move forward. I think there is very much to be gained from URLs and URNs being syntactically alligned. Currenty, it looks to me as if this is the case; the "urn" part is a , and everything after that is scheme-specific. The greedy algorithm (Section 4.4) and the exclusion of ":" in schemes assures that this parsing will be done correctly. The treatment of reserved characters could cause some problems, however. To allow substitution of "%7E" by "~" (URL, 2.2/2.3.2) while that character is not available on many keyboards is problematic. Therefore, that aspect has to be reconsidered anyway. The URL draft also does not agree with the URN draft on i18n issues. I18N in URLs is a large topic, and I hope to get the time tomorrow to comment on its treatment in the URL draft. In the context of this thread, it is at least required that consequences in these differences are analysed/understood, and that there is language in the URL draft (given it is kept to be responsible for URIs in general) that the syntax alignement does not include these issues. This most probably should be done with a general statement explaining what exactly is covered, and what not, by "uniform syntax". Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA14475 for urn-ietf-out; Wed, 18 Dec 1996 12:38:10 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAB14470 for ; Wed, 18 Dec 1996 12:38:07 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03439 (mail destined for urn-ietf@services.bunyip.com); Wed, 18 Dec 96 12:38:04 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <00633-0@josef.ifi.unizh.ch>; Wed, 18 Dec 1996 18:37:38 +0100 Date: Wed, 18 Dec 1996 18:37:37 +0100 (MET) From: "Martin J. Duerst" To: marshall eubanks Cc: urn-ietf@bunyip.com Subject: [URN] Re: Re[2]: Article re San Jose IETF in Sunday San Francisco paper In-Reply-To: <"josef.ifi..634:18.11.96.17.15.27"@ifi.unizh.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Wed, 18 Dec 1996, marshall eubanks wrote: > > Maybe URN's should include a check-sum or the like to make sure that > > it has been copied/typed correctly, much as crdit cards numbers, etc., > > do. This could even be in the URN label (as in, URN[XX]:yyyy, where > > XX is a 2 character ascii code based on the yyyy field). The web > > engine could then compare yyyy with XX and complain if they > > don't match. > > I was thinking here about the case where URN's could be very "cold." > If I get a URL from someone today, and it's wrong, I can generally > re-inquire, hunt around using search engines, etc. If I find a > URN in (say) a 2 year old mail message, it might be very nice to > know that it is typo free if it comes back as "not found." Credit > card numbers and the like include redundancy for exactly that reason. > A reasonable goal might be to be able to detect 2 character errors, > and to correct one character errors. As far as I understand URNs (I was mainly involved in their i18n aspects), their most important property is permanence. This means that if you have an URN that is "not found", by the virtue of knowing it being an URN, you know that it's misspelled. Another aspect of your proposal is that many namespaces, such as ISBN, already contain check-sums. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA14312 for urn-ietf-out; Wed, 18 Dec 1996 12:15:39 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA14307 for ; Wed, 18 Dec 1996 12:15:31 -0500 Received: from casa.usno.navy.mil by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03187 (mail destined for urn-ietf@services.bunyip.com); Wed, 18 Dec 96 12:15:19 -0500 Message-Id: <9612181715.AA03187@mocha.bunyip.com> Received: by CasA.usno.navy.mil (1.37.109.16/16.2) id AA184529177; Wed, 18 Dec 1996 12:12:57 -0500 Date: Wed, 18 Dec 1996 12:12:57 -0500 From: marshall eubanks To: mduerst@ifi.unizh.ch, urn-ietf@bunyip.com Subject: [URN] Re[2]: Article re San Jose IETF in Sunday San Francisco paper Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: marshall eubanks Errors-To: owner-urn-ietf@bunyip.com I sent the following to the general IETF list, not the URN list, by mistake. It concerns an idea I had after the problems that various people had with a URL given in a mail message to the IETF : > Maybe URN's should include a check-sum or the like to make sure that > it has been copied/typed correctly, much as crdit cards numbers, etc., > do. This could even be in the URN label (as in, URN[XX]:yyyy, where > XX is a 2 character ascii code based on the yyyy field). The web > engine could then compare yyyy with XX and complain if they > don't match. I was thinking here about the case where URN's could be very "cold." If I get a URL from someone today, and it's wrong, I can generally re-inquire, hunt around using search engines, etc. If I find a URN in (say) a 2 year old mail message, it might be very nice to know that it is typo free if it comes back as "not found." Credit card numbers and the like include redundancy for exactly that reason. A reasonable goal might be to be able to detect 2 character errors, and to correct one character errors. Regards Marshall Eubanks tme@casa.usno.navy.mil Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA13410 for urn-ietf-out; Wed, 18 Dec 1996 11:04:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA13402; Wed, 18 Dec 1996 11:04:47 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02444 (mail destined for uri@services.bunyip.com); Wed, 18 Dec 96 11:04:41 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.2/8.8.2) with ESMTP id KAA01432; Wed, 18 Dec 1996 10:03:59 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id JAA04091; Wed, 18 Dec 1996 09:59:50 -0600 (CST) Date: Wed, 18 Dec 1996 09:59:50 -0600 (CST) Message-Id: <199612181559.JAA04091@void.ncsa.uiuc.edu> To: Ryan Moats Cc: uri@bunyip.com, urn-ietf@bunyip.com Subject: [URN] Potential inconsistency between URL and URN syntaxes... In-Reply-To: <32B80993.5785@ds.internic.net> References: <32B80993.5785@ds.internic.net> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Ryan Moats writes: > However, in the latest draft URN syntax spec (circulating on the urn > mailing list), the syntax for a URN is > > > "urn:" ":" > > I don't beleive that the URN specification "can be used in any data > field that might otherwise hold a URL" as it currently stands (If > somebody thinks otherwise, please let me know). I think otherwise. I don't see anything wrong with this syntax - consider that the scheme name for this whole class of URNs is called "urn", and thus "urn:" preceeds the rest of the identifier. You were not specific about what the nature of the conflict is. If "urn:" were optional (which is a subject still open for debate, I presume), we may have a conflict. The general URI syntax allows the ":" prefix to be optional, and more of the prefix can be left out, but then we might have a relative URI, which has different semantics. With no "urn:", the would actually function as the scheme name since it indicates how to interpret the . But this is true even with a required "urn:" prefix since we want URNs to be independent of the resolution mechanism. I'm not clear whether you believe URNs *should* be used in any data field that might otherwise hold a URL, independent of whether they in fact can. I believe they should. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12709 for urn-ietf-out; Wed, 18 Dec 1996 10:12:47 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12704; Wed, 18 Dec 1996 10:12:44 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01880 (mail destined for uri@services.bunyip.com); Wed, 18 Dec 96 10:12:42 -0500 Received: by privateer.windrose.omaha.ne.us; Wed Dec 18 09:11 CST 1996 Message-Id: <32B80993.5785@ds.internic.net> Date: Wed, 18 Dec 1996 09:11:15 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: uri@bunyip.com Cc: urn-ietf@bunyip.com Subject: [URN] Potential inconsistency between URL and URN syntaxes... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Folks- I was reminded this morning that there is a potential inconsistency between the URL and URN syntax specifications (draft-fielding-url-syntax-02.txt and draft-ietf-urn-syntax-01.txt). Because of this, I am cross-posting this to both lists, so I apologize to those folks that will see this multiple times (I know I will...) The inconsistency arises from the following: In the URL syntax draft the following statement is made: > 1.1. URL, URN, and URI > > URLs are a subset of Uniform Resource Identifiers (URI), which also > includes the notion of Uniform Resource Names (URN). A URN differs > from a URL in that it identifies a resource in a location-independent > fashion (see RFC 1737, [10]). URNs are defined by a separate set of > specifications. > > Although this specification restricts its discussion to URLs, the > syntax defined is that of URI in general. Any requirements placed on > the URL syntax also apply to the URI syntax. This uniform syntax for > all resource identifiers allows a URN to be used in any data field > that might otherwise hold a URL. However, in the latest draft URN syntax spec (circulating on the urn mailing list), the syntax for a URN is > "urn:" ":" I don't beleive that the URN specification "can be used in any data field that might otherwise hold a URL" as it currently stands (If somebody thinks otherwise, please let me know). Therefore, either the syntax specs need to be aligned or the statements about the URL specification refering to the URI syntax need to be modulated (neither of which are pleasant topics...). My current preference is to modulate the URL syntax specification to support the URN syntax and move forward. Ryan Moats InterNIC Directory and Database Services Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA17646 for urn-ietf-out; Mon, 16 Dec 1996 16:50:54 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA17641 for ; Mon, 16 Dec 1996 16:50:48 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13020 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 16:48:58 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id QAA02687; Mon, 16 Dec 1996 16:48:57 -0500 Message-Id: <199612162148.QAA02687@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Mon, 16 Dec 1996 16:48:57 -0500 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: urn-ietf@bunyip.com Subject: [URN] DRAFT URN Meeting Minutes Cc: jcurran@bbn.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Well, rather than tearing apart case insensivity for a while longer, here's some more material to play with! These are the draft meeting minutes that Sally Hambridge put together for us (thanks Sally!). Overall, I think the meeting was quite successful, in that we covered several drafts, made a plan for what to do next, and seem to be making quite reasonable progress. I would appreciate corrections/comments from people who attended the meeting -- I intend to send the minutes in on Friday this week. Additionally, comments on the content (whether or not you made it to the meeting) are also welcomed. Cheers! Leslie. ================== Draft Minutes of the URN Working Group 37th IETF, San Jose, December 12, 1996 Group Co-Chairs: Leslie Daigle, leslie@bunyip.com John Curran, jcurran@bbn.com Minute-Meister: Sally Hambridge, Intel Leslie opened the meeting by reviewing the Charter and Milestones. Hot Spots in the milestones are: we lack a draft detailing N2L/N2R/etc resolution results. We will probably use Ron Daniel's HTTP conventions draft as a start on this milestone. We also need to submit a document describing one new namespace and a document which describes grandfathering in older naming schemes, as well as the Frameworks and Requirements draft. Karen Sollins presented the open issues with the current Frameworks and Requirements document: The document discusses the assumptions of longevity, delegation, and independence. The requirements fall in 3 major areas: Evolution, Usability, and Security. The framework looks like this: URN: | | Global NID registry | | | | | Private URN resolution service UDS server | | Private URN resolution service Karen includes a definition section which defines Local Resolution service - what transforms URNs into access to resources; Hints - information that helps to access the information; UDS - URN Resolution Service Discovery Service - how to find the right URN resolution service; HFN - Human friendly names. The Security area will discuss access control on hints; server authenticity; Server distribution (a countermeasure on denial of service attacks) and Privacy - the users from resolution services and for publishers for their clients and publications lists. Issues: Encouragement of separation of URNs from semantics - Efficiency as a goal or a requirement is in several places (documents) which need to be aggregated. - Whether there is a useful distinction to be made between long- term and short-term hints - Acceptance by potential providers of UDS services. Karen asked what's missing from the list of issues: Internationalization (i18n) should be covered one way or another. Name space ID - needs to be in a document but probably not this document. Ryan Moats presented the issues with the URN syntax ID: URN: should this be optional. Please see the later discussion on this for the consensus. NID syntax: Why not use numbers and "-". No reason - Ryan will change the draft. There was a suggestion for following the RFC for URLs on this, but it was pointed out that this document is currently undergoing a revision. NID namespace will have case insensitivity and add %escaping. The NSS may be case sensitive. URN Character set adds/deletes: Add "%" to the allowed character set and add a list of characters NOT part of the set to the draft. %escaping: Will be allowed for escaping of reserved characters in addition to characters outside the URN character set; and allow for %HH escaping to use either upper or lower case. Where does a URN end? At the first non-URN character set character. Equivalency: Are things the same when they point to the same resource? (Equivalency of resources was deemed to be a rathole). Leslie offered that a URN could point to a specific day's weather and another could refer to today's weather, and these were pointing to the same thing but were not equivalent. ROUGH CONSENSUS was reached that ONLY lexical equivalency will be covered in the draft. The namespace will have strict rules. For the Human readability - MUST/SHOULD the following text is being substituted: Any namespace (existing or newly-devised) that is proposed as a URN-namespace must be expressed in this syntax. If names in these namespaces contain characters other than those defined for the URN character set they must be translated into canonical form as discussed in section 2.2 Ron Daniel discussed the NAPTR draft. - There will be verbiage to state that records with unknown flags must be ignored. - The Pseudo-code has to go. - "R" Flag for treating Regex as "Raw" - Don't do "E" flag for encrypting Raw fields. Flag field reserves 0-9 for experimentation. The TFLag allows you to look for the same domain as I. ROUGH CONSENSUS was to allow people to create new flags however they want, but that if you see a flag you don't recognize you ignore it. There was a question of the references to other drafts, and John Curran said he would find out if the text RFC xxx could be written and if the RFC editor would insert the correct numbers. This draft will be going as an Experimental RFC. There was discussion about how the experimental status will effect DNS and the regex substitutions. We need to be explicit. We need to say how this doesn't overload DNS and how DNS security will help and where it won't. Also, there will probably be more than one discover service in the future and we don't want this one to be "The Standard". We need operational experience. The requiring resolution problem is not part of this draft. We will have one more revision on the mailing list, then this goes to Experimental. HTTP Conventions: Ron took this one too. - We need a simple resolver for testing, the goal is not Standards track. The goal is to use the conventions on encoding on requests and responses on http: GET /uri-res// HTTP 1.0 He will include % encoding, status codes, Accept: headers and other stuff from HTTP as appropriate. This allows cgi scripts to get names from files or directories, although they look ugly. Open Discussion: URN: There was a question of rough consensus on the problem of whether to require urn:. The room seems to indicate that urn: should be required on any part of the urn that was shipped around the Internet. Whether or not implementors would use urn: was left up to them for their own local products, but in transmission the urn: would be required. The problem with urn: seems to be at the user interface and user services level. Don't confuse human friendly names with internal representation. Documents: We need a URN dereferencing document to discuss the resolution service and the resolution system. These need the syntax (which is close) and the system requirements needs the framework (which is also close.) Assign URN - needs everything! We need namespace requirements. We need to have one new namespace and we need to bring in 1 existing namespace. We need to pay some attention to potential lawsuit issue. It is important for someone who has authority for the namespace to say how it works in URN. The proposal is for these to be experimental. Dun and Bradstreet is interested in working on this as soon as the syntax is ready. Clifford Lynch said that the NISO bibliographic IDs could move en masse. We can create a resolution system which can be used outside the URN space, but we need to make it work there first. Charter directions: * We need to get a grip on bringing in an existing namespace * We need a new namespace scheme * We need the Name space requirements document (to see whether DNS will or won't work) * We need to bring all the requirements from all sources into one place * We need to look at the process of creating new namespaces -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA17490 for urn-ietf-out; Mon, 16 Dec 1996 16:32:07 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA17485 for ; Mon, 16 Dec 1996 16:32:04 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12871 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 16:32:02 -0500 Received: by privateer.windrose.omaha.ne.us; Mon Dec 16 15:31 CST 1996 Message-Id: <32B5BF94.10A2@ds.internic.net> Date: Mon, 16 Dec 1996 15:31:00 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: "Martin J. Duerst" Cc: urn-ietf@bunyip.com, tows@earthlink.net Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Martin J. Duerst wrote: > > On Mon, 16 Dec 1996 jayhawk@windrose.omaha.ne.us wrote: > > > > >5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping > > > >are case insensitive. > > > Why is the NSS case sensitive? Most people are used to URL's which > > > are case insensitive. There would be a lot of confusion with people > > > ignoring caps, as well as allowing someone to take an NSS which is > > > identicle to another except for capitalization. (I think there was a > > > similar issue recently with URL's and the three letter classification.) > > > > I disagree that all URLs are case insensitive. Portions are, but then again, > > some portions aren't. > > See my example with a file name. In general, only the DNS part is > case insensitive. User id may be, may be not, password certainly > not, hierarchical part (filenames) certainly not, query part certainly > not. This makes URLs case sensitive: If you don't know the details > you better make sure you got it the right way, or it may point into > the void. This example works for me... > > Going back into my email archives (not as thorough as Bunyip's, but easier > > to get at, the syntax draft has always allowed individual namespaces to > > declare themselves as having a case-insensitive NSS, > > Is that mentionned specifically, or is it just due to the fact that > NSSs can declare any two names to be functionally equivalent? Yes. In section 5, the quote is "Some namespaces may define additional lexical equivalences, such as case-insensitivity of the NSS (or parts thereof)." Ryan P.S. I forgot where I was for my previous message, so please ignore that To: header. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA17428 for urn-ietf-out; Mon, 16 Dec 1996 16:27:33 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA17423 for ; Mon, 16 Dec 1996 16:27:30 -0500 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12847 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 16:27:26 -0500 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa15475; 16 Dec 96 16:26 EST Received: by skadhwe.lcs.mit.edu; (5.65v3.2/1.1.8.2/15Aug95-0306PM) id AA04046; Mon, 16 Dec 1996 16:26:53 -0500 Date: Mon, 16 Dec 1996 16:26:53 -0500 Message-Id: <9612162126.AA04046@skadhwe.lcs.mit.edu> From: Lewis Girod To: leslie@bunyip.com Cc: tows@earthlink.net, jayhawk@ds.internic.net, urn-ietf@bunyip.com In-Reply-To: <199612162102.QAA02633@beethoven.bunyip.com> (leslie@bunyip.com) Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com From: leslie@bunyip.com (Leslie Daigle) Date: Mon, 16 Dec 1996 16:02:28 -0500 There might be a better wording for this to suggest that the NSS is expected to be transported and interpreted literally. ... and that each namespace defines any relevant notions of lexical equivalence. Using NAPTR, this equivalence function is implemented within the regexps -- basically two different URNs generate the same domain name to look up. This may be used to express case insensitivity, as well as more complex equivalence functions. Also, since escaped characters are a syntax that applies to all NSS's, we can specify the hex characters encoding escaped characters to be case insensitive. - Lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA17295 for urn-ietf-out; Mon, 16 Dec 1996 16:18:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA17290 for ; Mon, 16 Dec 1996 16:18:55 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12763 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 16:18:48 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <29093-0@josef.ifi.unizh.ch>; Mon, 16 Dec 1996 22:18:31 +0100 Date: Mon, 16 Dec 1996 22:18:30 +0100 (MET) From: "Martin J. Duerst" To: jayhawk@windrose.omaha.ne.us Cc: urn-ietf@bunyip.com, tows@earthlink.net Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: <9612162043.AA12260@mocha.bunyip.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Mon, 16 Dec 1996 jayhawk@windrose.omaha.ne.us wrote: > > >5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping > > >are case insensitive. > > Why is the NSS case sensitive? Most people are used to URL's which > > are case insensitive. There would be a lot of confusion with people > > ignoring caps, as well as allowing someone to take an NSS which is > > identicle to another except for capitalization. (I think there was a > > similar issue recently with URL's and the three letter classification.) > > I disagree that all URLs are case insensitive. Portions are, but then again, > some portions aren't. See my example with a file name. In general, only the DNS part is case insensitive. User id may be, may be not, password certainly not, hierarchical part (filenames) certainly not, query part certainly not. This makes URLs case sensitive: If you don't know the details you better make sure you got it the right way, or it may point into the void. > Going back into my email archives (not as thorough as Bunyip's, but easier > to get at, the syntax draft has always allowed individual namespaces to > declare themselves as having a case-insensitive NSS, Is that mentionned specifically, or is it just due to the fact that NSSs can declare any two names to be functionally equivalent? >but that is not the > default. Further, there was some discussion that case-insensitivity would > have strange effects in the international arena (Martin, maybe you > can clarify this some more?) First, we would have to make sure that case-insensitivity also applies to accented characters, and to Greek, Cyrillic, and Armenian. Second, the question of whether to extend insensitivity to things similar, but not equivalent to case would come up (e.g. katakana and hiragana in Japanese). This is an actual point of discussion for SGML :-(. Third, casing can be different depending on language. The Turkish dotless I is the famous example. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA16937 for urn-ietf-out; Mon, 16 Dec 1996 16:02:34 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA16932 for ; Mon, 16 Dec 1996 16:02:32 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12577 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 16:02:31 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id QAA02633; Mon, 16 Dec 1996 16:02:30 -0500 Message-Id: <199612162102.QAA02633@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Mon, 16 Dec 1996 16:02:28 -0500 In-Reply-To: Towsner's message as of Dec 16, 14:59 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Towsner , Ryan Moats , urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com [Henry Towsner wrote:] > Why is the NSS case sensitive? Most people are used to URL's which > are case insensitive. There would be a lot of confusion with people > ignoring caps, as well as allowing someone to take an NSS which is > identicle to another except for capitalization. (I think there was a > similar issue recently with URL's and the three letter classification.) Don't forget that we are trying to architect something that will not preclude the incorporation of existing namespaces -- and many of those _are_ case sensitive. Also, "case sensitivity" is poorly defined when it comes to non-7-bit characters and non-English languages. There might be a better wording for this to suggest that the NSS is expected to be transported and interpreted literally. Leslie. -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA16854 for urn-ietf-out; Mon, 16 Dec 1996 15:57:27 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA16849 for ; Mon, 16 Dec 1996 15:57:23 -0500 Received: from proxy1.ba.best.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12480 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 15:57:09 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy1.ba.best.com (8.8.4/8.8.3) with SMTP id MAA06541; Mon, 16 Dec 1996 12:45:26 -0800 (PST) Date: Mon, 16 Dec 1996 12:45:26 -0800 (PST) From: "Gregory J. Woodhouse" To: Towsner Cc: Ryan Moats , urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com The NSS should be case sensitive. Think about URLs. The following are not equivalent: http://wherever.org/Folder/ http://wherever.org/folder/ I don't think case sensitivity in the NSS wil be any gret surprise with URNs. (Then again, I've never been much of a fan of case insensitivity, anyway.) --- gjw@wnetc.com / http://www.wnetc.com/home.html If you're going to reinvent the wheel, at least try to come to come up with a better one. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA16508 for urn-ietf-out; Mon, 16 Dec 1996 15:43:45 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA16497 for ; Mon, 16 Dec 1996 15:43:41 -0500 From: jayhawk@windrose.omaha.ne.us Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12260 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 15:43:35 -0500 Message-Id: <9612162043.AA12260@mocha.bunyip.com> Date: Mon, 16 Dec 96 14:42 CST To: urn-ietf@bunyip.com, tows@earthlink.net Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: jayhawk@windrose.omaha.ne.us Errors-To: owner-urn-ietf@bunyip.com > >5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping > >are case insensitive. > Why is the NSS case sensitive? Most people are used to URL's which > are case insensitive. There would be a lot of confusion with people > ignoring caps, as well as allowing someone to take an NSS which is > identicle to another except for capitalization. (I think there was a > similar issue recently with URL's and the three letter classification.) I disagree that all URLs are case insensitive. Portions are, but then again, some portions aren't. Going back into my email archives (not as thorough as Bunyip's, but easier to get at, the syntax draft has always allowed individual namespaces to declare themselves as having a case-insensitive NSS, but that is not the default. Further, there was some discussion that case-insensitivity would have strange effects in the international arena (Martin, maybe you can clarify this some more?) Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA16428 for urn-ietf-out; Mon, 16 Dec 1996 15:32:53 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA16423 for ; Mon, 16 Dec 1996 15:32:51 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12146 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 15:32:47 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <26999-0@josef.ifi.unizh.ch>; Mon, 16 Dec 1996 21:31:45 +0100 Date: Mon, 16 Dec 1996 21:31:43 +0100 (MET) From: "Martin J. Duerst" To: Towsner Cc: Ryan Moats , urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Mon, 16 Dec 1996, Towsner wrote: > >5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping > >are case insensitive. > Why is the NSS case sensitive? Most people are used to URL's which > are case insensitive. Looks like you are living on an MS-DOS box, or an IBM mainframe. Otherwise, create two files, just differing in captitalization, and try what you get with a file: URL. In case you file system is capitalizationwise challenged, and you still have difficulties believing me, I can set up two such files in our ftp directory :-). Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA16099 for urn-ietf-out; Mon, 16 Dec 1996 14:54:16 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA16094 for ; Mon, 16 Dec 1996 14:54:15 -0500 Received: from denmark-c.it.earthlink.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11518 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 14:54:09 -0500 Received: from [153.35.79.47] (Cust47.Max20.Boston.MA.MS.UU.NET [153.35.79.47]) by denmark.it.earthlink.net (8.7.5/8.7.3) with ESMTP id LAA18456; Mon, 16 Dec 1996 11:53:47 -0800 (PST) X-Sender: tows@mail.earthlink.net Message-Id: In-Reply-To: <32B56D9D.7B96@ds.internic.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Dec 1996 14:59:21 -0500 To: Ryan Moats , urn-ietf@bunyip.com From: Towsner Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Towsner Errors-To: owner-urn-ietf@bunyip.com >5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping >are case insensitive. Why is the NSS case sensitive? Most people are used to URL's which are case insensitive. There would be a lot of confusion with people ignoring caps, as well as allowing someone to take an NSS which is identicle to another except for capitalization. (I think there was a similar issue recently with URL's and the three letter classification.) -- -Henry Towsner Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA13366 for urn-ietf-out; Mon, 16 Dec 1996 10:42:59 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA13361 for ; Mon, 16 Dec 1996 10:42:55 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09436 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 10:42:43 -0500 Received: by privateer.windrose.omaha.ne.us; Mon Dec 16 09:41 CST 1996 Message-Id: <32B56D9D.7B96@ds.internic.net> Date: Mon, 16 Dec 1996 09:41:17 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: urn-ietf@bunyip.com Subject: [URN] Pre-release of draft-ietf-urn-syntax-02.txt Content-Type: multipart/mixed; boundary="------------4648506075BE" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com This is a multi-part message in MIME format. --------------4648506075BE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks- Apologies for jumping any traditional post-IETF "quiet time", but I would really like to try and move the syntax draft closer to draft standard. Attached is a pre-release of version -02. We managed to reach rough consensus on the open issues raised during the URN working group meeting, and so I've changed the syntax draft to note these agreements. I'm now looking for rough consensus from those folks on the mailing list that were not in San Jose. Ryan -----------Changes from the release draft are (in no particular order): 1. Various editing changes, and I've probably missed some, including cleaning up the modified BNF grammar. 2. The tag "urn:" is now required. There were several folks at San Jose that said that the absence of this tag would break things, while there was no one that said that the presence of this tag would break things. If someone has a situation were the presence will BREAK things (not just be inconvient) let the mailing list know! 3. The NID now allows letters and numbers. 4. The equivalence section only talks about lexical equivalence. Functional equivalence is namespace specific and is outside the scope of this document. 5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping are case insensitive. 6. "%" has been added to the URN character set. An explicit list of all octets not part of the URN character set has also been added (the "excluded character set". A URN ends with an octet that is part of the excluded character set. 7. "%"escaping is now allowed for reserved characters as well as characters not in the URN char set. 8. The two paragraphs in section 3 have been replaced with Leslie's suggestion to the mailing list. --------------4648506075BE Content-Type: text/plain; charset=us-ascii; name="urn.syntax.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="urn.syntax.txt" Internet-Draft Ryan Moats draft-ietf-urn-syntax-02.txt AT&T Expires in six months December 1996 URN Syntax Filename: draft-ietf-urn-syntax-02.txt Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers. This document sets forward the canonical syntax for URNs. Support for both existing legacy and new namespaces is discussed. Requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. 1. Introduction Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space. The URN syntax therefore provides a means to encode character data in a form that can be sent in existing protocols, transcribed on most keyboards, etc. Expires 5/19/97 [Page 1] INTERNET DRAFT URN Syntax December 1996 2. Syntax All URNs have the following syntax: ::= "urn:" ":" is the Namespace Identifier, and is the Namespace Specific String. The leading case-insensitive "urn:" sequence is required. The Namespace ID is used to determine the _syntactic_ interpretation of the Namespace Specific String (as discussed in [1]). RFC 1737 [2] presents additional requirements on URN encoding, which all have implications as far as limiting syntax. On the other hand, the requirement to support existing legacy naming systems has the effect of broadening syntax. Thus, we discuss the acceptable syntax for both the Namespace Identifier and the Namespace Specific String separately. 2.1 Namespace Identifier Syntax The following is the syntax for the Namespace Identifier. To (a) be consistent with all potential resolution schemes and (b) not put any undue constraints on any potential resolution scheme, the syntax for the Namespace Identifier is: ::= [ * ] ::= | | | "-" ::= | | ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" This is slightly more restrictive that what is stated in RFC 1738 [3] Expires 5/19/97 [Page 2] INTERNET DRAFT URN Syntax December 1996 (which allows the period "."). Further, the Namespace Identifier is case insensitive, so that "ISBN" and "isbn" refer to the same namespace. To avoid confusion with the "urn:" identifier, the NID "urn" is reserved and MUST NOT be used. 2.2 Namespace Specific String Syntax As required by 1737, there is a single canonical representation of the NSS portion of an URN. The format of this single canonical form follows: ::= * ::= | "%" ::= | | | ::= | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" ::= "(" | ")" | "+" | "\" | "," | "-" | "." | "/" | ":" | "=" | "?" | "@" | "%" Depending on the rules governing a namespace, valid identifiers in a namespace might contain characters that are not members of the URN character set above (). Such strings MUST be translated into canonical NSS format before using them as protocol elements or otherwise passing them on to other applications. Translation is done by encoding each character outside the URN character set as a sequence of one to six octets using UTF-8 encoding, and the encoding of each of those octets as "%" followed by two characters from the character set above. The two characters give the hexadecimal representation of that octet. Namespaces MAY designate one or more characters from the URN character set as having special meaning for that namespace (An example of this is the "%" character in the URN syntax itself). If the namespace also uses that character in a literal sense as well, the character used in a literal sense MUST be encoded with "%" followed by the hexadecimal representation of that octet. Therefore, the process of registering a namespace identifier shall include publication of a definition of which characters have a special meaning and how to encode these characters if used in a literal sense. Expires 5/19/97 [Page 3] INTERNET DRAFT URN Syntax December 1996 2.3 Excluded characters The following list is included only for the sake of completeness. Any octets/characters on this list are explicitly NOT part of the URN character set, and if used in a URN, MUST be %encoded: ::= octets 0-32 (0-20 hex) | "!" | """ | "#" | "$" | "&" | "'" | "*" | ";" | "<" | ">" | "[" | "]" | "^" | "_" | "`" | "{" | "|" | "}" | "~" | octets 127-255 (7F-FF hex) A URN ends when an octet/character from the excluded character set () is encountered. The character from the excluded character set is NOT part of the URN. 3. Support of existing legacy naming systems and new naming systems Any namespace (existing or newly-devised) that is proposed as a URN- namespace and fulfills the criteria of URN-namespaces MUST be expressed in this syntax. If names in these namespaces contain characters other than those defined for the URN character set, they MUST be translated into canonical form as discussed in section 2.2. 4. URN presentation and transport URN-aware applications MAY support "natural" display of URNs which contain characters encoded using "%" notation. However, they MUST provide for display of URNs in canonical form (i.e. in a format suitable for transcription). URNs MUST be transported in canonical format. 5. Lexical Equivalence in URNs For various purposes, such as caching, it is necessary to determine equivalence without actually resolving the URN. This done by testing for "lexical equivalence". Two URNs are lexically equivalent if they are octet-by-octet equal after the following preprocessing 1. normalize the case of the leading "urn:" token 2. normalize the case of the NID 3. normalizing the case of any "%" escaping Some namespaces may define additional lexical equivalences, such as case-insensitivity of the NSS (or parts thereof). Additional lexical equivalences MUST be documented as part of namespace registration, MUST always have the effect of eliminating some of the false negatives obtained by the procedure above, and MUST NEVER says that two URNs are not equivalent if the procedure above says they are equivalent. Expires 5/19/97 [Page 4] INTERNET DRAFT URN Syntax December 1996 6. Functional Equivalence in URNs Resolvers determine functional equivalence based on specific rules for the namespace. Therefore, namespace registration MUST include documentation on how to determine functional equivalence for that namespace. 7. Examples of equivalence The following URN comparisons highlight the difference between these types of equivalence: urn:isbn:1-23485-8-29, isbn:1-23485-8-29 are lexically equiv. urn:isbn:1-23485-8-29, ISBN:1-23485-8-29 are lexically equiv. urn:isbn:1-23485-8-29, isbn:123485829 are not lexically equiv. but may be functionally equivalent. 8. Security considerations This document specifies the syntax for URNs. While some namespaces resolvers may assign special meaning to certain of the characters of the Namespace Specific String, any security consideration resulting from such assignment are outside the scope of this document. It is strongly recommended that the process of registering a namespace identifier include any such considerations. 9. Acknowledgments Thanks to various members of the URN working group and <> for comments on earlier drafts of this document. This document is partially supported by the National Science Foundation. 10. References Request For Comments (RFC) and Internet Draft documents are available from and numerous mirror sites. [1] L. L. Daigle, P. Faltstrom, R. Iannella. "A Frame- work for the Assignment and Resolution of Uniform Resource Names," Internet Draft (work in progress). June 1996. [2] K. Sollins, L. Masinter. "Functional Requirements for Uniform Resource Names," RFC 1737. December 1994. Expires 5/19/97 [Page 5] INTERNET DRAFT URN Syntax December 1996 [3] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource Locators (URL)," RFC 1738. December 1994. 11. Editor's address Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA Phone: +1 402 894-9456 EMail: jayhawk@ds.internic.net This Internet Draft expires May 19, 1997. Expires 5/19/97 [Page 6] --------------4648506075BE-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA11110 for urn-ietf-out; Fri, 13 Dec 1996 01:24:45 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA11105 for ; Fri, 13 Dec 1996 01:24:42 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27540 (mail destined for urn-ietf@services.bunyip.com); Fri, 13 Dec 96 01:24:40 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id BAA01372 for urn-ietf@bunyip.com; Fri, 13 Dec 1996 01:24:40 -0500 Message-Id: <199612130624.BAA01372@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Fri, 13 Dec 1996 01:24:39 -0500 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: urn-ietf@bunyip.com Subject: [URN] URN WG Meeting -- summary Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com There was a URN WG meeting today (Dec 12/96) at the San Jose IETF. A brief summary of that session is attached -- minutes will follow in the next few days. .... The URN WG session included a discussion of the 4 current Internet drafts that we have (in generic terms, URN Discovery System Requirements & Framework, URN Syntax, NAPTR, and HTTP Conventions for URN Resolution). A few issues were identified with each document, and consensus was felt on most of them. Therefore, URN Syntax, NAPTR and HTTP Conventions will go through one more quick editing phase before being circulated on the mailing list and (barring further issues) submitted for consideration as RFCs. The System Requirements document is younger and will be restructured before calling for discussion on particular items. Volunteers were sought and obtained for tackling the URN Namespace Requirements document, and also proposed namespaces for grandfathering. To everyone's amazement, we accomplished this with the minimum of discussion and were done in 1 1/2 hours. Hurrah! Leslie. -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA19810 for urn-ietf-out; Fri, 6 Dec 1996 12:39:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA19770 for ; Fri, 6 Dec 1996 12:39:44 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19984 (mail destined for urn-ietf@services.bunyip.com); Fri, 6 Dec 96 12:39:37 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA14507 for ; Fri, 6 Dec 1996 10:39:35 -0700 (MST) Message-Id: <2.2.32.19961206174827.00707594@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Dec 1996 10:48:27 -0700 To: urn-ietf@bunyip.com From: Ron Daniel Subject: [URN] comments on Sollins' requirements draft Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Hi all, Some notes w.r.t. Karen Sollins' recent draft on URN Resolution Requirements and Framework. This is a little long, but maybe you can read it on the flight to San Jose. For those who have not yet learned how to sleep on flights, this should cure you of *that* problem. :-) ==== Notes on Conformance of the NAPTR Proposal to URN Resolution Requirements Karen Sollins has recently issued the first draft of a requirements document for URN Resolution Services. To provide feedback to her for subsequent versions of that draft, I have tried to document how the NAPTR resolution proposal does or does not meet those requirements. I'll confess to being a little ...difficult... :-) and deliberately taking advantage of what I perceived to be ambiguities in the requirements. This accounts for the "NAPTR is the greatest thing in the world" tone of much of my responses. The point is to try to push on the requirements as hard as possible to see where they might be weaker than desired. Where I have knowingly done so I have made an attempt at honesty by including a notes section that explains what I think is the real intent of the requirement and how NAPTR would or would not meet it. The notes section may also contain critiques of the requirement in general. General Comments: ================= I think Karen has done something good by noting that we have resolver discovery services (her UDS acronym) as opposed to resolvers. I would like to see the requirements made more explicit on which sort of service they apply to. The draft collects the requirements into summaries at the end of each section. That was found very useful and my comments key off of the summaries. I have added some numbers on the requirements to make it easier to refer to particular ones. I would like to see the draft use a numbering scheme. I found it confusing on pg. 6 where one paragraph starts off "Lastly..." and the next paragraph starts off "Second, ...". Requirements on Evolution (sec. 3.1) (3.1.1.a) Support for a growing set of URN schemes ================================================== The NAPTR proposal supports growth in the number of URN schemes (namespaces). New namespaces, X, may be added to X.urn.net and rules for their resolution established. (3.1.1.b) Support for new local URN resolution schemes ====================================================== The NAPTR proposal directly supports the evolution of URN resolution schemes through the "services" field in the NAPTR record. Multiple NAPTR records may be associated with a namespace to handle the period of transition from one resolution protocol to another. Notes: I was unclear on the use of the term "local" in the summary statement of the requirement. It did not appear in the narrative explanation of the requirement. The requirement is ambiguous. I can, I think, reasonably interpret it as I did in the answer above. However, I believe that Karen's intent was that there be an evolutionary path away from the NAPTR UDS approach itself, not just the resolver protocols "discovered" by the NAPTR approach. Assuming that was Karen's intent, I still think NAPTR meets the requirement. My intent is that NAPTR resolution be used as a fallback approach when a client does not have a specific handler for a namespace or URL protocol. This allows alternate resolution mechanisms to be used on a namespace by namespace basis. When a replacement UDS for NAPTR arises, there is no difficulty in making it the resolver of last resort instead of NAPTR, and in configuring clients so they only use NAPTR for namespaces not yet serviced by the new UDS. (3.1.1.c) Support for new authentication schemes: ================================================= The authentication schemes supported by the individual resolution protocols are outside the bounds of the NAPTR spec. The NAPTR UDS itself can utilize the recent DNSSEC work to build authentication mechanisms when desired. Any authentication needs not addressable through the DNSSEC framework can be addressed by defining a new DNS resource record, or by using a special convention on existing records such as TXT. Notes: The narrative for this requirement was not especially helpful. While the previous two requirements had narratives that could be shortened, this one needs some more explanation. (3.1.1.d) Support for alternative UDS schemes active simultaneously =================================================================== The notes for 3.1.1.b explain how NAPTR does not preclude alternative UDS schemes and shows one way in which a client can use multiple UDS schemes at the same time. (3.1.2) Support and encourage the evolution toward the separation of global identification from short-lived, locally useful, or human friendly semantics ======================================================================== The NAPTR proposal supports the resolution of identifiers from namespaces without the visible inclusion of resolution-system-specific hints such as domain names. Notes: "Support" is OK, but the "and encourage" is a bit much. Terry Allen has already commented on how this requirements document goes well beyond the URN Requirements document in terms of deprecating human- friendly names. I agree with he and Stu - we should take no position on the friendliness of names. If they can be made unique, persistent, and location-independent, that should be good enough for us. The narrative never makes a clear statement of the requirement. It only appears in the summary. (3.1.3) To support the development and deployment of pricing models to manage human behavior with respect to limited resources. ====================================================================== The NAPTR proposal allows fee-for-resolution systems to be deployed using the access controls on resolvers. The details of such controls are outside the bounds of the NAPTR spec. New namespces will almost certainly incurr the $50/yr. domain name registration fee. Notes: This requirement is *far* too strong. Prices are not the only way to control user behavior, assuming it needs to be controlled. This requirement should say nothing stronger than resolvers not precluding the possibility of payment being one of many possible controls on access to resolution info. 3.2 Usability and Feature Set Requirements 3.2.1 (The publisher) (3.2.1.a) URN to hint resolution must be correct and efficient ============================================================== The NAPTR proposal supports the efficient location of resolvers because of the highly caching nature of DNS. Correctness of that information is provided by the normal operation of DNS. In cases demanding unusually high guarrantees of correctness, the recent DNSSEC work can be used to provide signatures on the NAPTR responses. Efficiency of the resolvers themselves is outside the bounds of the NAPTR spec, but the NAPTR spec does help in making efficient resolution possible since it allows reslovers to be replicated through the use of the SRV record. Notes: We have no definition of "efficient" and "inefficient" so it is impossible to evaluate conformance to this requirement on an objective basis. I'll engage in subjective arguments with the best of 'em. You need an objective criteria to which you can point and say "put up or shut up". (3.2.1.b) Publishers must be able to select among URN resolution services to locate their resources ========================================================================= NAPTR directly supports this requirement through the use of the "services" field and multiple NAPTR records. Notes: The narrative goes beyond the requirement summary and says that the selection must be easy. How do we quantify that? The narrative also imposes a requirement not in the summary, that changing resolution services SHOULD NOT be expensive for the publisher. What is and is not expensive? (Adding a new NAPTR record is not, in itself, an expensive operation. What kind of fees might be imposed are impossible for the spec to address). (3.2.1.c) Publishers must be able to arrange for multiple access points for their location information. ======================================================================= The NAPTR proposal supports multiple resolvers through the SRV record. Notes: The narrative and the summary are quite different. The summary says "location information" while the narrative talks about "resources". The narrative also says services SHOULD be prepared to tailor responses based on the entity making the query and uses local caches as an example. The NAPTR proposal can accomodate these as well. Multiple locations for resources is handled by the resolvers, but the details are outside the bounds of the NAPTR spec. Tailored responses are also a resolver problem, but can be handled using existing technology. (3.2.1.d) Publishers must be able to provide for both long-lived and short-lived hints ================================================================ The NAPTR proposal allows for hint lifetime to be communicated using DNS TTLs, or resolution-method-specific lifetime information. (e.g. HTTP Expires: headers). Notes: The requirement seems to assume that a distinction must be drawn between short-term and long-term hints. I do not see this as being necessary. Is it not more important that publishers be able to communicate the expected lifetime of a hint and we not impose some artificial short/long distinction? Why not short/medium/long or really-really-really short//////etc. (3.2.1.e) It must be relatively easy for publishers to install and observer [sic] their hint information and any security constraints they need for their hints. ================================================================== The NAPTR proposal meets this requirement. (well, I blush a *little* when I say that, but I digress). Hint information held on resolvers is outside the bounds of the NAPTR proposal, but we expect that the hint information on resolvers will be held in databases that can be maintained using normal practice. Access to those databases will be through particular resolution protocols. Maintaining and monitoring the security imposed by those resolution protocols is outside the bounds of the NAPTR spec, and outside the bounds of the resolution protocol specs as well. The hint information within the bounds of the NAPTR spec are the NAPTR resource records used to find resolvers. That information is relatively small and is expected to not change frequently. Editing zone files is not the job of the publisher, but of the managment, so we will get to that part of the requirement later I'm sure. Monitoring the correct provision of information can be easily achieved, either through the use of nslookup or through the use of ultra-friendly front ends around nslookup. (Recent work on dynamic update will make the construction of ultra-friendly front ends possible so direct zone file editing can be avoided). Notes: "relatively easy" is not quantifiable. Therefore, I don't blush *too* much when I say that editing a zone file meets the requirement. Isn't installation of hint info a requirement for the resolver managers, not the publishers? publishers should be able to provide the necessary info about new resources to the management, but they don't need to install the hints themselves. (3.2.2) Client requirements Generic note - it took awhile for me to figure out that "client" meant "user-agent", not "user". A change in terminology might be nice. (3.2.2.a) The interface to the UDS must be simple, effective, and efficient. ============================================================================ The current NAPTR library has a simple, effective, and efficient interface. Notes: (OK, OK, proof by assertion is not a recognized logical technique. :-) The API for out NAPTR library is pretty simple, init_resolution() and get_next_resolver(). However, that API is outside the bounds of the NAPTR spec. Any number of APIs could be developed that provide access to the information from the NAPTR records. As I have been told repeatedly in other contexts, the IETF rarely standardizes APIs. In this case I think that is certianly the right policy, because I don't think we know enough about the space of possible UDS systems to develop an API that will work with all of them in a useful fashion. If we are not going to standardize an API, I don't think we should be setting requirements on them. (3.2.2.b) The client and client applications must be able to understand the information stored in and provided by the UDS, in order to be able to make informed choices. ======================================================================== The NAPTR proposal supports this requirement, since the results coming back clearly indicate the services offered by a resolver and the protocol necessary to communicate with the resolver. Notes: Shouldn't this really be a requirement on the resolvers rather than the UDS? The HTTP Conventions approach would still meet it since results are tagged with media types. The last paragraph in the section on client requirements does not state any requirements and might be moved to the assumptions section. (3.2.2.c) I would add a requirement that the info returned from the UDS to the client (and the resolver to the client) must be capable of evolving over time without the wholesale replacement of the UDS or resolution protocol. (3.2.3) Management requirements (3.2.3.a) The managment of hints must be as unobtrusive as possible, avoiding using too many network resources. ===================================================================== Managing hints in NAPTR records is local to the zone containing that record and is therefore unobtrusive. Notes: this seems kind of vague (3.2.3.b) A pricing scheme may be necessary to provide not only cost recovery, but also social incentives and disincentives to encourage certain sorts of behavior deemed necessary to meet other requirements. ====================================================================== I've already addressed this in 3.1.3, haven't I? Notes: This is not a well-stated requirement. How about "resolution service providers may use pricing schemes or other means of access control"? I still think you are pushing too hard for pricing. It is a policy issue, and the technical issues for UDS requirments are not to preclude it. (3.2.3.c) The configuration and verification of configuration of individual UDS servers must be simple enough not to discourage configuration and verification. ================================================================ It is possible to configure and verify NAPTR resource record information. Notes: How can I evaluate conformance to this requirement? My friends and I can write NAPTR records and we can use our debug client to make sure we get to the machine we think we are going to get to. Is that good enough? The last sentence of the narrative for this requirement imposes another requirement - one that I urge you to remove. The sentance says: "[...] encouraging volunteer participants REQUIRES that, as with the DNS, such volunteers can feel confident about the service they are providing and its benefit to both themselves and the rest of the community". How can we evaluate conformance to such a requirement? (3.3) Security and Privacy requirements Oh boy. While there are other parts of the draft I don't like, I find chunks of this section unacceptable. The requirements in this section have the implicit effect of mandating a security policy across all URN resolvers and UDS'. This policy will be too strong for some sites and too weak for others. My most vociferous objection is to the last sentence of the first paragraph: "Therefore we believe that the benefit of providing integrity guarantees beyond those provided by the servers themselves does not outweight the cost". You can't make that decision for me! There are people at my site who are *very* interested in integrity guarantees. I know because I have talked to them. Whether they will remain interested once they see the true cost is for *them* to decide. This requirements document has no business requiring or precluding any security measures. What it must do is operate under the assumption that there is some site out there with NO security, and that vicious hackers have totally had their way with that site. It must then be possible for sites that wish to be totally paranoid about security to resolve a URN to the resource in such a fashion that they can 1) Be assured that it has not been compromised or 2) Be able to determine that at least one of the steps in the resolution process can not be guranteed to be safe, and that any use of the resource is at their own risk. That is all that can be done. Any attempt to mandate that all sites obey some minimal level of security is flawed. Its an instance of the "everyone is my friend" assumption. This implicit establishment of the security policy that must be obeyed by URN resolvers shows up in several other places. There are many sentences where you say that something "must" exist which I would like to change to saying "must be capable of supporting". For example you say that "There needs to be an authoritative version of each hint, and it must support change control limited only to those principals with the right to modify it". I would prefer a different wording: "Each resolution hint shall have an authoritative instance. It must be possible to restrict changes to the authoritative hint according to the security policy of the organization issuing the hint. Propagation of changes to the authoritative version to any sites mirroring it must be capable of being carried out in a fashion consistent with the security policy governing the operation of the mirroring service." (Actually, I would prefer something less awkward, but I digress. :-) Its not that the former is hard to achieve, requiring root access to edit a zone file meets the letter of the requirement. The problem is that it precludes certain modes of operation. You and I may think that those modes of operation are only for idiots, but we are not the ones making the cost/benefit calculations. I also disagree with some of your threat analysis. For example, you are concerned about packet sniffers violating user's privacy and state that it can be "combatted by anonymizing queries through a trusted, fairly local gateway, although it involves an extra step and another potential bottleneck". This becomes the requirement "Client privacy is threatened by packet sniffing and server logging. It is desirable to reduce these threats as much as possible". The most likely scenario for snooping involves an employer monitoring employee's traffic for appropriate use. So, the people most likely to run the "anonymizing gateway" are the ones most likely to be analyzing the requests. (I can point to at least one example of an organization that monitors HTTP requests and does random sampling of incoming GIFs for obvious reasons). Your requirement stating that it is desirable to reduce such threats takes a position counter to the U.S. legal precedent that employers have the right to do such monitoring. That is one reason I keep harping on not mandating a security policy. Whose side should we take on such an issue? Anyway, since this message is already so long, and since I disagree so strongly with the security requirements, I'm going to stop here. We can iterate on the requirements a few times. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA04535 for urn-ietf-out; Wed, 4 Dec 1996 13:52:19 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA04530 for ; Wed, 4 Dec 1996 13:52:17 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00439 (mail destined for urn-ietf@services.bunyip.com); Wed, 4 Dec 96 13:52:14 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id LAA08669 for ; Wed, 4 Dec 1996 11:52:08 -0700 (MST) Message-Id: <2.2.32.19961204190058.006f1218@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Dec 1996 12:00:58 -0700 To: urn-ietf@bunyip.com From: Ron Daniel Subject: [URN] FPIs as a URN Namespace Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Hi, At the Montreal BOF, I suggested FPIs (ISO Formal Public Identifiers) as one of the namespaces that would be of interest for grandfathering into the URN world. Recently I've started working on just how to accomplish such a feat. Although I am not ready to issue an internet draft of the subject, people may want to take a look at some notes I've put together on the topic. They are at http://www.acl.lanl.gov/URN/FPI-URN.html If time allows we may discuss this at the WG meeting next week. Later, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA21212 for urn-ietf-out; Wed, 4 Dec 1996 04:46:01 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA21199 for ; Wed, 4 Dec 1996 04:45:58 -0500 Received: from aun.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19000 (mail destined for urn-ietf@services.bunyip.com); Wed, 4 Dec 96 04:45:55 -0500 Received: from dale.uninett.no (actually MACFAY.terena.nl) by aun.uninett.no with SMTP (PP); Wed, 4 Dec 1996 10:45:22 +0100 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id XAA03644; Tue, 3 Dec 1996 23:25:52 +0100 From: Harald.T.Alvestrand@uninett.no To: Ron Daniel Cc: urn-ietf@bunyip.com Subject: Re: [URN] some more NAPTR edits In-Reply-To: Your message of "Wed, 27 Nov 1996 13:18:25 MST." <2.2.32.19961127201825.00d31a90@acl.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <3640.849651951.1@dale.uninett.no> Date: Tue, 03 Dec 1996 23:25:51 +0100 Message-Id: <3642.849651951@dale.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com Ron, I think encrypted NAPTR records are a Bad Idea. The reason is that I can't figure out where to put the information about which key to use. You may have to specify that the key is identified by the replacement field, with the raw data in the regexp field, in which case the semantics is different from "R", and you might as well make E exclusive with R. or something else......key handling is the bane of encryption systems. Harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA08087 for urn-ietf-out; Tue, 3 Dec 1996 17:43:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA08082 for ; Tue, 3 Dec 1996 17:43:48 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA05282 (mail destined for urn-ietf@services.bunyip.com); Tue, 3 Dec 96 17:43:47 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id RAA27946 for urn-ietf@bunyip.com; Tue, 3 Dec 1996 17:43:47 -0500 Message-Id: <199612032243.RAA27946@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Tue, 3 Dec 1996 17:43:46 -0500 In-Reply-To: Leslie Daigle's message as of Dec 3, 16:56 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: urn-ietf@bunyip.com Subject: Re: [URN] Getting ready for next week's meeting... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Thanks to Ron for being eagle-eyed and catching the error -- he has been involved in many of the drafts, but not all of them! > . URN Framework and Requirements [Ron 15] This should, of course, be . URN Framework and Requirements [Karen 15] Leslie. -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA07707 for urn-ietf-out; Tue, 3 Dec 1996 16:56:29 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA07702 for ; Tue, 3 Dec 1996 16:56:26 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04665 (mail destined for urn-ietf@services.bunyip.com); Tue, 3 Dec 96 16:56:25 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id QAA27889 for urn-ietf@bunyip.com; Tue, 3 Dec 1996 16:56:24 -0500 Message-Id: <199612032156.QAA27889@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Tue, 3 Dec 1996 16:56:24 -0500 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: urn-ietf@bunyip.com Subject: [URN] Getting ready for next week's meeting... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com As some of the draft-editors have been asking about length of timeslots on the agenda for next week's meeting, it seems a good time to propose a refined view of that agenda and a Plan. The refined view (with time assignments) is attached. The basic plan is to give everybody air time to discuss issues with individual drafts. Of course, since all attendees WILL have read the drafts (:-) I am asking that draft-editors focus on preparing themselves for _issues_, and not use their valuable time for reviewing material that should already be familiar. What I propose, then, is that each draft-editor arrive prepared with: . a _very_ brief overview of the draft . a list of known issues with the draft . a list of proposed solutions to those issues (if any) . a sense of humour What I think we can walk away from the meeting with is: . some proposed solutions to issues . a (hopefully finite) list of issues that remain to be addressed with each draft . a plan for addressing the remainder of our chartered work (i.e., documents, volunteers :-) In order to make this all work smoothly, I suggest that, if you have issues-as-yet-unaired with a particular draft, rather than harbouring them until next week's meeting and springing them on unsuspecting editors, how about at least listing them now? (on the mailing list, or to the editors directly). There isn't a lot of time at the meeting, so if we can use it for solid discussion instead of trying to reach understanding over terminolory in describing issues, that would be great. For starters, let me know if there are any comments on the proposed agenda... Cheers! Leslie. ---------------------------------------- IETF URN Working Group ---------------------------------------- Agenda for Thursday, December 12, 1996 (9h00-11h30), San Jose, California. Status review: [10 minutes] . Status of documents . Progress on WG milestones Discussion of document-specific issues: [90 minutes] . URN Framework and Requirements [Ron 15] . URN Syntax [Ryan 15] . NAPTR proposal [Ron and/or Michael 15] . HTTP conventions [Ron 15] . General issues across drafts/flex time [30] Where to go from here: [30 minutes] . other issues . addressing remaining documents -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA10226 for urn-ietf-out; Sun, 1 Dec 1996 11:32:29 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA10217 for ; Sun, 1 Dec 1996 11:32:26 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17202 (mail destined for urn-ietf@services.bunyip.com); Sun, 1 Dec 96 11:32:23 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id IAA08428 for ; Sun, 1 Dec 1996 08:30:40 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id IAA20816 for urn-ietf@bunyip.com; Sun, 1 Dec 1996 08:31:01 -0800 (PST) Date: Sun, 1 Dec 1996 08:31:01 -0800 (PST) From: Terry Allen Message-Id: <199612011631.IAA20816@ishtar.fsc.fujitsu.com> To: urn-ietf@bunyip.com Subject: [URN] Compliance in Framework draft Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com This message is about compliance requirements as stated in the framework draft. I think compliance requirements, clearly stated, are a good thing. Compliance is mentioned several times, most notably in the two sections excerpted below (it would be good to have a distinct section specifically on compliance): | Abstract: | | This document addresses the issues of the discovery of local URN | resolution services that in turn will directly translate URNs into | URLs and URCs. The document falls into three major parts, the | assumptions underlying the work, the requirements in order to be a | viable URN-resolution-service discovery service or UDS, and a | framework for designing UDSs. The requirements fall into three major | areas: evolvability, usability, and security and privacy. A UDS that | is compliant with the framework will not necessarily be compliant with | the requirements. Compliance with the requirements will need to be | validated separately. [ ... ] | 4. The Framework | | With these assumptions and requirements in mind, one can conclude with a | general framework within which UDS designs will fall. As stated | earlier, although this framework is put forth as a suggested guide for | UDS designers, compliance with it will in no way guarantee compliance | with the requirements. Such an evaluation must be performed separately. | It is also understood that there may be UDS services that do not meet | the requirements in clearly identified ways. This may be true | especially with early plans and experiments. For example, although a | careful threat analysis may have been done to understand security | requirements, not all those security requirements may be addressed, in | order to use existing facilities to allow for early deployment for | experimentation purposes. All such lack of compliance should be clearly | documented. It emerges from these sections that those offering UDSs should document lack of compliance with the requirements, which I take to be the bulletted items listed in extract form at the end of this message. Let's think about the requirements in the light of this compliance requirement. How is a vendor to make meaningful comment on the following (a short selection): | * To support the development and deployment of pricing models to | manage human behavior with respect to limited resources. | e) It must be relatively easy for publishers to install and | observer their hint information and any security constraints | they need for their hints. | a) The management of hints must be as unobtrusive as possible, | avoiding using too many network resources; | * Broad availability of servers will reduce the thread to denial | of service; Can I as a client or user expect to obtain useful information wrt those points from a vendor's documentation? I'd expect no more than "yeah, we can do that" and "sure, our system is relatively easy and unobtrusive". When you think of it this way, does it not appear that many of the requirements are desiderata for a well functioning Internet in general, and need not be listed among the requirements for UDSs specifically? EXCERPTED LIST OF REQUIREMENTS | 3. Requirements [ ... ] | 3.1 Evolution [ ... ] | In summary, the requirements in the area of evolvability are: | | * To support evolution of mechanisms, specifically for | a) a growing set of URN schemes; | b) new local URN resolution schemes; | c) new authentication schemes; | d) alternative UDS schemes active simultaneously; | * To support and encourage the evolution toward the separation of | global identification from short-lived, locally useful, or human | friendly semantics; | * To support the development and deployment of pricing models to | manage human behavior with respect to limited resources. | | 3.2 Usability and Feature Set Requirements [ ... ] | To summarize, the usability requirements fall into three areas based on | participation in hint management and discovery: | | * The publisher | a) URN to hint resolution must be correct and efficient; | b) Publishers must be able to select among URN resolution | services to locate their resources; | c) Publishers must be able to arrange for multiple access points | for their location information; | d) Publishers must be able to provide for both long-lived and | short-lived hints; | e) It must be relatively easy for publishers to install and | observer their hint information and any security constraints | they need for their hints. | * The client | a) The interface to the UDS must be simple, effective, and | efficient; | b) The client and client applications must be able to understand | the information stored in and provided by the UDS, in order | to be able to make informed choices. | * The management | a) The management of hints must be as unobtrusive as possible, | avoiding using too many network resources; | b) A pricing scheme may be necessary to provide not only cost | recovery, but also social incentives and disincentives to | encourage certain sorts of behavior deemed necessary to meet | other requirements; | c) The configuration and verification of configuration of | individual UDS servers must be simple enough not to | discourage configuration and verification. | | 3.3 Security and Privacy Requirements [ ... ] | trusts it not to be compromised. We can turn each of these into a | security goal. | | * ACCESS CONTROL ON HINTS: There needs to be an authoritative version of | each hint, and it must support change control limited only to those | principals with the right to modify it. The choice of who those | principals are or whether they are unlimited must be made by the | publisher of a hint. | | * SERVER AUTHENTICITY: Servers and clients must be able to learn the | identity of the servers with which they communicate. This will be a | matter of degree and it is possible that there will be more | trustworthy, but less accessible servers, supported by a larger | cluster of less authenticatable servers that are more widely | available. In the worst case, if the client receives what appears to | be invalid information, the client should assume that the hint may be | inaccurate and confirmation of the data should be sought from more | reliable but less accessible data. | | * SERVER DISTRIBUTION: Broad availability will provide resistance to | denial of service. It is only to the extent that the services are | available that they provide any degree of trustworthiness. In | addition, the distribution of services will reduce to vulnerability | of the whole community, by reducing the trust put in any single | server. This must be mitigated by the fact that to the extent trust | is based on a linked set of servers, if any one fails, the whole | chain of trust fails; the more elements there are in such a chain, | the more vulnerable it may become. [ ... ] | In summary, security and privacy requirements can be identified as some | degree of protection from threats: | | * It must be possible to create authoritative versions of a hint | with access to modification privileges controlled; | * It must be possible to determine the identity of servers or avoid | contact with unauthenticated servers; | * Broad availability of servers will reduce the thread to denial | of service; | * Client privacy is threatened by packet sniffing and server | logging. It is desirable to reduce these threats as much as | possible; | * It should be feasible for publishers to keep private certain | information such as an overall picture of the resources they are | publishing and the identity of their clients; | * Publishers should be able to restrict access to the resolution of | the URNs for the resources they publish, if they wish. Regards, 1997-010000666000003600000100000030724306277673170010623 0ustar wwwrunwww Received: from ietf.org by ietf.org id aa24163; 7 Jan 97 14:38 EST Received: from black-ice.cc.vt.edu by ietf.org id aa24082; 7 Jan 97 14:37 EST Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.4/8.8.4) with ESMTP id OAA14582; Tue, 7 Jan 1997 14:32:46 -0500 Message-Id: <199701071932.OAA14582@black-ice.cc.vt.edu> X-Mailer: exmh version 2.0beta 12/23/96 To: TurnerX Rentz Cc: ietf@ietf.org Subject: Re: RSVP Can't Handle Spikes?? In-Reply-To: Your message of "Tue, 07 Jan 1997 01:24:00 PST." Sender:ietf-request@ietf.org From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_1265497112P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Tue, 07 Jan 1997 14:32:45 -0500 Source-Info: From (or Sender) name not authenticated. --==_Exmh_1265497112P Content-Type: text/plain; charset=us-ascii On Tue, 07 Jan 1997 01:24:00 PST, TurnerX Rentz said: > Ok, let's look at URLs (http traffic) - they tend to be spiked, Lots > of graphics and then nothing. Document delivered. Done. > > My idea is this: Why can't we just make Kb small for HTTP traffic? Or not use RSVP at all. > RSVP Can't handle Spikes? Then why mess with it at all?? Unless I missed something, the intent is that the flow that *requested* the bandwidth is guaranteed (say) 30%, and everybody else gets to fight it out for the other 70%. Currently, some manual twiddling is needed to prevent total starvation (by overcommitting the link). What the article is saying is that once a flow says "I want to use RSVP and I want 27% of the bandwidth", RSVP will do a bad job of reacting if THAT flow suddenly asks for 49% of the bandwidth. Solution: use RSVP for videoconferencing and other long-lasting flows where the bandwidth used is fairly predicable, and DONT use RSVP for short bursty flows, like HTTP or SMTP or what have you. The fact that RSVP doesn't deal well with managing a flow that behaves according to the HTTP model is no more significant than the fact that if you buy a Maserati, you don't get a big trunk, or if you buy a minivan, you don't get high performance. --==_Exmh_1265497112P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMtKk2tQBOOoptg9JAQGCkAQAwnWehjDmunSacuRjj9qhqXdRb654Fb4O Cmxbz6Gv3t3n0lyHQqAgdHyN1u7Bb7ZplasjC/CO140SDiKseCVrUVEhP7KNOU4f 7rtbF1aoUNS0/DKmiBHFDY78gZFRhqka9MUO6ytBFOdrdCXljSxv5UIqXYyeUsig vJ0960fZLi8= =YpVE -----END PGP MESSAGE----- --==_Exmh_1265497112P--   Received: from ietf.org by ietf.org id aa25963; 7 Jan 97 15:05 EST Received: from zephyr.isi.edu by ietf.org id aa25653; 7 Jan 97 15:03 EST Received: from can.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 7 Jan 1997 11:59:06 -0800 Date: Tue, 7 Jan 97 12:00:19 PST Sender:ietf-request@ietf.org From: braden@isi.edu Posted-Date: Tue, 7 Jan 97 12:00:19 PST Message-Id: <9701072000.AA17715@can.isi.edu> Received: by can.isi.edu (4.1/4.0.3-6) id ; Tue, 7 Jan 97 12:00:19 PST To: ietf@ietf.org, TurnerX_Rentz@ccm.jf.intel.com Subject: Re: RSVP Can't Handle Spikes?? Source-Info: From (or Sender) name not authenticated. *> *> My idea is this: Why can't we just make Kb small for HTTP traffic? *> Dear TR, I am impressed that you got to section 3.5 of the RSVP spec and read about blockade state, after learning about the Internet technology from the technical journal "Datacomm Magazine". In fact, RSVP blockade state is irrelevant to your issue. Blockade state was designed to ameliorate a particular technical problem arising from making heterogeneous reservations for a multicast session. Web access is unicast. *> *> RSVP Can't handle Spikes? Then why mess with it at all?? *> *> TR *> *> To answer this question, I suggest you continue your reading with RFC1633, "Integrated Service in the Internet Architecture: An Overview", June 1994. Then we can talk about the nonsense you quoted from DataComm magazine. Bob Braden   Received: from ietf.org by ietf.org id aa02874; 8 Jan 97 7:23 EST Received: from cisco-uk.cisco.com by ietf.org id aa02665; 8 Jan 97 7:18 EST Received: from [171.68.144.14] (lon-macip9.cisco.com [171.68.144.14]) by london.cisco.com (8.8.3/8.8.3) with SMTP id MAA05745; Wed, 8 Jan 1997 12:04:31 GMT X-Sender: fred@stilton.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 8 Jan 1997 04:07:21 -0800 To: TurnerX Rentz Sender:ietf-request@ietf.org From: Fred Baker Subject: Re: RSVP Can't Handle Spikes?? Cc: ietf@ietf.org Source-Info: From (or Sender) name not authenticated. At 1:24 AM 1/7/97, TurnerX Rentz wrote: > Problem is, it can't keep up with HTTP (hypertext transfer > protocol) traffic, which spikes and falls radically. " seems to me like sales FUD. I don't see any reason that congestion management mechanisms underlying RSVP couldn't handle spikes of congestion.   Received: from ietf.org by ietf.org id aa17387; 8 Jan 97 12:40 EST Received: from pax.cavebear.com by ietf.org id aa17264; 8 Jan 97 12:38 EST Received: from localhost by CaveBear.com (SMI-8.6/SMI-SVR4) id JAA16076; Wed, 8 Jan 1997 09:28:26 -0800 Date: Wed, 8 Jan 1997 09:28:26 -0800 (PST) Sender:ietf-request@ietf.org From: Karl Auerbach Reply-To: karl@cavebear.com To: Fred Baker cc: TurnerX Rentz , ietf@ietf.org Subject: Re: RSVP Can't Handle Spikes?? In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. > > Problem is, it can't keep up with HTTP (hypertext transfer > > protocol) traffic, which spikes and falls radically. " > > seems to me like sales FUD. I don't see any reason that congestion > management mechanisms underlying RSVP couldn't handle spikes of congestion. I took at look at the data comm thing. They may be trying to say that http connections, because they are so short lived, are not amenable to RSVP because the connection is nearly over by the time the reservation is established. (And I doubt that that packeteer product can do much for short http connections because they are self throttling by slow start algorithms and there often won't even be any ACK bits for rackateer to finagle until the connection is getting ready to close.) I certainly think the article got off onto some wrong tangent about traffic "spikes". It would be worthwhile to write a note to the editors of datacom setting them straight. By-the-way, I do rememember that at the last IETF we decided to write an "applicability statement" about RSVP (and I also remember saying that I would help write it.) --karl--   Received: from ietf.org by ietf.org id aa29806; 8 Jan 97 16:18 EST Received: from dfw-ix7.ix.netcom.com by ietf.org id aa29526; 8 Jan 97 16:14 EST Received: from #ghandchi.ix.netcom.com (ple-ca7-09.ix.netcom.com [204.31.114.41]) by dfw-ix7.ix.netcom.com (8.6.13/8.6.12) with SMTP id NAA05881; Wed, 8 Jan 1997 13:08:22 -0800 Message-ID: <32D40DAA.52A8@netcom.com> Date: Wed, 08 Jan 1997 13:12:10 -0800 Sender:ietf-request@ietf.org From: Sam Ghandchi Reply-To: samg@netcom.com Organization: self X-Mailer: Mozilla 3.0 (Win95; I) MIME-Version: 1.0 To: karl@cavebear.com CC: Fred Baker , TurnerX Rentz , ietf@ietf.org Subject: Re: RSVP Can't Handle Spikes?? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Source-Info: From (or Sender) name not authenticated. Karl Auerbach wrote: > > > > Problem is, it can't keep up with HTTP (hypertext transfer > > > protocol) traffic, which spikes and falls radically. " > > > > seems to me like sales FUD. I don't see any reason that congestion > > management mechanisms underlying RSVP couldn't handle spikes of congestion. > > I took at look at the data comm thing. They may be trying to say that > http connections, because they are so short lived, are not amenable to > RSVP because the connection is nearly over by the time the reservation is > established. > > (And I doubt that that packeteer product can do much for short http > connections because they are self throttling by slow start algorithms and > there often won't even be any ACK bits for rackateer to finagle until the > connection is getting ready to close.) > > I certainly think the article got off onto some wrong tangent about > traffic "spikes". > > It would be worthwhile to write a note to the editors of datacom setting > them straight. > > By-the-way, I do rememember that at the last IETF we decided to write an > "applicability statement" about RSVP (and I also remember saying that I > would help write it.) > > --karl-- I think the question is whether one can have a layer4-implemented Packet Rate Control System (PRCS) (not queuing) for IP, without a cooperative approach of RSVP. Of course, if such a PRCS is implemented, it can take advantage of RSVP, when RSVP is present in the end-stations and provide even better QoS. - Sam   Received: from cnri by ietf.org id aa11799; 9 Jan 97 11:06 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa13927; 9 Jan 97 11:06 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id KAA06344; Thu, 9 Jan 1997 10:55:04 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1695179 for TN3270E@LIST.NIH.GOV; Thu, 9 Jan 1997 10:54:57 -0500 Received: from saluki.cisco.com (saluki.cisco.com [171.69.1.205]) by list.nih.gov (8.7.5/8.6.12) with SMTP id KAA06330 for ; Thu, 9 Jan 1997 10:54:52 -0500 (EST) Received: from mboe-home-ss20.cisco.com (mboe-home-ss20.cisco.com [171.69.136.130]) by saluki.cisco.com (8.6.12/8.6.5) with ESMTP id HAA11723; Thu, 9 Jan 1997 07:54:21 -0800 Received: from localhost (LOCALHOST.cisco.com [127.0.0.1]) by mboe-home-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id KAA25183; Thu, 9 Jan 1997 10:54:19 -0500 Date: Thu, 9 Jan 1997 10:54:19 -0500 (EST) From: Michael Boe Reply-To: Michael Boe Subject: Re: RFC1647 changes (was Re: More information and discussion) To: Bill Kelly Cc: TN3270E list In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tn3270e@list.nih.gov > On Thu, 9 Jan 1997, Nick Weeds wrote: > > > Here are a few more specific questions to get the ball rolling... > > > > 1) Revisions to RFC1647 > > > > What do we need to put into the revised RFC1647 ? > > Bill Kelly's list from 6/26/95 was as follows > > Just to clarify things, the current list of updates I have dates from > 11/08/95, and is as follows: > > --------------------------------------------------------------------------- > > 11/08/95 > Changes required for rfc1647: > > - must support End Bracket to indicate "end of print job". > I still don't know how to deal with this when the server is in a non-SNA > environment. Does anyone have any ideas on this? > > I'd like to see us add a value to the DATA-TYPE field in the tn3270e > header, something like PRINT-EOJ with a value of 0x08, that the server > (SNA or non-SNA) could send to the client to indicate end of print > job. For an SNA server, it would send this when it gets an End Bracket > from the host application (or when it gets a "null RU", as in from an > AS/400 - Cleve?); for a non-SNA server, it would send this when....? > > - clarify section 8.1.4 SEQ-NUMBER Field to state that > 1) the field should be sent in network byte order (big endian) > 2) either byte that contains a 0xff must be doubled to 0xffff before > sending and stripped back to 0xff after receipt > > - clarify section 10.5.2 on the format of the data when the DATA-TYPE > field is SSCP-LU-DATA. The 4th paragraph in this section will now > end with: > > While the connection is "suspended," any data messages (except > TN3270E responses) exchanged between the client and server should > have the DATA-TYPE flag set to SSCP-LU-DATA; the data stream > will be as defined in [7], specifically the "Operation in SSCP-SLU > Session" section. > > - In section 7.2.1, remove the sentence "The function-list > consists of a string of 2-byte entries separated from one > another by a single space character." > > - Clarify the wording in the last paragraph in 10.3: > > Once the client receives a BIND-IMAGE data message, the > allowable DATA-TYPE values, in addition to SSCP-LU-DATA, now > include 3270-DATA and/or SCS-DATA, depending on whether.... > > - Add a statement at the end of section 7.2.1 to say that if an > impasse is reached during FUNCTIONS negotiation (for example, if a > client requested and was granted a DEVICE-TYPE representing a printer, > but refuses to accept either the SCS-CTL-CODES or DATA-STREAM-CTL > functions) the 'offended' party should terminate the negotiation by > sending an IAC WON'T TN3270E. > > - Somewhere early on, state that all numeric literals in the document > specify decimal values, unless they are preceeded by "0x" > > ------------------------------------------------------------------------- > > As far as I know, the PRINT-EOJ value has been implemented by everyone > with a value of 0x08. Does anyone know of any exceptions to this? There are certainly some exceptions operating in the field: OCS and IBM both have versions of client products which expect FFF5 (1646 signoff), I suppose due to the fact that they needed to get something out the door and nothing official existed at the time. However, I believe both vendors have now fixed this up in new versions. Cleve, Ed? Ed, to the best of your knowledge, have the Japanese versions been fixed up? /msb   Received: from cnri by ietf.org id ai06292; 9 Jan 97 22:38 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa29124; 9 Jan 97 19:50 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id TAA20281; Thu, 9 Jan 1997 19:40:30 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1700515 for TN3270E@LIST.NIH.GOV; Thu, 9 Jan 1997 19:40:26 -0500 Received: from oc.com (external2.oc.com [192.84.55.251]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id TAA20263 for ; Thu, 9 Jan 1997 19:40:23 -0500 (EST) Received: from cvgpc (cvgpc.oc.com [192.82.215.104]) by oc.com (8.8.4/8.7.5) with SMTP id SAA06372; Thu, 9 Jan 1997 18:39:15 -0600 (CST) Message-Id: <2.2.32.19970110003914.00a081e8@mailhost.oc.com> X-Sender: cvg@mailhost.oc.com X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Jan 1997 18:39:14 -0600 To: Michael Boe , Bill Kelly From: Cleve Graves Subject: Re: RFC1647 changes (was Re: More information and discussion) Cc: TN3270E list Sender: owner-tn3270e@list.nih.gov As far as I know the OCS implementations use the 0x08 when operating in "E" mode, and us the 0xfff5 when in RFC 1646 mode. It was my understanding that we (the WG) had agreed to us the 0x08 end-of-print flag, because it was capable of handling all the cases outlined (ie. SNA, non-SNA, and AS/400). But this agreement came about after the RFC had been published, so we could correct the Document. At 10:54 AM 1/9/97 -0500, Michael Boe wrote: >> On Thu, 9 Jan 1997, Nick Weeds wrote: >> >> > Here are a few more specific questions to get the ball rolling... >> > >> > 1) Revisions to RFC1647 >> > >> > What do we need to put into the revised RFC1647 ? >> > Bill Kelly's list from 6/26/95 was as follows >> >> Just to clarify things, the current list of updates I have dates from >> 11/08/95, and is as follows: >> >> --------------------------------------------------------------------------- >> >> 11/08/95 >> Changes required for rfc1647: >> >> - must support End Bracket to indicate "end of print job". >> I still don't know how to deal with this when the server is in a non-SNA >> environment. Does anyone have any ideas on this? >> >> I'd like to see us add a value to the DATA-TYPE field in the tn3270e >> header, something like PRINT-EOJ with a value of 0x08, that the server >> (SNA or non-SNA) could send to the client to indicate end of print >> job. For an SNA server, it would send this when it gets an End Bracket >> from the host application (or when it gets a "null RU", as in from an >> AS/400 - Cleve?); for a non-SNA server, it would send this when....? >> >> - clarify section 8.1.4 SEQ-NUMBER Field to state that >> 1) the field should be sent in network byte order (big endian) >> 2) either byte that contains a 0xff must be doubled to 0xffff before >> sending and stripped back to 0xff after receipt >> >> - clarify section 10.5.2 on the format of the data when the DATA-TYPE >> field is SSCP-LU-DATA. The 4th paragraph in this section will now >> end with: >> >> While the connection is "suspended," any data messages (except >> TN3270E responses) exchanged between the client and server should >> have the DATA-TYPE flag set to SSCP-LU-DATA; the data stream >> will be as defined in [7], specifically the "Operation in SSCP-SLU >> Session" section. >> >> - In section 7.2.1, remove the sentence "The function-list >> consists of a string of 2-byte entries separated from one >> another by a single space character." >> >> - Clarify the wording in the last paragraph in 10.3: >> >> Once the client receives a BIND-IMAGE data message, the >> allowable DATA-TYPE values, in addition to SSCP-LU-DATA, now >> include 3270-DATA and/or SCS-DATA, depending on whether.... >> >> - Add a statement at the end of section 7.2.1 to say that if an >> impasse is reached during FUNCTIONS negotiation (for example, if a >> client requested and was granted a DEVICE-TYPE representing a printer, >> but refuses to accept either the SCS-CTL-CODES or DATA-STREAM-CTL >> functions) the 'offended' party should terminate the negotiation by >> sending an IAC WON'T TN3270E. >> >> - Somewhere early on, state that all numeric literals in the document >> specify decimal values, unless they are preceeded by "0x" >> >> ------------------------------------------------------------------------- >> >> As far as I know, the PRINT-EOJ value has been implemented by everyone >> with a value of 0x08. Does anyone know of any exceptions to this? > >There are certainly some exceptions operating in the field: OCS and IBM both >have versions of client products which expect FFF5 (1646 signoff), I suppose >due to the fact that they needed to get something out the door and nothing >official existed at the time. However, I believe both vendors have now fixed >this up in new versions. Cleve, Ed? Ed, to the best of your knowledge, have >the Japanese versions been fixed up? > >/msb > Thanks, ---------------------------------------------------- Off the router, onto the bridge, down the firewall, nothin' but 'Net!! ---------------------------------------------------- Cleve   Received: from cnri by ietf.org id aa14708; 10 Jan 97 13:52 EST Received: from ACADEM2.ACADEM.COM by CNRI.Reston.VA.US id aa18285; 10 Jan 97 13:52 EST Received: (from majordomo@localhost) by academ2.academ.com (8.8.4/8.7.3) id MAA01072 for ietf-nntp-outgoing; Fri, 10 Jan 1997 12:49:38 -0600 (CST) X-Authentication-Warning: academ2.academ.com: majordomo set sender to owner-ietf-nntp using -f Received: from academ.com (root@ACADEM.COM [198.137.249.2]) by academ2.academ.com (8.8.4/8.7.3) with ESMTP id MAA01067 for ; Fri, 10 Jan 1997 12:49:36 -0600 (CST) Received: from lacroix.wildbear.on.ca (lacroix.wildbear.on.ca [199.246.132.198]) by academ.com (8.8.4/8.7.1) with ESMTP id MAA18294 for ; Fri, 10 Jan 1997 12:49:34 -0600 (CST) Received: by lacroix.wildbear.on.ca from localhost (router,SLMailNT V3.0); Fri, 10 Jan 1997 13:42:30 -0500 Received: by lacroix.wildbear.on.ca from wildside.wildbear.on.ca (199.246.132.193::mail daemon,SLMailNT V3.0); Fri, 10 Jan 1997 13:42:29 -0500 Message-Id: <3.0.32.19970110134751.00e4026c@lacroix> X-Sender: "Jack De Winter" X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 10 Jan 1997 13:47:52 -0500 To: Chris Hall , ietf-nntp@academ.com From: Jack De Winter Subject: Re: ietf-nntp New wording on article numbers - draft 3 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-nntp@academ.com Precedence: bulk >Let me see if I understand this correctly. Are you saying that a >collection of articles numbered, say, {12,13,14,15,16,17} at the master, >could arrive at the slave in, say, the order {13,15,12,17,14,16} ? But >all earlier articles would arrive before this collection, and all later >would arrive after -- so the out of order arrival is localised ? > >If so, could the slave not avoid exposing the out of order arrival ? >That is, could the slave avoid serving an article (or its number) until >all lower numbered articles have turned up ? (Assuming you can >guarantee that the articles will turn up, even if you cannot guarantee >the order.) um, I don't want to be the stick in the barrel, but are there any circumstances where the above behaviour would actually manifest itself in reality? if so, could you give a good example, complete with reasons at all of the points? (the hard point with doing pure theoretics is that we don't always think of applications right off the bat... sharing the applications can help make the theory a lot easier) regards, Jack ------------------------------------------------- Jack De Winter - Wildbear Consulting, Inc. (519) 576-3873 http://www.wildbear.on.ca/ Author of SLMail(95/NT) (http://www.seattlelab.com/) and other great products.   Received: from cnri by ietf.org id aa28950; 10 Jan 97 17:26 EST Received: from uscore-1.mv.com by CNRI.Reston.VA.US id aa24722; 10 Jan 97 17:26 EST Received: from localhost (daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) with SMTP id RAA04291 for ; Fri, 10 Jan 1997 17:23:57 -0500 (EST) Received: by pwg.org (bulk_mailer v1.5); Fri, 10 Jan 1997 17:22:10 -0500 Received: (from daemon@localhost) by lists.underscore.com (8.7.5/8.7.3) id RAA04052 for pwg-outgoing; Fri, 10 Jan 1997 17:16:21 -0500 (EST) Message-ID: From: Babak Jahromi To: "'pwg@pwg.org'" , "'p1284_3@lexmark.com'" , 'Randy Turner' Subject: RE: PWG> February Meeting Details Date: Fri, 10 Jan 1997 14:17:57 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 18 TEXT Sender: owner-pwg@pwg.org I certainly don't. Could someone please send that out? I am planning to attend. >---------- >From: Randy Turner[SMTP:rturner@sharplabs.com] >Sent: Friday, January 10, 1997 1:25 PM >To: pwg@pwg.org; p1284_3@lexmark.com >Subject: PWG> February Meeting Details > >Has anyone come up with details regarding when/where the >February meeting for PWG/IEEE will take place? > >Thanks > > >Randy >   Received: from cnri by ietf.org id aa06390; 17 Jan 97 13:04 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa17013; 17 Jan 97 13:04 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id MAA12280; Fri, 17 Jan 1997 12:50:35 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1771960 for TN3270E@LIST.NIH.GOV; Fri, 17 Jan 1997 12:50:32 -0500 Received: from cheerios.cisco.com (cheerios.cisco.com [171.69.192.213]) by list.nih.gov (8.7.5/8.6.12) with SMTP id MAA12268 for ; Fri, 17 Jan 1997 12:50:27 -0500 (EST) Received: from mboe-home-ss20.cisco.com (mboe-home-ss20.cisco.com [171.69.136.130]) by cheerios.cisco.com (8.6.10/8.6.5) with ESMTP id JAA23766; Fri, 17 Jan 1997 09:49:51 -0800 Received: from localhost ([127.0.0.1]) by mboe-home-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id MAA02811; Fri, 17 Jan 1997 12:49:51 -0500 Date: Fri, 17 Jan 1997 12:49:51 -0500 (EST) From: Michael Boe Reply-To: Michael Boe Subject: Re: Tying up loose ends in RFC 1647 To: Bill Kelly Cc: TN3270E list In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tn3270e@list.nih.gov > Hi, > > My understanding is that there's general agreement that the first thing > we'd like to do is clean up 1647 and submit it as a Draft Standard. To > that end, I would like to make a Last Call for comments on changes > required. ("Last" being a perhaps optimistic term. :-) > > I'd like to stick as much as possible to issues that have arisen from > implementation of the RFC and the functions it provides, rather than > addressing any new functionality. In fact, we can't add any new functionality if we want to move it along the standards process. > > I've maintained a list of changes needed; the current version is dated > 11/8/95 and was recently posted to the list. If anyone would like me to > mail them a copy, please let me know. I've also very recently been made > aware of a few additional relatively minor (I hope!) issues, and will be > posting something on these to the list shortly. Thanks, I'd like a copy. Actually, I'd like a copy with all the changes made, so I eagerly await the new draft :-). > > If anyone has anything else, please speak now! I would especially like > to ask those who have been involved in actual implementations and > interoperability testing (something I have not been a part of). If > problems arose due to the RFC being vague about a given subject, or not > covering certain details, so that solutions had to be arrived at by > mutual agreement, we need to standardize those solutions. Has Ed Bailey or Peter Fife forwarded you the summary of the interoperability lab cisco hosted last October? This contains a non-exhaustive but informative list of things that need clarification or correction. > > One more thing: Bob Moskowitz recently mentioned something to the effect > that we can no longer have a Security section in an RFC that simply says > "Security issues are not addressed in this document". That's essentially > what 1647 does. Do we get "grandfathered" in and can get away with doing > this, or do we have to do something more? I remember Harald making noises at the BOF that we can probably grandfather this one. Better talk to Harald about how that can be done. /msb   Received: from cnri by ietf.org id aa07928; 17 Jan 97 13:32 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa17760; 17 Jan 97 13:32 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id NAA13359; Fri, 17 Jan 1997 13:19:14 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1772371 for TN3270E@LIST.NIH.GOV; Fri, 17 Jan 1997 13:19:11 -0500 Received: from mailgate1.boeing.com ([130.42.28.16]) by list.nih.gov (8.7.5/8.6.12) with SMTP id NAA13343 for ; Fri, 17 Jan 1997 13:19:09 -0500 (EST) Received: from splinter.boeing.com by mailgate1.boeing.com (SMI-8.6/SMI-SVR4) id KAA20346; Fri, 17 Jan 1997 10:18:59 -0800 Received: from commanche.ca.boeing.com. by splinter.boeing.com with SMTP (1.37.109.16/16.2) id AA029784963; Fri, 17 Jan 1997 10:16:03 -0800 Received: by commanche.ca.boeing.com. (AIX 4.1/UCB 5.64/4.03) id AA40744; Fri, 17 Jan 1997 10:18:53 -0800 Message-Id: <9701171818.AA40744@commanche.ca.boeing.com.> To: Bill Kelly Cc: TN3270E list Subject: Re: Tying up loose ends in RFC 1647 In-Reply-To: (Your message of Fri, 17 Jan 97 10:20:01 -0600.) Date: Fri, 17 Jan 97 10:18:52 -0800 From: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" Sender: owner-tn3270e@list.nih.gov Bill We've been quiet on the list and just listening until: > "Security issues are not addressed in this document". That's essentially > what 1647 does. Do we get "grandfathered" in and can get away with doing > this, or do we have to do something more? > That my be fine for a university but if the vendors want customers for TN3270e products IT MUST HAVE REAL SECURITY. As it stands today, using TN3270e in an global network or Internet environment is leaving your host COMPLETELY OPEN to access and/or use by the rest of the world. That is NOT an acceptable business risk and will essentially prevent any widespread usage of TN3270e as part of a worldwide business communication environment. A "last call" at this time seems inappropriate and without the security part (which seemed to be agreed to in the earlier proposed charters) interest in the WG will probably drop off significantly. Take care | Terry L. Davis, P.E. ( terry.l.davis@boeing.com. 206-957-5325) | | Daniel D. McIntyre ( daniel.d.mcintyre@boeing.com. 206-957-5319 | | Boeing Information & Support Services | | Bellevue, WA | ----------------- Friday January 17,1997 10:15 AM PST ----------------   Received: from cnri by ietf.org id aa10880; 17 Jan 97 14:33 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa19294; 17 Jan 97 14:33 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id OAA15141; Fri, 17 Jan 1997 14:19:35 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1773029 for TN3270E@LIST.NIH.GOV; Fri, 17 Jan 1997 14:19:32 -0500 Received: from foxhound.cisco.com (foxhound.cisco.com [171.69.1.171]) by list.nih.gov (8.7.5/8.6.12) with SMTP id OAA15128 for ; Fri, 17 Jan 1997 14:19:30 -0500 (EST) Received: from mboe-home-ss20.cisco.com (mboe-home-ss20.cisco.com [171.69.136.130]) by foxhound.cisco.com (8.6.12/8.6.5) with ESMTP id LAA03870; Fri, 17 Jan 1997 11:18:59 -0800 Received: from localhost ([127.0.0.1]) by mboe-home-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id OAA02837; Fri, 17 Jan 1997 14:18:58 -0500 Date: Fri, 17 Jan 1997 14:18:58 -0500 (EST) From: Michael Boe Reply-To: Michael Boe Subject: Re: Tying up loose ends in RFC 1647 To: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" Cc: Bill Kelly , TN3270E list In-Reply-To: <9701171818.AA40744@commanche.ca.boeing.com.> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tn3270e@list.nih.gov > Bill > > We've been quiet on the list and just listening until: > > > "Security issues are not addressed in this document". That's essentially > > what 1647 does. Do we get "grandfathered" in and can get away with doing > > this, or do we have to do something more? > > > > That my be fine for a university but if the vendors want customers > for TN3270e products IT MUST HAVE REAL SECURITY. As it stands today, > using TN3270e in an global network or Internet environment is leaving > your host COMPLETELY OPEN to access and/or use by the rest of the world. > > That is NOT an acceptable business risk and will essentially prevent > any widespread usage of TN3270e as part of a worldwide business > communication environment. > > A "last call" at this time seems inappropriate and without the security > part (which seemed to be agreed to in the earlier proposed charters) > interest in the WG will probably drop off significantly. Terry, At the BOF we discussed whether or not RFC1647 should be pushed forward to the next stage of standardization. It was generally agreed (that is, there were several sounds of support and no sounds of objection from you or anyone else) that we should push forward with getting RFC1647 to the next step of standardization. As you know, the next step of standardization allows changes to the RFC, but only those which correct existing functionality, or drop existing functionality. So...I'm a bit confused. Adding security to the RFC would appear to nix the chances of it getting to the next phase of standardization in the short term (unless you are suggesting getting rid of printer LUs as part of security measures ;-). On the other hand, you didn't voice any objections to pushing the RFC1647 forward along the standards track. Which one is more important to you? Remember that we are planning "minor enhancements" to TN3270E as a part of the new RFCs to be written by the WG. My understanding is that security will be addressed fully as a part those "minor enhancements." [Aside: anything involving security issues is never "minor"--I suggest we be a bit more honest in the naming and staffing of this piece of work.] Ed/Deric, is my understanding correct here? /msb   Received: from cnri by ietf.org id aa20546; 17 Jan 97 18:48 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa26465; 17 Jan 97 18:47 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id QAA18116; Fri, 17 Jan 1997 16:10:50 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1774092 for TN3270E@LIST.NIH.GOV; Fri, 17 Jan 1997 16:10:46 -0500 Received: from mailgate1.boeing.com ([130.42.28.16]) by list.nih.gov (8.7.5/8.6.12) with SMTP id QAA18104 for ; Fri, 17 Jan 1997 16:10:44 -0500 (EST) Received: from splinter.boeing.com by mailgate1.boeing.com (SMI-8.6/SMI-SVR4) id NAA13219; Fri, 17 Jan 1997 13:09:56 -0800 Received: from commanche.ca.boeing.com. by splinter.boeing.com with SMTP (1.37.109.16/16.2) id AA282675218; Fri, 17 Jan 1997 13:06:58 -0800 Received: by commanche.ca.boeing.com. (AIX 4.1/UCB 5.64/4.03) id AA31032; Fri, 17 Jan 1997 13:09:46 -0800 Message-Id: <9701172109.AA31032@commanche.ca.boeing.com.> To: Michael Boe Cc: Bill Kelly , TN3270E list , tytso@mit.edu Subject: Re: Tying up loose ends in RFC 1647 In-Reply-To: (Your message of Fri, 17 Jan 97 14:18:58 -0500.) Date: Fri, 17 Jan 97 13:09:46 -0800 From: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" Sender: owner-tn3270e@list.nih.gov Fri, 17 Jan 1997 14:18:58 Michael Boe wrote: > At the BOF we discussed whether or not RFC1647 should be pushed forward to the > next stage of standardization. It was generally agreed (that is, there were > several sounds of support and no sounds of objection from you or anyone else) > that we should push forward with getting RFC1647 to the next step of > standardization. > If you remember, I made just about exactly the same statement at the BOF. Somewhere there was a mis-understanding as I left the BOF with the feeling that security WOULD BE incorporated in the standard. > As you know, the next step of standardization allows changes to the RFC, but > only those which correct existing functionality, or drop existing > functionality. > As I said, I assumed from discussions that a security section would be added "correct the existing functionality". > So...I'm a bit confused. Adding security to the RFC would appear to nix the > chances of it getting to the next phase of standardization in the short term > (unless you are suggesting getting rid of printer LUs as part of security > measures ;-). On the other hand, you didn't voice any objections to pushing > the RFC1647 forward along the standards track. Which one is more important to > you? > I think you'll have a great deal of difficulty getting folks to recommend use of TN3270e for corporate business on anything but encrypted links or with a token card as the primary authentication through a firewall (which BTW the user community hates) without fixing security. > .. > addressed fully as a part those "minor enhancements." [Aside: anything > involving security issues is never "minor"--I suggest we be a bit more honest > in the naming and staffing of this piece of work.] > Probably true. > Ed/Deric, is my understanding correct here? Likewise? ------------------------------------------------------------------------- To also respond: Fri, 17 Jan 1997 14:13:30 -0600 (CST) Bill Kelly's wrote: > I don't disagree with Terry's comments. In fact, I'd like to see tn3270 > (and ftp, and smtp...) support encryption well enough for my > installation's purposes. But the only way I can see to do it in TN3270E > in the short term is "the wrong way": get someone who knows a little about > encryption algorithms to pick one, and just say "okay, it supports > public-key encryption, and see reference #8 for the algorithm". Even > then, as Michael pointed out, "short term" then means starting over as a > new Proposed Standard with a newly assigned RFC number. > Initially you probably do not have to support full encryption via something like SSL or IPSEC. I think if we merely get away from presenting "clear text, reusable passwords" to the world that would be a good start for 1647. At least then we have a lock on the door, and drawing the shades via encryption could be tackled then in the next WG re-write. Perhaps Harald could answer specificially whether adding a security section would necessarily cause 1647 to restart, given the IETF rule changes. > -What (if anything) is being done on a wider scope, such as at the IP > level? Wasn't there some IETF work going on abut Telnet encryption? > I believe Theodore Ts'o might be able to give some status on secure telnet. If that RFC is far enough along it might be possible to incorporate that work. Take care | Terry L. Davis, P.E. | Boeing Information & Support Services | | 206-957-5325 | terry.l.davis@boeing.com. | --------------- Friday January 17,1997 01:00 PM PST -------------   Received: from ietf.org by ietf.org id aa22385; 17 Jan 97 19:43 EST Received: from callandor.cybercash.com by ietf.org id aa22309; 17 Jan 97 19:41 EST Received: by callandor.cybercash.com; id TAA06126; Fri, 17 Jan 1997 19:32:35 -0500 Received: from cybercash.com(204.149.68.52) by callandor.cybercash.com via smap (3.2) id xma006124; Fri, 17 Jan 97 19:32:26 -0500 Received: from crockerdec.cybercash.com (loial.cybercash.com) by cybercash.com (4.1/SMI-4.1) id AA02916; Fri, 17 Jan 97 19:36:12 EST Message-Id: <3.0.32.19970117194220.00740d84@cybercash.com> X-Sender: crocker@cybercash.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 17 Jan 1997 19:42:25 -0500 To: TurnerX Rentz Sender:ietf-request@ietf.org From: Steve Crocker Subject: Re: Scientific American Cc: ietf@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Source-Info: From (or Sender) name not authenticated. >Scientific American _had_ to have a reason for expecting ubiquity >by Summer 1997; that's only 4 months away. This is not a source >which is known for far speculation. I don't know why this was inserted in your message, but Scientific American does *not* use the same care or scholarly diligence in its columns on current news as it does in its scientific articles. Its current events reports are put together by reporters and/or editors on the strength of a phone call or two with no particular process for balance or accuracy other than the reporter's individual taste and judgment. Steve ---------------------------------- Steve Crocker Main: +1 703 620 4200 CyberCash, Inc. Desk: +1 703 716 5214 2100 Reston Parkway Fax: +1 703 620 4215 Reston, VA 22091 crocker@cybercash.com   Received: from ietf.org by ietf.org id aa18150; 18 Jan 97 9:58 EST Received: from ginger.lcs.mit.edu by ietf.org id aa17936; 18 Jan 97 9:52 EST Received: by ginger.lcs.mit.edu id AA21300; Sat, 18 Jan 97 09:43:35 -0500 Date: Sat, 18 Jan 97 09:43:35 -0500 Sender:ietf-request@ietf.org From: Noel Chiappa Message-Id: <9701181443.AA21300@ginger.lcs.mit.edu> To: TurnerX_Rentz@ccm.jf.intel.com, ietf@ietf.org Subject: Re: Re[2]: Will IPV6 be Just a Software Upgrade for the Routers? Cc: jnc@ginger.lcs.mit.edu Source-Info: From (or Sender) name not authenticated. From: TurnerX Rentz > Nonsense. With current routing technology, unique assigments of > addresses is still essential. Current routing technology only requires that they are unique; the very nature of indexing implies uniqueness. Without commenting on the rest of this discussion, I'd like to remind everyone involved that as far as "routing" in the sense of distributed path-selection computations (i.e. the things that routing protocols do), this statement ("only requires") is incorrect. The "names" or "identifiers" that are used in those computations (and in both IPv4 and IPv6, it's the "addresses") have the additional *requirement* that they have to be assigned in an *organized* way, so that "most" things which are close in the network get related addresses. (To be precise, they need to be organized so that they can be aggregated, and, in a network this large, they have to be recursively aggregable for a growing number of levels). Noel   Received: from ietf.org by ietf.org id aa05047; 18 Jan 97 22:17 EST Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa04835; 18 Jan 97 22:13 EST Sender:ietf-request@ietf.org From: Masataka Ohta Message-Id: <199701190306.MAA01990@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA01990; Sun, 19 Jan 1997 12:06:08 +0900 Subject: Re: Re[2]: Will IPV6 be Just a Software Upgrade for the Routers? To: Noel Chiappa Date: Sun, 19 Jan 97 12:06:07 JST Cc: TurnerX_Rentz@ccm.jf.intel.com, ietf@ietf.org, jnc@ginger.lcs.mit.edu In-Reply-To: <9701181443.AA21300@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jan 18, 97 9:43 am X-Mailer: ELM [version 2.3 PL11] Source-Info: From (or Sender) name not authenticated. Noel; > The "names" or "identifiers" that are used in those computations (and in both > IPv4 and IPv6, it's the "addresses") What is used in route computations is "locator". Don't call it "identifier". > they have to be assigned in an *organized* way, so that "most" things which > are close in the network get related addresses. (To be precise, they need to > be organized so that they can be aggregated, and, in a network this large, > they have to be recursively aggregable for a growing number of levels). Wrong. Yes., both "locator" and "identifier" must be assigned in an *organized*. But, "locator" *MUST* *ALWAYS* *PRECISELY* reflect the network topology. On the other hand, "identifier" will reflect organizational/political/economical hierarchy, which may sometimes close but basically unrelated to the network topology. For example, "identifier" of a mobile host is that of the mobile host's organization. Masataka Ohta   Received: from ietf.org by ietf.org id aa21651; 19 Jan 97 7:39 EST Received: from edu.lahti.fi by ietf.org id aa21409; 19 Jan 97 7:33 EST Received: (qmail 1348 invoked by uid 1067); 19 Jan 1997 12:39:20 -0000 Date: Sun, 19 Jan 1997 14:39:20 +0200 (EET) Sender:ietf-request@ietf.org From: Sampo Syreeni To: TurnerX Rentz cc: ietf@ietf.org Subject: Re: Ipv6 thread goes to sockets mailing lists, returns happy! In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Source-Info: From (or Sender) name not authenticated. On Sat, 18 Jan 1997, TurnerX Rentz wrote: > 4. The Marine Corps seems to think current address space is sufficient > http://stl.nps.navy.mil/~jenierle/chapt8.html Somehow I get the impression that isn't quite what is said. The author indicates that the current address space is sufficient for the TDN. However, just about the first thing said in chapter eight is "Exhaustion of IPv4 address space is the primary factor is forcing the move toward IPv6 in the global Internet. The tactical internet's need for IPv6 is somewhat different. Address space will not be a problem for the Tactical Data Network (TDN) if the Marine Corps implements the tactical IP addressing plan proposed in this study.". So what is said is that the Marine Corps has no forcing need for the larger address space, but the Internet as a whole sure has. > The military document above outlines a strategy for dual stack > migration, I would like to see something as high up as what > we have to do as application layer developers (you have to > assume the OS people are going to do their job in the commercial > world). I would think that in the case of the standard off the shelf applications, the modifications boil down to changing IP address size buffers and handling errors a bit differently. As the logical structure of DNS addresses would not seem to change much and the network level details are well encapsulated, you shouldn't need to do much. Unless you want to use multicast, security or other similar options new to IPv6. Sampo Syreeni, student, Decoy/dAWN   Received: from ietf.org by ietf.org id aa02813; 19 Jan 97 17:04 EST Received: from cs.nps.navy.mil by ietf.org id aa02567; 19 Jan 97 16:58 EST Received: from capella.cs.nps.navy.mil by cs.nps.navy.mil (4.1/SMI-4.1) id AA03639; Sun, 19 Jan 97 13:53:56 PST Sender:ietf-request@ietf.org From: Don Brutzman Received: by capella.cs.nps.navy.mil (4.1) id AA06962; Sun, 19 Jan 97 13:53:45 PST Message-Id: <9701192153.AA06962@capella.cs.nps.navy.mil> Subject: Re: Ipv6 thread goes to sockets mailing lists, returns happy! To: Sampo Syreeni Date: Sun, 19 Jan 1997 13:53:45 -0800 (PST) Cc: TurnerX_Rentz@ccm.jf.intel.com, ietf@ietf.org, Jim Nierle , Dan Boger , Information Infrastructure Research Group In-Reply-To: from "Sampo Syreeni" at Jan 19, 97 02:39:20 pm X-Mailer: ELM [version 2.4 PL25] Content-Type: text Content-Length: 4639 Source-Info: From (or Sender) name not authenticated. I'm not sure why the preceding discussion (attached below) is on the big ietf list. Here are some further details and a request to take the discussion elsewhere, unless there is some pressing reason to keep it on the big list. The document in question is a (great) master's thesis and not USMC policy. It is written with a very specific network environment in mind. ================================= Internetworking: Technical Strategy for Implementing the Next Generation Internet Protocol (IPv6) in the Marine Corps Tactical Data Network James E. Nierle Master's Thesis Naval Postgraduate School Monterey California USA June 1996 http://www.stl.nps.navy.mil/~jenierle/thesis.html Available in HTML and Postscript Abstract. The Marine Corps must architect a tactical internet based on a software technology that is in transition - the Internet Protocol (IP). Development of the Marine Corps' tactical internetworking system (Tactical Data Network or TDN) is progressing concurrently with the global Internet community's development of the Next Generation Internet Protocol (IPv6). Current (IPv4) and next generation (IPv6) versions of the Internet Protocol can together meet the tactical internetworking needs of the Marine Corps. IPv4 provides universal interoperability with other networking technologies and support for a wide range of services now, but without enhancements IPv4 cannot meet the long-terms needs of evolving tactical applications. IPv6 is needed to meet emerging requirements (such as secure mobility) but is not yet ready for implementation in the Tactical Data Network. Therefore the Marine Corps must build the tactical internet architecture using IPv4 and incorporate IPv6 improvements when transition is possible. Marine Corps commitment to IP is essential to ensure universal interoperability and hardware-independent evolution of tactical applications and networking technology. This work presents a tactical IP addressing plan for TDN that works with IPv4 and also facilitates smooth transition to IPv6. In concert with the other military services, the Marine Corps must develop a strategy for migrating the joint tactical internet to IPv6. The future viability of the Tactical Data Network depends on the Internet Protocol. ================================= All that said, Sampo's clarifying comments below appear valid. Thanks for yours and TurnerX Rentz's interest. Sampo Syreeni writes: > > On Sat, 18 Jan 1997, TurnerX Rentz wrote: > > > 4. The Marine Corps seems to think current address space is sufficient > > http://stl.nps.navy.mil/~jenierle/chapt8.html > > Somehow I get the impression that isn't quite what is said. The author > indicates that the current address space is sufficient for the TDN. > However, just about the first thing said in chapter eight is "Exhaustion > of IPv4 address space is the primary factor is forcing the move toward > IPv6 in the global Internet. The tactical internet's need for IPv6 is > somewhat different. Address space will not be a problem for the Tactical > Data Network (TDN) if the Marine Corps implements the tactical IP > addressing plan proposed in this study.". So what is said is that the > Marine Corps has no forcing need for the larger address space, but the > Internet as a whole sure has. > > > The military document above outlines a strategy for dual stack > > migration, I would like to see something as high up as what > > we have to do as application layer developers (you have to > > assume the OS people are going to do their job in the commercial > > world). > > I would think that in the case of the standard off the shelf applications, > the modifications boil down to changing IP address size buffers and handling > errors a bit differently. As the logical structure of DNS addresses would > not seem to change much and the network level details are well > encapsulated, you shouldn't need to do much. Unless you want to use > multicast, security or other similar options new to IPv6. > > Sampo Syreeni, student, Decoy/dAWN all the best, Don -- Don Brutzman Naval Postgraduate School, Code UW/Br Root 200 work 408.656.2149 Monterey California 93943-5000 USA fax 408.656.3679 Virtual worlds/underwater robots/Internet http://www.stl.nps.navy.mil/~brutzman   Received: from ietf.org by ietf.org id aa08464; 20 Jan 97 11:36 EST Received: from drake.bellcore.com by ietf.org id aa08063; 20 Jan 97 11:31 EST Received: from bellcore.com (localhost [127.0.0.1]) by drake.bellcore.com (8.7.5/8.7.3) with SMTP id LAA22361; Mon, 20 Jan 1997 11:22:50 -0500 (EST) Message-Id: <199701201622.LAA22361@drake.bellcore.com> To: Masataka Ohta cc: Noel Chiappa , TurnerX_Rentz@ccm.jf.intel.com, ietf@ietf.org Subject: Re: Re[2]: Will IPV6 be Just a Software Upgrade for the Routers? In-reply-to: Your message of "Sun, 19 Jan 1997 12:06:07 +0200." <199701190306.MAA01990@necom830.hpcl.titech.ac.jp> Date: Mon, 20 Jan 1997 11:22:49 -0500 Sender:ietf-request@ietf.org From: Mike Little Source-Info: From (or Sender) name not authenticated. Certainly this discussion is beginning to lose its relevance to the general ietf list. I think Noel still has a fair grasp of the term "locator", as I don't think it has changed *that* much since he associated a particular concept with this word a few years ago. I'll also point out that there is *NO* requirement in routing for the topology identifier (to avoid using terms like address and locator) to refelct any aspect of the network topology other than identity. Its primary purpose is to provide uniqueness of identity, and any additional features - such as position in a topological ordering - exist *solely* for reasons of efficiency (and/or convenience). It is a popular misconception that routing *requires* this overloading in the identifier/locator/address/whatever. Note that many routing systems are built to depend upon this overloading, but to say it in the manner you did: > >But, "locator" *MUST* *ALWAYS* *PRECISELY* reflect the network topology. > is simply not true. -Mike   Received: from ietf.org by ietf.org id aa18114; 20 Jan 97 16:27 EST Received: from [198.3.105.221] by ietf.org id aa17751; 20 Jan 97 16:20 EST Received: by SNOOPY with Internet Mail Service (5.0.1389.3) id <01BC06ED.CFE18350@SNOOPY>; Mon, 20 Jan 1997 16:20:12 -0500 Message-ID: Sender:ietf-request@ietf.org From: "Harrington, Dan" To: "'ietf@ietf.org'" Cc: "'TurnerX_Rentz@ccm.jf.intel.com'" Subject: RE: Ipv6 thread goes to sockets mailing lists, returns happy! Date: Mon, 20 Jan 1997 16:20:11 -0500 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1389.3) Content-Type: text/plain Source-Info: From (or Sender) name not authenticated. Turner asked: > Is there a software migration RFC and methodology for migration > anywhere? RFC 1933 is the IPv6 Transition Mechanisms document. It is due for an update shortly, as per the working group meeting at the December IETF. There are also a couple of socket API drafts being worked on within the IPng Working Group. Hope this helps... Dan   Received: from ietf.org by ietf.org id aa18377; 20 Jan 97 16:30 EST Received: from ftp.com by ietf.org id aa18323; 20 Jan 97 16:29 EST Received: from ftp.com by ftp.com ; Mon, 20 Jan 1997 16:27:54 -0500 Received: from mailserv-2high.ftp.com by ftp.com ; Mon, 20 Jan 1997 16:27:54 -0500 Received: by MAILSERV-2HIGH.FTP.COM (SMI-8.6/SMI-SVR4) id QAA26797; Mon, 20 Jan 1997 16:27:57 -0500 Date: Mon, 20 Jan 1997 16:27:57 -0500 Message-Id: <199701202127.QAA26797@MAILSERV-2HIGH.FTP.COM> To: TurnerX_Rentz@ccm.jf.intel.com Subject: Re: Ipv6 thread goes to sockets mailing lists, returns happy! Sender:ietf-request@ietf.org From: Larry Backman Reply-To: backman@ftp.com Cc: ietf@ietf.org X-Orig-Sender: backman@mailserv-2high.ftp.com Repository: mailserv-2high.ftp.com, [message accepted at Mon Jan 20 16:27:47 1997] Originating-Client: tunes.ftp.com Source-Info: From (or Sender) name not authenticated. || Looks like the sockets groups are better to talk to about || protocols these days. :0 Having been involved in the winsock mailing lists for a few years I would take what you heard on the winsock mailing lists with a few grains of salt. || || || Here's some things I found out about IPv6 so far. || Submitted for your approval: || || || 1.Alot of os will need a recompile but not that || bad. For example, the TDI in Windows NT will need to be || recompiled but the whole kernel won't need a rewrite. || :) I would not take this as fact without a Microsoft engineer explaining this in detail. Since we have shipped an IPV6 module within our Win95 stack we've gone thru a bunch of the work necessary to add IP6 to an IP4 stack. I can assure you, or actually one of my engineers who is on this list can tell you in better detail than I, that adding IP6 to a stack involves work from the MAC interface level right up to the applications level. Each and every layer will need some work done to it, some trivial, some not so trivial. Anyone who represents adding IP6 to a commercial stack as a small effort is either not aware of or is glossing over the details. || || 2. The Sockets APIs published by Microsoft will let you || almost just recompile your app. with a new pointer to the || new stack for _application layer_ apps. The newer protocols || - I can't say - I still remember the big push for everybody || to be on ATM by now and I honestly can't figure out where || that thing went. Winsock-2, which is a new variant of the ubiquituous Winsock 1.1 API will eventually allow you to talk to an IP6 compliant stack. If your smart and wrote your app properly and didn't assume an address was a long and use protocols which don't have embedded IP addresses you *might* just be able to recompile your app and have it work. But I doubt it as there are dozen's of trivial little gotcha's that add up to a few week to few month learning curve before your app is as robust over IP6 as over IP4. Then there is the infrastructure; but that's someone else's story... L.   Received: from ietf.org by ietf.org id aa21088; 20 Jan 97 17:52 EST Received: from black-ice.cc.vt.edu by ietf.org id aa20909; 20 Jan 97 17:46 EST Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.4/8.8.4) with ESMTP id RAA20986; Mon, 20 Jan 1997 17:40:50 -0500 Message-Id: <199701202240.RAA20986@black-ice.cc.vt.edu> X-Mailer: exmh version 2.0beta 12/23/96 To: backman@ftp.com Cc: TurnerX_Rentz@ccm.jf.intel.com, ietf@ietf.org Subject: Re: Ipv6 thread goes to sockets mailing lists, returns happy! In-Reply-To: Your message of "Mon, 20 Jan 1997 16:27:57 EST." <199701202127.QAA26797@MAILSERV-2HIGH.FTP.COM> Sender:ietf-request@ietf.org From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: <199701202127.QAA26797@MAILSERV-2HIGH.FTP.COM> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_127004608P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Mon, 20 Jan 1997 17:40:49 -0500 Source-Info: From (or Sender) name not authenticated. --==_Exmh_127004608P Content-Type: text/plain; charset=us-ascii On Mon, 20 Jan 1997 16:27:57 EST, Larry Backman said: > || 1.Alot of os will need a recompile but not that > || bad. For example, the TDI in Windows NT will need to be > || recompiled but the whole kernel won't need a rewrite. > || :) > Each and every layer will need some work done to it, some trivial, > some not so trivial. Anyone who represents adding IP6 to a commercial > stack as a small effort is either not aware of or is glossing over the > details. I think he meant that although many parts of the kernel will end up being touched, that for the most part, many parts will *NOT* be touched - you don't need to redo the device drivers, or the process management scheme, or other such things. And if the code was properly written and encapsulated to begin with, most modules will simply need to be re-compiled and ready to go (one 'make' should do most of the work). IPv6 will not create the hit that (say) rewriting a kernel to support true multiprogramming would require, where *everything* needs to be looked at, from the file system to who knows what else.... -- Valdis Kletnieks Computer Systems Engineer Virginia Tech --==_Exmh_127004608P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMuP0b9QBOOoptg9JAQGwVAQAp+yGD0mP+JZOFKMKyLl7iBspWBq8uapT 6qlL0bdqfWpuak1Ce1hx47VIXE4eKqPsJEBWxeGgi2Yq3p1iPzUJxt82G8Tj2av6 c4nI/OaVu57H7uK2YhKwrOdjuZZqXFIIqmJXg9jz4Q2fQsH/EskQx43WBAMmoUZU T09y/jj+q6w= =ziIc -----END PGP MESSAGE----- --==_Exmh_127004608P--   Received: from ietf.org by ietf.org id aa25991; 20 Jan 97 20:57 EST Received: from necom830.hpcl.titech.ac.jp by ietf.org id aa25740; 20 Jan 97 20:51 EST Sender:ietf-request@ietf.org From: Masataka Ohta Message-Id: <199701210143.KAA04807@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id KAA04807; Tue, 21 Jan 1997 10:43:18 +0900 Subject: Re: Re[2]: Will IPV6 be Just a Software Upgrade for the Routers? To: Mike Little Date: Tue, 21 Jan 97 10:43:18 JST Cc: mohta@necom830.hpcl.titech.ac.jp, jnc@ginger.lcs.mit.edu, TurnerX_Rentz@ccm.jf.intel.com, ietf@ietf.org In-Reply-To: <199701201622.LAA22361@drake.bellcore.com>; from "Mike Little" at Jan 20, 97 11:22 am X-Mailer: ELM [version 2.3 PL11] Source-Info: From (or Sender) name not authenticated. Mike; > Certainly this discussion is beginning to lose its relevance to > the general ietf list. I think Noel still has a fair grasp of > the term "locator", as I don't think it has changed *that* much > since he associated a particular concept with this word a few years > ago. Until I saw your mail, I have never seen any confusion on the term "locator". > I'll also point out that there is *NO* requirement in routing for > the topology identifier Please don't say "topology identifier" and just stick to the established terminology (between specialists on this issue) described in draft-iab-ip-ad-today-01.txt to be published as an Informational RFC soonly. > Its primary purpose is to provide uniqueness of identity, Your debate is bogus. Identity is, by definition, unique. Masataka Ohta   Received: from cnri by ietf.org id aa26476; 21 Jan 97 13:19 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa16850; 21 Jan 97 13:19 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id NAA12304; Tue, 21 Jan 1997 13:09:52 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1803651 for TN3270E@LIST.NIH.GOV; Tue, 21 Jan 1997 13:09:49 -0500 Received: from airedale.cisco.com (airedale.cisco.com [171.69.1.135]) by list.nih.gov (8.7.5/8.6.12) with SMTP id NAA12230 for ; Tue, 21 Jan 1997 13:07:06 -0500 (EST) Received: from mboe-home-ss20.cisco.com (mboe-home-ss20.cisco.com [171.69.136.130]) by airedale.cisco.com (8.6.12/8.6.5) with ESMTP id MAA07931; Mon, 20 Jan 1997 12:26:03 -0800 Received: from localhost ([127.0.0.1]) by mboe-home-ss20.cisco.com (8.6.8+c/CISCO.WS.1.1) with ESMTP id PAA04239; Mon, 20 Jan 1997 15:25:32 -0500 Date: Mon, 20 Jan 1997 15:25:32 -0500 (EST) From: Michael Boe Reply-To: Michael Boe Subject: Re: TN3270E header : SEQ-NUMBER To: Bill Kelly Cc: TN3270E list In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tn3270e@list.nih.gov > > I think the current > > RFC has somewhat overspecified how they behave. But that wouldn't be the > > first time overspecification has occurred :-). > > I'm certainly open to removing unnecessary verbage; if you have some > specific suggestions, please post them for discussion. I'm saying that it's overspecified, but I'm not suggesting changing it (except for the clarification stuff). The overspecification (in this case, the starting number) doesn't really conflict with anything else, so there's doesn't seem to be any point in retracting it. /msb   Received: from cnri by ietf.org id aa20701; 22 Jan 97 7:19 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa07630; 22 Jan 97 7:19 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id HAA05669; Wed, 22 Jan 1997 07:08:16 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1812028 for TN3270E@LIST.NIH.GOV; Wed, 22 Jan 1997 07:08:13 -0500 Received: from fxiod05.is.chrysler.com (firewall-user@fxiod05.is.chrysler.com [204.189.94.74]) by list.nih.gov (8.7.5/8.6.12) with SMTP id GAA05505 for ; Wed, 22 Jan 1997 06:57:31 -0500 (EST) Received: by fxiod05.is.chrysler.com; id AA18156; Wed, 22 Jan 97 06:57:31 EST Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod05.is.chrysler.com via smap (V3.1.1) id xma018118; Wed, 22 Jan 97 06:57:08 -0500 Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id GAA21545; Wed, 22 Jan 1997 06:43:43 -0500 (EST) Message-Id: <3.0.32.19970121160114.009926f0@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 22 Jan 1997 06:54:45 -0500 To: "Terry L. Davis, Boeing Information & Support Services, Bellevue,\ WA" , Bill Kelly From: Robert Moskowitz Subject: Re: Tying up loose ends in RFC 1647 Cc: TN3270E list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-tn3270e@list.nih.gov At 10:18 AM 1/17/97 -0800, Terry L. Davis, Boeing Information & Support > >That my be fine for a university but if the vendors want customers >for TN3270e products IT MUST HAVE REAL SECURITY. As it stands today, >using TN3270e in an global network or Internet environment is leaving >your host COMPLETELY OPEN to access and/or use by the rest of the world. Opening up security will be a can of worms, I must admit. I believe the best we will be able to do is list a set of alternatives. Sitting here at National airport after attending 3 security meetings in one day, I'd list the following: TELNET Auth and Encryp -- Kerberos based SSL (WTS) Client auth and encrypt -- X.509 based IPsec -- DNSsec and/or X.509 based Each of these have their pros and cons. I am partial to IPsec, but SSL or its IETF follow-on (WTS I believe is the wg) has some deployment advantages, being more of an app toolkit whereas IPsec is more of a TCP/IP kernel toolkit. Kerberos in a trading partner environment, I have trouble with. We are doing a SSL/DCE combo here at www.spin.chrysler.com and I do not like some key aspects of the model. Robert Moskowitz Chrysler Corporation (810) 758-8212   Received: from cnri by ietf.org id aa20744; 22 Jan 97 7:19 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa07640; 22 Jan 97 7:19 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id HAA05652; Wed, 22 Jan 1997 07:07:51 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1812027 for TN3270E@LIST.NIH.GOV; Wed, 22 Jan 1997 07:07:29 -0500 Received: from fxiod01.is.chrysler.com (firewall-user@fxiod01.is.chrysler.com [204.189.94.70]) by list.nih.gov (8.7.5/8.6.12) with SMTP id GAA05497 for ; Wed, 22 Jan 1997 06:57:28 -0500 (EST) Received: by fxiod01.is.chrysler.com; id AA15397; Wed, 22 Jan 97 06:57:27 EST Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod01.is.chrysler.com via smap (V3.1.1) id xma015379; Wed, 22 Jan 97 06:57:09 -0500 Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id GAA21549; Wed, 22 Jan 1997 06:43:44 -0500 (EST) Message-Id: <3.0.32.19970121161402.00992760@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 22 Jan 1997 06:54:46 -0500 To: Bill Kelly , TN3270E list From: Robert Moskowitz Subject: Re: Tying up loose ends in RFC 1647 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-tn3270e@list.nih.gov At 02:13 PM 1/17/97 -0600, Bill Kelly wrote: I've been spending too much of my time in security meetings.... >I'd have to agree that doing security "the right way" is going to be an >involved process. I'm nowhere near well-versed in this area, but a lot >of questions come to mind, such as: TO do it the 'right way' you will need to find the philosopher's stone. >-What (if anything) is being done on a wider scope, such as at the IP > level? Wasn't there some IETF work going on abut Telnet encryption? IPsec is a real option, but until the PF_KEY API is also implemented, it is either on or off. No application interaction. Telnet encryption is a valuable piece of work, but will have major deployment issues. It needs Kerberos or DCE. Of course, Open/Edition supports DCE as will Nt5.0. SSL really has somethings to say for itself. Yuck. >-What about U.S. government export laws? Heck, what about every other > country's notions and laws concerning cryptography? If it uses a good > encryption algorithm, aren't there going to be problems for vendors in > the international arena? Watch for my Feb 15th column in NWC. This is what one of my meetings was about today. Sigh. >-Anyone on this list know a lot about encryption algorithms? Encryption algorithms is actually not so much the issue for 'good cyrpto'. Rather good enveloping technology and session initialization. Targeted attacks are rarely at the crypto, but at side issues like the format of the packet. Thus you can do something with 3DES and be trivially attacked, whereas a good RC4 40 bit could actually be tougher to attack! >I don't disagree with Terry's comments. In fact, I'd like to see tn3270 >(and ftp, and smtp...) support encryption well enough for my >installation's purposes. But the only way I can see to do it in TN3270E >in the short term is "the wrong way": get someone who knows a little about >encryption algorithms to pick one, and just say "okay, it supports >public-key encryption, and see reference #8 for the algorithm". Even >then, as Michael pointed out, "short term" then means starting over as a >new Proposed Standard with a newly assigned RFC number. The answer for the short term is grab the SSL libraries from australia and slide it in. The generate your keys. You really don't have to go to verisign, but then you will have to be your own authentification tree. Pluses and minuses again. Robert Moskowitz Chrysler Corporation (810) 758-8212   Received: from cnri by ietf.org id aa20756; 22 Jan 97 7:19 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa07650; 22 Jan 97 7:19 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id HAA05696; Wed, 22 Jan 1997 07:08:29 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1812029 for TN3270E@LIST.NIH.GOV; Wed, 22 Jan 1997 07:08:26 -0500 Received: from fxiod05.is.chrysler.com (firewall-user@fxiod05.is.chrysler.com [204.189.94.74]) by list.nih.gov (8.7.5/8.6.12) with SMTP id GAA05512 for ; Wed, 22 Jan 1997 06:57:35 -0500 (EST) Received: by fxiod05.is.chrysler.com; id AA18159; Wed, 22 Jan 97 06:57:31 EST Received: from mhbclpr2-nf0.is.chrysler.com(129.9.212.187) by fxiod05.is.chrysler.com via smap (V3.1.1) id xma018120; Wed, 22 Jan 97 06:57:09 -0500 Received: from rgm3 (rgm3.is.chrysler.com [129.9.247.160]) by mhbclpr2-nf0.is.chrysler.com (8.7.5/8.7.3) with SMTP id GAA21551; Wed, 22 Jan 1997 06:43:45 -0500 (EST) Message-Id: <3.0.32.19970121162244.00992280@pop3hub.is.chrysler.com> Reply-To: rgm3@chrysler.com X-Sender: rgm3@pop3hub.is.chrysler.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 22 Jan 1997 06:54:47 -0500 To: "Terry L. Davis, Boeing Information & Support Services, Bellevue,\ WA" , Michael Boe From: Robert Moskowitz Subject: Re: Tying up loose ends in RFC 1647 Cc: Bill Kelly , TN3270E list , tytso@mit.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-tn3270e@list.nih.gov At 01:09 PM 1/17/97 -0800, Terry L. Davis, Boeing Information & Support >> >I think you'll have a great deal of difficulty getting folks to recommend >use of TN3270e for corporate business on anything but encrypted links or >with a token card as the primary authentication through a firewall (which >BTW the user community hates) without fixing security. Firewall and encryption are really interesting challenges. Does the firewall participate in the authentication or does it let it through unencumbered. BTW, SSL firewall proxies are only good for outbound traffic. For inbound, the external clients have to specify your firewall as their SSL proxy. This is impossible with a trading partner that will need to go to multiple sites. Thus the best we will be able to do is to agree on a basic set of security functions that can be set up. For example, if auth/encrypt is used, the traffic is passed through the firewall to the TN3270E server for auth/decrypt. Robert Moskowitz Chrysler Corporation (810) 758-8212   Received: from cnri by ietf.org id aa16520; 23 Jan 97 11:41 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa14226; 23 Jan 97 11:41 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id LAA16641; Thu, 23 Jan 1997 11:29:39 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1827134 for TN3270E@LIST.NIH.GOV; Thu, 23 Jan 1997 11:29:30 -0500 Received: from smtp.datcon.co.uk (smtp.datcon.co.uk [192.91.191.4]) by list.nih.gov (8.7.5/8.6.12) with SMTP id LAA16629 for ; Thu, 23 Jan 1997 11:29:24 -0500 (EST) Received: by smtp.datcon.co.uk with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BC094A.82D41BE0@smtp.datcon.co.uk>; Thu, 23 Jan 1997 16:28:48 -0000 Message-ID: From: Nick Weeds To: 'Bill Kelly' Cc: 'tnsna' Subject: RE: rfc1647: Initial state of session (fwd) Date: Thu, 23 Jan 1997 16:28:41 -0000 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 73 TEXT Sender: owner-tn3270e@list.nih.gov Bill, Although I haven't checked RFC1647 recently, my understanding of it is the same as yours: - without BIND-IMAGES the initial data is 3270-DATA or SCS-DATA - with BIND-IMAGES the initial data is SSCP-LU-DATA - in either case NVT-DATA may be exchanged instead. The server I'm using at the moment enables BIND-IMAGES and uses either SSCP-LU-DATA or NVT-DATA - SSCP-LU-DATA for logon if the SNA SSCP session is brought up successfully - NVT-DATA for error messages if the SNA SSCP session isn't brought up successfully. Nick. >---------- >From: Bill Kelly[SMTP:kellywh@MAIL.AUBURN.EDU] >Sent: 23 January 1997 13:33 >To: TN3270E list >Subject: rfc1647: Initial state of session (fwd) > >I posted this the other day, but never got an acknowlegement from the >listserver, so I'm not sure it made it through. If so, please pardon the >re-post. > >-Bill > >---------- Forwarded message ---------- >Date: Tue, 21 Jan 1997 08:33:06 -0600 (CST) >From: Bill Kelly >To: TN3270E list >Subject: rfc1647: Initial state of session > >Hi, > >The following question was recently posed to me (paraphrasing): > >"If a client negotiates tn3270e successfully, but then gets nothing from >the server, what state is the session in? NVT? SSCP-LU? 3270?" > >My reply was that there are two possibilities. The first is when the >BIND-IMAGE function has NOT been agreed to in the tn3270e negotiation. In >this case, section 9.1 says the session is initally in 3270 mode. > >If the BIND-IMAGE function HAS been agreed to, then the situation is >different, as described in the last paragraph of section 10.3: > > "When BIND-IMAGE is in effect, data messages with DATA-TYPE > set to 3270-DATA or SCS-DATA are not allowed before the first > BIND-IMAGE is received by the client; only SSCP-LU-DATA or > NVT-DATA can be used to transmit user-oriented data." > >It's the latter situation that I'm wondering about. Essentially, the rfc >says that between Binds (i.e., before a Bind and after an Unbind), either >SSCP-LU-DATA or NVT-DATA is allowed. > >My question is this: has this caused problems during implementation? For >example, are there clients that expect only SSCP-LU-DATA and servers that >send NVT-DATA? > >I think there are legitimate situations where SSCP-LU-DATA can be sent, >and others where it can't, so that NVT-DATA is in order. Does anything >need to be said in the rfc to clarify things? > >Thanks, >Bill > >Bill Kelly phone: (334) 844-4512 >Auburn University Internet: kellywh@mail.auburn.edu >Division of University Computing >   Received: from cnri by ietf.org id aa25932; 23 Jan 97 14:29 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa19070; 23 Jan 97 14:29 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id OAA21741; Thu, 23 Jan 1997 14:16:42 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1829052 for TN3270E@LIST.NIH.GOV; Thu, 23 Jan 1997 14:16:38 -0500 Received: from ebi.cisco.com (ebi.cisco.com [171.69.160.21]) by list.nih.gov (8.7.5/8.6.12) with SMTP id OAA21729 for ; Thu, 23 Jan 1997 14:16:18 -0500 (EST) Received: from localhost (localhost.cisco.com [127.0.0.1]) by ebi.cisco.com (8.6.12/CISCO.SERVER.1.1) with ESMTP id OAA28035; Thu, 23 Jan 1997 14:10:48 -0500 Date: Thu, 23 Jan 1997 14:10:48 -0500 (EST) From: Michael Boe Reply-To: Michael Boe Subject: Re: rfc1647: Initial state of session (fwd) To: Nick Weeds cc: 'Bill Kelly' , 'tnsna' In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tn3270e@list.nih.gov > Bill, > > Although I haven't checked RFC1647 recently, my understanding of it is > the same as yours: > - without BIND-IMAGES the initial data is 3270-DATA or SCS-DATA > - with BIND-IMAGES the initial data is SSCP-LU-DATA > - in either case NVT-DATA may be exchanged instead. > > The server I'm using at the moment enables BIND-IMAGES and uses either > SSCP-LU-DATA or NVT-DATA > - SSCP-LU-DATA for logon if the SNA SSCP session is brought up > successfully > - NVT-DATA for error messages if the SNA SSCP session isn't brought > up successfully. > > Nick. > > >---------- > >From: Bill Kelly[SMTP:kellywh@MAIL.AUBURN.EDU] > >Sent: 23 January 1997 13:33 > >To: TN3270E list > >Subject: rfc1647: Initial state of session (fwd) > > > >I posted this the other day, but never got an acknowlegement from the > >listserver, so I'm not sure it made it through. If so, please pardon the > >re-post. > > > >-Bill > > > >---------- Forwarded message ---------- > >Date: Tue, 21 Jan 1997 08:33:06 -0600 (CST) > >From: Bill Kelly > >To: TN3270E list > >Subject: rfc1647: Initial state of session > > > >Hi, > > > >The following question was recently posed to me (paraphrasing): > > > >"If a client negotiates tn3270e successfully, but then gets nothing from > >the server, what state is the session in? NVT? SSCP-LU? 3270?" As a practical matter, most of the tn3270 clients appear to remain "locked" until the first data comes from the host. Of course, this data could be nothing but a keyboard restore.... > > > >My reply was that there are two possibilities. The first is when the > >BIND-IMAGE function has NOT been agreed to in the tn3270e negotiation. In > >this case, section 9.1 says the session is initally in 3270 mode. > > > >If the BIND-IMAGE function HAS been agreed to, then the situation is > >different, as described in the last paragraph of section 10.3: > > > > "When BIND-IMAGE is in effect, data messages with DATA-TYPE > > set to 3270-DATA or SCS-DATA are not allowed before the first > > BIND-IMAGE is received by the client; only SSCP-LU-DATA or > > NVT-DATA can be used to transmit user-oriented data." > > > >It's the latter situation that I'm wondering about. Essentially, the rfc > >says that between Binds (i.e., before a Bind and after an Unbind), either > >SSCP-LU-DATA or NVT-DATA is allowed. > > > >My question is this: has this caused problems during implementation? For > >example, are there clients that expect only SSCP-LU-DATA and servers that > >send NVT-DATA? Not that I'm aware of....but we never send NVT-DATA and we've never received NVT-DATA from any client that I know of. We would certainly object if we got NVT-DATA unsolicited from the client. Unless there's already an existing implementation of a client out there that (by default) sends NVT-DATA unsolicited between BINDs, I suggest removing that capability from the spec. Makes it simpler. > > > >I think there are legitimate situations where SSCP-LU-DATA can be sent, > >and others where it can't, so that NVT-DATA is in order. Does anything > >need to be said in the rfc to clarify things? Finally, and this is off the beaten path a little, but it would be helpful to clear up the fact that SSCP-LU-DATA is exchanged in SCS format, not 3270DS, for clients which have negotiated BIND-IMAGE. /msb   Received: from cnri by ietf.org id aa00145; 24 Jan 97 10:12 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa12230; 24 Jan 97 10:12 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id KAA14959; Fri, 24 Jan 1997 10:01:44 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1837409 for TN3270E@LIST.NIH.GOV; Fri, 24 Jan 1997 10:01:41 -0500 Received: from mailgate1.boeing.com ([130.42.28.16]) by list.nih.gov (8.7.5/8.6.12) with SMTP id KAA14947 for ; Fri, 24 Jan 1997 10:01:39 -0500 (EST) Received: from splinter.boeing.com by mailgate1.boeing.com (SMI-8.6/SMI-SVR4) id HAA24775; Fri, 24 Jan 1997 07:01:29 -0800 Received: from commanche.ca.boeing.com. by splinter.boeing.com with SMTP (1.37.109.16/16.2) id AA063177908; Fri, 24 Jan 1997 06:58:28 -0800 Received: by commanche.ca.boeing.com. (AIX 4.1/UCB 5.64/4.03) id AA43334; Fri, 24 Jan 1997 07:01:22 -0800 Message-Id: <9701241501.AA43334@commanche.ca.boeing.com.> To: rgm3@chrysler.com Cc: Michael Boe , Bill Kelly , TN3270E list , ronald.j.blomster@boeing.com, randal.hanford@pss.boeing.com Subject: Re: Tying up loose ends in RFC 1647 In-Reply-To: (Your message of Wed, 22 Jan 97 06:54:47 -0500.) <3.0.32.19970121162244.00992280@pop3hub.is.chrysler.com> Date: Fri, 24 Jan 97 07:01:21 -0800 From: "Terry L. Davis, Boeing Information & Support Services, Bellevue, WA" Sender: owner-tn3270e@list.nih.gov Robert A few comments on your numerous notes: On 1/22 you wrote: > Firewall and encryption are really interesting challenges. Does the > firewall participate in the authentication or does it let it through > unencumbered. BTW, SSL firewall proxies are only good for outbound > traffic. For inbound, the external clients have to specify your firewall > as their SSL proxy. This is impossible with a trading partner that will > need to go to multiple sites. > ... The most difficult challenge for firewalls traversal remains the getting the printer connection through! Since it wants a seperate port connection, there is no easy way to authenticate it to the firewall. BTW at least as far as Boeing is concerned, INBOUND SSL traffic is NOT a problem now. We already wrote an web reverse SSL proxy server. (Not that we wanted to, just unfortunately none of the commercial vendors have yet delivered one to my knowledge.) In a different 1/22 note you responded to Bill Kelly: > The answer for the short term is grab the SSL libraries from australia and > slide it in. The generate your keys. You really don't have to go to > verisign, but then you will have to be your own authentification tree. > Pluses and minuses again. > Works well, that's where the SSL code for the reverse proxy came from and we intend to be our own certificate authority anyway. Likewise since we already have the SSL proxy technology, you can probably guess where I would suggest we look first to solve the problem if the standard doesn't address it. Take care | Terry L. Davis, P.E. | Boeing Information & Support Services | | Phone: 206-957-5325 | Bellevue, Washington, USA | | Email: terry.l.davis@boeing.com. | --------------- Friday January 24,1997 06:43 AM PST -------------   Received: from cnri by ietf.org id aa17778; 27 Jan 97 18:44 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa28867; 27 Jan 97 18:44 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA00121 for uri-out; Mon, 27 Jan 1997 18:16:13 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA29977; Mon, 27 Jan 1997 18:15:47 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08920 (mail destined for uri@services.bunyip.com); Mon, 27 Jan 97 18:13:31 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id QAA00991; Mon, 27 Jan 1997 16:12:42 -0700 (MST) Message-Id: <3.0.32.19970127161513.00719f30@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 27 Jan 1997 16:23:45 -0700 To: Tim Berners-Lee From: "Ron Daniel Jr." Subject: Re: Relative URLs, // and ; Cc: uri@bunyip.com, urn-ietf@bunyip.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-uri@bunyip.com Precedence: bulk [I'm adding urn-ietf@bunyip.com to the Cc list since that is the list for the IETF's URN-WG.] Thus spoke Tim Berners-Lee: >The URN scheme should be >mapped onto >urn1://authority/nameissuedbyauthority The proposed URN syntax is laid out in draft-ietf-urn-syntax, but the short description is: urn:namespace_id:namespace_specific_string for example urn:isbn:1-234-5678-9 urn:upc:42709-10150 etc. Some namespaces, such as ISO Formal Public Identifiers, already make use of '//'. For such namespaces we say they need to %encode occurances of '/' that do not follow the rules of RFC1639. Those rules were that '/' denoted hierarchy with the most significant component on the left. >At 11:29 am 27-01-97 -0600, Daniel LaLiberte wrote: >>Are you just putting your foot down now .. finally. > >I've been out of the loop. URIs are not supposed to be irrevocably linked >to DNS! >Unfortunately there have been many demands on my time. I don't understand your assertion about DNS. No URN namespace is required to use domain names, as shown by the examples above. Certainly the namespaces we are considering for use at the lab have NO tie to the DNS. (They may be resolved through the DNS, but the names themselves don't use domain names). Members of the URN-WG have expressed a desire for a namespace that is easy for people to get started with, and lots of people think that using the domain name hierarchy (perhaps with some augmentations to overcome the reassignment problem) is the way to go. Such a namespace might look like urn:inet:acl.lanl.gov(1):fy97_budget but I emphasize that this is only one namespace out of many. [Lots of stuff on "///", "//", "/" deleted.] At this time we have not defined any relative URN specification. Nevertheless we do not allow unencoded occurances of '/' in URNs unless they follow the rules in RFC1630. Similarly, '?', '#', and a few other characters must be encoded unless they follow the rules of RFC1630. One of the URN requirements was to allow old namespaces to be grandfathered into URNs. Because of this, I am wary about requiring ALL URN namespaces to use '//'. Some namespaces will not have the notion of a relative identifier, others (such as path) may not need '//'. What we do require is that when representing a name from an old namespace as a URN, reserved characters are encoded unless they meet the semantics established by 1630. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab, MS B287 voice: +1 505 665 0597 Los Alamos National Laboratory fax: +1 505 665 4939 Los Alamos, NM, USA 87545 http://www.acl.lanl.gov/~rdaniel/ Want to buy: "The Five Laws of Library Science" by S.R. Ranganathan   Received: from cnri by ietf.org id aa11258; 30 Jan 97 11:58 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa14167; 30 Jan 97 11:58 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id LAA00857; Thu, 30 Jan 1997 11:45:35 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1907803 for TN3270E@LIST.NIH.GOV; Thu, 30 Jan 1997 11:45:31 -0500 Received: from doberman.cisco.com (doberman.cisco.com [171.69.1.178]) by list.nih.gov (8.7.5/8.6.12) with SMTP id LAA00841 for ; Thu, 30 Jan 1997 11:45:30 -0500 (EST) Received: from mboe-home-ss20.Cisco.COM (mboe-home-ss20.cisco.com [171.69.136.130]) by doberman.cisco.com (8.6.12/8.6.5) with ESMTP id IAA27813; Thu, 30 Jan 1997 08:24:28 -0800 Received: from localhost (localhost.cisco.com [127.0.0.1]) by mboe-home-ss20.Cisco.COM (8.6.8+c/CISCO.WS.1.1) with ESMTP id LAA01829; Thu, 30 Jan 1997 11:24:27 -0500 Date: Thu, 30 Jan 1997 11:24:27 -0500 (EST) From: Michael Boe Reply-To: Michael Boe Subject: Re: Associate configuration : Host or Server? To: Bill Kelly Cc: TN3270E list In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-tn3270e@list.nih.gov > On Wed, 29 Jan 1997, Paula Parash wrote: > > > In section 7.1.1 , the RFC deals with device pools. > > It emphasizes the role of the 3270E server in controlling and maintaining > > the different pools and specifically in defining a 'paired' printer > > device. > > > > >From a system administrator's point of view, how should these > > >definitions be > > done , keeping in mind the host's definitions? > > In other words, how should the server's definitions relate to the host's > > resources/definitions? > > I'm not sure I understand the specific question here, but... > > I think what you're asking is how the paired printer definitions are > related to other host definitions (since obviously from VTAM's point of > view there is no direct association between a terminal and a printer)? > > The example that comes to mind is where you have CICS applications that > maintain tables of terminal/printer pairs or groups. They use these > tables to determine where a print request coming from terminal X should be > sent. The table would tell it to send the output to printer Y. These > sorts of applications are common when you have public or shared sets of > terminals and printers, such as in public areas of a library, or at a > nursing station in a hospital. In these cases, the tn3270e server's > mapping of terminal and printer pairs would match the pairings defined in > the CICS application's tables. This way, when a tn3270e client requests a > paired printer, it will get the device name that matches the printer name > to which the CICS application will be sending print. The host-side administrative solution to the problem at the host & server end is pretty much guaranteed to ad-hoc and non-standard. This is because host-side print definitions are likewise ad-hoc and non-standard. IMS has different ways of doing this than CICS which works differently from modern session-managers, etc. The point of this is that the old working group (wisely) chose to make this a server-side problem and invented the ASSOCIATE print command to deal with it. The consequence of this is that the client does not need to know either the screen DEVICE-NAME or the printer DEVICE-NAME at start up. What *is* critical for the client to know a priori is the that Session B (a printer) should negotiate ASSOCIATE with a DEVICE-NAME which was returned from a server as a result of the TN3270E negotiation for Session A (a screen). That is, the client should associated a printer *session* with a screen *session*. The client should *not* associate a printer session with a hardcoded DEVICE-NAME. Unfortunately, the RFC is not all that clear in this area. Bill, this might another place that needs some clarification. /msb   Received: from cnri by ietf.org id aa25682; 30 Jan 97 18:56 EST Received: from list.nih.gov by CNRI.Reston.VA.US id aa29802; 30 Jan 97 18:56 EST Received: from list.nih.gov (terrific.net.nih.gov [165.112.130.6]) by list.nih.gov (8.7.5/8.6.12) with ESMTP id SAA14163; Thu, 30 Jan 1997 18:46:48 -0500 (EST) Received: from LIST.NIH.GOV by LIST.NIH.GOV (LISTSERV-TCP/IP release 1.8b) with spool id 1912880 for TN3270E@LIST.NIH.GOV; Thu, 30 Jan 1997 18:46:45 -0500 Received: from mail-host.walldata.com (mail-host.walldata.com [198.252.98.4]) by list.nih.gov (8.7.5/8.6.12) with SMTP id SAA14146 for ; Thu, 30 Jan 1997 18:46:40 -0500 (EST) Received: from msmail.walldata.com (postalunion.walldata.com) by mail-host.walldata.com (5.x/SMI-SVR4) id AA11934; Thu, 30 Jan 1997 15:46:27 -0800 Received: from Microsoft Mail (PU Serial #1100) by msmail.walldata.com (PostalUnion/SMTP(tm) v2.1.8d for Windows NT(tm)) id AA-1997Jan30.154422.1100.591256; Thu, 30 Jan 1997 15:47:21 -0800 From: "Erickson, Rodger" To: Bill Kelly , Michael Boe Cc: TN3270E list Message-Id: <1997Jan30.154422.1100.591256@msmail.walldata.com> X-Mailer: Microsoft Mail via PostalUnion/SMTP for Windows NT Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Organization: Wall Data Inc. Date: Thu, 30 Jan 1997 15:47:21 -0800 Subject: RE: Associate configuration : Host or S Sender: owner-tn3270e@list.nih.gov Michael Boe wrote: >The point of this is that the old working group (wisely) chose to make this a >server-side problem and invented the ASSOCIATE print command to deal with it. >The consequence of this is that the client does not need to know either the >screen DEVICE-NAME or the printer DEVICE-NAME at start up. What *is* >critical for the client to know a priori is the that Session B (a printer) should >negotiate ASSOCIATE with a DEVICE-NAME which was returned from a server >as a result of the TN3270E negotiation for Session A (a screen). That is, the >client should associated a printer *session* with a screen *session*. The >client should *not* associate a printer session with a hardcoded DEVICE-NAME. > >Unfortunately, the RFC is not all that clear in this area. Bill, this might >another place that needs some clarification. I wholeheartedly agree that this is something that should be clarified and expounded on a little bit in 1647. As an implementor that was not really involved at all with the TN3270E working group, I fell into the trap that Michael describes. Without further clarification in the RFC, I promise that others will fall into the trap and the feature could become "worthless" (if people are doing if differently because there's no "right" way to do it). Rodger Erickson Wall Data   Received: from cnri by ietf.org id aa28070; 31 Jan 97 13:16 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa16329; 31 Jan 97 13:16 EST Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA03668 for uri-out; Fri, 31 Jan 1997 12:29:17 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA03663; Fri, 31 Jan 1997 12:29:13 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26323 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 12:29:11 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id LAA16189; Fri, 31 Jan 1997 11:28:26 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id LAA04310; Fri, 31 Jan 1997 11:28:42 -0600 (CST) Date: Fri, 31 Jan 1997 11:28:42 -0600 (CST) Message-Id: <199701311728.LAA04310@void.ncsa.uiuc.edu> To: "Ron Daniel Jr." Cc: Ryan Moats , urn-ietf@bunyip.com, timbl@w3.org, uri@bunyip.com MMDF-Warning: Parse error in original version of preceding line at CNRI.Reston.VA.US Subject: URI and URN syntax In-Reply-To: <199701311547.IAA01443@acl.lanl.gov> References: <199701311547.IAA01443@acl.lanl.gov> Sender: owner-uri@bunyip.com Precedence: bulk Ron Daniel, Jr. writes: > My current position on this is that we should follow 1630 where it claims > to speak for all URI schemes. This means we should put % / # and ? into > the set of reserved characters for all URN namespaces. I think the > direction on = ; * and ! is less clear so I can go either way on those > characters. I agree that we should follow rfc 1630, and push for clarifications there if needed. In fact, why not simply inherit that spec rather than copy it into the URN syntax spec? If a URN is-a URI (it better be!), then URNs must inherit the URI constraints, although URNs can be more constrained. Tim B-L recently mentioned on the URI list that relative URIs may contain ";name=value;name=value" pairs in his original plans, but I don't know that this is actually followed in any practice, but the characters are still reserved unless explicitly unreserved. Instead, we see "?name=value&name=value" used for a similar purpose, but the structure after the '?' is merely a convention. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/  1997-01.mail0000666000175200000100000122757311373052002011502 0ustar steveywww Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA17305 for urn-ietf-out; Fri, 31 Jan 1997 18:11:43 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA17297 for ; Fri, 31 Jan 1997 18:11:40 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02494 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 18:11:39 -0500 From: Leslie Daigle Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id SAA15222 for urn-ietf@bunyip.com; Fri, 31 Jan 1997 18:11:38 -0500 Date: Fri, 31 Jan 1997 18:11:38 -0500 Message-Id: <199701312311.SAA15222@beethoven.bunyip.com> To: urn-ietf@bunyip.com Subject: [URN] You can pick your friends, but you inherit your relatives... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Leslie Daigle Errors-To: owner-urn-ietf@bunyip.com Okay, a lot of interesting material has been brought up on the subject of relative URNs, in particular as a case of relative URIs. Much good material has been flushed out this week, but it has also been made clear that there is much left to be understood. Of the questions that have been raised (and, indeed, many of the answers that have been given), I believe that we can't make any more progress on this at this point -- not until we have more of the base documents on the table and hammered out. One of the key things that was missing in many of the informal scenarios that were discussed is the issue of _assignment_ of URNs -- it hasn't yet been made clear that assignment will always be easy or immediate, so the notion of URNs in "working trees and published trees" _may_ not even be an issue. Also, some of the examples were based on assumptions that URNs are encountered _within documents_ and thus relativity was an issue of referring to the base document that was retrieved (without addressing the concept of URNs that then get pulled out of documents and kept for later use -- as Karen put it, escaping its environment in which the relation was defined. Or, is the environment of relationship in fact the object to which the URN is assigned, or some other construct in the namespace?). These are merely things that are not entirely clear until we've finished the basic work we set out to do. As Ron Daniel put it so succinctly earlier in the week: > My current position is that: > 1 URNs are one of the two forms of URI. > 2 URLs are the other form of URI. > 3 URNs are not URLs although they have a similar syntax. In fact, > we purposefully try to align our syntax with that of URLs in order > to avoid gratuitous differences. However, we don't adopt all of the > URL syntax features until we see how they impact the core purpose of > URNs - persistent, location-independent, resource identifiers. > (The difference, to me, is that URNs MUST NOT specify any > resolution-system specific hints, like protocol, port, host, etc. > while URLs typically do specify such things.) > (As a side note, the question of whether there really is a > difference between URNs and URLs has been beaten to death and has > been declared out of bounds for this list. The URN-WG charter > assumes there is such a difference, and if there is not then the > worst that happens to the world is that our work is moot.) > 4 In the absence of good arguments to the contrary, unencoded '/' in URNs > will end up denoting hierarchy as stated in RFC 1630. > 5 Since we have only just started seriously discussing relative URNs, > we have not reached consensus on the existance or absence of such a > good argument. > 6 Since the URN-WG is chartered to produce a URN Syntax draft, and > neither the charter or URN requirements RFC mentions relative URNs, we > should not stop the syntax draft while we discuss them. > 7 Therefore, the syntax draft should leave an escape hatch for relative > URNs. > 8 This is easy to do, we just state that '/' SHOULD (not MUST) be > %encoded, leaving the door open for people not to encode it if they > think > a) they are following the letter and spirit of 1630 > b) whatever we do decide will be in line with 1630 With regards to the discussion surrounding whether or not '/' should be encoded today, (specifically Roy Fielding's concerns and Dan Laliberte's elaboration on the FPI example), I think it's pretty clear that the point is: '/' should be % encoded iff: . in the particular namespace, '/' does not necessarily denote hierarchy (or other relative terms) . the designers of the namespace have determined that it is not desirable to expose that hierarchy _for_the_purposes_ _of_describing_relationships_between_URNs (e.g., if some other hierarchy is desired) Note that the '/' is intended to denote relativity in the _URN_namespace_, i.e., as part of the process of handling URNs. This _may_ in fact be distinct from any hierarchy as it is assigned in the underlying namespace. So, I think we have discussed this to the point where Ryan can move forward with the syntax document, and urge people to remember their good arguments and points of view so that we can come back to this thread _after_ we have moved forward with the namespace definition document, and various namespaces. Cheers! Leslie. ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA15960 for urn-ietf-out; Fri, 31 Jan 1997 17:53:47 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA15951 for ; Fri, 31 Jan 1997 17:53:44 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02309 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 17:53:43 -0500 From: Leslie Daigle Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id RAA15195 for urn-ietf@bunyip.com; Fri, 31 Jan 1997 17:53:40 -0500 Date: Fri, 31 Jan 1997 17:53:40 -0500 Message-Id: <199701312253.RAA15195@beethoven.bunyip.com> To: urn-ietf@bunyip.com Subject: [URN] Results from questions... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Leslie Daigle Errors-To: owner-urn-ietf@bunyip.com Thanks to everyone who replied to my request for comments on aligning URN and URL syntaxes (original message attached below). As promised, the replies themselves can (eventually -- a small matter of making material "go live" in our tree) be found at: http://www.bunyip.com/research/ietf/urn-ietf/lldrfc.txt Overall, people seemed to feel that URN syntax should be aligned with URI syntax -- see RFC 1630. This was part of the overall sentiment that URNs are URI schemes, and definitely _not_ URL schemes. There was almost unanimity on the point that URNs should _not_ go through the URL vetting process, except for one reply which I think had more to do with the fact that URNs should be _reviewed_ than that they should specifically be reviewed by the specific procedure developed for vetting URLs. As for whether or not aligning the syntax would facilitate acceptance of URNs in application software, responses varied from suggesting that it _would_ make it easier to the fact that the differences required for handling URNs would still be sufficiently great that it wouldn't be any easier for application software to handle URNs just because they had the same kind of syntax. However, no specific ills of aligning syntax have yet been identified. So, the effort was succesful insofar as it suggests that the group does not seem to anticipate major problems with the general course we are taking with the syntax (although there are some specific details to keep track of). Thanks again to all who answered. Leslie. ================== [Original request for comments] It seems to me that we are at a crossroads with the URN syntax, and we need to get some concrete sense of direction quickly. I'd like to outline the situation below and then ask for everyone to send feedback to me directly -- and please, do send feedback, if only to let me know people are still thinking about this :-) Ryan, our URN syntax document editor, has spent a good deal of time trying to get URN syntax to line up reasonably well with the existing URL syntax document (i.e., the de facto "URI" syntax document). This document is currently under review, and there are efforts afoot to determine a review process for vetting new URL schemes. As part of the discussion of this (on the uri@bunyip.com mailing list), the issue of URN conformance with URL syntax has come up. There are some specific changes that would (still) have to be made to accomplish this. While these are not necessarily stressing in terms of syntax, there are some particular ramifications that need to be considered: . If we align the syntaxes wrt reserved characters, etc, will URN: necessarily imply that URNs are a "scheme" of URLs? If so, then URNs will have to go through the URL vetting process, and potentially the string "URN" will be objected to. Also, will this imply that URNs are equivalent to URLs in terms of semantics? (There are those that think the are, and those that think they aren't). . Alternatively, can we align the syntaxes and succeed in having URN: treated as a special case by URL resolvers, (treated as an opaque URL, as Ryan described it). These questions have little to do with implementation details -- i.e., any of the above can certainly be implemented. The real questions, to my way of thinking, lie in: . Does lining up the syntaxes increase the likelihood of getting URNs handled sooner rather than later by existing software (i.e., are the necessary differences in handling going to mean that existing software can't handle them anyway?) . What issues will we have to address in terms of supporting/distinguishing URN/URL semantics? (E.g., if URNs are supported as URL "schemes", can we make the distinction between names and addresses). I have not been successful in trying to make this an even-handed message -- it is pretty clear that I am concerned that we are heading back into rough waters regarding "why do we need URNs when we have URLs". _However_, I know there are other people who have seen all of this and think that there is no real issue at all. So, please send feedback -- if you think there is an issue here, and why, or if you think there is no issue here, and why not. Please send directly to me -- I will summarize for the list, and make the collected messages available. Thanks, Leslie. ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA14694 for urn-ietf-out; Fri, 31 Jan 1997 17:34:35 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA14689 for ; Fri, 31 Jan 1997 17:34:26 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02091 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 17:34:22 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id QAA21077; Fri, 31 Jan 1997 16:34:05 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id QAA06798; Fri, 31 Jan 1997 16:34:21 -0600 (CST) Date: Fri, 31 Jan 1997 16:34:21 -0600 (CST) Message-Id: <199701312234.QAA06798@void.ncsa.uiuc.edu> To: "Martin J. Duerst" Cc: urn-ietf , URL mailing list Subject: Re: [URN] Re: Relative URLs and URNs In-Reply-To: References: <199701311759.LAA04496@void.ncsa.uiuc.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Martin J. Duerst writes: > For URLs, it's very clear how relative URLs behave. But for URNs, > there is an additional step: Resolution from name to location. There isn't necessarily any additional step. Names *can* be resolved "directly" to resources. Or perhaps you will get a URC or set of URLs back. "Directly" is in quotes because there is necessarily some indirection in the resolution process, but that may not involve getting a URL. > The question now is: is a relative URI supposed to be applied > to the name (i.e. before resolution, URN) or the location > (i.e. after resolution, URL) of the document. Given the above, this question doesn't necessarily make sense. But more below. But there is an easy answer to the question of how a relative URI is resolved relative to a base URN. The rules for relative URLs described in RFC 1808 (http://ds.internic.net/rfc/rfc1808.txt) should work exactly the same for URNs, with possibly one clarification described below. > We definitely cannot and should not assume that names and locations > are equally structured. Correct, we cannot. But you don't need to worry about that, if you follow the rules. RFC 1808 describes a seven step process for constructing the absolute URL from the relative URL and the context. We can just substitute URI (and therefore include URN) wherever it says URL. The first step of the seven concerns finding the base URI, which I give here in brief since that is where the clarification is needed. Use the first one that succeeds: 1. Use the explicit base URI from the document content, if any. 2. Use the explicit base URI from the encapsulating entity, if any. (e.g. http response message, another document, etc) 3. Use the URI used to retrieve the entity, if any. 4. Otherwise the base URI is undefined. Step 3 should be clarified: If there is no explicit base URI found by step 1 and 2, we should use the *last* URI used to retrieve the entity, not the first or some intermediate. This applies both for a chain of URL redirections or for a URN that is resolved into a URL. Roy Fielding pointed this out to me when I thought it should be the first URI used, or perhaps the last permanent redirect. So this clarification is an answer to your question above; whether the relative URI is applied to the name or the location depends on what the document and server say should be done. > > Is it true that the fpi URNs are non-hierarchical, or if they have > > hierarchical structure, you don't want to expose it? (I'd recommend > > that the syntax of fpi URNs expose the structure and avoid reserved > > chars, something like urn:fpi:/LANL/ACL/1997/03/01/4039/EN) > > What does exposing the structure help exactly? A resolver migh > very well use the last few digits of the long number for > distributed processing because it gives better distribution. Exposing the hierarchical structure *allows* use of relative URNs, but even with that structure, you wouldn't have to use relative URNs if you did not want to. Moreover, exposing the structure permits more scalable resolution. Information obtained at intermediate levels can be cached so the client can use that information in subsequent similar requests rather than requesting it again. As you say, instead of an explicit structuring of the name space (e.g. using '/' delimiter), an alternative is to use the characters in the identifier itself. The handle scheme would have clients hash the whole id and from that lookup one of several global handle servers. Either way, we have an essentially random distribution of servers - but this randomness defeats locality of reference. Locality of reference means, in this application, that you (or members of your local group) are likely to reference related material, so if the related material is colocated, you can remember the location (or other metadata) one time and use it again next time. But if you distribute randomly, the relationship between the material does not help. I've written (long ago - rough draft) some more on this scaling issue at: http://union.ncsa.uiuc.edu/~liberte/scalability.html In order of preference we have: 1. No distribution - one server 2. Random distribution 3. Organized distribution > > If a relative URI can be used with either an http URL > > base or a path URN base, you don't have to change anything but the base. > > I don't think that such parallel structures are really useful or > important. You expose an awful lot of structure that, for the sake of > persistency, you might want to hide. The flexibility to change name spaces and keep the same substructure is useful. If, as a result, you get *more* persistence, not less, that is important. > > Relative URNs *are* likely to save one a significant amount of work *if* > > you use a name space that is hierarchical and that supports relative > > URNs. > > Can you give more details on actual examples where this work is > saved? If you mean examples where I have actually saved work, no I have not done this yet. But Ron has described his experience which argues *against* the value of relative URIs in the case of moving the document to a *non*-hierarchical name space. A path URN is hierarchical, and looks just like an http URL except for the scheme and host part. The relative URIs in a document can remain exactly the same when moving to a path URN for the base. Not changing things saves time, obviously. dan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA14297 for urn-ietf-out; Fri, 31 Jan 1997 17:02:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA14291 for ; Fri, 31 Jan 1997 17:02:34 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01831 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 17:02:00 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <17158-0@josef.ifi.unizh.ch>; Fri, 31 Jan 1997 22:57:55 +0100 Date: Fri, 31 Jan 1997 22:57:54 +0100 (MET) From: "Martin J. Duerst" To: "Ron Daniel Jr." Cc: Daniel LaLiberte , URL mailing list , urn-ietf Subject: Re: [URN] Re: Relative URLs and URNs In-Reply-To: <3.0.32.19970131141946.009654f0@acl.lanl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Fri, 31 Jan 1997, Ron Daniel Jr. wrote: > Thus spoke Daniel LaLiberte: > >Ron Daniel, Jr. writes: > > > The point I was trying to make is that the presence of the relative > > > URLs is not helping us as we make the transition to URNs. > > > >Relative URLs (which are relative URIs intended to be interpreted > >relative to an absolute URL) would not interfere with a transition > >to URNs if you keep the same absolute URL base. > > Not always true. If our resolver offers the N2R service, its nice to > use it because bookmarks will be to the URN, not to a URL. Similarly, > the Location: text field in netscape will display the URN. However, > that means that relative URIs will be relative to the URN, not the > URL of the instance we fetch. Since the hierarchies are not the same, > it breaks. The problem that the thing you want to have in the bookmark and the thing you want to use for relative URL resolving are not the same was discussed earlier in quite some detail. It might be time to split these into two. But then again, I'm not at all sure whether this will lead to a consistent model for relative URNs, or whether this will contribute to the need for relative URNs. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA13773 for urn-ietf-out; Fri, 31 Jan 1997 16:43:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA13767 for ; Fri, 31 Jan 1997 16:43:55 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01530 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 16:43:51 -0500 Received: from montana (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id OAA09013; Fri, 31 Jan 1997 14:43:48 -0700 (MST) Message-Id: <3.0.32.19970131144250.0096d800@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 31 Jan 1997 14:43:27 -0700 To: Daniel LaLiberte From: "Ron Daniel Jr." Subject: Re: [URN] Re: Relative URLs and URNs Cc: URL mailing list , urn-ietf@bunyip.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com At 11:39 AM 1/31/97 -0600, Daniel LaLiberte wrote: >Ryan Moats writes: > > Just to make everyting clear, if the client does not understand the > > namespace, should treat the NSS as an opaque string, yes? (At least, > > I certainly hope so...) > >Nothing else makes sense. >But maybe such a client should commit suicide. :-) Whaa??? It seems to me that 1630 and other documents argue just the opposite - that the semantics of '/', '#', ... are set so that clients can slice and dice the URIs even if they don't know the scheme or namespace. More importantly, the same slicing and dicing code can be used across several known schemes. >As a general rule, for scalability in a world where clients far >out-number the servers, the clients or servers near the clients should >be doing most of the work. I'll certainly agree with that. Ron Daniel Jr. voice:+1 505 665 0597 Advanced Computing Lab fax:+1 505 665 4939 MS B287 email:rdaniel@lanl.gov Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel Los Alamos, NM, USA, 87545 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA13301 for urn-ietf-out; Fri, 31 Jan 1997 16:20:27 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA13296 for ; Fri, 31 Jan 1997 16:20:24 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00895 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 16:20:20 -0500 Received: from montana (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id OAA08668; Fri, 31 Jan 1997 14:20:11 -0700 (MST) Message-Id: <3.0.32.19970131141946.009654f0@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 31 Jan 1997 14:19:50 -0700 To: Daniel LaLiberte From: "Ron Daniel Jr." Subject: Re: [URN] Re: Relative URLs and URNs Cc: "URL mailing list" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com Thus spoke Daniel LaLiberte: >Ron Daniel, Jr. writes: > > The point I was trying to make is that the presence of the relative > > URLs is not helping us as we make the transition to URNs. > >Relative URLs (which are relative URIs intended to be interpreted >relative to an absolute URL) would not interfere with a transition >to URNs if you keep the same absolute URL base. Not always true. If our resolver offers the N2R service, its nice to use it because bookmarks will be to the URN, not to a URL. Similarly, the Location: text field in netscape will display the URN. However, that means that relative URIs will be relative to the URN, not the URL of the instance we fetch. Since the hierarchies are not the same, it breaks. > > For example, the document at > > http://www.acl.lanl.gov/URN/index.html > > might get a FPI of > > -//LANL ACL//199703014039//EN > > which results in the URN > > urn:fpi:-%2F%2FLANL%20ACL%2F%2F199703014039%2F%2FEN > >Is it true that the fpi URNs are non-hierarchical, or if they have >hierarchical structure, you don't want to expose it? (I'd recommend >that the syntax of fpi URNs expose the structure and avoid reserved >chars, something like urn:fpi:/LANL/ACL/1997/03/01/4039/EN) FPIs do have a hierarchical structure, and I have no strong feelings either way about exposing it. What I do care about is a reasonable approach to granfathering old namespaces. About the only objective criteria I know of for determining if a mapping from a legacy name to a URN is reasonable is to see if it is invertible. I can't recover the original FPI from your sample encoding of it because your '/' character could map to space, //, or nothing at all (where you put them into 1997/03/01/4039). (They could also map to :: in some FPIs). Being able to map to the original identifier is important since it allows us to add a URN resolution gateway on top of existing databases. Putting that problem aside, lets assume that I can use urn:fpi:/LANL/ACL/1997/03/01/4039/EN to refer to the document currently known as http://www.acl.lanl.gov/URN/index.html which has a relative reference to HREF="software.html" Since we are using N2R in order to get bookmarks to use the persistent name for a resource, Netscape would try to fetch new URNs that look like urn:fpi:/LANL/ACL/1997/03/01/4039/software.html This is the crucial problem with relative URNs. There are LOTs of different hierarchies into which a document can reasonably be placed. Relative URNs will persist across namespace transitions if we keep the same hierarchy. If we want to change the hierarchy, the relative references will no longer work. The scary thing about relative URNs is that if you access the document using someone else's name for it, your relative links will break (unless you have used something like the BASE tag, but then we are back to editing the documents to move to a new namespace). >Relative URNs *are* likely to save one a significant amount of work *if* >you use a name space that is hierarchical and that supports relative >URNs. ... *and* if your next namespace uses the same hierarchy as the earlier namespace. (In which case, why are you switching?) Ron Daniel Jr. voice:+1 505 665 0597 Advanced Computing Lab fax:+1 505 665 4939 MS B287 email:rdaniel@lanl.gov Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel Los Alamos, NM, USA, 87545 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA08476 for urn-ietf-out; Fri, 31 Jan 1997 14:25:47 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA08471 for ; Fri, 31 Jan 1997 14:25:44 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29302 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 14:25:42 -0500 Received: from montana (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA06717; Fri, 31 Jan 1997 12:25:38 -0700 (MST) Message-Id: <3.0.32.19970131121645.009b1260@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 31 Jan 1997 12:25:14 -0700 To: "Gregory J. Woodhouse" From: "Ron Daniel Jr." Subject: Re: [URN] Re: Relative URLs and URNs Cc: Daniel LaLiberte , URL mailing list , urn-ietf@bunyip.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com Thus spoke Gregory J. Woodhouse: >If there are >no relative URNs, many (most?) people will not use URNs because they will >be unable to develop web sites off-line (meaning off the production server, >not disconnected). I don't think that is quite true. Since the URN doesn't contain resolution system info, they get resolved through the use of a database that can map the URN to a URL, set of URLs, metadata, or the resource itself. People using URNs to refer to a connected set of resources will do their testing by having a set of URLs in the resolver database that point to the test environment. Once they are ready to go, they change those URLs to the production machine. Ron Daniel Jr. voice:+1 505 665 0597 Advanced Computing Lab fax:+1 505 665 4939 MS B287 email:rdaniel@lanl.gov Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel Los Alamos, NM, USA, 87545 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA08057 for urn-ietf-out; Fri, 31 Jan 1997 14:14:09 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA08022 for ; Fri, 31 Jan 1997 14:13:36 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29089 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 14:13:16 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id NAA17430; Fri, 31 Jan 1997 13:12:23 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id NAA05009; Fri, 31 Jan 1997 13:12:39 -0600 (CST) Date: Fri, 31 Jan 1997 13:12:39 -0600 (CST) Message-Id: <199701311912.NAA05009@void.ncsa.uiuc.edu> To: "Martin J. Duerst" Cc: Daniel LaLiberte , jayhawk@ds.internic.net, "Ron Daniel Jr." , omar syed , URL mailing list , urn-ietf@bunyip.com Subject: [URN] Proxies and extensible clients In-Reply-To: References: <199701311739.LAA04387@void.ncsa.uiuc.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Martin J. Duerst writes: > Not necessarily. With the number of URL schemes and URN namespaces > increasing, as well as the complexity of other things the client has > to do, it might be a very good implementation strategy to delegate > all the URL/URN resolution stuff to a *local* server (proxy). Yes, yes! I was going too far. By "client", I sometimes metaphorically mean things in the neighborhood of the client which act as sort of extensions of the client. A local proxy or Java applet that understands a scheme works just as well as, if not better than, explicitly cramming the hardcoded understanding of all schemes into one client. In fact, I am very interested in how a Java applet API can be done to avoid the security concerns (accessing arbitrary new servers). The main problem with new URI schemes is deploying them to millions of clients. Even proxies would have to be educated, so auto-downloadable code that understands new URI schemes and associated protocols would grease the rails on the bridge to the future. dan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA07603 for urn-ietf-out; Fri, 31 Jan 1997 14:06:08 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA07593 for ; Fri, 31 Jan 1997 14:06:06 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28916 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 14:06:00 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <08376-0@josef.ifi.unizh.ch>; Fri, 31 Jan 1997 20:02:11 +0100 Date: Fri, 31 Jan 1997 20:02:09 +0100 (MET) From: "Martin J. Duerst" To: Daniel LaLiberte Cc: "Ron Daniel Jr." , URL mailing list , urn-ietf Subject: Re: [URN] Re: Relative URLs and URNs In-Reply-To: <199701311759.LAA04496@void.ncsa.uiuc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Fri, 31 Jan 1997, Daniel LaLiberte wrote: > Relative URLs (which are relative URIs intended to be interpreted > relative to an absolute URL) This reminds me of an implicit problem here with URNs that I haven't seen answered: For URLs, it's very clear how relative URLs behave. But for URNs, there is an additional step: Resolution from name to location. The question now is: is a relative URI supposed to be applied to the name (i.e. before resolution, URN) or the location (i.e. after resolution, URL) of the document. We definitely cannot and should not assume that names and locations are equally structured. The later alternative would help for things such as coordinating between development and production version (there would be URNs for the "entry points" of the production version, but the rest would all be relative URLs). The former alternative seems to be implied by all those that see the need for hierarchical URN namespaces. I don't see how we could have both unless we introduce additional syntax (e.g. \ for URN hierarchy and / for URL hierarchy, or maybe something with /// and //). Daniel, maybe you can tell me which one you have in mind? > > The URNs > > we are assigning are very different from the URLs we currently use. > > For example, the document at > > http://www.acl.lanl.gov/URN/index.html > > might get a FPI of > > -//LANL ACL//199703014039//EN > > which results in the URN > > urn:fpi:-%2F%2FLANL%20ACL%2F%2F199703014039%2F%2FEN > > Is it true that the fpi URNs are non-hierarchical, or if they have > hierarchical structure, you don't want to expose it? (I'd recommend > that the syntax of fpi URNs expose the structure and avoid reserved > chars, something like urn:fpi:/LANL/ACL/1997/03/01/4039/EN) What does exposing the structure help exactly? A resolver migh very well use the last few digits of the long number for distributed processing because it gives better distribution. > > Relative URNs only save you work if the next > > namespace you use is very similar to the one you currently use. > > If they are not similar, then you have to edit the documents, just > > as you would have to do if you had used absolute identifiers. > > Or, another way of looking at it is that (absolute) URNs only save you > work if the structure of the name space is similar to the one you > currently use. If a relative URI can be used with either an http URL > base or a path URN base, you don't have to change anything but the base. I don't think that such parallel structures are really useful or important. You expose an awful lot of structure that, for the sake of persistency, you might want to hide. > > This is not a damning indictment of relative URNs, it just points out > > that they are unlikely to save one a significant amount of work. > > Relative URNs *are* likely to save one a significant amount of work *if* > you use a name space that is hierarchical and that supports relative > URNs. Can you give more details on actual examples where this work is saved? Not that I am absolutely against relative URNs, as some of my mail may have suggested. But I just try to figure things out, and for some of the things, I don't have an answer yet. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA07270 for urn-ietf-out; Fri, 31 Jan 1997 14:01:54 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA07259 for ; Fri, 31 Jan 1997 14:01:51 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28867 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 14:01:49 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id OAA11060; Fri, 31 Jan 1997 14:01:42 -0500 Date: Fri, 31 Jan 1997 14:01:42 -0500 Message-Id: <199701311901.OAA11060@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: gjw@wnetc.com Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com In-Reply-To: (gjw@wnetc.com) Subject: Re: [URN] Reltive URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com Yes, URNs are intended not only to be persistent, but also to be global. Furthermore, the closest we got in the URN requirements to humans was to say that they be "human transcribable". We intentionally did not go further into the realm of human friendliness. Relative and global are contradictory in my model of this world, unless someone can _guarantee_ that a relative URN would NEVER escape the environment within which it is relative without being converted to its global representation. But, if that's the case, it doesn't belong in a standard anyway; it's a private convention, and people can do anything they want in private, as long as it doesn't affect the outside world. So, this whole discussion about "relative" URNs leaves me very puzzled. Karen Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA05998 for urn-ietf-out; Fri, 31 Jan 1997 13:40:24 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA05993 for ; Fri, 31 Jan 1997 13:40:20 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27792 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 13:40:16 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Jan 31 12:39 CST 1997 Message-Id: <32F22E54.4A3@ds.internic.net> Date: Fri, 31 Jan 1997 12:39:32 -0500 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 2.02E (OS/2; I) Mime-Version: 1.0 To: "Gregory J. Woodhouse" Cc: "Ron Daniel Jr." , Daniel LaLiberte , URL mailing list , urn-ietf@bunyip.com Subject: Re: [URN] Re: Relative URLs and URNs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Gregory J. Woodhouse wrote: > > I always use relative URLs for my internal links. One reason I do this is > so that I can maintain a copy of my site (or part thereof) on my > workstation for development purposes and then upload it to the server. If > URNs can only be absolute, then this methodology doesn't work. If there are > no relative URNs, many (most?) people will not use URNs because they will > be unable to develop web sites off-line (meaning off the production server, > not disconnected). > While I agree that developing web-sites on development machines becomes easier with relative URIs, I don't buy that not having them makes it impossible, just more difficult. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA05917 for urn-ietf-out; Fri, 31 Jan 1997 13:37:24 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA05911 for ; Fri, 31 Jan 1997 13:37:21 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27421 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 13:37:12 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <06735-0@josef.ifi.unizh.ch>; Fri, 31 Jan 1997 19:32:13 +0100 Date: Fri, 31 Jan 1997 19:32:11 +0100 (MET) From: "Martin J. Duerst" To: Daniel LaLiberte Cc: jayhawk@ds.internic.net, "Ron Daniel Jr." , omar syed , URL mailing list , urn-ietf@bunyip.com Subject: Re: [URN] Re: Relative URLs and URNs In-Reply-To: <199701311739.LAA04387@void.ncsa.uiuc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Fri, 31 Jan 1997, Daniel LaLiberte wrote: > Ryan Moats writes: > > Just to make everyting clear, if the client does not understand the > > namespace, should treat the NSS as an opaque string, yes? (At least, > > I certainly hope so...) > > Nothing else makes sense. > But maybe such a client should commit suicide. :-) Not necessarily. With the number of URL schemes and URN namespaces increasing, as well as the complexity of other things the client has to do, it might be a very good implementation strategy to delegate all the URL/URN resolution stuff to a *local* server (proxy). Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA05909 for urn-ietf-out; Fri, 31 Jan 1997 13:37:19 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA05903 for ; Fri, 31 Jan 1997 13:37:14 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27305 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 13:34:10 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <06046-0@josef.ifi.unizh.ch>; Fri, 31 Jan 1997 19:17:48 +0100 Date: Fri, 31 Jan 1997 19:17:46 +0100 (MET) From: "Martin J. Duerst" To: Daniel LaLiberte Cc: "Ron Daniel Jr." , omar syed , URL mailing list , urn-ietf Subject: Re: [URN] Re: Relative URLs and URNs In-Reply-To: <199701311656.KAA03953@void.ncsa.uiuc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Fri, 31 Jan 1997, Daniel LaLiberte wrote: > > Thus spoke Omar Syed: > > > 2. clients must treat as an opaque string (i.e. do not interperet) > > > Ron Daniel, Jr. writes: > > I think assumption 2 is in error. Clients that know the structure of > > a name in a particular namespace are likely to manipulate it. > > I agree. Clients, of course, can do whatever they want (whatever they > can get away with) anyway, but they have to be able to interpret the > structure of an identifier in order to do as much processing of it on > their own as they can. Forcing clients (if that were possible) to > always consult a remote server to process the whole identifier is a > sure way to make the system unscalable. Forcing to consult a *remote* server is a bad thing. On the other hand, if we would require that a client *has to* understand anything about the structure of certain URNs, that might also be too much of a limitation. > Ron Daniel, Jr. writes: > > This is the sort of problem I am running into now in our tests, where > > we have a bunch of HTML pages we are retroactively assigning URNs to. > > Since those pages have lots of relative links in them, we can either: > > 1) Make sure our new URNs reflect the same filesystem arrangement > > as the pages do. > > 2) Modify the pages to make all the references absolute. > > Alternative 1 certainly is unattractive, since a major point of URNs is > > to provide independence from the filesystem organization du jour. > > First, identifiers (relative or not) may *reflect* a filesystem > structure, but it is up to the server whether to look up an identifier > in a filesystem, database, or pass it to a CGI program, for > example. So it is incorrect to assume filesystems specifically. For what Ron is saying, the fact that it is the *filesystem* structure is irrelevant. It could be any hierarchy. The main point is that if you want to keep relative addressing and change the base, then you have to keep the structure. This is a good thing with relative URLs, because currently they mainly point to filesystems and coordinated relocation of directory subtrees is an operation well supported for filesystems. It's an operation that is much less supported/common, and much less important, for other kinds of things, for example for rote numberings and for conceptual hierarchies (two of the things various people think URNs might be used for). > But going beyond that, the identier may reflect a hierarchical > structure (filesystem or not) and if you want that structure to be > persistent, you have to arrange that old identifiers are redirected > to the new identifiers, and the old identifiers are not reused for > other purposes. As far as I know, we mainly want the identifiers to be persistent. Then if a bunch of identifiers stay persistent, their structure will stay persistent (with the same sense of persistency as the identifiers themselves). For URNs (in contrast to URLs), keeping the structure when moving from one namespace to another (or one part of a hierarchy to another if there is a hierarchy) seems not to be that important. In particular, for namespaces, the reason to make a new namespace might very clearly be that you want to have another structure. If you need the same structure, you can always use the old names. For example, if you take ISBN. It has structure: country/publisher/book/error code. Now take Library of Congress numbers. If they had been happy with the structure of ISBNs, they would have used ISBNs (well, maybe historically, they were first). Some more general thoughts: One important question is whether one sees the world as primarily hierarchical or not. File systems and the military are primarily hierarchical, other systems are less so. Tim said in an earlier message that throwing away the special meaning of "/" would mean loosing generality. But this is only so if one sees the hierarchy as the general case, and the non-hierarchical case as a one-level hierarchy. From another viewpoint, everything is opaque, and the hierarchical structure is just an internal affair. Daniel, in other mails you have made references to efficiency problems that can be alleviated by hierarchy. However, even if an URN is completely opaque, there is no reason to have efficiency problems. For example, the client could ask a resolver close to it to help out, and this could go ask another resolver if it can't deal with it. If you have to split the load for a huge namespace, you can as well split it on semantically meaningful boundaries as you can split it on arbitrary boundaries (e.g. take the two first letters of the string to decide which next resolver to contact. For an example, in DNS currently zones are related to ".". This creates big problems because the .com-domain is too big. If we had a mechanism to split such domains (I guess work is going on on such things), then one of the obvious things would be to split them on the last or the last two letters of the label before .com. Another idea is that something such as Java Applets are part of a resolution scheme. For example, on a request for an URN resolution, a browser recieves a (reference to) a piece of code that it uses according to certain conventions. Such an applet could for example do such things as say "Hey, I know this namespace, and I know it has certain conventions for hierarchies, and these hierarchies in that case actually are connected to the way these things are resolved, and I just helped resolve an URN aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa^xyz which is very similar to what I have to help resolve now, namely aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa^pqr so let's use (most of) the result of what I got for the previous resolution. Just some ideas. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA04368 for urn-ietf-out; Fri, 31 Jan 1997 13:16:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA04363 for ; Fri, 31 Jan 1997 13:16:47 -0500 Received: from proxy1.ba.best.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26799 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 13:16:43 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy1.ba.best.com (8.8.5/8.8.3) with SMTP id KAA13919; Fri, 31 Jan 1997 10:00:50 -0800 (PST) Date: Fri, 31 Jan 1997 10:00:49 -0800 (PST) From: "Gregory J. Woodhouse" To: "Ron Daniel Jr." Cc: Daniel LaLiberte , URL mailing list , urn-ietf@bunyip.com Subject: Re: [URN] Re: Relative URLs and URNs In-Reply-To: <3.0.32.19970131103134.00914c00@acl.lanl.gov> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com I always use relative URLs for my internal links. One reason I do this is so that I can maintain a copy of my site (or part thereof) on my workstation for development purposes and then upload it to the server. If URNs can only be absolute, then this methodology doesn't work. If there are no relative URNs, many (most?) people will not use URNs because they will be unable to develop web sites off-line (meaning off the production server, not disconnected). --- gjw@wnetc.com / http://www.wnetc.com/home.html If you're going to reinvent the wheel, at least try to come to come up with a better one. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA04251 for urn-ietf-out; Fri, 31 Jan 1997 13:11:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA04246 for ; Fri, 31 Jan 1997 13:11:42 -0500 Received: from proxy2.ba.best.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26762 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 13:11:40 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.8.5/8.8.3) with SMTP id KAA00732; Fri, 31 Jan 1997 10:05:10 -0800 (PST) Date: Fri, 31 Jan 1997 10:05:10 -0800 (PST) From: "Gregory J. Woodhouse" To: Daniel LaLiberte Cc: jayhawk@ds.internic.net, "Ron Daniel Jr." , omar syed , URL mailing list , urn-ietf@bunyip.com Subject: Re: [URN] Re: Relative URLs and URNs In-Reply-To: <199701311739.LAA04387@void.ncsa.uiuc.edu> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com On Fri, 31 Jan 1997, Daniel LaLiberte wrote: > > As a general rule, for scalability in a world where clients far > out-number the servers, the clients or servers near the clients should > be doing most of the work. > > dan > Excellent point. --- gjw@wnetc.com / http://www.wnetc.com/home.html If you're going to reinvent the wheel, at least try to come to come up with a better one. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA04057 for urn-ietf-out; Fri, 31 Jan 1997 12:59:42 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA04051 for ; Fri, 31 Jan 1997 12:59:40 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26659 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 12:59:37 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id LAA16540; Fri, 31 Jan 1997 11:59:19 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id LAA04496; Fri, 31 Jan 1997 11:59:36 -0600 (CST) Date: Fri, 31 Jan 1997 11:59:36 -0600 (CST) Message-Id: <199701311759.LAA04496@void.ncsa.uiuc.edu> To: "Ron Daniel Jr." Cc: Daniel LaLiberte , "URL mailing list" , Subject: Re: [URN] Re: Relative URLs and URNs In-Reply-To: <3.0.32.19970131103134.00914c00@acl.lanl.gov> References: <3.0.32.19970131103134.00914c00@acl.lanl.gov> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Ron Daniel, Jr. writes: > The point I was trying to make is that the presence of the relative > URLs is not helping us as we make the transition to URNs. Relative URLs (which are relative URIs intended to be interpreted relative to an absolute URL) would not interfere with a transition to URNs if you keep the same absolute URL base. But if you want each and every one of your documents to have a URN, and you can't use relative URNs then you have to use absolute URNs. That much is clear. > The URNs > we are assigning are very different from the URLs we currently use. > For example, the document at > http://www.acl.lanl.gov/URN/index.html > might get a FPI of > -//LANL ACL//199703014039//EN > which results in the URN > urn:fpi:-%2F%2FLANL%20ACL%2F%2F199703014039%2F%2FEN Is it true that the fpi URNs are non-hierarchical, or if they have hierarchical structure, you don't want to expose it? (I'd recommend that the syntax of fpi URNs expose the structure and avoid reserved chars, something like urn:fpi:/LANL/ACL/1997/03/01/4039/EN) > Relative URNs only save you work if the next > namespace you use is very similar to the one you currently use. > If they are not similar, then you have to edit the documents, just > as you would have to do if you had used absolute identifiers. Or, another way of looking at it is that (absolute) URNs only save you work if the structure of the name space is similar to the one you currently use. If a relative URI can be used with either an http URL base or a path URN base, you don't have to change anything but the base. > This is not a damning indictment of relative URNs, it just points out > that they are unlikely to save one a significant amount of work. Relative URNs *are* likely to save one a significant amount of work *if* you use a name space that is hierarchical and that supports relative URNs. dan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA03895 for urn-ietf-out; Fri, 31 Jan 1997 12:40:04 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA03888 for ; Fri, 31 Jan 1997 12:40:01 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26437 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 12:39:59 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id LAA16342; Fri, 31 Jan 1997 11:39:38 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id LAA04387; Fri, 31 Jan 1997 11:39:55 -0600 (CST) Date: Fri, 31 Jan 1997 11:39:55 -0600 (CST) Message-Id: <199701311739.LAA04387@void.ncsa.uiuc.edu> To: jayhawk@ds.internic.net Cc: Daniel LaLiberte , "Ron Daniel Jr." , omar syed , URL mailing list , urn-ietf@bunyip.com Subject: Re: [URN] Re: Relative URLs and URNs In-Reply-To: <32F21E1E.4387@ds.internic.net> References: <199701310644.XAA03311@acl.lanl.gov> <199701311656.KAA03953@void.ncsa.uiuc.edu> <32F21E1E.4387@ds.internic.net> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Ryan Moats writes: > Just to make everyting clear, if the client does not understand the > namespace, should treat the NSS as an opaque string, yes? (At least, > I certainly hope so...) Nothing else makes sense. But maybe such a client should commit suicide. :-) As a general rule, for scalability in a world where clients far out-number the servers, the clients or servers near the clients should be doing most of the work. dan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA03751 for urn-ietf-out; Fri, 31 Jan 1997 12:34:00 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA03663; Fri, 31 Jan 1997 12:29:13 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26323 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 12:29:11 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id LAA16189; Fri, 31 Jan 1997 11:28:26 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id LAA04310; Fri, 31 Jan 1997 11:28:42 -0600 (CST) Date: Fri, 31 Jan 1997 11:28:42 -0600 (CST) Message-Id: <199701311728.LAA04310@void.ncsa.uiuc.edu> To: "Ron Daniel Jr." Cc: "Ryan Moats" , , timbl@w3.org, uri@bunyip.com Subject: [URN] URI and URN syntax In-Reply-To: <199701311547.IAA01443@acl.lanl.gov> References: <199701311547.IAA01443@acl.lanl.gov> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Ron Daniel, Jr. writes: > My current position on this is that we should follow 1630 where it claims > to speak for all URI schemes. This means we should put % / # and ? into > the set of reserved characters for all URN namespaces. I think the > direction on = ; * and ! is less clear so I can go either way on those > characters. I agree that we should follow rfc 1630, and push for clarifications there if needed. In fact, why not simply inherit that spec rather than copy it into the URN syntax spec? If a URN is-a URI (it better be!), then URNs must inherit the URI constraints, although URNs can be more constrained. Tim B-L recently mentioned on the URI list that relative URIs may contain ";name=value;name=value" pairs in his original plans, but I don't know that this is actually followed in any practice, but the characters are still reserved unless explicitly unreserved. Instead, we see "?name=value&name=value" used for a similar purpose, but the structure after the '?' is merely a convention. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA03728 for urn-ietf-out; Fri, 31 Jan 1997 12:32:53 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA03723 for ; Fri, 31 Jan 1997 12:32:51 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26357 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 12:32:48 -0500 Received: from montana (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA02713; Fri, 31 Jan 1997 10:32:44 -0700 (MST) Message-Id: <3.0.32.19970131103134.00914c00@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 31 Jan 1997 10:32:19 -0700 To: Daniel LaLiberte From: "Ron Daniel Jr." Subject: Re: [URN] Re: Relative URLs and URNs Cc: "URL mailing list" , Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com Thus spoke Daniel LaLiberte: >Ron Daniel, Jr. writes: > > This is the sort of problem I am running into now in our tests, where > > we have a bunch of HTML pages we are retroactively assigning URNs to. >First, identifiers (relative or not) may *reflect* a filesystem >structure, but it is up to the server whether to look up an identifier >in a filesystem, database, or pass it to a CGI program, for >example. So it is incorrect to assume filesystems specifically. The point I was trying to make is that the presence of the relative URLs is not helping us as we make the transition to URNs. The URNs we are assigning are very different from the URLs we currently use. For example, the document at http://www.acl.lanl.gov/URN/index.html might get a FPI of -//LANL ACL//199703014039//EN which results in the URN urn:fpi:-%2F%2FLANL%20ACL%2F%2F199703014039%2F%2FEN Relative URNs only save you work if the next namespace you use is very similar to the one you currently use. If they are not similar, then you have to edit the documents, just as you would have to do if you had used absolute identifiers. This is not a damning indictment of relative URNs, it just points out that they are unlikely to save one a significant amount of work. Ron Daniel Jr. voice:+1 505 665 0597 Advanced Computing Lab fax:+1 505 665 4939 MS B287 email:rdaniel@lanl.gov Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel Los Alamos, NM, USA, 87545 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA03702 for urn-ietf-out; Fri, 31 Jan 1997 12:31:23 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA03697 for ; Fri, 31 Jan 1997 12:31:21 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26337 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 12:31:16 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Jan 31 11:30 CST 1997 Message-Id: <32F21E1E.4387@ds.internic.net> Date: Fri, 31 Jan 1997 11:30:22 -0500 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 2.02E (OS/2; I) Mime-Version: 1.0 To: Daniel LaLiberte Cc: "Ron Daniel Jr." , omar syed , URL mailing list , urn-ietf@bunyip.com Subject: Re: [URN] Re: Relative URLs and URNs References: <199701310644.XAA03311@acl.lanl.gov> <199701311656.KAA03953@void.ncsa.uiuc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Daniel LaLiberte wrote: > > > Thus spoke Omar Syed: > > > 2. clients must treat as an opaque string (i.e. do not interperet) > > > Ron Daniel, Jr. writes: > > I think assumption 2 is in error. Clients that know the structure of > > a name in a particular namespace are likely to manipulate it. > > I agree. Clients, of course, can do whatever they want (whatever they > can get away with) anyway, but they have to be able to interpret the > structure of an identifier in order to do as much processing of it on > their own as they can. Forcing clients (if that were possible) to > always consult a remote server to process the whole identifier is a > sure way to make the system unscalable. Just to make everyting clear, if the client does not understand the namespace, should treat the NSS as an opaque string, yes? (At least, I certainly hope so...) Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA03225 for urn-ietf-out; Fri, 31 Jan 1997 12:00:21 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA03220 for ; Fri, 31 Jan 1997 12:00:10 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25976 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 12:00:05 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id JAA12605; Fri, 31 Jan 1997 09:00:01 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id IAA26793; Fri, 31 Jan 1997 08:59:55 -0800 (PST) Date: Fri, 31 Jan 1997 08:59:55 -0800 (PST) From: Terry Allen Message-Id: <199701311659.IAA26793@ishtar.fsc.fujitsu.com> To: jayhawk@ds.internic.net, mduerst@ifi.unizh.ch Subject: Re: [URN] Some good ideas coming out of the "relative..." discussions... Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com >2. While I don't mind adding "#" to the reserved list (unless somebody screams), it does bring to mind creeping "featuritis". Do we want to reserve "?" as well? How much of the "special" meaning URL characters do we want to use for the same meaning? (I don't have a position yet, I'm just trying to take the pulse of the mailing list...) I believe the XML folks are finding the URL # and ? features rather restrictive. They want to use TEI's extended pointer syntax for XML linking, and are creeping up on the point where they'll have to say how it can be represented in URLs. It's not clear yet that it can be, completely. So it may be that for complex queries (and requests that are meant to retrieve only part of an object) a more flexible approach will be to send a UR* plus some additional information. (I have no suggestion yet about how to do this.) We should not assume that # and ? are sufficient to fulfill all needs. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA03192 for urn-ietf-out; Fri, 31 Jan 1997 11:56:47 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA03187 for ; Fri, 31 Jan 1997 11:56:39 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25934 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 11:56:37 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id KAA15830; Fri, 31 Jan 1997 10:56:23 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id KAA03953; Fri, 31 Jan 1997 10:56:39 -0600 (CST) Date: Fri, 31 Jan 1997 10:56:39 -0600 (CST) Message-Id: <199701311656.KAA03953@void.ncsa.uiuc.edu> To: "Ron Daniel Jr." Cc: "omar syed" , "URL mailing list" , Subject: Re: [URN] Re: Relative URLs and URNs In-Reply-To: <199701310644.XAA03311@acl.lanl.gov> References: <199701310644.XAA03311@acl.lanl.gov> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: "owner-urn-ietf@bunyip.com > Thus spoke Omar Syed: > > 2. clients must treat" as an opaque string (i.e. do not interperet) Ron Daniel, Jr. writes: > I think assumption 2 is in error. Clients that know the structure of > a name in a particular namespace are likely to manipulate it. I agree. Clients, of course, can do whatever they want (whatever they can get away with) anyway, but they have to be able to interpret the structure of an identifier in order to do as much processing of it on their own as they can. Forcing clients (if that were possible) to always consult a remote server to process the whole identifier is a sure way to make the system unscalable. Ron Daniel, Jr. writes: > This is the sort of problem I am running into now in our tests, where > we have a bunch of HTML pages we are retroactively assigning URNs to. > Since those pages have lots of relative links in them, we can either: > 1) Make sure our new URNs reflect the same filesystem arrangement > as the pages do. > 2) Modify the pages to make all the references absolute. > Alternative 1 certainly is unattractive, since a major point of URNs is > to provide independence from the filesystem organization du jour. First, identifiers (relative or not) may *reflect* a filesystem structure, but it is up to the server whether to look up an identifier in a filesystem, database, or pass it to a CGI program, for example. So it is incorrect to assume filesystems specifically. But going beyond that, the identier may reflect a hierarchical structure (filesystem or not) and if you want that structure to be persistent, you have to arrange that old identifiers are redirected to the new identifiers, and the old identifiers are not reused for other purposes. Redirecting is supported by NCSA httpd, and I assume many other servers. Instead of sending a redirection back to the client, the server could handle it itself, especially if the new place is within the same server. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA01685 for urn-ietf-out; Fri, 31 Jan 1997 10:47:49 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA01679 for ; Fri, 31 Jan 1997 10:47:47 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24954 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 10:47:44 -0500 Received: from montana (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id IAA01443; Fri, 31 Jan 1997 08:47:34 -0700 (MST) Message-Id: <199701311547.IAA01443@acl.lanl.gov> From: "Ron Daniel Jr." To: "Ryan Moats" Cc: Subject: Re: [URN] Some good ideas coming out of the "relative..." discussions... Date: Fri, 31 Jan 1997 08:46:04 -0700 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com Thus spoke Ryan Moats: > 2. While I don't mind adding "#" to the reserved list (unless somebody > screams), it does bring to mind creeping "featuritis". Do we want to > reserve "?" as well? How much of the "special" meaning URL characters > do we want to use for the same meaning? (I don't have a position yet, > I'm just trying to take the pulse of the mailing list...) RFC 1630 is not totally consistent on this. The prose reserves the four characters %, /, #, and ? for purposes it describes and that we are all familiar with. The prose also says that * and ! "are reserved for use as having special signifiance [sic] within specific schemes". I'm not sure what that means. The BNF says that the reserved characters are = ; # ? : and space. However, literal occurances of space are not reserved, they are forbidden. Similarly, only the first occurance of : has a reserved meaning. The RFC defines the use of ; and = in some specific URL schemes but makes no overall statement on their use. My current position on this is that we should follow 1630 where it claims to speak for all URI schemes. This means we should put % / # and ? into the set of reserved characters for all URN namespaces. I think the direction on = ; * and ! is less clear so I can go either way on those characters. Ron Daniel Jr. voice:+1 505 665 0597 Advanced Computing Lab fax:+1 505 665 4939 MS B287 email:rdaniel@lanl.gov Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel Los Alamos, NM, USA, 87545 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA00221 for urn-ietf-out; Fri, 31 Jan 1997 09:28:44 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA00216 for ; Fri, 31 Jan 1997 09:28:42 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23806 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 09:28:39 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Jan 31 08:27 CST 1997 Message-Id: <32F1F32E.7FD4@ds.internic.net> Date: Fri, 31 Jan 1997 08:27:10 -0500 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 2.02E (OS/2; I) Mime-Version: 1.0 To: "Martin J. Duerst" Cc: urn-ietf@bunyip.com Subject: Re: [URN] Some good ideas coming out of the "relative..." discussions... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Martin J. Duerst wrote: > > On Thu, 30 Jan 1997, Ryan Moats wrote: > > > Mainly, I am thinking of creating a "reserved" set, that > > contains "%" and "/". The reason's for "%" being reserved are well > > known, and that text would be moved to that section. > > > > For "/", Ron and I worked out the following proposed text: > > > > ... > > "/" is RESERVED for future developments. It might be used for > > denoting hierarchy to allow for relative URN processing, but the WG > > has not yet reached consensus on this, so such developments will be > > documented separately. In the interim, namespace developers SHOULD NOT > > use an unecoded "/", but rather use %-encoding for "/" ("%2F"). > > ... > > That should be a MUST, of course. And if we are at it, why not > also put "#" into the reserved set? Two things: 1. Martin, I've read your mail to the list. I assume that you no longer are worried about the "SHOULD" above. It was chosen on purpose after some thought. 2. While I don't mind adding "#" to the reserved list (unless somebody screams), it does bring to mind creeping "featuritis". Do we want to reserve "?" as well? How much of the "special" meaning URL characters do we want to use for the same meaning? (I don't have a position yet, I'm just trying to take the pulse of the mailing list...) 3. At this point, I'll hold off the next pre-release of the draft until point 2 gets a bit more clear (however I am putting place holders in this morning...) Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA29815 for urn-ietf-out; Fri, 31 Jan 1997 09:07:28 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA29805 for ; Fri, 31 Jan 1997 09:07:24 -0500 Received: from aruba.lerc.nasa.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23636 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 09:07:20 -0500 Received: from btree.lerc.nasa.gov by aruba.lerc.nasa.gov with ESMTP (NASA LeRC 8.7.4.1/2.01-main) id UAA27626; Thu, 30 Jan 1997 20:19:53 -0500 (EST) Received: from btree by btree.lerc.nasa.gov with SMTP (NASA LeRC 8.7.4.1/2.01-local) id UAA23745; Thu, 30 Jan 1997 20:19:53 -0500 (EST) Message-Id: <32F148B7.4313@lerc.nasa.gov> Date: Thu, 30 Jan 1997 20:19:51 -0500 From: omar syed Organization: NASA Lewis Research Center X-Mailer: Mozilla 3.0 (X11; U; SunOS 5.5.1 sun4u) Mime-Version: 1.0 To: "Ron Daniel Jr." Cc: Keith Moore , Tim Berners-Lee , Daniel LaLiberte , "Martin J. Duerst" , URL mailing list , urn-ietf@bunyip.com Subject: Re: [URN] Re: Relative URLs and URNs References: <199701300607.XAA02743@acl.lanl.gov> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: omar syed Errors-To: owner-urn-ietf@bunyip.com Ron Daniel Jr. wrote: > > Thus spoke Keith Moore: > > > If we disallow unencoded '/' within URNs for now, we can always add > > relative URNs later when we understand them better. > > I couldn't agree more. > > Encoding '/' is a bit cumbersome, but it is worth it for the potential > gain in the future. Hello members of IETF URN WG, I have recently joined this mailing list. But, I have had an interest in URNs ever since I learned about the Web and found that URLs are not persistent (around 1993). I have read the related RFC's and scanned through the old mailing list archives. I just wanted to ask some questions and bring up some concerns about relative URNs (since that is a hot topic right now). Maybe the WG has already addressed them. If so, please enlighten me. The rest of what I say is predicated on the following: 1. urn:: 2. clients must treat as an opaque string (i.e. do not interperet) 3. the details of interpereting a are know only to coresponding resolvers 4. clients must use appropriate resolvers to map the to a location or resource Now then, assume we have a resource r1 and a resource r2. Lets say that a reference to resource r1 is: urn:nid1:A:B:Res1 Lets say that a reference to resource r2 is: urn:nid1:A:B:Res2 Lets also assume that resource r1 contains a relative reference to r2. Maybe something like . Now for the questions: If the client, after retreiving resource r1, wishes to get the resource identified by "Res2", how does it proceed? It can identify that this reference does not specify a scheme, so it should use the same scheme it used to get the current resource. But the client is not allowed to interperet the so it cannot replace the "Res1" from the previous absolute URN with "Res2" to create a new URN. The best it can do (I think) is pass both the previous absolute URN and the current relative URN to the top level resolver of the nid1 name space. Is this how a client is supposed to proceed? If so, then a delimiter is needed to seperate the absolute URN from the releative URN when the client passes this info to the resolver. Is '/' being reserved for this purpose? Maybe something like: urn::/ Now for the serious concerns: Lets say that another valid reference for resouce r1 is: urn:nid2:X:Y:resource1 Suppose a client uses this absolute URN to get r1 and then comes across the relative URN: "Res2". The first concern is that the client won't even know that the author of resource r1 had intended the relative URN to be retrieved using the "urn:nid1" scheme. Is there a way for an author to specify the intended scheme along with the relative URN? Using "urn:nid1:Res2" should with the current interpertation cause the client to treat it as an absolute URN. Will the '/' (or other reserved character) be used to indicate a relative URN. Maybe something like: urn:nid1:/Res2. Also will authors have to maintain multiple relative URN references (for each that can be used to reference it)? For example: Will HTML specs be modified to allow this? Assuming the relative URN in resource r1 reads , but the absolute URN: urn:nid2:X:Y:resource1 was used to retreive r1. Can the client now use something like: urn:nid2:X:Y:resource1/urn:nid1:/Res2 to attempt to get r2. The nid2 resolvers would have to determine the nid1 equivalent of urn:nid2:X:Y:resource1 and could then tell the client to try: urn:nid1:A:B:Res1/urn:nid1:/Res2 If such a cross name space mapping could be done, it may eliminate the need for authors to maintain multiple relative URNs. But is it possible? Finally, the most serious concern: It is quite possible for there to be multiple ways to reach a reference even within the same name space. For example: urn:nid1:A:B:Res1 and urn:nid1:A:res1 may both be valid. However, the URN: urn:nid1:A:Res2 may not be defined. So a client could request the URN: urn:nid1:A:res1/urn:nid1:/Res2 How would the resolver know to remap 'A:res1' to 'A:B:Res1' since the first is already a valid reference in its name space. My personal take on this is: I would like to have the URN specs allow for relative URNs, but the details of how they will actually be implamented in practice boggles my mind. That's it. Sorry it got to be so long. Please excuse my grammer and spelling; I was in a hurry to write down my thoughts. Im sorry if this stuff is "text book" matarial for the URN WG, but I asked anyhow so that I may be better able to participate in the future. Thanks for reading and any answers you can provide. Omar Syed Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA29676 for urn-ietf-out; Fri, 31 Jan 1997 08:56:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA29670 for ; Fri, 31 Jan 1997 08:56:34 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23510 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 08:56:32 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <21458-0@josef.ifi.unizh.ch>; Fri, 31 Jan 1997 14:25:40 +0100 Date: Fri, 31 Jan 1997 14:25:39 +0100 (MET) From: "Martin J. Duerst" To: "Roy T. Fielding" Cc: URL mailing list , urn-ietf@bunyip.com Subject: Re: [URN] Re: Relative URLs and URNs In-Reply-To: <9701301832.aa03874@paris.ics.uci.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Thu, 30 Jan 1997, Roy T. Fielding wrote: > > Thus spoke Keith Moore: > > > >> If we disallow unencoded '/' within URNs for now, we can always add > >> relative URNs later when we understand them better. > > I couldn't disagree more. > > If '/' is disallowed in URNs, then a conforming parser will reject > a URN containing '/'. That means you will never be able to introduce > relative URNs. Creating barriers to technology just because it isn't > understood is a mistake, particularly when the only time '/' is > meaningful for *any* URI is when it is used as a base for parsing > relative URIs. > > If you aren't using relative forms, then there is no reason to encode '/'. > If you are, then you don't want '/' encoded. There does not exist a > situation in which it is beneficial to disallow '/' in URNs. There might not be any disagreement. Keith wants '/' disallowed within actually existing URNs. The parser can (and should, in this case) be more open. "SHOULD" is the best way to say it (contrary to my message a few minutes ago, where I didn't see that "SHOULD" was on puprose). Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA29274 for urn-ietf-out; Fri, 31 Jan 1997 08:10:52 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA29269 for ; Fri, 31 Jan 1997 08:10:50 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23276 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 08:10:39 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <20901-0@josef.ifi.unizh.ch>; Fri, 31 Jan 1997 14:10:45 +0100 Date: Fri, 31 Jan 1997 14:10:44 +0100 (MET) From: "Martin J. Duerst" To: Ryan Moats Cc: urn-ietf@bunyip.com Subject: Re: [URN] Some good ideas coming out of the "relative..." discussions... In-Reply-To: <32F0D01E.5E5D@ds.internic.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Thu, 30 Jan 1997, Ryan Moats wrote: > Mainly, I am thinking of creating a "reserved" set, that > contains "%" and "/". The reason's for "%" being reserved are well > known, and that text would be moved to that section. > > For "/", Ron and I worked out the following proposed text: > > ... > "/" is RESERVED for future developments. It might be used for > denoting hierarchy to allow for relative URN processing, but the WG > has not yet reached consensus on this, so such developments will be > documented separately. In the interim, namespace developers SHOULD NOT > use an unecoded "/", but rather use %-encoding for "/" ("%2F"). > ... That should be a MUST, of course. And if we are at it, why not also put "#" into the reserved set? Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA25453 for urn-ietf-out; Fri, 31 Jan 1997 01:46:12 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA25436 for ; Fri, 31 Jan 1997 01:45:10 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21457 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 01:45:08 -0500 Received: from montana (transitory13.lanl.gov [128.165.7.187]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id XAA03311; Thu, 30 Jan 1997 23:44:07 -0700 (MST) Message-Id: <199701310644.XAA03311@acl.lanl.gov> From: "Ron Daniel Jr." To: "omar syed" Cc: "URL mailing list" , Subject: Re: [URN] Re: Relative URLs and URNs Date: Thu, 30 Jan 1997 23:43:33 -0700 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com Thus spoke Omar Syed: > The rest of what I say is predicated on the following: > > 1. urn:: > 2. clients must treat as an opaque string (i.e. do not interperet) > 3. the details of interpereting a are know only to > coresponding resolvers > 4. clients must use appropriate resolvers to map the to > a location or resource I think assumption 2 is in error. Clients that know the structure of a name in a particular namespace are likely to manipulate it. Further, the rules in RFC1630 about only using '/' to denote hierarchy and mandating a particular order for the elements in the hierarchy are intended (I assume) to provide enough commonality across namespaces that clients will be able to process identifiers from novel namespaces. > But the client is not allowed to > interperet the so it cannot replace the "Res1" > from the previous absolute URN with "Res2" to create a new > URN. Yes, it could do that. > Now for the serious concerns: > > Lets say that another valid reference for resouce r1 is: > urn:nid2:X:Y:resource1 > > Suppose a client uses this absolute URN to get r1 and then > comes across the relative URN: "Res2". > > The first concern is that the client won't even know that > the author of resource r1 had intended the relative URN > to be retrieved using the "urn:nid1" scheme. Is there a > way for an author to specify the intended scheme along > with the relative URN? This is the sort of problem I am running into now in our tests, where we have a bunch of HTML pages we are retroactively assigning URNs to. Since those pages have lots of relative links in them, we can either: 1) Make sure our new URNs reflect the same filesystem arrangement as the pages do. 2) Modify the pages to make all the references absolute. Alternative 1 certainly is unattractive, since a major point of URNs is to provide independence from the filesystem organization du jour. But, to answer your question, there are two appraoches the author of an HTML page can use to say that the references are relative to BASE-URN-1 instead of BASE-URN-2. One is just to use absolute references. The second is to use the BASE tag of HTML. > Also will authors have to maintain multiple relative URN > references (for each that can be used to reference it)? > For example: > > Will HTML specs be modified to allow this? > Finally, the most serious concern: > > It is quite possible for there to be multiple ways > to reach a reference even within the same name space. > For example: > urn:nid1:A:B:Res1 > and > urn:nid1:A:res1 > may both be valid. However, the URN: > urn:nid1:A:Res2 > may not be defined. So a client could request the URN: > urn:nid1:A:res1/urn:nid1:/Res2 > How would the resolver know to remap 'A:res1' to 'A:B:Res1' > since the first is already a valid reference in its name space. It wouldn't. Ron Daniel Jr. voice:+1 505 665 0597 Advanced Computing Lab fax:+1 505 665 4939 MS B287 email:rdaniel@lanl.gov Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel Los Alamos, NM, USA, 87545 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA25231 for urn-ietf-out; Fri, 31 Jan 1997 01:19:16 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA25226 for ; Fri, 31 Jan 1997 01:19:14 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21327 (mail destined for urn-ietf@services.bunyip.com); Fri, 31 Jan 97 01:19:12 -0500 Received: from montana (transitory13.lanl.gov [128.165.7.187]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id XAA03255; Thu, 30 Jan 1997 23:19:07 -0700 (MST) Message-Id: <199701310619.XAA03255@acl.lanl.gov> From: "Ron Daniel Jr." To: "Roy T. Fielding" Cc: "URL mailing list" , Subject: Re: [URN] Re: Relative URLs and URNs Date: Thu, 30 Jan 1997 23:14:46 -0700 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com Thus spoke Roy Fielding: > If '/' is disallowed in URNs, then a conforming parser will reject > a URN containing '/'. That means you will never be able to introduce > relative URNs. Perhaps I was reading something into Keith's statement that wasn't really there, but I took his statement to mean that the syntax draft (or another document) would tell namespace developers not to use unencoded '/' while we figure out if it will or won't follow 1630. Since he said that we could always add relative URNs later, it would not seem to be a blanket prohibition on unencoded '/'. "should not" vs. "must not", as we have said in some more recent messages. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA24132 for urn-ietf-out; Thu, 30 Jan 1997 23:03:55 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA24127 for ; Thu, 30 Jan 1997 23:03:52 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20164 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 23:03:49 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id UAA22463; Thu, 30 Jan 1997 20:03:46 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id UAA14065; Thu, 30 Jan 1997 20:03:37 -0800 (PST) Date: Thu, 30 Jan 1997 20:03:37 -0800 (PST) From: Terry Allen Message-Id: <199701310403.UAA14065@ishtar.fsc.fujitsu.com> To: IAN.HIGGS@reuters.com, rdaniel@lanl.gov Subject: Re: [URN] Fragment references. Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com What Ron said, although point 4 may be determined by usage rather than specification, in the long run. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html >From owner-urn-ietf@bunyip.com Thu Jan 30 16:09 PST 1997 From: "Ron Daniel Jr." To: "Ian Higgs +44 171 542 8595" Cc: "URN Mailing list" Subject: Re: [URN] Fragment references. Date: Thu, 30 Jan 1997 16:22:59 -0700 X-Msmail-Priority: Normal X-Priority: 3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Thus spoke Ian Higgs > Has everybody already agreed that a URN is NOT a form of URI > and the "/" character does NOT imply a hierarchy as stated in RFC1630? No. That is pretty much the discussion we are having now. My current position is that: 1 URNs are one of the two forms of URI. 2 URLs are the other form of URI. 3 URNs are not URLs although they have a similar syntax. In fact, we purposefully try to align our syntax with that of URLs in order to avoid gratuitous differences. However, we don't adopt all of the URL syntax features until we see how they impact the core purpose of URNs - persistent, location-independent, resource identifiers. (The difference, to me, is that URNs MUST NOT specify any resolution-system specific hints, like protocol, port, host, etc. while URLs typically do specify such things.) (As a side note, the question of whether there really is a difference between URNs and URLs has been beaten to death and has been declared out of bounds for this list. The URN-WG charter assumes there is such a difference, and if there is not then the worst that happens to the world is that our work is moot.) 4 In the absence of good arguments to the contrary, unencoded '/' in URNs will end up denoting hierarchy as stated in RFC 1630. 5 Since we have only just started seriously discussing relative URNs, we have not reached consensus on the existance or absence of such a good argument. 6 Since the URN-WG is chartered to produce a URN Syntax draft, and neither the charter or URN requirements RFC mentions relative URNs, we should not stop the syntax draft while we discuss them. 7 Therefore, the syntax draft should leave an escape hatch for relative URNs. 8 This is easy to do, we just state that '/' SHOULD (not MUST) be %encoded, leaving the door open for people not to encode it if they think a) they are following the letter and spirit of 1630 b) whatever we do decide will be in line with 1630 > I think that I missed that. > If so then there can be no such thing as relative URNs and all URNs > might as well be 32 digit random numbers (for which there IS a case). One of the URN requirements is to accomodate legacy namespaces. ISBN, UPC, VIN, SICI, ISAN, ISWC, ... are all namespaces that identify important content. Further, they are easy to map to the URN Syntax draft as it currently exists. There is no need to say all URNs must be 32digit random numbers. Such a namespace canbe created if you want, but there is no reason to preclude the ones I cite above. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA23621 for urn-ietf-out; Thu, 30 Jan 1997 21:48:19 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA23616 for ; Thu, 30 Jan 1997 21:48:16 -0500 Received: from paris.ics.uci.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19685 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 21:48:10 -0500 Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa03874; 30 Jan 97 18:32 PST Cc: URL mailing list , urn-ietf@bunyip.com Subject: Re: [URN] Re: Relative URLs and URNs In-Reply-To: Your message of "Wed, 29 Jan 1997 18:54:23 MST." <199701300607.XAA02743@acl.lanl.gov> Date: Thu, 30 Jan 1997 18:32:03 -0800 From: "Roy T. Fielding" Message-Id: <9701301832.aa03874@paris.ics.uci.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Roy T. Fielding" Errors-To: owner-urn-ietf@bunyip.com > Thus spoke Keith Moore: > >> If we disallow unencoded '/' within URNs for now, we can always add >> relative URNs later when we understand them better. I couldn't disagree more. If '/' is disallowed in URNs, then a conforming parser will reject a URN containing '/'. That means you will never be able to introduce relative URNs. Creating barriers to technology just because it isn't understood is a mistake, particularly when the only time '/' is meaningful for *any* URI is when it is used as a base for parsing relative URIs. If you aren't using relative forms, then there is no reason to encode '/'. If you are, then you don't want '/' encoded. There does not exist a situation in which it is beneficial to disallow '/' in URNs. .....Roy Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA19805 for urn-ietf-out; Thu, 30 Jan 1997 18:34:11 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA19788 for ; Thu, 30 Jan 1997 18:34:08 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18586 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 18:34:02 -0500 Received: from montana (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id QAA15556; Thu, 30 Jan 1997 16:33:42 -0700 (MST) Message-Id: <199701302333.QAA15556@acl.lanl.gov> From: "Ron Daniel Jr." To: "Ian Higgs +44 171 542 8595" Cc: "URN Mailing list" Subject: Re: [URN] Fragment references. Date: Thu, 30 Jan 1997 16:22:59 -0700 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com Thus spoke Ian Higgs > Has everybody already agreed that a URN is NOT a form of URI > and the "/" character does NOT imply a hierarchy as stated in RFC1630? No. That is pretty much the discussion we are having now. My current position is that: 1 URNs are one of the two forms of URI. 2 URLs are the other form of URI. 3 URNs are not URLs although they have a similar syntax. In fact, we purposefully try to align our syntax with that of URLs in order to avoid gratuitous differences. However, we don't adopt all of the URL syntax features until we see how they impact the core purpose of URNs - persistent, location-independent, resource identifiers. (The difference, to me, is that URNs MUST NOT specify any resolution-system specific hints, like protocol, port, host, etc. while URLs typically do specify such things.) (As a side note, the question of whether there really is a difference between URNs and URLs has been beaten to death and has been declared out of bounds for this list. The URN-WG charter assumes there is such a difference, and if there is not then the worst that happens to the world is that our work is moot.) 4 In the absence of good arguments to the contrary, unencoded '/' in URNs will end up denoting hierarchy as stated in RFC 1630. 5 Since we have only just started seriously discussing relative URNs, we have not reached consensus on the existance or absence of such a good argument. 6 Since the URN-WG is chartered to produce a URN Syntax draft, and neither the charter or URN requirements RFC mentions relative URNs, we should not stop the syntax draft while we discuss them. 7 Therefore, the syntax draft should leave an escape hatch for relative URNs. 8 This is easy to do, we just state that '/' SHOULD (not MUST) be %encoded, leaving the door open for people not to encode it if they think a) they are following the letter and spirit of 1630 b) whatever we do decide will be in line with 1630 > I think that I missed that. > If so then there can be no such thing as relative URNs and all URNs > might as well be 32 digit random numbers (for which there IS a case). One of the URN requirements is to accomodate legacy namespaces. ISBN, UPC, VIN, SICI, ISAN, ISWC, ... are all namespaces that identify important content. Further, they are easy to map to the URN Syntax draft as it currently exists. There is no need to say all URNs must be 32digit random numbers. Such a namespace canbe created if you want, but there is no reason to preclude the ones I cite above. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA17794 for urn-ietf-out; Thu, 30 Jan 1997 17:55:17 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA17785 for ; Thu, 30 Jan 1997 17:55:14 -0500 Received: from ritig1.rit.reuters.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18241 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 17:55:11 -0500 Received: from ritig4.rit.reuters.com by ritig1.rit.reuters.com; (5.65v3.2/1.1.8.2/14Sep94-0947PM) id AA03945; Thu, 30 Jan 1997 16:48:12 -0500 Received: from mr.rit.reuters.com by RITIG4.RIT.REUTERS.COM (PMDF V5.1-5 #7805) id <01IETZQ0HNS000024E@RITIG4.RIT.REUTERS.COM>; Thu, 30 Jan 1997 17:53:39 EST Received: with PMDF-MR; Thu, 30 Jan 1997 22:53:50 +0000 (GMT) Mr-Received: by mta REC.MUAS; Relayed; Thu, 30 Jan 1997 22:53:50 +0000 Mr-Received: by mta RE6; Relayed; Thu, 30 Jan 1997 22:53:53 +0000 Mr-Received: by mta RITIG4; Relayed; Thu, 30 Jan 1997 22:53:26 +0000 Disclose-Recipients: prohibited Date: Thu, 30 Jan 1997 22:53:50 +0000 (GMT) From: Ian Higgs +44 171 542 8595 Subject: Re: [URN] Fragment references. In-Reply-To: <199701302157.NAA01386@ishtar.fsc.fujitsu.com> To: Terry Allen Cc: URN Mailing list Message-Id: <5650532230011997/A33094/RE6/11B1F5B52F00*@MHS> Autoforwarded: false Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Priority: urgent Sensitivity: Company-Confidential Ua-Content-Id: 11B1F5B52F00 X400-Mts-Identifier: [;5650532230011997/A33094/RE6] Hop-Count: 2 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ian Higgs +44 171 542 8595 Errors-To: owner-urn-ietf@bunyip.com Sorry to confuse you - I may be crossing threads and discussing two things at once. ] This assumes that a "relative URN" is a "fragment reference." That's ] not obvious. I see them as two very different things: fragment refs are "#something" but relative refs are "../something". i.e. fragment refs are 'pointers' within the current resource and (probably) do not imply a fetch but relative refs are refs to another resource and do imply a fetch. ] I would say that relative URNs have not been specified. Has everybody already agreed that a URN is NOT a form of URI and the "/" character does NOT imply a hierarchy as stated in RFC1630? I think that I missed that. If so then there can be no such thing as relative URNs and all URNs might as well be 32 digit random numbers (for which there IS a case). /Ian Higgs Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA16035 for urn-ietf-out; Thu, 30 Jan 1997 17:02:51 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA16030 for ; Thu, 30 Jan 1997 17:02:49 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17721 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 17:02:45 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id QAA08808; Thu, 30 Jan 1997 16:01:18 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id QAA29640; Thu, 30 Jan 1997 16:01:35 -0600 (CST) Date: Thu, 30 Jan 1997 16:01:35 -0600 (CST) Message-Id: <199701302201.QAA29640@void.ncsa.uiuc.edu> To: "Ron Daniel Jr." Cc: "Daniel LaLiberte" , "Ryan Moats" , Subject: Re: [URN] Some good ideas coming out of the "relative..." discussions... In-Reply-To: <199701302003.NAA09442@acl.lanl.gov> References: <199701302003.NAA09442@acl.lanl.gov> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Ron Daniel, Jr. writes: > Please note that Ryan's message says "SHOULD NOT", not "MUST NOT". Ah, right you are. Sorry for going overboard. Too much coffee and arguing at the same time is making me jumpy. dan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA15932 for urn-ietf-out; Thu, 30 Jan 1997 16:58:29 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA15927 for ; Thu, 30 Jan 1997 16:58:28 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17651 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 16:58:24 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id NAA09984; Thu, 30 Jan 1997 13:57:48 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id NAA01386; Thu, 30 Jan 1997 13:57:42 -0800 (PST) Date: Thu, 30 Jan 1997 13:57:42 -0800 (PST) From: Terry Allen Message-Id: <199701302157.NAA01386@ishtar.fsc.fujitsu.com> To: IAN.HIGGS@reuters.com, urn-ietf@bunyip.com Subject: Re: [URN] Fragment references. Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Ian Higgs wrote: | Somebody asked: | > How is a location within a resource really different from a relative | > URN? | | I would say that a relative reference always implies a new request, | but an internal fragment reference does not. An internal fragment | reference just implies a scroll in the display. I would say that relative URNs have not been specified. | However, as I understand the existing specifications, there could be | two possible understandings of fragment references. This assumes that a "relative URN" is a "fragment reference." That's not obvious. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA14430 for urn-ietf-out; Thu, 30 Jan 1997 16:12:22 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA14425 for ; Thu, 30 Jan 1997 16:12:20 -0500 Received: from ritig1.rit.reuters.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17185 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 16:12:14 -0500 Received: from ritig4.rit.reuters.com by ritig1.rit.reuters.com; (5.65v3.2/1.1.8.2/14Sep94-0947PM) id AA01134; Thu, 30 Jan 1997 15:05:27 -0500 Received: from mr.rit.reuters.com by RITIG4.RIT.REUTERS.COM (PMDF V5.1-5 #7805) id <01IETW5M12000000BC@RITIG4.RIT.REUTERS.COM> for urn-ietf@bunyip.com; Thu, 30 Jan 1997 16:10:55 EST Received: with PMDF-MR; Thu, 30 Jan 1997 21:11:09 +0000 (GMT) Mr-Received: by mta REC.MUAS; Relayed; Thu, 30 Jan 1997 21:11:09 +0000 Mr-Received: by mta RE6; Relayed; Thu, 30 Jan 1997 21:11:09 +0000 Mr-Received: by mta RITIG4; Relayed; Thu, 30 Jan 1997 21:10:44 +0000 Disclose-Recipients: prohibited Date: Thu, 30 Jan 1997 21:11:09 +0000 (GMT) From: Ian Higgs +44 171 542 8595 Subject: [URN] Fragment references. To: URN Mailing list Message-Id: <4109112130011997/A32374/RE6/11B1F54B0800*@MHS> Autoforwarded: false Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Importance: normal Priority: urgent Sensitivity: Company-Confidential Ua-Content-Id: 11B1F54B0800 X400-Mts-Identifier: [;4109112130011997/A32374/RE6] Hop-Count: 2 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ian Higgs +44 171 542 8595 Errors-To: owner-urn-ietf@bunyip.com Somebody asked: > How is a location within a resource really different from a relative > URN? I would say that a relative reference always implies a new request, but an internal fragment reference does not. An internal fragment reference just implies a scroll in the display. However, as I understand the existing specifications, there could be two possible understandings of fragment references. ++++ Imagine a resource includes a link ... ++ Case 1 The browser "knows" that # means relative, scans the current resource for the matching and adjust the display to that location. ++ Case 2 The browser takes the reference used to get the resource in the first place (URL or URN), strips off any existing "#xxx" and adds the new "#somewhere". The resulting reference is passed to a lower part of the software which is asked to fetch the resource. The "fetcher" strips the "#somewhere" off again, looks in the cache and finds a resource matching the reference or sends out a new request for it. The browser gets the returned resource and THEN performs the scan as in case 1. ++++ In the first case, the browser does not repeat the request. In the second case it may. Current practice seems to be the first case, so that: - the "browser" does not include the "#somewhere" in the request. - the "#somewhere" is not used or meaningful to the resolver or server. - the COMPLETE resource is always returned. For a URL this raises interesting questions. If the URL refers to a script rather than a fixed resource, then the first case is displaying a stale result and the second case implies a refresh which may return a different result if the resource is not cached. If we say that the value of a URN is the persistence of the resource, regardless of the physical location, then I assume that the two cases are equivalent, since the resource should not have changed. If we say that the value of a URN is the implied indirection that insulates us from the physical location of the resource, then it is possible that the resource can change between requests or that the requests are resolved to different copies/versions of the resource. Does this possibility matter to us? /Ian Higgs Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA11540 for urn-ietf-out; Thu, 30 Jan 1997 15:04:29 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA11529 for ; Thu, 30 Jan 1997 15:04:22 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16549 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 15:04:15 -0500 Received: from montana (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id NAA09442; Thu, 30 Jan 1997 13:03:55 -0700 (MST) Message-Id: <199701302003.NAA09442@acl.lanl.gov> From: "Ron Daniel Jr." To: "Daniel LaLiberte" , "Ryan Moats" Cc: Subject: Re: [URN] Some good ideas coming out of the "relative..." discussions... Date: Thu, 30 Jan 1997 13:02:45 -0700 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com Thus spoke Daniel LaLiberte: > Ryan Moats writes: > > documented separately. In the interim, namespace developers SHOULD NOT > > use an unecoded "/", but rather use %-encoding for "/" ("%2F"). > > The only sensible proposal is to *allow* unencoded '/', with the > warning that they must be used in conformance to the relative URI > spec. That's my final offer. Please note that Ryan's message says "SHOULD NOT", not "MUST NOT". The spec will allow '/' characters, but will discourage their use. This is to try to reduce backward compatability problems if, during the course of discussing relative URNs, we find that 1630's semantics on '/' are not quite right. Of course, we will probably not find that, so "should" instead of "must" will let people go ahead and try to predict the future. I think he is doing a reasonable thing, and I think it meets the needs you and Tim have expressed. Ron Daniel Jr. voice:+1 505 665 0597 Advanced Computing Lab fax:+1 505 665 4939 MS B287 email:rdaniel@lanl.gov Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel Los Alamos, NM, USA, 87545 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA08988 for urn-ietf-out; Thu, 30 Jan 1997 14:15:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA08983 for ; Thu, 30 Jan 1997 14:15:13 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15858 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 14:15:11 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id NAA06349; Thu, 30 Jan 1997 13:14:59 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id NAA28043; Thu, 30 Jan 1997 13:15:16 -0600 (CST) Date: Thu, 30 Jan 1997 13:15:16 -0600 (CST) Message-Id: <199701301915.NAA28043@void.ncsa.uiuc.edu> To: David Durand Cc: urn-ietf@bunyip.com Subject: Re: [URN] Some good ideas coming out of the "relative..." discussions... In-Reply-To: <199701301711.MAA19220@csb.bu.edu> References: <199701301711.MAA19220@csb.bu.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com David Durand writes: > ... Now, if we have to encode FPIs to > make them into URNs that is OK, but if the relative URN stuff comes > out, it will make sense to unescape the slashes again. So there will > be two canonical representations for the same URN, depending on when > it was issued, kind of defeating the goals of persistence. Allowing multiple names for things does not defeat the persistence or uniqueness properties. The persistence property is that the name is never used again for anything else. The uniqueness property is that a name is only the name of one resource (which may be a mutable resource) not that the resource only has one name. > ... If we make no special allowances now, > and later decide that we really need relative URNs we could add > another kind of resolution service that takes a base URN and a > relative URN and returns the "real" URN. This service is call concatenation. Clients can do it themselves. dan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA07734 for urn-ietf-out; Thu, 30 Jan 1997 13:58:09 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA07727 for ; Thu, 30 Jan 1997 13:58:06 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15648 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 13:58:03 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id MAA06134; Thu, 30 Jan 1997 12:57:46 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id MAA27832; Thu, 30 Jan 1997 12:58:03 -0600 (CST) Date: Thu, 30 Jan 1997 12:58:03 -0600 (CST) Message-Id: <199701301858.MAA27832@void.ncsa.uiuc.edu> To: Ryan Moats Cc: urn-ietf@bunyip.com Subject: [URN] Some good ideas coming out of the "relative..." discussions... In-Reply-To: <32F0D01E.5E5D@ds.internic.net> References: <32F0D01E.5E5D@ds.internic.net> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Ryan Moats writes: > documented separately. In the interim, namespace developers SHOULD NOT > use an unecoded "/", but rather use %-encoding for "/" ("%2F"). Curious development. The whole reason I went along with the recent work (the NAPTR mechanism and the "urn:" prefix for subscheme with opaque strings) was that I could still see how the hierarchical path scheme could be deployed. This requirement means that either all name spaces under "urn:" will be flat, or if a name space uses a hierarchy, it must use a different delimiter thus destroying the possibility of using relative URIs and getting scalable resolution without later creating new names for everything. I object strongly. Disallowing unenconded '/' can only serve the flat name spaces, which I believe are unscalable. This does not serve the internet well. Protecting the world from hierarchical name spaces because you don't understand how they work is unnecessarily over constraining. Why not allow some name spaces to be hierarchical and see if the resolution services can make them work? What harm is there in that? If a name space fails, it fails. Other name spaces will fail too - I believe the flat name spaces will fail. I'm not opposed to allowing flat name spaces to try, however. The only sensible proposal is to *allow* unencoded '/', with the warning that they must be used in conformance to the relative URI spec. That's my final offer. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA06625 for urn-ietf-out; Thu, 30 Jan 1997 13:41:22 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA06613 for ; Thu, 30 Jan 1997 13:41:11 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15531 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 13:41:08 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id MAA05878; Thu, 30 Jan 1997 12:40:21 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id MAA27743; Thu, 30 Jan 1997 12:40:38 -0600 (CST) Date: Thu, 30 Jan 1997 12:40:38 -0600 (CST) Message-Id: <199701301840.MAA27743@void.ncsa.uiuc.edu> To: Keith Moore Cc: Tim Berners-Lee , Daniel LaLiberte , "Martin J. Duerst" , "Ron Daniel Jr." , URL mailing list , urn-ietf@bunyip.com, JCMa@AI.MIT.EDU Subject: [URN] Re: Relative URLs and URNs In-Reply-To: <199701292335.SAA31944@ig.cs.utk.edu> References: <3.0.32.19970129174648.007c5900@hq.lcs.mit.edu> <199701292335.SAA31944@ig.cs.utk.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Keith Moore writes: > > Keith, you make a good point that relative URIs are limited in > > persistence to the persistence of the two URIs. > > I don't know which two URIs you're talking about. The two URIs are something like an http URL and a URN of some kind. A relative URI could be relative to either kind of absolute URI. Of course, if the scheme of an absolute URI does not support relative URIs, the URI could not be used as the base URI of a document. > The persistence problem, as I see it, comes from wiring > non-persistent information into the URI -- in this case, the > grouping of subsets of URI space -- and depending on that > information to be persistent. Relative URIs may or may not wire non-persistent information depending on how your resolution service works. The grouping of subsets of a URI space is a grouping of the *identifiers*, but that does not necessarily mean that the *resources themselves* are similarly grouped. A redirection can be returned by the resolution service for any part of the group pointing the client off to where the resource currently lives (or closer to it anyway). In fact, a hierarchical subdivision of the group can make it even easier for the resolution service to provide that redirection, and more importantly, for the client to (more scalably) remember the redirection for a whole subdivision. All this and a bit more is supported by the path scheme resolution mechanism. Keith, you seem to be arguing not only against relative URNs but against any hierarchical structuring of the URN space. The two issues are closely related since once you have hierarchical structuring, you can also easily have relative identifiers. What is the difference between always using absolute URNs such as urn://path/A/B/C/D.doc urn://path/A/B/C/E.doc and using relative URNs such as C/D.doc C/E.doc within a document having a base URN of urn://path/A/B/index.doc It might be the case that for some resolution mechanisms, you resolve the relative part by itself in a different way than you resolve the corresponding absolute URI. So you might not be able to resolve urn://path/A/B/C/D.doc directly but instead, after resolving urn://path/A/B/, you find out about some different kind of service (say an HTTP server) that you request C/D.doc from. > Tim B.L. said: > > But Dan La L was right too in pointing out that the relative URI > > may in fact be longer lived than the absolute. So it is not a > > clear case. > > Unless I misunderstood his argument, it seemed to be predicated on > the idea that old name spaces will go away and need to be changed. > But since the URN framework is specifically designed so that old name > spaces do not need to be changed, I don't accept the premise. The old name space may live forever with no problem - we only have to guarantee that the names are never used again - no problem (even for human-meaningful names). The real problem is in finding a resolution service that will resolve the old names. Say a name space is created in such a way that it is really difficult to actually resolve identifiers in a scalable way. One way to solve this problem is to create a new name space with better resolution mechanisms. The relative URIs in the documents could remain unchanged if both the old and new name spaces supported relative URIs. (Footnote: Another different kind of problem for finding a resolution service could occur if hardly anyone cares about the resources any more, no matter how scalable the resolution service might be. The problem might be to find a cheap enough resolution service.) (Footnote: Finding (looking up) a resolution service is an essential part of the resolution process. You have to have a specific place (location/address) to start the lookup process. That's what makes a name logically the same as an address, but we are not allowed to talk about that on the URN list - email me replies on that.) > As far as I can tell, if we're going to have persistent relative URNs > (or equivalently, URNs that reference portions of a single resource) > we're going to need a level of indirection for relative URNs just like > we have for normal URNs. Yes, and providing that indirection is no more of a problem for relative URNs than for absolute URNs, depending on how your resolution service works. If you are thinking only of resolution services that work with flat name spaces, then indeed relative URNs will be a problem. Obviously, document writers will not be able to use URNs in non-hierarchical name spaces as base URIs. > That is, > > given a resource a1 with URN "A1" and a similar resource a2 with URN "A2", > (for some meaning of "similar"), it's not reasonable to assume that > the portion of a1 named by "A1/foo" is similar to the portion of > a2 named by "A2/foo". Correct. It would be an error to assume that. Relative URNs can not be directly compared for equivalence without prepending the context of the base URN that makes them absolute. If you know that A1 and A2 are alternative (equivalent) URNs for the same resource, then you *do* know that "A1/foo" is equivalent to "A2/foo", otherwise you do not know they are equivalent. The same is true of absolute and relative URLs, by the way. > My view is that since persistence is an important property of URNs, > we should not define relative URNs (or URNs that specify portions of > documents) until we understand how to define them without diluting > the persistence of URNs. Relative URNs do not dilute the persistence of URNs any more than hierarchically structured URNs are non-persistent. > If we disallow unencoded '/' within URNs for now, we can always add > relative URNs later when we understand them better. True, but you would also be disallowing hierarchical name spaces such as the path scheme defines. Understanding relative URNs is a good idea, but I don't understand why it is so difficult to understand them. Earlier, regarding locations within a resource, you said, > Even then, I'm not sure what it means to talk about references > relative to a "Base URN" ...because this assumes that the "Base URN" > will need to change while the intra-resource reference names > need to stay the same. Important difference: The base URN *may* change (e.g. to a newer better name space), while the intra-resource (or inter-resource - same can of worms) relative identifiers *need not* change. All this talk of hierarchy should be extended to also include Tim's matrix space with relative URIs of the form ";name=value;name=value". John Mallery has suggested a URN scheme that is entirely matrix based. John, it might be useful for you to briefly describe it now. I need to give it more thought myself, to figure out how to make the resolution scalable. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA05773 for urn-ietf-out; Thu, 30 Jan 1997 12:56:00 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA05768 for ; Thu, 30 Jan 1997 12:55:58 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15118 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 12:55:36 -0500 Received: from montana (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id KAA07936; Thu, 30 Jan 1997 10:55:26 -0700 (MST) Message-Id: <199701301755.KAA07936@acl.lanl.gov> From: "Ron Daniel Jr." To: "David Durand" , Subject: Re: [URN] Some good ideas coming out of the "relative..." discussions... Date: Thu, 30 Jan 1997 10:54:58 -0700 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com Thus spoke David Durand: > The one thing that strikes me here is that FPIs use the "/" > character to indicate syntactic divisions in the name (actually they > use "//", but the idea is the same. Now, if we have to encode FPIs to > make them into URNs that is OK, but if the relative URN stuff comes > out, it will make sense to unescape the slashes again. We are starting to do some FPI resolution here and are encoding the '/' characters. I am not so sure that we would want to unescape the '//' sequences in the future. I don't know that FPI's hierarchy follows the letter and spirit of the relative URL spec. I am very doubtful that it follows implementation practice for that spec. Also, sometimes "::" is used instead of "//". I think there are two basic arguments for relative URIs. One is to make it easier to move a connected set of resources, the other is for concision. As far as URNs and FPIs go, neither is compelling. The primary place to use FPIs is in SGML, where they are typically hidden behind an entity reference. That takes care of concision. Moving a collection does not require changes to the documents, only to the name->location resolution info. For FPIs this will typically be a local SGMLopen catalog, or a catalog accessed through a fallback resolution procedure such as NAPTR. (At least, that is the approach we are taking) Ron Daniel Jr. voice:+1 505 665 0597 Advanced Computing Lab fax:+1 505 665 4939 MS B287 email:rdaniel@lanl.gov Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel Los Alamos, NM, USA, 87545 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA05157 for urn-ietf-out; Thu, 30 Jan 1997 12:23:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA05152 for ; Thu, 30 Jan 1997 12:23:18 -0500 Received: from proxy2.ba.best.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14336 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 12:23:16 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.8.5/8.8.3) with SMTP id JAA02912; Thu, 30 Jan 1997 09:17:29 -0800 (PST) Date: Thu, 30 Jan 1997 09:17:29 -0800 (PST) From: "Gregory J. Woodhouse" To: Ryan Moats Cc: urn-ietf@bunyip.com Subject: [URN] Reltive URNs In-Reply-To: <32F0D01E.5E5D@ds.internic.net> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com This almost seems like a replay of the old question of whether URNs should be human readable or not. If the only goal of URNs is persistence then there is an argument aginst relative URNs , namely that their interptertation become context dependent, and so they can't really be called peristent. There is some merit to this point of view. If URNs are thought of as abstract, location independent names, then I think reltive URNs make a lot of sense. There is no necessary relationship between URI hierchies and physical representation. One could well imagine a URN like this HTMLObjects:Corporate:Intel:Product-Lines:Overview:gee-whiz-chip:version7 I don't mean to suggest this is a good URN scheme, but it is an example of how a name could be hierarchical in structure without being tied in any way to physical representation. If URNs are only meant to be permanent identifiers then it makes snse to just use something like 12 byte idntifier or some such thing, and then it doesn't make sense to speak of raltive URNs. If URNs are abstract names for resources, it makes a lot of sense. In other words, it seems to me that this is the same fundamental issu reappearing in a different context. --- gjw@wnetc.com / http://www.wnetc.com/home.html If you're going to reinvent the wheel, at least try to come to come up with a better one. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA04965 for urn-ietf-out; Thu, 30 Jan 1997 12:12:41 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA04960 for ; Thu, 30 Jan 1997 12:12:34 -0500 Received: from [128.197.13.2] by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14224 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 12:12:31 -0500 Received: from csb.bu.edu (dgd@CSB.BU.EDU [128.197.10.4]) by cs.bu.edu (8.8.5/8.8.5/(BU-S-01/27/97-fc1)) with ESMTP id MAA07690 for ; Thu, 30 Jan 1997 12:11:21 -0500 (EST) From: David Durand Received: by csb.bu.edu (8.8.5/Spike-2.1) id MAA19220; Thu, 30 Jan 1997 12:11:16 -0500 (EST) Date: Thu, 30 Jan 1997 12:11:16 -0500 (EST) Message-Id: <199701301711.MAA19220@csb.bu.edu> To: urn-ietf@bunyip.com Subject: Re: [URN] Some good ideas coming out of the "relative..." discussions... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: David Durand Errors-To: "owner-urn-ietf@bunyip.com From: Ryan Moats" Mainly, I am thinking of creating a "reserved" set, that contains "%" and "/". The reason's for "%" being reserved are well known, and that text would be moved to that section. For "/", Ron and I worked out the following proposed text: ... "/" is RESERVED for future developments. It might be used for denoting hierarchy to allow for relative URN processing, but the WG has not yet reached consensus on this, so such developments will be documented separately. In the interim, namespace developers SHOULD NOT use an unecoded "/", but rather use %-encoding for "/" ("%2F"). ... Comments? The one thing that strikes me here is that FPIs use the "/" character to indicate syntactic divisions in the name (actually they use "//", but the idea is the same. Now, if we have to encode FPIs to make them into URNs that is OK, but if the relative URN stuff comes out, it will make sense to unescape the slashes again. So there will be two canonical representations for the same URN, depending on when it was issued, kind of defeating the goals of persistence. Perhaps the best thing is to recognize that "relative URNs" may well be naming scheme dependent in the long run, and thus not good candidates for syntax hacking. If we make no special allowances now, and later decide that we really need relative URNs we could add another kind of resolution service that takes a base URN and a relative URN and returns the "real" URN. This could be handled as a single "relative" scheme with an opaque string, since the actual name assignment scheme could be determined by looking at the base URN. -- David Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA04616 for urn-ietf-out; Thu, 30 Jan 1997 11:46:21 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA04610 for ; Thu, 30 Jan 1997 11:46:19 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13996 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 11:46:16 -0500 Received: by privateer.windrose.omaha.ne.us; Thu Jan 30 10:45 CST 1997 Message-Id: <32F0D01E.5E5D@ds.internic.net> Date: Thu, 30 Jan 1997 10:45:18 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: urn-ietf@bunyip.com Subject: [URN] Some good ideas coming out of the "relative..." discussions... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Although I've only been lurking on what I call the "relative..." discussions, I did talk with Ron Daniel on the phone earlier today, and I think that some good ideas have arisen out of this that should be incorporated in the syntax draft. Mainly, I am thinking of creating a "reserved" set, that contains "%" and "/". The reason's for "%" being reserved are well known, and that text would be moved to that section. For "/", Ron and I worked out the following proposed text: ... "/" is RESERVED for future developments. It might be used for denoting hierarchy to allow for relative URN processing, but the WG has not yet reached consensus on this, so such developments will be documented separately. In the interim, namespace developers SHOULD NOT use an unecoded "/", but rather use %-encoding for "/" ("%2F"). ... Comments? Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA21126 for urn-ietf-out; Thu, 30 Jan 1997 01:07:51 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA21121 for ; Thu, 30 Jan 1997 01:07:47 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11178 (mail destined for urn-ietf@services.bunyip.com); Thu, 30 Jan 97 01:07:45 -0500 Received: from montana (transitory20.lanl.gov [128.165.7.180]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id XAA02743; Wed, 29 Jan 1997 23:07:29 -0700 (MST) Message-Id: <199701300607.XAA02743@acl.lanl.gov> From: "Ron Daniel Jr." To: "Keith Moore" , "Tim Berners-Lee" Cc: "Keith Moore" , "Daniel LaLiberte" , "Martin J. Duerst" , "URL mailing list" , Subject: Re: [URN] Re: Relative URLs and URNs Date: Wed, 29 Jan 1997 18:54:23 -0700 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com Thus spoke Keith Moore: > If we disallow unencoded '/' within URNs for now, we can always add > relative URNs later when we understand them better. I couldn't agree more. Encoding '/' is a bit cumbersome, but it is worth it for the potential gain in the future. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA14105 for urn-ietf-out; Wed, 29 Jan 1997 18:40:35 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA14100 for ; Wed, 29 Jan 1997 18:40:32 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08833 (mail destined for urn-ietf@services.bunyip.com); Wed, 29 Jan 97 18:40:24 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id SAA31944; Wed, 29 Jan 1997 18:35:05 -0500 (EST) Message-Id: <199701292335.SAA31944@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Tim Berners-Lee Cc: Keith Moore , Daniel LaLiberte , "Martin J. Duerst" , "Ron Daniel Jr." , URL mailing list , urn-ietf@bunyip.com Subject: [URN] Re: Relative URLs and URNs In-Reply-To: Your message of "Wed, 29 Jan 1997 17:46:52 EST." <3.0.32.19970129174648.007c5900@hq.lcs.mit.edu> Date: Wed, 29 Jan 1997 18:35:05 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > >> If all URNs are syntactically opaque URLs, are we not imposing a > >> restriction on all URNs that they cannot use the relative URL mechanism? > > > >Yes, but this is a feature. Relative URLs wire relationships between > >resources into the resource name itself, which hurts long-term persistence. > > Keith, you make a good point that relative URIs are limited in persistence to > the persistence of the two URIs. I don't know which two URIs you're talking about. The persistence problem, as I see it, comes from wiring non-persistent information into the URI -- in this case, the grouping of subsets of URI space -- and depending on that information to be persistent. > But Dan La L was right too in pointing out that > the relative URI may in fact be longer lived than the absolute. So it is > not a clear case. Unless I misunderstood his argument, it seemed to be predicated on the idea that old name spaces will go away and need to be changed. But since the URN framework is specifically designed so that old name spaces do not need to be changed, I don't accept the premise. As far as I can tell, if we're going to have persistent relative URNs (or equivalently, URNs that reference portions of a single resource) we're going to need a level of indirection for relative URNs just like we have for normal URNs. That is, given a resource a1 with URN "A1" and a similar resource a2 with URN "A2", (for some meaning of "similar"), it's not reasonable to assume that the portion of a1 named by "A1/foo" is similar to the portion of a2 named by "A2/foo". What we would need is some mapping layer which we could ask "what portion of a2 is equivalent to the portion of a1 named by "A1/foo"?". (and just because "A1/foo" maps to "A2/bar" doesn't mean that A2/bar maps to A1/foo) > So one should not forbid them. Disabling a consistent function in a special > case is normally a kludge, not a feature. In general, specs which tell > people what to do against their better judgement are typically suspect too. > This would be something to put in a usage document: "When relative > URIs are considered harmful and when not" My view is that since persistence is an important property of URNs, we should not define relative URNs (or URNs that specify portions of documents) until we understand how to define them without diluting the persistence of URNs. If we disallow unencoded '/' within URNs for now, we can always add relative URNs later when we understand them better. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA12504 for urn-ietf-out; Wed, 29 Jan 1997 17:48:21 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA12434 for ; Wed, 29 Jan 1997 17:47:26 -0500 Received: from www10.w3.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08542 (mail destined for urn-ietf@services.bunyip.com); Wed, 29 Jan 97 17:47:25 -0500 Received: from peak.w3.org ([18.23.10.162]) by www10.w3.org (8.7.5/8.7.3) with SMTP id RAA27652; Wed, 29 Jan 1997 17:47:02 -0500 (EST) Message-Id: <3.0.32.19970129174648.007c5900@hq.lcs.mit.edu> X-Sender: timbl@hq.lcs.mit.edu X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 29 Jan 1997 17:46:52 -0500 To: Keith Moore , Daniel LaLiberte From: Tim Berners-Lee Subject: [URN] Re: Relative URLs and URNs Cc: "Martin J. Duerst" , "Ron Daniel Jr." , URL mailing list , urn-ietf@bunyip.com, moore@cs.utk.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Tim Berners-Lee Errors-To: owner-urn-ietf@bunyip.com At 11:12 am 29-01-97 -0500, Keith Moore wrote: >> If all URNs are syntactically opaque URLs, are we not imposing a >> restriction on all URNs that they cannot use the relative URL mechanism? > >Yes, but this is a feature. Relative URLs wire relationships between >resources into the resource name itself, which hurts long-term persistence. Keith, you make a good point that relative URIs are limited in persistence to the persistence of the two URIs. But Dan La L was right too in pointing out that the relative URI may in fact be longer lived than the absolute. So it is not a clear case. So one should not forbid them. Disabling a consistent function in a special case is normally a kludge, not a feature. In general, specs which tell people what to do against their better judgement are typically suspect too. This would be something to put in a usage document: "When relative URIs are considered harmful and when not" [...] (Dan L:) >> Another advantage of relative identifiers is that they are shorter >> than their equivalent full identifiers. Yes. >It's not necessarily true that a URN is shorter than a relative URL. (That wasn't what Dan said (that relative URIs in general are shorter than absolute URIs) , I assume it's the reverse of what you meant to say, that "It's not necessarily true that a relative URL is shorter than a URN" ) >Since URNs don't need to be human-meaningful, they can be allocated >from a denser space than is typical for URLs. There is nothing to *stop* URLs being allocated extremely densely. Following my comment in Leslie's message, it is a social issue that URLs are typically not dense and not always persistently maintained. Since HTTP URLs don't need to be human-meaningful, they can be allocated from a denser space than may equally become typical for URNs. >Keith Tim Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA11762 for urn-ietf-out; Wed, 29 Jan 1997 17:26:38 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA11756 for ; Wed, 29 Jan 1997 17:26:35 -0500 Received: from www10.w3.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08401 (mail destined for urn-ietf@services.bunyip.com); Wed, 29 Jan 97 17:26:33 -0500 Received: from peak.w3.org ([18.23.10.162]) by www10.w3.org (8.7.5/8.7.3) with SMTP id RAA27534; Wed, 29 Jan 1997 17:26:40 -0500 (EST) Message-Id: <3.0.32.19970129172627.007b2140@hq.lcs.mit.edu> X-Sender: timbl@hq.lcs.mit.edu X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 29 Jan 1997 17:26:39 -0500 To: Leslie Daigle , urn-ietf@bunyip.com, connolly@w3.org From: Tim Berners-Lee Subject: Re: [URN] what's in a syntax? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Tim Berners-Lee Errors-To: owner-urn-ietf@bunyip.com I don't follow this consistently, but I am granting myself the luxury of responding here (with my w3c hat off) as I think it is important. At 03:25 pm 27-01-97 -0500, Leslie Daigle wrote: > . If we align the syntaxes wrt reserved characters, etc, will > > URN: > > necessarily imply that URNs are a "scheme" of URLs? It would be sufficiently confusing that I would certainly oppose it if it didn't. > If so, then URNs will have to go through the URL vetting process, > and potentially the string "URN" will be objected to. I don't see any reason why anyone should object to a string. (It would be nice if one were to admit the possibility of other schemes which match the URN requirements but are in fact different schemes, just as you can consider "URL" to be one requirement and "HTTP" to be a protocol meeting it. But if the only thing in one's way is an arbitrary string, then it should not really prevent progress!) > Also, will this imply that URNs are equivalent to URLs in terms > of semantics? (There are those that think the are, and those that > think they aren't). No, no 1000 times no! I have tried so many times to say that universal URI syntax is more universal than the semantics of any "name", "address", "locator" space. It is social issues not technical ones which in the end make the differences between names and addresses in a global information space. > . Alternatively, can we align the syntaxes and succeed in having > > URN: > > treated as a special case by URL resolvers, (treated as an > opaque URL, as Ryan described it). Hands up those who like special cases. >These questions have little to do with implementation details -- i.e., >any of the above can certainly be implemented. The real questions, to my >way of thinking, lie in: > > . Does lining up the syntaxes increase the likelihood of getting > URNs handled sooner rather than later by existing software (i.e., > are the necessary differences in handling going to mean that > existing software can't handle them anyway?) > > . What issues will we have to address in terms of > supporting/distinguishing URN/URL semantics? (E.g., if URNs > are supported as URL "schemes", can we make the distinction > between names and addresses). The semantics of any URI scheme, http: and urn: included, are defined by - The specification of hte scheme in the rules it allows for changing the mapping of URI to content; - the social systems set up to ensure that the rules are followed; - the extent to which those social systems work; - The rules set up, in a hierarchical system, by delegates such as URN authorities for URNs or webmasters for HTTP which determine how specifically the mapping of URI to content in any given subtree; - Similarly, the social systems to enforce those rules and the extent that they work. Historians and librarians of the future will be able to say what worked in terms of being persistent. >I have not been successful in trying to make this an even-handed message -- it >is pretty clear that I am concerned that we are heading back into rough >waters regarding "why do we need URNs when we have URLs". If the URN group is going to set up a new name space with good properties, then that seems to me to have some value. I also believe in the coexistence of alternative schemes and (especially when social factors are involved) the real world and the market testing them and choosing in the end. Tim BL Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA11095 for urn-ietf-out; Wed, 29 Jan 1997 16:20:09 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA11084 for ; Wed, 29 Jan 1997 16:19:58 -0500 Received: from Honey.Innosoft.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07805 (mail destined for urn-ietf@services.bunyip.com); Wed, 29 Jan 97 16:19:48 -0500 Received: from LOCALHOST by envy.cs.utk.edu with SMTP (cf v2.11c-UTK) id LAA01155; Wed, 29 Jan 1997 11:13:24 -0500 Message-Id: <199701291613.LAA01155@envy.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Daniel LaLiberte Cc: "Martin J. Duerst" , "Ron Daniel Jr." , Tim Berners-Lee , URL mailing list , urn-ietf@bunyip.com, moore@cs.utk.edu Subject: [URN] Re: Relative URLs and URNs In-Reply-To: Your message of "Wed, 29 Jan 1997 09:58:08 CST." <199701291558.JAA18910@void.ncsa.uiuc.edu> Date: Wed, 29 Jan 1997 11:12:51 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > If all URNs are syntactically opaque URLs, are we not imposing a > restriction on all URNs that they cannot use the relative URL mechanism? Yes, but this is a feature. Relative URLs wire relationships between resources into the resource name itself, which hurts long-term persistence. > Long term, support for some name > spaces will eventually fade out completely, so moving to a new name > space is not only a possibility, it seems to be a certainty. Yes, for newly-created names. But there's no reason why resolution services cannot continue to exist for old namespaces, even though they may use new resolution methods and protocols. > How is a location within a resource really different from a relative > URN? The answer depends on whether the relationship between locations within a resource can change over time. But you're right - the ability to reference different portions of a resource opens up a very similar can of worms as the ability to reference one resource relative to another. If you want persistent references for portions of a resource, you need similar rules for assignment as you would for persistent identifiers for resources themselves -- e.g. don't use section numbers (they'll change) or human-meaningful section names (because the document will be reorganized into sections that don't correspond to the original one). Even then, I'm not sure what it means to talk about references relative to a "Base URN" ...because this assumes that the "Base URN" will need to change while the intra-resource reference names need to stay the same. > Another advantage of relative identifiers is that they are shorter > than their equivalent full identifiers. It's not necessarily true that a URN is shorter than a relative URL. Since URNs don't need to be human-meaningful, they can be allocated from a denser space than is typical for URLs. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA03172 for urn-ietf-out; Wed, 29 Jan 1997 12:56:51 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA03167 for ; Wed, 29 Jan 1997 12:56:47 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA05847 (mail destined for urn-ietf@services.bunyip.com); Wed, 29 Jan 97 12:56:30 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <08248-0@josef.ifi.unizh.ch>; Wed, 29 Jan 1997 18:48:36 +0100 Date: Wed, 29 Jan 1997 18:48:35 +0100 (MET) From: "Martin J. Duerst" To: URL mailing list , urn-ietf@bunyip.com Subject: Re: [URN] what's in a syntax? (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com The following is a mail I sent to Leslie regarding her request on the URN list. I am posting it now, as mentionned before, because I think that it gives some more background to some things currently discussed about URNs and URLs. Not that I think that the things I discuss here should be realized immediately, though. Regards, Martin. ---------- Forwarded message ---------- Date: Tue, 28 Jan 1997 10:01:53 +0100 (MET) From: "Martin J. Duerst" To: Leslie Daigle Subject: Re: [URN] what's in a syntax? On Mon, 27 Jan 1997, Leslie Daigle wrote: > It seems to me that we are at a crossroads with the URN syntax, and we need to > get some concrete sense of direction quickly. > > I'd like to outline the situation below and then ask for everyone to send > feedback to me directly -- and please, do send feedback, if only to let me > know people are still thinking about this :-) Hello Leslie, I'm definitely still caring about it, although my main concern is internationalization. Even for this, the syntactic parallels between URLs and URNs are important, whereas semantically (e.g. why do we need internationalization), there are wide differences. > Ryan, our URN syntax document editor, has spent a good deal of time trying > to get URN syntax to line up reasonably well with the existing URL syntax > document (i.e., the de facto "URI" syntax document). > > This document is currently under review, and there are efforts afoot to > determine a review process for vetting new URL schemes. > > As part of the discussion of this (on the uri@bunyip.com mailing list), > the issue of URN conformance with URL syntax has come up. There are some > specific changes that would (still) have to be made to accomplish this. > While these are not necessarily stressing in terms of syntax, there > are some particular ramifications that need to be considered: > > . If we align the syntaxes wrt reserved characters, etc, will > > URN: > > necessarily imply that URNs are a "scheme" of URLs? No, URNs are not, and should not be, a special scheme. They are on par with URLs. But syntactically, they look like a (not so) special scheme, and this has many advantages. And they might be processed by many browsers like a scheme, i.e. look at part before first ":", decide which subroutine to call, and pass the rest to this subroutine. > If so, then URNs will have to go through the URL vetting process, > and potentially the string "URN" will be objected to. No, URNs are one level higher. > Also, will this imply that URNs are equivalent to URLs in terms > of semantics? (There are those that think the are, and those that > think they aren't). That's not my field of expertise, but I think finally, usage will show it. In some sense, they are similar (you get something back if you type it into a browser), in some sense, they are hopefully different (persistency,...). > . Alternatively, can we align the syntaxes and succeed in having > > > URN: > > treated as a special case by URL resolvers, (treated as an > opaque URL, as Ryan described it). An opaque URL, in terms of URLs, is nothing special. A lot of URLs are opaque URLs, such as "mailto" or "data". URNs conform to URL syntax. They just don't conform to the syntax for generic URLs, but that's not necessary. The question might arise whether relative addressing of URNs is necessary or desirable. The way I see URNs, their persistency implies that they are rather big and independent, so that relative addressing is not of much use. One of the scenarios I see is that an URN (e.g. for a book) is resolved to an URL that is the top of the hypertext structure that actually represents that book, and that that hypertext structure is internally linked using relative URLs. This may lead to the question whether we need a way to not only say "book X" (with urn:isbn:0-12345678-9) but "paragraph m on page n of chapter y". There would be no need for such things to use relatively, as other means can be used for addressing inside a document, and as the main advantage of relative addressing, invariance under coordinated movement to another place, is irrelevant because URNs don't change if the actual resource is moved to another place. But still, the requirement of addressing a point inside an URN may remain. The problem is that such addressing can be done in many different ways (pages vs. chapters and sections, or seconds for a video,...). The #name feature looks promising, but it restricts references to only those places that have been tagged beforehand, not a good thing for maybe very bulky documents. What I think is worth contemplating, if not already done, are ways to identify locations inside an URN. This is quite an architectural question, because we might require that URN resolvers resolve locations inside a resource at the same time they resolve the URN itself, or that it is just something done syntactically. In the first case, an URN urn:isbn:0-12345678-9=page34line20 would be passed as 0-12345678-9=page34line20 to some isbn resolver, which, maybe with the help of other resolvers, could return an URL such as http://xxx.yyy.lib/books/shelfNN/ourBook/chapter3/section2#anchor which might be the closest identifiable point to line 20 on page 34. The alternative would be to have an URN urn:isbn:0-12345678-9=/chapter3/section2#anchor which would be chopped apart either by the URN software or an isbn resolver (depending on whether a generic syntax is choosen or not). The resolving process would then return only http://xxx.yyy.lib/books/shelfNN/ourBook and the client would append /chapter3/section2#anchor to get the same result. In the above, the fact that the first example uses lines and pages should not give the impression that this variant is more oriented towards physical location; the important thing is that it (potentially) allows various addressing modalities and transformation from one modality to another. The character "=" has been choosen just as an example. If we decide that addressing inside a resource is a desired syntactical property of (potentially) all URNs and that it should be handled syntactically (i.e. by string concatenation with the resulting URL, with all the problems of non-portability), then it might become "#". If URN resolvers are responsible for this part also, there is no need for a convention, although it is not bad to have an informal one. The main problem in this case is that URN schemes have to plan for such things in advance; it is difficult to start with an "isbn" scheme without such a feature and later add one. There is also the danger of fragmentation, i.e. from an isbn scheme, somebody might create an isbnpageline scheme, whereas somebody else might create an isbnchaptsect scheme. If done with enough foresight, this is of course not necessessary, because urn:isbn:0-12345678-9=page34line20 and urn:isbn:0-12345678-9=chapt2sect3 (which in both cases would need a little bit more of syntax after the "=") can both coexist. > These questions have little to do with implementation details -- i.e., > any of the above can certainly be implemented. The real questions, to my > way of thinking, lie in: > > . Does lining up the syntaxes increase the likelihood of getting > URNs handled sooner rather than later by existing software (i.e., > are the necessary differences in handling going to mean that > existing software can't handle them anyway?) The syntaxes are already lined up (apart from internationalization issues). > . What issues will we have to address in terms of > supporting/distinguishing URN/URL semantics? (E.g., if URNs > are supported as URL "schemes", can we make the distinction > between names and addresses). > > > I have not been successful in trying to make this an even-handed message -- it > is pretty clear that I am concerned that we are heading back into rough > waters regarding "why do we need URNs when we have URLs". _However_, I > know there are other people who have seen all of this and think that there > is no real issue at all. The rough question might be "do we need some mechanism to identify 'locations' inside a resource". > So, please send feedback -- if you think there is an issue here, and why, or > if you think there is no issue here, and why not. Please send directly > to me -- I will summarize for the list, and make the collected messages > available. It turns out that I have written a lot here. If you think that it makes sense to send this directly to the list for further discussion, please do so or tell me to do so. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA00238 for urn-ietf-out; Wed, 29 Jan 1997 10:58:58 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA00230 for ; Wed, 29 Jan 1997 10:58:41 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03090 (mail destined for urn-ietf@services.bunyip.com); Wed, 29 Jan 97 10:58:38 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.5/8.8.5) with ESMTP id JAA22415; Wed, 29 Jan 1997 09:58:13 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id JAA18910; Wed, 29 Jan 1997 09:58:08 -0600 (CST) Date: Wed, 29 Jan 1997 09:58:08 -0600 (CST) Message-Id: <199701291558.JAA18910@void.ncsa.uiuc.edu> To: "Martin J. Duerst" Cc: "Ron Daniel Jr." , Tim Berners-Lee , URL mailing list , urn-ietf@bunyip.com Subject: [URN] Re: Relative URLs and URNs In-Reply-To: References: <3.0.32.19970127161513.00719f30@acl.lanl.gov> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com.Thus.spoke.Tim.Berners-Lee:The.URN.scheme.should.be.mapped.onto.urn1://authority/nameissuedbyauthority Martin J. Duerst writes: > As far as I understand, the first part after the "urn" prefix is > not an authority (work is going on on mechanisms to actually > find such authorities or resolvers), but more akin to a scheme > in the URL case. So the use of ":" instead of "//" has some > merit. That is one way to look at it. I like to think of the as a scheme name because it determines how the rest of the identifier is interpreted, just as for other identifiers. But this nested notation does not fit in the current generic URI notation. We could probably change the generic URI notation to allow this nesting, but there are some other considerations. For one thing, there was some discussion about whether the itself should be hierarchical to allow subauthorities. Scheme names are not (currently) hierarchical. But if the in the identifier is used to find or look up an authority or resolver, then the is at least the *name* of the authority or resolver. > I beg to disagree. URNs are designed to be syntactically equivalent to > opaque URLs. Whether URNs are syntactically opaque URLs is still open for discussion. If all URNs are syntactically opaque URLs, are we not imposing a restriction on all URNs that they cannot use the relative URL mechanism? > Ron Daniels said: > > At this time we have not defined any relative URN specification. True, but we wouldn't need to define a new relative URN specification if we simply inherited the relative URL specification so that it applies to URNs also. > Because URNs are persistent, the main advantage of relative URNs, > namely invariance on coordinated movements to other locations, > is irrelevant. Not true, for several reasons. One reason is that, although URNs are *intended* to be persistent, there will be multiple names for things, each possibly providing different associated services or different reliability or speed of resolution. Long term, support for some name spaces will eventually fade out completely, so moving to a new name space is not only a possibility, it seems to be a certainty. Therefore, making the identifiers within a document relative to the base identifier is a good idea. This is not really different from what you suggest next: > What could be more relevant is the possibility to address parts of > resources, or 'locations' within resources, together with URNs. How is a location within a resource really different from a relative URN? What makes an identifier be relative is that part of the context for interpreting it is missing from the identifier itself. That context is the base URL of a document, but it could just as well be a base URN of the document. So both relative URNs and relative URLs are better thought of as relative identifiers of some kind. What kind of identifier they are depends on the context, the base URI. The very same relative identifier could be both a relative URL (e.g. http) and a relative URN (e.g. path), if the URN supported hierarchy at that level. Another advantage of relative identifiers is that they are shorter than their equivalent full identifiers. This becomes a significant issue when there are large numbers of identifiers in a document. (This is analogous to the flyweight pattern, if you are familiar with OO design patterns.) > I have sent some considerations about this to Leslie as a > response to her request on the URN mailing list; I can make > this available if somebody is interested. If Leslie includes that in her summary, I can wait. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA16782 for urn-ietf-out; Tue, 28 Jan 1997 04:21:38 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA16775 for ; Tue, 28 Jan 1997 04:21:36 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12762 (mail destined for urn-ietf@services.bunyip.com); Tue, 28 Jan 97 04:21:33 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <22338-0@josef.ifi.unizh.ch>; Tue, 28 Jan 1997 10:21:39 +0100 Date: Tue, 28 Jan 1997 10:21:38 +0100 (MET) From: "Martin J. Duerst" To: "Ron Daniel Jr." Cc: Tim Berners-Lee , URL mailing list , urn-ietf@bunyip.com Subject: [URN] Re: Relative URLs, // and ; In-Reply-To: <3.0.32.19970127161513.00719f30@acl.lanl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Mon, 27 Jan 1997, Ron Daniel Jr. wrote: > [I'm adding urn-ietf@bunyip.com to the Cc list since that is the > list for the IETF's URN-WG.] > > Thus spoke Tim Berners-Lee: > > >The URN scheme should be > >mapped onto > >urn1://authority/nameissuedbyauthority As far as I understand, the first part after the "urn" prefix is not an authority (work is going on on mechanisms to actually find such authorities or resolvers), but more akin to a scheme in the URL case. So the use of ":" instead of "//" has some merit. > The proposed URN syntax is laid out in draft-ietf-urn-syntax, but > the short description is: > urn:namespace_id:namespace_specific_string > for example > urn:isbn:1-234-5678-9 > urn:upc:42709-10150 > etc. > > Some namespaces, such as ISO Formal Public Identifiers, already make > use of '//'. For such namespaces we say they need to %encode occurances > of '/' that do not follow the rules of RFC1639. Those rules were that > '/' denoted hierarchy with the most significant component on the left. I beg to disagree. URNs are designed to be syntactically equivalent to opaque URLs. In an opaque URL, escaping of '/' is not needed, unless it is syntactically significant. See e.g. section 2.1 of draft-fielding-... The only reserved characters that URN syntax itself uses is ":", and this doesn't have to be escaped because it cannot appear in the first two parts ("urn" and e.g. "isbn"). The need of escaping of reserved characters after the second ":" is determined by the needs of the namespace. These will usually be rather low, as some of them don't use many characters so that there is no problem identifying reserved characters, and others will most certainly have their own way to get around this problem. E.g. in the case of "isbn", "-" is a reserved character, but it is not also used at the place of a digit (or X). In the case of ISO Formal Public Identifiers, either "/" is also disallowed between structurally meaningful "/", or there must be a way to escape such "/". > At this time we have not defined any relative URN specification. Because URNs are persistent, the main advantage of relative URNs, namely invariance on coordinated movements to other locations, is irrelevant. What could be more relevant is the possibility to address parts of resources, or 'locations' within resources, together with URNs. I have sent some considerations about this to Leslie as a response to her request on the URN mailing list; I can make this available if somebody is interested. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA29985 for urn-ietf-out; Mon, 27 Jan 1997 18:15:54 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA29977; Mon, 27 Jan 1997 18:15:47 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08920 (mail destined for uri@services.bunyip.com); Mon, 27 Jan 97 18:13:31 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id QAA00991; Mon, 27 Jan 1997 16:12:42 -0700 (MST) Message-Id: <3.0.32.19970127161513.00719f30@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Mon, 27 Jan 1997 16:23:45 -0700 To: Tim Berners-Lee From: "Ron Daniel Jr." Subject: [URN] Re: Relative URLs, // and ; Cc: uri@bunyip.com, urn-ietf@bunyip.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com [I'm adding urn-ietf@bunyip.com to the Cc list since that is the list for the IETF's URN-WG.] Thus spoke Tim Berners-Lee: >The URN scheme should be >mapped onto >urn1://authority/nameissuedbyauthority The proposed URN syntax is laid out in draft-ietf-urn-syntax, but the short description is: urn:namespace_id:namespace_specific_string for example urn:isbn:1-234-5678-9 urn:upc:42709-10150 etc. Some namespaces, such as ISO Formal Public Identifiers, already make use of '//'. For such namespaces we say they need to %encode occurances of '/' that do not follow the rules of RFC1639. Those rules were that '/' denoted hierarchy with the most significant component on the left. >At 11:29 am 27-01-97 -0600, Daniel LaLiberte wrote: >>Are you just putting your foot down now .. finally. > >I've been out of the loop. URIs are not supposed to be irrevocably linked >to DNS! >Unfortunately there have been many demands on my time. I don't understand your assertion about DNS. No URN namespace is required to use domain names, as shown by the examples above. Certainly the namespaces we are considering for use at the lab have NO tie to the DNS. (They may be resolved through the DNS, but the names themselves don't use domain names). Members of the URN-WG have expressed a desire for a namespace that is easy for people to get started with, and lots of people think that using the domain name hierarchy (perhaps with some augmentations to overcome the reassignment problem) is the way to go. Such a namespace might look like urn:inet:acl.lanl.gov(1):fy97_budget but I emphasize that this is only one namespace out of many. [Lots of stuff on "///", "//", "/" deleted.] At this time we have not defined any relative URN specification. Nevertheless we do not allow unencoded occurances of '/' in URNs unless they follow the rules in RFC1630. Similarly, '?', '#', and a few other characters must be encoded unless they follow the rules of RFC1630. One of the URN requirements was to allow old namespaces to be grandfathered into URNs. Because of this, I am wary about requiring ALL URN namespaces to use '//'. Some namespaces will not have the notion of a relative identifier, others (such as path) may not need '//'. What we do require is that when representing a name from an old namespace as a URN, reserved characters are encoded unless they meet the semantics established by 1630. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab, MS B287 voice: +1 505 665 0597 Los Alamos National Laboratory fax: +1 505 665 4939 Los Alamos, NM, USA 87545 http://www.acl.lanl.gov/~rdaniel/ Want to buy: "The Five Laws of Library Science" by S.R. Ranganathan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA25208 for urn-ietf-out; Mon, 27 Jan 1997 15:25:12 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA25198 for ; Mon, 27 Jan 1997 15:25:10 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06906 (mail destined for urn-ietf@services.bunyip.com); Mon, 27 Jan 97 15:25:08 -0500 From: Leslie Daigle Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id PAA12419 for urn-ietf@bunyip.com; Mon, 27 Jan 1997 15:25:07 -0500 Date: Mon, 27 Jan 1997 15:25:07 -0500 Message-Id: <199701272025.PAA12419@beethoven.bunyip.com> To: urn-ietf@bunyip.com Subject: [URN] what's in a syntax? Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Leslie Daigle Errors-To: owner-urn-ietf@bunyip.com It seems to me that we are at a crossroads with the URN syntax, and we need to get some concrete sense of direction quickly. I'd like to outline the situation below and then ask for everyone to send feedback to me directly -- and please, do send feedback, if only to let me know people are still thinking about this :-) Ryan, our URN syntax document editor, has spent a good deal of time trying to get URN syntax to line up reasonably well with the existing URL syntax document (i.e., the de facto "URI" syntax document). This document is currently under review, and there are efforts afoot to determine a review process for vetting new URL schemes. As part of the discussion of this (on the uri@bunyip.com mailing list), the issue of URN conformance with URL syntax has come up. There are some specific changes that would (still) have to be made to accomplish this. While these are not necessarily stressing in terms of syntax, there are some particular ramifications that need to be considered: . If we align the syntaxes wrt reserved characters, etc, will URN: necessarily imply that URNs are a "scheme" of URLs? If so, then URNs will have to go through the URL vetting process, and potentially the string "URN" will be objected to. Also, will this imply that URNs are equivalent to URLs in terms of semantics? (There are those that think the are, and those that think they aren't). . Alternatively, can we align the syntaxes and succeed in having URN: treated as a special case by URL resolvers, (treated as an opaque URL, as Ryan described it). These questions have little to do with implementation details -- i.e., any of the above can certainly be implemented. The real questions, to my way of thinking, lie in: . Does lining up the syntaxes increase the likelihood of getting URNs handled sooner rather than later by existing software (i.e., are the necessary differences in handling going to mean that existing software can't handle them anyway?) . What issues will we have to address in terms of supporting/distinguishing URN/URL semantics? (E.g., if URNs are supported as URL "schemes", can we make the distinction between names and addresses). I have not been successful in trying to make this an even-handed message -- it is pretty clear that I am concerned that we are heading back into rough waters regarding "why do we need URNs when we have URLs". _However_, I know there are other people who have seen all of this and think that there is no real issue at all. So, please send feedback -- if you think there is an issue here, and why, or if you think there is no issue here, and why not. Please send directly to me -- I will summarize for the list, and make the collected messages available. Thanks, Leslie. ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA29082 for urn-ietf-out; Mon, 20 Jan 1997 11:59:41 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA29076 for ; Mon, 20 Jan 1997 11:59:37 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04806 (mail destined for urn-ietf@services.bunyip.com); Mon, 20 Jan 97 11:59:23 -0500 Received: by privateer.windrose.omaha.ne.us; Mon Jan 20 10:58 CST 1997 Message-Id: <32E3A44E.CF4@ds.internic.net> Date: Mon, 20 Jan 1997 10:58:54 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: urn-ietf@bunyip.com Subject: [URN] Last ?? Pre-release of syntax-02. Content-Type: multipart/mixed; boundary="------------2C1F68322435" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com This is a multi-part message in MIME format. --------------2C1F68322435 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks- Here is the next (and if I'm lucky last) pre-release of syntax-02. Changes from the last pre-release are that I've moved characters around to align with the URL specification, and added an Appendix on how URN's should be handled by URL resolvers. Please look at this as it could probably use some hammering. If I don't see any comments by next monday I'll send it to the i-d editors. (Actually if the comments are slight enough I'll do that anyway). Ryan --------------2C1F68322435 Content-Type: text/plain; charset=us-ascii; name="urn.syntax.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="urn.syntax.txt" Internet-Draft Ryan Moats draft-ietf-urn-syntax-02.txt AT&T Expires in six months January 1997 URN Syntax Filename: draft-ietf-urn-syntax-02.txt Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers. This document sets forward the canonical syntax for URNs. Support for both existing legacy and new namespaces is discussed. Requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. 1. Introduction Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space. The URN syntax therefore provides a means to encode character data in a form that can be sent in existing protocols, transcribed on most keyboards, etc. Expires 7/31/97 [Page 1] INTERNET DRAFT URN Syntax January 1997 2. Syntax All URNs have the following syntax: ::= "urn:" ":" is the Namespace Identifier, and is the Namespace Specific String. The leading case-insensitive "urn:" sequence is required. The Namespace ID is used to determine the _syntactic_ interpretation of the Namespace Specific String (as discussed in [1]). RFC 1737 [2] presents additional requirements on URN encoding, which all have implications as far as limiting syntax. On the other hand, the requirement to support existing legacy naming systems has the effect of broadening syntax. Thus, we discuss the acceptable syntax for both the Namespace Identifier and the Namespace Specific String separately. 2.1 Namespace Identifier Syntax The following is the syntax for the Namespace Identifier. To (a) be consistent with all potential resolution schemes and (b) not put any undue constraints on any potential resolution scheme, the syntax for the Namespace Identifier is: ::= [ * ] ::= | | | "-" ::= | | ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" This is slightly more restrictive that what is stated in [3] (which Expires 7/31/97 [Page 2] INTERNET DRAFT URN Syntax January 1997 allows the characters "." and "+"). Further, the Namespace Identifier is case insensitive, so that "ISBN" and "isbn" refer to the same namespace. To avoid confusion with the "urn:" identifier, the NID "urn" is reserved and MUST NOT be used. 2.2 Namespace Specific String Syntax As required by 1737, there is a single canonical representation of the NSS portion of an URN. The format of this single canonical form follows: ::= 1* ::= | "%" ::= | | | ::= | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" ::= "(" | ")" | "+" | "," | "-" | "." | "/" | ":" | "=" | "?" | "@" | "%" | ";" | "$" | "_" | "!" | "~" | "*" | "'" Depending on the rules governing a namespace, valid identifiers in a namespace might contain characters that are not members of the URN character set above (). Such strings MUST be translated into canonical NSS format before using them as protocol elements or otherwise passing them on to other applications. Translation is done by encoding each character outside the URN character set as a sequence of one to six octets using UTF-8 encoding, and the encoding of each of those octets as "%" followed by two characters from the character set above. The two characters give the hexadecimal representation of that octet. The "%" character is reserved in the URN syntax for introducing the escape sequence for an octet. Literal use of the "%" character in a namespace must be encoded using "%25" in URNs for that namespace. The presence of an "%" character in a URN MUST be followed by two characters from the character set. Namespaces MAY designate one or more characters from the URN character set as having special meaning for that namespace. If the namespace also uses that character in a literal sense as well, the character used in a literal sense MUST be encoded with "%" followed by the hexadecimal representation of that octet. Therefore, the Expires 7/31/97 [Page 3] INTERNET DRAFT URN Syntax January 1997 process of registering a namespace identifier shall include publication of a definition of which characters have a special meaning to that namespace. 2.3 Excluded characters The following list is included only for the sake of completeness. Any octets/characters on this list are explicitly NOT part of the URN character set, and if used in a URN, MUST be %encoded: ::= octets 0-32 (0-20 hex) | "\" | """ | "#" | "&" | "<" | ">" | "[" | "]" | "^" | "`" | "{" | "|" | "}" | octets 127-255 (7F-FF hex) A URN ends when an octet/character from the excluded character set () is encountered. The character from the excluded character set is NOT part of the URN. 3. Support of existing legacy naming systems and new naming systems Any namespace (existing or newly-devised) that is proposed as a URN- namespace and fulfills the criteria of URN-namespaces MUST be expressed in this syntax. If names in these namespaces contain characters other than those defined for the URN character set, they MUST be translated into canonical form as discussed in section 2.2. 4. URN presentation and transport URN-aware applications MAY support "natural" display of URNs which contain characters encoded using "%" notation. However, they MUST provide for display of URNs in canonical form (i.e. in a format suitable for transcription). URNs MUST be transported in canonical format. 5. Lexical Equivalence in URNs For various purposes, such as caching, it is necessary to determine equivalence without actually resolving the URN. This done by testing for "lexical equivalence". Two URNs are lexically equivalent if they are octet-by-octet equal after the following preprocessing 1. normalize the case of the leading "urn:" token 2. normalize the case of the NID 3. normalizing the case of any "%" escaping Some namespaces may define additional lexical equivalences, such as case-insensitivity of the NSS (or parts thereof). Additional lexical equivalences MUST be documented as part of namespace registration, MUST Expires 7/31/97 [Page 4] INTERNET DRAFT URN Syntax January 1997 always have the effect of eliminating some of the false negatives obtained by the procedure above, and MUST NEVER say that two URNs are not equivalent if the procedure above says they are equivalent. 6. Functional Equivalence in URNs Functional equivalence is determined by URN resolvers and is therefore outside the scope of this document. Namespace registration MUST include documentation on how to determine functional equivalence for that namespace. 7. Examples of equivalence The following URN comparisons highlight the difference between these types of equivalence: urn:isbn:1-23485-8-29, urn:isbn:1-23485-8-29 are lexically equiv. urn:isbn:1-23485-8-29, URN:ISBN:1-23485-8-29 are lexically equiv. urn:isbn:1-23485-8-29, urn:isbn:123485829 are not lexically equiv. but may be functionally equivalent. 8. Security considerations This document specifies the syntax for URNs. While some namespaces resolvers may assign special meaning to certain of the characters of the Namespace Specific String, any security consideration resulting from such assignment are outside the scope of this document. It is strongly recommended that the process of registering a namespace identifier include any such considerations. 9. Acknowledgments Thanks to various members of the URN working group and <> for comments on earlier drafts of this document. This document is partially supported by the National Science Foundation, Cooperative Agreement NCR-9218179. 10. References Request For Comments (RFC) and Internet Draft documents are available from and numerous mirror sites. [1] K. R. Sollins. "Requirements and a Framework for URN Resolution Systems" Internet Draft (work in progress). November 1996. [2] K. Sollins, L. Masinter. "Functional Requirements Expires 7/31/97 [Page 5] INTERNET DRAFT URN Syntax January 1997 for Uniform Resource Names," RFC 1737. December 1994. [3] T. Berners-Lee, R. Fielding, L. Masinter. "Uniform Resource Locators (URL)," Internet Draft (work in progress). December 1996. 11. Editor's address Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA Phone: +1 402 894-9456 EMail: jayhawk@ds.internic.net Appendix A. Handling of URNs by URL resolvers/browsers. The URN syntax has been defined so that URNs can be used in places where URLs are expected. A resolver that conforms to the current URL syntax specification [3] will extract a scheme value of "urn:" rather than a scheme value of "urn:". A URN MUST be considered an opaque URL by URL resolvers and either passed (with the "urn:" tag) to a URN resolver for resolution. The URN resolver can either be an external resolver that the URL resolver knows of, or it can be functionality built-in to the URL resolver. To avoid confusion of users, a URL browser SHOULD display the com- plete URN (including the "urn:" tag) to ensure that there is no con- fusion between URN namespace identifiers and URL scheme identifiers. This Internet Draft expires July 31, 1997. Expires 7/31/97 [Page 6] --------------2C1F68322435-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA08521 for urn-ietf-out; Mon, 13 Jan 1997 14:08:30 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA08516 for ; Mon, 13 Jan 1997 14:08:28 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02537 (mail destined for urn-ietf@services.bunyip.com); Mon, 13 Jan 97 14:08:23 -0500 Received: by privateer.windrose.omaha.ne.us; Mon Jan 13 13:02 CST 1997 Message-Id: <32DA79BC.733C@ds.internic.net> Date: Mon, 13 Jan 1997 13:06:52 -0500 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 2.02E (OS/2; I) Mime-Version: 1.0 To: "Martin J. Duerst" Cc: urn-ietf@bunyip.com Subject: Re: [URN] [Fwd: Proposed URN Syntax Draft changes to align with URL syntax draft] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Martin J. Duerst wrote: > > On Thu, 9 Jan 1997, Ryan Moats wrote [regrouped]: > > > 1. The URN syntax is more restrictive in the types of characters > > allowed vis-a-vie the URL syntax. Specifically, the characters > > ";", "$", "_", "!", "~", "*", "'" are allowed (in unescaped format) > > in the URL syntax while not in the URN syntax. > > > My current thoughts are to move the characters in note 1 above from the > > excluded character set to the allowed character set to more closely > > align the URN and URL character sets. IF SOMEONE THINKS THIS IS A BAD > > IDEA THIS IS A GOOD TIME TO LET ME KNOW! > > With exception of "~", for which some change has been going on in > the URL syntax draft, they should be in. The reasoning for this is > that we don't know what kind of reserved characters a namespace would > like to use, but we know that it can only use those that we include. I haven't seen anything on this. Is "~" going to be moved to the excluded URL character set? > > 2. The URL syntax document makes a claim that the its syntax is the > > syntax for URIs in general so that URNs may be used in any data field > > that might otherwise hold a URL. > > > > Issue 2 is handled (I believe) by adding an appendix to the URN syntax > > document that covers how a URL resolver should react to a URN. My > > proposal is that the URN be considered an opaque URL that gets handed > > off to a URN resolver. There are alternate solutions, but they become > > progressively more ugly. > > Yes, this is a good way to describe it. Please make sure you don't > write "an URL resolver SHOULD", but that you describe this as a possible > way to proceed that clarifies the relationship between URLs and URNs. My view is that a URL resolver that doesn't understand URN syntax MUST treat the URN as an opaque URL and not try to do anything with it (other than pass it to a URN resolver). A URL resolver that understands URNs... well that's a beast of a different hue. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA06583 for urn-ietf-out; Mon, 13 Jan 1997 12:55:39 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA06578 for ; Mon, 13 Jan 1997 12:55:36 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00951 (mail destined for urn-ietf@services.bunyip.com); Mon, 13 Jan 97 12:55:30 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <20698-0@josef.ifi.unizh.ch>; Mon, 13 Jan 1997 18:54:59 +0100 Date: Mon, 13 Jan 1997 18:54:58 +0100 (MET) From: "Martin J. Duerst" To: Ryan Moats Cc: urn-ietf@bunyip.com Subject: Re: [URN] [Fwd: Proposed URN Syntax Draft changes to align with URL syntax draft] In-Reply-To: <32D53ECE.1EBF@ds.internic.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Thu, 9 Jan 1997, Ryan Moats wrote [regrouped]: > Well, here we are in the week of 1/6/97 and some issues have come up > vis-a-vie the URL syntax document. Here are the technical issues (as I > see them, and I've probably missed/ignored some): > > 1. The URN syntax is more restrictive in the types of characters > allowed vis-a-vie the URL syntax. Specifically, the characters > ";", "$", "_", "!", "~", "*", "'" are allowed (in unescaped format) > in the URL syntax while not in the URN syntax. > My current thoughts are to move the characters in note 1 above from the > excluded character set to the allowed character set to more closely > align the URN and URL character sets. IF SOMEONE THINKS THIS IS A BAD > IDEA THIS IS A GOOD TIME TO LET ME KNOW! With exception of "~", for which some change has been going on in the URL syntax draft, they should be in. The reasoning for this is that we don't know what kind of reserved characters a namespace would like to use, but we know that it can only use those that we include. > 2. The URL syntax document makes a claim that the its syntax is the > syntax for URIs in general so that URNs may be used in any data field > that might otherwise hold a URL. > > I'll admit that there are a lot of political issues that I am ignoring > for now, but I want to see if we can move forward with the technical > issues. > Issue 2 is handled (I believe) by adding an appendix to the URN syntax > document that covers how a URL resolver should react to a URN. My > proposal is that the URN be considered an opaque URL that gets handed > off to a URN resolver. There are alternate solutions, but they become > progressively more ugly. Yes, this is a good way to describe it. Please make sure you don't write "an URL resolver SHOULD", but that you describe this as a possible way to proceed that clarifies the relationship between URLs and URNs. > Note that issues 1 and 2 are somewhat independent. Given the current > allowed characters and the above suggested appendix, any URN could be > used in place of a URL. > > Although I've considered it in the past, I think that defining URN's as > a URL "scheme" is a less optimal solution than the above proposals. I agree we should not say that an URN is an URL "scheme". Syntactically, it is equivalent to an URL scheme, but semantically, it is something different. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA26793 for urn-ietf-out; Thu, 9 Jan 1997 15:24:33 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA26788 for ; Thu, 9 Jan 1997 15:24:31 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA05291 (mail destined for urn-ietf@services.bunyip.com); Thu, 9 Jan 97 15:24:25 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id MAA28091; Thu, 9 Jan 1997 12:24:10 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id MAA08051; Thu, 9 Jan 1997 12:24:06 -0800 (PST) Date: Thu, 9 Jan 1997 12:24:06 -0800 (PST) From: Terry Allen Message-Id: <199701092024.MAA08051@ishtar.fsc.fujitsu.com> To: jayhawk@ds.internic.net, urn-ietf@bunyip.com Subject: Re: [URN] [Fwd: Proposed URN Syntax Draft changes to align with URL syntax draft] Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Ryan's suggestions sound okay to me. >Obviously, I am soliciting input to try and gain an idea about consensus (and fairly quickly, too). Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA24756 for urn-ietf-out; Thu, 9 Jan 1997 13:55:49 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA24751 for ; Thu, 9 Jan 1997 13:55:47 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04301 (mail destined for urn-ietf@services.bunyip.com); Thu, 9 Jan 97 13:55:35 -0500 Received: by privateer.windrose.omaha.ne.us; Thu Jan 9 12:54 CST 1997 Message-Id: <32D53ECE.1EBF@ds.internic.net> Date: Thu, 09 Jan 1997 12:54:06 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: urn-ietf@bunyip.com Subject: [URN] [Fwd: Proposed URN Syntax Draft changes to align with URL syntax draft] Content-Type: multipart/mixed; boundary="------------5232E4A818" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com This is a multi-part message in MIME format. --------------5232E4A818 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit For some reason, this didn't go anywhere the first time???! Ryan --------------5232E4A818 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: by privateer.windrose.omaha.ne.us; Tue Jan 7 13:02 CST 1997 Sender: jayhawk Message-ID: <32D29DAC.3DC6@ds.internic.net> Date: Tue, 07 Jan 1997 13:02:04 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) MIME-Version: 1.0 To: urn-ietf@bunyip.com Subject: Proposed URN Syntax Draft changes to align with URL syntax draft References: <32BAEDA2.4940@ds.internic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ryan Moats wrote: > > Folks- > > There have been some good comments about the syntax draft and some > good stuff coming out of meshing it with the URL syntax, so I am > planning the following (i.e. you have been warned!). > > There will be another pre-release of syntax-02 coming out on > 12/26 ( Holidays, what are Holidays ;-} ). The target is to > have -02 be sent to the i-d editors on 1/6/97. > > This way folks (who don't have anything else to do between 12/25 > and 1/1) can read the new version... Well, here we are in the week of 1/6/97 and some issues have come up vis-a-vie the URL syntax document. Here are the technical issues (as I see them, and I've probably missed/ignored some): 1. The URN syntax is more restrictive in the types of characters allowed vis-a-vie the URL syntax. Specifically, the characters ";", "$", "_", "!", "~", "*", "'" are allowed (in unescaped format) in the URL syntax while not in the URN syntax. 2. The URL syntax document makes a claim that the its syntax is the syntax for URIs in general so that URNs may be used in any data field that might otherwise hold a URL. I'll admit that there are a lot of political issues that I am ignoring for now, but I want to see if we can move forward with the technical issues. My current thoughts are to move the characters in note 1 above from the excluded character set to the allowed character set to more closely align the URN and URL character sets. IF SOMEONE THINKS THIS IS A BAD IDEA THIS IS A GOOD TIME TO LET ME KNOW! Issue 2 is handled (I believe) by adding an appendix to the URN syntax document that covers how a URL resolver should react to a URN. My proposal is that the URN be considered an opaque URL that gets handed off to a URN resolver. There are alternate solutions, but they become progressively more ugly. Note that issues 1 and 2 are somewhat independent. Given the current allowed characters and the above suggested appendix, any URN could be used in place of a URL. Although I've considered it in the past, I think that defining URN's as a URL "scheme" is a less optimal solution than the above proposals. Obviously, I am soliciting input to try and gain an idea about consensus (and fairly quickly, too). Ryan --------------5232E4A818-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA23964 for urn-ietf-out; Thu, 9 Jan 1997 13:00:35 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA23959 for ; Thu, 9 Jan 1997 13:00:30 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03878 (mail destined for urn-ietf@services.bunyip.com); Thu, 9 Jan 97 13:00:26 -0500 Received: from magenta.acl.lanl.gov (magenta.acl.lanl.gov [128.165.147.153]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id LAA01187 for ; Thu, 9 Jan 1997 11:00:24 -0700 (MST) From: "Ronald E. Daniel" Received: (rdaniel@localhost) by magenta.acl.lanl.gov (8.7.5/8.6.4) id LAA01285 for urn-ietf@bunyip.com; Thu, 9 Jan 1997 11:00:24 -0700 (MST) Date: Thu, 9 Jan 1997 11:00:24 -0700 (MST) Message-Id: <199701091800.LAA01285@magenta.acl.lanl.gov> To: urn-ietf@bunyip.com Subject: [URN] new HTTP conventions draft Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ronald E. Daniel" Errors-To: owner-urn-ietf@bunyip.com INTERNET DRAFT Ron Daniel draft-ietf-urn-http-conv-01.txt Los Alamos National Laboratory 9 Jan, 1997 Conventions for the Use of HTTP for URN Resolution Status of this Memo =================== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft expires 21 July, 1997. Abstract: ========= The URN-WG was formed to specify persistent, location-independent names for network accessible resources, as well as resolution mechanisms to retrive the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal [1]. That proposal specifies how a client may find a "resolver" for a URN, when the URN does not contain a domain name for that resolver. A resolver is a database that can tell the client where the resource is, can provide information (such as a bibliographic citation) on the resource, or may even be able to provide the resource itself to the client. While the NAPTR draft specifies how to locate a resolver, it does not specify how the client should speak to the resolver. Instead, the NAPTR draft provides a field that can be used to specify the "resolution protocol" the client may use to speak to the resolver. This draft establishes conventions for using HTTP as one such resolution protocol. It specifies how to encode URN resolution requests and responses in HTTP 1.0 (and 1.1) requests and responses. Once a client has used NAPTR records to locate a resolver that speaks the "http" resolution protocol, these are the conventions it must follow. The primary goal of this draft is to define a convention that is simple to implement and will allow existing HTTP servers to easily add support for URN resolution. We expect that the resolution databases that arise will be useful when more sophisticated resolution protocols are developed later. 1.0 Introduction: ================== The NAPTR draft[1] describes a way of using DNS to locate resolvers for URIs. That draft provides the services field to specify the "resolution protocol" spoken by the resolver, as well as the "resolution services" it offers. As of this writing, the "resolution protocols" allowed by the NAPTR draft are HTTP, RCDS, HDL, and RWHOIS. (That list is expected to grow over time). The NAPTR draft also lists a variety of resolution services, such as N2L (given a URN, return a URL); N2R (Given a URN, return the named resource), etc. This draft specifies the conventions to follow to encode resolution service requests in the HTTP protocol, allowing widely available HTTP daemons to serve as URN resolvers. This is the specification to follow when the services field ina NAPTR record begins with "http". The reader is assumed to be familiar with the HTTP/1.0 [2] and 1.1 [3] specifications. Implementors of this specification should be familiar with CGI scripts for database lookups. 2.0 General Approach: ===================== The general approach used to encode resolution service requests in HTTP is quite simple: GET /uri-res// HTTP/1.0 For example, if we have the URN "urn:cid:foo@huh.com" and want a URL, we would send the request: GET /uri-res/N2L/urn:cid:foo@huh.com HTTP/1.0 Because of the character set limitations on URIs, we might wish to encode the '@' character as its hex equivalent, thus the request would be GET /uri-res/N2L/urn:cid:foo%40huh.com HTTP/1.0 The request could also be encoded as an HTTP 1.1 request. This would look like: GET /uri-res/N2L/urn:cid:foo%40huh.com HTTP/1.1 Host: Handling these requests on the server side is easy to implement in a number of ways. The N2L request could be handled by a CGI script that took the incoming URN, looked it up in a database, and returned the URL as an HTTP redirect. Service requests like N2R or N2C could be set up so that the daemon answered the request by returning files out of N2R/ and N2C/ directories, or they could also be handled by a script that accessed a database of information. One caveat should be kept in mind. The URN syntax draft[4] discusses the notion of lexical equivalance. This means that two URIs are equivalent under certain conditions of case-insensitivity and/or %encoding of characters. Resolvers MUST return identical results for all lexically equivalent encodings of a URI. For example, the requests below must return identical results: GET /uri-res/N2L/urn:cid:foo@huh.com HTTP/1.0 GET /uri-res/N2L/URN:CID:foo@huh.com HTTP/1.0 GET /uri-res/N2L/urn:cid:foo%40huh%2ecom HTTP/1.0 Responses from the HTTP server follow standard HTTP practice. Status codes, such as 200 (OK) or 404 (Not Found) shall be returned. The normal rules for determining cachability, negotiating formats, etc. apply. 3.0 Service-specific details: ============================= This section goes through the various resolution services established in the URN services draft[5] and states how to encode each of them, how the results should be returned, and any special status codes that are likely to arise. Unless stated otherwise, the HTTP requests are formed according to the simple convention above, either for HTTP/1.0 or HTTP/1.1. The response is assumed to be an entity with normal headers and body unless stated otherwise. (N2L is the only request that need not return a body). 3.1 N2L (URN to URL): ---------------------- The request is encoded as above. The URL MUST be returned in a Location: header for the convienience of the user in the most common case of wanting the resource. If the lookup is successful, a 30X status line SHOULD be returned. HTTP/1.1 clients should be sent the 303 status code. HTTP/1.0 clients should be sent the 302 (Moved temporarily) status code unless the resolver has particular resons for using 301 (moved permanently) or 304 (not modified) codes. Note that access controls may be applied to this, or any other, resolution service request. Therefore the 401 (unauthorized) and 403 (forbidden) status codes are legal responses. The server may wish to provide a body in the response to explain the reason for refusing access, and/or to provide alternate information about the resource, such as the price it will cost to obtain the resource's URL. 3.2 N2Ls (URN to URLs): ------------------------ The request is encoded as above. The result is a list of 0 or more URLs. The Internet Media Type (aka ContentType) of the result may be negotiated using standard HTTP mechanisms if desired. At a minimum the resolver should support the text/uri-list media type. (See Appendix A for the definition of this media type). That media type is suitable for machine-processing of the list of URLs. Resolvers may also return the results as text/html, text/plain, or any other media type they deem suitable. No matter what the particular media type, the result MUST be a list of the URLs which may be used to obtain an instance of the resource identified by the URN. All URIs shall be encoded according to the URI specification [6]. If the client has requested the result be returned as text/html or application/html, the result should be encoded as: where the strings ...url n... are replaced by the n'th URL in the list. 3.3 N2R (URN to Resource): --------------------------- The request is encoded as above. The resource is returned using standard HTTP mechanisms. The request may be modified using the Accept: header as in normal HTTP to specify that the result be given in a preferred Internet Media Type. 3.4 N2Rs (URN to Resources): ----------------------------- This resolution service returns multiple instances of a resource, for example, GIF and JPEG versions of an image. The judgment about the resources being "the same" resides with the naming authority that issued the URN. The request is encoded as above. The result shall be a MIME multipart/alternative message with the alternative versions of the resource in seperate body parts. If there is only one version of the resource identified by the URN, it MAY be returned without the multipart/alternative wrapper. Resolver software SHOULD look at the Accept: header, if any, and only return versions of the resource that are acceptable according to that header. 3.5 N2C (URN to URC): ---------------------- URCs (Uniform Resource Characteristics) are descriptions of other resources. This request allows us to obtain a description of the resource identified by a URN, as opposed to the resource itself. The description might be a bibliographic citation, a digital signature, a revision history, etc. This draft does not specify the content of any response to a URC request. That content is expected to vary from one resolver to another. The format of any response to a N2C request MUST be communicated using the ContentType header, as is standard HTTP practice. The Accept: header SHOULD be honored. 3.6 N2Ns (URN to URNs): ------------------------ While URNs are supposed to identify one and only one resource, that does not mean that a resource may have one and only one URN. For example, consider a resource that has something like "current-weather-map" for one URN and "weather-map-for-datetime-x" for another URN. The N2Ns service request lets us obtain lists of URNs that are believed equivalent at the time of the request. As the weathermap example shows, some of the equivalances will be transitory, so the standard HTTP mechanisms for communicating cachability MUST be honored. The request is encoded as above. The result is a list of all the URNs, known to the resolver, which identify the same resource as the input URN. The result shall be encoded as for the N2Ls request above (text/uri-list unless specified otherwise by an Accept: header). 3.7 L2Ns (URL to URNs): ---------------------- The request is encoded as above. The response is a list of any URNs known to be assigned to the resource at the given URL. The result shall be encoded as for the N2Ls and N2Ns requests. 3.8 L2Ls (URL to URLs): ------------------------ The request is encoded as described above. The result is a list of all the URLs that the resolver knows are associated with the resource located by the given URL. This is encoded as for the N2Ls, N2Ns, and L2Ns requests. 3.9 L2C (URL to URC): ---------------------- The request is encoded as above, the response is the same as for the N2C request. Appendix A: The text/uri-list Internet Media Type ================================================= [This appendix will be augmented or replaced by the registration of the text/uri-list IMT once that registration has been performed]. Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns, L2Ls, result in a list of URIs being returned to the client. The text/uri-list Internet Media Type is defined to provide a simple format for the automatic processing of such lists of URIs. The format of text/uri-list resources is: 1) Any lines beginning with the '#' character are comment lines and are ignored during processing. (Note that '#' is a character that may appear in URIs, so it only denotes a comment when it is the first character on a line). 2) The remaining non-comment lines MUST be URIs (URNs or URLs), encoded according to the URI specification RFC[6]. Each URI shall appear on one and only one line. 3) As for all text/* formats, lines are terminated with a CR LF pair. In applications where one URI has been mapped to a list of URIs, such as in response to the N2Ls request, the first line of the text/uri-list response SHOULD be a comment giving the original URI. An example of such a result for the N2L request is shown below in figure 1. # urn:cid:foo@huh.org http://www.huh.org/cid/foo.html http://www.huh.org/cid/foo.pdf ftp://ftp.foo.org/cid/foo.txt Figure 1: Example of the text/uri-list format Appendix B: n2l.pl script ========================== This is a simple CGI script for the N2L resolution service. It assumes the presence of a DBM database to store the URN to URL mappings. This script does not specify standard behavior, it is provided merely as a courtesy for implementors. In fact, this script does not process incoming Accept: headers, nor does it generate status codes. Such behavior should be part of a real script for any of the resolution services. #!/bin/perl # N2L - performs urn to url resolution $n2l_File = "...filename for DBM database..."; $urn = $ENV{'PATH_INFO'} ; if(length($urn)<3) { $error=1; } if(!$error) { $urn =~s/^(\/)(urn:)?(.*)/$3/i; # Additional operations should be performed here # to convert lexically equivalent versions of a URI into # a canonical version for DB lookups. dbmopen(%lu,$n2l_File,0444); if($lu{$urn}) { $url=$lu{$urn}; print STDOUT "Location: $url\n\n"; }else{ $error=2; } dbmclose(%lu); } if($error) { print "Content-Type: text/html \n\n"; print "\n"; print "URN Resolution: N2L\n"; print "\n"; print "

URN to URL resolution failed for the URN:

\n"; print "

$urn

\n"; print "\n"; print "\n"; } exit; References: =========== [1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", draft-ietf-urn-naptr-01.txt, November, 1996. [2] RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-Lee, R. Fielding, H. Frystyk, May 1996. [3] R. Fielding, J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", draft-ietf-http-v11-spec-06, July 1996. [4] R. Moats, "URN Syntax", draft-ietf-urn-syntax-02, Jan. 1997. [5] URN Resolution Services Draft - (That document is in preparation. It will actually be strongly based on the content of this document and the NAPTR draft[1]). [6] RFC 1630, "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", T. Berners-Lee, June 1994. Security Considerations ======================= Communications with a resolver may be of a sensitive nature. Some resolvers will hold information that should only be released to authorized users. The results from resolvers may be the target of spoofing, especially once electronic commerce transactions are common and there is money to be made by directing users to pirate repositories rather than repositories which pay royalties to rightsholders. Resolution requests may be of interest to traffic analysts. The requests may also be subject to spoofing. The requests and responses in this draft are amenable to encoding, signing, and authentication in the manner of any other HTTP traffic. Author Contact Information: =========================== Ron Daniel Advanced Computing Lab, MS B287 Los Alamos National Laboratory Los Alamos, NM, USA, 87545 voice: +1 505 665 0597 fax: +1 505 665 4939 email: rdaniel@lanl.gov This draft expires 21 July, 1997. Ron Daniel Jr. email: rdaniel@acl.lanl.gov Advanced Computing Lab, MS B287 voice: (505) 665-0597 Los Alamos National Laboratory fax: (505) 665-4939 Los Alamos, NM, USA 87545 http://www.acl.lanl.gov/~rdaniel/ Want to buy: "The Five Laws of Library Science" by S.R. Ranganathan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA23896 for urn-ietf-out; Thu, 9 Jan 1997 12:53:02 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA23887 for ; Thu, 9 Jan 1997 12:52:53 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03819 (mail destined for urn-ietf@services.bunyip.com); Thu, 9 Jan 97 12:52:20 -0500 Received: from magenta.acl.lanl.gov (magenta.acl.lanl.gov [128.165.147.153]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id KAA01066 for ; Thu, 9 Jan 1997 10:52:13 -0700 (MST) From: "Ronald E. Daniel" Received: (rdaniel@localhost) by magenta.acl.lanl.gov (8.7.5/8.6.4) id KAA01261 for urn-ietf@bunyip.com; Thu, 9 Jan 1997 10:52:13 -0700 (MST) Date: Thu, 9 Jan 1997 10:52:13 -0700 (MST) Message-Id: <199701091752.KAA01261@magenta.acl.lanl.gov> To: urn-ietf@bunyip.com Subject: [URN] next version of NAPTR Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ronald E. Daniel" Errors-To: owner-urn-ietf@bunyip.com Hi all, Hope you had a happy holiday season. Now that I'm back at work, I've edited the NAPTR and HTTP conventions drafts. The NAPTR draft is appended, I'll send the HTTP conventions draft in a seperate message. The new versions are also available from: http://www.acl.lanl.gov/URN/naptr.txt http://www.acl.lanl.gov/URN/http_res.txt Old versions are available from http://www.acl.lanl.gov/URN/naptr-03.txt http://www.acl.lanl.gov/URN/http_res-00.txt in case you care. Some of the references need to be cleaned up - both drafts refer to the URN Resolution Services draft we decided needed to be written. Also, the NAPTR draft has a couple of other citations I have some questions about. Other than that I think these are complete. Your comments please! Regards, Ron =================== INTERNET DRAFT Ron Daniel draft-ietf-urn-naptr-02.txt Los Alamos National Laboratory Michael Mealling Network Solutions, Inc. 08 Jan., 1996 Resolution of Uniform Resource Identifiers using the Domain Name System Status of this Memo =================== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft expires 14 July, 1997. Abstract: ========= Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. In addition to locating resolvers, the NAPTR provides for other naming systems to be grandfathered into the URN world, provides independence between the name assignment system and the resolution protocol system, and allows multiple services (Name to Location, Name to Description, Name to Resource, ...) to be offered. In conjunction with the SRV RR, the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing. Introduction: ============= Uniform Resource Locators have been a significant advance in locating resources on the Internet. 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 to serve as persistent, location-independent identifiers for Internet resources in order to overcome most of the problems with URLs. RFC-1737 [1] 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 URLs, which identify the host to contact and the protocol to use. Readers are referred to [2] 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 DNS to locate "resolvers" that can provide information on individual resources, potentially including the resource itself. To accomplish this, we "rewrite" the URI into a domain name following the rules provided in NAPTR records. Rewrite rules provide considerable power, which is important when trying to meet the goals listed above. However, collections of rules can become difficult to understand. To lessen this problem, the NAPTR rules are *always* applied to the original URI, *never* to the output of previous rules. Locating a resolver through the rewrite procedure may take multiple steps, but the beginning is always the same. Every URI has a colon-delimited prefix. NAPTR resolution begins by taking this prefix, appending the well-known suffix ".urn.net", and querying the DNS for NAPTR records at that domain name. Based on the results of this query, zero or more additional DNS queries may be needed to locate resolvers for the URI. The details of the conversation between the client and the resolver thus located are outside the bounds of this draft. Three brief examples of this procedure are given in the next section. The NAPTR RR provides the level of indirection needed to keep the naming system independent of the resolution system, its protocols, and services. Coupled with the new SRV resource record proposal[3] there is also the potential for replicating the resolver on multiple hosts, overcoming some of the most significant problems of URLs. This is an important and subtle point. Not only do the NAPTR and SRV records allow us to replicate the resource, we can replicate the resolvers that know about the replicated resource. Preventing a single point of failure at the resolver level is a significant benefit. Separating the resolution procedure from the way names are constructed has additional benefits. Different resolution procedures can be used over time, and resolution procedures that are determined to be useful can be extended to deal with additional namespaces. Caveats ======= The NAPTR proposal is the first resolution procedure to be considered by the URN-WG. There are several concerns about the proposal which have motivated the group to recommend it for publication as an Experimental rather than a standards-track RFC. First, URN resolution is new to the IETF and we wish to gain operational experience before recommending any procedure for the standards track. Second, the NAPTR proposal is based on DNS and consequently inherits concerns about security and administration. The recent advancement of the DNSSEC and secure update drafts to Proposed Standard reduce these concerns, but we wish to experiment with those new capabilities in the context of URN administration. A third area of concern is the potential for a noticeable impact on the DNS. We believe that the proposal makes appropriate use of caching and additional information, but it is best to go slow where the potential for impact on a core system like the DNS is concerned. Fourth, the rewrite rules in the NAPTR proposal are based on regular expressions. Since regular expressions are difficult for humans to construct correctly, concerns exist about the usability and maintainability of the rules. This is especially true where international character sets are concerned. Terminology =========== "Must" or "Shall" - Software that does not behave in the manner that this document says it must is not conformant to this document. "Should" - Software that does not follow the behavior that this document says it should may still be conformant, but is probably broken in some fundamental way. "May" - Implementations may or may not provide the described behavior, while still remaining conformant to this document. Brief overview and examples of the NAPTR RR: ============================================ A detailed description of the NAPTR RR will be given later, but to give a flavor for the proposal we first give a simple description of the record and three examples of its use. The key fields in the NAPTR RR are order, preference, service, flags, regexp, and replacement: * The order field specifies the order in which records MUST be processed when multiple NAPTR records are returned in response to a single query. A naming authority may have delegated a portion of its namespace to another agency. Evaluating the NAPTR records in the correct order is necessary for delegation to work properly. * The preference field specifies the order in which records SHOULD be processed when multiple NAPTR records have the same value of "order". This field lets a service provider specify the order in which resolvers are contacted, so that more capable machines are contacted in preference to less capable ones. * The service field specifies the resolution protocol and resolution service(s) that will be available if the rewrite specified by the regexp or replacement fields is applied. Resolution protocols are the protocols used to talk with a resolver. They will be specified in other documents, such as [4]. Resolution services are operations such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC), etc. These will be discussed in the URN Resolution Services document[5], and their behavior in a particular resolution protocol will be given in the specification for that protocol (see [4] for a concrete example). * The flags field contains modifiers that affect what happens in the next DNS lookup, typically for optimizing the process. Flags may also affect the interpretation of the other fields in the record, therefore, clients MUST skip NAPTR records which contain an unknown flag value. * The regexp field is one of two fields used for the rewrite rules, and is the core concept of the NAPTR record. The regexp field is a String containing a sed-like substitution expression. (The actual grammar for the substitution expressions is given later in this draft). The substitution expression is applied to the original URN to determine the next domain name to be queried. The regexp field should be used when the domain name to be generated is conditional on information in the URI. If the next domain name is always known, which is anticipated to be a common occurrence, the replacement field should be used instead. * The replacement field is the other field that may be used for the rewrite rule. It is an optimization of the rewrite process for the case where the next domain name is fixed instead of being conditional on the content of the URI. The replacement field is a domain name (subject to compression if a DNS sender knows that a given recipient is able to decompress names in this RR type's RDATA field). If the rewrite is more complex than a simple substitution of a domain name, the replacement field should be set to . and the regexp field used. Note that the client applies all the substitutions and performs all lookups, they are not performed in the DNS servers. Note also that it is the belief of the developers of this document that regexps should rarely be used. The replacement field seems adequate for the vast majority of situations. Regexps are only necessary when portions of a namespace are to be delegated to different resolvers. Finally, note that the regexp and replacement fields are, at present, mutually exclusive. However, developers of client software should be aware that a new flag might be defined which requires values in both fields. Example 1 --------- Consider a URN that uses the hypothetical DUNS namespace. DUNS numbers are identifiers for approximately 30 million registered businesses around the world, assigned and maintained by Dunn and Bradstreet. The URN might look like: urn:duns:002372413:annual-report-1997 The first step in the resolution process is to find out about the DUNS namespace. The namespace identifier, duns, is extracted from the URN, prepended to urn.net, and the NAPTRs for duns.urn.net looked up. It might return records of the form: duns.urn.net ;; order pref flags service regexp replacement IN NAPTR 100 10 "s" "dunslink+N2L+N2C" "" dunslink.udp.isi.dandb.com IN NAPTR 100 20 "s" "rcds+N2C" "" rcds.udp.isi.dandb.com IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" "" http.tcp.isi.dandb.com The order field contains equal values, indicating that no name delegation order has to be followed. The preference field indicates that the provider would like clients to use the special dunslink protocol, followed by the RCDS protocol, and that HTTP is offered as a last resort. All the records specify the "s" flag, which will be explained momentarily. The service fields say that if we speak dunslink, we will be able to issue either the N2L or N2C requests to obtain a URL or a URC (description) of the resource. The Resource Cataloging and Distribution Service (RCDS)[6] could be used to get a URC for the resource, while HTTP could be used to get a URL, URC, or the resource itself. All the records supply the next domain name to query, none of them need to be rewritten with the aid of regular expressions. The general case might require multiple NAPTR rewrites to locate a resolver, but eventually we will come to the "terminal NAPTR". Once we have the terminal NAPTR, our next probe into the DNS will be for a SRV or A record instead of another NAPTR. Rather than probing for a non-existent NAPTR record to terminate the loop, the flags field is used to indicate a terminal lookup. If it has a value of "s", the next lookup should be for SRV RRs, "a" denotes that A records should sought. A "p" flag is also provided to indicate that the next action is Protocol-specific, but that looking up another NAPTR will not be part of it. Since our example RR specified the "s" flag, it was terminal. Assuming our client does not know the dunslink protocol, our next action is to lookup SRV RRs for rcds.udp.isi.dandb.com, which will tell us hosts that can provide the necessary resolution service. That lookup might return: ;; Pref Weight Port Target rcds.udp.isi.dandb.com IN SRV 0 0 1000 defduns.isi.dandb.com IN SRV 0 0 1000 dbmirror.com.au IN SRV 0 0 1000 ukmirror.com.uk telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their RCDS server. (The reader is referred to the SRV proposal [3] for the interpretation of the fields above). There is opportunity for significant optimization here. We can return the SRV records as additional information for terminal NAPTRs (and the A records as additional information for those SRVs). While this recursive provision of additional information is not explicitly blessed in the DNS specifications, it is not forbidden, and BIND does take advantage of it [7]. This is a significant optimization. In conjunction with a long TTL for *.urn.net records, the average number of probes to DNS for resolving DUNS URNs would approach one. Therefore, DNS server implementors SHOULD provide additional information with NAPTR responses. The additional information will be either SRV or A records. If SRV records are available, their A records should be provided as recursive additional information. Note that the example NAPTR records above are intended to represent the reply the client will see. They are not quite identical to what the domain administrator would put into the zone files. For one thing, the administrator should supply the trailing '.' character on replacement domain names. An additional difference will be illustrated later. Example 2 --------- Consider a URN namespace based on MIME Content-Ids. The URN might look like this: urn:cid:199606121851.1@mordred.gatech.edu The first step in the resolution process is to find out about the CID namespace. The namespace identifier, cid, is extracted from the URN, prepended to urn.net, and the NAPTR for cid.urn.net looked up. It might return records of the form: cid.urn.net ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "/urn:cid:.+@([^@]+)$/\1/i" . We have only one NAPTR response, so ordering the responses is not a problem. The replacement field is empty, so we check the regexp field and use the pattern provided there. We apply that regexp to the entire URN to see if it matches, which it does. The \1 part of the substitution expression returns the string "mordred.gatech.edu". Since the flags field does not contain "s" or "a", the lookup is not terminal and our next probe to DNS is for more NAPTR records: lookup(query=NAPTR, "mordred.gatech.edu"). While mordred could have its very own NAPTR, maintaining those records on all the machines at a site as large as Georgia Tech would be an intolerable burden. Instead, a wildcard may be used so that the domain administrator at Georgia Tech has only a single NAPTR record to maintain. That record might look like: *.gatech.edu IN NAPTR ;; order pref flags service regexp replacement IN NAPTR 100 50 "s" "z3950+N2L+N2C" "" z3950.tcp.gatech.edu. IN NAPTR 100 50 "s" "rcds+N2C" "" rcds.udp.gatech.edu. IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" http.tcp.gatech.edu. (Unlike all the other example records in this draft, the one above is the contents of a zone file, not the response received by the client. That is so that the wildcard can be seen.) Continuing with our example, we note that the values of the order and preference fields are equal in all records, so the client is free to pick any record. The flags field tells us that these are the last NAPTR patterns we should see, and after the rewrite (a simple replacement in this case) we should look up SRV records to get information on the hosts that can provide the necessary service. Assuming we prefer the Z39.50 protocol, our lookup might return: ;; Pref Weight Port Target z3950.tcp.gatech.edu IN SRV 0 0 1000 z3950.gatech.edu IN SRV 0 0 1000 z3950.cc.gatech.edu IN SRV 0 0 1000 z3950.uga.edu telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their Z39.50 server. Recall that the regular expression used \1 to extract a domain name from the CID. There is a significant caveat about the use of backslashes in DNS zone files. DNS treats backslashes as the escape character so that '.' can be escaped when necessary. This means that when a regular expression is entered into the zone file, the backslashes must be escaped by another backslash. For the case of the cid.urn.net record above, the regular expression entered into the zone file should be "/.+@([^@]+)/\\1/i". When the client code actually receives the record, the pattern will have been converted to "/.+@([^@]+)/\1/i". Example 3 --------- Even if URN systems were in place now, there would still be a tremendous number of URLs. It should be possible to develop a URN resolution system that can also provide location independence for those URLs. This is related to the requirement in [1] to be able to grandfather in names from other naming systems, such as ISO Formal Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, etc. The NAPTR RR could also be used for URLs that have already been assigned. Assume we have the URL for a very popular piece of software that the publisher wishes to mirror at multiple sites around the world: http://www.foo.com/software/latest-beta.exe We extract the prefix, "http", and lookup NAPTR records for http.urn.net. This might return a record of the form http.urn.net IN NAPTR ;; order pref flags service regexp replacement 100 90 "" "" "!http://([^/:]+)!\1!i" . This expression returns everything after the first double slash and before the next slash or colon. (We use the '!' character to delimit the parts of the substitution expression. Otherwise we would have to use backslashes to escape the forward slashes, and would have a regexp in the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".). Applying this pattern to the URL extracts "www.foo.com". Looking up NAPTR records for that might return: www.foo.com ;; order pref flags service regexp replacement IN NAPTR 100 100 "s" "http+L2R" "" http.tcp.foo.com IN NAPTR 100 100 "s" "ftp+L2R" "" ftp.tcp.foo.com Looking up SRV records for http.tcp.foo.com would return information on the hosts that foo.com has designated to be its mirror sites. The client can then pick one for the user. NAPTR RR Format =============== The format of the NAPTR RR is given below. The DNS type code for NAPTR is 104 [this is being changed, we believe it will be assigned 35]. Domain TTL Class Order Preference Flags Service Regexp Replacement where: Domain The domain name this resource record refers to. TTL Standard DNS Time To Live field Class Standard DNS meaning Order A 16-bit integer specifying the order in which the NAPTR records MUST be processed to ensure correct delegation of portions of the namespace over time. Low numbers are processed before high numbers, and once a NAPTR is found that "matches" a URN, the client MUST NOT consider any NAPTRs with a higher value for order. Preference A 16-bit integer which specifies the order in which NAPTR records with equal "order" values SHOULD be processed, low numbers being processed before high numbers. This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. Flags A String giving flags to control aspects of the rewriting and interpretation of the fields in the record. Flags are single characters from the set [A-Z0-9]. The case of the alphabetic characters is not significant. At this time only three flags, "S", "A", and "P", are defined. "S" means that the next lookup should be for SRV records instead of NAPTR records. "A" means that the next lookup should be for A records. The "P" flag says that the remainder of the resolution shall be carried out in a Protocol-specific fashion, and we should not do any more DNS queries. The remaining alphabetic flags are reserved. The numeric flags may be used for local experimentation. The S, A, and P flags are all mutually exclusive, and resolution libraries MAY signal an error if more than one is given. (Experimental code and code for assisting in the creation of NAPTRs would be more likely to signal such an error than a client such as a browser). We anticipate that multiple flags will be allowed in the future, so implementers MUST NOT assume that the flags field can only contain 0 or 1 characters. Finally, if a client encounters a record with an unknown flag, it MUST ignore it and move to the next record. This test takes precedence even over the "order" field. Since flags can control the interpretation placed on fields, a novel flag might change the interpretation of the regexp and/or replacement fields such that it is impossible to determine if a record matched a URN. Service Specifies the resolution service(s) available down this rewrite path. It may also specify the particular protocol that is used to talk with a resolver. A protocol MUST be specified if the flags field states that the NAPTR is terminal. If a protocol is specified, but the flags field does not state that the NAPTR is terminal, the next lookup MUST be for a NAPTR. The client MAY choose not to perform the next lookup if the protocol is unknown, but that behavior MUST NOT be relied upon. The service field may take any of the values below (using the Augmented BNF of RFC 822[8]): service_field = [ [protocol] *("+" rs)] protocol = "rcds" / "http" / "hdl" / "rwhois" rs = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C" / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C" i.e. an optional protocol specification followed by 0 or more resolution services. Each resolution service is indicated by an initial '+' character. Note that the empty string is also a valid service field. This will typically be seen at the top levels of a namespace, when it is impossible to know what services and protocols will be offered by a particular publisher within that name space. At this time the known protocols are rcds[6], hdl[9] (binary, UDP-based protocols), http[4] (a textual, TCP-based protocol), and rwhois[10] (textual, UDP or TCP based). More will be allowed later. The names of the protocols must be formed from the characters [a-Z0-9]. Case of the characters is not significant. The service requests currently allowed will be described in more detail in [5], but in brief they are: N2L - Given a URN, return a URL N2Ls - Given a URN, return a set of URLs N2R - Given a URN, return an instance of the resource. N2Rs - Given a URN, return multiple instances of the resouce, typically encoded using multipart/alternative. N2C - Given a URN, return a collection of meta-information on the named resource. The format of this response is the subject of another document. N2Ns - Given a URN, return all URNs that are also identifers for the resource. L2R - Given a URL, return the resource. L2Ns - Given a URL, return all the URNs that are identifiers for the resource. L2Ls - Given a URL, return all the URLs for instances of of the same resource. L2C - Given a URL, return a description of the resource. The actual format of the service request and response will be determined by the resolution protocol, and is the subject for other documents (e.g. [4]). Protocols need not offer all services. The labels for service requests shall be formed from the set of characters [A-Z0-9]. The case of the alphabetic characters is not significant. Regexp A STRING containing a substitution expression that is applied to the original URI in order to construct the next name to lookup. The grammar of the substitution expression is given in the next section. Replacement The next NAME to query for NAPTR, SRV, or A records depending on the value of the flags field. As mentioned above, this may be compressed. Substitution Expression Grammar: ================================ The content of the regexp field is a substitution expression. True sed(1) substitution expressions are not appropriate for use in this application for a variety of reasons, therefore the contents of the regexp field MUST follow the grammar below: subst_expr = delim-char ere delim-char repl delim-char *flags delim-char = "/" / "!" / ... (Any non-digit or non-flag character other than backslash '\'. All occurances of a delim_char in a subst_expr must be the same character.) ere = POSIX Extended Regular Expression (see [11], section 2.8.4) repl = dns_str / backref / repl dns_str / repl backref dns_str = ...... which RFC can I cite for this? 1035 seems obsolete ..... backref = "\" 1POS_DIGIT flags = "i" DNS_CHAR = "_" / "0" / "1" / ... / "9" / "a" / ... / "z" POS_DIGIT = "1" / "2" / ... / "9" ; 0 is not an allowed backref value The result of applying the substitution expression to the original URI shall be a legal domain name. Since it is possible for the regexp field to be improperly specified, such that a non-conforming domain name can be constructed, client software SHOULD verify that the result is a legal domain name before making queries on it. Backref expressions in the repl portion of the substitution expression are replaced by the (possibly empty) string of characters enclosed by '(' and ')' in the ERE portion of the substitution expression. N is a single digit from 1 through 9, inclusive. It specifies the N'th backref expression, the one that begins with the N'th '(' and continues to the matching ')'. For example, the ERE (A(B(C)DE)(F)G) has backref expressions: \1 = ABCDEFG \2 = BCDE \3 = C \4 = F \5..\9 = error - no matching subexpression The "i" flag indicates that the ERE matching SHALL be performed in a case-insensitive fashion. Furthermore, any backref replacements MAY be normalized to lower case when the "i" flag is given. The first character in the substitution expression shall be used as the character that delimits the components of the substitution expression. There must be exactly three non-escaped occurrences of the delimiter character in a substitution expression. Since escaped occurrences of the delimiter character will be interpreted as occurrences of that character, digits MUST NOT be used as delimiters. Backrefs would be confused with literal digits were this allowed. Similarly, if flags are specified in the substitution expression, the delimiter character must not also be a flag character. Advice to domain administrators: ================================ Beware of regular expressions. Not only are they a pain to get correct on their own, but there is the previously mentioned interaction with DNS. Any backslashes in a regexp must be entered twice in a zone file in order to appear once in a query response. More seriously, the need for double backslashes has probably not been tested by all implementors of DNS servers. We anticipate that urn.net will be the heaviest user of regexps. Only when delegating portions of namespaces should the typical domain administrator need to use regexps. On a related note, beware of interactions with the shell when manipulating regexps from the command line. Since '\' is a common escape character in shells, there is a good chance that when you think you are saying "\\" you are actually saying "\". Similar caveats apply to characters such as '*', '(', etc. The "a" flag allows the next lookup to be for A records rather than SRV records. Since there is no place for a port specification in the NAPTR record, when the "A" flag is used the specified protocol must be running on its default port. The URN-WG is discussing the use of international characters in URNs. Regular expressions for strings in international character sets are likely to be essentially impossible to read or write by hand. Usage ===== For the edification of implementers, pseudocode for a client routine using NAPTRs is given below. This code is provided merely as a convience, it does not have any weight as a standard way to process NAPTR records. Also, as is the case with pseudocode, it has never been executed and may contain logical errors. You have been warned. // // findResolver(URN) // Given a URN, find a host that can resolve it. // findResolver(string URN) { sprintf(key, "%s.urn.net", extractNS(URN)); // prepend prefix to urn.net do { rewrite_flag = false; terminal = false; if (key has been seen) { quit with a loop detected error } add key to list of "seens" records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key' sort NAPTR records by "order" field and "preference" field (with "order" being more significant than "preference"). n_naptrs = number of NAPTR records in response. curr_order = records[0].order; max_order = records[n_naptrs-1].order; // Process current batch of NAPTRs according to "order" field. for (j=0; j < n_naptrs && records[j].order <= max_order; j++) { if (unknown-flag) // skip this record and go to next one continue; newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp); if (!newkey) // Skip to next record if the rewrite didn't match continue; // We did do a rewrite, shrink max_order to current value // so that delegation works properly max_order = naptr[j].order; // Will we know what to do with the protocol and services // specified in the NAPTR? If not, try next record. if(!isKnownProto(naptr[j].services)) { continue; } if(!isKnownService(naptr[j].services)) { continue; } // At this point we have a successful rewrite and we will know // how to speak the protocol and request a known resolution // service. Before we do the next lookup, check some // optimization possibilities. if (strcasecmp(flags, "S") || strcasecmp(flags, "P")) || strcasecmp(flags, "A")) { terminal = true; services = naptr[j].services; addnl = any SRV and/or A records returned as additional info for naptr[j]. } key = newkey; rewriteflag = true; break; } } while (rewriteflag && !terminal); // Did we not find our way to a resolver? if (!rewrite_flag) { report an error return NULL; } // Leave rest to another protocol? if (strcasecmp(flags, "P")) { return key as host to talk to; } // If not, keep plugging if (!addnl) { // No SRVs came in as additional info, look them up srvs = lookup(type=SRV, key); } sort SRV records by preference, weight, ... foreach (SRV record) { // in order of preference try contacting srv[j].target using the protocol and one of the resolution service requests from the "services" field of the last NAPTR record. if (successful) return (target, protocol, service); // Actually we would probably return a result, but this // code was supposed to just tell us a good host to talk to. } die with an "unable to find a host" error; } Notes: ====== - A client MUST process multiple NAPTR records in the order specified by the "order" field, it MUST NOT simply use the first record that provides a known protocol and service combination. - If a record at a particular order matches the URI, but the client doesn't know the specified protocol and service, the client SHOULD continue to examine records that have the same order. The client MUST NOT consider records with a higher value of order. This is necessary to make delegation of portions of the namespace work. The order field is what lets site administrators say "all requests for URIs matching pattern x go to server 1, all others go to server 2". (A match is defined as: 1) The NAPTR provides a replacement domain name or 2) The regular expression matches the URN ) - When multiple RRs have the same "order", the client should use the value of the preference field to select the next NAPTR to consider. However, because of preferred protocols or services, estimates of network distance and bandwidth, etc. clients may use different criteria to sort the records. - If the lookup after a rewrite fails, clients are strongly encouraged to report a failure, rather than backing up to pursue other rewrite paths. - When a namespace is to be delegated among a set of resolvers, regexps must be used. Each regexp appears in a separate NAPTR RR. Administrators should do as little delegation as possible, because of limitations on the size of DNS responses. - Note that SRV RRs impose additional requirements on clients. Acknowledgments: ================= The authors would like to thank Keith Moore for all his consultations during the development of this draft. We would also like to thank Paul Vixie for his assistance in debugging our implementation, and his answers on our questions. References: =========== [1] RFC-1737, "Functional Requirements for Uniform Resource Names", Karen Sollins and Larry Masinter, Dec. 1994. [2] Urn implementors article in DLIB? Perhaps [2] draft-daigle-urn-framework-00.txt "A Uniform Resource Naming Framework", Leslie Daigle and Patrik Faltstrom, June, 1996. [3] RFC 2052, "A DNS RR for specifying the location of services (DNS SRV)", A. Gulbrandsen and P. Vixie, October 1996. [4] RFC-xxxx, "Conventions for the Use of HTTP for Resolution of URNs", Ron Daniel Jr., currently available as draft-ietf-urn-http-conv-01.txt, Dec. 1996. [5] RFC-xxxx, "URN Resolution Services", ???, draft-ietf-urn-??? (This document is on the URN-WG's list of documents to prepare, but has not yet been written. It will get its start from the treatment of resolution services in [4]). [6] Keith Moore, "Resource Cataloging and Distribution Service", ??? [7] Paul Vixie, personal communication. [8] RFC-822, "Standard for the Format of ARPA Internet Text Messages", Dave H. Crocker, August 1982. [9] Charles Orth, Bill Arms; Handle Resolution Protocol Specification, http://www.handle.net/docs/client_spec.html [10] RFC-1714, "Referral Whois Protocol (RWhois)", S. Williamson and M. Kosters, November 1994. [11] IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1); IEEE Std 1003.2-1992; The Institute of Electrical and Electronics Engineers; New York; 1993. ISBN:1-55937-255-9 Security Considerations ======================= The use of "urn.net" as the registry for URN namespaces is subject to denial of service attacks, as well as other DNS spoofing attacks. The interactions with DNSSEC are currently being studied. It is expected that NAPTR records will be signed with SIG records once the DNSSEC work is deployed. The rewrite rules make identifiers from other namespaces subject to the same attacks as normal domain names. Since they have not been easily resolvable before, this may or may not be considered a problem. Regular expressions should be checked for sanity, not blindly passed to something like PERL. Author Contact Information: =========================== Ron Daniel Los Alamos National Laboratory MS B287 Los Alamos, NM, USA, 87545 voice: +1 505 665 0597 fax: +1 505 665 4939 email: rdaniel@lanl.gov Michael Mealling Network Solutions 505 Huntmar Park Drive Herndon, VA 22070 voice: (703) 742-0400 fax: (703) 742-9552 email: michaelm@internic.net URL: http://www.netsol.com/ This draft expires 14 July, 1997. Ron Daniel Jr. email: rdaniel@acl.lanl.gov Advanced Computing Lab, MS B287 voice: (505) 665-0597 Los Alamos National Laboratory fax: (505) 665-4939 Los Alamos, NM, USA 87545 http://www.acl.lanl.gov/~rdaniel/ Want to buy: "The Five Laws of Library Science" by S.R. Ranganathan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA23579 for urn-ietf-out; Thu, 9 Jan 1997 12:27:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA23574 for ; Thu, 9 Jan 1997 12:27:52 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03667 (mail destined for urn-ietf@services.bunyip.com); Thu, 9 Jan 97 12:27:18 -0500 Received: from magenta.acl.lanl.gov (magenta.acl.lanl.gov [128.165.147.153]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id KAA00789 for ; Thu, 9 Jan 1997 10:26:56 -0700 (MST) From: "Ronald E. Daniel" Received: (rdaniel@localhost) by magenta.acl.lanl.gov (8.7.5/8.6.4) id KAA01201 for urn-ietf@bunyip.com; Thu, 9 Jan 1997 10:26:55 -0700 (MST) Date: Thu, 9 Jan 1997 10:26:55 -0700 (MST) Message-Id: <199701091726.KAA01201@magenta.acl.lanl.gov> To: urn-ietf@bunyip.com Subject: [URN] http conventions draft version 01 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ronald E. Daniel" Errors-To: owner-urn-ietf@bunyip.com Hi, I've made an editing pass through the HTTP conventions draft. The new version (01) is appended. Also, you can fetch it from http://www.acl.lanl.gov/URN/http_res.txt Regards, Ron ================================= INTERNET DRAFT Ron Daniel draft-ietf-urn-http-conv-01.txt Los Alamos National Laboratory 9 Jan, 1997 Conventions for the Use of HTTP for URN Resolution Status of this Memo =================== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft expires 21 July, 1997. Abstract: ========= The URN-WG was formed to specify persistent, location-independent names for network accessible resources, as well as resolution mechanisms to retrive the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal [1]. That proposal specifies how a client may find a "resolver" for a URN, when the URN does not contain a domain name for that resolver. A resolver is a database that can tell the client where the resource is, can provide information (such as a bibliographic citation) on the resource, or may even be able to provide the resource itself to the client. While the NAPTR draft specifies how to locate a resolver, it does not specify how the client should speak to the resolver. Instead, the NAPTR draft provides a field that can be used to specify the "resolution protocol" the client may use to speak to the resolver. This draft establishes conventions for using HTTP as one such resolution protocol. It specifies how to encode URN resolution requests and responses in HTTP 1.0 (and 1.1) requests and responses. Once a client has used NAPTR records to locate a resolver that speaks the "http" resolution protocol, these are the conventions it must follow. The primary goal of this draft is to define a convention that is simple to implement and will allow existing HTTP servers to easily add support for URN resolution. We expect that the resolution databases that arise will be useful when more sophisticated resolution protocols are developed later. 1.0 Introduction: ================== The NAPTR draft[1] describes a way of using DNS to locate resolvers for URIs. That draft provides the services field to specify the "resolution protocol" spoken by the resolver, as well as the "resolution services" it offers. As of this writing, the "resolution protocols" allowed by the NAPTR draft are HTTP, RCDS, HDL, and RWHOIS. (That list is expected to grow over time). The NAPTR draft also lists a variety of resolution services, such as N2L (given a URN, return a URL); N2R (Given a URN, return the named resource), etc. This draft specifies the conventions to follow to encode resolution service requests in the HTTP protocol, allowing widely available HTTP daemons to serve as URN resolvers. This is the specification to follow when the services field ina NAPTR record begins with "http". The reader is assumed to be familiar with the HTTP/1.0 [2] and 1.1 [3] specifications. Implementors of this specification should be familiar with CGI scripts for database lookups. 2.0 General Approach: ===================== The general approach used to encode resolution service requests in HTTP is quite simple: GET /uri-res// HTTP/1.0 For example, if we have the URN "urn:cid:foo@huh.com" and want a URL, we would send the request: GET /uri-res/N2L/urn:cid:foo@huh.com HTTP/1.0 Because of the character set limitations on URIs, we might wish to encode the '@' character as its hex equivalent, thus the request would be GET /uri-res/N2L/urn:cid:foo%40huh.com HTTP/1.0 The request could also be encoded as an HTTP 1.1 request. This would look like: GET /uri-res/N2L/urn:cid:foo%40huh.com HTTP/1.1 Host: Handling these requests on the server side is easy to implement in a number of ways. The N2L request could be handled by a CGI script that took the incoming URN, looked it up in a database, and returned the URL as an HTTP redirect. Service requests like N2R or N2C could be set up so that the daemon answered the request by returning files out of N2R/ and N2C/ directories, or they could also be handled by a script that accessed a database of information. One caveat should be kept in mind. The URN syntax draft[4] discusses the notion of lexical equivalance. This means that two URIs are equivalent under certain conditions of case-insensitivity and/or %encoding of characters. Resolvers MUST return identical results for all lexically equivalent encodings of a URI. For example, the requests below must return identical results: GET /uri-res/N2L/urn:cid:foo@huh.com HTTP/1.0 GET /uri-res/N2L/URN:CID:foo@huh.com HTTP/1.0 GET /uri-res/N2L/urn:cid:foo%40huh%2ecom HTTP/1.0 Responses from the HTTP server follow standard HTTP practice. Status codes, such as 200 (OK) or 404 (Not Found) shall be returned. The normal rules for determining cachability, negotiating formats, etc. apply. 3.0 Service-specific details: ============================= This section goes through the various resolution services established in the URN services draft[5] and states how to encode each of them, how the results should be returned, and any special status codes that are likely to arise. Unless stated otherwise, the HTTP requests are formed according to the simple convention above, either for HTTP/1.0 or HTTP/1.1. The response is assumed to be an entity with normal headers and body unless stated otherwise. (N2L is the only request that need not return a body). 3.1 N2L (URN to URL): ---------------------- The request is encoded as above. The URL MUST be returned in a Location: header for the convienience of the user in the most common case of wanting the resource. If the lookup is successful, a 30X status line SHOULD be returned. HTTP/1.1 clients should be sent the 303 status code. HTTP/1.0 clients should be sent the 302 (Moved temporarily) status code unless the resolver has particular resons for using 301 (moved permanently) or 304 (not modified) codes. Note that access controls may be applied to this, or any other, resolution service request. Therefore the 401 (unauthorized) and 403 (forbidden) status codes are legal responses. The server may wish to provide a body in the response to explain the reason for refusing access, and/or to provide alternate information about the resource, such as the price it will cost to obtain the resource's URL. 3.2 N2Ls (URN to URLs): ------------------------ The request is encoded as above. The result is a list of 0 or more URLs. The Internet Media Type (aka ContentType) of the result may be negotiated using standard HTTP mechanisms if desired. At a minimum the resolver should support the text/uri-list media type. (See Appendix A for the definition of this media type). That media type is suitable for machine-processing of the list of URLs. Resolvers may also return the results as text/html, text/plain, or any other media type they deem suitable. No matter what the particular media type, the result MUST be a list of the URLs which may be used to obtain an instance of the resource identified by the URN. All URIs shall be encoded according to the URI specification [6]. If the client has requested the result be returned as text/html or application/html, the result should be encoded as: where the strings ...url n... are replaced by the n'th URL in the list. 3.3 N2R (URN to Resource): --------------------------- The request is encoded as above. The resource is returned using standard HTTP mechanisms. The request may be modified using the Accept: header as in normal HTTP to specify that the result be given in a preferred Internet Media Type. 3.4 N2Rs (URN to Resources): ----------------------------- This resolution service returns multiple instances of a resource, for example, GIF and JPEG versions of an image. The judgment about the resources being "the same" resides with the naming authority that issued the URN. The request is encoded as above. The result shall be a MIME multipart/alternative message with the alternative versions of the resource in seperate body parts. If there is only one version of the resource identified by the URN, it MAY be returned without the multipart/alternative wrapper. Resolver software SHOULD look at the Accept: header, if any, and only return versions of the resource that are acceptable according to that header. 3.5 N2C (URN to URC): ---------------------- URCs (Uniform Resource Characteristics) are descriptions of other resources. This request allows us to obtain a description of the resource identified by a URN, as opposed to the resource itself. The description might be a bibliographic citation, a digital signature, a revision history, etc. This draft does not specify the content of any response to a URC request. That content is expected to vary from one resolver to another. The format of any response to a N2C request MUST be communicated using the ContentType header, as is standard HTTP practice. The Accept: header SHOULD be honored. 3.6 N2Ns (URN to URNs): ------------------------ While URNs are supposed to identify one and only one resource, that does not mean that a resource may have one and only one URN. For example, consider a resource that has something like "current-weather-map" for one URN and "weather-map-for-datetime-x" for another URN. The N2Ns service request lets us obtain lists of URNs that are believed equivalent at the time of the request. As the weathermap example shows, some of the equivalances will be transitory, so the standard HTTP mechanisms for communicating cachability MUST be honored. The request is encoded as above. The result is a list of all the URNs, known to the resolver, which identify the same resource as the input URN. The result shall be encoded as for the N2Ls request above (text/uri-list unless specified otherwise by an Accept: header). 3.7 L2Ns (URL to URNs): ---------------------- The request is encoded as above. The response is a list of any URNs known to be assigned to the resource at the given URL. The result shall be encoded as for the N2Ls and N2Ns requests. 3.8 L2Ls (URL to URLs): ------------------------ The request is encoded as described above. The result is a list of all the URLs that the resolver knows are associated with the resource located by the given URL. This is encoded as for the N2Ls, N2Ns, and L2Ns requests. 3.9 L2C (URL to URC): ---------------------- The request is encoded as above, the response is the same as for the N2C request. Appendix A: The text/uri-list Internet Media Type ================================================= [This appendix will be augmented or replaced by the registration of the text/uri-list IMT once that registration has been performed]. Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns, L2Ls, result in a list of URIs being returned to the client. The text/uri-list Internet Media Type is defined to provide a simple format for the automatic processing of such lists of URIs. The format of text/uri-list resources is: 1) Any lines beginning with the '#' character are comment lines and are ignored during processing. (Note that '#' is a character that may appear in URIs, so it only denotes a comment when it is the first character on a line). 2) The remaining non-comment lines MUST be URIs (URNs or URLs), encoded according to the URI specification RFC[6]. Each URI shall appear on one and only one line. 3) As for all text/* formats, lines are terminated with a CR LF pair. In applications where one URI has been mapped to a list of URIs, such as in response to the N2Ls request, the first line of the text/uri-list response SHOULD be a comment giving the original URI. An example of such a result for the N2L request is shown below in figure 1. # urn:cid:foo@huh.org http://www.huh.org/cid/foo.html http://www.huh.org/cid/foo.pdf ftp://ftp.foo.org/cid/foo.txt Figure 1: Example of the text/uri-list format Appendix B: n2l.pl script ========================== This is a simple CGI script for the N2L resolution service. It assumes the presence of a DBM database to store the URN to URL mappings. This script does not specify standard behavior, it is provided merely as a courtesy for implementors. In fact, this script does not process incoming Accept: headers, nor does it generate status codes. Such behavior should be part of a real script for any of the resolution services. #!/bin/perl # N2L - performs urn to url resolution $n2l_File = "...filename for DBM database..."; $urn = $ENV{'PATH_INFO'} ; if(length($urn)<3) { $error=1; } if(!$error) { $urn =~s/^(\/)(urn:)?(.*)/$3/i; # Additional operations should be performed here # to convert lexically equivalent versions of a URI into # a canonical version for DB lookups. dbmopen(%lu,$n2l_File,0444); if($lu{$urn}) { $url=$lu{$urn}; print STDOUT "Location: $url\n\n"; }else{ $error=2; } dbmclose(%lu); } if($error) { print "Content-Type: text/html \n\n"; print "\n"; print "URN Resolution: N2L\n"; print "\n"; print "

URN to URL resolution failed for the URN:

\n"; print "

$urn

\n"; print "\n"; print "\n"; } exit; References: =========== [1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", draft-ietf-urn-naptr-01.txt, November, 1996. [2] RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-Lee, R. Fielding, H. Frystyk, May 1996. [3] R. Fielding, J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", draft-ietf-http-v11-spec-06, July 1996. [4] R. Moats, "URN Syntax", draft-ietf-urn-syntax-02, Jan. 1997. [5] URN Resolution Services Draft - (That document is in preparation. It will actually be strongly based on the content of this document and the NAPTR draft[1]). [6] RFC 1630, "Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web", T. Berners-Lee, June 1994. Security Considerations ======================= Communications with a resolver may be of a sensitive nature. Some resolvers will hold information that should only be released to authorized users. The results from resolvers may be the target of spoofing, especially once electronic commerce transactions are common and there is money to be made by directing users to pirate repositories rather than repositories which pay royalties to rightsholders. Resolution requests may be of interest to traffic analysts. The requests may also be subject to spoofing. The requests and responses in this draft are amenable to encoding, signing, and authentication in the manner of any other HTTP traffic. Author Contact Information: =========================== Ron Daniel Advanced Computing Lab, MS B287 Los Alamos National Laboratory Los Alamos, NM, USA, 87545 voice: +1 505 665 0597 fax: +1 505 665 4939 email: rdaniel@lanl.gov This draft expires 21 July, 1997. Ron Daniel Jr. email: rdaniel@acl.lanl.gov Advanced Computing Lab, MS B287 voice: (505) 665-0597 Los Alamos National Laboratory fax: (505) 665-4939 Los Alamos, NM, USA 87545 http://www.acl.lanl.gov/~rdaniel/ Want to buy: "The Five Laws of Library Science" by S.R. Ranganathan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA29848 for urn-ietf-out; Wed, 8 Jan 1997 18:38:49 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA29841 for ; Wed, 8 Jan 1997 18:38:47 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28959 (mail destined for urn-ietf@services.bunyip.com); Wed, 8 Jan 97 18:38:45 -0500 Received: from magenta.acl.lanl.gov (rdaniel@magenta.acl.lanl.gov [128.165.147.153]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id QAA03561 for ; Wed, 8 Jan 1997 16:38:44 -0700 (MST) From: "Ronald E. Daniel" Received: (rdaniel@localhost) by magenta.acl.lanl.gov (8.7.5/8.6.4) id QAA13017 for urn-ietf@bunyip.com; Wed, 8 Jan 1997 16:38:27 -0700 (MST) Date: Wed, 8 Jan 1997 16:38:27 -0700 (MST) Message-Id: <199701082338.QAA13017@magenta.acl.lanl.gov> To: urn-ietf@bunyip.com Subject: [URN] naptr draft URL Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ronald E. Daniel" Errors-To: owner-urn-ietf@bunyip.com The latest version of the naptr draft is also available at http://www.acl.lanl.gov/URN/naptr.txt and at http://www.acl.lanl.gov/URN/naptr-04.txt (The reason for the -04 in the filename while the draft itself says -02 is that the first two versions were individual submissions, while the subsequent versions have been the product of the URN-WG). Regards, Ron Daniel Jr. email: rdaniel@acl.lanl.gov 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 obscure_term: "hypernym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA29526 for urn-ietf-out; Wed, 8 Jan 1997 18:15:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA29521 for ; Wed, 8 Jan 1997 18:15:48 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28848 (mail destined for urn-ietf@services.bunyip.com); Wed, 8 Jan 97 18:15:28 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id QAA03290 for ; Wed, 8 Jan 1997 16:15:09 -0700 (MST) Message-Id: <3.0.32.19970108162501.006e2590@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 08 Jan 1997 16:25:21 -0700 To: urn-ietf@bunyip.com From: "Ron Daniel Jr." Subject: [URN] NAPTR draft - version 2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com Hi, Here is the NAPTR draft, with edits to incorporate the comments from the San Jose meeting. There are two references that need to be cleaned up, other than that I think it is ready to go. Your comments please! Regards, Ron =========== INTERNET DRAFT Ron Daniel draft-ietf-urn-naptr-02.txt Los Alamos National Laboratory Michael Mealling Network Solutions, Inc. 08 Jan., 1996 Resolution of Uniform Resource Identifiers using the Domain Name System Status of this Memo =================== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft expires 14 July, 1997. Abstract: ========= Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. In addition to locating resolvers, the NAPTR provides for other naming systems to be grandfathered into the URN world, provides independence between the name assignment system and the resolution protocol system, and allows multiple services (Name to Location, Name to Description, Name to Resource, ...) to be offered. In conjunction with the SRV RR, the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing. Introduction: ============= Uniform Resource Locators have been a significant advance in locating resources on the Internet. 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 to serve as persistent, location-independent identifiers for Internet resources in order to overcome most of the problems with URLs. RFC-1737 [1] 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 URLs, which identify the host to contact and the protocol to use. Readers are referred to [2] 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 DNS to locate "resolvers" that can provide information on individual resources, potentially including the resource itself. To accomplish this, we "rewrite" the URI into a domain name following the rules provided in NAPTR records. Rewrite rules provide considerable power, which is important when trying to meet the goals listed above. However, collections of rules can become difficult to understand. To lessen this problem, the NAPTR rules are *always* applied to the original URI, *never* to the output of previous rules. Locating a resolver through the rewrite procedure may take multiple steps, but the beginning is always the same. Every URI has a colon-delimited prefix. NAPTR resolution begins by taking this prefix, appending the well-known suffix ".urn.net", and querying the DNS for NAPTR records at that domain name. Based on the results of this query, zero or more additional DNS queries may be needed to locate resolvers for the URI. The details of the conversation between the client and the resolver thus located are outside the bounds of this draft. Three brief examples of this procedure are given in the next section. The NAPTR RR provides the level of indirection needed to keep the naming system independent of the resolution system, its protocols, and services. Coupled with the new SRV resource record proposal[3] there is also the potential for replicating the resolver on multiple hosts, overcoming some of the most significant problems of URLs. This is an important and subtle point. Not only do the NAPTR and SRV records allow us to replicate the resource, we can replicate the resolvers that know about the replicated resource. Preventing a single point of failure at the resolver level is a significant benefit. Separating the resolution procedure from the way names are constructed has additional benefits. Different resolution procedures can be used over time, and resolution procedures that are determined to be useful can be extended to deal with additional namespaces. Caveats ======= The NAPTR proposal is the first resolution procedure to be considered by the URN-WG. There are several concerns about the proposal which have motivated the group to recommend it for publication as an Experimental rather than a standards-track RFC. First, URN resolution is new to the IETF and we wish to gain operational experience before recommending any procedure for the standards track. Second, the NAPTR proposal is based on DNS and consequently inherits concerns about security and administration. The recent advancement of the DNSSEC and secure update drafts to Proposed Standard reduce these concerns, but we wish to experiment with those new capabilities in the context of URN administration. A third area of concern is the potential for a noticeable impact on the DNS. We believe that the proposal makes appropriate use of caching and additional information, but it is best to go slow where the potential for impact on a core system like the DNS is concerned. Fourth, the rewrite rules in the NAPTR proposal are based on regular expressions. Since regular expressions are difficult for humans to construct correctly, concerns exist about the usability and maintainability of the rules. This is especially true where international character sets are concerned. Terminology =========== "Must" or "Shall" - Software that does not behave in the manner that this document says it must is not conformant to this document. "Should" - Software that does not follow the behavior that this document says it should may still be conformant, but is probably broken in some fundamental way. "May" - Implementations may or may not provide the described behavior, while still remaining conformant to this document. Brief overview and examples of the NAPTR RR: ============================================ A detailed description of the NAPTR RR will be given later, but to give a flavor for the proposal we first give a simple description of the record and three examples of its use. The key fields in the NAPTR RR are order, preference, service, flags, regexp, and replacement: * The order field specifies the order in which records MUST be processed when multiple NAPTR records are returned in response to a single query. A naming authority may have delegated a portion of its namespace to another agency. Evaluating the NAPTR records in the correct order is necessary for delegation to work properly. * The preference field specifies the order in which records SHOULD be processed when multiple NAPTR records have the same value of "order". This field lets a service provider specify the order in which resolvers are contacted, so that more capable machines are contacted in preference to less capable ones. * The service field specifies the resolution protocol and resolution service(s) that will be available if the rewrite specified by the regexp or replacement fields is applied. Resolution protocols are the protocols used to talk with a resolver. They will be specified in other documents, such as [4]. Resolution services are operations such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC), etc. These will be discussed in the URN Resolution Services document[5], and their behavior in a particular resolution protocol will be given in the specification for that protocol (see [4] for a concrete example). * The flags field contains modifiers that affect what happens in the next DNS lookup, typically for optimizing the process. Flags may also affect the interpretation of the other fields in the record, therefore, clients MUST skip NAPTR records which contain an unknown flag value. * The regexp field is one of two fields used for the rewrite rules, and is the core concept of the NAPTR record. The regexp field is a String containing a sed-like substitution expression. (The actual grammar for the substitution expressions is given later in this draft). The substitution expression is applied to the original URN to determine the next domain name to be queried. The regexp field should be used when the domain name to be generated is conditional on information in the URI. If the next domain name is always known, which is anticipated to be a common occurrence, the replacement field should be used instead. * The replacement field is the other field that may be used for the rewrite rule. It is an optimization of the rewrite process for the case where the next domain name is fixed instead of being conditional on the content of the URI. The replacement field is a domain name (subject to compression if a DNS sender knows that a given recipient is able to decompress names in this RR type's RDATA field). If the rewrite is more complex than a simple substitution of a domain name, the replacement field should be set to . and the regexp field used. Note that the client applies all the substitutions and performs all lookups, they are not performed in the DNS servers. Note also that it is the belief of the developers of this document that regexps should rarely be used. The replacement field seems adequate for the vast majority of situations. Regexps are only necessary when portions of a namespace are to be delegated to different resolvers. Finally, note that the regexp and replacement fields are, at present, mutually exclusive. However, developers of client software should be aware that a new flag might be defined which requires values in both fields. Example 1 --------- Consider a URN that uses the hypothetical DUNS namespace. DUNS numbers are identifiers for approximately 30 million registered businesses around the world, assigned and maintained by Dunn and Bradstreet. The URN might look like: urn:duns:002372413:annual-report-1997 The first step in the resolution process is to find out about the DUNS namespace. The namespace identifier, duns, is extracted from the URN, prepended to urn.net, and the NAPTRs for duns.urn.net looked up. It might return records of the form: duns.urn.net ;; order pref flags service regexp replacement IN NAPTR 100 10 "s" "dunslink+N2L+N2C" "" dunslink.udp.isi.dandb.com IN NAPTR 100 20 "s" "rcds+N2C" "" rcds.udp.isi.dandb.com IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" "" http.tcp.isi.dandb.com The order field contains equal values, indicating that no name delegation order has to be followed. The preference field indicates that the provider would like clients to use the special dunslink protocol, followed by the RCDS protocol, and that HTTP is offered as a last resort. All the records specify the "s" flag, which will be explained momentarily. The service fields say that if we speak dunslink, we will be able to issue either the N2L or N2C requests to obtain a URL or a URC (description) of the resource. The Resource Cataloging and Distribution Service (RCDS)[6] could be used to get a URC for the resource, while HTTP could be used to get a URL, URC, or the resource itself. All the records supply the next domain name to query, none of them need to be rewritten with the aid of regular expressions. The general case might require multiple NAPTR rewrites to locate a resolver, but eventually we will come to the "terminal NAPTR". Once we have the terminal NAPTR, our next probe into the DNS will be for a SRV or A record instead of another NAPTR. Rather than probing for a non-existent NAPTR record to terminate the loop, the flags field is used to indicate a terminal lookup. If it has a value of "s", the next lookup should be for SRV RRs, "a" denotes that A records should sought. A "p" flag is also provided to indicate that the next action is Protocol-specific, but that looking up another NAPTR will not be part of it. Since our example RR specified the "s" flag, it was terminal. Assuming our client does not know the dunslink protocol, our next action is to lookup SRV RRs for rcds.udp.isi.dandb.com, which will tell us hosts that can provide the necessary resolution service. That lookup might return: ;; Pref Weight Port Target rcds.udp.isi.dandb.com IN SRV 0 0 1000 defduns.isi.dandb.com IN SRV 0 0 1000 dbmirror.com.au IN SRV 0 0 1000 ukmirror.com.uk telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their RCDS server. (The reader is referred to the SRV proposal [3] for the interpretation of the fields above). There is opportunity for significant optimization here. We can return the SRV records as additional information for terminal NAPTRs (and the A records as additional information for those SRVs). While this recursive provision of additional information is not explicitly blessed in the DNS specifications, it is not forbidden, and BIND does take advantage of it [7]. This is a significant optimization. In conjunction with a long TTL for *.urn.net records, the average number of probes to DNS for resolving DUNS URNs would approach one. Therefore, DNS server implementors SHOULD provide additional information with NAPTR responses. The additional information will be either SRV or A records. If SRV records are available, their A records should be provided as recursive additional information. Note that the example NAPTR records above are intended to represent the reply the client will see. They are not quite identical to what the domain administrator would put into the zone files. For one thing, the administrator should supply the trailing '.' character on replacement domain names. An additional difference will be illustrated later. Example 2 --------- Consider a URN namespace based on MIME Content-Ids. The URN might look like this: urn:cid:199606121851.1@mordred.gatech.edu The first step in the resolution process is to find out about the CID namespace. The namespace identifier, cid, is extracted from the URN, prepended to urn.net, and the NAPTR for cid.urn.net looked up. It might return records of the form: cid.urn.net ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "/urn:cid:.+@([^@]+)$/\1/i" . We have only one NAPTR response, so ordering the responses is not a problem. The replacement field is empty, so we check the regexp field and use the pattern provided there. We apply that regexp to the entire URN to see if it matches, which it does. The \1 part of the substitution expression returns the string "mordred.gatech.edu". Since the flags field does not contain "s" or "a", the lookup is not terminal and our next probe to DNS is for more NAPTR records: lookup(query=NAPTR, "mordred.gatech.edu"). While mordred could have its very own NAPTR, maintaining those records on all the machines at a site as large as Georgia Tech would be an intolerable burden. Instead, a wildcard may be used so that the domain administrator at Georgia Tech has only a single NAPTR record to maintain. That record might look like: *.gatech.edu IN NAPTR ;; order pref flags service regexp replacement IN NAPTR 100 50 "s" "z3950+N2L+N2C" "" z3950.tcp.gatech.edu. IN NAPTR 100 50 "s" "rcds+N2C" "" rcds.udp.gatech.edu. IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" http.tcp.gatech.edu. (Unlike all the other example records in this draft, the one above is the contents of a zone file, not the response received by the client. That is so that the wildcard can be seen.) Continuing with our example, we note that the values of the order and preference fields are equal in all records, so the client is free to pick any record. The flags field tells us that these are the last NAPTR patterns we should see, and after the rewrite (a simple replacement in this case) we should look up SRV records to get information on the hosts that can provide the necessary service. Assuming we prefer the Z39.50 protocol, our lookup might return: ;; Pref Weight Port Target z3950.tcp.gatech.edu IN SRV 0 0 1000 z3950.gatech.edu IN SRV 0 0 1000 z3950.cc.gatech.edu IN SRV 0 0 1000 z3950.uga.edu telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their Z39.50 server. Recall that the regular expression used \1 to extract a domain name from the CID. There is a significant caveat about the use of backslashes in DNS zone files. DNS treats backslashes as the escape character so that '.' can be escaped when necessary. This means that when a regular expression is entered into the zone file, the backslashes must be escaped by another backslash. For the case of the cid.urn.net record above, the regular expression entered into the zone file should be "/.+@([^@]+)/\\1/i". When the client code actually receives the record, the pattern will have been converted to "/.+@([^@]+)/\1/i". Example 3 --------- Even if URN systems were in place now, there would still be a tremendous number of URLs. It should be possible to develop a URN resolution system that can also provide location independence for those URLs. This is related to the requirement in [1] to be able to grandfather in names from other naming systems, such as ISO Formal Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, etc. The NAPTR RR could also be used for URLs that have already been assigned. Assume we have the URL for a very popular piece of software that the publisher wishes to mirror at multiple sites around the world: http://www.foo.com/software/latest-beta.exe We extract the prefix, "http", and lookup NAPTR records for http.urn.net. This might return a record of the form http.urn.net IN NAPTR ;; order pref flags service regexp replacement 100 90 "" "" "!http://([^/:]+)!\1!i" . This expression returns everything after the first double slash and before the next slash or colon. (We use the '!' character to delimit the parts of the substitution expression. Otherwise we would have to use backslashes to escape the forward slashes, and would have a regexp in the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".). Applying this pattern to the URL extracts "www.foo.com". Looking up NAPTR records for that might return: www.foo.com ;; order pref flags service regexp replacement IN NAPTR 100 100 "s" "http+L2R" "" http.tcp.foo.com IN NAPTR 100 100 "s" "ftp+L2R" "" ftp.tcp.foo.com Looking up SRV records for http.tcp.foo.com would return information on the hosts that foo.com has designated to be its mirror sites. The client can then pick one for the user. NAPTR RR Format =============== The format of the NAPTR RR is given below. The DNS type code for NAPTR is 104 [this is being changed, we believe it will be assigned 35]. Domain TTL Class Order Preference Flags Service Regexp Replacement where: Domain The domain name this resource record refers to. TTL Standard DNS Time To Live field Class Standard DNS meaning Order A 16-bit integer specifying the order in which the NAPTR records MUST be processed to ensure correct delegation of portions of the namespace over time. Low numbers are processed before high numbers, and once a NAPTR is found that "matches" a URN, the client MUST NOT consider any NAPTRs with a higher value for order. Preference A 16-bit integer which specifies the order in which NAPTR records with equal "order" values SHOULD be processed, low numbers being processed before high numbers. This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. Flags A String giving flags to control aspects of the rewriting and interpretation of the fields in the record. Flags are single characters from the set [A-Z0-9]. The case of the alphabetic characters is not significant. At this time only three flags, "S", "A", and "P", are defined. "S" means that the next lookup should be for SRV records instead of NAPTR records. "A" means that the next lookup should be for A records. The "P" flag says that the remainder of the resolution shall be carried out in a Protocol-specific fashion, and we should not do any more DNS queries. The remaining alphabetic flags are reserved. The numeric flags may be used for local experimentation. The S, A, and P flags are all mutually exclusive, and resolution libraries MAY signal an error if more than one is given. (Experimental code and code for assisting in the creation of NAPTRs would be more likely to signal such an error than a client such as a browser). We anticipate that multiple flags will be allowed in the future, so implementers MUST NOT assume that the flags field can only contain 0 or 1 characters. Finally, if a client encounters a record with an unknown flag, it MUST ignore it and move to the next record. This test takes precedence even over the "order" field. Since flags can control the interpretation placed on fields, a novel flag might change the interpretation of the regexp and/or replacement fields such that it is impossible to determine if a record matched a URN. Service Specifies the resolution service(s) available down this rewrite path. It may also specify the particular protocol that is used to talk with a resolver. A protocol MUST be specified if the flags field states that the NAPTR is terminal. If a protocol is specified, but the flags field does not state that the NAPTR is terminal, the next lookup MUST be for a NAPTR. The client MAY choose not to perform the next lookup if the protocol is unknown, but that behavior MUST NOT be relied upon. The service field may take any of the values below (using the Augmented BNF of RFC 822[8]): service_field = [ [protocol] *("+" rs)] protocol = "rcds" / "http" / "hdl" / "rwhois" rs = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C" / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C" i.e. an optional protocol specification followed by 0 or more resolution services. Each resolution service is indicated by an initial '+' character. Note that the empty string is also a valid service field. This will typically be seen at the top levels of a namespace, when it is impossible to know what services and protocols will be offered by a particular publisher within that name space. At this time the known protocols are rcds[6], hdl[9] (binary, UDP-based protocols), http[4] (a textual, TCP-based protocol), and rwhois[10] (textual, UDP or TCP based). More will be allowed later. The names of the protocols must be formed from the characters [a-Z0-9]. Case of the characters is not significant. The service requests currently allowed will be described in more detail in [5], but in brief they are: N2L - Given a URN, return a URL N2Ls - Given a URN, return a set of URLs N2R - Given a URN, return an instance of the resource. N2Rs - Given a URN, return multiple instances of the resouce, typically encoded using multipart/alternative. N2C - Given a URN, return a collection of meta-information on the named resource. The format of this response is the subject of another document. N2Ns - Given a URN, return all URNs that are also identifers for the resource. L2R - Given a URL, return the resource. L2Ns - Given a URL, return all the URNs that are identifiers for the resource. L2Ls - Given a URL, return all the URLs for instances of of the same resource. L2C - Given a URL, return a description of the resource. The actual format of the service request and response will be determined by the resolution protocol, and is the subject for other documents (e.g. [4]). Protocols need not offer all services. The labels for service requests shall be formed from the set of characters [A-Z0-9]. The case of the alphabetic characters is not significant. Regexp A STRING containing a substitution expression that is applied to the original URI in order to construct the next name to lookup. The grammar of the substitution expression is given in the next section. Replacement The next NAME to query for NAPTR, SRV, or A records depending on the value of the flags field. As mentioned above, this may be compressed. Substitution Expression Grammar: ================================ The content of the regexp field is a substitution expression. True sed(1) substitution expressions are not appropriate for use in this application for a variety of reasons, therefore the contents of the regexp field MUST follow the grammar below: subst_expr = delim-char ere delim-char repl delim-char *flags delim-char = "/" / "!" / ... (Any non-digit or non-flag character other than backslash '\'. All occurances of a delim_char in a subst_expr must be the same character.) ere = POSIX Extended Regular Expression (see [11], section 2.8.4) repl = dns_str / backref / repl dns_str / repl backref dns_str = ...... which RFC can I cite for this? 1035 seems obsolete ..... backref = "\" 1POS_DIGIT flags = "i" DNS_CHAR = "_" / "0" / "1" / ... / "9" / "a" / ... / "z" POS_DIGIT = "1" / "2" / ... / "9" ; 0 is not an allowed backref value The result of applying the substitution expression to the original URI shall be a legal domain name. Since it is possible for the regexp field to be improperly specified, such that a non-conforming domain name can be constructed, client software SHOULD verify that the result is a legal domain name before making queries on it. Backref expressions in the repl portion of the substitution expression are replaced by the (possibly empty) string of characters enclosed by '(' and ')' in the ERE portion of the substitution expression. N is a single digit from 1 through 9, inclusive. It specifies the N'th backref expression, the one that begins with the N'th '(' and continues to the matching ')'. For example, the ERE (A(B(C)DE)(F)G) has backref expressions: \1 = ABCDEFG \2 = BCDE \3 = C \4 = F \5..\9 = error - no matching subexpression The "i" flag indicates that the ERE matching SHALL be performed in a case-insensitive fashion. Furthermore, any backref replacements MAY be normalized to lower case when the "i" flag is given. The first character in the substitution expression shall be used as the character that delimits the components of the substitution expression. There must be exactly three non-escaped occurrences of the delimiter character in a substitution expression. Since escaped occurrences of the delimiter character will be interpreted as occurrences of that character, digits MUST NOT be used as delimiters. Backrefs would be confused with literal digits were this allowed. Similarly, if flags are specified in the substitution expression, the delimiter character must not also be a flag character. Advice to domain administrators: ================================ Beware of regular expressions. Not only are they a pain to get correct on their own, but there is the previously mentioned interaction with DNS. Any backslashes in a regexp must be entered twice in a zone file in order to appear once in a query response. More seriously, the need for double backslashes has probably not been tested by all implementors of DNS servers. We anticipate that urn.net will be the heaviest user of regexps. Only when delegating portions of namespaces should the typical domain administrator need to use regexps. On a related note, beware of interactions with the shell when manipulating regexps from the command line. Since '\' is a common escape character in shells, there is a good chance that when you think you are saying "\\" you are actually saying "\". Similar caveats apply to characters such as '*', '(', etc. The "a" flag allows the next lookup to be for A records rather than SRV records. Since there is no place for a port specification in the NAPTR record, when the "A" flag is used the specified protocol must be running on its default port. The URN-WG is discussing the use of international characters in URNs. Regular expressions for strings in international character sets are likely to be essentially impossible to read or write by hand. Usage ===== For the edification of implementers, pseudocode for a client routine using NAPTRs is given below. This code is provided merely as a convience, it does not have any weight as a standard way to process NAPTR records. Also, as is the case with pseudocode, it has never been executed and may contain logical errors. You have been warned. // // findResolver(URN) // Given a URN, find a host that can resolve it. // findResolver(string URN) { sprintf(key, "%s.urn.net", extractNS(URN)); // prepend prefix to urn.net do { rewrite_flag = false; terminal = false; if (key has been seen) { quit with a loop detected error } add key to list of "seens" records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key' sort NAPTR records by "order" field and "preference" field (with "order" being more significant than "preference"). n_naptrs = number of NAPTR records in response. curr_order = records[0].order; max_order = records[n_naptrs-1].order; // Process current batch of NAPTRs according to "order" field. for (j=0; j < n_naptrs && records[j].order <= max_order; j++) { if (unknown-flag) // skip this record and go to next one continue; newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp); if (!newkey) // Skip to next record if the rewrite didn't match continue; // We did do a rewrite, shrink max_order to current value // so that delegation works properly max_order = naptr[j].order; // Will we know what to do with the protocol and services // specified in the NAPTR? If not, try next record. if(!isKnownProto(naptr[j].services)) { continue; } if(!isKnownService(naptr[j].services)) { continue; } // At this point we have a successful rewrite and we will know // how to speak the protocol and request a known resolution // service. Before we do the next lookup, check some // optimization possibilities. if (strcasecmp(flags, "S") || strcasecmp(flags, "P")) || strcasecmp(flags, "A")) { terminal = true; services = naptr[j].services; addnl = any SRV and/or A records returned as additional info for naptr[j]. } key = newkey; rewriteflag = true; break; } } while (rewriteflag && !terminal); // Did we not find our way to a resolver? if (!rewrite_flag) { report an error return NULL; } // Leave rest to another protocol? if (strcasecmp(flags, "P")) { return key as host to talk to; } // If not, keep plugging if (!addnl) { // No SRVs came in as additional info, look them up srvs = lookup(type=SRV, key); } sort SRV records by preference, weight, ... foreach (SRV record) { // in order of preference try contacting srv[j].target using the protocol and one of the resolution service requests from the "services" field of the last NAPTR record. if (successful) return (target, protocol, service); // Actually we would probably return a result, but this // code was supposed to just tell us a good host to talk to. } die with an "unable to find a host" error; } Notes: ====== - A client MUST process multiple NAPTR records in the order specified by the "order" field, it MUST NOT simply use the first record that provides a known protocol and service combination. - If a record at a particular order matches the URI, but the client doesn't know the specified protocol and service, the client SHOULD continue to examine records that have the same order. The client MUST NOT consider records with a higher value of order. This is necessary to make delegation of portions of the namespace work. The order field is what lets site administrators say "all requests for URIs matching pattern x go to server 1, all others go to server 2". (A match is defined as: 1) The NAPTR provides a replacement domain name or 2) The regular expression matches the URN ) - When multiple RRs have the same "order", the client should use the value of the preference field to select the next NAPTR to consider. However, because of preferred protocols or services, estimates of network distance and bandwidth, etc. clients may use different criteria to sort the records. - If the lookup after a rewrite fails, clients are strongly encouraged to report a failure, rather than backing up to pursue other rewrite paths. - When a namespace is to be delegated among a set of resolvers, regexps must be used. Each regexp appears in a separate NAPTR RR. Administrators should do as little delegation as possible, because of limitations on the size of DNS responses. - Note that SRV RRs impose additional requirements on clients. Acknowledgments: ================= The authors would like to thank Keith Moore for all his consultations during the development of this draft. We would also like to thank Paul Vixie for his assistance in debugging our implementation, and his answers on our questions. References: =========== [1] RFC-1737, "Functional Requirements for Uniform Resource Names", Karen Sollins and Larry Masinter, Dec. 1994. [2] Urn implementors article in DLIB? Perhaps [2] draft-daigle-urn-framework-00.txt "A Uniform Resource Naming Framework", Leslie Daigle and Patrik Faltstrom, June, 1996. [3] RFC 2052, "A DNS RR for specifying the location of services (DNS SRV)", A. Gulbrandsen and P. Vixie, October 1996. [4] RFC-xxxx, "Conventions for the Use of HTTP for Resolution of URNs", Ron Daniel Jr., currently available as draft-ietf-urn-http-conv-01.txt, Dec. 1996. [5] RFC-xxxx, "URN Resolution Services", ???, draft-ietf-urn-??? (This document is on the URN-WG's list of documents to prepare, but has not yet been written. It will get its start from the treatment of resolution services in [4]). [6] Keith Moore, "Resource Cataloging and Distribution Service", ??? [7] Paul Vixie, personal communication. [8] RFC-822, "Standard for the Format of ARPA Internet Text Messages", Dave H. Crocker, August 1982. [9] Charles Orth, Bill Arms; Handle Resolution Protocol Specification, http://www.handle.net/docs/client_spec.html [10] RFC-1714, "Referral Whois Protocol (RWhois)", S. Williamson and M. Kosters, November 1994. [11] IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1); IEEE Std 1003.2-1992; The Institute of Electrical and Electronics Engineers; New York; 1993. ISBN:1-55937-255-9 Security Considerations ======================= The use of "urn.net" as the registry for URN namespaces is subject to denial of service attacks, as well as other DNS spoofing attacks. The interactions with DNSSEC are currently being studied. It is expected that NAPTR records will be signed with SIG records once the DNSSEC work is deployed. The rewrite rules make identifiers from other namespaces subject to the same attacks as normal domain names. Since they have not been easily resolvable before, this may or may not be considered a problem. Regular expressions should be checked for sanity, not blindly passed to something like PERL. Author Contact Information: =========================== Ron Daniel Los Alamos National Laboratory MS B287 Los Alamos, NM, USA, 87545 voice: +1 505 665 0597 fax: +1 505 665 4939 email: rdaniel@lanl.gov Michael Mealling Network Solutions 505 Huntmar Park Drive Herndon, VA 22070 voice: (703) 742-0400 fax: (703) 742-9552 email: michaelm@internic.net URL: http://www.netsol.com/ This draft expires 14 July, 1997. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab, MS B287 voice: +1 505 665 0597 Los Alamos National Laboratory fax: +1 505 665 4939 Los Alamos, NM, USA 87545 http://www.acl.lanl.gov/~rdaniel/ Want to buy: "The Five Laws of Library Science" by S.R. Ranganathan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA25131 for urn-ietf-out; Tue, 7 Jan 1997 14:03:39 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA25126 for ; Tue, 7 Jan 1997 14:03:37 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16503 (mail destined for urn-ietf@services.bunyip.com); Tue, 7 Jan 97 14:03:35 -0500 Received: by privateer.windrose.omaha.ne.us; Tue Jan 7 13:02 CST 1997 Message-Id: <32D29DAC.3DC6@ds.internic.net> Date: Tue, 07 Jan 1997 13:02:04 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: urn-ietf@bunyip.com Subject: [URN] Proposed URN Syntax Draft changes to align with URL syntax draft References: <32BAEDA2.4940@ds.internic.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Ryan Moats wrote: > > Folks- > > There have been some good comments about the syntax draft and some > good stuff coming out of meshing it with the URL syntax, so I am > planning the following (i.e. you have been warned!). > > There will be another pre-release of syntax-02 coming out on > 12/26 ( Holidays, what are Holidays ;-} ). The target is to > have -02 be sent to the i-d editors on 1/6/97. > > This way folks (who don't have anything else to do between 12/25 > and 1/1) can read the new version... Well, here we are in the week of 1/6/97 and some issues have come up vis-a-vie the URL syntax document. Here are the technical issues (as I see them, and I've probably missed/ignored some): 1. The URN syntax is more restrictive in the types of characters allowed vis-a-vie the URL syntax. Specifically, the characters ";", "$", "_", "!", "~", "*", "'" are allowed (in unescaped format) in the URL syntax while not in the URN syntax. 2. The URL syntax document makes a claim that the its syntax is the syntax for URIs in general so that URNs may be used in any data field that might otherwise hold a URL. I'll admit that there are a lot of political issues that I am ignoring for now, but I want to see if we can move forward with the technical issues. My current thoughts are to move the characters in note 1 above from the excluded character set to the allowed character set to more closely align the URN and URL character sets. IF SOMEONE THINKS THIS IS A BAD IDEA THIS IS A GOOD TIME TO LET ME KNOW! Issue 2 is handled (I believe) by adding an appendix to the URN syntax document that covers how a URL resolver should react to a URN. My proposal is that the URN be considered an opaque URL that gets handed off to a URN resolver. There are alternate solutions, but they become progressively more ugly. Note that issues 1 and 2 are somewhat independent. Given the current allowed characters and the above suggested appendix, any URN could be used in place of a URL. Although I've considered it in the past, I think that defining URN's as a URL "scheme" is a less optimal solution than the above proposals. Obviously, I am soliciting input to try and gain an idea about consensus (and fairly quickly, too). Ryan 1997-020000666000003600000100000006013406307330553010604 0ustar wwwrunwww Received: from ietf.org by ietf.org id aa28140; 12 Feb 97 9:57 EST Received: from ietf.ietf.org by ietf.org id aa25856; 12 Feb 97 9:34 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: urn-ietf@bunyip.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-syntax-02.txt Date: Wed, 12 Feb 1997 09:34:13 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702120934.aa25856@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : URN Syntax Author(s) : R. Moats Filename : draft-ietf-urn-syntax-02.txt Pages : 7 Date : 02/11/1997 Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers. This document sets forward the canonical syntax for URNs. A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-syntax-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-syntax-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970211102211.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-syntax-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-syntax-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970211102211.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03006; 20 Feb 97 10:00 EST Received: from ietf.ietf.org by ietf.org id aa01526; 20 Feb 97 9:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: urn-ietf@bunyip.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-naptr-02.txt Date: Thu, 20 Feb 1997 09:35:12 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702200935.aa01526@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Resolution of Uniform Resource Identifiers using the Domain Name System Author(s) : R. Daniel, M. Mealling Filename : draft-ietf-urn-naptr-02.txt Pages : 14 Date : 02/19/1997 Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-naptr-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-naptr-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970219104118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-naptr-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-naptr-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219104118.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from ietf.org by ietf.org id aa03002; 20 Feb 97 10:00 EST Received: from ietf.ietf.org by ietf.org id aa01564; 20 Feb 97 9:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; cc: urn-ietf@bunyip.com Sender:ietf-announce-request@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-http-conv-01.txt Date: Thu, 20 Feb 1997 09:35:17 -0500 X-Orig-Sender: cclark@ietf.org Message-ID: <9702200935.aa01564@ietf.org> --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : A Trivial Convention for using HTTP in URN Resolution Author(s) : R. Daniel Filename : draft-ietf-urn-http-conv-01.txt Pages : 6 Date : 02/19/1997 The Uniform Resource Names Working Group (URN-WG) was formed to specify persistent, location-independent names for network accessible resources, as well as resolution mechanisms to retrieve the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal [1]. That proposal specifies how a client may find a "resolver" for a URN. A resolver is a database that can provide information about the resource identified by a URN, such as the resource's location, a bibliographic description, or even the resource itself. The protocol used for the client to communicate with the resolver is not specified in the NAPTR proposal. Instead, the NAPTR resource record provides a field that indicates the "resolution protocol" and "resolution service requests" offered by the resolver. This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. The primary goal of THTTP is to be simple to implement so that existing HTTP servers may easily add support for URN resolution. We expect that the databases used by early resolvers will be useful when more sophisticated esolution protocols are developed later. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-http-conv-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-http-conv-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-http-conv-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970219105545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-http-conv-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-http-conv-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219105545.I-D@ietf.org> --OtherAccess-- --NextPart--   Received: from cnri by ietf.org id aa15852; 21 Feb 97 13:30 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa19153; 21 Feb 97 13:30 EST Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id MAA03964 for uri-out; Fri, 21 Feb 1997 12:40:26 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id MAA03937; Fri, 21 Feb 1997 12:39:47 -0500 (EST) Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04329 (mail destined for urn-ietf@services.bunyip.com); Fri, 21 Feb 97 12:39:46 -0500 Received: from beach.w3.org by MINTAKA.LCS.MIT.EDU id aa04054; 21 Feb 97 12:21 EST Message-Id: <330DD97C.D6F7D91@w3.org> Date: Fri, 21 Feb 1997 11:21:00 -0600 From: Dan Connolly Organization: World Wide Web Consortium X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.18 i586) Mime-Version: 1.0 To: touch@isi.edu Cc: rdaniel@acl.lanl.gov, liberte@ncsa.uiuc.edu, uri@bunyip.com, urn-ietf@bunyip.com Subject: Re: URI-protocol mapping (was Re: How to add new "protocols" ?) References: <199702211554.AA05345@ash.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-uri@bunyip.com Precedence: bulk touch@ISI.EDU wrote: > > > OK, I'll bite: how is it that "location-dependent" vs. > > "location-independent" is a technical distinction? > It's very technical. The host requirements RFC specifies locations > as either fully-qualified DNS names or IP addresses. And that's what > you have here. I.e., you have as much of a location as the internet > allows. Ah! I wan't aware of that. I really appreciate you pointing that out. OK, I'm happy with 'location-independent' as a technical term if 'location' is defined as 'FQDN or IP address'. I inferred the more geographic connotations. I want that in the specs though. If I didn't know it, I'm sure lots of other folks didn't know it. A quick scan of the URN requirements/framework draft[1] and the URN requirements RFC[2] doesn't show a similar definition of 'location'. And there's no reference to the host requirements RFC. Hang on... I went to add it to my glossary of web architecture terms[3], but a brief scan of the host requirements RFC[4] shows: |the DNS provides globally-unique, | location-independent names. If a FQDNs are locations, how does DNS provide location-independent names? In fact, I don't see this definition of location that you refer to at all in the host requirements RFC[4]. Could you elaborate? [1] ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-req-frame-00.txt [2] http://ds.internic.net/rfc/rfc1737.txt [3] http://www.w3.org/pub/WWW/Architecture/Terms [4] ftp://ftp.math.utah.edu/pub/rfc/rfc1123.txt   Received: from cnri by ietf.org id aa24526; 25 Feb 97 14:21 EST Received: from services.Bunyip.Com by CNRI.Reston.VA.US id aa18776; 25 Feb 97 14:21 EST Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id NAA05966 for uri-out; Tue, 25 Feb 1997 13:31:13 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id NAA05948; Tue, 25 Feb 1997 13:30:58 -0500 (EST) From: touch@isi.edu Received: from zephyr.isi.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29768 (mail destined for urn-ietf@services.bunyip.com); Tue, 25 Feb 97 13:30:56 -0500 Received: from ash.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 25 Feb 1997 10:30:54 -0800 Date: Tue, 25 Feb 1997 10:30:49 -0800 Posted-Date: Tue, 25 Feb 1997 10:30:49 -0800 Message-Id: <199702251830.AA12562@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Tue, 25 Feb 1997 10:30:49 -0800 To: touch@isi.edu, connolly@w3.org Subject: Re: URI-protocol mapping (was Re: How to add new "protocols" ?) Cc: rdaniel@acl.lanl.gov, liberte@ncsa.uiuc.edu, uri@bunyip.com, urn-ietf@bunyip.com X-Auto-Sig-Adder-By: faber@isi.edu Sender: owner-uri@bunyip.com Precedence: bulk > From connolly%w3.org@beach.w3.org Fri Feb 21 09:39:57 1997 > > touch@ISI.EDU wrote: > > > > > OK, I'll bite: how is it that "location-dependent" vs. > > > "location-independent" is a technical distinction? > > > It's very technical. The host requirements RFC specifies locations > > as either fully-qualified DNS names or IP addresses. And that's what > > you have here. I.e., you have as much of a location as the internet > > allows. > > Ah! I wan't aware of that. I really appreciate you pointing > that out. > > OK, I'm happy with 'location-independent' as a technical > term if 'location' is defined as 'FQDN or IP > address'. I inferred the more geographic connotations. > A quick scan of the URN requirements/framework draft[1] > and the URN requirements RFC[2] doesn't > show a similar definition of 'location'. And there's > no reference to the host requirements RFC. That is a clear inconsistency. Given that HTTP/1.1 does ref it. > Hang on... I went to add it to my glossary of web > architecture terms[3], but a brief scan of the > host requirements RFC[4] shows: > > |the DNS provides globally-unique, > | location-independent names. > > If a FQDNs are locations, how does DNS provide > location-independent names? We're confusing the term location here, as is probably obvious. The DNS provides globally-unique, (geographically) location-independent names. FQDNs are locations, just not geographic ones. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/   Received: from ietf.org by ietf.org id aa24269; 26 Feb 97 11:35 EST Received: from black-ice.cc.vt.edu by ietf.org id aa24126; 26 Feb 97 11:34 EST Received: from black-ice.cc.vt.edu (valdis@LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.8.5/8.8.5) with ESMTP id LAA32304; Wed, 26 Feb 1997 11:31:59 -0500 Message-Id: <199702261631.LAA32304@black-ice.cc.vt.edu> X-Mailer: exmh version 2.0gamma 1/27/96 To: Neal McBurnett Cc: ietf@ietf.org, m.t.hamilton@lut.ac.uk, wright@lbl.gov Subject: Re: ids-dnsnames-02.txt: add list.domain.name for mail lists In-Reply-To: Your message of "Tue, 25 Feb 1997 16:58:42 PST." <9702260058.AA13799@lever.dr.lucent.com> Sender:ietf-request@ietf.org From: Valdis.Kletnieks@vt.edu X-Url: http://black-ice.cc.vt.edu/~valdis/ References: <9702260058.AA13799@lever.dr.lucent.com> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==_Exmh_383835428P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Wed, 26 Feb 1997 11:31:58 -0500 Source-Info: From (or Sender) name not authenticated. --==_Exmh_383835428P Content-Type: text/plain; charset=us-ascii On Tue, 25 Feb 1997 16:58:42 PST, Neal McBurnett said: > The machines are frequently distinct from the "mail" machine > for a given organization because the operational characteristics > and requirements can be very different. > > I propose the alias "list" for the "mail list" service. > It is the most common generic name in the lists I subscribe to. > Are there common alternatives? Well.. actually, I suspect that in most cases, the machine name is either listserv.domain.xyz (for people running LSoft's software), or majordomo.domain.xyz, or listproc.domain.xyz (for those running the CREN list processor). I can't remember seeing a machine called list.domain.xyz, and I've been doing Listserv stuff since 1984 or so. Are you sure that your "the lists I subscribe to" isn't biased in some way (for instance, many of your lists are hosted in one domain, so that domain's preferences impact the names you see)? The command languages for these 3 products are sufficiently different that bundling them all under the same 'list' is probably a bad idea. -- Valdis Kletnieks Computer Systems Engineer Virginia Tech --==_Exmh_383835428P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.2 iQCVAwUBMxRlfNQBOOoptg9JAQHCUwP/W7VtJ0FGgeZ3P/U0Ei7Dx7/KgWZ0sFb+ 1HMGcZa8UASOZJ6o3NegsAoFHkkJi5rqW574UpN9rJS7476s0wSSMeJg5M+MZYb7 z9/XlB5oMb8UIEEyqMkTaOYSJJBP10ztRsRo42SjGQgTXV3NLrPNo3pPoLnntCiE YM8CSrLt7aA= =SbSb -----END PGP MESSAGE----- --==_Exmh_383835428P--   Received: from ietf.org by ietf.org id aa27448; 26 Feb 97 12:21 EST Received: from buster.lbl.gov by ietf.org id aa27311; 26 Feb 97 12:18 EST Received: from [128.3.9.20] by cnrmail.lbl.gov with ESMTP (Apple Internet Mail Server 1.1.1); Wed, 26 Feb 1997 09:15:28 -0800 X-Sender: wright@cnrmail.lbl.gov Message-Id: In-Reply-To: <199702261631.LAA32304@black-ice.cc.vt.edu> References: Your message of "Tue, 25 Feb 1997 16:58:42 PST." <9702260058.AA13799@lever.dr.lucent.com> <9702260058.AA13799@lever.dr.lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 26 Feb 1997 09:15:26 -0800 To: Valdis.Kletnieks@vt.edu, Neal McBurnett Sender:ietf-request@ietf.org From: Russ Wright Subject: Re: ids-dnsnames-02.txt: add list.domain.name for mail lists Cc: ietf@ietf.org, ids@merit.edu Source-Info: From (or Sender) name not authenticated. Thanks for the comments. If anyone else has suggestions perhaps we should discuss on the ids@merit.edu list rather than the general ietf list. To address this particular comment- I think Valdis is correct about avoiding one alias. Having said that it was made pretty clear to me that the IESG folks who reviewed this document don't want a long list of aliases in the document. Russ At 8:31 AM -0800 2/26/97, Valdis.Kletnieks@vt.edu wrote: >On Tue, 25 Feb 1997 16:58:42 PST, Neal McBurnett said: >> The machines are frequently distinct from the "mail" machine >> for a given organization because the operational characteristics >> and requirements can be very different. >> >> I propose the alias "list" for the "mail list" service. >> It is the most common generic name in the lists I subscribe to. >> Are there common alternatives? > >Well.. actually, I suspect that in most cases, the machine name is >either listserv.domain.xyz (for people running LSoft's software), >or majordomo.domain.xyz, or listproc.domain.xyz (for those running >the CREN list processor). I can't remember seeing a machine called >list.domain.xyz, and I've been doing Listserv stuff since 1984 or so. >Are you sure that your "the lists I subscribe to" isn't biased in some >way (for instance, many of your lists are hosted in one domain, so >that domain's preferences impact the names you see)? > >The command languages for these 3 products are sufficiently different >that bundling them all under the same 'list' is probably a bad idea. > > >-- > Valdis Kletnieks > Computer Systems Engineer > Virginia Tech  1997-02.mail0000666000175200000100000125422711373052020011477 0ustar steveywww Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id OAA11774 for urn-ietf-out; Wed, 26 Feb 1997 14:52:08 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id OAA11769 for ; Wed, 26 Feb 1997 14:52:04 -0500 (EST) Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13198 (mail destined for urn-ietf@services.bunyip.com); Wed, 26 Feb 97 14:52:03 -0500 From: Leslie Daigle Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id OAA04639 for urn-ietf@bunyip.com; Wed, 26 Feb 1997 14:52:02 -0500 Date: Wed, 26 Feb 1997 14:52:02 -0500 Message-Id: <199702261952.OAA04639@beethoven.bunyip.com> To: urn-ietf@bunyip.com Subject: [URN] Planning for Memphis Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Leslie Daigle Errors-To: owner-urn-ietf@Bunyip.Com The scramble for Memphis hotel rooms seems to be the sign that it's time to talk about what we will attempt to achieve before that meeting. A number of people have been working hard since San Jose, so we've been making a good deal of progress. Meeting dates: Memphis IETF meeting is April 7-11, 1997. Internet-Draft CUTOFF date: Wednesday, March 26, 1997 at 5pm ET Document status/plan: Architecture: . URN syntax (Ryan Moats -- almost to last call) . UDS requirements (Karen Sollins -- new draft by Memphis) . Namespace requirements (Renato Iannella; Ron Daniel has provided some starting structure -- draft by Memphis) . (URI?) Resolution Service Definitions (Need volunteer -- draft by Memphis) Implementation . NAPTR (Ron Daniel -- almost to last call) - should refer to the UDS requirements doc . THTTP (Ron Daniel -- almost to last call) - should refer to the Resolution Services Def'n . Existing Namespace (some work being done with SICI's) . New, generic namespace -- waiting on Namespace requirements doc I've been in touch with most editors directly at this point, and I think the above is achievable. At this point, I'm looking for a volunteer to take the Trivial HTTP draft and extract from it a generic statement about Resolution Service Definitions for that last architecture draft. As a first approximation, I think this should include: . definitions of each service . definitions of responses for each service. This includes how to handle exceptions/error conditions. For example, N2Ls: . says that a list of URLs for the resource are returned; resolution service definitions must include statements about how these are carried (e.g., in the THTTP it is described as tex/uri-list media type, etc). . defines _what_ URLs are to be returned for the URN (i.e., this is what nails the semantics of what you should _expect_ to get at the end of that URL -- the definitive resource? resource-du-jour?) . describes what exceptions are possible: unknown, not available, not accessible (security). Thoughts? Volunteers? Let me know! Leslie. ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id TAA16340 for urn-ietf-out; Tue, 25 Feb 1997 19:47:15 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id TAA16335 for ; Tue, 25 Feb 1997 19:47:04 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03255 (mail destined for urn-ietf@services.bunyip.com); Tue, 25 Feb 97 19:47:00 -0500 From: Masataka Ohta Message-Id: <199702260044.JAA09113@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id JAA09113; Wed, 26 Feb 1997 09:43:45 +0859 Subject: Re: [URN] Re: URL internationalization! To: alb@sct.gouv.qc.ca (Alain LaBont/e'/) Date: Wed, 26 Feb 97 9:43:43 JST Cc: mohta@necom830.hpcl.titech.ac.jp, jch@netscape.com, mduerst@ifi.unizh.ch, ietf-url@imc.org, urn-ietf@bunyip.com In-Reply-To: <3.0.1.16.19970225104424.09e7394a@riq.qc.ca>; from "Alain LaBont/e'/" at Feb 25, 97 10:44 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Masataka Ohta Errors-To: owner-urn-ietf@Bunyip.Com Alain; > [Alain Stop using to insist on ISO-8859-1 for fully Internationalized communication. Use ASCII only. > >> Turkish is probably the worst case btw. Turkish uses the latin script > but... > > [Masataka Ohta] : > >These days, there are annoying live demonstrations in ietf ML that > >Turkish is just fine with ASCII. Have you done something? > > [Alain > No, I am not aware of this. But I know that the Turks would not agree. All the people of IETF ML is aware that you are wrong. > >> If they pronounce it they have it wrong all the time. On a speakerphone in > >> an airport a Turk might not recognize his/her own name. > > [Masataka Ohta] : > >??? How can the speakerphone operator pronounce my name written in > >Kanji? > > [Alain] : > The sub-thread (a perenthesis open by Jan, pronounced Yan) of this > discussion, I believe, dealt with the use of the International Phonetic > Alphabet for machine-readable passports or for airline tickets. That's not even a subthread. > But to come back to the sub-thread, with the IPA any human-pronounceable > sound can be represented, So with ASCII, or just a binary sequence of '0' and '1'. The only difference is that, with ASCII, there already exists formal notations transcribable by anyone and readable/writable/pronoucible by those who know the language. Masataka Ohta Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id NAA06463 for urn-ietf-out; Tue, 25 Feb 1997 13:55:30 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id NAA06458 for ; Tue, 25 Feb 1997 13:55:26 -0500 (EST) Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29897 (mail destined for urn-ietf@services.bunyip.com); Tue, 25 Feb 97 13:55:12 -0500 Received: by privateer.windrose.omaha.ne.us; Tue Feb 25 12:54 CST 1997 Message-Id: <33133556.77D6@ds.internic.net> Date: Tue, 25 Feb 1997 12:54:14 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: urn-ietf@bunyip.com Subject: [URN] Syntax v 2.1 (pre-release of syntax-03) Content-Type: multipart/mixed; boundary="------------33B96FF35FDA" Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@Bunyip.Com This is a multi-part message in MIME format. --------------33B96FF35FDA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks- Moving right along with the syntax, attached is v2.1 of the URN syntax draft. I've made changes based on Ron's comments. If nobody has any serious qualms, I'd like to issue v3 next week (3/3) and then go to whatever our equivalent of "WG last call" is so that we can submit this to the IETF by mid-March (Leslie, any problems with this?) Ryan --------------33B96FF35FDA Content-Type: text/plain; charset=us-ascii; name="urn.syntax.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="urn.syntax.txt" Internet-Draft Ryan Moats draft-ietf-urn-syntax-03.txt AT&T Expires in six months March 1997 URN Syntax Filename: draft-ietf-urn-syntax-03.tx Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers. This document sets forward the canonical syntax for URNs. A discussion of both existing legacy and new namespaces and requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. 1. Introduction Uniform Resource Names (URNs) are intended to serve as persistent, location-independent, resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space. Therefore, the URN syntax provides a means to encode character data in a form that can be sent in existing protocols, transcribed on most keyboards, etc. Expires 9/30/97 [Page 1] INTERNET DRAFT URN Syntax March 1997 2. Syntax All URNs have the following syntax (phrases enclosed in quotes are REQUIRED): ::= "urn:" ":" where is the Namespace Identifier, and is the Namespace Specific String. The leading "urn:" sequence is case-insensitive. The Namespace ID determines the _syntactic_ interpretation of the Namespace Specific String (as discussed in [1]). RFC 1630 [2] and RFC 1737 [3] each presents additional considerations for URN encoding, which have implications as far as limiting syntax. On the other hand, the requirement to support existing legacy naming systems has the effect of broadening syntax. Thus, we discuss the acceptable syntax for both the Namespace Identifier and the Namespace Specific String separately. 2.1 Namespace Identifier Syntax The following is the syntax for the Namespace Identifier. To (a) be consistent with all potential resolution schemes and (b) not put any undue constraints on any potential resolution scheme, the syntax for the Namespace Identifier is: ::= [ 1,31 ] ::= | | | "-" ::= | | ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" This is slightly more restrictive that what is stated in [4] (which Expires 9/30/97 [Page 2] INTERNET DRAFT URN Syntax March 1997 allows the characters "." and "+"). Further, the Namespace Identifier is case insensitive, so that "ISBN" and "isbn" refer to the same namespace. To avoid confusion with the "urn:" identifier, the NID "urn" is reserved and MUST NOT be used. 2.2 Namespace Specific String Syntax As required by RFC 1737, there is a single canonical representation of the NSS portion of an URN. The format of this single canonical form follows: ::= 1* ::= | "%" ::= | | | | ::= | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" ::= "(" | ")" | "+" | "," | "-" | "." | ":" | "=" | "@" | ";" | "$" | "_" | "!" | "*" | "'" Depending on the rules governing a namespace, valid identifiers in a namespace might contain characters that are not members of the URN character set above (). Such strings MUST be translated into canonical NSS format before using them as protocol elements or otherwise passing them on to other applications. Translation is done by encoding each character outside the URN character set as a sequence of one to six octets using UTF-8 encoding, and the encoding of each of those octets as "%" followed by two characters from the character set above. The two characters give the hexadecimal representation of that octet. 2.3 Reserved characters The remaining character set left to be discussed above is the reserved character set, which contains various characters reserved from normal use. The reserved character set follows, with a discussion on the specifics of why each character is reserved. The reserved character set is: ::= '%" | "/" | "?" | "#" Expires 9/30/97 [Page 3] INTERNET DRAFT URN Syntax March 1997 2.3.1 The "%" character The "%" character is reserved in the URN syntax for introducing the escape sequence for an octet. Literal use of the "%" character in a namespace must be encoded using "%25" in URNs for that namespace. The presence of an "%" character in an URN MUST be followed by two characters from the character set. Namespaces MAY designate one or more characters from the URN character set as having special meaning for that namespace. If the namespace also uses that character in a literal sense as well, the character used in a literal sense MUST be encoded with "%" followed by the hexadecimal representation of that octet. Further, a character MUST NOT be "%"-encoded if the character is not a reserved character. Therefore, the process of registering a namespace identifier shall include publication of a definition of which characters have a special meaning to that namespace. 2.3.2 The other reserved characters RFC 1630 [2] reserves the characters "/", "?", and "#" for particular purposes. The URN-WG has not yet debated the applicability and precise semantics of those purposes as applied to URNs. Therefore, these characters are RESERVED for future developments. Namespace developers SHOULD NOT use these characters in unencoded form, but rather use the appropriate %-encoding for each character. 2.4 Excluded characters The following list is included only for the sake of completeness. Any octets/characters on this list are explicitly NOT part of the URN character set, and if used in an URN, MUST be %encoded: ::= octets 1-32 (1-20 hex) | "\" | """ | "&" | "<" | ">" | "[" | "]" | "^" | "`" | "{" | "|" | "}" | "~" | octets 127-255 (7F-FF hex) In addition, octet 0 (0 hex) should NEVER be used, in either unencoded or %-encoded form. An URN ends when an octet/character from the excluded character set () is encountered. The character from the excluded character set is NOT part of the URN. 3. Support of existing legacy naming systems and new naming systems Any namespace (existing or newly-devised) that is proposed as an URN-namespace and fulfills the criteria of URN-namespaces MUST be Expires 9/30/97 [Page 4] INTERNET DRAFT URN Syntax March 1997 expressed in this syntax. If names in these namespaces contain characters other than those defined for the URN character set, they MUST be translated into canonical form as discussed in section 2.2. 4. URN presentation and transport The URN syntax defines the canonical format for URNs and all URN transport and interchanges MUST take place in this format. Further, all URN-aware applications MUST offer the option of displaying URNs in this canonical form to allow for direct transcription (for example by cut and paste techniques). Such applications MAY support display of URNs in a more human-friendly form and may use a character set that includes characters that aren't permitted in URN syntax as defined in this RFC (that is, they may replace %-notation by characters in some extended character set in display to humans). 5. Lexical Equivalence in URNs For various purposes such as caching, it's often desirable to determine if two URNs are the same without resolving them. The general purpose means of doing so is by testing for "lexical equivalence" as defined below. Two URNs are lexically equivalent if they are octet-by-octet equal after the following preprocessing: 1. normalize the case of the leading "urn:" token 2. normalize the case of the NID 3. normalizing the case of any %-escaping Note that %-escaping MUST NOT be removed. Some namespaces may define additional lexical equivalences, such as case-insensitivity of the NSS (or parts thereof). Additional lexical equivalences MUST be documented as part of namespace registration, MUST always have the effect of eliminating some of the false negatives obtained by the procedure above, and MUST NEVER say that two URNs are not equivalent if the procedure above says they are equivalent. 6. Examples of lexical equivalence The following URN comparisons highlight the lexical equivalence definitions: 1- URN:foo:a123,456 2- urn:foo:a123,456 3- urn:FOO:a123,456 4- urn:foo:A123,456 Expires 9/30/97 [Page 5] INTERNET DRAFT URN Syntax March 1997 5- urn:foo:a123%2C456 6- URN:FOO:a123%2c456 URNs 1, 2, and 3 are all lexically equivalent. URN 4 is not lexically equivalent any of the other URNs of the above set. URNs 5 and 6 are only lexically equivalent to each other. 7. Functional Equivalence in URNs Functional equivalence is determined by practice within a given namespace and managed by resolvers for that namespeace. Thus, it is beyond the scope of this document. Namespace registration must include guidance on how to determine functional equivalence for that namespace, i.e. when two URNs are the identical within a namespace. 8. Security considerations This document specifies the syntax for URNs. While some namespaces resolvers may assign special meaning to certain of the characters of the Namespace Specific String, any security consideration resulting from such assignment are outside the scope of this document. It is strongly recommended that the process of registering a namespace identifier include any such considerations. 9. Acknowledgments Thanks to various members of the URN working group and <> for comments on earlier drafts of this document. This document is partially supported by the National Science Foundation, Cooperative Agreement NCR-9218179. 10. References Request For Comments (RFC) and Internet Draft documents are available from and numerous mirror sites. [1] K. R. Sollins, "Requirements and a Framework for URN Resolution Systems," Internet Draft (work in progress), November 1996. [2] T. Berners-Lee, "Universal Resource Identifiers in WWW," RFC 1630, June 1994. [3] K. Sollins and L. Masinter, "Functional Require- ments for Uniform Resource Names," RFC 1737. December 1994. Expires 9/30/97 [Page 6] INTERNET DRAFT URN Syntax March 1997 [4] T. Berners-Lee, R. Fielding, L. Masinter, "Uniform Resource Locators (URL)," Internet Draft (work in progress), December 1996. 11. Editor's address Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA Phone: +1 402 894-9456 EMail: jayhawk@ds.internic.net Appendix A. Handling of URNs by URL resolvers/browsers. The URN syntax has been defined so that URNs can be used in places where URLs are expected. A resolver that conforms to the current URL syntax specification [3] will extract a scheme value of "urn:" rather than a scheme value of "urn:". An URN MUST be considered an opaque URL by URL resolvers and passed (with the "urn:" tag) to an URN resolver for resolution. The URN resolver can either be an external resolver that the URL resolver knows of, or it can be functionality built-in to the URL resolver. To avoid confusion of users, an URL browser SHOULD display the com- plete URN (including the "urn:" tag) to ensure that there is no con- fusion between URN namespace identifiers and URL scheme identifiers. This Internet Draft expires September 30, 1997. Expires 9/30/97 [Page 7] --------------33B96FF35FDA-- Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id NAA05955 for urn-ietf-out; Tue, 25 Feb 1997 13:31:02 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id NAA05948; Tue, 25 Feb 1997 13:30:58 -0500 (EST) From: touch@ISI.EDU Received: from zephyr.isi.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29768 (mail destined for urn-ietf@services.bunyip.com); Tue, 25 Feb 97 13:30:56 -0500 Received: from ash.isi.edu by zephyr.isi.edu (5.65c/5.61+local-23) id ; Tue, 25 Feb 1997 10:30:54 -0800 Date: Tue, 25 Feb 1997 10:30:49 -0800 Posted-Date: Tue, 25 Feb 1997 10:30:49 -0800 Message-Id: <199702251830.AA12562@ash.isi.edu> Received: by ash.isi.edu (5.65c/4.0.3-6) id ; Tue, 25 Feb 1997 10:30:49 -0800 To: touch@ISI.EDU, connolly@w3.org Subject: [URN] Re: URI-protocol mapping (was Re: How to add new "protocols" ?) Cc: rdaniel@acl.lanl.gov, liberte@ncsa.uiuc.edu, uri@bunyip.com, urn-ietf@bunyip.com X-Auto-Sig-Adder-By: faber@isi.edu Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: touch@ISI.EDU Errors-To: owner-urn-ietf@Bunyip.Com > From connolly%w3.org@beach.w3.org Fri Feb 21 09:39:57 1997 > > touch@ISI.EDU wrote: > > > > > OK, I'll bite: how is it that "location-dependent" vs. > > > "location-independent" is a technical distinction? > > > It's very technical. The host requirements RFC specifies locations > > as either fully-qualified DNS names or IP addresses. And that's what > > you have here. I.e., you have as much of a location as the internet > > allows. > > Ah! I wan't aware of that. I really appreciate you pointing > that out. > > OK, I'm happy with 'location-independent' as a technical > term if 'location' is defined as 'FQDN or IP > address'. I inferred the more geographic connotations. > A quick scan of the URN requirements/framework draft[1] > and the URN requirements RFC[2] doesn't > show a similar definition of 'location'. And there's > no reference to the host requirements RFC. That is a clear inconsistency. Given that HTTP/1.1 does ref it. > Hang on... I went to add it to my glossary of web > architecture terms[3], but a brief scan of the > host requirements RFC[4] shows: > > |the DNS provides globally-unique, > | location-independent names. > > If a FQDNs are locations, how does DNS provide > location-independent names? We're confusing the term location here, as is probably obvious. The DNS provides globally-unique, (geographically) location-independent names. FQDNs are locations, just not geographic ones. Joe ---------------------------------------------------------------------- Joe Touch - touch@isi.edu http://www.isi.edu/~touch/ ISI / Project Leader, ATOMIC-2, LSAM http://www.isi.edu/atomic2/ USC / Research Assistant Prof. http://www.isi.edu/lsam/ Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id KAA01689 for urn-ietf-out; Tue, 25 Feb 1997 10:50:01 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id KAA01678 for ; Tue, 25 Feb 1997 10:49:58 -0500 (EST) Received: from socrate.riq.qc.ca by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28575 (mail destined for urn-ietf@services.bunyip.com); Tue, 25 Feb 97 10:49:51 -0500 Received: from 506.riq.qc.ca (riq-44-188.riq.qc.ca) by socrate.riq.qc.ca (5.x/SMI-SVR4) id AA23158; Tue, 25 Feb 1997 10:52:55 -0500 Message-Id: <3.0.1.16.19970225104424.09e7394a@riq.qc.ca> X-Sender: alb@riq.qc.ca X-Mailer: Windows Eudora Pro Version 3.0.1 beta 8 (16) Date: Tue, 25 Feb 1997 10:44:24 To: Masataka Ohta From: "Alain LaBont/e'/" Subject: Re: [URN] Re: URL internationalization! Cc: jch@netscape.com, mduerst@ifi.unizh.ch, ietf-url@imc.org, urn-ietf@bunyip.com In-Reply-To: <199702251504.AAA08366@necom830.hpcl.titech.ac.jp> References: <3.0.1.32.19970220102436.006aadd0@riq.qc.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "Alain LaBont/e'/" Errors-To: owner-urn-ietf@Bunyip.Com A 00:03 97-02-26 JST, Masataka Ohta a icrit : [Alain LaBonti] : >> Turkish is probably the worst case btw. Turkish uses the latin script but... [Masataka Ohta] : >These days, there are annoying live demonstrations in ietf ML that >Turkish is just fine with ASCII. Have you done something? [Alain LaBonti] : No, I am not aware of this. But I know that the Turks would not agree. It is one of the best examples to show that ASCII is unsuited to represent the whole Latin script. [Masataka Ohta] : >> If they pronounce it they have it wrong all the time. On a speakerphone in >> an airport a Turk might not recognize his/her own name. [Masataka Ohta] : >??? How can the speakerphone operator pronounce my name written in >Kanji? [Alain] : The sub-thread (a perenthesis open by Jan, pronounced Yan) of this discussion, I believe, dealt with the use of the International Phonetic Alphabet for machine-readable passports or for airline tickets. I said that I supported that idea fully, implicitly regreting that it is utopic (but I believe in Utopia sometimes (: ) Of course Kanji is a problem as even a Japanese needs to be initiated to transform it into kana. That is not the point. Kanji should be allowed in URLs though, as I believe in the use of *a* universal character set reproducible everywhere on earth, temporarily with a fallback if necessary. But to come back to the sub-thread, with the IPA any human-pronounceable sound can be represented, your name as well as the most delightful Cockney accent in English. Its use would make all humans equal as far as name pronunciation is involved. It could even be represented in some URLs (: Alain LaBonti (pronounce LaBontay - also note that "ain" and "on" are pure nasal vowel sounds, not diphthongs! and these sounds can't be represented in ASCII without long explanations on how to reconfigure your internal mouth and tongue (: ) Quibec (pronounce Kaybec, even in standard English!) Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id KAA28611 for urn-ietf-out; Tue, 25 Feb 1997 10:07:07 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id KAA28599 for ; Tue, 25 Feb 1997 10:07:03 -0500 (EST) Received: from [131.112.32.132] by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28223 (mail destined for urn-ietf@services.bunyip.com); Tue, 25 Feb 97 10:07:00 -0500 From: Masataka Ohta Message-Id: <199702251504.AAA08366@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id AAA08366; Wed, 26 Feb 1997 00:03:47 +0859 Subject: Re: [URN] Re: URL internationalization! To: alb@riq.qc.ca (Alain LaBont/e'/) Date: Wed, 26 Feb 97 0:03:46 JST Cc: mohta@necom830.hpcl.titech.ac.jp, jch@netscape.com, alb@sct.gouv.qc.ca, mduerst@ifi.unizh.ch, ietf-url@imc.org, urn-ietf@bunyip.com In-Reply-To: <3.0.1.32.19970220102436.006aadd0@riq.qc.ca>; from "Alain LaBont/e'/" at Feb 20, 97 10:25 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Masataka Ohta Errors-To: owner-urn-ietf@Bunyip.Com Alain LaBont; > [Masataka Otha]: > >Look at international airline tickets of people from France, Japan, > >Thai, Arab and India and tell me what is wrong. > > [Alain LaBont: > I don't know for others (I suspect that it is not good either) but my name > is not respected when LABONTE is written on my airline ticket. When my name is written in Kanji on international airine ticket, I can't use the ticket outside of Japan. > In fact as > it is not considered transliteration Of course, it is not transliteration but just a formal notation of Airline operators. > Turkish is probably the worst case btw. Turkish uses the latin script but... These days, there are annoying live demonstrations in ietf ML that Turkish is just fine with ASCII. Have you done something? > If they pronounce it they have it wrong all the time. On a speakerphone in > an airport a Turk might not recognize his/her own name. ??? How can the speakerphone operator pronounce my name written in Kanji? Masataka Ohta Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id MAA03942 for urn-ietf-out; Fri, 21 Feb 1997 12:39:59 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id MAA03937; Fri, 21 Feb 1997 12:39:47 -0500 (EST) Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04329 (mail destined for urn-ietf@services.bunyip.com); Fri, 21 Feb 97 12:39:46 -0500 Received: from beach.w3.org by MINTAKA.LCS.MIT.EDU id aa04054; 21 Feb 97 12:21 EST Message-Id: <330DD97C.D6F7D91@w3.org> Date: Fri, 21 Feb 1997 11:21:00 -0600 From: Dan Connolly Organization: World Wide Web Consortium X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.18 i586) Mime-Version: 1.0 To: touch@ISI.EDU Cc: rdaniel@acl.lanl.gov, liberte@ncsa.uiuc.edu, uri@bunyip.com, urn-ietf@bunyip.com Subject: [URN] Re: URI-protocol mapping (was Re: How to add new "protocols" ?) References: <199702211554.AA05345@ash.isi.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Dan Connolly Errors-To: owner-urn-ietf@Bunyip.Com touch@ISI.EDU wrote: > > > OK, I'll bite: how is it that "location-dependent" vs. > > "location-independent" is a technical distinction? > It's very technical. The host requirements RFC specifies locations > as either fully-qualified DNS names or IP addresses. And that's what > you have here. I.e., you have as much of a location as the internet > allows. Ah! I wan't aware of that. I really appreciate you pointing that out. OK, I'm happy with 'location-independent' as a technical term if 'location' is defined as 'FQDN or IP address'. I inferred the more geographic connotations. I want that in the specs though. If I didn't know it, I'm sure lots of other folks didn't know it. A quick scan of the URN requirements/framework draft[1] and the URN requirements RFC[2] doesn't show a similar definition of 'location'. And there's no reference to the host requirements RFC. Hang on... I went to add it to my glossary of web architecture terms[3], but a brief scan of the host requirements RFC[4] shows: |the DNS provides globally-unique, | location-independent names. If a FQDNs are locations, how does DNS provide location-independent names? In fact, I don't see this definition of location that you refer to at all in the host requirements RFC[4]. Could you elaborate? [1] ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-req-frame-00.txt [2] http://ds.internic.net/rfc/rfc1737.txt [3] http://www.w3.org/pub/WWW/Architecture/Terms [4] ftp://ftp.math.utah.edu/pub/rfc/rfc1123.txt Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id FAA24326 for urn-ietf-out; Fri, 21 Feb 1997 05:09:43 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id FAA24321 for ; Fri, 21 Feb 1997 05:09:40 -0500 (EST) Received: from [131.112.32.132] by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00157 (mail destined for urn-ietf@services.bunyip.com); Fri, 21 Feb 97 05:09:38 -0500 From: Masataka Ohta Message-Id: <199702211007.TAA15352@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA15352; Fri, 21 Feb 1997 19:07:00 +0900 Subject: [URN] Re: URL internationalization! To: Jonathan_Rosenne@compuserve.com (Jonathan Rosenne) Date: Fri, 21 Feb 97 19:06:59 JST Cc: mohta@necom830.hpcl.titech.ac.jp, urn-ietf@bunyip.com, ietf-url@imc.org In-Reply-To: <199702200959_MC2-1183-775B@compuserve.com>; from "Jonathan Rosenne" at Feb 20, 97 9:59 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Masataka Ohta Errors-To: owner-urn-ietf@Bunyip.Com > >ASCII script is rich enough to denote French, Japanese, Thai, > >Arabic, Hindi... > > How would you denote Arabic in ASCII? ??? > Arabic has more consonants than ASCII > has letters. So does English. Can you pronounce "th", "sh", "ch", "ng"... Masataka Ohta Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id MAA08037 for urn-ietf-out; Thu, 20 Feb 1997 12:42:26 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id MAA08032 for ; Thu, 20 Feb 1997 12:42:24 -0500 (EST) From: jayhawk@ds.internic.net Received: from cagw2.att.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23987 (mail destined for urn-ietf@services.bunyip.com); Thu, 20 Feb 97 12:42:21 -0500 Received: from qsun.ho.att.com by caig2.att.att.com (SMI-8.6/EMS-1.2 sol2) id OAA09078; Wed, 19 Feb 1997 14:25:47 -0500 Received: from sloop (rickslap.ho.att.com) by qsun.ho.att.com (4.1/EMS-1.1.1 SunOS) id AA20092; Wed, 19 Feb 97 14:20:29 EST Message-Id: <330B52BC.69FB@ds.internic.net> Date: Wed, 19 Feb 1997 14:21:32 -0500 Original-From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 2.02E (OS/2; I) Mime-Version: 1.0 To: Leslie Daigle Cc: urn-ietf@bunyip.com Subject: [URN] URN Mailing List Archives.... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: jayhawk@ds.internic.net Errors-To: owner-urn-ietf@Bunyip.Com Leslie (and all the URN folks)- To help me find previous mail on various topics (especially related to repeat issues on the syntax draft ;-) I have set up a mirror of the URN mailing list archives from bunyip.com to the various ds.internic.net machines. These mirrored archives are available from http://ds.internic.net/ietf/urn/urn-archives ftp://ds.internic.net/ietf/urn/urn-archives Further, these archives are searchable by WAIS. To search these archives, either 1. Telnet to any ds.internic.net machine, log in as user "wais" and search the database urn-mail-archives, or 2. Use the WWW interface at http://ds.internic.net/ds/urnwais.html Hope others find this as useful as I have (now that most of the kinks are out of it) Ryan Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id KAA04662 for urn-ietf-out; Thu, 20 Feb 1997 10:27:18 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id KAA04657 for ; Thu, 20 Feb 1997 10:27:15 -0500 (EST) Received: from socrate.riq.qc.ca by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22466 (mail destined for urn-ietf@services.bunyip.com); Thu, 20 Feb 97 10:27:10 -0500 Received: from alain-labont- (riq-44-132.riq.qc.ca) by socrate.riq.qc.ca (5.x/SMI-SVR4) id AA27489; Thu, 20 Feb 1997 10:29:58 -0500 Message-Id: <3.0.1.32.19970220102436.006aadd0@riq.qc.ca> X-Sender: alb@riq.qc.ca (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 beta 3 (32) Date: Thu, 20 Feb 1997 10:25:26 -0500 To: Masataka Ohta , jch@netscape.com (YON - Jan C. Hardenbergh) From: "Alain LaBont/e'/" Subject: Re: [URN] Re: URL internationalization! Cc: mohta@necom830.hpcl.titech.ac.jp, alb@sct.gouv.qc.ca, mduerst@ifi.unizh.ch, ietf-url@imc.org, urn-ietf@bunyip.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "Alain LaBont/e'/" Errors-To: owner-urn-ietf@Bunyip.Com A 14:50 97-02-20 JST, Masataka Ohta a icrit : >> > ASCII script is rich enough to denote French, Japanese, Thai, >> > Arabic, Hindi... [Jan C. Hardenbergh]: >> This is just wrong! [Masataka Otha]: >Look at international airline tickets of people from France, Japan, >Thai, Arab and India and tell me what is wrong. [Alain LaBonti]: I don't know for others (I suspect that it is not good either) but my name is not respected when LABONTE is written on my airline ticket. In fact as it is not considered transliteration (it is downgrading the same script) it is even more wrong than transliteration from another script to the Latin. Turkish is probably the worst case btw. Turkish uses the latin script but... If they try to match this with a database, they have trouble all the time. If they pronounce it they have it wrong all the time. On a speakerphone in an airport a Turk might not recognize his/her own name. There is a movement to have OCR-B modified on machine-readable passports because this using of the plain English alphabet is a mess. Personally I would prefer to use the plain IPA to make all people of the earth equal if we were *not to use* a canonical universal characater set. Furthermore expected pronounciation for teh main interested people could be perfectly rendered by a machine. Alain LaBonti Quibec Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id KAA04601 for urn-ietf-out; Thu, 20 Feb 1997 10:24:31 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id KAA04591 for ; Thu, 20 Feb 1997 10:24:26 -0500 (EST) Received: from ietf.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22453 (mail destined for urn-ietf@services.bunyip.com); Thu, 20 Feb 97 10:24:24 -0500 Received: from ietf.ietf.org by ietf.org id aa01564; 20 Feb 97 9:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: urn-ietf@bunyip.com From: Internet-Drafts@ietf.org Subject: [URN] I-D ACTION:draft-ietf-urn-http-conv-01.txt Date: Thu, 20 Feb 1997 09:35:17 -0500 Message-Id: <9702200935.aa01564@ietf.org> Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Internet-Drafts@ietf.org Errors-To: owner-urn-ietf@Bunyip.Com --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : A Trivial Convention for using HTTP in URN Resolution Author(s) : R. Daniel Filename : draft-ietf-urn-http-conv-01.txt Pages : 6 Date : 02/19/1997 The Uniform Resource Names Working Group (URN-WG) was formed to specify persistent, location-independent names for network accessible resources, as well as resolution mechanisms to retrieve the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal [1]. That proposal specifies how a client may find a "resolver" for a URN. A resolver is a database that can provide information about the resource identified by a URN, such as the resource's location, a bibliographic description, or even the resource itself. The protocol used for the client to communicate with the resolver is not specified in the NAPTR proposal. Instead, the NAPTR resource record provides a field that indicates the "resolution protocol" and "resolution service requests" offered by the resolver. This document specifies the "THTTP" resolution protocol - a trivial convention for encoding resolution service requests and responses as HTTP 1.0 or 1.1 requests and responses. The primary goal of THTTP is to be simple to implement so that existing HTTP servers may easily add support for URN resolution. We expect that the databases used by early resolvers will be useful when more sophisticated esolution protocols are developed later. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-http-conv-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-http-conv-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-http-conv-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970219105545.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-http-conv-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-http-conv-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219105545.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id KAA04597 for urn-ietf-out; Thu, 20 Feb 1997 10:24:29 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id KAA04589 for ; Thu, 20 Feb 1997 10:24:26 -0500 (EST) Received: from ietf.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22451 (mail destined for urn-ietf@services.bunyip.com); Thu, 20 Feb 97 10:24:24 -0500 Received: from ietf.ietf.org by ietf.org id aa01526; 20 Feb 97 9:35 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: urn-ietf@bunyip.com From: Internet-Drafts@ietf.org Subject: [URN] I-D ACTION:draft-ietf-urn-naptr-02.txt Date: Thu, 20 Feb 1997 09:35:12 -0500 Message-Id: <9702200935.aa01526@ietf.org> Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Internet-Drafts@ietf.org Errors-To: owner-urn-ietf@Bunyip.Com --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Resolution of Uniform Resource Identifiers using the Domain Name System Author(s) : R. Daniel, M. Mealling Filename : draft-ietf-urn-naptr-02.txt Pages : 14 Date : 02/19/1997 Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-naptr-02.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-02.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: ftp.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-naptr-02.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19970219104118.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-naptr-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-naptr-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19970219104118.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id KAA03843 for urn-ietf-out; Thu, 20 Feb 1997 10:06:15 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id KAA03836 for ; Thu, 20 Feb 1997 10:06:12 -0500 (EST) Received: from socrate.riq.qc.ca by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22273 (mail destined for urn-ietf@services.bunyip.com); Thu, 20 Feb 97 10:06:09 -0500 Received: from alain-labont- (riq-44-132.riq.qc.ca) by socrate.riq.qc.ca (5.x/SMI-SVR4) id AA24765; Thu, 20 Feb 1997 10:08:21 -0500 Message-Id: <3.0.1.32.19970220100300.006a1d4c@riq.qc.ca> X-Sender: alb@riq.qc.ca (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 beta 3 (32) Date: Thu, 20 Feb 1997 10:03:27 -0500 To: Masataka Ohta , alb@sct.gouv.qc.ca (Alain LaBont/e'/) From: "Alain LaBont/e'/" Subject: [URN] Re: URL internationalization! Cc: mohta@necom830.hpcl.titech.ac.jp, mduerst@ifi.unizh.ch, ietf-url@imc.org, urn-ietf@bunyip.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "Alain LaBont/e'/" Errors-To: owner-urn-ietf@Bunyip.Com A 12:49 97-02-20 JST, Masataka Ohta a icrit : >If you don't want to insulate yourself within ISO-8859-1 community, >don't use ISO-8859-1. I am surprised that you said in an earlier note that you say ISO/IEC 2022 is not a problem and that you can't process ISO/IEC 8859-1 which is just a subset of ISO/IEC 2022 code extension etchnique. If you support ISO/IEC 2022 you have to support all of the ISO/IEC SC2 character set registry. You have to go to the limit of your own arguments. >The more conservative you send, the more people can read it. > >ASCII script is rich enough to denote French, Japanese, Thai, >Arabic, Hindi... How do you distinguish in ASCII: ENFANTS LEGITIMES DE LOUIS XIV and ENFANTS LIGITIMIS DE LOUIS XIV ? Just curious... French can't be vehicled in ASCII. Period. I must also tell you that you mix "script" and "character set". ASCII is a character set, the Latin characters are a script. The Latin script includes many more characters than the character repertoire of ASCII. Alain LaBonti Quibec Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id KAA03539 for urn-ietf-out; Thu, 20 Feb 1997 10:00:28 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id KAA03534 for ; Thu, 20 Feb 1997 10:00:26 -0500 (EST) Received: from hil-img-6.compuserve.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22186 (mail destined for urn-ietf@services.bunyip.com); Thu, 20 Feb 97 10:00:25 -0500 Received: by hil-img-6.compuserve.com (8.6.10/5.950515) id JAA26722; Thu, 20 Feb 1997 09:59:49 -0500 Date: Thu, 20 Feb 1997 09:59:07 -0500 From: Jonathan Rosenne Subject: [URN] Re: URL internationalization! To: Masataka Ohta Cc: URN List , URL List Message-Id: <199702200959_MC2-1183-775B@compuserve.com> Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Jonathan Rosenne Errors-To: owner-urn-ietf@Bunyip.Com >ASCII script is rich enough to denote French, Japanese, Thai, >Arabic, Hindi... How would you denote Arabic in ASCII? Arabic has more consonants than ASCII has letters. Jonathan Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id JAA03360 for urn-ietf-out; Thu, 20 Feb 1997 09:57:26 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id JAA03355 for ; Thu, 20 Feb 1997 09:57:23 -0500 (EST) Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22122 (mail destined for urn-ietf@services.bunyip.com); Thu, 20 Feb 97 09:57:20 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <26462-0@josef.ifi.unizh.ch>; Thu, 20 Feb 1997 15:57:22 +0100 Date: Thu, 20 Feb 1997 15:57:21 +0100 (MET) From: "Martin J. Duerst" To: Masataka Ohta Cc: "YON - Jan C. Hardenbergh" , alb@sct.gouv.qc.ca, ietf-url@imc.org, urn-ietf@bunyip.com Subject: Re: [URN] Re: URL internationalization! In-Reply-To: <199702200550.OAA12558@necom830.hpcl.titech.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@Bunyip.Com Masataka - > Multi-language support is doable with ASCII only and is orthogonal > to multi-script support. A very crude multilingual support is doable with the basic Latin script only. And at some point, there were even people that claimed that all languages would have to switch to it to keep up with computer technology. But actually, computer technology has improved a lot, and this is no longer necessary nor desirable. > > Besides, all you ASCII lovers should be exceptionally excited by > > Martin's proposal because ASCII is a subset of utf8 (RFC 2044) > > No, not at all. ISO-2022-{JP, KR, CN, JP-2} are all supersets > of ASCII and better than utf8 in all aspects. Definitely not. I already mentionned several serious problems with ISO-2022. I got reminded here of one I forgot, but which is rather crucial: - ISO-2022 interferes with URL reserved characters. ISO-2022-JP, for example, can contain, in stretches that encode Japanese characters, octets with the same values as "/" or "#" and so on. > UTF8 is not a proper charset at all. Look at RFC 1815 on how > to construct proper charsets from ISO 10646. There is nothing in the relevant definitions of MIME "charset"s that prescribes that a sender or receiver would be required to display all of the characters that can be encoded with a given "charset". Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id JAA03339 for urn-ietf-out; Thu, 20 Feb 1997 09:57:09 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id JAA03330 for ; Thu, 20 Feb 1997 09:57:04 -0500 (EST) Received: from socrate.riq.qc.ca by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22118 (mail destined for urn-ietf@services.bunyip.com); Thu, 20 Feb 97 09:56:58 -0500 Received: from alain-labont- (riq-44-132.riq.qc.ca) by socrate.riq.qc.ca (5.x/SMI-SVR4) id AA23591; Thu, 20 Feb 1997 10:00:32 -0500 Message-Id: <3.0.1.32.19970220095510.006a1cf0@riq.qc.ca> X-Sender: alb@riq.qc.ca (Unverified) X-Mailer: Windows Eudora Pro Version 3.0.1 beta 3 (32) Date: Thu, 20 Feb 1997 09:55:34 -0500 To: Masataka Ohta From: "Alain LaBont/e'/" Subject: [URN] Re: URL internationalization! Cc: mohta@necom830.hpcl.titech.ac.jp, mduerst@ifi.unizh.ch, ietf-url@imc.org, urn-ietf@bunyip.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "Alain LaBont/e'/" Errors-To: owner-urn-ietf@Bunyip.Com A 12:49 97-02-20 JST, Masataka Ohta m'a icrit : >The current detouring attempt of Unicode/ISO 10646 on local script >support is that they are confusing people like you with no real >internationzalization expertise not to be able to distinguish >"language" and "script". For your information I've been working on internationalization for more than 10 yers and I am project editor of international standards in the field, member of ISO/IEC JTC1/SC22/WG20 (internationalization of applications). You're invited to join the international team of ISO on the subject, most welcome. I know perfectly well the difference between script and language, between character set and glyph and so on... that said promoting a worldwide canonical character set definitely has to do with internationalization. Alain LaBonti Quibec Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id CAA16749 for urn-ietf-out; Thu, 20 Feb 1997 02:09:18 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id CAA16744 for ; Thu, 20 Feb 1997 02:09:15 -0500 (EST) Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20725 (mail destined for urn-ietf@services.bunyip.com); Thu, 20 Feb 97 02:08:44 -0500 Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <16604(1)>; Wed, 19 Feb 1997 22:14:51 PST Received: from palimpsest ([127.0.0.1]) by palimpsest.parc.xerox.com with SMTP id <242>; Wed, 19 Feb 1997 22:12:47 PDT Message-Id: <330BEB5E.2420@parc.xerox.com> Date: Wed, 19 Feb 1997 21:12:46 PST From: Larry Masinter Organization: Xerox PARC X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 5.5.1 sun4u) Mime-Version: 1.0 To: "YON - Jan C. Hardenbergh" Cc: Masataka Ohta , alb@sct.gouv.qc.ca, mduerst@ifi.unizh.ch, ietf-url@imc.org, urn-ietf@bunyip.com Subject: Re: [URN] Re: URL internationalization! References: <199702200550.OAA12558@necom830.hpcl.titech.ac.jp> <330BE868.6D1@netscape.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@Bunyip.Com Folks, This particular flame war belongs on uri@bunyip.com, which is the only forum for discussion of the URL generic syntax document. Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id BAA16278 for urn-ietf-out; Thu, 20 Feb 1997 01:19:24 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id BAA16273 for ; Thu, 20 Feb 1997 01:19:21 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20598 (mail destined for urn-ietf@services.bunyip.com); Thu, 20 Feb 97 01:19:18 -0500 From: Masataka Ohta Message-Id: <199702200616.PAA12667@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id PAA12667; Thu, 20 Feb 1997 15:16:00 +0900 Subject: Re: [URN] Re: URL internationalization! To: jch@netscape.com (YON - Jan C. Hardenbergh) Date: Thu, 20 Feb 97 15:15:59 JST Cc: mohta@necom830.hpcl.titech.ac.jp, alb@sct.gouv.qc.ca, mduerst@ifi.unizh.ch, ietf-url@imc.org, urn-ietf@bunyip.com In-Reply-To: <330BE868.6D1@netscape.com>; from "YON - Jan C. Hardenbergh" at Feb 19, 97 10:00 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Masataka Ohta Errors-To: owner-urn-ietf@Bunyip.Com YON > > > > ASCII script is rich enough to denote French, Japanese, Thai, > > > > Arabic, Hindi... > > > > > > This is just wrong! > > > > Look at international airline tickets of people from France, Japan, > > Thai, Arab and India and tell me what is wrong. > > I was trying to decipher my airline ticket the other day. The first > problem is that NO ONE can pronounce anyone's name. Very good point. Still, anyone can transcribe your name. Don't make NO ONE can pronouce nor transcibe anyone's URL. > Living in the US > with a name like Jan makes this a hot button for me. Does "Jan" contain non-ASCII characters? > > We are not interested in transcribing pronounciation of various > > language to the accuracy of IPA, which is sometimes excessive > > and somtimes insufficient. > > Show me the way. Of what? > > Each language already has its own denotation system in basic 26 > > Latin alphabets, most, if not all, of them are unrelated to IPA. > > Spec'd by whom? In Japan, it's ministry of foreign affairs. You should ask airline office. > > Multi-language support is doable with ASCII only and is orthogonal > > to multi-script support. > > ??? Let's see the following Japanese translation of my sentence above: Maruchi ringaru sapohto ha asukii dakede dekirunode atte, maruchi sukuriputo sapohto toha chokkou suru gainen da. which is a sentence of Japanese language with Latin script. That is, this mail is a bi-lingual mail with ASCII only. > > > Besides, all you ASCII lovers should be exceptionally excited by > > > Martin's proposal because ASCII is a subset of utf8 (RFC 2044) > > > > No, not at all. ISO-2022-{JP, KR, CN, JP-2} are all supersets > > of ASCII and better than utf8 in all aspects. > > Font management with ISO 2022 is intractable! Wrong. It is only that whether some font is available or not. So is ISO 10646. Read RFC 1815. And, it is usually the case that when someone does not have a font of some character, that person can't read the character, anyway. Still, I can type "Jan". Isn't it a great multilingual monoscript internationalization accomplished by ASCII? > > UTF8 is not a proper charset at all. Look at RFC 1815 on how > > to construct proper charsets from ISO 10646. > > Of course utf8 is not a charset. It is an encoding of ISO 10646. Absolutely. Masataka Ohta Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id BAA16182 for urn-ietf-out; Thu, 20 Feb 1997 01:00:29 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id BAA16177 for ; Thu, 20 Feb 1997 01:00:25 -0500 (EST) Received: from h-205-217-237-33.netscape.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20497 (mail destined for urn-ietf@services.bunyip.com); Thu, 20 Feb 97 01:00:23 -0500 Received: from mmx-inside.mcom.com (h-207-1-145-164.mcom.com [207.1.145.164]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id VAA29918; Wed, 19 Feb 1997 21:59:40 -0800 (PST) Message-Id: <330BE868.6D1@netscape.com> Date: Wed, 19 Feb 1997 22:00:08 -0800 From: "YON - Jan C. Hardenbergh" Organization: Netscape Communications X-Mailer: Mozilla 3.01 (Win95; U) Mime-Version: 1.0 To: Masataka Ohta Cc: alb@sct.gouv.qc.ca, mduerst@ifi.unizh.ch, ietf-url@imc.org, urn-ietf@bunyip.com Subject: Re: [URN] Re: URL internationalization! References: <199702200550.OAA12558@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "YON - Jan C. Hardenbergh" Errors-To: owner-urn-ietf@Bunyip.Com Masataka Ohta wrote: > > > > ASCII script is rich enough to denote French, Japanese, Thai, > > > Arabic, Hindi... > > > > This is just wrong! > > Look at international airline tickets of people from France, Japan, > Thai, Arab and India and tell me what is wrong. I was trying to decipher my airline ticket the other day. The first problem is that NO ONE can pronounce anyone's name. Living in the US with a name like Jan makes this a hot button for me. > > Perhaps, if you used the ASCII hacking of the IPA, I could go along > > with that. > > No, we don't. > > We are not interested in transcribing pronounciation of various > language to the accuracy of IPA, which is sometimes excessive > and somtimes insufficient. Show me the way. > Each language already has its own denotation system in basic 26 > Latin alphabets, most, if not all, of them are unrelated to IPA. Spec'd by whom? > Multi-language support is doable with ASCII only and is orthogonal > to multi-script support. ??? > > Besides, all you ASCII lovers should be exceptionally excited by > > Martin's proposal because ASCII is a subset of utf8 (RFC 2044) > > No, not at all. ISO-2022-{JP, KR, CN, JP-2} are all supersets > of ASCII and better than utf8 in all aspects. Font management with ISO 2022 is intractable! > UTF8 is not a proper charset at all. Look at RFC 1815 on how > to construct proper charsets from ISO 10646. Of course utf8 is not a charset. It is an encoding of ISO 10646. YON Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id AAA16144 for urn-ietf-out; Thu, 20 Feb 1997 00:53:58 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id AAA16139 for ; Thu, 20 Feb 1997 00:53:51 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20446 (mail destined for urn-ietf@services.bunyip.com); Thu, 20 Feb 97 00:53:47 -0500 From: Masataka Ohta Message-Id: <199702200550.OAA12558@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id OAA12558; Thu, 20 Feb 1997 14:50:36 +0900 Subject: Re: [URN] Re: URL internationalization! To: jch@netscape.com (YON - Jan C. Hardenbergh) Date: Thu, 20 Feb 97 14:50:35 JST Cc: mohta@necom830.hpcl.titech.ac.jp, alb@sct.gouv.qc.ca, mduerst@ifi.unizh.ch, ietf-url@imc.org, urn-ietf@bunyip.com In-Reply-To: <330BDBF3.E4F@netscape.com>; from "YON - Jan C. Hardenbergh" at Feb 19, 97 9:06 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Masataka Ohta Errors-To: owner-urn-ietf@Bunyip.Com > > ASCII script is rich enough to denote French, Japanese, Thai, > > Arabic, Hindi... > > This is just wrong! Look at international airline tickets of people from France, Japan, Thai, Arab and India and tell me what is wrong. > Perhaps, if you used the ASCII hacking of the IPA, I could go along > with that. No, we don't. We are not interested in transcribing pronounciation of various language to the accuracy of IPA, which is sometimes excessive and somtimes insufficient. Each language already has its own denotation system in basic 26 Latin alphabets, most, if not all, of them are unrelated to IPA. Multi-language support is doable with ASCII only and is orthogonal to multi-script support. > Besides, all you ASCII lovers should be exceptionally excited by > Martin's proposal because ASCII is a subset of utf8 (RFC 2044) No, not at all. ISO-2022-{JP, KR, CN, JP-2} are all supersets of ASCII and better than utf8 in all aspects. UTF8 is not a proper charset at all. Look at RFC 1815 on how to construct proper charsets from ISO 10646. Masataka Ohta Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id AAA15782 for urn-ietf-out; Thu, 20 Feb 1997 00:12:26 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id AAA15777 for ; Thu, 20 Feb 1997 00:12:23 -0500 (EST) Received: from h-205-217-237-33.netscape.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20143 (mail destined for urn-ietf@services.bunyip.com); Thu, 20 Feb 97 00:12:17 -0500 Received: from mmx-inside.mcom.com (h-207-1-145-164.mcom.com [207.1.145.164]) by starfish.netscape.com (8.7.5/8.7.3) with SMTP id VAA29155; Wed, 19 Feb 1997 21:06:32 -0800 (PST) Message-Id: <330BDBF3.E4F@netscape.com> Date: Wed, 19 Feb 1997 21:06:59 -0800 From: "YON - Jan C. Hardenbergh" Organization: Netscape Communications X-Mailer: Mozilla 3.01 (Win95; U) Mime-Version: 1.0 To: Masataka Ohta Cc: "Alain LaBont/e'/" , mduerst@ifi.unizh.ch, ietf-url@imc.org, urn-ietf@bunyip.com Subject: Re: [URN] Re: URL internationalization! References: <199702200350.MAA12140@necom830.hpcl.titech.ac.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "YON - Jan C. Hardenbergh" Errors-To: owner-urn-ietf@Bunyip.Com > ASCII script is rich enough to denote French, Japanese, Thai, > Arabic, Hindi... This is just wrong! Perhaps, if you used the ASCII hacking of the IPA, I could go along with that. http://www.arts.gla.ac.uk/IPA/ipa.html Besides, all you ASCII lovers should be exceptionally excited by Martin's proposal because ASCII is a subset of utf8 (RFC 2044) IPA: YON ASCII: Jan C. Hardenbergh Vanity: www.jch.com/~jch/ Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id WAA14648 for urn-ietf-out; Wed, 19 Feb 1997 22:53:06 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id WAA14630 for ; Wed, 19 Feb 1997 22:52:57 -0500 (EST) Received: from [131.112.32.132] by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19914 (mail destined for urn-ietf@services.bunyip.com); Wed, 19 Feb 97 22:52:53 -0500 From: Masataka Ohta Message-Id: <199702200350.MAA12140@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA12140; Thu, 20 Feb 1997 12:49:55 +0859 Subject: [URN] Re: URL internationalization! To: alb@sct.gouv.qc.ca (Alain LaBont/e'/) Date: Thu, 20 Feb 97 12:49:54 JST Cc: mohta@necom830.hpcl.titech.ac.jp, mduerst@ifi.unizh.ch, ietf-url@imc.org, urn-ietf@bunyip.com In-Reply-To: <9702191437.AA00032@socrate.riq.qc.ca>; from "Alain LaBont/e'/" at Feb 19, 97 9:37 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Masataka Ohta Errors-To: owner-urn-ietf@Bunyip.Com Alain; > The moral of the story is that we ought to use a worlwide character set > where even Japanese characters are integrity-preserved everywhere! It has nothing to do with URL internationalization. We don't use worldwide characters on our international airline tickets. > Any > language can be used internationally, not only English. The issue is not language, but script. ASCII-only Latin script is perfectly fine as a formal notation of, say, Japanese. For example, Japanese sentence "Doumo" in ASCII means "Hi" in English. > We should not detour > the issue. OK. The current detouring attempt of Unicode/ISO 10646 on local script support is that they are confusing people like you with no real internationzalization expertise not to be able to distinguish "language" and "script". So, if you don't want to detour, never say "language-tag" when what you need is "script-tag", which is MIME charset. > The net result to use ASCII worldwide plus a local character set > only on a cultural island would be that English would dominate everywhere > and other languages at a major disadvantage. Sure. That's exactly why Unicde/ISO 10646 is no good. But, it has nothing to do with the attempt of URL localization. > This is not what I call > internationalization, that is insularization. If you don't want to insulate yourself within ISO-8859-1 community, don't use ISO-8859-1. The more conservative you send, the more people can read it. ASCII script is rich enough to denote French, Japanese, Thai, Arabic, Hindi... > The main moral of the story is that ASCII is not the solution! ASCII is not the solution of plain text internationalization to support mixed multiple scripts, nor is ISO 10646. But, it has nothing to do with the fact that localized URLs are agaist internationalization. Masataka Ohta Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id MAA21954 for urn-ietf-out; Wed, 19 Feb 1997 12:24:33 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id MAA21918 for ; Wed, 19 Feb 1997 12:24:16 -0500 (EST) Received: from socrate.riq.qc.ca by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12303 (mail destined for urn-ietf@services.bunyip.com); Wed, 19 Feb 97 09:22:51 -0500 Received: from 506.riq.qc.ca (riq-44-162.riq.qc.ca) by socrate.riq.qc.ca (5.x/SMI-SVR4) id AA28609; Wed, 19 Feb 1997 09:27:04 -0500 Date: Wed, 19 Feb 1997 09:27:04 -0500 Message-Id: <9702191427.AA28609@socrate.riq.qc.ca> X-Sender: alb@riq.qc.ca X-Mailer: Eudora Light pour Windows Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: "Martin J. Duerst" , Masataka Ohta From: "Alain LaBont/e'/" Subject: [URN] Re: URL internationalization! Cc: ietf-url@imc.org, urn-ietf@bunyip.com Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "Alain LaBont/e'/" Errors-To: owner-urn-ietf@Bunyip.Com @ 11:09 97-02-19 +0100, Martin J. Duerst icrit : >Masataka - > >On Wed, 19 Feb 1997, you wrote: > >> Alain; >> >> > In Canada that is done all the time... there are URLs in newspapers (in >> > English and in French), on all TV channels (in many languages), in email >> > (many languages too), on the radio networks (polyglot), through our ears >> > (also polyglot (: )... We have to type, transcribe and mail URLs all the time. >> > >> > So I do not understand the objection to Martin D|rst. >> >> Because you haven't read Martin. You don't have to, though. He >> said you are not doing that. > >No, I didn't say so. What I said is that the practice of using >characters besides ASCII without a specification of how the >server will interpret them is not guaranteed to work. In the >case of Canada, it will work in many cases because iso-8859-1 >is well established there in the context of the web. However, >it will not work worldwide. Right. That is why I support the idea that you submitted, Martin, that we decide for a canonical worldwide character set for URLs. It should be supported everywhere, and if display can't be done temporarily, that data integrity be preserved at all time so that at some point, copies of copies of copies will fall on the desk of somebody who can display. Copies should be able to be cut-and-pasted and preserved integrity too. Keyboarding is useful requirement too. There is a standard for this, ISO/IEC 14755. Alain LaBonti Quibec Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id MAA21944 for urn-ietf-out; Wed, 19 Feb 1997 12:24:30 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id MAA21927 for ; Wed, 19 Feb 1997 12:24:22 -0500 (EST) Received: from socrate.riq.qc.ca by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12382 (mail destined for urn-ietf@services.bunyip.com); Wed, 19 Feb 97 09:35:36 -0500 Received: from 506.riq.qc.ca (riq-44-162.riq.qc.ca) by socrate.riq.qc.ca (5.x/SMI-SVR4) id AA00032; Wed, 19 Feb 1997 09:37:07 -0500 Date: Wed, 19 Feb 1997 09:37:07 -0500 Message-Id: <9702191437.AA00032@socrate.riq.qc.ca> X-Sender: alb@riq.qc.ca X-Mailer: Eudora Light pour Windows Version 1.5.2 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit To: Masataka Ohta , mduerst@ifi.unizh.ch (Martin J. Duerst) From: "Alain LaBont/e'/" Subject: [URN] Re: URL internationalization! Cc: mohta@necom830.hpcl.titech.ac.jp, ietf-url@imc.org, urn-ietf@bunyip.com Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "Alain LaBont/e'/" Errors-To: owner-urn-ietf@Bunyip.Com At 19:31 97-02-19 JST, Masataka Ohta wrote: >> No, I didn't say so. What I said is that the practice of using >> characters besides ASCII without a specification of how the >> server will interpret them is not guaranteed to work. In the >> case of Canada, it will work in many cases because iso-8859-1 >> is well established there in the context of the web. However, >> it will not work worldwide. > >The moral of the story is that interEuropeanization is not >internationalization. The moral of the story is that we ought to use a worlwide character set where even Japanese characters are integrity-preserved everywhere! Any language can be used internationally, not only English. We should not detour the issue. The net result to use ASCII worldwide plus a local character set only on a cultural island would be that English would dominate everywhere and other languages at a major disadvantage. This is not what I call internationalization, that is insularization. The main moral of the story is that ASCII is not the solution! Alain LaBonti Quibec Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id FAA13786 for urn-ietf-out; Wed, 19 Feb 1997 05:34:27 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id FAA13781 for ; Wed, 19 Feb 1997 05:34:24 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10344 (mail destined for urn-ietf@services.bunyip.com); Wed, 19 Feb 97 05:34:22 -0500 From: Masataka Ohta Message-Id: <199702191031.TAA10396@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id TAA10396; Wed, 19 Feb 1997 19:31:08 +0900 Subject: [URN] Re: URL internationalization! To: mduerst@ifi.unizh.ch (Martin J. Duerst) Date: Wed, 19 Feb 97 19:31:07 JST Cc: mohta@necom830.hpcl.titech.ac.jp, alb@riq.qc.ca, ietf-url@imc.org, urn-ietf@bunyip.com In-Reply-To: ; from "Martin J. Duerst" at Feb 19, 97 11:09 am X-Mailer: ELM [version 2.3 PL11] Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Masataka Ohta Errors-To: owner-urn-ietf@Bunyip.Com > No, I didn't say so. What I said is that the practice of using > characters besides ASCII without a specification of how the > server will interpret them is not guaranteed to work. In the > case of Canada, it will work in many cases because iso-8859-1 > is well established there in the context of the web. However, > it will not work worldwide. The moral of the story is that interEuropeanization is not internationalization. Masataka Ohta Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id FAA13550 for urn-ietf-out; Wed, 19 Feb 1997 05:09:28 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id FAA13545 for ; Wed, 19 Feb 1997 05:09:25 -0500 (EST) Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10107 (mail destined for urn-ietf@services.bunyip.com); Wed, 19 Feb 97 05:09:21 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <16088-0@josef.ifi.unizh.ch>; Wed, 19 Feb 1997 11:09:28 +0100 Date: Wed, 19 Feb 1997 11:09:27 +0100 (MET) From: "Martin J. Duerst" To: Masataka Ohta Cc: "Alain LaBont/e'/" , ietf-url@imc.org, urn-ietf@bunyip.com Subject: [URN] Re: URL internationalization! In-Reply-To: <199702190355.MAA09542@necom830.hpcl.titech.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by services.bunyip.com id FAA13546 Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@Bunyip.Com Masataka - On Wed, 19 Feb 1997, you wrote: > Alain; > > > In Canada that is done all the time... there are URLs in newspapers (in > > English and in French), on all TV channels (in many languages), in email > > (many languages too), on the radio networks (polyglot), through our ears > > (also polyglot (: )... We have to type, transcribe and mail URLs all the time. > > > > So I do not understand the objection to Martin Dürst. > > Because you haven't read Martin. You don't have to, though. He > said you are not doing that. No, I didn't say so. What I said is that the practice of using characters besides ASCII without a specification of how the server will interpret them is not guaranteed to work. In the case of Canada, it will work in many cases because iso-8859-1 is well established there in the context of the web. However, it will not work worldwide. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id XAA09544 for urn-ietf-out; Tue, 18 Feb 1997 23:32:29 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id XAA09539 for ; Tue, 18 Feb 1997 23:32:26 -0500 (EST) Received: from proxy2.ba.best.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07126 (mail destined for urn-ietf@services.bunyip.com); Tue, 18 Feb 97 23:32:24 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.8.5/8.8.3) with SMTP id UAA13106; Tue, 18 Feb 1997 20:28:50 -0800 (PST) Date: Tue, 18 Feb 1997 20:28:50 -0800 (PST) From: "Gregory J. Woodhouse" To: "Alain LaBont/e'/" Cc: Masataka Ohta , mduerst@ifi.unizh.ch, ietf-url@imc.org, urn-ietf@bunyip.com Subject: Re: [URN] Re: URL internationalization! In-Reply-To: <9702190422.AA08153@socrate.riq.qc.ca> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@Bunyip.Com I always thought the original comment about transcribability was meant as irony. You know: no one needs to transcribe URLs, except ... --- gjw@wnetc.com / http://www.wnetc.com/home.html If you're going to reinvent the wheel, at least try to come up with a better one. Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id XAA09395 for urn-ietf-out; Tue, 18 Feb 1997 23:18:10 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id XAA09390 for ; Tue, 18 Feb 1997 23:18:06 -0500 (EST) Received: from socrate.riq.qc.ca by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06963 (mail destined for urn-ietf@services.bunyip.com); Tue, 18 Feb 97 23:18:04 -0500 Received: from alain-labont- (riq-44-132.riq.qc.ca) by socrate.riq.qc.ca (5.x/SMI-SVR4) id AA08153; Tue, 18 Feb 1997 23:22:46 -0500 Message-Id: <9702190422.AA08153@socrate.riq.qc.ca> Comments: Authenticated sender is From: "Alain LaBont/e'/" To: alb@riq.qc.ca (Alain LaBont/e'/), Masataka Ohta Date: Tue, 18 Feb 1997 23:17:21 +0005 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Comments: Sender has elected to use 8-bit data in this message. If problems arise, refer to postmaster at sender's site. Subject: [URN] Re: URL internationalization! Cc: mohta@necom830.hpcl.titech.ac.jp, mduerst@ifi.unizh.ch, ietf-url@imc.org, urn-ietf@bunyip.com Priority: normal In-Reply-To: <199702190355.MAA09542@necom830.hpcl.titech.ac.jp> References: <3.0.1.32.19970218224621.006a1310@riq.qc.ca>; from "Alain LaBont/e'/" at Feb 18, 97 10:46 pm X-Mailer: Pegasus Mail for Win32 (v2.52FR) Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "Alain LaBont/e'/" Errors-To: owner-urn-ietf@Bunyip.Com > From: Masataka Ohta > Subject: Re: URL internationalization! > To: alb@riq.qc.ca (Alain LaBont/e'/) > Date: Wed, 19 Feb 97 12:54:58 JST > Cc: mohta@necom830.hpcl.titech.ac.jp, mduerst@ifi.unizh.ch, ietf-url@imc.org, > urn-ietf@bunyip.com > Alain; > > > In Canada that is done all the time... there are URLs in newspapers (in > > English and in French), on all TV channels (in many languages), in email > > (many languages too), on the radio networks (polyglot), through our ears > > (also polyglot (: )... We have to type, transcribe and mail URLs all the time. > > > > So I do not understand the objection to Martin D|rst. > > Because you haven't read Martin. You don't have to, though. He > said you are not doing that. > > Masataka Ohta ?????? Alain LaBonti Quibec Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id WAA09092 for urn-ietf-out; Tue, 18 Feb 1997 22:57:42 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id WAA09087 for ; Tue, 18 Feb 1997 22:57:39 -0500 (EST) Received: from necom830.hpcl.titech.ac.jp by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06761 (mail destined for urn-ietf@services.bunyip.com); Tue, 18 Feb 97 22:57:38 -0500 From: Masataka Ohta Message-Id: <199702190355.MAA09542@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA09542; Wed, 19 Feb 1997 12:54:59 +0859 Subject: [URN] Re: URL internationalization! To: alb@riq.qc.ca (Alain LaBont/e'/) Date: Wed, 19 Feb 97 12:54:58 JST Cc: mohta@necom830.hpcl.titech.ac.jp, mduerst@ifi.unizh.ch, ietf-url@imc.org, urn-ietf@bunyip.com In-Reply-To: <3.0.1.32.19970218224621.006a1310@riq.qc.ca>; from "Alain LaBont/e'/" at Feb 18, 97 10:46 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Masataka Ohta Errors-To: owner-urn-ietf@Bunyip.Com Alain; > In Canada that is done all the time... there are URLs in newspapers (in > English and in French), on all TV channels (in many languages), in email > (many languages too), on the radio networks (polyglot), through our ears > (also polyglot (: )... We have to type, transcribe and mail URLs all the time. > > So I do not understand the objection to Martin D|rst. Because you haven't read Martin. You don't have to, though. He said you are not doing that. Masataka Ohta Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id WAA09048 for urn-ietf-out; Tue, 18 Feb 1997 22:51:46 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id WAA09043 for ; Tue, 18 Feb 1997 22:51:43 -0500 (EST) Received: from socrate.riq.qc.ca by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06707 (mail destined for urn-ietf@services.bunyip.com); Tue, 18 Feb 97 22:51:41 -0500 Received: from alain-labont- (riq-44-132.riq.qc.ca) by socrate.riq.qc.ca (5.x/SMI-SVR4) id AA06042; Tue, 18 Feb 1997 22:51:21 -0500 Message-Id: <3.0.1.32.19970218224621.006a1310@riq.qc.ca> X-Sender: alb@riq.qc.ca X-Mailer: Windows Eudora Pro Version 3.0.1 beta 3 (32) Date: Tue, 18 Feb 1997 22:46:38 -0500 To: Masataka Ohta , mduerst@ifi.unizh.ch (Martin J. Duerst) From: "Alain LaBont/e'/" Subject: [URN] Re: URL internationalization! Cc: ietf-url@imc.org, urn-ietf@bunyip.com Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "Alain LaBont/e'/" Errors-To: owner-urn-ietf@Bunyip.Com A 12:23 97-02-19 JST, Masataka Ohta a icrit : >Martin; > >The discussion that the Internetionalized URL is the ASCII-only >URL has already finished a few years ago. > >You have raised no now point. > >Perhaps, you have never used WWW browsers yet, but, those of us >who have know that we don't need URL human readable unless it >is keyboarded, transcribed or mailed. In Canada that is done all the time... there are URLs in newspapers (in English and in French), on all TV channels (in many languages), in email (many languages too), on the radio networks (polyglot), through our ears (also polyglot (: )... We have to type, transcribe and mail URLs all the time. So I do not understand the objection to Martin D|rst. Saionara. Gru_. Alain LaBonti Quibec Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id WAA08855 for urn-ietf-out; Tue, 18 Feb 1997 22:26:49 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id WAA08849 for ; Tue, 18 Feb 1997 22:26:43 -0500 (EST) Received: from [131.112.32.132] by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06468 (mail destined for urn-ietf@services.bunyip.com); Tue, 18 Feb 97 22:26:41 -0500 From: Masataka Ohta Message-Id: <199702190324.MAA09332@necom830.hpcl.titech.ac.jp> Received: by necom830.hpcl.titech.ac.jp (8.6.11/TM2.1) id MAA09332; Wed, 19 Feb 1997 12:23:45 +0859 Subject: [URN] Re: URL internationalization! To: mduerst@ifi.unizh.ch (Martin J. Duerst) Date: Wed, 19 Feb 97 12:23:45 JST Cc: ietf-url@imc.org, urn-ietf@bunyip.com In-Reply-To: ; from "Martin J. Duerst" at Feb 18, 97 12:53 pm X-Mailer: ELM [version 2.3 PL11] Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: Masataka Ohta Errors-To: owner-urn-ietf@Bunyip.Com Martin; The discussion that the Internetionalized URL is the ASCII-only URL has already finished a few years ago. You have raised no now point. Perhaps, you have never used WWW browsers yet, but, those of us who have know that we don't need URL human readable unless it is keyboarded, transcribed or mailed. Try, for example, Netscape. Masataka Ohta Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id MAA05558 for urn-ietf-out; Tue, 18 Feb 1997 12:05:11 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id MAA05540 for ; Tue, 18 Feb 1997 12:05:08 -0500 (EST) Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08140 (mail destined for urn-ietf@services.bunyip.com); Tue, 18 Feb 97 12:05:00 -0500 Received: from montana (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA14388; Tue, 18 Feb 1997 10:04:54 -0700 (MST) Message-Id: <3.0.32.19970218100414.00960900@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 18 Feb 1997 10:04:19 -0700 To: "Gregory J. Woodhouse" , jayhawk@ds.internic.net From: "Ron Daniel Jr." Subject: Re: [URN] What to use for NID's? Cc: urn-ietf@bunyip.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@Bunyip.Com At 05:50 AM 2/18/97 -0800, Gregory J. Woodhouse wrote: >On Tue, 18 Feb 1997 jayhawk@ds.internic.net wrote: > >> I've been looking at Ron's conventions draft and playing around with >> setting up a couple of namespaces and I got to wondering... >> >> I believe that we still have to put together a document covering >> the registration requirements of a namespace (which I am not >> volunteering >> to do ;-), I'm appending some rough material tha tmight be used to start such a draft. >>but are we willing to allow the "x-" convention? > >Why not? We miht want to make a distinction between globally unique names >and globally resolvable names. I can understand concern over the >possibility of NIDs in the x- namespace that aren't globally unique (even >then, an argument could be made), but why not allow names that can only be >resolved locally? I've been thinking about doing something like this where >the names would reference database records. While I am not adamantly opposed to "x-", I know people who are and I find their arguments pretty sound. There are two major goals for URNs, persistence and location-independence. It seems to me that "x-" violates the intent of persistence, and are not necessary for local experiments. Assume you have used "x-foo" for a local namespace identifier in an experiment. The experiment is declared a success and you want to start using "foo" as the NID. All your old documents and citations have to be changed - exactly what we are trying to avoid with URNs. For local experiments, do what we are doing. Our proxy looks at the incoming URNs to see if the NID is one that we have local knowledge of. (e.g. we are starting to use SICIs to identify e-journal articles. We have a local repository of those articles, so our proxy checks our local repository before doing the fallback to sici.urn.net.) So, if your proxy can trap requests for the local "foo" NID, there is no need for "x-". ==== Namespace Requirements - fodder for a future Internet Draft URN namespaces will need to be unique, which implies IANA or a similar organization will need to run a registry for them. Here are some rules that they might apply when deciding to register namespaces: 0a: Does the namespace meet the requirements of uniqueness, transcribability, etc. from the URN Requirements RFC? 0b: Does its encoding as a URN meet the URN Syntax draft/RFC? 1a: Is it an already-existing internationally standardized namespace? 1b: Is the entity making the request a duly-authorized representative of an organization that has a legitimate claim to register the namespace? 1c: Are any resolution procedures (such a NAPTR records) in accordance with the rules of conduct in that namespace and common business practices? This set of rules seems restrictive, but is intended to allow for the quick grandfathering of already-established namespaces of broad utility. Examples of such namespaces are ISBN (International Standard Book Number), ISAN (intl. Std. Audiovisual Number), ISWC (Intl. Std. Work Code), UPC (Uniform Product Code), FPI (Formal Public Identifier). These are all namespaces that have been standardized by ISO, so the first question is answered. Not just anyone can claim to represent such a namespace. Namespaces will typically identifiy one or more registration agencies who have responsibility for the daily operation of the namespace. If the reqistration request does not come from a authorized representative of such a registration agency, it shall be denied. The third question is to ensure even competition for name resolution services. If multiple companies are already in the business of resolving identifiers from a namespace, they should all have an equal chance to have their resolver contacted. 2a: If not an international standard, is the namespace from a National standards-setting body? 2b: (See 1b) 2c: (See 1c) If the namespace is the product of a national standards organization, it shall be registered unless the namespace has already been considered by an international standards organization and rejected or modified. 3a: Does the namespace come from a national or international industry association that does not have Standards-developing status? 3b, 3c as above 3d: Is there no internationally standardized namespace that fulfills the same role, or into which this namespace can be "reasonably" grandafthered? Namespaces may arise from organizations like the Natl. Association of Manufacturers. 4a: If the namespace is the product of a commercial organization, can it accomodate a reasonably large set of other organizations? 4b, 4c, 4d as above. This is to allow organizations like the barcode vendors, Dunn&Bradstreet, etc. to register their namespaces, while trying to preclude vanity namespaces. I think we want to explicitly discourage vanity namespaces. If Disney wants to use urn:disney:whatever to identify their videos, etc. we should ask them to justify why namespaces such as UPC (which they already use) and ISAN are inappropriate. 5a: Is it early enough in the experimental period, and did the namespace applicants buy the registry administrators enough beer, that the registry administrators decide to make a special case? This is called "bowing to reality" :-) Ron Daniel Jr. voice:+1 505 665 0597 Advanced Computing Lab fax:+1 505 665 4939 MS B287 email:rdaniel@lanl.gov Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel Los Alamos, NM, USA, 87545 Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id KAA29931 for urn-ietf-out; Tue, 18 Feb 1997 10:16:28 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id KAA29926 for ; Tue, 18 Feb 1997 10:16:25 -0500 (EST) Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06534 (mail destined for urn-ietf@services.bunyip.com); Tue, 18 Feb 97 10:16:22 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <24697-0@josef.ifi.unizh.ch>; Tue, 18 Feb 1997 16:10:43 +0100 Date: Tue, 18 Feb 1997 16:10:41 +0100 (MET) From: "Martin J. Duerst" To: urn-ietf@bunyip.com Subject: Re: [URN] URL internationalization! In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@Bunyip.Com On Tue, 18 Feb 1997, Martin J. Duerst wrote: > Hello everybody, > > In the next mail to this list and its counterpart, I will make > proposals for changes/additions to the syntax or the process draft. > These changes are designed to set the direction for consistent > internationalization (i18n) of URLs in the future. > [The current state is best characterized by the word "chaos".] I appologize that this mail went to the URN list, it was intended to the URI and URL list. Anyway, maybe you like to see what's going on, URNs are not unaffeced by it. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id IAA27256 for urn-ietf-out; Tue, 18 Feb 1997 08:55:50 -0500 (EST) Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with SMTP id IAA27251 for ; Tue, 18 Feb 1997 08:55:45 -0500 (EST) Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00886 (mail destined for urn-ietf@services.bunyip.com); Tue, 18 Feb 97 08:55:40 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <19671-0@josef.ifi.unizh.ch>; Tue, 18 Feb 1997 12:53:06 +0100 Date: Tue, 18 Feb 1997 12:53:05 +0100 (MET) From: "Martin J. Duerst" To: URL mailing list , urn-ietf@bunyip.com Subject: [URN] URL internationalization! Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@Bunyip.Com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@Bunyip.Com Hello everybody, [Please appologize if you receive this mail twice.] In the next mail to this list and its counterpart, I will make proposals for changes/additions to the syntax or the process draft. These changes are designed to set the direction for consistent internationalization (i18n) of URLs in the future. [The current state is best characterized by the word "chaos".] As is customary for standards, language is limited to the facts, without much background. To give you this background, and show that the direction pointed to is very reasonable, I am sending this mail with detailled explanations to show that it actually works. If you have any further questions, I will be glad to answer them. If the changes proposed are approved, I will convert and expand the main part of this mail into an internet draft. My proposals to the URL process and syntax draft are based on many discussions in conferences and on IETF mailing lists, and talks on this issue in the last Unicode conference and at the Multilinguism workshop in Sevilla. Overview -------- 0. The Current State 1. The Solution 2. The Proposals 3. The Second Step 4. Backwards Compatibility and Upgrade Path 0. The Current State -------------------- URLs currently are sequences of a limited subset of ASCII characters. To encode other characters, arbitrary and unspecified character encodings ("charset"s) are used, and the resulting octets are encoded using the %HH escaping mechanism. The first step of this is highly unsatisfactory because it cannot be inverted, i.e. you cannot derive the characters from the octets, and because even forward conversion cannot be done without some additional information, i.e. if you know the characters of a file name, you can't construct the URL, because you don't know the encoding that the server will expect. The above is current practice, and can't be changed overnight, especially because a lot of protocols and software is affected. But it is possible to specify the direction to go, and to start moving in that direction. Maybe you ask why caring about the internationalization of URLs is necessary at all. Well, for some parts of URLs (in particular the query part), i18n is undeniably necessary, and for others, not doing it is putting people and communities using something else than basic Latin at an unnecessary disadvantage. Of course, no information provider will be forced to use these features. But as an example, take the Hong Kong Turist Association adventising Hong Kong in the US and in Japan. It will only help them if the URL to their Japanese site is as understandable, memorizable, transcribable, or guessable for Japanese speakers as the ASCII URL is for English speakers. The arguments that i18n URLs cannot be keyboarded, transcribed, or mailed may have had some significance in the past, but are getting less and less valid. On the Web, with forms and Java, it's easy to offer a keyboarding service for the whole of UNicode. Anyway, the proposals I am making here are not at all going that far. I am just mentionning these things above and below to show that it's actually workable and desirable. Discussions on the URN list have shown that some people are still very sceptical about transcribability. The work on HTML 2.0 and HTML i18n has shown that it is possible to move towards i18n in a well-defined way even at a rather late stage. 1. The Solution --------------- To solve the problem that character encodings are not known, there could be different solutions. Using tags (a la RFC 1522) is ugly because these tags would have to be carried around on paper and everywhere. Having every scheme and mechanism use different conventions is also rather impracticable because this leads to confusion (e.g. if the dns part of an URL is different from the path part because dns and http use different conventions). Inventing new schemes for internationalization (e.g. ftp->iftp) is likewise too clumsy. The solution that remains is to specify preference for a single character encoding. Because this has to encompass a very wide range of characters, the Universal Character Set (UCS) of Unicode/ISO 10646 is the only solution. To be compatible with ASCII, there exist two UCS Transform Formats, UTF-7 and UTF-8. UTF-7, however, has various disadvantages. Some of the characters it uses can have special functions inside URLs. It is not completely compatible with ASCII. And it has some potential limitations with regards to the full space of UCS (although the later point is rather theoretical). UTF-8, designed by Rob Pike and others at Bell labs, is not perfect for URLs either. But it is fully ASCII-compatible, and doesn't interfere with URL syntax. Also, the problem that it uses all 8 bits per octet is solved by the widely deployed %HH-encoding of URLs. The problem that with %HH-ecoding, some URLs can get rather long, will hopefully be addressed by the direct use of the characters themselves somewhere in the future (see below). UTF-8 has an additional addvantage, namely that it is with high probability easily distinguishable from legacy encodings. This was one of the reasons it was adopted for internationalizing FTP (see draft-ietf-ftpext-intl-ftp-00.txt). URNs also have adopted UTF-8 and %HH-encoding (see draft-ietf-urn-syntax-02.txt). This is important because URLs and URNs are both part of URIs, and are otherwise kept in synch syntacticatly. Also, the general recommendation from the Internet Architecture Board is to use UTF-8 in situations where ASCII-compatibility is necessary (see draft-weider-iab-char-wrkshop-00.txt). This has lead to the conclusion, in the various discussions I have been involved, that UTF-8 is the solution. A good documentation on this can found at http://www.alis.com:8085/~yergeau/url-00.html). Actually, Francois Yergeau was faster than me to realize that UTF-8 is the way to go, and we wouldn't be where we are now if it weren't for his efforts. 2. The Proposals ---------------- In Sevilla, I proposed two steps to move towards the solution. The first step is to specify UTF-8 as the preferred character encoding for URLs, while leaving URLs unchanged otherwise. This brings the target for URLs in sync with the spec for URNs. For reasons already explained, the proposals for changes to the syntax and process draft I make cover only the first step. For most people caring about i18n, this looks like "not enough". But it is important to set the basic infrastructure first. Once we have that, the rest will come almost without effort. The two important points in the first step are "no enforcement" and "canonical form" (a better name for the later might be lowest common denominator). Canonical form means that %HH-escaping is compulsory, and no 8-bit or native encoding is allowed. This is important to stay in sync with URNs, to allow UTF-8 URL software and actual URLs to deploy before raising the expectations of users too much, and to address the concerns about transcribability of those in the URI community not very familliar with i18n issues. Of course, as with URNs, even with the canonical form only, it will be possible rather quickly to offer nice user interfaces hiding the %HH (once you know how the conversion is done!). Due to current use, it is impossible to mandate any character encoding for URLs; a lot of URLs would immediately become illegal. Also, URLs are a "hat" over many very different protocols and mechanisms, which all have their own communities and special needs. Some URLs, such as the "data:" URL, do not encode characters at all (but most actually do :-). Others might have very specific requirements that preclude the use of UTF-8, or may not need i18n at all for some good reason. However, please note that there is no need for the protocol or mechanism itself to use UTF-8 for internationalization. Assuming the protocol or mechanism is internationalized, with a well-defined way to encode the characters of UCS, a mapping from UTF-8 to that specific encoding can be defined. This is preferable to exposing the scheme-specific i18n in URLs, because it greatly simplifies URL handling and user interface issues. For examples of scheme- or mechanism-specific i18n, please see IMAP [RFC 2060, section 5.1.3], defining "modified UTF-7", and the "UTF-5" from my proposal for domain name i18n (draft-duerst-dns-i18n-00.txt). 3. The Second Step ------------------ Once the direction towards using UTF-8 as the character encoding for URL is firmly set, and other i18n aspects are nicely covered by software such as browsers and servers, it will be time for step two, I hope. This means that %HH-escaping will not be mandatory anymore. Note that this does not mean that binary UTF-8 will be placed in the middle of an ASCII-only document, or in a Latin-X document, or in a UCS2/UTF-16 document. In these cases, and in all others where the character encoding is implicitly or explicitly known, those characters that can be represented natively will be encoded using the native encoding. For the rest of the characters, UTF-8 and %HH-encoding will be used. This is crucial to make transcoding, for example in response to an "Accept-Charset:" header in HTTP, as well as e.g. when cutting/pasting text in a GUI interface, work correctly. It also conforms what is done currently with the basic URL characters e.g. in a document encoded in EBCDIC. 4. Backwards Compatibility and Upgrade Path ------------------------------------------- Backwards compatibility is fully guaranteed. No URL that was legal up to now is made illegal. No URL that works now is stopping to work. And it is actually possible to convert to using UTF-8 gradually, without the servers depending on all clients to be upgraded or vice versa. And even those cases that already use native document encoding for their URLs, and rely on them being interpreted octet-wise, can be dealt with, to the extent they have been working up to now. If a server e.g. has a Latin-X filesystem locally, and gets an URL that could be UTF-8, it converts it to Latin-X and looks if the resource is there. If the resource is not found, it tests using the raw octets directly. Because of the heuristic separation between UTF-8 and other encodings, and the usually extremely sparse use of namespace on a server (except for forms input, see below), chances for collision are exorbitantly small. If somebody is not satisfied with this, it's easy to add an extension that checks all current resource names and assures that there are no conflicting resource names, or that in case of conflict, the user gets a choice. A similar thing can happen on the browser side. A native URL, in whatever encoding, is converted to UTF-8 and used to probe the server. If it fails, another probe is made with the raw octet form of the native URL. Initially, it could be done the other way round, as long as that can be expected to yield more hits. Caching of the encoding that led to the last hit, on whatever granularity desirable, can help to reduce unnecessary connections. And the time penalty is not that significant, because the current use of native character representation with the expectation of binary interpretation has never been guaranteed to work anyway. Now for those URLs that the server creates on the fly, in particular the query part that results from form input. This currently is the biggest headache to people actually working on i18n of browsers and servers, and an uniform convention to use UTF-8 would improve the situation a lot. Unfortunately, however, the namespace in this case is more tightly populated. A server has a reasonable chance, depending on the character encodings it is expecting, to detect UTF-8. But a client doesn't have many clues about the server. Because this is a rather old problem, several solutions have been proposed and some of them are (partially) implementated. The first is (in the context of HTTP) to use a GET with a multipart body, where each of the parts has an appropriate "charset" tag. The second is to incorporate a hidden field into the FORM, and guess the encoding by reasonably assuming that the client is sending the same characters back, although maybe in a different encoding, and that all fields use the same character encoding. The third is to use the encoding of the document that was sent, with UTF-8 also in the case of UCS2/UTF-16 or raw UCS4. However, it is not sure that on a server that can transcode to Unicode, all the scripts will be able to accept Unicode. The fourth is to use the "Accept-Charset=" attribute defined in RFC 2070 for the and