Network Working Group                                        A. Melnikov
Internet-Draft                                                 Isode Ltd
Intended status: Informational                                   G. Lunt
Expires: September 8, 2011                                      SMHS Ltd
                                                           March 7, 2011


 Registration of Military Message Handling System (MMHS) header fields
                        for use in Internet Mail
                  draft-melnikov-mmhs-header-fields-00

Abstract

   A Miltary Message Handling System (MMHS) processes formal messages
   ensuring release, distribution, security, and timely delivery across
   national and international strategic and tactical networks.  The MMHS
   Elements of Service are defined as a set of extensions to the ITU-T
   X.400 (1992) international standards and are specified in STANAG 4406
   Edition 2.  This document describes a method for enabling those MMHS
   Elements of Service that are defined as Heading Extension to be
   encoded as RFC 5322 (Internet Email) message header fields.  These
   header field definitions support the provision of a STANAG 4406 MMHS
   over Internet Email, and also provides for a STANAG 4406 / Internet
   Email Gateway supporting message conversion compliant to this
   specification.

Status of This Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 8, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Melnikov & Lunt         Expires September 8, 2011               [Page 1]


Internet-Draft             MMHS header fields                 March 2011


   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 . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
   3.  Registration Templates . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Permanent MMHS Header Field Registrations  . . . . . . . .  4
     3.2.  Header field: MMHS-Exempted-Address  . . . . . . . . . . .  4
     3.3.  Header field: MMHS-Extended-Authorisation-Info . . . . . .  5
     3.4.  Header field: MMHS-Subject-Indicator-Codes . . . . . . . .  5
     3.5.  Header field: MMHS-Handling-Instructions . . . . . . . . .  6
     3.6.  Header field: MMHS-Message-Instructions  . . . . . . . . .  6
     3.7.  Header field: MMHS-Codress-Message-Indicator . . . . . . .  7
     3.8.  Header field: MMHS-Originator-Reference  . . . . . . . . .  7
     3.9.  Header field: MMHS-Primary-Precedence  . . . . . . . . . .  8
     3.10. Header field: MMHS-Copy-Precedence . . . . . . . . . . . .  8
     3.11. Header field: MMHS-Message-Type  . . . . . . . . . . . . .  9
     3.12. Header field: MMHS-Other-Recipient-Indicator . . . . . . . 10
     3.13. Header field: MMHS-Acp127-Message-Identifier . . . . . . . 10
     3.14. Header field: MMHS-Originator-PLAD . . . . . . . . . . . . 11
   4.  Formal Syntax  . . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Service in Comparison to STANAG 4406 . . . . . . . . . . . . . 13
   6.  Gatewaying with STANAG 4406  . . . . . . . . . . . . . . . . . 14
   7.  Gatewaying with ACP 127  . . . . . . . . . . . . . . . . . . . 15
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     10.2. Informative References . . . . . . . . . . . . . . . . . . 16
   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 16












Melnikov & Lunt         Expires September 8, 2011               [Page 2]


Internet-Draft             MMHS header fields                 March 2011


1.  Introduction

   [RFC5322] defines a protocol for the format of electronic messages
   exchanged on the Internet.  MMHS is a military specification defined
   in STANAG 4406 [STANAG-4406] which defines a number of extensions to
   the basic X.400 (1992) protocol for the services required by military
   mail.

   This document enables the provision of most of the elements of
   service defined in STANAG 4406 [STANAG-4406] for Internet Email.
   This specification is written to extend the MIXER specification
   [RFC2156] to enable inter-conversion in a MIXER gateway with the
   X.400 IPMS heading extensions defined in STANAG 4406 Annex A.

   The document is primarily aimed at the ability to represent MMHS
   messages in RFC 5322.  The RFC 5322 header fields defined are
   prefixed with the string "MMHS-" to distinguish them from any other
   header fields.

2.  Conventions Used in This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   The formal syntax use the Augmented Backus-Naur Form (ABNF) [RFC5234]
   notation including the core rules defined in Appendix B of RFC 5234
   [RFC5234].

3.  Registration Templates

   Header field entries are summarized in tabular form for convenience
   of reference and presented in full in the following sections.

   Any header field specified in this document MUST NOT appear more than
   once in message headers.















