Internet Draft Engineering Task Force (IETF)                        A. Murdock
Intended status: Informational
Request for Comments: 7467                               NATO C&I Agency
Expires: July 5, 2015                               January 5,
Category: Informational                                       April 2015
ISSN: 2070-1721

    URN Namespace for the North Atlantic Treaty Organization (NATO)
                       draft-murdock-nato-nid-03.txt

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.  The current primary use is for  At this time, the URN will be used
   primarily to uniquely identifying identify Extensible Markup Language (XML) artifacts
   artefacts that provide information about NATO message text formats
   and service specifications as described in various NATO standards,
   instructions
   instructions, and publications.

Status of this This Memo

   This Internet-Draft document is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum
   (IETF).  It represents the consensus of six months the IETF community.  It has
   received public review and may be updated, replaced, or obsoleted has been approved for publication by other the
   Internet Engineering Steering Group (IESG).  Not all documents at
   approved by the IESG are a candidate for any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list level of Internet
   Standard; see Section 2 of RFC 5741.

   Information about the current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list status of Internet-Draft Shadow Directories can this document, any errata,
   and how to provide feedback on it may be accessed obtained at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on July 5, 2015.
   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.

   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.

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 ................... 5 4
      2.7. Identifier Persistence Considerations .................. 5 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 ........................... 6 5
      2.12. Validation Mechanism .................................. 6 5
      2.13. Scope ................................................. 6 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
   9.
   Acknowledgments ............................................. ................................................ 8
   Author's Address ............................................... 8

1.  Introduction

   Historically, NATO has used standardized character-oriented message
   text formats (MTF) to interoperate, report report, and exchange information
   both among its commands and with national entities, commercial
   partners
   partners, and Non-Governmental Organizations (NGOs).  These MTFs are
   generated using the NATO Message Text Formatting System (FORMETS) in
   accordance with the rules, constructions 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) message catalogue [6]. NATO Message
   Catalogue [7].

   Prior to 2008 2008, these messages were only available as slash delimited 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, a request for this document requests that a formal URN space
   type is being
   made be assigned as described in Section 4.3 of RFC 3406.

2.  Specification Template

2.1.  Namespace ID

   The Namespace ID (NID) "nato" is requested. has been assigned by IANA.

2.2.  Registration Information

   Version 1
   Date: 2014-09-11

2.3.  Declared Registrant of the Namespace

   Registering Organization:
      Name: North Atlantic Treaty Organization (NATO)
            Communications & Information Services Agency (NCIA)
      Address: SHAPE, 7010, Belgium
      Declared Contact:

   Role: NATO Naming and Addressing Registration
                        Authority (NRA)
      Email: nra@ncia.nato.int

2.4.  Declaration of Syntactic Structure

   The Namespace Specific String (NSS) of all URNs that use the "nato"
   NID shall have the following structure:

   <URN> ::= "urn:" "nato" ":" <NSS>

   <NSS> ::= <Type> | <Type> ":" <Source> |
             <Type> ":" <Source> 1*( ":" <segment> )

   <Type> ::= 1*<non-colon chars>

   <Source> ::= 1*<non-colon chars>

   <segment>  ::= 1*<non-colon chars>

   <non-colon chars> ::= <non-colon trans> | "%" <hex> <hex>

   <non-colon trans> ::= <upper> | <lower> | <number> |
                         <non-colon other>

   <hex>         ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
                     "a" | "b" | "c" | "d" | "e" | "f"

   <non-colon other> ::= "(" | ")" | "+" | "," | "-" | "." |
                     "=" | "@" | ";" | "$" |"_" | "!" | "*" | "'"
   The "Type" is the top-level segment of the NSS.  It is a required US-
ASCII
   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".

   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 catalogue, or
   other
source of relevant specifications.

   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.
   (i.e., below "Source") at its discretion.  In either case, the NRA
   will ensure that a registry of the resulting namespace is maintained.

2.5.  Relevant Ancillary Documentation

   AdatP-3

   ADatP-3 - The message text format standard promulgated under NATO, "Concept of NATO Message Text Formatting System
   (Conformets) - ADatP-3 (A)", STANAG 5500 ed. 7

   The interim NATO Metadata Registry and Repository (NMRR) webpage can
   be found at https://nmrr.ncia.nato.int/home.htm - Edition 7, November 2010.

2.6.  Identifier Uniqueness Considerations

   The NRA, as registrar, shall directly assure 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 at most one resource at most and not reassigned.

2.7.  Identifier Persistence Considerations

   The Registrar may assign URNs in sub-trees below the level of Type or
   Standard, but
   Standard; however, once registered, URNs shall not be re-assigned. reassigned.
   Within the registry, their status as active "active" or archive "archive" shall be
   recorded.

2.8.  Process of Identifier Assignment

   A namespace specific namespace-specific string within the NATO namespace will only be
   assigned upon advancement of a relevant specification.  The Registrar
   checks
   will check all requested identifiers against the existing
   registrations within urn:nato to ensure uniqueness and encourage
   relevance.

   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 URN must be registered with appropriate metadata
   before an authorized request for URN resolution can be initiated (if
   necessary).

