idnits 2.17.1 draft-ietf-urn-net-procedures-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 1) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of lines with control characters in the document. == There is 2 instances of lines with non-RFC2606-compliant FQDNs in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 71: '...e urn.net registration procedures MUST...' RFC 2119 keyword, line 133: '...ioned URL scheme or URN namespace MUST...' RFC 2119 keyword, line 147: '...sent to the list MUST contain the foll...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 1998) is 9447 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2168 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 1738 (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 2048 (Obsoleted by RFC 4288, RFC 4289) Summary: 14 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 URN Working Group M.Mealling 2 INTERNET-DRAFT Network Solutions, Inc. 3 Expires six months from June 1998 4 Intended category: Experimental 5 draft-ietf-urn-net-procedures-00.txt 7 Assignment Procedures for the URI Resolution using DNS (RFC2168) 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at 18 any time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as work in progress. 21 To view the entire list of current Internet-Drafts, please check 22 the "1id-abstracts.txt" listing contained in the Internet-Drafts 23 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 24 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 25 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 26 (US West Coast). 28 Abstract 30 RFC2168 defines a DNS resource record and an algorithm for using DNS 31 as a registry for retrieving URN authority delegation rules (sometimes 32 called resolution hints). That document specifies that the first step 33 in that algorithm is to lookup the first NAPTR record for the namespace- 34 id in the "urn.net" zone; i.e., the first step in resolving 35 "urn:ietf:rfc:2168" would be to lookup a NAPTR record for the domain 36 "ietf.urn.net". This document describes the procedures for inserting 37 a new rule into this DNS-based URI resolution registry. 39 1. Introduction 41 In the course of defining a resolution mechanism [RFC2168] according 42 to the rules in RFC2276 [RFC2276] for Uniform Resource Names [RFC2141], 43 it became apparent that the same system could be used to resolve 44 URIs [RFC1738] in the general case. Thus, RFC2168 was specified in 45 such a way as to be generic in its discussions of URNs vs URLs. The 46 end result of this is that RFC2168 defines two things: a Resolver 47 Discovery System registry for URNs and a resolver discovery system 48 for URLs. While this may not seem an important distinction to the 49 casual reader there are some important distinctions in terms of 50 creating new URN namespaces and new URI schemes. Thus, its 51 assignment procedures for the RFC2168 defines registry must adhere 52 to the procedures defined in the assignment documents of both systems. 54 At the same time this document must also define its own procedures, 55 which will ensure its stability and impact on the Domain Name System. 56 These include optimizations such as an extremely long time to live 57 on the values in the urn.net zone and efficient uses of delegations 58 to minimize delegation loops. 60 2. URL Resolution 62 At this time there is no set procedure for registering new URL schemes 63 other than a published RFC. Due to this lack and the existence of 64 non-published schemes such as "about" and "res", there is an IETF 65 working group discussing how to deal with this problem. Thus, at 66 this time the only requirements for requesting an entry in the urn.net 67 zone is that the URL scheme be published or in use somewhere and that 68 it not conflict with an existing URL scheme. 70 When the IETF does standardize a set of procedures for vetting and 71 registering new URL schemes, the urn.net registration procedures MUST 72 adhere to those procedures for determining if the URL scheme in question 73 is valid. 75 3. URN Resolution 77 RFCXXXX defines the procedures for assignment of new URN namespace-ids. 78 Since the urn.net registration procedures only deal with the 79 namespace-id portion of the URN space, that document is the sole 80 determining document for what can be entered into the urn.net zone 81 for a URN. 83 4. Delegation Requirements 85 Delegation of a namespace can happen in two ways. In the case of 86 a URL where the entity being delegated to is hard-coded into the 87 identifier itself, the syntax of where this is located is set. 88 In the case where the entity being delegated to is set in the rule, 89 that entity can change as the rule changes. 91 One of the optimizations that the urn.net registry attempts to make 92 is that any entry in that zone should have an extremely long 93 time to live. 'Extremely long' should be measured in years if possible. 94 Thus, any rule that can change must be delegated out of the urn.net 95 zone by a replacement rule in the NAPTR record. For example, the 'foo' 96 URN namespace has flexible rules for how delegation takes place. Instead 97 of putting those rules in the urn.net zone, the entry instead punts 98 those rules off to a nameserver that has a shorter time to live. The 99 record in urn.net would look like this: 101 foo IN NAPTR 100 10 "" "" "" urn-resolver.foo.com. 103 Thus, when the client starts out in the resolution process, the second 104 step is to begin asking 'urn-resolver.foo.com' for the NAPTR records 105 that contain the resolution rules. 107 Conversely, the 'http' URL scheme adheres to a particular syntax that 108 specifies that the host to ask is specified in the URL in question. 109 Since this syntax does not change, that rule can be specified in the 110 urn.net zone. The record would look like this: 112 http IN NAPTR 100 100 "" "" "/http:\\/\\/([^\\/:]+)/\\2/i" . 114 Thus, the second step of resolution is to attempt to contact the 115 host contained in the URL itself. 117 5. Submission Procedure 119 Using the MIME Content-Type registration mechanism [RFC2048] as a 120 model for a successful registration mechanism, the urn.net procedure 121 consists of a request template submitted to a open mailing list 122 made up of interested parties. If no objections are made within 123 a two week period, a representative of the urn.net registration 124 authority considers the submission to be accepted and enters 125 that submission into the nameserver. 127 At this time the registration authority is expected to be the IANA. 129 Objections are restricted to those that point out impacts on 130 the urn.net zone itself or to DNS in general. Objections to the URL 131 scheme or to the URN namespace-id are not allowed, as these should 132 be raised in their respective forums. The logical conclusion of 133 this is that ANY sanctioned URL scheme or URN namespace MUST 134 be allowed to be registered if it meets the requirements specified 135 in this document as regards times to live and general impact 136 to the DNS. 138 Updating a record in the urn.net zone also requires that the same 139 process to be followed. Since urn.net is designed with a long time to 140 live, changes to records in that zone are discouraged. Thus updates 141 must follow the same procedures as a new request. Changes will 142 be given a higher level of scrutiny, as they may represent 143 potential problems with a specific delegation. 145 6. Registration Template 147 The template to be sent to the list MUST contain the following 148 values: 150 6.1 Type 152 Either SCHEME or NID. SCHEME specifies that the record being registered 153 represents a URL scheme. NID specifies that it is a URN namespace-id. 155 6.2 Key 157 This is the domain portion. It must be valid according to the 158 procedures specified in the URN namespace-id assignment document 159 and any future standards for registering new URL schemes. 161 6.3 Authority 163 This is the authority doing the registration of the record. It must 164 be an authority recognized as either the IESG or an authority 165 specified in the documents submitted for approval by any URN or URL 166 registration mechanism. 168 6.4 Records 170 One or more records representing the rule set for the key. The required 171 values are Preference, Order, Flags, Services, Regex, and Replacement 172 as defined by RFC2168. 174 7. Example Template 176 To: register@urn.net 177 From: joe@foo.com 179 Type: NID 180 Key: foo 181 Authority: Foo Technology, Inc as specified in RFCFOO 182 Record: foo IN NAPTR 100 100 "" "" "" urn.foo.com. 184 8. IANA Considerations 186 This document describes a mechanism for registering representations of 187 protocol items that have already been registered with some IETF 188 sanctioned agency (probably the IANA as well). This means that the IANA 189 need not determine appropriateness of the underlying namespaces, 190 since that is determined by another process. 192 The only real impact on the IANA will be: 194 to maintain (or designate some other entity to maintain) a primary 195 nameserver for the urn.net zone; 197 to maintain the mailing list "register@urn.net" as the forum for 198 discussions of submissions; and 200 to act as the party that determines if all objections have been 201 noted and accommodated. 203 7. References 205 [RFC2168] Ron Daniel & Michael Mealling, "Resolution of Uniform 206 Resource Identifiers using the Domain Name System", RFC 2168, 207 June 1997. 209 [RFC2276] K. Sollins, "Architectural Principles of Uniform Resource 210 Name Resolution", RFC 2276, January 1998. 212 [RFC2141] Ryan Moats, "URN Syntax", RFC 2141, May 1997. 214 [RFC1738] T. Berners-Lee, L. Masinter and M. McCahill, 215 "Uniform Resource Locators (URL)" RFC 1738, December 1994. 216 218 [RFC2048] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet 219 Mail Extensions (MIME) Part Four: Registration Procedures", 220 RFC 2048, November 1996. 222 8. Author Contact Information 224 Michael Mealling 225 Network Solutions 226 505 Huntmar Park Drive 227 Herndon, VA 22070 228 voice: (703) 742-0400 229 fax: (703) 742-9552 230 email: michaelm@rwhois.net 232 This document expires 6 months from June, 1997