From owner-urn-ietf@LISTS.NETSOL.COM Thu Feb 1 22:21:04 2001 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18558 for ; Thu, 1 Feb 2001 22:21:04 -0500 (EST) 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 WAA28479; Thu, 1 Feb 2001 22:09:28 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8684354 for URN-IETF@LISTS.NETSOL.COM; Thu, 1 Feb 2001 22:08:35 -0500 Received: from astro.cs.utk.edu (ASTRO.CS.UTK.EDU [128.169.93.168]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id WAA28464 for ; Thu, 1 Feb 2001 22:08:30 -0500 (EST) Received: from astro.cs.utk.edu (LOCALHOST [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id WAA29921; Thu, 1 Feb 2001 22:02:23 -0500 (EST) X-URI: http://www.cs.utk.edu/~moore/ Approved-By: moore@CS.UTK.EDU Message-ID: <200102020302.WAA29921@astro.cs.utk.edu> Date: Thu, 1 Feb 2001 22:02:23 -0500 Reply-To: Keith Moore From: Keith Moore Subject: Re: NID registration for NBN To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: Your message of "Wed, 31 Jan 2001 07:17:21 PST." <200101311517.HAA11009@orpheus.cs.sfu.ca> > Please forgive me if my enthusiasm for our current work > overflows sometimes into the realm of what some might call > 'advertizing.' Whereas the pessism of many with respect > to URN work is based partly on doubts about whether DDDS > resolution services will ever be deployed, we are excited > by the fact that the resolution technology we require is > already widely deployed world-wide. We also think our model > is the Right Thing for future bibliographic services: a > decentralized model that gives local libraries precedence > over publishers and global services and gives users > ultimate control to set their own bibliographic service > providers. there seems to be a misunderstanding here about the role of DDDS with respect to URNs. the assignment of URNs is independent of the resolution mechanism, and DDDS is only one possible resolution mechanism. decentralized lookup mechanisms in addition to DDDS are highly desirable, and the idea that users could choose their own bibliographic service providers was part of the justification for this design feature of URNs you should therefore feel completely free to design and deploy private resolution services for URNs. From owner-urn-ietf@LISTS.NETSOL.COM Wed Feb 7 07:57:50 2001 Received: from lists.netsol.com ([216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28678 for ; Wed, 7 Feb 2001 07:57:50 -0500 (EST) 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 HAA06659; Wed, 7 Feb 2001 07:44:58 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8686503 for URN-IETF@LISTS.NETSOL.COM; Wed, 7 Feb 2001 07:42:43 -0500 Received: from post.it.helsinki.fi (post.it.helsinki.fi [128.214.205.24]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA06640 for ; Wed, 7 Feb 2001 07:42:41 -0500 (EST) Received: from helsinki.fi (kvp110.lib.helsinki.fi [128.214.91.92]) by post.it.helsinki.fi (8.11.1/8.11.0-SPAMmers-sod-off) with ESMTP id f17CaaY31783; Wed, 7 Feb 2001 14:36:36 +0200 (EET) X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 References: <200101311517.HAA11009@orpheus.cs.sfu.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Juha Hakala Message-ID: <3A814154.6993E499@helsinki.fi> Date: Wed, 7 Feb 2001 14:36:36 +0200 Reply-To: Juha Hakala From: Juha Hakala Subject: Re: NID registration for NBN To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Rob, Although ISO 3166-1, 5th edition does not allow (or explicitly forbid) parallel usage of capital and small letters, I decided to be liberal in the NBN registration. There are two reasons for this: 1. According to RFC 2141, namespace ID and string "urn:" are case insensitive. If urn:nbn: equals URN:NBN: and all possible combinations of small and capital letters, it makes sense to stick to the same practice and allow both fi and FI. 2. The library community has an old practice of using small letters in country codes in our bibliographical databases. Insisting on "FI" only would be counterintuitive. Also, we have used small letters in URNs delivered since 1998. I would rather not change the practice by now. As far as I know, there are no NBN-based URN resolution services available yet. The largest on-going implementation project is in Norway; the national library will identify every item in their digital deposit with NBN-based URNs. They are currently digitising several terabytes of data every year. Best regards, Juha Rob Cameron wrote: > > Juha, > > With respect to the NBN document, I have one immediate concern > that you may wish to address in regard to the Rules for Lexical > Equivalence. Just as you state that x and X are equivalent > in the ISBN document (with the implication that X is canonical) > I believe that you should make a similar statement with respect > to the country code component of an NBN. Are "FI", "fi", "Fi" > and "fI" all legal and equivalent? Personally, I think it's > best to stick with ISO 3166 precisely and require "FI". > > This problem is an immediate concern to us in our implementation > of the NBN domain under the bibp: scheme as well. Even if you do > not wish to change the document, I would like to know your > thoughts on this. We want to make our bibp:NBN services > interoperate with any urn:NBN services that are developed. > > Are there any urn:NBN servers that are available at this time? > We would appreciate the opportunity to direct NBN requests > to them; we would also provide feedback on any interoperability > concerns that arise. > > On a general note, thanks for considering and responding on > my point with respect to resolution models. Our work with the > bibp: scheme will continue to pursue the decentralized model, > but I agree that there is no need to refer to this in the > urn:ISBN document. > > Please forgive me if my enthusiasm for our current work > overflows sometimes into the realm of what some might call > 'advertizing.' Whereas the pessism of many with respect > to URN work is based partly on doubts about whether DDDS > resolution services will ever be deployed, we are excited > by the fact that the resolution technology we require is > already widely deployed world-wide. We also think our model > is the Right Thing for future bibliographic services: a > decentralized model that gives local libraries precedence > over publishers and global services and gives users > ultimate control to set their own bibliographic service > providers. From owner-urn-ietf@LISTS.NETSOL.COM Sun Feb 11 16:35:24 2001 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12657 for ; Sun, 11 Feb 2001 16:35:23 -0500 (EST) 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 QAA12294; Sun, 11 Feb 2001 16:22:25 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8689541 for URN-IETF@LISTS.NETSOL.COM; Sun, 11 Feb 2001 16:21:33 -0500 Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id QAA12285 for ; Sun, 11 Feb 2001 16:21:31 -0500 (EST) Received: from thinkingcat.com ([64.229.215.57]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20010211211456.CMFV2541.tomts5-srv.bellnexxia.net@thinkingcat.com> for ; Sun, 11 Feb 2001 16:14:56 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------32A770A5621E8647BFD0C6DF" Approved-By: Leslie Daigle Message-ID: <3A87004C.6BAB4F34@thinkingcat.com> Date: Sun, 11 Feb 2001 16:12:44 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: New revision of RFC2611bis To: URN-IETF@LISTS.NETSOL.COM This is a multi-part message in MIME format. --------------32A770A5621E8647BFD0C6DF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Howdy, Attached is a revised version of the RFC2611 rewrite, per comments received. Dirk -- re. UTF8 vs. arbitrary escaped binary in URNs, your point still stands. Let's deal with that in internationalization, not here. I've removed the "US-ASCII" from the example. Martin -- have removed the duplicated "registrant" section in the example. Note that the example did not replace the template; the template was moved to an appendix. Have moved the illustration to an appendix as well. Keith -- have incorporated some of the points you made about desiderata for formal namespaces in that section. Apart from which, I . separated the "organization" and "contact" info in the declared registrant section of the template (per discussions on some NID registrations we've seen come by). . added context to the pointer to the IANA registration page. Leslie. -- ------------------------------------------------------------------- "Days used to be longer." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- --------------32A770A5621E8647BFD0C6DF Content-Type: text/plain; charset=iso-8859-1; name="draft-ietf-urn-rfc2611bis-01.txt" Content-Disposition: inline; filename="draft-ietf-urn-rfc2611bis-01.txt" Content-Transfer-Encoding: quoted-printable Internet-Draft L. Daigle URN WG Thinking Cat Enterprises Expires August 11, 2001 D. van Gulik Category: Best Current Practice WebWeaving draft-ietf-urn-rfc2611bis-01.txt R. Iannella IPR Systems P. Faltstrom Cisco February 11, 2001 URN Namespace Definition Mechanisms Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt Abstract The URN WG has defined a syntax for Uniform Resource Names (URNs) [RFC2141], as well as some proposed mechanisms for their resolution and use in Internet applications ([RFCXXXX], [RFCYYYY]). The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed ([RFC2288]), and this document lays out general definitions of and mechanisms for establishing URN "namespaces". This document obsoletes RFC2611. Discussion of this document should be directed to urn-ietf@ietf.org Daigle [Page 1] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 Table of Contents Abstract ........................................................ Table of Contents ............................................... 1.0 Introduction ................................................ 2.0 What is a URN Namespace? .................................... 3.0 URN Namespace (Registration) Types .......................... 3.1 Experimental Namespaces ..................................... 3.2 Informal Namespaces ......................................... 3.3 Formal Namespaces ........................................... 4.0 URN Namespace Registration, Update, and NID Assignment Process ..................................................... 4.1 Experimental ................................................ 4.2 Informal .................................................... 4.3 Formal ...................................................... 5.0 Security Considerations ..................................... 6.0 IANA Considerations ......................................... 7.0 References .................................................. 8.0 Authors' Addresses .......................................... 9.0 Appendix A -- URN Namespace Definition Template ............. 10.0 Appendix B -- Illustration ................................. 10.1 Example Template ........................................... 10.2 Registration steps in practice ............................. 1.0 Introduction Uniform Resource Names (URNs) are resource identifiers with the specific requirements for enabling location independent identification of a resource, as well as longevity of reference. There are 2 assumptions that are key to this document: Assumption #1: Assignment of a URN is a managed process. I.e., not all strings that conform to URN syntax are necessarily valid URNs. A URN is assigned according to the rules of a particular namespace (in terms of syntax, semantics, and process). Assumption #2: The space of URN namespaces is managed. I.e., not all syntactically correct URN namespaces (per the URN syntax definition) are valid URN namespaces. A URN namespace must have a recognized definition in order to be valid. The purpose of this document is to outline a mechanism and provide a Daigle [Page 2] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 template for explicit namespace definition, along with the mechanism for associating an identifier (called a "Namespace ID", or NID) which is registered with the Internet Assigned Numbers Authority, IANA. Note that this document restricts itself to the description of processes for the creation of URN namespaces. If "resolution" of any so-created URN identifiers is desired, a separate process of registration in a global NID directory, such as that provided by the DDDS system [RFCXXXX], is necessary. See [RFCYYYY] for information on obtaining registration in the DDDS global NID directory. 2.0 What is a URN Namespace? For the purposes of URNs, a "namespace" is a collection of uniquely- assigned identifiers. A URN namespace itself has an identifier in order to - ensure global uniqueness of URNs - (where desired) provide a cue for the structure of the identifier For example, ISBNs and ISSNs are both collections of identifiers used in the traditional publishing world; while there may be some number (or numbers) that is both a valid ISBN identifier and ISSN identifier, using different designators for the two collections ensures that no two URNs will be the same for different resources. The development of an identifier structure, and thereby a collection of identifiers, is a process that is inherently dependent on the requirements of the community defining the identifier, how they will be assigned, and the uses to which they will be put. All of these issues are specific to the individual community seeking to define a namespace (e.g., publishing community, association of booksellers, protocol developers, etc); they are beyond the scope of the IETF URN work. This document outlines the processes by which a collection of identifiers satisfying certain constraints (uniqueness of assignment, etc) can become a bona fide URN namespace by obtaining a NID. In a nutshell, a template for the definition of the namespace is completed for deposit with IANA, and a NID is assigned. The details of the process and possibilities for NID strings are outlined below; first, a template for the definition is provided. 3.0 URN Namespace (Registration) Types Daigle [Page 3] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 There are 3 categories of URN namespaces defined here, distinguished by expected level of service and required procedures for registration. Registration processes for each of these namespace types are given in Section 4.0. 3.1 Experimental Namespaces These are not explicitly registered with IANA. They take the form X- No provision is made for avoiding collision of experimental NIDs; they are intended for use within internal or limited experimental contexts. 3.2 Informal Namespaces These are fully fledged URN namespaces, with all the rights and requirements associated thereto. Informal namespaces can be registered in global registration services. They are required to uphold the general principles of a well-managed URN namespace -- providing persistent, unique identification of resources. Informal and formal namespaces (described below) differ in the NID assignment. IANA will assign an alphanumeric NID to registered informal namespaces, per the process outlined in Section 4.0. 3.3 Formal Namespaces A formal namespace may be requested, and IETF review sought, in cases where the publication of the NID proposal and the underlying namespace will provide benefit to an open and broad base of the Internet community. That is, as in any open standards outcome, publication of the NID proposal would allow persons not immediately associated with the proposer to work with the identifiers, or otherwise better carry out their own activities than if the NID publication had not been made. Benefits are expected to be in the form of open accessibility, interoperability, etc. It is expected that Formal NIDs may be applied to namespaces where some aspects are not fully open. For example, a namespace may make use of an externally managed (proprietary) registry (as, e.g., ISBN does), for assignment of URNs in the namespace, but it may still provide broad community benefit if the services associated have openly-published access protocols. In addition to the basic registration information defined in the Daigle [Page 4] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 registration template (in Appendix A), a formal namespace request must be accompanied by documented considerations of the need for a new namespace and the community benefit of formally establishing the proposed URN namespace. Additionally, since the goal of URNs is to provide persistent identification, some consideration as to the longevity and maintainability of the namespace must be given. The URN WG discussed at length the issue of finding objective measures for predicting (a priori) the continued success of a namespace. No conclusion was reached -- much depends on factors that are completely beyond the technical scope of the namespace. However, the collective experience of the IETF community does contain a wealth of information on technical factors that will prevent longevity of identification. The IESG may elect not to publish a proposed namespace RFC if the IETF community consensus is that it contains technical flaws that will prevent (or seriously impair the possibility of) persistent identification. The kinds of things the URN WG discussed included: - the organization maintaining the URN namespace should demonstrate stability and ability to maintain the URN namespace for a long time, and/or it should be clear how the namespace can continue to be usable/useful if the organization ceases to be able to foster it; - it should demonstrate ability and competency at name assignment in order to facilitate persistence (e.g. to minimize the likelihood of conflicts); - it should commit to not re-assigning existing names and allowing old names to continue to be valid, even if the owners or assignees of those names are no longer members or customers of that organization. This does not mean that there must be resolution of such names, but it does mean that they must not resolve the name to false or stale information, and it means that they must not be reassigned. These aspects, though hard to quantify objectively, should be considered by organizations/people considering the development of a Formal URN namespace, and they will be kept in mind when evaluating the technical merits of any proposed Formal namespace. 4.0 URN Namespace Registration, Update, and NID Assignment Process Different levels of disclosure are expected/defined for namespaces. Daigle [Page 5] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 According to the level of open-forum discussion surrounding the disclosure, a URN namespace may be assigned or may request a particular identifier. The "IANA Considerations" document [RFC2434] suggests the need to specify update mechanisms for registrations -- who is given the authority to do so, from time to time, and what are the processes. Since URNs are meant to be persistently useful, few (if any) changes should be made to the structural interpretation of URN strings (e.g., adding or removing rules for lexical equivalence that might affect the interpretation of URN IDs already assigned). However, it may be important to introduce clarifications, expand the list of authorized URN assigners, etc, over the natural course of a namespace's lifetime. Specific processes are outlined below. The official list of registered URN namespaces is maintained by IANA. URN namespace registrations are currently being posted in the anonymous FTP directory "ftp://ftp.isi.edu/in- notes/iana/assignments/URN-namespaces/". See [STD2] for the current location of IANA registry. The registration and maintenance procedures vary slightly from one namespace type (as defined in Section 3.0) to another. 4.1 Experimental These are not explicitly registered with IANA. They take the form X- No provision is made for avoiding collision of experimental NIDs; they are intended for use within internal or limited experimental contexts. As there is no registration, no registration maintenance procedures are needed. 4.2 Informal These are registered with IANA and are assigned a number sequence as an identifier, in the format: "urn-" where is chosen by the IANA on a First Come First Served basis (see [RFC2434]). Registrants should send a copy of the registration template (see Daigle [Page 6] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 Appendix A), duly completed, to the urn-nid@apps.ietf.org mailing and allow for a 2 week discussion period for clarifying the expression of the registration information and suggestions for improvements to the namespace proposal. After suggestions for clarification of the registration information have been incorporated, the template may be submitted to: iana@iana.org for assignment of a NID. The only restrictions on are that it consist strictly of digits and that it not cause the NID to exceed length limitations outlined in the URN syntax ([RFC2141]). Registrations may be updated by the original registrant, or an entity designated by the registrant, by updating the registration template, submitting it to the discussion list for a further 2 week discussion period, and finally resubmitting it to IANA, as described above. 4.3 Formal Formal NIDs are assigned via IETF Consensus, as defined in [RFC2434]: "IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists)." Thus, the Formal NID application is made via publication of an RFC through standard IETF processes. The RFC need not be standards- track, but it will be subject to IESG review and acceptance pursuant to the guidelines written here (as well as standard RFC publication guidelines). The template defined in Appendix A may be included as part of an RFC defining some other aspect of the namespace, or it may be put forward as an RFC in its own right. The proposed template should be sent to the urn-nid@apps.ietf.org mailing list to allow for a 2 week discussion period for clarifying the expression of the registration information, before the IESG Daigle [Page 7] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 reviews the document. The RFC must include a "Namespace Considerations" section, which outlines the perceived need for a new namespace (i.e., where existing namespaces fall short of the proposer's requirements). Considerations might include: - URN assignment procedures - URN resolution/delegation - type of resources to be identified - type of services to be supported NOTE: It is expected that more than one namespace may serve the same "functional" purpose; the intent of the "Namespace Considerations" section is to provide a record of the proposer's "due diligence" in exploring existing possibilities, for the IESG's consideration. The RFC must also include a "Community Considerations" section, which indicates the dimensions upon which the proposer expects the Internet community to be able to benefit by publication of this namespace. Potential considerations include: - open assignment and use of identifiers within the namespace - open operation of resolution servers for the namespace (server) - creation of software that can meaningfully resolve and access services for the namespace (client) A particular NID string is requested, and is assigned by IETF consensus (as defined in [RFC2434]), with the additional constraints that the NID string must - not be an already-registered NID - not start with "x-" (see Type I above) - not start with "urn-" (see Type II above) - not start with "XY-", where XY is any combination of 2 ASCII letters (see NOTE, below) - be more than 2 letters long NOTE: ALL two-letter combinations, and two-letter combinations followed by "-" and any sequence of valid NID characters, are reserved for potential use as countrycode- based NIDs for eventual national registrations of URN namespaces. The definition and scoping of rules for allocation of responsibility for such namespaces is beyond the scope of this document. Registrations may be revised by updating the RFC through standard Daigle [Page 8] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 IETF RFC update mechanisms. Thus, proposals for updates may be made by the original authors, other IETF participants, or the IESG. In any case, the proposed updated template must be circulated on the urn-nid discussion list, allowing for a 2 week review period. 5.0 Security Considerations This document largely focuses on providing mechanisms for the declaration of public information. Nominally, these declarations should be of relatively low security profile, however there is always the danger of "spoofing" and providing mis-information. Information in these declarations should be taken as advisory. 6.0 IANA Considerations This document outlines the processes for registering URN namespaces, and has implications for the IANA in terms of registries to be maintained. In all cases, the IANA should assign the appropriate NID (informal or formal), as described above, once an IESG-designated expert has confirmed that the requisite registration process steps have been completed. 7.0 References [ISO8601] ISO 8601 : 1988 (E), "Data elements and interchange formats - Information interchange - Representation of dates and times" [RFC2288] Lynch, C., Preston, C. and R. Daniel, "Using Existing Bibliographic Identifiers as Uniform Resource Names", RFC 2288, February 1998. [RFCXXXX] Mealling, M., "URI Resolution using the Dynamic Delegation Discovery System", RFCXXXX. [RFCYYYY] Mealling, M., "Assignment Procedures for URI Resolution Using DNS", RFCYYYY. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, Daigle [Page 9] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 October 1998. [STD2] Reynolds, J, and J. Postel, "Assigned Numbers", STD 2, October 1994. [RFC1737] Sollins, K. and L. Masinter, "Functional Requirements for Uniform Resource Names", RFC 1737, December 1994. [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998. 8.0 Authors' Addresses Leslie L. Daigle Thinking Cat Enterprises EMail: leslie@thinkingcat.com Dirk-Willem van Gulik WebWeaving Plein 1813 - 5a 8545 HX Arnhem The Netherlands Phone: +39 0332 78 0014 (Phone and Fax) EMail: Dirkx@webweaving.org Renato Iannella IPR Systems Pty Ltd. EMail: renato@iprsystems.com Patrik Faltstrom Cisco Systems Inc 170 W Tasman Drive SJ-13/2 San Jose CA 95134 USA EMail: paf@cisco.com URL: http://www.cisco.com 9.0 Appendix A -- URN Namespace Definition Template Daigle [Page 10] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 Definition of a URN namespace is accomplished by completing the following information template. Apart from providing a mechanism for disclosing structure of the URN namespace, this information is designed to be useful for - entities seeking to have a URN assigned in a namespace (if applicable) - entities seeking to provide URN resolvers for a namespace (if applicable) This is particularly important for communities evaluating the possibility of using a portion of an existing URN namespace rather than creating their own. Information in the template is as follows: Namespace ID: Assigned by IANA. In some contexts, a particular one may be requested (see below). Registration Information: This is information to identify the particular version of registration information: - registration version number: starting with 1, incrementing by 1 with each new version - registration date: date submitted to the IANA, using the format YYYY-MM-DD as outlined in [ISO8601]. Declared registrant of the namespace: This includes: Registering organization Name Address Designated contact person Name Coordinates (at least one of: e-mail, phone, postal address) Declaration of syntactic structure: This section should outline any structural features of identifiers in this namespace. At the very least, this description may be used to introduce terminology used in other sections. This structure may also be used for determining realistic caching/shortcuts approaches; suitable caveats should be provided. Daigle [Page 11] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 If there are any specific character encoding rules (e.g., which character should always be used for single-quotes), these should be listed here. Answers might include, but are not limited to: - the structure is opaque (no exposition) - a regular expression for parsing the identifier into components, including naming authorities Relevant ancillary documentation: This section should list any RFCs, standards, or other published documentation that defines or explains all or part of the namespace structure. Answers might include, but are not limited to: - RFCs outlining syntax of the namespace - Other of the defining community's (e.g., ISO) documents outlining syntax of the identifiers in the namespace - Explanatory material introducing the namespace Identifier uniqueness considerations: This section should address the requirement that URN identifiers be assigned uniquely -- they are assigned to at most one resource, and are not reassigned. (Note that the definition of "resource" is fairly broad; for example, information on "Today's Weather" might be considered a single resource, although the content is dynamic.) Possible answers include, but are not limited to: - exposition of the structure of the identifiers, and partitioning of the space of identifiers amongst assignment authorities which are individually responsible for respecting uniqueness rules - identifiers are assigned sequentially - information is withheld; the namespace is opaque Identifier persistence considerations: Although non-reassignment of URN identifiers ensures that a URN will persist in identifying a particular resource even after the "lifetime of the resource", some consideration should be given to the persistence of the usability of the URN. This is particularly important in the case of URN namespaces providing global resolution. Daigle [Page 12] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 Possible answers include, but are not limited to: - quality of service considerations Process of identifier assignment: This section should detail the mechanisms and/or authorities for assigning URNs to resources. It should make clear whether assignment is completely open, or if limited, how to become an assigner of identifiers, and/or get one assigned by existing assignment authorities. Answers could include, but are not limited to: - assignment is completely open, following a particular algorithm - assignment is delegated to authorities recognized by a particular organization (e.g., the Digital Object Identifier Foundation controls the DOI assignment space and its delegation) - assignment is completely closed (e.g., for a private organization) Process for identifier resolution: If a namespace is intended to be accessible for global resolution, it must be registerd in an RDS (Resolution Discovery System, see [RFC2276]) such as DDDS. Resolution then proceeds according to standard URI resolution processes, and the mechanisms of the RDS. What this section should outline is the requirements for becoming a recognized resolver of URNs in this namespace (and being so- listed in the RDS registry). Answers may include, but are not limited to: - the namespace is not listed with an RDS; this is not relevant - resolution mirroring is completely open, with a mechanism for updating an appropriate RDS - resolution is controlled by entities to which assignment has been delegated Rules for Lexical Equivalence: If there are particular algorithms for determining equivalence between two identifiers in the underlying namespace (hence, in the URN string itself), rules can be provided here. Some examples include: - equivalence between hyphenated and non-hyphenated groupings in Daigle [Page 13] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 the identifier string - equivalence between single-quotes and double-quotes - Namespace-defined equivalences between specific characters, such as "character X with or without diacritic marks". Note that these are not normative statements for any kind of best practice for handling equivalences between characters; they are statements limited to reflecting the namespace's own rules. Conformance with URN Syntax: This section should outline any special considerations required for conforming with the URN syntax. This is particularly applicable in the case of legacy naming systems that are used in the context of URNs. For example, if a namespace is used in contexts other than URNs, it may make use of characters that are reserved in the URN syntax. This section should flag any such characters, and outline necessary mappings to conform to URN syntax. Normally, this will be handled by hex encoding the symbol. For example, see the section on SICIs in [RFC2288]. Validation mechanism: Apart from attempting resolution of a URN, a URN namespace may provide mechanism for "validating" a URN -- i.e., determining whether a given string is currently a validly-assigned URN. For example, even if an ISBN URN namespace is created, it is not clear that all ISBNs will translate directly into "assigned URNs". A validation mechanims might be: - a syntax grammar - an on-line service - an off-line service Scope: This section should outline the scope of the use of the identifiers in this namespace. Apart from considerations of private vs. public namespaces, this section is critical in evaluating the applicability of a requested NID. For example, a namespace claiming to deal in "social security numbers" should have a global scope and address all social security number structures (unlikely). On the other hand, at a national level, it is reasonable to propose a URN namespace for "this nation's social Daigle [Page 14] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 security numbers". 10.0 Appendix B -- Illustration 10.1 Example Template The following example is provided for the purposes of illustration of the URN NID template described in Appendix A. Although it is based on a hypothetical "generic Internet namespace" that has been discussed informally within the URN WG, there are still technical and infrastructural issues that would have to be resolved before such a namespace could be properly and completely described. Namespace ID: To be assigned Registration Information: Version 1 Date: Declared registrant of the namespace: Name: Thinking Cat Enterprises Address: 1 ThinkingCat Way Trupville, NewCountry Contact: L. Daigle E-mail: leslie@thinkingcat.com Declaration of structure: The identifier structure is as follows: URN::: where FQDN is a fully-qualified domain name, and the assigned string is conformant to URN syntax requirements. Relevant ancillary documentation: Definition of domain names, found in: P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC1035, November 1987. Identifier uniqueness considerations: Uniqueness is guaranteed as long as the assigned string is never Daigle [Page 15] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 reassigned for a given FQDN, and that the FQDN is never reassigned. N.B.: operationally, there is nothing that prevents a domain name from being reassigned; indeed, it is not an uncommon occurrence. This is one of the reasons that this example makes a poor URN namespace in practice, and is therefore not seriously being proposed as it stands. Identifier persistence considerations: Persistence of identifiers is dependent upon suitable delegation of resolution at the level of "FQDN"s, and persistence of FQDN assignment. Same note as above. Process of identifier assignment: Assignment of these URNs delegated to individual domain name holders (for FQDNs). The holder of the FQDN registration is required to maintain an entry (or delegate it) in the DDDS. Within each of these delegated name partitions, the string may be assigned per local requirements. e.g. urn::thinkingcat.com:001203 Process for identifier resolution: Domain name holders are responsible for operating or delegating resolution servers for the FQDN in which they have assigned URNs. Rules for Lexical Equivalence: FQDNs are case-insensitive. Thus, the portion of the URN urn::: is case-insenstive for matches. The remainder of the identifier must be considered case-sensitve. Conformance with URN Syntax: No special considerations. Validation mechanism: None specified. Daigle [Page 16] =0C Internet-Draft draft-ietf-urn-rfc2611bis-01.txt February 2001 Scope: Global. 10.2 Registration steps in practice The key steps for registration of informal or formal namespaces typically play out as follows: Informal NID: 1. Complete the registration template. This may be done as part of an Internet-Draft. 2. Communicate the registration template to urn-nid@apps.ietf.org for technical review -- as a published I-D, or text e-mail message containing the template. 3. Update the registration template as necessary from comments, and repeat steps 2 and 3 as necessary. 4. Once comments have been addressed (and the review period has expired) end a request to IANA with the revised registration template. Formal NID: 1. Write an Internet-Draft describing the namespace and including the registration template, duly completed. 2. Send the Internet-Draft to the I-D editor, and send a copy to urn-nid@apps.ietf.org for technical review. 3. Update the Internet-Draft as necessary from comments, and repeat steps 2 and 3 as needed. 4. Send a request to the IESG to publish the I-D as an RFC. The IESG may request further changes (published as I-D revisions) and/or direct discussion to designated working groups, area experts, etc. 5. If the IESG approves the document for publication as an RFC, send a request to IANA to register the requested NID. Daigle [Page 17] =0C --------------32A770A5621E8647BFD0C6DF-- From owner-urn-ietf@LISTS.NETSOL.COM Sun Feb 11 18:25:46 2001 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA13510 for ; Sun, 11 Feb 2001 18:25:46 -0500 (EST) 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 SAA13328; Sun, 11 Feb 2001 18:13:25 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8689697 for URN-IETF@LISTS.NETSOL.COM; Sun, 11 Feb 2001 18:13:14 -0500 Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id SAA13321 for ; Sun, 11 Feb 2001 18:13:11 -0500 (EST) Received: (from michael@localhost) by bailey.dscga.com (8.9.1/) id RAA23668; Sun, 11 Feb 2001 17:57:12 -0500 (EST) References: <3A87004C.6BAB4F34@thinkingcat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.1.2i Approved-By: Michael Mealling Message-ID: <20010211175712.I18551@bailey.dscga.com> Date: Sun, 11 Feb 2001 17:57:12 -0500 Reply-To: michaelm@NETSOL.COM From: Michael Mealling Subject: Re: New revision of RFC2611bis To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <3A87004C.6BAB4F34@thinkingcat.com>; from leslie@THINKINGCAT.COM on Sun, Feb 11, 2001 at 04:12:44PM -0500 By and large I don't find a problem with Section 3.3 but there are a few boundary cases with some of the existing namespace requests that bother me a little.... On Sun, Feb 11, 2001 at 04:12:44PM -0500, Leslie Daigle wrote: > 3.3 Formal Namespaces > > A formal namespace may be requested, and IETF review sought, in cases > where the publication of the NID proposal and the underlying > namespace will provide benefit to an open and broad base of the > Internet community. That is, as in any open standards outcome, > publication of the NID proposal would allow persons not immediately > associated with the proposer to work with the identifiers, or > otherwise better carry out their own activities than if the NID > publication had not been made. Benefits are expected to be in the > form of open accessibility, interoperability, etc. Do we really want to restrict this to the Internet community? SICI's for example are almost unknown outside the Digital Library field but we don't really see a need to force Juha to get an informal space. I'd like to suggest that we reword the first sentence to this: A formal namespace may be requested, and IETF review sought, in cases where the publication of the NID proposal and the underlying namespace will provide benefit to an open and broad base community. > It is expected that Formal NIDs may be applied to namespaces where > some aspects are not fully open. For example, a namespace may make > use of an externally managed (proprietary) registry (as, e.g., ISBN > does), for assignment of URNs in the namespace, but it may still > provide broad community benefit if the services associated have > openly-published access protocols. By "openly-published access protocols" are we talking about our own or others? I.e. if the digital libraries world develops their own protocols for access to SICIs and you have to pay to get the spec of the ISO spec to implement it, is that open enough? > In addition to the basic registration information defined in the > registration template (in Appendix A), a formal namespace request > must be accompanied by documented considerations of the need for a > new namespace and the community benefit of formally establishing the > proposed URN namespace. By 'community benefit' are we still limiting that to the 'Internet community' or to the user community who might make use of the namespace? In the section on defining the process for Formal registration: > The RFC must also include a "Community Considerations" section, which > indicates the dimensions upon which the proposer expects the Internet > community to be able to benefit by publication of this namespace. > Potential considerations include: > > - open assignment and use of identifiers within the namespace > - open operation of resolution servers for the namespace > (server) > - creation of software that can meaningfully resolve and > access services for the namespace (client) Again, I'd change the above paragraph to remove the word "Internet" before the word "community". -MM -- -------------------------------------------------------------------------------- Michael Mealling | Vote Libertarian! | www.rwhois.net/michael Sr. Research Engineer | www.ga.lp.org/gwinnett | ICQ#: 14198821 Network Solutions | www.lp.org | michaelm@netsol.com From owner-urn-ietf@LISTS.NETSOL.COM Mon Feb 12 08:28:02 2001 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05465 for ; Mon, 12 Feb 2001 08:28:02 -0500 (EST) 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 IAA19575; Mon, 12 Feb 2001 08:16:52 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8690564 for URN-IETF@LISTS.NETSOL.COM; Mon, 12 Feb 2001 08:16:27 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA19121 for ; Mon, 12 Feb 2001 07:28:20 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04248; Mon, 12 Feb 2001 07:22:18 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200102121222.HAA04248@ietf.org> Date: Mon, 12 Feb 2001 07:22:18 -0500 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-dns-ddds-database-03.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : A DDDS Database Using The Domain Name System Author(s) : M. Mealling Filename : draft-ietf-urn-dns-ddds-database-03.txt Pages : 20 Date : 09-Feb-01 This document describes a Dynamic Delegation Discovery System Database using the Domain Name System as a distributed database of Rules. The Keys are domain-names and the Rules are encoded using the NAPTR Resource Record. Since this document officially obsoletes RFC 2168, it is the official specification for the NAPTR DNS Resource Record. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-dns-ddds-database-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-dns-ddds-database-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-dns-ddds-database-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010209143025.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-dns-ddds-database-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-dns-ddds-database-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010209143025.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Mon Feb 12 08:28:20 2001 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05492 for ; Mon, 12 Feb 2001 08:28:20 -0500 (EST) 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 IAA19587; Mon, 12 Feb 2001 08:17:38 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8690567 for URN-IETF@LISTS.NETSOL.COM; Mon, 12 Feb 2001 08:17:35 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA19133 for ; Mon, 12 Feb 2001 07:28:24 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04266; Mon, 12 Feb 2001 07:22:23 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200102121222.HAA04266@ietf.org> Date: Mon, 12 Feb 2001 07:22:22 -0500 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-ddds-04.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : Dynamic Delegation Discovery System (DDDS) Author(s) : M. Mealling Filename : draft-ietf-urn-ddds-04.txt Pages : 21 Date : 09-Feb-01 This document describes the Dynamic Delegation Discovery System (DDDS). The DDDS defines an abstract algorithm for applying dynamically retrieved string transformation rules to an application-unique string. Well-formed transformation rules will reflect the delegation of management of information associated with the string. Other documents specify applications and rule databases with which this algorithm may be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-ddds-04.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-ddds-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-ddds-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010209143034.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-ddds-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-ddds-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010209143034.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Mon Feb 12 08:28:29 2001 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05503 for ; Mon, 12 Feb 2001 08:28:29 -0500 (EST) 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 IAA19599; Mon, 12 Feb 2001 08:17:47 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8690570 for URN-IETF@LISTS.NETSOL.COM; Mon, 12 Feb 2001 08:17:44 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA19145 for ; Mon, 12 Feb 2001 07:28:29 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04285; Mon, 12 Feb 2001 07:22:27 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200102121222.HAA04285@ietf.org> Date: Mon, 12 Feb 2001 07:22:27 -0500 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-uri-res-ddds-03.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : URI Resolution using the Dynamic Delegation Discovery System Author(s) : M. Mealling Filename : draft-ietf-urn-uri-res-ddds-03.txt Pages : 24 Date : 09-Feb-01 A specification for taking a URI and locating an authoritative server for information about that URI. The method used to locate that authoritative server is the Dynamic Delegation Discovery System. This document, along with RFC YYYY[10] and RFC ZZZZ[9], obsoletes RFC 2168[12], RFC 2915[16] and updates RFC 2276[8]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-uri-res-ddds-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-uri-res-ddds-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-uri-res-ddds-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010209143045.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-uri-res-ddds-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-uri-res-ddds-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010209143045.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Tue Feb 13 08:39:07 2001 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17775 for ; Tue, 13 Feb 2001 08:39:07 -0500 (EST) 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 IAA00635; Tue, 13 Feb 2001 08:24:03 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8692029 for URN-IETF@LISTS.NETSOL.COM; Tue, 13 Feb 2001 08:22:39 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id HAA00276 for ; Tue, 13 Feb 2001 07:07:14 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15679; Tue, 13 Feb 2001 07:01:13 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200102131201.HAA15679@ietf.org> Date: Tue, 13 Feb 2001 07:01:13 -0500 Reply-To: Internet-Drafts@ietf.org Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-urn-rfc2611bis-01.txt To: URN-IETF@LISTS.NETSOL.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Uniform Resource Names Working Group of the IETF. Title : URN Namespace Definition Mechanisms Author(s) : L. Daigle, D. van Gulik, R. Iannella, P. Faltstrom Filename : draft-ietf-urn-rfc2611bis-01.txt Pages : 17 Date : 12-Feb-01 The URN WG has defined a syntax for Uniform Resource Names (URNs) [RFC2141], as well as some proposed mechanisms for their resolution and use in Internet applications ([RFCXXXX], [RFCYYYY]). The whole rests on the concept of individual 'namespaces' within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed ([RFC2288]), and this document lays out general definitions of and mechanisms for establishing URN 'namespaces'. This document obsoletes RFC2611. Discussion of this document should be directed to urn-ietf@ietf.org A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-rfc2611bis-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-urn-rfc2611bis-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-urn-rfc2611bis-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010212125324.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-rfc2611bis-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-rfc2611bis-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010212125324.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Thu Feb 15 18:40:07 2001 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02326 for ; Thu, 15 Feb 2001 18:40:07 -0500 (EST) 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 SAA22401; Thu, 15 Feb 2001 18:25:32 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8694219 for URN-IETF@LISTS.NETSOL.COM; Thu, 15 Feb 2001 18:23:36 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from sylvia.harvard.edu (sylvia.harvard.edu [128.103.151.242]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id JAA18899 for ; Thu, 15 Feb 2001 09:07:33 -0500 (EST) Received: from localhost (stephen@localhost) by sylvia.harvard.edu (8.9.3/8.9.3) with SMTP id JAA10491; Thu, 15 Feb 2001 09:01:30 -0500 (EST) X-Sender: stephen@sylvia MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Message-ID: Date: Thu, 15 Feb 2001 09:01:30 -0500 Reply-To: Stephen Abrams From: Stephen Abrams Subject: Informal NID registration for Harvard University Library To: URN-IETF@LISTS.NETSOL.COM Hello all: I am attaching below a copy of the message I recently sent to the "urn-nid@apps.ietf.org" mailing for comment on my request for registration with IANA of an informal namespace identifier for use by the Harvard University Library. I am posting my request here to elicit additional comments from the wider community of interested parties. -- Stephen L. Abrams stephen_abrams@harvard.edu Digital Library Software Engineer Tel: (617) 495-3724 Office for Information Systems Fax: (617) 495-0491 > From: Stephen Abrams > To: urn-nid@apps.ietf.org > Subject: Informal NID registration for Harvard University Library > > HUL is in the midst of a multi-year project to develop and deploy a > comprehensive infrastructure to collect, maintain, and delivery > digital content. This content includes digital representations of > existing analog material as well as material that is "born digital." > The source for this content includes material owned by or created at > Harvard University, as well as resources purchased or licensed from > external providers. In most cases these resources are accessed by the > Harvard community via HUL-supported delivery systems. Some of the > licensed material is provided by vendors through commercial interfaces > customized to delivery institution-appropriate versions of the > requested material. > > We have designed the proposed namespace to meet HUL's specific needs, > especially regarding distributed URN assignment and resolution to > Harvard-appropriate versions of material available in multiple > instantiations. These needs did not appear to be met by any of the > currently registered namespaces, or by any of proposed namespaces > still under discussion by this WG. > > HUL has developed and deployed an administrative system to assign URNs > and a local resolution mechanism to support the delivery of resources > named under our namespace. > > Any comments on this namespace are welcome. > > > > Namespace ID: > > To be assigned by IANA. > > Registration Information: > > Version 1 > Date: 2001-02-07 > > Declared registrant of the namespace: > > Name: Stephen Abrams > E-mail: nrsadm@hulmail.harvard.edu > Affiliation: Harvard University Library > Address: Office for Information Systems > 1280 Massachusetts Avenue, Suite 404 > Cambridge, MA 02138 > > The named registrant is specified in his capacity as the namespace > administrator for the Harvard University Library Office for > Information Systems (HUL/OIS). If the future, other individuals may > be designated by HUL/OIS for the purposes of administering potential > updates to this registration. > > Declaration of syntactic structure: > > All URNs defined under the namespace have the following structure, > specified in ABNF notation [1]: > > urn = "urn:" nid ":" nss > nid = "urn-" n > n = number-assigned-by-IANA > nss = authoritypath ":" resourcename > authoritypath = authority / (authoritypath "." authority) > authority = 1*authoritychar > authoritychar = upper / lower / number / > "(" / ")" / "+" / "," / "-" / "=" / "@" / > ";" / "$" / "_" / "!" / "*" / "'" / ("%" hex hex) > resourcename = 1*resourcechar > resourcechar = authoritychar / "." / ":" > > where , , , and are defined in Section > 2.2 of [4]. > > The %-escaping mechanism, as described in Sections 2.2 and 2.3.1 of > [4], is used to incorporate into URNs characters that are not > explicitly allowed by the grammar. > > Examples of valid URNs defined under the namespace include: > > urn:urn-:FHCL:10403 > urn:urn-:HBS.Baker.TC:1923 > urn:urn-:HUL.Eresource:holliswb > urn:urn-:HUL.OIS:Home > > The component of the URN uniquely identifies the > naming authority under which the URN was assigned. A naming > authority is an administrative unit or agent that has been granted > the privilege of creating, and the responsibility for maintaining > persistently, names in the subset of the full namespace identified > by that authority's . > > Naming authorities exist within a tree-like structure of authority > delegation, under which any given naming authority derives its > privileges and responsibilities from a pre-existing parent > authority. Naming authorities may independently propose and enforce > local policies and administrative procedures relative to names > created within their scope. > > The administrator of a naming authority, regardless of its position > within the delegation tree, has full oversight and operational > control over all aspects of URN administration of all delegated > authorities that derive from the common parent. The root naming > authority for the namespace is administered by HUL/OIS. The root > authority exists solely to provide a common root of delegatable > naming authority; it alone has no corresponding . > > Relevant ancillary documentation: > > [1] Crocker, D. and P. Overell, "Augmented BNF for Syntax > Specifications: ABNF", RFC 2234, November 1997. > > [2] Daniel, R., "A Trivial Convention for Using HTTP in URN > Resolution", RFC 2169, June 1997. > > [3] Mealling, M. and R. Daniel, Jr., "URI Resolution Services > Necessary for URN Resolution", RFC 2483, January 1999. > > [4] Moats, R. "URN Syntax", RFC 2141, May 1997. > > [5] Shafer, K., S. Weibel, E. Jul, and J. Fausey, "Introduction > to Persistent Uniform Resource Locators", Proc. INET '96, The > Internet: Transforming Our Society Now, Montreal, June 24-28, > 1996. > > Identifier uniqueness considerations: > > Individual naming authorities are responsible for insuring the > uniqueness of the components of the URNs created > within their scope. Naming authorities are also responsible for > insuring the uniqueness of the terminal component of the > for all delegated authorities. > > Identifier persistence considerations: > > HUL provides an administrative system that maintains URN > registration within the namespace. The system insures that once a > URN is assigned it is never reassigned to a different resource. > > Process of identifier assignment: > > The administrative system is decentralized to allow individual > naming authorities to create and maintain independently the URNs > that fall within the scope of those authorities. > > Administrative units or agents wishing to assign URNs must be > granted the appropriate privilege to do so from the administrator of > the naming authority in the scope of which the URNs are to be > created. Similarly, units or agents wishing to administer a new > delegated naming authority must negotiate directly with the > administrator of the potential parent authority, who, if > acquiescent, will create the delegated authority. > > Process for identifier resolution: > > HUL provides a resolution service for the namespace. The service > accepts THTTP-formatted [2] resolution requests for the URN-to-URL > and URN-to-URLs services (specified by either the "N2L" and "N2Ls" > mnemonics of [2] or the "I2L" and "I2Ls" mnemonics of [3]). Server > responses are consistent with [3]. > > Multiple URLs associated with a single URN are maintained within the > resolver database in an ordered list. A URN-to-URL request against > a URN with multiple URLs returns the URL with the highest priority > in the list. > > The mechanism used by client user agents to determine the location > of the resolution service is outside of the scope of this > registration document. > > In the absence of widely available native support for URNs within > the current generation of web clients, the resolution service also > accepts requests in a PURL-like syntax [5] for URNs that are > encapsulated into URLs: > > http:///urn-:: > > In this case, the URN-to-URL resolution service is assumed by the > resolver. > > Rules for Lexical Equivalence: > > The entire URN is case-insensitive. > > Conformance with URN syntax: > > No special considerations. > > Validation mechanism: > > The administrative system performs syntactic validation of all URNs > at the point of their registration. > > Scope: > > This namespace is used for the identification of network-accessible > resources delivered to the Harvard community and the public through > the mediation of HUL-supported systems or other delivery mechanisms > controlled or directed by Harvard-affiliated entities whose > standards and procedures for resource maintenance and access are > consistent with those of HUL, or for resources made accessible to > the Harvard community under contractual or similar arrangements. > These resources are provided by various organizational units of > Harvard University, including administrative and academic > departments, libraries, and museums, as well as digital content > purchased or licensed from external vendors. From owner-urn-ietf@LISTS.NETSOL.COM Mon Feb 19 18:25:47 2001 Received: from lists.netsol.com (lists.netsol.com [216.168.224.214]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17823 for ; Mon, 19 Feb 2001 18:25:47 -0500 (EST) 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 SAA25004; Mon, 19 Feb 2001 18:14:12 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8696859 for URN-IETF@LISTS.NETSOL.COM; Mon, 19 Feb 2001 18:12:19 -0500 Received: from tomts5-srv.bellnexxia.net (tomts5.bellnexxia.net [209.226.175.25]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id SAA24966 for ; Mon, 19 Feb 2001 18:12:17 -0500 (EST) Received: from thinkingcat.com ([64.229.215.57]) by tomts5-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010219230545.BASQ18941.tomts5-srv.bellnexxia.net@thinkingcat.com>; Mon, 19 Feb 2001 18:05:45 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3A87004C.6BAB4F34@thinkingcat.com> <20010211175712.I18551@bailey.dscga.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <3A91A624.41C1F133@thinkingcat.com> Date: Mon, 19 Feb 2001 18:03:00 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: New revision of RFC2611bis To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Howdy, I hit "reply" as soon as this message came in, and immediately tripped over terminology I've spent the intervening week trying to tease out in my own head. The key thing it keeps coming back to is: the text as written tried to capture what the group discussed when grappling with the notion that, for the IETF to expend effort in publishing and registering a namespace, there should be some overall benefit. The two ends of the spectrum are: 1. completely open standard, accessible and useful to every Internet user (which ISBN is not, simply because you have to pay 'em money to get an identifier) 2. completely closed namespace, assigned, resolved and used strictly by and within one organization, quite possibly never even exposed to traffic on the public Internet As I understood what the WG had to say, we want to be more generous than #1, but #2 is really not within the scope of something we want to call "Uniform", or feel the IETF/IANA should spend time formally registering (each one would punch a whole in available NID string space, without giving anything back to "the Internet community", or Internet-using people that may have no affiliation with the organization defining the namespace). But how to define the middle ground? If you look at something like MIME media types, there's one for Windows Word. Even without exposing the structure of Word documents, the registration _does_ benefit the Internet community at large because it allows (for example) Netscape to write software that will pop up MS's product when it encounters a Word attachment. (Okay, okay, it's a separate argument as to whether you _should_ auto-open attachments!! but you get my point, I hope). But, if MS registered "Blurb1", "Blurb2" and "Blurb3", but didn't make it clear that those corresponded to Excel, Word and Access attachments respectively, where's the value to the Internet community? It just shortens the list of available strings (MIME media types, or NIDs in our case). So, that was what I'd _heard_ the WG wanted to get captured in the document; did I get it wrong? can we express it better? Looking at your comments with the above in mind: Michael Mealling wrote: > > By and large I don't find a problem with Section 3.3 but there are > a few boundary cases with some of the existing namespace requests > that bother me a little.... > > On Sun, Feb 11, 2001 at 04:12:44PM -0500, Leslie Daigle wrote: > > 3.3 Formal Namespaces > > > > A formal namespace may be requested, and IETF review sought, in cases > > where the publication of the NID proposal and the underlying > > namespace will provide benefit to an open and broad base of the > > Internet community. That is, as in any open standards outcome, > > publication of the NID proposal would allow persons not immediately > > associated with the proposer to work with the identifiers, or > > otherwise better carry out their own activities than if the NID > > publication had not been made. Benefits are expected to be in the > > form of open accessibility, interoperability, etc. > > Do we really want to restrict this to the Internet community? SICI's > for example are almost unknown outside the Digital Library field > but we don't really see a need to force Juha to get an informal space. I'd intended "Internet-using" community, which is (these days) pretty wide open. The Digital Library field is a subset of that community. > I'd like to suggest that we reword the first sentence to this: > > A formal namespace may be requested, and IETF review sought, in cases > where the publication of the NID proposal and the underlying > namespace will provide benefit to an open and broad base community. "Open" is the keyword, I think. I think this is within spirit of what was intended -- as long as we keep the rest of the para. > > > It is expected that Formal NIDs may be applied to namespaces where > > some aspects are not fully open. For example, a namespace may make > > use of an externally managed (proprietary) registry (as, e.g., ISBN > > does), for assignment of URNs in the namespace, but it may still > > provide broad community benefit if the services associated have > > openly-published access protocols. > > By "openly-published access protocols" are we talking about our own > or others? I.e. if the digital libraries world develops their own > protocols for access to SICIs and you have to pay to get the spec > of the ISO spec to implement it, is that open enough? This is a good question, and I'd like to hear other input on it. In the MS-Word example above, there's still value in knowing what the beast is, even though the format is not an open spec. Ultimately, that was written as a "for example"; perhaps it's the preceeding text that needs to be clarified? > > > In addition to the basic registration information defined in the > > registration template (in Appendix A), a formal namespace request > > must be accompanied by documented considerations of the need for a > > new namespace and the community benefit of formally establishing the > > proposed URN namespace. > > By 'community benefit' are we still limiting that to the 'Internet > community' or to the user community who might make use of the > namespace? The whole Internet -- why is the _I_ETF involved in this registration? Note that the intention was to either: . define some user community that is a cross-section of the Internet-using world (e.g., digital library users), or . illuminate how every Internet user potentially makes use of this existing (e.g., the MS-Word MIME type, whether you use MS-Word or not). Perhaps, "new namespace and the benefit to all or some open subset of the Internet-using community of formally establishing the proposed URN namespace."? > > In the section on defining the process for Formal registration: > > > The RFC must also include a "Community Considerations" section, which > > indicates the dimensions upon which the proposer expects the Internet > > community to be able to benefit by publication of this namespace. > > Potential considerations include: > > > > - open assignment and use of identifiers within the namespace > > - open operation of resolution servers for the namespace > > (server) > > - creation of software that can meaningfully resolve and > > access services for the namespace (client) > > Again, I'd change the above paragraph to remove the word "Internet" before > the word "community". Ihhhhhhhhhhh... I'm concerned that it could be interpreted as the community served by #2 above. I agree it shouldn't imply #1 only. What's the way to express the middle ground? Leslie. -- ------------------------------------------------------------------- "Days used to be longer." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com -------------------------------------------------------------------