Melnikov & Lunt         Expires September 8, 2011               [Page 3]


Internet-Draft             MMHS header fields                 March 2011


3.1.  Permanent MMHS Header Field Registrations

   +----------------------------------+----------+---------------------+
   | Header name                      | Protocol | Reference           |
   +----------------------------------+----------+---------------------+
   | MMHS-Exempted-Address            | mail     | [STANAG-4406], A1.1 |
   |                                  |          | and B.105           |
   | MMHS-Extended-Authorisation-Info | mail     | [STANAG-4406], A1.2 |
   |                                  |          | and B.106           |
   | MMHS-Subject-Indicator-Codes     | mail     | [STANAG-4406], A1.3 |
   |                                  |          | and B.107           |
   | MMHS-Handling-Instructions       | mail     | [STANAG-4406], A1.4 |
   |                                  |          | and B.108           |
   | MMHS-Message-Instructions        | mail     | [STANAG-4406], A1.5 |
   |                                  |          | and B.109           |
   | MMHS-Codress-Message-Indicator   | mail     | [STANAG-4406], A1.6 |
   |                                  |          | and B.110           |
   | MMHS-Originator-Reference        | mail     | [STANAG-4406], A1.7 |
   |                                  |          | and B.111           |
   | MMHS-Primary-Precedence          | mail     | [STANAG-4406], A1.8 |
   |                                  |          | and B.101           |
   | MMHS-Copy-Precedence             | mail     | [STANAG-4406], A1.9 |
   |                                  |          | and B.102           |
   | MMHS-Message-Type                | mail     | [STANAG-4406],      |
   |                                  |          | A1.10 and B.103     |
   | MMHS-Other-Recipient-Indicator   | mail     | [STANAG-4406],      |
   |                                  |          | A1.12 and B.113     |
   | MMHS-Acp127-Message-Identifier   | mail     | [STANAG-4406],      |
   |                                  |          | A1.14 and B.116     |
   | MMHS-Originator-PLAD             | mail     | [STANAG-4406],      |
   |                                  |          | A1.15 and B.117     |
   +----------------------------------+----------+---------------------+

3.2.  Header field: MMHS-Exempted-Address

   Applicable protocol: mail [RFC5322]
   Status: informational
   Author/change controller:
   Specification document(s): [[anchor5: this document]]

   The exempted address header field, by its presence indicates the
   addresses of members in an Address List (AL) that should not receive
   the message.  If this extension is absent from the Extensions heading
   field, all members of an AL will be considered to be valid recipients
   of the message.  Note: There is no guarantee that the exempted
   addresses will not receive the message as the result of redirection,
   Distribution List (DL) expansion, etc.




Melnikov & Lunt         Expires September 8, 2011               [Page 4]


Internet-Draft             MMHS header fields                 March 2011


   Example:
   MMHS-Exempted-Address: UK SHL CGT Samuals G
    <graham.samuals@shl.example.com>, UK SHL Duty Officer
   <duty@shl.example.com>

3.3.  Header field: MMHS-Extended-Authorisation-Info

   Applicable protocol: mail [RFC5322]
   Status: informational
   Author/change controller:
   Specification document(s): [[anchor7: this document]]

   The extended authorisation info header field, by its presence
   indicates either the date and the time when the message was
   officially released by the releasing officer or the date and time
   when the message was submitted to a communication facility for
   transmission.

   This header field SHOULD always be present in an email message which
   complies with this specification.

   Example:
   MMHS-Extended-Authorisation-Info:
    Mon, 09 Aug 2010 15:27:40 +0200

   The example above demonstrates use of folding white space (FWS
   [RFC5322]).

3.4.  Header field: MMHS-Subject-Indicator-Codes

   Applicable protocol: mail [RFC5322]
   Status: informational
   Author/change controller:
   Specification document(s): [[anchor9: this document]]

   The subject indicator codes (SIC) header field, by its presence
   indicates distribution information to a recipient or a recipient's
   User Agent.  This information can be used to perform automatic or
   manual local distribution of a message.  If this header field is
   absent, then the local distribution will be in accordance with the
   message handling policy of the recipient's domain.

   [STANAG-4406] specifies two optional components of the Distribution
   Code Element of Service.  This header field covers only the SIC code
   variant of distribution codes.  SICs are the published, nested codes
   that provide information for message distribution after delivery to
   the recipient organisation.




