idnits 2.17.1 draft-murdock-nato-nid-00.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 is 1 instance of too long lines in the document, the longest one being 127 characters in excess of 72. ** The abstract seems to contain references ([4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 11, 2014) is 3508 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '2' is defined on line 281, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (ref. '1') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 3406 (ref. '2') (Obsoleted by RFC 8141) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 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: March 11, 2015 September 11, 2014 5 URN Namespace for NATO 6 draft-murdock-nato-nid-00.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 March 18, 2015. 31 Copyright Notice 33 Copyright (c) 2014 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 describes a Uniform Resource Name (URN) namespace 46 primarily for uniquely identifying Extensible Markup Language (XML) 47 artifacts that provide information about NATO message text formats 48 and service specifications as described in various NATO standards 49 [4], instructions and publications. 51 Table of Contents 53 1. Introduction...................................................2 54 2. Specification Template.........................................3 55 2.1. Namespace ID:.............................................3 56 2.2. Registration Information:.................................3 57 2.3. Declared Registrant of the Namespace:.....................3 58 2.4. Declaration of Syntactic Structure:.......................3 59 2.5. Relevant Ancillary Documentation:.........................4 60 2.6. Identifier Uniqueness Considerations......................4 61 2.7. Identifier Persistence Considerations:....................4 62 2.8. Process of Identifier Assignment:.........................4 63 2.9. Process for Identifier Resolution:........................5 64 2.10. Rules for Lexical Equivalence:...........................5 65 2.11. Conformance with URN Syntax:.............................5 66 2.12. Validation Mechanism:....................................5 67 2.13. Scope:...................................................5 68 3. Namespace Considerations.......................................5 69 4. Community Considerations.......................................6 70 5. Security Considerations........................................6 71 6. IANA Considerations............................................6 72 7. Conclusions....................................................6 73 8. References.....................................................7 74 8.1. Normative References......................................7 75 8.2. Informative References....................................7 76 9. Acknowledgments................................................7 78 1. Introduction 80 Historically, NATO has used standardized character-oriented message 81 text formats (MTF) to interoperate, report and exchange information 82 both among its commands and with national entities, commercial 83 partners and NGOs. These MTFs are generated using the NATO Message 84 Text Formatting System (FORMETS) in accordance with the rules, 85 constructions and vocabulary specified within the Allied Data 86 Publication Number 3 (ADatP-3). Almost 400 NATO-defined messages 87 that conform to ADatP-3 are contained in an Allied Procedural 88 Publication Number 11 (APP-11) message catalogue. 90 Prior to 2008 these messages were only available as slash delimited 91 textual messages. Since 2008, the APP-11 message catalogue (expresses 92 message definitions) also includes XML-MTF definitions for these 93 messages, giving rise to a need to define and manage a URN namespace 94 rooted in the "nato" NID. 96 2. Specification Template 98 2.1. Namespace ID: 100 The Namespace ID "nato" is requested. 102 2.2. Registration Information: 104 Version 1 106 Date: 2014-09-11 108 2.3. Declared Registrant of the Namespace: 110 Registering Organization: 112 North Atlantic Treaty Organization (NATO) 114 Communications & Information Services Agency (NCIA) 116 Address: SHAPE, 7010, Belgium 118 Declared Contact: 120 Role: NATO Naming and Addressing Authority (NRA) 122 Email: nra@ncia.nato.int 124 2.4. Declaration of Syntactic Structure: 126 The Namespace Specific String (NSS) of all URNs that use the "nato" 127 NID shall have the following structure: 129 urn:nato:: 131 The "Type" is a required US-ASCII string that conforms to the URN 132 syntax requirements (see RFC 2141 [1]) and defines a particular 133 category or type of named resources, such as "mtf" 134 The "Source" is an optional US-ASCII string that conforms to the URN 135 syntax requirements (see RFC 2141 [1]) and defines a particular 136 standard, catalogue or other source of relevant specifications 138 The NATO Naming and Registration Authority (NRA) functions as a Local 139 Internet Registry under RIPE NCC and will also serve as the 140 responsible registrar for managing the assignments of both "Type" and 141 "Source" strings. The NRA may also assign URNs in sub-trees below the 142 level of the Type or Source as needed. They will also ensure a 143 registry of the resulting namespace is maintained. 145 2.5. Relevant Ancillary Documentation: 147 APP-11 - the ADatP-3 message catalogue 149 AdatP-3 - The message text format standard promulgated under STANAG 150 5500 ed. 7 152 The interim NATO Metadata Registry and Repository (NMRR) webpage can 153 be found at https://nmrr.ncia.nato.int/home.htm 155 2.6. Identifier Uniqueness Considerations: 157 The NRA, as registrar, shall directly assure the global uniqueness of 158 the assigned strings. Though responsibility for administration of 159 sub-trees may be delegated, these shall not be published to the 160 registry or be requested to be resolved by any URN resolver until the 161 uniqueness of the resulting urn:nato namespace has been validated 162 against the existing contents of the registry. URN identifiers shall 163 be assigned to at most one resource and not reassigned. 165 2.7. Identifier Persistence Considerations: 167 The Registrar may assign URNs in sub-trees below the level of Type or 168 Standard, but once registered, URNs shall not be re-assigned. Within 169 the registry, their status as active or archive shall be recorded. 171 2.8. Process of Identifier Assignment: 173 A namespace specific string within the NATO namespace will only be 174 assigned upon advancement of a relevant specification. The Registrar 175 checks all requested identifiers against the existing registrations 176 within urn:nato to ensure uniqueness and encourage relevance. At this 177 time, the possibility of delegating registration activities for the 178 sub-tree is evaluated, subject to supporting agreements. Otherwise, 179 such responsibilities remain with the NRA as overarching Registrar. 180 The urn is then registered with appropriate metadata and an 181 authorized request for URN resolution can be initiated (if 182 necessary). 184 2.9. Process for Identifier Resolution: 186 The namespace is not currently listed with a Resolution Discovery 187 System (RDS) [3]. In the future, URNs from this namespace may be rd resolved using a NATO listing in an RDS, using a 3 party listed 188 resolver, using an unlisted, private resolver, or some combination of 189 these. The resolution method for each sub-tree will be registered 190 with the NRA Registrar. 192 2.10. Rules for Lexical Equivalence: 194 No special considerations. The rules for lexical equivalence 195 specified in RFC 2141 apply. 197 2.11. Conformance with URN Syntax: 199 No special considerations. 201 2.12. Validation Mechanism: 203 None specified. It will be conducted as part of the application for 204 identifier registration as indicated in preceding paragraphs. 206 2.13. Scope: 208 Global. 210 3. Namespace Considerations 212 In addition to the large number of XML message specifications that 213 now exist in APP-11, there are other existing and emerging NATO 214 standard messages expressed as XML, as well as ongoing Web service 215 specification development. With no single NID registered to NATO, 216 some of these specifications may be established within locally 217 relevant, self-generated URN namespaces. Not only does this inhibit 218 the portability and adoption intended by standards development [4], 219 it risks name collisions when exposed to the global context of the 220 federation of partners for which these messages are destined. 222 The use of Uniform Resource Names with an appropriate Namespace ID 223 will enable the various NATO standards committees and working groups 224 [5] to use unique, relevant, reliable, permanent, managed and 225 accessible namespace names for its XML products. It also provides 226 NATO the opportunity to leverage the use of URNs for persistent 227 naming of non-XML resources. 229 4. Community Considerations 231 The NATO standards development community, and those implementing such 232 standards, will benefit from publication of this namespace by having 233 more permanent and reliable names for the XML namespaces defined 234 within STANAGs, the MTF catalogue (APP-11) and other published 235 standards [4]. 237 Though these are NATO-published standards [4], they represent the 238 consensus of multi-national working groups, are implemented in 239 commercial products and used by partners within the international 240 community. 242 In the case of MTF standards [5], the responsibility for its 243 development and maintenance belongs to the NATO C3 Board's Message 244 Text Formats (MFT) Capability Team [5]. This team is "open to all 245 recognized NATO Partners around the Globe in principle. The term 246 'Partners around the Globe' summarizes all partners that are listed 247 on the NATO webpage: Euro-Atlantic Partnership Council (EAPC), NATO's 248 Mediterranean Dialogue (MD), Istanbul Cooperation Initiative (ICI) 249 and Partners across the globe" [AC/322-N(2014)0091-AS1]. 251 5. Security Considerations 253 This document introduces no additional security considerations beyond 254 those associated with the use and resolution of URNs in general. 256 Distribution of NATO information in any form is subject to its 257 security policies. 259 6. IANA Considerations 261 This document defines a URN NID registration of "nato", which is 262 requested to be entered into the IANA registry located at 263 . 265 7. Conclusions 267 It is necessary that a standards body, like NATO, ensures its 268 messages, service specifications and other XML artifacts are based in 269 namespaces that can be described using unique, persistent and managed 270 URNs. Considering its role as an information broker between many 271 disparate communities, this document recommends a formal namespace 272 identifier (NID) urn:nato for Uniform Resource Names (URN) associated 273 with NATO information products. 275 8. References 277 8.1. Normative References 279 [1] Moats, R., "URN Syntax", RFC 2141, May 1997. 281 [2] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, 282 "Uniform Resource Name (URN) Namespace Definition Mechanisms", 283 BCP 66, RFC 3406, October 2002. 285 [3] Sollins, K., "Architectural Principles of Uniform Resource Name 286 Resolution", RFC 2276, January 1998. 288 8.2. Informative References 290 [4] List of Current NATO Standards (publicly available hosted by 291 NATO Standardization Office): 292 http://nso.nato.int/nso/nsdd/listpromulg.html 294 [5] The Message Text Format Capability Team website: 295 https://nhqc3s.hq.nato.int/Default.aspx 297 [AC/322-N(2014)0091-AS1] NATO notice which specifies that partners 298 that have, or intend to introduce, systems interoperable 299 with NATO MTFs may join the respective NATO working group, 300 subject to the approval of the C3 Board. 302 9. Acknowledgments 304 The author acknowledges and appreciates the support and expertise 305 provided by Nanda Kol and Ulrich Ritgen. 307 This document was prepared using 2-Word-v2.0.template.dot. 309 Authors' Addresses 311 Aidan Murdock 312 NATO C&I Agency 313 Core Enterprise Services 314 Naming and Registration Authority 315 SHAPE, Belgium 316 7010 318 Email: Aidan.murdock@ncia.nato.int