Internet Engineering Task Force (IETF) A. Murdock
Request for Comments: 7467 NATO C&I Agency
Category: Informational April 2015
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Murdock
Request for Comments: 7467 NATO C&I Agency
Category: Informational April 2015
ISSN: 2070-1721
URN Namespace for the North Atlantic Treaty Organization (NATO)
北大西洋公约组织（北约）的名称空间
Abstract
摘要
This document allocates a formal Uniform Resource Name (URN) namespace for assignment by the North Atlantic Treaty Organization (NATO), as specified in RFC 3406. At this time, the URN will be used primarily to uniquely identify Extensible Markup Language (XML) artefacts that provide information about NATO message text formats and service specifications as described in various NATO standards, instructions, and publications.
本文件按照RFC 3406中的规定，为北大西洋公约组织（北约）分配一个正式的统一资源名称（URN）命名空间。此时，URN将主要用于唯一标识可扩展标记语言（XML）人工制品，这些人工制品提供有关北约消息文本格式和服务规范的信息，如各种北约标准、说明和出版物中所述。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7467.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7467.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ................................................ 2
2. Specification Template ...................................... 3
2.1. Namespace ID ........................................... 3
2.2. Registration Information ............................... 3
2.3. Declared Registrant of the Namespace ................... 3
2.4. Declaration of Syntactic Structure ..................... 3
2.5. Relevant Ancillary Documentation ....................... 4
2.6. Identifier Uniqueness Considerations ................... 4
2.7. Identifier Persistence Considerations .................. 4
2.8. Process of Identifier Assignment ....................... 5
2.9. Process for Identifier Resolution ...................... 5
2.10. Rules for Lexical Equivalence ......................... 5
2.11. Conformance with URN Syntax ........................... 5
2.12. Validation Mechanism .................................. 5
2.13. Scope ................................................. 5
3. Namespace Considerations .................................... 6
4. Community Considerations .................................... 6
5. Security Considerations ..................................... 7
6. IANA Considerations ......................................... 7
7. Conclusions ................................................. 7
8. References .................................................. 7
8.1. Normative References ................................... 7
8.2. Informative References ................................. 8
Acknowledgments ................................................ 8
Author's Address ............................................... 8
1. Introduction ................................................ 2
2. Specification Template ...................................... 3
2.1. Namespace ID ........................................... 3
2.2. Registration Information ............................... 3
2.3. Declared Registrant of the Namespace ................... 3
2.4. Declaration of Syntactic Structure ..................... 3
2.5. Relevant Ancillary Documentation ....................... 4
2.6. Identifier Uniqueness Considerations ................... 4
2.7. Identifier Persistence Considerations .................. 4
2.8. Process of Identifier Assignment ....................... 5
2.9. Process for Identifier Resolution ...................... 5
2.10. Rules for Lexical Equivalence ......................... 5
2.11. Conformance with URN Syntax ........................... 5
2.12. Validation Mechanism .................................. 5
2.13. Scope ................................................. 5
3. Namespace Considerations .................................... 6
4. Community Considerations .................................... 6
5. Security Considerations ..................................... 7
6. IANA Considerations ......................................... 7
7. Conclusions ................................................. 7
8. References .................................................. 7
8.1. Normative References ................................... 7
8.2. Informative References ................................. 8
Acknowledgments ................................................ 8
Author's Address ............................................... 8
Historically, NATO has used standardized character-oriented message text formats (MTF) to interoperate, report, and exchange information both among its commands and with national entities, commercial partners, and Non-Governmental Organizations (NGOs). These MTFs are generated using the NATO Message Text Formatting System (FORMETS) in accordance with the rules, constructions, and vocabulary specified within the Allied Data Publication Number 3 (ADatP-3). Almost 400 NATO-defined messages that conform to ADatP-3 are contained in the Allied Procedural Publication Number 11 (APP-11) NATO Message Catalogue [7].
历史上，北约使用标准化的面向字符的消息文本格式（MTF）在其司令部之间以及与国家实体、商业伙伴和非政府组织（NGO）之间进行互操作、报告和交换信息。这些MTF是使用北约信息文本格式系统（FORMETS）根据盟军数据出版物第3号（ADatP-3）中规定的规则、结构和词汇生成的。盟军程序出版物第11号（APP-11）北约信息目录[7]中包含了近400条符合ADatP-3的北约定义信息。
Prior to 2008, these messages were only available as slash-delimited textual messages. Since 2008, the APP-11 message catalogue also includes XML-MTF definitions for these messages, giving rise to a need to define and manage a URN namespace to name the XML namespaces. To address this need, this document requests that a formal URN space type be assigned as described in Section 4.3 of RFC 3406.
在2008年之前，这些消息只能作为斜杠分隔的文本消息使用。自2008年以来，APP-11消息目录还包括这些消息的XML-MTF定义，因此需要定义和管理URN名称空间来命名XML名称空间。为了满足这一需求，本文件要求按照RFC 3406第4.3节的规定分配正式的URN空间类型。
The Namespace ID (NID) "nato" has been assigned by IANA.
IANA已分配名称空间ID（NID）“nato”。
Version 1 Date: 2014-09-11
版本1日期：2014-09-11
Registering Organization: Name: North Atlantic Treaty Organization (NATO) Communications & Information Agency (NCIA) Address: SHAPE, 7010, Belgium Declared Contact: NATO Naming and Addressing Registration Authority (NRA) Email: nra@ncia.nato.int
注册机构：名称：北大西洋公约组织（北约）通信和信息局（NCIA）地址：比利时7010 SHAPE声明联系人：北约命名和地址注册机构（NRA）电子邮件：nra@ncia.nato.int
The Namespace Specific String (NSS) of all URNs that use the "nato" NID shall have the following structure:
使用“nato”NID的所有URN的命名空间特定字符串（NSS）应具有以下结构：
<URN> ::= "urn:" "nato" ":" <NSS>
<URN> ::= "urn:" "nato" ":" <NSS>
<NSS> ::= <Type> | <Type> ":" <Source> |
<Type> ":" <Source> 1*( ":" <segment> )
<NSS> ::= <Type> | <Type> ":" <Source> |
<Type> ":" <Source> 1*( ":" <segment> )
<Type> ::= 1*<non-colon chars>
<Type> ::= 1*<non-colon chars>
<Source> ::= 1*<non-colon chars>
<Source> ::= 1*<non-colon chars>
<segment> ::= 1*<non-colon chars>
<segment> ::= 1*<non-colon chars>
<non-colon chars> ::= <non-colon trans> | "%" <hex> <hex>
<non-colon chars> ::= <non-colon trans> | "%" <hex> <hex>
<non-colon trans> ::= <upper> | <lower> | <number> |
<non-colon other>
<non-colon trans> ::= <upper> | <lower> | <number> |
<non-colon other>
<hex> ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
<hex> ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
<non-colon other> ::= "(" | ")" | "+" | "," | "-" | "." |
"=" | "@" | ";" | "$" |"_" | "!" | "*" | "'"
<non-colon other> ::= "(" | ")" | "+" | "," | "-" | "." |
"=" | "@" | ";" | "$" |"_" | "!" | "*" | "'"
The "Type" is the top-level segment of the NSS. It is a required US-ASCII string, subject to the above syntax, that conforms to the URN syntax requirements (see RFC 2141 [1]). It identifies a particular category or type of named resources, such as "mtf".
“类型”是NSS的顶级部分。这是一个必需的US-ASCII字符串，符合上述语法，符合URN语法要求（参见RFC 2141[1]）。它标识特定类别或类型的命名资源，例如“mtf”。
The "Source" is the second-level segment of the NSS, belonging to the "Type" context. At this time, not all "Type" segments have "Source" children, making "Source" an optional US-ASCII string, subject to the above syntax and conformant to the URN syntax requirements (see RFC 2141 [1]). "Source" identifies a particular standard, catalogue, or other relevant specifications.
“源”是NSS的第二级段，属于“类型”上下文。此时，并非所有“类型”段都有“源”子项，使“源”成为可选的US-ASCII字符串，符合上述语法并符合URN语法要求（参见RFC 2141[1]）。“来源”标识特定标准、目录或其他相关规范。
The NATO Naming and Registration Authority (NRA) functions as a Local Internet Registry under RIPE NCC and will also serve as the responsible registrar for assigning the first two levels of segments within the NSS ("Type" and "Source"). The NRA may directly assign segments below these levels of the namespace hierarchy, or delegate assignment responsibilities for segments below the second level (i.e., below "Source") at its discretion. In either case, the NRA will ensure that a registry of the resulting namespace is maintained.
北约命名和注册管理局（NRA）在NCC下作为本地互联网注册处，还将作为负责注册的机构，负责分配NSS内前两级的网段（“类型”和“来源”）。NRA可直接分配命名空间层次结构这些级别以下的段，或自行决定将分配责任委托给第二级别以下（即“源”以下）的段。在任何一种情况下，NRA都将确保维护结果命名空间的注册表。
ADatP-3 - NATO, "Concept of NATO Message Text Formatting System (Conformets) - ADatP-3 (A)", STANAG 5500 - Edition 7, November 2010.
ADatP-3-北约，“北约报文文本格式系统（Conformets）的概念-ADatP-3（A）”，STANAG 5500-第7版，2010年11月。
The NRA, as registrar, shall directly ensure the global uniqueness of the assigned strings. Though responsibility for administration of sub-trees may be delegated, these shall not be published to the registry or be requested to be resolved by any URN resolver until the uniqueness of the resulting urn:nato URN has been validated against the existing contents of the registry. URN identifiers shall be assigned to one resource at most and not reassigned.
NRA作为注册机构，应直接确保指定字符串的全局唯一性。尽管可以委托管理子树的责任，但在根据注册表的现有内容验证生成的URN:nato URN的唯一性之前，不得将这些子树发布到注册表，也不得要求任何URN解析器进行解析。URN标识符最多只能分配给一个资源，不得重新分配。
The Registrar may assign URNs in sub-trees below the level of Type or Standard; however, once registered, URNs shall not be reassigned. Within the registry, their status as "active" or "archive" shall be recorded.
注册官可在低于类型或标准等级的子树中分配骨灰盒；但是，一旦登记，骨灰盒不得重新分配。在登记册内，应记录其“活动”或“存档”状态。
A namespace-specific string within the NATO namespace will only be assigned upon advancement of a relevant specification. The Registrar will check all requested identifiers against the existing registrations within urn:nato to ensure uniqueness and encourage relevance.
北约名称空间中特定于名称空间的字符串将仅在相关规范升级后分配。注册官将对照urn:nato内的现有注册检查所有请求的标识符，以确保唯一性并鼓励相关性。
The assignment may include delegated registration activities for the sub-tree if underpinned by supporting agreements. Otherwise, such responsibilities remain with the NRA as the overarching Registrar. In any case, the URN must be registered with appropriate metadata before an authorized request for URN resolution can be initiated (if necessary).
如果有支持协议支持，则该任务可能包括子目录树的委托注册活动。否则，此类责任仍由NRA作为总注册官承担。在任何情况下，必须使用适当的元数据注册URN，然后才能启动授权的URN解析请求（如有必要）。
The namespace is not currently listed with a Resolution Discovery System (RDS) [3]. In the future, URNs from this namespace may be resolved using a NATO listing in an RDS, using a third-party-listed resolver, an unlisted private resolver, or some combination of these. The resolution method for each segment will be registered with the NRA Registrar.
名称空间当前未与解析发现系统（RDS）[3]一起列出。将来，可以使用RDS中的北约列表、使用第三方列出的冲突解决程序、未列出的私有冲突解决程序或它们的某种组合来解析此命名空间中的URN。每段的解析方法将在NRA注册处注册。
No special considerations. The rules for lexical equivalence specified in RFC 2141 apply.
没有特别考虑。RFC 2141中规定的词汇等价规则适用。
No special considerations.
没有特别考虑。
None specified. It will be conducted as part of the application for identifier registration as indicated in preceding paragraphs.
没有具体说明。如前几段所述，这将作为标识符注册申请的一部分进行。
Global.
全球的
In addition to the large number of XML message specifications that now exist in APP-11, there are other existing and emerging NATO standard messages expressed as XML, as well as ongoing Web service specification development. With no single NID registered to NATO, some of these specifications may be established within locally relevant, self-generated URN namespaces. Not only does this inhibit the portability and adoption intended by standards development [5], it risks name collisions when exposed to the global context of the federation of partners for which these messages are destined.
除了APP-11中现有的大量XML消息规范外，还有其他现有和新兴的北约标准消息以XML表示，以及正在进行的Web服务规范开发。由于没有向北约注册单个NID，其中一些规范可以在本地相关的、自行生成的URN名称空间中建立。这不仅抑制了标准开发[5]所期望的可移植性和采用性，而且在暴露于这些消息所针对的合作伙伴联合会的全局上下文时，还存在名称冲突的风险。
The use of Uniform Resource Names with an appropriate Namespace ID will enable the various NATO standards committees and working groups [6] to use unique, relevant, reliable, permanent, managed, and accessible namespace names for their XML products.
使用具有适当名称空间ID的统一资源名称将使各个北约标准委员会和工作组[6]能够为其XML产品使用唯一、相关、可靠、永久、受管理和可访问的名称空间名称。
A dedicated namespace also provides NATO the opportunity to leverage the use of URNs for persistent naming of non-XML resources.
专用名称空间还提供了利用URN对非XML资源进行持久命名的机会。
The NATO standards development community, and those implementing such standards, will benefit from publication of this namespace by having more permanent and reliable names for the XML namespaces defined within STANAGs, the MTF catalogue (APP-11), and other published standards [5].
北约标准开发团体以及实施此类标准的团体将受益于该名称空间的发布，因为它们在STANAGs、MTF目录（APP-11）和其他发布的标准中定义了更为永久和可靠的XML名称空间名称[5]。
Though these are NATO-published standards [5], they represent the consensus of multi-national working groups, are implemented in commercial products, and are used by partners within the international community.
尽管这些标准是北约发布的标准[5]，但它们代表了多国工作组的共识，在商业产品中实施，并被国际社会的合作伙伴使用。
In the case of MTF standards [7], the responsibility for its development and maintenance belongs to the NATO C3 Board's Message Text Formats (MFT) Capability Team [6]. This team is "open to all recognized NATO Partners around the Globe in principle. The term 'Partners around the Globe' summarizes all partners that are listed on the NATO webpage: Euro-Atlantic Partnership Council (EAPC), NATO's Mediterranean Dialogue (MD), Istanbul Cooperation Initiative (ICI) and Partners across the globe" [8].
就MTF标准而言[7]，其开发和维护责任属于北约C3委员会的消息文本格式（MFT）能力团队[6]。该团队“原则上对全球所有公认的北约合作伙伴开放。“全球合作伙伴”一词概括了北约网页上列出的所有合作伙伴：欧洲-大西洋伙伴关系理事会（EAPC）、北约地中海对话（MD）、伊斯坦布尔合作倡议（ICI）和全球合作伙伴”[8]。
Since the URNs in this namespace are opaque, there are no additional security considerations other than those normally associated with the use and resolution of URIs and URNs in general (see the Security Considerations in Internet STD 66 [4], RFC 2141 [1], and BCP 66 [2]).
由于此命名空间中的URN是不透明的，因此除了通常与URI和URN的使用和解析相关的安全注意事项外，没有其他安全注意事项（请参阅Internet STD 66[4]、RFC 2141[1]和BCP 66[2]中的安全注意事项）。
It is noted, however, that resolution algorithms and rules for handling invalid URNs are opaque. Therefore, attempting to resolve a NATO URN through a resolver other than one operated or delegated by NATO may return outdated, incorrect, or confusing results.
然而，需要注意的是，用于处理无效URN的解析算法和规则是不透明的。因此，试图通过非北约操作或授权的解析程序解析北约URN可能会返回过时、不正确或混乱的结果。
Distribution of NATO information in any form is subject to its security policies. Nonetheless, this specification is for public use and not subject to any NATO security policies.
以任何形式分发北约信息都要遵守其安全政策。尽管如此，本规范仅供公众使用，不受任何北约安全政策的约束。
This document registers the formal URN NID "nato", which has been entered into the "Formal URN Namespaces" IANA registry [9]. Per Section 4.3 of RFC 3406 [2], formal NIDs are assigned via IETF Consensus and are subject to IESG review and acceptance. The registration template is given in Section 2.
本文件注册了正式的URN NID“nato”，该名称已输入“正式URN名称空间”IANA注册表[9]。根据RFC 3406[2]第4.3节，正式NID通过IETF共识分配，并接受IESG审查和验收。注册模板见第2节。
It is necessary that NATO ensures its messages, service specifications, and other XML artefacts are based in namespaces that can be described using unique, persistent, and managed URNs. Considering its role as an information broker between many disparate communities, this document registers a formal namespace identifier (NID) "nato" for Uniform Resource Names (URN) associated with NATO information products and vocabularies: urn:nato.
北约有必要确保其消息、服务规范和其他XML构件基于名称空间，这些名称空间可以使用唯一、持久和受管理的URN进行描述。考虑到其作为许多不同社区之间的信息代理的角色，本文档为与北约信息产品和词汇相关联的统一资源名称（URN）注册了一个正式名称空间标识符（NID）“nato”：URN:nato。
[1] Moats, R., "URN Syntax", RFC 2141, May 1997, <http://www.rfc-editor.org/info/rfc2141>.
[1] 护城河，R.，“瓮语法”，RFC 21411997年5月<http://www.rfc-editor.org/info/rfc2141>.
[2] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002, <http://www.rfc-editor.org/info/rfc3406>.
[2] Daigle，L.，van Gulik，D.，Iannella，R.，和P.Faltstrom，“统一资源名（URN）命名空间定义机制”，BCP 66，RFC 3406，2002年10月<http://www.rfc-editor.org/info/rfc3406>.
[3] Sollins, K., "Architectural Principles of Uniform Resource Name Resolution", RFC 2276, January 1998, <http://www.rfc-editor.org/info/rfc2276>.
[3] Sollins，K.，“统一资源名称解析的体系结构原则”，RFC 22761998年1月<http://www.rfc-editor.org/info/rfc2276>.
[4] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[4] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[5] NATO, "List of Current NATO Standards", <http://nso.nato.int/nso/nsdd/listpromulg.html>.
[5] 北约，“现行北约标准清单”<http://nso.nato.int/nso/nsdd/listpromulg.html>.
[6] NATO, "NATO HQ C3 Staff Main Page", <https://nhqc3s.hq.nato.int/Default.aspx>.
[6] 北约，“北约总部C3员工主页”<https://nhqc3s.hq.nato.int/Default.aspx>.
[7] NATO, "NATO Message Catalogue - APP-11(C) Change 1" STANAG 7149, Edition 5, September 2010.
[7] 北约，“北约信息目录——APP-11（C）变更1”STANAG 7149，第5版，2010年9月。
[8] NATO, "Request to open MTF CaT to all NATO Partners", document AC/322-N(2014)0091-AS1, 2014. Available from the NATO Public Diplomacy Division.
[8] 北约，“向所有北约合作伙伴开放MTF CaT的请求”，文件AC/322-N（2014）0091-AS12014。可从北约公共外交部获得。
[9] IANA, "Uniform Resource Names (URN) Namespaces", <http://www.iana.org/assignments/urn-namespaces>.
[9] IANA，“统一资源名称（URN）命名空间”<http://www.iana.org/assignments/urn-namespaces>.
Acknowledgments
致谢
The author acknowledges and appreciates the support and expertise provided by Nanda Kol, Ulrich Ritgen, and the urn-nid review team.
作者承认并感谢Nanda Kol、Ulrich Ritgen和urn nid审查团队提供的支持和专业知识。
Authors' Address
作者地址
Aidan Murdock NATO C&I Agency Core Enterprise Services Naming and Registration Authority SHAPE, Belgium 7010
艾丹·默多克北约C&I机构核心企业服务命名和注册机构，比利时7010
EMail: Aidan.murdock@ncia.nato.int
EMail: Aidan.murdock@ncia.nato.int