From owner-urn-ietf@LISTS.NETSOL.COM Wed Aug 7 08:08:09 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14342 for ; Wed, 7 Aug 2002 08:08:09 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA16134; Wed, 7 Aug 2002 08:06:29 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 62309 for URN-IETF@LISTS.NETSOL.COM; Wed, 7 Aug 2002 08:02:59 -0400 Received: from ger5.wwwserver.net ([212.162.54.34]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id IAA16105 for ; Wed, 7 Aug 2002 08:02:57 -0400 (EDT) Received: from philo.de (p3E9D04F6.dip0.t-ipconnect.de [62.157.4.246]) by ger5.wwwserver.net (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id NAA13783 for ; Wed, 7 Aug 2002 13:56:37 +0200 Apparently-To: @lists.netsol.com. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: de,en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.netsol.com id IAA16106 Approved-By: Dieter =?iso-8859-1?Q?K=F6hler?= Message-ID: <3D510AF1.6F2FA78E@philo.de> Date: Wed, 7 Aug 2002 13:56:33 +0200 Reply-To: Dieter =?iso-8859-1?Q?K=F6hler?= From: Dieter =?iso-8859-1?Q?K=F6hler?= Subject: URN syntax: . URNs and URIs To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 8bit Section 2.3.1 of RFC 2141 states: "The presence of an "%" character in an URN MUST be followed by two characters from the character set." However, this requirement is not met by the syntax notation: ::= 1* ::= | "%" ::= | | | | ::= '%" | "/" | "?" | "#" It should rather read: ::= 1* ::= | ::= | | | | ::= "/" | "?" | "#" ::= "%" I think it would be important to clarify this in a update RFC, because if only following the formal syntax given in 2141 URNs are not conforming to the URI specification as described in RFC 2396. A related issue is that RFC 2141 does not explicitly explain its relation to RFC 2396. I guess the intention was that URNs form a class which is a subset of the URI class. Dieter Köhler, M.A. Institute of Philosophy University of Karlsruhe Germany From owner-urn-ietf@LISTS.NETSOL.COM Wed Aug 7 10:34:59 2002 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20609 for ; Wed, 7 Aug 2002 10:34:59 -0400 (EDT) Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA17323; Wed, 7 Aug 2002 10:33:38 -0400 (EDT) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 62459 for URN-IETF@LISTS.NETSOL.COM; Wed, 7 Aug 2002 10:30:52 -0400 Received: from ger5.wwwserver.net ([212.162.54.34]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA17307 for ; Wed, 7 Aug 2002 10:30:50 -0400 (EDT) Received: from philo.de (p3E9D04EF.dip0.t-ipconnect.de [62.157.4.239]) by ger5.wwwserver.net (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) with ESMTP id QAA20895 for ; Wed, 7 Aug 2002 16:24:38 +0200 Apparently-To: @lists.netsol.com. X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: de,en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------8425DABC3C7FF77B8283C4CC" Approved-By: Dieter =?iso-8859-1?Q?K=F6hler?= Message-ID: <3D512DA3.75EA89C7@philo.de> Date: Wed, 7 Aug 2002 16:24:35 +0200 Reply-To: Dieter =?iso-8859-1?Q?K=F6hler?= From: Dieter =?iso-8859-1?Q?K=F6hler?= Subject: URN Namespace for Hierarchical Object Designators To: URN-IETF@LISTS.NETSOL.COM This is a multi-part message in MIME format. --------------8425DABC3C7FF77B8283C4CC Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable About one year ago I sent the proposal of what I called a "URN Namespace = for Structured Object Designators" to this list (see "http://lists.netsol.com/cgi-bin/wa?A2=3Dind0107&L=3Durn-ietf&D=3D1&T=3D0= &O=3DD&F=3D&S=3D&P=3D52"). = Meanwhile I revised this proposal and called it: "URN Namespace for Hiera= rchical Object Designators (HOD) 1.0". I still wonder whether it is an appropria= te candidate for an URN namespace at all or should instead be specified as a= new type of an URI. In particular RFC 1737 states about the relation of URNs= and URLs: "It is strongly recommended that there be a mapping between the nam= es generated by each naming authority and URLs." However, Hierarchical Obje= ct Designators do not require that the designated objects are identifiable b= y a network URL. They are especially designed for metadata to address object= s which are not digital resources. Any advice and comments on the new proposal are welcome! Dieter K=F6hler, M.A. Institute of Philosophy University of Karlsruhe Germany --------------8425DABC3C7FF77B8283C4CC Content-Type: text/plain; charset=iso-8859-1; name="hod.txt" Content-Disposition: inline; filename="hod.txt" Content-Transfer-Encoding: quoted-printable XXXXXXXXXXXXX Dieter Koehler Request for Comments: YYYY University of Karlsruhe Category: Standards Track August 2002 URN Namespace for Hierarchical Object Designators (HOD) 1.0 Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Abstract This document describes a Uniform Resource Name (URN) namespace = [RFC2141] for Hierarchical Object Designators (HODs). HODs are = intended to serve as reference pointers to structured objects. This = document sets forward the canonical syntax for HODs. 1. Introduction Hierarchical Object Designators (HODs) are intended to serve as = reference pointers to structured objects by using Uniform Resource Names (URNs) [RFC2141] within a HOD URN Namespace. = HODs are designed especially for dynamic linking of metadata about = complex objects in an open hypertext systems. These objects may = or may not be identifiable by a network URL. Examples for objects which are not identifiable by a network URL are physical or = abstract objects such as "London" or "The works of Plato". = However, such objects can be addressed in electronic hypertext = systems by a digital alias. This document defines the framework for hierarchical structured = reference systems for such objects, their parts, and different versions thereof. For example: "London in the year 1776", = "London - East End", "The beginning of Plato's Symposion", = "The additions of hand two to manuscript W of Plato's Symposion". If a reference system is defined according to this framework, the syntactical form of a reference allows an user agent to search = for related metadata not only based on the exact reference = provided, but also on proximity with regard to the reference system. For example: A search for metadata about "London in the year 1776" might also reveal proximity metadata about "England in the year 1776" or "London in the 1770s", or by using a widened scope: "Europe in the 18th century". 2. Namespace ID "hod" requested. 3. Registration Information Registration Version Number: 1.0 Registration Date: yyyy-mm-dd 4. Declared registrant of the namespace The HOD namespace is reserved by the IETF. 5. Terms and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", = "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in = this document are to be interpreted as described in [RFC2119]. 6. Syntax The following syntax definitions are given in Augmented = Backus-Naur Form (ABNF) according to [RFC2234]. = The URN syntax as described in [RFC2141] defines an URN as = URN =3D "urn:" NID ":" NSS where is the Namespace Identifier, and is the Namespace Specific String. = URNs in the HOD namespace can be identified by the following Namespace Identifier: NID =3D "hod" All Namespace Specific Strings in the HOD namespace have the = following syntax: NSS =3D versionNum ":" OSS versionNum =3D 1*( ALPHA / DIGIT / "_" / "." / "-" ) = OSS =3D authorityId ":" dateId reference authorityId =3D 1*( ALPHA / DIGIT / "." / "-" ) dateId =3D 8 ( DIGIT ) reference =3D "/" *1( div *( "/" div ) *1"/") div =3D divName *1( ";" *1(divVersion) ) ; = divName =3D 1*divChars ; divVersion =3D 1*divChars ; divChars =3D ALPHA / DIGIT / escape / other escape =3D "%" HEXDIG HEXDIG other =3D "(" / ")" / "+" / "," / "-" / "." / ":" / = "=3D" / "@" / "$" / "_" / "!" / "*" / "'" The indicates conformance of the Object Specific = String () to the labeled HOD namespace specification version. The version number "1.0" indicates conformance to this version of = this HOD namespace specification; the value "1.0" MUST NOT be = used if the URN does not conform to this version of this = specification. It is intended to give later versions of this = specification numbers other than "1.0", but this intent does not = indicate a commitment to produce any future versions of HOD, nor if any are produced, to use any particular numbering scheme. Since future versions are not ruled out, this construct is = provided as a means to allow the possibility of automatic version = recognition, should it become necessary. Processors SHOULD = signal an error if they receive URNs labeled with versions they = do not support. The MUST be an Internet domain name, and MUST be = owned by the organization creating the HOD reference system and = allocating the URN to it, at the date identified by the . is a date in [ISO8601] Basic Format (CCYYMMDD), and MUST = correspond to a date at which the organization allocating the = URN owned the domain name specified in the . The = "00000000" indicates an experimental HOD URN. No = provision is made for avoiding collision of experimental HOD = URNs; they are intended for use within internal or limited = experimental contexts. signifies a certain reference according to a = reference system defined by the authority with owned the domain = name specified in the . The used reference system is uniquely identified by the combination of and . 7. Basic Reference System Structure A reference consists of a sequence of division statements = separated by slash ("/"). The allowed values for these = divisions form a reference system. These divisions = represent nested structure levels beginning with the most = general and leading to the most specific. In other words: The possible divisions of a reference system form one or = more nested trees. = = Each division consists of a mandatory division name and an = optional division version indicator separated by semicolon (";"). If no division version indicator is given, the division name together with its parent divisions specify a certain object. If a division version indicator is given, = it indicates a certain version of the object specified by = the division name and its parent divisions. If only the semicolon, but no division version indicator is given, it refers to each of the individual versions of the object = specified by the division name and its parent divisions, = but not to the object as a whole. Division versions are local. Literal equivalence between = division versions indicates equivalent versions of an = object only under the same parent division. Equivalent = division versions occurring on different division levels = do not indicate the same global version. Resource system = specifications may introduce additional rules to define equivalence between literally different references. = The literal values of references indicate no specific order. Resource system specifications MAY introduce additional rules = for ordering references. = More than one reference system for the same objects MAY be = defined. However, it is out of the scope of this documentation to define a mechanism to identify references based on different reference systems designating them same designat. 8. Examples For the following examples it is assumed that a fictitious = authority owns the domain at <20010101> and is declaring under this authorityId and dateId a simple hod = namespace for bibliographic reference of the form = "author/book/chapter/paragraph". = (i) Thus = urn:hod:1.0:x-test.org:20010101/Adams/My%20Life/42/11 = is to be read as pointing to chapter 42, paragraph 11 of the book entitled "My Life" from an author named "Adams". If there exist two editions of this book, both could for example be distinguished by different division versions "A" and "B": = urn:hod:1.0:x-test.org:20010101/Adams/My%20Life;A/42/11 urn:hod:1.0:x-test.org:20010101/Adams/My%20Life;B/42/11 (ii) Note that these URNs do not necessarily mean the same as: urn:hod:1.0:x-test.org:20010101/Adams/My%20Life/42/11;A urn:hod:1.0:x-test.org:20010101/Adams/My%20Life/42/11;B This document makes no assumptions about the identity of literally identical division versions appearing on different division levels. However, authorities specifying a reference system are free to do so. (iii) Varying the above example the URN urn:hod:1.0:x-test.org:20010101/Adams/My%20Life is referring to all editions of Adams' book "My Life", while urn:hod:1.0:x-test.org:20010101/Adams/My%20Life;A is only referring to edition "A". = (iv) The hod namespace also provides means to distinguish = between e.g. a reference to the author "Adams" from a = reference to all of his works. To refer to the author = "Adams" the URN urn:hod:1.0:x-test.org:20010101/Adams can be used, while = urn:hod:1.0:x-test.org:20010101/Adams/ refers to all of his books (individually). However, it is up to the authority specifying a reference system to = exactly define the meaning of the first of these two = references, and so she might choose to treat it as a = shortcut for the second. = 9. Identifier uniqueness considerations The combination of AuthorityId and DateId serves to uniquely identify the organization that is allocating the URN. That organization is responsible for ensuring the uniqueness of the designator. 10. Identifier persistence considerations A HOD URN may only be allocated by an organization that owns an Internet domain name. The URN identifies a date on which the organization owned that domain name. The combination of date and domain name will serve to uniquely identify that organization for all time. 11. Process of identifier assignment The organization identified by the AuthorityId/DateId combination is responsible for allocating a designator that is unique among all those that it allocates with that DateId. 12. Process of identifier resolution HOD providers are responsible for clearly specifying the designat = of the designators, they define. Since HOD URNs are primarily = designed to identify abstract or physical objects HOD providers are responsible for the provision of a URN resolution service, if = any, only if there exists a canonical network resource of the = designat they have assigned with a HOD URN. 13. Rules for Lexical Equivalence Two HOD URNs are lexically equivalent if they are octet-by-octet = equal after the following preprocessing: 1. normalize the case of the leading "urn:hod:" token 2. normalize the case of the versionNum 3. normalize the case of the AuthorityId 4. normalizing the case of any %-escaping Note that %-escaping MUST NOT be removed. Some HOD providers may define additional lexical equivalencies, = such as case-insensitivity of the (or parts = thereof). Additional lexical equivalencies MUST be clearly documented, 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. 14. Dynamic linking of documents containing HOD URNs Defining rules for dynamic linking of documents containing HOD = URNs is out of the scope of this document. = 15. Conformance with URN Syntax No special considerations beyond the syntax herein described. 16. Validation mechanism Organizations that allocate HOD URNs are responsible for the provision of a URN validation service, if any, for URNs they have assigned with a valid AuthorityId/DateId combination. 17. Scope Global 18. Security considerations This document proposes means of encoding hierarchical object designators within the URN framework. This document does not = discuss resolution; thus questions of secure or authenticated = resolution mechanisms are out of scope. It does not address = means of validating the integrity or authenticating the = source or provenance of URNs that contain hierarchical object designators. 19. Acknowledgments ... 20. References [ISO8601] "Date Elements and Interchange Formats -- = Information Interchange -- Represantation = of Dates and Times", ed. International = Organization for Standardization (ISO), = ISO 8601, 2000-12-21. [RFC2119] Bradner, S., "Key words for use in RFCs to = Indicate Requirement Levels", RFC 2119, = 1997-03. = [RFC2141] Moats, R., "URN Syntax", RFC 2141, 1997-05. [RFC2234] Crocker, D. and P. Overell, "Augmented BNF = for Syntax Specifications: ABNF", RFC 2234, = 1997-11. 21. Author's Address Dieter Koehler Institut fuer Philosophie Universit=E4t Karlsruhe (TH) D-76128 Karlsruhe GERMANY --------------8425DABC3C7FF77B8283C4CC--