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 ------------------------------------------------------------------------------