diff options
Diffstat (limited to 'doc/rfc/rfc6477.txt')
| -rw-r--r-- | doc/rfc/rfc6477.txt | 1179 |
1 files changed, 1179 insertions, 0 deletions
diff --git a/doc/rfc/rfc6477.txt b/doc/rfc/rfc6477.txt new file mode 100644 index 0000000..6bd48ce --- /dev/null +++ b/doc/rfc/rfc6477.txt @@ -0,0 +1,1179 @@ + + + + + + +Internet Engineering Task Force (IETF) A. Melnikov +Request for Comments: 6477 Isode Ltd +Category: Informational G. Lunt +ISSN: 2070-1721 SMHS Ltd + January 2012 + + Registration of Military Message Handling System (MMHS) + Header Fields for Use in Internet Mail + +Abstract + + A Military 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 and ACP 123. This document specifies message header fields + and associated processing for RFC 5322 (Internet Message Format) to + provide a comparable messaging service. In addition, this document + provides for a STANAG 4406 / Internet Email Gateway that supports + message conversion. + +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. + + 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/rfc6477. + +Copyright Notice + + Copyright (c) 2012 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 + + + +Melnikov & Lunt Informational [Page 1] + +RFC 6477 MMHS Header Fields January 2012 + + + 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. Conventions Used in This Document ...............................3 + 3. Registration Templates ..........................................3 + 3.1. Header Field: MMHS-Exempted-Address ........................5 + 3.2. Header Field: MMHS-Extended-Authorisation-Info .............5 + 3.3. Header Field: MMHS-Subject-Indicator-Codes .................6 + 3.4. Header Field: MMHS-Handling-Instructions ...................6 + 3.5. Header Field: MMHS-Message-Instructions ....................7 + 3.6. Header Field: MMHS-Codress-Message-Indicator ...............8 + 3.7. Header Field: MMHS-Originator-Reference ....................8 + 3.8. Header Field: MMHS-Primary-Precedence ......................9 + 3.9. Header Field: MMHS-Copy-Precedence ........................10 + 3.10. Header Field: MMHS-Message-Type ..........................10 + 3.11. Header Field: MMHS-Other-Recipients-Indicator-To .........11 + 3.12. Header Field: MMHS-Other-Recipients-Indicator-CC .........12 + 3.13. Header Field: MMHS-Acp127-Message-Identifier .............13 + 3.14. Header Field: MMHS-Originator-PLAD .......................13 + 4. Formal Syntax ..................................................14 + 5. Service in Comparison to ACP 123 / STANAG 4406 .................16 + 6. Gatewaying with ACP 123 / STANAG 4406 ..........................16 + 7. Gatewaying with ACP 127 ........................................18 + 8. IANA Considerations ............................................18 + 9. Security Considerations ........................................18 + 10. References ....................................................19 + 10.1. Normative References .....................................19 + 10.2. Informative References ...................................19 + Appendix A. Acknowledgements ......................................21 + +1. Introduction + + [RFC5322] defines a protocol for the format of electronic messages + exchanged on the Internet. MMHS is a military specification defined + in ACP 123 [ACP123] (also specified in STANAG 4406 [STANAG-4406]), + which defines a number of extensions to the basic X.400 (1992) + protocol for the services required by military messaging. + + This document supports translating most of the Elements of Service + defined in ACP 123 [ACP123] to Internet message header fields (see + Section 5 for more details). This specification is written to extend + the Mime Internet X.400 Enhanced Relay (MIXER) specification + + + + +Melnikov & Lunt Informational [Page 2] + +RFC 6477 MMHS Header Fields January 2012 + + + [RFC2156] to enable inter-conversion in a MIXER gateway with the + X.400 Interpersonal Messaging System (IPMS) heading extensions + defined in ACP 123 / STANAG 4406, Annex A. + + The document is aimed at the ability to represent MMHS messages as + RFC 5322 messages. All RFC 5322 header fields defined in this + document are prefixed with the string "MMHS-" to distinguish them + from any other header fields. + + Unless stated otherwise, all header fields described in this document + are OPTIONAL in an Internet Message. + + This document is structured as follows: Section 3 and its subsections + formally define new Internet header fields and show some examples. + Section 4 provides Augmented Backus-Naur Form (ABNF) syntax for them. + Section 5 provides some background information about which features + of ACP 123 / STANAG 4406 were not implemented in this specification. + Subsequent sections talk about additional requirements for gatewaying + to/from ACP 123 / STANAG 4406 and ACP 127 [ACP127] environments, + respectively. + +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 uses the ABNF [RFC5234] notation including the core + rules defined in Appendix B of RFC 5234 [RFC5234]. + +3. Registration Templates + + Header field entries are summarized below in tabular form for + convenience of reference and presented in full in the following + subsections. + + Any header field specified in this document MUST NOT appear more than + once in message headers. + + + + + + + + + + + + + +Melnikov & Lunt Informational [Page 3] + +RFC 6477 MMHS Header Fields January 2012 + + + +------------------------------------+----------+-------------------+ + | Header name | Protocol | Reference | + +------------------------------------+----------+-------------------+ + | MMHS-Exempted-Address | mail | [ACP123], | + | | | Appendices A1.1 | + | | | and B.105 | + | MMHS-Extended-Authorisation-Info | mail | [ACP123], | + | | | Appendices A1.2 | + | | | and B.106 | + | MMHS-Subject-Indicator-Codes | mail | [ACP123], | + | | | Appendices A1.3 | + | | | and B.107 | + | MMHS-Handling-Instructions | mail | [ACP123][ACP123], | + | | | Appendices A1.4 | + | | | and B.108 | + | MMHS-Message-Instructions | mail | [ACP123], | + | | | Appendices A1.5 | + | | | and B.109 | + | MMHS-Codress-Message-Indicator | mail | [ACP123], | + | | | Appendices A1.6 | + | | | and B.110 | + | MMHS-Originator-Reference | mail | [ACP123], | + | | | Appendices A1.7 | + | | | and B.111 | + | MMHS-Primary-Precedence | mail | [ACP123], | + | | | Appendices A1.8 | + | | | and B.101 | + | MMHS-Copy-Precedence | mail | [ACP123], | + | | | Appendices A1.9 | + | | | and B.102 | + | MMHS-Message-Type | mail | [ACP123], | + | | | Appendices A1.10 | + | | | and B.103 | + | MMHS-Other-Recipients-Indicator-To | mail | [ACP123], | + | | | Appendices A1.12 | + | | | and B.113 | + | MMHS-Other-Recipients-Indicator-CC | mail | [ACP123], | + | | | Appendices A1.12 | + | | | and B.113 | + | MMHS-Acp127-Message-Identifier | mail | [ACP123], | + | | | Appendices A1.14 | + | | | and B.116 | + | MMHS-Originator-PLAD | mail | [ACP123], | + | | | Appendices A1.15 | + | | | and B.117 | + +------------------------------------+----------+-------------------+ + + + + + +Melnikov & Lunt Informational [Page 4] + +RFC 6477 MMHS Header Fields January 2012 + + +3.1. Header Field: MMHS-Exempted-Address + + Applicable protocol: mail [RFC5322] + Status: informational + Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF + Specification document(s): [RFC6477] + + The MMHS-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 header field is absent from the + message, 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. + + Example: + MMHS-Exempted-Address: + UK SHL CGT Samuals G <graham.samuals@shl.example.com>, + UK SHL Duty Officer <duty@shl.example.com> + +3.2. Header Field: MMHS-Extended-Authorisation-Info + + Applicable protocol: mail [RFC5322] + Status: informational + Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF + Specification document(s): [RFC6477]] + + The MMHS-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 initially submitted to a communication facility + for transmission. + + This header field SHOULD always be present in an email message that + complies with this specification. + + Example: + MMHS-Extended-Authorisation-Info: + Mon, 09 Aug 2010 15:27:40 +0100 + + The example above demonstrates use of folding white space (FWS + [RFC5322]). + + + + + + + +Melnikov & Lunt Informational [Page 5] + +RFC 6477 MMHS Header Fields January 2012 + + +3.3. Header Field: MMHS-Subject-Indicator-Codes + + Applicable protocol: mail [RFC5322] + Status: informational + Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF + Specification document(s): [RFC6477] + + A Subject Indicator Code (SIC) is a mechanism for formally + identifying the topic of a message. SICs are nested codes that + provide information for message distribution after delivery to the + recipient organization. SICs are usually three letters or three + letters and digits, but may be up to eight characters long. Nations + and organizations using SICs usually maintain a central registry. + + When present, an MMHS-Subject-Indicator-Codes header field contains + one or more SICs, which 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 + the MMHS-Subject-Indicator-Codes header field is absent, then the + local distribution will be in accordance with the message handling + policy of the recipient's domain. + + [ACP123] specifies two optional components of the Distribution Code + Element of Service. The MMHS-Subject-Indicator-Codes header field + covers only the SIC code component of distribution codes. + + Example: + MMHS-Subject-Indicator-Codes: SDM; KKZ ; BRL + + The example above includes three SIC codes: "SDM" (GROUND/LAND + REQUIREMENTS), "KKZ" (HELICOPTER PUBLICATIONS/MANUALS), and "BRL" + (HILEX INCIDENTS). + +3.4. Header Field: MMHS-Handling-Instructions + + Applicable protocol: mail [RFC5322] + Status: informational + Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF + Specification document(s): [RFC6477] + + The MMHS-Handling-Instructions header field, by its presence, + indicates human-readable local handling instructions that require + 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. + + + + + + +Melnikov & Lunt Informational [Page 6] + +RFC 6477 MMHS Header Fields January 2012 + + + Handling instructions (also called "transmission instructions") are a + part of format line 4 as defined in ACP 127 [ACP127] 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 to support interoperability with ACP 127 + systems. + + Example: + MMHS-Handling-Instructions: RXFPA ZOV MINDEF + + The example above includes one ACP 131(F) handling instruction: + "RXFPA ZOV MINDEF". The "ZOV MINDEF" indicates that MINDEF rerouted + the message for some reason, and the correct routing is via RXFPA. + +3.5. Header Field: MMHS-Message-Instructions + + Applicable protocol: mail [RFC5322] + Status: informational + Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF + Specification document(s): [RFC6477] + + The MMHS-Message-Instructions header field, by its presence, + indicates message instructions (also known as "remarks") accompanying + the message (e.g., similar to the operating signals specified in ACP + 131 [ACP131]). If this header field is 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 two message instructions defined by + ACP123(B) [ACP123]: "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. + + + + + + + + + +Melnikov & Lunt Informational [Page 7] + +RFC 6477 MMHS Header Fields January 2012 + + +3.6. Header Field: MMHS-Codress-Message-Indicator + + Applicable protocol: mail [RFC5322] + Status: informational + Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF + Specification document(s): [RFC6477] + + The MMHS-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 all addresses, i.e., the sender and + all recipients, are encrypted within the ACP 127 text (body) + [ACP127]. The heading of any Codress message contains only the + minimum amount of information that will enable a receiving station to + deal properly and expeditiously with the particular transmission. + The general rules for the preparation and transmission of Codress + messages are given in ACP 121 [ACP121]. + + This header field is used only to support interoperability with ACP + 127 systems. + + Example: + MMHS-Codress-Message-Indicator: 23 + +3.7. Header Field: MMHS-Originator-Reference + + Applicable protocol: mail [RFC5322] + Status: informational + Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF + Specification document(s): [RFC6477] + + The MMHS-Originator-Reference header field, by its presence, + indicates a 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 organizational + unit and is further qualified within national policy. + + Note: trailing and leading spaces in an originator reference are not + allowed by syntax. + + Example: + MMHS-Originator-Reference: IMSCOM-JIC-612-78 + + + + + +Melnikov & Lunt Informational [Page 8] + +RFC 6477 MMHS Header Fields January 2012 + + +3.8. Header Field: MMHS-Primary-Precedence + + Applicable protocol: mail [RFC5322] + Status: informational + Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF + Specification document(s): [RFC6477] + + The MMHS-Primary-Precedence header field, by its presence, indicates + the precedence level of the primary ("action") recipients. The + message originating domain MUST 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, i.e., a Military Message with a higher MMHS- + Primary-Precedence header field value SHOULD be handled before a + Military Message with a lower MMHS-Primary-Precedence header field + value. + + The header field value is a non-negative integer, or one of the six + 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"), + optionally followed by a comment. Note that, according to ACP 123, + values in the range from 0 to 15 are reserved for NATO-defined + precedence levels, and values in the range from 16 to 31 are reserved + for national users. + + Example 1: + MMHS-Primary-Precedence: 0 (Deferred) + + Example 2: + MMHS-Primary-Precedence: FLASH + + Example 3: + MMHS-Primary-Precedence: 7 + + + + + + + + + + + + + + + +Melnikov & Lunt Informational [Page 9] + +RFC 6477 MMHS Header Fields January 2012 + + +3.9. Header Field: MMHS-Copy-Precedence + + Applicable protocol: mail [RFC5322] + Status: informational + Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF + Specification document(s): [RFC6477] + + The MMHS-Copy-Precedence header field, by its presence, indicates the + precedence level of the copy ("information") recipients. The message + originating domain MUST 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. i.e. a Military Message with higher MMHS- + Copy-Precedence header field value SHOULD be handled before a + Military Message with a lower MMHS-Copy-Precedence header field + value. + + The header field value is a non-negative 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"), + optionally followed by a comment. Note that according to ACP 123, + values in the range from 0 to 15 are reserved for NATO-defined + precedence levels and values in the range from 16 to 31 are reserved + for national users. + + Example 1: + MMHS-Copy-Precedence: 2 (priority) + + Example 2: + MMHS-Copy-Precedence: Priority + +3.10. Header Field: MMHS-Message-Type + + Applicable protocol: mail [RFC5322] + Status: informational + Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF + Specification document(s): [RFC6477] + + The MMHS-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. (Note that the list of types is extensible, + and other types can be specified using the numeric form, see below). + + + + + +Melnikov & Lunt Informational [Page 10] + +RFC 6477 MMHS Header Fields January 2012 + + + It may include 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 of an undefined type. + + The header field value is a non-negative integer, or one of the four + predefined case-insensitive labels: "exercise" (same as "0"), + "operation" (same as "1"), "project" (same as "2"), "drill" (same as + "3"). Note that according to ACP 123, values in the range from 0 to + 127 are reserved for NATO-defined Message Type identifiers and values + in the range from 128 to 255 are not defined by NATO and may be used + nationally or bilaterally. + + Example 1: + MMHS-Message-Type: 0(exercise); identifier="CANDLE FISH" + + Example 2: + MMHS-Message-Type: 3 + + Example 3: + MMHS-Message-Type: 2 (projet) + + Example 4: + MMHS-Message-Type: project + + Note that some of the examples above demonstrate use of optional + comments. See Section 4 for the exact syntax of this header field. + +3.11. Header Field: MMHS-Other-Recipients-Indicator-To + + Applicable protocol: mail [RFC5322] + Status: informational + Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF + Specification document(s): [RFC6477] + + The MMHS-Other-Recipients-Indicator-To header field, by its presence, + indicates the names of primary ("action") recipients that are + intended to receive, or have received, the message via means other + than MMHS. Note that the absence of both this header field and the + MMHS-Other-Recipients-Indicator-CC header field (see Section 3.12) + does not guarantee that all recipients are within the MMHS. + + This header field enables a recipient to determine all action + recipients of a Military Message. This header field is derived from + the Other Recipient Indicator Element of Service. + + + + + + + +Melnikov & Lunt Informational [Page 11] + +RFC 6477 MMHS Header Fields January 2012 + + + 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 the Military Message being inserted into the MMHS. + + Example: + MMHS-Other-Recipients-Indicator-To: UK SHL COS; UK SHL IM + + The example above includes names of two primary recipients that + received the message via means other than MMHS. + +3.12. Header Field: MMHS-Other-Recipients-Indicator-CC + + Applicable protocol: mail [RFC5322] + Status: informational + Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF + Specification document(s): [RFC6477] + + The MMHS-Other-Recipients-Indicator-CC header field, by its presence, + indicates the names of copy ("information") recipients that are + intended to receive, or have received, the message via means other + than MMHS. Note that the absence of both this header field and the + MMHS-Other-Recipients-Indicator-To header field (see Section 3.11) + does not guarantee that all recipients are within the MMHS. + + This header field enables a recipient to determine all copy + recipients of a Military Message. This header field is derived from + the Other Recipient Indicator Element of Service. + + 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. + + + + +Melnikov & Lunt Informational [Page 12] + +RFC 6477 MMHS Header Fields January 2012 + + + Example: + MMHS-Other-Recipients-Indicator-CC: UK SHL LEGAD + + The example above includes 1 copy (information) recipient that + received the message via means other than MMHS. + +3.13. Header Field: MMHS-Acp127-Message-Identifier + + Applicable protocol: mail [RFC5322] + Status: informational + Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF + Specification document(s): [RFC6477] + + The MMHS-Acp127-Message-Identifier header field, by its presence, + indicates an ACP 127 message identifier [ACP127] for a message that + originated from an ACP 127 domain. If this extension is absent, then + the message did not encounter an ACP 127 domain. + + The MMHS-Acp127-Message-Identifier contains the contents of ACP 127 + format line 3, which consists of three space-separated fields: the + Calling Station (DERI), Station Serial Number (SSN), and Filing Time + (JFT) [ACP127]. + + This header field is used only to support interoperability with ACP + 127 systems, it should be treated as opaque by a pure MMHS system. + + Example: + MMHS-Acp127-Message-Identifier: RPDLE 1234 0341215 + +3.14. Header Field: MMHS-Originator-PLAD + + Applicable protocol: mail [RFC5322] + Status: informational + Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF + Specification document(s): [RFC6477] + + The MMHS-Originator-PLAD (PLAD: Plain Language Address Designator) + header field, by its presence, indicates the plain language address + associated with an originator for cross-referencing purposes. If + this header field is absent, then the message will be considered not + to have an originator PLAD cross-reference between the MMHS and ACP + 127 domains. + + This header field is used only to support interoperability with ACP + 127 systems. + + + + + + +Melnikov & Lunt Informational [Page 13] + +RFC 6477 MMHS Header Fields January 2012 + + + This header field and the MMHS-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], [RFC5234], and [RFC2156]. + + NZ-DIGIT = %x31-39 + ; "1".."9" + + nonneg-integer = "0" / (NZ-DIGIT *DIGIT) + + military-string = 1*69( ps-char ) + + quoted-military-string = DQUOTE military-string DQUOTE + + military-string-sequence = military-string + *( [FWS] ";" [FWS] military-string ) + + Exempted-Address = "MMHS-Exempted-Address:" + [FWS] address-list [FWS] CRLF + + 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 ) + ; ACP 123 specifies that the maximum number of + ; SICs is 8. Use of more than 8 SICs is + ; permitted, but additional SICs might not + ; be transferred to ACP 123 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 + + + + +Melnikov & Lunt Informational [Page 14] + +RFC 6477 MMHS Header Fields January 2012 + + + Codress-Message-Indicator = "MMHS-Codress-Message-Indicator:" + [FWS] nonneg-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 + ; 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 + + Designator = military-string + + OtherRecipIndicatorPrimary = "MMHS-Other-Recipients-Indicator-To:" + [FWS] Designator *([FWS] ";" [FWS] Designator) + [FWS] CRLF + + OtherRecipIndicatorCopy = "MMHS-Other-Recipients-Indicator-CC:" + [FWS] Designator *([FWS] ";" [FWS] Designator) + [FWS] CRLF + + Acp127MessageIdentifier = "MMHS-Acp127-Message-Identifier:" + [FWS] military-string [FWS] CRLF + + + + +Melnikov & Lunt Informational [Page 15] + +RFC 6477 MMHS Header Fields January 2012 + + + OriginatorPLAD = "MMHS-Originator-PLAD:" [FWS] military-string [FWS] + CRLF + + address-list = <Defined in RFC 5322> + +5. Service in Comparison to ACP 123 / STANAG 4406 + + The service specified in this document is a subset of the + functionality set out in Annex A1 "Military Heading Extensions" of + [ACP123]. The majority of this functionality is supported in this + document. A few capabilities have been left out, which would have + significantly increased the complexity of this specification. + + For Distribution Codes (A.1.3) only Subject Indicator Codes are + supported and Distribution Extensions are omitted. Authors of this + document believe that distribution extensions are not widely used. + + Address List Indication (A.1.11) is not supported. This complex + extension is deprecated in [ACP123]. + + Pilot Forwarding Information (A.1.13) is not supported. + + Security Information Labels (A.1.16) is not supported. This + extension is deprecated in favor of Annex A of [ACP123], which uses + Enhanced Security Services (ESS) Labels [RFC2634] that can be + supported in a directly compatible manner in S/MIME [RFC5751]. + + ACP 127 Notification Requests (see Annex A.2.1 of [ACP123) and + Responses (see Annex A.3.1 of [ACP123]) are not supported. These + extensions are used to request and return notifications from ACP 127 + gateways, and are not relevant to an SMTP gateway. + +6. Gatewaying with ACP 123 / STANAG 4406 + + The header fields defined in this specification are designed to be + mapped with ACP 123 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 [ACP123] 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 ACP + 123 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 + + + +Melnikov & Lunt Informational [Page 16] + +RFC 6477 MMHS Header Fields January 2012 + + + proprietary manner. If a Distribution Extension is encoded, this MAY + be discarded or represented as a comment (<CFWS>). The whole message + MAY be signed according to [RFC5652]. These rules also apply to + heading extensions in forwarded messages. MM-Message MUST be treated + as a forwarded message for the purposes of MIXER mapping. If an ACP + 127 Notification Request is present, this MAY be discarded or + represented as a comment (<CFWS>). + + Incoming X.400 notifications are encoded according to [RFC2156]. If + an ACP 127 Notification Response is present, this MAY be discarded or + mapped in a proprietary manner. + + 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, + for instance, policy or characteristics such as the message + containing a military body part. The X.400 message might be signed + according to ACP 123 Annex B [ACP123] or STANAG 4406 Annex G + [STANAG-4406]. message/rfc822 body parts included in the message + SHOULD be mapped to MM-Message 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- + Authorization-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 + message need not be considered a Military Message and can be + handled according to a local policy. + + c. Copy Precedence is required if the Cc header field is present and + there is an MMHS-Copy-Precedence header field that is different + from the MMHS-Primary-Precedence header field. + + d. For Message-ID fields, ACP 123 applies additional constraints + over X.400, leading to the following rules in addition 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. + + + + + +Melnikov & Lunt Informational [Page 17] + +RFC 6477 MMHS Header Fields January 2012 + + + 2. The OR Address part is required, and it is not usually + generated by an [RFC2156] mapping. It is mandatory in ACP + 123. 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 Elements of Service specific to ACP 127 [ACP127]. 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 + headings be mapped to ACP 123 and hence into ACP 127 following the + Annex D (Gateway Translation) of [STANAG-4406]. + +8. IANA Considerations + + IANA has added the list of header fields specified in subsections of + Section 3 to the "Permanent Message Header Field Names" registry + defined by "Registration Procedures for Message Header Fields" + [RFC3864]. + +9. Security Considerations + + Annex B of [ACP123] describes how MMHS messages can be protected in + an X.400 environment. Similar protection can be provided using + S/MIME [RFC5751] and/or DKIM [RFC6376]. In particular, DKIM can be + used to protect against alteration, deletion, or insertion of header + fields specified in this document that can affect disposition and + quality of service applied to processing of the protected Internet + message by receiving gateways/endpoints that support this + specification. (Note that most of the header fields defined in this + document might affect processing of the message by the receiving + gateway/end system, MMHS-Subject-Indicator-Codes and MMHS-Primary- + Precedence/MMHS-Copy-Precedence header fields being the most + important examples. For example, alteration of the MMHS-Primary- + Precedence header field value might affect processing speed of the + message by the recipient Message Transfer Agent (MTA).) + + When the original message header fields are digitally signed, the act + of gatewaying messages with such header fields to/from an Internet + environment from/to an ACP 123 environment breaks digital signatures. + The gateway can sign the translated message itself (e.g., with DKIM), + but a message recipient would be unable to verify that the message + was generated by the original sender. + + + + + +Melnikov & Lunt Informational [Page 18] + +RFC 6477 MMHS Header Fields January 2012 + + +10. References + +10.1. Normative References + + [ACP123] CCEB, "Common Messaging Strategy and Procedures", ACP 123 + (B), May 2009, http://jcs.dtic.mil/j6/cceb/acps/acp123/. + + [ACP127] CCEB, "Communication Instructions - Tape Relay + Procedures", ACP 127 (G), November 1988, + http://jcs.dtic.mil/j6/cceb/acps/acp127/. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [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. + + [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, January + 2008. + + [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, + October 2008. + + [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD + 70, RFC 5652, September 2009. + + [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., + "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, + September 2011. + +10.2. Informative References + + [ACP121] CCEB, "Comms Instructions - General", ACP 121 (I), + October 2010, http://jcs.dtic.mil/j6/cceb/acps/acp121/. + + [ACP131] CCEB, "Comms Instructions - Operating Signals", ACP 131 + (F), April 2009, + http://jcs.dtic.mil/j6/cceb/acps/acp131/. + + [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for + S/MIME", RFC 2634, June 1999. + + + + +Melnikov & Lunt Informational [Page 19] + +RFC 6477 MMHS Header Fields January 2012 + + + [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet + Mail Extensions (S/MIME) Version 3.2 Message + Specification", RFC 5751, January 2010. + + [STANAG-4406] + NATO, "STANAG 4406 Edition 2: Military Message Handling + System", STANAG 4406, March 2005. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Melnikov & Lunt Informational [Page 20] + +RFC 6477 MMHS Header Fields January 2012 + + +Appendix A. Acknowledgements + + This document copies a lot of text from the "Mapping between X.400 + P772 and RFC-822" by Julian Onions and Graeme Lunt and STANAG 4406 + (2nd Edition). So the authors of this document would like to + acknowledge contributions made by the authors of these documents. + + Many thanks for reviews and text provided by Steve Kille, Alan Ross, + David Wilson, James Usmar, Kathy Nuckles, Andy Trayler, Ken Carlberg, + Chris Bonatti, Oeyvind Jonsson, Mykyta Yevstifeyev, Sean Turner, + Stephen Farrell, Adrian Farrel, and Peter Saint-Andre. + +Authors' Addresses + + Alexey Melnikov + Isode Ltd + 5 Castle Business Village + 36 Station Road + Hampton, Middlesex, TW12 2BX + UK + + EMail: Alexey.Melnikov@isode.com + + Graeme Lunt + SMHS Ltd + Bescar Moss Farm + Bescar Lane + Ormskirk L40 9QN + UK + + EMail: graeme.lunt@smhs.co.uk + + + + + + + + + + + + + + + + + + + + +Melnikov & Lunt Informational [Page 21] + |