From owner-urn-ietf@LISTS.NETSOL.COM Thu Mar 1 22:31:34 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 WAA04530 for ; Thu, 1 Mar 2001 22:31:34 -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 WAA08234; Thu, 1 Mar 2001 22:18:57 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8675355 for URN-IETF@LISTS.NETSOL.COM; Thu, 1 Mar 2001 22:16:26 -0500 Received: from tomts6-srv.bellnexxia.net (smtp.bellnexxia.net [209.226.175.26]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id WAA08209 for ; Thu, 1 Mar 2001 22:16:25 -0500 (EST) Received: from thinkingcat.com ([64.229.206.85]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010302030950.YIWT25007.tomts6-srv.bellnexxia.net@thinkingcat.com> for ; Thu, 1 Mar 2001 22:09:50 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------4E2C391C8ECB154D2ADED3CF" Approved-By: Leslie Daigle Message-ID: <3A9F0E3E.DB28F6A2@thinkingcat.com> Date: Thu, 1 Mar 2001 22:06:38 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: new new version of RFC2611bis To: URN-IETF@LISTS.NETSOL.COM This is a multi-part message in MIME format. --------------4E2C391C8ECB154D2ADED3CF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Howdy, I have just sent the attached revision to the Internet-Drafts editor. It: . incorporates text changes proposed by Michael, following discussion on this list . requires an 'iana considerations' section in any Formal NID requesting RFC (per IANA's request) . fixes a couple of fluffs in the running text Leslie. -- ------------------------------------------------------------------- "Winters never cease." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- --------------4E2C391C8ECB154D2ADED3CF Content-Type: text/plain; charset=iso-8859-1; name="draft-ietf-urn-rfc2611bis-02.txt" Content-Disposition: inline; filename="draft-ietf-urn-rfc2611bis-02.txt" Content-Transfer-Encoding: quoted-printable Internet-Draft L. Daigle URN WG Thinking Cat Enterprises Expires September 1, 2001 D. van Gulik Category: Best Current Practice WebWeaving draft-ietf-urn-rfc2611bis-02.txt R. Iannella IPR Systems P. Faltstrom Cisco March 1, 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-02.txt March 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-02.txt March 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-02.txt March 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 some subset of users on the Internet. That is, a formal NID proposal, if accepted, must be functional on and with the global Internet, not limited to users in communities or networks not connected to the Internet. For example, a NID is requested that is meant for naming of physics research. If that NID request required that the user use a propietary network or service that was not at all open to the general Internet user then it would make a poor request for a formal NID. The intent is that, while the community of those who may actively use the names assigned within that NID may be small (but no less important), the potential use of names within that NID is open to any user on the Internet. 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 privately managed (proprietary) registry (as, e.g., ISBN does), for assignment of URNs in the namespace, but it may still Daigle [Page 4] =0C Internet-Draft draft-ietf-urn-rfc2611bis-02.txt March 2001 provide benefit to some Internet users if the services associated have openly-published access protocols. 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. 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. Daigle [Page 5] =0C Internet-Draft draft-ietf-urn-rfc2611bis-02.txt March 2001 4.0 URN Namespace Registration, Update, and NID Assignment Process Different levels of disclosure are expected/defined for namespaces. 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 Daigle [Page 6] =0C Internet-Draft draft-ietf-urn-rfc2611bis-02.txt March 2001 basis (see [RFC2434]). Registrants should send a copy of the registration template (see 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 Daigle [Page 7] =0C Internet-Draft draft-ietf-urn-rfc2611bis-02.txt March 2001 mailing list to allow for a 2 week discussion period for clarifying the expression of the registration information, before the IESG 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 its community to be able to benefit by publication of this namespace as well as how a general Internet user will be able to use the space if they care to do so. 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) The RFC must include an "IANA Considerations" section, indicating that the document includes a URN NID registration that is to be entered into the IANA registry of URN NIDs. 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 Daigle [Page 8] =0C Internet-Draft draft-ietf-urn-rfc2611bis-02.txt March 2001 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 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. This document replaces the processes outlined in [RFC2611]. 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. Daigle [Page 9] =0C Internet-Draft draft-ietf-urn-rfc2611bis-02.txt March 2001 [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, 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 Daigle [Page 10] =0C Internet-Draft draft-ietf-urn-rfc2611bis-02.txt March 2001 EMail: paf@cisco.com URL: http://www.cisco.com 9.0 Appendix A -- URN Namespace Definition Template 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 the case of a Formal NID registration, a particular NID string may be requested. 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) Daigle [Page 11] =0C Internet-Draft draft-ietf-urn-rfc2611bis-02.txt March 2001 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. 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: Daigle [Page 12] =0C Internet-Draft draft-ietf-urn-rfc2611bis-02.txt March 2001 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. 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: Daigle [Page 13] =0C Internet-Draft draft-ietf-urn-rfc2611bis-02.txt March 2001 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 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 Daigle [Page 14] =0C Internet-Draft draft-ietf-urn-rfc2611bis-02.txt March 2001 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 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: Daigle [Page 15] =0C Internet-Draft draft-ietf-urn-rfc2611bis-02.txt March 2001 P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION", RFC1035, November 1987. Identifier uniqueness considerations: Uniqueness is guaranteed as long as the assigned string is never 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: Daigle [Page 16] =0C Internet-Draft draft-ietf-urn-rfc2611bis-02.txt March 2001 No special considerations. Validation mechanism: None specified. 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. Daigle [Page 17] =0C Internet-Draft draft-ietf-urn-rfc2611bis-02.txt March 2001 5. If the IESG approves the document for publication as an RFC, send a request to IANA to register the requested NID. Daigle [Page 18] =0C --------------4E2C391C8ECB154D2ADED3CF-- From owner-urn-ietf@LISTS.NETSOL.COM Thu Mar 1 22:36:31 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 WAA04886 for ; Thu, 1 Mar 2001 22:36:31 -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 WAA08318; Thu, 1 Mar 2001 22:24:21 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8675360 for URN-IETF@LISTS.NETSOL.COM; Thu, 1 Mar 2001 22:22:11 -0500 Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id WAA08237 for ; Thu, 1 Mar 2001 22:19:09 -0500 (EST) Received: from thinkingcat.com ([64.229.206.85]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010302031239.XOL757.tomts7-srv.bellnexxia.net@thinkingcat.com> for ; Thu, 1 Mar 2001 22:12:39 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <3A9F0EE7.AAE827E9@thinkingcat.com> Date: Thu, 1 Mar 2001 22:09:27 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: WG last call: draft-ietf-urn-rfc2611bis-02.txt To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Howdy, Since there has been little discussion of recent versions of this document, and the last version has minor changes, I'm going to go ahead and put it to working group last call. I circulated the document on this list, but I don't expect to see it in the repository until next week. Also, we're heading into the "pre-IETF wipeout zone", so I'm going to extend the timeframe of the WG last call to March 30, 2001, i.e., the Friday after the IETF meeting. I will issue a reminder a week before the end of last call. Leslie. -- ------------------------------------------------------------------- "Winters never cease." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Mon Mar 5 10:01:05 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 KAA17000 for ; Mon, 5 Mar 2001 10:01: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 JAA05306; Mon, 5 Mar 2001 09:47:40 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8677752 for URN-IETF@LISTS.NETSOL.COM; Mon, 5 Mar 2001 09:46:30 -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 GAA04514 for ; Mon, 5 Mar 2001 06:52:35 -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 GAA11355; Mon, 5 Mar 2001 06:46:35 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200103051146.GAA11355@ietf.org> Date: Mon, 5 Mar 2001 06:46:35 -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-02.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-02.txt Pages : 18 Date : 02-Mar-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-02.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-02.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-02.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: <20010302132407.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-rfc2611bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-rfc2611bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010302132407.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Mon Mar 5 21:07:28 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 VAA13809 for ; Mon, 5 Mar 2001 21:07:28 -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 UAA09686; Mon, 5 Mar 2001 20:56:13 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8678141 for URN-IETF@LISTS.NETSOL.COM; Mon, 5 Mar 2001 20:55:45 -0500 Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id UAA09679 for ; Mon, 5 Mar 2001 20:55:43 -0500 (EST) Received: from thinkingcat.com ([64.229.206.85]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010306014913.SASL741.tomts8-srv.bellnexxia.net@thinkingcat.com> for ; Mon, 5 Mar 2001 20:49:13 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <3AA4414D.CACB481C@thinkingcat.com> Date: Mon, 5 Mar 2001 20:45:49 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: FEEDBACK for Last Call of draft-ietf-urn-rfc2611bis-02.txt To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Howdy, Particularly because of the limited discussion the last couple of months on this document, I'd like to have some sense of when people have read it but have no issue with it (and therefore don't have anything to post). So, I would ask that anyone who DOES read the document send back the following. If you're just saying "yeah", you can send it to me directly (as WG chair); if you have issues, send it to the whole list and/or the document authors. I can post a digest version of the ones not copied to the list. This in no way replaces standard operating procedure (comments as you see fit), just provides a vehicle for reviewers that otherwise go silently unnoticed. "I have looked at the document draft-ietf-urn-rfc2611bis-02.txt and: __ read it over casually, had no big issues with it __ read it carefully in detail, had no issues with it __ read it carefully in detail, and had concerns with it, as explained below. [Explanation]" Much appreciated, Leslie. -- ------------------------------------------------------------------- "The best laid plans are written in pencil." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Wed Mar 7 15:20:06 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 PAA21321 for ; Wed, 7 Mar 2001 15:20:06 -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 PAA22266; Wed, 7 Mar 2001 15:07:45 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8678958 for URN-IETF@LISTS.NETSOL.COM; Wed, 7 Mar 2001 15:07:10 -0500 Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id PAA22253 for ; Wed, 7 Mar 2001 15:07:08 -0500 (EST) Received: from orpheus (cameron@orpheus [199.60.3.24]) by cs.sfu.ca (8.9.1/8.9.1) with SMTP id MAA29461; Wed, 7 Mar 2001 12:01:07 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: 8xwvmkmN00go17hx5jNVPw== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Approved-By: Rob Cameron Message-ID: <200103072001.MAA29461@cs.sfu.ca> Date: Wed, 7 Mar 2001 12:01:07 -0800 Reply-To: Rob Cameron From: Rob Cameron Subject: Re: Informal NID registration for Harvard University Library To: URN-IETF@LISTS.NETSOL.COM Stephen, Your document addresses a very important point that may be of general interest to list members and is certainly of interest to us. > 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. Dealing with rules for delegated authority of namespace management is an interesting topic. I think it deserves considerable discussion. In the general context, there may be very tight top-level control of a namespace. But once a namespace has been delegated, the next level of control may be very loose. In the area of DNS names, the result has been cybersquatting and other practices. I'm not sure, but this may also become a problem with respect to URN namespace management. I think that a requirement for negotiated control at each level of the hierarchy, as in your document, makes sense. In the area of bibliographic identification, at least, I think there is reason to go further. Here are three general concerns that I have and possible statements to address them. (1) Conflicts with historical (non-URN) identifying codes. For example, suppose that the naming authority HUL.ULC (University Library Council) creates a new subauthority HUL.ULC.PSC for a "Preservation Standards Committee". This may be allowed because there is no pre-existing URN that would conflict. But there may be historical ULC documents that use "PSC" for "Public Services Committee". When URNs for those documents are created, a conflict may arise. I don't doubt that you've thought of this, but it would be good to have model wording that attempts to address the problem. Here's a possibility. "A naming authority must make best efforts to ensure that codes assigned for subauthorities or resources do not conflict with previous uses of those codes within the scope of the authority." (2) Unnecessarily distinct syntax. I can't quickly come up with an example for your domain, so I'll give one from our work with USIN journal article syntax. We allow individual authorities to create their own identifier syntaxes (as your flexible resourcename syntax does). But we also have syntactic conventions that apply to things like serial resources. For example, for print journals we define the ":" operator to introduce principal enumeration (volumes), the "()" notation for secondary enumeration (issues) and the "@" notation to specify the starting page number of an article. This applies to all namespaces with the USIN framework and should be respected by all naming authorities. "A naming authority must respect syntactic conventions established by parent authorities. No conflicting use of such conventions is permitted. Where applicable, the conventions should be used." (3) Registration level problems. Suppose that the Digital Acquistions Committee of your University Library Council wants to start issuing URNs, before ULC is ready to start managing its namespace. In this case, I think the HUL authority should negotiate on behalf of ULC to register the HUL.ULC.DAC. "Naming authorities may act for subauthorities as required. For example, a naming authority may authorize a sub-subauthority even though the relevant subauthority is inactive." These are not meant to be criticisms, just points for discussion, if you or others are so inclined. Robert D. Cameron, Professor cameron@cs.sfu.ca School of Computing Science FAX: (604) 291-3045 Simon Fraser University Phone: (604) 291-3241 Burnaby, B.C., Canada V5A 1S6 Bibliographic Protocol/Universal Serial Item Names Project http://usin.org/ From owner-urn-ietf@LISTS.NETSOL.COM Thu Mar 8 08:37:03 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 IAA25724 for ; Thu, 8 Mar 2001 08:37:03 -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 IAA27033; Thu, 8 Mar 2001 08:25:37 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8679224 for URN-IETF@LISTS.NETSOL.COM; Thu, 8 Mar 2001 08:23:59 -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 HAA26744 for ; Thu, 8 Mar 2001 07:04:46 -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 GAA22648; Thu, 8 Mar 2001 06:58:46 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200103081158.GAA22648@ietf.org> Date: Thu, 8 Mar 2001 06:58:46 -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-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 : A DDDS Database Using The Domain Name System Author(s) : M. Mealling Filename : draft-ietf-urn-dns-ddds-database-04.txt Pages : 20 Date : 07-Mar-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-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-dns-ddds-database-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-dns-ddds-database-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: <20010307143050.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-dns-ddds-database-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-dns-ddds-database-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010307143050.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-urn-ietf@LISTS.NETSOL.COM Thu Mar 8 09:42: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 JAA27848 for ; Thu, 8 Mar 2001 09:42:24 -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 JAA27648; Thu, 8 Mar 2001 09:31:21 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8679322 for URN-IETF@LISTS.NETSOL.COM; Thu, 8 Mar 2001 09:31:14 -0500 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 JAA27641 for ; Thu, 8 Mar 2001 09:31:13 -0500 (EST) Received: from stephen.harvard.edu ([128.103.151.229]) by sylvia.harvard.edu (8.9.3/8.9.3) with ESMTP id JAA18143; Thu, 8 Mar 2001 09:25:12 -0500 (EST) X-Sender: stephen@hulmail.harvard.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Approved-By: Stephen Abrams Message-ID: <4.3.2.7.2.20010308092149.00b3d5d0@hulmail.harvard.edu> Date: Thu, 8 Mar 2001 09:25:12 -0500 Reply-To: Stephen Abrams From: Stephen Abrams Subject: Re: Informal NID registration for Harvard University Library To: URN-IETF@LISTS.NETSOL.COM In-Reply-To: <200103072001.MAA29461@cs.sfu.ca> Hi Robert: Thanks for responding to our recent namespace registration template. > Dealing with rules for delegated authority of namespace managmenet > is an interesting topic. I think it deserves considerable discussion. Our system was designed explicitly to allow decentralized naming operations, so we spent quite a bit of time thinking about the devolution of policy and administrative control. Our general approach is to let individual naming authorities do whatever they want, subject to the minimal rules imposed by the namespace syntax and general system policy. However, the scope of administrative privilege accumulates downward as sub-authorities are delegated, so a higher, and presumably, more responsible authority can always override an action taken at a lower delegation level. > In the general context, there may be very tight top-level control of > a namespace. But once a namespace has been delegated, the next level > of control may be very loose. In the area of DNS names, the result > has been cybersquatting and other practices. I'm not sure, but > this may also become a problem with respect to URN namespace > management. We avoid any potential problems along these lines in the following manner: Our delegation model provides parent naming authorities with control their children, as stated in the registration template: "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." For any operational privilege explicitly granted to a naming authority (e.g., create URN, update resolved URL, etc.), that authority implicitly holds the same privilege relative to all of its children and their derivatives. During sub-authority delegation, the parent authority administrator cannot grant to the delegated administrator privileges that the parent does not possess. So any potentially unacceptable action taken by a delegated authority can be overridden by its parent, or some authority further up the tree. (This takes the form of being able to repair or undo some action; there is no provision in our administrative system for actions to be be vetted by some higher authoritiy before being performed.) > "A naming authority must make best efforts to ensure that codes > assigned for subauthorities or resources do not conflict with previous > uses of those codes within the scope of the authority." In our namespace the NSS is subdivided into two components, an to identify the naming authority under which scope the URN is issued, and a to identify the resource: nss = authoritypath ":" resourcename with the colon being a reserved character in . The two identifiers: HUL.ULC.PSC:xyz HUL.ULC:PSC.xyz (for resource "xyz" issued by the "PSC" authority; and "PSC.xyz" issued by the "ULC" authority) remain unambiguous for identification purposes. If ULC has both a Public Services Committee and a Preservation Standards Committee, the first one to use the PSC acronym gets it. As a best practice we encourage the creation of delegated authority identifiers (and s) that are not semantically loaded to avoid potential ambiguities. We encourage the notion that URNs are opaque identifiers and not additional descriptive metadata. Whether these recommendations will be accepted in practice remains problematic. > "A naming authority must respect syntactic conventions established by > parent authorities. No conflicting use of such conventions is > permitted. Where applicable, the conventions should be used." Our registration system does not have the facility for allowing authorities to define extensions to the namespace syntax, or for enforcing any such extensions. Any such rules would have to be implemented as part of the workflow for an authority and its delegates. There is nothing to stop an authority for doing this: "Naming authorities may independently propose and enforce local policies and administrative procedures relative to names created within their scope." Again, we are trying to encourage the notion that names are opaque identifiers. Descriptive metadata properly belong in catalogs or other resource discovery systems. > "Naming authorities may act for subauthorities as required. For > example, a naming authority may authorize a sub-subauthority even > though the relevant subauthority is inactive." This is already allowed, and was meant to be declared by the statement: "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." Each naming authority has complete control over the subset of the full namespace specified by that authority's . In short, I agree with your various proposals, but I think that we have already addressed this concerns in our template, although perhaps our language was more implicit than explicit. __________________________________________________________ Stephen L. Abrams stephen_abrams@harvard.edu Digital Library Software Engineer Tel: (617) 495-3724 Office for Information Systems Fax: (617) 495-0491 Harvard University Library From owner-urn-ietf@LISTS.NETSOL.COM Tue Mar 13 11:16:45 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 LAA22649 for ; Tue, 13 Mar 2001 11:16:44 -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 LAA01836; Tue, 13 Mar 2001 11:04:41 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8681030 for URN-IETF@LISTS.NETSOL.COM; Tue, 13 Mar 2001 11:04:02 -0500 Approved-By: michael@BAILEY.DSCGA.COM Received: from lhc.nlm.nih.gov (lhc.nlm.nih.gov [130.14.35.128]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA01586 for ; Tue, 13 Mar 2001 10:34:45 -0500 (EST) Received: (from jak@localhost) by lhc.nlm.nih.gov (8.8.8+Sun/8.8.7) id KAA26012 for urn-ietf@lists.netsol.com; Tue, 13 Mar 2001 10:28:47 -0500 (EST) Message-ID: <200103131528.KAA26012@lhc.nlm.nih.gov> Date: Tue, 13 Mar 2001 10:28:47 -0500 Reply-To: "John A. Kunze" From: "John A. Kunze" Subject: (new) ARK Persistent Identifier Scheme To: URN-IETF@LISTS.NETSOL.COM I wanted to let folks know about a new persistent naming scheme called ARK (Archival Resource Key). It may be of interest to members of this list. A first version of the ARK proposal appears as an Internet-Draft in the IETF archives, but the revision pointed to by http://www.ckm.ucsf.edu/people/jak/home/ark-01.ps (postscript, 26pp) or http://www.ckm.ucsf.edu/people/jak/home/ark-01.txt (plain text, 38pp) is much more complete. No part of the proposal is on the IETF meeting agenda. If any of you will be there (Minneapolis) next week, you should be able to find me at the informal FURI (Future of Uniform Resource Identifiers) session Tuesday 20 March, 17:00-18:00. Enclosed is an abstract and table of contents. There will no doubt be a number of revisions to this draft proposal. Comments and reactions would be most welcome. Please send them to jak@ckm.ucsf.edu. -John --------------------------------------------------------------------------- John A. Kunze +1 415-502-6660 University of California, 530 Parnassus Ave, Box 0840 jak@ckm.ucsf.edu San Francisco/US National San Francisco, CA 94143-0840 Fax: 415-502-0910 Library of Medicine ----------------------- UC San Francisco and US NLM ----------------------- The ARK Persistent Identifier Scheme -- 8 March 2001 Abstract The ARK (Archival Resource Key) is a scheme intended to facilitate the persistent naming and retrieval of information objects. It comprises an identifier syntax and three services. An ARK has four components: ark:[NMAH]/NAAN/Name the prefix "ark:", the (optional and mutable) Name Mapping Authority Hostport (NMAH, where "hostport" is a hostname followed optionally by a colon and port number), the Name Assigning Authority Number (NAAN), and the assigned Name. The NAAN and Name together form the immutable persistent identifier for the object. An ARK request is an ARK to which is appended a service request beginning with a question mark. Use of an ARK request proceeds in two steps. First, the NMAH, if not specified, is discovered based on the NAAN. Two methods for discovery are proposed: one is file based, the other based on the DNS NAPTR record. Second, the ARK request is submitted to the NMAH. Three ARK services are defined, gaining access to: (1) the object (or a sensible substitute), (2) a description of the object (metadata), and (3) a description of the commitment made by the NMA regarding the persistence of the object (policy). These services are defined initially to use the HTTP protocol, given the World Wide Web's pre-eminence among Internet information retrieval systems. When the NMAH is specified, the "ark:" prefix may be replaced with "http://", to produce a valid URL that can gain access to ARK services using an unmodified Web client. Table of Contents (page numbers refer to the plain text document) Status of this Document ........................................ 1 Abstract ....................................................... 1 1. Introduction ............................................... 3 1.1. Three Reasons to Use ARKs ................................ 3 1.2. Organizing Support for ARKs .............................. 4 1.3. A Definition of Identifier ............................... 5 2. ARK Anatomy ................................................ 6 2.1. The Name Mapping Authority Hostport (NMAH) ............... 6 2.2. The Name Assigning Authority Number (NAAN) ............... 7 2.3. The Name Part ............................................ 8 2.4. Lexical Equivalence ...................................... 8 2.5. Naming Considerations .................................... 9 3. Assigners of ARKs .......................................... 11 4. Finding a Name Mapping Authority ........................... 11 4.1. Looking Up NMAHs in a Globally Accessible File ........... 13 4.2. Looking up NMAHs Distributed via DNS ..................... 15 5. Generic ARK Service Definition ............................. 16 5.1. Generic ARK Access Service (access, location) ............ 17 5.2. Generic Policy Service (permanence, naming, etc.) ....... 17 5.3. Generic Description Service .............................. 18 6. Overview of the HTTP Key Mapping Protocol (HKMP) ........... 18 7. Overview of Electronic Resource Citations (ERCs) ........... 21 7.1. ERC Syntax ............................................... 23 7.2. ERC Stories .............................................. 24 7.3. The ERC Anchoring Story .................................. 25 7.4. ERC Elements ............................................. 26 7.5. ERC Element Values ....................................... 29 7.6. ERC Element Encoding and Dates ........................... 31 7.7. ERC Stub Records and Internal Support .................... 33 8. Advice to Web Clients ...................................... 33 9. Security Considerations .................................... 34 10. Authors' Addresses ........................................ 34 11. References ................................................ 35 12. Appendix: An NLM Prototype ARK Service ................... 36 13. Appendix: Current ARK Name Authority Table ............... 36 14. Copyright Notice .......................................... 38 From owner-urn-ietf@LISTS.NETSOL.COM Mon Mar 26 18:43:45 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 SAA20934 for ; Mon, 26 Mar 2001 18:43:45 -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 SAA16777; Mon, 26 Mar 2001 18:30:29 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8697317 for URN-IETF@LISTS.NETSOL.COM; Mon, 26 Mar 2001 18:28:14 -0500 Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id SAA16766 for ; Mon, 26 Mar 2001 18:28:13 -0500 (EST) Received: from thinkingcat.com ([64.229.192.99]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010326232148.BKJY24361.tomts7-srv.bellnexxia.net@thinkingcat.com> for ; Mon, 26 Mar 2001 18:21:48 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <3A9F0EE7.AAE827E9@thinkingcat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <3ABFCEE5.2897C05B@thinkingcat.com> Date: Mon, 26 Mar 2001 18:21:09 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: REMINDER [was Re: WG last call: draft-ietf-urn-rfc2611bis-02.txt] To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Howdy, As promised, here is a reminder that the WG last call for this document ends on Friday, March 30. Again, it would be appreciated if you could send me explicit feedback upon reviewing the draft -- not to replace the last call process, but to get some sense of who is reading the document and doesn't have major comments to share: "I have looked at the document draft-ietf-urn-rfc2611bis-02.txt and: __ read it over casually, had no big issues with it __ read it carefully in detail, had no issues with it __ read it carefully in detail, and had concerns with it, as explained below. [Explanation]" Thanks, Leslie. Leslie Daigle wrote: > > Howdy, > > Since there has been little discussion of recent versions of this > document, and the last version has minor changes, I'm going to > go ahead and put it to working group last call. > > I circulated the document on this list, but I don't expect to > see it in the repository until next week. Also, we're heading > into the "pre-IETF wipeout zone", so I'm going to extend the > timeframe of the WG last call to March 30, 2001, i.e., the Friday > after the IETF meeting. > > I will issue a reminder a week before the end of last call. > > Leslie. > > -- > > ------------------------------------------------------------------- > "Winters never cease." > -- ThinkingCat > > Leslie Daigle > leslie@thinkingcat.com > ------------------------------------------------------------------- -- ------------------------------------------------------------------- "The best laid plans are written in pencil." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Wed Mar 28 20:21:44 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 UAA16395 for ; Wed, 28 Mar 2001 20:21:44 -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 UAA08423; Wed, 28 Mar 2001 20:09:17 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8700749 for URN-IETF@LISTS.NETSOL.COM; Wed, 28 Mar 2001 20:07:17 -0500 Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id UAA08410 for ; Wed, 28 Mar 2001 20:07:15 -0500 (EST) Received: from orpheus (cameron@orpheus [199.60.3.24]) by cs.sfu.ca (8.9.1/8.9.1) with SMTP id RAA18011; Wed, 28 Mar 2001 17:01:17 -0800 (PST) MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: q2KCFcJMIkC2wjwuivPQDQ== X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Approved-By: Rob Cameron Message-ID: <200103290101.RAA18011@cs.sfu.ca> Date: Wed, 28 Mar 2001 17:01:17 -0800 Reply-To: Rob Cameron From: Rob Cameron Subject: Re: REMINDER [was Re: WG last call: draft-ietf-urn-rfc2611bis-02.txt] To: URN-IETF@LISTS.NETSOL.COM Leslie, Here are my comments on this draft. 1. I believe it would help to introduce some finer terminology with respect to uniqueness. For example, the phrase "uniquely-assigned identifier" would be read by many to mean that one and only one identifier may exist for a resource. What is technically required, however, is that every URN is unambiguous, i.e., that it denotes a unique resource. With separately assigned namespaces, with possibly overlapping functionality, it is not possible to ensure that the URN for a resource is unique. 2. The examples given with ISBNs and ISSNs are confusing, because they make false statements. "while there may be some number (or numbers) that is both a valid ISBN identifier and ISSN identifier, ..." (Section 2.0) "a namespace may make use of an privately managed (proprietary) registry (as, e.g., ISBN does)." (Section 3.3) 3. I am confused by the statement: 'even if an ISBN URN namespace is created, it is not clear that all ISBNs will translate directly into "assigned URNs".' What are you trying to say? 4. I am greatly concerned about the following paragraph at the end of section 4.3. "Registrations may be revised by updating the RFC through standard 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." If the original authors are not involved, I believe that this is process is woefully inadequate. From owner-urn-ietf@LISTS.NETSOL.COM Thu Mar 29 10:40:00 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 KAA19176 for ; Thu, 29 Mar 2001 10:39:59 -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 KAA15724; Thu, 29 Mar 2001 10:26:35 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8702073 for URN-IETF@LISTS.NETSOL.COM; Thu, 29 Mar 2001 10:24:37 -0500 Received: from tomts6-srv.bellnexxia.net (tomts6.bellnexxia.net [209.226.175.26]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id KAA15714 for ; Thu, 29 Mar 2001 10:24:36 -0500 (EST) Received: from thinkingcat.com ([64.229.192.99]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.16 201-229-121-116-20010115) with ESMTP id <20010329151811.TAOV29116.tomts6-srv.bellnexxia.net@thinkingcat.com>; Thu, 29 Mar 2001 10:18:11 -0500 X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <200103290101.RAA18011@cs.sfu.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Approved-By: Leslie Daigle Message-ID: <3AC35202.225D9900@thinkingcat.com> Date: Thu, 29 Mar 2001 10:17:22 -0500 Reply-To: Leslie Daigle From: Leslie Daigle Organization: Thinking Cat Enterprises Subject: Re: REMINDER [was Re: WG last call: draft-ietf-urn-rfc2611bis-02.txt] To: URN-IETF@LISTS.NETSOL.COM Content-Transfer-Encoding: 7bit Hi Rob, Thanks much for the comments. I'll incorporate them in a revised draft, except: Rob Cameron wrote: > 2. The examples given with ISBNs and ISSNs are confusing, because > they make false statements. > > "while there may be some number (or numbers) that is both a valid > ISBN identifier and ISSN identifier, ..." (Section 2.0) The point is that NSS's may be the same between two different NIDs, and there will be _no_ relationship between the two URNs. I can change it from ISSN/ISBN (though I'm not absolutely certain it's wrong -- if you pull the dashes from each, they become number strings, and is it absolutely the case that there might not happen to be 2 number strings that were the same?). > "a namespace may make use of an privately managed (proprietary) > registry (as, e.g., ISBN does)." (Section 3.3) Please clarify what aspect is wrong. > > 3. I am confused by the statement: 'even if an ISBN URN namespace is > created, it is not clear that all ISBNs will translate directly > into "assigned URNs".' What are you trying to say? ISBNs are assigned to all published books. It isn't clear (or at least, it wasn't before they published their proposed NID) that they would want every single ISBN to be converted into a URN. I.e., that if you found an ISBN, did some syntactic translation for converting it into URN:ISBN: it would produce a URN that ISBN considered "assigned", for which resolution services might be expected. I will clarify the point; it's an issue of relationship between existing naming schemes (for other purposes) and URNs as identifiers. THey may not map one-to-one. > > 4. I am greatly concerned about the following paragraph at the > end of section 4.3. > > "Registrations may be revised by updating the RFC through standard > 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." > > If the original authors are not involved, I believe that this is > process is woefully inadequate. This paragraph captures IETF RFC update policy. The IESG is unlikely to accept updates from random sources. The original authors are obviously the first place to start, but the namespace should not languish if there are clarifications needed and the original authors cannot be contacted. Thanks again, Leslie. -- ------------------------------------------------------------------- "The best laid plans are written in pencil." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- From owner-urn-ietf@LISTS.NETSOL.COM Thu Mar 29 12:16:27 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 MAA25299 for ; Thu, 29 Mar 2001 12:16:27 -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 MAA16515; Thu, 29 Mar 2001 12:03:40 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8702184 for URN-IETF@LISTS.NETSOL.COM; Thu, 29 Mar 2001 12:02:15 -0500 Received: from cs.sfu.ca (cs.sfu.ca [142.58.111.1]) by lists.netsol.com (8.9.3/8.9.3) with ESMTP id MAA16503 for ; Thu, 29 Mar 2001 12:02:14 -0500 (EST) Received: from orpheus.cs.sfu.ca (cameron@orpheus [199.60.3.24]) by cs.sfu.ca (8.9.1/8.9.1) with ESMTP id IAA21042; Thu, 29 Mar 2001 08:56:16 -0800 (PST) Received: (from cameron@localhost) by orpheus.cs.sfu.ca (8.9.1/8.9.1) id IAA02326; Thu, 29 Mar 2001 08:56:15 -0800 (PST) Approved-By: Rob Cameron Message-ID: <200103291656.IAA02326@orpheus.cs.sfu.ca> Date: Thu, 29 Mar 2001 08:56:15 -0800 Reply-To: Rob Cameron From: Rob Cameron Subject: Re: REMINDER [was Re: WG last call: draft-ietf-urn-rfc2611bis-02.txt] To: URN-IETF@LISTS.NETSOL.COM Hi, Leslie. Those familiar with ISSNs know that they are always 8 digits, while ISBNs are always 10 digits. Thus an ISSN cannot be the same as an ISBN. In practice, some library software systems have a combined ISBN/ISSN search, relying on the fact that they may be distinguished by length. It is not fair to characterize ISBNs as a privately managed proprietary space. ISBNs are managed by an international network of registration agencies. Each agency manages ISBNs for a particular language/country group. In many cases the registration agencies are national libraries. Even if not, the agency must effectively be operated as a public trust. Any publisher must be allowed to register for ISBN codes. A fee may be required but may be waived for charitable organizations. Charging of a fee does not make the namespace privately managed nor proprietary. The DNS namespace also requires payment of fees and I doubt that most in the IETF would consider it a privately managed, proprietary namespace. On the final point, we have been contemplating the registration of a namespace for the Universal Serial Item Names that we use with bibliographic protocol. I am very uncomfortable with the idea that once defined, the namespace could be modified with only a two week review period. From owner-urn-ietf@LISTS.NETSOL.COM Fri Mar 30 11:18:34 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 LAA23257 for ; Fri, 30 Mar 2001 11:17:56 -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 KAA28032; Fri, 30 Mar 2001 10:57:32 -0500 (EST) Received: from LISTS.NETSOL.COM by LISTS.NETSOL.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8704093 for URN-IETF@LISTS.NETSOL.COM; Fri, 30 Mar 2001 10:50:59 -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 HAA27102 for ; Fri, 30 Mar 2001 07:37:11 -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 HAA11029; Fri, 30 Mar 2001 07:31:17 -0500 (EST) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200103301231.HAA11029@ietf.org> Date: Fri, 30 Mar 2001 07:31:17 -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-net-procedures-07.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 : Assignment Procedures for the URI Resolution using DNS Author(s) : M. Mealling Filename : draft-ietf-urn-net-procedures-07.txt Pages : 10 Date : 29-Mar-01 RFCYYYY defines a how DNS is used as a DDDS database that contains URI delegation rules (sometimes called resolution hints). That document specifies that the first step in that algorithm is to append 'URI.ARPA' to the URI scheme and retrieve the NAPTR record for that domain-name. I.e., the first step in resolving 'http://foo.com/' would be to look up a NAPTR record for the domain 'http.URI.ARPA'. URN resolution also follows a similar procedure but uses the 'URN.ARPA' zone as its root. This document describes the procedures for inserting a new rule into the 'URI.ARPA' and 'URN.ARPA' zones. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-urn-net-procedures-07.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-net-procedures-07.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-net-procedures-07.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: <20010329145419.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-urn-net-procedures-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-urn-net-procedures-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010329145419.I-D@ietf.org> --OtherAccess-- --NextPart--