Appendix A. Agreed Profiles

Defines military header fields to be used for SMTP messages that are gatewayed across military mail environment boundaries.

Defines the Standards Profile for Federated Mission Networking (FMN) Spiral 1. FMN Standards Profiles provide a suite of interoperability standards and other standardized profiles for interoperability of selected community of interest services, core services and communications services in a federation of mission networks. It places the required interoperability requirements, standards and specifications in context for FMN Affiliates.

Outlines the file formats and package structures approved by the Archives Committee for the long-term preservation of NATO digital information of permanent value.

This Service Interface Profile (SIP) describes the key elements that make up the NNEC Core Enterprise Services (CES) Security Services.

This specification provides the profile for securing representational state transfer (REST) web services (known as RESTful web services) that are deployed within the NNEC web service infrastructure. It specifies security requirements that need to be accounted for depending on the environment in which the services are being deployed, and the level of assurance required for protecting those services. This profile covers the required security protection profile for a Client to access protected resources on a Resource Server using REST.

The purpose of this Service Interface Profile (SIP) is to specify how the security token service component of the Core Enterprise Services (CES) Security Services may be called.

The purpose of this Service Interface Profile (SIP), which should be read along with the Agency Directive 06.05.04.02.H 2, "Service Interface Profile for Security Services" [NCIA AD 06.05.04.02.H], is to specify how services may be called that are protected by the Core Enterprise Services (CES) Security Services.

The purpose of this Service Interface Profile (SIP) is to specify the interface of the directory service itself.

This specification provides the interface control for simple object access protocol (SOAP) web services that are deployed within the NNEC web service infrastructure.

This specification provides the profile for securing representational state transfer (REST) web services (known as RESTful web services) that are deployed within the NNEC web service infrastructure. This covers only the call from a Web Service Consumer to a Web Service Provider using REST, and the response from the service provider. It includes how the message must be structured and the elements that must be contained within the call.

This document gives directives along with clarifications and amendments to the [OASIS WS-BaseNotification, 2006] and [OASIS WS-BrokeredNotification, 2006] specification on how to implement a notification broker/subscription manager to promote interoperability between the publish/subscribe engines and generic message subscribers. Some extensions to the protocol have been introduced in order to meet NATO requirements.

This document is part of a Service Interface Profile (SIP) for Publish/Subscribe Core Enterprise Services (CES) and should be read together with the main document [NCIA AD 06.05.04.02.E]. It gives guidance on implementation of a WS-Notification compliant notification broker. It is REQUIRED that each notification broker implementation also includes the subscription manager functionality.

This document is part of a Service Interface Profile (SIP) for publish/subscribe Core Enterprise Services (CES) and should be read together with the main document "Service Interface Profile for Publish/Subscribe Services" [NCIA AD 06.05.04.02.E]. It gives guidance on implementation of a WS-Notification-compliant notification consumer.

This Service Interface Profile (SIP) describes the key eleme nts that make up the NNEC Core Enterprise Services (CES) Notification Cache service. It describes and profiles the operations which a Notification Cache service offers together with the associated message formats, and serves as a template and guideline for implementations.

This Collaboration Service Interface Profile (SIP) is focused on instant messaging and is based on the extensible messaging and presence protocol (XMPP).

This document specifies the Service Interface Profile (SIP) for a number of instant messaging services that can be implemented and used by any XMPP entity (XMPP Client or XMPP Server) on the XMPP network.

This document gives guidance on the implementation of a Map Rendering Service, being a special kind of a Geospatial Service.

Profile the use of cryptographic protocols, which can be used to implement support for different cryptographic techniques and mechanisms, for generating cryptographic artefacts to be stored in a cryptographic binding.

Confidentiality metadata labels can be supported in XMPP stanzas as indicated by XEP-0258 whereby a mechanism for carrying Enhanced Security Services (ESS) Security labels is standardized. This profile extends the XEP-0258 specification to support carrying an Embedded or Detached BDO for Message stanzas. This profile supports the XMPP use cases for one-to-one instant messaging and multi-user chat.

This Binding Profile for XMP describes how metadata should be incorporated within an XMP packet as a structured value.

This profile defines a generic packaging mechanism, based upon the Open Packaging Container (OPC) defined in ISO/IEC 29500-2:2008, to associate any arbitrary file that do not use the Office Open XML (OOXML) format or have no specific profile for supporting the Binding Information with their own file format.

Introduces and describes profiles for Binding Metadata to a Data Object which may and will be reused in other profiles.

This profile for the OOXML describes how metadata can be maintained.

In an environment where data objects must have bound metadata, the resource identified in the URI will already contain a BDO (detached, encapsulating or embedded). As such, there is no requirement for metadata binding that is specific for REST. However, to support information sharing between partners it may be necessary to locate a Binding Data Object (BDO) in the HTTP protocol layer.

Sidecar files allow the association of metadata with a data object for which there is no profile.

This profile specifies the mechanism for binding metadata to Internet Email (both formal and informal) including MIME entities.

Where there is a requirement to bind metadata to a SOAP message or data object (s) within the SOAP body that is exchanged between a service consumer and a service provider, the SOAP Binding Profile specified must be adhered to.