idnits 2.17.1 draft-ietf-urn-ietf-02.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-24) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 4 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 118: '...uest for "urn:ietf:std:51" MUST return...' RFC 2119 keyword, line 139: '...cters in the NSS MUST result in the re...' 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 (July 1997) is 9780 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2141 (ref. '1') (Obsoleted by RFC 8141) -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Ryan Moats 2 draft-ietf-urn-ietf-02.txt AT&T 3 Expires in six months July 1997 5 A URN Namespace for IETF Documents 6 Filename: draft-ietf-urn-ietf-02.txt 8 Status of This Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its 12 areas, and its working groups. Note that other groups may also 13 distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as ``work 19 in progress.'' 21 To learn the current status of any Internet-Draft, please check 22 the ``1id-abstracts.txt'' listing contained in the Internet- 23 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 24 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 25 Coast), or ftp.isi.edu (US West Coast). 27 Abstract 29 A system for Uniform Resource Names (URNs) must be capable of 30 supporting new naming systems. As an example of how a new namespace 31 may be proposed, this document presents a naming system based on the 32 RFC family of documents (RFCs, STDs, and FYIs) developed by the IETF 33 and published by the RFC editor and the minutes of working groups 34 (WG) and birds of a feather (BOF) meetings that occur during IETF 35 conferences. This namespace can be supported within the URN 36 framework and the currently proposed syntax for URNs. 38 1. Namespace Syntax 40 Consistent with the URN syntax specification [1], each namespace must 41 specify syntax related information that is specific to that 42 namespace. This section covers these specifications. 44 1.1. Namespace Identifier (NID) 46 The namespace identifier for this namespace is "ietf". 48 1.2. Namespace Specific String (NSS) 50 The Namespace Specific String has the following ABNF [2] 51 specification: 52 NSS = (family ":" number) / ("mtg-" number "-" wgbofname) 54 family = "rfc" / "std" / "fyi" 56 number = 1*DIGIT 58 wgbofname = 1*LETDIGIT 60 LETDIGIT = DIGIT / %x41..%x5a / %x61..%x7a 62 DIGIT = %x30..%x39 64 The ABNF specification for "family" is based on the current documents 65 in the RFC family. As new document series are added to the IETF 66 family by the IESG (or its successor), this ABNF specification will 67 need to be updated. Any system intended to resolve names for this 68 namespace should be written with the awareness that a new document 69 series may be introduced at any time. 71 The ABNF specification for "wgbofname" is based on the current and 72 past abbreviations for working groups and BOFs in the IETF. If a 73 working group or BOF is created that used characters outside the 74 range of this ABNF specification, this specification will need to be 75 updated. Any system intended to resolve names for this namespace 76 should be written with the awareness that this could occur at any 77 time. 79 1.3. Assignment of URNs in this Namespace 81 URNs are assigned in the namespace in two ways. The first is when a 82 new RFC, FYI or STD is passed by the IESG and published by the RFC 83 Editor. This new document will have a new series number and will 84 therefore define a new URN. The document mappings maintained by the 85 RFC Editor (the index files "rfc-index.txt", "fyi-index.txt", "std- 86 index.txt") are defined to be the definitive statement of the 87 assignment of RFC Family URNs in this namespace. 89 The second way a URN is assigned is when a working group or birds of 90 a feather files meeting minutes as part of an IETF conference. The 91 list of minutes maintained by the IETF for each working group and 92 conference in the subtree pointed at by the URL ftp://ietf.org/ietf/ 93 is considered the definitive assignment of URNs for working group or 94 birds of a feather minutes. 96 1.4. Additional Reserved Characters 98 No characters in addition to those specified in [1] are reserved by 99 this namespace. 101 1.5. Additional Lexical Equivalence Relations 103 Note that the entire URN is case-insensitive, because of the 104 definition of the NSS. 106 1.6. Functional Equivalence Relations 108 Rules for equivalence in this namespace are embedded in the document 109 mappings maintained by the RFC Editor (the index files "rfc- 110 index.txt", "fyi-index.txt", "std-index.txt"). A resource is 111 equivalent to the set of resources implied by the "(Also...)" 112 construct in these mappings. As an example, the URN 113 "urn:ietf:rfc:1661" is equivalent to th URN "urn:ietf:std:51" because 114 the "rfc-index.txt" map shows that RFC 1661 is also STD 51. However, 115 the URN "urn:ietf:std:51" is equivalent to the SET of URNs 116 "urn:ietf:rfc:1661" and "urn:ietf:rfc:1662" since the "std-index.txt" 117 shows that STD 51 is also RFC 1661 and RFC 1662. Therefore, a 118 resolver receiving a N2R request for "urn:ietf:std:51" MUST return 119 either STD 51 or BOTH RFC 1661 and RFC 1662. 121 2. Comments 123 Readers will notice that this namespace does not include internet 124 drafts. While these documents are published by the internet drafts 125 editor, they were excluded because they do not provide persistent 126 resources to refer to (all internet drafts expire after six months). 127 This is as opposed to the RFC family of documents which never expire 128 (an RFC may be obsoleted or superceded but the actual RFC document 129 itself does not expire). 131 3. Security Considerations 133 Because this namespace defines no additional reserved characters, it 134 does not add any security considerations beyond those inherent from 135 the existence of the reserved characters from [1]. Further, the 136 definition of the NSS above does not use any of the reserved 137 characters from [1], which means that resolvers for this namespace 138 may be considered "secure" in the sense that any escaping of 139 characters in the NSS MUST result in the resolver indicating that the 140 URN has incorrect syntax. 142 4. Acknowledgments 144 Thanks to various members of the URN working group for comments on 145 earlier drafts of this document. The work described in this document 146 is partially supported by the National Science Foundation, 147 Cooperative Agreement NCR-9218179. 149 4. References 151 Request For Comments (RFC) and Internet Draft documents are available 152 from and numerous mirror sites. 154 [1] R. Moats, "URN Syntax," RFC 2141, May 5, 1997. 156 [2] D. Crocker, P. Overell, "Augmented BNF for Syntax 157 Specifications: ABNF," Internet Draft (work in pro- 158 gress), January 1997. 160 5. Author's Address 162 Ryan Moats 163 AT&T 164 15621 Drexel Circle 165 Omaha, NE 68135-2358 166 USA 168 Phone: +1 402 894-9456 169 EMail: jayhawk@att.com 171 This Internet Draft expires January 31, 1998.