Melnikov & Lunt         Expires September 8, 2011               [Page 5]


Internet-Draft             MMHS header fields                 March 2011


   Example:
   MMHS-Subject-Indicator-Codes: SDM; KKZ ; BRL

   The example above includes 3 SIC codes: "SDM" (GROUND/LAND
   REQUIREMENTS), "KKZ" (HELICOPTER PUBLICATIONS/MANUALS) and "BRL"
   (HILEX INCIDENTS).

3.5.  Header field: MMHS-Handling-Instructions

   Applicable protocol: mail [RFC5322]
   Status: informational
   Author/change controller:
   Specification document(s): [[anchor11: this document]]

   The handling instructions header field, by its presence indicates
   human readable local handling instructions that requires some manual
   handling by a traffic operator.  If this header field is absent the
   message will be considered as not requiring manual handling by a
   traffic operator.

   Handling instructions (also called transmission instructions) are a
   part of format line 4 as defined in ACP 127, and concern the sending
   of the message, e.g. that a particular system shall be used for
   transfer of the message.

   This header field is used only to support interoperability with ACP
   127 systems.  It is not a necessity within the MMHS and is for
   transition purposes only.

   Example:
   MMHS-Handling-Instructions: ZNY; RRRRR

   The example above includes 2 ACP127(G) handling instructions
   examples: "ZNY" and "RRRRR".  "ZNY" indicates that the message is
   transmitted over networks that meet security criteria for classified
   handling.  "RRRRR" indicates that the network must be at least of
   Restricted Sensitivity for transmitting the message.

3.6.  Header field: MMHS-Message-Instructions

   Applicable protocol: mail [RFC5322]
   Status: informational
   Author/change controller:
   Specification document(s): [[anchor13: this document]]

   The message instructions header field, by its presence indicates
   message instructions accompanying the message (e.g., similar to the
   operating signals specified in ACP 131).  If this header field is



Melnikov & Lunt         Expires September 8, 2011               [Page 6]


Internet-Draft             MMHS header fields                 March 2011


   absent the message will be considered received without message
   instructions.

   The difference between Handling instructions and Message instructions
   is that the former is only for manual handling by traffic operators,
   while the latter also contains information of interest to the persons
   reading the message.

   Example:
   MMHS-Message-Instructions: MINIMIZE CONSIDERED; NO DISTRIBUTION

   The example above includes 2 ACP123(B) defined message instructions:
   "MINIMIZE CONSIDERED" indicating that the originating user has
   considered the Minimize status of the recipients and "NO
   DISTRIBUTION", indicating that the recipients should not distribute
   the message further without the originating user's approval.

3.7.  Header field: MMHS-Codress-Message-Indicator

   Applicable protocol: mail [RFC5322]
   Status: informational
   Author/change controller:
   Specification document(s): [[anchor15: this document]]

   The codress message indicator header field, by its presence indicates
   that the message is in codress format.  If this header field is
   absent the message will be considered received without the codress
   format.

   A Codress message is one in which the entire address is encrypted
   within the text.  The Heading of the Codress message contains
   information only necessary for appropriately trained staff to handle
   the message properly.

   This header field is used only to support interoperability with ACP
   127 systems.

   Example:
   MMHS-Codress-Message-Indicator: 23

3.8.  Header field: MMHS-Originator-Reference

   Applicable protocol: mail [RFC5322]
   Status: informational
   Author/change controller:
   Specification document(s): [[anchor17: this document]]

   The originator reference header field, by its presence indicates a



Melnikov & Lunt         Expires September 8, 2011               [Page 7]


Internet-Draft             MMHS header fields                 March 2011


   user defined reference called the "originator's number".  If this
   header field is absent, then the message will be considered received
   without any user defined reference.

   The "originator's number" is used by the originating organisational
   unit and is further qualified within national policy.

   Note: trailing and leading spaces in an originator reference are not
   allowed.  Any leading or trailing spaces would be stripped.

   Example:
   MMHS-Originator-Reference: UNCLAS WHAT WAS 1500Z POSITION OF USS
   ESTES

