idnits 2.17.1 draft-rushing-s1000d-urn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 318. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 1, 2005) is 6752 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: '1' is defined on line 271, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 273, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 276, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 280, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 283, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (ref. '1') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2396 (ref. '2') (Obsoleted by RFC 3986) ** Obsolete normative reference: RFC 3406 (ref. '3') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2234 (ref. '4') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Rushing 3 Internet-Draft Inmedius 4 Expires: May 1, 2006 November 1, 2005 6 A URN Namespace for ASD Specification 1000D 7 draft-rushing-s1000d-urn-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on May 1, 2006 . 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document describes a Uniform Resource Name (URN) namespace for 41 naming persistent resources defined by ASD Specification 1000D. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Specification Template . . . . . . . . . . . . . . . . . . . . 3 47 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 48 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 49 5. Namespace Considerations and Community Considerations . . . . 7 50 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 51 7. Normative References . . . . . . . . . . . . . . . . . . . . . 7 52 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 53 Intellectual Property and Copyright Statements . . . . . . . . 9 55 1. Introduction 57 Specification 1000D (S1000D) is an international specification for 58 the procurement and production of technical publications. The 59 current issue of the specification has been jointly produced by the 60 Aerospace and Defence Industries Association of Europe (ASD. 61 Previously AECMA, European Association of Aerospace Industries) and 62 the Aerospace Industries Association of America (AIA). The 63 specification is used worldwide by a variety of commercial and 64 government entities for the development of technical documentation. 66 The specification adopts ISO, CALS and W3C standards to promote 67 document standardization in which information is generated in a 68 neutral format. Compliant documentation generated using the 69 specification can be processed on different, and often disparate, IT 70 systems. It is this feature, added to the concept of modularization, 71 which makes the specification acceptable to the wider international 72 community. 74 Portions of S1000D define a resource coding system to allow resources 75 created under the specification to be uniquely identified in global 76 environment. To provide for the creation of a web-based resource 77 management system, ASD would like to assign URNs to resources created 78 under the specification in order to retain unique, permanent, 79 location-independent names for these resources, in addition to 80 providing a framework for resolution of these resources. 82 For more information about ASD and S1000D see http://www.s1000d.org. 84 This namespace specification is for a formal namespace. 86 2. Specification Template 88 Namespace ID: 90 To be assigned. Request the string "S1000D". 92 Registration information: 94 Version 2 95 Date: <2005-03-7, when submitted> 97 Declared registrant of the namespace: 99 Name: 100 ASD TPSMG Chairperson 101 Address: 102 Corporate Technical Services 103 Technical Documentation 104 Kentigern House 105 65 Brown Street 106 Glasgow G2 8EX 107 UK 108 Contact: 109 Mr. Dennis Hoyland 110 E-mail: adcts@techinfo.mod.uk 112 Declaration of structure: 114 The identifier has the following ABNF structure. 116 ;start ABNF notation 118 URN = "URN:" namespace NSS 120 namespace = "S1000D:" 122 NSS = dmc-nss / pmc-nss / csn-nss / icn-nss 123 com-nss / ddn-nss / dml-nss 125 ;Define the subnamespace as an subnamespace identifer 126 ;plus a subnamespace code string 127 dmc-nss = "DMC-" nss-code 128 pmc-nss = "PMC-" nss-code 129 csn-nss = "CSN-" nss-code 130 icn-nss = "ICN-" nss-code 131 com-nss = "COM-" nss-code 132 ddn-nss = "DDN-" nss-code 133 dml-nss = "DML-" nss-code 135 ;Define the subnamespace code as a string encoded to the 136 ;format specified by the namespace identifier and an 137 ;optional extension string indicating the resource status. 138 nss-code = subcode subext 140 ;The code strings are a groups of alpha and digit characters 141 ;separated by the dash character. The specific code syntax 142 ;for each subnamespace is decribed in ASD Specification 1000D. 143 subcode = 1*(DIGIT / ALPHA / "-") 145 ;Define the encoding extension as an optional set of status 146 ;indicators separated by the "_" character. 147 subext = [issue] [lang] 148 issue = "_I-" 3DIGIT 149 lang = "_L-" 2ALPHA 150 ;ABNF core rules RFC 2234, listed for clarity 151 ;ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 152 ;DIGIT = %x30-39 ; 0-9 154 ;end ABNF notation 156 The following subnamespaces are currently defined: 158 "DMC" - contains all Data Modules Codes 159 "PMC" - contains all Publication Module Codes 160 "CSN" - contains all Catalogue Sequence Numbers 161 "ICN" - contains all Illustration Control Numbers. 162 "COM" - contains all Comment Codes. 163 "DDN" - contains all Data Dispatch Notices. 164 "DML" - contains all Data Module Lists. 166 Example usage: 168 URN:S1000D:{subid}-{subcode}_{subext} 170 e.g., URN:S1000D:DMC-AE-A-07-05-0000-00A-040A-A_I-001_L-EN 172 where: 173 {subid} = DMC, The code is a Data Module Code 174 {subcode} = AE-A-07-05-0000-00A-040A-A, String in DMC syntax 175 {subext} = _I-001_L-EN, the first issue in English. 177 Relevant ancillary documentation: 179 ASD S1000D, Issue 2.2 180 Reference: Chap 7.4.1.2, "IETP - Resource resolution" 181 url: http://www.s1000d.org 183 Identifier uniqueness considerations: 185 Identifier uniqueness is guaranteed through processes outlined 186 within ASD S1000D. All codes defined within the specification 187 must begin with a Model Identifier (MI) that will be registered 188 with the NATO Maintenance and Supply Agency (NAMSA) and is never 189 to be reused. All project generated codes are prefixed by the 190 assigned MI and are required by the specification to be unique 191 within the scope of the project. Since all project codes are 192 prefixed by a globally unique MI, and since these codes must be 193 unique within the project, all generated identifiers will 194 be globally unique. 196 Identifier persistence considerations: 198 Persistence of identifiers is dependent upon suitable delegation 199 of resolution and the fact that generated identifiers are to be 200 persistent once published. Existing information objects can be 201 used in new projects by referencing them through their 202 persistent identifiers. 204 Process of identifier assignment: 206 Identifiers are assigned in the following manner. Projects are 207 assigned a Model Identifier by the NAMSA organization. Projects 208 then generate identifiers using the processes outlined in 209 ASD S1000D. The codes are prefixed with the encoding 210 identifier and possibly postfixed by the extension status 211 identifiers. 213 Process for identifier resolution: 215 The project identified by the Model Identifier is responsible for 216 providing a method of resource resolution. A suggested method of 217 resolution is outlined in ASD S1000D. 219 Rules for Lexical Equivalence: 221 All generated identifiers are to be considered are case- 222 insensitive. 224 Conformance with URN syntax: 226 No special considerations. 228 Validation mechanism: 230 Identifiers must conform to ASD S1000D. 232 Scope: 234 Global. 236 3. Examples 238 The following examples are not guaranteed to be real and are provided 239 for illustrative purposes only. 241 URN:S1000D:DMC-AE-A-07-04-0101-00A-040A-A 242 URN:S1000D:DMC-AE-A-07-05-0000-00A-040A-A_I-001_L-EN 243 URN:S1000D:ICN-AE-B-291101-M-C0419-00571-A-01-1 244 URN:S1000D:PMC-AE-F6117-00001-00 246 4. Security Considerations 248 There are no additional security considerations other than those 249 normally associated with the use and resolution of URNs in general. 251 5. Namespace Considerations and Community Considerations 253 Resources will be named and maintained in accordance with the 254 processes described in this document, in addition to the processes 255 described in S1000D. Any organization or individual can utilize the 256 specification to create resources described by S1000D. Resolution 257 and/or use of created resources is unrestricted by the specification 258 in order to promote widespread adoption of open ASD standards, 259 although organizations creating resources may control them as they 260 see fit. 262 6. IANA Considerations 264 This document describes a "S1000D" URN NID registration for the 265 S1000D organization and will need to be entered into the IANA 266 registry of URN NIDs upon approval. 267 (http://www.iana.org/assignments/urn-namespaces). 269 7. Normative References 271 [1] Moats, R., "URN Syntax", RFC 2141, May 1997. 273 [2] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource 274 Identifiers (URI): Generic Syntax", RFC 2396, August 1998. 276 [3] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, 277 "Uniform Resource Names (URN) Namespace Definition Mechanisms", 278 BCP 66, RFC 3406, October 2002. 280 [4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 281 Specifications: ABNF", RFC 2234, November 1997. 283 [5] "ASD Specification 1000D", May 2005. 285 Author's Address 287 Sean Rushing 288 Inmedius, Inc. 289 2710 South Kolb Road 290 Tucson, AZ 85730 291 USA 293 Phone: +01 520 747 3955 294 Email: srushing@inmedius.com 296 Intellectual Property Statement 298 The IETF takes no position regarding the validity or scope of any 299 Intellectual Property Rights or other rights that might be claimed to 300 pertain to the implementation or use of the technology described in 301 this document or the extent to which any license under such rights 302 might or might not be available; nor does it represent that it has 303 made any independent effort to identify any such rights. Information 304 on the procedures with respect to rights in RFC documents can be 305 found in BCP 78 and BCP 79. 307 Copies of IPR disclosures made to the IETF Secretariat and any 308 assurances of licenses to be made available, or the result of an 309 attempt made to obtain a general license or permission for the use of 310 such proprietary rights by implementers or users of this 311 specification can be obtained from the IETF on-line IPR repository at 312 http://www.ietf.org/ipr. 314 The IETF invites any interested party to bring to its attention any 315 copyrights, patents or patent applications, or other proprietary 316 rights that may cover technology that may be required to implement 317 this standard. Please address the information to the IETF at 318 ietf-ipr@ietf.org. 320 Disclaimer of Validity 322 This document and the information contained herein are provided on an 323 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 324 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 325 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 326 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 327 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 328 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 330 Copyright Statement 332 Copyright (C) The Internet Society (2005). This document is subject 333 to the rights, licenses and restrictions contained in BCP 78, and 334 except as set forth therein, the authors retain all their rights. 336 Acknowledgment 338 Funding for the RFC Editor function is currently provided by the 339 Internet Society.