Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA29018 for urn-ietf-out; Sat, 28 Dec 1996 04:37:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA29000; Sat, 28 Dec 1996 04:37:37 -0500 Received: from paris.ics.uci.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA25738 (mail destined for urn-ietf@services.bunyip.com); Sat, 28 Dec 96 04:37:35 -0500 Received: from liege.ics.uci.edu by paris.ics.uci.edu id aa05581; 28 Dec 96 1:30 PST To: Ryan Moats Cc: uri@bunyip.com, urn-ietf@bunyip.com Subject: [URN] Re: Comments on url-syntax-draft... In-Reply-To: Your message of "Fri, 27 Dec 1996 10:39:46 CST." <32C3FBD2.7FA0@ds.internic.net> Date: Sat, 28 Dec 1996 01:30:19 -0800 From: "Roy T. Fielding" Message-Id: <9612280130.aa05581@paris.ics.uci.edu> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Roy T. Fielding" Errors-To: owner-urn-ietf@bunyip.com > I forsee problems in the URL draft with any potential "meta-scheme", > an example of which is providing checksums for a URx if it maintains > its current section 1.1 language. I see no such problems. For one thing, there is no such thing as a "meta-scheme" which would have separate requirements from any "normal" scheme. If it can't be parsed by the generic-URL syntax, then it can't be used in any context in which URLs are found, which would place it well outside the bounds of the URN charter's definition of URNs. > The point is that the current draft is unacceptable in its making a > statement about URNs without realizing that URNs are a superset of URLs > and should not be bound by the URL syntax (in fact one could argue the > reverse). Both points are in error. URNs are not a superset of URLs -- both are subsets of URI. There does not exist a URN that cannot be *parsed* as a URL. In fact, the URL syntax is much less restrictive than the proposed URN syntax. Claims that such a URI syntax is "too restrictive" are not useful without an example of a legal URN which would be disallowed by the URL syntax. Personally, I have yet to even imagine one. > One reason is that URNs are more general than URLs. How so? > Another is that > URN syntax pushes the deterministic structure off to the namespace > resolver. No it doesn't. In order to parse a URN, you need to know where it begins and where it ends. That is the definition of an opaque URI. > Another is that URLs are inherently tied to the underlying > filesystem structure. That is totally misinformed -- there is nothing in an http URL which is inherently tied to any filesystem, and the same goes for news, mid, cid, telnet, wais, etc. The URL document contains the wording about URI in general because there currently does not exist a standard reference for URI, which is the thing that HTTP and HTML use in references. Without that wording, the HTML and HTTP specifications will have to restrict themselves to using URLs, thus making an artificial distinction created for political reasons part of the official standard. Since I assume you want to actually use URNs in HTML and HTTP and other areas where URLs are currently found (I certainly do), it would be pretty stupid for us to remove any mention of the URI syntax from the URL standard. Waiting for URNs to achieve the same standard status as URLs is not reasonable. I included only the most basic of requirements in defining the URI syntax. If the URN WG cannot live with the requirements as stated, then I cannot possibly imagine that URNs can be used in the ways intended by your own requirements documents. But that can't be the case, since your own syntax document is *more* restrictive than the URL spec. I can only assume that you need to read it again and point the actual problems and not presuppositions. ....Roy Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id WAA26807 for urn-ietf-out; Fri, 27 Dec 1996 22:58:02 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id WAA26802 for ; Fri, 27 Dec 1996 22:58:00 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA24750 (mail destined for urn-ietf@services.bunyip.com); Fri, 27 Dec 96 22:57:24 -0500 Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <16866(6)>; Fri, 27 Dec 1996 19:57:19 PST Received: by palimpsest.parc.xerox.com id <248>; Fri, 27 Dec 1996 19:57:08 PDT To: jayhawk@windrose.omaha.ne.us Cc: urn-ietf@bunyip.com In-Reply-To: <9612271934.AA23259@mocha.bunyip.com> (jayhawk@windrose.omaha.ne.us) Subject: Re: [URN] Re: Comments on url-syntax-draft... From: Larry Masinter Message-Id: <96Dec27.195708pdt."248"@palimpsest.parc.xerox.com> Date: Fri, 27 Dec 1996 18:57:08 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com URLs aren't required to be a slash-separated hierarchy of symbolic elements, it's just that relative URLs don't work with the ones that aren't. # If a namespace wants to define such a structure, that's OK. URLs (on # the other hand) do imply this structure across all non-opaque URL # schemes. Right. "urn:" can be thought of as an opaque URL scheme. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA17854 for urn-ietf-out; Fri, 27 Dec 1996 14:34:44 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA17847 for ; Fri, 27 Dec 1996 14:34:41 -0500 From: jayhawk@windrose.omaha.ne.us Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23259 (mail destined for urn-ietf@services.bunyip.com); Fri, 27 Dec 96 14:34:39 -0500 Message-Id: <9612271934.AA23259@mocha.bunyip.com> Date: Fri, 27 Dec 96 13:33 CST To: urn-ietf@bunyip.com Subject: [URN] Re: Comments on url-syntax-draft... References: <01IDI6JYSI8O003M9A@SCI.WFBR.EDU> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Length: 1684 Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: jayhawk@windrose.omaha.ne.us Errors-To: owner-urn-ietf@bunyip.com Foteos Macrides wrote: > > Ryan Moats wrote: > >[..] > >One reason is that URNs are more general than URLs. Another is that > >URN syntax pushes the deterministic structure off to the namespace > >resolver. Another is that URLs are inherently tied to the underlying > >filesystem structure. There are more, but this should be a start. > >[...] > > I don't understand your claim that URLs are inherently tied > to the underlying filesystem strucure. The path field in a generic > URL is a "slash-separated hierarchy of symbolic elements" (*not* Unix > filesystem paths 8-). Each "symbolic element" and/or the overall > path field can have mappings to the the local filesystem structure, > (e.g., by server mappings and/or local system enviroment variables or > symbolic links) but the URL syntax, itself, is platform/filesystem > independent. I'll grant your point for the sake of argument (I don't necessarily agree with it, as I never said UNIX%C2%AE), but the point of prime importance (from my previous discussion) is EXACTLY that 'The path field in a generic URL is a "slash-separated hierarchy of symbolic elements."' It is this hierarchy (or, otherwise put, implied structure) that is one of the major (IMO) syntactical differences between URNs and URLs. URNs should not (and currently do not) impose such structure across all namespaces. If a namespace wants to define such a structure, that's OK. URLs (on the other hand) do imply this structure across all non-opaque URL schemes. Removing that argument from the above discussion by no means changes my assertion that URNs and URLs should have different syntactical structure. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA13612 for urn-ietf-out; Fri, 27 Dec 1996 11:40:45 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA13607; Fri, 27 Dec 1996 11:40:43 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22473 (mail destined for uri@services.bunyip.com); Fri, 27 Dec 96 11:40:37 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 27 10:39 CST 1996 Message-Id: <32C3FBD2.7FA0@ds.internic.net> Date: Fri, 27 Dec 1996 10:39:46 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Larry Masinter Cc: uri@bunyip.com, urn-ietf@bunyip.com Subject: [URN] Re: Comments on url-syntax-draft... References: <96Dec26.231820pdt."248"@palimpsest.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Larry Masinter wrote: > > Ryan, > > I don't think we intend for 'a:b:c:d' to be parsed as belonging to > scheme 'a:b:c', so I think we should fix the regular expression in > appendix B to treat 'urn:isbn:1-32456-78902-X' as belonging to > scheme 'urn' and not scheme 'urn:isbn'. > > I don't know how to proceed on the issue of changing the URL draft to > describe URNs and URN parsing. I think if we're going to proceed from > Proposed Standard to Draft Standard that we are not supposed to add > functionality, and that the only changes we can make are those that > are consistent with current practice. In my mind you have two options: (1) Delete the text in Section 1.1 relating to URNs and URIs or (2) Change the Appendixes and elsewhere to fix the problem above. I forsee problems in the URL draft with any potential "meta-scheme", an example of which is providing checksums for a URx if it maintains its current section 1.1 language. The point is that the current draft is unacceptable in its making a statement about URNs without realizing that URNs are a superset of URLs and should not be bound by the URL syntax (in fact one could argue the reverse). > I don't know why URNs don't require any determinist structure to URNs > while it seemed important that URLs require such a structure for URLs. One reason is that URNs are more general than URLs. Another is that URN syntax pushes the deterministic structure off to the namespace resolver. Another is that URLs are inherently tied to the underlying filesystem structure. There are more, but this should be a start. > (Actually, URLs don't make such a requirement, they just don't > guarantee that relative URLs work if you don't use it.) ??? I don't see this. I see that absolute URLs have a definite structured syntax throughout the draft. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id CAA08662 for urn-ietf-out; Fri, 27 Dec 1996 02:19:14 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id CAA08645; Fri, 27 Dec 1996 02:18:36 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21422 (mail destined for urn-ietf@services.bunyip.com); Fri, 27 Dec 96 02:18:34 -0500 Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <16709(4)>; Thu, 26 Dec 1996 23:18:30 PST Received: by palimpsest.parc.xerox.com id <248>; Thu, 26 Dec 1996 23:18:20 PDT To: jayhawk@ds.internic.net Cc: uri@bunyip.com, urn-ietf@bunyip.com In-Reply-To: <32C290D3.790B@ds.internic.net> (message from Ryan Moats on Thu, 26 Dec 1996 06:50:59 PST) Subject: [URN] Re: Comments on url-syntax-draft... From: Larry Masinter Message-Id: <96Dec26.231820pdt."248"@palimpsest.parc.xerox.com> Date: Thu, 26 Dec 1996 22:18:20 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com Ryan, I don't think we intend for 'a:b:c:d' to be parsed as belonging to scheme 'a:b:c', so I think we should fix the regular expression in appendix B to treat 'urn:isbn:1-32456-78902-X' as belonging to scheme 'urn' and not scheme 'urn:isbn'. I don't know how to proceed on the issue of changing the URL draft to describe URNs and URN parsing. I think if we're going to proceed from Proposed Standard to Draft Standard that we are not supposed to add functionality, and that the only changes we can make are those that are consistent with current practice. I don't know why URNs don't require any determinist structure to URNs while it seemed important that URLs require such a structure for URLs. (Actually, URLs don't make such a requirement, they just don't guarantee that relative URLs work if you don't use it.) Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA21562 for urn-ietf-out; Thu, 26 Dec 1996 13:21:21 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA21555 for ; Thu, 26 Dec 1996 13:21:18 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18793 (mail destined for urn-ietf@services.bunyip.com); Thu, 26 Dec 96 13:21:12 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <18710-0@josef.ifi.unizh.ch>; Thu, 26 Dec 1996 19:21:05 +0100 Date: Thu, 26 Dec 1996 19:21:03 +0100 (MET) From: "Martin J. Duerst" To: Ryan Moats Cc: Dirk.vanGulik@jrc.it, urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: <32BED0A0.5215@ds.internic.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Mon, 23 Dec 1996, Ryan Moats wrote: > Dirk.vanGulik@jrc.it wrote: > > Ok, here is a real example; P-R document references; > > > > Country They type (the keys/display on the screen) > > France #PEL/77124 > > UK *PEL/77124 (Where the * is the oblique L > > pound sign) > > Greece $PEL/77l24 (Note the 'l' instead of '1') > > Holland FlPEL/77l24 (Where fl is the florin symbol) > > > > Luckily however the _wire_ format is perfectly sensible and > > the same; But the fun bit is that they all happily print and > > fax each other those references; and all know how to cope > > with them just fine :-) > > > > The point I am trying to make is that for some namespaces to > > be grandfathered in have a stronger relation to their wire > > octed stream than to the glyph/symbolic representation; so for > > those you really want to ignore all you learned about really > > neat UTF8 symbol encoding :-) Yes, this is true. I proposed some text to take this into account. But for the examples above, I guess there are other possibilities. First, note that the "1" vs. "l" issue is really just a glyph issue, it's a difference you see frequently between Europe and the US, for example. Only the #/*/$/Fl is an octet issue. For this, just taking the octet representation (# and * suggest it's %23, but I might be wrong), resulting in urn:vangulikexample:%24PEL/77124, is one solution. Because this happens to be a valid UTF-8 sequence, URN interfaces may display that as #PEL/77124 or as %24PEL/77124. Another is the one I have mentionned earlier, and which Ryan gives the details below, namely accepting all different "spellings" and defining namespacesspecific equivalence between them. This works as long as there is no character that can lead to different octets in different countries. It looks like this is not the case for the example above, as otherwise faxes would lead to heavy confusion. Another solution might be to drop the initial letter altogether, leading to PEL/77124. This works in particular if the initial letter is the same all the time and serves as a kind of namespace identificator that would be replaced by the NIS anyway. Another solution might be to decide on a new or improved scheme for numbering for the first letter, e.g. replacing all the above with "@" or "X" or whatever. The best solution really depends on all kinds of details, and is up to those that are responsible for the namespace. All solutions are possible within the current syntax draft. The first solution is the most technical, easiest to interface with the current system. The others are more human- and future-oriented. While it is true that humans can easily deal with the current #/*/$/Fl mess, it should be clearly noted that this is an artefact produced by limitations of early computers, and there is no strong reason to perpetuate it. > I think somebody is confused (probably me), but I don't see what the > problem with this example is. All of those P-R document references > do not have to map to the same URN. In fact, based on how they are > described above, the shouldn't. Rather, the namespace that holds > the above resource (call it foobar), will have the following > 4 URNs (I'll probably get this wrong, bear with me): > > urn:foobar:%23PEL/77124 > urn:foobar:%C2%A3PEL/77124 > urn:foobar:%24PEL/77l24 > urn:foobar:%E0%86%92PEL/77l24 > > My main point having gotten here is this: > > It's up to the namespace resolver for foobar to understand that these > may all refer to the same resource, not the syntax. Therefore > "wire-coding should be more important that glyph/symbolic > representation" becomes a resolver issue, not a syntax issue. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA16652 for urn-ietf-out; Thu, 26 Dec 1996 09:51:59 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA16647; Thu, 26 Dec 1996 09:51:56 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18416 (mail destined for uri@services.bunyip.com); Thu, 26 Dec 96 09:51:52 -0500 Received: by privateer.windrose.omaha.ne.us; Thu Dec 26 08:51 CST 1996 Message-Id: <32C290D3.790B@ds.internic.net> Date: Thu, 26 Dec 1996 08:50:59 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Larry Masinter Cc: uri@bunyip.com, urn-ietf@bunyip.com Subject: [URN] Comments on url-syntax-draft... References: <96Dec26.011608pst."2694"@golden.parc.xerox.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Larry- I've looked through your new draft especially with a view to meshing with the URN syntax and I still have two major issues. Fortunately, I believe that a single solution will handle both. I also have an editorial issue. Once these are taken care of, I believe that both drafts have been aligned on this issue. 1. Given the current URN spec, the "greedy" algorith in Appendix B will pick up the urn scheme as "urn:". For example the URN urn:isbn:1-32456-78902-X will be parsed as being scheme "urn:isbn". 2. There is no general specification of structure for a URN NSS, it is determined on a namespace by namespace basis. I can see two solutions to item 1: (a) modify the scheme syntax in Section 4.1 to include ":" or (b) add a section for URN handling that states that a scheme including the "urn:" token should be treated as an opaque URL because it is really a URN. I propose that option (b) be followed because the easiest solution to item 2 is for the URL parser to declare a URN as an "opaque-URL" and do no processing on it. This would ensure that the NSS structure doesn't confuse the URL parser. I believe that an appendix for this would work the best, and I add it below... My editorial issue is that the section paragraph in section 1.1 is potentially confusing. There are requirements in the URL syntax that do not apply to the URN syntax. I would prefer to see the following paragraph in its place: "This specification restricts its discussion to URLs. URN syntax is specified in [URN Syntax Ref]. URN and URL syntax have been specified so that a URN may be used in any data field that might otherwise hold a URL. Details of how to handle a URN are provided in Appendix X." Ryan Moats =======================Appendix on URN handling in a URL parser Appendix X. URN Handling in URL parsers URN syntax is specified in [URN Syntax Ref]. URNs include a leading tag "urn:". Thus, the "greedy" algorithm in Appendix B will return a scheme that includes this tag. In addition, URNs do not require any determinist strcuture to the URN. Rather, this is assigned on a namespace-by-namespace basis. To enable a URL parser to handle a URN properly, A URL parser that detects a scheme that includes the "urn:" tag MUST treat the URL as an opaque URL to be handed to a URN resolver for further processing. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA16641 for urn-ietf-out; Thu, 26 Dec 1996 09:51:48 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA16634 for ; Thu, 26 Dec 1996 09:51:44 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18412 (mail destined for urn-ietf@services.bunyip.com); Thu, 26 Dec 96 09:51:38 -0500 Received: by privateer.windrose.omaha.ne.us; Thu Dec 26 08:50 CST 1996 Message-Id: <32C290CE.2193@ds.internic.net> Date: Thu, 26 Dec 1996 08:50:54 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: urn-ietf@bunyip.com Subject: [URN] Second pre-release of 3rd syntax draft. Content-Type: multipart/mixed; boundary="------------76D545817A4" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com This is a multi-part message in MIME format. --------------76D545817A4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Howdy, everybody- As promised, here is the second pre-release of the 3rd syntax draft (-02). Changes from the previous pre-release: 1. Added a paragraph on the "%" character to align with the URL syntax and clear up misconceptions about its presence in the URL character set. 2. Moved the "\" character to the excluded character set. This also aligns the URN syntax with the URL syntax The current schedule is to send this to the I-D editors 1/6/97. Have a happy new year! Ryan --------------76D545817A4 Content-Type: text/plain; charset=us-ascii; name="urn.syntax.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="urn.syntax.txt" Internet-Draft Ryan Moats draft-ietf-urn-syntax-02.txt AT&T Expires in six months December 1996 URN Syntax Filename: draft-ietf-urn-syntax-02.txt Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers. This document sets forward the canonical syntax for URNs. Support for both existing legacy and new namespaces is discussed. Requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. 1. Introduction Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space. The URN syntax therefore provides a means to encode character data in a form that can be sent in existing protocols, transcribed on most keyboards, etc. Expires 5/19/97 [Page 1] INTERNET DRAFT URN Syntax December 1996 2. Syntax All URNs have the following syntax: ::= "urn:" ":" is the Namespace Identifier, and is the Namespace Specific String. The leading case-insensitive "urn:" sequence is required. The Namespace ID is used to determine the _syntactic_ interpretation of the Namespace Specific String (as discussed in [1]). RFC 1737 [2] presents additional requirements on URN encoding, which all have implications as far as limiting syntax. On the other hand, the requirement to support existing legacy naming systems has the effect of broadening syntax. Thus, we discuss the acceptable syntax for both the Namespace Identifier and the Namespace Specific String separately. 2.1 Namespace Identifier Syntax The following is the syntax for the Namespace Identifier. To (a) be consistent with all potential resolution schemes and (b) not put any undue constraints on any potential resolution scheme, the syntax for the Namespace Identifier is: ::= [ * ] ::= | | | "-" ::= | | ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" This is slightly more restrictive that what is stated in [3] (which Expires 5/19/97 [Page 2] INTERNET DRAFT URN Syntax December 1996 allows the characters "." and "+"). Further, the Namespace Identifier is case insensitive, so that "ISBN" and "isbn" refer to the same namespace. To avoid confusion with the "urn:" identifier, the NID "urn" is reserved and MUST NOT be used. 2.2 Namespace Specific String Syntax As required by 1737, there is a single canonical representation of the NSS portion of an URN. The format of this single canonical form follows: ::= 1* ::= | "%" ::= | | | ::= | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" ::= "(" | ")" | "+" | "," | "-" | "." | "/" | ":" | "=" | "?" | "@" | "%" Depending on the rules governing a namespace, valid identifiers in a namespace might contain characters that are not members of the URN character set above (). Such strings MUST be translated into canonical NSS format before using them as protocol elements or otherwise passing them on to other applications. Translation is done by encoding each character outside the URN character set as a sequence of one to six octets using UTF-8 encoding, and the encoding of each of those octets as "%" followed by two characters from the character set above. The two characters give the hexadecimal representation of that octet. The "%" character is reserved in the URN syntax for introducing the escape sequence for an octet. Literal use of the "%" character in a namespace must be encoded using "%25" in URNs for that namespace. The prescence of an "%" character in a URN MUST be followed by two characters from the character set. Namespaces MAY designate one or more characters from the URN character set as having special meaning for that namespace. If the namespace also uses that character in a literal sense as well, the character used in a literal sense MUST be encoded with "%" followed by the hexadecimal representation of that octet. Therefore, the process of registering a namespace identifier shall include Expires 5/19/97 [Page 3] INTERNET DRAFT URN Syntax December 1996 publication of a definition of which characters have a special meaning to that namespace. 2.3 Excluded characters The following list is included only for the sake of completeness. Any octets/characters on this list are explicitly NOT part of the URN character set, and if used in a URN, MUST be %encoded: ::= octets 0-32 (0-20 hex) | "\" | "!" | """ | "#" | "$" | "&" | "'" | "*" | ";" | "<" | ">" | "[" | "]" | "^" | "_" | "`" | "{" | "|" | "}" | "~" | octets 127-255 (7F-FF hex) A URN ends when an octet/character from the excluded character set () is encountered. The character from the excluded character set is NOT part of the URN. 3. Support of existing legacy naming systems and new naming systems Any namespace (existing or newly-devised) that is proposed as a URN- namespace and fulfills the criteria of URN-namespaces MUST be expressed in this syntax. If names in these namespaces contain characters other than those defined for the URN character set, they MUST be translated into canonical form as discussed in section 2.2. 4. URN presentation and transport URN-aware applications MAY support "natural" display of URNs which contain characters encoded using "%" notation. However, they MUST provide for display of URNs in canonical form (i.e. in a format suitable for transcription). URNs MUST be transported in canonical format. 5. Lexical Equivalence in URNs For various purposes, such as caching, it is necessary to determine equivalence without actually resolving the URN. This done by testing for "lexical equivalence". Two URNs are lexically equivalent if they are octet-by-octet equal after the following preprocessing 1. normalize the case of the leading "urn:" token 2. normalize the case of the NID 3. normalizing the case of any "%" escaping Some namespaces may define additional lexical equivalences, such as case-insensitivity of the NSS (or parts thereof). Additional lexical Expires 5/19/97 [Page 4] INTERNET DRAFT URN Syntax December 1996 equivalences MUST be documented as part of namespace registration, MUST always have the effect of eliminating some of the false negatives obtained by the procedure above, and MUST NEVER say that two URNs are not equivalent if the procedure above says they are equivalent. 6. Functional Equivalence in URNs Functional equivalence is determined by URN resolvers and is therefore outside the scope of this document. Namespace registration MUST include documentation on how to determine functional equivalence for that namespace. 7. Examples of equivalence The following URN comparisons highlight the difference between these types of equivalence: urn:isbn:1-23485-8-29, urn:isbn:1-23485-8-29 are lexically equiv. urn:isbn:1-23485-8-29, URN:ISBN:1-23485-8-29 are lexically equiv. urn:isbn:1-23485-8-29, urn:isbn:123485829 are not lexically equiv. but may be functionally equivalent. 8. Security considerations This document specifies the syntax for URNs. While some namespaces resolvers may assign special meaning to certain of the characters of the Namespace Specific String, any security consideration resulting from such assignment are outside the scope of this document. It is strongly recommended that the process of registering a namespace identifier include any such considerations. 9. Acknowledgments Thanks to various members of the URN working group and <> for comments on earlier drafts of this document. This document is partially supported by the National Science Foundation, Cooperative Agreement NCR-9218179. 10. References Request For Comments (RFC) and Internet Draft documents are available from and numerous mirror sites. [1] K. R. Sollins. "Requorements and a Framework for URN Resolution Systems" Internet Draft (work in progress). November 1996. Expires 5/19/97 [Page 5] INTERNET DRAFT URN Syntax December 1996 [2] K. Sollins, L. Masinter. "Functional Requirements for Uniform Resource Names," RFC 1737. December 1994. [3] T. Berners-Lee, R. Fielding, L. Masinter. "Uniform Resource Locators (URL)," Internet Draft (work in progress). December 1996. 11. Editor's address Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA Phone: +1 402 894-9456 EMail: jayhawk@ds.internic.net This Internet Draft expires May 19, 1997. Expires 5/19/97 [Page 6] --------------76D545817A4-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA04975 for urn-ietf-out; Mon, 23 Dec 1996 13:41:39 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA04964 for ; Mon, 23 Dec 1996 13:41:36 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07581 (mail destined for urn-ietf@services.bunyip.com); Mon, 23 Dec 96 13:41:20 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id NAA01369; Mon, 23 Dec 1996 13:41:18 -0500 Message-Id: <199612231841.NAA01369@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Mon, 23 Dec 1996 13:41:16 -0500 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: minutes@ietf.org Subject: [URN] Re: DRAFT URN Meeting Minutes Cc: jcurran@bbn.com, urn-ietf@bunyip.com, hta@uninett.no, moore@cs.utk.edu Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Minutes of the URN Working Group 37th IETF, San Jose, December 12, 1996 Group Co-Chairs: Leslie Daigle, leslie@bunyip.com John Curran, jcurran@bbn.com Minute-Meister: Sally Hambridge, Intel Leslie opened the meeting by reviewing the Charter and Milestones. Hot Spots in the milestones are: we lack a draft detailing N2L/N2R/etc resolution results. We will probably use Ron Daniel's HTTP conventions draft as a start on this milestone. We also need to submit a document describing one new namespace and a document which describes grandfathering in older naming schemes, as well as the Frameworks and Requirements draft. Karen Sollins presented the open issues with the current Frameworks and Requirements document: The document discusses the assumptions of longevity, delegation, and independence. The requirements fall in 3 major areas: Evolution, Usability, and Security. The framework looks like this: URN: | | Global NID registry | | | | | Private URN resolution service UDS server | | Private URN resolution service Karen includes a definition section which defines Local Resolution service - what transforms URNs into access to resources; Hints - information that helps to access the information; UDS - URN Resolution Service Discovery Service - how to find the right URN resolution service; HFN - Human friendly names. The Security area will discuss access control on hints; server authenticity; Server distribution (a countermeasure on denial of service attacks) and Privacy - the users from resolution services and for publishers for their clients and publications lists. Issues: - Encouragement of separation of URNs from semantics - Efficiency as a goal or a requirement is in several places (documents) which need to be aggregated. - Whether there is a useful distinction to be made between long- term and short-term hints - Acceptance by potential providers of UDS services. Karen asked what's missing from the list of issues: Internationalization (i18n) should be covered one way or another. Name space ID - needs to be in a document but probably not this document. Ryan Moats presented the issues with the URN syntax ID: URN: should this be optional. Please see the later discussion on this for the consensus. NID syntax: Why not use numbers and "-". No reason - Ryan will change the draft. There was a suggestion for following the RFC for URLs on this, but it was pointed out that this document is currently undergoing a revision. NID namespace will have case insensitivity and add %escaping. The NSS may be case sensitive. URN Character set adds/deletes: Add "%" to the allowed character set and add a list of characters NOT part of the set to the draft. %escaping: Will be allowed for escaping of reserved characters in addition to characters outside the URN character set; and allow for %HH escaping to use either upper or lower case. Where does a URN end? At the first non-URN character set character. Equivalency: Are things the same when they point to the same resource? (Equivalency of resources was deemed to be a rathole). Leslie offered that a URN could point to a specific day's weather and another could refer to today's weather, and these were pointing to the same thing but were not equivalent. ROUGH CONSENSUS was reached that ONLY lexical equivalency will be covered in the draft. Each namespace may have its own rules. For the Human readability - MUST/SHOULD the following text is being substituted: Any namespace (existing or newly-devised) that is proposed as a URN-namespace must be expressed in this syntax. If names in these namespaces contain characters other than those defined for the URN character set they must be translated into canonical form as discussed in section 2.2 Ron Daniel discussed the NAPTR draft. - There will be verbiage to state that records with unknown flags must be ignored. - The Pseudo-code will get a strong disclaimer. - "R" Flag for treating Regex as "Raw" - Don't do "E" flag for encrypting Raw fields. - Flag field reserves 0-9 for experimentation. ROUGH CONSENSUS was to allow people to create new flags however they want, but that if you see a flag you don't recognize you ignore it. Ron is going to revise the wording of the draft so that people may place any interpretation they want on the various fields as long as they define a flag for it. There was a question of the references to other drafts, and John Curran said he would find out if the text RFC xxx could be written and if the RFC editor would insert the correct numbers. This draft will be going as an Experimental RFC. There was discussion about how the experimental status will effect DNS and the regex substitutions. We need to be explicit. We need to say how this doesn't overload DNS and how DNS security will help and where it won't. Also, there will probably be more than one discover service in the future and we don't want this one to be "The Standard". We need operational experience. The requiring resolution problem is not part of this draft. We will have one more revision on the mailing list, then this goes to Experimental. HTTP Conventions: Ron took this one too. We need a simple resolver for testing, the goal is not Standards track. The goal is to use the conventions on encoding on requests and responses on http: GET /uri-res// HTTP 1.0 Open Discussion: URN: There was a question of rough consensus on the problem of whether to require urn:. The room seems to indicate that urn: should be required on any part of the urn that was shipped around the Internet. Whether or not implementors would use urn: was left up to them for their own local products, but in transmission the urn: would be required. The problem with urn: seems to be at the user interface and user services level. Don't confuse human friendly names with internal representation. Documents: We need a URN dereferencing document to discuss the resolution service and the resolution system. These need the syntax (which is close) and the system requirements needs the framework (which is also close.) Assign URN - needs everything! We need namespace requirements. Renato Iannella was volunteered to create a first draft of this document. We need to have one new namespace and we need to bring in 1 existing namespace. We need to pay some attention to potential lawsuit issue. It is important for someone who has authority for the namespace to say how it works in URN. The proposal is for these to be experimental. Dun and Bradstreet is interested in working on this as soon as the syntax is ready. Clifford Lynch said that the NISO bibliographic IDs could move en masse. We can create a resolution system which can be used outside the URN space, but we need to make it work there first. Charter directions: * We need to get a grip on bringing in an existing namespace * We need a new namespace scheme * We need the Name space requirements document (to see whether DNS-based namespace will or won't work, and if not, what we can do about a generically-accessible namespace) * We need to look at the process of creating new namespaces -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA04420 for urn-ietf-out; Mon, 23 Dec 1996 13:35:44 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA04413 for ; Mon, 23 Dec 1996 13:35:41 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07521 (mail destined for urn-ietf@services.bunyip.com); Mon, 23 Dec 96 13:35:38 -0500 Received: by privateer.windrose.omaha.ne.us; Mon Dec 23 12:34 CST 1996 Message-Id: <32BED0A0.5215@ds.internic.net> Date: Mon, 23 Dec 1996 12:34:08 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Dirk.vanGulik@jrc.it Cc: "Martin J. Duerst" , urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Dirk.vanGulik@jrc.it wrote: > Ok, here is a real example; P-R document references; > > Country They type (the keys/display on the screen) > France #PEL/77124 > UK *PEL/77124 (Where the * is the oblique L > pound sign) > Greece $PEL/77l24 (Note the 'l' instead of '1') > Holland FlPEL/77l24 (Where fl is the florin symbol) > > Luckily however the _wire_ format is perfectly sensible and > the same; But the fun bit is that they all happily print and > fax each other those references; and all know how to cope > with them just fine :-) > > The point I am trying to make is that for some namespaces to > be grandfathered in have a stronger relation to their wire > octed stream than to the glyph/symbolic representation; so for > those you really want to ignore all you learned about really > neat UTF8 symbol encoding :-) > I think somebody is confused (probably me), but I don't see what the problem with this example is. All of those P-R document references do not have to map to the same URN. In fact, based on how they are described above, the shouldn't. Rather, the namespace that holds the above resource (call it foobar), will have the following 4 URNs (I'll probably get this wrong, bear with me): urn:foobar:%23PEL/77124 urn:foobar:%C2%A3PEL/77124 urn:foobar:%24PEL/77l24 urn:foobar:%E0%86%92PEL/77l24 My main point having gotten here is this: It's up to the namespace resolver for foobar to understand that these may all refer to the same resource, not the syntax. Therefore "wire-coding should be more important that glyph/symbolic representation" becomes a resolver issue, not a syntax issue. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA27555 for urn-ietf-out; Mon, 23 Dec 1996 04:40:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA27550 for ; Mon, 23 Dec 1996 04:40:50 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04776 (mail destined for urn-ietf@services.bunyip.com); Mon, 23 Dec 96 04:40:36 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA25034; Mon, 23 Dec 96 10:45:34 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA17045; Mon, 23 Dec 1996 10:39:39 +0100 Date: Mon, 23 Dec 1996 10:39:39 +0100 (MET) From: Dirk.vanGulik@jrc.it X-Sender: dirkx@elect6.jrc.it To: "Martin J. Duerst" Cc: Dirk.vanGulik@jrc.it, Ryan Moats , urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: Message-Id: Reply-Path: Dirk.vanGulik@jrc.it Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Dirk.vanGulik@jrc.it Errors-To: owner-urn-ietf@bunyip.com On Sat, 21 Dec 1996, Martin J. Duerst wrote: > On Sat, 21 Dec 1996 Dirk.vanGulik@jrc.it wrote: > > > Ryan wrote: > > > Dirk.vanGulik@jrc.it wrote: > > > > > > > > 3. suggested escape hatch for (grandfathered in) namespaces > > > > where the glyph representation is confirmed ambigious. (For > > > > example the $, #, pound and yen sign). > > > > > > This is already taken care of by the character set. The only > > > way to put a character from this set in a URN is to use "%" encoding. > > > Otherwise, the character terminates the URN. > > > > > It dawns on me that you may be talking about what hex value to use > > > for the "%" encoding. My current position is that it is the > > > UNICODE/10646 value via UTF-8. > > > > No Actually not, What I meant is that I've seen people in the document > > and library world using quite a few naming schemes where in different > > places they use say the '$' and '$' with two lines through it and the '#' > > and the L-shaped pound sign interchangably, depending on what keyboard > > and machine they are working. So in these spaces the glyph-to-wire > > encoding (using the % utf-8 encoding) is no longer trivial, as it is no > > longer the shape of the symbol which matters. > > I start to understand. Real examples always make it easier. Ok, here is a real example; P-R document references; Country They type (the keys/display on the screen) France #PEL/77124 UK *PEL/77124 (Where the * is the oblique L pound sign) Greece $PEL/77l24 (Note the 'l' instead of '1') Holland FlPEL/77l24 (Where fl is the florin symbol) Luckily however the _wire_ format is perfectly sensible and the same; But the fun bit is that they all happily print and fax each other those references; and all know how to cope with them just fine :-) The point I am trying to make is that for some namespaces to be grandfathered in have a stronger relation to their wire octed stream than to the glyph/symbolic representation; so for those you really want to ignore all you learned about really neat UTF8 symbol encoding :-) Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA23468 for urn-ietf-out; Sat, 21 Dec 1996 16:41:12 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA23462 for ; Sat, 21 Dec 1996 16:41:09 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28546 (mail destined for urn-ietf@services.bunyip.com); Sat, 21 Dec 96 16:41:07 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <12447-0@josef.ifi.unizh.ch>; Sat, 21 Dec 1996 22:41:22 +0100 Date: Sat, 21 Dec 1996 22:41:21 +0100 (MET) From: "Martin J. Duerst" To: Dirk.vanGulik@jrc.it Cc: Ryan Moats , urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Sat, 21 Dec 1996 Dirk.vanGulik@jrc.it wrote: > Ryan wrote: > > Dirk.vanGulik@jrc.it wrote: > > > > > > 3. suggested escape hatch for (grandfathered in) namespaces > > > where the glyph representation is confirmed ambigious. (For > > > example the $, #, pound and yen sign). > > > > This is already taken care of by the character set. The only > > way to put a character from this set in a URN is to use "%" encoding. > > Otherwise, the character terminates the URN. > > > It dawns on me that you may be talking about what hex value to use > > for the "%" encoding. My current position is that it is the > > UNICODE/10646 value via UTF-8. > > No Actually not, What I meant is that I've seen people in the document > and library world using quite a few naming schemes where in different > places they use say the '$' and '$' with two lines through it and the '#' > and the L-shaped pound sign interchangably, depending on what keyboard > and machine they are working. So in these spaces the glyph-to-wire > encoding (using the % utf-8 encoding) is no longer trivial, as it is no > longer the shape of the symbol which matters. I start to understand. Real examples always make it easier. For the two cases above, the $ with | or || is not a problem, as for them there is only one codepoint in UNicode. For the '#' and the pound sign, they both have a codepoint in UNicode/10646. What I think you should do for your namespace would be that you define that '#' and pound sign are lexically equivalent. The users can type whichever they want, and some component in the architecture that will be built will equate them, as for other namespaces, it would equate lower-case and upper-case. So if all the problematic cases you had in mind have the same structure, it turns out we already have taken care of that in the syntax draft :-). > Well this still does not quite solve it; but I think the underlying issue > is about what is the 'real' thing, a sequene of sybols or a sequence of > octeds. There are several "real" things. The best defined is the URN as such, a string of characters from a limited set. It is used to represent a string of characters from a wider set, along certain rules, or in some exceptions something else, which will have to be defined separately. There are also, at some point, octets. They are an intermediate stage when mapping from *represented* characters to *representing* characters. And they can be a "point of attachment" when a namespace exists in digital form only, and has to be brougt into an URN. The question of what is the "real" thing is a question of philosophy, not a question of protocol specification. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA23212 for urn-ietf-out; Sat, 21 Dec 1996 16:26:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA23203 for ; Sat, 21 Dec 1996 16:26:46 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28476 (mail destined for urn-ietf@services.bunyip.com); Sat, 21 Dec 96 16:26:43 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <12300-0@josef.ifi.unizh.ch>; Sat, 21 Dec 1996 22:26:49 +0100 Date: Sat, 21 Dec 1996 22:26:48 +0100 (MET) From: "Martin J. Duerst" To: Dirk.vanGulik@jrc.it Cc: Larry Masinter , jayhawk@ds.internic.net, urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com > On Fri, 20 Dec 1996, Larry Masinter wrote: > > > I've come to understand that %XX encoding of UTF8 is particularly > > ugly, and that some variation of UTF7 (if not UTF7 itself) would be > > better for contexts where 7-bit-safe channels should be assumed. On Sat, 21 Dec 1996 Dirk.vanGulik@jrc.it wrote: > yes, you are quite right; but this was brought up before, and there > was some good reasoining as why to go UTF8 anyway. > > Martin, could you re-elaborate ? - The main reason we have a limited character set and %HH is transcribability, not 7-bit channels. - The basic syntactical equivalence between URLs and URNs is very important. URLs have %HH. - Other parallels between URLs and URNs are also valuable. URLs, hopefully, will move towards UTF-8. (The ftp URL scheme is already moving in that direction). There have been a lot of discussions about other alternatives, but UTF-8 is generally viewed as the best solution. - 7-bit channels are still existing, but getting fewer and fewer. They are ugly by themselves, and don't "deserve" beauty. If we design something that looks "nice" for the remaining 7-bit channels, it will look ugly for 8-bit channels and so forever. - Once we are reasonably sure that i18n text, and URLs/URNs in i18n text, are treated decently, we can move on to allow a text to include as such those URN *represended* characters it can represent, and only use %HH for characters that cannot be represented and non-character %HH. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA23040 for urn-ietf-out; Sat, 21 Dec 1996 16:04:09 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA23033 for ; Sat, 21 Dec 1996 16:04:05 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28424 (mail destined for urn-ietf@services.bunyip.com); Sat, 21 Dec 96 16:04:02 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA18737; Sat, 21 Dec 96 22:09:28 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA16198; Sat, 21 Dec 1996 22:03:39 +0100 Date: Sat, 21 Dec 1996 22:03:33 +0100 (MET) From: Dirk.vanGulik@jrc.it X-Sender: dirkx@elect6.jrc.it To: Ryan Moats Cc: Dirk.vanGulik@jrc.it, urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: <32BAE705.7E75@ds.internic.net> Message-Id: Reply-Path: Dirk.vanGulik@jrc.it Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Dirk.vanGulik@jrc.it Errors-To: owner-urn-ietf@bunyip.com Ryan wrote: > Dirk.vanGulik@jrc.it wrote: > > > > I think you may have missed my mail on URN/URL potential > incompatibilities. The current text of the draft on the "%" issue > is the following: > > "...Translation is done by encoding each character outside the URN > character set as a sequence of one to six octets using UTF-8 encoding, > and the encoding of each of those octets as "%" followed by two > characters from the character set above. The two characters give > the hexadecimal representation of that octet. > > The "%" character is reserved in the URN syntax for introducing the > escape sequence for an octet. Literal use of the "%" character in a > namespace must be encoded using %25 in URNs for that namespace. The > precence of an "%" character in a URN MUST be followed by two characters > from the character set. Sorry about that; I should have double checked wether I used the last draft, I apoliogize !. > > 3. suggested escape hatch for (grandfathered in) namespaces > > where the glyph representation is confirmed ambigious. (For > > example the $, #, pound and yen sign). > > This is already taken care of by the character set. The only > way to put a character from this set in a URN is to use "%" encoding. > Otherwise, the character terminates the URN. > It dawns on me that you may be talking about what hex value to use > for the "%" encoding. My current position is that it is the > UNICODE/10646 value via UTF-8. No Actually not, What I meant is that I've seen people in the document and library world using quite a few naming schemes where in different places they use say the '$' and '$' with two lines through it and the '#' and the L-shaped pound sign interchangably, depending on what keyboard and machine they are working. So in these spaces the glyph-to-wire encoding (using the % utf-8 encoding) is no longer trivial, as it is no longer the shape of the symbol which matters. > > 4. suggested escape hatch for namespaces where the identifiers > > have no meaningfull representation in the urn syntax (at > > least meaningfull in the sense that a UA could gain > > something by showing it to the user) such as spaces which > > have a purely binary object identifiers; base64 is the > > _should_ wannabe. > > I don't have a problem with this, so long as such information > is included in the namespace registration documentation. > Yes, I had hoped I made that clear in the remainder of the doc. > > If a proposed namespace identifier is already in use as a protocol > > specifier in the URI space, such as for example ftp, http or email, > > the proposal for this identifier should justify this choise; i.e > > > > urn:email:dirk.vangulik@jrc.it or > > urn:ftp:someplace:abc.efg > > urn:ftp://someplace/abcd.efg > > Now this makes some sense to me. I'm wondering if we want to > make the statement stronger... > > > Now this kind of 'clashes' with the needs to grandfather in various > > schemes as their glyfh encoding might *NOT* be an unambigious character > > index. For example if the indexes or local control identifiers are > > collected over various contries; which each use their own (say latin) > > charset, but the actual LCI is just the sequence of the character index > > number _ITSELF_ into the various charsets. So encoding the glyf using > > UTF8 it represents in one charset display mapping would most certainly > > wrong for another one; and if the people interoperate you have broken the > > LCI scheme. The reverse also happens; and on top of that normalizing in > > UTF8 makes it even more fun. > > The last portion of the last sentence has gone away and so the last > sentence now reads: > > "Therefore, the process of registering a namespace identifier > shall include publication of a definition of which characters have > a special meaning to that namespace". Well this still does not quite solve it; but I think the underlying issue is about what is the 'real' thing, a sequene of sybols or a sequence of octeds. > I don't see a case of glyph ambiguity in the URN character set > itself, however your following sentence: > > > ++ Likewise if glyph ambiguity does not allow for UTF8 encoding > > ++ the publication should outline the possible ambiguity and > > ++ representations possible for display. > > I like and am willing to add. > > > ++ The URN is a sequence of glyphs taken from the . It is > > ++ represented by an octet stream with the only the values of the > > ++ indexes of the glyphs in UTF-8. A glyph or symbol encoded, > > ++ entered, stored, displayed or conveyed which is not in this limited > > ++ range, for examply with an UTF-8 encoding, is purely based on the > > ++ mutual understanding of the publishing and utilizing party; but is > > ++ not to be used to represent the URN. > > > > The above needs to be tackled anyway, somewhere; unless I missed the > > place in the current draft which tells us which is really the authorative > > representation (between machines :-) of the beast. (Ignoring > > normalziaiton,etc). > > I thought (probably incorrectly) that this had been closed going into > San Jose. The URN's canonical form (for transmission between > machines) is the sequence of characters from . Well it that is your understanding as well; then I am very happy; I'll wait and see the next version of the draft to see how this was worded. > Now Martin and Keith can tell me I'm wrong, but I thought this was > closed. Well I hope it is indeed closed with this. > Other things: > > If a namespace wants to be opaque and use base-64, that's fine, but > I don't see where the syntax document must specify that. Well this was more to stay in line with the UTF8 suggestion; because _IF_ you say that the cannonical for discussion is closed and it is the wire octed stream which counts; than the UTF8 and Base64 suggestions for encodings become exactly that; and thus needs to be specified in the documents which describe them. Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA22969 for urn-ietf-out; Sat, 21 Dec 1996 15:52:29 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA22964 for ; Sat, 21 Dec 1996 15:52:25 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28385 (mail destined for urn-ietf@services.bunyip.com); Sat, 21 Dec 96 15:52:18 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA18716; Sat, 21 Dec 96 21:57:06 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA16180; Sat, 21 Dec 1996 21:51:06 +0100 Date: Sat, 21 Dec 1996 21:51:06 +0100 (MET) From: Dirk.vanGulik@jrc.it X-Sender: dirkx@elect6.jrc.it To: Larry Masinter Cc: mduerst@ifi.unizh.ch, jayhawk@ds.internic.net, Dirk.vanGulik@jrc.it, urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: <96Dec20.235708pst."2695"@golden.parc.xerox.com> Message-Id: Reply-Path: Dirk.vanGulik@jrc.it Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Dirk.vanGulik@jrc.it Errors-To: owner-urn-ietf@bunyip.com yes, you are quite right; but this was brought up before, and there was some good reasoining as why to go UTF8 anyway. Martin, could you re-elaborate ? Dw. http://ewse.ceo.org http://enrm.ceo.org DWvGulik@Dialis.xs4all.nl Dirk.vanGulik@jrc.it +39 332 78 0014 +39 332 78 9549 fax +39 332 78 9185 ISEI/ESBA; The Center For Earth Observation Joint Research Centre of the European Communities, Ispra, Italy On Fri, 20 Dec 1996, Larry Masinter wrote: > I've come to understand that %XX encoding of UTF8 is particularly > ugly, and that some variation of UTF7 (if not UTF7 itself) would be > better for contexts where 7-bit-safe channels should be assumed. > > Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA22012 for urn-ietf-out; Sat, 21 Dec 1996 13:32:07 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA22007 for ; Sat, 21 Dec 1996 13:32:04 -0500 Received: from mail.bbnplanet.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA28037 (mail destined for urn-ietf@services.bunyip.com); Sat, 21 Dec 96 13:32:01 -0500 Received: from jcurran-ppp.near.net by mail.bbnplanet.com id aa17567; 21 Dec 96 13:38 EST X-Sender: jcurran@mail.bbnplanet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Phone: (617) 873-4398 Usmail: 150 CambridgePark Drive, Cambridge, MA, 02140 Date: Sat, 21 Dec 1996 13:31:58 -0500 To: Leslie Daigle From: John Curran Subject: Re: [URN] Checksums in URNs Cc: "David W. Morris" , urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: John Curran Errors-To: owner-urn-ietf@bunyip.com At 15:37 12/20/96, Leslie Daigle wrote: >... >Unless someone (that could mean you, David Morris :-) can come up with >concrete answers to the questions I asked earlier (see below), I think >we can sum up _consensus_ by saying: there is obvious merit in having >mechanisms to test the integrity of URNs. We don't yet know what the >best mechanism to handle that is (we don't even yet have any real-life >experience with them), so we can't answer it now, and will leave it as >a future problem. A very reasonable position... my own more critical viewpoint is that given the complete lack of existing experimentation in deploying checksums in URx enviroments (read: absence of running code) and the multiple requirements one might have (single error detection, multiple error detection, correction, etc.), I would claim that we're far removed from the realm of standardization and have entered the realm of creeping featurism. By all means,folks should explore using checksums (and this is readily possible both on a namespace-specific basis and via meta approaches), but none of this requires inclusion of checksums in the underlying URN or UR* frameworks. To look to mandating such in the absence of running code is not how we try to do things in the IETF. /John Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id CAA11461 for urn-ietf-out; Sat, 21 Dec 1996 02:59:49 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id CAA11428 for ; Sat, 21 Dec 1996 02:59:41 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA26266 (mail destined for urn-ietf@services.bunyip.com); Sat, 21 Dec 96 02:59:35 -0500 Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <15954(6)>; Fri, 20 Dec 1996 23:59:28 PST Received: by golden.parc.xerox.com id <2695>; Fri, 20 Dec 1996 23:57:08 PST To: mduerst@ifi.unizh.ch Cc: jayhawk@ds.internic.net, Dirk.vanGulik@jrc.it, urn-ietf@bunyip.com In-Reply-To: (mduerst@ifi.unizh.ch) Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt From: Larry Masinter Message-Id: <96Dec20.235708pst."2695"@golden.parc.xerox.com> Date: Fri, 20 Dec 1996 23:57:08 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com I've come to understand that %XX encoding of UTF8 is particularly ugly, and that some variation of UTF7 (if not UTF7 itself) would be better for contexts where 7-bit-safe channels should be assumed. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA04280 for urn-ietf-out; Fri, 20 Dec 1996 16:07:39 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA04275 for ; Fri, 20 Dec 1996 16:07:37 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23386 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 16:07:31 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id NAA09274 for ; Fri, 20 Dec 1996 13:07:33 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id NAA00011 for urn-ietf@bunyip.com; Fri, 20 Dec 1996 13:06:12 -0800 (PST) Date: Fri, 20 Dec 1996 13:06:12 -0800 (PST) From: Terry Allen Message-Id: <199612202106.NAA00011@ishtar.fsc.fujitsu.com> To: urn-ietf@bunyip.com Subject: Re: [URN] Checksums in URNs Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com Seems to me that checksums are metadata about the URN. Certainly for name spaces that don't include checksums in their names. So checksums should go outside URNs, either in the manner Larry suggested or in some more generalized way (like the checksums you might want to use for other URIs and divers objects). Happy Solstice. Terry Allen Fujitsu Software Corp. tallen@fsc.fujitsu.com "In going on with these experiments, how many pretty systems do we build, which we soon find outselves obliged to destroy?" - Benjamin Franklin A Davenport Group Sponsor: http://www.ora.com/davenport/index.html Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA04171 for urn-ietf-out; Fri, 20 Dec 1996 15:56:07 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA04166 for ; Fri, 20 Dec 1996 15:56:03 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23262 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 15:55:50 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <25054-0@josef.ifi.unizh.ch>; Fri, 20 Dec 1996 21:55:38 +0100 Date: Fri, 20 Dec 1996 21:55:36 +0100 (MET) From: "Martin J. Duerst" To: Ryan Moats Cc: Dirk.vanGulik@jrc.it, urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: <32BAE705.7E75@ds.internic.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Fri, 20 Dec 1996, Ryan Moats wrote: > Dirk.vanGulik@jrc.it wrote: > The "%" character is reserved in the URN syntax for introducing the > escape sequence for an octet. Literal use of the "%" character in a > namespace must be encoded using %25 in URNs for that namespace. The > precence of an "%" character in a URN MUST be followed by two characters > from the character set. Very good. Wanted to suggest to mention %25 myself. Saying that one has to use the %HH-encoding of the UTF-8 representation of "%" is the same thing, but the first is a little more direct. > > 3. suggested escape hatch for (grandfathered in) namespaces > > where the glyph representation is confirmed ambigious. (For > > example the $, #, pound and yen sign). > > This is already taken care of by the character set. The only > way to put a character from this set in a URN is to use "%" encoding. > Otherwise, the character terminates the URN. > > It dawns on me that you may be talking about what hex value to use > for the "%" encoding. My current position is that it is the > UNICODE/10646 value via UTF-8. I also have difficulties grasping what Dirk exactly means. For me, it could be one of two things: (1) It's the problem that under some transfers, the # can change into a pound sign. If this is the thing, then we dealt with it on the "represented characters" side by using UTF-8 (where both # and pound have their well-defined positions) and on the "representing characters" side by not having it in . (2) It's the problem that e.g. the $ exists in several variants, in particular with one and two vertical bars, and that a namespace would, for some reason I currently ignore, need to distinguish between those two. Unicode/ISO 10646 and therefore UTF-8 don't make such a distinction, as they encode characters, and not glyphs. If this is what Dirk is worrying about, I would like to answer as follows: The kinds of namespaces that we immagined to be mapped from the real world, such as ISBN, car numbers, account numbers, and so on, really won't use such subtleties of typography. It would be too easy to mix up the two repre- sentations for the people that use them. I think that such cases are so special that it is not necessary to mention them in detail. They are best lumped together with the cases where "characters represented" don't make sense. > > 4. suggested escape hatch for namespaces where the identifiers > > have no meaningfull representation in the urn syntax (at > > least meaningfull in the sense that a UA could gain > > something by showing it to the user) such as spaces which > > have a purely binary object identifiers; base64 is the > > _should_ wannabe. > > I don't have a problem with this, so long as such information > is included in the namespace registration documentation. I always suggested such an escape hatch, but I would like to keep it generic. For clarification, I propose to *add* after Depending on the rules governing a namespace, valid identifiers in a namespace might contain characters that are not members of the URN character set above (). Such strings MUST be translated into canonical NSS format before using them as protocol elements or otherwise passing them on to other applications. Translation is done by encoding each character outside the URN character set as a sequence of one to six octets using UTF-8 encoding, and the encoding of each of those octets as "%" followed by two characters from the character set above. The two characters give the hexadecimal representation of that octet. a new paragraph saying + Namespaces that cannot be interpreted in terms of characters + may define their own mapping to syntactically + conforming NSSs. If a widespread and reliable digital form exists, they + may make use of octet encoding using the "%" character. Please note that + therefore, URNs can contain encoded octet sequences that are not valid + URN sequences. Such namespaces may also use other means for encoding + digital data, such as base64. > > 6. Some extra requiments on the NSI if it is one of the URI > > prefixes. I can see valid reasons to do this; but also > > can see easy confusion with the UA interface; so if one > > proposes such a NSI idenfier she'd better address/defend > > it in the publication right away. Quick example: > > > > urn:email:dirk.vangulik@jrc.it > > urn:smtp:Marcel-1.08-1111165644-064SrPH@snoopy.ant.co.uk > > urn:nntp:some-message-id-as-above > > Oog. I'm gonna take a pass on this one also for now (I have to > think about it some more)... My thoughts (not finished yet): - What about new URL schemes? Do we need a common registration? - If we have a common registration, isn't there the danger that the urn: prefix will be dropped, for which finally agreement seems to have been found? > > ... > > Now this kind of 'clashes' with the needs to grandfather in various > > schemes as their glyfh encoding might *NOT* be an unambigious character > > index. For example if the indexes or local control identifiers are > > collected over various contries; which each use their own (say latin) > > charset, but the actual LCI is just the sequence of the character index > > number _ITSELF_ into the various charsets. So encoding the glyf using > > UTF8 it represents in one charset display mapping would most certainly > > wrong for another one; and if the people interoperate you have broken the > > LCI scheme. The reverse also happens; and on top of that normalizing in > > UTF8 makes it even more fun. If there is a namespace that encodes using different "charset"s for different identifiers, then either the information about each "charset" used is still available, somewhere in the identifier or elsewhere, and the identifiers can be converted to UTF8 and treated as everything else. Otherwise, if the information about which "charset" is used in each identifier is not available, or too difficult to get (e.g. needing a connection to ask for it from some remote site), the characters are lost, and there is no other solution to treat this as if they never had been there. (i.e. use base64 or such). In this case, there is no need to speak about glyphs. If glyphs are indeed an issue (e.g. a namespace indeed has to distinguish between $ with one and with | and with ||), then if this is a general problem for many of the characters/glyphs used, we can't very well speak about characters anymore, and a special mapping has to be designed. If it's only one or two glyphs, among many where chararacters are well suited, the private zone might be used, or some character might be substituted that is not otherwise used in the namespace. > I don't see a case of glyph ambiguity in the URN character set > itself, however your following sentence: > > > ++ Likewise if glyph ambiguity does not allow for UTF8 encoding > > ++ the publication should outline the possible ambiguity and > > ++ representations possible for display. > > I like and am willing to add. Ryan, does this sentence refer to the preceeding or the following paragraph? I think the preceeding paragraph is not necessary. URNs in general are displayed in their cannonical form. We introduced UTF-8 so that we can construct nice interfaces for the display of character-based URNs. It would be strange to specify that in the context of a certain namespace, a $ has to be represented with ||. It would also be daring by a namespace encoding icons to request or require that the icons are displayed as such. > > ++ The URN is a sequence of glyphs taken from the . It is > > ++ represented by an octet stream with the only the values of the > > ++ indexes of the glyphs in UTF-8. A glyph or symbol encoded, > > ++ entered, stored, displayed or conveyed which is not in this limited > > ++ range, for examply with an UTF-8 encoding, is purely based on the > > ++ mutual understanding of the publishing and utilizing party; but is > > ++ not to be used to represent the URN. > > > > The above needs to be tackled anyway, somewhere; unless I missed the > > place in the current draft which tells us which is really the authorative > > representation (between machines :-) of the beast. (Ignoring > > normalziaiton,etc). > > I thought (probably incorrectly) that this had been closed going into > San Jose. The URN's canonical form (for transmission between > machines) is the sequence of characters from . > Now Martin and Keith can tell me I'm wrong, but I thought this was > closed. Yes, it had been closed. It is represented by: 4. URN presentation and transport URN-aware applications MAY support "natural" display of URNs which contain characters encoded using "%" notation. However, they MUST provide for display of URNs in canonical form (i.e. in a format suitable for transcription). URNs MUST be transported in canonical format. Please note that this does not specify octet representation of the canonical format. Octet representation may look differently if the URN is in an EBCDIC file or an ASCII file or a UNicode file (the later with every second octet being a NULL). I don't think there is a need to reopen this. It's a fair and safe, although not extremely efficient, compromize. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA03904 for urn-ietf-out; Fri, 20 Dec 1996 15:47:08 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA03899 for ; Fri, 20 Dec 1996 15:47:06 -0500 Received: from fssun10.dev.oclc.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23200 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 15:47:05 -0500 Received: from orc.NISOR (orc.dev.oclc.org) by oclc.org (4.1/SMI-4.1) id AA15255; Fri, 20 Dec 96 15:46:54 EST Received: by orc.NISOR (SMI-8.6/SMI-SVR4) id PAA03039; Fri, 20 Dec 1996 15:48:11 -0500 Date: Fri, 20 Dec 1996 15:48:11 -0500 From: weibel@oclc.org (Stu Weibel) Message-Id: <199612202048.PAA03039@orc.NISOR> To: urn-ietf@bunyip.com Subject: [URN] checksums X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: weibel@oclc.org (Stu Weibel) Errors-To: owner-urn-ietf@bunyip.com Leslie is right... this thread is not critical to the success of URN deployment and can be handled elsewhere. Creeping featurism is the bane of this group. Solve one problem at a time. stu Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA03804 for urn-ietf-out; Fri, 20 Dec 1996 15:37:43 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA03799 for ; Fri, 20 Dec 1996 15:37:37 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23139 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 15:37:19 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 20 14:35 CST 1996 Message-Id: <32BAF8A8.5324@ds.internic.net> Date: Fri, 20 Dec 1996 14:35:52 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Daniel LaLiberte Cc: Dirk.vanGulik@jrc.it, urn-ietf@bunyip.com Subject: Re: structured NIDs [was Re: [URN] Pre-release of draft-ietf-...] References: <32BAE705.7E75@ds.internic.net> <199612202013.OAA23521@void.ncsa.uiuc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Daniel LaLiberte wrote: > > Ryan Moats writes: > > Dirk.vanGulik@jrc.it wrote: > > > I only recently realized this when we where making an updated version > > > of a namespace; and we actually federated the namespace identification > > > itself for a little test; i.e. > > > > > > urn:v2.inet:some.where:somestring > > > > Ok, now we talk about the "." in the NID. I don't have a strong opinion > > as to whether it should be included or not. Anybody else what to > > comment on this? > > Whether we do this or not, I don't consider it a silly question. > It affects performance as well as human factor issues such as how > organizations tend to arrange themselves (i.e. in hierarchies). > > Structuring the NID is not strictly necessary because any > substructure *could* be pushed off to the NSS. But substructure in the > NSS would not be as easily visible to clients and thus caching would > be more difficult. > > For example, if urn:inet:v2:some.where:somestring were handled one way > and urn:inet:v8:some.where:somestring were handled another, then the > V2 vs V8 is in the NSS. But the NAPTR data for inet could specify a > regex that matches on this part of the NSS and thus different > resolvers could be specified, but it is more work for the client. Hang on. The NID cannot have ":" in it. Therefore, the NID for both of these cases is inet. Now, if the inet namespace wants to have substructure, that's fine. However, the questions are: (1) Should the NID have substrcuture? (2) If yes, how do we do it? I deleted the rest of the mail because it gets into implementation (question 2) without discussing question 1. Thinking about this some more, I'm wondering what structure in the NID gives me. The NID is used to (a) help find a namespace resolver and (b) maybe help find NA information from the NSS. Structure in the NID would only be used to solve (a) or (b) which are already being done without the strucutre. Unless somebody has a (c), (d) or etc. that NID structure gives me, why complicate the syntax? Note: I'm punting on (2), because I'm leaning toward the answer to (1) being "no". Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA03787 for urn-ietf-out; Fri, 20 Dec 1996 15:37:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA03782 for ; Fri, 20 Dec 1996 15:37:18 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23136 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 15:37:17 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id PAA00458; Fri, 20 Dec 1996 15:37:14 -0500 Message-Id: <199612202037.PAA00458@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Fri, 20 Dec 1996 15:37:13 -0500 In-Reply-To: "David W. Morris"'s message as of Dec 20, 11:33 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: "David W. Morris" , Ryan Moats Subject: Re: [URN] Checksums in URNs Cc: "Ron Daniel Jr." , urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Okay, I think this is losing focus... The question is not simply whether having the ability to checksum URNs would be a good thing or not -- there is much merit in the suggestion, because the problems it tries to solve are very real. However, there _is_ the question of whether or not it should be moved into the general URN syntax/structure. There are reasons to do this (it'll be built in and usable by all schemes), and reasons not to (creeping featurism, trying to pick _one_ way to solve the problem for _all time_). There seem to be more questions popping up -- how to handle white spaces, what this is really intended to do, how it should be represented, etc. There are alternative mechanisms -- the external wrapper/service, as Larry suggested, or even incorporating it into individual namespaces -- or coming up with a standardized way that new namespaces could _all_ adopt. Unless someone (that could mean you, David Morris :-) can come up with concrete answers to the questions I asked earlier (see below), I think we can sum up _consensus_ by saying: there is obvious merit in having mechanisms to test the integrity of URNs. We don't yet know what the best mechanism to handle that is (we don't even yet have any real-life experience with them), so we can't answer it now, and will leave it as a future problem. Cheers! Leslie. [From my earlier message:] Things that need to be made clear: . whether this can be defined across _all_ URNs or is better hanlded by individual namespaces . is there _one_ checksumming standard that could be considered acceptable across _all_ URNs, now and forever, or else how do we identify which system was used for which URN? . how this would be handled in the rest of the URN resolution system (e.g., impacts on how NAPTR would handle URNs, etc) . how this would fit into the proposed syntax If somebody wants to propose concrete answers to these issues, we can see about getting consensus about moving on this... Specifically, rather than defining what "MUST" be done "by URNs", I'm looking for some _concrete_ proposed adaptations to the drafts that would do what is wanted. -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA03755 for urn-ietf-out; Fri, 20 Dec 1996 15:34:53 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA03750 for ; Fri, 20 Dec 1996 15:34:50 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA23120 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 15:34:47 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id NAA04420; Fri, 20 Dec 1996 13:34:33 -0700 (MST) Message-Id: <3.0.32.19961220133010.006cb3f0@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 20 Dec 1996 13:44:00 -0700 To: "David W. Morris" From: "Ron Daniel Jr." Subject: Re: [URN] Checksums in URNs Cc: Ryan Moats , urn-ietf@bunyip.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com Thus spoke David W. Morris (at least at 11:54 AM 12/20/96 -0800) >is some form of self validation a >necessary precondition for the long term utility and success of >URNs. If the answer is yes, then the self-validation should be >specified as part of the URN, even if only to say that a conforming >URN implemenation must support ck:. If the answer is no, then the >URN specification can ignore the issue and allow the perhaps never >to be designed and specified other means to be used. Actually, you are asking for something a bit stronger than a self-validation ability. Lots of namespaces already provide check-digit calculations of one form or another. However, their calculations are not the same, so a user agent can't validate the URNs. You are asking for the one-true-way to do check digits in URNs, which would allow clients to do a sanity check on the URN even if they were disconnected from the rest of the world. While this would be nice, I am NOT convinced that it is mandatory. I AM concerned about any attempts to say "this one aspect of URNs must be immutable for all time". If protocols, machines, filenames, resolution mechanisms, ... are all assumed subject to change over time and therefore discouraged from appearing in the URN, what makes us think that any arbitrary check digit calculation will also be immutable? There is at least one counter-example. The DUNS number system changed its check digit calculation, and coming up with a new one that would not invalidate the old numbers had to be fun. The reasons they made that change, to fit more numbers into their fixed-size identifier, are not so important to URNs but my point is that we should avoid making requirements for immutable procedures in a system that is expected to live a long time in a mutable environment. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA03539 for urn-ietf-out; Fri, 20 Dec 1996 15:18:43 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA03534 for ; Fri, 20 Dec 1996 15:18:41 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22933 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 15:18:39 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.2/8.8.2) with ESMTP id OAA22671; Fri, 20 Dec 1996 14:17:50 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id OAA23521; Fri, 20 Dec 1996 14:13:41 -0600 (CST) Date: Fri, 20 Dec 1996 14:13:41 -0600 (CST) Message-Id: <199612202013.OAA23521@void.ncsa.uiuc.edu> To: Ryan Moats Cc: Dirk.vanGulik@jrc.it, urn-ietf@bunyip.com Subject: structured NIDs [was Re: [URN] Pre-release of draft-ietf-...] In-Reply-To: <32BAE705.7E75@ds.internic.net> References: <32BAE705.7E75@ds.internic.net> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Ryan Moats writes: > Dirk.vanGulik@jrc.it wrote: > > I only recently realized this when we where making an updated version > > of a namespace; and we actually federated the namespace identification > > itself for a little test; i.e. > > > > urn:v2.inet:some.where:somestring > > Ok, now we talk about the "." in the NID. I don't have a strong opinion > as to whether it should be included or not. Anybody else what to > comment on this? Whether we do this or not, I don't consider it a silly question. It affects performance as well as human factor issues such as how organizations tend to arrange themselves (i.e. in hierarchies). Structuring the NID is not strictly necessary because any substructure *could* be pushed off to the NSS. But substructure in the NSS would not be as easily visible to clients and thus caching would be more difficult. For example, if urn:inet:v2:some.where:somestring were handled one way and urn:inet:v8:some.where:somestring were handled another, then the V2 vs V8 is in the NSS. But the NAPTR data for inet could specify a regex that matches on this part of the NSS and thus different resolvers could be specified, but it is more work for the client. By the way, if the components of the structured NID were reversed and separated by "/", then we would have something strongly resembling the "path" scheme. The reversal to reconstruct a DNS name (e.g. inet/v2 -> v2.inet.urn.net) could be done explicitly by clients rather than rely on a sequence of regex substitutions and DNS lookups proportional in length to the number of components. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA03290 for urn-ietf-out; Fri, 20 Dec 1996 15:03:42 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA03285 for ; Fri, 20 Dec 1996 15:03:40 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22836 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 15:03:31 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id NAA04136; Fri, 20 Dec 1996 13:03:23 -0700 (MST) Message-Id: <3.0.32.19961220131241.006cd914@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 20 Dec 1996 13:12:49 -0700 To: "David W. Morris" , Ryan Moats From: "Ron Daniel Jr." Subject: Re: [URN] Checksums in URNs Cc: urn-ietf@bunyip.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com Thus spoke David W. Morris (at least at 11:33 AM 12/20/96 -0800) [on the subject of white space] >the real world fact is that >URNs will be 'typed' into plain text mail, printed, etc. For ease >of handling, line breaks, etc. will creep in. Any verification scheme >should, I think, allow for the possiblity. I think this is a "user-interface" issue. When one system sends a URN to another system, white space characters are not allowed. If a user, OCR system, ... somehow comes up with a bunch of whitespace characters when they try to specify a URN to a user-agent, then it is that user-agent's responsibility to make it legal or refuse it. We can and should provide some "advice to imlpementors" that they should expect to see illegal characters in URNs, especially when a user is providing the URN, but that they MUST not send an illegal URN, they SHOULD try obvious cleanups, and the MAY try to be very smart indeed about how they make up a legal URN from an illegal one. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA03202 for urn-ietf-out; Fri, 20 Dec 1996 14:58:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA03197 for ; Fri, 20 Dec 1996 14:58:43 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22792 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 14:58:41 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 20 13:57 CST 1996 Message-Id: <32BAEF94.7EC3@ds.internic.net> Date: Fri, 20 Dec 1996 13:57:08 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: "David W. Morris" Cc: "Ron Daniel Jr." , urn-ietf@bunyip.com Subject: Re: [URN] Checksums in URNs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com David W. Morris wrote: > > On Fri, 20 Dec 1996, Ryan Moats wrote: > > [rest-deleted...] > > > BTW, just as a final note, the current URN syntax does not allow > > arbitrary white space to be added in an unescaped form (just for > > those inquiring minds) > > And I am not proposing changing that ... but the real world fact is that > URNs will be 'typed' into plain text mail, printed, etc. For ease > of handling, line breaks, etc. will creep in. Any verification scheme > should, I think, allow for the possiblity. Any verification scheme "built into the URN itself" cannot handle that possibility, because the unescaped white-space terminates the URN. A verification scheme that can't handle the possibility is not acceptable (I think we agree on this). So, build the verification scheme into something that can handle the white-space (a new meta-scheme). Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA03185 for urn-ietf-out; Fri, 20 Dec 1996 14:57:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA03175 for ; Fri, 20 Dec 1996 14:57:54 -0500 Received: from shell1.aimnet.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22767 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 14:57:48 -0500 Received: from localhost (dwm@localhost) by shell1.aimnet.com (8.8.4/SHELL) with SMTP id LAA23429; Fri, 20 Dec 1996 11:54:07 -0800 (PST) Date: Fri, 20 Dec 1996 11:54:07 -0800 (PST) From: "David W. Morris" X-Sender: dwm@shell1.aimnet.com To: "Ron Daniel Jr." Cc: Ryan Moats , urn-ietf@bunyip.com Subject: Re: [URN] Checksums in URNs In-Reply-To: <3.0.32.19961220125706.006cb8d8@acl.lanl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "David W. Morris" Errors-To: owner-urn-ietf@bunyip.com On Fri, 20 Dec 1996, Ron Daniel Jr. wrote: > I agree with Ryan. I am not in favor of adding more stuff > to the URN syntax, especially when it can be accomplished by > other means. My base concern is only ... is some form of self validation a necessary precondition for the long term utility and success of URNs. If the answer is yes, then the self-validation should be specified as part of the URN, even if only to say that a conforming URN implemenation must support ck:. If the answer is no, then the URN specification can ignore the issue and allow the perhaps never to be designed and specified other means to be used. If in practice, URNs are perceived as as fragile as today's URLs, then the effort to design URNs will have been wasted. One aspect of today's fragility is typographic error of on entry. Dave Morris Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA03074 for urn-ietf-out; Fri, 20 Dec 1996 14:49:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA03069 for ; Fri, 20 Dec 1996 14:49:44 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22699 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 14:49:42 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 20 13:48 CST 1996 Message-Id: <32BAEDA2.4940@ds.internic.net> Date: Fri, 20 Dec 1996 13:48:50 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: urn-ietf@bunyip.com Subject: [URN] Syntax Draft Plans... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Folks- There have been some good comments about the syntax draft and some good stuff coming out of meshing it with the URL syntax, so I am planning the following (i.e. you have been warned!). There will be another pre-release of syntax-02 coming out on 12/26 ( Holidays, what are Holidays ;-} ). The target is to have -02 be sent to the i-d editors on 1/6/97. This way folks (who don't have anything else to do between 12/25 and 1/1) can read the new version... Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA03059 for urn-ietf-out; Fri, 20 Dec 1996 14:49:22 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA03054 for ; Fri, 20 Dec 1996 14:49:20 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22695 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 14:49:18 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA03994; Fri, 20 Dec 1996 12:49:08 -0700 (MST) Message-Id: <3.0.32.19961220125706.006cb8d8@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Fri, 20 Dec 1996 12:58:34 -0700 To: Ryan Moats , "David W. Morris" From: "Ron Daniel Jr." Subject: Re: [URN] Checksums in URNs Cc: urn-ietf@bunyip.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com I agree with Ryan. I am not in favor of adding more stuff to the URN syntax, especially when it can be accomplished by other means. Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA02917 for urn-ietf-out; Fri, 20 Dec 1996 14:37:04 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA02912 for ; Fri, 20 Dec 1996 14:37:02 -0500 Received: from shell1.aimnet.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22626 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 14:36:56 -0500 Received: from localhost (dwm@localhost) by shell1.aimnet.com (8.8.4/SHELL) with SMTP id LAA19558; Fri, 20 Dec 1996 11:33:27 -0800 (PST) Date: Fri, 20 Dec 1996 11:33:26 -0800 (PST) From: "David W. Morris" X-Sender: dwm@shell1.aimnet.com To: Ryan Moats Cc: "Ron Daniel Jr." , urn-ietf@bunyip.com Subject: Re: [URN] Checksums in URNs In-Reply-To: <32BAE83F.5574@ds.internic.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "David W. Morris" Errors-To: owner-urn-ietf@bunyip.com On Fri, 20 Dec 1996, Ryan Moats wrote: > Yes, but if it is encased in a meta-scheme, the URN syntax draft doesn't > (and shouldn't care about it). If it is embedded in the URN itself, > then the ck: scheme is redundant. Why invent the wheel twice? Because ck: can apply to any URL but since it isn't part of the URL it would be hard to require ... it would be an internet standard way to validate things with no home to require its use. > > As to the discussion of white space, etc. that's a different topic than > what I'm going on about... > > Ryan > > BTW, just as a final note, the current URN syntax does not allow > arbitrary white space to be added in an unescaped form (just for > those inquiring minds) And I am not proposing changing that ... but the real world fact is that URNs will be 'typed' into plain text mail, printed, etc. For ease of handling, line breaks, etc. will creep in. Any verification scheme should, I think, allow for the possiblity. Dave Morris Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA02799 for urn-ietf-out; Fri, 20 Dec 1996 14:26:46 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA02794 for ; Fri, 20 Dec 1996 14:26:43 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22576 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 14:26:41 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 20 13:25 CST 1996 Message-Id: <32BAE83F.5574@ds.internic.net> Date: Fri, 20 Dec 1996 13:25:51 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: "David W. Morris" Cc: "Ron Daniel Jr." , urn-ietf@bunyip.com Subject: Re: [URN] Checksums in URNs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com David W. Morris wrote: > > On Fri, 20 Dec 1996, Ron Daniel Jr. wrote: > > > My preference would be to NOT require checksums in all URNs. > > I rather like Larry's suggestion of a wrapper like > > ck:the-checksum:the-uri > > I like the clean elegance of the checksum wrapper as a general > solution ... but I'm having a hard shaking the notion that having > a checksum built in to the URN would vastly improve the reliability > of URNs over time. On the other hand, I don't see where it would help... > My current feeling is that ck: is good and should be done as it can > apply for URLs of all kinds.... No problem so far... >AND URNs should have provision for > a built in checksum which MUST be supported by all conforming UAs, > Transfer Agents, etc. but MAY be used in any specific URN. I have a problem with this, in that it adds optional structure to the URN. This optional structure make the URN syntax dirtier (IMHO) and could create more headaches in resolving with the URL syntax (and I'm at my limit of various pain medications already...)... > In either case, part of the design MUST consider how the feature will > be used by humans ... I think that means that the syntax of ck: and > a URN form if allowed needs to support linear white space insertion > in the URL/URN at arbitrary points. Yes, but if it is encased in a meta-scheme, the URN syntax draft doesn't (and shouldn't care about it). If it is embedded in the URN itself, then the ck: scheme is redundant. Why invent the wheel twice? As to the discussion of white space, etc. that's a different topic than what I'm going on about... Ryan BTW, just as a final note, the current URN syntax does not allow arbitrary white space to be added in an unescaped form (just for those inquiring minds) Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA02675 for urn-ietf-out; Fri, 20 Dec 1996 14:22:08 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA02666 for ; Fri, 20 Dec 1996 14:22:00 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22554 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 14:21:56 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 20 13:20 CST 1996 Message-Id: <32BAE705.7E75@ds.internic.net> Date: Fri, 20 Dec 1996 13:20:37 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Dirk.vanGulik@jrc.it Cc: urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Dirk.vanGulik@jrc.it wrote: > > Just some comments on grandfathering and the % changes. The quick summary > > 0. A plea to make the representation the real > thing; while still urging for the UA's to display/enter/... > then with effective UTF8 decoding. I'll take a pass on this for the moment... > > 1. suggested removal of the '%' sign from the list. > > 2. suggested a utf-8 glyph encoding of '%' as a > octed for the char itself (%25 I think) I think you may have missed my mail on URN/URL potential incompatibilities. The current text of the draft on the "%" issue is the following: "...Translation is done by encoding each character outside the URN character set as a sequence of one to six octets using UTF-8 encoding, and the encoding of each of those octets as "%" followed by two characters from the character set above. The two characters give the hexadecimal representation of that octet. The "%" character is reserved in the URN syntax for introducing the escape sequence for an octet. Literal use of the "%" character in a namespace must be encoded using %25 in URNs for that namespace. The precence of an "%" character in a URN MUST be followed by two characters from the character set. Namespaces MAY designate one or more characters from the URN character set as having special meaning for that namespace. If the namespace also uses that character in a literal sense as well, the character used in a literal sense MUST be encoded with "%" followed by the hexadecimal representation of that octet. Therefore, the process of registering a namespace identifier shall include publication of a definition of which characters have a special meaning." This takes care of the above issues, as well as your "...%is..." example below... > 3. suggested escape hatch for (grandfathered in) namespaces > where the glyph representation is confirmed ambigious. (For > example the $, #, pound and yen sign). This is already taken care of by the character set. The only way to put a character from this set in a URN is to use "%" encoding. Otherwise, the character terminates the URN. It dawns on me that you may be talking about what hex value to use for the "%" encoding. My current position is that it is the UNICODE/10646 value via UTF-8. > 4. suggested escape hatch for namespaces where the identifiers > have no meaningfull representation in the urn syntax (at > least meaningfull in the sense that a UA could gain > something by showing it to the user) such as spaces which > have a purely binary object identifiers; base64 is the > _should_ wannabe. I don't have a problem with this, so long as such information is included in the namespace registration documentation. > 5. Some very SILLY suggestion about leaving the '.' in the > NSS reserverd for future version or expansion. I agree that I think it is silly. I got confused here as to whether you were talking about the NID or the NSS. Reserving "." in the NSS is the thing I think is silly. I'll talk about the NID later... > 6. Some extra requiments on the NSI if it is one of the URI > prefixes. I can see valid reasons to do this; but also > can see easy confusion with the UA interface; so if one > proposes such a NSI idenfier she'd better address/defend > it in the publication right away. Quick example: > > urn:email:dirk.vangulik@jrc.it > urn:smtp:Marcel-1.08-1111165644-064SrPH@snoopy.ant.co.uk > urn:nntp:some-message-id-as-above Oog. I'm gonna take a pass on this one also for now (I have to think about it some more)... > -- This is slightly more restrictive that what is stated in RFC 1738 [3] > -- (which allows the period "."). Further, the Namespace Identifier is > -- case insensitive, so that "ISBN" and "isbn" refer to the same > -- namespace. > > I only recently realized this when we where making an updated version > of a namespace; and we actually federated the namespace identification > itself for a little test; i.e. > > urn:v2.inet:some.where:somestring Ok, now we talk about the "." in the NID. I don't have a strong opinion as to whether it should be included or not. Anybody else what to comment on this? > -- To avoid confusion with the "urn:" identifier, the NID "urn" is > -- reserved and MUST NOT be used. > > After some confusion here; I would like to add something along the > lines of: > > If a proposed namespace identifier is already in use as a protocol > specifier in the URI space, such as for example ftp, http or email, > the proposal for this identifier should justify this choise; i.e > > urn:email:dirk.vangulik@jrc.it or > urn:ftp:someplace:abc.efg > urn:ftp://someplace/abcd.efg Now this makes some sense to me. I'm wondering if we want to make the statement stronger... > ... > This means that a '%' followed by a non-hex encodes itself, but so > > urn:abc:jan%is%gek and Not any more, see my discussion above. > ... > Now this kind of 'clashes' with the needs to grandfather in various > schemes as their glyfh encoding might *NOT* be an unambigious character > index. For example if the indexes or local control identifiers are > collected over various contries; which each use their own (say latin) > charset, but the actual LCI is just the sequence of the character index > number _ITSELF_ into the various charsets. So encoding the glyf using > UTF8 it represents in one charset display mapping would most certainly > wrong for another one; and if the people interoperate you have broken the > LCI scheme. The reverse also happens; and on top of that normalizing in > UTF8 makes it even more fun. The last portion of the last sentence has gone away and so the last sentence now reads: "Therefore, the process of registering a namespace identifier shall include publication of a definition of which characters have a special meaning to that namespace". I don't see a case of glyph ambiguity in the URN character set itself, however your following sentence: > ++ Likewise if glyph ambiguity does not allow for UTF8 encoding > ++ the publication should outline the possible ambiguity and > ++ representations possible for display. I like and am willing to add. > ++ The URN is a sequence of glyphs taken from the . It is > ++ represented by an octet stream with the only the values of the > ++ indexes of the glyphs in UTF-8. A glyph or symbol encoded, > ++ entered, stored, displayed or conveyed which is not in this limited > ++ range, for examply with an UTF-8 encoding, is purely based on the > ++ mutual understanding of the publishing and utilizing party; but is > ++ not to be used to represent the URN. > > The above needs to be tackled anyway, somewhere; unless I missed the > place in the current draft which tells us which is really the authorative > representation (between machines :-) of the beast. (Ignoring > normalziaiton,etc). I thought (probably incorrectly) that this had been closed going into San Jose. The URN's canonical form (for transmission between machines) is the sequence of characters from . Now Martin and Keith can tell me I'm wrong, but I thought this was closed. Other things: If a namespace wants to be opaque and use base-64, that's fine, but I don't see where the syntax document must specify that. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA01599 for urn-ietf-out; Fri, 20 Dec 1996 13:53:15 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA01592 for ; Fri, 20 Dec 1996 13:53:11 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22339 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 13:52:54 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA12960; Fri, 20 Dec 96 19:58:19 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA15610; Fri, 20 Dec 1996 19:52:29 +0100 Date: Fri, 20 Dec 1996 19:52:28 +0100 (MET) From: Dirk.vanGulik@jrc.it X-Sender: dirkx@elect6.jrc.it To: Ryan Moats Cc: urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: <32B56D9D.7B96@ds.internic.net> Message-Id: Reply-Path: Dirk.vanGulik@jrc.it Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Dirk.vanGulik@jrc.it Errors-To: owner-urn-ietf@bunyip.com Just some comments on grandfathering and the % changes. The quick summary 0. A plea to make the representation the real thing; while still urging for the UA's to display/enter/... then with effective UTF8 decoding. 1. suggested removal of the '%' sign from the list. 2. suggested a utf-8 glyph encoding of '%' as a octed for the char itself (%25 I think) 3. suggested escape hatch for (grandfathered in) namespaces where the glyph representation is confirmed ambigious. (For example the $, #, pound and yen sign) 4. suggested escape hatch for namespaces where the identifiers have no meaningfull representation in the urn syntax (at least meaningfull in the sense that a UA could gain something by showing it to the user) such as spaces which have a purely binary object identifiers; base64 is the _should_ wannabe. 5. Some very SILLY suggestion about leaving the '.' in the NSS reserverd for future version or expansion. 6. Some extra requiments on the NSI if it is one of the URI prefixes. I can see valid reasons to do this; but also can see easy confusion with the UA interface; so if one proposes such a NSI idenfier she'd better address/defend it in the publication right away. Quick example: urn:email:dirk.vangulik@jrc.it urn:smtp:Marcel-1.08-1111165644-064SrPH@snoopy.ant.co.uk urn:nntp:some-message-id-as-above Although one might think these are a bad idea; the syntax and resolution allows for them; the do make a bit of sense and I can image people with actually have brains dreaming up persitant names for resources they already have avaible under a well know url. Have fun. Dw. -- URN Syntax -- Filename: draft-ietf-urn-syntax-02.txt -- -- 2.1 Namespace Identifier Syntax -- -- The following is the syntax for the Namespace Identifier. To (a) be -- consistent with all potential resolution schemes and (b) not put any -- undue constraints on any potential resolution scheme, the syntax for -- the Namespace Identifier is: -- -- ::= [ * ] -- -- ::= | | | "-" -- -- ::= | | -- -- ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | -- "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | -- "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | -- "Y" | "Z" -- -- ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | -- "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | -- "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | -- "y" | "z" -- -- ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | -- "8" | "9" -- -- This is slightly more restrictive that what is stated in RFC 1738 [3] -- (which allows the period "."). Further, the Namespace Identifier is -- case insensitive, so that "ISBN" and "isbn" refer to the same -- namespace. I only recently realized this when we where making an updated version of a namespace; and we actually federated the namespace identification itself for a little test; i.e. urn:v2.inet:some.where:somestring Which obviously works with the v2.inet.urn.net lookup. I am not sure wether this is fluff functionality; and I feel that I am going down a slipperly slope; but you 'might' want to reserve the dot somehow for future expansion if you need an extra dimension; say because we do not have the syntax right now; you could do something like urn:duns.2:gorbaglobinrealniceunicode I.e. have an escape option. -- To avoid confusion with the "urn:" identifier, the NID "urn" is -- reserved and MUST NOT be used. After some confusion here; I would like to add something along the lines of: If a proposed namespace identifier is already in use as a protocol specifier in the URI space, such as for example ftp, http or email, the proposal for this identifier should justify this choise; i.e urn:email:dirk.vangulik@jrc.it or urn:ftp:someplace:abc.efg urn:ftp://someplace/abcd.efg Because I can see people wanting to re-use some of the existing well know protocol specifiers; but that would _really_ cause confusion esspecially when the User agent allow you to type 'ibm' and really turn it into http://www.ibm.com:80/home.html these days :-) -- As required by 1737, there is a single canonical representation of -- the NSS portion of an URN. The format of this single canonical form -- follows: -- -- ::= * -- -- ::= | "%" -- -- ::= | | | -- -- ::= | "A" | "B" | "C" | "D" | "E" | "F" | -- "a" | "b" | "c" | "d" | "e" | "f" -- -- ::= "(" | ")" | "+" | "" | "," | "-" | "." | "/" | -- ":" | "=" | "?" | "@" | "%" This means that a '%' followed by a non-hex encodes itself, but so urn:abc:jan%is%gek and is no problem. But than suppose you _want_ to replace the 'is' by a 'ef' which looks like hex (though you did not intend it. So I would propose to re-formulate it as: ++ ::= "(" | ")" | "+" | "" | "," | "-" | "." | "/" | ++ ":" | "=" | "?" | "@" And in the text -- Depending on the rules governing a namespace, valid identifiers in a -- namespace might contain characters that are not members of the URN -- character set above (). Such strings MUST be translated -- into canonical NSS format before using them as protocol elements or -- otherwise passing them on to other applications. Translation is done -- by encoding each character outside the URN character set as a -- sequence of one to six octets using UTF-8 encoding, and the encoding -- of each of those octets as "%" followed by two characters from the -- character set above. The two characters give the hexadecimal ++ representation of that octet. The percentage sign _itself_ is encoded ++ as an octed index into its UTF-8 representation -- Namespaces MAY designate one or more characters from the URN -- character set as having special meaning for that namespace (An -- example of this is the "%" character in the URN syntax itself). If -- the namespace also uses that character in a literal sense as well, -- the character used in a literal sense MUST be encoded with "%" -- followed by the hexadecimal representation of that octet. Therefore, -- the process of registering a namespace identifier shall include -- publication of a definition of which characters have a special -- meaning and how to encode these characters if used in a literal -- sense. Now this kind of 'clashes' with the needs to grandfather in various schemes as their glyfh encoding might *NOT* be an unambigious character index. For example if the indexes or local control identifiers are collected over various contries; which each use their own (say latin) charset, but the actual LCI is just the sequence of the character index number _ITSELF_ into the various charsets. So encoding the glyf using UTF8 it represents in one charset display mapping would most certainly wrong for another one; and if the people interoperate you have broken the LCI scheme. The reverse also happens; and on top of that normalizing in UTF8 makes it even more fun. So for this reason I suggest the follwing change of wording -- Depending on the rules governing a namespace, valid identifiers in a -- namespace might contain character indexes that are not members of the ++ URN character set above or have a different glyph represenation in the ++ above charset. (). Such strings MUST be translated -- into canonical NSS format before using them as protocol elements or -- otherwise passing them on to other applications. Translation is done -- by encoding each character index outside the URN character and/or ++ with a different glyph interpretation. If the glyph and indexes ++ representation is unambigious then it SHOULD be encoded as a ++ sequence of one to six octets using UTF-8 encoding, and the encoding -- of each of those octets as "%" followed by two characters from the -- character set above. The two characters give the hexadecimal ++ representation of that octet. The percentage glyph _itself_ is encoded ++ as an octed index into the UTF-8 representation. As an aside; could someone more knowledgable than me add something about normalization of the UTF-8 string; as this does aid the encoding when a user is allowed to enter a URN from a keyword with other keys than than those corresponding to the symbols of . -- Namespaces whose object identifiers do not have a mapping to an -- information conveying representation SHOULD use a base64 encoding -- of the binary encoded identifier. -- Namespaces MAY designate one or more characters from the URN -- character set as having special meaning for that namespace (An -- example of this is the "%" character in the URN syntax itself). If -- the namespace also uses that character in a literal sense as well, -- the character used in a literal sense MUST be encoded with "%" -- followed by the hexadecimal representation of that octet. Therefore, -- the process of registering a namespace identifier shall include -- publication of a definition of which characters have a special -- meaning and how to encode these characters if used in a literal ++ sense. Likewise if glyph ambiguity does not allow for UTF8 encoding ++ the publication should outline the possible ambiguity and ++ representations possible for display. By the way; I do feel quite strong about glyph ambiguity and the ability to encode arbritary strings. I would even be happier if each name scheme essnetially defined _ITSELF_ what glyph encoding it uses; and only suggest extremly strongly that UTF is the way to go. But that the bottom line is that: ++ The URN is a sequence of glyphs taken from the . It is ++ represented by an octed stream with the only the values of the ++ indexes of the glyphs in UTF-8. A glyph or symbol encoded, ++ entered, stored, displayed or conveyed which is not in this limited ++ range, for examply with an UTF-8 encoding, is purely based on the ++ mutual understanding of the publishing and utilizing party; but is ++ not to be used to represent the URN. The above needs to be tackled anyway, somewhere; unless I missed the place in the current draft which tells us which is really the authorative representation (between machines :-) of the beast. (Ignoring normalziaiton,etc). Well, Merry Chrismass, Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA00538 for urn-ietf-out; Fri, 20 Dec 1996 13:19:54 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA00533 for ; Fri, 20 Dec 1996 13:19:51 -0500 Received: from shell1.aimnet.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA22003 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 13:19:49 -0500 Received: from localhost (dwm@localhost) by shell1.aimnet.com (8.8.4/SHELL) with SMTP id KAA16026; Fri, 20 Dec 1996 10:16:10 -0800 (PST) Date: Fri, 20 Dec 1996 10:16:10 -0800 (PST) From: "David W. Morris" X-Sender: dwm@shell1.aimnet.com To: "Ron Daniel Jr." Cc: urn-ietf@bunyip.com Subject: Re: [URN] Checksums in URNs In-Reply-To: <199612201718.KAA02118@acl.lanl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "David W. Morris" Errors-To: owner-urn-ietf@bunyip.com On Fri, 20 Dec 1996, Ron Daniel Jr. wrote: > My preference would be to NOT require checksums in all URNs. > I rather like Larry's suggestion of a wrapper like > ck:the-checksum:the-uri I like the clean elegance of the checksum wrapper as a general solution ... but I'm having a hard shaking the notion that having a checksum built in to the URN would vastly improve the reliability of URNs over time. My current feeling is that ck: is good and should be done as it can apply for URLs of all kinds. AND URNs should have provision for a built in checksum which MUST be supported by all conforming UAs, Transfer Agents, etc. but MAY be used in any specific URN. In either case, part of the design MUST consider how the feature will be used by humans ... I think that means that the syntax of ck: and a URN form if allowed needs to support linear white space insertion in the URL/URN at arbitrary points. Dave Morris Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA29886 for urn-ietf-out; Fri, 20 Dec 1996 12:41:49 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA29881 for ; Fri, 20 Dec 1996 12:41:47 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21692 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 12:41:41 -0500 Received: from jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AB12310; Fri, 20 Dec 96 18:47:06 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA15559; Fri, 20 Dec 1996 18:41:13 +0100 Date: Fri, 20 Dec 1996 18:41:13 +0100 (MET) From: Dirk.vanGulik@jrc.it X-Sender: dirkx@elect6.jrc.it To: "Ron Daniel Jr." Cc: urn-ietf@bunyip.com Subject: Re: [URN] Checksums in URNs In-Reply-To: <199612201718.KAA02118@acl.lanl.gov> Message-Id: Reply-Path: Dirk.vanGulik@jrc.it Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Dirk.vanGulik@jrc.it Errors-To: owner-urn-ietf@bunyip.com Although I can see the appeal of checksummed URN's; I would be more interested implemeting them with a (commercial:-) type of referall system; say the 'nice and easy' service peole urn:nae:580064875 to just give an example of a 9-code protected string. This URN can be N2N-ed by a nice-and-easy service (currently sitting on port 6080 of elect6.jrc.it) which will either give you the URN lodged with it (through elect6.jrc.it:8080/nae.html) or an HTML page explaining that you've got it wrong and the most likely alternative(s). As URNs mature I do thing there is room for the 'friendly-name- lodger' service and I do not know how many other people perfectly willing to service you with nice namespaces which just have that competive edge to your company/project. This is what is made possible in the URN architecture (or at least in my private idea of it) it; and this is what thus should be used to 'grandfather' in such ideas. Merry Chrismass to yee al by the way Dw. -- Live is fair to dutchmen; Sinterklaas comes round it on the fifth http://ewse.ceo.org http://enrm.ceo.org DWvGulik@Dialis.xs4all.nl Dirk.vanGulik@jrc.it +39 332 78 0014 +39 332 78 9549 fax +39 332 78 9185 ISEI/ESBA; The Center For Earth Observation Joint Research Centre of the European Communities, Ispra, Italy On Fri, 20 Dec 1996, Ron Daniel Jr. wrote: > -----BEGIN PGP SIGNED MESSAGE----- > > Mime-Version: 1.0 > Content-Type: text/plain > Content-Transfer-Encoding: 7bit > > To: urn-ietf@bunyip.com > Date: Fri Dec 20 10:28:01 1996 > My preference would be to NOT require checksums in all URNs. > I rather like Larry's suggestion of a wrapper like > ck:the-checksum:the-uri > > > Ron Daniel Jr. email: rdaniel@lanl.gov > Advanced Computing Lab, MS B287 voice: +1 505 665 0597 > Los Alamos National Laboratory fax: +1 505 665 4939 > Los Alamos, NM, USA 87545 http://www.acl.lanl.gov/~rdaniel > Want to buy: "Five Laws of Library Science" by S.R. Ranganathan > -----BEGIN PGP SIGNATURE----- > Version: 2.6.2 > > iQB1AwUBMrrMoTOY2EydG1XFAQHdlgMA20ZcisvDDGG4yz4AJ7c4wMtiz4kwE1R5 > uzWotqHhTTgrkjuUPe0r38bxlFiyu5W+lgaHsSFbrnS+IpfMRclpgwmrW3sNclYc > x/4+Yz8d0u/4qomFaMRJcyZMwQNKLyuY > =7+Oc > -----END PGP SIGNATURE----- > > Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA29665 for urn-ietf-out; Fri, 20 Dec 1996 12:18:47 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA29660 for ; Fri, 20 Dec 1996 12:18:41 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA21515 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 12:18:39 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA02118 for ; Fri, 20 Dec 1996 10:18:36 -0700 (MST) Date: Fri, 20 Dec 1996 10:18:36 -0700 (MST) Message-Id: <199612201718.KAA02118@acl.lanl.gov> From: "Ron Daniel Jr." To: urn-ietf@bunyip.com X-Priority: Normal Subject: Re: [URN] Checksums in URNs X-Mailer: Pronto Secure [Ver 1.12] X-Prontosecureinfo: T=signed, P=x-pgp Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Ron Daniel Jr." Errors-To: owner-urn-ietf@bunyip.com -----BEGIN PGP SIGNED MESSAGE----- Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit To: urn-ietf@bunyip.com Date: Fri Dec 20 10:28:01 1996 My preference would be to NOT require checksums in all URNs. I rather like Larry's suggestion of a wrapper like ck:the-checksum:the-uri Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab, MS B287 voice: +1 505 665 0597 Los Alamos National Laboratory fax: +1 505 665 4939 Los Alamos, NM, USA 87545 http://www.acl.lanl.gov/~rdaniel Want to buy: "Five Laws of Library Science" by S.R. Ranganathan -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQB1AwUBMrrMoTOY2EydG1XFAQHdlgMA20ZcisvDDGG4yz4AJ7c4wMtiz4kwE1R5 uzWotqHhTTgrkjuUPe0r38bxlFiyu5W+lgaHsSFbrnS+IpfMRclpgwmrW3sNclYc x/4+Yz8d0u/4qomFaMRJcyZMwQNKLyuY =7+Oc -----END PGP SIGNATURE----- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA22341 for urn-ietf-out; Fri, 20 Dec 1996 09:35:19 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA22301; Fri, 20 Dec 1996 09:34:23 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19208 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 09:34:20 -0500 Received: by privateer.windrose.omaha.ne.us; Fri Dec 20 08:32 CST 1996 Message-Id: <32BAA368.4FD2@ds.internic.net> Date: Fri, 20 Dec 1996 08:32:08 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: "Martin J. Duerst" Cc: Towsner , Larry Masinter , leslie@bunyip.com, tme@CasA.usno.navy.mil, urn-ietf@bunyip.com, jcurran@bbn.com, uri@bunyip.com Subject: Re: [URN] Checksums in URNs References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com My turn to add my two cents worth... Martin J. Duerst wrote: > > On Thu, 19 Dec 1996, Towsner wrote: > > > >Checksums and other kinds of decorations can be done outside the > > >URL. Think of it as a metascheme: > > > ck: > > > e.g. ck:A3Bd:http://www.parc.xerox.com/masinter > > > > I like the idea of having the checksum be optional, as a > > meta-scheme. > > Same for me. I'll make three... > >I also think the checksum should be limited to alpha-numeric > > characters, to avoid confusion. > > What do you mean by "limited to alpha-numeric characters"? Can you be > more precise. How about just hex characters to keep it simple... > >Perhaps this should be part of the URL > > scheme as well. > > If it is a metascheme, then it is a new URI scheme. It doesn't > have to be discussed either in URL nor in URN syntax. It would > go into a separate draft. It has to make sure, on its own, > that it is compatible with the URL/URN syntax. I agree with Martin, and if we use ck: then we are already compatible with the URL/URN character sets. How to generate the hex sequence is another headache altogether... > Perhaps the URL syntax draft, where it speaks about URIs, > could be generalized in the direction of metaschemes. > From the syntax viewpoint, we already have two metaschemes > (urn: and ck:), which can even be combined together, > as ck:urn:namespace:NSS. Martin is correct here as well. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA22265 for urn-ietf-out; Fri, 20 Dec 1996 09:30:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA22260 for ; Fri, 20 Dec 1996 09:30:47 -0500 Received: from yscydion.ansa.co.uk by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19191 (mail destined for urn-ietf@services.bunyip.com); Fri, 20 Dec 96 09:30:44 -0500 Received: by yscydion.ansa.co.uk; Fri, 20 Dec 96 14:30:01 GMT Received: by plato.ansa.co.uk; Fri, 20 Dec 96 14:30:00 GMT To: dirkx%elect2@dicsmss1.jrc.it Cc: "Ronald E. Daniel" , urn-ietf@bunyip.com Subject: Re: [URN] HTTP conventions draft References: From: Toby Speight Mime-Version: 1.0 (generated by *modified* tm-edit 7.43) Content-Type: text/plain (PGP signed); charset=US-ASCII Date: 20 Dec 1996 14:29:59 +0000 In-Reply-To: dirkx%elect2@dicsmss1.jrc.it's message of Thu, 19 Dec 1996 17:21:59 +0100 (MET) Message-Id: Lines: 49 Organization: ANSA - APM Ltd. X-Mailer: Gnus v5.3/Emacs 19.32 X-Author-Info: X-Pgp-Id: 0xABBDC46D (from servers or author-info) Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Toby Speight Errors-To: owner-urn-ietf@bunyip.com -----BEGIN PGP SIGNED MESSAGE----- Dirkx> dirkx >>>>> In article , >>>>> Dirkx wrote: Dirkx> On Wed, 20 Nov 1996, Ronald E. Daniel wrote: Ron> If the client has requested the result be returned as text/html Ron> or application/html, the result should be encoded as: Ron> Ron> where the strings ...url n... are replaced by the n'th URL in the Ron> list. Dirkx> Given the fact that you can ask for a machine parsable list, the Dirkx> above seems superfluous and tooo easy to get wrong. I would prefer Dirkx> to just kill it; as it does little extra in (machine parsable) Dirkx> functionality. I think we should keep a recommendation that servers ought to be prepared to return types other than a URI list (text/html and text/plain, perhaps?) even if the format isn't specified. IOW, we ought to ensure that we can send something human-parsable, at least until text/uri-list is ubiquitous. I think Ron's suggestion is fine, if the word "should" is used in the usual IETF strict sense of "not broken if it doesn't do this, and shouldn't be relied upon, but ought to do it if there's no good reason not to." -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQB1AwUBMrqi2+dsuUurvcRtAQFrPwMAj1uY12LYIis9/ChPKw3w0zKqej2liFI1 GkE/6CX4/wt3Lz4aPNCSftCWCX8ml3hTPbws3jMEbJD8dQAso5J5cB0PJwhVwn49 8tghQ6Q7t9gMeGuSXFghnm5Tb/0xDuhY =9skI -----END PGP SIGNATURE----- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id IAA21302 for urn-ietf-out; Fri, 20 Dec 1996 08:14:32 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id IAA21297; Fri, 20 Dec 1996 08:14:30 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA18882 (mail destined for uri@services.bunyip.com); Fri, 20 Dec 96 08:13:52 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <06235-0@josef.ifi.unizh.ch>; Fri, 20 Dec 1996 14:13:27 +0100 Date: Fri, 20 Dec 1996 14:13:25 +0100 (MET) From: "Martin J. Duerst" To: Towsner Cc: Larry Masinter , leslie@bunyip.com, tme@CasA.usno.navy.mil, urn-ietf@bunyip.com, jcurran@bbn.com, uri@bunyip.com Subject: Re: [URN] Checksums in URNs In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Thu, 19 Dec 1996, Towsner wrote: > >Checksums and other kinds of decorations can be done outside the > >URL. Think of it as a metascheme: > > ck: > > e.g. ck:A3Bd:http://www.parc.xerox.com/masinter >=20 > =09I like the idea of having the checksum be optional, as a > meta-scheme. Same for me. >I also think the checksum should be limited to alpha-numeric > characters, to avoid confusion. What do you mean by "limited to alpha-numeric characters"? Can you be more precise. >Perhaps this should be part of the URL > scheme as well. If it is a metascheme, then it is a new URI scheme. It doesn't have to be discussed either in URL nor in URN syntax. It would go into a separate draft. It has to make sure, on its own, that it is compatible with the URL/URN syntax. Perhaps the URL syntax draft, where it speaks about URIs, could be generalized in the direction of metaschemes. From=20the syntax viewpoint, we already have two metaschemes (urn: and ck:), which can even be combined together, as ck:urn:namespace:NSS. Regards,=09Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id UAA13062 for urn-ietf-out; Thu, 19 Dec 1996 20:36:04 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id UAA13057 for ; Thu, 19 Dec 1996 20:36:02 -0500 Received: from germany-c.it.earthlink.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15769 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 20:36:00 -0500 Received: from [153.35.78.27] (Cust15.Max18.Boston.MA.MS.UU.NET [153.35.78.15]) by germany.it.earthlink.net (8.7.5/8.7.3) with ESMTP id RAA18448; Thu, 19 Dec 1996 17:35:28 -0800 (PST) X-Sender: tows@mail.earthlink.net Message-Id: In-Reply-To: <96Dec19.160759pdt."150"@palimpsest.parc.xerox.com> References: <199612192243.RAA04511@beethoven.bunyip.com> (leslie@bunyip.com) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 19 Dec 1996 20:41:24 -0500 To: Larry Masinter , leslie@bunyip.com From: Towsner Subject: Re: [URN] Checksums in URNs Cc: tme@CasA.usno.navy.mil, urn-ietf@bunyip.com, jcurran@bbn.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Towsner Errors-To: owner-urn-ietf@bunyip.com >Checksums and other kinds of decorations can be done outside the >URL. Think of it as a metascheme: > ck: > e.g. ck:A3Bd:http://www.parc.xerox.com/masinter I like the idea of having the checksum be optional, as a meta-scheme. I also think the checksum should be limited to alpha-numeric characters, to avoid confusion. Perhaps this should be part of the URL scheme as well. -- -Henry Towsner Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA12030 for urn-ietf-out; Thu, 19 Dec 1996 19:08:20 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA12025 for ; Thu, 19 Dec 1996 19:08:18 -0500 Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA15356 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 19:08:15 -0500 Received: from palimpsest.parc.xerox.com ([13.1.101.126]) by alpha.xerox.com with SMTP id <14488(8)>; Thu, 19 Dec 1996 16:08:09 PST Received: by palimpsest.parc.xerox.com id <150>; Thu, 19 Dec 1996 16:07:59 PDT To: leslie@bunyip.com Cc: tme@CasA.usno.navy.mil, urn-ietf@bunyip.com, jcurran@bbn.com In-Reply-To: <199612192243.RAA04511@beethoven.bunyip.com> (leslie@bunyip.com) Subject: Re: [URN] Checksums in URNs From: Larry Masinter Message-Id: <96Dec19.160759pdt."150"@palimpsest.parc.xerox.com> Date: Thu, 19 Dec 1996 15:07:59 PST Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Larry Masinter Errors-To: owner-urn-ietf@bunyip.com Checksums and other kinds of decorations can be done outside the URL. Think of it as a metascheme: ck: e.g. ck:A3Bd:http://www.parc.xerox.com/masinter Does anyone have a 2 character (or, perhaps a 4 character, 24-bit base64) checksum scheme they'd propose? To interpret a checksum URL, just strip off the ck & checksum. Larry Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA10805 for urn-ietf-out; Thu, 19 Dec 1996 17:43:32 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA10800 for ; Thu, 19 Dec 1996 17:43:29 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA14701 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 17:43:18 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id RAA04511; Thu, 19 Dec 1996 17:43:17 -0500 Message-Id: <199612192243.RAA04511@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Thu, 19 Dec 1996 17:43:17 -0500 In-Reply-To: marshall eubanks's message as of Dec 18, 12:12 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: marshall eubanks , urn-ietf@bunyip.com Subject: [URN] Checksums in URNs Cc: jcurran@bbn.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com [Was: Re: [URN] Re[2]: Article re San Jose IETF in Sunday San Francisco paper] [Marshall Eubanks wrote:] > > Maybe URN's should include a check-sum or the like to make sure that > > it has been copied/typed correctly, much as crdit cards numbers, etc., > > do. This could even be in the URN label (as in, URN[XX]:yyyy, where > > XX is a 2 character ascii code based on the yyyy field). The web > > engine could then compare yyyy with XX and complain if they > > don't match. [...] > A reasonable goal might be to be able to detect 2 character errors, > and to correct one character errors. In principle, being able to distinguish between wrong names and evaporated resources seems like a good thing. I haven't seen any comments (yet) that suggest that it is felt to be out of scope. We are now on the verge of finalizing the URN syntax, etc, so we should evaluate whether this seems like a solid, reasonably-implemented idea. Things that need to be made clear: . whether this can be defined across _all_ URNs or is better hanlded by individual namespaces . is there _one_ checksumming standard that could be considered acceptable across _all_ URNs, now and forever, or else how do we identify which system was used for which URN? . how this would be handled in the rest of the URN resolution system (e.g., impacts on how NAPTR would handle URNs, etc) . how this would fit into the proposed syntax If somebody wants to propose concrete answers to these issues, we can see about getting consensus about moving on this... Leslie. -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA00836 for urn-ietf-out; Thu, 19 Dec 1996 11:24:10 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA00829 for ; Thu, 19 Dec 1996 11:24:00 -0500 Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10744 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 11:23:56 -0500 Received: from jrc.it (elect2.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C) id AA21953; Thu, 19 Dec 96 17:29:21 +0100 Received: by jrc.it (5.x/EB-950213-L) id AA13570; Thu, 19 Dec 1996 17:21:59 +0100 Date: Thu, 19 Dec 1996 17:21:59 +0100 (MET) From: dirkx%elect2@dicsmss1.jrc.it To: "Ronald E. Daniel" Cc: urn-ietf@bunyip.com Subject: Re: [URN] HTTP conventions draft In-Reply-To: <199611202031.NAA29358@magenta.acl.lanl.gov> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: dirkx%elect2@dicsmss1.jrc.it Errors-To: owner-urn-ietf@bunyip.com On Wed, 20 Nov 1996, Ronald E. Daniel wrote: > I've changed the conventions draft to remove the integer from the > text/uri-list media type. The new version is appended. I will > send this to the ID editor later today. > > INTERNET DRAFT Ron Daniel > draft-ietf-urn-http-conventions-00.txt Los Alamos National Laboratory > 13 Nov, 1996 > > > Conventions for the Use of HTTP for URN Resolution > ... > If the client has requested the result be returned as text/html or > application/html, the result should be encoded as: > > where the strings ...url n... are replaced by the n'th URL in the list. > Given the fact that you can ask for a machine parsable list, the above seems superfluous and tooo easy to get wrong. I would prefer to just kill it; as it does little extra in (machine parsable) functionality. Just a minor one :-) Dw. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA27145 for urn-ietf-out; Thu, 19 Dec 1996 10:36:03 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA27131; Thu, 19 Dec 1996 10:35:54 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA10263 (mail destined for uri@services.bunyip.com); Thu, 19 Dec 96 10:35:48 -0500 Received: by privateer.windrose.omaha.ne.us; Thu Dec 19 09:34 CST 1996 Message-Id: <32B9606C.702E@ds.internic.net> Date: Thu, 19 Dec 1996 09:34:04 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: "Martin J. Duerst" Cc: Leslie Daigle , uri@bunyip.com, urn-ietf@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Martin J. Duerst wrote: > > We don't want a HTML parser or something similar to need separate code > for parsing URLs and URNs. It should be able to deal with URNs as one > URL scheme, syntactically. It looks like that is possible, but I have > to admit that I am no regex expert. > While I am not a regex expert either, there seem to me some obvious issues here, which I have tried to address with comments on where changes need to be made: 1. Can a URL parser handle the "urn::" leader for URNs properly? Having looked at the "greedy" algorithm and the Regular Expression in the URL draft, I can say that the first part is sufficient to pick up the scheme as "urn:". If we take the approach in comment 3 below, then the URL spec should note that (a) schemes may well have ":" in them or (b) a scheme beginning with "urn:" is treated as an opaque URL because it is really a URN (ITEM FOR URL DRAFT). 2. The URN and URL character sets are not currently aligned well. ("Well" means that there are characters allowed for URLs that are not allowed for URNs). There are currently (by my counting), two characters allowed in the URN char set that are not allowed in the URL char set: "\" and "%". I don't have a problem with moving the "\" to the excluded set for URNs (ITEM FOR URN DRAFT) "%" is also part of the URN char set only to ensure that the definition for the end of a URN is clean. It's sole purpose is to introduce an escape sequence for an octet (a literal "%" must be encoded as %25). I am strengthening the language in the URN syntax draft with respect to the "%" issue. (ITEM FOR URN DRAFT) 3. There is no specification of structure for a URN NSS. The only way to handle this through a URL parser is for the URL parser to declare the URN as an "opaque-URL" and do no processing on it. This specification (if done) must be done in the URL document (ITEM FOR URL DRAFT). If we do these things, I think we've cleaned up the problem. I am currently moving the "\" character to the excluded region of the URN character set. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA26267 for urn-ietf-out; Thu, 19 Dec 1996 09:57:13 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA26243; Thu, 19 Dec 1996 09:56:34 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09870 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 09:55:13 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <11442-0@josef.ifi.unizh.ch>; Thu, 19 Dec 1996 15:26:52 +0100 Date: Thu, 19 Dec 1996 15:26:51 +0100 (MET) From: "Martin J. Duerst" To: Leslie Daigle Cc: Ryan Moats , uri@bunyip.com, urn-ietf@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... In-Reply-To: <199612182324.SAA04077@beethoven.bunyip.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Wed, 18 Dec 1996, Leslie Daigle wrote: > It looks like the following questions are on the table: > > . should URN and URL syntaxes be consistent? I guess we have to ask "to what extent should they be consistent". Definitely, allowing something such as ">" in URNs, while they are used to delimit URLs, would be a very bad idea. On the other hand, the fact that the octets represented (with %HH in the canonical form) in URNs are interpreted as UTF-8 should not at the moment force URLs to suddenly convert to UTF-8 (quite difficult), but should not on the other hand scare URLs away from making the necessary preparations to get better i18n facilities and try to move in the direction of UTF-8. (more on that later). > . if yes, which should now change: > > . URLs cannot, because of legacy support, although > there is the issue of "I18N" > > . URNs "can", except that the existing syntax was > built for specific reasons to address issues that > have concerned URNs more than URLs (e.g., bringing > in other namespaces and addressing multiple language > issues). > > > Is it "desirable" that URN syntax be compliant with URL syntax, or "required"? > What _breaks_ if it is not? We don't want a HTML parser or something similar to need separate code for parsing URLs and URNs. It should be able to deal with URNs as one URL scheme, syntactically. It looks like that is possible, but I have to admit that I am no regex expert. > [Ryan quotes from the URL draft:] > > > > > > Although this specification restricts its discussion to URLs, the > > > syntax defined is that of URI in general. Any requirements placed on > > > the URL syntax also apply to the URI syntax. This uniform syntax for > > > all resource identifiers allows a URN to be used in any data field > > > that might otherwise hold a URL. > > This draft is for the _URL_ syntax, and this is the only paragraph that > lays claim to all of URI syntaxes. But it lays claims for all of the URL document, or at least a large part of it. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id JAA25509 for urn-ietf-out; Thu, 19 Dec 1996 09:10:44 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id JAA25504 for ; Thu, 19 Dec 1996 09:10:41 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09579 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 09:10:39 -0500 Received: by privateer.windrose.omaha.ne.us; Thu Dec 19 08:09 CST 1996 Message-Id: <32B94C92.AA7@ds.internic.net> Date: Thu, 19 Dec 1996 08:09:22 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: Michael Carroll Cc: urn-ietf@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... References: <9612190027.AA06740@mocha.bunyip.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Michael Carroll wrote: > > It might be better for us to describe the current task as specifying > *a* syntax for URNs, rather than *the* syntax for URNs. This would > clearly suggest the possibility that there will be other syntaxes > later. The other syntaxes may use characters from nonroman > character sets; perhaps mappings will be specified from one syntax > to another. Wait a minute. We've hashed this out already. Nonroman character sets are handled via UTF-8 and %encoding. I really don't want to re-open this. Having multiple syntax definitions (IMHO) can be considered a root of a lot of the current URL troubles. Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA21360 for urn-ietf-out; Thu, 19 Dec 1996 01:11:52 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA21355 for ; Thu, 19 Dec 1996 01:11:49 -0500 Received: from proxy2.ba.best.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA08196 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 01:11:47 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.8.4/8.8.3) with SMTP id WAA24552 for ; Wed, 18 Dec 1996 22:09:36 -0800 (PST) Date: Wed, 18 Dec 1996 22:09:35 -0800 (PST) From: "Gregory J. Woodhouse" To: urn-ietf@bunyip.com Subject: [URN] permanence Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com I've mostly kept silent on this matter because it seems rather late in the game to discuss this kind of issue, but I have to agree that permanence is best viewed as an implementation decision rather than a matter of policy. Okay, that calls for some explanation. Ideally, I would like to think of URNs as *abstract* names for resources, and I have to think that is what they are intended to be. URLs encode specific information about which servers store the information and wht specific requests are necessary to retriewve the resource. URNs, on the other hand, encode no such information, and this is the sense in which they are abstract. Of course, permanence is a side effect of abstractness (and very much an intended one!) By analogy, if the implementation of a class is modified, objects which instantiate that class or its descendants need not be aware of the change. Similarly, if a resource is moved, documents which reference it via a URN need not be modified. Okay, okay, that's all very obvious, and it may seem pointless say as much here, but it seems that using permanence as the defining characteristic of URNs has been the source of a lot of confusion. --- gjw@wnetc.com / http://www.wnetc.com/home.html If you're going to reinvent the wheel, at least try to come to come up with a better one. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id AAA21109 for urn-ietf-out; Thu, 19 Dec 1996 00:36:00 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id AAA21104 for ; Thu, 19 Dec 1996 00:35:52 -0500 Received: from shell1.aimnet.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA07859 (mail destined for urn-ietf@services.bunyip.com); Thu, 19 Dec 96 00:35:48 -0500 Received: from localhost (dwm@localhost) by shell1.aimnet.com (8.8.4/SHELL) with SMTP id VAA02042; Wed, 18 Dec 1996 21:31:39 -0800 (PST) Date: Wed, 18 Dec 1996 21:30:57 -0800 (PST) From: "David W. Morris" X-Sender: dwm@shell1.aimnet.com To: "Martin J. Duerst" Cc: marshall eubanks , urn-ietf@bunyip.com Subject: Re: [URN] Re: Re[2]: Article re San Jose IETF in Sunday San Francisco paper In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "David W. Morris" Errors-To: owner-urn-ietf@bunyip.com On Wed, 18 Dec 1996, Martin J. Duerst wrote: > On Wed, 18 Dec 1996, marshall eubanks wrote: > > know that it is typo free if it comes back as "not found." Credit > > card numbers and the like include redundancy for exactly that reason. > > A reasonable goal might be to be able to detect 2 character errors, > > and to correct one character errors. > > As far as I understand URNs (I was mainly involved in their i18n > aspects), their most important property is permanence. This means > that if you have an URN that is "not found", by the virtue of > knowing it being an URN, you know that it's misspelled. That is a circular argument .... permanence is a point of design here not a point of policy. Hence, while the mechanism will allow a URN to be resolved forever, it doesn't guarantee that it will be. So I think the suggestion is quite useful. You really can't tell if it is misspelled or the archives burned down. If you knew it was mispelled, it might be worth attempting other means to figure out what was meant while if it wasn't mispelled, then the resource is gone and one is out of luck. Having a URN checksum/crc/md5 to detect typos and an internal self checking feature is redundancy but so what. The internet protocols are rampant with examples of redundancy between layers and I surely wouldn't expect a client to know how to validate every variation of ISBN but it could be expected to validate a URN. Dave Morris Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA18792 for urn-ietf-out; Wed, 18 Dec 1996 19:27:19 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA18787 for ; Wed, 18 Dec 1996 19:27:17 -0500 Received: from rlg.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06740 (mail destined for urn-ietf@services.bunyip.com); Wed, 18 Dec 96 19:27:12 -0500 Message-Id: <9612190027.AA06740@mocha.bunyip.com> Date: Wed, 18 Dec 96 16:27:02 PST From: "Michael Carroll" To: urn-ietf@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Michael Carroll" Errors-To: owner-urn-ietf@bunyip.com It might be better for us to describe the current task as specifying *a* syntax for URNs, rather than *the* syntax for URNs. This would clearly suggest the possibility that there will be other syntaxes later. The other syntaxes may use characters from nonroman character sets; perhaps mappings will be specified from one syntax to another. If we look at it this way, I think it's not even desirable that all syntaxes for URNs comply with requirements on "the" (existing) syntax for URLs. It's just desirable that the first URN syntax comply. I don't know of anything that breaks if it doesn't. I agree "now is a logical time" to separate these things out. Michael -- Michael Carroll Research Libraries Group br.mjc@rlg.org To: URN-IETF@BUNYIP.COM Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id SAA18303 for urn-ietf-out; Wed, 18 Dec 1996 18:24:22 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id SAA18298; Wed, 18 Dec 1996 18:24:20 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA06453 (mail destined for uri@services.bunyip.com); Wed, 18 Dec 96 18:24:19 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id SAA04077; Wed, 18 Dec 1996 18:24:18 -0500 Message-Id: <199612182324.SAA04077@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Wed, 18 Dec 1996 18:24:18 -0500 In-Reply-To: Ryan Moats's message as of Dec 18, 9:11 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Ryan Moats , uri@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... Cc: urn-ietf@bunyip.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com It looks like the following questions are on the table: . should URN and URL syntaxes be consistent? . if yes, which should now change: . URLs cannot, because of legacy support, although there is the issue of "I18N" . URNs "can", except that the existing syntax was built for specific reasons to address issues that have concerned URNs more than URLs (e.g., bringing in other namespaces and addressing multiple language issues). Is it "desirable" that URN syntax be compliant with URL syntax, or "required"? What _breaks_ if it is not? [Ryan quotes from the URL draft:] > > > > Although this specification restricts its discussion to URLs, the > > syntax defined is that of URI in general. Any requirements placed on > > the URL syntax also apply to the URI syntax. This uniform syntax for > > all resource identifiers allows a URN to be used in any data field > > that might otherwise hold a URL. This draft is for the _URL_ syntax, and this is the only paragraph that lays claim to all of URI syntaxes. It was written before there was a concrete proposal for URNs. I think the URL syntax RFC would be quite complete _without_ this paragraph. The URL syntax is going to face its own battles as the issues of character sets and languages are brought up -- it seems like now is a logical time to separate out the evolution of these two things, _unless_ there are some very concrete things that will break if they are not kept consistent. Cheers! Leslie. -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA15029 for urn-ietf-out; Wed, 18 Dec 1996 13:23:05 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA15010; Wed, 18 Dec 1996 13:22:21 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03878 (mail destined for urn-ietf@services.bunyip.com); Wed, 18 Dec 96 13:22:06 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <02348-0@josef.ifi.unizh.ch>; Wed, 18 Dec 1996 19:21:07 +0100 Date: Wed, 18 Dec 1996 19:21:06 +0100 (MET) From: "Martin J. Duerst" To: Ryan Moats Cc: uri@bunyip.com, urn-ietf@bunyip.com Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes... In-Reply-To: <32B80993.5785@ds.internic.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Wed, 18 Dec 1996, Ryan Moats wrote: > Folks- > > I was reminded this morning that there is a potential inconsistency > between the URL and URN syntax specifications > (draft-fielding-url-syntax-02.txt and draft-ietf-urn-syntax-01.txt). > Because of this, I am cross-posting this to both lists, so I apologize > to those folks that will see this multiple times (I know I will...) I have noticed this inconsistency, too, and am glad Ryan brought it up. > The inconsistency arises from the following: > > In the URL syntax draft the following statement is made: > > > 1.1. URL, URN, and URI > > > > URLs are a subset of Uniform Resource Identifiers (URI), which also > > includes the notion of Uniform Resource Names (URN). A URN differs > > from a URL in that it identifies a resource in a location-independent > > fashion (see RFC 1737, [10]). URNs are defined by a separate set of > > specifications. > > > > Although this specification restricts its discussion to URLs, the > > syntax defined is that of URI in general. Any requirements placed on > > the URL syntax also apply to the URI syntax. This uniform syntax for > > all resource identifiers allows a URN to be used in any data field > > that might otherwise hold a URL. > > However, in the latest draft URN syntax spec (circulating on the urn > mailing list), the syntax for a URN is > > > "urn:" ":" > > I don't beleive that the URN specification "can be used in any data > field that might otherwise hold a URL" as it currently stands (If > somebody thinks otherwise, please let me know). Therefore, either the > syntax specs need to be aligned or the statements about the URL > specification refering to the URI syntax need to be modulated > (neither of which are pleasant topics...). My current preference > is to modulate the URL syntax specification to support the URN syntax > and move forward. I think there is very much to be gained from URLs and URNs being syntactically alligned. Currenty, it looks to me as if this is the case; the "urn" part is a , and everything after that is scheme-specific. The greedy algorithm (Section 4.4) and the exclusion of ":" in schemes assures that this parsing will be done correctly. The treatment of reserved characters could cause some problems, however. To allow substitution of "%7E" by "~" (URL, 2.2/2.3.2) while that character is not available on many keyboards is problematic. Therefore, that aspect has to be reconsidered anyway. The URL draft also does not agree with the URN draft on i18n issues. I18N in URLs is a large topic, and I hope to get the time tomorrow to comment on its treatment in the URL draft. In the context of this thread, it is at least required that consequences in these differences are analysed/understood, and that there is language in the URL draft (given it is kept to be responsible for URIs in general) that the syntax alignement does not include these issues. This most probably should be done with a general statement explaining what exactly is covered, and what not, by "uniform syntax". Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA14475 for urn-ietf-out; Wed, 18 Dec 1996 12:38:10 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAB14470 for ; Wed, 18 Dec 1996 12:38:07 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03439 (mail destined for urn-ietf@services.bunyip.com); Wed, 18 Dec 96 12:38:04 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <00633-0@josef.ifi.unizh.ch>; Wed, 18 Dec 1996 18:37:38 +0100 Date: Wed, 18 Dec 1996 18:37:37 +0100 (MET) From: "Martin J. Duerst" To: marshall eubanks Cc: urn-ietf@bunyip.com Subject: [URN] Re: Re[2]: Article re San Jose IETF in Sunday San Francisco paper In-Reply-To: <"josef.ifi..634:18.11.96.17.15.27"@ifi.unizh.ch> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Wed, 18 Dec 1996, marshall eubanks wrote: > > Maybe URN's should include a check-sum or the like to make sure that > > it has been copied/typed correctly, much as crdit cards numbers, etc., > > do. This could even be in the URN label (as in, URN[XX]:yyyy, where > > XX is a 2 character ascii code based on the yyyy field). The web > > engine could then compare yyyy with XX and complain if they > > don't match. > > I was thinking here about the case where URN's could be very "cold." > If I get a URL from someone today, and it's wrong, I can generally > re-inquire, hunt around using search engines, etc. If I find a > URN in (say) a 2 year old mail message, it might be very nice to > know that it is typo free if it comes back as "not found." Credit > card numbers and the like include redundancy for exactly that reason. > A reasonable goal might be to be able to detect 2 character errors, > and to correct one character errors. As far as I understand URNs (I was mainly involved in their i18n aspects), their most important property is permanence. This means that if you have an URN that is "not found", by the virtue of knowing it being an URN, you know that it's misspelled. Another aspect of your proposal is that many namespaces, such as ISBN, already contain check-sums. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA14312 for urn-ietf-out; Wed, 18 Dec 1996 12:15:39 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA14307 for ; Wed, 18 Dec 1996 12:15:31 -0500 Received: from casa.usno.navy.mil by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA03187 (mail destined for urn-ietf@services.bunyip.com); Wed, 18 Dec 96 12:15:19 -0500 Message-Id: <9612181715.AA03187@mocha.bunyip.com> Received: by CasA.usno.navy.mil (1.37.109.16/16.2) id AA184529177; Wed, 18 Dec 1996 12:12:57 -0500 Date: Wed, 18 Dec 1996 12:12:57 -0500 From: marshall eubanks To: mduerst@ifi.unizh.ch, urn-ietf@bunyip.com Subject: [URN] Re[2]: Article re San Jose IETF in Sunday San Francisco paper Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: marshall eubanks Errors-To: owner-urn-ietf@bunyip.com I sent the following to the general IETF list, not the URN list, by mistake. It concerns an idea I had after the problems that various people had with a URL given in a mail message to the IETF : > Maybe URN's should include a check-sum or the like to make sure that > it has been copied/typed correctly, much as crdit cards numbers, etc., > do. This could even be in the URN label (as in, URN[XX]:yyyy, where > XX is a 2 character ascii code based on the yyyy field). The web > engine could then compare yyyy with XX and complain if they > don't match. I was thinking here about the case where URN's could be very "cold." If I get a URL from someone today, and it's wrong, I can generally re-inquire, hunt around using search engines, etc. If I find a URN in (say) a 2 year old mail message, it might be very nice to know that it is typo free if it comes back as "not found." Credit card numbers and the like include redundancy for exactly that reason. A reasonable goal might be to be able to detect 2 character errors, and to correct one character errors. Regards Marshall Eubanks tme@casa.usno.navy.mil Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA13410 for urn-ietf-out; Wed, 18 Dec 1996 11:04:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA13402; Wed, 18 Dec 1996 11:04:47 -0500 Received: from sdgmail.ncsa.uiuc.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA02444 (mail destined for uri@services.bunyip.com); Wed, 18 Dec 96 11:04:41 -0500 Received: from void.ncsa.uiuc.edu (void [141.142.103.20]) by ncsa.uiuc.edu (8.8.2/8.8.2) with ESMTP id KAA01432; Wed, 18 Dec 1996 10:03:59 -0600 (CST) From: Daniel LaLiberte Received: (from liberte@localhost) by void.ncsa.uiuc.edu (8.8.2/8.8.2) id JAA04091; Wed, 18 Dec 1996 09:59:50 -0600 (CST) Date: Wed, 18 Dec 1996 09:59:50 -0600 (CST) Message-Id: <199612181559.JAA04091@void.ncsa.uiuc.edu> To: Ryan Moats Cc: uri@bunyip.com, urn-ietf@bunyip.com Subject: [URN] Potential inconsistency between URL and URN syntaxes... In-Reply-To: <32B80993.5785@ds.internic.net> References: <32B80993.5785@ds.internic.net> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Daniel LaLiberte Errors-To: owner-urn-ietf@bunyip.com Ryan Moats writes: > However, in the latest draft URN syntax spec (circulating on the urn > mailing list), the syntax for a URN is > > > "urn:" ":" > > I don't beleive that the URN specification "can be used in any data > field that might otherwise hold a URL" as it currently stands (If > somebody thinks otherwise, please let me know). I think otherwise. I don't see anything wrong with this syntax - consider that the scheme name for this whole class of URNs is called "urn", and thus "urn:" preceeds the rest of the identifier. You were not specific about what the nature of the conflict is. If "urn:" were optional (which is a subject still open for debate, I presume), we may have a conflict. The general URI syntax allows the ":" prefix to be optional, and more of the prefix can be left out, but then we might have a relative URI, which has different semantics. With no "urn:", the would actually function as the scheme name since it indicates how to interpret the . But this is true even with a required "urn:" prefix since we want URNs to be independent of the resolution mechanism. I'm not clear whether you believe URNs *should* be used in any data field that might otherwise hold a URL, independent of whether they in fact can. I believe they should. -- Daniel LaLiberte (liberte@ncsa.uiuc.edu) National Center for Supercomputing Applications http://union.ncsa.uiuc.edu/~liberte/ Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA12709 for urn-ietf-out; Wed, 18 Dec 1996 10:12:47 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA12704; Wed, 18 Dec 1996 10:12:44 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA01880 (mail destined for uri@services.bunyip.com); Wed, 18 Dec 96 10:12:42 -0500 Received: by privateer.windrose.omaha.ne.us; Wed Dec 18 09:11 CST 1996 Message-Id: <32B80993.5785@ds.internic.net> Date: Wed, 18 Dec 1996 09:11:15 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: uri@bunyip.com Cc: urn-ietf@bunyip.com Subject: [URN] Potential inconsistency between URL and URN syntaxes... Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Folks- I was reminded this morning that there is a potential inconsistency between the URL and URN syntax specifications (draft-fielding-url-syntax-02.txt and draft-ietf-urn-syntax-01.txt). Because of this, I am cross-posting this to both lists, so I apologize to those folks that will see this multiple times (I know I will...) The inconsistency arises from the following: In the URL syntax draft the following statement is made: > 1.1. URL, URN, and URI > > URLs are a subset of Uniform Resource Identifiers (URI), which also > includes the notion of Uniform Resource Names (URN). A URN differs > from a URL in that it identifies a resource in a location-independent > fashion (see RFC 1737, [10]). URNs are defined by a separate set of > specifications. > > Although this specification restricts its discussion to URLs, the > syntax defined is that of URI in general. Any requirements placed on > the URL syntax also apply to the URI syntax. This uniform syntax for > all resource identifiers allows a URN to be used in any data field > that might otherwise hold a URL. However, in the latest draft URN syntax spec (circulating on the urn mailing list), the syntax for a URN is > "urn:" ":" I don't beleive that the URN specification "can be used in any data field that might otherwise hold a URL" as it currently stands (If somebody thinks otherwise, please let me know). Therefore, either the syntax specs need to be aligned or the statements about the URL specification refering to the URI syntax need to be modulated (neither of which are pleasant topics...). My current preference is to modulate the URL syntax specification to support the URN syntax and move forward. Ryan Moats InterNIC Directory and Database Services Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA17646 for urn-ietf-out; Mon, 16 Dec 1996 16:50:54 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA17641 for ; Mon, 16 Dec 1996 16:50:48 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA13020 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 16:48:58 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id QAA02687; Mon, 16 Dec 1996 16:48:57 -0500 Message-Id: <199612162148.QAA02687@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Mon, 16 Dec 1996 16:48:57 -0500 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: urn-ietf@bunyip.com Subject: [URN] DRAFT URN Meeting Minutes Cc: jcurran@bbn.com Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Well, rather than tearing apart case insensivity for a while longer, here's some more material to play with! These are the draft meeting minutes that Sally Hambridge put together for us (thanks Sally!). Overall, I think the meeting was quite successful, in that we covered several drafts, made a plan for what to do next, and seem to be making quite reasonable progress. I would appreciate corrections/comments from people who attended the meeting -- I intend to send the minutes in on Friday this week. Additionally, comments on the content (whether or not you made it to the meeting) are also welcomed. Cheers! Leslie. ================== Draft Minutes of the URN Working Group 37th IETF, San Jose, December 12, 1996 Group Co-Chairs: Leslie Daigle, leslie@bunyip.com John Curran, jcurran@bbn.com Minute-Meister: Sally Hambridge, Intel Leslie opened the meeting by reviewing the Charter and Milestones. Hot Spots in the milestones are: we lack a draft detailing N2L/N2R/etc resolution results. We will probably use Ron Daniel's HTTP conventions draft as a start on this milestone. We also need to submit a document describing one new namespace and a document which describes grandfathering in older naming schemes, as well as the Frameworks and Requirements draft. Karen Sollins presented the open issues with the current Frameworks and Requirements document: The document discusses the assumptions of longevity, delegation, and independence. The requirements fall in 3 major areas: Evolution, Usability, and Security. The framework looks like this: URN: | | Global NID registry | | | | | Private URN resolution service UDS server | | Private URN resolution service Karen includes a definition section which defines Local Resolution service - what transforms URNs into access to resources; Hints - information that helps to access the information; UDS - URN Resolution Service Discovery Service - how to find the right URN resolution service; HFN - Human friendly names. The Security area will discuss access control on hints; server authenticity; Server distribution (a countermeasure on denial of service attacks) and Privacy - the users from resolution services and for publishers for their clients and publications lists. Issues: Encouragement of separation of URNs from semantics - Efficiency as a goal or a requirement is in several places (documents) which need to be aggregated. - Whether there is a useful distinction to be made between long- term and short-term hints - Acceptance by potential providers of UDS services. Karen asked what's missing from the list of issues: Internationalization (i18n) should be covered one way or another. Name space ID - needs to be in a document but probably not this document. Ryan Moats presented the issues with the URN syntax ID: URN: should this be optional. Please see the later discussion on this for the consensus. NID syntax: Why not use numbers and "-". No reason - Ryan will change the draft. There was a suggestion for following the RFC for URLs on this, but it was pointed out that this document is currently undergoing a revision. NID namespace will have case insensitivity and add %escaping. The NSS may be case sensitive. URN Character set adds/deletes: Add "%" to the allowed character set and add a list of characters NOT part of the set to the draft. %escaping: Will be allowed for escaping of reserved characters in addition to characters outside the URN character set; and allow for %HH escaping to use either upper or lower case. Where does a URN end? At the first non-URN character set character. Equivalency: Are things the same when they point to the same resource? (Equivalency of resources was deemed to be a rathole). Leslie offered that a URN could point to a specific day's weather and another could refer to today's weather, and these were pointing to the same thing but were not equivalent. ROUGH CONSENSUS was reached that ONLY lexical equivalency will be covered in the draft. The namespace will have strict rules. For the Human readability - MUST/SHOULD the following text is being substituted: Any namespace (existing or newly-devised) that is proposed as a URN-namespace must be expressed in this syntax. If names in these namespaces contain characters other than those defined for the URN character set they must be translated into canonical form as discussed in section 2.2 Ron Daniel discussed the NAPTR draft. - There will be verbiage to state that records with unknown flags must be ignored. - The Pseudo-code has to go. - "R" Flag for treating Regex as "Raw" - Don't do "E" flag for encrypting Raw fields. Flag field reserves 0-9 for experimentation. The TFLag allows you to look for the same domain as I. ROUGH CONSENSUS was to allow people to create new flags however they want, but that if you see a flag you don't recognize you ignore it. There was a question of the references to other drafts, and John Curran said he would find out if the text RFC xxx could be written and if the RFC editor would insert the correct numbers. This draft will be going as an Experimental RFC. There was discussion about how the experimental status will effect DNS and the regex substitutions. We need to be explicit. We need to say how this doesn't overload DNS and how DNS security will help and where it won't. Also, there will probably be more than one discover service in the future and we don't want this one to be "The Standard". We need operational experience. The requiring resolution problem is not part of this draft. We will have one more revision on the mailing list, then this goes to Experimental. HTTP Conventions: Ron took this one too. - We need a simple resolver for testing, the goal is not Standards track. The goal is to use the conventions on encoding on requests and responses on http: GET /uri-res// HTTP 1.0 He will include % encoding, status codes, Accept: headers and other stuff from HTTP as appropriate. This allows cgi scripts to get names from files or directories, although they look ugly. Open Discussion: URN: There was a question of rough consensus on the problem of whether to require urn:. The room seems to indicate that urn: should be required on any part of the urn that was shipped around the Internet. Whether or not implementors would use urn: was left up to them for their own local products, but in transmission the urn: would be required. The problem with urn: seems to be at the user interface and user services level. Don't confuse human friendly names with internal representation. Documents: We need a URN dereferencing document to discuss the resolution service and the resolution system. These need the syntax (which is close) and the system requirements needs the framework (which is also close.) Assign URN - needs everything! We need namespace requirements. We need to have one new namespace and we need to bring in 1 existing namespace. We need to pay some attention to potential lawsuit issue. It is important for someone who has authority for the namespace to say how it works in URN. The proposal is for these to be experimental. Dun and Bradstreet is interested in working on this as soon as the syntax is ready. Clifford Lynch said that the NISO bibliographic IDs could move en masse. We can create a resolution system which can be used outside the URN space, but we need to make it work there first. Charter directions: * We need to get a grip on bringing in an existing namespace * We need a new namespace scheme * We need the Name space requirements document (to see whether DNS will or won't work) * We need to bring all the requirements from all sources into one place * We need to look at the process of creating new namespaces -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA17490 for urn-ietf-out; Mon, 16 Dec 1996 16:32:07 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA17485 for ; Mon, 16 Dec 1996 16:32:04 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12871 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 16:32:02 -0500 Received: by privateer.windrose.omaha.ne.us; Mon Dec 16 15:31 CST 1996 Message-Id: <32B5BF94.10A2@ds.internic.net> Date: Mon, 16 Dec 1996 15:31:00 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: "Martin J. Duerst" Cc: urn-ietf@bunyip.com, tows@earthlink.net Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com Martin J. Duerst wrote: > > On Mon, 16 Dec 1996 jayhawk@windrose.omaha.ne.us wrote: > > > > >5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping > > > >are case insensitive. > > > Why is the NSS case sensitive? Most people are used to URL's which > > > are case insensitive. There would be a lot of confusion with people > > > ignoring caps, as well as allowing someone to take an NSS which is > > > identicle to another except for capitalization. (I think there was a > > > similar issue recently with URL's and the three letter classification.) > > > > I disagree that all URLs are case insensitive. Portions are, but then again, > > some portions aren't. > > See my example with a file name. In general, only the DNS part is > case insensitive. User id may be, may be not, password certainly > not, hierarchical part (filenames) certainly not, query part certainly > not. This makes URLs case sensitive: If you don't know the details > you better make sure you got it the right way, or it may point into > the void. This example works for me... > > Going back into my email archives (not as thorough as Bunyip's, but easier > > to get at, the syntax draft has always allowed individual namespaces to > > declare themselves as having a case-insensitive NSS, > > Is that mentionned specifically, or is it just due to the fact that > NSSs can declare any two names to be functionally equivalent? Yes. In section 5, the quote is "Some namespaces may define additional lexical equivalences, such as case-insensitivity of the NSS (or parts thereof)." Ryan P.S. I forgot where I was for my previous message, so please ignore that To: header. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA17428 for urn-ietf-out; Mon, 16 Dec 1996 16:27:33 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA17423 for ; Mon, 16 Dec 1996 16:27:30 -0500 Received: from mintaka.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12847 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 16:27:26 -0500 Received: from skadhwe.lcs.mit.edu by MINTAKA.LCS.MIT.EDU id aa15475; 16 Dec 96 16:26 EST Received: by skadhwe.lcs.mit.edu; (5.65v3.2/1.1.8.2/15Aug95-0306PM) id AA04046; Mon, 16 Dec 1996 16:26:53 -0500 Date: Mon, 16 Dec 1996 16:26:53 -0500 Message-Id: <9612162126.AA04046@skadhwe.lcs.mit.edu> From: Lewis Girod To: leslie@bunyip.com Cc: tows@earthlink.net, jayhawk@ds.internic.net, urn-ietf@bunyip.com In-Reply-To: <199612162102.QAA02633@beethoven.bunyip.com> (leslie@bunyip.com) Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Lewis Girod Errors-To: owner-urn-ietf@bunyip.com From: leslie@bunyip.com (Leslie Daigle) Date: Mon, 16 Dec 1996 16:02:28 -0500 There might be a better wording for this to suggest that the NSS is expected to be transported and interpreted literally. ... and that each namespace defines any relevant notions of lexical equivalence. Using NAPTR, this equivalence function is implemented within the regexps -- basically two different URNs generate the same domain name to look up. This may be used to express case insensitivity, as well as more complex equivalence functions. Also, since escaped characters are a syntax that applies to all NSS's, we can specify the hex characters encoding escaped characters to be case insensitive. - Lewis Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA17295 for urn-ietf-out; Mon, 16 Dec 1996 16:18:57 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA17290 for ; Mon, 16 Dec 1996 16:18:55 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12763 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 16:18:48 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <29093-0@josef.ifi.unizh.ch>; Mon, 16 Dec 1996 22:18:31 +0100 Date: Mon, 16 Dec 1996 22:18:30 +0100 (MET) From: "Martin J. Duerst" To: jayhawk@windrose.omaha.ne.us Cc: urn-ietf@bunyip.com, tows@earthlink.net Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: <9612162043.AA12260@mocha.bunyip.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Mon, 16 Dec 1996 jayhawk@windrose.omaha.ne.us wrote: > > >5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping > > >are case insensitive. > > Why is the NSS case sensitive? Most people are used to URL's which > > are case insensitive. There would be a lot of confusion with people > > ignoring caps, as well as allowing someone to take an NSS which is > > identicle to another except for capitalization. (I think there was a > > similar issue recently with URL's and the three letter classification.) > > I disagree that all URLs are case insensitive. Portions are, but then again, > some portions aren't. See my example with a file name. In general, only the DNS part is case insensitive. User id may be, may be not, password certainly not, hierarchical part (filenames) certainly not, query part certainly not. This makes URLs case sensitive: If you don't know the details you better make sure you got it the right way, or it may point into the void. > Going back into my email archives (not as thorough as Bunyip's, but easier > to get at, the syntax draft has always allowed individual namespaces to > declare themselves as having a case-insensitive NSS, Is that mentionned specifically, or is it just due to the fact that NSSs can declare any two names to be functionally equivalent? >but that is not the > default. Further, there was some discussion that case-insensitivity would > have strange effects in the international arena (Martin, maybe you > can clarify this some more?) First, we would have to make sure that case-insensitivity also applies to accented characters, and to Greek, Cyrillic, and Armenian. Second, the question of whether to extend insensitivity to things similar, but not equivalent to case would come up (e.g. katakana and hiragana in Japanese). This is an actual point of discussion for SGML :-(. Third, casing can be different depending on language. The Turkish dotless I is the famous example. Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA16937 for urn-ietf-out; Mon, 16 Dec 1996 16:02:34 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA16932 for ; Mon, 16 Dec 1996 16:02:32 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12577 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 16:02:31 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id QAA02633; Mon, 16 Dec 1996 16:02:30 -0500 Message-Id: <199612162102.QAA02633@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Mon, 16 Dec 1996 16:02:28 -0500 In-Reply-To: Towsner's message as of Dec 16, 14:59 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Towsner , Ryan Moats , urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com [Henry Towsner wrote:] > Why is the NSS case sensitive? Most people are used to URL's which > are case insensitive. There would be a lot of confusion with people > ignoring caps, as well as allowing someone to take an NSS which is > identicle to another except for capitalization. (I think there was a > similar issue recently with URL's and the three letter classification.) Don't forget that we are trying to architect something that will not preclude the incorporation of existing namespaces -- and many of those _are_ case sensitive. Also, "case sensitivity" is poorly defined when it comes to non-7-bit characters and non-English languages. There might be a better wording for this to suggest that the NSS is expected to be transported and interpreted literally. Leslie. -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA16854 for urn-ietf-out; Mon, 16 Dec 1996 15:57:27 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA16849 for ; Mon, 16 Dec 1996 15:57:23 -0500 Received: from proxy1.ba.best.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12480 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 15:57:09 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy1.ba.best.com (8.8.4/8.8.3) with SMTP id MAA06541; Mon, 16 Dec 1996 12:45:26 -0800 (PST) Date: Mon, 16 Dec 1996 12:45:26 -0800 (PST) From: "Gregory J. Woodhouse" To: Towsner Cc: Ryan Moats , urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: Message-Id: X-Url: http://www.wnetc.com/ Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Gregory J. Woodhouse" Errors-To: owner-urn-ietf@bunyip.com The NSS should be case sensitive. Think about URLs. The following are not equivalent: http://wherever.org/Folder/ http://wherever.org/folder/ I don't think case sensitivity in the NSS wil be any gret surprise with URNs. (Then again, I've never been much of a fan of case insensitivity, anyway.) --- gjw@wnetc.com / http://www.wnetc.com/home.html If you're going to reinvent the wheel, at least try to come to come up with a better one. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA16508 for urn-ietf-out; Mon, 16 Dec 1996 15:43:45 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA16497 for ; Mon, 16 Dec 1996 15:43:41 -0500 From: jayhawk@windrose.omaha.ne.us Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12260 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 15:43:35 -0500 Message-Id: <9612162043.AA12260@mocha.bunyip.com> Date: Mon, 16 Dec 96 14:42 CST To: urn-ietf@bunyip.com, tows@earthlink.net Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt X-Sun-Charset: US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: jayhawk@windrose.omaha.ne.us Errors-To: owner-urn-ietf@bunyip.com > >5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping > >are case insensitive. > Why is the NSS case sensitive? Most people are used to URL's which > are case insensitive. There would be a lot of confusion with people > ignoring caps, as well as allowing someone to take an NSS which is > identicle to another except for capitalization. (I think there was a > similar issue recently with URL's and the three letter classification.) I disagree that all URLs are case insensitive. Portions are, but then again, some portions aren't. Going back into my email archives (not as thorough as Bunyip's, but easier to get at, the syntax draft has always allowed individual namespaces to declare themselves as having a case-insensitive NSS, but that is not the default. Further, there was some discussion that case-insensitivity would have strange effects in the international arena (Martin, maybe you can clarify this some more?) Ryan Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id PAA16428 for urn-ietf-out; Mon, 16 Dec 1996 15:32:53 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id PAA16423 for ; Mon, 16 Dec 1996 15:32:51 -0500 Received: from josef.ifi.unizh.ch by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA12146 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 15:32:47 -0500 Received: from enoshima.ifi.unizh.ch by josef.ifi.unizh.ch with SMTP (PP) id <26999-0@josef.ifi.unizh.ch>; Mon, 16 Dec 1996 21:31:45 +0100 Date: Mon, 16 Dec 1996 21:31:43 +0100 (MET) From: "Martin J. Duerst" To: Towsner Cc: Ryan Moats , urn-ietf@bunyip.com Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: "Martin J. Duerst" Errors-To: owner-urn-ietf@bunyip.com On Mon, 16 Dec 1996, Towsner wrote: > >5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping > >are case insensitive. > Why is the NSS case sensitive? Most people are used to URL's which > are case insensitive. Looks like you are living on an MS-DOS box, or an IBM mainframe. Otherwise, create two files, just differing in captitalization, and try what you get with a file: URL. In case you file system is capitalizationwise challenged, and you still have difficulties believing me, I can set up two such files in our ftp directory :-). Regards, Martin. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id OAA16099 for urn-ietf-out; Mon, 16 Dec 1996 14:54:16 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id OAA16094 for ; Mon, 16 Dec 1996 14:54:15 -0500 Received: from denmark-c.it.earthlink.net by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA11518 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 14:54:09 -0500 Received: from [153.35.79.47] (Cust47.Max20.Boston.MA.MS.UU.NET [153.35.79.47]) by denmark.it.earthlink.net (8.7.5/8.7.3) with ESMTP id LAA18456; Mon, 16 Dec 1996 11:53:47 -0800 (PST) X-Sender: tows@mail.earthlink.net Message-Id: In-Reply-To: <32B56D9D.7B96@ds.internic.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 16 Dec 1996 14:59:21 -0500 To: Ryan Moats , urn-ietf@bunyip.com From: Towsner Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Towsner Errors-To: owner-urn-ietf@bunyip.com >5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping >are case insensitive. Why is the NSS case sensitive? Most people are used to URL's which are case insensitive. There would be a lot of confusion with people ignoring caps, as well as allowing someone to take an NSS which is identicle to another except for capitalization. (I think there was a similar issue recently with URL's and the three letter classification.) -- -Henry Towsner Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id KAA13366 for urn-ietf-out; Mon, 16 Dec 1996 10:42:59 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id KAA13361 for ; Mon, 16 Dec 1996 10:42:55 -0500 Received: from windrose.omaha.ne.us by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA09436 (mail destined for urn-ietf@services.bunyip.com); Mon, 16 Dec 96 10:42:43 -0500 Received: by privateer.windrose.omaha.ne.us; Mon Dec 16 09:41 CST 1996 Message-Id: <32B56D9D.7B96@ds.internic.net> Date: Mon, 16 Dec 1996 09:41:17 -0600 From: Ryan Moats Organization: InterNIC Directory and Database Services X-Mailer: Mozilla 3.0 (X11; I; SunOS 5.5 sun4c) Mime-Version: 1.0 To: urn-ietf@bunyip.com Subject: [URN] Pre-release of draft-ietf-urn-syntax-02.txt Content-Type: multipart/mixed; boundary="------------4648506075BE" Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ryan Moats Errors-To: owner-urn-ietf@bunyip.com This is a multi-part message in MIME format. --------------4648506075BE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Folks- Apologies for jumping any traditional post-IETF "quiet time", but I would really like to try and move the syntax draft closer to draft standard. Attached is a pre-release of version -02. We managed to reach rough consensus on the open issues raised during the URN working group meeting, and so I've changed the syntax draft to note these agreements. I'm now looking for rough consensus from those folks on the mailing list that were not in San Jose. Ryan -----------Changes from the release draft are (in no particular order): 1. Various editing changes, and I've probably missed some, including cleaning up the modified BNF grammar. 2. The tag "urn:" is now required. There were several folks at San Jose that said that the absence of this tag would break things, while there was no one that said that the presence of this tag would break things. If someone has a situation were the presence will BREAK things (not just be inconvient) let the mailing list know! 3. The NID now allows letters and numbers. 4. The equivalence section only talks about lexical equivalence. Functional equivalence is namespace specific and is outside the scope of this document. 5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping are case insensitive. 6. "%" has been added to the URN character set. An explicit list of all octets not part of the URN character set has also been added (the "excluded character set". A URN ends with an octet that is part of the excluded character set. 7. "%"escaping is now allowed for reserved characters as well as characters not in the URN char set. 8. The two paragraphs in section 3 have been replaced with Leslie's suggestion to the mailing list. --------------4648506075BE Content-Type: text/plain; charset=us-ascii; name="urn.syntax.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="urn.syntax.txt" Internet-Draft Ryan Moats draft-ietf-urn-syntax-02.txt AT&T Expires in six months December 1996 URN Syntax Filename: draft-ietf-urn-syntax-02.txt Status of This Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers. This document sets forward the canonical syntax for URNs. Support for both existing legacy and new namespaces is discussed. Requirements for URN presentation and transmission are presented. Finally, there is a discussion of URN equivalence and how to determine it. 1. Introduction Uniform Resource Names (URNs) are intended to serve as persistent resource identifiers and are designed to make it easy to map other namespaces (which share the properties of URNs) into URN-space. The URN syntax therefore provides a means to encode character data in a form that can be sent in existing protocols, transcribed on most keyboards, etc. Expires 5/19/97 [Page 1] INTERNET DRAFT URN Syntax December 1996 2. Syntax All URNs have the following syntax: ::= "urn:" ":" is the Namespace Identifier, and is the Namespace Specific String. The leading case-insensitive "urn:" sequence is required. The Namespace ID is used to determine the _syntactic_ interpretation of the Namespace Specific String (as discussed in [1]). RFC 1737 [2] presents additional requirements on URN encoding, which all have implications as far as limiting syntax. On the other hand, the requirement to support existing legacy naming systems has the effect of broadening syntax. Thus, we discuss the acceptable syntax for both the Namespace Identifier and the Namespace Specific String separately. 2.1 Namespace Identifier Syntax The following is the syntax for the Namespace Identifier. To (a) be consistent with all potential resolution schemes and (b) not put any undue constraints on any potential resolution scheme, the syntax for the Namespace Identifier is: ::= [ * ] ::= | | | "-" ::= | | ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z" ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | "y" | "z" ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" This is slightly more restrictive that what is stated in RFC 1738 [3] Expires 5/19/97 [Page 2] INTERNET DRAFT URN Syntax December 1996 (which allows the period "."). Further, the Namespace Identifier is case insensitive, so that "ISBN" and "isbn" refer to the same namespace. To avoid confusion with the "urn:" identifier, the NID "urn" is reserved and MUST NOT be used. 2.2 Namespace Specific String Syntax As required by 1737, there is a single canonical representation of the NSS portion of an URN. The format of this single canonical form follows: ::= * ::= | "%" ::= | | | ::= | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b" | "c" | "d" | "e" | "f" ::= "(" | ")" | "+" | "\" | "," | "-" | "." | "/" | ":" | "=" | "?" | "@" | "%" Depending on the rules governing a namespace, valid identifiers in a namespace might contain characters that are not members of the URN character set above (). Such strings MUST be translated into canonical NSS format before using them as protocol elements or otherwise passing them on to other applications. Translation is done by encoding each character outside the URN character set as a sequence of one to six octets using UTF-8 encoding, and the encoding of each of those octets as "%" followed by two characters from the character set above. The two characters give the hexadecimal representation of that octet. Namespaces MAY designate one or more characters from the URN character set as having special meaning for that namespace (An example of this is the "%" character in the URN syntax itself). If the namespace also uses that character in a literal sense as well, the character used in a literal sense MUST be encoded with "%" followed by the hexadecimal representation of that octet. Therefore, the process of registering a namespace identifier shall include publication of a definition of which characters have a special meaning and how to encode these characters if used in a literal sense. Expires 5/19/97 [Page 3] INTERNET DRAFT URN Syntax December 1996 2.3 Excluded characters The following list is included only for the sake of completeness. Any octets/characters on this list are explicitly NOT part of the URN character set, and if used in a URN, MUST be %encoded: ::= octets 0-32 (0-20 hex) | "!" | """ | "#" | "$" | "&" | "'" | "*" | ";" | "<" | ">" | "[" | "]" | "^" | "_" | "`" | "{" | "|" | "}" | "~" | octets 127-255 (7F-FF hex) A URN ends when an octet/character from the excluded character set () is encountered. The character from the excluded character set is NOT part of the URN. 3. Support of existing legacy naming systems and new naming systems Any namespace (existing or newly-devised) that is proposed as a URN- namespace and fulfills the criteria of URN-namespaces MUST be expressed in this syntax. If names in these namespaces contain characters other than those defined for the URN character set, they MUST be translated into canonical form as discussed in section 2.2. 4. URN presentation and transport URN-aware applications MAY support "natural" display of URNs which contain characters encoded using "%" notation. However, they MUST provide for display of URNs in canonical form (i.e. in a format suitable for transcription). URNs MUST be transported in canonical format. 5. Lexical Equivalence in URNs For various purposes, such as caching, it is necessary to determine equivalence without actually resolving the URN. This done by testing for "lexical equivalence". Two URNs are lexically equivalent if they are octet-by-octet equal after the following preprocessing 1. normalize the case of the leading "urn:" token 2. normalize the case of the NID 3. normalizing the case of any "%" escaping Some namespaces may define additional lexical equivalences, such as case-insensitivity of the NSS (or parts thereof). Additional lexical equivalences MUST be documented as part of namespace registration, MUST always have the effect of eliminating some of the false negatives obtained by the procedure above, and MUST NEVER says that two URNs are not equivalent if the procedure above says they are equivalent. Expires 5/19/97 [Page 4] INTERNET DRAFT URN Syntax December 1996 6. Functional Equivalence in URNs Resolvers determine functional equivalence based on specific rules for the namespace. Therefore, namespace registration MUST include documentation on how to determine functional equivalence for that namespace. 7. Examples of equivalence The following URN comparisons highlight the difference between these types of equivalence: urn:isbn:1-23485-8-29, isbn:1-23485-8-29 are lexically equiv. urn:isbn:1-23485-8-29, ISBN:1-23485-8-29 are lexically equiv. urn:isbn:1-23485-8-29, isbn:123485829 are not lexically equiv. but may be functionally equivalent. 8. Security considerations This document specifies the syntax for URNs. While some namespaces resolvers may assign special meaning to certain of the characters of the Namespace Specific String, any security consideration resulting from such assignment are outside the scope of this document. It is strongly recommended that the process of registering a namespace identifier include any such considerations. 9. Acknowledgments Thanks to various members of the URN working group and <> for comments on earlier drafts of this document. This document is partially supported by the National Science Foundation. 10. References Request For Comments (RFC) and Internet Draft documents are available from and numerous mirror sites. [1] L. L. Daigle, P. Faltstrom, R. Iannella. "A Frame- work for the Assignment and Resolution of Uniform Resource Names," Internet Draft (work in progress). June 1996. [2] K. Sollins, L. Masinter. "Functional Requirements for Uniform Resource Names," RFC 1737. December 1994. Expires 5/19/97 [Page 5] INTERNET DRAFT URN Syntax December 1996 [3] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform Resource Locators (URL)," RFC 1738. December 1994. 11. Editor's address Ryan Moats AT&T 15621 Drexel Circle Omaha, NE 68135-2358 USA Phone: +1 402 894-9456 EMail: jayhawk@ds.internic.net This Internet Draft expires May 19, 1997. Expires 5/19/97 [Page 6] --------------4648506075BE-- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id BAA11110 for urn-ietf-out; Fri, 13 Dec 1996 01:24:45 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id BAA11105 for ; Fri, 13 Dec 1996 01:24:42 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA27540 (mail destined for urn-ietf@services.bunyip.com); Fri, 13 Dec 96 01:24:40 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id BAA01372 for urn-ietf@bunyip.com; Fri, 13 Dec 1996 01:24:40 -0500 Message-Id: <199612130624.BAA01372@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Fri, 13 Dec 1996 01:24:39 -0500 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: urn-ietf@bunyip.com Subject: [URN] URN WG Meeting -- summary Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com There was a URN WG meeting today (Dec 12/96) at the San Jose IETF. A brief summary of that session is attached -- minutes will follow in the next few days. .... The URN WG session included a discussion of the 4 current Internet drafts that we have (in generic terms, URN Discovery System Requirements & Framework, URN Syntax, NAPTR, and HTTP Conventions for URN Resolution). A few issues were identified with each document, and consensus was felt on most of them. Therefore, URN Syntax, NAPTR and HTTP Conventions will go through one more quick editing phase before being circulated on the mailing list and (barring further issues) submitted for consideration as RFCs. The System Requirements document is younger and will be restructured before calling for discussion on particular items. Volunteers were sought and obtained for tackling the URN Namespace Requirements document, and also proposed namespaces for grandfathering. To everyone's amazement, we accomplished this with the minimum of discussion and were done in 1 1/2 hours. Hurrah! Leslie. -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id MAA19810 for urn-ietf-out; Fri, 6 Dec 1996 12:39:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id MAA19770 for ; Fri, 6 Dec 1996 12:39:44 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19984 (mail destined for urn-ietf@services.bunyip.com); Fri, 6 Dec 96 12:39:37 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id KAA14507 for ; Fri, 6 Dec 1996 10:39:35 -0700 (MST) Message-Id: <2.2.32.19961206174827.00707594@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 06 Dec 1996 10:48:27 -0700 To: urn-ietf@bunyip.com From: Ron Daniel Subject: [URN] comments on Sollins' requirements draft Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Hi all, Some notes w.r.t. Karen Sollins' recent draft on URN Resolution Requirements and Framework. This is a little long, but maybe you can read it on the flight to San Jose. For those who have not yet learned how to sleep on flights, this should cure you of *that* problem. :-) ==== Notes on Conformance of the NAPTR Proposal to URN Resolution Requirements Karen Sollins has recently issued the first draft of a requirements document for URN Resolution Services. To provide feedback to her for subsequent versions of that draft, I have tried to document how the NAPTR resolution proposal does or does not meet those requirements. I'll confess to being a little ...difficult... :-) and deliberately taking advantage of what I perceived to be ambiguities in the requirements. This accounts for the "NAPTR is the greatest thing in the world" tone of much of my responses. The point is to try to push on the requirements as hard as possible to see where they might be weaker than desired. Where I have knowingly done so I have made an attempt at honesty by including a notes section that explains what I think is the real intent of the requirement and how NAPTR would or would not meet it. The notes section may also contain critiques of the requirement in general. General Comments: ================= I think Karen has done something good by noting that we have resolver discovery services (her UDS acronym) as opposed to resolvers. I would like to see the requirements made more explicit on which sort of service they apply to. The draft collects the requirements into summaries at the end of each section. That was found very useful and my comments key off of the summaries. I have added some numbers on the requirements to make it easier to refer to particular ones. I would like to see the draft use a numbering scheme. I found it confusing on pg. 6 where one paragraph starts off "Lastly..." and the next paragraph starts off "Second, ...". Requirements on Evolution (sec. 3.1) (3.1.1.a) Support for a growing set of URN schemes ================================================== The NAPTR proposal supports growth in the number of URN schemes (namespaces). New namespaces, X, may be added to X.urn.net and rules for their resolution established. (3.1.1.b) Support for new local URN resolution schemes ====================================================== The NAPTR proposal directly supports the evolution of URN resolution schemes through the "services" field in the NAPTR record. Multiple NAPTR records may be associated with a namespace to handle the period of transition from one resolution protocol to another. Notes: I was unclear on the use of the term "local" in the summary statement of the requirement. It did not appear in the narrative explanation of the requirement. The requirement is ambiguous. I can, I think, reasonably interpret it as I did in the answer above. However, I believe that Karen's intent was that there be an evolutionary path away from the NAPTR UDS approach itself, not just the resolver protocols "discovered" by the NAPTR approach. Assuming that was Karen's intent, I still think NAPTR meets the requirement. My intent is that NAPTR resolution be used as a fallback approach when a client does not have a specific handler for a namespace or URL protocol. This allows alternate resolution mechanisms to be used on a namespace by namespace basis. When a replacement UDS for NAPTR arises, there is no difficulty in making it the resolver of last resort instead of NAPTR, and in configuring clients so they only use NAPTR for namespaces not yet serviced by the new UDS. (3.1.1.c) Support for new authentication schemes: ================================================= The authentication schemes supported by the individual resolution protocols are outside the bounds of the NAPTR spec. The NAPTR UDS itself can utilize the recent DNSSEC work to build authentication mechanisms when desired. Any authentication needs not addressable through the DNSSEC framework can be addressed by defining a new DNS resource record, or by using a special convention on existing records such as TXT. Notes: The narrative for this requirement was not especially helpful. While the previous two requirements had narratives that could be shortened, this one needs some more explanation. (3.1.1.d) Support for alternative UDS schemes active simultaneously =================================================================== The notes for 3.1.1.b explain how NAPTR does not preclude alternative UDS schemes and shows one way in which a client can use multiple UDS schemes at the same time. (3.1.2) Support and encourage the evolution toward the separation of global identification from short-lived, locally useful, or human friendly semantics ======================================================================== The NAPTR proposal supports the resolution of identifiers from namespaces without the visible inclusion of resolution-system-specific hints such as domain names. Notes: "Support" is OK, but the "and encourage" is a bit much. Terry Allen has already commented on how this requirements document goes well beyond the URN Requirements document in terms of deprecating human- friendly names. I agree with he and Stu - we should take no position on the friendliness of names. If they can be made unique, persistent, and location-independent, that should be good enough for us. The narrative never makes a clear statement of the requirement. It only appears in the summary. (3.1.3) To support the development and deployment of pricing models to manage human behavior with respect to limited resources. ====================================================================== The NAPTR proposal allows fee-for-resolution systems to be deployed using the access controls on resolvers. The details of such controls are outside the bounds of the NAPTR spec. New namespces will almost certainly incurr the $50/yr. domain name registration fee. Notes: This requirement is *far* too strong. Prices are not the only way to control user behavior, assuming it needs to be controlled. This requirement should say nothing stronger than resolvers not precluding the possibility of payment being one of many possible controls on access to resolution info. 3.2 Usability and Feature Set Requirements 3.2.1 (The publisher) (3.2.1.a) URN to hint resolution must be correct and efficient ============================================================== The NAPTR proposal supports the efficient location of resolvers because of the highly caching nature of DNS. Correctness of that information is provided by the normal operation of DNS. In cases demanding unusually high guarrantees of correctness, the recent DNSSEC work can be used to provide signatures on the NAPTR responses. Efficiency of the resolvers themselves is outside the bounds of the NAPTR spec, but the NAPTR spec does help in making efficient resolution possible since it allows reslovers to be replicated through the use of the SRV record. Notes: We have no definition of "efficient" and "inefficient" so it is impossible to evaluate conformance to this requirement on an objective basis. I'll engage in subjective arguments with the best of 'em. You need an objective criteria to which you can point and say "put up or shut up". (3.2.1.b) Publishers must be able to select among URN resolution services to locate their resources ========================================================================= NAPTR directly supports this requirement through the use of the "services" field and multiple NAPTR records. Notes: The narrative goes beyond the requirement summary and says that the selection must be easy. How do we quantify that? The narrative also imposes a requirement not in the summary, that changing resolution services SHOULD NOT be expensive for the publisher. What is and is not expensive? (Adding a new NAPTR record is not, in itself, an expensive operation. What kind of fees might be imposed are impossible for the spec to address). (3.2.1.c) Publishers must be able to arrange for multiple access points for their location information. ======================================================================= The NAPTR proposal supports multiple resolvers through the SRV record. Notes: The narrative and the summary are quite different. The summary says "location information" while the narrative talks about "resources". The narrative also says services SHOULD be prepared to tailor responses based on the entity making the query and uses local caches as an example. The NAPTR proposal can accomodate these as well. Multiple locations for resources is handled by the resolvers, but the details are outside the bounds of the NAPTR spec. Tailored responses are also a resolver problem, but can be handled using existing technology. (3.2.1.d) Publishers must be able to provide for both long-lived and short-lived hints ================================================================ The NAPTR proposal allows for hint lifetime to be communicated using DNS TTLs, or resolution-method-specific lifetime information. (e.g. HTTP Expires: headers). Notes: The requirement seems to assume that a distinction must be drawn between short-term and long-term hints. I do not see this as being necessary. Is it not more important that publishers be able to communicate the expected lifetime of a hint and we not impose some artificial short/long distinction? Why not short/medium/long or really-really-really short//////etc. (3.2.1.e) It must be relatively easy for publishers to install and observer [sic] their hint information and any security constraints they need for their hints. ================================================================== The NAPTR proposal meets this requirement. (well, I blush a *little* when I say that, but I digress). Hint information held on resolvers is outside the bounds of the NAPTR proposal, but we expect that the hint information on resolvers will be held in databases that can be maintained using normal practice. Access to those databases will be through particular resolution protocols. Maintaining and monitoring the security imposed by those resolution protocols is outside the bounds of the NAPTR spec, and outside the bounds of the resolution protocol specs as well. The hint information within the bounds of the NAPTR spec are the NAPTR resource records used to find resolvers. That information is relatively small and is expected to not change frequently. Editing zone files is not the job of the publisher, but of the managment, so we will get to that part of the requirement later I'm sure. Monitoring the correct provision of information can be easily achieved, either through the use of nslookup or through the use of ultra-friendly front ends around nslookup. (Recent work on dynamic update will make the construction of ultra-friendly front ends possible so direct zone file editing can be avoided). Notes: "relatively easy" is not quantifiable. Therefore, I don't blush *too* much when I say that editing a zone file meets the requirement. Isn't installation of hint info a requirement for the resolver managers, not the publishers? publishers should be able to provide the necessary info about new resources to the management, but they don't need to install the hints themselves. (3.2.2) Client requirements Generic note - it took awhile for me to figure out that "client" meant "user-agent", not "user". A change in terminology might be nice. (3.2.2.a) The interface to the UDS must be simple, effective, and efficient. ============================================================================ The current NAPTR library has a simple, effective, and efficient interface. Notes: (OK, OK, proof by assertion is not a recognized logical technique. :-) The API for out NAPTR library is pretty simple, init_resolution() and get_next_resolver(). However, that API is outside the bounds of the NAPTR spec. Any number of APIs could be developed that provide access to the information from the NAPTR records. As I have been told repeatedly in other contexts, the IETF rarely standardizes APIs. In this case I think that is certianly the right policy, because I don't think we know enough about the space of possible UDS systems to develop an API that will work with all of them in a useful fashion. If we are not going to standardize an API, I don't think we should be setting requirements on them. (3.2.2.b) The client and client applications must be able to understand the information stored in and provided by the UDS, in order to be able to make informed choices. ======================================================================== The NAPTR proposal supports this requirement, since the results coming back clearly indicate the services offered by a resolver and the protocol necessary to communicate with the resolver. Notes: Shouldn't this really be a requirement on the resolvers rather than the UDS? The HTTP Conventions approach would still meet it since results are tagged with media types. The last paragraph in the section on client requirements does not state any requirements and might be moved to the assumptions section. (3.2.2.c) I would add a requirement that the info returned from the UDS to the client (and the resolver to the client) must be capable of evolving over time without the wholesale replacement of the UDS or resolution protocol. (3.2.3) Management requirements (3.2.3.a) The managment of hints must be as unobtrusive as possible, avoiding using too many network resources. ===================================================================== Managing hints in NAPTR records is local to the zone containing that record and is therefore unobtrusive. Notes: this seems kind of vague (3.2.3.b) A pricing scheme may be necessary to provide not only cost recovery, but also social incentives and disincentives to encourage certain sorts of behavior deemed necessary to meet other requirements. ====================================================================== I've already addressed this in 3.1.3, haven't I? Notes: This is not a well-stated requirement. How about "resolution service providers may use pricing schemes or other means of access control"? I still think you are pushing too hard for pricing. It is a policy issue, and the technical issues for UDS requirments are not to preclude it. (3.2.3.c) The configuration and verification of configuration of individual UDS servers must be simple enough not to discourage configuration and verification. ================================================================ It is possible to configure and verify NAPTR resource record information. Notes: How can I evaluate conformance to this requirement? My friends and I can write NAPTR records and we can use our debug client to make sure we get to the machine we think we are going to get to. Is that good enough? The last sentence of the narrative for this requirement imposes another requirement - one that I urge you to remove. The sentance says: "[...] encouraging volunteer participants REQUIRES that, as with the DNS, such volunteers can feel confident about the service they are providing and its benefit to both themselves and the rest of the community". How can we evaluate conformance to such a requirement? (3.3) Security and Privacy requirements Oh boy. While there are other parts of the draft I don't like, I find chunks of this section unacceptable. The requirements in this section have the implicit effect of mandating a security policy across all URN resolvers and UDS'. This policy will be too strong for some sites and too weak for others. My most vociferous objection is to the last sentence of the first paragraph: "Therefore we believe that the benefit of providing integrity guarantees beyond those provided by the servers themselves does not outweight the cost". You can't make that decision for me! There are people at my site who are *very* interested in integrity guarantees. I know because I have talked to them. Whether they will remain interested once they see the true cost is for *them* to decide. This requirements document has no business requiring or precluding any security measures. What it must do is operate under the assumption that there is some site out there with NO security, and that vicious hackers have totally had their way with that site. It must then be possible for sites that wish to be totally paranoid about security to resolve a URN to the resource in such a fashion that they can 1) Be assured that it has not been compromised or 2) Be able to determine that at least one of the steps in the resolution process can not be guranteed to be safe, and that any use of the resource is at their own risk. That is all that can be done. Any attempt to mandate that all sites obey some minimal level of security is flawed. Its an instance of the "everyone is my friend" assumption. This implicit establishment of the security policy that must be obeyed by URN resolvers shows up in several other places. There are many sentences where you say that something "must" exist which I would like to change to saying "must be capable of supporting". For example you say that "There needs to be an authoritative version of each hint, and it must support change control limited only to those principals with the right to modify it". I would prefer a different wording: "Each resolution hint shall have an authoritative instance. It must be possible to restrict changes to the authoritative hint according to the security policy of the organization issuing the hint. Propagation of changes to the authoritative version to any sites mirroring it must be capable of being carried out in a fashion consistent with the security policy governing the operation of the mirroring service." (Actually, I would prefer something less awkward, but I digress. :-) Its not that the former is hard to achieve, requiring root access to edit a zone file meets the letter of the requirement. The problem is that it precludes certain modes of operation. You and I may think that those modes of operation are only for idiots, but we are not the ones making the cost/benefit calculations. I also disagree with some of your threat analysis. For example, you are concerned about packet sniffers violating user's privacy and state that it can be "combatted by anonymizing queries through a trusted, fairly local gateway, although it involves an extra step and another potential bottleneck". This becomes the requirement "Client privacy is threatened by packet sniffing and server logging. It is desirable to reduce these threats as much as possible". The most likely scenario for snooping involves an employer monitoring employee's traffic for appropriate use. So, the people most likely to run the "anonymizing gateway" are the ones most likely to be analyzing the requests. (I can point to at least one example of an organization that monitors HTTP requests and does random sampling of incoming GIFs for obvious reasons). Your requirement stating that it is desirable to reduce such threats takes a position counter to the U.S. legal precedent that employers have the right to do such monitoring. That is one reason I keep harping on not mandating a security policy. Whose side should we take on such an issue? Anyway, since this message is already so long, and since I disagree so strongly with the security requirements, I'm going to stop here. We can iterate on the requirements a few times. Regards, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id NAA04535 for urn-ietf-out; Wed, 4 Dec 1996 13:52:19 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id NAA04530 for ; Wed, 4 Dec 1996 13:52:17 -0500 Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA00439 (mail destined for urn-ietf@services.bunyip.com); Wed, 4 Dec 96 13:52:14 -0500 Received: from legiron.acl.lanl.gov (legiron.acl.lanl.gov [128.165.147.188]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id LAA08669 for ; Wed, 4 Dec 1996 11:52:08 -0700 (MST) Message-Id: <2.2.32.19961204190058.006f1218@acl.lanl.gov> X-Sender: rdaniel@acl.lanl.gov X-Mailer: Windows Eudora Pro Version 2.2 (32) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 04 Dec 1996 12:00:58 -0700 To: urn-ietf@bunyip.com From: Ron Daniel Subject: [URN] FPIs as a URN Namespace Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Ron Daniel Errors-To: owner-urn-ietf@bunyip.com Hi, At the Montreal BOF, I suggested FPIs (ISO Formal Public Identifiers) as one of the namespaces that would be of interest for grandfathering into the URN world. Recently I've started working on just how to accomplish such a feat. Although I am not ready to issue an internet draft of the subject, people may want to take a look at some notes I've put together on the topic. They are at http://www.acl.lanl.gov/URN/FPI-URN.html If time allows we may discuss this at the WG meeting next week. Later, Ron Daniel Jr. email: rdaniel@lanl.gov Advanced Computing Lab voice: +1 505 665 0597 MS B287 fax: +1 505 665 4939 Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/ Los Alamos, NM, USA 87545 obscure_term: "hyponym" Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id EAA21212 for urn-ietf-out; Wed, 4 Dec 1996 04:46:01 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id EAA21199 for ; Wed, 4 Dec 1996 04:45:58 -0500 Received: from aun.uninett.no by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA19000 (mail destined for urn-ietf@services.bunyip.com); Wed, 4 Dec 96 04:45:55 -0500 Received: from dale.uninett.no (actually MACFAY.terena.nl) by aun.uninett.no with SMTP (PP); Wed, 4 Dec 1996 10:45:22 +0100 Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.12) with ESMTP id XAA03644; Tue, 3 Dec 1996 23:25:52 +0100 From: Harald.T.Alvestrand@uninett.no To: Ron Daniel Cc: urn-ietf@bunyip.com Subject: Re: [URN] some more NAPTR edits In-Reply-To: Your message of "Wed, 27 Nov 1996 13:18:25 MST." <2.2.32.19961127201825.00d31a90@acl.lanl.gov> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <3640.849651951.1@dale.uninett.no> Date: Tue, 03 Dec 1996 23:25:51 +0100 Message-Id: <3642.849651951@dale.uninett.no> Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Harald.T.Alvestrand@uninett.no Errors-To: owner-urn-ietf@bunyip.com Ron, I think encrypted NAPTR records are a Bad Idea. The reason is that I can't figure out where to put the information about which key to use. You may have to specify that the key is identified by the replacement field, with the raw data in the regexp field, in which case the semantics is different from "R", and you might as well make E exclusive with R. or something else......key handling is the bane of encryption systems. Harald A Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA08087 for urn-ietf-out; Tue, 3 Dec 1996 17:43:50 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA08082 for ; Tue, 3 Dec 1996 17:43:48 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA05282 (mail destined for urn-ietf@services.bunyip.com); Tue, 3 Dec 96 17:43:47 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id RAA27946 for urn-ietf@bunyip.com; Tue, 3 Dec 1996 17:43:47 -0500 Message-Id: <199612032243.RAA27946@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Tue, 3 Dec 1996 17:43:46 -0500 In-Reply-To: Leslie Daigle's message as of Dec 3, 16:56 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: urn-ietf@bunyip.com Subject: Re: [URN] Getting ready for next week's meeting... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com Thanks to Ron for being eagle-eyed and catching the error -- he has been involved in many of the drafts, but not all of them! > . URN Framework and Requirements [Ron 15] This should, of course, be . URN Framework and Requirements [Karen 15] Leslie. -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA07707 for urn-ietf-out; Tue, 3 Dec 1996 16:56:29 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA07702 for ; Tue, 3 Dec 1996 16:56:26 -0500 Received: from beethoven.Bunyip.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA04665 (mail destined for urn-ietf@services.bunyip.com); Tue, 3 Dec 96 16:56:25 -0500 Received: (leslie@localhost) by beethoven.bunyip.com (8.6.9/8.6.10) id QAA27889 for urn-ietf@bunyip.com; Tue, 3 Dec 1996 16:56:24 -0500 Message-Id: <199612032156.QAA27889@beethoven.bunyip.com> From: leslie@bunyip.com (Leslie Daigle) Date: Tue, 3 Dec 1996 16:56:24 -0500 X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: urn-ietf@bunyip.com Subject: [URN] Getting ready for next week's meeting... Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: leslie@bunyip.com (Leslie Daigle) Errors-To: owner-urn-ietf@bunyip.com As some of the draft-editors have been asking about length of timeslots on the agenda for next week's meeting, it seems a good time to propose a refined view of that agenda and a Plan. The refined view (with time assignments) is attached. The basic plan is to give everybody air time to discuss issues with individual drafts. Of course, since all attendees WILL have read the drafts (:-) I am asking that draft-editors focus on preparing themselves for _issues_, and not use their valuable time for reviewing material that should already be familiar. What I propose, then, is that each draft-editor arrive prepared with: . a _very_ brief overview of the draft . a list of known issues with the draft . a list of proposed solutions to those issues (if any) . a sense of humour What I think we can walk away from the meeting with is: . some proposed solutions to issues . a (hopefully finite) list of issues that remain to be addressed with each draft . a plan for addressing the remainder of our chartered work (i.e., documents, volunteers :-) In order to make this all work smoothly, I suggest that, if you have issues-as-yet-unaired with a particular draft, rather than harbouring them until next week's meeting and springing them on unsuspecting editors, how about at least listing them now? (on the mailing list, or to the editors directly). There isn't a lot of time at the meeting, so if we can use it for solid discussion instead of trying to reach understanding over terminolory in describing issues, that would be great. For starters, let me know if there are any comments on the proposed agenda... Cheers! Leslie. ---------------------------------------- IETF URN Working Group ---------------------------------------- Agenda for Thursday, December 12, 1996 (9h00-11h30), San Jose, California. Status review: [10 minutes] . Status of documents . Progress on WG milestones Discussion of document-specific issues: [90 minutes] . URN Framework and Requirements [Ron 15] . URN Syntax [Ryan 15] . NAPTR proposal [Ron and/or Michael 15] . HTTP conventions [Ron 15] . General issues across drafts/flex time [30] Where to go from here: [30 minutes] . other issues . addressing remaining documents -- ---------------------------------------------------------------------------- "_Be_ Leslie Daigle where you Vice President, Research _are_." Bunyip Information Systems (514) 875-8611 -- ThinkingCat leslie@bunyip.com ---------------------------------------------------------------------------- Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA10226 for urn-ietf-out; Sun, 1 Dec 1996 11:32:29 -0500 Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA10217 for ; Sun, 1 Dec 1996 11:32:26 -0500 Received: from loki.fsc.fujitsu.com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b) id AA17202 (mail destined for urn-ietf@services.bunyip.com); Sun, 1 Dec 96 11:32:23 -0500 Received: from ishtar.fsc.fujitsu.com (ishtar [192.240.3.45]) by loki.fsc.fujitsu.com (8.7.5/8.6.11) with ESMTP id IAA08428 for ; Sun, 1 Dec 1996 08:30:40 -0800 (PST) Received: (from tallen@localhost) by ishtar.fsc.fujitsu.com (8.7.5/8.6.11) id IAA20816 for urn-ietf@bunyip.com; Sun, 1 Dec 1996 08:31:01 -0800 (PST) Date: Sun, 1 Dec 1996 08:31:01 -0800 (PST) From: Terry Allen Message-Id: <199612011631.IAA20816@ishtar.fsc.fujitsu.com> To: urn-ietf@bunyip.com Subject: [URN] Compliance in Framework draft Sender: owner-urn-ietf@services.bunyip.com Precedence: bulk Reply-To: Terry Allen Errors-To: owner-urn-ietf@bunyip.com This message is about compliance requirements as stated in the framework draft. I think compliance requirements, clearly stated, are a good thing. Compliance is mentioned several times, most notably in the two sections excerpted below (it would be good to have a distinct section specifically on compliance): | Abstract: | | This document addresses the issues of the discovery of local URN | resolution services that in turn will directly translate URNs into | URLs and URCs. The document falls into three major parts, the | assumptions underlying the work, the requirements in order to be a | viable URN-resolution-service discovery service or UDS, and a | framework for designing UDSs. The requirements fall into three major | areas: evolvability, usability, and security and privacy. A UDS that | is compliant with the framework will not necessarily be compliant with | the requirements. Compliance with the requirements will need to be | validated separately. [ ... ] | 4. The Framework | | With these assumptions and requirements in mind, one can conclude with a | general framework within which UDS designs will fall. As stated | earlier, although this framework is put forth as a suggested guide for | UDS designers, compliance with it will in no way guarantee compliance | with the requirements. Such an evaluation must be performed separately. | It is also understood that there may be UDS services that do not meet | the requirements in clearly identified ways. This may be true | especially with early plans and experiments. For example, although a | careful threat analysis may have been done to understand security | requirements, not all those security requirements may be addressed, in | order to use existing facilities to allow for early deployment for | experimentation purposes. All such lack of compliance should be clearly | documented. It emerges from these sections that those offering UDSs should document lack of compliance with the requirements, which I take to be the bulletted items listed in extract form at the end of this message. Let's think about the requirements in the light of this compliance requirement. How is a vendor to make meaningful comment on the following (a short selection): | * To support the development and deployment of pricing models to | manage human behavior with respect to limited resources. | e) It must be relatively easy for publishers to install and | observer their hint information and any security constraints | they need for their hints. | a) The management of hints must be as unobtrusive as possible, | avoiding using too many network resources; | * Broad availability of servers will reduce the thread to denial | of service; Can I as a client or user expect to obtain useful information wrt those points from a vendor's documentation? I'd expect no more than "yeah, we can do that" and "sure, our system is relatively easy and unobtrusive". When you think of it this way, does it not appear that many of the requirements are desiderata for a well functioning Internet in general, and need not be listed among the requirements for UDSs specifically? EXCERPTED LIST OF REQUIREMENTS | 3. Requirements [ ... ] | 3.1 Evolution [ ... ] | In summary, the requirements in the area of evolvability are: | | * To support evolution of mechanisms, specifically for | a) a growing set of URN schemes; | b) new local URN resolution schemes; | c) new authentication schemes; | d) alternative UDS schemes active simultaneously; | * To support and encourage the evolution toward the separation of | global identification from short-lived, locally useful, or human | friendly semantics; | * To support the development and deployment of pricing models to | manage human behavior with respect to limited resources. | | 3.2 Usability and Feature Set Requirements [ ... ] | To summarize, the usability requirements fall into three areas based on | participation in hint management and discovery: | | * The publisher | a) URN to hint resolution must be correct and efficient; | b) Publishers must be able to select among URN resolution | services to locate their resources; | c) Publishers must be able to arrange for multiple access points | for their location information; | d) Publishers must be able to provide for both long-lived and | short-lived hints; | e) It must be relatively easy for publishers to install and | observer their hint information and any security constraints | they need for their hints. | * The client | a) The interface to the UDS must be simple, effective, and | efficient; | b) The client and client applications must be able to understand | the information stored in and provided by the UDS, in order | to be able to make informed choices. | * The management | a) The management of hints must be as unobtrusive as possible, | avoiding using too many network resources; | b) A pricing scheme may be necessary to provide not only cost | recovery, but also social incentives and disincentives to | encourage certain sorts of behavior deemed necessary to meet | other requirements; | c) The configuration and verification of configuration of | individual UDS servers must be simple enough not to | discourage configuration and verification. | | 3.3 Security and Privacy Requirements [ ... ] | trusts it not to be compromised. We can turn each of these into a | security goal. | | * ACCESS CONTROL ON HINTS: There needs to be an authoritative version of | each hint, and it must support change control limited only to those | principals with the right to modify it. The choice of who those | principals are or whether they are unlimited must be made by the | publisher of a hint. | | * SERVER AUTHENTICITY: Servers and clients must be able to learn the | identity of the servers with which they communicate. This will be a | matter of degree and it is possible that there will be more | trustworthy, but less accessible servers, supported by a larger | cluster of less authenticatable servers that are more widely | available. In the worst case, if the client receives what appears to | be invalid information, the client should assume that the hint may be | inaccurate and confirmation of the data should be sought from more | reliable but less accessible data. | | * SERVER DISTRIBUTION: Broad availability will provide resistance to | denial of service. It is only to the extent that the services are | available that they provide any degree of trustworthiness. In | addition, the distribution of services will reduce to vulnerability | of the whole community, by reducing the trust put in any single | server. This must be mitigated by the fact that to the extent trust | is based on a linked set of servers, if any one fails, the whole | chain of trust fails; the more elements there are in such a chain, | the more vulnerable it may become. [ ... ] | In summary, security and privacy requirements can be identified as some | degree of protection from threats: | | * It must be possible to create authoritative versions of a hint | with access to modification privileges controlled; | * It must be possible to determine the identity of servers or avoid | contact with unauthenticated servers; | * Broad availability of servers will reduce the thread to denial | of service; | * Client privacy is threatened by packet sniffing and server | logging. It is desirable to reduce these threats as much as | possible; | * It should be feasible for publishers to keep private certain | information such as an overall picture of the resources they are | publishing and the identity of their clients; | * Publishers should be able to restrict access to the resolution of | the URNs for the resources they publish, if they wish. Regards,