2.9.  Process for Identifier Resolution

   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 third-party-listed
   resolver, using an unlisted private resolver, or some combination of these.
   The resolution method for each segment will be registered with the
   NRA Registrar.

2.10.  Rules for Lexical Equivalence

   No special considerations.  The rules for lexical equivalence
   specified in RFC 2141 apply.

2.11.  Conformance with URN Syntax

   No special considerations.

2.12.  Validation Mechanism

   None specified.  It will be conducted as part of the application for
   identifier registration as indicated in preceding paragraphs.

2.13.  Scope

   Global.

3.  Namespace Considerations

   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 [4], [5],
   it risks name collisions when exposed to the global context of the
   federation of partners for which these messages are destined.

   The use of Uniform Resource Names with an appropriate Namespace ID
   will enable the various NATO standards committees and working groups
   [5]
   [6] to use unique, relevant, reliable, permanent, managed managed, and
   accessible namespace names for their XML products.

   A dedicated namespace also provides NATO the opportunity to leverage
   the use of URNs for persistent naming of non-XML resources.

4.  Community Considerations

   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) (APP-11), and other published
   standards [4]. [5].

   Though these are NATO-published standards [4], [5], they represent the
   consensus of multi-national working groups, are implemented in
   commercial products products, and are used by partners within the
   international community.

   In the case of MTF standards [5], [7], the responsibility for its
   development and maintenance belongs to the NATO C3 Board's Message
   Text Formats (MFT) Capability Team [5]. [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" [AC/322-N(2014)0091-AS1]. [8].

5.  Security Considerations

   This document introduces

   Since the URNs in this namespace are opaque, there are no additional
   security considerations beyond other than those normally associated with the
   use and resolution of URIs and URNs in general. general (see the Security
   Considerations in Internet STD 66 [4], RFC 2141 [1], and 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.

   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.

6.  IANA Considerations

   This document defines a registers the formal URN NID registration of "nato", which is
   requested to be has been
   entered into the "Formal URN Namespaces" IANA registry [Uniform Resource
   Names (URN) Namespaces]. [9].  Per
   Section 4.3 of RFC 3406 [2] Sec. 4.3, [2], formal NIDs are assigned via IETF
   Consensus and are subject to IESG review and acceptance.  The
   registration template is given in section Section 2.

7.  Conclusions

   It is necessary that NATO ensures its messages, service specifications
   specifications, and other XML artifacts artefacts are based in namespaces that
   can be described using unique, persistent persistent, and managed URNs.
   Considering its role as an information broker between many disparate
   communities, this document
   recommends registers a formal namespace identifier
   (NID) urn:nato "nato" for Uniform Resource Names (URN) associated with NATO
   information products and
   vocabularies. vocabularies: urn:nato.

8.  References

8.1.  Normative References

   [1]  Moats, R., "URN Syntax", RFC 2141, May 1997. 1997,
        <http://www.rfc-editor.org/info/rfc2141>.

   [2]  Daigle, L., van Gulik, D., Iannella, R. R., and P. Faltstrom,
        "Uniform Resource Name Names (URN) Namespace Definition Mechanisms",
        BCP 66, RFC 3406, October 2002. 2002,
        <http://www.rfc-editor.org/info/rfc3406>.

   [3]  Sollins, K., "Architectural Principles of Uniform Resource Name
        Resolution", RFC 2276, January 1998. 1998,
        <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>.

8.2.  Informative References

   [4]  List

   [5]  NATO, "List of Current NATO Standards (publicly available hosted by
         NATO Standardization Office):
         http://nso.nato.int/nso/nsdd/listpromulg.html

   [5]  The Message Text Format Capability Team website:
         https://nhqc3s.hq.nato.int/Default.aspx Standards",
        <http://nso.nato.int/nso/nsdd/listpromulg.html>.

   [6]  APP-11  NATO, "NATO HQ C3 Staff Main Page",
        <https://nhqc3s.hq.nato.int/Default.aspx>.

   [7]  NATO, "NATO Message Catalogue - the ADatP-3 message catalogue promulgated under NATO
        Standardization Agreement (STANAG) 7149 ed.5

   [AC/322-N(2014)0091-AS1] NATO notice which specifies that partners
             that have, or intend APP-11(C) Change 1" STANAG 7149,
        Edition 5, September 2010.

   [8]  NATO, "Request to introduce, systems interoperable
             with open MTF CaT to all NATO MTFs may join Partners", document
        AC/322-N(2014)0091-AS1, 2014.  Available from the respective NATO working group,
             subject to the approval of the C3 Board.

   [Uniform Public
        Diplomacy Division.

   [9]  IANA, "Uniform Resource Names (URN) Namespaces] This is the the Official
   IANA Registry of URN Namespaces located at:
   http://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml

9. Namespaces",
        <http://www.iana.org/assignments/urn-namespaces>.

Acknowledgments

   The author acknowledges and appreciates the support and expertise
   provided by Nanda Kol, Ulrich Ritgen Ritgen, and the urn-nid review team.

   This document was prepared using 2-Word-v2.0.template.dot.

Authors' Address

   Aidan Murdock
   NATO C&I Agency
   Core Enterprise Services
   Naming and Registration Authority
   SHAPE, Belgium
   7010

   Email:

   EMail: Aidan.murdock@ncia.nato.int