3.9.  Header field: MMHS-Primary-Precedence

   Applicable protocol: mail [RFC5322]
   Status: informational
   Author/change controller:
   Specification document(s): [[anchor19: this document]]

   The primary precedence header field, by its presence indicates the
   precedence level of the primary ("action") recipients.  The message
   originating domain shall ensure that this header field is always
   present if the message contains "To:" (action) addresses.

   The MMHS Primary Precedence Element of Service indicates the relative
   order in which Military Messages are to be handled for primary
   (action) recipients.

   The header field value is an integer, or one of the 6 predefined
   case-insensitive labels: "deferred" (same as "0"), "routine" (same as
   "1"), "priority" (same as "2"), "immediate" (same as "3"), "flash"
   (same as "4"), or "override" (same as "5").

   Example 1:
   MMHS-Primary-Precedence: 0 (Deferred)

   Example 2:
   MMHS-Primary-Precedence: FLASH

   Example 3:
   MMHS-Primary-Precedence: 7

3.10.  Header field: MMHS-Copy-Precedence

   Applicable protocol: mail [RFC5322]
   Status: informational



Melnikov & Lunt         Expires September 8, 2011               [Page 8]


Internet-Draft             MMHS header fields                 March 2011


   Author/change controller:
   Specification document(s): [[anchor21: this document]]

   The copy precedence header field by its presence indicates the
   precedence level of the copy ("information") recipients.  The message
   originating domain shall ensure that this header field is always
   present if the message contains "Cc:" or "Bcc:" (information)
   addresses.

   The MMHS Copy Precedence Element of Service indicates the relative
   order in which Military Messages are to be handled for copy
   (information) recipients.

   The header field value is an integer, or one of the 6 predefined
   case-insensitive labels: "deferred" (same as "0"), "routine" (same as
   "1"), "priority" (same as "2"), "immediate" (same as "3"), "flash"
   (same as "4"), or "override" (same as "5").

   Example 1:
   MMHS-Copy-Precedence: 4 (flash)

   Example 2:
   MMHS-Copy-Precedence: Flash

3.11.  Header field: MMHS-Message-Type

   Applicable protocol: mail [RFC5322]
   Status: informational
   Author/change controller:
   Specification document(s): [[anchor23: this document]]

   The message type heading extension, by its presence indicates whether
   the message is to be considered as an exercise, an operation, a
   project or a drill.  It may includes an optional parameter specifying
   the name of the exercise, operation, project or drill.  If this
   extension is absent the message will be considered to be an undefined
   typed.

   The header field value is a non-negative integer, or one of the 4
   predefined case-insensitive labels: "exercise" (same as "0"),
   "operation" (same as "1"), "project" (same as "2"), "drill" (same as
   "3").

   Example 1:
   MMHS-Message-Type: 0(exercise); identifier="CANDLE FISH"

   Example 2:
   MMHS-Message-Type: 3



Melnikov & Lunt         Expires September 8, 2011               [Page 9]


Internet-Draft             MMHS header fields                 March 2011


   Example 3:
   MMHS-Message-Type: 2 (projet)

   Example 4:
   MMHS-Message-Type: project

3.12.  Header field: MMHS-Other-Recipient-Indicator

   Applicable protocol: mail [RFC5322]
   Status: informational
   Author/change controller:
   Specification document(s): [[anchor25: this document]]

   The other recipients indicator header field, by its presence
   indicates the names of recipients, as well as the category (primary
   or copy) in which they are placed, that are intended to receive or
   have received the message via means other than MMHS.  The absence of
   this element does not guarantee that all recipients are within the
   MMHS.

   This MMHS Element of Service enables an MMHS recipient to determine
   all recipients of a Military Message.  There are several reasons as
   to why a recipient of a Military Message may be identified by this
   header:

   1.  The recipient is not part of the MMHS

   2.  The path to the recipient through the MMHS may not be secure,
       therefore, the originator has used alternative mechanisms to
       distribute the Military Message

   3.  The recipient was already in receipt of the Military Message
       prior to it being inserted into the MMHS

   Example:
   MMHS-Other-Recipient-Indicator: primary="UK SHL COS"; COPY = "UK SHL
   LEGAD"

   The example above includes names of 2 recipients which received the
   message via means other than MMHS.  One of the recipients is primary
   (action) and another is a copy (information) recipient.

