idnits 2.17.1 draft-ietf-urn-ietf-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-20) 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 97: '...uest for "urn:ietf:std:51" MUST return...' RFC 2119 keyword, line 108: '...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 (May 1997) is 9837 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-00.txt AT&T 3 Expires in six months May 1997 5 URN Namespace for RFC series documents 6 Filename: draft-ietf-urn-ietf-00.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 the sort of 31 information that needs to be supplied when proposing new namepsaces, 32 this document presents a naming system based on the RFC family of 33 documents (RFCs, STDs, and FYIs) developed by the IETF and published 34 by the RFC editor. This namespace can be supported within the URN 35 framework and the currently proposed syntax for URNs. 37 0. Document History and Status 39 With the first draft of this document, the only issue that has 40 occured on the list is the discussion on functional equivalence for 41 this namespace (see section 1.5). There are currently two positions 42 on this: the first is what is specified here, and the second is that 43 there is no equivalency for this namespace, e.g. a resolver receiving 44 a request must return ONLY the resource named by that request. 46 1. Namespace Syntax 48 Consistent with the URN syntax specification [1], each namespace must 49 specify syntax related information that is specific to that 50 namespace. This section covers these specifications. 52 1.1. Namespace Identifier (NID) 54 The namespace identifier for this namespace is "ietf". 56 1.2. Namespace Specific String (NSS) 58 The Namespace Specific String has the following ABNF [2] 59 specification: 60 NSS = family ":" number 62 family = "rfc" | "std" | "fyi" 64 number = 1*DIGIT 66 DIGIT = %x30..%x39 68 The ABNF specification for "family" above is based on the current 69 documents in the RFC family. As new document series are added to the 70 IETF family by the IESG (or its successor), this ABNF specification 71 will need to be updated. Any system intended to resolve names for 72 this namespace should be written with the awareness that a new 73 document series may be introduced at any time. 75 1.3. Additional Reserved Characters 77 No characters in addition to those specified in [1] are reserved by 78 this namespace. 80 1.4. Additional Lexical Equivalence Relations 82 Note that the entire URN is case-insensitive, because of the 83 defintion of the NSS. 85 1.5. Functional Equivalence Relations 87 Rules for equivalence in this namespace are embedded in the document 88 mappings maintained by the RFC Editor (the index files "rfc- 89 index.txt", "fyi-index.txt", "std-index.txt"). A resource is 90 equivalent to the set of resources implied by the "(Also...)" 91 construct in these mappings. As an example, the URN 92 "urn:ietf:rfc:1661" is equivalent to th URN "urn:ietf:std:51" because 93 the "rfc-index.txt" map shows that RFC 1661 is also STD 51. However, 94 the URN "urn:ietf:std:51" is equivalent to the SET of URNs 95 "urn:ietf:rfc:1661" and "urn:ietf:rfc:1662" since the "std-index.txt" 96 shows that STD 51 is also RFC 1661 and RFC 1662. Therefore, a 97 resolver receiving a N2R request for "urn:ietf:std:51" MUST return 98 either STD 51 or BOTH RFC 1661 and RFC 1662. 100 2. Security Considerations 102 Because this namespace defines no additional reserved characters, it 103 does not add any security considerations beyond those inherent from 104 the existence of the reserved characters from [1]. Further, the 105 definition of the NSS above does not use any of the reserved 106 characters from [1], which means that resolvers for this namespace 107 may be considered "secure" in the sense that any escaping of 108 characters in the NSS MUST result in the resolver indicating that the 109 URN has incorrect syntax. 111 3. Acknowledgments 113 Thanks to various members of the URN working group for comments on 114 earlier drafts of this document. This document is partially 115 supported by the National Science Foundation, Cooperative Agreement 116 NCR-9218179. 118 4. References 120 Request For Comments (RFC) and Internet Draft documents are available 121 from and numerous mirror sites. 123 [1] R. Moats, "URN Syntax," RFC 2141, May 5, 1997. 125 [2] D. Crocker, P. Overell, "Augmented BNF for Syntax 126 Specifications: ABNF," Internet Draft (work in pro- 127 gress), January 1997. 129 5. Author's Address 131 Ryan Moats 132 AT&T 133 15621 Drexel Circle 134 Omaha, NE 68135-2358 135 USA 137 Phone: +1 402 894-9456 138 EMail: jayhawk@att.com 140 This Internet Draft expires November 30, 1997.