idnits 2.17.1 draft-murdock-nato-nid-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 5, 2015) is 3370 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2141 (ref. '1') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3406 (ref. '2') (Obsoleted by RFC 8141) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft A. Murdock 2 Intended status: Informational NATO C&I Agency 3 Expires: July 5, 2015 January 5, 2015 5 URN Namespace for the North Atlantic Treaty Organization (NATO) 6 draft-murdock-nato-nid-03.txt 8 Status of this Memo 10 This Internet-Draft is submitted in full conformance with the 11 provisions of BCP 78 and BCP 79. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 This Internet-Draft will expire on July 5, 2015. 31 Copyright Notice 33 Copyright (c) 2015 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. 43 Abstract 45 This document allocates a formal Uniform Resource Name (URN) 46 namespace for assignment by the North Atlantic Treaty Organization 47 (NATO), as specified in RFC 3406. The current primary use is for 48 uniquely identifying Extensible Markup Language (XML) artifacts 49 that provide information about NATO message text formats and 50 service specifications as described in various NATO standards, 51 instructions and publications. 53 Table of Contents 55 1. Introduction ................................................ 2 56 2. Specification Template ...................................... 3 57 2.1. Namespace ID ........................................... 3 58 2.2. Registration Information ............................... 3 59 2.3. Declared Registrant of the Namespace ................... 3 60 2.4. Declaration of Syntactic Structure ..................... 3 61 2.5. Relevant Ancillary Documentation ....................... 4 62 2.6. Identifier Uniqueness Considerations ................... 5 63 2.7. Identifier Persistence Considerations .................. 5 64 2.8. Process of Identifier Assignment ....................... 5 65 2.9. Process for Identifier Resolution ...................... 5 66 2.10. Rules for Lexical Equivalence ......................... 5 67 2.11. Conformance with URN Syntax ........................... 6 68 2.12. Validation Mechanism .................................. 6 69 2.13. Scope ................................................. 6 70 3. Namespace Considerations .................................... 6 71 4. Community Considerations .................................... 6 72 5. Security Considerations ..................................... 7 73 6. IANA Considerations ......................................... 7 74 7. Conclusions ................................................. 7 75 8. References .................................................. 7 76 8.1. Normative References ................................... 7 77 8.2. Informative References ................................. 8 78 9. Acknowledgments ............................................. 8 80 1. Introduction 82 Historically, NATO has used standardized character-oriented message 83 text formats (MTF) to interoperate, report and exchange information 84 both among its commands and with national entities, commercial 85 partners and Non-Governmental Organizations (NGOs). These MTFs are 86 generated using the NATO Message Text Formatting System (FORMETS) in 87 accordance with the rules, constructions and vocabulary specified 88 within the Allied Data Publication Number 3 (ADatP-3). Almost 400 89 NATO-defined messages that conform to ADatP-3 are contained in the 90 Allied Procedural Publication Number 11 (APP-11) message catalogue [6]. 92 Prior to 2008 these messages were only available as slash delimited 93 textual messages. Since 2008, the APP-11 message catalogue also 94 includes XML-MTF definitions for these messages, giving rise to a 95 need to define and manage a URN namespace to name the XML namespaces. 96 To address this need, a request for a formal URN space type is being 97 made as described in Section 4.3 of RFC 3406. 99 2. Specification Template 101 2.1. Namespace ID 103 The Namespace ID "nato" is requested. 105 2.2. Registration Information 107 Version 1 109 Date: 2014-09-11 111 2.3. Declared Registrant of the Namespace 113 Registering Organization: 115 North Atlantic Treaty Organization (NATO) 117 Communications & Information Services Agency (NCIA) 119 Address: SHAPE, 7010, Belgium 121 Declared Contact: 123 Role: NATO Naming and Addressing Authority (NRA) 125 Email: nra@ncia.nato.int 127 2.4. Declaration of Syntactic Structure 129 The Namespace Specific String (NSS) of all URNs that use the "nato" 130 NID shall have the following structure: 132 ::= "nato" ":" 134 ::= | ":" | ":" 1*( ":" 135 ) 137 ::= 1* 139 ::= 1* 141 ::= 1* 143 ::= | "%" 144 ::= | | | 147 ::= | "A" | "B" | "C" | "D" | "E" | "F" | 148 "a" | "b" | "c" | "d" | "e" | "f" 150 ::= "(" | ")" | "+" | "," | "-" | "." | 151 "=" | "@" | ";" | "$" |"_" | "!" | "*" | "'" 153 The "Type" is the top-level segment of the NSS. It is a required US- 154 ASCII string, subject to the above syntax, that conforms to the URN 155 syntax requirements (see RFC 2141 [1]). It identifies a particular 156 category or type of named resources, such as "mtf". 158 The "Source" is the second-level segment of the NSS, belonging to the 159 "Type" context. At this time, not all "Type" segments have "Source" 160 children, making "Source" an optional US-ASCII string, subject to the 161 above syntax and conformant to the URN syntax requirements (see RFC 2141 162 [1]). "Source" identifies a particular standard, catalogue or other 163 source of relevant specifications. 165 The NATO Naming and Registration Authority (NRA) functions as a Local 166 Internet Registry under RIPE NCC and will also serve as the responsible 167 registrar for assigning the first two levels of segments within the NSS 168 ("Type" and "Source"). The NRA may directly assign segments below these 169 levels of the namespace hierarchy, or delegate assignment 170 responsibilities for segments below the second level (i.e. below 171 "Source") at its discretion. In either case, NRA will ensure a registry 172 of the resulting namespace is maintained. 174 2.5. Relevant Ancillary Documentation 176 AdatP-3 - The message text format standard promulgated under STANAG 177 5500 ed. 7 179 The interim NATO Metadata Registry and Repository (NMRR) webpage can 180 be found at https://nmrr.ncia.nato.int/home.htm 182 2.6. Identifier Uniqueness Considerations 184 The NRA, as registrar, shall directly assure the global uniqueness of 185 the assigned strings. Though responsibility for administration of 186 sub-trees may be delegated, these shall not be published to the 187 registry or be requested to be resolved by any URN resolver until the 188 uniqueness of the resulting urn:nato URN has been validated against 189 the existing contents of the registry. URN identifiers shall be 190 assigned to at most one resource and not reassigned. 192 2.7. Identifier Persistence Considerations 194 The Registrar may assign URNs in sub-trees below the level of Type or 195 Standard, but once registered, URNs shall not be re-assigned. Within 196 the registry, their status as active or archive shall be recorded. 198 2.8. Process of Identifier Assignment 200 A namespace specific string within the NATO namespace will only be 201 assigned upon advancement of a relevant specification. The Registrar 202 checks all requested identifiers against the existing registrations 203 within urn:nato to ensure uniqueness and encourage relevance. 205 The assignment may include delegated registration activities for the 206 sub-tree if underpinned by supporting agreements. Otherwise, such 207 responsibilities remain with the NRA as overarching Registrar. In 208 any case, the urn must be registered with appropriate metadata before 209 an authorized request for URN resolution can be initiated (if 210 necessary). 212 2.9. Process for Identifier Resolution 214 The namespace is not currently listed with a Resolution Discovery 215 System (RDS) [3]. In the future, URNs from this namespace may be 216 resolved using a NATO listing in an RDS, using a third party listed 217 resolver, using an unlisted private resolver, or some combination of 218 these. The resolution method for each segment will be registered 219 with the NRA Registrar. 221 2.10. Rules for Lexical Equivalence 223 No special considerations. The rules for lexical equivalence 224 specified in RFC 2141 apply. 226 2.11. Conformance with URN Syntax 228 No special considerations. 230 2.12. Validation Mechanism 232 None specified. It will be conducted as part of the application for 233 identifier registration as indicated in preceding paragraphs. 235 2.13. Scope 237 Global. 239 3. Namespace Considerations 241 In addition to the large number of XML message specifications that 242 now exist in APP-11, there are other existing and emerging NATO 243 standard messages expressed as XML, as well as ongoing Web service 244 specification development. With no single NID registered to NATO, 245 some of these specifications may be established within locally 246 relevant, self-generated URN namespaces. Not only does this inhibit 247 the portability and adoption intended by standards development [4], 248 it risks name collisions when exposed to the global context of the 249 federation of partners for which these messages are destined. 251 The use of Uniform Resource Names with an appropriate Namespace ID 252 will enable the various NATO standards committees and working groups 253 [5] to use unique, relevant, reliable, permanent, managed and 254 accessible namespace names for their XML products. 256 A dedicated namespace also provides NATO the opportunity to leverage 257 the use of URNs for persistent naming of non-XML resources. 259 4. Community Considerations 261 The NATO standards development community, and those implementing such 262 standards, will benefit from publication of this namespace by having 263 more permanent and reliable names for the XML namespaces defined 264 within STANAGs, the MTF catalogue (APP-11) and other published 265 standards [4]. 267 Though these are NATO-published standards [4], they represent the 268 consensus of multi-national working groups, are implemented in 269 commercial products and used by partners within the international 270 community. 272 In the case of MTF standards [5], the responsibility for its 273 development and maintenance belongs to the NATO C3 Board's Message 274 Text Formats (MFT) Capability Team [5]. This team is "open to all 275 recognized NATO Partners around the Globe in principle. The term 276 'Partners around the Globe' summarizes all partners that are listed 277 on the NATO webpage: Euro-Atlantic Partnership Council (EAPC), NATO's 278 Mediterranean Dialogue (MD), Istanbul Cooperation Initiative (ICI) 279 and Partners across the globe" [AC/322-N(2014)0091-AS1]. 281 5. Security Considerations 283 This document introduces no additional security considerations beyond 284 those associated with the use and resolution of URNs in general. 286 Distribution of NATO information in any form is subject to its 287 security policies. Nonetheless, this specification is for public use 288 and not subject to any NATO security policies. 290 6. IANA Considerations 292 This document defines a formal URN NID registration of "nato", which is 293 requested to be entered into the IANA registry [Uniform Resource 294 Names (URN) Namespaces]. Per RFC 3406 [2] Sec. 4.3, formal NIDs are assigned 295 via IETF Consensus and are subject to IESG review and acceptance. The 296 registration template is given in section 2. 298 7. Conclusions 300 It is necessary that NATO ensures its messages, service specifications 301 and other XML artifacts are based in namespaces that can be described 302 using unique, persistent and managed URNs. Considering its role as an 303 information broker between many disparate communities, this document 304 recommends a formal namespace identifier (NID) urn:nato for Uniform 305 Resource Names (URN) associated with NATO information products and 306 vocabularies. 308 8. References 310 8.1. Normative References 312 [1] Moats, R., "URN Syntax", RFC 2141, May 1997. 314 [2] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, 315 "Uniform Resource Name (URN) Namespace Definition Mechanisms", 316 BCP 66, RFC 3406, October 2002. 318 [3] Sollins, K., "Architectural Principles of Uniform Resource Name 319 Resolution", RFC 2276, January 1998. 321 8.2. Informative References 323 [4] List of Current NATO Standards (publicly available hosted by 324 NATO Standardization Office): 325 http://nso.nato.int/nso/nsdd/listpromulg.html 327 [5] The Message Text Format Capability Team website: 328 https://nhqc3s.hq.nato.int/Default.aspx 330 [6] APP-11 - the ADatP-3 message catalogue promulgated under NATO 331 Standardization Agreement (STANAG) 7149 ed.5 333 [AC/322-N(2014)0091-AS1] NATO notice which specifies that partners 334 that have, or intend to introduce, systems interoperable 335 with NATO MTFs may join the respective NATO working group, 336 subject to the approval of the C3 Board. 338 [Uniform Resource Names (URN) Namespaces] This is the the Official 339 IANA Registry of URN Namespaces located at: 340 http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml 342 9. Acknowledgments 344 The author acknowledges and appreciates the support and expertise 345 provided by Nanda Kol, Ulrich Ritgen and the urn-nid review team. 347 This document was prepared using 2-Word-v2.0.template.dot. 349 Authors' Address 351 Aidan Murdock 352 NATO C&I Agency 353 Core Enterprise Services 354 Naming and Registration Authority 355 SHAPE, Belgium 356 7010 358 Email: Aidan.murdock@ncia.nato.int