3.13.  Header field: MMHS-Acp127-Message-Identifier

   Applicable protocol: mail [RFC5322]
   Status: informational
   Author/change controller:
   Specification document(s): [[anchor27: this document]]



Melnikov & Lunt         Expires September 8, 2011              [Page 10]


Internet-Draft             MMHS header fields                 March 2011


   The ACP127 message identifier header field, by its presence indicates
   an ACP 127 message identifier which originated from an ACP 127
   domain.  If this extension is absent, then the message did not
   encounter an ACP 127 domain.

   The acp127-message-identifier contains the contents of ACP127 format
   line 3 consisting of the Calling Station (DERI), Station Serial
   Number (SSN), and Filing Time (JFT).

   This header field is used only to support interoperability with ACP
   127 systems.

   Example:
   MMHS-Acp127-Message-Identifier: RPDLE 123 11/1215Z

3.14.  Header field: MMHS-Originator-PLAD

   Applicable protocol: mail [RFC5322]
   Status: informational
   Author/change controller:
   Specification document(s): [[anchor29: this document]]

   The originator Plain Language Address Designators (PLAD) header
   field, by its presence indicates the plain language address
   associated with an originator for cross reference purposes.  If this
   header field is absent, then the message will be considered to not
   having an originators PLAD cross reference between the MMHS and ACP
   127 domains.

   This header field is used only to support interoperability with ACP
   127 systems.

   This MMHS header field and the Extended Authorisation Info header
   field provide a cross reference for message identification in both
   ACP 127 and MMHS domains.

   Example:
   MMHS-Originator-PLAD: SACLANT

4.  Formal Syntax

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) as described in [RFC5234].  Terms not defined here are
   taken from [RFC5322] and [RFC2156].

    NZ-DIGIT       =  %x31-39
                      ; "1".."9"




Melnikov & Lunt         Expires September 8, 2011              [Page 11]


Internet-Draft             MMHS header fields                 March 2011


    nonneg-integer = "0" / (NZ-DIGIT *DIGIT)

    integer = ["-" / "+"] nonneg-integer
              ; ////Any min/max limit?

    military-string = 1*69( ps-char )

    quoted-military-string = DQUOTE military-string DQUOTE

    military-string-sequence = military-string [ [FWS] ";" [FWS] military-string-sequence ]

    Exempted-Address = "MMHS-Exempted-Address:" [FWS] address-list [FWS] CRLF
     ;; /////Are "[FWS]" around address-list needed/allowed?

    Extended-Authorisation-Info = "MMHS-Extended-Authorisation-Info:" [FWS] date-time CRLF

    Subject-Indicator-Codes = "MMHS-Subject-Indicator-Codes:" [FWS] [sic-sequence] [FWS] CRLF

    sic-sequence = sic *( [FWS] ";" [FWS] sic )
                   ; STANAG 4406 specifies that the maximum number of SICs is 8.
                   ; Use of more than 8 SIC codes is permitted, but additional
                   ; SIC codes might not be transferred to STANAG 4406 system

    sic = 3*8( ps-char )

    Handling-Instructions = "MMHS-Handling-Instructions:"
                            [FWS] military-string-sequence [FWS] CRLF

    Message-Instructions = "MMHS-Message-Instructions:"
                           [FWS] military-string-sequence [FWS] CRLF

    Codress-Message-Indicator = "MMHS-Codress-Message-Indicator:" [FWS] integer [FWS] CRLF

    Originator-Reference = "MMHS-Originator-Reference:"
                           [FWS] military-string [FWS] CRLF

    PrimaryPrecedence = "MMHS-Primary-Precedence:" [FWS] precedence CRLF

    CopyPrecedence = "MMHS-Copy-Precedence:" [FWS] precedence CRLF

    precedence = (nonneg-integer / std-precedence) [CFWS]

    std-precedence = "deferred" / "routine" / "priority" /
                     "immediate" / "flash" / "override"
                     ; deferred == 0
                     ; routine == 1
                     ; priority == 2
                     ; immediate == 3



