idnits 2.17.1 draft-ietf-urn-ietf-01.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 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 102: '...uest for "urn:ietf:std:51" MUST return...' RFC 2119 keyword, line 113: '...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 (June 1997) is 9812 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. -------------------------------------------------------------------------------- 2 Internet-Draft Ryan Moats 3 draft-ietf-urn-ietf-01.txt AT&T 4 Expires in six months June 1997 6 A URN Namespace for IETF Documents 7 Filename: draft-ietf-urn-ietf-01.txt 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 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet- 19 Drafts as reference material or to cite them other than as ``work 20 in progress.'' 22 To learn the current status of any Internet-Draft, please check 23 the ``1id-abstracts.txt'' listing contained in the Internet- 24 Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net 25 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 26 Coast), or ftp.isi.edu (US West Coast). 28 Abstract 30 A system for Uniform Resource Names (URNs) must be capable of 31 supporting new naming systems. As an example of the sort of 32 information that needs to be supplied when proposing new namepsaces, 33 this document presents a naming system based on the RFC family of 34 documents (RFCs, STDs, and FYIs) developed by the IETF and published 35 by the RFC editor and the minutes of working groups (WG) and birds of 36 a feather (BOF) meetings that occur during IETF conferences. This 37 namespace can be supported within the URN framework and the currently 38 proposed syntax for URNs. 40 1. Namespace Syntax 42 Consistent with the URN syntax specification [1], each namespace must 43 specify syntax related information that is specific to that 44 namespace. This section covers these specifications. 46 1.1. Namespace Identifier (NID) 48 The namespace identifier for this namespace is "ietf". 50 1.2. Namespace Specific String (NSS) 52 The Namespace Specific String has the following ABNF [2] 53 specification: 54 NSS = (family ":" number) / ("mtg-" number "-" wgbofname) 56 family = "rfc" / "std" / "fyi" 58 number = 1*DIGIT 60 wgbofname = 1*LETDIGIT 62 LETDIGIT = DIGIT / %x41..%x5a / %x61..%x7a 64 DIGIT = %x30..%x39 66 The ABNF specification for "family" is based on the current documents 67 in the RFC family. As new document series are added to the IETF 68 family by the IESG (or its successor), this ABNF specification will 69 need to be updated. Any system intended to resolve names for this 70 namespace should be written with the awareness that a new document 71 series may be introduced at any time. 73 The ABNF specification for "wgbofname" is based on the current and 74 past abbreviations for working groups and BOFs in the IETF. If a 75 working group or BOF is created that used characters outside the 76 range of this ABNF specification, this specification will need to be 77 update. Any system intended to resolve names for this namespace 78 should be written with the awareness that this could occur at any 79 time. 80 1.3. Additional Reserved Characters 82 No characters in addition to those specified in [1] are reserved by 83 this namespace. 85 1.4. Additional Lexical Equivalence Relations 87 Note that the entire URN is case-insensitive, because of the 88 definition of the NSS. 90 1.5. Functional Equivalence Relations 92 Rules for equivalence in this namespace are embedded in the document 93 mappings maintained by the RFC Editor (the index files "rfc- 94 index.txt", "fyi-index.txt", "std-index.txt"). A resource is 95 equivalent to the set of resources implied by the "(Also...)" 96 construct in these mappings. As an example, the URN 97 "urn:ietf:rfc:1661" is equivalent to th URN "urn:ietf:std:51" because 98 the "rfc-index.txt" map shows that RFC 1661 is also STD 51. However, 99 the URN "urn:ietf:std:51" is equivalent to the SET of URNs 100 "urn:ietf:rfc:1661" and "urn:ietf:rfc:1662" since the "std-index.txt" 101 shows that STD 51 is also RFC 1661 and RFC 1662. Therefore, a 102 resolver receiving a N2R request for "urn:ietf:std:51" MUST return 103 either STD 51 or BOTH RFC 1661 and RFC 1662. 105 2. Security Considerations 107 Because this namespace defines no additional reserved characters, it 108 does not add any security considerations beyond those inherent from 109 the existence of the reserved characters from [1]. Further, the 110 definition of the NSS above does not use any of the reserved 111 characters from [1], which means that resolvers for this namespace 112 may be considered "secure" in the sense that any escaping of 113 characters in the NSS MUST result in the resolver indicating that the 114 URN has incorrect syntax. 116 3. Acknowledgments 118 Thanks to various members of the URN working group for comments on 119 earlier drafts of this document. The work described in this document 120 is partially supported by the National Science Foundation, 121 Cooperative Agreement NCR-9218179. 123 4. References 125 Request For Comments (RFC) and Internet Draft documents are available 126 from and numerous mirror sites. 128 [1] R. Moats, "URN Syntax," RFC 2141, May 5, 1997. 130 [2] D. Crocker, P. Overell, "Augmented BNF for Syntax 131 Specifications: ABNF," Internet Draft (work in pro- 132 gress), January 1997. 134 5. Author's Address 136 Ryan Moats 137 AT&T 138 15621 Drexel Circle 139 Omaha, NE 68135-2358 140 USA 141 Phone: +1 402 894-9456 142 EMail: jayhawk@att.com 144 This Internet Draft expires December 31, 1997.