Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA24422 for urn-ietf-out; Fri, 29 Nov 1996 21:15:13 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA24417 for ; Fri, 29 Nov 1996 21:15:07 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12817 (mail destined for urn-ietf@services.bunyip.com); Fri, 29 Nov 96 21:15:02 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id SAA01368; Fri, 29 Nov 1996 18:13:27 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id SAA29904; Fri, 29 Nov 1996 18:13:46 -0800 (PST) Date: Fri, 29 Nov 1996 18:13:46 -0800 (PST) From: Terry Allen Message-Id: <199611300213.SAA29904@ishtar.fsc.fujitsu.com> To: sollins@LCS.MIT.EDU, urn-ietf@bunyip.com Subject: Re: [URN] URN resolution requirements and framework Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com I trust the following will not be taken as a rotten egg or a tomato (much less a gas-green tomato): Summary: The case for unfriendly/meaningless/semantic-free naming is made much more strongly in the framework doc than in RFC 1737, and inappropriately so in view of recent discussions on the issue here. Please suppress. Details: | The Uniform Resource Identifier Working Group defined a naming | architecture, as demonstrated in a series of three RFCs 1736[RFC1736], | 1737{RFC1737}, and 1738[RFC1738]. Although several further documents | are needed to complete the description of that architecture, it | incorporates three core functions often associated with "naming": | identification, location, and mnemonics or semantics. Names may provide | the ability to distinguish one resource from another, by distinguishing | their "names". Names may help to provide access to a resource by | including "location" information. Lastly, names may have other semantic | or mnemonic information that either helps human users remember or figure | out the names, or include other semantic information about the resource | being named. The URI working group concluded that there was need for | persistent, globally unique identifiers, distinct from location or other | semantic information; these "names" provide identity, in that if two of | them are "the same" (under some simple rule of canonicalization), they | identify the same resource. Furthermore, the group decided that these | "names" were generally to be for machine, rather than human consumption. Where does it say that in the RFCs you refer to? I find in RFC 1737 only the assertion that URNs should be machine-parseable. There is a weak sentence claiming that on the assumption that semantic drift is a problem for names, naming authorities should be discouraged from using meaningful names (actually, names that employ information about the resource; meaningful names are not advised against *per se*). That's far short of what you're saying here, now. | One can imagine a variety human-friendly naming (HFN) schemes supporting | different suites of applications and user communities. These will need | to provide mappings to URNs in tighter or looser couplings, depending on | the namespace. It is these that will be mnemonic, content-full, and | perhaps mutable, to track changes in use and semantics. They may Or they will be URNs themselves. I can imagine that, too. This is a document on URNs, not HFNs. The general mechanism of "hints" can cover HFNs; there is no need to assert that the future will instantiate your views on meaningful naming. Especially if consensus is desired. The argument below, about URLs, is not about separation of semantics from identification, as claimed, it's about the different utilities of naming and pointing. | Today we see the problem most clearly with the use of URLs for | identification. When a web page moves, its URL becomes invalid. | Suppose such a URL is embedded in some page, stored in long term | storage. There are three possible outcomes to this scenario. One | possibility is that the client is left high and dry with some message | saying that the page cannot be found. Alternatively, a "forwarding | pointer" may be left behind, in the form of an explicit page requesting | the client to click on a new URL. Although this will allow the client | to find the intended page, the broken link cannot be fixed because the | URL is embedded in a file outside of the client's control. A third | alternative is that the target server supplies an HTTP redirect so that | the new page is provided for the client automatically. In this case, | the client may not even realize that the URL is no longer correct. The | real problem with both of these latter two situations is that they only | work as long as the forwarding pointer can be found at the old URL. So far, so good. And no mention of semantics. | Semantics, in this case location information, was embedded in the | identifier, and the resolution system was designed to depend on the | semantics being correct. There are few cases in which we can expect That's one way of thinking of it; it depends on the URL and the resolution system. This is not a strong argument that it's semantics that make URLs fragile; "http://192.240.3.1/nnnnn/zzzzz" is just as fragile. | semantics of any sort to remain valid for a long time, but in many cases | references need to have long lifespans. Most documents are only useful | while their references still function. You are arguing that semantic drift in naming is so great that it affects some appreciable number of documents during their useful lifetime. I don't buy it. Take out the semantics part and you have a good argument for why we need URNs; isn't that why it's here? What follows by way of "postulation re scope of evolution" might better be replaced with a less controversial example just as apt to the point. Or just leave it out: these aliases are nothing but hints, right? | We expect the evolution to separation of semantics from identification | to move along at least three paths. The first will be to develop | temporary aliases to capture the semantics currently embedded in | identifiers. This will require additional translation, but it will | allow for the development of semantics-free URNs. Second, we expect | locally shared or private aliases to arise, again supported by a | translation mechanism and allowing for the long-term storage of global, | semantics-free URNs. Such an aliasing scheme may be used to permit | local aliases for named resources as well as to present these aliases to | users in lieu of the URNs themselves. Lastly, we expect there may be a | development of global aliases. These will be more user friendly "names" | that would be shared on a much larger scale, and might be defined in | some global registry. This may include trademarked names as well as | names in extremely common use. As with the other alias systems, a | facility for translation is needed. However, in this case, since the | system of aliases is of global scope, the translation facility will be | very slow if each time an alias is translated it needs to query a | centralized or even reasonably distributed global registry. In order to | achieve acceptable speeds, the translation facility will need to | maintain a local cache, possibly in cooperation with other nearby alias | caches. Clearly this is all postulation at present, but it is provided | here to demonstrate some of the scope of evolution for which we must be | prepared. That it may be, but it is also declaring a position on human-friendly naming that we do not agree upon. Stu Weibel gave us good advice: take no position on the issue. | In summary, the requirements in the area of evolvability are: | * To support evolution of mechanisms, specifically for | a) a growing set of URN schemes; | b) new local URN resolution schemes; | c) new authentication schemes; | d) alternative UDS schemes active simultaneously; | * To support and encourage the evolution toward the separation of | global identification from short-lived, locally useful, or human | friendly semantics; "To permit" is sufficient; or, in the language used in every other point in this list, "To support". Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA18582 for urn-ietf-out; Fri, 29 Nov 1996 10:43:52 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA18577 for ; Fri, 29 Nov 1996 10:43:44 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09022 (mail destined for urn-ietf@services.bunyip.com); Fri, 29 Nov 96 10:43:37 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <25229-0@josef.ifi.unizh.ch>; Fri, 29 Nov 1996 16:42:11 +0100 Date: Fri, 29 Nov 1996 16:42:08 +0100 (MET) From: "Martin J. Duerst" To: Leslie Daigle Cc: Ryan Moats , URN mailing list Subject: Re: [URN] Collecting open issue information on the syntax draft... In-Reply-To: <199611221942.OAA21503@beethoven.bunyip.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Fri, 22 Nov 1996, Leslie Daigle wrote: > [Ryan brought up:] > > 4. human readability for new namespaces: MUST/SHOULD? > > If that is the case, I would propose the following change to the syntax > draft: > > > 3. Support of existing legacy naming systems and new naming systems > > > URN-aware applications MAY accept as input other resource identifiers > > from existing legacy namespaces. If such identifiers contain > > characters that are not members of the URN character set specified in > > section 2.2, the identifier MUST be translated to canonical format as > > discussed in section 2.2. > > > > Some existing name spaces that have the properties of the URN-space > > contain some human-significant components, and these exist in a wide > > variety of languages. However, URNs are NOT intended to convey > > information that is significant to humans. While the translation > > rule in section 2.2 is provided for existing namespaces, new > > namespaces, as part of their registration documentation, MUST define > > a discipline for assigning new URNs that does not simplify the > > generation of human-significant names. > > would become: > > > 3. Support of existing legacy naming systems and new naming systems > > Any namespace (existing or newly-devised) that is proposed as a > URN-namespace and fulfills the criteria of URN-namespaces must > be expressed in this syntax. If names in these spaces contain > characters other than those defined for the URN character set, > they must be translated into canonical format as discussed in > section 2.2. I can only support Leslie's proposal (just change "spaces" on line 3 to "name spaces" and "canonical format" to "canonical form".) Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA07752 for urn-ietf-out; Thu, 28 Nov 1996 13:37:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA07746 for ; Thu, 28 Nov 1996 13:37:51 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04761 (mail destined for urn-ietf@services.bunyip.com); Thu, 28 Nov 96 13:37:46 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <08949-0@josef.ifi.unizh.ch>; Thu, 28 Nov 1996 19:37:51 +0100 Date: Thu, 28 Nov 1996 19:37:49 +0100 (MET) From: "Martin J. Duerst" To: Ryan Moats Cc: URN mailing list Subject: Re: [URN] Collecting open issue information on the syntax draft... In-Reply-To: <9611221640.AA24257@mocha.bunyip.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Fri, 22 Nov 1996, Ryan Moats wrote: > Folks- > > I've been going back over the open issues with the syntax draft > and trying to ensure that I have all of them before I start thinking > about slides for San Jose. > When does a URN end? > --------------------------------------- > > It has also been pointed out to me that the syntax draft does not indicate > when a URN ends. Some statement should be added to indicate this > situation. My current preference is to state that a "On the line, the > URN ends with an octet that is not a member of the URN charset", > or something like that, but what about other formats? If you think about SGML public identifiers, which are quite long, or if you consider narrow columns in newspapers, having all of an URN on one line may not be possible. You may find a solution in draft-fielding-url-syntax-00.txt, but maybe there is none (I quickly scanned it and didn't find any). Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA25916 for urn-ietf-out; Wed, 27 Nov 1996 15:09:56 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA25911 for ; Wed, 27 Nov 1996 15:09:54 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27995 (mail destined for urn-ietf@services.bunyip.com); Wed, 27 Nov 96 15:09:52 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id NAA03343 for ; Wed, 27 Nov 1996 13:09:49 -0700 (MST) Message-Id: <2.2.32.19961127201825.00d31a90@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 27 Nov 1996 13:18:25 -0700 To: urn-ietf@bunyip.com From: Ron Daniel Subject: [URN] some more NAPTR edits Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Hi, I've been looking some more at security for NAPTR resolution and think there may be times when people will want to provide encrypted info in a NAPTR record. I'm considering some changes to the draft to accomodate this - the main part of those changes is appended. I'll wait until after San Jose to actually make the edits to the draft and resubmit, because these changes may be controversial. Regards, Ron =============== Flags A String giving flags to control aspects of the rewriting. Flags are characters from the set [0-9A-Z]. The case of the alphabetic characters is not significant. Multiple flags may appear in the flags field. The flags A-Z are reserved, 0-9 are available for local experimentation. At this time there are 5 defined flags: A, S, P, R and E. S, A, and P all indicate that the NAPTR is terminal and the next lookup should be for A records, SRV records, or protocol-known records, respectively. The A, S, and P flags are mutually exclusive. The "R" flag indicates that the regexp field is to be treated as a Raw string, not as a substitution expression. The interpretation to be placed on that string will be set by other flags. When the "R" flag is given, there MUST be a value in the regexp field. There MAY be a value in the replacement field, in which case that shall be the next domain name to be contacted. The "R" flag may be combined with one of the "A", "S", or "P" flags. Specifying the "R" flag is the only time it is not an error to have a value in both the regexp and replacement fields. The "E" flag specifies that the regexp field holds an encrypted string. The "R" flag must be specified if the "E" flag is given. Further details on the encryption protocol will be specified in subsequent releases of this draft. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA13817 for urn-ietf-out; Tue, 26 Nov 1996 15:34:56 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA13794 for ; Tue, 26 Nov 1996 15:34:24 -0500 Received: from iberia-c.it.earthlink.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18685 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 15:34:21 -0500 Received: from [153.35.78.27] (Cust27.Max18.Boston.MA.MS.UU.NET [153.35.78.27]) by iberia.it.earthlink.net (8.7.5/8.7.3) with ESMTP id MAA11660; Tue, 26 Nov 1996 12:33:10 -0800 (PST) X-Sender: tows@mail.earthlink.net Message-Id: In-Reply-To: <96Nov26.063616pdt."135"@palimpsest.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Nov 1996 03:37:05 -0500 To: Larry Masinter From: Towsner Subject: Re: [URN] Persistence as part of URN framework Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Towsner Errors-To: owner-urn-ietf@bunyip.com At 8:36am -0500 11/26/96, Larry Masinter wrote: ># All I wanted was an *optional* persistence value to be possible, so that the ># URN resolution service could indicate the longevity of the resolver (not the ># URN), at least until the longevity was extended once the people managing it ># were willing to commit to a longer running service. > >... > ># No-one seems to be able to get their head round the fact that such expiry ># times are meaningless if you don't know how long you will be able to resolve ># URNs which end up pointing to HTTP, but might point to another scheme later ># to keep them alive. I think the problem is that people just aren't thinking ># in terms of how much the world will change in the decades ahead. All I'm ># trying to propose is a way to avoid having to poll for broken resolution ># services in the future. > ># I give up. > >No URN resolution protocol that doesn't explicitly deal with the >issues of what happens when providers quit, merge, or split can >seriously claim to address URN requirements. > >A protocol can be marked as 'Experimental', but even Experimental >drafts can be marked to clearly indicate what parts of the problem >they're not handling. The experiment then can help determine how >serious, in practice, the problem really is. I think some type of persistance check is important. The ability to mark information as transient should definately be part of the URN framework. -- -Henry Towsner Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA13802 for urn-ietf-out; Tue, 26 Nov 1996 15:34:42 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA13797 for ; Tue, 26 Nov 1996 15:34:40 -0500 Received: from iberia-c.it.earthlink.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18690 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 15:34:38 -0500 Received: from [153.35.78.27] (Cust27.Max18.Boston.MA.MS.UU.NET [153.35.78.27]) by iberia.it.earthlink.net (8.7.5/8.7.3) with ESMTP id MAA11548; Tue, 26 Nov 1996 12:32:02 -0800 (PST) X-Sender: tows@mail.earthlink.net Message-Id: In-Reply-To: <2.2.32.19961126154635.00d18aa0@acl.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Nov 1996 03:34:47 -0500 To: Ron Daniel , Fisher Mark , urn-ietf From: Towsner Subject: Re: [URN] Collecting open issue information on the syntaxdraft... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Towsner Errors-To: owner-urn-ietf@bunyip.com >What I want to >see first is the use of internationally standardized namespaces such >as ISBN for on-line access to books, ISSN/SICI for access to magazine, >journal, and newspaper articles; ISAN for access to video programs and >movies; ISWC/ASCAP/BMI identifiers for access to music; UPC for access >to product descriptions, etc. National Standards bodies, such as ANSI, >and industry associations, such as the EIA, may also have developed >namespaces we could support. > >The Fortune 500 already make use of one or more of these namespaces >for particular purposes (especially UPC). From what I've read of the proposals, it seems to me that URN's are not intended as a replacement for URL's. They are intended to be used to locate *resources,* such as product descriptions or documents. URL's are capable of locating some company's web page, URN's, however, are better suited for locateing RFC 112 anywhere on the internet. -- -Henry Towsner Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA13107 for urn-ietf-out; Tue, 26 Nov 1996 14:51:47 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA13101 for ; Tue, 26 Nov 1996 14:51:44 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18308 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 14:51:40 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA22304; Tue, 26 Nov 1996 12:51:33 -0700 (MST) Message-Id: <2.2.32.19961126200009.00d30be8@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Nov 1996 13:00:09 -0700 To: Bob Briscoe From: Ron Daniel Subject: Re: [URN] Persistence as part of URN framework Cc: "urn-ietf@bunyip.com" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Bob Briscoe (at least at 10:27 AM 11/26/96 +0000) >[...] No-one seems to be able to get their head round the fact that [...] I'm trying to understand your point, and am sorry that its taking so much time. Lets try again. >All I wanted was an *optional* persistence value to be possible, Because of the limitations on DNS response sizes, there is a strong incentive not to put in any fields that are not needed. If we can agree that what you are asking for is necessary functionality not achievable by other means, then we will modify the NAPTR proposal to allow it. But I have not yet been convinced on that point. In fact, during the course of preparing this reply, I am more firmly of the view that the combination of DNS TTLs and the "Expires:" header of the HTTP resolution protocol (and equivalant features in other protocols) can achieve enough of what you are asking for that a seperate "lifetime" field is not justified. Let me try again to state what I think you are asking for and why. Then I will explain what it won't achieve. Finally I will explain what it will achieve beyond the combo of DNS TTL and "Expires:"-type info, and why I think the additional benefit is not significant. What I think you want: ======================= A way to determine the minimum remaining lifetime of a resolver without contacting that resolver to ask it. In other words, a new "lifetime" field in the NAPTR record. Why I think you want it: ======================== In an earlier message you indicated that one application of such a capability would be to automate the maintenance of links in HTML-like resources without continual polling, where a poll would probably be the wasteful operation of fetching the resource then throwing it away. In another message you said that this information will help in the migration from one resolution protocol to another. Why what you are asking for does not achieve at least some of what you want: =========================================================== Imagine that today (11/26/96) a customer signs a contract with a Resolution Service Provider (RSP) for one year's worth of service. You seem to be asking that the RSP be capable of updating their NAPTR record to indicate that the HTTP resolver they run will be available until at least 11/26/97. But of course, new customers come along and sign new contracts, again for a year's service. The NAPTR record could be continually updated to reflect that the RSP is now contractually bound to provide the HTTP resolver for a year after the most recent agreement with a customer. But why? It does not mean that the the original customer's URNs will still be resolvable there. Their contract was only for one year. Maybe they have decided to contract with a different RSP that can offer the spiffy new X2Y service. This is why I think that a special "lifetime" field in the NAPTR record does not achieve what you want from the "link maintenence" example. If I write a paper and use a URN to link to someone else's resource, the lifetime of the resolver does not necessarily tell me the lifetime of their resolution info on that resolver. However, if I go ahead and ask the resolver about that particular URN (assuming the approach in the HTTP Conventions draft), the HTTP Expires: header can be used to provide the detailed information on just how long one particular URN will continue to be resolvable on one particular resolution server under a particular resolution protocol. (This will be the minimum of the time remaining on that customer's contract, the time until the resolution service provider wants to scrap a particular resolution protocol, and the time remaining on the resolution service provider's contract with whoever they got their domain name from). When that time has expired I can try to resolve the name again and see what happens. What it *would* achieve over existing capabilities and why I think the additional benefit is not significant: ================================================================= >I've been off-line with Ron Daniel who is happy that schemes such as HTTP >which have expiry headers can get this information to you once you have >resolved how to speak to HTTP. > >No-one seems to be able to get their head round the fact that such expiry >times are meaningless if you don't know how long you will be able to resolve >URNs which end up pointing to HTTP, but might point to another scheme later >to keep them alive. I think the problem is that people just aren't thinking >in terms of how much the world will change in the decades ahead. All I'm >trying to propose is a way to avoid having to poll for broken resolution >services in the future. Let's look at a case where a resolution service provider (RSP) wants to swap from HTTP to some other resolution protocol - Z39.50 for example. We will also look at a couple of clients and how the swap affect them. RSP: ---- When the RSP starts offering HTTP_based resolution, they might say "OK, we will try this HTTP thing for 6 months as see how it goes". Their N2L, N2C, ... scripts generate an Expires: header that clocks down to that 6 month deadline. The NAPTR record for their HTTP-based resolver has a TTL that is considerably shorter - 1 week perhaps - to allow them to change the resolution services offered during the initial experimental period with only the week's advance notice. Client 1: --------- Somewhere along the way, a smart link manager is given a URN and starts to resolve it. It gets the Expires: header from the RSP's HTTP-based resolver and caches the expiry data with the URN. Its job as a "smart" link manager will be to recheck the availability of the resource and flag an error when it is no longer resolvable. It should do this in the least intrusive fashion possible. RSP: ---- Sometime later, the RSP decides that they don't like the HTTP-based approach and want to switch to a Z39.50-based approach. They will wait until the 6-month period expires before killing off the HTTP daemon, but in the meantime they bring up their Z39.50-based server and install a NAPTR record to point to it. They also decide that they want the NAPTR record for their HTTP server to disappear about a week before the server itself is killed. So, they start clocking down the TTL on the HTTP server's NAPTR record to that T=6mo-1week deadline. At that time the HTTP daemon's NAPTR record will be removed. Client 2: --------- Before that T=6mo-1week deadline, a different user agent attempts to resolve the URN and now encounters 2 terminal NAPTR records - one for the HTTP resolver and one for the Z39.50 resolver. It picks which one to talk to based on the protocols it knows how to speak, the services they offer, etc. If it knows both resolution protocols, it MAY make the decision based on the TTL of the NAPTR records. Once it has contacted the resolver the client will know how long the resolver guarrantees to provide resolution for that URN. As shown in the "contract" example earlier, this can be a considerably shorter time than the lifetime of the resolver. Client 1: --------- The 6 month expiry date comes along, and a random time later the link manager wants to recheck the URN. It starts a new NAPTR resolution which, some number of DNS probes later, gets it to the terminal NAPTR records. There is now a new terminal NAPTR record for a Z39.50-based resolver, but no HTTP-based record. If the client knows Z39.50 it can do something like N2Ls and get new expiry info. If not, it can use the TTL as a provisional expiry date and do more frequent checks of the DNS records in the hopes that a known resolution protocol will be offered at some time in the future. When it is, a more accurate expiry time can be obtained. Your request for a resolver lifetime field would modify the scenario above in two places. In the Client 2 paragraph, in the case where the client could speak more than one of the resolution protocols that were offered, it could make the decision on which one to pursue based on the resolver lifetime rather than the NAPTR TTL. However, as the "contract" example shows, this does not guarantee that the resolver with the longer minimum guaranteed lifetime actually will resolve that resource longer than the other one. So, the difference here does not seem all that significant. The second place where the "lifetime" field would change the scenario is in the last step where Client 1 does not know the new protocol. Rather than marking the URN provisionally resolvable with the NAPTR TTL as the time for the next check, it could mark it provisionally resolvable with the Z39.50 resolver lifetime as the time for the next check. The TTL is never longer than the resolver lifetime, so the TTL is the safer choice although it will lead to more "polls". In this case, however, a "poll" is fairly light weight - some DNS probes to see if the terminal NAPTR for the unknown protocol still exits (in which case we retain the provisionally resolvable status and check back later) or if new NAPTRs exist that we can follow. These could be introduced at any time so checking for them periodically is not a bad thing. Here again, the benefit from the new field does not seem so clear-cut that I'm not convinced it is necessary. I'm willing to be convinced of the necessity for such a field. However, since it requires extra space in the records and changes to running code you have to make a good case for it. If you can show me where the combination of DNS TTLs and resolution-specific Expiry info does not provide enough info to handle an important case, and the new field would, I'll change the spec. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA10668 for urn-ietf-out; Tue, 26 Nov 1996 11:51:04 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA10663 for ; Tue, 26 Nov 1996 11:50:53 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16766 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 11:50:02 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id LAA17893; Tue, 26 Nov 1996 11:50:00 -0500 Date: Tue, 26 Nov 1996 11:50:00 -0500 Message-Id: <199611261650.LAA17893@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: urn-ietf@bunyip.com Subject: [URN] resending Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com Don't know what happened, but here's the whole document...Thanks to those of you who pointed this out to me. Karen ______________________________ Internet Draft Karen R. Sollins draft-ietf-urn-req-frame-00.txt MIT/LCS Expires May 26, 1997 November 26, 1996 Requirements and a Framework for URN Resolution Systems Status of this draft This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract: This document addresses the issues of the discovery of local URN resolution services that in turn will directly translate URNs into URLs and URCs. The document falls into three major parts, the assumptions underlying the work, the requirements in order to be a viable URN-resolution-service discovery service or UDS, and a framework for designing UDSs. The requirements fall into three major areas: evolvability, usability, and security and privacy. A UDS that is compliant with the framework will not necessarily be compliant with the requirements. Compliance with the requirements will need to be validated separately. 1. Introduction The purpose of this document is to lay out the engineering criteria for what we will call here a URN-resolution-service discovery service (UDS). __________ Acknowledgments Foremost acknowledgment for this document goes to Lewis Girod, as my co-author on a previous URN requirements document and for his insightful comments on this version of the document. In addition, I recognize the contributors to a previous URN framework document, the "Knoxville" group. There are too many of you to acknowledge here individually, but thank you. Finally, I must thank the contributors to the URN working group mailing list (urn-ietf@bunyip.com), for their animated discussions on these and related topics. URN Resolution Requirements Page 1 This is a component of the realization of an information infrastructure. In the case of this work, that infrastructure is to be available, "in the Internet" or globally, and hence the solutions to the problems we are addressing must globally scalable. In this work, we are focussing specifically on naming of resources and resolution of those names to the exclusion of other problems such as typing, resource access and availability, security of the resources, etc. Those are all important problems, but not part of this effort. The Uniform Resource Identifier Working Group defined a naming architecture, as demonstrated in a series of three RFCs 1736[RFC1736], 1737{RFC1737}, and 1738[RFC1738]. Although several further documents are needed to complete the description of that architecture, it incorporates three core functions often associated with "naming": identification, location, and mnemonics or semantics. Names may provide the ability to distinguish one resource from another, by distinguishing their "names". Names may help to provide access to a resource by including "location" information. Lastly, names may have other semantic or mnemonic information that either helps human users remember or figure out the names, or include other semantic information about the resource being named. The URI working group concluded that there was need for persistent, globally unique identifiers, distinct from location or other semantic information; these "names" provide identity, in that if two of them are "the same" (under some simple rule of canonicalization), they identify the same resource. Furthermore, the group decided that these "names" were generally to be for machine, rather than human consumption. One can imagine a variety human-friendly naming (HFN) schemes supporting different suites of applications and user communities. These will need to provide mappings to URNs in tighter or looser couplings, depending on the namespace. It is these that will be mnemonic, content-full, and perhaps mutable, to track changes in use and semantics. They may provide nicknaming and other aliasing, relative or short names, context sensitive names, descriptive names, etc. The URI naming architecture as described in the introductions to RFCs 1736 and 1737 lays out three sorts of components to the naming architecture: identifiers called Uniform Resource Names (URNs), locators called Uniform Resource Locators (URLs) and semantic meta-information called Uniform Resource Characteristics (URCs). This document focusses on part of the problem of the translation from URN to URL and/or URC. Within the URI community there has been a concept used frequently that for lack of a better term we will call a _hint_. A hint is something that helps in the resolution of a URN. Examples of hints are: 1) the name of a resolution service that may further resolve the URN, 2) the address of such a service, 3) a location at which the resource was previously found. The defining feature of hints is that they are only hints; they may be out of date, temporarily invalid, or only applicable within a specific locality. They do not provide a guarantee of access, but they probably will help in the resolution process. Wemust assume that most resolutions of URNs will be provided by the use of locally stored hints, because maintaining a database of globally available, completely up-to-date location information is infeasible for performance reasons. There are a number of circumstances in which one can imagine that hints become invalid, either because a resource has moved or because a different URN resolution service has taken over the URN Resolution Requirements Page 2 responsibility for resolution of the URN. Hints may be found in a variety of places. It is generally assumed that a well engineered system will maintain a set of hints for each URN at each location where that URN is found. In addition, for those situations in which those hints found locally fail, a well-engineered system will provide a fall-back mechanism for discovering further hints. It is this fall-back mechanism, a UDS, that is being addressed in this document. As with all hints, there can never be a guarantee that access to a resource will be available to all clients, even if the resource is accessible to some. However, a UDS is expected to work with reasonably high reliability, and, hence, may result in increased response time. The remainder of this document falls into three sections. The first identifies several sets of assumptions underlying this work. The next lays out the requirements for a URN-resolution-service discovery service. This section is probably the most critical of the document, because it is this that provides the metric for whether or not a proposed scheme for a UDS is adequate or not. For the reader short on time, each of the three major subsections of the requirements section concludes with a summary list of the requirements identified in that section. The final section of the document lays out a framework for such UDSs. The purpose of this last section is to bound the search space for UDS schemes. One must be careful not to assume that because a UDS scheme fits within the framework that it necessarily meets the requirements. As will be discussed further in this last section, designing within the framework does not guarantee compliance, so compliance evaluation must also be part of the process of evaluation of a scheme. 2. Assumptions Based on previous internet drafts and discussion in both the URN BOFs and on the URN WG mailing list, three major areas of assumptions are apparent: longevity, delegation, and independence. Each will be discussed separately. The URN requirements state that a URN is to be a "persistent identifier". It is probably the case that nothing will last forever, but in the time frame of resources, users of those resources, and the systems to support the resources, the identifier should be considered to be persistent or have a longer lifetime than those other entities. There are two assumptions that are implied by longevity of URNs: mobility and evolution. "Mobility" assumes that. everything will move over the life of a URN. For example, resources will move from one machine to another, because individual machines have a much shorter lifetime than resources, generally measured in a number of years less than a decade. Owners of resources may move and wish their resources to follow them. The services themselves will move. "Evolutions" assumes that the supporting infrastructure will evolve. This may take the form of entirely new transport protocols or new versions of existing protocols. Furthermore, services such as storage services may evolve; it is even possible that within a human lifetime the Unix file system model may no longer be in use! Clearly there will be evolution of and improvement in supporting authentication and security mechanisms. These are only examples. In general, we must assume that almost any piece of the supporting infrastructure of URN resolution will evolve. In order to deal with both the mobility and evolution assumptions that derive URN Resolution Requirements Page 3 from the assumption of longevity, we must assume that users and their applications can remain independent of these mutating details of the supporting infrastructure. The second and third assumptions are two forms of modularity, delegation and isolation. The delegation assumption is that an entity may partition and pass off some of its authority or responsibility. One of those responsibilities is for assigning URNs; practically speaking, there cannot be only a single authority for assigning URNs. We expect that there will be a multi-tiered naming authority delegation. Furthermore, it is difficult to imagine a non-partitioned and delegated global UDS, meaning that hint discovery and resolution will be partitioned and delegated. In some UDS schemes, the delegation of naming authority will form a basis for delegating the management and dispensing of location information. The third assumption is independence or isolation of one authority from another and, at least to some extent from its parent. Underlying much of the thinking and discussion in the URI and URN working groups has been the assumption that when a component delegates authority to another component, the delegatee can operate in that domain independently of its peers and within bounds specified by the delegation, independently of the delegator. This isolation is critically important in order to allow for independence of policy and mechanism. There are a number of more specific assumptions that fall under this rubric of isolation. First, we assume that the publisher of a resource can choose resolution services, independently of choices made by others. At any given time, the owner of a namespace may choose a particular URN resolution service for that delegated namespace. Such a URN resolution service may be outside the UDS service model, and just identified or located by the UDS service. Second, it must be possible to make a choice among UDS services, perhaps based on different underlying internal architectures. The reason that this is an assumption is that there must be an evolutionary path through a sequence of core UDS services. Although at any given time there is likely to be only one or a small set of such services, the number is likely to increase during a transition period from one architecture to another. Thus, it must be assumed that clients can make a choice among a probably very small set of UDSs. Third, there must be independence in the choice about levels and models of security and authenticity required. This choice may be made by the owner of a naming subspace, in controlling who can modify hints in that subspace. A naming authority may delegate this choice to the owners of the resources named by the names it has assigned. There may be limitations on this freedom of choice in order to allow other participants to have the level of security and authenticity they require, for example, in order to maintain the integrity of the UDS infrastructure as a whole. Fourth, there is an assumption of independence of choice of the rule of canonicalization of URNs within a namespace, limited by any restrictions or constraints that may have been set by its parent namespace. This is a choice held by naming authorities over their own subnamespaces. Rules for canonicalization will be discussed further in the framework section below. Thus, there are assumptions of independence and isolation to allow for delegated, independent authority in a variety of domains. URN Resolution Requirements Page 4 The modularity assumptions of delegation and isolation imply independence of decision and implementation, leading to a decentralization that provides a certain degree of safety from denial of service. Based on these these assumptions in conjunction with that of longevity and those for URLs and URNs as detailed in RFCs 1736 and 1737, we can now turn to the requirements for a URN services delegation service. 3. Requirements The requirements applying to a URN-resolution-service discovery service or UDS center around three important design goals: evolvability, usability, and security and privacy. At its core the function of a UDS is to provide hints for accessing a resource given a URN for it. These hints may range in applicability from local to global, and from short-lived to long-lived. They also may vary in their degree of verifiable authenticity. While it may be neither feasible nor necessary that initial implementations support every requirement, every implementation must support evolution to systems that do support every requirement. It is also important to note that there are other requirements, not applicable specifically to a UDS that must also be met. A whole URN system will consist of namespaces, the resolution information for them, and the mapping from names in the namespaces to resolution information (or hints). URN schemes must meet the requirements of RFC 1737. Resolution information, to the extent it is expressed as URLs must meet the requirements of RFC 1736. But this does not tell the whole story. Although the URN working group will identify several acceptable namespaces and the rules binding them, such as how delegation occurs, how it is expressed in the names, how and to what extent binding to hint information will be constrained by the namespace, in the long run a document will be needed to guide the evaluation criteria for acceptance of new namespaces. These are not included in the list of requirements below because they are not requirements for a UDS, but rather for naming schemes themselves. 3.1 Evolution One of the lessons of the Internet that we must incorporate into the development of mechanisms for resolving URNs is that we must be prepared for change. Such changes may happen slowly enough to be considered evolutionary modifications of existing services or dramatically enough to be considered revolutionary. They may permeate the Internet universe bit by bit, living side by side with earlier services or they may take the Internet by storm, causing an apparent complete transformation over a short period of time. There are several directions in which we can predict the need for evolution, even at this time, prior to the deployment of any such service. At the very least, the community and the mechanisms proposed should be prepared for these. First, we expect there to be additions and changes to the mechanisms. The community already understands that there must be a capacity for new URN schemes. A URN scheme will define a set of URNs that meet the URN requirements[RFC1737], but may have further constraints on the internal URN Resolution Requirements Page 5 structure of the URN. The requirements document would allow for an overall plan in which URN schemes are free to specify parts of the URN that are left opaque in the larger picture. In fact, a URN scheme may choose to make public the algorithms for any such "opaque" part of the URN. For example, although it may be unnecessary to know the structure of an ISBN, the algorithm for understanding the structure of an ISBN has been made public. Other schemes may either choose not to make their algorithms public, or choose a scheme in which knowledge of the scheme does not provide any significant semantics to the user. In any case, we must be prepared for a growing number of URN schemes. Often in conjunction with a new URN scheme, but possibly independently of any particular URN scheme, new resolution services may evolve. For example, one can imagine a specialized resolution service based on the particular structure of ISBNs that improves the efficiency of finding documents given their ISBNs. Alternatively, one can also imagine a general purpose resolution service that trades performance for generality; although it exhibits only average performance resolving ISBNs, it makes up for this weakness by understanding all existing URN schemes, so that its clients can use the same service to resolve URNs regardless of naming scheme. In this context, there will always be room for improvement of services, through improved performance, better adaptability to new URN schemes, or lower cost. In any case, new models for URN resolution will evolve and we must be prepared to allow for their participation in the overall resolution of URNs. If we begin with one overall plan for URN resolution, into which the enhancements described above may fit, we must also be prepared for an evolution in the authentication schemes that will be considered either useful or necessary in the future. There is no single globally accepted authentication scheme, and there may never be one. Even if one does exist at some point in time, there will always be threats to it, and so we must always be prepared to move on to newer and better schemes, as the old ones become too easily spoofed or guessed. Lastly, in terms of mechanism, although we may develop and deploy a single UDS scheme initially, we must be prepared for that top level model to evolve. Thus, if the UDS model supports an apparently centralized (from a policy standpoint) scheme for inserting and modifying authoritative information, over time we must be prepared to evolve to a different model, perhaps one that has a more distributed model of authority and authenticity. If the model has no core but rather a cascaded partial discovery of information, we may find that this becomes unmanageable with an increase in scaling. Whatever the core of the model, we must be prepared for it to evolve with changes in scaling, performance, and policy constraints such as security and cost. Second, in addition to the evolution of resolution mechanisms, we expect that the community will follow an evolutionary path towards the separation of semantics from identification. The URN requirements document suggested this path as well, and there has been general agreement in much of the community that such a separation is desirable. This is a problem that the public at large has generally not understood. Today we see the problem most clearly with the use of URLs for identification. When a web page moves, its URL becomes invalid. URN Resolution Requirements Page 6 Suppose such a URL is embedded in some page, stored in long term storage. There are three possible outcomes to this scenario. One possibility is that the client is left high and dry with some message saying that the page cannot be found. Alternatively, a "forwarding pointer" may be left behind, in the form of an explicit page requesting the client to click on a new URL. Although this will allow the client to find the intended page, the broken link cannot be fixed because the URL is embedded in a file outside of the client's control. A third alternative is that the target server supplies an HTTP redirect so that the new page is provided for the client automatically. In this case, the client may not even realize that the URL is no longer correct. The real problem with both of these latter two situations is that they only work as long as the forwarding pointer can be found at the old URL. Semantics, in this case location information, was embedded in the identifier, and the resolution system was designed to depend on the semantics being correct. There are few cases in which we can expect semantics of any sort to remain valid for a long time, but in many cases references need to have long lifespans. Most documents are only useful while their references still function. We expect the evolution to separation of semantics from identification to move along at least three paths. The first will be to develop temporary aliases to capture the semantics currently embedded in identifiers. This will require additional translation, but it will allow for the development of semantics-free URNs. Second, we expect locally shared or private aliases to arise, again supported by a translation mechanism and allowing for the long-term storage of global, semantics-free URNs. Such an aliasing scheme may be used to permit local aliases for named resources as well as to present these aliases to users in lieu of the URNs themselves. Lastly, we expect there may be a development of global aliases. These will be more user friendly "names" that would be shared on a much larger scale, and might be defined in some global registry. This may include trademarked names as well as names in extremely common use. As with the other alias systems, a facility for translation is needed. However, in this case, since the system of aliases is of global scope, the translation facility will be very slow if each time an alias is translated it needs to query a centralized or even reasonably distributed global registry. In order to achieve acceptable speeds, the translation facility will need to maintain a local cache, possibly in cooperation with other nearby alias caches. Clearly this is all postulation at present, but it is provided here to demonstrate some of the scope of evolution for which we must be prepared. A third evolutionary requirement is even more mechanical than the others. At any point in time, the community is likely to be supporting a compromise position with respect to resolution. We will probably be operating in a situation balanced between feasibility and the ideal, perhaps with policy controls used to help stabilize the service. Ideally, the service would be providing exactly what the customers wanted and they in turn would not request more support than they need. Since we will always be in a situation in which some service provision resources will be in short supply, some form of policy controls will always be necessary. For example, suppose hint entries are being submitted in such volume that the hint servers are using up their excess URN Resolution Requirements Page 7 capacity and need more disk space. An effective solution to this problem would be a mechanism such as a pricing policy. This pricing policy has the dual effect of both encouraging conservative use of resources and collecting revenue for the improvement and maintenance of the system. As technology changes and the balance of which resources are in short supply changes, the mechanisms and policies for controlling their use must evolve as well. In summary, the requirements in the area of evolvability are: * To support evolution of mechanisms, specifically for a) a growing set of URN schemes; b) new local URN resolution schemes; c) new authentication schemes; d) alternative UDS schemes active simultaneously; * To support and encourage the evolution toward the separation of global identification from short-lived, locally useful, or human friendly semantics; * To support the development and deployment of pricing models to manage human behavior with respect to limited resources. 3.2 Usability and Feature Set Requirements Usability can be evaluated from three distinct perspectives: those of a publisher wishing to make a piece of information public, those of a client requesting URN resolution, and those of the provider or manager of resolution information. We will separately address the usability requirements from each of these three perspectives. It is worth noting that there are two additional sorts of participants in the whole naming process, as discussed in the URN WG. They are the naming authorities which choose and assign names, and the authors who include URNs in their resources. These two are not relevant to the design of a UDS and hence are not discussed further here. 3.2.1 The Publisher The publisher must be able to make URNs known to potential customers. >From the perspective of a publisher, it is of primary importance that URNs be correctly and efficiently resolvable by potential clients. Publishers also stand to gain from long-lived URNs, since they increase the chance that references continue to point to their published resources. The publisher must also be able to choose easily among a variety of potential services that might translate URNs to location information. In order to allow for this mobility among resolution services, the architecture for resolution services specified within the IETF should not result in a scenario in which changing from one resolution service to another is an expensive operation. The publisher should be able to arrange for multiple access points to a published resource. For this to be useful, resolution services should be prepared to provide different resolution or hint information to different clients, based on a variety of information including location and the various access privileges the client might have. For example, companies might arrange for locally replicated copies of popular URN Resolution Requirements Page 8 resources, and would like to provide access to the local copies only for their own employees. This is distinct from access control on the resource as a whole, and may be applied differently to different copies. The publisher should be able to provide both long and short term information about accessing the resource. Long term information is likely to be such information as the long term location of the resource or the location or identity of a resolution service with which the publisher has a long term relationship. One can imagine that the arrangement with such a long term "authoritative" resolution service might be a guarantee of reliability, resiliency to failure, and atomic updates. Shorter term information is useful for short term changes in services or to avoid short lived congestion or failure problems. For example, if the actual repository of the resource is temporarily inaccessible, the resource might be made available from another repository. This short term information can be viewed as temporary refinements of the longer term information, and as such should be more easily and quickly made available, but may be less reliable. Lastly, the publishers will be the source of much hint information that will be stored and served by the manager of the infrastructure. Despite the fact that many publishers will not understand the details of the UDS mechanism, it must be easy and straightforward to install hint information. The publisher must be able not only to express hints, but also to verify that what is being served by the manager is correct. Furthermore, to the extent that there are security constraints on hint information, the publisher must be able to both express them and verify compliance to them easily. 3.2.2 The Client >From the perspective of the client, simplicity and usability are paramount. Of critical importance to serving clients effectively is that there be an efficient protocol through which the client can acquire hint information. Since resolving the name is only the first step on the way to getting access to a resource, the amount of time spent on it must be minimized. Furthermore, it will be important to be able to build simple, standard interfaces to the UDS so that both the client and applications on the client's behalf can interpret hints and subsequently make informed choices. The client, perhaps with the assistance of the application, must be able to specify preferences and priorities and then apply them. If the ordering of hints is only partial, the client may become directly involved in the choice and interpretation of them and hence they must be understandable to that client. On the other hand, in general it should be possible to configure default preferences, with individual preferences viewed as overriding any defaults. >From the client's perspective, although URNs will provide important functionality, the client is most likely to interact directly only with human friendly names (HFNs). As in direct human interaction (not computer mediated), the sharing of names will be on a small,private, or domain specific scale. HFNs will be the sorts of references and names that are easy to remember, type, choose among, assign, etc. There will URN Resolution Requirements Page 9 also need to be a number of mechanisms for mapping HFNs to URNs. Such services as "yellow pages" or "search tools" fall into this category. Although we are mentioning HFNs here, it is important to recognize that HFNs and the mappings from HFNs to URNs is and must remain a separate functionality from a UDS. Hence, although HFNs will be critical to clients, they do not fall into the domain of this document. 3.2.3 The Management Finally, we must address the usability concerns with respect to the management of the hint infrastructure itself. What we are terming "management" is a service that is distinct from publishing; it is the core of a UDS. It involves the storage and provision of hints to the clients, so that they can find published resources. It also provides security to the extent that there is a commitment for provision of such security; this is addressed below. The management of hints must be as unobtrusive as possible. First, its infrastructure (hint storage servers and distribution protocols) should have as little impact as possible on other network activities. It must be remembered that this is an auxiliary activity and must remain in the background. Second, in order to make hint management feasible, there will need to be a system for economic incentives and disincentives. Recovering the cost of running the system is only one reason for levying charges. The introduction of payments often has a beneficial impact on social behavior. It may be necessary to discourage certain forms of behavior that when out of control have serious negative impact on the whole community. At the same time, payment policies should encourage behavior that benefits the community as a whole. Thus, for example, a small one-time charge for authoritatively storing a hint will encourage conservative use of hints. If we assume that there is a fixed cost for managing a hint, then the broader its applicability across the URN space, the more cost effective it is. That is, when one hint can serve for a whole collection of URNs, there will be an incentive to submit one general hint over a large number of more specific hints. Similar policies can be instituted to discourage the frequent changing of hints. In these ways and others, cost effective behavior can be encouraged. Lastly, symmetric to issues of usability for publishers, it must also be simple for the management to configure the mapping of URNs to hints. It must be easy both to understand the configuration and to verify that configuration is correct. With respect to management, this requirement may have an impact not only on the information itself but also on how it is partitioned among network servers that collaboratively provide the management service or UDS. For example, it should be straightforward to bring up a server and verify that the data it is managing is correct. Since we are discussing a global and probably growing service, encouraging volunteer participants requires that, as with the DNS, such volunteers can feel confident about the service they are providing and its benefit to both themselves and the rest of the community. URN Resolution Requirements Page 10 To summarize, the usability requirements fall into three areas based on participation in hint management and discovery: * The publisher a) URN to hint resolution must be correct and efficient; b) Publishers must be able to select among URN resolution services to locate their resources; c) Publishers must be able to arrange for multiple access points for their location information; d) Publishers must be able to provide for both long-lived and short-lived hints; e) It must be relatively easy for publishers to install and observer their hint information and any security constraints they need for their hints. * The client a) The interface to the UDS must be simple, effective, and efficient; b) The client and client applications must be able to understand the information stored in and provided by the UDS, in order to be able to make informed choices. * The management a) The management of hints must be as unobtrusive as possible, avoiding using too many network resources; b) A pricing scheme may be necessary to provide not only cost recovery, but also social incentives and disincentives to encourage certain sorts of behavior deemed necessary to meet other requirements; c) The configuration and verification of configuration of individual UDS servers must be simple enough not to discourage configuration and verification. 3.3 Security and Privacy Requirements Although much of the information we are discussing in this document might be considered "meta-information", there are some important security and privacy concerns that must be addressed by a service supporting that information. By first considering the sorts of attacks that are of concern, we can then focus on the security and privacy issues that are important. The reader will notice that integrity plays less of a role here than might be expected. To the extent that servers provide access control, the information they manage will have certain integrity guarantees. Beyond that we must recognize that we are dealing merely with hint information about the location of possibly interesting resources. Therefore we believe that the benefit of providing integrity guarantees beyond those provided by the servers themselves does not outweigh the cost. Because the majority of the activity will be the distribution of hint information, the threats of concern are those affecting the maintenance of correct information to distribute and the availability of the sources of information. The first approach to URN resolution is to discover local hints. By being local, they will be as widely distributed as possible. The drawback of such wide distribution is the inability to update them; therefore, they will become out of date with time. An alternative or backup mechanism would concentrate hint information in URN Resolution Requirements Page 11 servers, thus requiring that update information only be distributed to these servers. Hence the vulnerable points are the sources of the information and the distribution network among them. If one assumes that there will be principals of some sort that are responsible for the information about each URN entry in the URN resolution service, then one major threat is an attacker that masquerades as a valid principal and inserts incorrect information into the service. A second threat vector results from the fact that the service itself will be implemented by a set of servers that collaborate and share the hint information critical to their activities. By masquerading as a valid server in this pool, an attacker can both provide incorrect information to clients and provide incorrect information to other servers, which those servers will then distribute. A third threat is that if the resolution service is too centralized, service can be denied by a variety of network attacks ranging from flooding the service with queries to causing various network problems that will reduce access to the service. The more centralized a service is the more vulnerable is the community that trusts it not to be compromised. We can turn each of these into a security goal. * ACCESS CONTROL ON HINTS: There needs to be an authoritative version of each hint, and it must support change control limited only to those principals with the right to modify it. The choice of who those principals are or whether they are unlimited must be made by the publisher of a hint. * SERVER AUTHENTICITY: Servers and clients must be able to learn the identity of the servers with which they communicate. This will be a matter of degree and it is possible that there will be more trustworthy, but less accessible servers, supported by a larger cluster of less authenticatable servers that are more widely available. In the worst case, if the client receives what appears to be invalid information, the client should assume that the hint may be inaccurate and confirmation of the data should be sought from more reliable but less accessible data. * SERVER DISTRIBUTION: Broad availability will provide resistance to denial of service. It is only to the extent that the services are available that they provide any degree of trustworthiness. In addition, the distribution of services will reduce to vulnerability of the whole community, by reducing the trust put in any single server. This must be mitigated by the fact that to the extent trust is based on a linked set of servers, if any one fails, the whole chain of trust fails; the more elements there are in such a chain, the more vulnerable it may become. _Ensuring_ privacy for clients and publishers is in some respects essentially impossible. Fortunately, assuring a reasonable degree of privacy for those who want it is possible. The privacy of clients is primarily threatened by packet sniffers and servers that log requests. A server or a packet sniffer can without much difficulty record the contents of queries as they pass by and compile the information into a relation between URNs and clients. This can be combatted by anonymizing queries through a trusted, fairly local gateway, although it involves an URN Resolution Requirements Page 12 extra step and another potential bottleneck. The additional step can be mitigated by caching responses in the gateway, thus often avoiding the need to forward requests beyond it. A second alternative is to send only partial queries. As will be discussed further in the framework section, there may be two reasons for transformation of a URN, first to canonicalize it and second to extract the identity of another server to which to send a further request. This second alternative of sending partial queries would be achieved by also extracting some partial URN to further resolve at each stage. This would not anonymize the queries, but might make them more difficult to chain together into a complete story for logging. On the other hand, to the degree that the search process is distributed, packet sniffing at a single point is less likely to reveal data about a specific person, and is hence less threatening to privacy. Furthermore, if clients have flexibility in terms of the specific services they choose to use, they can regularly switch services in the hopes of foiling a packet sniffer watching their usual access point. The privacy of publishers is much easier to safeguard. Since they are trying to publish something, in some situations privacy is probably not desired. However, publishers do have information that they might like to keep private: information about who their clients are, and information about what names exist in their namespace. The information about who their clients are may be difficult to collect depending on the implementation of the resolution system. For example, if the resolution information relating to a given publisher is widely replicated, the hits to _each_ replicated copy will need to be recorded. Of course, determining if a specific client is requesting a given name can be approached from the other direction, by watching the client as we saw above. The other privacy issue for publishers has to do with access control over URN resolution. This issue is dependent on the implementation of the publisher's authoritative URN resolution server. URN resolution servers can be designed to require proof of identity in order to be issued resolution information; if the client does not have permission to access the URN requested, the service denies that such a URN exists. An encrypted protocol can also be used so that both the request and the response are obscured. Encryption is possible in this case because the identity of the final recipient is known (i.e. the URN server). In summary, security and privacy requirements can be identified as some degree of protection from threats: * It must be possible to create authoritative versions of a hint with access to modification privileges controlled; * It must be possible to determine the identity of servers or avoid contact with unauthenticated servers; * Broad availability of servers will reduce the thread to denial of service; * Client privacy is threatened by packet sniffing and server logging. It is desirable to reduce these threats as much as possible; * It should be feasible for publishers to keep private certain URN Resolution Requirements Page 13 information such as an overall picture of the resources they are publishing and the identity of their clients; * Publishers should be able to restrict access to the resolution of the URNs for the resources they publish, if they wish. 4. The Framework With these assumptions and requirements in mind, one can conclude with a general framework within which UDS designs will fall. As stated earlier, although this framework is put forth as a suggested guide for UDS designers, compliance with it will in no way guarantee compliance with the requirements. Such an evaluation must be performed separately. It is also understood that there may be UDS services that do not meet the requirements in clearly identified ways. This may be true especially with early plans and experiments. For example, although a careful threat analysis may have been done to understand security requirements, not all those security requirements may be addressed, in order to use existing facilities to allow for early deployment for experimentation purposes. All such lack of compliance should be clearly documented. The design of the framework is based on a simple assumption about the syntax of a URN. This assumed syntax is: URN:: where URN: is a prefix on all URNs, NID is the namespace identifier, and NSS is the namespace specific string. The prefix identifies each URN as such. The NID determines the general syntax for all URNs within its namespace. The NSS is probably partitioned into a set of delegated and subdelegated namespaces, and this is probably reflected in further syntax specifications. In the more complex environments, each delegated namespace will be permitted to choose the syntax of the variable part of the namespace that has been delegated to it. In simpler namespaces, the syntax will be restricted completely by the parent namespace. For example, although the DNS does not meet all the requirements for URNs, it has a completely restricted syntax, such that any further structuring must be done only by adding further refinements to the left, maintaining the high order to low order, right to left structure. A delegated syntax might be one in which a host is named by the DNS, but to the right of that and separated by an "@" is a string whose internal ordering is defined by the file system on the host, which may be defined high order to low order, left to right. Of course, much more complex and nested syntaxes should be possible, especially given the need to grandfather namespaces. In order to resolve URNs, rules will be needed for two reasons. One is simply to canonicalize those namespaces that do not fall into a straightforward (probably right to left or left to right) ordering of the components of a URN, as determined by the delegated naming authorities involved. It is also possible that rules will be needed in order to derive from URNs the names of UDS servers to be used in stages. The NID defines a top level syntax. This syntax will determine whether the NID alone or in conjunction with some extraction from the NSS (for the top level naming authority name) to identify the first level server URN Resolution Requirements Page 14 to be contacted. Each stage of the lookup either a new rule for generating the strings used in yet another lookup (the strings being the identify of another UDS server and possibly a string to be resolved if it is different than the original URN) or a reference outside the UDS to a private URN resolution service, sidestepping any furthere use of the UDS scheme. Figure 1 depicts this process. URN: | | | | v +-------------------+ |Global NID registry| +-------------------+ | | | (return rule or URN resolution service reference) | +----------------------------------+ | | +->(apply rule to determine UDS server) | | | | | | | | | | | +----------+ | | |UDS server| +-----------------+ | +----------+ | | | | v | | | (set of choices) | | +----+----------(...)--------+ | (rule) | | | | | | | | | | +------+ | | v v +----------+ +----------+ |private | |private | |URN | |URN | |resolution| |resolution| |service | |service | +----------+ +----------+ Figure 1: A UDS framework There are several points worth noting about the UDS framework. First, it leaves open the determination of the protocols and data organization, distribution and replication needed to support a particular UDS scheme. Second, it leaves open the location of the computations engendered by URN Resolution Requirements Page 15 the rules. Third, it leaves open the possibility that partitioning (distribution) of the UDS database need not be on the same boundaries as the name delegation. This may seem radical to some, but if the information is stored in balanced B-trees for example, the partitioning may not be along those naming authority delegation boundaries. Lastly, it leaves open access to the Global NID Registry. Is this distributed to every client, or managed in widely distributed servers? One concept that has not been addressed in Figure 1 is that there may be more than one UDS available at any given time, in order to allow for evolution to new schemes. Thus, the picture should probably look more like Figure 2. URN:: | | +-----------+-------(...)-------+ | | | | | | v v +---------------------+ +---------------------+ |Global NID registry 1| |Global NID registry N| +---------------------+ +---------------------+ . . . . . . Figure 2: More than one co-existing UDS scheme If we are to support more than one co-existing UDS scheme, there will need to be coordination between them with respect to storage and propagation of information and modifications. The issue is that generally it should be assumed that all information should be available through any operational UDS scheme. One cannot expect potential publishers to submit updates to N UDS schemes. Hence there will need to be a straightforward mapping of information from one to the other of these schemes. It is possible that that transformation will only go in one direction, because a newer UDS service is replacing an older one, which is not kept up to date, in order to encourage transfer to the newer one. Thus, at some point, updates may be made only to the newer one and not be made available to the older one. Such a situation should probably be avoided, if possible. This framework is presented in order to suggest to UDS scheme designers a direction in which to start designing. It is obvious to the reader that adherence to this framework will in no way guarantee compliance with the requirements or even assumption described in Sections 2 and 3. These must be reviewed independently as part of the design process. There is no single correct design that will meet these requirements. Furthermore, it is assumed that preliminary proposals may not meet all the requirements, but should be expected to itemized and justify any lack of compliance. URN Resolution Requirements Page 16 5. References [RFC1736] Kunze, J., "Functional Recommendations for Internet Resource Locators", RFC 1736, February, 1995. [RFC1737] Sollins, K. and Masinter, L., "Functional Requirements for Uniform Resource Names", RFC 1738, December, 1994. [RFC1738] Berners-Lee, T., Masinter, L., McCahill, M., "Uniform Resource Locators (URL)", RFC 1738, December, 1994. 6. Contact information: Karen Sollins MIT Laboratory for Computer Science 545 Technology Sq. Cambridge, MA 02139 Tel: +1 617 253 6006 Email: sollins@lcs.mit.edu This InternetDraft expires on May 26, 1997. URN Resolution Requirements Page 17 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA10454 for urn-ietf-out; Tue, 26 Nov 1996 11:44:26 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA10449 for ; Tue, 26 Nov 1996 11:44:24 -0500 Received: from gizmo.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16695 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 11:44:13 -0500 Received: from mrrl.lut.ac.uk (martin@localhost.mrrl.lut.ac.uk [127.0.0.1]) by gizmo.lut.ac.uk (8.8.3/8.6.9) with ESMTP id QAA18687 for ; Tue, 26 Nov 1996 16:43:46 GMT Message-Id: <199611261643.QAA18687@gizmo.lut.ac.uk> X-Mailer: exmh version 1.6.9 8/22/96 To: urn-ietf Subject: Re: [URN] Collecting open issue information on the syntaxdraft... X-Uri: In-Reply-To: Your message of "Tue, 26 Nov 1996 08:46:35 MST." <2.2.32.19961126154635.00d18aa0@acl.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 26 Nov 1996 16:43:46 +0000 From: Martin Hamilton Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin Hamilton Errors-To: owner-urn-ietf@bunyip.com Ron Daniel writes: | What I want to | see first is the use of internationally standardized namespaces such | as ISBN for on-line access to books, ISSN/SICI for access to magazine, | journal, and newspaper articles; ISAN for access to video programs and | movies; ISWC/ASCAP/BMI identifiers for access to music; UPC for access | to product descriptions, etc. National Standards bodies, such as ANSI, | and industry associations, such as the EIA, may also have developed | namespaces we could support. How about RFCs for starters ? :-) Martin Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA09376 for urn-ietf-out; Tue, 26 Nov 1996 10:45:09 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA09371 for ; Tue, 26 Nov 1996 10:45:07 -0500 Received: from ietf.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15902 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 10:45:03 -0500 Received: from ietf.org by ietf.org id aa19547; 26 Nov 96 9:20 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: urn-ietf@bunyip.com From: Internet-Drafts@ietf.org Subject: [URN] I-D ACTION:draft-ietf-urn-req-frame-00.txt Date: Tue, 26 Nov 1996 09:20:46 -0500 Message-Id: <9611260920.aa19547@ietf.org> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org Errors-To: owner-urn-ietf@bunyip.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Requirements and a Framework for URN Resolution Systems Author(s) : K. Sollins Filename : draft-ietf-urn-req-frame-00.txt Pages : 17 Date : 11/25/1996 This document addresses the issues of the discovery of local URN resolution services that in turn will directly translate URNs into URLs and URCs. The document falls into three major parts, the assumptions underlying the work, the requirements in order to be a viable URN-resolution-service discovery service or UDS, and a framework for designing UDSs. The requirements fall into three major areas: evolvability, usability, and security and privacy. A UDS that is compliant with the framework will not necessarily be compliant with the requirements. Compliance with the requirements will need to be validated separately. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-req-frame-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-req-frame-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-req-frame-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961125154650.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-req-frame-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-req-frame-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961125154650.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA09290 for urn-ietf-out; Tue, 26 Nov 1996 10:38:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA09284 for ; Tue, 26 Nov 1996 10:38:12 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15756 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 10:38:08 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id IAA17468; Tue, 26 Nov 1996 08:37:59 -0700 (MST) Message-Id: <2.2.32.19961126154635.00d18aa0@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Nov 1996 08:46:35 -0700 To: Fisher Mark , urn-ietf From: Ron Daniel Subject: Re: [URN] Collecting open issue information on the syntaxdraft... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Fisher Mark (at least at 08:03 AM 11/26/96 EST) >I am curious as to how you see URNs being used. From my perspective as an >Intranet service provider, I could well see URNs in use by at least (almost) >each Fortune 500 company, as well as many academic and research >organizations, with each one having their own namespace. This is exactly what I do NOT want to see happen early on, although such namespaces are going to occur in the fullness of time. What I want to see first is the use of internationally standardized namespaces such as ISBN for on-line access to books, ISSN/SICI for access to magazine, journal, and newspaper articles; ISAN for access to video programs and movies; ISWC/ASCAP/BMI identifiers for access to music; UPC for access to product descriptions, etc. National Standards bodies, such as ANSI, and industry associations, such as the EIA, may also have developed namespaces we could support. The Fortune 500 already make use of one or more of these namespaces for particular purposes (especially UPC). Until we come up with the procedures for registering company-specific namespaces and dealing with the inevitable conflicts over trademark-style issues, I want to err on the side of caution. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA08760 for urn-ietf-out; Tue, 26 Nov 1996 09:37:32 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA08755 for ; Tue, 26 Nov 1996 09:36:55 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15310 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 09:36:53 -0500 Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <16862(1)>; Tue, 26 Nov 1996 06:36:30 PST Received: by palimpsest.parc.xerox.com id <135>; Tue, 26 Nov 1996 06:36:16 PDT To: rbriscoe@jungle.bt.co.uk Cc: FisherM@is3.indy.tce.com, Harald.T.Alvestrand@uninett.no, urn-ietf@bunyip.com Subject: Re: [URN] Persistence as part of URN framework From: Larry Masinter Message-Id: <96Nov26.063616pdt."135"@palimpsest.parc.xerox.com> Date: Tue, 26 Nov 1996 05:36:16 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com # All I wanted was an *optional* persistence value to be possible, so that the # URN resolution service could indicate the longevity of the resolver (not the # URN), at least until the longevity was extended once the people managing it # were willing to commit to a longer running service. ... # No-one seems to be able to get their head round the fact that such expiry # times are meaningless if you don't know how long you will be able to resolve # URNs which end up pointing to HTTP, but might point to another scheme later # to keep them alive. I think the problem is that people just aren't thinking # in terms of how much the world will change in the decades ahead. All I'm # trying to propose is a way to avoid having to poll for broken resolution # services in the future. # I give up. No URN resolution protocol that doesn't explicitly deal with the issues of what happens when providers quit, merge, or split can seriously claim to address URN requirements. A protocol can be marked as 'Experimental', but even Experimental drafts can be marked to clearly indicate what parts of the problem they're not handling. The experiment then can help determine how serious, in practice, the problem really is. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA08375 for urn-ietf-out; Tue, 26 Nov 1996 09:12:45 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA08370 for ; Tue, 26 Nov 1996 09:12:43 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15222 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 09:12:41 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id JAA23138; Tue, 26 Nov 1996 09:12:41 -0500 Message-Id: <199611261412.JAA23138@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Tue, 26 Nov 1996 09:12:40 -0500 In-Reply-To: Fisher Mark's message as of Nov 26, 8:03 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Fisher Mark , Ron Daniel , urn-ietf Subject: Re: [URN] Collecting open issue information on the syntaxdraft... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com [Mark Fisher wrote:] > I am curious as to how you see URNs being used. From my perspective as an > Intranet service provider, I could well see URNs in use by at least (almost) > each Fortune 500 company, as well as many academic and research > organizations, with each one having their own namespace. Sounds like an > awful lot of work to me for those of us on the mailing list to have to vet > each of those namespaces... In the running terminology, "a namespace" refers to a particular name assignment/resolution structuring -- e.g., ISBNs might be "a namespace". While there will be some kind of overall governing of individual namespaces, assignment of subspaces is expected/needed. I think your examples are really about individual companies/institutions/ISPs wanting to have a piece of a space to control, adn that is definitely expected (e.g., top-level domains are individually controlled and partitioned in DNS; but the "owner" of a domain name can assign as many subdomains as they want, subject to the rules of DNS, not the domain-assigner). I think that, given one or two "inet"-type URN namespaces, what the organizations you've cited will want is the ability to assign names in (some part of) those spaces. Leslie. -- ---------------------------------------------------------------------------- "The light at the end of the tunnel Leslie Daigle is often the blindingly obvious..." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA07970 for urn-ietf-out; Tue, 26 Nov 1996 08:19:49 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA07965 for ; Tue, 26 Nov 1996 08:19:47 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15077 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 08:19:45 -0500 Received: by seawall with (8.6.12/) id IAA10989; Tue, 26 Nov 1996 08:19:42 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma010979; Tue Nov 26 08:19:27 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <329AEF40@MSMAIL.INDY.TCE.COM>; Tue, 26 Nov 96 08:23:12 EST From: Fisher Mark To: Ron Daniel , urn-ietf Subject: Re: [URN] Collecting open issue information on the syntaxdraft... Date: Tue, 26 Nov 96 08:03:00 EST Message-Id: <329AEF40@MSMAIL.INDY.TCE.COM> Encoding: 21 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com >I recommend that, for some time, new namespaces receieve standards-track >review, rather like new URL schemes currently do. That review process >is the place where we can address concerns such as limited longevity or >legal liability due to the inclusion of particular attempts at >"friendliness". The syntax draft does not have to address that issue one >way or the other. I am curious as to how you see URNs being used. From my perspective as an Intranet service provider, I could well see URNs in use by at least (almost) each Fortune 500 company, as well as many academic and research organizations, with each one having their own namespace. Sounds like an awful lot of work to me for those of us on the mailing list to have to vet each of those namespaces... (The "Fortune 500", for non-U.S. listmembers, is the top 500 companies in the U.S. as rated by the U.S. magazine "Fortune". Lots of namespaces to check out...) ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA06514 for urn-ietf-out; Tue, 26 Nov 1996 05:27:29 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA06509 for ; Tue, 26 Nov 1996 05:27:14 -0500 Received: from [132.146.5.1] by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12468 (mail destined for urn-ietf@services.bunyip.com); Tue, 26 Nov 96 05:27:11 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 26 Nov 1996 10:26:29 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 26 Nov 1996 10:26:06 +0000 Received: from by kaa.jungle.bt.co.uk; Tue, 26 Nov 96 10:24:45 GMT Message-Id: <2.2.32.19961126102739.006cf950@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 26 Nov 1996 10:27:39 +0000 To: Fisher Mark From: Bob Briscoe Subject: Re: [URN] Persistence as part of URN framework Cc: "Harald.T.Alvestrand@uninett.no" , "urn-ietf@bunyip.com" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com Mark, Many apologies for such a long time replying. I had to get some work delivered, which translates to "ignore mailing lists". All I wanted was an *optional* persistence value to be possible, so that the URN resolution service could indicate the longevity of the resolver (not the URN), at least until the longevity was extended once the people managing it were willing to commit to a longer running service. If the people running the resolver weren't willing to think about persistence, a default longevity value of 0 could be sent out in the NAPTR records. However, I can find no-one else who considers this important, so I'll drop out. I've been off-line with Ron Daniel who is happy that schemes such as HTTP which have expiry headers can get this information to you once you have resolved how to speak to HTTP. No-one seems to be able to get their head round the fact that such expiry times are meaningless if you don't know how long you will be able to resolve URNs which end up pointing to HTTP, but might point to another scheme later to keep them alive. I think the problem is that people just aren't thinking in terms of how much the world will change in the decades ahead. All I'm trying to propose is a way to avoid having to poll for broken resolution services in the future. I give up. Bob At 09:53 07/11/96 EST, Fisher Mark wrote: > >>Using DNS TTL records for this is just broken; DNS TTLs are used >>to limit caching of name->address mapping, and in the NAPTR proposal, >>they should be a fraction of the time one expects to have advance >>warning of a server relocation or mapping restructure. >>Normal TTLs are on the order of 3 days, and are usually reduced to less >>than 1 day before serious network reorganizations. > >And if you are changing your resolution services faster than that, you are >changing them too fast (IMHO). Perhaps the key idea TimBL came up with in >devising the Web was that, unlike other hypertext systems (including the >Dexter model), links could be broken, i.e. nonfunctional. This single idea >was perhaps above all others important in spreading the Web far and wide, as >perfectly reliable systems as difficult to construct (even for an >appropriately low value of "perfect"). Under the Dexter model, an >application will die or limp on after reporting an internal error upon >encountering a broken hyperlink. In the Web, the UA just keeps surfing on >to the next link. > >All that URNs can do is assist in persistence; persistence itself must be >maintained outside the URN architecture, as persistence is ultimately a >political/economic quality, not a technical quality. We would expect a BT >URN to persist because of our trust in BT, not because there is some >technical solution to persistence. Persistence is assisted in URNs by the >ability to hand off resolution duties automagically to successor resolution >entities. I would regard measures of persistence to be an optional but >necessary part of the metadata for a URN, not as mandatory metadata. It is >quite possible that URN will see incredibly wide use, as much or more as >URLs are now ("every person a URN namespace owner"). Many of these >namespaces may just persist for a few years or months, with the owner not >caring about measures of persistence. Persistence is ultimately up to the >creating/resolving entity(s). > >Uniqueness is an easier problem than persistence, although uniqueness has a >strong political/economic component. One can certainly imagine the case of >URNs for government materials that, after they are first created for public >consumption, are found to be embarrassing to that government and the URNs >are silently, suddenly changed to refer to much more innocuous materials. > Uniqueness, also, is ultimately up to the creating/resolving entity. >====================================================================== >Mark Leighton Fisher Thomson Consumer Electronics >fisherm@indy.tce.com Indianapolis, IN > > Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA24916 for urn-ietf-out; Mon, 25 Nov 1996 12:06:02 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA24907 for ; Mon, 25 Nov 1996 12:05:47 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06863 (mail destined for urn-ietf@services.bunyip.com); Mon, 25 Nov 96 12:05:27 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id MAA17730; Mon, 25 Nov 1996 12:05:22 -0500 Date: Mon, 25 Nov 1996 12:05:22 -0500 Message-Id: <199611251705.MAA17730@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: urn-ietf@bunyip.com Subject: [URN] URN resolution requirements and framework Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com Hi! Attached is the first draft of a proposed document on requirements and a framework for URN resolution. It is based on the internet drafts presented at the URN BOF in Montreal separately on requirements (without the discussion of various schemes) and the framework document by Leslie, Patrik, and Renato. I have added an additional preliminary section on assumptions, which seems important in light of some of the discussions on this list. I've also tried to enhance the requirements, again based on discussions and broaden the framework a little, to make it less specific to the NAPTR proposal, in order to extend its utility. We will talk about it in San Jose, but in the meantime comments and discussion (no rotten eggs or tomatoes, please:-) are welcome. Karen PS: To the Americans on the list, have a nice Thanksgiving! ______________________________ Internet Draft Karen R. Sollins draft-ietf-urn-req-frame-00.txt MIT/LCS Expires May 26, 1997 November 26, 1996 Requirements and a Framework for URN Resolution Systems Status of this draft This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract: This document addresses the issues of the discovery of local URN resolution services that in turn will directly translate URNs into URLs and URCs. The document falls into three major parts, the assumptions underlying the work, the requirements in order to be a viable URN-resolution-service discovery service or UDS, and a framework for designing UDSs. The requirements fall into three major areas: evolvability, usability, and security and privacy. A UDS that is compliant with the framework will not necessarily be compliant with the requirements. Compliance with the requirements will need to be validated separately. 1. Introduction The purpose of this document is to lay out the engineering criteria for what we will call here a URN-resolution-service discovery service (UDS). __________ Acknowledgments Foremost acknowledgment for this document goes to Lewis Girod, as my co-author on a previous URN requirements document and for his insightful comments on this version of the document. In addition, I recognize the contributors to a previous URN framework document, the "Knoxville" group. There are too many of you to acknowledge here individually, but thank you. Finally, I must thank the contributors to the URN working group mailing list (urn-ietf@bunyip.com), for their animated discussions on these and related topics. URN Resolution Requirements Page 1 This is a component of the realization of an information infrastructure. In the case of this work, that infrastructure is to be available, "in the Internet" or globally, and hence the solutions to the problems we are addressing must globally scalable. In this work, we are focussing specifically on naming of resources and resolution of those names to the exclusion of other problems such as typing, resource access and availability, security of the resources, etc. Those are all important problems, but not part of this effort. The Uniform Resource Identifier Working Group defined a naming architecture, as demonstrated in a series of three RFCs 1736[RFC1736], 1737{RFC1737}, and 1738[RFC1738]. Although several further documents are needed to complete the description of that architecture, it incorporates three core functions often associated with "naming": identification, location, and mnemonics or semantics. Names may provide the ability to distinguish one resource from another, by distinguishing their "names". Names may help to provide access to a resource by including "location" information. Lastly, names may have other semantic or mnemonic information that either helps human users remember or figure out the names, or include other semantic information about the resource being named. The URI working group concluded that there was need for persistent, globally unique identifiers, distinct from location or other semantic information; these "names" provide identity, in that if two of them are "the same" (under some simple rule of canonicalization), they identify the same resource. Furthermore, the group decided that these "names" were generally to be for machine, rather than human consumption. One can imagine a variety human-friendly naming (HFN) schemes supporting different suites of applications and user communities. These will need to provide mappings to URNs in tighter or looser couplings, depending on the namespace. It is these that will be mnemonic, content-full, and perhaps mutable, to track changes in use and semantics. They may provide nicknaming and other aliasing, relative or short names, context sensitive names, descriptive names, etc. The URI naming architecture as described in the introductions to RFCs 1736 and 1737 lays out three sorts of components to the naming architecture: identifiers called Uniform Resource Names (URNs), locators called Uniform Resource Locators (URLs) and semantic meta-information called Uniform Resource Characteristics (URCs). This document focusses on part of the problem of the translation from URN to URL and/or URC. Within the URI community there has been a concept used frequently that for lack of a better term we will call a _hint_. A hint is something that helps in the resolution of a URN. Examples of hints are: 1) the name of a resolution service that may further resolve the URN, 2) the address of such a service, 3) a location at which the resource was previously found. The defining feature of hints is that they are only hints; they may be out of date, temporarily invalid, or only applicable within a specific locality. They do not provide a guarantee of access, but they probably will help in the resolution process. Wemust assume that most resolutions of URNs will be provided by the use of locally stored hints, because maintaining a database of globally available, completely up-to-date location information is infeasible for performance reasons. There are a number of circumstances in which one can imagine that hints become invalid, either because a resource has moved or because a different URN resolution service has taken over the URN Resolution Requirements Page 2 responsibility for resolution of the URN. Hints may be found in a variety of places. It is generally assumed that a well engineered system will maintain a set of hints for each URN at each location where that URN is found. In addition, for those situations in which those hints found locally fail, a well-engineered system will provide a fall-back mechanism for discovering further hints. It is this fall-back mechanism, a UDS, that is being addressed in this document. As with all hints, there can never be a guarantee that access to a resource will be available to all clients, even if the resource is accessible to some. However, a UDS is expected to work with reasonably high reliability, and, hence, may result in increased response time. The remainder of this document falls into three sections. The first identifies several sets of assumptions underlying this work. The next lays out the requirements for a URN-resolution-service discovery service. This section is probably the most critical of the document, because it is this that provides the metric for whether or not a proposed scheme for a UDS is adequate or not. For the reader short on time, each of the three major subsections of the requirements section concludes with a summary list of the requirements identified in that section. The final section of the document lays out a framework for such UDSs. The purpose of this last section is to bound the search space for UDS schemes. One must be careful not to assume that because a UDS scheme fits within the framework that it necessarily meets the requirements. As will be discussed further in this last section, designing within the framework does not guarantee compliance, so compliance evaluation must also be part of the process of evaluation of a scheme. 2. Assumptions Based on previous internet drafts and discussion in both the URN BOFs and on the URN WG mailing list, three major areas of assumptions are apparent: longevity, delegation, and independence. Each will be discussed separately. The URN requirements state that a URN is to be a "persistent identifier". It is probably the case that nothing will last forever, but in the time frame of resources, users of those resources, and the systems to support the resources, the identifier should be considered to be persistent or have a longer lifetime than those other entities. There are two assumptions that are implied by longevity of URNs: mobility and evolution. "Mobility" assumes that. everything will move over the life of a URN. For example, resources will move from one machine to another, because individual machines have a much shorter lifetime than resources, generally measured in a number of years less than a decade. Owners of resources may move and wish their resources to follow them. The services themselves will move. "Evolutions" assumes that the supporting infrastructure will evolve. This may take the form of entirely new transport protocols or new versions of existing protocols. Furthermore, services such as storage services may evolve; it is even possible that within a human lifetime the Unix file system model may no longer be in use! Clearly there will be evolution of and improvement in supporting authentication and security mechanisms. These are only examples. In general, we must assume that almost any piece of the supporting infrastructure of URN resolution will evolve. In order to deal with both the mobility and evolution assumptions that derive URN Resolution Requirements Page 3 from the assumption of longevity, we must assume that users and their applications can remain independent of these mutating details of the supporting infrastructure. The second and third assumptions are two forms of modularity, delegation and isolation. The delegation assumption is that an entity may partition and pass off some of its authority or responsibility. One of those responsibilities is for assigning URNs; practically speaking, there cannot be only a single authority for assigning URNs. We expect that there will be a multi-tiered naming authority delegation. Furthermore, it is difficult to imagine a non-partitioned and delegated global UDS, meaning that hint discovery and resolution will be partitioned and delegated. In some UDS schemes, the delegation of naming authority will form a basis for delegating the management and dispensing of location information. The third assumption is independence or isolation of one authority from another and, at least to some extent from its parent. Underlying much of the thinking and discussion in the URI and URN working groups has been the assumption that when a component delegates authority to another component, the delegatee can operate in that domain independently of its peers and within bounds specified by the delegation, independently of the delegator. This isolation is critically important in order to allow for independence of policy and mechanism. There are a number of more specific assumptions that fall under this rubric of isolation. First, we assume that the publisher of a resource can choose resolution services, independently of choices made by others. At any given time, the owner of a namespace may choose a particular URN resolution service for that delegated namespace. Such a URN resolution service may be outside the UDS service model, and just identified or located by the UDS service. Second, it must be possible to make a choice among UDS services, perhaps based on different underlying internal architectures. The reason that this is an assumption is that there must be an evolutionary path through a sequence of core UDS services. Although at any given time there is likely to be only one or a small set of such services, the number is likely to increase during a transition period from one architecture to another. Thus, it must be assumed that clients can make a choice among a probably very small set of UDSs. Third, there must be independence in the choice about levels and models of security and authenticity required. This choice may be made by the owner of a naming subspace, in controlling who can modify hints in that subspace. A naming authority may delegate this choice to the owners of the resources named by the names it has assigned. There may be limitations on this freedom of choice in order to allow other participants to have the level of security and authenticity they require, for example, in order to maintain the integrity of the UDS infrastructure as a whole. Fourth, there is an assumption of independence of choice of the rule of canonicalization of URNs within a namespace, limited by any restrictions or constraints that may have been set by its parent namespace. This is a choice held by naming authorities over their own subnamespaces. Rules for canonicalization will be discussed further in the framework section below. Thus, there are assumptions of independence and isolation to allow for delegated, independent authority in a variety of domains. URN Resolution Requirements Page 4 The modularity assumptions of delegation and isolation imply independence of decision and implementation, leading to a decentralization that provides a certain degree of safety from denial of service. Based on these these assumptions in conjunction with that of longevity and those for URLs and URNs as detailed in RFCs 1736 and 1737, we can now turn to the requirements for a URN services delegation service. 3. Requirements The requirements applying to a URN-resolution-service discovery service or UDS center around three important design goals: evolvability, usability, and security and privacy. At its core the function of a UDS is to provide hints for accessing a resource given a URN for it. These hints may range in applicability from local to global, and from short-lived to long-lived. They also may vary in their degree of verifiable authenticity. While it may be neither feasible nor necessary that initial implementations support every requirement, every implementation must support evolution to systems that do support every requirement. It is also important to note that there are other requirements, not applicable specifically to a UDS that must also be met. A whole URN system will consist of namespaces, the resolution information for them, and the mapping from names in the namespaces to resolution information (or hints). URN schemes must meet the requirements of RFC 1737. Resolution information, to the extent it is expressed as URLs must meet the requirements of RFC 1736. But this does not tell the whole story. Although the URN working group will identify several acceptable namespaces and the rules binding them, such as how delegation occurs, how it is expressed in the names, how and to what extent binding to hint information will be constrained by the namespace, in the long run a document will be needed to guide the evaluation criteria for acceptance of new namespaces. These are not included in the list of requirements below because they are not requirements for a UDS, but rather for naming schemes themselves. 3.1 Evolution One of the lessons of the Internet that we must incorporate into the development of mechanisms for resolving URNs is that we must be prepared for change. Such changes may happen slowly enough to be considered evolutionary modifications of existing services or dramatically enough to be considered revolutionary. They may permeate the Internet universe bit by bit, living side by side with earlier services or they may take the Internet by storm, causing an apparent complete transformation over a short period of time. There are several directions in which we can predict the need for evolution, even at this time, prior to the deployment of any such service. At the very least, the community and the mechanisms proposed should be prepared for these. First, we expect there to be additions and changes to the mechanisms. The community already understands that there must be a capacity for new URN schemes. A URN scheme will define a set of URNs that meet the URN requirements[RFC1737], but may have further constraints on the internal URN Resolution Requirements Page 5 structure of the URN. The requirements document would allow for an overall plan in which URN schemes are free to specify parts of the URN that are left opaque in the larger picture. In fact, a URN scheme may choose to make public the algorithms for any such "opaque" part of the URN. For example, although it may be unnecessary to know the structure of an ISBN, the algorithm for understanding the structure of an ISBN has been made public. Other schemes may either choose not to make their algorithms public, or choose a scheme in which knowledge of the scheme does not provide any significant semantics to the user. In any case, we must be prepared for a growing number of URN schemes. Often in conjunction with a new URN scheme, but possibly independently of any particular URN scheme, new resolution services may evolve. For example, one can imagine a specialized resolution service based on the particular structure of ISBNs that improves the efficiency of finding documents given their ISBNs. Alternatively, one can also imagine a general purpose resolution service that trades performance for generality; although it exhibits only average performance resolving ISBNs, it makes up for this weakness by understanding all existing URN schemes, so that its clients can use the same service to resolve URNs regardless of naming scheme. In this context, there will always be room for improvement of services, through improved performance, better adaptability to new URN schemes, or lower cost. In any case, new models for URN resolution will evolve and we must be prepared to allow for their participation in the overall resolution of URNs. If we begin with one overall plan for URN resolution, into which the enhancements described above may fit, we must also be prepared for an evolution in the authentication schemes that will be considered either useful or necessary in the future. There is no single globally accepted authentication scheme, and there may never be one. Even if one does exist at some point in time, there will always be threats to it, and so we must always be prepared to move on to newer and better schemes, as the old ones become too easily spoofed or guessed. Lastly, in terms of mechanism, although we may develop and deploy a single UDS scheme initially, we must be prepared for that top level model to evolve. Thus, if the UDS model supports an apparently centralized (from a policy standpoint) scheme for inserting and modifying authoritative information, over time we must be prepared to evolve to a different model, perhaps one that has a more distributed model of authority and authenticity. If the model has no core but rather a cascaded partial discovery of information, we may find that this becomes unmanageable with an increase in scaling. Whatever the core of the model, we must be prepared for it to evolve with changes in scaling, performance, and policy constraints such as security and cost. Second, in addition to the evolution of resolution mechanisms, we expect that the community will follow an evolutionary path towards the separation of semantics from identification. The URN requirements document suggested this path as well, and there has been general agreement in much of the community that such a separation is desirable. This is a problem that the public at large has generally not understood. Today we see the problem most clearly with the use of URLs for identification. When a web page moves, its URL becomes invalid. URN Resolution Requirements Page 6 Suppose such a URL is embedded in some page, stored in long term storage. There are three possible outcomes to this scenario. One possibility is that the client is left high and dry with some message saying that the page cannot be found. Alternatively, a "forwarding pointer" may be left behind, in the form of an explicit page requesting the client to click on a new URL. Although this will allow the client to find the intended page, the broken link cannot be fixed because the URL is embedded in a file outside of the client's control. A third alternative is that the target server supplies an HTTP redirect so that the new page is provided for the client automatically. In this case, the client may not even realize that the URL is no longer correct. The real problem with both of these latter two situations is that they only work as long as the forwarding pointer can be found at the old URL. Semantics, in this case location information, was embedded in the identifier, and the resolution system was designed to depend on the semantics being correct. There are few cases in which we can expect semantics of any sort to remain valid for a long time, but in many cases references need to have long lifespans. Most documents are only useful while their references still function. We expect the evolution to separation of semantics from identification to move along at least three paths. The first will be to develop temporary aliases to capture the semantics currently embedded in identifiers. This will require additional translation, but it will allow for the development of semantics-free URNs. Second, we expect locally shared or private aliases to arise, again supported by a translation mechanism and allowing for the long-term storage of global, semantics-free URNs. Such an aliasing scheme may be used to permit local aliases for named resources as well as to present these aliases to users in lieu of the URNs themselves. Lastly, we expect there may be a development of global aliases. These will be more user friendly "names" that would be shared on a much larger scale, and might be defined in some global registry. This may include trademarked names as well as names in extremely common use. As with the other alias systems, a facility for translation is needed. However, in this case, since the system of aliases is of global scope, the translation facility will be very slow if each time an alias is translated it needs to query a centralized or even reasonably distributed global registry. In order to achieve acceptable speeds, the translation facility w Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA27284 for urn-ietf-out; Fri, 22 Nov 1996 17:35:04 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA27273 for ; Fri, 22 Nov 1996 17:34:54 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26813 (mail destined for urn-ietf@services.bunyip.com); Fri, 22 Nov 96 17:34:48 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id OAA19698; Fri, 22 Nov 1996 14:33:14 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id OAA23886; Fri, 22 Nov 1996 14:33:35 -0800 (PST) Date: Fri, 22 Nov 1996 14:33:35 -0800 (PST) From: Terry Allen Message-Id: <199611222233.OAA23886@ishtar.fsc.fujitsu.com> To: jayhawk@ds.internic.net, leslie@bunyip.com, urn-ietf@bunyip.com Subject: Re: [URN] Collecting open issue information on the syntax draft... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com (Apologies for being out of touch recently while at SGML 96.) > Any namespace (existing or newly-devised) that is proposed as a URN-namespace and fulfills the criteria of URN-namespaces must be expressed in this syntax. If names in these spaces contain characters other than those defined for the URN character set, they must be translated into canonical format as discussed in section 2.2. I agree with Leslie's proposed emendation and the reasons she expressed for it. EXCEPT, that the name space itself need not be expressed in this syntax, only the URN represntation of that name space. So perhaps "must be expressed" should be "must have rules for expressing its names". Regards, Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA25105 for urn-ietf-out; Fri, 22 Nov 1996 15:27:43 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA25100 for ; Fri, 22 Nov 1996 15:27:40 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25951 (mail destined for urn-ietf@services.bunyip.com); Fri, 22 Nov 96 15:27:33 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id NAA15209; Fri, 22 Nov 1996 13:27:30 -0700 (MST) Message-Id: <2.2.32.19961122203559.0073a20c@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 22 Nov 1996 13:35:59 -0700 To: leslie@bunyip.com (Leslie Daigle), "URN mailing list" From: Ron Daniel Subject: Re: [URN] Collecting open issue information on the syntax draft... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Leslie Daigle (at least at 02:42 PM 11/22/96 -0500) >Once we've settled on a syntax and handling mechanisms, we have nothing >further to say about what people do within those constraints. Hear! Hear! I recommend that, for some time, new namespaces receieve standards-track review, rather like new URL schemes currently do. That review process is the place where we can address concerns such as limited longevity or legal liability due to the inclusion of particular attempts at "friendliness". The syntax draft does not have to address that issue one way or the other. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA24537 for urn-ietf-out; Fri, 22 Nov 1996 14:42:06 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA24532 for ; Fri, 22 Nov 1996 14:42:03 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25620 (mail destined for urn-ietf@services.bunyip.com); Fri, 22 Nov 96 14:42:02 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id OAA21503; Fri, 22 Nov 1996 14:42:01 -0500 Message-Id: <199611221942.OAA21503@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Fri, 22 Nov 1996 14:42:00 -0500 In-Reply-To: "Ryan Moats"'s message as of Nov 22, 10:41 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "Ryan Moats" , "URN mailing list" Subject: Re: [URN] Collecting open issue information on the syntax draft... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com This touches on something I asked Ryan about in the draft, and wanted to bring up here. In reading through the recent thread on character sets and URNs (admittedly, slightly out of step with real-time), it seemed to come to a reasoned and reasonable conclusion about handling character sets other than US-ASCII in URNs. I didn't feel that this was completely represented in the syntax draft, although I'm not sure whether it was because my reading of the thread was at fault. [Ryan brought up:] > 4. human readability for new namespaces: MUST/SHOULD? This is in reference to the paragraph, in the syntax draft: Some existing name spaces that have the properties of the URN-space contain some human-significant components, and these exist in a wide variety of languages. However, URNs are NOT intended to convey information that is significant to humans. While the translation rule in section 2.2 is provided for existing namespaces, new namespaces, as part of their registration documentation, MUST define a discipline for assigning new URNs that does not simplify the generation of human-significant names. The way I read this, the only thing the syntax draft is recognizing is that there may be existing namespaces that have things that happen to be human-readable, and these may be in character sets other than US-ASCII, so UTF-8 is proposed as a mechanism of handling these anomalies -- but that these namespaces should ensure that future names assigned should not suffer from human-readability. (Admittedly, a "strong" reading of the statement, but I'm trying to illustrate the point). I just don't see the point of such a statement. The syntax draft defines how to formally express a URN -- in US-ASCII or UTF-8. Period. What things a namespace-proposer chooses to use in their namespace is not relevant, as long as they can be carried in this syntax, and otherwise meet the requirements of namespaces (uniqueness of names, etc). So, if someone proposes a namespace that happens to be human-friendly (_whatever_ that means!) in spite of meeting all these requirements, cool! What was intended in the charter was to avoid having the syntax and handling mechanisms' design _driven_ by a need to keep things "human-friendly" (e.g., shorter than URLs, no funny punctuation, whatever). Once we've settled on a syntax and handling mechanisms, we have nothing further to say about what people do within those constraints. I bring all of this up because it is not clear to me that particular paragraph adequately represented what _seemed_ to be consensus on the matter on the list. If that is the case, I would propose the following change to the syntax draft: > 3. Support of existing legacy naming systems and new naming systems > URN-aware applications MAY accept as input other resource identifiers > from existing legacy namespaces. If such identifiers contain > characters that are not members of the URN character set specified in > section 2.2, the identifier MUST be translated to canonical format as > discussed in section 2.2. > > Some existing name spaces that have the properties of the URN-space > contain some human-significant components, and these exist in a wide > variety of languages. However, URNs are NOT intended to convey > information that is significant to humans. While the translation > rule in section 2.2 is provided for existing namespaces, new > namespaces, as part of their registration documentation, MUST define > a discipline for assigning new URNs that does not simplify the > generation of human-significant names. would become: 3. Support of existing legacy naming systems and new naming systems Any namespace (existing or newly-devised) that is proposed as a URN-namespace and fulfills the criteria of URN-namespaces must be expressed in this syntax. If names in these spaces contain characters other than those defined for the URN character set, they must be translated into canonical format as discussed in section 2.2. Well, it's not the most inspired wording, but can people live with this? Leslie. -- ---------------------------------------------------------------------------- "The light at the end of the tunnel Leslie Daigle is often the blindingly obvious..." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA18932 for urn-ietf-out; Fri, 22 Nov 1996 11:40:13 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA18927 for ; Fri, 22 Nov 1996 11:40:11 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24257 (mail destined for urn-ietf@services.bunyip.com); Fri, 22 Nov 96 11:40:08 -0500 Message-Id: <9611221640.AA24257@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Fri Nov 22 10:39 CST 1996 From: "Ryan Moats" To: "URN mailing list" Date: Fri, 22 Nov 96 10:41:13 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] Collecting open issue information on the syntax draft... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com Folks- I've been going back over the open issues with the syntax draft and trying to ensure that I have all of them before I start thinking about slides for San Jose. The open issues as I see them with this document at this moment in time are: 1. "urn:" tag: YES/NO? 2. URN char set: additions/deletions? 3. %escaping: just octets outside char set or reserve/literal chars as well? 4. human readability for new namespaces: MUST/SHOULD? 5. equivalency: needs some more work (as you pointed out above) 6. How do we know when a URN ends? I don't want to necessarily discuss them now, but want to be sure that I haven't missed anything before San Jose. Ryan P.S. I'm providing a short synopsis of the issue for those that aren't straightforward: %escaping ---------------- The issue here (as I see it) is that the current rules for URN syntax reserve % for escaping characters outside the URN char set. A namespace identifier that use % to escape the literal use of a character that also has a special meaning for that namespace can not be made into a valid URN. I happen to think this requires fixing, or at least more thought. equivalency ------------------ It has been pointed out to me that saying "two URNs are equivalent if they return the same resource" is not quite an accurate statement. This statement requires some improvement, and such will be discussed. When does a URN end? --------------------------------------- It has also been pointed out to me that the syntax draft does not indicate when a URN ends. Some statement should be added to indicate this situation. My current preference is to state that a "On the line, the URN ends with an octet that is not a member of the URN charset", or something like that, but what about other formats? Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA18679 for urn-ietf-out; Fri, 22 Nov 1996 11:07:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA18674 for ; Fri, 22 Nov 1996 11:07:35 -0500 Received: from ietf.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23928 (mail destined for urn-ietf@services.bunyip.com); Fri, 22 Nov 96 11:07:33 -0500 Received: from ietf.org by ietf.org id aa27563; 22 Nov 96 9:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: urn-ietf@bunyip.com From: Internet-Drafts@ietf.org Subject: [URN] I-D ACTION:draft-ietf-urn-http-conv-00.txt Date: Fri, 22 Nov 1996 09:41:23 -0500 Message-Id: <9611220941.aa27563@ietf.org> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org Errors-To: owner-urn-ietf@bunyip.com --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Conventions for the Use of HTTP for URN Resolution Author(s) : R. Daniel Filename : draft-ietf-urn-http-conv-00.txt Pages : 6 Date : 11/21/1996 The URN-WG was formed to specify persistent, location-independent names for network accessible resources, and resolution mechanisms to retrive the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal [1]. That proposal does not get the client software all the way from the URN to the resource. Instead, it gets the client from a URN to a "resolver", which is a system that can then tell the client where the resource is. The NAPTR draft defines a "resolution protocol" to be the protocol used to speak to a resolver in order to obtain the resource, its location(s), or other information about the resource. The NAPTR proposal allows different resolution protocols to be used for commuicating with resolvers. This draft establishes conventions for encoding URN resolution requests and responses in HTTP 1.0 (and 1.1) requests and responses. The primary goal of this draft is to define a convention that is simple to implement and will allow existing HTTP servers to easily add support for URNresolution. We expect that the resolution databases that arise will be useful when more sophisticated resolution protocols are developed later. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-http-conv-00.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-http-conv-00.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-http-conv-00.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121163444.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-http-conv-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-http-conv-00.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121163444.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA18627 for urn-ietf-out; Fri, 22 Nov 1996 11:05:28 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA18622 for ; Fri, 22 Nov 1996 11:05:25 -0500 Received: from ietf.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23894 (mail destined for urn-ietf@services.bunyip.com); Fri, 22 Nov 96 11:05:17 -0500 Received: from ietf.org by ietf.org id aa27580; 22 Nov 96 9:41 EST Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:; Cc: urn-ietf@bunyip.com From: Internet-Drafts@ietf.org Subject: [URN] I-D ACTION:draft-ietf-urn-naptr-01.txt Date: Fri, 22 Nov 1996 09:41:32 -0500 Message-Id: <9611220941.aa27580@ietf.org> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Internet-Drafts@ietf.org Errors-To: owner-urn-ietf@bunyip.com --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Resolution of Uniform Resource Identifiers using the Domain Name System Author(s) : R. Daniel, M. Mealling Filename : draft-ietf-urn-naptr-01.txt Pages : 13 Date : 11/21/1996 Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. In addition to locating resolvers, the NAPTR provides for other naming systems to be grandfathered into the URN world, provides independence between the name assignment system and the resolution protocol system, and allows multiple services (Name to Location, Name to Description, Name to Resource, ...) to be offered. In conjunction with the SRV RR proposal [3], the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-naptr-01.txt". A URL for the Internet-Draft is: ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-01.txt Internet-Drafts directories are located at: o Africa: ftp.is.co.za o Europe: nic.nordu.net ftp.nis.garr.it o Pacific Rim: munnari.oz.au o US East Coast: ds.internic.net o US West Coast: ftp.isi.edu Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-ietf-urn-naptr-01.txt". NOTE: The mail server at ds.internic.net can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e., documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19961121163946.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-naptr-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-naptr-01.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19961121163946.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA09656 for urn-ietf-out; Thu, 21 Nov 1996 21:17:32 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA09651 for ; Thu, 21 Nov 1996 21:17:30 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20265 (mail destined for urn-ietf@services.bunyip.com); Thu, 21 Nov 96 21:17:29 -0500 From: Leslie Daigle Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id VAA20575 for urn-ietf@bunyip.com; Thu, 21 Nov 1996 21:17:29 -0500 Date: Thu, 21 Nov 1996 21:17:29 -0500 Message-Id: <199611220217.VAA20575@beethoven.bunyip.com> To: urn-ietf@bunyip.com Subject: [URN] Status Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Leslie Daigle Errors-To: owner-urn-ietf@bunyip.com Okay, on the brink of the SJ IETF meeting, it seems a good time to review the progress of this Fall, particularly with respect to our charter. So, first of all, congratulations to everybody for a very productive Fall; the document editors have been working _very_ hard, and people have been unstinting in their generous, and constructive, commentary. We now have drafts of: . URN Framework and Requirements (soon to be published) . URN Syntax . NAPTR proposed implementation . HTTP resolution conventions we are _that_ close to having something that can actually be deployed in a test-fashion. Ah, yes, there is one thing missing: a namespace. On previous occasions, one or more people have suggested that they would be willing to work on the definition of a new namespace, or on the use of an existing namespace in the URN context ("grandfathering"). Now that the syntax is settling down, I would appreciate volunteers and proposals for namespaces -- please send mail to me, and I will summarize to the list. The agenda for the San Jose meeting is pretty straightforward -- there will be time to talk about specific issues with individual drafts, assessing where we are, and determining how to tackle the remaining required drafts (read: flushing out volunteers, if none are evident before then :-) Thanks! Leslie. P.S.: By the way -- it has been pointed out to me that the URL I circulated a couple of weeks ago was wrong (although our kindly web-maintainers have aliased around my gaffe). The proper URL is: http://www.bunyip.com/research/ietf/urn-ietf/ I have updated the page to include our charter and the pointers to other work that people proposed. I will include pointers to the new crop of I-D's, as soon as things settle down (i.e.: after Tuesday, 5pm!). ---------------------------------------- IETF URN Working Group ---------------------------------------- Agenda for Thursday, December 12, 1996, San Jose, California. Status review: . Status of documents . Progress on WG milestones Discussion of document-specific issues: . URN Framework and Requirements . URN Syntax . NAPTR proposal . HTTP conventions Where to go from here: . addressing remaining documents ---------------------------------------------------------------------------- "The light at the end of the tunnel Leslie Daigle is often the blindingly obvious..." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA08349 for urn-ietf-out; Wed, 20 Nov 1996 15:34:32 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA08342 for ; Wed, 20 Nov 1996 15:34:18 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08321 (mail destined for urn-ietf@services.bunyip.com); Wed, 20 Nov 96 15:34:00 -0500 Received: from magenta.acl.lanl.gov (rdaniel@magenta.acl.lanl.gov [128.165.147.153]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id NAA29873 for ; Wed, 20 Nov 1996 13:33:58 -0700 (MST) From: "Ronald E. Daniel" Received: (rdaniel@localhost) by magenta.acl.lanl.gov (8.7.5/8.6.4) id NAA29364 for urn-ietf@bunyip.com; Wed, 20 Nov 1996 13:33:58 -0700 (MST) Date: Wed, 20 Nov 1996 13:33:58 -0700 (MST) Message-Id: <199611202033.NAA29364@magenta.acl.lanl.gov> To: urn-ietf@bunyip.com Subject: [URN] NAPTR revision Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ronald E. Daniel" Errors-To: owner-urn-ietf@bunyip.com Hi, I've revised the NAPTR draft to allow characters other than '/' to be used as the delimiters in the regexp field. I will send this in to the ID editor later today. The new version is appended. Regards, Ron === INTERNET DRAFT Ron Daniel draft-ietf-urn-naptr-01.txt Los Alamos National Laboratory Michael Mealling Network Solutions, Inc. 19 Nov., 1996 Resolution of Uniform Resource Identifiers using the Domain Name System [Edits since -00: 1) Changed SRV citation to RFC from ID 2) Pulled underscores from SRV names. 3) Changed syntax of substitution expression to allow delimiter characters other than '/'. ] Status of this Memo =================== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft expires 19 May, 1997. Abstract: ========= Uniform Resource Locators (URLs) are the foundation of the World Wide Web, and are a vital Internet technology. However, they have proven to be brittle in practice. The basic problem is that URLs typically identify a particular path to a file on a particular host. There is no graceful way of changing the path or host once the URL has been assigned. Neither is there a graceful way of replicating the resource located by the URL to achieve better network utilization and/or fault tolerance. Uniform Resource Names (URNs) have been hypothesized as a adjunct to URLs that would overcome such problems. URNs and URLs are both instances of a broader class of identifiers known as Uniform Resource Identifiers (URIs). This document describes a new DNS Resource Record, NAPTR (Naming Authority PoinTeR), that provides rules for mapping parts of URIs to domain names. By changing the mapping rules, we can change the host that is contacted to resolve a URI. This will allow a more graceful handling of URLs over long time periods, and forms the foundation for a new proposal for Uniform Resource Names. In addition to locating resolvers, the NAPTR provides for other naming systems to be grandfathered into the URN world, provides independence between the name assignment system and the resolution protocol system, and allows multiple services (Name to Location, Name to Description, Name to Resource, ...) to be offered. In conjunction with the SRV RR proposal [3], the NAPTR record allows those services to be replicated for the purposes of fault tolerance and load balancing. Introduction: ============= Uniform Resource Locators have been a significant advance in locating resources on the Internet. However, their brittle nature over time has been recognized for several years. The Uniform Resource Identifier working group proposed the development of Uniform Resource Names to serve as persistent, location-independent identifiers for Internet resources in order to overcome most of the problems with URLs. RFC-1737 [1] sets forth requirements on URNs. During the lifetime of the URI-WG, a number of URN proposals were generated. The developers of several of those proposals met in a series of meetings, resulting in a compromise known as the Knoxville framework. The major principle behind the Knoxville framework is that the resolution system must be seperate from the way names are assigned. This is in marked contrast to most URLs, which identify the host to contact and the protocol to use. Readers are referred to [2] for background on the Knoxville framework and for additional information on the context and purpose of this proposal. Seperating the way names are resolved from the way they are constructed provides several benefits. It allows multiple naming approaches and resolution approaches to compete, as it allows different protocols and resolvers to be used. There is just one problem with such a separation - how do we resolve a name when it can't give us directions to its resolver? For the short term, DNS is the obvious candidate for the resolution framework, since it is widely deployed and understood. However, it is not appropriate to use DNS to maintain information on a per-resource basis. First of all, DNS was never intended to handle that many records. Second, the limited record size is inappropriate for catalog information. Third, domain names are not appropriate as URNs. Therefore our approach is to use DNS to locate "resolvers" that can provide information on individual resources, potentially including the resource itself. To accomplish this, we "rewrite" the URI into a domain name following the rules provided in NAPTR records. Rewrite rules provide considerable power, which is important when trying to meet the goals listed above. However, collections of rules can become difficult to understand. To lessen this problem, the NAPTR rules are *always* applied to the original URI, *never* to the output of previous rules. Locating a resolver through the rewrite procedure may take multiple steps, but the beginning is always the same. Every URI has a colon-delimited prefix. NAPTR resolution begins by taking this prefix, appending the well-known suffix ".urn.net", and querying the DNS for NAPTR records at that domain name. Based on the results of this query, zero or more additional DNS queries may be needed to locate resolvers for the URI. The details of the conversation between the client and the resolver thus located are outside the bounds of this draft. Three brief examples of this procedure are given in the next section. The NAPTR RR provides the level of indirection needed to keep the naming system independent of the resolution system, its protocols, and services. Coupled with the new SRV resource record proposal[3] there is also the potential for replicating the resolver on multiple hosts, overcoming some of the most significant problems of URLs. This is an important and subtle point. Not only do the NAPTR and SRV records allow us to replicate the resource, we can replicate the resolvers that know about the replicated resource. Preventing a single point of failure at the resolver level is a significant benefit. Seperating the resolution procedure from the way names are constructed has additional benefits. Different resolution procedures can be used over time, and resolution procedures that are determined to be useful can be extended to deal with additional namespaces. Terminology =========== "Must" or "Shall" - Software that does not behave in the manner that this document says it must is not conformant to this document. "Should" - Software that does not follow the behavior that this document says it should may still be conformant, but is probably broken in some fundamental way. "May" - Implementations may or may not provide the described behavior, while still remaining conformant to this document. Brief overview and examples of the NAPTR RR: ============================================ A detailed description of the NAPTR RR will be given later, but to give a flavor for the proposal we first give a simple description of the record and three examples of its use. The key fields in the NAPTR RR are order, preference, service, flags, regexp, and replacement: * The order field specifies the order in which records MUST be processed when multiple NAPTR records are returned in response to a single query. A naming authority may have delegated a portion of its namespace to another agency. Evaluating the NAPTR records in the correct order is necessary for delegation to work properly. * The preference field specifies the order in which records SHOULD be processed when multiple NAPTR records have the same value of "order". This field lets a service provider specify the order in which resolvers are contacted, so that more capable machines are contacted in preference to less capable ones. * The service field specifies the resolution protocol and resolution service(s) that will be available if the rewrite specified by the regexp or replacement fields is applied. Resolution protocols are the protocols used to talk with a resolver. They will be specified in other documents. Resolution services are operations such as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC), etc. These are discussed in the URN Framework document[2], and their behavior in a particular resolution protocol will be given in the specification for that protocol. * The flags field contains modifiers that affect what happens in the next DNS lookup, typically for optimizing the process. * The regexp field is one of two fields used for the rewrite rules, and is the core concept of the NAPTR record. The regexp field is a String containing a sed-like substitution expression. (The actual grammar for the substitution expressions is given later in this draft). The substitution expression is applied to the original URN to determine the next domain name to be queried. The regexp field should be used when the domain name to be generated is conditional on information in the URI. If the next domain name is always known, which is anticipated to be a common occurrence, the replacement field should be used instead. * The replacement field is the other field that may be used for the rewrite rule. It is an optimization of the rewrite process for the case where the next domain name is fixed instead of being conditional on the content of the URI. The replacement field is a domain name (subject to compression if a DNS sender knows that a given recipient is able to decompress names in this RR type's RDATA field). If the rewrite is more complex than a simple substitution of a domain name, the replacement field should be set to . and the regexp field used. Note that the client applies all the substitutions and performs all lookups - this is not handled in DNS servers. Note also that there is no reason to provide values in both the replacement and regexp field. Only one should be specified. If a value is specified in both, the replacement name MUST be used and the regexp string MUST be ignored. It is the belief of the developers of this document that regexps should rarely be used. The replacement field seems adequate for the vast majority of situations. Regexps are only necessary when portions of a namespace are to be delegated to different resolvers. Example 1 --------- Consider a URN that uses the hypothetical DUNS namespace. DUNS numbers are identifiers for approximately 30 million registered businesses around the world, assigned and maintained by Dunn and Bradstreet. The URN might look like: urn:duns:002372413:annual-report-1997 The first step in the resolution process is to find out about the DUNS namespace. The namespace identifier, duns, is extracted from the URN, prepended to urn.net, and the NAPTRs for duns.urn.net looked up. It might return records of the form: duns.urn.net ;; order pref flags service regexp replacement IN NAPTR 100 10 "s" "dunslink+N2L+N2C" "" dunslink.udp.isi.dandb.com IN NAPTR 100 20 "s" "rcds+N2C" "" rcds.udp.isi.dandb.com IN NAPTR 100 30 "s" "http+N2L+N2C+N2R" "" http.tcp.isi.dandb.com The order field contains equal values, indicating that no name delegation order has to be followed. The preference field indicates that the provider would like clients to use the special dunslink protocol, followed by the RCDS protocol, and that HTTP is offered as a last resort. All the records specify the "s" flag, which will be explained momentarily. The service fields say that if we speak dunslink, we will be able to issue either the N2L or N2C requests to obtain a URL or a URC (description) of the resource. The Resource Cataloging and Distribution Service (RCDS)[7] could be used to get a URC for the resource, while HTTP could be used to get a URL, URC, or the resource itself. All the records supply the next domain name to query, none of them need to be rewritten with the aid of regular expressions. The general case might require multiple NAPTR rewrites to locate a resolver, but eventually we will come to the "terminal NAPTR". Once we have the terminal NAPTR, our next probe into the DNS will be for a SRV or A record instead of another NAPTR. Rather than probing for a non-existent NAPTR record to terminate the loop, the flags field is used to indicate a terminal lookup. If it has a value of "s", the next lookup should be for SRV RRs, "a" denotes that A records should sought. A "p" flag is also provided to indicate that the next action is Protocol-specific, but that looking up another NAPTR will not be part of it. Since our example RR specified the "s" flag, it was terminal. Our next action is to lookup SRV RRs for rcds.udp.isi.dandb.com, which will tell us hosts that can provide the necessary resolution service. That lookup might return: ;; Pref Weight Port Target rcds.udp.isi.dandb.com IN SRV 0 0 1000 defduns.isi.dandb.com IN SRV 0 0 1000 dbmirror.com.au IN SRV 0 0 1000 ukmirror.com.uk telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their RCDS server. (The reader is referred to the SRV proposal [3] for the interpretation of the fields above). There is opportunity for significant optimization here. We can return the SRV records as additional information for terminal NAPTRs (and the A records as additional information for those SRVs). While this recursive provision of additional information is not explicitly blessed in the DNS specifications, it is not forbidden, and BIND does take advantage of it [4]. This is a significant optimization. In conjunction with a long TTL for *.urn.net records, the average number of probes to DNS for resolving DUNS URNs would approach one. Therefore, DNS server implementors SHOULD provide additional information with NAPTR responses. The additional information will be either SRV or A records. If SRV records are available, their A records may be provided as recursive additional information. Note that the example NAPTR records above are intended to represent the reply the client will see. They are not quite identical to what the domain administrator would put into the zone files. For one thing, the administrator should supply the trailing '.' character on replacement domain names. An additional difference will be illustrated later. Example 2 --------- Consider a URI namespace based on MIME Content-Ids. The URN might look like this: urn:cid:199606121851.1@mordred.gatech.edu The first step in the resolution process is to find out about the CID namespace. The namespace identifier, cid, is extracted from the URN, prepended to urn.net, and the NAPTR for cid.urn.net looked up. It might return records of the form: cid.urn.net ;; order pref flags service regexp replacement IN NAPTR 100 10 "" "" "/.+@([^@]+)/\1/i" . We have only one NAPTR response, so ordering the responses is not a problem. The replacement field is empty, so we check the regexp field and use the pattern provided there. We apply that regexp to the entire URN to see if it matches, which it does. The \1 part of the substitution expression returns the string "mordred.gatech.edu". Since the flags field does not contain "s" or "a", the lookup is not terminal and our next probe to DNS is for more NAPTR records: lookup(query=NAPTR, "mordred.gatech.edu"). While mordred could have its very own NAPTR, maintaining those records on all the machines at a site as large as Georgia Tech would be an intolerable burden. Instead, a wildcard may be used so that the domain administrator at Georgia Tech has only a single NAPTR record to maintain. That record might look like: *.gatech.edu IN NAPTR ;; order pref flags service regexp replacement IN NAPTR 100 50 "s" "z3950+N2L+N2C" "" z3950.tcp.gatech.edu. IN NAPTR 100 50 "s" "rcds+N2C" "" rcds.udp.gatech.edu. IN NAPTR 100 50 "s" "http+N2L+N2C+N2R" "" http.tcp.gatech.edu. (Unlike all the other example records in this draft, the one above is the contents of a zone file, not the response received by the client. That is so that the wildcard can be seen.) Continuing with our example, we note that the values of the order and preference fields are equal in all records, so the client is free to pick any record. The flags field tells us that these are the last NAPTR patterns we should see, and after the rewrite (a simple replacement in this case) we should look up SRV records to get information on the hosts that can provide the necessary service. Assuming we prefer the Z39.50 protocol, our lookup might return: ;; Pref Weight Port Target z3950.tcp.gatech.edu IN SRV 0 0 1000 z3950.gatech.edu IN SRV 0 0 1000 z3950.cc.gatech.edu IN SRV 0 0 1000 z3950.uga.edu telling us three hosts that could actually do the resolution, and giving us the port we should use to talk to their Z39.50 server. Recall that the regular expression used \1 to extract a domain name from the CID. There is a significant caveat about the use of backslashes in DNS zone files. DNS treats backslashes as the escape character so that '.' can be escaped when necessary. This means that when a regular expression is entered into the zone file, the backslashes must be escaped by another backslash. For the case of the cid.urn.net record above, the regular expression entered into the zone file should be "/.+@([^@]+)/\\1/i". When the client code actually receives the record, the pattern will have been converted to "/.+@([^@]+)/\1/i". Example 3 --------- Even if URN systems were in place now, there would still be a tremendous number of URLs. It should be possible to develop a URN resolution system that can also provide location independence for those URLs. This is related to the requirement in [1] to be able to grandfather in names from other naming systems, such as ISO Formal Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs, etc. The NAPTR RR could also be used for URLs that have already been assigned. Assume we have the URL for a very popular piece of software that the publisher wishes to mirror at multiple sites around the world: http://www.foo.com/software/latest-beta.exe We extract the prefix, "http", and lookup NAPTR records for http.urn.net. This might return a record of the form http.urn.net IN NAPTR ;; order pref flags service regexp replacement 100 90 "" "" "/.*\/\/([^\/:]+)/\1/i" . This expression returns everything after the first double slash and before the next slash or colon. Backslashes are needed to escape the forward slash since the forward slash character is what separates the components of the substitution expression. (Recall from the previous example that in the zone file, this pattern actually needs to be entered as "/.*\\/\\/([^\\/:]+)/\\1/i"). Applying this pattern to the URL extracts "www.foo.com". Looking up NAPTR records for that might return: www.foo.com ;; order pref flags service regexp replacement IN NAPTR 100 100 "s" "http+L2R" "" http.tcp.foo.com IN NAPTR 100 100 "s" "ftp+L2R" "" ftp.tcp.foo.com Looking up SRV records for http.tcp.foo.com would return information on the hosts that foo.com has designated to be its mirror sites. The client can then pick one for the user. NAPTR RR Format =============== The format of the NAPTR RR is given below. The DNS type code for NAPTR is 104 [this is being changed, we believe it will be assigned 35]. Domain TTL Class Order Preference Flags Service Regexp Replacement where: Domain The domain name this resource record refers to. TTL Standard DNS Time To Live field Class Standard DNS meaning Order A 16-bit integer specifying the order in which the NAPTR records MUST be processed to ensure correct delegation of portions of the namespace over time. Low numbers are processed before high numbers, and once a NAPTR is found that "matches" a URN, the client MUST NOT consider any NAPTRs with a higher value for order. Preference A 16-bit integer which specifies the order in which NAPTR records with equal "order" values SHOULD be processed, low numbers being processed before high numbers. This is similar to the preference field in an MX record, and is used so domain administrators can direct clients towards more capable hosts or lighter weight protocols. Flags A String giving flags to control aspects of the rewriting. Flags are single characters from the set [A-Z0-9]. The case of the alphabetic characters is not significant. At this time only three flags, "S", "A", and "P", are defined. "S" means that the next lookup should be for SRV records instead of NAPTR records. "A" means that the next lookup should be for A records. The "P" flag says that the remainder of the resolution shall be carried out in a Protocol-specific fashion, and we should not do any more DNS queries. The remaining alphabetic flags are reserved. The numeric flags may be used for local experimentation. The S, A, and P flags are all mutually exclusive, and resolution libraries MAY signal an error if more than one is given. (Experimental code and code for assiting in the creation of NAPTRs would be more likely to signal such an error than a client such as a browser). We anticipate that multiple flags will be allowed in the future, so implementors MUST NOT assume that the flags field can only contain 0 or 1 characters. Service Specifies the resolution service(s) available down this rewrite path. It may also specify the particular protocol that is used to talk with a resolver. A protocol MUST be specified if the flags field states that the NAPTR is terminal. If a protocol is specified, but the flags field does not state that the NAPTR is terminal, the next lookup MUST be for a NAPTR. The client MAY choose not to perform the next lookup if the protocol is unknown, but that behavior MUST NOT be relied upon. The service field may take any of the values below (using the Augmented BNF of RFC 822[5]): service_field = [ [protocol] *("+" rs)] protocol = "rcds" / "http" / "hdl" / "rwhois" rs = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C" / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C" i.e. an optional protocol specification followed by 0 or more resolution services. Each resolution service is indicated by an initial '+' character. Note that the empty string is also a valid service field. This will typically be seen at the top levels of a namespace, when it is impossible to know what services and protocols will be offered by a particular publisher within that name space. At this time the known protocols are rcds[7], hdl[8] (binary, UDP-based protocols), http[11] (a textual, TCP-based protocol), and rwhois[10] (textual, UDP or TCP based). More will be allowed later. The names of the protocols must be formed from the characters [a-Z0-9]. Case of the characters is not significant. The service requests currently allowed are: N2L - Given a URN, return a URL N2Ls - Given a URN, return a set of URLs N2R - Given a URN, return an instance of the resource. N2Rs - Given a URN, return multiple instances of the resouce, typically encoded using multipart/alternative. N2C - Given a URN, return a collection of meta-information on the named resource. The format of this response is the subject of another document. N2Ns - Given a URN, return all URNs that are also identifers for the resource. L2R - Given a URL, return the resource. L2Ns - Given a URL, return all the URNs that are identifiers for the resource. L2Ls - Given a URL, return all the URLs for instances of of the same resource. L2C - Given a URL, return a description of the resource. The actual format of the service request and response will be determined by the resolution protocol, and is the subject for other documents. Protocols need not offer all services. The labels for service requests shall be formed from the set of characters [A-Z0-9]. The case of the alphabetic characters is not significant. Regexp A STRING containing a substitution expression that is applied to the original URI in order to construct the next name to lookup. The grammar of the substitution expression is given in the next section. Replacement The next NAME to query for NAPTR, SRV, or A records depending on the value of the flags field. As mentioned above, this may be compressed. Substitution Expression Grammar: ================================ The content of the regexp field is a substitution expression. True sed(1) substitution expressions are not appropriate for use in this application for a variety of reasons, therefore the contents of the regexp field MUST follow the grammar below: subst_expr = delim-char ere delim-char repl delim-char *flags delim-char = "/" / "!" / ... (Any non-digit or non-flag character other than backslash '\'. All occurances of a delim_char in a subst_expr must be the same character.) ere = POSIX Extended Regular Expression (see [9], section 2.8.4) repl = dns_str / backref / repl dns_str / repl backref dns_str = ...... which RFC can I cite for this? 1035 seems obsolete ..... backref = "\" 1POS_DIGIT flags = "i" DNS_CHAR = "_" / "0" / "1" / ... / "9" / "a" / ... / "z" POS_DIGIT = "1" / "2" / ... / "9" ; 0 is not an allowed backref value The result of applying the substitution expression to the original URI shall be a legal domain name. Since it is possible for the regexp field to be improperly specified, such that a non-conforming domain name can be constructed, client software SHOULD verify that the result is a legal domain name before making queries on it. Backref expressions "\N" in the repl portion of the substitution expression are replaced by the (possibly empty) string of characters enclosed by '(' and ')' in the ERE portion of the substitution expression. N is a single digit from 1 through 9, inclusive. It specifies the N'th backref expression, the one that begins with the N'th '(' and continues to the matching ')'. For example, the ERE (A(B(C)DE)(F)G) has backref expressions: \1 = ABCDEFG \2 = BCDE \3 = C \4 = F \5..\9 = error - no matching subexpression The "i" flag indicates that the ERE matching SHALL be performed in a case-insensitive fashion. Furthermore, any backref replacements MAY be normalized to lower case when the "i" flag is given. The first character in the substitution expression shall be used as the character that delimits the components of the substitution expression. There must be exactly three non-escaped occurances of the delimiter character in a substitution expression. Since escaped occurances of the delimiter character will be interpreted as occurances of that character, digits MUST NOT be used as delimiters. Backrefs would be confused with literal digits were this allowed. Similarly, if flags are specified in the substitution expression, the delimiter character must not also be a flag character. Advice to domain administrators: ================================ Beware of regular expressions. Not only are they a pain to get correct on their own, but there is the previously mentioned interaction with DNS. Any backslashes in a regexp must be entered twice in a zone file in order to appear once in a query response. More seriously, the need for double backslashes has probably not been tested by all implementors of DNS servers. We anticipate that urn.net will be the heaviest user of regexps. Only when delegating portions of namespaces should the typical domain administrator need to use regexps. On a related note, beware of interactions with the shell when manipulating regexps from the command line. Since '\' is a common escape character in shells, there is a good chance that when you think you are saying "\\" you are actually saying "\". Similar caveats apply to characters such as '*', '(', etc. The "a" flag allows the next lookup to be for A records rather than SRV records. Since there is no place for a port specification in the NAPTR record, when the "A" flag is used the specified protocol must be running on its default port. The URN-WG is discussing the use of international characters in URNs. The regexp package used may need to be changed from POSIX to one with the ability to handle UNICODE characters. Usage ===== Pseudocode for a client routine using NAPTRs is given below: // // findResolver(URN) // Given a URN, find a host that can resolve it. // findResolver(string URN) { sprintf(key, "%s.urn.net", extractNS(URN)); // prepend prefix to urn.net do { rewrite_flag = false; terminal = false; if (key has been seen) { quit with a loop detected error } add key to list of "seens" records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key' sort NAPTR records by "order" field and "preference" field (with "order" being more significant than "preference"). n_naptrs = number of NAPTR records in response. curr_order = records[0].order; max_order = records[n_naptrs-1].order; // Process current batch of NAPTRs according to "order" field. for (j=0; j < n_naptrs && records[j].order <= max_order; j++) { newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp); if (!newkey) // Skip to next record if the rewrite didn't match continue; // We did do a rewrite, shrink max_order to current value // so that delegation works properly max_order = naptr[j].order; // Will we know what to do with the protocol and services // specified in the NAPTR? If not, try next record. if(!isKnownProto(naptr[j].services)) { continue; } if(!isKnownService(naptr[j].services)) { continue; } // At this point we have a sucessful rewrite and we will know // how to speak the protocol and request a known resolution // service. Before we do the next lookup, check some // optimization possibilities. if (strcasecmp(flags, "S") || strcasecmp(flags, "P")) || strcasecmp(flags, "A")) { terminal = true; services = naptr[j].services; addnl = any SRV and/or A records returned as additional info for naptr[j]. } key = newkey; rewriteflag = true; break; } } while (rewriteflag && !terminal); // Did we not find our way to a resolver? if (!rewrite_flag) { report an error return NULL; } // Leave rest to another protocol? if (strcasecmp(flags, "P")) { return key as host to talk to; } // If not, keep plugging if (!addnl) { // No SRVs came in as additional info, look them up srvs = lookup(type=SRV, key); } sort SRV records by preference, weight, ... foreach (SRV record) { // in order of preference try contacting srv[j].target using the protocol and one of the resolution service requests from the "services" field of the last NAPTR record. if (successful) return (target, protocol, service); // Actually we would probably return a result, but this // code was supposed to just tell us a good host to talk to. } die with an "unable to find a host" error; } Notes: ====== - The "urn:" prefix is a matter of religious controversy. Client code should handle the cases when it is and is not present. Similarly, if regular expressions are used in NAPTR records, they should be immune to the presence or absence of an initial "urn:". - A client MUST process multiple NAPTR records in the order specified by the "order" field, it MUST NOT simply use the first record that provides a known protocol and service combination. - If a record at a particular order matches the URI, but the client doesn't know the specified protocol and service, the client SHOULD continue to examine records that have the same order. The client MUST NOT consider records with a higher value of order. This is necessary to make delegation of portions of the namespace work. The order field is what lets site administrators say "all requests for URIs matching pattern x go to server 1, all others go to server 2". (A match is defined as: 1) The NAPTR provides a replacement domain name 2) The regular expression matches the URN ) - When multiple RRs have the same "order", the client should use the value of the preference field to select the next NAPTR to consider. However, because of preferred protocols or services, estimates of network distance and bandwidth, etc. clients may use different criteria to sort the records. - If the lookup after a rewrite fails, clients are strongly encouraged to report a failure, rather than backing up to pursue other rewrite paths. - When a namespace is to be delegated among a set of resolvers, regexps must be used. Each regexp appears in a separate NAPTR RR. Administrators should do as little delegation as possible, because of limitations on the size of DNS responses. - Note that SRV RRs impose additional requirements on clients. Acknowledgments: ================= The authors would like to thank Keith Moore for all his consultations during the development of this draft. We would also like to thank Paul Vixie for his assistance in debugging our implementation, and his answers on our questions. References: =========== [1] RFC-1737, "Functional Requirements for Uniform Resource Names", Karen Sollins and Larry Masinter, Dec. 1994. [2] draft-daigle-urn-framework-00.txt "A Uniform Resource Naming Framework", Leslie Daigle and Patrik Faltstrom, June, 1996. [3] RFC 2052, "A DNS RR for specifying the location of services (DNS SRV)", A. Gulbrandsen and P. Vixie, October 1996. [4] Paul Vixie, personal communication. [5] RFC-822, "Standard for the Format of ARPA Internet Text Messages", Dave H. Crocker, August 1982. [6] Keith Moore, personal communication. [7] Keith Moore, "Resource Cataloging and Distribution Service", ??? (insert as [4], renumber the others?) [8] Charles Orth, Bill Arms; Handle Resolution Protocol Specification, http://www.handle.net/docs/client_spec.html [9] IEEE Standard for Information Technology - Portable Operating System Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1); IEEE Std 1003.2-1992; The Institute of Electrical and Electronics Engineers; New York; 1993. ISBN:1-55937-255-9 [10] ... rwhois spec ... [11] ... encoding resolution service requests in HTTP... Security Considerations ======================= The use of "urn.net" as the registry for URN namespaces is subject to denial of service attacks, as well as other DNS spoofing attacks. The interactions with DNSSEC are currently being studied. It is expected that NAPTR records will be signed with SIG records once the DNSSEC work is deployed. The rewrite rules make identifiers from other namespaces subject to the same attacks as normal domain names. Since they have not been easily resolvable before, this may or may not be considered a problem. Regular expressions should be checked for sanity, not blindly passed to something like PERL. Author Contact Information: =========================== Ron Daniel Los Alamos National Laboratory MS B287 Los Alamos, NM, USA, 87545 voice: +1 505 665 0597 fax: +1 505 665 4939 email: rdaniel@lanl.gov Michael Mealling Network Solutions 505 Huntmar Park Drive Herndon, VA 22070 voice: (703) 742-0400 fax: (703) 742-9552 email: michaelm@internic.net URL: http://www.netsol.com/ This draft expires 19 May, 1997. Ron Daniel Jr. email: rdaniel@acl.lanl.gov Advanced Computing Lab voice: (505) 665-0597 MS B-287 TA-3 Bldg. 2011 fax: (505) 665-4939 Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, 87545 obscure_term: "hypernym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA08321 for urn-ietf-out; Wed, 20 Nov 1996 15:32:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA08316 for ; Wed, 20 Nov 1996 15:32:10 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08307 (mail destined for urn-ietf@services.bunyip.com); Wed, 20 Nov 96 15:32:01 -0500 Received: from magenta.acl.lanl.gov (rdaniel@magenta.acl.lanl.gov [128.165.147.153]) by acl.lanl.gov (8.7.3/8.7.3) with ESMTP id NAA29850 for ; Wed, 20 Nov 1996 13:31:58 -0700 (MST) From: "Ronald E. Daniel" Received: (rdaniel@localhost) by magenta.acl.lanl.gov (8.7.5/8.6.4) id NAA29358 for urn-ietf@bunyip.com; Wed, 20 Nov 1996 13:31:57 -0700 (MST) Date: Wed, 20 Nov 1996 13:31:57 -0700 (MST) Message-Id: <199611202031.NAA29358@magenta.acl.lanl.gov> To: urn-ietf@bunyip.com Subject: [URN] HTTP conventions draft Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ronald E. Daniel" Errors-To: owner-urn-ietf@bunyip.com Hi, I've changed the conventions draft to remove the integer from the text/uri-list media type. The new version is appended. I will send this to the ID editor later today. Regards, Ron ==== INTERNET DRAFT Ron Daniel draft-ietf-urn-http-conventions-00.txt Los Alamos National Laboratory 13 Nov, 1996 Conventions for the Use of HTTP for URN Resolution Status of this Memo =================== This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). This draft expires 15 May, 1997. Abstract: ========= The URN-WG was formed to specify persistent, location-independent names for network accessible resources, and resolution mechanisms to retrive the resources given such a name. At this time the URN-WG is considering one particular resolution mechanism, the NAPTR proposal. That proposal does not get the client software all the way from the URN to the resource. Instead, it gets the client from a URN to a "resolver", which is a system that can then tell the client where the resource is. The NAPTR draft defines a "resolution protocol" to be the protocol used to speak to a resolver in order to obtain the resource, its location(s), or other information about the resource. The NAPTR proposal allows different resolution protocols to be used for commuicating with resolvers. This draft establishes conventions for encoding URN resolution requests and responses in HTTP 1.0 (and 1.1) requests and responses. The primary goal of this draft is to define a convention that is simple to implement and will allow existing HTTP servers to easily add support for URN resolution. We expect that the resolution databases that arise will be useful when more sophisticated resolution protocols are developed later. 1.0 Introduction: ================== The NAPTR draft[1] describes a way of using DNS to locate resolvers for URIs. That draft provides places to specify the "resolution protocol" spoken by the resolver, as well as the "resolution services" it offers. As of this writing, the "resolution protocols" allowed by the NAPTR draft are HTTP, RCDS, HDL, and RWHOIS. (That list is expected to grow over time). The NAPTR draft also lists a variety of resolution services, such as N2L (given a URN, return a URL); N2R (Given a URN, return the named resource), etc. This draft specifies the conventions to follow to encode resolution service requests in the HTTP protocol, allowing widely available HTTP daemons to serve as URN resolvers. The reader is assumed to be familiar with the HTTP/1.0 [2] and 1.1 [3] specifications. 2.0 General Approach: ===================== The general approach used to encode resolution service requests in HTTP is quite simple: GET /uri-res// HTTP/1.0 For example, if we have the URN "cid:foo@huh.com" and want a URL, we would send the request: GET /uri-res/N2L/cid:foo@huh.com HTTP/1.0 Because of the character set limitations on URIs, we might wish to encode the '@' character as its hex equivalent, thus the request would be GET /uri-res/N2L/cid:foo%40huh.com HTTP/1.0 The request could also be encoded as an HTTP 1.1 request. This would look like: GET /uri-res/N2L/cid:foo%40huh.com HTTP/1.1 Host: Handling these requests on the server side is easy to implement in a number of ways. The N2L request could be handled by a CGI script that took the incoming URN, looked it up in a database, and returned the URL as an HTTP redirect. Service requests like N2R or N2C could be set up so that the daemon answered the request by returning files out of N2R/ and N2C/ directories, or they could be handled by a script. One caveat should be kept in mind. The "urn:" prefix is still the subject of controversy, so some URN documents advocate treating it as optional. HTTP resolvers MUST return identical results for URIs that do and do not contain the "urn:" prefix. For example, the two request below must return identical results: GET /uri-res/N2L/cid:foo%40huh.com HTTP/1.0 GET /uri-res/N2L/urn:cid:foo%40huh.com HTTP/1.0 Responses from the HTTP server follow standard HTTP practice. Status codes, such as 200 (OK) or 404 (Not Found) shall be returned. The normal rules for determining cachability, negotiating formats, etc. apply. 3.0 Service-specific details: ============================= This section goes through the various resolution services established in the URN Framework draft [4] and states how to encode each of them, how the results should be returned, and any special status codes that are likely to arise. Unless stated otherwise, the HTTP requests are formed according to the simple convention above, either for HTTP/1.0 or HTTP/1.1. The response is assumed to be an entity with normal headers and body unless stated otherwise. (N2L is the only request that does not return a body). 3.1 N2L (URN to URL): ---------------------- The request is encoded as above. The URL MUST be returned in a Location: header for the convienience of the most common case of wanting the resource. A 30X status line SHOULD be returned. HTTP/1.1 clients should be sent the 303 status code. HTTP/1.0 clients should be sent the 302 (Moved temporarily) status code unless the resolver has particular resons for using 301 (moved permanently) or 304 (not modified) codes. 3.2 N2Ls (URN to URLs): ------------------------ The request is encoded as above. The result is a list of 0 or more URLs. The Internet Media Type (aka ContentType) of the result may be negotiated using standard HTTP mechanisms if desired. At a minimum the resolver should support the text/uri-list media type. (See Appendix A for the definition of this media type). That media type is suitable for machine-processing of the list of URLs. Resolvers may also return the results as text/html, text/plain, or any other media type they deem suitable. No matter what the particular media type, the result MUST be a list of the URLs which may be used to obtain an instance of the resource identified by the URN. All URIs shall be encoded according to the URI specification [5]. If the client has requested the result be returned as text/html or application/html, the result should be encoded as: where the strings ...url n... are replaced by the n'th URL in the list. 3.3 N2R (URN to Resource): --------------------------- The request is encoded as above. The resource is returned using standard HTTP mechanisms. The request may be modified using the Accept: header as in normal HTTP to specify that the result be given in a preferred Internet Media Types. 3.4 N2Rs (URN to Resources): ----------------------------- This resolution service returns multiple instances of a resource, for example, GIF and JPEG versions of an image. The judgment about the resources being "the same" resides with the naming authority that issued the URN. The request is encoded as above. The result shall be a MIME multipart/alternative message with the alternative versions of the resource in seperate body parts. If there is only one version of the resource identified by the URN, it MAY be returned without the multipart/alternative wrapper. Resolver software SHOULD look at the Accept: header, if any, and only return versions of the resource that are acceptable according to that header. 3.5 N2C (URN to URC): ---------------------- URCs (Uniform Resource Characteristics) are descriptions of other resources. This request allows us to obtain a description of the resource identified by a URN, as opposed to the resource itself. The description might be a bibliographic citation, a digital signature, a revision history, etc. This draft does not specify the content of any response to a URC request. That content is expected to vary from one resolver to another. The format of any response to a N2C request MUST be communicated using the ContentType header, as is standard HTTP practice. The Accept: header SHOULD be honored. 3.6 N2Ns (URN to URNs): ------------------------ While URNs are supposed to identify one and only one resource, that does not mean that a resource may have one and only one URN. For example, consider a resource that has something like "current-weather-map" for one URN and "weather-map-for-datetime-x" for another URN. The N2Ns service request lets us obtain lists of URNs that are believed equivalent at the time of the request. As the weathermap example shows, some of the equivalances will be transitory, so the standard HTTP mechanisms for communicating cachability MUST be honored. The request is encoded as above. The result is a list of all the URNs, known to the resolver, which identify the same resource as the input URN. The result shall be encoded as for the N2Ls request above (text/uri-list unless specified otherwise by an Accept: header). 3.7 L2Ns (URL to URNs): ---------------------- The request is encoded as above. The response is a list of any URNs known to be assigned to the resource at the given URL. The result shall be encoded as for the N2Ls and N2Ns requests. 3.8 L2Ls (URL to URLs): ------------------------ The request is encoded as described above. The result is a list of all the URLs that the resolver knows are associated with the resource located by the given URL. This is encoded as for the N2Ls, N2Ns, and L2Ns requests. 3.9 L2C (URL to URC): ---------------------- The request is encoded as above, the response is the same as for the N2C request. Implementation Notes: ===================== This section gives an example of how to configure a web server to respond to the N2L resolution request. It is not intended to specify standard behavior, it is provided here merely as a courtesy for implementors. First, we assume the presence of a CGI script, n2l.pl, that processes the provided URN, converting it into a canonical format. It would remove any "urn:" prefix, decode any %encoded special characters, normalize case-insensitive parts of the URN to lower case, etc. It would then use the normalized URN as the key for a search in a database, which we assume returns the URL as a string. A sample of our implementation of that script is provided as Appendix B. We will further assume that the n2l.pl script is in the cgi-bin directory of the web server. The easiest way to invoke the n2l.pl script in response to N2L requests is to set up a Redirect directive in the srm.conf file. (This works for servers based on the original NCSA HTTP daemon, such as Apache.) The relevant Redirect directives might look like: Redirect /uri-res/N2L http://urn.acl.lanl.gov/cgi-bin/n2l.pl Redirect /uri-res/L2N http://urn.acl.lanl.gov/cgi-bin/l2n.pl Appendix A: The text/uri-list Internet Media Type ================================================= [This appendix will be augmented or replaced by the registration of the text/uri-list IMT once that registration has been performed]. Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns, L2Ls, result in a list of URIs being returned to the client. The text/uri-list Internet Media Type is defined to provide a simple format for the automatic processing of such lists of URIs. The format of text/uri-list resources is: 1) Any lines beginning with the '#' character are comment lines and are ignored during processing. (Note that '#' is a character that may appear in URIs, so it only denotes a comment when it is the first character on a line). 2) The remaining non-comment lines MUST be URIs (URNs or URLs), encoded according to the URI specification RFC[5]. Each URI shall appear on one and only one line. 3) As for all text/* formats, lines are terminated with a CR LF pair. In applications where one URI has been mapped to a list of URIs, such as in response to the N2Ls request, the first line of the text/uri-list response SHOULD be a comment giving the original URI. An example of such a result for the N2L request is shown below in figure 1. # urn:cid:foo@huh.org http://www.huh.org/cid/foo.html http://www.huh.org/cid/foo.pdf ftp://ftp.foo.org/cid/foo.txt Figure 1: Example of the text/uri-list format Appendix B: n2l.pl script ========================== This is a simple perl script for the N2L resolution service. It assumes the presence of a DBM database to store the URN to URL mappings. #!/bin/perl # N2L - performs urn to url resolution $n2l_File = "...filename for DBM database..."; $urn = $ENV{'PATH_INFO'} ; if(length($urn)<3) { $error=1; } if(!$error) { $urn =~s/^(\/)(urn:)?(.*)/$3/i; # Additional canonicalization should be performed here dbmopen(%lu,$n2l_File,0444); if($lu{$urn}) { $url=$lu{$urn}; print STDOUT "Location: $url\n\n"; }else{ $error=2; } dbmclose(%lu); } if($error) { print "Content-Type: text/html \n\n"; print "\n"; print "URN Resolution: N2L\n"; print "\n"; print "

URN to URL resolution failed for the URN:

\n"; print "

$urn

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

URN to URL resolution failed for the URN:

\n"; print "

$urn

\n"; print "\n"; print "\n"; } exit; References: =========== [1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", draft-ietf-urn-naptr-00.txt, October, 1996. [2] T. Berners-Lee, R. Fielding, H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May, 1996. [3] HTTP 1.1 draft [4] URN Framework draft [5] RFC 1630 Security Considerations ======================= Communications with a resolver may be of a sensitive nature. Some resolvers will hold information that should only be released to authorized users. The results from resolvers may be the target of spoofing, especially once electronic commerce transactions are common and ther is money to be made by directing users to pirate repositories rather than repositories which pay royalties to rightsholders. Resolution requests may be of interest to traffic analysts. The requests may also be subject to spoofing. The requests and responses in this draft are amenable to encoding, signing, and authentication in the manner of any other HTTP traffic. Author Contact Information: =========================== Ron Daniel Los Alamos National Laboratory MS B287 Los Alamos, NM, USA, 87545 voice: +1 505 665 0597 fax: +1 505 665 4939 email: rdaniel@lanl.gov This draft expires 15 May, 1997. Ron Daniel Jr. email: rdaniel@acl.lanl.gov Advanced Computing Lab voice: (505) 665-0597 MS B-287 TA-3 Bldg. 2011 fax: (505) 665-4939 Los Alamos National Lab http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, 87545 obscure_term: "hypernym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA13751 for urn-ietf-out; Wed, 13 Nov 1996 16:32:01 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA13745 for ; Wed, 13 Nov 1996 16:31:59 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15170 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 16:31:58 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id NAA06896; Wed, 13 Nov 1996 13:30:12 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id NAA19036; Wed, 13 Nov 1996 13:30:23 -0800 (PST) Date: Wed, 13 Nov 1996 13:30:23 -0800 (PST) From: Terry Allen Message-Id: <199611132130.NAA19036@ishtar.fsc.fujitsu.com> To: moore@cs.utk.edu, stu_weibel@oclc.org Subject: Re: [URN] Re: I18N does not belong in URNs Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Keith writes: | As to the former statement, in case there's any doubt as to "URNs aren't | supposed to be human meaningful", I refer interested parties to the group's | charter | (http://www.ietf.org/html.charters/urn-charter.html) and to RFC 1737, | the requirements of which the charter incorporates by reference. Please cite specific passages in support of your position. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA13616 for urn-ietf-out; Wed, 13 Nov 1996 16:28:01 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA13608 for ; Wed, 13 Nov 1996 16:27:57 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15103 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 16:27:44 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <02106-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 22:24:54 +0100 Subject: Re: [URN] Please avoid "URNs are" To: moore@cs.utk.edu (Keith Moore) Date: Wed, 13 Nov 1996 22:24:53 +0100 (MET) Cc: moore@cs.utk.edu, Harald.T.Alvestrand@uninett.no, Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611132031.PAA21010@ig.cs.utk.edu> from "Keith Moore" at Nov 13, 96 03:31:47 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4775 From: Martin J Duerst Message-Id: <"josef.ifi..528:13.10.96.21.24.55"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore wrote: >> >Also, we can't assume that the transcription of a URN from paper to >> >keyboard will be through an intelligent tool that understands how to >> >translate URNs from display format to some other format. >> >> You need a reasonably intelligent human user, of course. As for >> keyboarding tools, in the worst case you would need a Unicode >> book (cheaper than most keyboards themselves, but unfortunately >> heavy), a piece of paper, and a code table for the 16 hex digits. >> As an alternative, I suggest some nice site programmed in Java, >> or whatever. > >Sorry, I just don't buy it. > >People aren't going to carry around Unicode books, and they're not >going to be willing to poke through several pages or screenfuls of >glphys to find the one matching a particular character in a URN. The Unicode book was of course meant more as a joke. But it shows that the minimal requirement, in terms of software, is really very low. I don't say that it should be done that way. On the other hand, what are you going to do if you get a traditional payment slip with a Japanese postal transfer account number on it, and are requested to send some money electronically to that account? If you have nothing but a US keyboard and lynx for Web access, would you prefer to look up the relevant character in an Unicode book and do the UCS-2 => UTF-8 => %HH calculations according to a well-established convention, or would you prefer to have to search for a document defining how the Japanese postal transfer account number namespace is mapped to the GCD character set, and then to get whatever specific standard you need to determine the encoding of that character, and then go through a similar encoding procedure? As another example, if you go to a library in China that uses some ideographs in their catalog numbers, do you want to require that the thousands of daily Chinese users learn how to convert from their traditional catalog numbering system to what the library has arbitrarily decided to use for encoding it into URNs (other than some straightforward prefixing), just that in the rare case that such an URN finds its way to some Western ignorant, he is able to type it in without even the slightest effort? By defining UTF-8 to be used in URNs, we can make life easier for all Japanese typing in postal transfer account numbers, and all Chinese users of such catalogs, and many others in large numbers, while not giving the accidental outside user much more work than what he might have had anyway. And we still can rest assured that when you get an URN from a friend in Japan or China, and that friend is indeed aware of your ignorance about ideographs, (s)he can send it in a form (namely %HH) that you will feel sure will not get mutilated. [In general, an integrated browser/mail handling system will not have problems to handle the URN even if it is Japanese characters (assumed the encoding is correctly labeled, a requirement which we need anyway). But your friend may be so kind and take into account your disbelief in these matters.] >Pen-style PDAs have enough trouble analyzing latin letters; they >aren't going to support the ability to enter arbitrary Unicode >characters anytime soon -- especially not from people who aren't used >to writing those characters.** Arbitrary Unicode contains lots of similar-looking instances, and indeed would be difficult. But if characters from the usual subsets are used in context, pen input covering pretty much full Unicode is not so difficult. Please note that for writers knowing how to write the characters, pen input actually works better for ideographs than for English. >From reading RFC 1737, URNs were obviously intended to be composed of >a small set of characters. Trying to incorporate all of Unicode into >URNs is just too big a stretch. >From reading some parts for RFC 1737, one may definitely get that impression, in particular if one has never really imagined that something else could be possible. But there is nothing in RFC 1737 that requires that we do not define how other characters are represented in case they need to be represented. We do not "incorporate all of Unicode" in the sense that we require every URN to contain at least an Arabic and a Hebrew character and a CJK Ideograph and so on. We just make it possible that such characters can be represented by URLs for those namespaces that have such a requirement. We also make it possible for namespaces that contain characters from the base Latin alphabet to be represented in URLs. To be fair to (almost) all really existing namespaces, we have to either restrict ourselves to just the digits or so, or to allow for any character from the universal character set to be representable. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA12430 for urn-ietf-out; Wed, 13 Nov 1996 15:40:47 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA12425 for ; Wed, 13 Nov 1996 15:40:14 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14350 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 15:39:45 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id PAA21010; Wed, 13 Nov 1996 15:31:47 -0500 (EST) Message-Id: <199611132031.PAA21010@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: moore@cs.utk.edu (Keith Moore), Harald.T.Alvestrand@uninett.no, Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] Please avoid "URNs are" In-Reply-To: Your message of "Wed, 13 Nov 1996 20:54:21 +0100." <"josef.ifi..262:13.10.96.19.54.32"@ifi.unizh.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Nov 1996 15:31:47 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > >> > o Single encoding: The encoding for presentation for people in clear > >> > text, electronic mail and the like is the same as the encoding in > >> > other transmissions. > >> > >> This requirement makes sense in the sense that the number of different > >> representations and encoding should be as low as possible. > > > >I hope that "as low as possible" is equivalent to "one". > > Well, with EBCDIC and ASCII, you will certainly have two :-). Not if we think of URNs as being composed of characters :) > >> But it does not say anything about how URNs are noted on paper. > > > >No it doesn't. But it seems reasonable to expect that people will > >transcribe URNs from their screens to paper, and from that paper to > >keyboard. The result of doing so had better produce the same URN. > > Of course. Modulo some problems of the kind of O/0 and l/1/I, it > will, for all of i18n. Not if my keyboard doesn't support the characters in the URN. > >Also, we can't assume that the transcription of a URN from paper to > >keyboard will be through an intelligent tool that understands how to > >translate URNs from display format to some other format. > > You need a reasonably intelligent human user, of course. As for > keyboarding tools, in the worst case you would need a Unicode > book (cheaper than most keyboards themselves, but unfortunately > heavy), a piece of paper, and a code table for the 16 hex digits. > As an alternative, I suggest some nice site programmed in Java, > or whatever. Sorry, I just don't buy it. People aren't going to carry around Unicode books, and they're not going to be willing to poke through several pages or screenfuls of glphys to find the one matching a particular character in a URN. Pen-style PDAs have enough trouble analyzing latin letters; they aren't going to support the ability to enter arbitrary Unicode characters anytime soon -- especially not from people who aren't used to writing those characters.** >From reading RFC 1737, URNs were obviously intended to be composed of a small set of characters. Trying to incorporate all of Unicode into URNs is just too big a stretch. Keith **(And while voice-recognition technology is already good enough to distinguish latin letters and digits pronounced by random people in random dialects, it will never be good enough to let people "speak in" random characters that they've never seen before and don't know how to prononuce. I mention this because it seems obvious to me that personal computers, especially portable ones, are going to support voice recognition -- a microphone is a lot more portable than either a keyboard or a writing surface.) Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA11982 for urn-ietf-out; Wed, 13 Nov 1996 15:22:14 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA11977; Wed, 13 Nov 1996 15:22:12 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14120 (mail destined for find@services.bunyip.com); Wed, 13 Nov 96 15:22:07 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id PAA20999; Wed, 13 Nov 1996 15:16:58 -0500 (EST) Message-Id: <199611132016.PAA20999@ig.cs.utk.edu> To: apps-working-group-list:; Subject: [URN] reminder of Internet-Draft cutoff date Date: Wed, 13 Nov 1996 15:16:58 -0500 From: Keith Moore Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com This is just a reminder that the cutoff for Internet-Draft submissions prior to the San Jose IETF meeting is Tuesday, November 26, 1996 at 1700 Eastern Standard US time. (I think that's 2200 UTC) Proposals to be discussed at IETF WG meetings must be submitted as Internet-Drafts prior to discussion. So if you want to have a proposal discussed at the San Jose IETF, you need to get it in before this deadline. Please also note that due to the the large number of last-minute internet-draft submissions, last-minute drafts require more time to appear in the Internet-Drafts repositories. Given the US Thanksgiving holidays on 28-29 November, I wouldn't expect last-minute drafts to be generally available before 2-3 December or so. So to give other working group members more time to review drafts, I encourage people to submit their drafts a few days before the deadline. For information on how to submit an Internet-Draft, look at ftp://ftp.ietf.org/ietf/1id-guidelines.txt Keith Moore APPS AD Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA11959 for urn-ietf-out; Wed, 13 Nov 1996 15:20:26 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA11953 for ; Wed, 13 Nov 1996 15:20:23 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14036 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 15:13:19 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id PAA20767; Wed, 13 Nov 1996 15:12:48 -0500 (EST) Message-Id: <199611132012.PAA20767@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: stu_weibel@oclc.org (Stu Weibel) Cc: urn-ietf@bunyip.com, moore@cs.utk.edu Subject: [URN] Re: I18N does not belong in URNs In-Reply-To: Your message of "Mon, 11 Nov 1996 13:56:14 EST." <199611111856.NAA20145@orc.NISOR> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Nov 1996 15:12:48 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com Stu writes: > Keith Moore writes: > > > URNs aren't supposed to be human-meaningful. Making them human-meaningful > > defeats the purpose of having them be long-term stable. > > This reflects a philosophy, an attitude, a point of view that is NOT > shared in anything like a consensus in this group. As to the latter statement, I agree with you. Many people do not believe (or are not yet convinced) that human-meaningful URNs are inherently nonpersistent over the long term. Even I will concede that there might be a way out. Tim Berners-Lee and others have suggested adding low-precision dates to URNs. So (e.g.) the "199610" in the URN urn:inet:kodak.com/199610/gibberish would fix the meaning of "kodak.com" and any other human-readable strings within the URN to "the meaning of these words in the tenth month of 1996". Maybe that would be sufficient. There's no way to know for sure, since it depends on what people do in the future. As to the former statement, in case there's any doubt as to "URNs aren't supposed to be human meaningful", I refer interested parties to the group's charter (http://www.ietf.org/html.charters/urn-charter.html) and to RFC 1737, the requirements of which the charter incorporates by reference. Actually, I recommend that everyone here re-read RFC 1737, with particular emphasis on the Introduction. It is a good description of the problem that this group was created to solve. > I say again... > this WG should adopt the *least restrictive* solution that is technologically > sound and let people do with it what their communities choose. That sounds reasonable, but by itself, it's not good engineering sense. Here's an alternative view for consideration: This WG should adopt the *least complex* solution which meets the various requirements of its charter, and which does not impose unnecessary restrictions beyond those inherent in the problem space. Of course, both of these positions are extreme. Usually we want a solution that is not too complex to implement, but still has some extra flexibility to allow the solution, once deployed, to adapt to unanticipated uses. But when people propose adding I18N support to URNs to make them human meaningful, I view this as adding a great deal of extra complexity in an attempt to make URNs solve a completely different problem than they were designed to solve. (And given the history of various "information infrastructure" groups at failing to narrow their scope to a problem that's solvable in finite time, I get very nervous.) By contrast, when people propose adding I18N support to URNs to allow them to incorporate URN-like names that happen to include one or two non-universal characters, I wonder things like "Is it really worth the complexity?" and "Which is more important, global scope and transcribability and single encoding or the ability to easily grandfather all URN-like systems?" Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA10723 for urn-ietf-out; Wed, 13 Nov 1996 14:57:11 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA10718 for ; Wed, 13 Nov 1996 14:56:58 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13771 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 14:55:22 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01921-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 20:54:22 +0100 Subject: Re: [URN] Please avoid "URNs are" To: moore@cs.utk.edu (Keith Moore) Date: Wed, 13 Nov 1996 20:54:21 +0100 (MET) Cc: moore@cs.utk.edu, Harald.T.Alvestrand@uninett.no, Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611131905.OAA15428@ig.cs.utk.edu> from "Keith Moore" at Nov 13, 96 02:05:06 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4344 From: Martin J Duerst Message-Id: <"josef.ifi..262:13.10.96.19.54.32"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore wrote: >> >> PLEASE avoid saying "URNs are XXX". Please use wording such >> >> as "URNs are noted on paper as XXX", "URNs are represented >> >> on computers in the following forms...", or "URNs represent >> >> characters from the following set..." or whatever. >> > >> >I'm not sure how much difference it makes. RFC 1737 requires >> >the following: >> > >> > o Single encoding: The encoding for presentation for people in clear >> > text, electronic mail and the like is the same as the encoding in >> > other transmissions. >> >> This requirement makes sense in the sense that the number of different >> representations and encoding should be as low as possible. > >I hope that "as low as possible" is equivalent to "one". Well, with EBCDIC and ASCII, you will certainly have two :-). >> But it does not say anything about how URNs are noted on paper. > >No it doesn't. But it seems reasonable to expect that people will >transcribe URNs from their screens to paper, and from that paper to >keyboard. The result of doing so had better produce the same URN. Of course. Modulo some problems of the kind of O/0 and l/1/I, it will, for all of i18n. >Also, we can't assume that the transcription of a URN from paper to >keyboard will be through an intelligent tool that understands how to >translate URNs from display format to some other format. You need a reasonably intelligent human user, of course. As for keyboarding tools, in the worst case you would need a Unicode book (cheaper than most keyboards themselves, but unfortunately heavy), a piece of paper, and a code table for the 16 hex digits. As an alternative, I suggest some nice site programmed in Java, or whatever. >A URN could >certainly be sent via email, transcribed to paper, and typed back into >plain text email by someone else. For Japanese postal transfer accounts, that would work without problems, even if the Kanji character appears as such, and not mutilated to some ASCII-compatible form. The only thing you have to make sure is that if you cut/paste something from/to your URN field in a browser, the underlying encoding is changed appropriately (from ISO-2022-JP in the case of email to UTF-8, with or without the additional %HH depending on what is needed). Browsers such as Netscape do conversions correctly in other instances, so I have no doubt they would get it right as soon as they know what to do. >For grandfathering other URN schemes, non-universal characters will >need to be converted into sequences of universal characters. International standards use the term "universal character set" to denote an encompassing set of characters. In order to avoid misunderstanding by less informed readers, why not use "greatest-common-denominator characters" or GCD characters for short. >That way >there can be a well-defined conversion from {j.random.naming.scheme} >to URN, but only one format for the URN once it's converted. It's >fine if smart software recognizes certain types of URNs and undoes the >conversion, so long as the unconverted form is displayed as an >identifier from {j.random.naming.scheme} and NOT as a URN. We have been at this point before. It is mainly a naming issue, and to some extent a protocol encoding issue. You are requesting that things that don't appear %HH-encoded, but with the origina characters they represent, are not called URNs. You are also requesting that there be no 8-bit transfer form. >As for URNs encoded in EBCDIC: we should probably define URNs as >sequences of characters, Here wording really matters. To be clear, it is best to say that URNs are *represented by* sequences of characters. They *are* abstract, permanent identifiers or something along these lines. >which can be represented in any character >encoding scheme, so long as: > >+ that encoding scheme is clearly labeled (e.g. MIME charset) whenever >multiple encodings can appear in the same context, and > >+ there is a unique encoding in that scheme for each character that >can appear in a URN. > >So URN character sequences could be encoded in ASCII or EBCDIC or >UCS-32 or whatever and still be URNs. A small detail: What you mean by UCS-32 is called UCS-4. It might have been called UCS-31, but not UCS-32, because in the 4-byte form, the uppermost bit (sign bit) is not used. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA10076 for urn-ietf-out; Wed, 13 Nov 1996 14:17:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA10067 for ; Wed, 13 Nov 1996 14:17:03 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13374 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 14:16:57 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01896-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 20:16:13 +0100 Subject: Re: [URN] I18N does not belong in URNs To: Dirk.vanGulik@jrc.it (Dirk.vanGulik) Date: Wed, 13 Nov 1996 20:16:12 +0100 (MET) Cc: FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <9611111313.AA04245@ jrc.it> from "Dirk.vanGulik" at Nov 11, 96 02:13:30 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3530 From: Martin J Duerst Message-Id: <"josef.ifi..120:13.10.96.19.16.30"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Dirk.vanGulik wrote: >Or they use a naming scheme dependent interpretation. You could for >example simply limit the representation of the URN to the glyphs >A-Z, 0-9 and say the dot, dash, and colon. Too much in favor of English users (+Hawaiian and Suwaheli)! >I recently came across a specific scheme, say 'crdis' which has a lot of >LocalControlIdentfiers which can (only be fully) expressed in 2-byte octets. >This obviously gave problems as some of our z39.50 servers and HTTP/URN resolving >code did not quite like this. A pragmatic solution was to simply base64 >encode the identfication string. > >A specialist GUI could now base64-decode the string to arrive >at something meaningfull for a human. But it does not have to. >And it does keep things simple. I have mentionned earlier the possibility that some namespaces may contain arbitrary data, as opposed to characters, and I have therefore suggested that the requirement that all URNs be UTF-8 should be relaxed. I have given the data: URL as an example. Here we have an obvious second examlpe. >I really would like to roll up the charset discussion; I agree that for a lot >of scheme's, in particular those to be grandfathered in, one will need very >flexible encodings. They need to be very flexible in the sense that they have to be able to accomodate a very large set of characters, and something else than characters in some cases. But there is absolutely no reason to have arbitrary flexibility for those cases where indeed characters have to be represented. For this case, it is much easier to specify that UTF-8 be used (optionally or even mandatorily with %HH encoding). >But the internet transfer mechanisms are not quite up to >that yet. So I would suggest: > > 1. Limit the URNs to just a few chars (along the lines of DNS) This > also makes comparing URNs easy. As for the character set *representing* URNs, I can agree. This would basically mean that everything has to be %HH encoded. > 2. Allow, or perhaps even force, each registered naming scheme > to suggest a possible encoding/escape sequencing to derive > nice human names from the URN. This can be used by the more > advanced GUIs. The greatest majority of naming schemes will have identical problems, namely how to represent characters in namespaces. And a single and very simple GUI can provide nice human representations for these cases (modulo available fonts). And a single and widely applicable convention should be used by all naming schemes dealing with characters. > 3. And keep a few chars (say the %) in stock, for the future. > > 4. And remember, one can always make something like a next generation > URN+:das:asd which can only be transcribed properly using say UTF8. There is absolutely no need to wait any longer for UTF-8. >I know that such an encoding essentially wastes space; but that is a tradeoff >I am willing to make for simplfied storage, encoding and comparing. All your requirements can be fulfilled by: - Allowing non-character namespaces to create their own non UTF-8 encodings (as I have suggested previously). - Require that internally, all 8-bit octets resulting from UTF-8 encoding of characters beyond ASCII (+some in ASCII) be encoded with %HH, so that there is no 8-bit from of URNs. Although I have good reasons to think that the second point is not needed, I could live with it. But giving up a convention such as UTF-8 to map arbitrary characters in namespaces to URNs would be a great loss. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA10001 for urn-ietf-out; Wed, 13 Nov 1996 14:10:33 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA09995 for ; Wed, 13 Nov 1996 14:10:27 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13304 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 14:10:18 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id OAA15428; Wed, 13 Nov 1996 14:05:06 -0500 (EST) Message-Id: <199611131905.OAA15428@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: moore@cs.utk.edu (Keith Moore), Harald.T.Alvestrand@uninett.no, Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] Please avoid "URNs are" In-Reply-To: Your message of "Wed, 13 Nov 1996 19:41:54 +0100." <"josef.ifi..077:13.10.96.18.41.56"@ifi.unizh.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Nov 1996 14:05:06 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > >> PLEASE avoid saying "URNs are XXX". Please use wording such > >> as "URNs are noted on paper as XXX", "URNs are represented > >> on computers in the following forms...", or "URNs represent > >> characters from the following set..." or whatever. > > > >I'm not sure how much difference it makes. RFC 1737 requires > >the following: > > > > o Single encoding: The encoding for presentation for people in clear > > text, electronic mail and the like is the same as the encoding in > > other transmissions. > > This requirement makes sense in the sense that the number of different > representations and encoding should be as low as possible. I hope that "as low as possible" is equivalent to "one". > But it does not say anything about how URNs are noted on paper. No it doesn't. But it seems reasonable to expect that people will transcribe URNs from their screens to paper, and from that paper to keyboard. The result of doing so had better produce the same URN. Also, we can't assume that the transcription of a URN from paper to keyboard will be through an intelligent tool that understands how to translate URNs from display format to some other format. A URN could certainly be sent via email, transcribed to paper, and typed back into plain text email by someone else. For grandfathering other URN schemes, non-universal characters will need to be converted into sequences of universal characters. That way there can be a well-defined conversion from {j.random.naming.scheme} to URN, but only one format for the URN once it's converted. It's fine if smart software recognizes certain types of URNs and undoes the conversion, so long as the unconverted form is displayed as an identifier from {j.random.naming.scheme} and NOT as a URN. As for URNs encoded in EBCDIC: we should probably define URNs as sequences of characters, which can be represented in any character encoding scheme, so long as: + that encoding scheme is clearly labeled (e.g. MIME charset) whenever multiple encodings can appear in the same context, and + there is a unique encoding in that scheme for each character that can appear in a URN. So URN character sequences could be encoded in ASCII or EBCDIC or UCS-32 or whatever and still be URNs. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA09902 for urn-ietf-out; Wed, 13 Nov 1996 14:01:51 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA09884 for ; Wed, 13 Nov 1996 14:00:12 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13195 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 14:00:08 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01830-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 19:41:55 +0100 Subject: Re: [URN] Please avoid "URNs are" To: moore@cs.utk.edu (Keith Moore) Date: Wed, 13 Nov 1996 19:41:54 +0100 (MET) Cc: Harald.T.Alvestrand@uninett.no, Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611131825.NAA15239@ig.cs.utk.edu> from "Keith Moore" at Nov 13, 96 01:25:05 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1086 From: Martin J Duerst Message-Id: <"josef.ifi..077:13.10.96.18.41.56"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore wrote: >> PLEASE avoid saying "URNs are XXX". Please use wording such >> as "URNs are noted on paper as XXX", "URNs are represented >> on computers in the following forms...", or "URNs represent >> characters from the following set..." or whatever. > >I'm not sure how much difference it makes. RFC 1737 requires >the following: > > o Single encoding: The encoding for presentation for people in clear > text, electronic mail and the like is the same as the encoding in > other transmissions. This requirement makes sense in the sense that the number of different representations and encoding should be as low as possible. But it does not say anything about how URNs are noted on paper. It also does not say something about how people may finally see it (the encoding used for presentation could well be %HH, with an intelligent tool showing Chinese or whatever). In addition, when considering EBCDIC, it would either forbid URNs to be transmitted with EBCDIC, or would garble URNs encoded in EBCDIC for the sake of preserving the encoding. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA09901 for urn-ietf-out; Wed, 13 Nov 1996 14:01:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA09881 for ; Wed, 13 Nov 1996 14:00:08 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13192 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 14:00:01 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01807-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 19:27:49 +0100 Subject: Re: [URN] I18N does not belong in URNs To: conklin@info.cren.net (Jim Conklin) Date: Wed, 13 Nov 1996 19:27:48 +0100 (MET) Cc: Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: from "Jim Conklin" at Nov 11, 96 11:59:15 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2020 From: Martin J Duerst Message-Id: <"josef.ifi..611:13.10.96.18.27.55"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Jim Conklin wrote: > I've been trying to decide how one might allow human-meaningful URNs for >multiple languages and encodings, and it seems to me that this would be >possible if and only if the URN identifier itself includes character-set >information. Jim - The current proposal implicitly includes character-set information. This is done by choosing the Universal Character Set (ISO 10646), which assures that any character in any existing and reasonably used character set can be used. If you don't know about ISO 10646, also known under the name Unicode, I can point you to additional information. Including character set information explicitly would make the URNs more clumsy, would require applications to handle more and more character sets, and would have some other disadvantages. This is independent of whether URNs should/could/should not be meaningful. > Would it make sense to include in the definition of the URN format (yes, >I know, this is past history!) an optional language and encoding >specification which could then be used by sufficiently intelligent clients >to display the URN in the specified language using the specified character >encoding? As for encoding, I have given you the answer above. You now also mention language. I do not think that language information is necessary for URNs. If you think it is necessary, can you please explain your reasons, so that I can answer specifically? >Even the language and encoding could, in that way, be rendered >in the specified language and, with a (relatively) small number of >predefined languages and encodings, those could be specified in a small, >universal symbol set, since they'd normally not be seen by the end user >with a smart client. As for "small number of encodings", we have a solution with only one encoding. That should be small enough a number. As for "small number of languages", if language information should indeed be needed, restricting the number of languages would be very unfair indeed. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA09770 for urn-ietf-out; Wed, 13 Nov 1996 13:47:07 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA09765 for ; Wed, 13 Nov 1996 13:47:04 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13034 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 13:46:31 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id NAA15239; Wed, 13 Nov 1996 13:25:05 -0500 (EST) Message-Id: <199611131825.NAA15239@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: Harald.T.Alvestrand@uninett.no, Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] Please avoid "URNs are" In-Reply-To: Your message of "Wed, 13 Nov 1996 19:16:55 +0100." <"josef.ifi..391:13.10.96.18.16.57"@ifi.unizh.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 13 Nov 1996 13:25:05 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > PLEASE avoid saying "URNs are XXX". Please use wording such > as "URNs are noted on paper as XXX", "URNs are represented > on computers in the following forms...", or "URNs represent > characters from the following set..." or whatever. I'm not sure how much difference it makes. RFC 1737 requires the following: o Single encoding: The encoding for presentation for people in clear text, electronic mail and the like is the same as the encoding in other transmissions. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA09372 for urn-ietf-out; Wed, 13 Nov 1996 13:22:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA09361 for ; Wed, 13 Nov 1996 13:21:53 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12793 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 13:21:21 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01775-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 19:16:56 +0100 Subject: Re: [URN] Please avoid "URNs are" To: Harald.T.Alvestrand@uninett.no Date: Wed, 13 Nov 1996 19:16:55 +0100 (MET) Cc: Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <25174.847734044@dale.uninett.no> from "Harald.T.Alvestrand@uninett.no" at Nov 11, 96 06:40:44 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1535 From: Martin J Duerst Message-Id: <"josef.ifi..391:13.10.96.18.16.57"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Harald Alvestran wrote: >There are about 3 alternatives I can see: > >- The URN syntax doc says that URNs are sequences of ASCII > characters (or some subset thereof) >- The URN syntax doc says that URNs are sequences of OCTETS, > with no meaning assigned by the URN syntax doc after the > second : >- The URN syntax doc says that URNs are sequences of CHARACTERS, > drawn from the ISO 10646 set. > >The tradeoffs are different for the 3 cases. I have followed the followups to this message, but only have been confused more. PLEASE avoid saying "URNs are XXX". Please use wording such as "URNs are noted on paper as XXX", "URNs are represented on computers in the following forms...", or "URNs represent characters from the following set..." or whatever. Except for octet values coinciding with encoded ASCII characters coinciding with the notation of these same characters on paper and actually representing these same characters, the distinctions made above matter very much both to have a clear and working proposal, and to have this proposal being understood by those that will need to do so. When you start to think about i18n issues, it is difficult to get avay from the simple ASCII world where "representing" and "represented" are just fillers because everything looks the same. As Ryan Moats has said earlier, changing your thinking to accomodate the complexities outside ASCII can be painful. He at least understands that it has to be done. So in future messages, please avoid saying "URNs are". Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA09167 for urn-ietf-out; Wed, 13 Nov 1996 13:10:45 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA09158 for ; Wed, 13 Nov 1996 13:10:13 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12681 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 13:10:09 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01757-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 19:02:03 +0100 Subject: Re: [URN] I18N does not belong in URNs To: masinter@parc.xerox.com (Larry Masinter) Date: Wed, 13 Nov 1996 19:02:02 +0100 (MET) Cc: FisherM@is3.indy.tce.com, Dirk.vanGulik@jrc.it, girod@LCS.MIT.EDU, Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <96Nov12.090844pst."2695"@golden.parc.xerox.com> from "Larry Masinter" at Nov 12, 96 09:08:44 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 799 From: Martin J Duerst Message-Id: <"josef.ifi..026:13.10.96.18.02.18"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Larry Masinter wrote: ># If (as an example) a Chinese information provider wished to make ># available their resources to English speakers as URNs, I would ># suspect they would want to provide "English-compatible" URNs, ># rather than long, seemingly random %XX-encoded strings. > >So the library of China should assign chinese URNs to the information >they think only Chinese readers will want to read, and ASCII URNs to >the texts they think might also be of interest to people who don't >read Chinese? Probably they shouldn't, but they might. They indeed might already have some naming scheme for their complete library that includes Chinese characters and that they want to grandfather. And there is no rule that for a given resource, there can only be one single URN. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA09116 for urn-ietf-out; Wed, 13 Nov 1996 13:07:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA09105 for ; Wed, 13 Nov 1996 13:06:49 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12661 (mail destined for urn-ietf@services.bunyip.com); Wed, 13 Nov 96 13:06:39 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01765-0@josef.ifi.unizh.ch>; Wed, 13 Nov 1996 19:06:06 +0100 Subject: Re: [URN] I18N does not belong in URNs To: masinter@parc.xerox.com (Larry Masinter) Date: Wed, 13 Nov 1996 19:06:05 +0100 (MET) Cc: FisherM@is3.indy.tce.com, Dirk.vanGulik@jrc.it, girod@LCS.MIT.EDU, Harald.T.Alvestrand@uninett.no, moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <96Nov12.090844pst."2695"@golden.parc.xerox.com> from "Larry Masinter" at Nov 12, 96 09:08:44 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 792 From: Martin J Duerst Message-Id: <"josef.ifi..121:13.10.96.18.06.07"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Larry Masinter wrote: >So the library of China should assign chinese URNs to the information >they think only Chinese readers will want to read, and ASCII URNs to >the texts they think might also be of interest to people who don't >read Chinese? Just some additional comment: In case they decide to assign anything meaningful (which we will tell them not to do, but they still might do), please note that for many classic texts (as well as for many other things such as place names, countries, names of persons) there are established conventions that differ from language to language. This means that it could be very difficult for a Chinese to identify a hint to some text in an ASCII URN, although he/she might know the name of the text, and the text itself, very well. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA23052 for urn-ietf-out; Tue, 12 Nov 1996 13:24:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA23047 for ; Tue, 12 Nov 1996 13:24:54 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03711 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 13:24:51 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id LAA09242; Tue, 12 Nov 1996 11:24:21 -0700 (MST) Message-Id: <2.2.32.19961112183238.0070c654@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 11:32:38 -0700 To: Harald.T.Alvestrand@uninett.no From: Ron Daniel Subject: Re: [URN] HTTP resolution protocol Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com I'm revising the "Conventions for the Use of HTTP for URN Resolution" draft that I sent to the list awhile back. Before I do so I wanted to ask the list about one point in Harald's last message on the subject. Thus spoke Harald.T.Alvestrand@uninett.no (at least at 02:44 PM 11/4/96 +0100) >(Warning: I'm coming into this without reading the entire debate...) > >I like the idea that HTTP GET is an URI to MIME object resolution >protocol. It either fails or returns a MIME object. > >But the scheme of service:/uri would IMHO require registering >N2L, N2Ls, N2C and so on as URI types; this sounds wrong to me. Agreed. > >If we want a resolution CONVENTION, it seems to me that the right >convention is "GET /resolve/N2L/" (mimicking a CGI-BIN script). >If we want a resolution STANDARD, it seems to me that the right >thing is "N2L HTTP/1.1" I tend to agree that a true resolution STANDARD should define the new HTTP Methods. However, I was shooting for a simple CONVENTION for people to follow. The primary goal was to make it easy to retrofit URN resolution onto existing web servers. That is the tack that I will continue to follow if there is not a massive outpouring of derision from the list. I will change Harald's suggestion from GET /resolve// to GET /uri-res// because an Alta Vista search turned up some instances of /resolve in existing URLs, but no instances of /uri-res. >For handing back lists of things, mimic the responses that were put >into HTTP/1.1 for content negotiation (putting up a header for thte >machine processible version and HTML for the human-readable version). Will do. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA21428 for urn-ietf-out; Tue, 12 Nov 1996 12:09:25 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA21423 for ; Tue, 12 Nov 1996 12:09:22 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02419 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 12:09:15 -0500 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16915(3)>; Tue, 12 Nov 1996 09:09:03 PST Received: by golden.parc.xerox.com id <2695>; Tue, 12 Nov 1996 09:08:44 PST To: FisherM@is3.indy.tce.com Cc: Dirk.vanGulik@jrc.it, girod@LCS.MIT.EDU, Harald.T.Alvestrand@uninett.no, mduerst@ifi.unizh.ch, moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <32888C2E@MSMAIL.INDY.TCE.COM> (message from Fisher Mark on Tue, 12 Nov 1996 06:37:00 PST) Subject: Re: [URN] I18N does not belong in URNs From: Larry Masinter Message-Id: <96Nov12.090844pst."2695"@golden.parc.xerox.com> Date: Tue, 12 Nov 1996 09:08:44 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com # If (as an example) a Chinese information provider wished to make # available their resources to English speakers as URNs, I would # suspect they would want to provide "English-compatible" URNs, # rather than long, seemingly random %XX-encoded strings. So the library of China should assign chinese URNs to the information they think only Chinese readers will want to read, and ASCII URNs to the texts they think might also be of interest to people who don't read Chinese? Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA21389 for urn-ietf-out; Tue, 12 Nov 1996 12:01:06 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA21384 for ; Tue, 12 Nov 1996 12:01:03 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02342 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 12:01:01 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id LAA17005; Tue, 12 Nov 1996 11:57:44 -0500 (EST) Message-Id: <199611121657.LAA17005@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Fisher Mark Cc: "Dirk.vanGulik" , "girod@LCS.MIT.EDU" , "Harald.T.Alvestrand@uninett.no" , "mduerst@ifi.unizh.ch" , "moore@cs.utk.edu" , "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Tue, 12 Nov 1996 09:37:00 EST." <32888C2E@MSMAIL.INDY.TCE.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 12 Nov 1996 11:57:43 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > >The reason for _not_ allowing any octet in the string after urn: is to > >avoid entering into the dark realm of having to retrive MIB like display > >strings whenever you encounter a URN you've not seen before; and which > >you would like to display to a human in such a way he/she can still > >transcribe it. Just showing a list of two digit hex numbers would not do. > > Realistically, how often should we expect a resource that we _can_ read to > be expressed by a URN that we can't read (i.e. the URN needs the %XX > encoding convention)? I would maintain that this would be the > unusual case. I disagree, for several reasons: 1. many resources don't require a particular language. 2. even if you can read the language, you might not be able to type in the characters on your keyboard. 3. machines are getting better at automatic language translation. it's entirely possible, perhaps likely, that in a few years your web browser will have plugins that let it translate from other languages to the one you read best. it might not be as good as being able to read the original language, but it will be good enough to understand most of what's being said. URNs are defined to have global scope. A name that is usable only by a Chinese speaker (or for that matter, an English speaker) isn't a URN. The reason you assign a URN to something is to make it usable by a potentially global audience for a potentially long time. (That doesn't mean that it's usable by anybody -- there can always be access controls-- but it does mean that who can use the resource isn't pre-determined when the name is assigned.) If you don't want your resource to be globally usable, don't give it a URN. Or conversely, if you want to prevent someone who doesn't speak your language from trying to read your resources, URNs aren't the right mechanism for doing this. > Otherwise, we might as well go with sequences of random digits. Yes, that's much closer to what URNs are (IMHO) supposed to be. It also has the advantage of being much easier to implement. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA21067 for urn-ietf-out; Tue, 12 Nov 1996 11:50:29 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA21061 for ; Tue, 12 Nov 1996 11:50:27 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02231 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 11:50:24 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id JAA08316; Tue, 12 Nov 1996 09:50:21 -0700 (MST) Message-Id: <2.2.32.19961112165834.006e96d4@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 12 Nov 1996 09:58:34 -0700 To: stu_weibel@oclc.org (Stu Weibel), urn-ietf@bunyip.com From: Ron Daniel Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Thus spoke Stu Weibel (at least at 01:56 PM 11/11/96 -0500) >I say again... >this WG should adopt the *least restrictive* solution that is technologically >sound and let people do with it what their communities choose. Amen. I recommend: 1) New namespace proposals get standards-track review (or at least come out as experimental RFCs). This will allow namespaces that are obviously bad to be weeded out. 2) We develop an informational RFC on recommended practices for namespaces. This can discuss the problems that arise with persistence for friendly names. Namespaces that want to allow friendly, persistent names can then look to this guide for the questions they will have to answer when their namespace proposal comes up for standards-track review. (Someone else suggested this earlier). Issues of allowed characters are essentially orthogonal to friendliness. We have the example of the Japanese bank account. We also have the example of things like Library of Congress call numbers, which contain a subset of the Latin letters, digits, and some punctuation. (LCCNs are probably not going to make a good URN namespace, but its not due to issues of friendliness). I'm not at all thrilled by proposals to restrict URNs to digits. That seems overly restrictive. The place to prevent crappy namespaces is when they come up for review, not (IMHO) trying to forestall their appearance by restricting the character set. This still leaves us with the ASCII-only vs. 10646-only vs. multiple charset positions. I'll take that up in another message. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA20848 for urn-ietf-out; Tue, 12 Nov 1996 11:42:41 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA20840 for ; Tue, 12 Nov 1996 11:42:32 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02088 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 11:42:28 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA09612; Tue, 12 Nov 96 17:47:29 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA05351; Tue, 12 Nov 1996 17:41:34 +0100 Date: Tue, 12 Nov 1996 17:41:34 +0100 From: "Dirk.vanGulik" Message-Id: <9611121641.AA05351@ jrc.it> To: Dirk.vanGulik@jrc.it, Harald.T.Alvestrand@uninett.no, jayhawk@ds.internic.net Subject: [URN] Re: Harald's syntax proposals [Somewhat Long] (was I18N does not belong in URNs) Cc: FisherM@is3.indy.tce.com, girod@LCS.MIT.EDU, mduerst@ifi.unizh.ch, moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Dirk.vanGulik" Errors-To: owner-urn-ietf@bunyip.com "Ryan Moats" wrote > On Tue, 12 Nov 1996 16:50:36 +0100, Dirk.vanGulik wrote: > > >> To me, the extension (as written) has a couple of holes. The URN has to have > >> information about the namespace so that the resolver can resolve the URN > >> correctly (it took me a while to realize that the proper parsing of option B is > >> the second ":"). Therefore, having no meaning after the optional "urn:" > >> doesn't work. > > > >I realized this as well; but was (and still am) unsure how to effectuate this; > >because is implies that the bit between the first to ':' is really limited in > >encoding. Something which has bothered me in the syntax document. But I have > >no immediate solution for it. > > This is on purpose. The more you free up the NID encoding, the more you restrict > potential implementations. > > >Well: (Which each char actualy being an octet, etc..) > > > > [<] urn:NS:OPS [>] > > > > NS consists of A..Z, 0..9 > > OPS consists of A..Z, 0..9, '-', '_' and '.' > > > > The '-','_','.' are kept in reserve for the NS > > > > Whitespace is allowed > > > >Would be kind of simple. > > Yes, and we may reach something like this eventually (there would > have to be more characters added to the NSS to support grandfathered > spaces. There are just some tradeoffs that we would have to agree upon. Well the whole point was to 'fudge' this grandfathering; and force (almost) all of it to use an encoding scheme of some kind; but naturally they _ONLY_ have to know about this encoding when they want to go in- or out- to the old grandfathered in scheme; and then quite naturally they know what the secret encoding trick is. One of the main points I would like to get across is that all this grand- fathering only matters on the interface between the grandfather and this new born URN daughter; and exactly on that interface there is all the room in the world to do say a base64 to XYZ decoding. > >> >A > >> >> - The URN syntax doc says that URNs are sequences of ASCII > >> >> characters (or some subset thereof) > >> > >> This is of course, the simplest. A minimum of transport encoding would be > >> involved. There may be some reserved characters that would be need to be > >> encoded on a namespace specific basis but those could be done with > >> %HH encoding. > > > >Which would imply namespace specific encapsulation needs; which kind of imposes > >external NS knowledge on arbritary clients. > > Somebody will have to know this anyway. I'm not saying that all the reserved characters > have to be in the syntax document (in fact I'm saying they can't). I'm saying that any > reserved character should be encoded with %HH, which is slightly different. Yes; and I woudl really like to argue that there should be NO encoding on this level at all; the syntax document should be entirely free of it. It might be that in a document which details how some kind of differnt scheme is grandfathered into a certain NS, one will have to detail all this; but that is completely outside the URN syntax document I hope. As a conclusion; I think we quite agree; but compared to you I would prefer the encoding to be pushed away further from the URN, and actually not be a part of it; whereas you would actually allow the URN to consist of arbitrary octets which are encoded with a limited set ? Or am I wrong again ? > >> >B > >> >> - The URN syntax doc says that URNs are sequences of OCTETS, > >> >> with no meaning assigned by the URN syntax doc after the > >> >> second ':' > >> > >> I've modified the above to point up the ':' character. This is the "opaque string" > >> option. This option would require some transport encoding for 8-bit unclean pipes. > >> I see presentation as the major trade-off here. For 8-bit unfriendly schemes, > >> something like the %HH scheme would be needed. For others, the %HH scheme > >> could be mixed with actual glyphs that are representation of that octet (or sequence > >> of octets) in that presentation scheme. However, THIS IS ONLY FOR THE > >> CONVIENCE OF THE PRESENTATION SCHEME, NOT THE USER!!!! > >> The other difficulty is that reserved characters have to be limited to > >> a subset of ASCII or there is the possibility for encoding collisions that would require > >> the syntax doc to specify its own encoding scheme. > >Somehow not very practical ? IMHO. > I didn't say it was practical, just tried to state what the tradeoffs are. Point taken. I was trying to state a point as well :-) Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA20237 for urn-ietf-out; Tue, 12 Nov 1996 11:19:24 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA20217 for ; Tue, 12 Nov 1996 11:19:09 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01726 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 11:19:03 -0500 Message-Id: <9611121619.AA01726@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Tue Nov 12 10:18 CST 1996 From: "Ryan Moats" To: "Dirk.vanGulik@jrc.it" , "Harald.T.Alvestrand@uninett.no" Cc: "FisherM@is3.indy.tce.com" , "girod@LCS.MIT.EDU" , "mduerst@ifi.unizh.ch" , "moore@cs.utk.edu" , "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Date: Tue, 12 Nov 96 10:19:43 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] Re: Harald's syntax proposals [Somewhat Long] (was I18N does not belong in URNs) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Tue, 12 Nov 1996 16:50:36 +0100, Dirk.vanGulik wrote: >> To me, the extension (as written) has a couple of holes. The URN has to have >> information about the namespace so that the resolver can resolve the URN >> correctly (it took me a while to realize that the proper parsing of option B is >> the second ":"). Therefore, having no meaning after the optional "urn:" >> doesn't work. > >I realized this as well; but was (and still am) unsure how to effectuate this; >because is implies that the bit between the first to ':' is really limited in >encoding. Something which has bothered me in the syntax document. But I have >no immediate solution for it. This is on purpose. The more you free up the NID encoding, the more you restrict potential implementations. >Well: (Which each char actualy being an octet, etc..) > > [<] urn:NS:OPS [>] > > NS consists of A..Z, 0..9 > OPS consists of A..Z, 0..9, '-', '_' and '.' > > The '-','_','.' are kept in reserve for the NS > > Whitespace is allowed > >Would be kind of simple. Yes, and we may reach something like this eventually (there would have to be more characters added to the NSS to support grandfathered spaces. There are just some tradeoffs that we would have to agree upon. >> >A >> >> - The URN syntax doc says that URNs are sequences of ASCII >> >> characters (or some subset thereof) >> >> This is of course, the simplest. A minimum of transport encoding would be >> involved. There may be some reserved characters that would be need to be >> encoded on a namespace specific basis but those could be done with >> %HH encoding. > >Which would imply namespace specific encapsulation needs; which kind of imposes >external NS knowledge on arbritary clients. Somebody will have to know this anyway. I'm not saying that all the reserved characters have to be in the syntax document (in fact I'm saying they can't). I'm saying that any reserved character should be encoded with %HH, which is slightly different. >> >B >> >> - The URN syntax doc says that URNs are sequences of OCTETS, >> >> with no meaning assigned by the URN syntax doc after the >> >> second ':' >> >> I've modified the above to point up the ':' character. This is the "opaque string" >> option. This option would require some transport encoding for 8-bit unclean pipes. >> I see presentation as the major trade-off here. For 8-bit unfriendly schemes, >> something like the %HH scheme would be needed. For others, the %HH scheme >> could be mixed with actual glyphs that are representation of that octet (or sequence >> of octets) in that presentation scheme. However, THIS IS ONLY FOR THE >> CONVIENCE OF THE PRESENTATION SCHEME, NOT THE USER!!!! >> The other difficulty is that reserved characters have to be limited to >> a subset of ASCII or there is the possibility for encoding collisions that would require >> the syntax doc to specify its own encoding scheme. >> > >Somehow not very practical ? IMHO. I didn't say it was practical, just tried to state what the tradeoffs are. Ryan P.S. Sorry folks, I think I was in such a hurry to send the last comment off that I didn't admit who wrote it. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA19931 for urn-ietf-out; Tue, 12 Nov 1996 10:52:18 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA19926 for ; Tue, 12 Nov 1996 10:52:14 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01325 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 10:51:56 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA08366; Tue, 12 Nov 96 16:56:56 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA05330; Tue, 12 Nov 1996 16:50:36 +0100 Date: Tue, 12 Nov 1996 16:50:36 +0100 From: "Dirk.vanGulik" Message-Id: <9611121550.AA05330@ jrc.it> To: Dirk.vanGulik@jrc.it, Harald.T.Alvestrand@uninett.no, jayhawk@ds.internic.net Subject: [URN] Re: Harald's syntax proposals [Somewhat Long] (was I18N does not belong in URNs) Cc: FisherM@is3.indy.tce.com, girod@LCS.MIT.EDU, mduerst@ifi.unizh.ch, moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Dirk.vanGulik" Errors-To: owner-urn-ietf@bunyip.com > To me, the extension (as written) has a couple of holes. The URN has to have > information about the namespace so that the resolver can resolve the URN > correctly (it took me a while to realize that the proper parsing of option B is > the second ":"). Therefore, having no meaning after the optional "urn:" > doesn't work. I realized this as well; but was (and still am) unsure how to effectuate this; because is implies that the bit between the first to ':' is really limited in encoding. Something which has bothered me in the syntax document. But I have no immediate solution for it. > The second hole is that while having an interpretation for a specific namespace > defined in a separate namespace document is reasonable (in fact I don't see > how to avoid it) defining general castings in external documents doesn't No, the MIB refernce was meant half in yest; and in fact I hope it will not come to this; i.e. that most generic clients using URNs will simply hardly ever show them to the user. However for very specialist (and also for practical reasons) people close to the data might like specific castings a lot; especialy when the keys in your mother database are easily derivable. But the rest of the world should not care; and the references in external document to the display encoding is really only there to satisfy the curiosity and the very specialist users of that NS. > strike me as a big win. I still believe we can keep the syntax doc reasonably > short while solving the small problem in front of us. Well: (Which each char actualy being an octet, etc..) [<] urn:NS:OPS [>] NS consists of A..Z, 0..9 OPS consists of A..Z, 0..9, '-', '_' and '.' The '-','_','.' are kept in reserve for the NS Whitespace is allowed Would be kind of simple. > This being said, if the holes are plugged up, option D could be a reasonable > alternative > > Now, back to Harald's proposals, I'll try to synopsize them with my thoughts > on the tradeoffs > > >A > >> - The URN syntax doc says that URNs are sequences of ASCII > >> characters (or some subset thereof) > > This is of course, the simplest. A minimum of transport encoding would be > involved. There may be some reserved characters that would be need to be > encoded on a namespace specific basis but those could be done with > %HH encoding. Which would imply namespace specific encapsulation needs; which kind of imposes external NS knowledge on arbritary clients. > >B > >> - The URN syntax doc says that URNs are sequences of OCTETS, > >> with no meaning assigned by the URN syntax doc after the > >> second ':' > > I've modified the above to point up the ':' character. This is the "opaque string" > option. This option would require some transport encoding for 8-bit unclean pipes. > I see presentation as the major trade-off here. For 8-bit unfriendly schemes, > something like the %HH scheme would be needed. For others, the %HH scheme > could be mixed with actual glyphs that are representation of that octet (or sequence > of octets) in that presentation scheme. However, THIS IS ONLY FOR THE > CONVIENCE OF THE PRESENTATION SCHEME, NOT THE USER!!!! > The other difficulty is that reserved characters have to be limited to > a subset of ASCII or there is the possibility for encoding collisions that would require > the syntax doc to specify its own encoding scheme. > Somehow not very practical ? IMHO. Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA19591 for urn-ietf-out; Tue, 12 Nov 1996 10:22:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA19586 for ; Tue, 12 Nov 1996 10:22:17 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01013 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 10:22:11 -0500 Message-Id: <9611121522.AA01013@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Tue Nov 12 09:21 CST 1996 From: "Ryan Moats" To: "Dirk.vanGulik@jrc.it" , "Harald.T.Alvestrand@uninett.no" Cc: "FisherM@is3.indy.tce.com" , "girod@LCS.MIT.EDU" , "mduerst@ifi.unizh.ch" , "moore@cs.utk.edu" , "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Date: Tue, 12 Nov 96 09:22:43 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] Re: Harald's syntax proposals [Somewhat Long] (was I18N does not belong in URNs) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Tue, 12 Nov 1996 14:09:34 +0100, Dirk.vanGulik wrote: >Harald wrote: >> There are about 3 alternatives I can see: > >A >> - The URN syntax doc says that URNs are sequences of ASCII >> characters (or some subset thereof) > >B >> - The URN syntax doc says that URNs are sequences of OCTETS, >> with no meaning assigned by the URN syntax doc after the >> second : > >C >> - The URN syntax doc says that URNs are sequences of CHARACTERS, >> drawn from the ISO 10646 set. > >> The tradeoffs are different for the 3 cases. > >To extend on this, IMHO very sensible, concept: as it gives room >to sensible wire definitions: > >D. Augmenting, case 'B'; > >The URN syntax docs says the URNs are sequences of >OCTETS, whose value comes from a specific range '*' with no meaning >assigned by the URN sysntax doc after the first four octets (which >are the indexes of the glyphs 'u','r','n' and ':' in charset-XYZ.) > >Where the range '*' is; when each octed is taken as in index into >charset-XYZ, is from the range (say) A-Z, 0-9, '_', '-', ":' and '.' > >I'd suggest ISO-8859, US-ASCII, NISO, etc for charset-XYZ. > >For each naming scheme an interpretation/casting can be defined for >the part of the URN after the name-scheme-identifier. > >For the 'inet' (or x-dns-2) name-schme; the suggested interpretation is >as indexes into 8 bit encoded 7bit ASCII (or ISO-8859-1 or whatever). > >Would that be of (some) use? > >The reason for _not_ allowing any octet in the string after urn: is to >avoid entering into the dark realm of having to retrive MIB like display >strings whenever you encounter a URN you've not seen before; and which >you would like to display to a human in such a way he/she can still >transcribe it. Just showing a list of two digit hex numbers would not do. > >Although overloading yet another DNS query type to get the display string >could be fun on the 'display-string'.name-scheme.urn.net level :-) > >Dw. To me, the extension (as written) has a couple of holes. The URN has to have information about the namespace so that the resolver can resolve the URN correctly (it took me a while to realize that the proper parsing of option B is the second ":"). Therefore, having no meaning after the optional "urn:" doesn't work. The second hole is that while having an interpretation for a specific namespace defined in a separate namespace document is reasonable (in fact I don't see how to avoid it) defining general castings in external documents doesn't strike me as a big win. I still believe we can keep the syntax doc reasonably short while solving the small problem in front of us. This being said, if the holes are plugged up, option D could be a reasonable alternative Now, back to Harald's proposals, I'll try to synopsize them with my thoughts on the tradeoffs >A >> - The URN syntax doc says that URNs are sequences of ASCII >> characters (or some subset thereof) This is of course, the simplest. A minimum of transport encoding would be involved. There may be some reserved characters that would be need to be encoded on a namespace specific basis but those could be done with %HH encoding. >B >> - The URN syntax doc says that URNs are sequences of OCTETS, >> with no meaning assigned by the URN syntax doc after the >> second ':' I've modified the above to point up the ':' character. This is the "opaque string" option. This option would require some transport encoding for 8-bit unclean pipes. I see presentation as the major trade-off here. For 8-bit unfriendly schemes, something like the %HH scheme would be needed. For others, the %HH scheme could be mixed with actual glyphs that are representation of that octet (or sequence of octets) in that presentation scheme. However, THIS IS ONLY FOR THE CONVIENCE OF THE PRESENTATION SCHEME, NOT THE USER!!!! The other difficulty is that reserved characters have to be limited to a subset of ASCII or there is the possibility for encoding collisions that would require the syntax doc to specify its own encoding scheme. >C >> - The URN syntax doc says that URNs are sequences of CHARACTERS, >> drawn from the ISO 10646 set. > >> The tradeoffs are different for the 3 cases. This last one has most of the issues above. There are probably others that I haven't thought of, mainly because I don't claim to be an expert in the ins and outs of 7-bit and 8-bit friendliness. Having synopsized the plusses and minuses of these, there are some common issues: If we restrict the range of octets for the NSS (this is option A and option D) then a lot of the trasnport encoding, reserved character encoding and related issues go away. If we allow any octet (option B and C) then transport encoding becomes a minor issue and reserved character encoding must be considered. Everything else (to me right now at least) is related to presentation and meta-interpretation (by humans) of the NSS. I'm not sure if these should intrude into the syntax doc. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA19325 for urn-ietf-out; Tue, 12 Nov 1996 09:50:05 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA19320 for ; Tue, 12 Nov 1996 09:50:03 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00786 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 09:49:55 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA06815; Tue, 12 Nov 96 15:54:58 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA05259; Tue, 12 Nov 1996 15:49:40 +0100 Date: Tue, 12 Nov 1996 15:49:40 +0100 From: "Dirk.vanGulik" Message-Id: <9611121449.AA05259@ jrc.it> To: Dirk.vanGulik@jrc.it, FisherM@is3.indy.tce.com Subject: Re: [URN] I18N does not belong in URNs Cc: urn-ietf@bunyip.com X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Dirk.vanGulik" Errors-To: owner-urn-ietf@bunyip.com > >The reason for _not_ allowing any octet in the string after urn: is to > >avoid entering into the dark realm of having to retrive MIB like display > >strings whenever you encounter a URN you've not seen before; and which > >you would like to display to a human in such a way he/she can still > >transcribe it. Just showing a list of two digit hex numbers would not do. > Realistically, how often should we expect a resource that we _can_ read to > be expressed by a URN that we can't read (i.e. the URN needs the %XX > encoding convention)? I would maintain that this would be the unusual case. > If (as an example) a Chinese information provider wished to make available > their resources to English speakers as URNs, I would suspect they would want > to provide "English-compatible" URNs, rather than long, seemingly random > %XX-encoded strings. Conversely (and for example), an Austrailian > information provider that wants to market their information to native Arabic > speakers (who are not necessarily English speakers) would want to provide > their URNs in an "Arabic-compatible" form, rather than the foreign-looking > English alphabet. Well, that would be an expectation of something which resembles 'URL's on steroids; my, personal, take on this is a bit different. We are seeing all sorts of collections being opened up; each with some kind of local identifier or control number; often closely tied to the language and habits of the -original- maintainers. A lot of the 'objects' in these collections have different views, depending on who you are, what you have paid, what your preferences and access permisisons are. So quite quickly you end up with the identifier of say a Technical Maintenance document of a, say, phillips KT52 TV frame or a the left wing SPL bolt installation a manual of a MD123 aeroplane. Which just happens to be avaible in quite a few languages. Although for the original maintainers there might be a language in which the local control identifier beared some relevance, but for most users that relation is gone (and it was based on obsuce 8 char abbreviattions anyway). > Although I would expect content-negotiation to be used on URNs, if the URN > resource is to be used widely by the native speaker of a language, it would > be better expressed in a form compatible with their native language. Yes; that is a common human desire; worth allowing for. Which means some kind of transcription of a reasonable number of languages and charset. Which still are compatible with all others. Hence my simplified (and optional) Base64 kind of encoding for name-schemes which need this. > Otherwise, we might as well go with sequences of random digits. Well; that is certainly what they conceptually could be to an 'alien' from Mars; or a native japanese only speaker. And there is nothign wrong with that. Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA19157 for urn-ietf-out; Tue, 12 Nov 1996 09:39:38 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA19152 for ; Tue, 12 Nov 1996 09:39:35 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00713 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 09:39:33 -0500 Received: by seawall with (8.6.12/) id JAA07356; Tue, 12 Nov 1996 09:39:27 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma007344; Tue Nov 12 09:39:09 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <32888C2E@MSMAIL.INDY.TCE.COM>; Tue, 12 Nov 96 09:39:42 EST From: Fisher Mark To: "Dirk.vanGulik" Cc: "girod@LCS.MIT.EDU" , "Harald.T.Alvestrand@uninett.no" , "mduerst@ifi.unizh.ch" , "moore@cs.utk.edu" , "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Subject: Re: [URN] I18N does not belong in URNs Date: Tue, 12 Nov 96 09:37:00 EST Message-Id: <32888C2E@MSMAIL.INDY.TCE.COM> Encoding: 26 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com >The reason for _not_ allowing any octet in the string after urn: is to >avoid entering into the dark realm of having to retrive MIB like display >strings whenever you encounter a URN you've not seen before; and which >you would like to display to a human in such a way he/she can still >transcribe it. Just showing a list of two digit hex numbers would not do. Realistically, how often should we expect a resource that we _can_ read to be expressed by a URN that we can't read (i.e. the URN needs the %XX encoding convention)? I would maintain that this would be the unusual case. If (as an example) a Chinese information provider wished to make available their resources to English speakers as URNs, I would suspect they would want to provide "English-compatible" URNs, rather than long, seemingly random %XX-encoded strings. Conversely (and for example), an Austrailian information provider that wants to market their information to native Arabic speakers (who are not necessarily English speakers) would want to provide their URNs in an "Arabic-compatible" form, rather than the foreign-looking English alphabet. Although I would expect content-negotiation to be used on URNs, if the URN resource is to be used widely by the native speaker of a language, it would be better expressed in a form compatible with their native language. Otherwise, we might as well go with sequences of random digits. ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA18370 for urn-ietf-out; Tue, 12 Nov 1996 08:12:35 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA18365 for ; Tue, 12 Nov 1996 08:12:32 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00226 (mail destined for urn-ietf@services.bunyip.com); Tue, 12 Nov 96 08:12:28 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA03848; Tue, 12 Nov 96 14:17:28 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA05166; Tue, 12 Nov 1996 14:09:34 +0100 Date: Tue, 12 Nov 1996 14:09:34 +0100 From: "Dirk.vanGulik" Message-Id: <9611121309.AA05166@ jrc.it> To: Dirk.vanGulik@jrc.it, Harald.T.Alvestrand@uninett.no Subject: Re: [URN] I18N does not belong in URNs Cc: FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, mduerst@ifi.unizh.ch, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Dirk.vanGulik" Errors-To: owner-urn-ietf@bunyip.com Harald wrote: > There are about 3 alternatives I can see: A > - The URN syntax doc says that URNs are sequences of ASCII > characters (or some subset thereof) B > - The URN syntax doc says that URNs are sequences of OCTETS, > with no meaning assigned by the URN syntax doc after the > second : C > - The URN syntax doc says that URNs are sequences of CHARACTERS, > drawn from the ISO 10646 set. > The tradeoffs are different for the 3 cases. To extend on this, IMHO very sensible, concept: as it gives room to sensible wire definitions: D. Augmenting, case 'B'; The URN syntax docs says the URNs are sequences of OCTETS, whose value comes from a specific range '*' with no meaning assigned by the URN sysntax doc after the first four octets (which are the indexes of the glyphs 'u','r','n' and ':' in charset-XYZ.) Where the range '*' is; when each octed is taken as in index into charset-XYZ, is from the range (say) A-Z, 0-9, '_', '-', ":' and '.' I'd suggest ISO-8859, US-ASCII, NISO, etc for charset-XYZ. For each naming scheme an interpretation/casting can be defined for the part of the URN after the name-scheme-identifier. For the 'inet' (or x-dns-2) name-schme; the suggested interpretation is as indexes into 8 bit encoded 7bit ASCII (or ISO-8859-1 or whatever). Would that be of (some) use? The reason for _not_ allowing any octet in the string after urn: is to avoid entering into the dark realm of having to retrive MIB like display strings whenever you encounter a URN you've not seen before; and which you would like to display to a human in such a way he/she can still transcribe it. Just showing a list of two digit hex numbers would not do. Although overloading yet another DNS query type to get the display string could be fun on the 'display-string'.name-scheme.urn.net level :-) Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA14044 for urn-ietf-out; Mon, 11 Nov 1996 22:54:59 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA14039 for ; Mon, 11 Nov 1996 22:54:55 -0500 Received: from docker.library.uwa.edu.au by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27904 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 22:54:50 -0500 Received: from dehquhp.library.uwa.edu.au (dehquhp.library.uwa.edu.au [130.95.106.230]) by docker.library.uwa.edu.au (8.8.0/8.8.0) with ESMTP id LAA00225; Tue, 12 Nov 1996 11:54:27 +0800 (WST) Message-Id: <199611120354.LAA00225@docker.library.uwa.edu.au> From: "James K. Tauber" To: "David G. Durand" , Subject: Re: [URN] Readable Names (was: I18N does not belong in URNs) Date: Tue, 12 Nov 1996 11:55:20 +0800 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "James K. Tauber" Errors-To: owner-urn-ietf@bunyip.com > I think James Tauber (of Sun?) already has an FPI resolution > prototype operating. Formerly of Sun. Now back at the University of Western Australia. The fact that SP supports FPI resolution means that we now have a robust (human readable) namespace that is widely deployed, has a registration procedure (that's also widely deployed if you count ISBN owner identifiers) AND is resolvable here and now. James -- James K. Tauber / jtauber@library.uwa.edu.au University CWIS Coordination Officer The University of Western Australia Room 2.42, Scholars' Centre, Reid Library Phone: +61 9 380 7136 FAX: +61 9 380 1128 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA13396 for urn-ietf-out; Mon, 11 Nov 1996 21:49:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA13391 for ; Mon, 11 Nov 1996 21:49:18 -0500 Received: from CS.BU.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27663 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 21:49:17 -0500 Received: by cs.bu.edu (8.6.10/Spike-2.1) id VAA29804; Mon, 11 Nov 1996 21:49:11 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Nov 1996 21:54:29 -0500 To: urn-ietf@bunyip.com From: dgd@cs.bu.edu (David G. Durand) Subject: [URN] Readable Names (was: I18N does not belong in URNs) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: dgd@cs.bu.edu (David G. Durand) Errors-To: owner-urn-ietf@bunyip.com >Jim, > >URNs aren't supposed to be human-meaningful. Making them human-meaningful >defeats the purpose of having them be long-term stable. > >Keith Please, stop saying this. Repeating the same thing over and over again does not make it true. Read ISO 9070, or any book on SGML, for an example, of a namespace that falsifies your claim. You may prefer another style of URN, and no one will stop you from doing so, but the repeated _false_ assertion that such a namespace cannot exist is annoying. The fact that there is a namespace already deployed with reasonable social mechanisms to guarantee uniqueness and persistence is what really bugs me about this repeated assertion. The argument that typing the meaningful ASCII-subset string in FPIs as a hex-encoded byte sequence will improve reliability falls on its own merits, as far as I can see. I think James Tauber (of Sun?) already has an FPI resolution prototype operating. You have shown one thing in your previous arguments: that long-term persistence may impair long-term human-friendliness. Since this problem is as old as recorded history (Cuneiform was reader-friendly, once), I'm neither excited, surprised, or worried, about it. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA10935 for urn-ietf-out; Mon, 11 Nov 1996 16:48:51 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA10930 for ; Mon, 11 Nov 1996 16:48:32 -0500 Received: from aun.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26249 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 16:48:30 -0500 Received: from dale.uninett.no (actually trhm1.or.uninett.no) by aun.uninett.no with SMTP (PP); Mon, 11 Nov 1996 22:48:14 +0100 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id SAA25176; Mon, 11 Nov 1996 18:40:44 +0100 From: Harald.T.Alvestrand@uninett.no To: "Dirk.vanGulik" Cc: FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, mduerst@ifi.unizh.ch, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Mon, 11 Nov 1996 14:13:30 +0100." <9611111313.AA04245@ jrc.it> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <25172.847734044.1@dale.uninett.no> Date: Mon, 11 Nov 1996 18:40:44 +0100 Message-Id: <25174.847734044@dale.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com There are about 3 alternatives I can see: - The URN syntax doc says that URNs are sequences of ASCII characters (or some subset thereof) - The URN syntax doc says that URNs are sequences of OCTETS, with no meaning assigned by the URN syntax doc after the second : - The URN syntax doc says that URNs are sequences of CHARACTERS, drawn from the ISO 10646 set. The tradeoffs are different for the 3 cases. Harald Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA10902 for urn-ietf-out; Mon, 11 Nov 1996 16:47:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA10897 for ; Mon, 11 Nov 1996 16:47:18 -0500 Received: from info.cren.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26243 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 16:47:14 -0500 Received: from [192.52.179.12] (conklin-180c.cren.net [192.52.179.12]) by info.cren.net (8.6.6/8.6.4 (CREN)) with SMTP id QAA10245; Mon, 11 Nov 1996 16:45:17 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Nov 1996 16:46:28 -0500 To: Keith Moore , urn-ietf@bunyip.com From: conklin@info.cren.net (Jim Conklin) Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: conklin@info.cren.net (Jim Conklin) Errors-To: owner-urn-ietf@bunyip.com At 1:05 PM 11/11/96, Keith Moore wrote: >Jim, > >URNs aren't supposed to be human-meaningful. Making them human-meaningful >defeats the purpose of having them be long-term stable. > >Keith Keith, It may be just my slowness, but you haven't convinced me of that yet. Jim Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA09890 for urn-ietf-out; Mon, 11 Nov 1996 15:24:32 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA09885 for ; Mon, 11 Nov 1996 15:24:28 -0500 Received: from fssun10.dev.oclc.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25687 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 15:24:20 -0500 Received: from orc.NISOR (orc.dev.oclc.org) by oclc.org (4.1/SMI-4.1) id AA00924; Mon, 11 Nov 96 13:55:10 EST Received: by orc.NISOR (SMI-8.6/SMI-SVR4) id NAA20145; Mon, 11 Nov 1996 13:56:14 -0500 Date: Mon, 11 Nov 1996 13:56:14 -0500 From: stu_weibel@oclc.org (Stu Weibel) Message-Id: <199611111856.NAA20145@orc.NISOR> To: urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: stu_weibel@oclc.org (Stu Weibel) Errors-To: owner-urn-ietf@bunyip.com > From owner-urn-ietf@bunyip.com Mon Nov 11 13:22:32 1996 > Errors-To: owner-urn-ietf@bunyip.com > Errors-To: owner-urn-ietf@bunyip.com Keith Moore writes: > URNs aren't supposed to be human-meaningful. Making them human-meaningful > defeats the purpose of having them be long-term stable. This reflects a philosophy, an attitude, a point of view that is NOT shared in anything like a consensus in this group. I say again... this WG should adopt the *least restrictive* solution that is technologically sound and let people do with it what their communities choose. This group has no business enforcing naming philosophy on the applications or systems that will deploy URN solutions. stu Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA08599 for urn-ietf-out; Mon, 11 Nov 1996 13:11:01 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA08594 for ; Mon, 11 Nov 1996 13:10:58 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24677 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 13:10:54 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id NAA16172; Mon, 11 Nov 1996 13:05:41 -0500 (EST) Message-Id: <199611111805.NAA16172@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: conklin@info.cren.net (Jim Conklin) Cc: "Dirk.vanGulik" , FisherM@is3.indy.tce.com, moore@cs.utk.edu, girod@LCS.MIT.EDU, mduerst@ifi.unizh.ch, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Mon, 11 Nov 1996 11:59:15 EST." Date: Mon, 11 Nov 1996 13:05:41 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com Jim, URNs aren't supposed to be human-meaningful. Making them human-meaningful defeats the purpose of having them be long-term stable. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA08035 for urn-ietf-out; Mon, 11 Nov 1996 12:01:30 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA08028 for ; Mon, 11 Nov 1996 12:01:22 -0500 Received: from info.cren.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24143 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 12:01:18 -0500 Received: from [192.52.179.12] (conklin-180c.cren.net [192.52.179.12]) by info.cren.net (8.6.6/8.6.4 (CREN)) with SMTP id LAA09181; Mon, 11 Nov 1996 11:58:19 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Nov 1996 11:59:15 -0500 To: "Dirk.vanGulik" , FisherM@is3.indy.tce.com, moore@cs.utk.edu From: conklin@info.cren.net (Jim Conklin) Subject: Re: [URN] I18N does not belong in URNs Cc: girod@LCS.MIT.EDU, mduerst@ifi.unizh.ch, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: conklin@info.cren.net (Jim Conklin) Errors-To: owner-urn-ietf@bunyip.com.I've.been.trying.to.decide.how.one.might.allow.human-meaningful.URNs.for multiple languages and encodings, and it seems to me that this would be possible if and only if the URN identifier itself includes character-set information. Would it make sense to include in the definition of the URN format (yes, I know, this is past history!) an optional language and encoding specification which could then be used by sufficiently intelligent clients to display the URN in the specified language using the specified character encoding? Even the language and encoding could, in that way, be rendered in the specified language and, with a (relatively) small number of predefined languages and encodings, those could be specified in a small, universal symbol set, since they'd normally not be seen by the end user with a smart client. Jim Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA05578 for urn-ietf-out; Mon, 11 Nov 1996 08:14:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA05564 for ; Mon, 11 Nov 1996 08:14:24 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22095 (mail destined for urn-ietf@services.bunyip.com); Mon, 11 Nov 96 08:14:15 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA14174; Mon, 11 Nov 96 14:19:03 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA04245; Mon, 11 Nov 1996 14:13:30 +0100 Date: Mon, 11 Nov 1996 14:13:30 +0100 From: "Dirk.vanGulik" Message-Id: <9611111313.AA04245@ jrc.it> To: FisherM@is3.indy.tce.com, moore@cs.utk.edu Subject: Re: [URN] I18N does not belong in URNs Cc: girod@LCS.MIT.EDU, mduerst@ifi.unizh.ch, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Dirk.vanGulik" Errors-To: owner-urn-ietf@bunyip.com > > > So, I see only 2 basic directions URN identifiers can go: > > > > 1) Totally opaque, random numeric strings; or > > > > 2) I18N character strings with appropriate encoding, > > preferably (IMHO) as UTF-8. > > > > There really is no middle ground -- if there is a pattern there, people will > > make use of it and screw up the system. > > As an example that there *is* middle ground, I suggest: > > 3) URNs are assigned by the "system" without regard to the content > that they name. (in other words, totally opaque, but not restricted to > numerals) > > This way, they can be composed of a larger character set without being > human meaningful. > > We can't restrict character sets too much because of the need to > grandfather existing URN spaces. > Or they use a naming scheme dependent interpretation. You could for example simply limit the representation of the URN to the glyphs A-Z, 0-9 and say the dot, dash, and colon. I recently came across a specific scheme, say 'crdis' which has a lot of LocalControlIdentfiers which can (only be fully) expressed in 2-byte octets. This obviously gave problems as some of our z39.50 servers and HTTP/URN resolving code did not quite like this. A pragmatic solution was to simply base64 encode the identfication string. A specialist GUI could now base64-decode the string to arrive at something meaningfull for a human. But it does not have to. And it does keep things simple. I really would like to roll up the charset discussion; I agree that for a lot of scheme's, in particular those to be grandfathered in, one will need very flexible encodings. But the internet transfer mechanisms are not quite up to that yet. So I would suggest: 1. Limit the URNs to just a few chars (along the lines of DNS) This also makes comparing URNs easy. 2. Allow, or perhaps even force, each registered naming scheme to suggest a possible encoding/escape sequencing to derive nice human names from the URN. This can be used by the more advanced GUIs. 3. And keep a few chars (say the %) in stock, for the future. 4. And remember, one can always make something like a next generation URN+:das:asd which can only be transcribed properly using say UTF8. or has its own charset/encoding/language triple. I know that such an encoding essentially wastes space; but that is a tradeoff I am willing to make for simplfied storage, encoding and comparing. Just my twohundred lires worth. Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA09891 for urn-ietf-out; Fri, 8 Nov 1996 09:26:29 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA09886 for ; Fri, 8 Nov 1996 09:26:27 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04842 (mail destined for urn-ietf@services.bunyip.com); Fri, 8 Nov 96 09:26:25 -0500 Message-Id: <9611081426.AA04842@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Fri Nov 8 08:24 CST 1996 From: "Ryan Moats" To: "Martin J Duerst" Cc: "moore@cs.utk.edu" , "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Date: Fri, 08 Nov 96 08:26:17 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] Almost an encoding agreement?! (was: I18N does not belong in Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Fri, 8 Nov 1996 15:18:59 +0100 (MET), Martin J Duerst wrote: >Ryan Moats wrote: > >>This look very similar to what is in the syntax draft now, with one exception >>(i.e. I like it but I see one "small" problem) >> >>If you go down this path, you need to ensure that if the namespace uses >>some octet in a reserved fasion, the character corresponding to the octet >>in ASCII would need to be %XX escaped when used in a literal sense. >>Further, unless you want real problems, we need to restrict the set of >>reserved characters to printable ASCII (minus some exceptions that get >>escaped already). > >We have been speaking about escaping characters before. Now you >speak about escaping octets. For ASCII, this may be the same, >but for UTF-8, it isn't. Oops, it looks like this was sloppy wording/thinking on my part... Octet == character above, but I got momentarily confused (so what else is new?) Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA09827 for urn-ietf-out; Fri, 8 Nov 1996 09:21:52 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA09822 for ; Fri, 8 Nov 1996 09:21:50 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04802 (mail destined for urn-ietf@services.bunyip.com); Fri, 8 Nov 96 09:21:28 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01030-0@josef.ifi.unizh.ch>; Fri, 8 Nov 1996 15:19:01 +0100 Subject: Re: [URN] Almost an encoding agreement?! (was: I18N does not belong in To: jayhawk@ds.internic.net Date: Fri, 8 Nov 1996 15:18:59 +0100 (MET) Cc: moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <9611072150.AA26126@mocha.bunyip.com> from "Ryan Moats" at Nov 7, 96 03:50:23 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1049 From: Martin J Duerst Message-Id: <"josef.ifi..836:08.10.96.14.19.09"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ryan Moats wrote: >This look very similar to what is in the syntax draft now, with one exception >(i.e. I like it but I see one "small" problem) > >If you go down this path, you need to ensure that if the namespace uses >some octet in a reserved fasion, the character corresponding to the octet >in ASCII would need to be %XX escaped when used in a literal sense. >Further, unless you want real problems, we need to restrict the set of >reserved characters to printable ASCII (minus some exceptions that get >escaped already). We have been speaking about escaping characters before. Now you speak about escaping octets. For ASCII, this may be the same, but for UTF-8, it isn't. Anyway, I guess it is okay to restrict reserved characters to an ASCII subset plus those characters that don't appear in the namespace in question and therefore don't have to be escaped. As an example for the later, "-" might be called a reserved character for ISBNs, but there is no need to escape it, because it doesn't appear in the ISBN proper. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA09100 for urn-ietf-out; Fri, 8 Nov 1996 08:22:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA09095 for ; Fri, 8 Nov 1996 08:22:12 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04531 (mail destined for urn-ietf@services.bunyip.com); Fri, 8 Nov 96 08:22:06 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00933-0@josef.ifi.unizh.ch>; Fri, 8 Nov 1996 14:20:17 +0100 Subject: Re: [URN] I18N does not belong in URNs To: moore@cs.utk.edu Date: Fri, 8 Nov 1996 14:20:16 +0100 (MET) Cc: tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611072109.QAA20758@ig.cs.utk.edu> from "Keith Moore" at Nov 7, 96 04:09:28 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5560 From: Martin J Duerst Message-Id: <"josef.ifi..453:08.10.96.13.20.21"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore wrote: >> >> So for grandfathering, we have two choices. >> >> >> >> 1) We interpret it as "direct grandfathering of characters", >> >> in which case we have to allow a really wide range >> >> of characters (i.e. ISO 10646). >> >> 2) We interpret it as "indirect grandfathering", in which >> >> case the digits, or whatever small set, will be >> >> enough. >> > >> >I suspect there will be some of each. >> >> I wouldn't mind "some of each", if this means "about the same >> amount for everybody on the world". If it comes to mean "a lot >> for English-speaking, but very little for the rest of the world", >> I would have to strongly disagree. > >Martin, > >Please accept that I agree with you here. I don't want Internet >information access protocols to be significantly biased in favor of >English speakers (or anybody else). > >I say "please accept" because if you accept that we substantially >agree on the above, it's a lot easier to understand the rest of what >I'm saying. I have no problems if you agree, of course :-). I just wanted to make sure that there was no misunderstanding. As for the rest of your mail, I agree to much of it. I am indifferent on the point of meaningfulness, but I leave the decision on that to those that care about it either way. >> You may agree with the above point, or you may disagree. But >> either way, ASCII only is unfair. If you think that naming >> schemes, protocols, standards, some review board, or whatever, >> can assure that no meaningful stuff is created, then there >> is no reason to restrict to ASCII. > >The working group needs to decide which is more important -- being >able to grandfather in existing URN-like name spaces from everywhere >on the planet, or having all URNs be transcribable by anyone on the >planet. I could certainly make a case for a subset of ASCII-only >based on the latter consideration. As I said, I would be ready to accept that, if it is a tight restriction of ASCII. The most of letters I would probably be ready to accept is A-F if we are going Hex. Of course, I would prefer it, for the benefit of everyone, if direct grandfathering would be choosen. >Perhaps the right thing to do is to define a mapping to be used when >grandfathering existing non-ASCII namespaces to URNs, i.e. to encode >the non-ASCII characters as UTF-8 and then encode each octet not >printable in ASCII using %XX notation. That way, people could still >type in resource names like they're accustomed to doing, but the >program they type them in to would convert them to canonical URN >format (by prepending URN:namespace: and doing the UTF-8 and %XX >encoding). For purposes of resolution, URNs would always be >transmitted in canonical format, but programs could decode the %XX and >UTF-8 for the purposes of display to humans. "always transmitted in canonical format" is a bit frightening, because it can make URNs unduely long in some cases. But in principle, I agree, and as Ryan has said, your proposal is just about the same as what the syntaxt draft currently says. >There's probably more than one organization in the world named ICRC. >The one your brother works for got ICRC.COM first, but the name is >still ambiguous. You could have as easily found the a different ICRC >than the one you were looking for. It's icrc.ORG. It is a true organization, not a company. Its name and especially its "logo", the red cross, are protected by special international treaties. It may be less known in the more peaceful regions of the world, though. Anyway, there was a chance that I would hit something else. But if I estimate that the chance is lower than 10%, and that it takes me 10 times more time to go through a search service, I will take the bet easily. For 10 things I look at, I will spend 20 time units that way. If I start with a search service just because I *might* be wrong, I will spend 100 time units for 10 lookups. >> If it can be that human-friendly, and that unambiguous, I don't know why >> I should go to a search service to find the ICRC. And I don't know >> why people that use other scripts should go though a serach service, >> while English speaking users don't have to do so. > >All names are unambiguous only within a limited context. When the net >was small, the context was inherently limited, so it didn't cause a >problem to have only one host for any given name. But now that the >net is much larger, it is a big problem. > >The whole huge mess over ownership of domain names, the InterNIC's >capriciousness in deciding who gets what domain within .COM, and all >of the hair-brained proposals to add tons of vanity-plate top-level >domains -- ALL of this is caused by the lack of support for >human-friendly names in the Internet infrastructure, and the resulting >misuse of DNS to do a job it wasn't designed to do. We're not going >to misuse URNs in the same way. I don't want URNs to be misused that way. But I, and many others, want something that can be used that way, without having to go through a search service when I see something on a cardboard box. >> No, but English can be used in URLs, and I get an unambigous >> result if there is one, in due time. In Japanese, even if the >> result would be unambiguous, I currently can't get it fast and >> easily. > >Which is better - an ambiguous result which is usually correct, or an >unambiguous result which is often incorrect? An unambiguous result which is often correct. This is what we have now. And I have made the calculations above. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA07587 for urn-ietf-out; Fri, 8 Nov 1996 04:10:27 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA07582 for ; Fri, 8 Nov 1996 04:10:25 -0500 From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03277 (mail destined for urn-ietf@services.bunyip.com); Fri, 8 Nov 96 04:10:19 -0500 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <03924-0@domen.uninett.no>; Fri, 8 Nov 1996 10:08:35 +0100 X-Mailer: exmh version 1.6.7 5/3/96 To: Daniel LaLiberte Cc: leslie@bunyip.com (Leslie Daigle), "Karen R. Sollins" , urn-ietf@bunyip.com Subject: Re: [URN] some comments In-Reply-To: Your message of "Thu, 07 Nov 1996 09:18:17 CST." <199611071518.JAA05599@ncsa.uiuc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Nov 1996 10:08:31 +0100 Message-Id: <3920.847444111@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com liberte@ncsa.uiuc.edu said: > Had I known we were going to be held to the details of the charter, I > would have spoken up at that time. But, honestly, would it have > mattered? You would certainly have gotten feedback, which might have led you to not bringing up this question now. I don't know if the charter would have changed. liberte@ncsa.uiuc.edu said: > But my whole point is that *because* the supposed difference between > URLs and URNs (the identifiers, not the resolution mechanisms) does > not exist, it is irrelevant to creating a solution, except for syntax > and other arbitrary constraints. The status quo is that unless the URN WG is able to do something about it, URLs are all that exist, and people will do what they have to do with them. So if you're right, you win by default. liberte@ncsa.uiuc.edu said: > >One of the things that we have to do, unfortunately, to get a > >solution to that limited problem, is to ask those who want to work on > >a different problem to leave. > So it has come to that, eh? As I've stated, we'll continue the > discussion off-line. But are you saying we shouldn't bother? No reason to go off-line; I suggest the former URI WG's list as a nice place to discuss the meta-issue of whether URNs are the right thing or not. If, in some other forum, the participants in this forum agree that what they are doing here won't work - fine; I'm sure I'll hear about it. But here - we are discussing how to make them work, and discussions on whether they are the right thing or not are not appropriate. liberte@ncsa.uiuc.edu said: > You should know that many experiments turn into standard practice. > If you want it to really be "just an experiment", perhaps you should > consider finding a way to kill it off afterwards so it doesn't escape > from the lab. :-) In the case of NAPTR, there's a simple way: Remove the urn.net domain from the root nameservers :-) But if it becomes standard practice, the experiment kind of succeeded, didn't it? Harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id DAA07499 for urn-ietf-out; Fri, 8 Nov 1996 03:49:18 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id DAA07494 for ; Fri, 8 Nov 1996 03:49:15 -0500 From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03184 (mail destined for urn-ietf@services.bunyip.com); Fri, 8 Nov 96 03:49:13 -0500 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <03364-0@domen.uninett.no>; Fri, 8 Nov 1996 09:46:58 +0100 X-Mailer: exmh version 1.6.7 5/3/96 To: Bob Briscoe Cc: Fisher Mark , "urn-ietf@bunyip.com" Subject: Re: [URN] Persistence as part of URN framework In-Reply-To: Your message of "Wed, 06 Nov 1996 17:39:57 GMT." <2.2.32.19961106173957.009f6a14@sherekhan.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 08 Nov 1996 09:46:46 +0100 Message-Id: <3361.847442806@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com OK - I see what you mean. Five roles, all different: - URN assigner (guarantees uniqueness of URNs) - URN buyer (gets an URN to apply to his work) - URN referer (puts references to others' work using URN) - URN user (clicks on the URN reference) - URN resolver (makes magic happen for the URN user) The assigner and the buyer have to have some agreement; if the buyer assigns his own URL, the agreement should be easy :-) The resolver may be the assigner, or someone the assigner has an agreement with, or it may be someone (reference.com? archive.org? oclc?) that does the resolution without bothering to ask anyone about it. What you're looking for is some kind of "minimum guarantee" from the assigner/buyer to the referer about the quality of resolution services that will be present in the future. Right? Harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA04318 for urn-ietf-out; Thu, 7 Nov 1996 18:41:04 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA04313 for ; Thu, 7 Nov 1996 18:40:58 -0500 Received: from trapdoor.dstc.edu.au by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00245 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 18:40:54 -0500 Received: from fatcat.dstc.edu.au (fatcat.dstc.edu.au [130.102.176.7]) by trapdoor.dstc.edu.au (8.6.9/8.6.12) with ESMTP id JAA09556; Fri, 8 Nov 1996 09:40:51 +1000 Received: (from renato@localhost) by fatcat.dstc.edu.au (8.6.10/8.6.12) id JAA26466; Fri, 8 Nov 1996 09:40:51 +1000 From: Renato Iannella Message-Id: <199611072340.JAA26466@fatcat.dstc.edu.au> Date: Fri, 8 Nov 1996 09:40:50 +1000 (EST) To: rbriscoe@jungle.bt.co.uk Cc: urn-ietf@bunyip.com Subject: Re[4]: [URN] Resolution Services (N2L etc) In-Reply-To: <2.2.32.19961107093626.006c2f7c@sherekhan.jungle.bt.co.uk> X-Mailer: Ishmail 1.3-960829-osf1 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Renato Iannella Errors-To: owner-urn-ietf@bunyip.com Bob Briscoe wrote: > > So now, the URN resolution service is doing authentication of metadata too! You seem to have made the assumption that a URC is a big massive set of metadata (authenticated, secure etc) when in reality, a URC can be whatever _your_ organisation decides (ie BT = Happy) The URN stuff will support its resolution - the client will then do all the hard work. > > What I was complaining about is the apparent assumption that the same URN > would be used for both URN and URC and one would have to say N2C if you > wanted the former, and N2L for the latter. If you have a URC - which only has a URL in it - then doing either N2C or N2L will return that single URL. This will enable you to have a URN pointing directly to the resource (albeit, via a small URC), then a trusted-third party can provide the full descriptions etc... Cheers... Renato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dr Renato Iannella http://www.dstc.edu.au/RDU/staff/ri Research Data Network CRC urn:inet:dstc.edu.au:renato:home DSTC Pty Ltd, Uni Qld, 4072, AUSTRALIA phone/fax: +61 7 3365 4310/11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Australian WWW Technical Conference '97 -> http://www.dstc.edu.au/aw3tc Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA04045 for urn-ietf-out; Thu, 7 Nov 1996 18:02:35 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA04040 for ; Thu, 7 Nov 1996 18:02:31 -0500 Received: from CS.BU.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26943 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 18:02:28 -0500 Received: by cs.bu.edu (8.6.10/Spike-2.1) id SAA28165; Thu, 7 Nov 1996 18:02:24 -0500 Date: Thu, 7 Nov 1996 18:02:24 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: urn-ietf@bunyip.com From: dgd@cs.bu.edu (David G. Durand) Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: dgd@cs.bu.edu (David G. Durand) Errors-To: owner-urn-ietf@bunyip.com At 4:09 PM 11/7/96, Keith Moore wrote: >Please accept that I agree with you here. I don't want Internet >information access protocols to be significantly biased in favor of >English speakers (or anybody else). > >I say "please accept" because if you accept that we substantially >agree on the above, it's a lot easier to understand the rest of what >I'm saying. > >For the case of URNs, I have no problem with the idea that they should >not be friendly to English speakers -- because they really shouldn't >be freindly to anybody, except to be transcribable! > >On the other hand, we can hardly prohibit some rare and occasional >misuse of URNs such that human-friendly meaning creeps in. And we've >long since established the need to grandfather in existing name spaces >that have the characteristics of URNs. Some of those name spaces are >going to have some minimal human-friendliness, some degree of meaning >exposed in the names. But there won't be much human-friendliness in >any name space that gets grandfathered in, as any naming scheme which >tries to embed lots of meaning in the names will inherently have poor >persistence and thus be unsuitable for URNs. I am tired of your repeating this. I have pointed out that the URN space of ISO Formal public identifiers is human-friendly (to English speakers, and you can bet the revision will be to the rest of the world). Those identifiers are assigned according to rules that are supposed to guarantee uniqueness. As they are in common productive use in the SGML world (which certainly has a significant relationship to the WWW) is a reason that they will be grandfathered in. So your assertion is simply _false_. So, now given that FPIs will be English-speaker friendly, and grandfathered into URN-space, what do you propose to do about it? I have worries about I18N becuase it seems to fail the transcribability test (for arbitrary transcribers) -- but I don't want to be a cultural imperialist, and I don't see any special virtue in ASCII other than omnipresence. Creating "unfriendly" namespaces may seem good practice to you, but I don't see how it can be mandatory, no matter how much you wish it to be so. >I agree that it may be difficult to get most people to understand that >URNs are not human-friendly names (since it's been difficult to do >even within this WG). I think it's an unreasonable requirement. That's why it's so hard to convince people of it. >Perhaps the right thing to do is to define a mapping to be used when >grandfathering existing non-ASCII namespaces to URNs, i.e. to encode >the non-ASCII characters as UTF-8 and then encode each octet not >printable in ASCII using %XX notation. That way, people could still >type in resource names like they're accustomed to doing, but the >program they type them in to would convert them to canonical URN >format (by prepending URN:namespace: and doing the UTF-8 and %XX >encoding). For purposes of resolution, URNs would always be >transmitted in canonical format, but programs could decode the %XX and >UTF-8 for the purposes of display to humans. So what does this get other than harder-to-debug network protocols? If we define a standard translation, and make sure that it's an equivalence relation (as seems to be required), then why not just transmit it the normal way. Once it can be seen in meaningful form, it _will_ be transmitted that way from human to human, regardless of any numericalization we try to impose. > >There's probably more than one organization in the world named ICRC. >The one your brother works for got ICRC.COM first, but the name is >still ambiguous. You could have as easily found the a different ICRC >than the one you were looking for. But once the name is assigned, you will never get the other ICRC.COM, so it doesn't matter. Even if one of the ICRCs goes out of business, ICRC.COM will not be reassigned. So no problem! The ISO naming rules (simple hierarchy, with well known roots) already can ensure this. >All names are unambiguous only within a limited context. When the net >was small, the context was inherently limited, so it didn't cause a >problem to have only one host for any given name. But now that the >net is much larger, it is a big problem. The only context that matters is the policies that we set up of URN management. Once a subset of the namespace is assigned it can't be reassigned. >Part of this is because you'll already be restricting the context of >the search -- if you're looking for the name of a business >organization, you'll go to a service that matches user-friendly names >against names of businesses. If you're looking for a person's name, >you'll use a different service. If URNs are assigned to have the properties of URNs they will still be persistent. No-one is arguing that URNs should be designed to be meaningfully searched, just that they may be designed to be meaningfully remembered. If your memory fails or your attempt to deduce things from other names you have seen fails, then you just have to find the right name (maybe via some kind of directory search). Obscure names are obscure, but they are not any more reliable for that. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA03946 for urn-ietf-out; Thu, 7 Nov 1996 17:48:44 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA03941 for ; Thu, 7 Nov 1996 17:48:42 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26677 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 17:48:36 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id RAA14420; Thu, 7 Nov 1996 17:48:34 -0500 Message-Id: <199611072248.RAA14420@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Thu, 7 Nov 1996 17:48:33 -0500 In-Reply-To: Daniel LaLiberte's message as of Nov 7, 15:25 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: urn-ietf@bunyip.com Subject: [URN] Enough, already. Cc: Harald.T.Alvestrand@uninett.no Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Okay, all else has failed... I would like ot request that anyone who has the interests of seeing this work move forward take a BREATHER from this topic -- call it an early weekend. There is much left to be discussed about a number of different issues -- of the things that have been discussed, some bear relevance to the work of this group and should be dealt with in an orderly fashion. As Karen mentioned, she is working on revised framework and requirements material, and that should provide a good focus for meaty discussions, when it is available. Let's wait a bit, rather than just chasing the theoretical around in circles -- that does not do justice to the opinions and viewpoints of anyone. Leslie. URN WG Co-Chair. -- ---------------------------------------------------------------------------- "The light at the end of the tunnel Leslie Daigle is often the blindingly obvious..." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA03508 for urn-ietf-out; Thu, 7 Nov 1996 16:50:09 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA03503 for ; Thu, 7 Nov 1996 16:50:07 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26126 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 16:50:03 -0500 Message-Id: <9611072150.AA26126@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Thu Nov 7 15:48 CST 1996 From: "Ryan Moats" To: "Keith Moore" , "Martin J Duerst" Cc: "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Date: Thu, 07 Nov 96 15:50:23 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] Almost an encoding agreement?! (was: I18N does not belong in URNs) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Thu, 07 Nov 1996 16:09:28 -0500, Keith Moore wrote: >Perhaps the right thing to do is to define a mapping to be used when >grandfathering existing non-ASCII namespaces to URNs, i.e. to encode >the non-ASCII characters as UTF-8 and then encode each octet not >printable in ASCII using %XX notation. That way, people could still >type in resource names like they're accustomed to doing, but the >program they type them in to would convert them to canonical URN >format (by prepending URN:namespace: and doing the UTF-8 and %XX >encoding). For purposes of resolution, URNs would always be >transmitted in canonical format, but programs could decode the %XX and >UTF-8 for the purposes of display to humans. Keith- This look very similar to what is in the syntax draft now, with one exception (i.e. I like it but I see one "small" problem) If you go down this path, you need to ensure that if the namespace uses some octet in a reserved fasion, the character corresponding to the octet in ASCII would need to be %XX escaped when used in a literal sense. Further, unless you want real problems, we need to restrict the set of reserved characters to printable ASCII (minus some exceptions that get escaped already). Is this acceptable? Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA03462 for urn-ietf-out; Thu, 7 Nov 1996 16:44:40 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA03457 for ; Thu, 7 Nov 1996 16:44:37 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26068 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 16:44:29 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id QAA06044; Thu, 7 Nov 1996 16:43:31 -0500 (EST) Message-Id: <199611072143.QAA06044@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Daniel LaLiberte Cc: Keith Moore , "Gregory J. Woodhouse" , urn-ietf@bunyip.com, uri@union.ncsa.uiuc.edu Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: Your message of "Thu, 07 Nov 1996 15:25:35 CST." <199611072125.PAA13247@ncsa.uiuc.edu> Date: Thu, 07 Nov 1996 16:43:31 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > > I believe the URN: prefix is essential, but not for this reason. As > > I've said before, the difference between URNs and URLs should have > > more to do with the properties of each name space than how they are > > resolved. > > But the properties of an identifier that are visible to a client (from > the user's perspective, that's all that matters) really come from the > properties of the resolution service. No, the properties of URNs have more to do with the way the name is *assigned* and the discipline that's used to bind the name to the resource, than with how the name is resolved. The resolution services can be substantially the same for URNs and URLs. > Declared properties don't > matter if they end up being untrue. If a URL can be made to behave > persistently by using the URI resolution service as you described (not > me this time!), then is it not behaving like a name (at least > regarding persistence)? Yes. You can have URLs that happen to be persistent. But you can't define a part of URL-space to be persistent. You can have a resolution service that returns a "persistence" bit, but that's not the same thing, because that bit could be turned on or off at any time. The persistence property of a URN cannot be changed; that's why the fact that the name is persistent is encoded in the name itself. To some degree, all of these are social conventions. We want to visually distinguish URNs from URLs because we want humans to use them differently. This requires that they realize that they are (at least in how they are used) very different things. > But if a URL has been made to behave persistently by using the URI > resolution service, isn't it just as good as a URN? Furthermore, I > would think it would be advantageous for everyone to start registering > their http URLs (or servers) in the URI tree, so eventually there > would no longer be a question about whether http URLs are persistent - > they all would be. No, there will always be resources and resource names that aren't guaranteed to be persistent. URNs are the special case, not the general case. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA03343 for urn-ietf-out; Thu, 7 Nov 1996 16:31:06 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA03338 for ; Thu, 7 Nov 1996 16:31:04 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25915 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 16:30:59 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id PAA13247; Thu, 7 Nov 1996 15:25:35 -0600 (CST) Date: Thu, 7 Nov 1996 15:25:35 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611072125.PAA13247@ncsa.uiuc.edu> To: Keith Moore Cc: "Gregory J. Woodhouse" , Daniel LaLiberte , urn-ietf@bunyip.com, uri@union.ncsa.uiuc.edu Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: <199611071956.OAA03504@ig.cs.utk.edu> References: <199611071956.OAA03504@ig.cs.utk.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Hey, you guys are still at it. I don't mind, but apparently others do. I'll be brief and again refer the reader to http://union.ncsa.uiuc.edu/HyperNews/get/www/URIs.html. Keith Moore writes: > I think there's a problem with terminology here. A glossary would help, but here is my standard warning: don't let definitions box you in a corner conceptually. > I believe the URN: prefix is essential, but not for this reason. As > I've said before, the difference between URNs and URLs should have > more to do with the properties of each name space than how they are > resolved. But the properties of an identifier that are visible to a client (from the user's perspective, that's all that matters) really come from the properties of the resolution service. Declared properties don't matter if they end up being untrue. If a URL can be made to behave persistently by using the URI resolution service as you described (not me this time!), then is it not behaving like a name (at least regarding persistence)? > But human beings need to be able to distinguish between a URN and a > URL. That way, they can tell a stable, persistent resource identifier > from a resource location. But if a URL has been made to behave persistently by using the URI resolution service, isn't it just as good as a URN? Furthermore, I would think it would be advantageous for everyone to start registering their http URLs (or servers) in the URI tree, so eventually there would no longer be a question about whether http URLs are persistent - they all would be. But during the transition, how hard would it be for the user-author of a document referencing another document to find out if one URL is persistent whereas another one is not? -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA03233 for urn-ietf-out; Thu, 7 Nov 1996 16:18:23 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA03228 for ; Thu, 7 Nov 1996 16:18:20 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25777 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 16:18:04 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id QAA04987; Thu, 7 Nov 1996 16:16:56 -0500 (EST) Message-Id: <199611072116.QAA04987@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Fisher Mark Cc: "girod@LCS.MIT.EDU" , Martin J Duerst , "moore@cs.utk.edu" , "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Thu, 07 Nov 1996 10:00:00 EST." <3281FA09@MSMAIL.INDY.TCE.COM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Nov 1996 16:16:56 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > So, I see only 2 basic directions URN identifiers can go: > > 1) Totally opaque, random numeric strings; or > > 2) I18N character strings with appropriate encoding, > preferably (IMHO) as UTF-8. > > There really is no middle ground -- if there is a pattern there, people will > make use of it and screw up the system. As an example that there *is* middle ground, I suggest: 3) URNs are assigned by the "system" without regard to the content that they name. (in other words, totally opaque, but not restricted to numerals) This way, they can be composed of a larger character set without being human meaningful. And there are other ways of providng the same feature. We can't restrict character sets too much because of the need to grandfather existing URN spaces. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA03181 for urn-ietf-out; Thu, 7 Nov 1996 16:15:17 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA03176 for ; Thu, 7 Nov 1996 16:15:13 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25756 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 16:14:43 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id QAA20758; Thu, 7 Nov 1996 16:09:28 -0500 (EST) Message-Id: <199611072109.QAA20758@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Thu, 07 Nov 1996 18:15:34 +0100." <"josef.ifi..235:07.10.96.17.15.36"@ifi.unizh.ch> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Nov 1996 16:09:28 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > >> So for grandfathering, we have two choices. > >> > >> 1) We interpret it as "direct grandfathering of characters", > >> in which case we have to allow a really wide range > >> of characters (i.e. ISO 10646). > >> 2) We interpret it as "indirect grandfathering", in which > >> case the digits, or whatever small set, will be > >> enough. > > > >I suspect there will be some of each. > > I wouldn't mind "some of each", if this means "about the same > amount for everybody on the world". If it comes to mean "a lot > for English-speaking, but very little for the rest of the world", > I would have to strongly disagree. Martin, Please accept that I agree with you here. I don't want Internet information access protocols to be significantly biased in favor of English speakers (or anybody else). I say "please accept" because if you accept that we substantially agree on the above, it's a lot easier to understand the rest of what I'm saying. For the case of URNs, I have no problem with the idea that they should not be friendly to English speakers -- because they really shouldn't be freindly to anybody, except to be transcribable! On the other hand, we can hardly prohibit some rare and occasional misuse of URNs such that human-friendly meaning creeps in. And we've long since established the need to grandfather in existing name spaces that have the characteristics of URNs. Some of those name spaces are going to have some minimal human-friendliness, some degree of meaning exposed in the names. But there won't be much human-friendliness in any name space that gets grandfathered in, as any naming scheme which tries to embed lots of meaning in the names will inherently have poor persistence and thus be unsuitable for URNs. Still, it's a judgement call as to whether a particular name space fits in URN space. In making such a judgement, what matters is the overall characteristics of the name space, not which characters are and aren't allowed. > >> Choosing ASCII only as for URLs would be very unfair cheating. > > > >If the names aren't human meaningful, I don't see what you're > >complaining about. > > If I were sure the names would not be meaningful, I would not > have much reason to complain. But the URL example shows that > restricting people from becomming meaningful is very hard if > not impossible. A lot of people "publish" things on the web by simply editing files in a particular directory; the URLs for those files are derived from their filenames. We can hardly expect people to assign meaningless names to files that they edit, and few people (outside the information sciences world) understand the virtue in using meaningless resource names. I agree that it may be difficult to get most people to understand that URNs are not human-friendly names (since it's been difficult to do even within this WG). This is part of why I think the URN: prefix is important (so that URNs are easily distinguished from URLs). It's also important to promote early use of the URN: prefix for existing non-friendly name spaces (so people get used to seeing URN: followed by gibberish). Finally, new URN spaces are going to require some restrictions about how those URNs are defined. (In both RCDS and the CNRI handle system, resource names aren't chosen by users -- you ask the system to create one and it gives it back to you.) Despite all of this, I'm sure that a few human-friendly URNs will creep in somewhere. But what's important is that URNs won't be generally useful as a means to define human-friendly names -- the case where a URN is human-friendly will be the odd exception rather than the rule. (I'm reminded of RFC numbers which are generally assigned in sequence, but occasionally are chosen to be easily remembered -- so RFC XX00 is often an "assigned numbers" RFC. My favorite example is RFC 1984.) > You may agree with the above point, or you may disagree. But > either way, ASCII only is unfair. If you think that naming > schemes, protocols, standards, some review board, or whatever, > can assure that no meaningful stuff is created, then there > is no reason to restrict to ASCII. The working group needs to decide which is more important -- being able to grandfather in existing URN-like name spaces from everywhere on the planet, or having all URNs be transcribable by anyone on the planet. I could certainly make a case for a subset of ASCII-only based on the latter consideration. Perhaps the right thing to do is to define a mapping to be used when grandfathering existing non-ASCII namespaces to URNs, i.e. to encode the non-ASCII characters as UTF-8 and then encode each octet not printable in ASCII using %XX notation. That way, people could still type in resource names like they're accustomed to doing, but the program they type them in to would convert them to canonical URN format (by prepending URN:namespace: and doing the UTF-8 and %XX encoding). For purposes of resolution, URNs would always be transmitted in canonical format, but programs could decode the %XX and UTF-8 for the purposes of display to humans. > One should assume that Japanese, Russians, Chinese, or whoever, can > be as disciplined, or as tighly controlled, as the English-speaking > part of the world. On the other hand, if you think that namespaces > will get meaningful because of people's nature, and you think it is > a bad thing that has to be avoided, there is no other choice but to > limit ourselves to the decimal digits and maybe two or three other > characters. We can discourage putting human-friendly names in URNs by the methods I mentioned above. Also, since URI resolution will work for either URNs or URLs, there will be no reason to insist that a name be in URN space just so it can have resolution. So the only people who will assign URNs will be those who really want long-term persistent and ugly resource names. (At least this is what I hope will happen.) > But there can be a great deal of human-friendliness, > without any need for ambiguity. URLs such as http://www.ibm.com > or http://www.icrc.org are examples. My brother, who works at ICRC in > Geneva, recently called me. Before he was able to tell me how I could > reach him by email, I had the ICRC home page on my browser, and had > found the generic email address explanations, and had sent him a mail. There's probably more than one organization in the world named ICRC. The one your brother works for got ICRC.COM first, but the name is still ambiguous. You could have as easily found the a different ICRC than the one you were looking for. (I keep getting tripped up when I visit the web page of Global Business Network -- which is www.gbn.ORG. www.GBN.COM is somebody else.) This is only going to get worse as more companies get on the Internet. > If it can be that human-friendly, and that unambiguous, I don't know why > I should go to a search service to find the ICRC. And I don't know > why people that use other scripts should go though a serach service, > while English speaking users don't have to do so. All names are unambiguous only within a limited context. When the net was small, the context was inherently limited, so it didn't cause a problem to have only one host for any given name. But now that the net is much larger, it is a big problem. The whole huge mess over ownership of domain names, the InterNIC's capriciousness in deciding who gets what domain within .COM, and all of the hair-brained proposals to add tons of vanity-plate top-level domains -- ALL of this is caused by the lack of support for human-friendly names in the Internet infrastructure, and the resulting misuse of DNS to do a job it wasn't designed to do. We're not going to misuse URNs in the same way. > > >> And I don't want to have to search through long lists > >> of possible answers just because I use Japanese, whereas > >> I will get one immediate answer for English. > > > >The point is that you will often get multiple answers for English. > >English names are no more precise than names in other languages. > > No, but English can be used in URLs, and I get an unambigous > result if there is one, in due time. In Japanese, even if the > result would be unambiguous, I currently can't get it fast and > easily. Which is better - an ambiguous result which is usually correct, or an unambiguous result which is often incorrect? The number of names you get back from a search of a user-friendly name is related to how ambiguous the name is. If the name you give is relatively unambiguous, you'll only get a few names back. "Kodak" (a name explicitly chosen to be globally unique) will give you relatively few hits, while "Acme" (a very common brand name) will give you far more. Part of this is because you'll already be restricting the context of the search -- if you're looking for the name of a business organization, you'll go to a service that matches user-friendly names against names of businesses. If you're looking for a person's name, you'll use a different service. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA02084 for urn-ietf-out; Thu, 7 Nov 1996 14:57:44 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA02077 for ; Thu, 7 Nov 1996 14:57:34 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24765 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 14:57:01 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id OAA03504; Thu, 7 Nov 1996 14:56:34 -0500 (EST) Message-Id: <199611071956.OAA03504@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Gregory J. Woodhouse" Cc: Daniel LaLiberte , Keith Moore , urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: Your message of "Thu, 07 Nov 1996 09:47:38 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 07 Nov 1996 14:56:33 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > It still seems to me that the issues is one of mechanics. It seems fine to > specify that the namespaces http:, ftp:, gopher:, etc. are reserved for > URLs so that a client knows a priori that when it sees > > http://foo.bar.com/ > > it knows it only need connect to foo.bar.com and retrieve the resource. > But without doing such a check, the client would have to assume the above > URI *could* be a URN and attempt to resolve it. I think there's a problem with terminology here. We have essentially two separate efforts going on here: (1) defining what URNs look like and how they are used, and (2) defining a mechanism for URI resolution. 1. URNs are a name space with the properties defined in RFC 1737. Strictly speaking, an http URL can never be a URN, since http as a name space isn't constrained to have those properties. 2. The URI resolution mechanism isn't limited to URNs -- it can also be used to resolve many types of URLs. So in the example above, the client doesn't have to know whether http://foo.bar.com/ is a URN or not to know if it can resolve the name. The client can simply attempt to apply URI resolution to the URL. If it succeeds, it can use any of the services returned by the resolution process. If the URI resolution fails, it can fall back to talking to the http server at foo.bar.com. > A separate issue is whether the above URI could represent different > resources when interpereted as a URL or a URN. A URI is either a URL or URN or something; it cannot be both a URL or a URN. As for "interpretation" of an http URL under URI resolution, this isn't a problem: a URL beginning with "http:" will always be resolved the same way. Of course it is "possible" for the resource pointed to by a URL and the resource you get from resolving that URL with URI resolution will be different. But this is no different from the situation we have today -- if the domain in a URL has multiple IP addresses pointing to multiple servers and those servers are not in synch. > Finally, a possible design is to have the above URI be both a URL and a > URN. By this, I mean that whatever service is responsible for resolving URNs > will recognize and deal appropriately with namespaces such as http:. But it > is obviously desirable not to have to go through the process of resolving a > URN just to get back a URL that is identical to the original URN. Well, this seems wasteful, but I submit that it really is desirable. The client doesn't know in advance whether resolution is available for a particular URL; it has to do a DNS lookup (or consult some other resolution service) to find out. As long as the client is attempting to do resolution anyway, it doesn't hurt for the resolution server to return a single URL - even one that matches the original. And there is a major win here -- if the demand for the resource named by the URL increases, the provider can simply replicate the resource on additional servers, tell the resolution server about it, and clients will find them. > Now, if I'm missing something fundamental, by all means tell me, but this > seems like a real issue to me. It seems that omitting the urn: prefix would > not break anything (unless of course a URI is allowed to have different > referents depending upon whether or not it is a URN), but it may still be > useful, just as it may be useful to have a url: prefix for URIs that are in > fact URLs. I believe the URN: prefix is essential, but not for this reason. As I've said before, the difference between URNs and URLs should have more to do with the properties of each name space than how they are resolved. That is, we need similar resolution mechanisms for URNs (to provide persistence, longevity, global scope) as for URLs (to provide redundancy, scalability, and fault-tolerance...which are desirable for URNs as well). But human beings need to be able to distinguish between a URN and a URL. That way, they can tell a stable, persistent resource identifier from a resource location. For instance, if you're writing a paper and you need to put references to other works, those references should be URNs, rather than URLs, whenever possible. Advertising a URL for a resource says nothing about its longevity or persistence; advertising a URN for a resource is an indication that the URN will always point to that resource (if the resource is available). Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA01593 for urn-ietf-out; Thu, 7 Nov 1996 14:07:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA01588 for ; Thu, 7 Nov 1996 14:07:17 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24191 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 14:06:45 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01228-0@josef.ifi.unizh.ch>; Thu, 7 Nov 1996 20:04:04 +0100 Subject: [URN] Re: Comments on "I18N does not belong in URNs" To: jayhawk@ds.internic.net (Ryan Moats) Date: Thu, 7 Nov 1996 20:04:03 +0100 (MET) Cc: moore@cs.utk.edu, urn-ietf@bunyip.com, tallen@fsc.fujitsu.com, girod@LCS.MIT.EDU In-Reply-To: <3280B0E8.6AF9@ds.internic.net> from "Ryan Moats" at Nov 6, 96 09:38:16 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1982 From: Martin J Duerst Message-Id: <"josef.ifi..635:07.10.96.19.04.05"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ryan Moats wrote: >Terry Allen commented (|): > >|That's an argument specifically against using UTF-8 at all. I'd >|like to hear more on this point from the UTF-8 proponents. > >Martin Duerst replied (@): > >@Also, the URN syntax draft clearly specifies how URNs are >@transported over 7-bit channels (using %HH). This works for >@URLs, there is no reason it shouldn't work for URNs. >@ >@So I really wonder where there should be a problem. > >Well, this is not exactly the way I interpret the syntax draft. >Section 3 of the draft states that encoding URNs for transport >is the responsibility of the transport protocol. The implied statement >is that the transport protocol is responsible for undoing the >encoding. I guess you should better make this more explicit. Anyway, %HH escaping is always available, and will work with email and other 7-bit-challenged protocols. >The encoding section is there in the case of encoding >that the URN resolver has to undo itself. What I wonder (and >am looking for some consesus on) is: "Is this necessary?" >Also, the %HH escaping technique does have some problems with UTF-8 >as Martin has pointed out on another thread... If we really want to focus on non-meaningful, ISBN-like stuff, then there is no problem, because the namespace itself will always be restricted to a fairly small character set, even if this is drawn from full Unicode/ISO 10646. This point can be slightly extended: Because Unicode/ISO 10646 is such a huge collection of characters, the chances that a namespace has to use all of them PLUS some more for structure are much smaller than with ASCII. They will only occur in those cases that we already have with ASCII, i.e. when we speak about devices (computers) that represent characters with Unicode. Real-world namespaces, such as the names of emperors or plays, or whatever, even in native notation for each of these, never will use such oddities as Zapf Dingbats in their names. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA01271 for urn-ietf-out; Thu, 7 Nov 1996 13:36:42 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA01237 for ; Thu, 7 Nov 1996 13:36:39 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23912 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 13:36:38 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id NAA10430; Thu, 7 Nov 1996 13:36:37 -0500 Date: Thu, 7 Nov 1996 13:36:37 -0500 Message-Id: <199611071836.NAA10430@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: Harald.T.Alvestrand@uninett.no, urn-ietf@bunyip.com In-Reply-To: <26912.847376443@domen.uninett.no> (Harald.T.Alvestrand@uninett.no) Subject: Re: [URN] some comments Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com Let me follow up Harald's comment with a note about the IRTF. Abel Weinrib is the chair of the IRTF and is very open to suggestions for new WGs in that context that want to explore more open ended questions. In fact there were 2 WGs formed last year on related topics. The one I chair is on an Internet Information Architecture. It is a closed group at present, but one of our threads of discussion is about how to open up the process to a wider community. I will certainly report further on that as we make progress. The other group is chaired by Cecilia Preston and my recollection is that the focus of that is metadata. I have no idea about the nature of their work. But, let me urge you, if you would like to form a group to work on something related to IETF activities, but more open-ended, to talk with Abel about it. I also recommend to you the recent RFC 2014 on the subject of the IRTF. Karen Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA01085 for urn-ietf-out; Thu, 7 Nov 1996 13:29:26 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA01077 for ; Thu, 7 Nov 1996 13:29:23 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23814 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 13:29:21 -0500 Message-Id: <9611071829.AA23814@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Thu Nov 7 12:27 CST 1996 From: "Ryan Moats" To: "Daniel LaLiberte" , "Harald.T.Alvestrand@uninett.no" , "Peter Deutsch" Cc: "Karen R. Sollins" , "Leslie Daigle" , "urn-ietf@bunyip.com" Date: Thu, 07 Nov 96 12:29:08 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] some comments Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Thu, 7 Nov 1996 11:50:05 -0500, Peter Deutsch wrote: >I think I understand the thrust of your argument, and if >not for the past four or five years of history, I'd agree >wholeheartedly that we need to remain open to change. > >Unfortunately, as someone who has been monitoring and >(before I was called away by my accountants) participating >in this debate pretty much since its inception, I'd have >to echo Karen's concerns. > >You are right - if bits or pieces turn out to be broken in >RFC 1737, then they should to be fixed. That's simply good >engineering. The problem I see, and I suspect that Karen >was attempting to address, is that there exist the danger >that in leaving open the possibility of modifying RFC >1737, at least some people will take it a mandate to fix >not just broken specifics, but the conceptual model >itself. This has been happening since the beginning of >this work and it's getting old. I fully agree with this. It was not my intent to break the whole structure, just fiddle with bits of it if necssary as we move forward. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA00853 for urn-ietf-out; Thu, 7 Nov 1996 13:12:22 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA00848 for ; Thu, 7 Nov 1996 13:12:16 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23650 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 13:12:15 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id NAA10377; Thu, 7 Nov 1996 13:12:14 -0500 Date: Thu, 7 Nov 1996 13:12:14 -0500 Message-Id: <199611071812.NAA10377@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: urn-ietf@bunyip.com Subject: [URN] requirements - see draft-girod-urn-res-req-00.txt Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com I suggest that you consider draft-girod-urn-res-req-00.txt, in which we identify a number of requirments for URN resolution services. For some reason it didn't make it onto the web page for the URN WG set up by the IETF. In addition, the framework paper suggests a few requirements, but is not explicit enough. I am now working a requirements/framework paper based on both of these, plus what I can cull from the discussions since the group has been set up. The requirements paper is the one we presented at the BOF in Montreal. The later sections of the paper discuss particular resolution schemes and are at this point outdated, but I believe that what we said in the requirements section is important for this group and must be said in some document we publish. Without stating explicitly the requirements for URN resolution services it is impossible to evaluate whether or not any particular scheme is what is needed. (Bob Briscoe you seem to be asking for this especially.) In addition to its being available from internet drafts it is also available from our anonymous ftp server (mercury.lcs.mit.edu:/pub/sollins/draft-girod-urn-res-req-00.txt). Karen Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA00691 for urn-ietf-out; Thu, 7 Nov 1996 13:04:14 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA00686 for ; Thu, 7 Nov 1996 13:04:12 -0500 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23567 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 13:04:10 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.8.2/8.7.3) with SMTP id JAA16220; Thu, 7 Nov 1996 09:47:38 -0800 (PST) Date: Thu, 7 Nov 1996 09:47:38 -0800 (PST) From: "Gregory J. Woodhouse" To: Daniel LaLiberte Cc: Keith Moore , urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: <199611071646.KAA07336@ncsa.uiuc.edu> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com It still seems to me that the issues is one of mechanics. It seems fine to specify that the namespaces http:, ftp:, gopher:, etc. are reserved for URLs so that a client knows a priori that when it sees http://foo.bar.com/ it knows it only need connect to foo.bar.com and retrieve the resource. But without doing such a check, the client would have to assume the above URI *could* be a URN and attempt to resolve it. In a sense, this isn't a huge restriction because the client needs to know how to retrieve resources specified by a URL, anyway, so it must know which namespaces are possible. A separate issue is whether the above URI could represent different resources when interpereted as a URL or a URN. This is, of course, only possible if the same namespace can have multiple semantics, and my understanding is that this is not the case, but to be honest, I don't see where this is spelled out. Finally, a possible design is to have the above URI be both a URL and a URN. By this, I mean that whatever service is responsible for resolving URNs will recognize and deal appropriately with namespaces such as http:. But it is obviously desirable not to have to go through the process of resolving a URN just to get back a URL that is identical to the original URN. (In the case of NAPTR we could have an N2R resolution, but then scalability issues come to mind.) Now, if I'm missing something fundamental, by all means tell me, but this seems like a real issue to me. It seems that omitting the urn: prefix would not break anything (unless of course a URI is allowed to have different referents depending upon whether or not it is a URN), but it may still be useful, just as it may be useful to have a url: prefix for URIs that are in fact URLs. --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/home.html resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA00212 for urn-ietf-out; Thu, 7 Nov 1996 12:18:10 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA00207 for ; Thu, 7 Nov 1996 12:18:08 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23013 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 12:17:24 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00910-0@josef.ifi.unizh.ch>; Thu, 7 Nov 1996 18:15:35 +0100 Subject: Re: [URN] I18N does not belong in URNs To: moore@cs.utk.edu Date: Thu, 7 Nov 1996 18:15:34 +0100 (MET) Cc: tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611062032.PAA10773@ig.cs.utk.edu> from "Keith Moore" at Nov 6, 96 03:32:28 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5192 From: Martin J Duerst Message-Id: <"josef.ifi..235:07.10.96.17.15.36"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore wrote: >Perhaps. I don't have as big a problem with this, as long as >there's a discipline about how they are assigned that prevents >URNs from being used as search strings. That's my main worry. >(URNs are also supposed to be transcribable, but I recognize that >only a very small set of characters is transcribable by everyone >on the planet.) For "everyone", you might have to limit it to X and O, or even X and XX :-). Just an additional example: Think about number plates of cars. Lots of non-ASCII characters there all over Asia. >> So for grandfathering, we have two choices. >> >> 1) We interpret it as "direct grandfathering of characters", >> in which case we have to allow a really wide range >> of characters (i.e. ISO 10646). >> 2) We interpret it as "indirect grandfathering", in which >> case the digits, or whatever small set, will be >> enough. > >I suspect there will be some of each. I wouldn't mind "some of each", if this means "about the same amount for everybody on the world". If it comes to mean "a lot for English-speaking, but very little for the rest of the world", I would have to strongly disagree. In theory, I could immagine making a worldwide search of suitable namespaces, and limiting the characters to those appearing in such namespaces. But I guess we would quickly end up with all the major alphabets completed, and the work deciding which of the ~20,000 CJK ideographs is used in a naming scheme, and which not, would not be very rewarding. >But we want the transformations >from "old identifier" to URN to be simple and easy to remember. Back to user-friendliness, in some sense. I have no problems about this. But again, I wouldn't like it if "simple and easy to remember" means that English speaking people just have to type them in, whereas people in the rest of the world, for namespaces that are currently in use there, need list of correspondences they have to look up or remember constantly. >> Choosing ASCII only as for URLs would be very unfair cheating. > >If the names aren't human meaningful, I don't see what you're >complaining about. If I were sure the names would not be meaningful, I would not have much reason to complain. But the URL example shows that restricting people from becomming meaningful is very hard if not impossible. You may agree with the above point, or you may disagree. But either way, ASCII only is unfair. If you think that naming schemes, protocols, standards, some review board, or whatever, can assure that no meaningful stuff is created, then there is no reason to restrict to ASCII. One should assume that Japanese, Russians, Chinese, or whoever, can be as disciplined, or as tighly controlled, as the English-speaking part of the world. On the other hand, if you think that namespaces will get meaningful because of people's nature, and you think it is a bad thing that has to be avoided, there is no other choice but to limit ourselves to the decimal digits and maybe two or three other characters. >> >> I definitely hate to see i18n just being moved around and delayed >> >> by some people. With UTF-8 in URNs, we have made great progress. >> > >> >No, this is a big step backward. Just because there is a new layer >> >being defined doesn't mean that I18N belongs there. >> > >> >I18N *is* important -- and I'd be happy to see a draft document or >> >draft charter for a working group to define a protocol (say an extension >> >of http/html) to resolve human-friendly names into URNs or URLs. >> >> Why is there a need for an additional protocol layer? >> There is no need currently for English, is it? > >Yes, there is. Human-friendly names are inherently ambiguous, >and have ambiguous meanings which require a human being to untangle. [examples removed] >URNs should be precise enough that a human isn't required to >disambiguate the result. I know your examples. But there can be a great deal of human-friendliness, without any need for ambiguity. URLs such as http://www.ibm.com or http://www.icrc.org are examples. My brother, who works at ICRC in Geneva, recently called me. Before he was able to tell me how I could reach him by email, I had the ICRC home page on my browser, and had found the generic email address explanations, and had sent him a mail. Of course, I'm an expert, but there are many people with less Web experience and technical expertise who could do that. If it can be that human-friendly, and that unambiguous, I don't know why I should go to a search service to find the ICRC. And I don't know why people that use other scripts should go though a serach service, while English speaking users don't have to do so. >> And I don't want to have to search through long lists >> of possible answers just because I use Japanese, whereas >> I will get one immediate answer for English. > >The point is that you will often get multiple answers for English. >English names are no more precise than names in other languages. No, but English can be used in URLs, and I get an unambigous result if there is one, in due time. In Japanese, even if the result would be unambiguous, I currently can't get it fast and easily. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA29723 for urn-ietf-out; Thu, 7 Nov 1996 11:52:21 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA29718 for ; Thu, 7 Nov 1996 11:52:19 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22778 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 11:52:17 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id KAA07336; Thu, 7 Nov 1996 10:46:58 -0600 (CST) Date: Thu, 7 Nov 1996 10:46:58 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611071646.KAA07336@ncsa.uiuc.edu> To: Keith Moore Cc: urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: <199611060416.XAA28069@ig.cs.utk.edu> References: <199611050616.AAA21984@ncsa.uiuc.edu> <199611060416.XAA28069@ig.cs.utk.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Keith Moore writes: > [...] But the difference between URNs and URLs has > almost nothing to do with how they are resolved (indeed, I hope they > use the same resolution mechanisms), and a lot to do with how the > names are assigned and maintained. This is at least a different view, especially regarding URLs, than other people hold. But I am under a restraining order :-) not to pursue this here, so I've created a new list uri@union.ncsa.uiuc.edu. To subscribe (this is not Majordomo), see the web page at: http://union.ncsa.uiuc.edu/HyperNews/get/www/URIs.html > This is why URNs need a URN: prefix -- because a lot of the value in > having a URN name space with those properties is so *humans* can > recognize a URN when they see it. The issue of whether the "urn:" prefix should be optional or required is still open. Since this issue relates directly to whether URNs can or should be distinguished from URLs, I'm open to having it discussed on uri@union.ncsa.uiuc.edu. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA29641 for urn-ietf-out; Thu, 7 Nov 1996 11:50:22 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA29635 for ; Thu, 7 Nov 1996 11:50:19 -0500 Received: from expresso.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22752 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 11:50:16 -0500 Received: by expresso.bunyip.com (NX5.67c/NX3.0S) id AA24400; Thu, 7 Nov 96 11:50:11 -0500 Message-Id: <9611071650.AA24400@expresso.bunyip.com> From: Peter Deutsch Date: Thu, 7 Nov 1996 11:50:05 -0500 In-Reply-To: Daniel LaLiberte's message as of Nov 7, 9:18 X-Mailer: Mail User's Shell (7.2.4 2/2/92) To: Daniel LaLiberte , Harald.T.Alvestrand@uninett.no Subject: Re: [URN] some comments Cc: leslie@bunyip.com (Leslie Daigle), "Karen R. Sollins" , urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Peter Deutsch Errors-To: owner-urn-ietf@bunyip.com Hi all, It's been some time since I posted in this forum (actually, I think my last shout in this problem space was back during the lifetime of the previous URI list). I've been busy, other people have been carrying the flag and I've tried to let sleeping dogs lie. This morning, I composed a reply to a message opening the possibility of reworking RFC1737. I then had the good sense to shelve the posting until I'd had time to view the rest of the thread, and was about to congratulate myself on the wisdom of my advancing years when I reached the subsequent exchange between Dan and Harald. Now, that exchange may be enough to close this debate, but given past history, I suspect it will instead open again the meta-discussion about conceptual models, process and so on. Because of Dan's specific concerns about process, I've decided to go ahead and send my missive. Harald obviously speaks with the weight of the Area Director and I applaud his remarks. I offer my complemetary message as someone who was a founding co-chair of the original URI working group and as someone who has been watching similar exchanges for something like five years now. There is no offense intended for any specific indvidual. I hope none is taken. ------------------------------ [* WARNING CONTAINS FREE DIATRIBES AND MEASURABLE RANTINGS. *] [* SOME EXPERTS BELIEVE THAT CONSUMING SUCH DIATRIBES AND *] [* RANTINGS LEADS TO IRRITABILITY, CROSS-POSTING AND FLAMES. *] [* CONSUME AT YOUR OWN RISK..... *] [ jayhawk@@dsm0.ds.internic.net wrote: ] . . . } First I have to apologize, because I should have added an indication that } that wasn't an entirely serious remark. } } } Having said that, I still claim that as we move forward, we have the right } to realize that something in 1737 isn't optimal or doesn't work etc. My } opinion is that if there is rough consensus in the WG, then saying "but } 1737 says that's a no-no" doesn't cut it. } I think I understand the thrust of your argument, and if not for the past four or five years of history, I'd agree wholeheartedly that we need to remain open to change. Unfortunately, as someone who has been monitoring and (before I was called away by my accountants) participating in this debate pretty much since its inception, I'd have to echo Karen's concerns. You are right - if bits or pieces turn out to be broken in RFC 1737, then they should to be fixed. That's simply good engineering. The problem I see, and I suspect that Karen was attempting to address, is that there exist the danger that in leaving open the possibility of modifying RFC 1737, at least some people will take it a mandate to fix not just broken specifics, but the conceptual model itself. This has been happening since the beginning of this work and it's getting old. I believe that this debate has been struggling on for so long because we have two basic belief systems (okay, two engineering models), and rather than divide into two groups to pursue alternate development paths, adherents of the two models have remained together and continued to debate essentially the same arguments and beliefs continuously for years. Yes, we've probably made some progress (there is a requirement document, there are some experimental systems deployed, the terminology seems to have stabilized, etc) but I'm really rather concerned that we don't yet have that essential working consensus on the underlying conceptual model. I'm seeing postings go by that echo pretty much exactly what was being posted several years ago in earlier forums (fora?). Because of that, I think leaving open the possibility of going back to rejig RFC 1737 sends the wrong message at this time. Yes, if you think something specific is broken, it's responsible to say so. But if someone's problem is with the conceptual model, then you should probably unsubscribe and leave the rest of us to our misconceptions. Please understand that I'm not taking a shot at your posting and I hope I don't offend you. From your tone you seem aware of the possibilities I'm warning against. It's just that I'm a little tired of the continual debate on questions which have been "asked and answered" and I fear that others may misconstrue your comments to mean that it's okay to continue fighting the good fight to "fix" the model. I'd like to remind people who have joined this debate within the past year or two that when we first formed the URI working group way back when, we had two camps. One camp thought everything could be done with URLs, and didn't accept that the semantics of URNs were different, or if they were, that meant we could or should implement them. The basic thrust seems to be "they're not real, or not needed. We can do the same things with URLs and building these other things would be harmful." The other camp believed that the differing semantics indicated the existance of a different class of identifiers and these should be designed, standardized and used separately from URLs. Such people believed that in doing so, URNs would prove useful in ways that URLs are not, and if some people didn't see this, that's fine as it would become clear who was right as URNs became widely deployed. Darwinian selection would do its thing. Since then a conceptual model was proposed (I think Karen captured its broad outlines well), URN requirements were teased out and written down, the framework document was promulgated and a few experimental systems were designed and deployed. Yes, that's measurable progress. But gosh, it's been a slog. And we still see people arguing against the model, or the necessity, or the functional requirements as already agreed. That was probably appropriate back in the URI group, when the conceptual model was being hammered out. Today, I personally believe that the model-related debates are hurting us all, as it's having a chilling effect on the testing, deployment and eventual acceptance of URNs. I think URNs are real and are badly needed, and we're running way behind schedule. We have a model and this group has a specific mandate to implement a component of that model. If you disagree with that model, please take your concerns to the Area Directors, the plenary sessions, the IETF mailing list or simply ignore the workings of this group. If you're right we will do no harm. If you're wrong you're holding up progress. If you agree with the model and disagree with the implementation, then that's fair game, but folks, life's too short. If you don't buy the model, please leave this work to those who do. - peterd -- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA29561 for urn-ietf-out; Thu, 7 Nov 1996 11:48:56 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA29555 for ; Thu, 7 Nov 1996 11:48:54 -0500 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22725 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 11:48:06 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.8.2/8.7.3) with SMTP id IAA09540; Thu, 7 Nov 1996 08:43:01 -0800 (PST) Date: Thu, 7 Nov 1996 08:43:01 -0800 (PST) From: "Gregory J. Woodhouse" To: Jim Conklin Cc: Terry Allen , urn-ietf@bunyip.com Subject: Re: [URN] Re meaningful names In-Reply-To: Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com Much of the software we release is in source code form. If someone werwe to argue that the code should not be commnted or well structured, perhaps even arguing tht algorithms should specifically be chosen because they are hard to follow, and then claim tht woul enhance software quality in that it would make it less tempting for customers to modify the code and possibly break it, I would say they were quite wrong. Software quality is enhanced by having clean, understandable and maintainable code. Now, why should URNs be any different? On Thu, 7 Nov 1996, Jim Conklin wrote: > Like Terry Allen, and for the same reasons, I will (again, as I did months > ago when we previously had this discussion) enter my vote for the ability > to use meaningful names. > > Jim > > --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/home.html resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA29180 for urn-ietf-out; Thu, 7 Nov 1996 11:35:09 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA29175 for ; Thu, 7 Nov 1996 11:35:07 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22622 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 11:34:12 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00889-0@josef.ifi.unizh.ch>; Thu, 7 Nov 1996 17:30:38 +0100 Subject: Re: [URN] I18N does not belong in URNs To: girod@LCS.MIT.EDU Date: Thu, 7 Nov 1996 17:30:37 +0100 (MET) Cc: tallen@fsc.fujitsu.com, moore@cs.utk.edu, urn-ietf@bunyip.com In-Reply-To: <9611062348.AA06182@skadhwe.lcs.mit.edu> from "Lewis Girod" at Nov 6, 96 06:48:00 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2326 From: Martin J Duerst Message-Id: <"josef.ifi..250:07.10.96.16.30.39"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Lewis Girod wrote: > this group seriously would agree to restrict URNs to digits > only for this reason, I would understand. > But with ASCII as a "restricted" character set, we will definitely > get cruftiness, and I see no reason to allow cruftiness for > English, but to deny it for most other languages. > >One idea we were experimenting with here was to use a subset of ASCII >that included only numerals, punctuation and consonants, which would >make most words hard to express (at least in some languages). There are some languages that use mostly consonants, esp. some of the Slavic languages. Arabic and Hebrew in principle write only consonants. But I am less worried about these aspects. What I am worried about is that we just exclude 5 letters from 26. This may not be noticed by some people, who happily will use AEIOU also. We have this now, as for example "~" seems to be unsafe or excluded, but still is used all the time. Also, many accronyms contain only consonants (e.g. HTML and HTTP), and if somebody wants to use words with vowels stripped, it will unduely give advantages to some and disadvantages to others. For example, compare mcrsft, ppl, bm, dgtl, hp, sn, and so on. So just cutting out the vowels is not enough if we want to go that way; for a small set, my preference would still be for 0123456789#* (phone keys). Of course, my general preference is for full i18n with UTF-8. > The interesting thing is that we already have that, in the current > syntax draft. Just call the readable form of it UFNs, and call > the encoded form, %HH-escaped, URNs. I have proposed similar > names for these things, namely IRNs (internationalized ...). > >True, those strings are hard to read but it doesn't solve the problem >because the URN and the UFN are tightly coupled -- the whole point of >UFNs is that they are nicknames with a short lifespan. A UFN should >be allowed to change over time without ever changing the aliased URN. I didn't want to stress that the %HH strings are difficult to read. What I a looking for in UFNs is that they are user friendly, i.e. easy to understand and type in by somebody e.g. in Japan or so, and that they are tightly coupled to something else, e.g. URNs or URLs, so that they can be resolved quickly and deterministically. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA28955 for urn-ietf-out; Thu, 7 Nov 1996 11:23:52 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA28949 for ; Thu, 7 Nov 1996 11:23:50 -0500 Received: from info.cren.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22459 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 11:23:48 -0500 Received: from [192.52.179.12] (conklin-180c.cren.net [192.52.179.12]) by info.cren.net (8.6.6/8.6.4 (CREN)) with SMTP id LAA22632; Thu, 7 Nov 1996 11:23:23 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Nov 1996 11:24:09 -0500 To: Terry Allen , urn-ietf@bunyip.com From: conklin@info.cren.net (Jim Conklin) Subject: Re: [URN] Re meaningful names Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: conklin@info.cren.net (Jim Conklin) Errors-To: owner-urn-ietf@bunyip.com Like Terry Allen, and for the same reasons, I will (again, as I did months ago when we previously had this discussion) enter my vote for the ability to use meaningful names. Jim Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA28179 for urn-ietf-out; Thu, 7 Nov 1996 10:23:19 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA28173 for ; Thu, 7 Nov 1996 10:23:16 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21932 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 10:22:55 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id JAA05599; Thu, 7 Nov 1996 09:18:17 -0600 (CST) Date: Thu, 7 Nov 1996 09:18:17 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611071518.JAA05599@ncsa.uiuc.edu> To: Harald.T.Alvestrand@uninett.no Cc: Daniel LaLiberte , leslie@bunyip.com (Leslie Daigle), "Karen R. Sollins" , urn-ietf@bunyip.com Subject: Re: [URN] some comments In-Reply-To: <26912.847376443@domen.uninett.no> References: <199611070635.AAA01984@ncsa.uiuc.edu> <26912.847376443@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Harald T. Alvestrand writes: > liberte@ncsa.uiuc.edu said: > > Standing on premise and charter as an argument is legalistic and > > dogmatic. That's dangerous, although it may lead to short term > > productivity. > > Actually, I asked for the WG to be run in exactly this fashion. Had I known we were going to be held to the details of the charter, I would have spoken up at that time. But, honestly, would it have mattered? > One reason why we wrote a rather narrow charter for this working > group, which DID include assumptions like "there is a difference > between URLs and URNs", was that we wanted to see if it was > possible to create a solution to a limited problem. But my whole point is that *because* the supposed difference between URLs and URNs (the identifiers, not the resolution mechanisms) does not exist, it is irrelevant to creating a solution, except for syntax and other arbitrary constraints. > One of the things that we have to do, unfortunately, to get a > solution to that limited problem, is to ask those who want to work > on a different problem to leave. So it has come to that, eh? As I've stated, we'll continue the discussion off-line. But are you saying we shouldn't bother? > The output of this working group is supposed to be a set of > Experimental documents. These don't form the be-all and end-all > of the Internet information architecture; they're just an experiment. You should know that many experiments turn into standard practice. If you want it to really be "just an experiment", perhaps you should consider finding a way to kill it off afterwards so it doesn't escape from the lab. :-) -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA27908 for urn-ietf-out; Thu, 7 Nov 1996 10:05:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA27903 for ; Thu, 7 Nov 1996 10:05:34 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21738 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 10:05:31 -0500 Received: by seawall with (8.6.12/) id KAA07429; Thu, 7 Nov 1996 10:05:29 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma007417; Thu Nov 7 10:05:10 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <3281FAD6@MSMAIL.INDY.TCE.COM>; Thu, 07 Nov 96 10:05:58 EST From: Fisher Mark To: Bob Briscoe , Terry Allen Cc: "urn-ietf@bunyip.com" Subject: RE: [URN] Persistence as part of URN framework Date: Thu, 07 Nov 96 10:05:00 EST Message-Id: <3281FAD6@MSMAIL.INDY.TCE.COM> Encoding: 19 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com >Final comment: >If you accept that pragmatically, URNs don't exist for ever (because they >only exist as long as anyone can prove they exist), you can still have the >"no reassignment" rule for people to keep to on best effort. IOW, just >because urn:duns:001234567:Dunn&Bradstreet_Collapse.report stops being >resolvable, anyone who knew of broken references to it well into the >future, >shouldn't deliberately re-use it for something else. Well, unless they can somehow take over resolution of the "duns" namespace, they _can't_ re-use it. That is why URNs were partitioned into namespaces -- so that each namespace resolver could control their namespace. If any party can perform the resolutions for a particular namespace (rather than the assigned resolution party), then a whole big can of worms is opened up -- security issues, reliability, liability, etc. ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA27878 for urn-ietf-out; Thu, 7 Nov 1996 10:02:30 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA27873 for ; Thu, 7 Nov 1996 10:02:26 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21704 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 10:02:23 -0500 Received: by seawall with (8.6.12/) id KAA07323; Thu, 7 Nov 1996 10:02:11 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma007316; Thu Nov 7 10:01:45 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <3281FA09@MSMAIL.INDY.TCE.COM>; Thu, 07 Nov 96 10:02:33 EST From: Fisher Mark To: "girod@LCS.MIT.EDU" , Martin J Duerst Cc: "moore@cs.utk.edu" , "tallen@fsc.fujitsu.com" , "urn-ietf@bunyip.com" Subject: Re: [URN] I18N does not belong in URNs Date: Thu, 07 Nov 96 10:00:00 EST Message-Id: <3281FA09@MSMAIL.INDY.TCE.COM> Encoding: 26 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com >But with ASCII as a "restricted" character set, we will definitely >get cruftiness, and I see no reason to allow cruftiness for >English, but to deny it for most other languages. Even purely numeric schemes can be crufty. Here at TCE we are transitioning from a meaningful component naming scheme to one where the only meaningful part is a prefix indicating the site where the number was assigned -- the rest of the number is random. If there is some way for people to assign a meaning or pattern to a character sequence, this meaning will be used. Sometimes patterns will be detected even when there is no actual pattern (this is how some optical illusions work) -- humans are pattern-detecting animals. So, I see only 2 basic directions URN identifiers can go: 1) Totally opaque, random numeric strings; or 2) I18N character strings with appropriate encoding, preferably (IMHO) as UTF-8. There really is no middle ground -- if there is a pattern there, people will make use of it and screw up the system. ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA27820 for urn-ietf-out; Thu, 7 Nov 1996 09:57:35 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA27815 for ; Thu, 7 Nov 1996 09:57:33 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21634 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 09:57:31 -0500 Received: by seawall with (8.6.12/) id JAA07179; Thu, 7 Nov 1996 09:57:18 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma007150; Thu Nov 7 09:56:30 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <3281F8CE@MSMAIL.INDY.TCE.COM>; Thu, 07 Nov 96 09:57:18 EST From: Fisher Mark To: "Harald.T.Alvestrand@uninett.no" , Bob Briscoe Cc: "urn-ietf@bunyip.com" Subject: Re: [URN] Persistence as part of URN framework Date: Thu, 07 Nov 96 09:53:00 EST Message-Id: <3281F8CE@MSMAIL.INDY.TCE.COM> Encoding: 42 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com >Using DNS TTL records for this is just broken; DNS TTLs are used >to limit caching of name->address mapping, and in the NAPTR proposal, >they should be a fraction of the time one expects to have advance >warning of a server relocation or mapping restructure. >Normal TTLs are on the order of 3 days, and are usually reduced to less >than 1 day before serious network reorganizations. And if you are changing your resolution services faster than that, you are changing them too fast (IMHO). Perhaps the key idea TimBL came up with in devising the Web was that, unlike other hypertext systems (including the Dexter model), links could be broken, i.e. nonfunctional. This single idea was perhaps above all others important in spreading the Web far and wide, as perfectly reliable systems as difficult to construct (even for an appropriately low value of "perfect"). Under the Dexter model, an application will die or limp on after reporting an internal error upon encountering a broken hyperlink. In the Web, the UA just keeps surfing on to the next link. All that URNs can do is assist in persistence; persistence itself must be maintained outside the URN architecture, as persistence is ultimately a political/economic quality, not a technical quality. We would expect a BT URN to persist because of our trust in BT, not because there is some technical solution to persistence. Persistence is assisted in URNs by the ability to hand off resolution duties automagically to successor resolution entities. I would regard measures of persistence to be an optional but necessary part of the metadata for a URN, not as mandatory metadata. It is quite possible that URN will see incredibly wide use, as much or more as URLs are now ("every person a URN namespace owner"). Many of these namespaces may just persist for a few years or months, with the owner not caring about measures of persistence. Persistence is ultimately up to the creating/resolving entity(s). Uniqueness is an easier problem than persistence, although uniqueness has a strong political/economic component. One can certainly imagine the case of URNs for government materials that, after they are first created for public consumption, are found to be embarrassing to that government and the URNs are silently, suddenly changed to refer to much more innocuous materials. Uniqueness, also, is ultimately up to the creating/resolving entity. ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA27494 for urn-ietf-out; Thu, 7 Nov 1996 09:36:07 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA27489 for ; Thu, 7 Nov 1996 09:36:05 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21314 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 09:36:01 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00725-0@josef.ifi.unizh.ch>; Thu, 7 Nov 1996 15:33:12 +0100 Subject: Re: [URN] Re meaningful names To: girod@LCS.MIT.EDU Date: Thu, 7 Nov 1996 15:33:11 +0100 (MET) Cc: tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <9611070152.AA06320@skadhwe.lcs.mit.edu> from "Lewis Girod" at Nov 6, 96 08:52:18 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2002 From: Martin J Duerst Message-Id: <"josef.ifi..915:07.10.96.14.33.19"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Lewis Girod wrote: > Date: Wed, 6 Nov 1996 16:35:41 -0800 (PST) > From: Terry Allen > | Of course, as you point out there is no way to stop people from > | putting semantics into names; the most effective way to deal with the > | issue is to implement a system of user friendly names over the top of > | URNs; 99% of the time the user would see and type only a UFN, and > | these UFNs would be resolved to the URNs that could then be used as > | long-lived references. > > Twice the work or more, doesn't deal with grandfathering, prone > to error; the most effective way to deal with the issue is to > drop your objection to meaningful names. > >It is more work (though how much more is hard to say), but it might >prove really useful. I don't think it would impact grandfathering at >all; grandfathered names could have a UFN alias or they might just be >typed in as URNs. Prone to error? UFNs wouldn't have the longevity >characteristics that URNs hopefully would have, if that's what you >mean -- that's why you don't use them in published links. If you look at what is currently published in terms of URLs, most of them try to be as user-friendly as possible. Non-userfriendlyness may be okay for some official publications, but for publishing things in newspapers and on cardboard boxes, user-friendliness is on great demand. Another aspect of user-friendliness is deterministic behaviour (maybe only shorttime): If you read something in a newspaper, you want to go to that site/document directly, and not have to go through search lists, and so on. The side which publishes a reference likewise wants you to go there directly, and not be detracted. This may not affect URN internationalization, but it definitely affects URL internationalization, because for all of the above, URLs are currently used, with the only restriction that the advantages the users look for are limited to English plus a few other rare languages. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA27394 for urn-ietf-out; Thu, 7 Nov 1996 09:31:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA27389 for ; Thu, 7 Nov 1996 09:31:32 -0500 Received: from fssun10.dev.oclc.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21257 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 09:31:26 -0500 Received: from orc.NISOR (orc.dev.oclc.org) by oclc.org (4.1/SMI-4.1) id AA26579; Thu, 7 Nov 96 09:31:21 EST Received: by orc.NISOR (SMI-8.6/SMI-SVR4) id JAA12243; Thu, 7 Nov 1996 09:32:24 -0500 Date: Thu, 7 Nov 1996 09:32:24 -0500 From: stu_weibel@oclc.org (Stu Weibel) Message-Id: <199611071432.JAA12243@orc.NISOR> To: urn-ietf@bunyip.com Subject: [URN] Semantically meaningful URNs X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: stu_weibel@oclc.org (Stu Weibel) Errors-To: owner-urn-ietf@bunyip.com The philosophical debate about whether URNs will be human transcribable, semantically meaningful, etc., is unproductive. This group should take no stand on this issue. Some naming authorities will choose one approach, others will choose another. The only constraint that is relevant here is that the Locally-Unique-Identifier assigned by a naming authority is not reassigned. There is a technical issue involved having to do with character encodings, of course. The mandate of this group should be to adopt the least restrictive approach that is supportable technically. stu Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA27343 for urn-ietf-out; Thu, 7 Nov 1996 09:21:59 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA27338 for ; Thu, 7 Nov 1996 09:21:57 -0500 From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21090 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 09:21:41 -0500 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <26916-0@domen.uninett.no>; Thu, 7 Nov 1996 15:20:45 +0100 X-Mailer: exmh version 1.6.7 5/3/96 To: Daniel LaLiberte Cc: leslie@bunyip.com (Leslie Daigle), "Karen R. Sollins" , urn-ietf@bunyip.com Subject: Re: [URN] some comments In-Reply-To: Your message of "Thu, 07 Nov 1996 00:35:39 CST." <199611070635.AAA01984@ncsa.uiuc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="==!Exmh_1839892962P"; micalg=pgp-md5; protocol="application/pgp-signature" Content-Transfer-Encoding: 7bit Date: Thu, 07 Nov 1996 15:20:43 +0100 Message-Id: <26912.847376443@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com --==!Exmh_1839892962P Content-Type: text/plain; charset=us-ascii Daniel, some words about process. liberte@ncsa.uiuc.edu said: > Standing on premise and charter as an argument is legalistic and > dogmatic. That's dangerous, although it may lead to short term > productivity. Actually, I asked for the WG to be run in exactly this fashion. One reason why we wrote a rather narrow charter for this working group, which DID include assumptions like "there is a difference between URLs and URNs", was that we wanted to see if it was possible to create a solution to a limited problem. One of the things that we have to do, unfortunately, to get a solution to that limited problem, is to ask those who want to work on a different problem to leave. We've got a process in place for forming working groups that are not about solving limited problems, called the Internet Research Task Force, and Karen Sollins is, I believe, chairing a group there that is chartered to look at wider problems; my mailbox is always open to suggestions for chartering other WGs for attacking concrete problems that need concrete solutions. The output of this working group is supposed to be a set of Experimental documents. These don't form the be-all and end-all of the Internet information architecture; they're just an experiment. But we need to get these documents out, and to get an experiment going; to that end, I've specifically asked the WG chair to make sure the WG sticks to its charter, and does NOT try to investigate other problems. Then this WG closes, and we have the chance to create a new one, with a new charter, with or without a new name, to revise the solution or to create a new one. But with THIS WG, I've asked it to stick to its charter. Harald T. Alvestrand Applications AD --==!Exmh_1839892962P Content-Type: application/pgp-signature -----BEGIN PGP MESSAGE----- Version: 2.6.i iQBVAgUBMoHwOTPwVTwXXgE5AQHpXwH+M0GnpcFcbVDgnFhbcfg1XKuisXTclz2g E8JFdHfMbVCfWdUPdPF4CnDQ+yPk8NxQ0xYL1/GhH8xYbOEDP8fF/w== =F9pb -----END PGP MESSAGE----- --==!Exmh_1839892962P-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA27308 for urn-ietf-out; Thu, 7 Nov 1996 09:17:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA27303 for ; Thu, 7 Nov 1996 09:17:47 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21057 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 09:17:44 -0500 Message-Id: <9611071417.AA21057@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Thu Nov 7 08:16 CST 1996 From: "Ryan Moats" To: "Karen R. Sollins" Cc: "urn-ietf@bunyip.com" Date: Thu, 07 Nov 96 08:18:09 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] Comments on "I18N does not belong in URNs" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Wed, 6 Nov 1996 20:46:17 -0500, Karen R. Sollins wrote: > > First I have to apologize, because I should have added an indication that > that wasn't an entirely serious remark. > >Apology accepted. Truthfully, I was at least as concerned that the >group as a whole not take your comment seriously:-) > > In a more directed vein, syntax draft already breaks 1737. Specifically, I'm > refering to the "case insensitivity" requirement (the draft current > has the NSS being case sensitive). "Case-insensitivity" is itself > tied up in what character set we use. If we treat the NSS as a series of > octets, then we can't have case insensitivity, because we haven't set > a character set (ho boy am I digressing...) > >We ALSO spent many hours arguing over this one. There were three >camps, those who thought case sensitivity was important, those who >thought that case insensitivity was important and those who thought we >just needed a single decision on it. As I remember it, the consensus >really went with the third group and we just had to go one way or the >other. So, although I'd really like not to have those discussions >again, I believe that the majority didn't feel strongly one way or the >other (unlike many of the other issue in that document:-) Sorry to be delayed in answering this, but I finally got the code I was working on last night to work, so I went back to my real life... Thanks for the information, it's useful for a historical (hysterical? ;-) ) perspective. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA26404 for urn-ietf-out; Thu, 7 Nov 1996 08:35:40 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA26399 for ; Thu, 7 Nov 1996 08:35:38 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20764 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 08:35:36 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00695-0@josef.ifi.unizh.ch>; Thu, 7 Nov 1996 14:34:53 +0100 Subject: Re: [URN] I18N does not belong in URNs To: dgd@cs.bu.edu Date: Thu, 7 Nov 1996 14:34:52 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: from "David G. Durand" at Nov 6, 96 12:27:54 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1008 From: Martin J Duerst Message-Id: <"josef.ifi..408:07.10.96.13.35.03"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com David Durand wrote: > I am not advocating either side at the moment -- I tend to agree that >transcribability of I18N names will be hellish and error prone. On the >other hand, eliminating almost all languages in the world from URNs is a >big hit. Every script or language has some characters that are easily confused. In ASCII, this is 0 and O, and l and I and 1. After some time of learning, such characters get eliminated where necessary, or used only where they are clearly identifiable from context. Foreign users tend to be more confused, for example it is customary in Japan to add a horizontal bar to the stem of a D to distinguish it from O. Transcribing will be a problem for those that don't know a script. But I assume that those who designed a naming system e.g. for Buddhist texts, made the assumption that a minimal knowledge of the script the texts are in could be assumed. Also, if they choose kanji, they will have choosen them so that they are easily disambiguated. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA26388 for urn-ietf-out; Thu, 7 Nov 1996 08:35:03 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA26383 for ; Thu, 7 Nov 1996 08:35:01 -0500 Received: from goggins.bath.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20752 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 08:34:54 -0500 Received: from ukoln.ac.uk (actually host lamin.bath.ac.uk) by goggins.bath.ac.uk with SMTP (PP); Thu, 7 Nov 1996 13:11:38 +0000 Date: Thu, 7 Nov 1996 13:11:18 +0000 (GMT) From: Andy Powell X-Sender: lisap@lamin.bath.ac.uk To: Leslie Daigle Cc: Larry Masinter , urn-ietf@bunyip.com Subject: Re: [URN] URN-WG home page w/references In-Reply-To: <199611051140.GAA13431@beethoven.bunyip.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Andy Powell Errors-To: owner-urn-ietf@bunyip.com On Tue, 5 Nov 1996, Leslie Daigle wrote: > Yes, there is a homepage for the group, although I have not had time to > update it since we became a working group. > > It lives at: > > http://www.bunyip.com/research/urn-ietf/ > > Suggestions for content are welcomed... In a slightly wider context... As part of a European project that we're working on here I've been building a (somewhat unstructured) list of resources related to the identification of 'electronic publications'. http://www.ukoln.ac.uk/BIBLINK/wp2/links.html It includes pointers to information about URNs, PURLs and various schemes either currently in use by or proposed by the publishing/library communities (ISBN, ISSN, PII, SICI, DOI, CIS, ISWC...). Andy. -- UK Office for Library and Information Networking University of Bath, Bath, BA2 7AY, UK Voice: +44 1225 323933 http://homes.ukoln.ac.uk/~lisap/ Fax: +44 1225 826838 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA25374 for urn-ietf-out; Thu, 7 Nov 1996 06:28:12 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA25369 for ; Thu, 7 Nov 1996 06:28:09 -0500 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20047 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 06:28:07 -0500 Received: from [193.12.104.243] (paf-hemma.swip.net [193.12.104.243]) by nic.cafax.se (8.8.2/8.8.2) with ESMTP id MAA05625; Thu, 7 Nov 1996 12:26:35 +0100 (MET) X-Sender: m-3329@mailbox.swip.net Message-Id: In-Reply-To: References: <"josef.ifi..460:06.10.96.10.44.08"@ifi.unizh.ch> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 7 Nov 1996 10:53:40 +0100 To: Jon Knight , Martin J Duerst From: Patrik Faltstrom Subject: Re: [URN] I18N does not belong in URNs Cc: moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com At 11.36 +0000 96-11-06, Jon Knight wrote: >> ISBNs don't qualify. They are not persistent. > >Aren't they? Crumbs, that means that the one scheme everyone is always >going on about grandfathering in URNs can't be grandfathered. Bummer. I >wonder if that will stuff up our library OPAC? How long does an ISBN >exist for until it gets reassigned to another publisher? It is at least in Sweden (ISBN series that start with 91) the case that it is the publisher that decides how persistent the ISBN is. For most books, most publishers do keep the ISBN very long lived, and does not reassign them. A new ISBN is given to a new version of a book, but not a new printing. For educational materials, pens, paper (yes, most things that a publisher or bookstore sells can because of the billing system most easily be handled if the "thing" have a ISBN) the ISBNs are more temporary. I know at least one publisher in Sweden that only had one ISBN allocated during one print of a book. I.e. assigned a new ISBN for a new print. They also reused ISBNs after about a year. So, to conclude, even inside the namespace of ISBNs, each organization giving out ISBNs do decide themselves what persistence is regardless of what rules there is globally for "global" ISBNs. This is _exactly_ why bookstores exists that have very advanced databases to be able to handle an order of an ISBN that have been replaced 15 times with new number because of reprints and the case that the publisher uses the ISBN as an identifier for the specification of that very print of the book, not the contents. But, I am not saying that ISBNs can not be used as URNs. In most cases, for _real_ books, an ISBN is persistent information about a book. Probably a new ISBN for each edition, but library cards include information about all possible ISBNs for one book, if you know one of them. My point is that local descisions for local parts of the namespace can have local rules for things like persistance. Patrik -------------------------------------------------------------------- Senior Researcher, Tele2/SwipNet Stockholm, Sweden paf@swip.net Phone: +46-8-56264000 urn:inet:urn.paf.se In theory, there's no difference between theory and practice, but in practice, there is. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA25253 for urn-ietf-out; Thu, 7 Nov 1996 06:04:10 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA25248 for ; Thu, 7 Nov 1996 06:04:08 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19965 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 06:03:44 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA20001; Thu, 7 Nov 96 12:08:42 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA01299; Thu, 7 Nov 1996 12:03:31 +0100 Date: Thu, 7 Nov 1996 12:03:31 +0100 From: "Dirk.vanGulik" Message-Id: <9611071103.AA01299@ jrc.it> To: urn-ietf@bunyip.com Subject: [URN] Pending Messages, reboot of elec/139.191.71.138 X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Dirk.vanGulik" Errors-To: owner-urn-ietf@bunyip.com Pending Message: uucp/11 days, 2 left; postmaster@jrc.it, dirkx@elec, postmaster@elec.isei.jrc.it --- Ron, About the last URN HTTP-alike resoving GET / HTTP/1.0 GET N2L/cid:foo%40huh.com HTTP/1.0 GET N2L/cid:foo%40huh.com HTTP/1.1 As expressed before, I am quite unhappy with using a 'fudged' (partial) URI in the request, rather than a proper METHOD or a real different syntax easy to recognize. Althoug I now agree that the META method I was advocating in the past in nowhere near flexible enough. If you look at the way the proxy requests and current 'full' urls in http 1.1 got squeezed in, I think we have a clear example of what a mess this gives in the long run when new protocols are added. RFC1738-> ; HTTP httpurl = "http://" hostport [ "/" hpath [ "?" search ]] hpath = hsegment *[ "/" hsegment ] hsegment = *[ uchar | ";" | ":" | "@" | "&" | "=" ] search = *[ uchar | ";" | ":" | "@" | "&" | "=" ] Looking at RFC1738 I realize that the use of the '/' before the colon and the absense of the initial '/' should perhaps give enough of a guarantee that both a partial is very easy, especially for proxies; and overloding such a little 'hole' in the specification for extension seems bad practice to me; the future will bring more and more proxies en-route, mixed 1.0, 1.1 and 1.x server/client combinations of different vendors. And a lot f servers are moving away from being essential unix file based into database retrival engines; for whom the bit after the '/' is just a token. So why not really split dimensions, and make it a separate method: N2L, N2C or N2N, ... I can assure you that, if this is the way to go; servers like apache can be augmentated to pass on the method, and to accept handlers for arbitrary methods. For testing purposes, there is a copy of a module in Contrib/incoming. And while on the subject; the HTTP\/(\d+)\.(\d+) string; do we _really_ want that ? given that with the above will need an add-on. How about URNRESOLV/version.version. :-) Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA24682 for urn-ietf-out; Thu, 7 Nov 1996 04:38:35 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA24677 for ; Thu, 7 Nov 1996 04:38:32 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18638 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 04:38:25 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Thu, 7 Nov 1996 09:37:38 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Thu, 7 Nov 1996 09:37:19 +0000 Received: from Ant.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Thu, 7 Nov 96 09:36:25 GMT Message-Id: <2.2.32.19961107093626.006c2f7c@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Nov 1996 09:36:26 +0000 To: Renato Iannella From: Bob Briscoe Subject: Re: Re[2]: [URN] Resolution Services (N2L etc) Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com At 10:13 07/11/96 +1000, Renato Iannella wrote: >Bob Briscoe wrote: >> If you insist, for instance, that the URC and the resource both have the >> same URN, you are mandating that a URC must be authored with the permission >> of the same domain of authority as the author of the resource itself (or >> vice versa). This stops people *independently* publishing URCs about other >> people's resources. Now where would the Web be today if you had to get >> someone's permission to link to them? > >I get a good feeling knowing that if I resolve a URN, I will >get back a URC describing that resource, created and maintained >by the owners (or their agents) - and not a third party >review of the resource. If I wanted that, then I would go >to such a service provider. > >If I publish a URN like >which points to a Technical Report at the DSTC - you can >quote it in a Web Page - and like everything - I can only >guarantee that it will last the lifetime of the DSTC. > >If you wish to provide a review of that Technical Report >(via a URC or whatever) then you are free to, and to allocate >you own URN, say . > So now, the URN resolution service is doing authentication of metadata too! Whoaaaa! There are so many assumptions flying around this working group that aren't documented in the framework. Hadn't you better look at your security if this is a goal? What if my URC describes my payment service and says it only charges 2% commission when in fact it charges 20%? Would the user be able to claim that this unsigned information misled them into using your payment service on the basis that it was the authentic metadata tied to the payment service via DNS (rather than someone else's possibly innocently out of date information)? Would a good lawyer be able to prove DNS could have been compromised and get the payment service operator off the hook? Yes. Why don't you just keep it simple. URNs are a base building block. If you just stick to name to address mapping, it's less likely to break in the future. If you want to authenticate metadata, the (now expired) drafts on URCs (e.g. Ron Daniel's URC Scenarios and requirements http://www.acl.lanl.gov/URI/Scenarios/scenarios_3.asc ) proposes signing the metadata which would also be able to tie the resource to the URC by reference so you could find it from the URC's name). >I don't wish to allocate a URN _directly_ to the Technical >Report - because I reserve the right to move it around our >network and to change its form. Don't see the problem - that's what URNs are for. 1. If you had a URN for the URC and an URN for the resource, the URC would just have to refer to the resource's URN. 2. You could just have a URN for the URC which would refer to the resource addresses directly and be the thing you update if the resources move around 3. You could just have a URN for the resources of you didn't want to bother with URCs What I was complaining about is the apparent assumption that the same URN would be used for both URN and URC and one would have to say N2C if you wanted the former, and N2L for the latter. What if BT want to sub-contract our resource description to a trusted third party so customers find it *more* believable than our own advertisements? The TTP might be willing to take liability for their descriptions but don't want the hassle of co-ordinating every URN registration with me? Ron's proposal: DSTC happy, BT happy. Your proposal: DSTC happy, BT sad. I would prefer there to be as near to zero assumptions as to how people might want to use URNs as possible. Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA23455 for urn-ietf-out; Thu, 7 Nov 1996 01:40:14 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA23450 for ; Thu, 7 Nov 1996 01:40:11 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17992 (mail destined for urn-ietf@services.bunyip.com); Thu, 7 Nov 96 01:40:07 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id AAA01984; Thu, 7 Nov 1996 00:35:39 -0600 (CST) Date: Thu, 7 Nov 1996 00:35:39 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611070635.AAA01984@ncsa.uiuc.edu> To: leslie@bunyip.com (Leslie Daigle) Cc: Daniel LaLiberte , "Karen R. Sollins" , urn-ietf@bunyip.com Subject: Re: [URN] some comments In-Reply-To: <199611032218.RAA12973@beethoven.bunyip.com> References: <199611032218.RAA12973@beethoven.bunyip.com> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com With all the activity on the URN list in just the last couple days, it seems like ancient history to bring up the name-location issue again. (You may have thought it was in the first place, but I think that is the wrong perspective to take. See below.) Instead, I'll just clarify a couple things here (and I'll respond briefly to a couple other postings later), and perhaps more importantly I'll make some meta-comments on the process. After that Leslie and I and anyone else who wants to participate will thrash it out off of this list and bring the result back. Email me if you are interested. I do this not with resignation, but because I hope it will be more effective. I expect you will consider the issue "on hold" in the meantime rather than decided by default. Leslie Daigle writes: > > Dan, > > For all the words that have flown about on this mailing list in the past > few days, I don't really think you've made it clear what you want out > of this particular thread. The issue came up when Karen expressed concern over the optional "urn:" prefix. Apparently, it doesn't help to make "urn:" optional in an attempt to avoid the problems and subsequent discussion. > Let me be fairly blunt in my interpretation > here, and you can tell me on which counts I have misunderstood you. > > I think there are 2 separate things in what you have been saying: > > . whether or not URNs are any different than URLs Yes, that is the main thing we have been discussing. Note: this is equivalent to whether or not URLs are any different than URNs. The issue also has to do with whether and how you bind an identifier with its resolution mechanism. So it is intimately related to (not separate from) the second question: > . whether or not URNs can be implemented using URL mechanisms No, not exactly. In fact, I have said several times that I believe we need the persistence being designed into the URN mechanisms, so it is more pertinent to ask whether URLs can be resolved with URN mechanisms. (But there is more to it than that.) > Let me say, as co-chair of this working > group, that this WG starts from the premise that there _is_ a difference > between URNs and URLs, and that our chartered purpose is ... This is largely a meta-comment: Standing on premise and charter as an argument is legalistic and dogmatic. That's dangerous, although it may lead to short term productivity. If the IETF actually works this way now, it is in danger of losing the valuable process which has made it work so well so far. Documented consensus should not be used as a wedge on future possibilities but as a foundation upon which to build. If it turns out the foundation is flawed, do we attempt to fix it or build on it anyway? Even standards are revised over time, so why should a charter be held up to be obeyed with more rigor? > ... To stick to our charter ... is a reflection of the fact that > this is a directed effort. That has a positive ring to it. All I'm trying to do is redirect the effort a bit. I wouldn't be here if I didn't think there was merit in most of the effort. How many people believe the "waterfall" approach to software development should be followed strictly with never a revision or retraction of the earlier steps along the way? We are following the waterfall model by establishing a charter, and similarly, by establishing URN requirements, and then sticking to these earlier decisions as if they were written in concrete. I think a big part of the problem with this whole process is reflected in partly why some IETF working groups have been dissolved. Remember "Rough consensus and working code". We seem to be forgetting about the working code part. The value of the working code is that it forces the issue of what makes sense in the real world. Requirements may crumble in the face of practical realities. So how do we make progress while the foundation may be shifting? It is done in practice all the time, so I wouldn't worry about that too much. We may waste more time arguing over whether we should allow a change in the foundation than just deciding what needs to be changed. Karen has repeatedly expressed concern about making progress, and I share that concern, but is coming to an understanding of the issues not making progress? > > This is not a matter of just agreeing on a definition - it is a matter > > of having definitions that make sense. > > A relative term -- I think the definitions make perfect sense. I'm willing to argue with you about what makes sense. I'm not willing to argue legalities. Nor do I believe this is a religious issue in the sense that it comes down to a matter of opinions. There is very little religion in mathematics. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA21135 for urn-ietf-out; Wed, 6 Nov 1996 20:52:27 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA21130 for ; Wed, 6 Nov 1996 20:52:25 -0500 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16212 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 20:52:23 -0500 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa26936; 6 Nov 96 20:52 EST Received: by skadhwe.lcs.mit.edu; (5.65v3.2/1.1.8.2/15Aug95-0306PM) id AA06320; Wed, 6 Nov 1996 20:52:18 -0500 Date: Wed, 6 Nov 1996 20:52:18 -0500 Message-Id: <9611070152.AA06320@skadhwe.lcs.mit.edu> From: Lewis Girod To: tallen@fsc.fujitsu.com Cc: urn-ietf@bunyip.com In-Reply-To: <199611070035.QAA22323@ishtar.fsc.fujitsu.com> (message from Terry Allen on Wed, 6 Nov 1996 16:35:41 -0800 (PST)) Subject: Re: [URN] Re meaningful names Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com Date: Wed, 6 Nov 1996 16:35:41 -0800 (PST) From: Terry Allen Well, no. The name is the name; if you come to dislike it or think it doesn't mean the right thing you can map something else onto it in a new name space. If an existing name space uses "Mainframes", so be it; it will still work just fine as part of an unambiguous identifier (even if users have to be told "what name space FOO calls Mainframes we now call Enterprise Systems"). Right, that was what I meant by ``overall cruftiness''. At any given time large portions of the namespace are providing backwards compatibility for out-of-date semantics. | Of course, as you point out there is no way to stop people from | putting semantics into names; the most effective way to deal with the | issue is to implement a system of user friendly names over the top of | URNs; 99% of the time the user would see and type only a UFN, and | these UFNs would be resolved to the URNs that could then be used as | long-lived references. Twice the work or more, doesn't deal with grandfathering, prone to error; the most effective way to deal with the issue is to drop your objection to meaningful names. It is more work (though how much more is hard to say), but it might prove really useful. I don't think it would impact grandfathering at all; grandfathered names could have a UFN alias or they might just be typed in as URNs. Prone to error? UFNs wouldn't have the longevity characteristics that URNs hopefully would have, if that's what you mean -- that's why you don't use them in published links. Lewis: | One idea we were experimenting with here was to use a subset of ASCII | that included only numerals, punctuation and consonants, which would | make most words hard to express (at least in some languages). I cannot imagine that such an approach would find favor in the real world. Outside of the context of a UFN infrastructure, no; but the real world has found utility in many namespaces as unfriendly as that... as long as people don't have to get too involved with them. As for whether such a scheme would ever gain real world acceptance, that probably depends largely on the implementation of a UFN scheme, and whether the real world finds it to be sufficient for their purposes. This discussion of UFNs is probably getting off the topic -- the part of this opinion that is relevant to the topic is that in the backs of our minds we should remember that semantics in names and longevity seem to be at cross purposes, and it would be nice if at some time in the future most new names were free of semantics. Given that, should we build in additional mechanisms specifically to support semantics in URNs? -lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA21088 for urn-ietf-out; Wed, 6 Nov 1996 20:46:23 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA21083 for ; Wed, 6 Nov 1996 20:46:20 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16165 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 20:46:19 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id UAA08973; Wed, 6 Nov 1996 20:46:17 -0500 Date: Wed, 6 Nov 1996 20:46:17 -0500 Message-Id: <199611070146.UAA08973@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: jayhawk@dsm0.ds.internic.net Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com In-Reply-To: <9611070116.AA15963@mocha.bunyip.com> (jayhawk@dsm0.ds.internic.net) Subject: Re: [URN] Comments on "I18N does not belong in URNs" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com First I have to apologize, because I should have added an indication that that wasn't an entirely serious remark. Apology accepted. Truthfully, I was at least as concerned that the group as a whole not take your comment seriously:-) In a more directed vein, syntax draft already breaks 1737. Specifically, I'm refering to the "case insensitivity" requirement (the draft current has the NSS being case sensitive). "Case-insensitivity" is itself tied up in what character set we use. If we treat the NSS as a series of octets, then we can't have case insensitivity, because we haven't set a character set (ho boy am I digressing...) We ALSO spent many hours arguing over this one. There were three camps, those who thought case sensitivity was important, those who thought that case insensitivity was important and those who thought we just needed a single decision on it. As I remember it, the consensus really went with the third group and we just had to go one way or the other. So, although I'd really like not to have those discussions again, I believe that the majority didn't feel strongly one way or the other (unlike many of the other issue in that document:-) Karen Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA21045 for urn-ietf-out; Wed, 6 Nov 1996 20:35:51 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA21040 for ; Wed, 6 Nov 1996 20:35:49 -0500 From: jayhawk@dsm0.ds.internic.net Received: from dsm0.ds.internic.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16106 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 20:35:48 -0500 Message-Id: <9611070135.AA16106@mocha.bunyip.com> Date: Wed, 6 Nov 96 20:35 EST To: moore@cs.utk.edu, sollins@LCS.MIT.EDU Cc: urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs Content-Length: 1716 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: jayhawk@dsm0.ds.internic.net Errors-To: owner-urn-ietf@bunyip.com >I would like to be more specific about Keith Moore's statement: > > URNs should be precise enough that a human isn't required to > disambiguate the result. > >In particular, in light of the following requirement from RFC 1737 > > o Global uniqueness: The same URN will never be assigned to two > different resources. > >the URN will refer to exactly one resource from the perspective of > ^^^^^^^^^^^^^^^^^^^^^^^ >that naming authority assigning the name. This is actually a >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >complicated problem having to do with who believes which things are >"the same" by what definition. This was carefully crafted after >lengthy and heated discussion. Before we launch into another lengthy >discussion about this, I recommend to all of you who were not involved >in the first round of this that you think about it VERY hard. Each >naming authority is making a declaration about its own model of >"sameness". This is not in the eye of the beholder, but in the eye of >the namer. And it is that that we are expressing in URNs. We are >saying that if you have two URNs and they are "the same" under some >simple rules for canonicalizing them (also mentioned in 1737), then by >some definition known to the naming authority (although not >necessarily known to the holder of the URN) they identify and always >will the same resource. Having thought about this in the specific context of the syntax draft, I am in complete agreement with the statement as I have quoted it. I would note that simple here implies (in my mind) very limited knowledge (read none) of the namespace itself. I don't think we want to change that. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA20903 for urn-ietf-out; Wed, 6 Nov 1996 20:16:44 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA20898 for ; Wed, 6 Nov 1996 20:16:42 -0500 From: jayhawk@dsm0.ds.internic.net Received: from dsm0.ds.internic.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15963 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 20:16:41 -0500 Message-Id: <9611070116.AA15963@mocha.bunyip.com> Date: Wed, 6 Nov 96 20:16 EST To: jayhawk@ds.internic.net, sollins@LCS.MIT.EDU Cc: urn-ietf@bunyip.com Subject: Re: [URN] Comments on "I18N does not belong in URNs" Content-Length: 2341 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: jayhawk@dsm0.ds.internic.net Errors-To: owner-urn-ietf@bunyip.com Karen R. Sollins said: >Ryan Moats said: > > Well, RFC 1737 is informational so we can break it IF WE HAVE GOOD > REASON and consensus. (This is a null statement, but I wanted to make > it anyway). > >It is informational because it is neither the specification of a >protocol nor the specification of protocol payload, and therefore >cannot be standardized. Beyond that, consider it a standard. It is >the base from which we are working. We went over all much of the >ground be rediscovered here and more and reached consensus in order to >produce 1737. If we are always in a state of flux where we cannot >make assumptions based on previous consensus reached, we will NEVER >make progress and this is a futile exercise. I'm sure we all have >better things to do. So, take it as a given that RFC 1737 stands. If >there is consensus that it doesn't, this working group must be >disolved. > First I have to apologize, because I should have added an indication that that wasn't an entirely serious remark. Having said that, I still claim that as we move forward, we have the right to realize that something in 1737 isn't optimal or doesn't work etc. My opinion is that if there is rough consensus in the WG, then saying "but 1737 says that's a no-no" doesn't cut it. In a more directed vein, syntax draft already breaks 1737. Specifically, I'm refering to the "case insensitivity" requirement (the draft current has the NSS being case sensitive). "Case-insensitivity" is itself tied up in what character set we use. If we treat the NSS as a series of octets, then we can't have case insensitivity, because we haven't set a character set (ho boy am I digressing...) I do have an issue that folks either haven't been thinking about or have tabled until other things get settled, and that is the whole escaping issue. Will we ever want to escape octets of the URN at the client? Now, I discount transport encoding with the assumption that the transport mechanism has to unencode the URN before passing it up. The syntax draft was written assuming that we would, but that seems to create all sorts of troubles if we allow namespaces to set up their own escape mechanisms (and allow non restricted octets in the URN). Does anybody have an opinion on this? Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA20869 for urn-ietf-out; Wed, 6 Nov 1996 20:13:32 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA20864 for ; Wed, 6 Nov 1996 20:13:30 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15932 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 20:13:25 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id UAA15866; Wed, 6 Nov 1996 20:12:46 -0500 (EST) Message-Id: <199611070112.UAA15866@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Karen R. Sollins" Cc: moore@cs.utk.edu, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Wed, 06 Nov 1996 20:06:02 EST." <199611070106.UAA09788@lysithea.lcs.mit.edu> Date: Wed, 06 Nov 1996 20:12:46 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > I would like to be more specific about Keith Moore's statement: > > URNs should be precise enough that a human isn't required to > disambiguate the result. > > In particular, in light of the following requirement from RFC 1737 > > o Global uniqueness: The same URN will never be assigned to two > different resources. > > the URN will refer to exactly one resource from the perspective of > ^^^^^^^^^^^^^^^^^^^^^^^ > that naming authority assigning the name. Yes, this is exactly correct. But what this means is that if you ask the naming authority to do resolution on a URN, you won't get back references to multiple resources. Contrast this with a search for matches to a user-friendly string, which always has the potential for multiple hits. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA20775 for urn-ietf-out; Wed, 6 Nov 1996 20:07:02 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA20765 for ; Wed, 6 Nov 1996 20:06:59 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15871 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 20:06:58 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id UAA09788; Wed, 6 Nov 1996 20:06:02 -0500 Date: Wed, 6 Nov 1996 20:06:02 -0500 Message-Id: <199611070106.UAA09788@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: moore@cs.utk.edu Cc: urn-ietf@bunyip.com In-Reply-To: <199611062032.PAA10773@ig.cs.utk.edu> (message from Keith Moore on Wed, 06 Nov 1996 15:32:28 -0500) Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com I would like to be more specific about Keith Moore's statement: URNs should be precise enough that a human isn't required to disambiguate the result. In particular, in light of the following requirement from RFC 1737 o Global uniqueness: The same URN will never be assigned to two different resources. the URN will refer to exactly one resource from the perspective of ^^^^^^^^^^^^^^^^^^^^^^^ that naming authority assigning the name. This is actually a ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ complicated problem having to do with who believes which things are "the same" by what definition. This was carefully crafted after lengthy and heated discussion. Before we launch into another lengthy discussion about this, I recommend to all of you who were not involved in the first round of this that you think about it VERY hard. Each naming authority is making a declaration about its own model of "sameness". This is not in the eye of the beholder, but in the eye of the namer. And it is that that we are expressing in URNs. We are saying that if you have two URNs and they are "the same" under some simple rules for canonicalizing them (also mentioned in 1737), then by some definition known to the naming authority (although not necessarily known to the holder of the URN) they identify and always will the same resource. For those of us who believe that semantics and mnemonics for humans should be handled elsewhere, this is the sum total of the semantics embodied in URNs and that is completely intentional. Note that this says nothing about what happens when you hold two different URNs. All bets are off in that case:-) Karen Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA20485 for urn-ietf-out; Wed, 6 Nov 1996 19:37:19 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA20470 for ; Wed, 6 Nov 1996 19:37:15 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15700 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 19:37:12 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id QAA29668; Wed, 6 Nov 1996 16:34:30 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id QAA22296; Wed, 6 Nov 1996 16:34:47 -0800 (PST) Date: Wed, 6 Nov 1996 16:34:47 -0800 (PST) From: Terry Allen Message-Id: <199611070034.QAA22296@ishtar.fsc.fujitsu.com> To: dgd@cs.bu.edu, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA20472 for urn-ietf-out; Wed, 6 Nov 1996 19:37:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA20465 for ; Wed, 6 Nov 1996 19:37:13 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15698 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 19:37:02 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id QAA29690 for ; Wed, 6 Nov 1996 16:35:19 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id QAA22323 for urn-ietf@bunyip.com; Wed, 6 Nov 1996 16:35:41 -0800 (PST) Date: Wed, 6 Nov 1996 16:35:41 -0800 (PST) From: Terry Allen Message-Id: <199611070035.QAA22323@ishtar.fsc.fujitsu.com> To: urn-ietf@bunyip.com Subject: [URN] Re meaningful names Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com [subject line changed to decouple Unicode from meaningful naming] I wrote: | Our longest-lived names actually are meaningful to humans; to support | your argument you have to establish that semantic drift affects | names specifically (Moby Dick, Julius Caesar, Assurnasirpal) and | that using them in the context of a defined name space does not ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | insulate them from semantic drift. Lewis Girod replied: | The names you are using as examples are all long lived because they | refer to conceptually immutable objects. This is the case in which | names are afforded some protection from semantic drift, although it | does not necessarily protect them completely. Out of context, I can't | tell if you mean Julius Caesar the guy who got stabbed or Julius | Caesar the play (and that was not an issue when JC was around!,) but | in the context of a namespace of people or plays that problem would be | resolved. Either way the name refers to a piece of history that, | whether or not it is well defined, people have an idea of what you | mean that doesn't change too much. Exactly. urn:roman.emperors:julius.caesar is not ambiguous. | However, I think what Keith was getting at was a problem that arises | when semantics is embedded in names in an attept to structure | hierarchical namespaces. The sort of semantic mechanism involved with | categorizing things is much more likely to drift over time; a | collection of companies originally categorized under ``Mainframes'' | might want to recategorize under ``Enterprise systems''. (Over longer | spans of time spellings and meanings of words change -- Julius Caesar | was originally filed under playes perhaps.) In the context of URNs, | every move we make we are stuck with forever... which eventually leads | to silly results and overall cruftiness. There is little point in | having semantically significant names unless you retain semantics that | makes sense as time goes on. Well, no. The name is the name; if you come to dislike it or think it doesn't mean the right thing you can map something else onto it in a new name space. If an existing name space uses "Mainframes", so be it; it will still work just fine as part of an unambiguous identifier (even if users have to be told "what name space FOO calls Mainframes we now call Enterprise Systems"). | Of course, as you point out there is no way to stop people from | putting semantics into names; the most effective way to deal with the | issue is to implement a system of user friendly names over the top of | URNs; 99% of the time the user would see and type only a UFN, and | these UFNs would be resolved to the URNs that could then be used as | long-lived references. Twice the work or more, doesn't deal with grandfathering, prone to error; the most effective way to deal with the issue is to drop your objection to meaningful names. Keith: | > Few people on this planet can accurately transcribe anything. | That's not true. People regularly transcribe telephone numbers, | email addresses, ISBNs, URLs, credit card numbers, etc. with | sufficient accuracy for their purposes. But ask people to Actually, they regularly mistranscribe them. In the past two weeks I have mistranscribed my VISA number and the VIN of my newly acquired used car, precisely because they are inherently meaningless. Martin, I think it was, pointed out the value of meaning for correct transcriptions. I think he's right. But I also think it's an issue this group should not legislate on: tell inventors of new name spaces what you like in the way of good practice, but don't prescribe. | > Your | > last point would have merit were it not that we absolutely must | > be able to grandfather in existing name spaces. | | Yes, we must be able to grandfather existing name spaces *that serve | similar purposes to URNs*. ISBNs qualify. Handles qualify. | Usenet message-ids qualify. But URNs don't have to handle existing | name spaces that don't have the characteristics that URNs have. This is circular argument unless it's grounding in the group's charter. What I find in the charter as Leslie posted it is: "Although the framework will allow URNs to be defined that vary in terms of degree of scalability and persistance, ensuring "user friendliness" of all resultant identifiers is beyond the scope of this group." That's far from saying that URNs shall not be meaningful, legible, or user-friendly. And RFC 1737 (section 5) explicitly takes no position on use of meaningful semantics. I don't find grounding for your argument. | I don't think this is a problem, because I don't think existing URN-like | name spaces are likely to be human friendly in the first place. (If someone | knows of a counterexample, please tell us.) Circular reasoning again. "Human friendliness" is not a defined property of URNs at the moment. Lewis: | One idea we were experimenting with here was to use a subset of ASCII | that included only numerals, punctuation and consonants, which would | make most words hard to express (at least in some languages). I cannot imagine that such an approach would find favor in the real world. Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA20425 for urn-ietf-out; Wed, 6 Nov 1996 19:36:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA20420 for ; Wed, 6 Nov 1996 19:36:33 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15687 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 19:36:30 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id TAA09761; Wed, 6 Nov 1996 19:36:27 -0500 Date: Wed, 6 Nov 1996 19:36:27 -0500 Message-Id: <199611070036.TAA09761@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: jayhawk@ds.internic.net Cc: urn-ietf@bunyip.com In-Reply-To: <3280B0E8.6AF9@ds.internic.net> (message from Ryan Moats on Wed, 06 Nov 1996 09:38:16 -0600) Subject: Re: [URN] Comments on "I18N does not belong in URNs" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com Ryan Moats said: Well, RFC 1737 is informational so we can break it IF WE HAVE GOOD REASON and consensus. (This is a null statement, but I wanted to make it anyway). It is informational because it is neither the specification of a protocol nor the specification of protocol payload, and therefore cannot be standardized. Beyond that, consider it a standard. It is the base from which we are working. We went over all much of the ground be rediscovered here and more and reached consensus in order to produce 1737. If we are always in a state of flux where we cannot make assumptions based on previous consensus reached, we will NEVER make progress and this is a futile exercise. I'm sure we all have better things to do. So, take it as a given that RFC 1737 stands. If there is consensus that it doesn't, this working group must be disolved. Just so you understand, although you are reading a great deal of unanimity (not complete) from those involved in that earlier work, there was a great deal of contention then also. Karen Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA20161 for urn-ietf-out; Wed, 6 Nov 1996 19:14:00 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA20156 for ; Wed, 6 Nov 1996 19:13:54 -0500 Received: from trapdoor.dstc.edu.au by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15494 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 19:13:51 -0500 Received: from fatcat.dstc.edu.au (fatcat.dstc.edu.au [130.102.176.7]) by trapdoor.dstc.edu.au (8.6.9/8.6.12) with ESMTP id KAA29639; Thu, 7 Nov 1996 10:13:48 +1000 Received: (from renato@localhost) by fatcat.dstc.edu.au (8.6.10/8.6.12) id KAA07870; Thu, 7 Nov 1996 10:13:48 +1000 From: Renato Iannella Message-Id: <199611070013.KAA07870@fatcat.dstc.edu.au> Date: Thu, 7 Nov 1996 10:13:47 +1000 (EST) To: rbriscoe@jungle.bt.co.uk Cc: urn-ietf@bunyip.com Subject: Re[2]: [URN] Resolution Services (N2L etc) In-Reply-To: <2.2.32.19961106143106.006dd1d8@sherekhan.jungle.bt.co.uk> X-Mailer: Ishmail 1.3-960829-osf1 Mime-Version: 1.0 Content-Type: text/plain Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Renato Iannella Errors-To: owner-urn-ietf@bunyip.com Bob Briscoe wrote: > If you insist, for instance, that the URC and the resource both have the > same URN, you are mandating that a URC must be authored with the permission > of the same domain of authority as the author of the resource itself (or > vice versa). This stops people *independently* publishing URCs about other > people's resources. Now where would the Web be today if you had to get > someone's permission to link to them? I get a good feeling knowing that if I resolve a URN, I will get back a URC describing that resource, created and maintained by the owners (or their agents) - and not a third party review of the resource. If I wanted that, then I would go to such a service provider. If I publish a URN like which points to a Technical Report at the DSTC - you can quote it in a Web Page - and like everything - I can only guarantee that it will last the lifetime of the DSTC. If you wish to provide a review of that Technical Report (via a URC or whatever) then you are free to, and to allocate you own URN, say . I don't wish to allocate a URN _directly_ to the Technical Report - because I reserve the right to move it around our network and to change its form. Cheers... Renato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dr Renato Iannella http://www.dstc.edu.au/RDU/staff/ri Research Data Network CRC urn:inet:dstc.edu.au:renato:home DSTC Pty Ltd, Uni Qld, 4072, AUSTRALIA phone/fax: +61 7 3365 4310/11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Australian WWW Technical Conference '97 -> http://www.dstc.edu.au/aw3tc Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA20068 for urn-ietf-out; Wed, 6 Nov 1996 18:48:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA20062 for ; Wed, 6 Nov 1996 18:48:43 -0500 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15393 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 18:48:41 -0500 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa26036; 6 Nov 96 18:48 EST Received: by skadhwe.lcs.mit.edu; (5.65v3.2/1.1.8.2/15Aug95-0306PM) id AA06182; Wed, 6 Nov 1996 18:48:00 -0500 Date: Wed, 6 Nov 1996 18:48:00 -0500 Message-Id: <9611062348.AA06182@skadhwe.lcs.mit.edu> From: Lewis Girod To: mduerst@ifi.unizh.ch Cc: tallen@fsc.fujitsu.com, moore@cs.utk.edu, urn-ietf@bunyip.com In-Reply-To: <"josef.ifi..893:06.10.96.10.21.51"@ifi.unizh.ch> (message from Martin J Duerst on Wed, 6 Nov 1996 11:21:49 +0100 (MET)) Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com Date: Wed, 6 Nov 1996 11:21:49 +0100 (MET) From: Martin J Duerst It is very clear that you can't retain semantics as time goes on. "mainframe" may mean something completely different in 5 years, or in 100 years, and it is impossible to predict. If people on Agreed; certainly some names will last longer than others but on the whole ``semantic drift'' is a fact of life. this group seriously would agree to restrict URNs to digits only for this reason, I would understand. But with ASCII as a "restricted" character set, we will definitely get cruftiness, and I see no reason to allow cruftiness for English, but to deny it for most other languages. One idea we were experimenting with here was to use a subset of ASCII that included only numerals, punctuation and consonants, which would make most words hard to express (at least in some languages). The interesting thing is that we already have that, in the current syntax draft. Just call the readable form of it UFNs, and call the encoded form, %HH-escaped, URNs. I have proposed similar names for these things, namely IRNs (internationalized ...). True, those strings are hard to read but it doesn't solve the problem because the URN and the UFN are tightly coupled -- the whole point of UFNs is that they are nicknames with a short lifespan. A UFN should be allowed to change over time without ever changing the aliased URN. -lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA17065 for urn-ietf-out; Wed, 6 Nov 1996 15:52:05 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA17059 for ; Wed, 6 Nov 1996 15:51:56 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13528 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 15:51:38 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id PAA10773; Wed, 6 Nov 1996 15:32:28 -0500 (EST) Message-Id: <199611062032.PAA10773@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: moore@cs.utk.edu (Keith Moore), tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Wed, 06 Nov 1996 18:02:19 +0100." <"josef.ifi..172:06.10.96.17.02.21"@ifi.unizh.ch> Date: Wed, 06 Nov 1996 15:32:28 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > >> >> Your > >> >> last point would have merit were it not that we absolutely must > >> >> be able to grandfather in existing name spaces. > >> > > >> >Yes, we must be able to grandfather existing name spaces *that serve > >> >similar purposes to URNs*. ISBNs qualify. Handles qualify. > >> >Usenet message-ids qualify. But URNs don't have to handle existing > >> >name spaces that don't have the characteristics that URNs have. > > >> And the fact that you > >> don't know about any such namespaces doesn't guarantee that there > >> are no such namespaces. > > I thought I didn't know any such namespaces when I wrote this mail. > But I have become aware that my postal savings account number in > Japan contains a kanji. The set of kanji in this case is limited > to one each for each of the central offices that keeps track of > postal savings accounts. I am very sure also that there are lots > of other examlpes that fit the requirements of URNs at least as > well as ISBNs that contain kanji or other non-ASCII characters. Perhaps. I don't have as big a problem with this, as long as there's a discipline about how they are assigned that prevents URNs from being used as search strings. That's my main worry. (URNs are also supposed to be transcribable, but I recognize that only a very small set of characters is transcribable by everyone on the planet.) Sorry, I can't make heads or tails of this. > So for grandfathering, we have two choices. > > 1) We interpret it as "direct grandfathering of characters", > in which case we have to allow a really wide range > of characters (i.e. ISO 10646). > 2) We interpret it as "indirect grandfathering", in which > case the digits, or whatever small set, will be > enough. I suspect there will be some of each. But we want the transformations from "old identifier" to URN to be simple and easy to remember. Ideally, you just prepend a URN:namespace: string. In some cases it may be necessary to remove punctuation; for instance, we might want to remove '-' characters from ISBNs. But that gets specified on a per-namespace basis. > Choosing ASCII only as for URLs would be very unfair cheating. If the names aren't human meaningful, I don't see what you're complaining about. > >> I definitely hate to see i18n just being moved around and delayed > >> by some people. With UTF-8 in URNs, we have made great progress. > > > >No, this is a big step backward. Just because there is a new layer > >being defined doesn't mean that I18N belongs there. > > > >I18N *is* important -- and I'd be happy to see a draft document or > >draft charter for a working group to define a protocol (say an extension > >of http/html) to resolve human-friendly names into URNs or URLs. > > Why is there a need for an additional protocol layer? > There is no need currently for English, is it? Yes, there is. Human-friendly names are inherently ambiguous, and have ambiguous meanings which require a human being to untangle. (If I ask for "Julius Caesar", do I mean the Shakespeare play or the person or what? Most people would think the name is unambiguous-- after all, they already know what they have in mind and the other meanings will not occur to them. But if you feed "Julius Caesar" to a library catalog, you will get back large numbers of hits. By contrast, if you feed ) URNs should be precise enough that a human isn't required to disambiguate the result. > And I don't want to have to search through long lists > of possible answers just because I use Japanese, whereas > I will get one immediate answer for English. The point is that you will often get multiple answers for English. English names are no more precise than names in other languages. > >> Some protocols (notably FTP) are also going in the direction of > >> UTF-8. Ideally, we will have a uniform solution for both URLs > >> and URNs, based on UTF-8. > > > >No. Ideally, if we figure out how to do this, we will have a > >uniform solution for all URLs. I18N (and even E8H :) absolutely > >doesn't belong in URNs. > > Well, if URLs are uniformly internationalized, I wouldn't > mind about URNs. But I know that there are people, and > this probably includes you, that claim that URLs also > are not designed to be human-friendly. They weren't *designed* to be human-friendly, and they don't do a very good job of it (if nothing else, they're hard to type and you can't easily say them out loud). But URLs tend to reflect their underlying file and directory structures, which *are* (sort of) human-friendly. (really they're more author-friendly) > >For URNs, human-friendliness will be excluded by design. > > I18N and human-friendliness are not the same thing. > For direct grandfathering, I18N is needed. If you are > sure human-friendliness will not sneak into URNs > with ASCII, it will also not sneak into URNs with > UTF-8. I think URNs need restrictions on human-friendliness in either case. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA13984 for urn-ietf-out; Wed, 6 Nov 1996 12:39:38 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA13979 for ; Wed, 6 Nov 1996 12:39:36 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11684 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 12:39:34 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 17:38:43 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 17:38:36 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Wed, 6 Nov 96 17:37:48 GMT Message-Id: <2.2.32.19961106173957.009f6a14@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Nov 1996 17:39:57 +0000 To: Harald.T.Alvestrand@uninett.no From: Bob Briscoe Subject: Re: [URN] Persistence as part of URN framework Cc: Fisher Mark , "urn-ietf@bunyip.com" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com At 15:58 06/11/96 +0100, Harald.T.Alvestrand@uninett.no wrote: >rbriscoe@jungle.bt.co.uk said: >> A URN user is not just someone who clicks on one. It could also be >> someone who publishes one (that you have published) to refer to your >> work in their work. They need to know how long they should reliably >> use your URN. Meta-data that any party might need is a proper >> candidate for holding in infrastructure. > >That's what I called an "URN buyer" >When I get an URN from someone, and apply it to my resources, >I would figure that I "own" that URN. No, no, no. I don't mean the owner of the URN. I mean someone who incorporates someone else's URN string in their work, just like I could stick urn:mailto:Harald.T.Alvestrand@uninett.no in here if you had published that as a URN. Then you are the 'URN buyer' or 'URN owner' I am the 'URN referrer' (inventing a word because quoter, citer etc. sound wobbly) And whoever clicks on the thing once they read this with a URN enabled mail client is the 'URN user'. If I put such an HREF to a URN in a WEB page, for instance, I might want to know how often to check it was still resolvable. > >rbriscoe@jungle.bt.co.uk said: >> Get my drift? >No. I still think the information publisher ("URN buyer) is the one >for which this information is vital, and that the information should >be part of the business contract between the provider of the URN >namespace and the information publisher. >The URN user (the one who looks up the information) should have no >need to know or care. Does this extra clarity change your view? Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA13887 for urn-ietf-out; Wed, 6 Nov 1996 12:23:13 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA13881 for ; Wed, 6 Nov 1996 12:23:11 -0500 Received: from CS.BU.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11543 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 12:23:07 -0500 Received: by cs.bu.edu (8.6.10/Spike-2.1) id MAA25270; Wed, 6 Nov 1996 12:22:49 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 6 Nov 1996 12:27:54 -0500 To: urn-ietf@bunyip.com From: dgd@cs.bu.edu (David G. Durand) Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: dgd@cs.bu.edu (David G. Durand) Errors-To: owner-urn-ietf@bunyip.com At 9:32 PM 11/5/96, Keith Moore wrote: >I don't think this is a problem, because I don't think existing URN-like >name spaces are likely to be human friendly in the first place. (If someone >knows of a counterexample, please tell us.) ISO Formal Public identitfiers are are semi-friendly (human-readable strings in the roman alphabet, assigned by users according to a prescribed organizational protocol). They are also in active, productive use in the SGML community, even without a global resolution service. >(Please note that assuming we can define I18N'ed URLs -- and there is >certainly a better case to be made for these then I18N'ed URNs -- I >would have no problem with this group defining resolution protocols that >can be used with them. It's just that I18N isn't appropriate for the >URN name-space. And I18N'ed URLs aren't in scope for this group.) Well, FPIs don't have that problem (the character set is _very_ restrictive), but, since we have human-readable URNs and they will continue to exist (good idea or not) the issue of I18N is relevant. I am not advocating either side at the moment -- I tend to agree that transcribability of I18N names will be hellish and error prone. On the other hand, eliminating almost all languages in the world from URNs is a big hit. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA13705 for urn-ietf-out; Wed, 6 Nov 1996 12:07:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA13700 for ; Wed, 6 Nov 1996 12:07:35 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11378 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 12:07:28 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01028-0@josef.ifi.unizh.ch>; Wed, 6 Nov 1996 18:02:20 +0100 Subject: Re: [URN] I18N does not belong in URNs To: moore@cs.utk.edu (Keith Moore) Date: Wed, 6 Nov 1996 18:02:19 +0100 (MET) Cc: moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611061542.KAA07371@ig.cs.utk.edu> from "Keith Moore" at Nov 6, 96 10:42:18 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3407 From: Martin J Duerst Message-Id: <"josef.ifi..172:06.10.96.17.02.21"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore wrote: >> >> Your >> >> last point would have merit were it not that we absolutely must >> >> be able to grandfather in existing name spaces. >> > >> >Yes, we must be able to grandfather existing name spaces *that serve >> >similar purposes to URNs*. ISBNs qualify. Handles qualify. >> >Usenet message-ids qualify. But URNs don't have to handle existing >> >name spaces that don't have the characteristics that URNs have. >> And the fact that you >> don't know about any such namespaces doesn't guarantee that there >> are no such namespaces. I thought I didn't know any such namespaces when I wrote this mail. But I have become aware that my postal savings account number in Japan contains a kanji. The set of kanji in this case is limited to one each for each of the central offices that keeps track of postal savings accounts. I am very sure also that there are lots of other examlpes that fit the requirements of URNs at least as well as ISBNs that contain kanji or other non-ASCII characters. Think about a library that collects Buddhist texts. For a specific bidirectionality feature, overriding, the use for part numbers is always cited. This means that there must be part numbers (a typical URN-like example again) that contain Arabic or Hebrew, mixed with numbers and Latin. So for grandfathering, we have two choices. 1) We interpret it as "direct grandfathering of characters", in which case we have to allow a really wide range of characters (i.e. ISO 10646). 2) We interpret it as "indirect grandfathering", in which case the digits, or whatever small set, will be enough. Choosing ASCII only as for URLs would be very unfair cheating. >> I definitely hate to see i18n just being moved around and delayed >> by some people. With UTF-8 in URNs, we have made great progress. > >No, this is a big step backward. Just because there is a new layer >being defined doesn't mean that I18N belongs there. > >I18N *is* important -- and I'd be happy to see a draft document or >draft charter for a working group to define a protocol (say an extension >of http/html) to resolve human-friendly names into URNs or URLs. Why is there a need for an additional protocol layer? There is no need currently for English, is it? And I don't want to have to search through long lists of possible answers just because I use Japanese, whereas I will get one immediate answer for English. >> Some protocols (notably FTP) are also going in the direction of >> UTF-8. Ideally, we will have a uniform solution for both URLs >> and URNs, based on UTF-8. > >No. Ideally, if we figure out how to do this, we will have a >uniform solution for all URLs. I18N (and even E8H :) absolutely >doesn't belong in URNs. Well, if URLs are uniformly internationalized, I wouldn't mind about URNs. But I know that there are people, and this probably includes you, that claim that URLs also are not designed to be human-friendly. >> For URNs, it will be by design, for >> URLs, it will be more by retrofitting, because according to >> the URL syntax document, the individual schemes have full >> autonomy. > >For URNs, human-friendliness will be excluded by design. I18N and human-friendliness are not the same thing. For direct grandfathering, I18N is needed. If you are sure human-friendliness will not sneak into URNs with ASCII, it will also not sneak into URNs with UTF-8. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA13458 for urn-ietf-out; Wed, 6 Nov 1996 11:44:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA13453 for ; Wed, 6 Nov 1996 11:44:34 -0500 Received: from weeble.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11113 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 11:43:45 -0500 Received: from jon by weeble.lut.ac.uk with smtp (Exim 0.55 #1) id E0vLAuZ-0006bD-00; Wed, 6 Nov 1996 16:33:07 +0000 Date: Wed, 6 Nov 1996 16:33:07 +0000 (GMT) From: Jon Knight X-Sender: jon@weeble.lut.ac.uk To: Bob Briscoe Cc: Terry Allen , FisherM@is3.indy.tce.com, urn-ietf@bunyip.com Subject: RE: [URN] Persistence as part of URN framework In-Reply-To: <2.2.32.19961106143207.006bdbbc@sherekhan.jungle.bt.co.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Jon Knight Errors-To: owner-urn-ietf@bunyip.com On Wed, 6 Nov 1996, Bob Briscoe wrote: > I'm saying the framework should require that any solution (like NAPTR) > should allow the option of specifying the longevity of the ability to > resolve the name. > > If you don't allow this, the only people who will ever use this will be > non-commercial organisations who think they are free to say "for ever" > without regard to the consequences. No commercial organisation would enter > into anything which included any commitment "for ever". Great, so this means that we can "commerce-proof" URNs from day one. Definately a +ve feature... :-) Tatty bye, Jim'll -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA13295 for urn-ietf-out; Wed, 6 Nov 1996 11:30:21 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA13290 for ; Wed, 6 Nov 1996 11:30:18 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10923 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 11:29:03 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00995-0@josef.ifi.unizh.ch>; Wed, 6 Nov 1996 17:26:44 +0100 Subject: Re: [URN] I18N does not belong in URNs To: moore@cs.utk.edu Date: Wed, 6 Nov 1996 17:26:43 +0100 (MET) Cc: girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611061530.KAA07042@ig.cs.utk.edu> from "Keith Moore" at Nov 6, 96 10:30:15 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1675 From: Martin J Duerst Message-Id: <"josef.ifi..590:06.10.96.16.26.45"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore wrote: >> If people on >> this group seriously would agree to restrict URNs to digits >> only for this reason, I would understand. > >Except for grandfathering, we could do this. As it is, I think >URNs can generally be restricted so that they're unlikely to be >human-friendly. Existing human-friendly namespaces are unlikely >to meet the requirements for URNs. Namespaces that do meet the >URN requirements will have their own disciplines for assigning names, >which URNs for those namespaces will inherit. New URN schemes >must have a specified discipline for assigning names. I understand what you want. And if everybody that will go to define namespaces and that will use URNs would understand it, too, it might work. But I am realistic in that I don't think things will stay restricted unless the syntax is very strictly restricted. It may be the 10 digits only, or it may be one or two more characters for separation and structure. But if you make it the whole Latin alphabet, even just upper case, people will break your intentions. What about saying that we have the digits plus "-" and "."? Or maybe "*" and "#", because then you can type URNs even on some telephones (don't believe these keys are on all telephones of the world, though). An ISBN namespace would define that "X" is substituted by ".". Other namespaces would need more difficult substitutions. The same types of substitutions would apply to namespaces using latin letters as well as namespaces using characters from other alphabets. Grandfathering would still work, although of course it would be very clumsy. But it would be the same clumsiness for everybody. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12738 for urn-ietf-out; Wed, 6 Nov 1996 10:43:47 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12733 for ; Wed, 6 Nov 1996 10:43:45 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10431 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 10:43:39 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id KAA07371; Wed, 6 Nov 1996 10:42:18 -0500 (EST) Message-Id: <199611061542.KAA07371@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Wed, 06 Nov 1996 11:44:05 +0100." <"josef.ifi..460:06.10.96.10.44.08"@ifi.unizh.ch> Date: Wed, 06 Nov 1996 10:42:18 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > >That's not true. People regularly transcribe telephone numbers, > >email addresses, ISBNs, URLs, credit card numbers, etc. with > >sufficient accuracy for their purposes. But ask people to > >transcribe identifiers in (say) Klingon, or to type them in > >on a keyboard not designed for such, and you'll get much lower > >accuracy. > > Most telephone numbers of companies are meaningful. Really? I don't find that to be true in practice. Looking through my personal phone book, only two out of thirty-one business phone numbers had any string or substring I could recognize as meaningful. > Most > email addresses are meaningful. Many URLs are meaningful. > Transcribability is aided by meaninfulness; there is a smaller > chance to make a mistake if one of these things is meaninful > than without meaningfulness. Yes. But long-term persistance is damaged by meaningfulness. > And Klingon is a VERY bad example. Nobody speaks Klingon. > Nobody grew up with Klingon. Nobody learned Klingon in > school as we learn the Latin script, and others learn > their traditional scripts. And Klingon isn't even in > Unicode. Klingon is a fancy of some SF enthusiasts, > and not a script used by millions every day to express > and exchange their thoughts and feelings. It's not a perfect example. I picked it because it is a foreign language to nearly everybody. > >> Your > >> last point would have merit were it not that we absolutely must > >> be able to grandfather in existing name spaces. > > > >Yes, we must be able to grandfather existing name spaces *that serve > >similar purposes to URNs*. ISBNs qualify. Handles qualify. > >Usenet message-ids qualify. But URNs don't have to handle existing > >name spaces that don't have the characteristics that URNs have. > >Offhand, I don't know of any name spaces that have such characteristics, > >that attempt to be human friendly. > > ISBNs don't qualify. They are not persistent. My understanding is that they're supposed to be persistent, though they are not always so in practice because some countries have too-little ISBN space so they must reassign them. > And the fact that you > don't know about any such namespaces doesn't guarantee that there > are no such namespaces. No, it doesn't. > About 30 years ago, some people said "I don't know of anybody > that would want to use anything else than English on computers". > And then they went on to design protocols :-(. > > > >> We should be building the big tent that everyone can live under, > >> not trying to close out name spaces we don't like. > > > >Yes, and we should also be restricting the problem to something that has > >a hope of a reasonable solution. They're not mutually exclusive, but > >over-reliance on the "one big tent" theory has caused the failure of > >many protocols. > > > >(Please note that assuming we can define I18N'ed URLs -- and there is > >certainly a better case to be made for these then I18N'ed URNs -- I > >would have no problem with this group defining resolution protocols that > >can be used with them. It's just that I18N isn't appropriate for the > >URN name-space. And I18N'ed URLs aren't in scope for this group.) > > When I participated in several attempts and discussions to > internationalize URLs, I was told by several people that have > also shown up on this list that for URLs, i18n would be difficult, > but that it would be solved for URNs. People had different understandings of what URNs are for. > I definitely hate to see i18n just being moved around and delayed > by some people. With UTF-8 in URNs, we have made great progress. No, this is a big step backward. Just because there is a new layer being defined doesn't mean that I18N belongs there. I18N *is* important -- and I'd be happy to see a draft document or draft charter for a working group to define a protocol (say an extension of http/html) to resolve human-friendly names into URNs or URLs. > Some protocols (notably FTP) are also going in the direction of > UTF-8. Ideally, we will have a uniform solution for both URLs > and URNs, based on UTF-8. No. Ideally, if we figure out how to do this, we will have a uniform solution for all URLs. I18N (and even E8H :) absolutely doesn't belong in URNs. > For URNs, it will be by design, for > URLs, it will be more by retrofitting, because according to > the URL syntax document, the individual schemes have full > autonomy. For URNs, human-friendliness will be excluded by design. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12531 for urn-ietf-out; Wed, 6 Nov 1996 10:41:35 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12526 for ; Wed, 6 Nov 1996 10:41:27 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10395 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 10:41:23 -0500 Received: by privateer.windrose.omaha.ne.us; Wed Nov 6 09:38 CST 1996 Message-Id: <3280B0E8.6AF9@ds.internic.net> Date: Wed, 06 Nov 1996 09:38:16 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Keith Moore , URN Mailing List Cc: Terry Allen , Lewis Girod , Martin J Duerst Subject: [URN] Comments on "I18N does not belong in URNs" References: <199611052333.SAA17528@ig.cs.utk.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com All- I'm going to try to munge my replies together to lots of mail that I saw this AM.... Keith Moore wrote (>): > > Support for UTF-8 in URNs is a gross layering violation. It also > violates the requirements of RFC 1737 in several ways: Well, RFC 1737 is informational so we can break it IF WE HAVE GOOD REASON and consensus. (This is a null statement, but I wanted to make it anyway). [Stuff snipped because I smell a rathole] > URNs need to have global scope and to be transcribable. Few people on > this planet could accurately transcribe more than a small percentage > of UTF-8. Even those that could transcribe it could probably not type > most UTF-8 characters on their keyboards. It's also completely > unacceptable to expect people to have a graphical display and hunt > through character menus just to type in a URN. This gets close to the encoding issue, so I postpone comments to below. > UTF-8 cannot be transported unmodified in common Internet protocols. > Even if some of those protocols are being upgraded to support more > charsets, it will be many years before UTF-8 can be transported safely > by these tools. Terry Allen commented (|): |That's an argument specifically against using UTF-8 at all. I'd |like to hear more on this point from the UTF-8 proponents. Martin Duerst replied (@): @The internet as such (TCP/IP) transports any kind of octets whatsoever. @Some of the higher level protocols fail in this respect because @of the short-sightedness of their designers. The worst is E-Mail, @because it works not only on the internet, but also with other @networks. But this is known, and with MIME, it is no problem @anymore. @Also, the URN syntax draft clearly specifies how URNs are @transported over 7-bit channels (using %HH). This works for @URLs, there is no reason it shouldn't work for URNs. @ @So I really wonder where there should be a problem. Well, this is not exactly the way I interpret the syntax draft. Section 3 of the draft states that encoding URNs for transport is the responsibility of the transport protocol. The implied statement is that the transport protocol is responsible for undoing the encoding. The encoding section is there in the case of encoding that the URN resolver has to undo itself. What I wonder (and am looking for some consesus on) is: "Is this necessary?" Also, the %HH escaping technique does have some problems with UTF-8 as Martin has pointed out on another thread... [more stuff snipped because I smell another rathole] > But incorporating UTF-8 in an attempt to make URNs human-readable is > an absolute showstopper. Well, I'll let the folks who asked for it defend why they wanted it, but I know I don't make any mention of human readability in the URN syntax draft. In fact, I view human readability as a namespace feature/bug/design goal and independent of the decision to support UTF-8 in the syntax doc. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12428 for urn-ietf-out; Wed, 6 Nov 1996 10:31:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12423 for ; Wed, 6 Nov 1996 10:31:31 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10288 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 10:31:28 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id KAA07042; Wed, 6 Nov 1996 10:30:16 -0500 (EST) Message-Id: <199611061530.KAA07042@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, moore@cs.utk.edu, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Wed, 06 Nov 1996 11:21:49 +0100." <"josef.ifi..893:06.10.96.10.21.51"@ifi.unizh.ch> Date: Wed, 06 Nov 1996 10:30:15 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > If people on > this group seriously would agree to restrict URNs to digits > only for this reason, I would understand. Except for grandfathering, we could do this. As it is, I think URNs can generally be restricted so that they're unlikely to be human-friendly. Existing human-friendly namespaces are unlikely to meet the requirements for URNs. Namespaces that do meet the URN requirements will have their own disciplines for assigning names, which URNs for those namespaces will inherit. New URN schemes must have a specified discipline for assigning names. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12361 for urn-ietf-out; Wed, 6 Nov 1996 10:24:27 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12356 for ; Wed, 6 Nov 1996 10:24:25 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10219 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 10:24:20 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id KAA06852; Wed, 6 Nov 1996 10:18:33 -0500 (EST) Message-Id: <199611061518.KAA06852@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Martin J Duerst Cc: tallen@fsc.fujitsu.com, moore@cs.utk.edu, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Wed, 06 Nov 1996 11:04:14 +0100." <"josef.ifi..610:06.10.96.10.04.17"@ifi.unizh.ch> Date: Wed, 06 Nov 1996 10:18:33 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > >That's an argument specifically against using UTF-8 at all. I'd > >like to hear more on this point from the UTF-8 proponents. > > The internet as such (TCP/IP) transports any kind of octets whatsoever. > Some of the higher level protocols fail in this respect because > of the short-sightedness of their designers. The worst is E-Mail, > because it works not only on the internet, but also with other > networks. But this is known, and with MIME, it is no problem > anymore. Disagree. Many people do not have MIME mailers; many of those who do have MIME mailers do not have the ability to send or receive UTF-8 in MIME. This isn't going to change anytime soon. Even when it does change, people still won't be able to effectively transcribe arbitrary UTF-8 characters. This idea is a non-starter. > Also, the URN syntax draft clearly specifies how URNs are > transported over 7-bit channels (using %HH). This works for > URLs, there is no reason it shouldn't work for URNs. It doesn't work for URLs either if people see Kanji (or whatever) on their screens (or business cards) but can't type it in. > >| URNs should not be in any language, not even English. I would > >| enthusiastically support requiring all URNs to be in a restricted > >| character set or otherwise discourage human friendliness (though due > >| to grandfathering requirements, each URN scheme would need its own > >| rules for ensuring this). > > > >That's an absolute show-stopper, if you are asking that existing > >naming schemes develop encryption methods to transform their names > >into unreadable strings. People just won't do it because they > >will see it as unreasonable and unnecessary. > > Exactly. And it is also an absolute show-stopper if the "restricted > character set" still allows to use meaningful English, or if the > restricted character set contains characters such as ~[]{}^<>\#|` > ("unsafe" or not) that don't appear on the average non-US keyboard, > or the "$" that can easily be seen as a demonstration of US "superiority". My idea is that each URN scheme should specify its own rules for how to make its part of the name space transcribable. Using odd characters such as those you mention would rule it out. And each URN scheme would also specify the discipline to be used for assigning new names, such that they would not use meaningful English or anything else. As for the '$' and US superiority, get real. I realize lots of people are sensitive about such things, but hopefully we all know that when viewed > Keith, why don't you make an URN syntax proposal that only allows > the characters "0" and "1"? It can easily be shown that with > appropriate, protocol-or-whatever-specific encoding mechanisms, > that will be enough to grandfather whatever has to be grandfathered. I'm not going to dignify this with an answer. > Or why don't you define a specific URN subspace, in which only > numerical digits are allowed, and then see how well it gets populated > in comparison with spaces that allow i18n? You mean like ISBNs? (oh sorry, they use digits '-' and 'X') If you want long-term stable resource identifiers, you don't assign them according to what's popular. > >We should be building the big tent that everyone can live under, > >not trying to close out name spaces we don't like. If we were > >to discourage readability we would find URNs ignored by > >users of at least some name spaces, and we would no longer have > >the unified noncolliding name space we presently contemplate. > > Exactly. URLs were supposedly designed to not be human-readable, > or so I was told by some people that are now on this group. > Current practice shows that this design aim was failed by > a wide margin. URLs inherently reflect the naming structure of their underlying filesystems. That design goal overrode any notions of readability or non-readability for URLs. But URNs should not be bound by such constraints. > Some people have learned something from this > failure, namely that users want readability and meaning. Absolutely they do. But human-friendly identifiers are inherently ambiguous -- if not when they are assigned, then they become ambiguous over time. This is inherent in the way we usually name things -- we borrow meaning from elsewhere and lend it to something new. Names are nearly always imprecise. > They even put it into telephone numbers, which, by the proponents > of non-meaningful URLs/URNs, are cited as examples for well- > working non-meaningful schemes. > > The conclusion is very clear: To deny readability and meaningfulness > is to ignore human nature. Except that URNs aren't really designed for human consumption. (other than transcribability, which isn't really consumption) The spaces to be grandfathered under URNs aren't designed for human consumption either. They do turn out to be useful -- they're just not useful for what you have in mind. > Anyway, incorporating UTF-8 into URNs is not an absolute > showstopper at all. It is the first attempt at recognizing > from the beginnig that i18n is an issue that is important, > and designing a sound solution for it from the beginning. Agreed that I18N is important. But putting UTF-8 in URNs is technically unsound. The sound solution is to put I18N (and all human friendly names) in a layer above URNs. That way, there is a clean separation between searching and fuzzy matching of (inherently ambiguous) human-friendly names, and resolution of computer-friendly resource identifiers. > All other attempts at i18n on the internet were done as > after-thoughts, a fact that lead to many clumsy and suboptimal > solutions. Let's not make this mistake again. Absolutely. Let's therefore not put I18N in a layer where it doesn't belong, and where it cannot work well, and concentrate on building a layer where it will work well. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12346 for urn-ietf-out; Wed, 6 Nov 1996 10:24:09 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12341 for ; Wed, 6 Nov 1996 10:23:37 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10214 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 10:23:05 -0500 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <17119(6)>; Wed, 6 Nov 1996 07:22:42 PST Received: by golden.parc.xerox.com id <2696>; Wed, 6 Nov 1996 07:22:15 PST To: mduerst@ifi.unizh.ch Cc: girod@LCS.MIT.EDU, tallen@fsc.fujitsu.com, moore@cs.utk.edu, urn-ietf@bunyip.com In-Reply-To: <"josef.ifi..893:06.10.96.10.21.51"@ifi.unizh.ch> (message from Martin J Duerst on Wed, 6 Nov 1996 02:21:49 PST) Subject: Re: [URN] I18N does not belong in URNs From: Larry Masinter Message-Id: <96Nov6.072215pst."2696"@golden.parc.xerox.com> Date: Wed, 6 Nov 1996 07:22:15 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com # But with ASCII as a "restricted" character set, we will definitely # get cruftiness, and I see no reason to allow cruftiness for # English, but to deny it for most other languages. You say you see 'no reason' yet a simple reason seems compelling: The upper-case ASCII character set is available to computer users in any language, even when the native language does not use ASCII. For the same reason, many otherwise useful ASCII characters were excluded from URLs because they do not appear in some 'national' character sets: {}|~ etc. Regards, Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA11713 for urn-ietf-out; Wed, 6 Nov 1996 10:00:52 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA11708 for ; Wed, 6 Nov 1996 10:00:50 -0500 From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10059 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 10:00:48 -0500 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <07869-0@domen.uninett.no>; Wed, 6 Nov 1996 15:58:16 +0100 X-Mailer: exmh version 1.6.7 5/3/96 To: Bob Briscoe Cc: Fisher Mark , "urn-ietf@bunyip.com" Subject: Re: [URN] Persistence as part of URN framework In-Reply-To: Your message of "Wed, 06 Nov 1996 14:31:36 GMT." <2.2.32.19961106143136.006e2924@sherekhan.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 15:58:12 +0100 Message-Id: <7866.847292292@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com rbriscoe@jungle.bt.co.uk said: > A URN user is not just someone who clicks on one. It could also be > someone who publishes one (that you have published) to refer to your > work in their work. They need to know how long they should reliably > use your URN. Meta-data that any party might need is a proper > candidate for holding in infrastructure. That's what I called an "URN buyer" When I get an URN from someone, and apply it to my resources, I would figure that I "own" that URN. rbriscoe@jungle.bt.co.uk said: > Get my drift? No. I still think the information publisher ("URN buyer) is the one for which this information is vital, and that the information should be part of the business contract between the provider of the URN namespace and the information publisher. The URN user (the one who looks up the information) should have no need to know or care. Harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA09129 for urn-ietf-out; Wed, 6 Nov 1996 09:31:43 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA09124 for ; Wed, 6 Nov 1996 09:31:40 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09823 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 09:31:29 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:31:04 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:30:46 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Wed, 6 Nov 96 14:29:57 GMT Message-Id: <2.2.32.19961106143207.006bdbbc@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Nov 1996 14:32:07 +0000 To: Terry Allen From: Bob Briscoe Subject: RE: [URN] Persistence as part of URN framework Cc: FisherM@is3.indy.tce.com, urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com Apologies. I had better explain myself better - I've used terminology from a different planet (ISO Open Distributed Processing Reference Model) and been sloppy with it. I'll stick to URN terminology, and be more strict... I'll answer the general point at the end first. >I don't see where you get the idea that a URN has a TTL at all. Where >does the NAPTR proposal say it does? (maybe I missed something) NAPTR doesn't. I said I was criticising the URN framework, not NAPTR, which I just mentioned as an example of what you get if you follow the framework. I'm saying the framework should require that any solution (like NAPTR) should allow the option of specifying the longevity of the ability to resolve the name. If you don't allow this, the only people who will ever use this will be non-commercial organisations who think they are free to say "for ever" without regard to the consequences. No commercial organisation would enter into anything which included any commitment "for ever". At 11:40 05/11/96 -0800, Terry Allen wrote: >Bob Briscoe writes: > >| The point I'm making is that if we (BT) sell or give away a URN (in our role >| as an Internet Service Provider), to give our customers the ability to > >Your role as ISP does not mean that you have to take on the role of >name space owner. I meant that as an ISP we might want to also operate a name space resolver service for a delegated portion of a scheme name space (without necessarily owning the name space itself). As this dual role is obviously causing confusion, lets say BT NSR are the name space resolver and BT ISP wants to be a customer of the resolver service because they consider it commercially advantageous to attract customers in by proving they have a route out if they want. > >| switch suppliers but keep their resource names, we will contract with them >| to do this for a certain time. The URN service should be able to reflect > >You will contract with them to do what for a certain time? Resolve >URNs from a name space you control? I wouldn't want to contract with >a name space owner that promised to resolve my URNs only so long as >I used them as my ISP. Am I missing something? I meant exactly the opposite. That BT ISP would be "retailing" the URN from BT NSR (the "URN wholesaler") to BT ISP's customer, Jo Blow, so she could switch to a different ACME ISP but still keep her URNs. Then ACME ISP might pay the annual URN maintenance fees to BT NSR, and pass the cost on to Jo Blow. > >| this contractual fact so that other independent systems can know how long >| they can rely on that person's URN (e.g. so the third party's content >| management system can re-check HREFs as they are about to become obsolete >| rather than by polling). > >What would make them obsolete? Or do you mean nonresolvable? Sorry, I meant unresolvable. I accept that a URN would never be obsolete if you disallow re-use (but see below as to why this distinction is irrelevant). > >| Once we have contracted to do this, we will *have to* ensure the URN is >| still accessible in terms of network infrastructure and servers. If the user > >And in the same way as before; if your client moves a resource to >another URL, he has to tell you so. What changes about that when >your client moves his resources to another system? Nothing. I'm just saying we need to lay down how long our commitment is before we start. If BT NSR commit to 50 years, while the International Chamber of Commerce NSR commits to 200 years and Dodgy NSR commits to 5 years, Jo Blow, would have a market differentiator for her to decide which ISP she wanted, by which NSR they backed if name longevity was important to her. All I'm saying is that for a multi-collaborative project like the Web, this meta-data (longevity) about a resolution service for a portion of a name scheme is the most useful characteristic to tag URNs with, so that other services that use URNs it resolves can know when to re-check their validity (resolvability). I should clarify that I'm talking about the longevity of the resolution service for a portion of the name space, not of the whole naming scheme itself. The eventuality I envisage is that if this whole idea gets superceded, so we've got very few resolution requests coming in for our portion, we want to be able to wind up without jarring everyone off by surprising them with a notice to quit. Effectively it's putting the principles of ISO9000 (Quality and all that) into even the very long term committments we make. By saying in advance we're going to stop at a certain time, we can always extend it if the thing is still useful, but we have the option not to. This scenario assumes it is unlikely that we will be able to find someone else to take over resolving our bit of the name space - if we don't see a benefit in doing it ourselves, it's unlikely someone else will. > >| has thrown away their Web browser and got SuperCrap5 instead, that's not our >| concern. I'm not saying we are planning doing this, I'm just laying out the >| processes a commercial company would go through before marketing URNs. > >I don't get the point about the user changing browsers. My reply was to Mark Fisher's posting, in particular his phrase: >>>Even then, the data would only >>>persist as long as technical means remained to read the persistent data. I was saying BT NSR can commit to providing service and comms infrastructure for a set length of time, but if the user throws away the hardware or software they used to access BT NSR's service, that's not BT NSR's problem. The phrase "throws away" includes the them breaking it (e.g. by installing an incompatible OS). > >| That's just PURLs - saying certain names are more persistent than others. >| What I'm saying is that for URNs to mean anything, you need the *optional* >| capability to say *how* persistent you mean when you say "pretty persistent" >| because "for ever" is just meaningless. It must be optional because some > >Well, no it isn't. URNs are not to be reassigned; is that more meaningful >for you than "forever"? There are no guarantees (nor can there be any) >that a URN will be resolvable over the Internet forever. Sorry, yes, URNs are superficially better than PURLs in this respect. However, the "no reassignment" rule is unenforceable unless a resolver is available to test whether the URN has already been assigned (this resolver might be a wodge of print-out printed at the point that the on-line resolver was shut down for ever, but this would only be useful in proving a URN had been reassigned after the event). So pragmatically, the "no reassignment" rule amounts to "no reassignment for the life of the resolver", which leads back to my request for a TTL specified for the resolver. > >| people don't want to think about how long "persistent" means. Others might >| not want anyone to infer how long they expect to be in business from the >| length of their TTLs! >| >| A naming service should at minimum deal with the characteristics that you >| can hang on a name >| - persistence of the name > >The *name* is persistent, period. Resolution is another matter. Prove it (see previous comment)! >I don't know what you mean to refer to when you write "naming service". Sorry, I mean "name space resolver service". Final comment: If you accept that pragmatically, URNs don't exist for ever (because they only exist as long as anyone can prove they exist), you can still have the "no reassignment" rule for people to keep to on best effort. IOW, just because urn:duns:001234567:Dunn&Bradstreet_Collapse.report stops being resolvable, anyone who knew of broken references to it well into the future, shouldn't deliberately re-use it for something else. Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA09106 for urn-ietf-out; Wed, 6 Nov 1996 09:31:28 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA09101 for ; Wed, 6 Nov 1996 09:31:26 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09820 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 09:31:20 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:30:37 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:30:17 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Wed, 6 Nov 96 14:29:26 GMT Message-Id: <2.2.32.19961106143136.006e2924@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Nov 1996 14:31:36 +0000 To: Harald.T.Alvestrand@uninett.no From: Bob Briscoe Subject: Re: [URN] Persistence as part of URN framework Cc: Fisher Mark , "urn-ietf@bunyip.com" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com At 10:10 06/11/96 +0100, Harald.T.Alvestrand@uninett.no wrote: >Bob, >your point is well made that there needs to be some mechanism >which allows an URN buyer to make a guess at how long the resolution >service will stay in place. >This is, I believe, properly part of a business arrangement. > >For an URN *user*, this may be interesting, but not vital. A URN user is not just someone who clicks on one. It could also be someone who publishes one (that you have published) to refer to your work in their work. They need to know how long they should reliably use your URN. Meta-data that any party might need is a proper candidate for holding in infrastructure. >It could easily(?) be solved as part of "metadata" on an URN, >together with properties like the changability of the resource >(the URN for "today's weather in Trondheim" has different properties >than the URN for "the weather in Trondheim on Nov 6, 1996 around 10:07" >(cloudy, rainy and about 3 degrees Celsius, BTW)). >But I don't see it as a vital part of the infrastructure. Certainly, I agree it could be metadata held somewhere else. However, because it is meta-data owned directly by the URN (to be precise, the portion of the name space the URN is part of) and because it has important utility, if it *isn't* going to be held in the infrastructure, I believe it is the job of this working group to say how it *would* be held. If you leave this for 'ron (later on) as you suggest, you'll end up having to have a URC for a URN resolution when URCs get sorted, then what URN do you give the new URC? Then you'll need to hold the longevity of the resolution for the new URN somewhere... how about another URC? Get my drift? > >Using DNS TTL records for this is just broken; DNS TTLs are used >to limit caching of name->address mapping, and in the NAPTR proposal, >they should be a fraction of the time one expects to have advance >warning of a server relocation or mapping restructure. >Normal TTLs are on the order of 3 days, and are usually reduced to less >than 1 day before serious network reorganizations. I didn't mean that. I used the term TTL to mean a new Time To Live (of the resolution availability), not the specific TTL that DNS uses. Sorry again for being sloppy with my terminology. Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA09099 for urn-ietf-out; Wed, 6 Nov 1996 09:31:24 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA09094 for ; Wed, 6 Nov 1996 09:31:20 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09817 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 09:30:56 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:30:10 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Wed, 6 Nov 1996 14:29:44 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Wed, 6 Nov 96 14:28:56 GMT Message-Id: <2.2.32.19961106143106.006dd1d8@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Nov 1996 14:31:06 +0000 To: Keith Moore From: Bob Briscoe Subject: Re: [URN] Resolution Services (N2L etc) Cc: urn-ietf@bunyip.com, moore@cs.utk.edu Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com At 23:27 05/11/96 -0500, Keith Moore wrote: >> 1.2 It strikes me that specifying available service requests (N2L, N2R etc) >> should not be the job of DNS or any URN resolution mechanism. You are adding >> metadata about the address that the name resolves to (i.e. allowed methods). >> NAPTR should simply get you to the place you asked for by mapping names to >> addresses. > >Not clear. DNS is the place to store name-to-IP-address bindings. If >the different services (methods) are at different IP-addresses, the >mappings between the names of the machines where the services reside, >and their IP addresses will be managed by DNS. And there's >potentially a big efficiency win to having the name-to-service mapping >lookup occur as a side-effect of an lookup that returns NAPTR records >with an /s flag. As long as everyone is clear that this is an efficiency hack, not a core requirement, and of the potential consequential problems, the purpose of my posting has been met. However, I would like to propose a far cleaner alternative (backed up by a load more words in the paper on URCs I'm about to put out) which doesn't need any efficiency hacks because it removes the need to differentiate between N2C, N2R etc. (and makes multi-collaborative working as easy as single domain - I'll explain why this is a problem below)... Lets take N2* first: N2C: I would propose, that each address mapping you would intend to give as a reply to an N2C or an N2L request, should each be given a different URN. URNs are cheap. As soon as you tie any two things (that are not the same thing) together under one name, you are doing the job of URCs not URNs. If you insist, for instance, that the URC and the resource both have the same URN, you are mandating that a URC must be authored with the permission of the same domain of authority as the author of the resource itself (or vice versa). This stops people *independently* publishing URCs about other people's resources. Now where would the Web be today if you had to get someone's permission to link to them? N2R: I'm much less clear why there is a need to differentiate between N2L and N2R in the first place. The name resolution service will give back a location whatever. It's then up to the client to use it and the protocol it specifies to access the resource if it wants, or not if it doesn't. Nothing else would scale, and any protocol schemes that needed the name resolver service to get resources for it should be killed at birth. Am I missing something? N2Ls & N2Rs: The plural versions are, IMHO, something that should be the default for all clients using URNs, with singular responses just a special case. All DNS BIND clients since some time in 1994 included round robin if they got a list of responses back, so if your user-agent asked BIND for an address it would get just one, but BIND would feed it another one if it asked again. If the user-agent wanted the list directly, there would be nothing stopping it implementing BIND internally. I think I've now reduced all the N2* options to a singular case for each URN - that is "N2Ls". Moving on to the L2* options. L2R, as I said under N2L & N2R (unless I'm missing something) is not the job of URNs. L2N is valid, but DNS already has a far more scalable solution by building a reverse mapping tree topped by a well known name (in-addr.arpa). This could be bent to do reverse NAPTR lookups. Effectively this makes and L2N into an N2Ls. L2L could be done with a reverse then a forward lookup. L2C would be useful, but in practice is unattainable if you want to allow multi-collaborative creation of URCs separate from resources. I have resigned myself to losing this capability in my work on URCs. The only way to do this is to rely on a harvester (like you have to do to find everyone who links to you on the Web today - you put in the URL of your resource as a query to the search engine). So that's thrown out all the proposed L2* opions or reduced them to "N2Ls". The bottom line is, you only need N2Ls or there are better ways to do this, IMHO. > >> Other systems (service discovery or navigation) should allow you to >> determine what you *should* ask for from the address once you get it, and >> once you have the address each protocol scheme might provide a well-known >> method for querying what methods you *can* do if that is what the scheme >> needs (e.g. HTTP/1.1 OPTIONS method). > >Only if all possible methods for a service are available at every >service location. You don't want to have to ask each service location >which methods are available at that server. See above. > >> IOW, the client should already know >> what it is going to do with the address it gets out of the URN service, or >> if it doesn't it should be prepared to find out. > >The client knows what it wants to do. But how the client does what it >wants to do may depend on what services are available. If there are >multiple resolution services available for a particular chunk of name >space, it might be that several of them will do what the client wants. >For example, if all a client wants is a URL, N2L might be more >efficient than N2C. Yes, you get efficiency, but at the expense of independence of collaboration. It would be valid to take the N2* approach to identify the "trusted" URCs if you wanted to do this, and still allow others to independently have other URCs. > >> OK, it may be *easier* to hack it this way, but that's not the point. You >> are embedding a duplication of meta-information in DNS which will always be >> prone to being out of date, unreliable, etc. Especially if the world moves >> to be much more dynamic in this area in the decades you envisage this >> lasting. More importantly, this information potentially has a different TTL >> than the address itself, so it will break your caching. > >I don't see what the problem is. DNS can specify TTLs on a >per-resource-record basis. The problem is that the decision on the *value* for the TTL is easy if it only relates to the life of the mapping. If it relates to the life of the mapping *and* the life of all the resolution services within those mappings, any potential for the automation of the generation of the TTL value has multiple dependencies. The more complexity you introduce, the more problems you get with distributed two phase commits, fraud modes etc. etc. > >At any rate, we should view the use of DNS for resolution as a >short-term experiment rather than a long-term solution. Viewed in >that context, it's not important that we get every little detail >right. Architecture isn't detail. I'm having to define BT's Future Commercial Internet Service Architecture on top of whatever you folks do. If I thought this wasn't important, I would have just kept schtumm and continued to listen to the URN stuff in read-only mode. Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA07668 for urn-ietf-out; Wed, 6 Nov 1996 06:39:31 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA07663 for ; Wed, 6 Nov 1996 06:39:24 -0500 Received: from weeble.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09231 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 06:38:39 -0500 Received: from jon by weeble.lut.ac.uk with smtp (Exim 0.55 #1) id E0vL6HX-0006Kl-00; Wed, 6 Nov 1996 11:36:31 +0000 Date: Wed, 6 Nov 1996 11:36:31 +0000 (GMT) From: Jon Knight X-Sender: jon@weeble.lut.ac.uk To: Martin J Duerst Cc: moore@cs.utk.edu, tallen@fsc.fujitsu.com, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: <"josef.ifi..460:06.10.96.10.44.08"@ifi.unizh.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Jon Knight Errors-To: owner-urn-ietf@bunyip.com On Wed, 6 Nov 1996, Martin J Duerst wrote: > Most telephone numbers of companies are meaningful. Are they? How are they meaningful to anything other than the telcos switching system? (Hint: alphabetic mappings don't work in most of the world and increasingly "area" codes don't tell you anything about the area that the call is destined for or its cost unless you happen to be a telco computer). > Most email addresses are meaningful. Many URLs are meaningful. Granted. And look at the hassle its caused; domain name wars, lawsuits in the States, etc, etc. Nasty. > Transcribability is aided by meaninfulness; there is a smaller > chance to make a mistake if one of these things is meaninful > than without meaningfulness. I disagree; transcribability would be aided by check digits and error correcting codes. Meaning is a red herring, especially as meaning is in people, not in words (as one of my old school textbooks used to say). Other naming schemes (eg ISBNs) have the check digits and aren't meaningful and yet work well. I've just seen too many URLs misprinted in books and newspapers (the UK's Guardian newspaper is the worst offender IMHO) leading to confused and annoyed users (especially when the misprinted URL is itself valid but for a different resource). IMHO this is an a priori proof that meaning does not aid transcribability. I'd like to see some URN schemes appear that are specifically designed to survive mis-transcription. Having said that, I'm easy and if people want to use broken "meaningful" names for URNs, I think that's up to them. Let the buyer beware, etc. > ISBNs don't qualify. They are not persistent. Aren't they? Crumbs, that means that the one scheme everyone is always going on about grandfathering in URNs can't be grandfathered. Bummer. I wonder if that will stuff up our library OPAC? How long does an ISBN exist for until it gets reassigned to another publisher? Tatty bye, Jim'll -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA07466 for urn-ietf-out; Wed, 6 Nov 1996 05:45:18 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA07459 for ; Wed, 6 Nov 1996 05:45:16 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09116 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 05:45:11 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00576-0@josef.ifi.unizh.ch>; Wed, 6 Nov 1996 11:44:06 +0100 Subject: Re: [URN] I18N does not belong in URNs To: moore@cs.utk.edu Date: Wed, 6 Nov 1996 11:44:05 +0100 (MET) Cc: tallen@fsc.fujitsu.com, urn-ietf@bunyip.com In-Reply-To: <199611060233.VAA20653@ig.cs.utk.edu> from "Keith Moore" at Nov 5, 96 09:32:59 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3278 From: Martin J Duerst Message-Id: <"josef.ifi..460:06.10.96.10.44.08"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Keith Moore answers Terry Allen: >> Keith Moore writes: >That's not true. People regularly transcribe telephone numbers, >email addresses, ISBNs, URLs, credit card numbers, etc. with >sufficient accuracy for their purposes. But ask people to >transcribe identifiers in (say) Klingon, or to type them in >on a keyboard not designed for such, and you'll get much lower >accuracy. Most telephone numbers of companies are meaningful. Most email addresses are meaningful. Many URLs are meaningful. Transcribability is aided by meaninfulness; there is a smaller chance to make a mistake if one of these things is meaninful than without meaningfulness. And Klingon is a VERY bad example. Nobody speaks Klingon. Nobody grew up with Klingon. Nobody learned Klingon in school as we learn the Latin script, and others learn their traditional scripts. And Klingon isn't even in Unicode. Klingon is a fancy of some SF enthusiasts, and not a script used by millions every day to express and exchange their thoughts and feelings. >> Your >> last point would have merit were it not that we absolutely must >> be able to grandfather in existing name spaces. > >Yes, we must be able to grandfather existing name spaces *that serve >similar purposes to URNs*. ISBNs qualify. Handles qualify. >Usenet message-ids qualify. But URNs don't have to handle existing >name spaces that don't have the characteristics that URNs have. >Offhand, I don't know of any name spaces that have such characteristics, >that attempt to be human friendly. ISBNs don't qualify. They are not persistent. And the fact that you don't know about any such namespaces doesn't guarantee that there are no such namespaces. About 30 years ago, some people said "I don't know of anybody that would want to use anything else than English on computers". And then they went on to design protocols :-(. >> We should be building the big tent that everyone can live under, >> not trying to close out name spaces we don't like. > >Yes, and we should also be restricting the problem to something that has >a hope of a reasonable solution. They're not mutually exclusive, but >over-reliance on the "one big tent" theory has caused the failure of >many protocols. > >(Please note that assuming we can define I18N'ed URLs -- and there is >certainly a better case to be made for these then I18N'ed URNs -- I >would have no problem with this group defining resolution protocols that >can be used with them. It's just that I18N isn't appropriate for the >URN name-space. And I18N'ed URLs aren't in scope for this group.) When I participated in several attempts and discussions to internationalize URLs, I was told by several people that have also shown up on this list that for URLs, i18n would be difficult, but that it would be solved for URNs. I definitely hate to see i18n just being moved around and delayed by some people. With UTF-8 in URNs, we have made great progress. Some protocols (notably FTP) are also going in the direction of UTF-8. Ideally, we will have a uniform solution for both URLs and URNs, based on UTF-8. For URNs, it will be by design, for URLs, it will be more by retrofitting, because according to the URL syntax document, the individual schemes have full autonomy. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA07183 for urn-ietf-out; Wed, 6 Nov 1996 05:23:11 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA07178 for ; Wed, 6 Nov 1996 05:23:03 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09062 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 05:22:54 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00546-0@josef.ifi.unizh.ch>; Wed, 6 Nov 1996 11:21:50 +0100 Subject: Re: [URN] I18N does not belong in URNs To: girod@LCS.MIT.EDU Date: Wed, 6 Nov 1996 11:21:49 +0100 (MET) Cc: tallen@fsc.fujitsu.com, moore@cs.utk.edu, urn-ietf@bunyip.com In-Reply-To: <9611060236.AA05648@skadhwe.lcs.mit.edu> from "Lewis Girod" at Nov 5, 96 09:36:55 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1929 From: Martin J Duerst Message-Id: <"josef.ifi..893:06.10.96.10.21.51"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Lewis Girod wrote: >However, I think what Keith was getting at was a problem that arises >when semantics is embedded in names in an attept to structure >hierarchical namespaces. The sort of semantic mechanism involved with >categorizing things is much more likely to drift over time; a >collection of companies originally categorized under ``Mainframes'' >might want to recategorize under ``Enterprise systems''. (Over longer >spans of time spellings and meanings of words change -- Julius Caesar >was originally filed under playes perhaps.) In the context of URNs, >every move we make we are stuck with forever... which eventually leads >to silly results and overall cruftiness. There is little point in >having semantically significant names unless you retain semantics that >makes sense as time goes on. It is very clear that you can't retain semantics as time goes on. "mainframe" may mean something completely different in 5 years, or in 100 years, and it is impossible to predict. If people on this group seriously would agree to restrict URNs to digits only for this reason, I would understand. But with ASCII as a "restricted" character set, we will definitely get cruftiness, and I see no reason to allow cruftiness for English, but to deny it for most other languages. >Of course, as you point out there is no way to stop people from >putting semantics into names; the most effective way to deal with the >issue is to implement a system of user friendly names over the top of >URNs; 99% of the time the user would see and type only a UFN, and >these UFNs would be resolved to the URNs that could then be used as >long-lived references. The interesting thing is that we already have that, in the current syntax draft. Just call the readable form of it UFNs, and call the encoded form, %HH-escaped, URNs. I have proposed similar names for these things, namely IRNs (internationalized ...). Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA07096 for urn-ietf-out; Wed, 6 Nov 1996 05:09:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA07091 for ; Wed, 6 Nov 1996 05:09:43 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09038 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 05:08:32 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00516-0@josef.ifi.unizh.ch>; Wed, 6 Nov 1996 11:04:16 +0100 Subject: Re: [URN] I18N does not belong in URNs To: tallen@fsc.fujitsu.com Date: Wed, 6 Nov 1996 11:04:14 +0100 (MET) Cc: moore@cs.utk.edu, urn-ietf@bunyip.com In-Reply-To: <199611060057.QAA25635@ishtar.fsc.fujitsu.com> from "Terry Allen" at Nov 5, 96 04:57:00 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4413 From: Martin J Duerst Message-Id: <"josef.ifi..610:06.10.96.10.04.17"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Terry Allen writes: >Keith Moore writes: >| UTF-8 cannot be transported unmodified in common Internet protocols. >| Even if some of those protocols are being upgraded to support more >| charsets, it will be many years before UTF-8 can be transported safely >| by these tools. > >That's an argument specifically against using UTF-8 at all. I'd >like to hear more on this point from the UTF-8 proponents. The internet as such (TCP/IP) transports any kind of octets whatsoever. Some of the higher level protocols fail in this respect because of the short-sightedness of their designers. The worst is E-Mail, because it works not only on the internet, but also with other networks. But this is known, and with MIME, it is no problem anymore. Also, the URN syntax draft clearly specifies how URNs are transported over 7-bit channels (using %HH). This works for URLs, there is no reason it shouldn't work for URNs. So I really wonder where there should be a problem. >| URNs should not be in any language, not even English. I would >| enthusiastically support requiring all URNs to be in a restricted >| character set or otherwise discourage human friendliness (though due >| to grandfathering requirements, each URN scheme would need its own >| rules for ensuring this). > >That's an absolute show-stopper, if you are asking that existing >naming schemes develop encryption methods to transform their names >into unreadable strings. People just won't do it because they >will see it as unreasonable and unnecessary. Exactly. And it is also an absolute show-stopper if the "restricted character set" still allows to use meaningful English, or if the restricted character set contains characters such as ~[]{}^<>\#|` ("unsafe" or not) that don't appear on the average non-US keyboard, or the "$" that can easily be seen as a demonstration of US "superiority". Keith, why don't you make an URN syntax proposal that only allows the characters "0" and "1"? It can easily be shown that with appropriate, protocol-or-whatever-specific encoding mechanisms, that will be enough to grandfather whatever has to be grandfathered. Or why don't you define a specific URN subspace, in which only numerical digits are allowed, and then see how well it gets populated in comparison with spaces that allow i18n? >We should be building the big tent that everyone can live under, >not trying to close out name spaces we don't like. If we were >to discourage readability we would find URNs ignored by >users of at least some name spaces, and we would no longer have >the unified noncolliding name space we presently contemplate. Exactly. URLs were supposedly designed to not be human-readable, or so I was told by some people that are now on this group. Current practice shows that this design aim was failed by a wide margin. Some people have learned something from this failure, namely that users want readability and meaning. They even put it into telephone numbers, which, by the proponents of non-meaningful URLs/URNs, are cited as examples for well- working non-meaningful schemes. The conclusion is very clear: To deny readability and meaningfulness is to ignore human nature. >| But incorporating UTF-8 in an attempt to make URNs human-readable is >| an absolute showstopper. > >I didn't understand that to be the point of it; I would agree >that if the only reason for using Unicode were to make URNs >readable that wouldn't be a sufficient reason for using it; >but I'm not sure that we can't just append existing names in >their natural coded character set as the NSS part of a URN, >which would have mixed results for readability. (But then >I feel sure I haven't understood all the implications >of that approach.) The problem is that for namespaces that currently only exist on paper, there is no "natural" coded character set. And definitely, as Terry mentionnes, mixing various character encodings in different parts of URNs would make handling software extremely complicated. Anyway, incorporating UTF-8 into URNs is not an absolute showstopper at all. It is the first attempt at recognizing from the beginnig that i18n is an issue that is important, and designing a sound solution for it from the beginning. All other attempts at i18n on the internet were done as after-thoughts, a fact that lead to many clumsy and suboptimal solutions. Let's not make this mistake again. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA06632 for urn-ietf-out; Wed, 6 Nov 1996 04:12:52 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA06627 for ; Wed, 6 Nov 1996 04:12:45 -0500 From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08918 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 04:12:43 -0500 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <03736-0@domen.uninett.no>; Wed, 6 Nov 1996 10:10:24 +0100 X-Mailer: exmh version 1.6.7 5/3/96 To: Bob Briscoe Cc: Fisher Mark , "urn-ietf@bunyip.com" Subject: Re: [URN] Persistence as part of URN framework In-Reply-To: Your message of "Tue, 05 Nov 1996 15:54:31 GMT." <2.2.32.19961105155431.006d63e0@sherekhan.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Nov 1996 10:10:11 +0100 Message-Id: <3693.847271411@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com Bob, your point is well made that there needs to be some mechanism which allows an URN buyer to make a guess at how long the resolution service will stay in place. This is, I believe, properly part of a business arrangement. For an URN *user*, this may be interesting, but not vital. It could easily(?) be solved as part of "metadata" on an URN, together with properties like the changability of the resource (the URN for "today's weather in Trondheim" has different properties than the URN for "the weather in Trondheim on Nov 6, 1996 around 10:07" (cloudy, rainy and about 3 degrees Celsius, BTW)). But I don't see it as a vital part of the infrastructure. Using DNS TTL records for this is just broken; DNS TTLs are used to limit caching of name->address mapping, and in the NAPTR proposal, they should be a fraction of the time one expects to have advance warning of a server relocation or mapping restructure. Normal TTLs are on the order of 3 days, and are usually reduced to less than 1 day before serious network reorganizations. harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA04904 for urn-ietf-out; Wed, 6 Nov 1996 00:16:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA04899 for ; Wed, 6 Nov 1996 00:16:12 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07927 (mail destined for urn-ietf@services.bunyip.com); Wed, 6 Nov 96 00:16:10 -0500 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <16211(7)>; Tue, 5 Nov 1996 21:16:06 PST Received: by golden.parc.xerox.com id <2696>; Tue, 5 Nov 1996 21:15:50 PST To: FisherM@is3.indy.tce.com Cc: rbriscoe@jungle.bt.co.uk, urn-ietf@bunyip.com In-Reply-To: <327F3294@MSMAIL.INDY.TCE.COM> (message from Fisher Mark on Tue, 5 Nov 1996 04:26:00 PST) Subject: Re: [URN] Persistence as part of URN framework From: Larry Masinter Message-Id: <96Nov5.211550pst."2696"@golden.parc.xerox.com> Date: Tue, 5 Nov 1996 21:15:50 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com # But there are no technical hooks to guarantee persistence. On the # cypherpunks list a few months ago, there was a discussion of what it would # take to encrypt a message now, save it away for 100 years, then let the # recipient decrypt the message. The conclusion I drew from that discussion # was that this was a hard problem without a technical solution short of # deploying on every desktop and in every data center a persistent OS that # stored copies of all persistent data. Even then, the data would only # persist as long as technical means remained to read the persistent data. # (How many of us could read a 600 bpi 9-track tape or punched card deck even # if we had to?) Jerry Saltzer & a grad student wrote some papers about long term document retention and the issues of system design for storage that was to last longer than 'mean time between site failure'. (Site failure = flood, earthquake, insurrection, war company bankruptcy, etc.) Their system didn't require global replication, but it was important to be careful, and also not to be to complicated about your replication algorithms. Look for 'Library 2000' somewhere at www.lcs.mit.edu. >From http://www.parc.xerox.com/masinter/www5stds.html: > Some unsolved problems > - stuff goes away > Material behind URLs disappears > - pimples.com > vanity domains for billboard use > - Apple Computer and Apple Music > conflicts over short names > - urn:hdl:MTV/I_quit > how does authority migrate? > - http://www.mitro.paris.fr/mitro > Non-ASCII names Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA04188 for urn-ietf-out; Tue, 5 Nov 1996 23:27:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA04181 for ; Tue, 5 Nov 1996 23:27:42 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07683 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 23:27:40 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id XAA28250; Tue, 5 Nov 1996 23:27:21 -0500 (EST) Message-Id: <199611060427.XAA28250@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bob Briscoe Cc: urn-ietf@bunyip.com, moore@cs.utk.edu Subject: Re: [URN] Resolution Services (N2L etc) In-Reply-To: Your message of "Tue, 05 Nov 1996 10:01:53 GMT." <2.2.32.19961105100153.006d0998@sherekhan.jungle.bt.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Nov 1996 23:27:21 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > 1.2 It strikes me that specifying available service requests (N2L, N2R etc) > should not be the job of DNS or any URN resolution mechanism. You are adding > metadata about the address that the name resolves to (i.e. allowed methods). > NAPTR should simply get you to the place you asked for by mapping names to > addresses. Not clear. DNS is the place to store name-to-IP-address bindings. If the different services (methods) are at different IP-addresses, the mappings between the names of the machines where the services reside, and their IP addresses will be managed by DNS. And there's potentially a big efficiency win to having the name-to-service mapping lookup occur as a side-effect of an lookup that returns NAPTR records with an /s flag. > Other systems (service discovery or navigation) should allow you to > determine what you *should* ask for from the address once you get it, and > once you have the address each protocol scheme might provide a well-known > method for querying what methods you *can* do if that is what the scheme > needs (e.g. HTTP/1.1 OPTIONS method). Only if all possible methods for a service are available at every service location. You don't want to have to ask each service location which methods are available at that server. > IOW, the client should already know > what it is going to do with the address it gets out of the URN service, or > if it doesn't it should be prepared to find out. The client knows what it wants to do. But how the client does what it wants to do may depend on what services are available. If there are multiple resolution services available for a particular chunk of name space, it might be that several of them will do what the client wants. For example, if all a client wants is a URL, N2L might be more efficient than N2C. > OK, it may be *easier* to hack it this way, but that's not the point. You > are embedding a duplication of meta-information in DNS which will always be > prone to being out of date, unreliable, etc. Especially if the world moves > to be much more dynamic in this area in the decades you envisage this > lasting. More importantly, this information potentially has a different TTL > than the address itself, so it will break your caching. I don't see what the problem is. DNS can specify TTLs on a per-resource-record basis. At any rate, we should view the use of DNS for resolution as a short-term experiment rather than a long-term solution. Viewed in that context, it's not important that we get every little detail right. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id XAA04135 for urn-ietf-out; Tue, 5 Nov 1996 23:16:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id XAA04130 for ; Tue, 5 Nov 1996 23:16:44 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07658 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 23:16:40 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id XAA28069; Tue, 5 Nov 1996 23:16:17 -0500 (EST) Message-Id: <199611060416.XAA28069@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Daniel LaLiberte Cc: Patrik Faltstrom , urn-ietf@bunyip.com, moore@cs.utk.edu Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: Your message of "Tue, 05 Nov 1996 00:16:00 CST." <199611050616.AAA21984@ncsa.uiuc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Nov 1996 23:16:17 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > Instead, perhaps you are trying to say that the name is not tightly > bound to information associated with the resource, that the > information can change and still the name is the name of the resource. > For example, the "resolution protocol" can change. I have no problem > with that, and never have. But this is still not abstractly different > from what happens to a URL. You're right, it's not. But the difference between URNs and URLs has almost nothing to do with how they are resolved (indeed, I hope they use the same resolution mechanisms), and a lot to do with how the names are assigned and maintained. That is, some people think it's very useful to have a class of names for which certain properties (long-term persistence, global scope, ..., and the rest of those named in RFC 1737) hold. Those names are called URNs. Yes, they're a lot like URLs in how they are handled. But the whole point in having URNs as a separate name space is: if you know that a particular name is a URN, you know that the RFC 1737 properties hold. (Or if you prefer, an assertion that a name is a URN implies that the RFC 1737 properties hold.) This is why URNs need a URN: prefix -- because a lot of the value in having a URN name space with those properties is so *humans* can recognize a URN when they see it. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA03958 for urn-ietf-out; Tue, 5 Nov 1996 22:22:40 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA03953 for ; Tue, 5 Nov 1996 22:22:38 -0500 Received: from docker.library.uwa.edu.au by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07292 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 22:22:34 -0500 Received: from dehquhp.library.uwa.edu.au (dehquhp.library.uwa.edu.au [130.95.106.230]) by docker.library.uwa.edu.au (8.8.0/8.8.0) with ESMTP id LAA13045; Wed, 6 Nov 1996 11:22:13 +0800 (WST) Message-Id: <199611060322.LAA13045@docker.library.uwa.edu.au> From: "James K. Tauber" To: "Stu Weibel" , , Subject: Re: [URN] URN-WG home page w/references Date: Wed, 6 Nov 1996 11:23:03 +0800 X-Msmail-Priority: Normal X-Priority: 3 X-Mailer: Microsoft Internet Mail 4.70.1155 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "James K. Tauber" Errors-To: owner-urn-ietf@bunyip.com > I think pointers to the PURL page and to the HANDLE page are > certainly in order as the only deployed approaches to persistent > naming at the present time. James Clark's SGML parsing library, SP, and included tools do FPI resolution via the delegating catalogue proposal. So there's another deployed approach. James -- James K. Tauber / jtauber@library.uwa.edu.au University CWIS Coordination Officer The University of Western Australia Room 2.42, Scholars' Centre, Reid Library Phone: +61 9 380 7136 FAX: +61 9 380 1128 Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA03782 for urn-ietf-out; Tue, 5 Nov 1996 21:47:43 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA03777 for ; Tue, 5 Nov 1996 21:47:41 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07182 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 21:47:28 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id VAA23245; Tue, 5 Nov 1996 21:47:13 -0500 (EST) Message-Id: <199611060247.VAA23245@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Lewis Girod Cc: tallen@fsc.fujitsu.com, moore@cs.utk.edu, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Tue, 05 Nov 1996 21:36:55 EST." <9611060236.AA05648@skadhwe.lcs.mit.edu> Date: Tue, 05 Nov 1996 21:47:12 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > Of course, as you point out there is no way to stop people from > putting semantics into names; the most effective way to deal with the > issue is to implement a system of user friendly names over the top of > URNs; 99% of the time the user would see and type only a UFN, and > these UFNs would be resolved to the URNs that could then be used as > long-lived references. Yes. Precisely. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA03706 for urn-ietf-out; Tue, 5 Nov 1996 21:38:08 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA03701 for ; Tue, 5 Nov 1996 21:38:06 -0500 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07139 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 21:38:04 -0500 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa17675; 5 Nov 96 21:36 EST Received: by skadhwe.lcs.mit.edu; (5.65v3.2/1.1.8.2/15Aug95-0306PM) id AA05648; Tue, 5 Nov 1996 21:36:55 -0500 Date: Tue, 5 Nov 1996 21:36:55 -0500 Message-Id: <9611060236.AA05648@skadhwe.lcs.mit.edu> From: Lewis Girod To: tallen@fsc.fujitsu.com Cc: moore@cs.utk.edu, urn-ietf@bunyip.com In-Reply-To: <199611060057.QAA25635@ishtar.fsc.fujitsu.com> (message from Terry Allen on Tue, 5 Nov 1996 16:57:00 -0800 (PST)) Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com Date: Tue, 5 Nov 1996 16:57:00 -0800 (PST) From: Terry Allen Our longest-lived names actually are meaningful to humans; to support your argument you have to establish that semantic drift affects names specifically (Moby Dick, Julius Caesar, Assurnasirpal) and that using them in the context of a defined name space does not insulate them from semantic drift. The names you are using as examples are all long lived because they refer to conceptually immutable objects. This is the case in which names are afforded some protection from semantic drift, although it does not necessarily protect them completely. Out of context, I can't tell if you mean Julius Caesar the guy who got stabbed or Julius Caesar the play (and that was not an issue when JC was around!,) but in the context of a namespace of people or plays that problem would be resolved. Either way the name refers to a piece of history that, whether or not it is well defined, people have an idea of what you mean that doesn't change too much. However, I think what Keith was getting at was a problem that arises when semantics is embedded in names in an attept to structure hierarchical namespaces. The sort of semantic mechanism involved with categorizing things is much more likely to drift over time; a collection of companies originally categorized under ``Mainframes'' might want to recategorize under ``Enterprise systems''. (Over longer spans of time spellings and meanings of words change -- Julius Caesar was originally filed under playes perhaps.) In the context of URNs, every move we make we are stuck with forever... which eventually leads to silly results and overall cruftiness. There is little point in having semantically significant names unless you retain semantics that makes sense as time goes on. Of course, as you point out there is no way to stop people from putting semantics into names; the most effective way to deal with the issue is to implement a system of user friendly names over the top of URNs; 99% of the time the user would see and type only a UFN, and these UFNs would be resolved to the URNs that could then be used as long-lived references. -lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA03645 for urn-ietf-out; Tue, 5 Nov 1996 21:33:25 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA03640 for ; Tue, 5 Nov 1996 21:33:22 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07127 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 21:33:18 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id VAA20653; Tue, 5 Nov 1996 21:33:00 -0500 (EST) Message-Id: <199611060233.VAA20653@ig.cs.utk.edu> X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Terry Allen Cc: moore@cs.utk.edu, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs In-Reply-To: Your message of "Tue, 05 Nov 1996 16:57:00 PST." <199611060057.QAA25635@ishtar.fsc.fujitsu.com> Date: Tue, 05 Nov 1996 21:32:59 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > Keith Moore writes: > | Support for UTF-8 in URNs is a gross layering violation. It also > | violates the requirements of RFC 1737 in several ways: > | > | URNs are not intended to be meaningful to humans. Rather, the desire > | for URNs to have a long lifetime indicates that they should not be > | human-friendly; otherwise, semantic drift will cause those names to > | need to be changed over time. > > Our longest-lived names actually are meaningful to humans; to support > your argument you have to establish that semantic drift affects > names specifically (Moby Dick, Julius Caesar, Assurnasirpal) and > that using them in the context of a defined name space does not > insulate them from semantic drift. Names like those you quote are ambiguous. There are different works named Moby Dick (not just the book by Melville; there are plays, screen plays, radio plays, parodies) and Julius Caesar (not just the play by Shakespeare, but also biographies, screen plays, and at least one symphony). Ambiguous names aren't suitable as URNs. > | URNs need to have global scope and to be transcribable. Few people on > | this planet could accurately transcribe more than a small percentage > | of UTF-8. Even those that could transcribe it could probably not type > | most UTF-8 characters on their keyboards. It's also completely > | unacceptable to expect people to have a graphical display and hunt > | through character menus just to type in a URN. > > Few people on this planet can accurately transcribe anything. That's not true. People regularly transcribe telephone numbers, email addresses, ISBNs, URLs, credit card numbers, etc. with sufficient accuracy for their purposes. But ask people to transcribe identifiers in (say) Klingon, or to type them in on a keyboard not designed for such, and you'll get much lower accuracy. > Your > last point would have merit were it not that we absolutely must > be able to grandfather in existing name spaces. Yes, we must be able to grandfather existing name spaces *that serve similar purposes to URNs*. ISBNs qualify. Handles qualify. Usenet message-ids qualify. But URNs don't have to handle existing name spaces that don't have the characteristics that URNs have. Offhand, I don't know of any name spaces that have such characteristics, that attempt to be human friendly. > | URNs should not be in any language, not even English. I would > | enthusiastically support requiring all URNs to be in a restricted > | character set or otherwise discourage human friendliness (though due > | to grandfathering requirements, each URN scheme would need its own > | rules for ensuring this). > > That's an absolute show-stopper, if you are asking that existing > naming schemes develop encryption methods to transform their names > into unreadable strings. People just won't do it because they > will see it as unreasonable and unnecessary. I don't think this is a problem, because I don't think existing URN-like name spaces are likely to be human friendly in the first place. (If someone knows of a counterexample, please tell us.) > We should be building the big tent that everyone can live under, > not trying to close out name spaces we don't like. Yes, and we should also be restricting the problem to something that has a hope of a reasonable solution. They're not mutually exclusive, but over-reliance on the "one big tent" theory has caused the failure of many protocols. (Please note that assuming we can define I18N'ed URLs -- and there is certainly a better case to be made for these then I18N'ed URNs -- I would have no problem with this group defining resolution protocols that can be used with them. It's just that I18N isn't appropriate for the URN name-space. And I18N'ed URLs aren't in scope for this group.) Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA03031 for urn-ietf-out; Tue, 5 Nov 1996 19:58:21 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA03026 for ; Tue, 5 Nov 1996 19:58:18 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06729 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 19:58:16 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id QAA01084; Tue, 5 Nov 1996 16:56:43 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id QAA25635; Tue, 5 Nov 1996 16:57:00 -0800 (PST) Date: Tue, 5 Nov 1996 16:57:00 -0800 (PST) From: Terry Allen Message-Id: <199611060057.QAA25635@ishtar.fsc.fujitsu.com> To: moore@cs.utk.edu, urn-ietf@bunyip.com Subject: Re: [URN] I18N does not belong in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Keith Moore writes: | Support for UTF-8 in URNs is a gross layering violation. It also | violates the requirements of RFC 1737 in several ways: | | URNs are not intended to be meaningful to humans. Rather, the desire | for URNs to have a long lifetime indicates that they should not be | human-friendly; otherwise, semantic drift will cause those names to | need to be changed over time. Our longest-lived names actually are meaningful to humans; to support your argument you have to establish that semantic drift affects names specifically (Moby Dick, Julius Caesar, Assurnasirpal) and that using them in the context of a defined name space does not insulate them from semantic drift. However, I'm still undecided on using Unicode at all, as I'm sure I don't understand some of the issues. I'll be meeting with Ron tomorrow and will hope to be wiser after that. | URNs need to have global scope and to be transcribable. Few people on | this planet could accurately transcribe more than a small percentage | of UTF-8. Even those that could transcribe it could probably not type | most UTF-8 characters on their keyboards. It's also completely | unacceptable to expect people to have a graphical display and hunt | through character menus just to type in a URN. Few people on this planet can accurately transcribe anything. Your last point would have merit were it not that we absolutely must be able to grandfather in existing name spaces. | UTF-8 cannot be transported unmodified in common Internet protocols. | Even if some of those protocols are being upgraded to support more | charsets, it will be many years before UTF-8 can be transported safely | by these tools. That's an argument specifically against using UTF-8 at all. I'd like to hear more on this point from the UTF-8 proponents. | URNs should not be in any language, not even English. I would | enthusiastically support requiring all URNs to be in a restricted | character set or otherwise discourage human friendliness (though due | to grandfathering requirements, each URN scheme would need its own | rules for ensuring this). That's an absolute show-stopper, if you are asking that existing naming schemes develop encryption methods to transform their names into unreadable strings. People just won't do it because they will see it as unreasonable and unnecessary. We should be building the big tent that everyone can live under, not trying to close out name spaces we don't like. If we were to discourage readability we would find URNs ignored by users of at least some name spaces, and we would no longer have the unified noncolliding name space we presently contemplate. Some name spaces will turn out not to work well, whether on the Internet, in general, or after several centuries. Users of those name spaces will have to cope or convert to other name spaces with better characteristics. That's life. | But incorporating UTF-8 in an attempt to make URNs human-readable is | an absolute showstopper. I didn't understand that to be the point of it; I would agree that if the only reason for using Unicode were to make URNs readable that wouldn't be a sufficient reason for using it; but I'm not sure that we can't just append existing names in their natural coded character set as the NSS part of a URN, which would have mixed results for readability. (But then I feel sure I haven't understood all the implications of that approach.) Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA02378 for urn-ietf-out; Tue, 5 Nov 1996 18:33:31 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA02373 for ; Tue, 5 Nov 1996 18:33:29 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06273 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 18:33:27 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id SAA17528; Tue, 5 Nov 1996 18:33:21 -0500 (EST) Message-Id: <199611052333.SAA17528@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ To: urn-ietf@bunyip.com Subject: [URN] I18N does not belong in URNs Cc: moore@cs.utk.edu From: Keith Moore Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Nov 1996 18:33:21 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com Support for UTF-8 in URNs is a gross layering violation. It also violates the requirements of RFC 1737 in several ways: URNs are not intended to be meaningful to humans. Rather, the desire for URNs to have a long lifetime indicates that they should not be human-friendly; otherwise, semantic drift will cause those names to need to be changed over time. URNs need to have global scope and to be transcribable. Few people on this planet could accurately transcribe more than a small percentage of UTF-8. Even those that could transcribe it could probably not type most UTF-8 characters on their keyboards. It's also completely unacceptable to expect people to have a graphical display and hunt through character menus just to type in a URN. UTF-8 cannot be transported unmodified in common Internet protocols. Even if some of those protocols are being upgraded to support more charsets, it will be many years before UTF-8 can be transported safely by these tools. URNs should not be in any language, not even English. I would enthusiastically support requiring all URNs to be in a restricted character set or otherwise discourage human friendliness (though due to grandfathering requirements, each URN scheme would need its own rules for ensuring this). But incorporating UTF-8 in an attempt to make URNs human-readable is an absolute showstopper. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA22019 for urn-ietf-out; Tue, 5 Nov 1996 14:42:21 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA22013 for ; Tue, 5 Nov 1996 14:42:14 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04304 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 14:42:06 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id LAA24073; Tue, 5 Nov 1996 11:40:26 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id LAA14040; Tue, 5 Nov 1996 11:40:32 -0800 (PST) Date: Tue, 5 Nov 1996 11:40:32 -0800 (PST) From: Terry Allen Message-Id: <199611051940.LAA14040@ishtar.fsc.fujitsu.com> To: FisherM@is3.indy.tce.com, rbriscoe@jungle.bt.co.uk Subject: RE: [URN] Persistence as part of URN framework Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Bob Briscoe writes: | The point I'm making is that if we (BT) sell or give away a URN (in our role | as an Internet Service Provider), to give our customers the ability to Your role as ISP does not mean that you have to take on the role of name space owner. | switch suppliers but keep their resource names, we will contract with them | to do this for a certain time. The URN service should be able to reflect You will contract with them to do what for a certain time? Resolve URNs from a name space you control? I wouldn't want to contract with a name space owner that promised to resolve my URNs only so long as I used them as my ISP. Am I missing something? | this contractual fact so that other independent systems can know how long | they can rely on that person's URN (e.g. so the third party's content | management system can re-check HREFs as they are about to become obsolete | rather than by polling). What would make them obsolete? Or do you mean nonresolvable? | Once we have contracted to do this, we will *have to* ensure the URN is | still accessible in terms of network infrastructure and servers. If the user And in the same way as before; if your client moves a resource to another URL, he has to tell you so. What changes about that when your client moves his resources to another system? | has thrown away their Web browser and got SuperCrap5 instead, that's not our | concern. I'm not saying we are planning doing this, I'm just laying out the | processes a commercial company would go through before marketing URNs. I don't get the point about the user changing browsers. | That's just PURLs - saying certain names are more persistent than others. | What I'm saying is that for URNs to mean anything, you need the *optional* | capability to say *how* persistent you mean when you say "pretty persistent" | because "for ever" is just meaningless. It must be optional because some Well, no it isn't. URNs are not to be reassigned; is that more meaningful for you than "forever"? There are no guarantees (nor can there be any) that a URN will be resolvable over the Internet forever. | people don't want to think about how long "persistent" means. Others might | not want anyone to infer how long they expect to be in business from the | length of their TTLs! | | A naming service should at minimum deal with the characteristics that you | can hang on a name | - persistence of the name The *name* is persistent, period. Resolution is another matter. I don't know what you mean to refer to when you write "naming service". | - ownership | - address mapping | - persistence of the address mapping | - I would say "etc." but that's about it! My complaint is that two items | from even this minimal list of four aren't covered by the framework (whereas | the NAPTR proposal starts introducing gratuitous characteristics that are | owned by the resource the name points at, not the name itself). | | I would be happy if we came down on a solution which just optionally | specified the longevity of the name (not the DNS NAPTR TTL because this is | the longevity of the mapping, not the name itself). You could potentially | have name TTLs of 10 years (or more). So a sensible discussion could now | ensue as to whether this is practical - to expect any descendant of DNS to | inherit any long lived TTLs from within DNS. I would say yes. I don't see where you get the idea that a URN has a TTL at all. Where does the NAPTR proposal say it does? (maybe I missed something) Regards, Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA19183 for urn-ietf-out; Tue, 5 Nov 1996 10:54:41 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA19178 for ; Tue, 5 Nov 1996 10:54:39 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02105 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 10:54:25 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 15:54:06 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 15:53:46 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Tue, 5 Nov 96 15:52:59 GMT Message-Id: <2.2.32.19961105155506.006d9050@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Nov 1996 15:55:06 +0000 To: Fisher Mark From: Bob Briscoe Subject: RE: [URN] Resolution Services (N2L etc) Cc: "urn-ietf@bunyip.com" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com At 07:41 05/11/96 EST, Fisher Mark wrote: > >>1.2 It strikes me that specifying available service requests (N2L, N2R etc) >>should not be the job of DNS or any URN resolution mechanism. You are >>adding >>metadata about the address that the name resolves to (i.e. allowed >>methods). >>NAPTR should simply get you to the place you asked for by mapping names to >>addresses. >[...] >>OK, it may be *easier* to hack it this way, but that's not the point. You >>are embedding a duplication of meta-information in DNS which will always be >>prone to being out of date, unreliable, etc. Especially if the world moves >>to be much more dynamic in this area in the decades you envisage this >>lasting. More importantly, this information potentially has a different TTL >>than the address itself, so it will break your caching. > >But this is meta-information that is not easy to change. It is not like, >"oh, from midnight to 6am I'll support HTTP, then from 6am to 8am I'll >support HTTP and our experimental Z39.50-2000, then from 8am-6pm I'll only >support whois++", etc. Rapidly changing what final resolution services are >supported is not a particularly easy task, or a desirable task even when it >is made easy. I'm not throwing out the resolution service, as you appear to think I am saying. I'm throwing out the service requests supported by that service (N2L, N2Ls, N2R, N2Rs, N2C etc.). This is one level of indirection too far. It's irrelevant whether they are likely to change *often*. What is important is that they will change at potentially *different* times to the resolution service. This is what breaks the meaning of the TTL. Once you have the resolution service you can find the service requests it supports, so this is unnecessary complexity. > >Could one (or more) of the DNS wizards on the list speak as to what the >average TTL tends to be? From what Bob is saying, it sounds like he expects >the TTL of the NAPTR record to be a longer time than the expected time >between final resolution service changes. >====================================================================== >Mark Leighton Fisher Thomson Consumer Electronics >fisherm@indy.tce.com Indianapolis, IN > > ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA19174 for urn-ietf-out; Tue, 5 Nov 1996 10:54:12 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA19167 for ; Tue, 5 Nov 1996 10:54:09 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02081 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 10:53:56 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 15:53:26 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 15:53:11 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Tue, 5 Nov 96 15:52:24 GMT Message-Id: <2.2.32.19961105155431.006d63e0@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Nov 1996 15:54:31 +0000 To: Fisher Mark From: Bob Briscoe Subject: RE: [URN] Persistence as part of URN framework Cc: "urn-ietf@bunyip.com" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com At 07:26 05/11/96 EST, Fisher Mark wrote: > >>Persistence is a contractual >>thing which needs a technical hook to hang the contract on. > >But there are no technical hooks to guarantee persistence. On the >cypherpunks list a few months ago, there was a discussion of what it would >take to encrypt a message now, save it away for 100 years, then let the >recipient decrypt the message. The conclusion I drew from that discussion >was that this was a hard problem without a technical solution short of >deploying on every desktop and in every data center a persistent OS that >stored copies of all persistent data. Even then, the data would only >persist as long as technical means remained to read the persistent data. > (How many of us could read a 600 bpi 9-track tape or punched card deck even >if we had to?) The point I'm making is that if we (BT) sell or give away a URN (in our role as an Internet Service Provider), to give our customers the ability to switch suppliers but keep their resource names, we will contract with them to do this for a certain time. The URN service should be able to reflect this contractual fact so that other independent systems can know how long they can rely on that person's URN (e.g. so the third party's content management system can re-check HREFs as they are about to become obsolete rather than by polling). Once we have contracted to do this, we will *have to* ensure the URN is still accessible in terms of network infrastructure and servers. If the user has thrown away their Web browser and got SuperCrap5 instead, that's not our concern. I'm not saying we are planning doing this, I'm just laying out the processes a commercial company would go through before marketing URNs. The same issues come up with phone number portability between suppliers. > >The important point about URNs is that there is an extra level of >indirection built into the resolution process, such that the URN -> URL -> >resource resolution (in the N2L case) can transparently (at the user agent >level) change the URL(s) associated with that URN, without changing the URN. > Kind of a superpowered 30x redirect, in a way. This technical detail (the >extra level of indirection) is what will give URNs additional capability to >persist. That's just PURLs - saying certain names are more persistent than others. What I'm saying is that for URNs to mean anything, you need the *optional* capability to say *how* persistent you mean when you say "pretty persistent" because "for ever" is just meaningless. It must be optional because some people don't want to think about how long "persistent" means. Others might not want anyone to infer how long they expect to be in business from the length of their TTLs! A naming service should at minimum deal with the characteristics that you can hang on a name - persistence of the name - ownership - address mapping - persistence of the address mapping - I would say "etc." but that's about it! My complaint is that two items from even this minimal list of four aren't covered by the framework (whereas the NAPTR proposal starts introducing gratuitous characteristics that are owned by the resource the name points at, not the name itself). I would be happy if we came down on a solution which just optionally specified the longevity of the name (not the DNS NAPTR TTL because this is the longevity of the mapping, not the name itself). You could potentially have name TTLs of 10 years (or more). So a sensible discussion could now ensue as to whether this is practical - to expect any descendant of DNS to inherit any long lived TTLs from within DNS. I would say yes. Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA18387 for urn-ietf-out; Tue, 5 Nov 1996 09:38:07 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA18382 for ; Tue, 5 Nov 1996 09:38:05 -0500 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01399 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 09:38:03 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id GAA07931; Tue, 5 Nov 1996 06:37:15 -0800 Date: Tue, 5 Nov 1996 06:37:14 -0800 (PST) From: "Gregory J. Woodhouse" To: Bob Briscoe Cc: urn-ietf@bunyip.com Subject: Re: [URN] Resolution Services (N2L etc) In-Reply-To: <2.2.32.19961105100153.006d0998@sherekhan.jungle.bt.co.uk> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com I'm sure I'm saying the same thing tht others will say, but while I think NAPTR will likely be replaced with some other mechanism, I do think the extra layer of indirections serves several very important purposes: Most importantly, it makes the underlying mechanism truly distributed and scalable. It also decentralizes URN administration provides a smooth transition path to new technologies. No other mechanism that I've seen proposed can make these claims. --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/home.html resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA18364 for urn-ietf-out; Tue, 5 Nov 1996 09:37:13 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA18359 for ; Tue, 5 Nov 1996 09:37:10 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01389 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 09:37:08 -0500 Message-Id: <9611051437.AA01389@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Tue Nov 5 08:36 CST 1996 From: "Ryan Moats" To: "Martin J Duerst" , "Patrik Faltstrom" Cc: "urn-ietf@bunyip.com" Date: Tue, 05 Nov 96 08:37:29 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax draft) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Tue, 5 Nov 1996 10:46:17 +0100 (MET), Patrik Faltstrom wrote: > >On Mon, 4 Nov 1996, Martin J Duerst wrote: > >> - Specify that protocols may only reserve 1-octet UTF-8 characters >> (i.e. ASCII). > >This is kind of stupid from my point of view. We do not win >anything by doing this, do we? > >> - Specify that protocols have to define their own escaping mechanisms >> for things beyond ASCII. > >This is better, much better. We say that native URNs are 8-bit >following the UTF-8 specification and that the protocol have >to come up with its own escaping mechanism. This is ok, so long as we are talking about transport protocol escaping which is removed before the URN is resolved. What we are talking about here (in my mind at least) is escaping that the URN resolver "sees" and has to remove before resolving a URN. Now, there is are some folks who have commented to me that there shouldn't be any escaping that the URN resolver should have to handle. If so, then the portions of the draft covering escaping can be removed. However, if we decide that the URN resolver must handle escaping, then I claim that the types of escaping it handles should be specified in the syntax document, not somewhere else. I should note that there has not been enough comment either way on the preceding paragraph to claim "rough consensus"... Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA17824 for urn-ietf-out; Tue, 5 Nov 1996 08:27:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA17819 for ; Tue, 5 Nov 1996 08:27:18 -0500 Received: from fssun10.dev.oclc.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01106 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 08:27:15 -0500 Received: from orc.NISOR (orc.dev.oclc.org) by oclc.org (4.1/SMI-4.1) id AA16003; Tue, 5 Nov 96 08:27:13 EST Received: by orc.NISOR (SMI-8.6/SMI-SVR4) id IAA04028; Tue, 5 Nov 1996 08:28:15 -0500 Date: Tue, 5 Nov 1996 08:28:15 -0500 From: weibel@oclc.org (Stu Weibel) Message-Id: <199611051328.IAA04028@orc.NISOR> To: leslie@bunyip.com, urn-ietf@bunyip.com Subject: Re: [URN] URN-WG home page w/references X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: weibel@oclc.org (Stu Weibel) Errors-To: owner-urn-ietf@bunyip.com I think pointers to the PURL page and to the HANDLE page are certainly in order as the only deployed approaches to persistent naming at the present time. http://purl.org http://www.handle.net thanks, stu > Yes, there is a homepage for the group, although I have not had time to > update it since we became a working group. > > It lives at: > > http://www.bunyip.com/research/urn-ietf/ > > Suggestions for content are welcomed... > > Leslie. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA17731 for urn-ietf-out; Tue, 5 Nov 1996 08:17:07 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA17726 for ; Tue, 5 Nov 1996 08:17:05 -0500 Received: from fssun10.dev.oclc.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01071 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 08:17:03 -0500 Received: from orc.NISOR (orc.dev.oclc.org) by oclc.org (4.1/SMI-4.1) id AA15140; Tue, 5 Nov 96 08:16:52 EST Received: by orc.NISOR (SMI-8.6/SMI-SVR4) id IAA03246; Tue, 5 Nov 1996 08:17:53 -0500 Date: Tue, 5 Nov 1996 08:17:53 -0500 From: weibel@oclc.org (Stu Weibel) Message-Id: <199611051317.IAA03246@orc.NISOR> To: urn-ietf@bunyip.com, FisherM@is3.indy.tce.com Subject: RE: [URN] Persistence as part of URN framework X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: weibel@oclc.org (Stu Weibel) Errors-To: owner-urn-ietf@bunyip.com Mark Fisher writes, > The important point about URNs is that there is an extra level of > indirection built into the resolution process, such that the URN -> URL -> > resource resolution (in the N2L case) can transparently (at the user agent > level) change the URL(s) associated with that URN, without changing the URN. > Kind of a superpowered 30x redirect, in a way. This technical detail (the > extra level of indirection) is what will give URNs additional capability to > persist. This is the part of the problem that PURLs address very well: one additional level of indirection that allows the management (contractural or otherwise) of URLs by an organization with the committment to maintain persistent access. I have argued for in the past and continue to believe that persistence is only to a small extent a function of the underlying technology: persistence is a function of *organizational committment*. Another essential element of some (but not all) varieties of URN is assurance that the object that is named is exactly the same as it was at the time of name assignment. PURLs do not address this issue, but can be used as a layer in such a solution (OCLC and CNRI have, together, demonstrated such a solution with PURL-HANDLE resolution, but there can clearly be other solutions). The third major element, protocol independence, is highly desirable but less urgent: We can live with the current protocols for the time while the necessary infrastructure (NAPTR for example) is developed and deployed. stu Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id HAA17578 for urn-ietf-out; Tue, 5 Nov 1996 07:40:51 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id HAA17573 for ; Tue, 5 Nov 1996 07:40:45 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00898 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 07:40:39 -0500 Received: by seawall with (8.6.12/) id HAA15012; Tue, 5 Nov 1996 07:40:38 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma015008; Tue Nov 5 07:40:13 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <327F35D5@MSMAIL.INDY.TCE.COM>; Tue, 05 Nov 96 07:40:53 EST From: Fisher Mark To: Bob Briscoe , "urn-ietf@bunyip.com" Subject: RE: [URN] Resolution Services (N2L etc) Date: Tue, 05 Nov 96 07:41:00 EST Message-Id: <327F35D5@MSMAIL.INDY.TCE.COM> Encoding: 30 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com >1.2 It strikes me that specifying available service requests (N2L, N2R etc) >should not be the job of DNS or any URN resolution mechanism. You are >adding >metadata about the address that the name resolves to (i.e. allowed >methods). >NAPTR should simply get you to the place you asked for by mapping names to >addresses. [...] >OK, it may be *easier* to hack it this way, but that's not the point. You >are embedding a duplication of meta-information in DNS which will always be >prone to being out of date, unreliable, etc. Especially if the world moves >to be much more dynamic in this area in the decades you envisage this >lasting. More importantly, this information potentially has a different TTL >than the address itself, so it will break your caching. But this is meta-information that is not easy to change. It is not like, "oh, from midnight to 6am I'll support HTTP, then from 6am to 8am I'll support HTTP and our experimental Z39.50-2000, then from 8am-6pm I'll only support whois++", etc. Rapidly changing what final resolution services are supported is not a particularly easy task, or a desirable task even when it is made easy. Could one (or more) of the DNS wizards on the list speak as to what the average TTL tends to be? From what Bob is saying, it sounds like he expects the TTL of the NAPTR record to be a longer time than the expected time between final resolution service changes. ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id HAA17492 for urn-ietf-out; Tue, 5 Nov 1996 07:26:48 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id HAA17487 for ; Tue, 5 Nov 1996 07:26:46 -0500 Received: from inet-gw.indy.tce.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00859 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 07:26:44 -0500 Received: by seawall with (8.6.12/) id HAA14740; Tue, 5 Nov 1996 07:26:38 -0500 Received: from cts2.indy.tce.com(157.254.98.70) by seawall.indy.tce.com via smap (V1.3) id sma014736; Tue Nov 5 07:26:20 1996 Received: by MSMAIL.INDY.TCE.COM with Microsoft Mail id <327F3294@MSMAIL.INDY.TCE.COM>; Tue, 05 Nov 96 07:27:00 EST From: Fisher Mark To: Bob Briscoe , "urn-ietf@bunyip.com" Subject: RE: [URN] Persistence as part of URN framework Date: Tue, 05 Nov 96 07:26:00 EST Message-Id: <327F3294@MSMAIL.INDY.TCE.COM> Encoding: 25 TEXT X-Mailer: Microsoft Mail V3.0 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Fisher Mark Errors-To: owner-urn-ietf@bunyip.com >Persistence is a contractual >thing which needs a technical hook to hang the contract on. But there are no technical hooks to guarantee persistence. On the cypherpunks list a few months ago, there was a discussion of what it would take to encrypt a message now, save it away for 100 years, then let the recipient decrypt the message. The conclusion I drew from that discussion was that this was a hard problem without a technical solution short of deploying on every desktop and in every data center a persistent OS that stored copies of all persistent data. Even then, the data would only persist as long as technical means remained to read the persistent data. (How many of us could read a 600 bpi 9-track tape or punched card deck even if we had to?) The important point about URNs is that there is an extra level of indirection built into the resolution process, such that the URN -> URL -> resource resolution (in the N2L case) can transparently (at the user agent level) change the URL(s) associated with that URN, without changing the URN. Kind of a superpowered 30x redirect, in a way. This technical detail (the extra level of indirection) is what will give URNs additional capability to persist. ====================================================================== Mark Leighton Fisher Thomson Consumer Electronics fisherm@indy.tce.com Indianapolis, IN Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA17086 for urn-ietf-out; Tue, 5 Nov 1996 06:40:34 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA17081 for ; Tue, 5 Nov 1996 06:40:32 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00703 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 06:40:31 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id GAA13431; Tue, 5 Nov 1996 06:40:30 -0500 Message-Id: <199611051140.GAA13431@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Tue, 5 Nov 1996 06:40:30 -0500 In-Reply-To: Larry Masinter's message as of Nov 4, 16:52 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Larry Masinter , urn-ietf@bunyip.com Subject: Re: [URN] URN-WG home page w/references Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Larry, > Is there a 'home page' for the URN working group? It would be really > useful to collect together the references & previous work. There was a > home page for URI that was (and still is) really useful, but lately > I've had to search for URN & URC references. Yes, there is a homepage for the group, although I have not had time to update it since we became a working group. It lives at: http://www.bunyip.com/research/urn-ietf/ Suggestions for content are welcomed... Leslie. -- ---------------------------------------------------------------------------- "The light at the end of the tunnel Leslie Daigle is often the blindingly obvious..." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA16516 for urn-ietf-out; Tue, 5 Nov 1996 05:02:10 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA16509 for ; Tue, 5 Nov 1996 05:02:08 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00444 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 05:01:35 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 10:01:23 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 10:01:06 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Tue, 5 Nov 96 10:00:21 GMT Message-Id: <2.2.32.19961105100228.006d9db8@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Nov 1996 10:02:28 +0000 To: urn-ietf@bunyip.com From: Bob Briscoe Subject: [URN] NAPTR substitution expression grammar Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com Comments on draft-ietf-urn-naptr-00.txt (cont.): 2. Substitution expression grammar 2.1 You claim to be copying sed ERE syntax (with the caveat it may all change to cover UTF-8). To avoid confusion for sed gits like me, could you consider using the escaped parentheses \( and \) to do back refs, rather than the one character ones ( and ) which simply imply grouping in POSIX EREs by my understanding. 2.2 Also, it would be friendly to allow any delimiter, like sed does, not just "/" (e.g. "!.*//\([^/:]+\)!\1!i" is a lot more readable than "/.*\/\/\([^\/:]+\)/\1/i"). Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA16491 for urn-ietf-out; Tue, 5 Nov 1996 05:01:38 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA16486 for ; Tue, 5 Nov 1996 05:01:36 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00435 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 05:01:29 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 10:01:17 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 10:00:58 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Tue, 5 Nov 96 10:00:07 GMT Message-Id: <2.2.32.19961105100213.006c3a98@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Nov 1996 10:02:13 +0000 To: urn-ietf@bunyip.com From: Bob Briscoe Subject: [URN] Persistence as part of URN framework Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com Comments on draft-daigle-urnframework-00.txt: On 12-Oct-96 in "[URN] suggestions for "A Framework for the Assignment and Resolution ..."" Larry Masinter said: This is a rather old song, but I will sing it again: draft-daigle-urnframework-00.txt is inadequate because it does not deal with any of the issues of administration & security & migration & longevity that are the entire motivation for having 'URNs' instead of 'URLs'. I couldn't agree more. If the only difference between a name and a location is persistence, can you really get away with defining a whole framework that doesn't mention even an optional capability to define how persistent a name is (or at least a best estimate)? You've chosen the DNS which has TTL in there as a given, but your framework doesn't put any requirements on this. For instance, we might want to sell persistent names, but if there's no way of telling how persistent they are, you've got nothing to prove anything, and the client has got nothing to buy into. Persistence is a contractual thing which needs a technical hook to hang the contract on. I believe defining persistence fits your charter too. Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA16453 for urn-ietf-out; Tue, 5 Nov 1996 05:01:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA16448 for ; Tue, 5 Nov 1996 05:01:12 -0500 Received: from zaphod.axion.bt.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00429 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 05:01:09 -0500 Received: from mailhub.axion.bt.co.uk by zaphod.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 10:00:46 +0000 Received: from kaa.jungle.bt.co.uk by mailhub.axion.bt.co.uk with SMTP (PP); Tue, 5 Nov 1996 10:00:34 +0000 Received: from phao.jungle.bt.co.uk by kaa.jungle.bt.co.uk; Tue, 5 Nov 96 09:59:46 GMT Message-Id: <2.2.32.19961105100153.006d0998@sherekhan.jungle.bt.co.uk> X-Sender: rbriscoe@sherekhan.jungle.bt.co.uk X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Nov 1996 10:01:53 +0000 To: urn-ietf@bunyip.com From: Bob Briscoe Subject: [URN] Resolution Services (N2L etc) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Bob Briscoe Errors-To: owner-urn-ietf@bunyip.com Strong comments on draft-ietf-urn-naptr-00 draft below. I've just joined this mail-list as I'm working on URCs and wanted to make sure I was up to date on back-ground. I have read all the drafts that I think are relevant (URN urnframework-00, urn-naptr-00, urn-syntax-00) and the last couple of months mail archives to get up to date. I have tried not to cover old ground, but please pull me up if I stray. In fact it's homely to note the same old arguments about URNs are still being re-cycled. I admire your collective sticking power. I haven't read daniel-http because it relies so heavily on the resolution service capability of NAPTR to which I have big objections (below). Comments on draft-ietf-urn-naptr-00.txt: 1. Resolution Services 1.1 Under Brief overview and examples, it says, "Resolution services are operations such as N2R... These are discussed in the URN framework document[2]..." They aren't (and below I say why I think they shouldn't be, other than to exclude them). 1.2 It strikes me that specifying available service requests (N2L, N2R etc) should not be the job of DNS or any URN resolution mechanism. You are adding metadata about the address that the name resolves to (i.e. allowed methods). NAPTR should simply get you to the place you asked for by mapping names to addresses. Other systems (service discovery or navigation) should allow you to determine what you *should* ask for from the address once you get it, and once you have the address each protocol scheme might provide a well-known method for querying what methods you *can* do if that is what the scheme needs (e.g. HTTP/1.1 OPTIONS method). IOW, the client should already know what it is going to do with the address it gets out of the URN service, or if it doesn't it should be prepared to find out. OK, it may be *easier* to hack it this way, but that's not the point. You are embedding a duplication of meta-information in DNS which will always be prone to being out of date, unreliable, etc. Especially if the world moves to be much more dynamic in this area in the decades you envisage this lasting. More importantly, this information potentially has a different TTL than the address itself, so it will break your caching. IMHO, what you *can* do with the URN should normally be put in with the advert for the URN (e.g. the mailing, the cereal box, the web page) that the service provider shouts about to get the thing used, and other people pass on in the normal way this gossip spreads. It is up to the service providers to promulgate the URN in such a way that when the client uses it, the correct method is invoked (e.g. if you want U2L, not U2R on a Web page, you just type the URN, rather than HREF'ing it). Bob ____________________________________________________________________________ Bob Briscoe http://www.labs.bt.com/people/briscorj/index.htm Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA16345 for urn-ietf-out; Tue, 5 Nov 1996 04:48:36 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA16340 for ; Tue, 5 Nov 1996 04:48:33 -0500 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00389 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 04:48:29 -0500 Received: from nic.cafax.se (paf@nic.cafax.se [193.12.122.42]) by nic.cafax.se (8.8.2/8.8.2) with SMTP id KAA06251; Tue, 5 Nov 1996 10:46:18 +0100 (MET) Date: Tue, 5 Nov 1996 10:46:17 +0100 (MET) From: Patrik Faltstrom X-Sender: paf@nic.cafax.se To: Martin J Duerst Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax draft) In-Reply-To: <"josef.ifi..324:04.10.96.10.50.51"@ifi.unizh.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com On Mon, 4 Nov 1996, Martin J Duerst wrote: > - Specify that protocols may only reserve 1-octet UTF-8 characters > (i.e. ASCII). This is kind of stupid from my point of view. We do not win anything by doing this, do we? > - Specify that protocols have to define their own escaping mechanisms > for things beyond ASCII. This is better, much better. We say that native URNs are 8-bit following the UTF-8 specification and that the protocol have to come up with its own escaping mechanism. Just because the US-ASCII characters are represented by themselves in an UTF-8 string, and these octets can not occur in any other UTF-8 sequence, I can not see that we have problems with the normal "dangerous" characters in for example a URL, i.e. space, percent, plus etc. A space can only occur in a UTF-8 string as a space, representing a space, so it has to be %encoded. It should because of this be quite easy :-) for each protocol to check what happens when a UTF-8 string is passed. My experience is that UTF-8 strings behaves like ISO-8859-1 strings, if you don't start inserting linebreaks, counting characters etc. Patrik Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA15027 for urn-ietf-out; Tue, 5 Nov 1996 01:20:54 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA15022 for ; Tue, 5 Nov 1996 01:20:50 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA29641 (mail destined for urn-ietf@services.bunyip.com); Tue, 5 Nov 96 01:20:47 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id AAA21984; Tue, 5 Nov 1996 00:16:00 -0600 (CST) Date: Tue, 5 Nov 1996 00:16:00 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611050616.AAA21984@ncsa.uiuc.edu> To: Patrik Faltstrom Cc: urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: References: <199611030651.AAA25490@ncsa.uiuc.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Patrik Faltstrom writes: > A URL refers to a location which though a caching mechanism, a proxy > cache, an interceptor with cache, multiple A-records in DNS or whatever > ends up refering to more than one occurance of the same resource. But those multiple occurances of the resource are at multiple locations, are they not? (BTW, the point of this particular line of argument is simply that the binding between URL and location is not as clear as people are making it sound. This, by itself, does not imply that URLs are persistent, as URNs are intended to be.) > A URN is a _name_ of a resource which have absolutely _NOTHING_ > to do with the resolution protocol, the different versions of > the resource that exist (text, postscript etc), the different > protocols used to locate and later fetch the resource or the > metadata for the resource. I'm not sure who else would agree with you that a name is so abstract that it has nothing to do with any of the information associated with the resource. If there is no association, how is that the name can even be used as a name of the resource? How would you ever get to the resource? Instead, perhaps you are trying to say that the name is not tightly bound to information associated with the resource, that the information can change and still the name is the name of the resource. For example, the "resolution protocol" can change. I have no problem with that, and never have. But this is still not abstractly different from what happens to a URL. What is happening when an HTTP server gives you a redirect to an ftp URL? Compare that to a DNS server for a naming authority giving you a redirect to an http URL. If you want to get from a URN to a resource, you must begin to look up some information starting with the URN. If you don't look up anything associated with the URN, you can't continue with the resolution, so there is something essential going on there, you must admit. The particular way you go about looking up the information is a process that involves protocols itself. (BTW, the point of this particular line of argument is simply that if URLs have a protocol associated with them, then so do URNs. But in fact, different protocols can be used to resolve either URNs or URLs.) > On Sun, 3 Nov 1996, Daniel LaLiberte wrote: > > But the very same URL was used to retrieve the resource either from a > > cache or from a remote server. So what "location" is the URL > > identifying when the resource actually lives in multiple places - the > > very same URL may be used to fetch the resource from any of those > > places? Notice you first say that a URL identifies (or names) the > > location of a resource, and then we find out that there are really > > multiple locations identified by the URL. But that is supposed to be > > the job of URNs. So why do we need URNs? (BTW, my "So why do we need URNs?" is somewhat rhetorical. I believe we do need more persistent resolution services, in case that is not clear. The point of the above line of argument is, again, that the binding between URLs and locations is not so clear. There is more to this argument that hasn't come out yet.) ... > Dan, you _have_ to start to differ between multiple locations > of a resource which is addressed by a URL - i.e. it's original > location, Is your view that a URL *is* the "original" location of the resource and also the URL "addresses" multiple locations of the resource? This is different from the definition that a URL identifies (or names) the location of the resource. > and the functionality that is built into the system > when a _name_ is assigned to a resource. As long as you have not > seen this difference that many of us others have seen, it is > a little bit hard to have a meaningful discussion. I see a difference, but it is not the difference you think it is. There is a difference in the functionality that can be provided by a new service, but it is not a difference because we call something a "name" vs a "location". The proof is that the things you call "locations" (i.e. URLs) can use this new service too. > Sorry for being harsh and short, but I am now a little bit tired > of having to try to come up with exactly the same arguments we > have been having since the UR* discussions started. We have > to move forward! I don't think these are exactly the same arguments - at least I havent seen my arguments before. But I didn't perceive harshness in your words, or it didn't bother me anyway. I am being patiently persistent - I only hope that my readers are being persistent enough to understand my arguments. > > A client can resolve > > "http://www.ncsa.uiuc.edu/" using HTTP or using the NAPTR protocol, or > > something else. This is the very same identifier, not two identifiers > > with the same character representation. Calling it two identifiers > > and saying one is a name and the other is [the name of] a location is > > missing the whole point. > > No, _you_ are missing the point. By saying that > "urn:http://www.ncsa.uiuc.edu/" is a _name_, one know that this > namespace called HTTP can grandfather other namespaces, this > _name_ can stay as it is even if the resource moves, the metadata > for this resource can be fetched etc etc all according to the URN > spec that was written down years ago. I'm not missing that point - I agree with it. I helped create all this, by the way, so I know what is going on here. But I am not talking about "urn:http://www.ncsa.uiuc.edu/", I am talking about "http://www.ncsa.uiuc.edu". If the "urn:" prefix is optional on URNs, then those two identifiers are equivalent. Answer this: do you agree with the previous statement? > If you have a URL, like "http://www.ncsa.uiuc.edu/", what do you do > if you have to move this resource from the host www.ncsa.uiuc.edu? > Change things in the DNS? But of course that works. But, if you move > the information from staying only on an http server to also stay in > a Z39.50 database and want the clients to be able to use both, or > [...] If "http://www.ncsa.uiuc.edu/" is in the "http" branch of the urn.net tree, then you could do any of these things. If some other name resolution mechanism is created in the future, then "http://www.ncsa.uiuc.edu/" could be registered there too. > There are thousands of things you _can_not_do_ with the name of a > location of something, that you only can do with a _name_ of a > resource which is resolved to one or many alternative locations. If *you* define an identifier as a location and therefore limit what you do with it based on that definition, then that's your choice. But anyone else is still free to use it as a name, if they can find a resolution service that treats it as a name, in the sense of providing persistent resolution, or any of the other thousands of things one might associate with names. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA13211 for urn-ietf-out; Mon, 4 Nov 1996 20:53:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA13206 for ; Mon, 4 Nov 1996 20:53:31 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28443 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 20:52:59 -0500 Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <14402(6)>; Mon, 4 Nov 1996 17:52:47 PST Received: by palimpsest.parc.xerox.com id <130>; Mon, 4 Nov 1996 17:52:43 PDT To: urn-ietf@bunyip.com In-Reply-To: <199611042006.PAA08313@lysithea.lcs.mit.edu> (sollins@lcs.mit.edu) Subject: [URN] URN-WG home page w/references From: Larry Masinter Message-Id: <96Nov4.175243pdt."130"@palimpsest.parc.xerox.com> Date: Mon, 4 Nov 1996 16:52:43 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com Is there a 'home page' for the URN working group? It would be really useful to collect together the references & previous work. There was a home page for URI that was (and still is) really useful, but lately I've had to search for URN & URC references. Regards, Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA08830 for urn-ietf-out; Mon, 4 Nov 1996 15:06:47 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA08825 for ; Mon, 4 Nov 1996 15:06:40 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25851 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 15:06:38 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id PAA08313; Mon, 4 Nov 1996 15:06:37 -0500 Date: Mon, 4 Nov 1996 15:06:37 -0500 Message-Id: <199611042006.PAA08313@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: urn-ietf@bunyip.com Subject: Re: [URN] some comments Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com Let me try once more... There are three core functions that are generally provided by "names": identification, location, and mnemonics or semantics. Let me describe each separate. In this context, all have meaning only with respect to resources. Identification allows the assigner of the name to declare the distinctiveness of a resource from other resources, from the perspective of the assigner of the name. This allows someone else to recognize this distinction or lack thereof as intended by the name assigner. Generally, all naming schemes provide this in some form or other. Location allows the assigner to declare something about how to locate or find the resource. In an abstract sense it can be seen as "location", but the meaning of location is left to the interpretation of the supporting infrastructure. A different way of saying this is that it is the input to the supporting protocol elements. Again, generally, at least in computer systems, all naming schemes provide this in some form or other. Mnemonics or semantics allows the assigner to include something "meaningful" to potential clients, such as ways to remember the name, or perhaps something about the nature of the resource (an extension defining the language in which the resource is encoded, an algorithm that was used in it, it's functionality, or perhaps its relationship to other resources, e.g. versioning). Not all naming schemes provide this. Human friendly schemes tend to do much more than machine friendly ones. Now, let's step back and look at our environment. We are talking about a situation in which there are "layers of abstraction". At "our" layer, the entities to be named are resources. Resources will be supported by an infrastructural suite, including (although I may have missed some) storage services (file systems, oodbms, object repositories, etc.), computation engines, access methods, access constraint methods, communications protocols, and perhaps others. So, for example, at the present the infrastructure may be provided by publicly accessible unix file systems, NT file systems, etc, as well as a collection of transport protocols such as HTTP, NNTP, FTP, Z39.50, etc. These are not part of our layer of abstraction, but rather are what we use to realize them. These things in turn are themselves supported by lower level abstractions. The same issues of naming listed above apply to each of the layers. After much more than 2 yrs we have chosen by consensus a particular model with respect to naming within our layer. That model for the most part separates the three functions and realizes them separately. In the URI architecture (not Tim B-L's idea of URIs, but that of the URI WG consensus), these functions are separately provided by three components of the architecture. Identification is provided by URNs, location by URLs, and semantics by URCs. That is what was agreed to by consensus of the working group. That is what is laid out in the introductions to both the URN and URL requirements documents that were also agreed to by the WG. Such a layering architecture also recognizes that there are different layers of abstraction and that at least abstractly one goes through the exercise repeatedly (and not just at the layers at which we are working) of taking an identifier and using it to either learn something about distinctions or lack thereof in the intention of the name assigner or perhaps semantics, and/or alternatively "resolving" or "binding" it, by translating it into something for which the only intention is that it be handed to some piece of the infrastructure to "do its thing" on. For this resolution or binding process one might use similar mechanisms at different layers of abstraction, such as table lookup or recourse to servers using the same query protocol in order to request resolution. But that in no way means that the same abstractions are being identified, learned about or resolved. Given our choice of separation, we, in this working group, have set about to design a first mechanism to provide the binding of name to location. Let me recommend to you an extremely well-written short paper on the subject, "On the Naming and Binding of Network Destinations" by Jerry Saltzer. This was originally published in 1983 (yes, that was long before the URI WG was formed :-), so its examples are from that era. The concepts are completely applicable to this discussion. This is not a new problem, nor is the model of distinguishing between name and address a new solution. It was issued as RFC 1498 (informational) in 1993. Two additional relevant references (from Saltzer's paper) that I also recommend to you are: Shoch, John F., "Inter-Network Naming, Addressing, and Routing," IEEE Proc. COMPCON Fall 1978, pp. 72-79. Also in Thurber, K. (ed.), Tutorial: Distributed Processor Communication Architecture, IEEE Publ. #EHO 152-9, 1979, pp. 280-287. Sunshine, Carl A., "Addressing Problems in Multi-Network Systems", to appear in Proc. IEEE INFOCOM 82, Las Vegas, Nevada, March 30 - April 1, 1982. Karen Sollins Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA05581 for urn-ietf-out; Mon, 4 Nov 1996 12:57:40 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA05576 for ; Mon, 4 Nov 1996 12:57:36 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24362 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 12:57:33 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id LAA10291; Mon, 4 Nov 1996 11:53:09 -0600 (CST) Date: Mon, 4 Nov 1996 11:53:09 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611041753.LAA10291@ncsa.uiuc.edu> To: Leslie Daigle Cc: urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: References: <199610311951.NAA10608@ncsa.uiuc.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Leslie Daigle writes: > A URL (location) is a point in 4-space, as defined by: > > . machine (aliased through DNS mechanisms) > . port number (default per protocol) > . protocol to speak on that port and at that machine > . string to use within that protocol > > A basic URN (name) has nothing to do with these 4 dimensions -- it is > independent of any machine identifier, port, or protocol. The string > associated with it is a _label_ that is unique across the specified > namespace. The URN being proposed to be resolved with the NAPTR mechanism has everything to do with these 4 dimensions. Specifically: . machine: urn.net (or whatever is decided) . port: DNS protocol port . protocol: DNS on top of UDP or TCP . string: nsi:opaque-string Furthermore, it is an iterative protocol, making several requests to DNS. But similarly, HTTP is iterative. You might respond that this is just one URN resolution mechanism and others are possible. Absolutely true. But the same is true of URLs. A URL is *not* necessarily resolved through the mechanism suggested by its components. An http URL can be resolved by the NAPTR mechansm, for example. Or it may be resolved through a cache. > [Dan LaLiberte wrote:] > > Consider caches. The resolution of a URL via a cache proxy may find > > the resource in the cache rather than in some remote server. What is > > "the location" of the resource in that case? > > Caches are external to either URN or URL systems. They may choose > to use the URL string as a label that identifies a particular > resource, and use that label to lookup contents of the cache. Stop right there for a moment. Note that the location of the resource found in the cache is *not* the location you described above that is suggested by the components of the URL. You say that caches are external to URIs, but the URL is in fact used to look up the resource. That is not external - that is part of the process of resolving the URL. > But, caches break when the label does not change, but the contents > of the location does. You mean "location of the contents", I presume. I understand what you are saying, and I believed the same once - I couldnt figure out why Tim Berner-Lee argued that URLs could work just fine for caching. I thought he was missing something. But the problem, as I understand it now, is not in the identifiers, it is in the resolution process. Identifiers, whether URLs or URNs, are *always* interpreted by some resolution process. And it is the resolution process that provides the persistence of reference, not the identifiers themselves. Take out the NAPTR resolution service (and provide no substitute resolution service) and URNs will be useless (except for unique identification which needs no resolution service). Yes, HTTP fails to provide persistent resolution because servers move and there is no way to redirect a whole service. Note that within a still existing server, a redirect can be used to provide persistent resolution. The PURL idea is to just make sure the purl server continues to exist, and people may or may not believe it will. Abstractly, there is no difference between depending on the continued existence of a purl server and depending on the continued existence of the DNS root service, and NAPTR resolution will depend on that, and on 'net' and 'urn.net'. The practical difference is that DNS probably will continue to exist even if all the purl servers vanish. > If you cache based on URN, your cache will > not break, because the content associated with the identifier > does not change. You seem to be jumping here to content-based identifiers. That is not in the requirements, as I understand it. The content of a resource may in fact change and still be identified by the same URI. Perhaps, you are talking about the uniqueness property of URNs such that a URN will always map to the *same* resource, as long as the resource exists, even though it may be a dynamically changing resource. But note that, like persistence, uniqueness is also (partly) a property of the resolution services, not the URN itself. The naming authority must make sure that a URN is only used once, but the resolution service must also behave such that it always associates a particular URN with the same resource, otherwise the URN is effectively *not* unique. But URLs could have that same uniqueness property. There is no guarantee that all http URLs will be unique, and we will never be able to get that guarantee, but a cache could find out from a server whether a URL is unique for the resource that was returned. > > We don't need to create a new kind of identifier to make a URL into a > > persistent location. We *do* need new persistent services, such as > > the NAPTR records in DNS. > > I'm not sure I understand the point you are making here. Access to NAPTR records in DNS is (will be) provided by a service, a DNS service. This NAPTR service might be limited to just parts of the DNS tree, under urn.net. I am suggesting that http URLs could be resolved through that limited service, by setting up an http branch under urn.net. Therefore, http URLs resolved this way could have exactly the same persistence as any other URN. It is the resolution service that provides the persistence, not the identifier itself. > It sounds like > you are saying -- forget everything else about all this stuff, let's > do NAPTR as a service, and then people can build in persistence using > whichever mechansisms strike their fancy? That is an interesting idea, if I understand what you are thinking, but it is not what I was suggesting. > I have a problem with that approach, for (at least) two reasons: > > . implementing a persistent location means adding much overhead > in systems that were not built for it. Yes, there is overhead in providing persistent resolution services. But not as much as you suggest, depending on how it is done. > . there are then no mechanisms to distinguish between things that > are meant to be persistent, and things that are expected not > to be. Time-to-live data would indicate how persistent things are. Why should we assume that URLs are not persistent? Why should we assume that URNs last forever? It is resolution services and the organizations that provide them that make URLs or URNs persist, or not. (BTW, throughout this discussion, I've slighted the guarantees of uniqueness of identifiers (i.e. not used for another resource), but that is a trivially easy problem to solve, so I am not particularly worried about it. In addition to providing persistent resolution services, we would need to know that particular URIs are unique, if that is important for some particular application. This information can be provided by servers along with the resource or separately. We don't *need* to create a new kind of identifier to know that particular identifiers are unique, although it is convenient to know that all identifiers with the same prefix are intended to be unique.) > > To summarize, both URLs and URNs have the following abstract > > resolution process in common: ... > It is definitely interesting to look at the surface similarities in > mechanics between URL resolution and the NAPTR approach to URN > handling. This abstraction is not a surface similarity - this is a fundamentally deep similarity. Both URLs and URNs have the same abstract mechanism - it is the details of exactly which processes are used that is at the surface. > What still is not clear to me is what you are suggesting > to _do_ with this. If you are suggesting that there is nothing > more to do with URN work than to define different steps in 2 and 3, > I have a problem with that... The "nothing more" involves setting up a persistent resolution service which is not exactly trivial, especially when it hopes to be applicable to all names, past and future. But yes, this resolution service fits right into this general URI resolution mechanism. The problem you might have with it is that it makes URLs and URNs look too much alike, which collapses the view that they must be different. Let me return to my claim that: It is the resolution service that provides the persistence, not the identifier itself. Something similar applies to any properties of identifiers. The only properties that are inherent in an identifier itself are properties of its actual representation. Any other properties *associated* with the identifier are derived from how it actually behaves, or is promised to behave when used in a particular context. But note that the same identifier can be used in different contexts, so it can "have" different properties in each. This is just a mathematical truth. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA05350 for urn-ietf-out; Mon, 4 Nov 1996 12:33:16 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA05345 for ; Mon, 4 Nov 1996 12:33:14 -0500 Received: from CS.BU.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23964 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 12:33:09 -0500 Received: by cs.bu.edu (8.6.10/Spike-2.1) id MAA01846; Mon, 4 Nov 1996 12:32:53 -0500 Date: Mon, 4 Nov 1996 12:32:53 -0500 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: urn-ietf@bunyip.com From: "David G. Durand" (David G. Durand) Subject: Re: Names and Locations (was [URN] some comments) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "David G. Durand" (David G. Durand) Errors-To: owner-urn-ietf@bunyip.com.Another.way.to.see.the.difference.between.URNs.and.URLs.is.to.look.at binding time: a URL has a resolution mechanism defined at the time that it is created. A URN is explicitly defined to have multiple potential resolution mechanisms, as long as they work (i.e. lead to right resource). You can use any kind of indentifier as a URL (even one that was originally assigned as a URL), but such use implies a contract by the name assigner, establishes the bounds of variation on the resource (usually, that the resource be immutable). URNs are supposed _not_ to have a privileged resolution mechanism, thus allowing the identifiers to outlive URN resolutin mechanisms. Now, it is true that we will need to have at least one mechanism for URL resolution, but the strategy for defining identifiers and that for resolving them should _not_ be tightly coupled because we _know_ that the mechnisms will change, but the URNs cannot change. It is the point of URNs that the _client_ can decide how to resolve them, while URLs require that the _URL creator_ prescribe how they should be resolved. That's also why a URN prefix makes URNs more useful, since it is a tip-off to a client that it may have a choice as to resolution strategy. It also signals that the assigner of the name claims to meet the contract for URN persistence. Mixing URN authorities with HTTP protocols is technically workable, but it makes the deployment of new naming authorities interact closely with the completely unrelated issue of protocols for HTTP resolution. It is much simpler to ensure that there is a requirement for syntactic differentiation of URNs _in contexts where both URLs and URNs can occur_. -- David _________________________________________ David Durand dgd@cs.bu.edu \ david@dynamicDiagrams.com Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA05110 for urn-ietf-out; Mon, 4 Nov 1996 12:05:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA05104 for ; Mon, 4 Nov 1996 12:05:54 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23564 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 12:05:52 -0500 Message-Id: <9611041705.AA23564@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Mon Nov 4 11:04 CST 1996 From: "Ryan Moats" To: "Martin J Duerst" Cc: "urn-ietf@bunyip.com" Date: Mon, 04 Nov 96 11:06:14 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Mon, 4 Nov 1996 17:37:06 +0100 (MET), Martin J Duerst wrote: >Ryan Moats wrote: > >>>- Specify that protocols may only reserve 1-octet UTF-8 characters >>> (i.e. ASCII). >>>- Specify that protocols have to define their own escaping mechanisms >>> for things beyond ASCII. >> >>Having had the weekend to mull this over some more (and seeing that my >>mulling was in the right direction...), here are my thoughts: >> >>I would add a third solution to the above-- That the syntax draft defines its >>own escaping mechanism for things beyond ASCII. This ensures that URN >>resolvers don't have to be re-written just because some new namespace comes >>along that wants to reserve some character in some totally different scheme >>then all the others currently used. >> >>Having said that, I currently lean strongly towards the first solution >>that Martin has >>proposed, as it keeps the syntax document short, doesn't add a new >>escaping mechanism (and all the complexity that adds). To sum up, it just >>strikes me as being CLEANER than any other solution. Does anybody >>have problems with it being written into the syntax draft? > >It looks cleaner to me, too, maybe even a subset of ASCII, as Jon >Knight has suggested, because as I have explained, even now %7E >is used in some parts of the world to escape a "~" that is not >a reserved character. I can live with a subset of ASCII, say from %20 to %7D. >Also, I think we will never be able to fully exclude the second >solution, and we may even say in the draft that it is allowed, >but of course there will be no support from any generic handling >software. I'd word it differently, but I can add such text as well. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA04734 for urn-ietf-out; Mon, 4 Nov 1996 11:37:58 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA04729 for ; Mon, 4 Nov 1996 11:37:51 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23341 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 11:37:24 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01465-0@josef.ifi.unizh.ch>; Mon, 4 Nov 1996 17:37:07 +0100 Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax To: jayhawk@ds.internic.net Date: Mon, 4 Nov 1996 17:37:06 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: <"josef.ifi..017:04.10.96.15.15.19"@ifi.unizh.ch> from "Ryan Moats" at Nov 4, 96 09:14:28 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1839 From: Martin J Duerst Message-Id: <"josef.ifi..168:04.10.96.16.37.08"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ryan Moats wrote: >On Mon, 4 Nov 1996 11:50:36 +0100 (MET), Martin J Duerst wrote: >It wasn't your explanation, it was getting my brain to stop thinking in ASCII >mode and start thinking in more general character mode. I'll probably still >slip back and forth, since it isn't natural yet... I see. I'm probably too much into i18n mode to realize such things anymore. >>- Specify that protocols may only reserve 1-octet UTF-8 characters >> (i.e. ASCII). >>- Specify that protocols have to define their own escaping mechanisms >> for things beyond ASCII. > >Having had the weekend to mull this over some more (and seeing that my >mulling was in the right direction...), here are my thoughts: > >I would add a third solution to the above-- That the syntax draft defines its >own escaping mechanism for things beyond ASCII. This ensures that URN >resolvers don't have to be re-written just because some new namespace comes >along that wants to reserve some character in some totally different scheme >then all the others currently used. > >Having said that, I currently lean strongly towards the first solution >that Martin has >proposed, as it keeps the syntax document short, doesn't add a new >escaping mechanism (and all the complexity that adds). To sum up, it just >strikes me as being CLEANER than any other solution. Does anybody >have problems with it being written into the syntax draft? It looks cleaner to me, too, maybe even a subset of ASCII, as Jon Knight has suggested, because as I have explained, even now %7E is used in some parts of the world to escape a "~" that is not a reserved character. Also, I think we will never be able to fully exclude the second solution, and we may even say in the draft that it is allowed, but of course there will be no support from any generic handling software. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA29455 for urn-ietf-out; Mon, 4 Nov 1996 10:22:56 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA29444 for ; Mon, 4 Nov 1996 10:22:53 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22581 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 10:22:51 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01422-0@josef.ifi.unizh.ch>; Mon, 4 Nov 1996 16:22:20 +0100 Subject: Re: [URN] New syntax draft To: jon@net.lut.ac.uk (Jon Knight) Date: Mon, 4 Nov 1996 16:22:19 +0100 (MET) Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com In-Reply-To: from "Jon Knight" at Nov 4, 96 03:15:56 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1597 From: Martin J Duerst Message-Id: <"josef.ifi..204:04.10.96.15.22.21"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Jon Knight wrote: >On Mon, 4 Nov 1996, Martin J Duerst wrote: >> Yes. But now immagine that some of these French/German/Nordic/Icelandic >> letters, or whatever else, is reserved, but that somebody was not able >> to represent them directly, and used %-escaping. What are you going to do? > >But nobody is suggesting making the Nordic runes reserved characters are >they? I was thinking that reserved characters would be a very well >defined, small subset of the ASCII range, just as with URLs. Nobody is explicitly suggesting to make the Nordic runes reserved characters at the moment. They would first have to be included in Unicode/ISo 10646, for which work is still progressing. But the current draft does not say reserved characters are restricted to ASCII, or even a subset of it. >> >And anyway, URLs don't use UTF-8 so this isn't going to be a problem >> >(we're talking URNs here right?). >> >> I just explained the problems using URL examples. Just because >> they problems might not apply to URLs, that still does not help >> for URNs. > >Which means that URLs are maybe doing something right and we should take >notice whilst doing URNs...? Such as only having a relatively small >number of reserved characters. It may well be that this is the right way to go. On the other hand, what does "grandfathering" exactly mean? If there is a namespace that already has e.g. some Nordic rune as reserved character, and we limit ourselves to a subset of ASCII, then although the namespace as such can be grandfathered, the reserved characters will have to be changed. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA29379 for urn-ietf-out; Mon, 4 Nov 1996 10:17:12 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA29374 for ; Mon, 4 Nov 1996 10:17:10 -0500 Received: from weeble.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22488 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 10:16:35 -0500 Received: from jon by weeble.lut.ac.uk with smtp (Exim 0.55 #1) id E0vKQkm-00043B-00; Mon, 4 Nov 1996 15:15:56 +0000 Date: Mon, 4 Nov 1996 15:15:56 +0000 (GMT) From: Jon Knight X-Sender: jon@weeble.lut.ac.uk To: Martin J Duerst Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com Subject: Re: [URN] New syntax draft In-Reply-To: <"josef.ifi..248:04.10.96.10.46.47"@ifi.unizh.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Jon Knight Errors-To: owner-urn-ietf@bunyip.com On Mon, 4 Nov 1996, Martin J Duerst wrote: > Yes. But now immagine that some of these French/German/Nordic/Icelandic > letters, or whatever else, is reserved, but that somebody was not able > to represent them directly, and used %-escaping. What are you going to do? But nobody is suggesting making the Nordic runes reserved characters are they? I was thinking that reserved characters would be a very well defined, small subset of the ASCII range, just as with URLs. > >And anyway, URLs don't use UTF-8 so this isn't going to be a problem > >(we're talking URNs here right?). > > I just explained the problems using URL examples. Just because > they problems might not apply to URLs, that still does not help > for URNs. Which means that URLs are maybe doing something right and we should take notice whilst doing URNs...? Such as only having a relatively small number of reserved characters. Tatty bye, Jim'll -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA29344 for urn-ietf-out; Mon, 4 Nov 1996 10:14:52 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA29337 for ; Mon, 4 Nov 1996 10:14:40 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22469 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 10:14:38 -0500 Message-Id: <9611041514.AA22469@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Mon Nov 4 09:13 CST 1996 From: "Ryan Moats" To: "Martin J Duerst" Cc: "urn-ietf@bunyip.com" Date: Mon, 04 Nov 96 09:14:28 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax draft) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com On Mon, 4 Nov 1996 11:50:36 +0100 (MET), Martin J Duerst wrote: >Ryan Moats wrote: > >> >>My brain hurts, but I think I finally understand the issue. > >Sorry for my long explanations. It wasn't your explanation, it was getting my brain to stop thinking in ASCII mode and start thinking in more general character mode. I'll probably still slip back and forth, since it isn't natural yet... >>Allow me to restate it to see if I'm right: >> >>The problem you are talking about arrises if the reserved character has >>a UTF-8 representation of more than 1 octet. Then, if we use %encoding >>to represent the character in a literal use, there is no way of determining >>from the URN whether the character is being used as a literal character >>or not. > >Exactly. > > >- Specify that protocols may only reserve 1-octet UTF-8 characters > (i.e. ASCII). >- Specify that protocols have to define their own escaping mechanisms > for things beyond ASCII. Having had the weekend to mull this over some more (and seeing that my mulling was in the right direction...), here are my thoughts: I would add a third solution to the above-- That the syntax draft defines its own escaping mechanism for things beyond ASCII. This ensures that URN resolvers don't have to be re-written just because some new namespace comes along that wants to reserve some character in some totally different scheme then all the others currently used. Having said that, I currently lean strongly towards the first solution that Martin has proposed, as it keeps the syntax document short, doesn't add a new escaping mechanism (and all the complexity that adds). To sum up, it just strikes me as being CLEANER than any other solution. Does anybody have problems with it being written into the syntax draft? Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA28449 for urn-ietf-out; Mon, 4 Nov 1996 08:47:34 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA28444 for ; Mon, 4 Nov 1996 08:47:32 -0500 From: Harald.T.Alvestrand@uninett.no Received: from domen.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21674 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 08:47:30 -0500 Received: from domen.uninett.no by domen.uninett.no with SMTP (PP) id <03479-0@domen.uninett.no>; Mon, 4 Nov 1996 14:44:28 +0100 X-Mailer: exmh version 1.6.7 5/3/96 To: Larry Masinter Cc: rdaniel@acl.lanl.gov, liberte@ncsa.uiuc.edu, urn-ietf@bunyip.com Subject: Re: [URN] HTTP resolution protocol In-Reply-To: Your message of "Mon, 04 Nov 1996 00:19:43 PST." <96Nov4.001943pst."2696"@golden.parc.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 14:44:25 +0100 Message-Id: <3476.847115065@domen.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com (Warning: I'm coming into this without reading the entire debate...) I like the idea that HTTP GET is an URI to MIME object resolution protocol. It either fails or returns a MIME object. But the scheme of service:/uri would IMHO require registering N2L, N2Ls, N2C and so on as URI types; this sounds wrong to me. If we want a resolution CONVENTION, it seems to me that the right convention is "GET /resolve/N2L/" (mimicking a CGI-BIN script). If we want a resolution STANDARD, it seems to me that the right thing is "N2L HTTP/1.1" For handing back lists of things, mimic the responses that were put into HTTP/1.1 for content negotiation (putting up a header for thte machine processible version and HTML for the human-readable version). Just my NOK 0.50.... Harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA27406 for urn-ietf-out; Mon, 4 Nov 1996 05:51:04 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA27401 for ; Mon, 4 Nov 1996 05:51:02 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21183 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 05:51:00 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00908-0@josef.ifi.unizh.ch>; Mon, 4 Nov 1996 11:50:37 +0100 Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax draft) To: jayhawk@ds.internic.net Date: Mon, 4 Nov 1996 11:50:36 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: <9611011512.AA05839@mocha.bunyip.com> from "Ryan Moats" at Nov 1, 96 09:12:22 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1322 From: Martin J Duerst Message-Id: <"josef.ifi..324:04.10.96.10.50.51"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ryan Moats wrote: >>Now for UTF-8, things are quite different. 8-bit bytes will >>on many occasions be escaped because it may be difficult to >>represent them otherwise. Having some character beyond ASCII >>represented with %HH (usually %HH%HH or %HH%HH%HH) can in no >>way imply that this is a special character. >>This means that any tools dealing with URNs in general will >>have no clue about where to keep the escaping, and where >>to remove it. A very exact knowledge of each NSS syntax >>would be needed. > >My brain hurts, but I think I finally understand the issue. Sorry for my long explanations. >Allow me to restate it to see if I'm right: > >The problem you are talking about arrises if the reserved character has >a UTF-8 representation of more than 1 octet. Then, if we use %encoding >to represent the character in a literal use, there is no way of determining >from the URN whether the character is being used as a literal character >or not. Exactly. >I'll save a discussion of potential solution directions to this until I'm sure >I understand the issue. I have already mentionned two possibilities: - Specify that protocols may only reserve 1-octet UTF-8 characters (i.e. ASCII). - Specify that protocols have to define their own escaping mechanisms for things beyond ASCII. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA27337 for urn-ietf-out; Mon, 4 Nov 1996 05:47:58 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA27325 for ; Mon, 4 Nov 1996 05:47:25 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21177 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 05:47:22 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <00897-0@josef.ifi.unizh.ch>; Mon, 4 Nov 1996 11:46:39 +0100 Subject: Re: [URN] New syntax draft To: jon@net.lut.ac.uk Date: Mon, 4 Nov 1996 11:46:38 +0100 (MET) Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com In-Reply-To: from "Jon Knight" at Nov 1, 96 01:44:31 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3326 From: Martin J Duerst Message-Id: <"josef.ifi..248:04.10.96.10.46.47"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Jon Knight wrote: >On Fri, 1 Nov 1996, Martin J Duerst wrote: >> When going from ASCII to UTF-8, there are some new problems. >> For ASCII, the general assumption is that only those charcters >> that need escaping are actually escaped, and therefore that >> escaping, e.g. for "/" or whatever, shouldn't be undone. >> The above is not exactly true, indeed the "~" is often escaped >> as %7E in Europe because it is difficult to type on European >> keyboards, but still I assume there are a lot of tools around >> working on URLs in general that work along the rule "if ASCII >> is escaped, don't remove the escaping, because this is a special >> character. > >Hmm, I don't really understand this; URL percent escaping is just away of >dealing with characters that you can't represent directly, either because >they're in the reserved set of characters or because they're not easy to >type (the French/German/Nordic/Icelandic letters in ISO-8859-1 for >example). If you're unescaping things, one would assume that you've >already parsed any reserved characters to extract any structuring >information that the provide. Yes. But now immagine that some of these French/German/Nordic/Icelandic letters, or whatever else, is reserved, but that somebody was not able to represent them directly, and used %-escaping. What are you going to do? Also, according to the syntax draft, intermediate software migth %-escape some UTF-8 part to pass the thing through a 7-bit channel. It will %-escape reserved and unreserved characters all alike. >Percent escaped characters aren't just >restricted to the reserved characters that need to be escaped; you can >percent escape your entire URL's path if you like. Any software that just >expects reserved characters to be percent escaped is going out of its way >to be braindead IMHO. The problem is with software that expects reserved charcters NOT to be escaped. >And anyway, URLs don't use UTF-8 so this isn't going to be a problem >(we're talking URNs here right?). I just explained the problems using URL examples. Just because they problems might not apply to URLs, that still does not help for URNs. And URLs don't use UTF-8 YET. They don't even use ASCII, in the sense we are proposing to use UTF-8 here. They just encode octets. For the benefit of us all, fortunately, there are some coincidences in most of the URL schemes, so that it actually looks as if URLs would use ASCII. If you currently see an URL with octets in the 8-bit range, there is not much of a chance to guess what characters it could represent. But steadily, the number of cases where there are chances that you get the characters if you interpret the octests as UTF-8 will be increasing. One example is ftp: The ftp-wg agreed on going into the direction of using UTF-8 as the common character encoding. According to the URL spec, that's up to ftp to decide. Because it is a very reasonable decision, it will hopefully be followed by others. The remaining formal difference between URL syntax and URN syntaxt would then be that the later officially allows the URN to be represented with characters/glyphs outside the ASCII range (on things such as cardboard boxes), but the former officially disallows such a behaviour. In practice, I guess this difference will vanish rather quickly. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id DAA26111 for urn-ietf-out; Mon, 4 Nov 1996 03:20:37 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id DAA26106 for ; Mon, 4 Nov 1996 03:20:35 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20672 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 03:20:03 -0500 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <15465(3)>; Mon, 4 Nov 1996 00:20:01 PST Received: by golden.parc.xerox.com id <2696>; Mon, 4 Nov 1996 00:19:43 PST To: Harald.T.Alvestrand@uninett.no Cc: rdaniel@acl.lanl.gov, liberte@ncsa.uiuc.edu, urn-ietf@bunyip.com In-Reply-To: <8499.847019598@dale.uninett.no> (Harald.T.Alvestrand@uninett.no) Subject: Re: [URN] HTTP resolution protocol From: Larry Masinter Message-Id: <96Nov4.001943pst."2696"@golden.parc.xerox.com> Date: Mon, 4 Nov 1996 00:19:43 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com # GET service:/uri HTTP/1.1 is certainly valid. Well, Request-Line = Method SP Request-URI SP HTTP-Version CRLF Request-URI = "*" | absoluteURI | abs_path and 'service:/uri' doesn't look like an 'abs_path', so it must be an 'absoluteURI'. While the HTTP spec doesn't explicitly limit Request-URIs to be URLs, I think it was the intent that they be resource identifiers of some sort. So now you're left with the idea that 'service' is really a kind of URL/URN scheme. You could do it, sure, and probably not break any existing HTTP servers either, but it's really odd to think of 'N2L' as a URI scheme, since it doesn't really locate a resource. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id CAA25882 for urn-ietf-out; Mon, 4 Nov 1996 02:58:11 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id CAA25877 for ; Mon, 4 Nov 1996 02:58:09 -0500 Received: from aun.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20595 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 02:58:06 -0500 Received: from dale.uninett.no by aun.uninett.no with SMTP (PP); Mon, 4 Nov 1996 08:57:46 +0100 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id MAA08501; Sun, 3 Nov 1996 12:13:18 +0100 From: Harald.T.Alvestrand@uninett.no To: Ron Daniel Cc: Daniel LaLiberte , Larry Masinter , urn-ietf@bunyip.com Subject: Re: [URN] HTTP resolution protocol In-Reply-To: Your message of "Thu, 31 Oct 1996 13:21:59 MST." <2.2.32.19961031202159.00699568@acl.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <8497.847019598.1@dale.uninett.no> Date: Sun, 03 Nov 1996 12:13:18 +0100 Message-Id: <8499.847019598@dale.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com GET service:/uri HTTP/1.1 is certainly valid. Harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA25384 for urn-ietf-out; Mon, 4 Nov 1996 01:47:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA25379 for ; Mon, 4 Nov 1996 01:47:12 -0500 Received: from IG.CS.UTK.EDU by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20288 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 01:47:10 -0500 Received: from localhost by ig.cs.utk.edu with SMTP (cf v2.11c-UTK) id BAA27792; Mon, 4 Nov 1996 01:46:45 -0500 (EST) Message-Id: <199611040646.BAA27792@ig.cs.utk.edu> X-Mailer: exmh version 1.6.7 5/3/96 X-Uri: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "Gregory J. Woodhouse" Cc: Leslie Daigle , Daniel LaLiberte , "Karen R. Sollins" , urn-ietf@bunyip.com, moore@cs.utk.edu Subject: Re: [URN] some comments In-Reply-To: Your message of "Sun, 03 Nov 1996 18:19:58 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 04 Nov 1996 01:46:45 -0500 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Keith Moore Errors-To: owner-urn-ietf@bunyip.com > Look at it from the point of view of implementation: Is > http://foo.bar.com/ a URL or a URN? Is there any conceptual reason why > http: cannot be a valid URN scheme? Yes. It's already well-established as a name space which does not have the properties desired for URNs. Now, if you ask a slightly different question: "can the protocols used to resolve URNs also be used to resolve some kinds of URLs?" ...then the answer is yes. This group needs to solve two problems: 1) how to provide long-term stable and resolvable resource identifiers. These are called URNs. 2. how to resolve many kinds of resource identifiers (not just URNs) to find multiple service locations etc. There is a lot of overlap between the solutions of these two problems, but they're not the same thing. We need to be careful that we don't confuse the two. Once the resolution system exists, the main difference between a URL and a URN is not the protocol used to perform resolution, but the discipline by which the name is assigned and used. Keith Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA25122 for urn-ietf-out; Mon, 4 Nov 1996 01:02:01 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA25117 for ; Mon, 4 Nov 1996 01:01:58 -0500 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA20136 (mail destined for urn-ietf@services.bunyip.com); Mon, 4 Nov 96 01:01:46 -0500 Received: from nic.cafax.se (paf@nic.cafax.se [193.12.122.42]) by nic.cafax.se (8.8.2/8.8.2) with SMTP id HAA03068; Mon, 4 Nov 1996 07:01:26 +0100 (MET) Date: Mon, 4 Nov 1996 07:01:25 +0100 (MET) From: Patrik Faltstrom X-Sender: paf@nic.cafax.se To: "Gregory J. Woodhouse" Cc: Leslie Daigle , Daniel LaLiberte , "Karen R. Sollins" , urn-ietf@bunyip.com Subject: Re: [URN] some comments In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com On Sun, 3 Nov 1996, Gregory J. Woodhouse wrote: > > Look at it from the point of view of implementation: Is > http://foo.bar.com/ a URL or a URN? http://foo.bar.com/ is a URL urn:http://foo.bar.com/ is a URN > Is there any conceptual reason why > http: cannot be a valid URN scheme? If it is possible for this to be a URN, > then under the NAPTR proposal it would be first necessary to do a DNS query > and receive and address for a service which will either resolve it for us > or tell us that it corresponds to the URL http://foo.bar.com/. Armed with > the information that this latter URI is a URL it is then possible to use > HTTP to retrieve the resource. >From an implementation standpoint the big difference is that when you have a URN scheme, the resolution protocol have to be able to change over time (in the NAPTR proposal from DNS to something else), the protocol used to fetch the data have to be able to be different between different locations of the resource (see the NAPTR and SRV records the NAPTR proposal uses) and the namespace have to be able to both grandfather and be grandfathered later on. All of the above without changing the name. One of the methods of doing a N2R, N2L, N2C etc. fetch for a URN after resolution is to use the http URL scheme, but that is definitely _after_ all of the URN abstraction levels have been resolved. Patrik Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id VAA23495 for urn-ietf-out; Sun, 3 Nov 1996 21:20:45 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id VAA23489 for ; Sun, 3 Nov 1996 21:20:38 -0500 Received: from dns2.noc.best.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19465 (mail destined for urn-ietf@services.bunyip.com); Sun, 3 Nov 96 21:20:36 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by dns2.noc.best.net (8.6.12/8.6.5) with SMTP id SAA25761; Sun, 3 Nov 1996 18:19:59 -0800 Date: Sun, 3 Nov 1996 18:19:58 -0800 (PST) From: "Gregory J. Woodhouse" To: Leslie Daigle Cc: Daniel LaLiberte , "Karen R. Sollins" , urn-ietf@bunyip.com Subject: Re: [URN] some comments In-Reply-To: <199611032218.RAA12973@beethoven.bunyip.com> Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com On Sun, 3 Nov 1996, Leslie Daigle wrote: > Dan, > > For all the words that have flown about on this mailing list in the past > few days, I don't really think you've made it clear what you want out > of this particular thread. Let me be fairly blunt in my interpretation > here, and you can tell me on which counts I have misunderstood you. > > I think there are 2 separate things in what you have been saying: > > . whether or not URNs are any different than URLs > . whether or not URNs can be implemented using URL mechanisms > > These are 2 very separate issues. Let me say, as co-chair of this working > group, that this WG starts from the premise that there _is_ a difference > between URNs and URLs, and that our chartered purpose is to refine an > architecture and experimental implementation that does not centre on > starting from URL mechanisms. > Look at it from the point of view of implementation: Is http://foo.bar.com/ a URL or a URN? Is there any conceptual reason why http: cannot be a valid URN scheme? If it is possible for this to be a URN, then under the NAPTR proposal it would be first necessary to do a DNS query and receive and address for a service which will either resolve it for us or tell us that it corresponds to the URL http://foo.bar.com/. Armed with the information that this latter URI is a URL it is then possible to use HTTP to retrieve the resource. --- Gregory Woodhouse gjw@wnetc.com home page: http://www.wnetc.com/home.html resource page: http://www.wnetc.com/resource/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA22518 for urn-ietf-out; Sun, 3 Nov 1996 17:18:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA22512 for ; Sun, 3 Nov 1996 17:18:12 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18485 (mail destined for urn-ietf@services.bunyip.com); Sun, 3 Nov 96 17:18:10 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id RAA12973; Sun, 3 Nov 1996 17:18:09 -0500 Message-Id: <199611032218.RAA12973@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Sun, 3 Nov 1996 17:18:08 -0500 In-Reply-To: Daniel LaLiberte's message as of Nov 3, 1:48 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Daniel LaLiberte , "Karen R. Sollins" Subject: Re: [URN] some comments Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Dan, For all the words that have flown about on this mailing list in the past few days, I don't really think you've made it clear what you want out of this particular thread. Let me be fairly blunt in my interpretation here, and you can tell me on which counts I have misunderstood you. I think there are 2 separate things in what you have been saying: . whether or not URNs are any different than URLs . whether or not URNs can be implemented using URL mechanisms These are 2 very separate issues. Let me say, as co-chair of this working group, that this WG starts from the premise that there _is_ a difference between URNs and URLs, and that our chartered purpose is to refine an architecture and experimental implementation that does not centre on starting from URL mechanisms. That purpose was selected after a process of consideration and consensus gathering (i.e., not unanimity, but a bulk of people suggesting they thought it had merit). To stick to our charter need not demonstrate the dogmatism or close-mindedness that I felt you were suggesting in your last mail to Karen -- it is a reflection of the fact that this is a directed effort. >From that standpoint, it is quite useful to consider other viewpoints and implementation mechanism insofar as the contribute a positive step towards defining, refining, explaining, or implementing the goal -- a sanity check, even. But, if you want to sit back and discuss the relative merits of different ways of how URIs could (have) be(en) implemented, you need to find a different discussional forum. I.e., I'm not saying it isn't valid/interesting discussional material -- I'm saying it's not for this space. > tomorrow. But I want to challenge the notion that we shouldn't rethink the > work of the last several years. For one thing, for the last 2 years, I > (and a few others) have been arguing against the split in names vs locations, > so why should that work be ignored? Dan, I think your frustration is misplaced. It is not that it "_is_" being ignored -- it is not being discussed _here_, because the starting premise for this WG is that it is not applicable. If you accept the basic premise of this working group, _and_ you still feel this is important, then the problem is that you have not adequately communicated to the people on this list _how_ your position is _not_ just completely at odds with everything we're trying to do (and, by the way, I would point out that it was in one of _your_ postings that you referred to "what you guys are doing" or some such terminology). > This is not a matter of just agreeing on a definition - it is a matter > of having definitions that make sense. A relative term -- I think the definitions make perfect sense. > But it is something that the client gets to decide! And the reason is > that "identifier of resource" vs "identifier of location of resource" > doesn't make sense. It is the chosen resolution mechanism that > determines how you get from an identifier to the resource. The > identifier does *not* determine the resolution mechanism, although > there may be conventions and globally agreed on mechanisms available. > The client *can* make the choice of how to resolve an identifier. It > is a fact of life in a free society that clients can do whatever they > want. (They can't always get away with it, though.) Without talking about resolution mechanisms, let me say this: a client _cannot_ decide, for any given string, "I want the thing this identifies", or "I want the thing at this location". Quite simply, if the client has the identifier of a location, it does not know _what_ the (intended) content is. This is _not_ a client decision. Consider this completely abstract example: . Location identifier: "the third thing from the right on the fourth shelf down" . Content identifier: "Moby Dick" If I am a client, holding the string "the third thing...", the only content I can refer to is whatever is there now -- I have no clue about what was there when location identifier was written down (included in an electronic document, beamed to my Newton, _whatever_). If the shelf has been re-arranged since this location was made, I will get whatever is there now. On the other hand, if I have "Moby Dick", I don't _care_ where it is now, where it was before, where it will be in the future or what I might have to do to get hold of it. The premise of this WG is that there is the need to be able to identify _what_ (i.e., content) one is looking for, as a separate task from identifying the location from which one wants content. If I have understood your position correctly, you are saying that there is no need for a new mechanism for retrieving things from shelves by name -- we'll just build new URL schemes wherein it is promised that shelves are never re-ordered (or at least, if they are, transparent pointers are used to continue the process to find the content that used to be located on a particular position), and thus the location description can be used as a unique, naming identifier. Here's my view on what has happened: to follow the above analogy a bit further, URLs are used to retrieve content by instructing something (call it a librarian in this case; in electronic terms, it is a scheme resolution process) to retrieve the content from a particular shelf and position. The URN proposal says "get me Moby Dick", and identifies a process whereby the librarian can figure out which shelf and object to retrieve. Because these (currently) look like much the same process, except for the implied longevity of the identifier, you are saying they are the same. I disagree. I think the URN approach is based on fundamentally different principles -- that it shall continue to be relevant long after shelves and objects are no longer useful mechanisms, and therefore they should _not_ play _any_ role in the naming process. I don't care if current URL and URN resolution mechanisms are isomorphic -- I am interested in defining the baseline implementation for the first generation of content identification strings -- divorced from location identification. I furthermore believe that the client (user or program) must be able to determine by some non-network-based mechanism, whether or not the identifier in hand is that of a location or of content. So, to sum up, the basic premises of this working group: . there is a difference between content identification and location identification . we have one proposed architecture for supporting the creation of effective content identifiers, and the use of these to determine content/location at any given point in time (resolution), and this is what we are working to refine. Dan, please tell me where I have missed your point... Leslie. -- ---------------------------------------------------------------------------- "The light at the end of the tunnel Leslie Daigle is often the blindingly obvious..." Vice President, Research Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA17886 for urn-ietf-out; Sun, 3 Nov 1996 09:50:09 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA17881 for ; Sun, 3 Nov 1996 09:50:07 -0500 Received: from nic.cafax.se by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17382 (mail destined for urn-ietf@services.bunyip.com); Sun, 3 Nov 96 09:50:04 -0500 Received: from nic.cafax.se (paf@nic.cafax.se [193.12.122.42]) by nic.cafax.se (8.8.2/8.8.2) with SMTP id PAA00892; Sun, 3 Nov 1996 15:49:51 +0100 (MET) Date: Sun, 3 Nov 1996 15:49:50 +0100 (MET) From: Patrik Faltstrom X-Sender: paf@nic.cafax.se To: Daniel LaLiberte Cc: Terry Allen , urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: <199611030651.AAA25490@ncsa.uiuc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Patrik Faltstrom Errors-To: owner-urn-ietf@bunyip.com On Sun, 3 Nov 1996, Daniel LaLiberte wrote: > and perhaps it is irrelevant semantics. What is relevant is that you > guys make a distinction between URLs and URNs, and it is a > distinction founded on a misunderstanding. I've been trying to dig > through to get to the heart of that misunderstanding. This is not a misunderstanding at all. There _is_ a difference between a URN and a URL which from my point of view _you_ have not understood. A URL refers to a location which though a caching mechanism, a proxy cache, an interceptor with cache, multiple A-records in DNS or whatever ends up refering to more than one occurance of the same resource. A URN is a _name_ of a resource which have absolutely _NOTHING_ to do with the resolution protocol, the different versions of the resource that exist (text, postscript etc), the different protocols used to locate and later fetch the resource or the metadata for the resource. There are a couple of us that during all of the years so far has only been talking about this difference being very very important. If you don't understand this difference...well...what are _we_ supposed to do about that. The difference is needed! > But the very same URL was used to retrieve the resource either from a > cache or from a remote server. So what "location" is the URL > identifying when the resource actually lives in multiple places - the > very same URL may be used to fetch the resource from any of those > places? Notice you first say that a URL identifies (or names) the > location of a resource, and then we find out that there are really > multiple locations identified by the URL. But that is supposed to be > the job of URNs. So why do we need URNs? Please Dan! There is a difference between having two A-records pointing to two different IP-addresses, and when you later connect to that hostname (which is resolved to one of the two addresses) you will end up at one of the two locations. You can use this technique in for example the hostname in a URL of course. You can also use a proxy cache or an interceptor to see that you pick the copy of the resource that is the most convinient for you. BUT, you are still refering to _one_ location where the resource is located. If you happen to have a local copy, well, let's use that one. It's the same thing as if you do an lseek() in the filesystem and want to read some bytes from a file. If the filesystem have cached those diskblocks, and give you the copies of the bits that happened to sit in RAM and not on the physical disk, are you not using an lseek() anyway? Dan, you _have_ to start to differ between multiple locations of a resource which is addressed by a URL - i.e. it's original location, and the functionality that is built into the system when a _name_ is assigned to a resource. As long as you have not seen this difference that many of us others have seen, it is a little bit hard to have a meaningful discussion. Sorry for being harsh and short, but I am now a little bit tired of having to try to come up with exactly the same arguments we have been having since the UR* discussions started. We have to move forward! > I used "http://www.ncsa.uiuc.edu/" for both, no "urn:" or "url:" for > either. (BTW, If "urn:" is optional, then > "urn:http://www.ncsa.uiuc.edu/" has identically the same meaning - it > is an equivalent identifier). A client can resolve > "http://www.ncsa.uiuc.edu/" using HTTP or using the NAPTR protocol, or > something else. This is the very same identifier, not two identifiers > with the same character representation. Calling it two identifiers > and saying one is a name and the other is [the name of] a location is > missing the whole point. No, _you_ are missing the point. By saying that "urn:http://www.ncsa.uiuc.edu/" is a _name_, one know that this namespace called HTTP can grandfather other namespaces, this _name_ can stay as it is even if the resource moves, the metadata for this resource can be fetched etc etc all according to the URN spec that was written down years ago. If you have a URL, like "http://www.ncsa.uiuc.edu/", what do you do if you have to move this resource from the host www.ncsa.uiuc.edu? Change things in the DNS? But of course that works. But, if you move the information from staying only on an http server to also stay in a Z39.50 database and want the clients to be able to use both, or if the resolution from www.ncsa.uiuc.edu to a hostname, which later is turned into an IP-address in DNS is not done in DNS for some reason in the future? What if the resource is mirrored to a different site? There are thousands of things you _can_not_do_ with the name of a location of something, that you only can do with a _name_ of a resource which is resolved to one or many alternative locations. > The point is a single identifier can, in fact, be resolved many > different ways by clients. Some ways are more direct (e.g. HTTP) and > some are more indirect (e.g. NAPTR). They are all resolution > mechanisms. They all result, eventually, in the resource, or whatever > is being requested. You _have_ to start to look at what kind of resolutions you do, and can do. Just because you can have one A-record point to a list of IP-addresses, that doesn't help you because the way the zones in DNS are delegated. You _have_ to look at who owns what part of the information used in the resolution process! > I see no difference between *names* and *locations* at least > regarding the identifiers themselves. I can see that. There seems to, though, to be a number of people that do, and I am one of them. Patrik Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id CAA15922 for urn-ietf-out; Sun, 3 Nov 1996 02:52:34 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id CAA15917 for ; Sun, 3 Nov 1996 02:52:31 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16743 (mail destined for urn-ietf@services.bunyip.com); Sun, 3 Nov 96 02:52:29 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id BAA25657; Sun, 3 Nov 1996 01:48:05 -0600 (CST) Date: Sun, 3 Nov 1996 01:48:05 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611030748.BAA25657@ncsa.uiuc.edu> To: "Karen R. Sollins" Cc: urn-ietf@bunyip.com Subject: Re: [URN] some comments In-Reply-To: <199611020043.TAA07540@lysithea.lcs.mit.edu> References: <199611020043.TAA07540@lysithea.lcs.mit.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Karen R. Sollins writes: > This is a response to several responses to my message (each time I sit > down to respond I'm interrupted and by the time I get back to it there > has been more mail:-) I know what you mean. I have to wait til the quiet hours to get real work done. > First, I want to echo what Leslie has been saying. Unless we are > going to rethink all the work of the last 3 or more years, URNs > identify resources and URLs identify locations of resources and these > are different abstractions. They could be chosen from the same set of > names, but they have different requirements on the names (see RFC1736 > and RFC1737). Enough said on that topic; for any more, see Leslie's > lucid comments. I'll comment on Leslie's comments, perhaps tomorrow. But I want to challenge the notion that we shouldn't rethink the work of the last several years. For one thing, for the last 2 years, I (and a few others) have been arguing against the split in names vs locations, so why should that work be ignored? This is not a matter of just agreeing on a definition - it is a matter of having definitions that make sense. For much longer, Tim Berners-Lee has argued against this name-location split. Most, if not all, of the W3C staff agree with this, and I don't think it is because they were tested on this point before being hired. I didn't agree with Tim at first, but it wasn't out of respect for him that I changed my mind. It takes a decision not to be dogmatic, though, to be open to honest rethinking. > From: Daniel LaLiberte > > One way to avoid this is to make sure that the context for resolution > is always clear. So when giving a URL in an HTML document you could > use HTTP="scheme:opaque-string", and when giving a URN you could use a > different tag, e.g. URN="nsi:opaque-string". This idea tends to pop > up occasionally, but I think it not useful. > > Leslie responded to most of this message, but this point surprised > me. You are suggesting that in HTML we label URNs as such. My suggestion was hypothetical. I am *not* suggesting we do it. > I am left with two questions. First, why is that only in HTML > should they be labelled? Where did I say only HTML? It was an example. > Second, why is it that the holder of a string (the principle > putting the string into the HTML document in this case) is the one > to decide which string is a URN and which is not? Good point. And this is a good reason *not* to do it. > Shouldn't that be decided by whoever did the name assignment? Yes and no. The creator of the identifier could use a name space associated with a resolution mechanism that provides name properties. But the author of the document containing the identifier *could* also suggest a resolution mechanism that provides name properties. Also, the client itself *could* use a resolution mechanism that provides name properties. The identifier itself does not provide name properties - the resolution mechanism does. > So, my conclusion is that, if it is really important to > label URNs (which I happen to believe is true, and it seems you are > suggesting) I am not suggesting that - to the contrary, I am arguing for the opposite of that. (Maybe you forgot who you were replying to.) I raised the idea of labelling identifiers as URNs within the context of their use precisely so it could be shot down. Thanks. > and if the assigner of an identifier should be the > determiner of whether the identifier is identifying a resource or a > location for a resource, the assigner of the identifier should clarify > that fact by including it in the identifier for all to know. This is > not something that the "client" gets to decide. But it is something that the client gets to decide! And the reason is that "identifier of resource" vs "identifier of location of resource" doesn't make sense. It is the chosen resolution mechanism that determines how you get from an identifier to the resource. The identifier does *not* determine the resolution mechanism, although there may be conventions and globally agreed on mechanisms available. The client *can* make the choice of how to resolve an identifier. It is a fact of life in a free society that clients can do whatever they want. (They can't always get away with it, though.) -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA15524 for urn-ietf-out; Sun, 3 Nov 1996 01:56:31 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA15517 for ; Sun, 3 Nov 1996 01:56:23 -0500 Received: from void.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA16634 (mail destined for urn-ietf@services.bunyip.com); Sun, 3 Nov 96 01:56:20 -0500 Received: (from liberte@localhost) by ncsa.uiuc.edu (8.7.6/8.7.3) id AAA25490; Sun, 3 Nov 1996 00:51:41 -0600 (CST) Date: Sun, 3 Nov 1996 00:51:41 -0600 (CST) From: Daniel LaLiberte Message-Id: <199611030651.AAA25490@ncsa.uiuc.edu> To: Terry Allen Cc: urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: <199610312051.MAA10123@ishtar.fsc.fujitsu.com> References: <199610312051.MAA10123@ishtar.fsc.fujitsu.com> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Daniel LaLiberte writes: > | OK, what is a location? > | ... Is it the > | domain name of the server, together with the path within the server? > | That's getting closer to the abstraction that URLs provide. Is the > | location, in fact, the URL itself? Terry Allen writes: > No, the URL is neither the location nor the resource, but the > name of a location, or a name of a location that may be resolved > on the fly. The location is not the resource; the name of the > location is not the name of the resource. On the face of it, this is sounding rather strange. First, I agree that the URL is not the resource itself (who would say that it is? from your comment at the end, I think you think I said that). Saying a URL is "the name of a location" is almost the same as "a URL identifies a location". The extra indirection of going from URL to identifier to location, rather than URL to location, seems unnecessary, and perhaps it is irrelevant semantics. What is relevant is that you guys make a distinction between URLs and URNs, and it is a distinction founded on a misunderstanding. I've been trying to dig through to get to the heart of that misunderstanding. > | Consider caches. The resolution of a URL via a cache proxy may find > | the resource in the cache rather than in some remote server. What is > | "the location" of the resource in that case? > > What is "the resource"? Any copy of what you got back from resolution? > then its location is both in the cache and on the remote server. > Is it "the copy I got back from resolution"? then its location > is in the cache. But the very same URL was used to retrieve the resource either from a cache or from a remote server. So what "location" is the URL identifying when the resource actually lives in multiple places - the very same URL may be used to fetch the resource from any of those places? Notice you first say that a URL identifies (or names) the location of a resource, and then we find out that there are really multiple locations identified by the URL. But that is supposed to be the job of URNs. So why do we need URNs? > | Here is an example of how what is thought of as a location really > | turns out to *be* a name (as in persistent location). Take a normal > | http URL such as http://www.ncsa.uiuc.edu/. Instead of using normal > | HTTP to resolve the URL, or to look it up in a cache, let's set up a > | NAPTR-based "http" naming authority. Under that branch of the name > | space, we could ask the appropriate DNS server to look up > | 'www.ncsa.uiuc.edu' to find out where a server is currently located > | and what "resolution protocols" are currently supported. > > That is a coincidence of naming: you made the name of the resource > (qua URN) be the same as the name of its location. But > urn:http://www.ncsa.uiuc.edu/ > and > url:http://www.ncsa.uiuc.edu/ > name two different things. I used "http://www.ncsa.uiuc.edu/" for both, no "urn:" or "url:" for either. (BTW, If "urn:" is optional, then "urn:http://www.ncsa.uiuc.edu/" has identically the same meaning - it is an equivalent identifier). A client can resolve "http://www.ncsa.uiuc.edu/" using HTTP or using the NAPTR protocol, or something else. This is the very same identifier, not two identifiers with the same character representation. Calling it two identifiers and saying one is a name and the other is [the name of] a location is missing the whole point. The point is a single identifier can, in fact, be resolved many different ways by clients. Some ways are more direct (e.g. HTTP) and some are more indirect (e.g. NAPTR). They are all resolution mechanisms. They all result, eventually, in the resource, or whatever is being requested. > | We don't need to create a new kind of identifier to make a URL > | into a persistent location. > Which is not what you did in the example just given. It is so. > You created a new name space and rules for using it that by design > produce a name that looks like a URL which, when resolved, will > give the same result. The name space is just a vehicle for resolving the identifier. Consider how a cache creates a name space for looking up resources given http URLs (usually it's just a hash table, but imagine it creates a similar hierarchy to model DNS and filesystems within servers). Would you claim that the cache is somehow making new identifiers? Here is, perhaps, the missing point: The persistence of a name space is not a property of the identifiers - it is a property of the mechanism used to resolve the identifiers. You seem to be saying that the persistence is a property of URNs, and thus names are obviously different from locations. I am saying that the persistence of URNs is due to resolution mechanisms such as the NAPTR mechanism. (It is also due to the naming authorities guaranteeing that the names will behave properly if the appropriate resolution mechanism is used.) Since different mechanisms can be used to resolve the very same identifiers, and since some mechanisms might provide persistence while others do not, there is no point in distinguishing the identifiers as either names or locations. There is nothing inherent in identifiers themselves that makes them have different properties, whether name-like or location-like. It is how the identifiers are created and used that gives them those properties. >From that standpoint, http URLs are different from new classes of identifiers that will be created under the URN name space(s). I certainly recognize that we need more persistence in the resolution process, and that is why we created the "path" resolution mechanism. (In fact, I believe the NAPTR mechanism doesn't go quite far enough, and agree with Larry in that regard.) But it is not the identifiers themselves that need to be distinguished based on the properties of the resolution mechanism. For one class of identifier, there might be two resolution mechanisms available, one supports persistence and the other does not. So are the identifiers names or locations? Irrelevant question. > | To summarize, both URLs and URNs have the following abstract > | resolution process in common: > | 1. Do some client-specific processing of the URI - maybe end there. > | 2. Look at the scheme name of the URI. If it says "URN:" drop it and repeat. > > No, you have to branch into your "find URN" subprocess. You could handle everything with "URN:" prefix with the same process, but it is not required - you could just as well handle each URN subscheme differently. Or you could handle parts of a single name space differently from the rest. > | 3. Look up the scheme in local table to find out what process should > > The local table will be different for URLs and URNs, will it not? Not necessarily. Each URL or URN scheme might have a different process associated with it, or we could use just one process for all schemes. > | be invoked. E.g. news URIs may use NNTP, http URIs may use HTTP, > | cid URIs may use NAPTR-protocol. > | 4. Invoke the process identified by step 3. > | 5. If error results, exit. > | 6. If redirected to another URI, repeat whole process with that URI. > | > | An alternative to steps 2 and 3 would use more than just the scheme > | name to determine what process to invoke. There are several other > | varients possible in the whole process, and each client or each user > | might do things differently. > | > | I hope I've made my postion very clear regarding names, locations, and > | the resolution process. > > That you see no difference between objects and their locations? I really don't see how you got that. When did I talk about the difference between objects and their locations? I see no difference between *names* and *locations* at least regarding the identifiers themselves. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA01925 for urn-ietf-out; Fri, 1 Nov 1996 19:43:24 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA01907 for ; Fri, 1 Nov 1996 19:43:21 -0500 Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11306 (mail destined for urn-ietf@services.bunyip.com); Fri, 1 Nov 96 19:43:18 -0500 Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id TAA07540; Fri, 1 Nov 1996 19:43:18 -0500 Date: Fri, 1 Nov 1996 19:43:18 -0500 Message-Id: <199611020043.TAA07540@lysithea.lcs.mit.edu> From: "Karen R. Sollins" To: urn-ietf@bunyip.com Subject: Re: [URN] some comments Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Karen R. Sollins" Errors-To: owner-urn-ietf@bunyip.com This is a response to several responses to my message (each time I sit down to respond I'm interrupted and by the time I get back to it there has been more mail:-) First, I want to echo what Leslie has been saying. Unless we are going to rethink all the work of the last 3 or more years, URNs identify resources and URLs identify locations of resources and these are different abstractions. They could be chosen from the same set of names, but they have different requirements on the names (see RFC1736 and RFC1737). Enough said on that topic; for any more, see Leslie's lucid comments. Let me respond (hopefully briefly) to various different responders to me: From: Terry Allen You phrase this as a general matter, and we clearly cannot pretend to govern all resolutions methods. As a trivial example, one method of URN resolution is the publication of physical books containing URNs and other information. Some URNs may be resolvable only by such non-Internet means. Suppose the government were to insist that copies of such books that are sold to the government must be printed on tamper-resistant paper (someone wanting security). Is that something this group should concern itself with? I don't think so, I don't think that one can speak of *the* "infrastructure supporting URN resolution," and so I don't agree with your very general statement. Can you sharpen it up some? Let's just stick to the Internet. I didn't realize that I needed to qualify what I was saying with this statement, but I hope it helps. In fact we have even less say over what happens outside the Internet than we do on the inside:-) From: Daniel LaLiberte One way to avoid this is to make sure that the context for resolution is always clear. So when giving a URL in an HTML document you could use HTTP="scheme:opaque-string", and when giving a URN you could use a different tag, e.g. URN="nsi:opaque-string". This idea tends to pop up occasionally, but I think it not useful. Leslie responded to most of this message, but this point surprised me. You are suggesting that in HTML we label URNs as such. I am left with two questions. First, why is that only in HTML should they be labelled? If it is useful to label URNs as distinct from other things, this is probably the case everywhere. And I certainly don't expect that everything will be in HTML. Second, why is it that the holder of a string (the principle putting the string into the HTML document in this case) is the one to decide which string is a URN and which is not? Shouldn't that be decided by whoever did the name assignment? So, my conclusion is that, if it is really important to label URNs (which I happen to believe is true, and it seems you are suggesting) and if the assigner of an identifier should be the determiner of whether the identifier is identifying a resource or a location for a resource, the assigner of the identifier should clarify that fact by including it in the identifier for all to know. This is not something that the "client" gets to decide. From: Ron Daniel I totally support the goal of allowing people to have high security if they want it. That is why I am in total, adamant, and unequivocal opposition to the assumption in part 2 - that there might be a URN resolution system with such poor isolation between security domains. I'm afraid you lost me in all the companies that do and don't want the same or different things, but I think we are really having an agreement. Let me give you a simple example of what I had in mind. For the sake of making things concrete, suppose we are using name resolution scheme NS_TRANS (made up) that manages a widely distributed core of translation information that allows for lookup of particular URNs and provides pointers to final stage URN resolution (probably URN to URL translation) servers managed by naming authorities. Then also suppose there is some naming authority NAT_SEC_CO that would like to cause the names it is assigning to be resolved as it believes is correct. NAT_SEC_CO would like to be confident that the information it provides to NS_TRANS is what will be distributed to potential customers and no one who is not authorized can change that information. At the same time, another naming authority NON_SEC_CO believes that the best way for information to be kept up to date is for it to be updatable by anyone, because it is the customers who will discover problems in the resolution information, and will be most motivated to make the corrections (I've heard this position taken by a very reputable person in a security conscious company in a slightly different context.) The position I take on this is that NS_TRANS had better have security mechanisms available to protect NAT_SEC_CO information and furthermore, anyone who wants to have access to it including NON_SEC_CO will have to play the right security game to get access to NAT_SEC_CO's information for modification. At the same time NAT_SEC_CO is given free and open access to NON_SEC_CO's information, as is the case for anyone else. The security infrastructure needs to be there in this case and anyone wanting access to controlled parts will have to play the game properly. It does not mean that the whole infrastructure or even the security provided for those that want it should in any way be dependent on untrustworthy components. That's nonsense, as you rightly point out. But it will depend on the infrastructure providing some security functionality for those that want it and imposing that on everyone who wants service in that corner of the infrastructure space. If we could not depend on the infrastructure for anything, how could we depend on supposed implementations of DNSSEC either? It will only work if the infrastructure is playing the game. Of course, each peer server in the infrastructure will also need to be defensive to protect against incorrectly behaving peers. But that's true in the DNS as well. So, Ron, I believe we are on the same side of this one:-) Karen PS: My apologies - I had planned to keep this short, but it got away from me. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA27704 for urn-ietf-out; Fri, 1 Nov 1996 10:58:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA27699 for ; Fri, 1 Nov 1996 10:58:47 -0500 Received: from workstation1.swip.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06202 (mail destined for urn-ietf@services.bunyip.com); Fri, 1 Nov 96 10:58:45 -0500 Received: (from leslie@localhost) by pluto.swip.net (8.7.6/8.6.12) id QAA06560; Fri, 1 Nov 1996 16:58:41 +0100 (MET) Date: Fri, 1 Nov 1996 16:58:41 +0100 (MET) From: Leslie Daigle X-Sender: leslie@pluto.swip.net To: Daniel LaLiberte Cc: urn-ietf@bunyip.com Subject: Re: Names and Locations (was [URN] some comments) In-Reply-To: <199610311951.NAA10608@ncsa.uiuc.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Leslie Daigle Errors-To: owner-urn-ietf@bunyip.com [Dan LaLiberte wrote:] > OK, what is a location? Is it the bits on the disk that "has" the Well, here's my perspective: A URL (location) is a point in 4-space, as defined by: =09. machine (aliased through DNS mechanisms) =09. port number (default per protocol) =09. protocol to speak on that port and at that machine =09. string to use within that protocol A basic URN (name) has nothing to do with these 4 dimensions -- it is=20 independent of any machine identifier, port, or protocol. The string associated with it is a _label_ that is unique across the specified namespace. > Consider caches. The resolution of a URL via a cache proxy may find > the resource in the cache rather than in some remote server. What is > "the location" of the resource in that case? Caches are external to either URN or URL systems. They may choose to use the URL string as a label that identifies a particular resource, and use that label to lookup contents of the cache. But, caches break when the label does not change, but the contents of the location does. If you cache based on URN, your cache will not break, because the content associat= ed with the identifier does not change. > Here is an example of how what is thought of as a location really > turns out to *be* a name (as in persistent location). Take a normal > http URL such as http://www.ncsa.uiuc.edu/. Instead of using normal > HTTP to resolve the URL, or to look it up in a cache, let's set up a > NAPTR-based "http" naming authority. Under that branch of the name > space, we could ask the appropriate DNS server to look up > 'www.ncsa.uiuc.edu' to find out where a server is currently located > and what "resolution protocols" are currently supported. >=20 > We don't need to create a new kind of identifier to make a URL into a > persistent location. We *do* need new persistent services, such as > the NAPTR records in DNS. I'm not sure I understand the point you are making here. It sounds like you are saying -- forget everything else about all this stuff, let's=20 do NAPTR as a service, and then people can build in persistence using whichever mechansisms strike their fancy? I have a problem with that approach, for (at least) two reasons: =09. implementing a persistent location means adding much overhead =09 in systems that were not built for it. =09. there are then no mechanisms to distinguish between things that =09 are meant to be persistent, and things that are expected not =09 to be. =20 > To summarize, both URLs and URNs have the following abstract > resolution process in common: >=20 > 1. Do some client-specific processing of the URI - maybe end there. > 2. Look at the scheme name of the URI. If it says "URN:" drop it and rep= eat. > 3. Look up the scheme in local table to find out what process should > be invoked. E.g. news URIs may use NNTP, http URIs may use HTTP, > cid URIs may use NAPTR-protocol. > 4. Invoke the process identified by step 3.=20 > 5. If error results, exit. > 6. If redirected to another URI, repeat whole process with that URI. >=20 It is definitely interesting to look at the surface similarities in mechani= cs between URL resolution and the NAPTR approach to URN handling. What still is not clear to me is what you are suggesting to _do_ with this. If you are suggesting that there is nothing more to do with URN work than to define different steps in 2 and 3, I have a problem with that... Leslie. ---------------------------------------------------------------------------= - Leslie Daigle "Min sv=E4vare =E4r full av =E5lar!" Vice President, Research Bunyip Information System= s -- ThinkingCat (514) 875-8611 leslie@bunyip.com ---------------------------------------------------------------------------= - Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA27189 for urn-ietf-out; Fri, 1 Nov 1996 10:12:16 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA27184 for ; Fri, 1 Nov 1996 10:12:14 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA05839 (mail destined for urn-ietf@services.bunyip.com); Fri, 1 Nov 96 10:12:11 -0500 Message-Id: <9611011512.AA05839@mocha.bunyip.com> Received: by privateer.windrose.omaha.ne.us; Fri Nov 1 09:11 CST 1996 From: "Ryan Moats" To: "jayhawk@ds.internic.net" , "Martin J Duerst" Cc: "urn-ietf@bunyip.com" Date: Fri, 01 Nov 96 09:12:22 Priority: Normal X-Mailer: PMMail 1.52 For OS/2 UNREGISTERED SHAREWARE Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: [URN] %encoding for reserved UTF-8 characters (was: New syntax draft) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ryan Moats" Errors-To: owner-urn-ietf@bunyip.com Sorry folks, but I need to keep the threads separate to keep my sanity [at least whatever remains of it.... ;-)] On Fri, 1 Nov 1996 12:11:37 +0100 (MET), Martin J Duerst wrote: >When going from ASCII to UTF-8, there are some new problems. >For ASCII, the general assumption is that only those charcters >that need escaping are actually escaped, and therefore that >escaping, e.g. for "/" or whatever, shouldn't be undone. >The above is not exactly true, indeed the "~" is often escaped >as %7E in Europe because it is difficult to type on European >keyboards, but still I assume there are a lot of tools around >working on URLs in general that work along the rule "if ASCII >is escaped, don't remove the escaping, because this is a special >character. >Now for UTF-8, things are quite different. 8-bit bytes will >on many occasions be escaped because it may be difficult to >represent them otherwise. Having some character beyond ASCII >represented with %HH (usually %HH%HH or %HH%HH%HH) can in no >way imply that this is a special character. >This means that any tools dealing with URNs in general will >have no clue about where to keep the escaping, and where >to remove it. A very exact knowledge of each NSS syntax >would be needed. My brain hurts, but I think I finally understand the issue. Allow me to restate it to see if I'm right: The problem you are talking about arrises if the reserved character has a UTF-8 representation of more than 1 octet. Then, if we use %encoding to represent the character in a literal use, there is no way of determining from the URN whether the character is being used as a literal character or not. I'll save a discussion of potential solution directions to this until I'm sure I understand the issue. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA25992 for urn-ietf-out; Fri, 1 Nov 1996 08:48:19 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA25987 for ; Fri, 1 Nov 1996 08:48:16 -0500 Received: from weeble.lut.ac.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04787 (mail destined for urn-ietf@services.bunyip.com); Fri, 1 Nov 96 08:45:36 -0500 Received: from jon by weeble.lut.ac.uk with smtp (Exim 0.55 #1) id E0vJJtg-0000iI-00; Fri, 1 Nov 1996 13:44:32 +0000 Date: Fri, 1 Nov 1996 13:44:31 +0000 (GMT) From: Jon Knight X-Sender: jon@weeble.lut.ac.uk To: Martin J Duerst Cc: jayhawk@ds.internic.net, urn-ietf@bunyip.com Subject: Re: [URN] New syntax draft In-Reply-To: <"josef.ifi..673:01.10.96.11.11.39"@ifi.unizh.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Jon Knight Errors-To: owner-urn-ietf@bunyip.com On Fri, 1 Nov 1996, Martin J Duerst wrote: > When going from ASCII to UTF-8, there are some new problems. > For ASCII, the general assumption is that only those charcters > that need escaping are actually escaped, and therefore that > escaping, e.g. for "/" or whatever, shouldn't be undone. > The above is not exactly true, indeed the "~" is often escaped > as %7E in Europe because it is difficult to type on European > keyboards, but still I assume there are a lot of tools around > working on URLs in general that work along the rule "if ASCII > is escaped, don't remove the escaping, because this is a special > character. Hmm, I don't really understand this; URL percent escaping is just away of dealing with characters that you can't represent directly, either because they're in the reserved set of characters or because they're not easy to type (the French/German/Nordic/Icelandic letters in ISO-8859-1 for example). If you're unescaping things, one would assume that you've already parsed any reserved characters to extract any structuring information that the provide. Percent escaped characters aren't just restricted to the reserved characters that need to be escaped; you can percent escape your entire URL's path if you like. Any software that just expects reserved characters to be percent escaped is going out of its way to be braindead IMHO. And anyway, URLs don't use UTF-8 so this isn't going to be a problem (we're talking URNs here right?). Tatty bye, Jim'll -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer Studies, Loughborough University of Technology, Leics., ENGLAND. LE11 3TU. * I've found I now dream in Perl. More worryingly, I enjoy those dreams. * Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id GAA25071 for urn-ietf-out; Fri, 1 Nov 1996 06:13:13 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id GAA25066 for ; Fri, 1 Nov 1996 06:13:11 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03771 (mail destined for urn-ietf@services.bunyip.com); Fri, 1 Nov 96 06:13:09 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01729-0@josef.ifi.unizh.ch>; Fri, 1 Nov 1996 12:11:38 +0100 Subject: Re: [URN] New syntax draft To: jayhawk@ds.internic.net Date: Fri, 1 Nov 1996 12:11:37 +0100 (MET) Cc: urn-ietf@bunyip.com In-Reply-To: <9610312029.AA28199@mocha.bunyip.com> from "Ryan Moats" at Oct 31, 96 02:29:20 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1952 From: Martin J Duerst Message-Id: <"josef.ifi..673:01.10.96.11.11.39"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ryan Moats wrote: >On Thu, 31 Oct 1996 11:58:35 +0100 (MET), Martin J Duerst wrote: > >>> It should be noted that certain characters in the Namespace Specific >>> String syntax may have special meaning in certain namespaces. >>> Therefore, the process of registering a namespace identifier shall >>> include publication of a definition of which characters have a >>> special meaning and how to encode these characters if used in a >>> literal sense. >> >>Can they be encoded with %HH? Or should we specifically request some >>other mechanism in order to not confuse different things, and let >>programs that deal with URNs in general change from %HH to 8-bit >>and back? > >Well, I don't have a current opinion one way or the other. Thinking about >it some more, I don't see how we can avoid %HH encoding, so why not >just say that encoding must be specified if %HH isn't used. When going from ASCII to UTF-8, there are some new problems. For ASCII, the general assumption is that only those charcters that need escaping are actually escaped, and therefore that escaping, e.g. for "/" or whatever, shouldn't be undone. The above is not exactly true, indeed the "~" is often escaped as %7E in Europe because it is difficult to type on European keyboards, but still I assume there are a lot of tools around working on URLs in general that work along the rule "if ASCII is escaped, don't remove the escaping, because this is a special character. Now for UTF-8, things are quite different. 8-bit bytes will on many occasions be escaped because it may be difficult to represent them otherwise. Having some character beyond ASCII represented with %HH (usually %HH%HH or %HH%HH%HH) can in no way imply that this is a special character. This means that any tools dealing with URNs in general will have no clue about where to keep the escaping, and where to remove it. A very exact knowledge of each NSS syntax would be needed. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id FAA24927 for urn-ietf-out; Fri, 1 Nov 1996 05:41:54 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id FAA24922 for ; Fri, 1 Nov 1996 05:41:51 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03675 (mail destined for urn-ietf@services.bunyip.com); Fri, 1 Nov 96 05:41:49 -0500 Received: from ifi.unizh.ch by josef.ifi.unizh.ch id <01687-0@josef.ifi.unizh.ch>; Fri, 1 Nov 1996 11:40:58 +0100 Subject: Re: [URN] More on UTF-8 Decoding (was: New syntax draft) To: jayhawk@ds.internic.net Date: Fri, 1 Nov 1996 11:40:57 +0100 (MET) Cc: gjw@wnetc.com, urn-ietf@bunyip.com In-Reply-To: <9610312052.AA28783@mocha.bunyip.com> from "Ryan Moats" at Oct 31, 96 02:52:22 pm Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 775 From: Martin J Duerst Message-Id: <"josef.ifi..598:01.10.96.10.41.13"@ifi.unizh.ch> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Martin J Duerst Errors-To: owner-urn-ietf@bunyip.com Ryan Moats wrote: >On Thu, 31 Oct 1996 14:38:57 +0100 (MET), Martin J Duerst wrote: > >>Gregory Woodhouse wrote: >> >>>I'm also concerned because decoding requires knowledge that the string >>>being decoded is UTF-8. >> >>Not exactly. It is very rare that a string that is not UTF-8 looks >>like an UTF-8 string. > >I think this is a good argument for taking UTF-8 decoding out >of the syntax document. Any reasons to leave it in? No, because if you "decode" UTF-8, you get characters, without saying of how exactly they are represented, and so "decode" is definitely the wrong name. You might consider replacing it with "interpretation", but this is only necessary in some cases (e.g. when trying to represent these things on sceen), and not in others. Regards, Martin.