Melnikov & Lunt         Expires September 8, 2011              [Page 12]


Internet-Draft             MMHS header fields                 March 2011


                     ; flash == 4
                     ; override == 5

    MessageType = "MMHS-Message-Type:" [FWS] message-type [CFWS]
                  [";" [FWS] MessageTypeParam ] [FWS] CRLF

    message-type = nonneg-integer / std-message-type

    std-message-type = "exercise" / "operation" / "project" /  "drill"
                       ; exercise  == 0
                       ; operation == 1
                       ; project == 2
                       ; drill == 3

    MessageTypeParam = "identifier" [FWS] "=" [FWS] quoted-military-string

    DesignatorType = "primary" / "copy"

    Designator = DesignatorType [FWS] "=" [FWS] quoted-military-string

    OtherRecipientIndicator = "MMHS-Other-Recipient-Indicator:"
                              [FWS] Designator *([FWS] ";" [FWS] Designator) [FWS] CRLF

    Acp127MessageIdentifier = "MMHS-Acp127-Message-Identifier:"
                              [FWS] military-string [FWS] CRLF

    OriginatorPLAD = "MMHS-Originator-PLAD:" [FWS] military-string [FWS] CRLF

5.  Service in Comparison to STANAG 4406

   The service specified in this document is a subset of the
   functionality set out in Annex A1 "Military Heading Extensions" of
   [STANAG-4406].  The majority of this functionality is supported.  A
   few capabilities have been left out which would have significantly
   increased the complexity of this specification, and do not appear to
   be of significant benefit.

   For Distribution Codes (A.1.3) only Subject Indicator Codes are
   supported and Distribution Extensions are omitted.  Distribution
   extensions are not widely used, and encoding ANY DEFINED BY in this
   specification would be difficult.

   Address List Indication (A.1.11) is not supported.  This complex
   extension is deprecated in [STANAG-4406].

   Pilot Forwarding Information (A.1.13) is not supported.  This complex
   extension is only for ACP 127 transition, and is not widely used.




Melnikov & Lunt         Expires September 8, 2011              [Page 13]


Internet-Draft             MMHS header fields                 March 2011


   Security Information Labels (A.1.16) is not supported.  This
   extension is deprecated in favour of Annex A, which uses ESS Labels
   [RFC2634] which can be supported in a directly compatible manner in
   S/MIME.

6.  Gatewaying with STANAG 4406

   The header fields defined in this specification are designed to be
   mapped with STANAG 4406 Annex A1 heading extensions as part of a
   MIXER mapping according to [RFC2156].  The syntax of these headings
   is defined such that mapping is mechanical.  OR Names should be
   mapped with Internet Email addresses according to [RFC2156].

   This section summarizes how a gateway between [STANAG-4406] and
   [RFC5322] conformant to this specification operates.

   If an incoming X.400 message is encoded as P772, [RFC5322] header
   fields MUST be generated according to this specification for all
   STANAG 4406 heading extensions where an equivalent header is defined
   in this specification.  For the three heading extensions where no
   mapping is defined the heading extension MAY be discarded or mapped
   in a proprietary manner.  If a Distribution Extension is encoded this
   MAY be discarded or represented as a comment.  The whole message MAY
   be signed according to [RFC5652].  These rules also apply to heading
   extensions in forwarded messages.  Forwarded content MUST be treated
   as a forwarded message for the purposes of MIXER mapping.

   If an incoming SMTP message contains any of the header fields defined
   in this specification, the outgoing X.400 message MUST be encoded as
   P772.  The outgoing message MAY be encoded as P772 for other reasons,
   such as policy or characteristics such as the message containing a
   military body part.  The X.400 message MAY be signed according to
   STANAG 4406 Annex B and Annex G.  message/rfc822 body parts included
   in the message SHOULD be mapped to forwarded content, and the heading
   mapping rules applied.

   Generated P772 messages SHOULD follow the following rules, generating
   heading extensions if needed.

   a.  Extended Authorization is required.  If the MMHS-Extended-
       Authorisation-Info header field is absent, then the default value
       is taken from the Date: header field.

   b.  Primary Precedence is required if the To header field is present.
       If the MMHS-Primary-Precedence header field is absent, the
       default value is "priority".





