idnits 2.17.1 draft-melnikov-mmhs-header-fields-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 22, 2011) is 4536 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 679, but not defined ** Obsolete normative reference: RFC 4871 (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode Ltd 4 Intended status: Informational G. Lunt 5 Expires: May 25, 2012 SMHS Ltd 6 November 22, 2011 8 Registration of Military Message Handling System (MMHS) header fields 9 for use in Internet Mail 10 draft-melnikov-mmhs-header-fields-08 12 Abstract 14 A Miltary Message Handling System (MMHS) processes formal messages 15 ensuring release, distribution, security, and timely delivery across 16 national and international strategic and tactical networks. The MMHS 17 Elements of Service are defined as a set of extensions to the ITU-T 18 X.400 (1992) international standards and are specified in STANAG 4406 19 Edition 2 or ACP 123. This document specifies message header fields 20 and associated processing for RFC 5322 (Internet Email) to provide a 21 comparable messaging service. In addition, this document provides 22 for a STANAG 4406 / Internet Email Gateway that supports message 23 conversion. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 25, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 61 3. Registration Templates . . . . . . . . . . . . . . . . . . . . 3 62 3.1. Header field: MMHS-Exempted-Address . . . . . . . . . . . 5 63 3.2. Header field: MMHS-Extended-Authorisation-Info . . . . . . 5 64 3.3. Header field: MMHS-Subject-Indicator-Codes . . . . . . . . 6 65 3.4. Header field: MMHS-Handling-Instructions . . . . . . . . . 6 66 3.5. Header field: MMHS-Message-Instructions . . . . . . . . . 7 67 3.6. Header field: MMHS-Codress-Message-Indicator . . . . . . . 7 68 3.7. Header field: MMHS-Originator-Reference . . . . . . . . . 8 69 3.8. Header field: MMHS-Primary-Precedence . . . . . . . . . . 8 70 3.9. Header field: MMHS-Copy-Precedence . . . . . . . . . . . . 9 71 3.10. Header field: MMHS-Message-Type . . . . . . . . . . . . . 10 72 3.11. Header field: MMHS-Other-Recipients-Indicator-To . . . . . 11 73 3.12. Header field: MMHS-Other-Recipients-Indicator-Cc . . . . . 11 74 3.13. Header field: MMHS-Acp127-Message-Identifier . . . . . . . 12 75 3.14. Header field: MMHS-Originator-PLAD . . . . . . . . . . . . 13 76 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 77 5. Service in Comparison to ACP 123/STANAG 4406 . . . . . . . . . 15 78 6. Gatewaying with ACP 123/STANAG 4406 . . . . . . . . . . . . . 16 79 7. Gatewaying with ACP 127 . . . . . . . . . . . . . . . . . . . 17 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 85 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 19 87 1. Introduction 89 [RFC5322] defines a protocol for the format of electronic messages 90 exchanged on the Internet. MMHS is a military specification defined 91 in ACP 123 [ACP123] (also specified in STANAG 4406 [STANAG-4406]) 92 which defines a number of extensions to the basic X.400 (1992) 93 protocol for the services required by military messaging. 95 This document supports translating most of the elements of service 96 defined in ACP 123 [ACP123] to Internet message header fields (see 97 Section 5 for more details). This specification is written to extend 98 the MIXER specification [RFC2156] to enable inter-conversion in a 99 MIXER gateway with the X.400 IPMS heading extensions defined in ACP 100 123/STANAG 4406 Annex A. 102 The document is aimed at the ability to represent MMHS messages as 103 RFC 5322 messages. All RFC 5322 header fields defined in this 104 document are prefixed with the string "MMHS-" to distinguish them 105 from any other header fields. 107 Unless stated otherwise, all header fields described in this document 108 are OPTIONAL in an Internet Message. 110 This document is structured as follows: Section 3 and its subsections 111 formally define new Internet header fields and show some examples. 112 Section 4 provides ABNF syntax for them. Section 5 provides some 113 background information about which features of ACP 123/STANAG 4406 114 were not implemented in this specification. Subsequent sections talk 115 about additional requirements for gatewaying to/from ACP 123/STANAG 116 4406 and ACP 127 [ACP127] environments respectively. 118 2. Conventions Used in This Document 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in [RFC2119]. 124 The formal syntax uses the Augmented Backus-Naur Form (ABNF) 125 [RFC5234] notation including the core rules defined in Appendix B of 126 RFC 5234 [RFC5234]. 128 3. Registration Templates 130 Header field entries are summarized below in tabular form for 131 convenience of reference and presented in full in the following 132 subsections. 134 Any header field specified in this document MUST NOT appear more than 135 once in message headers. 137 +------------------------------------+----------+-------------------+ 138 | Header name | Protocol | Reference | 139 +------------------------------------+----------+-------------------+ 140 | MMHS-Exempted-Address | mail | [ACP123], | 141 | | | Appendix A1.1 and | 142 | | | Appendix B.105 | 143 | MMHS-Extended-Authorisation-Info | mail | [ACP123], | 144 | | | Appendix A1.2 and | 145 | | | Appendix B.106 | 146 | MMHS-Subject-Indicator-Codes | mail | [ACP123], | 147 | | | Appendix A1.3 and | 148 | | | Appendix B.107 | 149 | MMHS-Handling-Instructions | mail | [ACP123][ACP123], | 150 | | | Appendix A1.4 and | 151 | | | Appendix B.108 | 152 | MMHS-Message-Instructions | mail | [ACP123], | 153 | | | Appendix A1.5 and | 154 | | | Appendix B.109 | 155 | MMHS-Codress-Message-Indicator | mail | [ACP123], | 156 | | | Appendix A1.6 and | 157 | | | Appendix B.110 | 158 | MMHS-Originator-Reference | mail | [ACP123], | 159 | | | Appendix A1.7 and | 160 | | | Appendix B.111 | 161 | MMHS-Primary-Precedence | mail | [ACP123], | 162 | | | Appendix A1.8 and | 163 | | | Appendix B.101 | 164 | MMHS-Copy-Precedence | mail | [ACP123], | 165 | | | Appendix A1.9 and | 166 | | | Appendix B.102 | 167 | MMHS-Message-Type | mail | [ACP123], | 168 | | | Appendix A1.10 | 169 | | | and Appendix | 170 | | | B.103 | 171 | MMHS-Other-Recipients-Indicator-To | mail | [ACP123], | 172 | | | Appendix A1.12 | 173 | | | and Appendix | 174 | | | B.113 | 175 | MMHS-Other-Recipients-Indicator-Cc | mail | [ACP123], | 176 | | | Appendix A1.12 | 177 | | | and Appendix | 178 | | | B.113 | 179 | MMHS-Acp127-Message-Identifier | mail | [ACP123], | 180 | | | Appendix A1.14 | 181 | | | and Appendix | 182 | | | B.116 | 183 | MMHS-Originator-PLAD | mail | [ACP123], | 184 | | | Appendix A1.15 | 185 | | | and Appendix | 186 | | | B.117 | 187 +------------------------------------+----------+-------------------+ 189 3.1. Header field: MMHS-Exempted-Address 191 Applicable protocol: mail [RFC5322] 192 Status: informational 193 Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF 194 Specification document(s): [[anchor4: this document]] 196 The exempted address header field, by its presence, indicates the 197 addresses of members in an Address List (AL) that should not receive 198 the message. If this header field is absent from the message, all 199 members of an AL will be considered to be valid recipients of the 200 message. Note: There is no guarantee that the exempted addresses 201 will not receive the message as the result of redirection, 202 Distribution List (DL) expansion, etc. 204 Example: 205 MMHS-Exempted-Address: UK SHL CGT Samuals G 206 , UK SHL Duty Officer 207 209 3.2. Header field: MMHS-Extended-Authorisation-Info 211 Applicable protocol: mail [RFC5322] 212 Status: informational 213 Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF 214 Specification document(s): [[anchor6: this document]] 216 The extended authorisation info header field, by its presence, 217 indicates either the date and the time when the message was 218 officially released by the releasing officer or the date and time 219 when the message was initially submitted to a communication facility 220 for transmission. 222 This header field SHOULD always be present in an email message which 223 complies with this specification. 225 Example: 226 MMHS-Extended-Authorisation-Info: 227 Mon, 09 Aug 2010 15:27:40 +0100 229 The example above demonstrates use of folding white space (FWS 230 [RFC5322]). 232 3.3. Header field: MMHS-Subject-Indicator-Codes 234 Applicable protocol: mail [RFC5322] 235 Status: informational 236 Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF 237 Specification document(s): [[anchor8: this document]] 239 Subject Indicator Codes (SICs) are a mechanism for formally 240 identifying the topic of a message. SICs are nested codes that 241 provide information for message distribution after delivery to the 242 recipient organisation. SIC codes are usually three letters or three 243 letters and digits, but may be up to 8 characters long. Nations and 244 organizations using SIC codes usually maintain a central registry. 246 When present a MMHS-Subject-Indicator-Codes header field contains one 247 or more SICs, which indicates distribution information to a recipient 248 or a recipient's User Agent. This information can be used to perform 249 automatic or manual local distribution of a message. If the MMHS- 250 Subject-Indicator-Codes header field is absent, then the local 251 distribution will be in accordance with the message handling policy 252 of the recipient's domain. 254 [ACP123] specifies two optional components of the Distribution Code 255 Element of Service. The MMHS-Subject-Indicator-Codes header field 256 covers only the SIC code variant of distribution codes. 258 Example: 259 MMHS-Subject-Indicator-Codes: SDM; KKZ ; BRL 261 The example above includes 3 SIC codes: "SDM" (GROUND/LAND 262 REQUIREMENTS), "KKZ" (HELICOPTER PUBLICATIONS/MANUALS) and "BRL" 263 (HILEX INCIDENTS). 265 3.4. Header field: MMHS-Handling-Instructions 267 Applicable protocol: mail [RFC5322] 268 Status: informational 269 Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF 270 Specification document(s): [[anchor10: this document]] 272 The handling instructions header field, by its presence, indicates 273 human readable local handling instructions that requires some manual 274 handling by a traffic operator. If this header field is absent the 275 message will be considered as not requiring manual handling by a 276 traffic operator. 278 Handling instructions (also called transmission instructions) are a 279 part of format line 4 as defined in ACP 127 [ACP127], and concern the 280 sending of the message, e.g. that a particular system shall be used 281 for transfer of the message. 283 This header field is used to support interoperability with ACP 127 284 systems. 286 Example: 287 MMHS-Handling-Instructions: RXFPA ZOV MINDEF 289 The example above includes one ACP 131(F) handling instruction: 290 "RXFPA ZOV MINDEF". The "ZOV MINDEF" indicates that MINDEF rerouted 291 the message for some reason, and the correct routing is via RXFPA. 293 3.5. Header field: MMHS-Message-Instructions 295 Applicable protocol: mail [RFC5322] 296 Status: informational 297 Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF 298 Specification document(s): [[anchor12: this document]] 300 The message instructions header field, by its presence, indicates 301 message instructions (also known as "remarks") accompanying the 302 message (e.g., similar to the operating signals specified in ACP 131 303 [ACP131]). If this header field is absent the message will be 304 considered received without message instructions. 306 The difference between Handling instructions and Message instructions 307 is that the former is only for manual handling by traffic operators, 308 while the latter also contains information of interest to the persons 309 reading the message. 311 Example: 312 MMHS-Message-Instructions: MINIMIZE CONSIDERED; NO DISTRIBUTION 314 The example above includes 2 ACP123(B) [ACP123] defined message 315 instructions: "MINIMIZE CONSIDERED" indicating that the originating 316 user has considered the Minimize status of the recipients and "NO 317 DISTRIBUTION", indicating that the recipients should not distribute 318 the message further without the originating user's approval. 320 3.6. Header field: MMHS-Codress-Message-Indicator 322 Applicable protocol: mail [RFC5322] 323 Status: informational 324 Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF 325 Specification document(s): [[anchor14: this document]] 327 The codress message indicator header field, by its presence, 328 indicates that the message is in Codress format. If this header 329 field is absent the message will be considered received without the 330 Codress format. 332 A Codress message is one in which all addresses, i.e. the sender and 333 all recipients, is encrypted within the ACP 127 text (body) [ACP127]. 334 The heading of any Codress message contains only the minimum of 335 information which will enable a receiving station to deal properly 336 and expeditiously with the particular transmission. The general 337 rules for the preparation and transmission of Codress messages are 338 given in ACP 121 [ACP121]. 340 This header field is used only to support interoperability with ACP 341 127 systems. 343 Example: 344 MMHS-Codress-Message-Indicator: 23 346 3.7. Header field: MMHS-Originator-Reference 348 Applicable protocol: mail [RFC5322] 349 Status: informational 350 Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF 351 Specification document(s): [[anchor16: this document]] 353 The originator reference header field, by its presence, indicates a 354 user defined reference called the "originator's number". If this 355 header field is absent, then the message will be considered received 356 without any user defined reference. 358 The "originator's number" is used by the originating organisational 359 unit and is further qualified within national policy. 361 Note: trailing and leading spaces in an originator reference are not 362 allowed by syntax. 364 Example: 365 MMHS-Originator-Reference: IMSCOM-JIC-612-78 367 3.8. Header field: MMHS-Primary-Precedence 369 Applicable protocol: mail [RFC5322] 370 Status: informational 371 Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF 372 Specification document(s): [[anchor18: this document]] 374 The primary precedence header field, by its presence, indicates the 375 precedence level of the primary ("action") recipients. The message 376 originating domain MUST ensure that this header field is always 377 present if the message contains "To:" ("action") addresses. 379 The MMHS Primary Precedence Element of Service indicates the relative 380 order in which Military Messages are to be handled for primary 381 (action) recipients, i.e. a Military Message with higher MMHS- 382 Primary-Precedence header field value SHOULD be handled before a 383 Military Message with a lower MMHS-Primary-Precedence header field 384 value. 386 The header field value is a non-negative integer, or one of the 6 387 predefined case-insensitive labels: "deferred" (same as "0"), 388 "routine" (same as "1"), "priority" (same as "2"), "immediate" (same 389 as "3"), "flash" (same as "4"), or "override" (same as "5"), 390 optionally followed by a comment. Note that according to ACP 123 391 values in the range from 0 to 15 are reserved for NATO defined 392 precedence levels and values in the range from 16 to 31 are reserved 393 for national users. 395 Example 1: 396 MMHS-Primary-Precedence: 0 (Deferred) 398 Example 2: 399 MMHS-Primary-Precedence: FLASH 401 Example 3: 402 MMHS-Primary-Precedence: 7 404 3.9. Header field: MMHS-Copy-Precedence 406 Applicable protocol: mail [RFC5322] 407 Status: informational 408 Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF 409 Specification document(s): [[anchor20: this document]] 411 The copy precedence header field, by its presence, indicates the 412 precedence level of the copy ("information") recipients. The message 413 originating domain MUST ensure that this header field is always 414 present if the message contains "Cc:" or "Bcc:" ("information") 415 addresses. 417 The MMHS Copy Precedence Element of Service indicates the relative 418 order in which Military Messages are to be handled for copy 419 (information) recipients. i.e. a Military Message with higher MMHS- 420 Copy-Precedence header field value SHOULD be handled before a 421 Military Message with a lower MMHS-Copy-Precedence header field 422 value. 424 The header field value is a non-negative integer, or one of the 6 425 predefined case-insensitive labels: "deferred" (same as "0"), 426 "routine" (same as "1"), "priority" (same as "2"), "immediate" (same 427 as "3"), "flash" (same as "4"), or "override" (same as "5"), 428 optionally followed by a comment. Note that according to ACP 123 429 values in the range from 0 to 15 are reserved for NATO defined 430 precedence levels and values in the range from 16 to 31 are reserved 431 for national users. 433 Example 1: 434 MMHS-Copy-Precedence: 2 (priority) 436 Example 2: 437 MMHS-Copy-Precedence: Priority 439 3.10. Header field: MMHS-Message-Type 441 Applicable protocol: mail [RFC5322] 442 Status: informational 443 Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF 444 Specification document(s): [[anchor22: this document]] 446 The message type heading extension, by its presence, indicates 447 whether the message is to be considered as an exercise, an operation, 448 a project or a drill. (Note that the list of types is extensible and 449 other types can be specified using the numeric form, see below.) It 450 may include an optional parameter specifying the name of the 451 exercise, operation, project or drill. If this extension is absent 452 the message will be considered to be of an undefined type. 454 The header field value is a non-negative integer, or one of the 4 455 predefined case-insensitive labels: "exercise" (same as "0"), 456 "operation" (same as "1"), "project" (same as "2"), "drill" (same as 457 "3"). Note that according to ACP 123 values in the range from 0 to 458 127 are reserved for NATO defined Message Type identifiers and values 459 in the range from 128 to 255 are not defined by NATO and may be used 460 nationally or bilaterally. 462 Example 1: 463 MMHS-Message-Type: 0(exercise); identifier="CANDLE FISH" 465 Example 2: 466 MMHS-Message-Type: 3 468 Example 3: 469 MMHS-Message-Type: 2 (projet) 471 Example 4: 473 MMHS-Message-Type: project 475 Note that some of the examples above demonstrate use of optional 476 comments. See Section 4 for the exact syntax of this header field. 478 3.11. Header field: MMHS-Other-Recipients-Indicator-To 480 Applicable protocol: mail [RFC5322] 481 Status: informational 482 Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF 483 Specification document(s): [[anchor23: this document]] 485 The other primary recipients indicator header field, by its presence, 486 indicates the names of primary recipients that are intended to 487 receive or have received the message via means other than MMHS. Note 488 that the absence of both this header field and the MMHS-Other- 489 Recipients-Indicator-Cc header field (see Section 3.12 does not 490 guarantee that all recipients are within the MMHS. 492 This header field enables a recipient to determine all action 493 recipients of a Military Message. This header field is derived from 494 the Other Recipient Info Element of Service. 496 There are several reasons as to why a recipient of a Military Message 497 may be identified by this header: 499 1. The recipient is not part of the MMHS 501 2. The path to the recipient through the MMHS may not be secure, 502 therefore, the originator has used alternative mechanisms to 503 distribute the Military Message 505 3. The recipient was already in receipt of the Military Message 506 prior to the Military Message being inserted into the MMHS 508 Example: 509 MMHS-Other-Recipients-Indicator-To: UK SHL COS; UK SHL IM 511 The example above includes names of 2 primary recipients which 512 received the message via means other than MMHS. 514 3.12. Header field: MMHS-Other-Recipients-Indicator-Cc 516 Applicable protocol: mail [RFC5322] 517 Status: informational 518 Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF 519 Specification document(s): [[anchor24: this document]] 520 The other copy recipients indicator header field, by its presence, 521 indicates the names of copy recipients that are intended to receive 522 or have received the message via means other than MMHS. Note that 523 the absence of both this header field and the MMHS-Other-Recipients- 524 Indicator-To header field (see Section 3.11 does not guarantee that 525 all recipients are within the MMHS. 527 This header field enables a recipient to determine all copy 528 recipients of a Military Message. This header field is derived from 529 the Other Recipient Info Element of Service. 531 There are several reasons as to why a recipient of a Military Message 532 may be identified by this header: 534 1. The recipient is not part of the MMHS 536 2. The path to the recipient through the MMHS may not be secure, 537 therefore, the originator has used alternative mechanisms to 538 distribute the Military Message 540 3. The recipient was already in receipt of the Military Message 541 prior to it being inserted into the MMHS 543 Example: 544 MMHS-Other-Recipients-Indicator-Cc: UK SHL LEGAD 546 The example above includes 1 copy (information) recipient which 547 received the message via means other than MMHS. 549 3.13. Header field: MMHS-Acp127-Message-Identifier 551 Applicable protocol: mail [RFC5322] 552 Status: informational 553 Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF 554 Specification document(s): [[anchor26: this document]] 556 The ACP127 message identifier header field, by its presence, 557 indicates an ACP 127 message identifier [ACP127] for a message that 558 originated from an ACP 127 domain. If this extension is absent, then 559 the message did not encounter an ACP 127 domain. 561 The acp127-message-identifier contains the contents of ACP127 format 562 line 3 consisting of three space (SP) separated fields: the Calling 563 Station (DERI), Station Serial Number (SSN), and Filing Time (JFT) 564 [ACP127]. 566 This header field is used only to support interoperability with ACP 567 127 systems, it should be treated as opaque by a pure MMHS system. 569 Example: 570 MMHS-Acp127-Message-Identifier: RPDLE 1234 0341215 572 3.14. Header field: MMHS-Originator-PLAD 574 Applicable protocol: mail [RFC5322] 575 Status: informational 576 Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF 577 Specification document(s): [[anchor28: this document]] 579 The originator Plain Language Address Designators (PLAD) header 580 field, by its presence, indicates the plain language address 581 associated with an originator for cross-reference purposes. If this 582 header field is absent, then the message will be considered to not 583 having an originators PLAD cross reference between the MMHS and ACP 584 127 domains. 586 This header field is used only to support interoperability with ACP 587 127 systems. 589 This header field and the Extended Authorisation Info header field 590 provide a cross-reference for message identification in both ACP 127 591 and MMHS domains. 593 Example: 594 MMHS-Originator-PLAD: SACLANT 596 4. Formal Syntax 598 The following syntax specification uses the Augmented Backus-Naur 599 Form (ABNF) as described in [RFC5234]. Terms not defined here are 600 taken from [RFC5322], [RFC5234] and [RFC2156]. 602 NZ-DIGIT = %x31-39 603 ; "1".."9" 605 nonneg-integer = "0" / (NZ-DIGIT *DIGIT) 607 military-string = 1*69( ps-char ) 609 quoted-military-string = DQUOTE military-string DQUOTE 611 military-string-sequence = military-string 612 *( [FWS] ";" [FWS] military-string ) 614 Exempted-Address = "MMHS-Exempted-Address:" 615 [FWS] address-list [FWS] CRLF 617 Extended-Authorisation-Info = "MMHS-Extended-Authorisation-Info:" 618 [FWS] date-time CRLF 620 Subject-Indicator-Codes = "MMHS-Subject-Indicator-Codes:" 621 [FWS] sic-sequence [FWS] CRLF 623 sic-sequence = sic *( [FWS] ";" [FWS] sic ) 624 ; ACP 123 specifies that the maximum number of 625 ; SICs is 8. Use of more than 8 SIC codes is 626 ; permitted, but additional SIC codes might not 627 ; be transferred to ACP 123 system. 629 sic = 3*8( ps-char ) 631 Handling-Instructions = "MMHS-Handling-Instructions:" 632 [FWS] military-string-sequence [FWS] CRLF 634 Message-Instructions = "MMHS-Message-Instructions:" 635 [FWS] military-string-sequence [FWS] CRLF 637 Codress-Message-Indicator = "MMHS-Codress-Message-Indicator:" 638 [FWS] nonneg-integer [FWS] CRLF 640 Originator-Reference = "MMHS-Originator-Reference:" 641 [FWS] military-string [FWS] CRLF 643 PrimaryPrecedence = "MMHS-Primary-Precedence:" [FWS] precedence CRLF 645 CopyPrecedence = "MMHS-Copy-Precedence:" [FWS] precedence CRLF 647 precedence = (nonneg-integer / std-precedence) [CFWS] 649 std-precedence = "deferred" / "routine" / "priority" / 650 "immediate" / "flash" / "override" 651 ; deferred == 0 652 ; routine == 1 653 ; priority == 2 654 ; immediate == 3 655 ; flash == 4 656 ; override == 5 658 MessageType = "MMHS-Message-Type:" [FWS] message-type [CFWS] 659 [";" [FWS] MessageTypeParam [FWS] ] CRLF 661 message-type = nonneg-integer / std-message-type 663 std-message-type = "exercise" / "operation" / "project" / "drill" 664 ; exercise == 0 665 ; operation == 1 666 ; project == 2 667 ; drill == 3 669 MessageTypeParam = "identifier" [FWS] "=" [FWS] 670 quoted-military-string 672 Designator = military-string 674 OtherRecipIndicatorPrimary = "MMHS-Other-Recipients-Indicator-To:" 675 [FWS] Designator *([FWS] ";" [FWS] Designator) 676 [FWS] CRLF 678 OtherRecipIndicatorCopy = "MMHS-Other-Recipients-Indicator-Cc:" 679 [FWS] Designator *([FWS] ";" [FWS] Designator) 680 [FWS] CRLF 682 Acp127MessageIdentifier = "MMHS-Acp127-Message-Identifier:" 683 [FWS] military-string [FWS] CRLF 685 OriginatorPLAD = "MMHS-Originator-PLAD:" [FWS] military-string [FWS] 686 CRLF 688 address-list = 690 5. Service in Comparison to ACP 123/STANAG 4406 692 The service specified in this document is a subset of the 693 functionality set out in Annex A1 "Military Heading Extensions" of 694 [ACP123]. The majority of this functionality is supported in this 695 document. A few capabilities have been left out which would have 696 significantly increased the complexity of this specification. 698 For Distribution Codes (A.1.3) only Subject Indicator Codes are 699 supported and Distribution Extensions are omitted. Authors of this 700 document believe that distribution extensions are not widely used. 702 Address List Indication (A.1.11) is not supported. This complex 703 extension is deprecated in [ACP123]. 705 Pilot Forwarding Information (A.1.13) is not supported. 707 Security Information Labels (A.1.16) is not supported. This 708 extension is deprecated in favour of Annex A of [ACP123], which uses 709 ESS Labels [RFC2634] which can be supported in a directly compatible 710 manner in S/MIME [RFC5751]. 712 ACP 127 Notification Requests (A.2.1) and Responses (A.3.1) are not 713 supported. These extensions are used to request and return 714 notifications from ACP 127 gateways, and are not relevant to an SMTP 715 gateway. 717 6. Gatewaying with ACP 123/STANAG 4406 719 The header fields defined in this specification are designed to be 720 mapped with ACP 123 Annex A1 heading extensions as part of a MIXER 721 mapping according to [RFC2156]. The syntax of these headings is 722 defined such that mapping is mechanical. OR Names SHOULD be mapped 723 with Internet Email addresses according to [RFC2156]. 725 This section summarizes how a gateway between [ACP123] and [RFC5322] 726 conformant to this specification operates. 728 If an incoming X.400 message is encoded as P772, [RFC5322] header 729 fields MUST be generated according to this specification for all ACP 730 123 heading extensions where an equivalent header is defined in this 731 specification. For the three heading extensions where no mapping is 732 defined the heading extension MAY be discarded or mapped in a 733 proprietary manner. If a Distribution Extension is encoded this MAY 734 be discarded or represented as a comment (). The whole message 735 MAY be signed according to [RFC5652]. These rules also apply to 736 heading extensions in forwarded messages. MM-Message MUST be treated 737 as a forwarded message for the purposes of MIXER mapping. If an ACP 738 127 Notification Request is present, this MAY be discarded or 739 represented as a comment (). 741 Incoming X.400 notifications are encoded according to [RFC2156]. If 742 an ACP 127 Notification Response is present, this MAY be discarded or 743 mapped in a proprietary manner. 745 If an incoming SMTP message contains any of the header fields defined 746 in this specification, the outgoing X.400 message MUST be encoded as 747 P772. The outgoing message MAY be encoded as P772 for other reasons, 748 such as policy or characteristics such as the message containing a 749 military body part. The X.400 message might be signed according to 750 ACP 123 Annex B [ACP123] or STANAG 4406 Annex G [STANAG-4406]. 751 message/rfc822 body parts included in the message SHOULD be mapped to 752 MM-Message, and the heading mapping rules applied. 754 Generated P772 messages SHOULD follow the following rules, generating 755 heading extensions if needed. 757 a. Extended Authorization is required. If the MMHS-Extended- 758 Authorisation-Info header field is absent, then the default value 759 is taken from the Date: header field. 761 b. Primary Precedence is required if the To header field is present. 762 If the MMHS-Primary-Precedence header field is absent, the 763 message need not be considered a military message and can be 764 handled according to a local policy. 766 c. Copy Precedence is required if the Cc header field is present. 767 If the MMHS-Copy-Precedence header field is absent, the message 768 need not be considered a military message and can be handled 769 according to a local policy. 771 d. For Message-ID fields, ACP 123 applies additional constraints 772 over X.400, leading to the following rules additional to 773 [RFC2156] which SHOULD be followed by a gateway following this 774 specification. 776 1. The local identifier MUST be at least 15 characters long. If 777 the [RFC2156] generated value is shorter than this, then it 778 is padded with spaces to 15 characters. This value will 779 correctly reverse map. 781 2. The OR Address part is required, and not usually generated by 782 an [RFC2156] mapping. It is mandatory in ACP 123. The 783 gateway SHOULD generate an OR Address in a manner that can be 784 reverse mapped. It MAY use the OR Address to encode long 785 message ids that cannot be encoded in the local identifier. 787 7. Gatewaying with ACP 127 789 The header fields defined in this specification include fields to 790 carry ACP 127 specific elements of service [ACP127]. This 791 specification does not define a mapping of these header fields to ACP 792 127. In the absence of this mapping, it is recommended that these 793 heading should be mapped to ACP 123 and hence into ACP 127 following 794 the Annex D (Gateway Translation) of [STANAG-4406]. 796 8. IANA Considerations 798 IANA is requested to add the list of header fields specified in 799 subsections of Section 3 to the "Permanent Message Header Field 800 Registry", defined by Registration Procedures for Message Header 801 Fields [RFC3864]. 803 9. Security Considerations 805 Annex B of [ACP123] describes how MMHS messages can be protected in 806 an X.400 environment. Similar protection can be provided using 807 S/MIME [RFC5751] and/or DKIM [RFC4871]. In particular, DKIM can be 808 used to protect against alteration, deletion or insertion of header 809 fields specified in this document which can affect disposition and 810 quality of service applied to processing of the protected Internet 811 message by receiving gateways/endpoints which support this 812 specification. (Note that most of the header fields defined in this 813 document might affect processing of the message by the receiving 814 gateway/end system, MMHS-Subject-Indicator-Codes and MMHS-Primary- 815 Precedence/MMHS-Copy-Precedence header fields being the most 816 important examples. For example alteration of the MMHS-Primary- 817 Precedence header field value might affect processing speed of the 818 message by the recipient MTA.) 820 When the original message header fields are digitally signed, the act 821 of gatewaying messages with such header fields to/from an Internet 822 environment from/to an ACP 123 environment breaks digital signatures. 823 The gateway can sign the translated message itself (e.g. with DKIM), 824 but a message recipient would be unable to verify that the message 825 was generated by the original sender. 827 10. References 829 10.1. Normative References 831 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 832 Requirement Levels", BCP 14, RFC 2119, March 1997. 834 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 835 October 2008. 837 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 838 Specifications: ABNF", STD 68, RFC 5234, January 2008. 840 [RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced 841 Relay): Mapping between X.400 and RFC 822/MIME", 842 RFC 2156, January 1998. 844 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 845 Procedures for Message Header Fields", BCP 90, 846 RFC 3864, September 2004. 848 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., 849 Fenton, J., and M. Thomas, "DomainKeys Identified Mail 850 (DKIM) Signatures", RFC 4871, May 2007. 852 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", 853 STD 70, RFC 5652, September 2009. 855 [ACP123] CCEB, "Common Messaging strategy and procedures", 856 ACP 123, May 2009. 858 [ACP127] CCEB, "Communication Instructions - Tape Relay 859 Procedures", ACP 127, November 1988. 861 10.2. Informative References 863 [RFC2634] Hoffman, P., "Enhanced Security Services for S/MIME", 864 RFC 2634, June 1999. 866 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose 867 Internet Mail Extensions (S/MIME) Version 3.2 Message 868 Specification", RFC 5751, January 2010. 870 [STANAG-4406] NATO, "STANAG 4406 Edition 2: Military Message 871 Handling System", STANAG 4406, March 2005. 873 [ACP121] CCEB, "Comms Instructions - General", ACP 121, 874 May 2010. 876 [ACP131] CCEB, "Comms Instructions - Operating Signals", 877 ACP 131, April 2009. 879 Appendix A. Acknowledgements 881 This document copies lots of text from 882 draft-onions-x400p772-822-mapping-01.txt and STANAG 4066 (2nd 883 Edition). So the authors of this document would like to acknowledge 884 contributions made by the authors of these documents. 886 Many thanks for reviews and text provided by Steve Kille, Alan Ross, 887 David Wilson, James Usmar, Kathy Nuckles, Andy Trayler, Ken Carlberg, 888 Chris Bonatti, Oeyvind Jonsson, Mykyta Yevstifeyev, Sean Turner, 889 Stephen Farrell, Adrian Farrel and Peter Saint-Andre. 891 Authors' Addresses 893 Alexey Melnikov 894 Isode Ltd 895 5 Castle Business Village 896 36 Station Road 897 Hampton, Middlesex TW12 2BX 898 UK 900 EMail: Alexey.Melnikov@isode.com 901 Graeme Lunt 902 SMHS Ltd 903 Bescar Moss Farm 904 Bescar Lane 905 Ormskirk L40 9QN 906 UK 908 EMail: graeme.lunt@smhs.co.uk