idnits 2.17.1 draft-ietf-urn-syntax-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 5 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 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 120: '...rs>). Such strings MUST be translated...' RFC 2119 keyword, line 129: '... Namespaces MAY designate one or mor...' RFC 2119 keyword, line 141: '...are applications MAY accept as input o...' RFC 2119 keyword, line 144: '..., the identifier MUST be translated to...' RFC 2119 keyword, line 152: '...egistration documentation, MUST define...' (5 more instances...) 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 (November 1996) is 10024 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) == Unused Reference: '3' is defined on line 236, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 1737 (ref. '2') ** Downref: Normative reference to an Informational RFC: RFC 1630 (ref. '3') ** Obsolete normative reference: RFC 1738 (ref. '4') (Obsoleted by RFC 4248, RFC 4266) Summary: 12 errors (**), 0 flaws (~~), 4 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-syntax-01.txt AT&T 4 Expires in six months November 1996 6 URN Syntax 7 Filename: draft-ietf-urn-syntax-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 Uniform Resource Names (URNs) are intended to serve as persistent 31 resource identifiers. This document sets forward the canonical syntax 32 for URNs. Support for both existing legacy and new namespaces is 33 discussed. Requirements for URN presentation and transmission are 34 presented. Finally, there is a discussion of URN equivalence and how 35 to determine it. 37 1. Introduction 39 Uniform Resource Names (URNs) are intended to serve as persistent 40 resource identifiers and are designed to make it easy to map other 41 namespaces (which share the properties of URNs) into URN-space. The 42 URN syntax therefore provides a means to encode character data in a 43 form that can be sent in existing protocols, transcribed on most 44 keyboards, etc. 46 2. Syntax 48 All URNs have the following syntax: 50 ::= ["urn:"] ":" 52 is the Namespace Identifier, and is the Namespace 53 Specific String. The leading case-insensitive "urn:" sequence is 54 currently optional, as no closure on its definite presence or absence 55 has been reached. The Namespace ID is used to determine the 56 _syntactic_ interpretation of the Namespace Specific String (as 57 discussed in [1]). 59 RFC 1737 [2] presents additional requirements on URN encoding, which 60 all have implications as far as limiting syntax. On the other hand, 61 the requirement to support existing legacy naming systems has the 62 effect of broadening syntax. Thus, we discuss the acceptable syntax 63 for both the Namespace Identifier and the Namespace Specific String 64 separately. 66 2.1 Namespace Identifier Syntax 68 The following is the syntax for the Namespace Identifier. To (a) be 69 consistent with all potential resolution schemes and (b) not put any 70 undue constraints on any potential resolution scheme, the syntax for 71 the Namespace Identifier is: 73 ::= [ ] 75 ::= | "-" | 77 ::= any one of the 52 alphabetic characters A through Z 78 in upper case and a through z in lower case 80 This is slightly more restrictive that what is stated in RFC 1738 [4] 81 (which allows the period "."). Further, the Namespace Identifier is 82 case insensitive, so that "ISBN" and "isbn" refer to the same 83 namespace. 85 To avoid confusion with the optional "urn:" identifier, the NID "urn" 86 is reserved and may not be used. 88 2.2 Namespace Specific String Syntax 90 As required by 1737, there is a single canonical representation of 91 the NSS portion of an URN. The format of this single canonical form 92 follows: 94 ::= * 96 ::= | "%" 98 ::= | | | 100 ::= | "A" | "B" | "C" | "D" | "E" | "F" 102 ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | 103 "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | 104 "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | 105 "Y" | "Z" 107 ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | 108 "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" | 109 "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" | 110 "y" | "z" 112 ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | 113 "8" | "9" 115 ::= "(" | ")" | "+" | " 116 ":" | "=" | "?" | "@" 118 Depending on the rules governing a namespace, valid identifiers in a 119 namespace might contain characters that are not members of the URN 120 character set above (). Such strings MUST be translated 121 into canonical NSS format before using them as protocol elements or 122 otherwise passing them on to other applications. Translation is done 123 by encoding each character outside the URN character set as a 124 sequence of one to six octets using UTF-8 encoding, and the encoding 125 of each of those octets as "%" followed by two characters from the 126 character set above. The two characters give the hexadecimal 127 representation of that octet. 129 Namespaces MAY designate one or more characters from the URN 130 character set as having special meaning for that namespace. If the 131 namespace also uses that character in a literal sense as well, the 132 character used in a literal sense must be encoded with "%" followed 133 by the hexadecimal representation of that octet. Therefore, the 134 process of registering a namespace identifier shall include 135 publication of a definition of which characters have a special 136 meaning and how to encode these characters if used in a literal 137 sense. 139 3. Support of existing legacy naming systems and new naming systems 141 URN-aware applications MAY accept as input other resource identifiers 142 from existing legacy namespaces. If such identifiers contain 143 characters that are not members of the URN character set specified in 144 section 2.2, the identifier MUST be translated to canonical format as 145 discussed in section 2.2. 147 Some existing name spaces that have the properties of the URN-space 148 contain some human-significant components, and these exist in a wide 149 variety of languages. However, URNs are NOT intended to convey 150 information that is significant to humans. While the translation 151 rule in section 2.2 is provided for existing namespaces, new 152 namespaces, as part of their registration documentation, MUST define 153 a discipline for assigning new URNs that does not simplify the 154 generation of human-significant names. 156 4. URN presentation and transport 158 URN-aware applications MAY support "natural" display of URNs which 159 contain characters encoded using "%" notation. However, they MUST 160 provide for display of URNs in canonical form (i.e. in a format 161 suitable for transcription). 163 URNs may only be transported in canonical format. 165 5. Equivalence in URNs 167 URNs are considered equivalent if they return the same resource. For 168 various purposes, such as caching, a test is necessary to determine 169 equivalence without actually resolving the URNs and fetching/comparing 170 the underlying resources. "Lexical equivalence" is a stricter condition 171 that the equivalence described above (functional equivalence). 173 5.1 Lexical Equivalence 175 Lexical equivalence may be determined by comparing two URNs without 176 making any network accesses. Two URNs are lexically equivalent if 177 they are octet-by-octet equal after the following preprocessing 179 1. drop any preceding "urn:" token 180 2. normalize the case of the NID 182 Some namespaces may define additional lexical equivalences, such as 183 case-insensitivity of the NSS (or parts thereof). Additional lexical 184 equivalences MUST be documented as part of namespace registration, 185 MUST always have the effect of eliminating some of the false 186 negatives obtained by the procedure above, and MUST NEVER says that 187 two URNs are not equivalent if the procedure above says they are 188 equivalent. 190 5.2 Functional Equivalence 192 Resolvers determine functional equivalence based on specific rules 193 for the namespace. Therefore, namespace registration must include 194 documentation on how to determine functional equivalence for that 195 namespace. 197 5.3 Examples 199 The following URN comparisons highlight the difference between these 200 types of equivalence: 202 urn:isbn:1-23485-8-29, isbn:1-23485-8-29 are lexically equiv. 203 urn:isbn:1-23485-8-29, ISBN:1-23485-8-29 are lexically equiv. 204 urn:isbn:1-23485-8-29, isbn:123485829 are not lexically equiv. 205 but may be functionally equivalent. 207 6. Security considerations 209 Because of the number of potential namespaces, it must be restated 210 that certain of the characters in the Namespace Specific String may 211 have special meaning to certain namespace resolvers. The process of 212 registering a namespace identifier shall therefore include 213 publication of a definition of which characters have a special 214 meaning. 216 7. Acknowledgments 218 Thanks to various members of the URN working group and <> for comments on earlier drafts of this document. This 220 document is partially supported by the National Science Foundation. 222 8. References 224 Request For Comments (RFC) and Internet Draft documents are available 225 from and numerous mirror sites. 227 [1] L. L. Daigle, P. Faltstrom, R. Iannella. "A Frame- 228 work for the Assignment and Resolution of Uniform 229 Resource Names," Internet Draft (work in progress). 230 June 1996. 232 [2] K. Sollins, L. Masinter. "Functional Requirements 233 for Uniform Resource Names," RFC 1737. December 234 1994. 236 [3] T. Berners-Lee. "Universal Resource Identifiers in 237 WWW," RFC 1630. June 1994. 239 [4] T. Berners-Lee, L. Masinter, M. McCahill. "Uniform 240 Resource Locators (URL)," RFC 1738. December 1994. 242 9. Editor's address 244 Ryan Moats 245 AT&T 246 15621 Drexel Circle 247 Omaha, NE 68135-2358 248 USA 250 Phone: +1 402 894-9456 251 EMail: jayhawk@ds.internic.net 253 This Internet Draft expires May 19, 1997.