[media-types] [IANA #1459711] application/vnd.nits+xml registration request

[Amanda Baber via RT <[e-mail]>]

Hi Murray,

Resending this request from September 14th.

thanks,
Amanda

On Mon Sep 14 19:16:10 2026, amanda.baber wrote:
> Hi Murray,
> 
> Can you review this request by September 28th?
> 
> This was originally submitted as a request to register
> application/nits+xml. I asked whether this should be considered an SDO
> request (and in that case, how we could receive confirmation from the
> organization) or put forward as a potential grandfathered request.
> NATO has registered names that begin with "vnd.nato," and it doesn't
> look like we were asked to find out whether standards tree
> registration was possible at that time.
> 
> More from the requester:
> 
> > After some discussion, we have decided that the simplest way forward
> > is to switch to the vendor tree and later move to the standards tree
> > if necessary. We are working out details about who the IESG can
> > contact, although we may decide that the vendor tree is sufficient.
> >
> > Our standard is promulgated by the NATO Standardization Office (NSO)
> > at https://nso.nato.int/. I work in a US-based group under the
> > National Geospatial-Intelligence Agency (NGA), which contributes to
> > the NSO but also has its own US-based standardization authority (NSG
> > Standards Registry).
> >
> > However, as you have pointed out, others under our umbrella have used
> > the vendor tree in the past; an example is the vnd.nitf file type in
> > addition to the vnd.nato types you mentioned.
> >
> > For now, could you modify our application to use the vendor tree?
> 
> Should this continue as a vendor-tree request?
> 
> See the template below.
> 
> thanks,
> Amanda
> 
> =====
> 
> Name: Ryen Krusinga
> 
> Email: [e-mail]
> 
> Media type name: application
> 
> Media subtype name: nits+xml
> 
> Required parameters: N/A
> 
> Optional parameters: "charset" The parameter has identical semantics
> to the charset parameter of the "application/xml" media type as
> specified in RFC 7303.
> 
> "sv" or "schemaversion" The parameter’s value is used to indicate the
> edition and version of the NITS (NATO ISR Track Standard) schema file
> to which the data is conformant. Allowed values are based on the
> nitsVersion attribute of the NitsRoot object as specified in Table
> 3.1-3 of AEDP-4676 Ed. A. Note that the XML schema itself is called
> AEDP-4676.2 beginning in STANAG 4676 Edition 3 and has no official
> name for prior editions; and it may have a different version number
> than the corresponding edition of the main standard. As of September
> 2026, allowed schemaversion values are:
> "B.1" Data is conformant to the XML schema for STANAG 4676 Edition 2
> covering AEDP-12 Edition B Version 1
> "B.2" Data is conformant to the XML schema for STANAG 4676 Edition 2
> covering AEDP-12 Edition B Version 2
> "C.1" Data is conformant to AEDP-4676.2 Ed. A Ver. 1, the XML schema
> for STANAG 4676 Edition 3 covering AEDP-4676 Ed. A
> If the "sv" and "schemaversion" parameters are absent, then the data
> consumer determines the version by examining file content. Edition 3
> is largely backwards compatible with Edition 2, so consumers should
> not reject data when the version is not included within the media
> type.
> 
> "profile" The parameter’s value is a comma-separated list of named
> profiles of NITS to which the data is conformant. The file includes
> values of the parameter as values of the "profile" attribute within
> the "nitsRoot" root element of the XML data.
> 
> Encoding considerations: binary
> 
> Based on the recommendation in the application:
> "If the format is based on JSON or XML, "binary" should generally be
> selected due to the possibility that lines could be longer than 998
> octets."
> Same as encoding considerations of application/xml as specified in RFC
> 7303.
> 
> Security considerations: Same as general security considerations for
> application/xml as specified in section 10 of RFC 3023.
> 
> While AEDP-4676.2 Ed. A is the published XSD that defines the XML
> encoding of NITS for STANAG 4676 Ed. 3, the schema supports the XSD
> 1.1 open content model and allows additional content to be inserted
> anywhere in the file. While the standard content defined by NITS
> itself includes no executable content, it is possible for a data
> provider to insert additional XML entities into the file that do
> contain executable content. In addition to ensuring the data is valid
> and well-formed XML, data consumers MUST take care to not blindly
> process any unexpected data found in the file and should only parse or
> display content using mechanisms that prevent malformed or malicious
> data attacking the consumer.
> 
> In many applications, access to the NITS data is restricted for
> privacy and control issues. NITS itself defines no mechanisms to
> restrict access to the data. As such, data providers MUST implement
> their own access methods to prevent unauthorized access to the data,
> and the transmission of the NITS data MUST be protected using standard
> encryption methods such as SSL/TLS. NITS files may include elements
> specifying confidentiality and how access to the data is restricted or
> permitted, encoded in the XML using ADatP-4774, the NATO
> Confidentiality Metadata Label Syntax. Consumers that discover ADatP-
> 4774 markings within NITS data MUST not provide further access to the
> data beyond what is permitted by those markings. Consumers that
> discover ADatP-4774 markings but do not recognize the specific
> markings MUST not provide any further access to the received data
> until permission to access the data can be authoritatively confirmed.
> 
> Interoperability considerations: Same as Interoperability
> considerations as specified in RFC 7303.
> 
> If both "sv" and "schemaversion" are specified, then the value of
> "schemaversion" MUST be ignored.
> 
> Structuring and validating the NITS data requires the XML schema files
> for the corresponding edition, Ed. 2 or Ed. 3. For Ed. 3, the schema
> files are published as AEDP-4676.2 and are also available upon request
> from the STANAG 4676 custodial support team (CST); for Ed. 2, they are
> only available by contacting the CST.
> 
> Published specification: STANAG 4676 Ed. 2
> AEDP-12 Edition B Version 2: "NATO ISR Tracking Standard, Edition B,
> Version 2"
> Available via the NSO NSDD (https://nso.nato.int)
> 
> STANAG 4676 Edition 3
> AEDP-4676 Edition A Version 1: "NATO ISR Track Standard, Edition A,
> Version 1"
> AEDP-4676.1 Edition A Version 1. "NATO ISR Track Standard
> Implementation Guide, Edition A, Version 1"
> AEDP-4676.2 Edition A Version 1: "NATO ISR Track Standard XML Schema
> Definition, Edition A, Version 1"
> Available by contacting the STANAG 4676 Custodian; currently under
> review and expected to be published in late 2026/early 2027 via the
> NSO NSDD
> 
> STANAG 4774
> ADatP-4774: "NATO Confidentiality Metadata Label Syntax"
> Available via the NSO NSDD
> 
> Applications which use this media: The NATO Intelligence, Surveillance
> and Reconnaissance (ISR) Track Standard (NITS) defines a standard
> format for object track data (data on the trajectories of real-world
> moving objects, such as boats, trucks or airplanes). NITS files are
> intended for use by applications that generate, analyze, and
> synthesize object track data for intelligence, surveillance, and
> reconnaissance purposes. The typical use case is for intelligence or
> defense systems communicating target information for the purposes of
> intelligence, analysis, and battlefield responsiveness. However, this
> is not an exhaustive list of possible uses, and there is nothing in
> the standard that prevents use in other environments (e.g., commercial
> truck fleet tracking, parents tracking the movement of their
> children’s electronic devices, tracking checked baggage through an
> airport baggage handling system, etc.)
> 
> Fragment identifier considerations: Same as fragment identifier
> considerations as specified in RFC 7303.
> 
> In addition, identifiers can be assigned to many of the elements in
> NITS, either using UUIDs (the "uid" element) or simple integers with
> local scope (the "lid" element). The uid values can be used to refer
> to a fragment of one NITS file from another file; this mechanism is
> heavily relied on to avoid repeating static data across a large
> sequence of NITS files. While the lid values alone cannot be used to
> refer to an element from outside the file, a local scope identifier (a
> UUID) can be assigned within each file, allowing the combination of
> local scope identifier and the simple local integer identifier can be
> used to refer to fragments of an NITS file from external resources.
> 
> Restrictions on usage: None
> 
> Provisional registration? (standards tree only): No
> 
> Additional information:
> 
> 1. Deprecated alias names for this type: N/A
> 2. Magic number(s): Same as magic numbers specified by RFC 7303
> 3. File extension(s): .nits
> 4. Macintosh file type code: N/A
> 5. Object Identifiers: N/A
> 
> General Comments:
> 
> Person to contact for further information:
> 
> 1. Name: Rob Downs
> 2. Email: [e-mail]
> 
> Intended usage: COMMON
> 
> Author/Change controller: NATO STANAG 4676 CST