Melnikov & Lunt         Expires September 8, 2011              [Page 14]


Internet-Draft             MMHS header fields                 March 2011


   c.  Copy Precedence is required if the Cc header field is present.
       If the MMHS-Copy-Precedence header field is absent, then the
       Default value is the value of the Primary Precedence as
       constructed above.

   d.  For Message-ID fields, STANAG 4406 applies additional constraints
       over X.400, leading to the following rules additional to
       [RFC2156] which SHOULD be followed by a gateway following this
       specification.

       1.  The local identifier MUST be at least 15 characters long.  If
           the [RFC2156] generated value is shorter than this, then it
           is padded with spaces to 15 characters.  This value will
           correctly reverse map.

       2.  The OR Address part is required, and not usually generated by
           an [RFC2156] mapping.  It is mandatory in STANAG 4406.  The
           gateway SHOULD generate an OR Address in a manner that can be
           reverse mapped.  It MAY use the OR Address to encode long
           message ids that cannot be encoded in the local identifier.

7.  Gatewaying with ACP 127

   The header fields defined in this specification include fields to
   carry ACP 127 specific elements of service.  This specification does
   not define a mapping of these header fields to ACP 127.  In the
   absence of this mapping, it is recommended that these heading should
   be mapped to STANAG 4406 and hence into ACP 127 following the Annex D
   (Gateway Translation) of [STANAG-4406].

8.  IANA Considerations

   IANA is requested to add the list of header fields specified in
   Section 3 (and its subsections) to the "Permanent Message Header
   Field Registry", defined by Registration Procedures for Message
   Header Fields [RFC3864].

9.  Security Considerations

   No security considerations are introduced by this document beyond
   those already inherent in use of the P772 header fields referenced.

10.  References

10.1.  Normative References

   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.



Melnikov & Lunt         Expires September 8, 2011              [Page 15]


Internet-Draft             MMHS header fields                 March 2011


   [RFC5322]      Resnick, P., Ed., "Internet Message Format", RFC 5322,
                  October 2008.

   [RFC5234]      Crocker, D. and P. Overell, "Augmented BNF for Syntax
                  Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC2156]      Kille, S., "MIXER (Mime Internet X.400 Enhanced
                  Relay): Mapping between X.400 and RFC 822/MIME",
                  RFC 2156, January 1998.

   [RFC3864]      Klyne, G., Nottingham, M., and J. Mogul, "Registration
                  Procedures for Message Header Fields", BCP 90,
                  RFC 3864, September 2004.

   [RFC5652]      Housley, R., "Cryptographic Message Syntax (CMS)",
                  STD 70, RFC 5652, September 2009.

   [STANAG-4406]  NATO, "STANAG 4406 Edition 2: Military Message
                  Handling System", STANAG 4406, March 2005.

10.2.  Informative References

   [RFC2634]      Hoffman, P., "Enhanced Security Services for S/MIME",
                  RFC 2634, June 1999.

Appendix A.  Acknowledgements

   This document copies lots of text from
   draft-onions-x400p772-822-mapping-01.txt and STANAG 4066 (2nd
   Edition).  So the author of this document would like to acknowledge
   contributions made by the authors of
   draft-onions-x400p772-822-mapping: Graeme Lunt and Julian Onions.

   Many thanks for input and text provided by Steve Kille, Alan Ross,
   David Wilson and James Usmar.

Authors' Addresses

   Alexey Melnikov
   Isode Ltd
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   EMail: Alexey.Melnikov@isode.com





Melnikov & Lunt         Expires September 8, 2011              [Page 16]


Internet-Draft             MMHS header fields                 March 2011


   Graeme Lunt
   SMHS Ltd
   Bescar Moss Farm
   Bescar Lane
   Ormskirk  L40 9QN
   UK

   EMail: graeme.lunt@smhs.co.uk











































Melnikov & Lunt         Expires September 8, 2011              [Page 17]