[要約] RFC 6477は、インターネットメールで使用するための軍事メッセージハンドリングシステム（MMHS）ヘッダーフィールドの登録に関するものです。このRFCの目的は、MMHSヘッダーフィールドの一貫性と相互運用性を確保することです。
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
インターネットメールで使用するための軍事メッセージ処理システム（MMHS）ヘッダーフィールドの登録
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.
軍事メッセージ処理システム（MMHS）は、国内および国際的な戦略的および戦術的ネットワーク全体でリリース、配布、セキュリティ、およびタイムリーな配信を保証する正式なメッセージを処理します。MMHSサービスの要素は、ITU-T X.400（1992）国際基準の拡張セットとして定義されており、STANAG 4406 Edition 2およびACP 123で指定されています。このドキュメントは、RFC 5322のメッセージヘッダーフィールドと関連する処理を指定しています（インターネットメッセージ形式）同等のメッセージングサービスを提供します。さらに、このドキュメントは、メッセージ変換をサポートするStanag 4406 / Internet Email Gatewayを提供します。
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.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
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
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。あなたの権利と制限を尊重して説明しているので、これらの文書を注意深く確認してください
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.
この文書に。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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
[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.
[RFC5322]は、インターネットで交換される電子メッセージの形式のプロトコルを定義します。MMHSは、ACP 123 [ACP123]（Stanag 4406 [Stanag-4406]でも指定されている）で定義されている軍事仕様であり、軍事メッセージに必要なサービスの基本的なX.400（1992）プロトコルに多数の拡張を定義しています。
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
このドキュメントは、ACP 123 [ACP123]で定義されているサービスのほとんどの要素をインターネットメッセージヘッダーフィールドに翻訳することをサポートしています（詳細については、セクション5を参照）。この仕様は、Mime Internet X.400 Enhanced Relay（Mixer）仕様を拡張するために書かれています
[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.
[RFC2156]は、ACP 123 / STANAG 4406、Annex Aで定義されているX.400対人メッセージングシステム（IPMS）見出しエクステンションを使用して、ミキサーゲートウェイで相互変換を可能にします。
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.
このドキュメントは、RFC 5322メッセージとしてMMHSメッセージを表す機能を目的としています。このドキュメントで定義されているすべてのRFC 5322ヘッダーフィールドには、他のヘッダーフィールドと区別するための文字列「MMHS」が付いています。
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.
このドキュメントは次のように構成されています。セクション3とそのサブセクションは、新しいインターネットヘッダーフィールドを正式に定義し、いくつかの例を示します。セクション4では、それらに拡張されたBackus-Naurフォーム（ABNF）構文を提供します。セクション5では、ACP 123 / STANAG 4406のどの機能がこの仕様に実装されていないかについての背景情報を提供します。後続のセクションでは、それぞれACP 123 / STANAG 4406およびACP 127 [ACP127]環境へのゲートウェイングの追加要件について説明します。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The formal syntax uses the ABNF [RFC5234] notation including the core rules defined in Appendix B of RFC 5234 [RFC5234].
正式な構文では、RFC 5234 [RFC5234]の付録Bで定義されているコアルールを含むABNF [RFC5234]表記を使用します。
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.
このドキュメントで指定されたヘッダーフィールドは、メッセージヘッダーに複数回表示されてはなりません。
+------------------------------------+----------+-------------------+
| 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 |
+------------------------------------+----------+-------------------+
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.
MMHS-exprected-Addressヘッダーフィールドは、その存在により、メッセージを受信してはならないアドレスリスト（AL）のメンバーのアドレスを示します。このヘッダーフィールドがメッセージに欠けている場合、ALのすべてのメンバーはメッセージの有効な受信者と見なされます。
Note: there is no guarantee that the exempted addresses will not receive the message as the result of redirection, Distribution List (DL) expansion, etc.
注：リダイレクト、配布リスト（DL）拡張などの結果として、免除されたアドレスがメッセージを受信しないという保証はありません。
Example:
MMHS-Exempted-Address:
UK SHL CGT Samuals G <graham.samuals@shl.example.com>,
UK SHL Duty Officer <duty@shl.example.com>
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.
MMHS-Extended-Authorisation-INFOヘッダーフィールドは、その存在により、リリース担当者によってメッセージが公式にリリースされた日付と時刻のいずれか、またはメッセージが最初に送信のための通信施設に提出された日時を示します。
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]).
上記の例は、折りたたみホワイトスペースの使用を示しています（FWS [RFC5322]）。
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.
サブジェクトインジケーターコード（sic）は、メッセージのトピックを正式に識別するメカニズムです。SICは、受信者組織への配信後にメッセージ配布の情報を提供するネストされたコードです。SICは通常、3文字または3文字と数字ですが、最大8文字の長さである可能性があります。通常、SICを使用している国や組織は、中央のレジストリを維持しています。
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.
存在する場合、MMHS-Subject-Indicator-Codesヘッダーフィールドには、1つ以上のSICが含まれています。これには、受信者または受信者のユーザーエージェントへの配布情報が示されます。この情報は、メッセージの自動または手動のローカル配布を実行するために使用できます。MMHS-Subject-Indicator-Codesヘッダーフィールドがない場合、ローカル分布は、受信者のドメインのメッセージ処理ポリシーに従います。
[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.
[ACP123]は、サービスの配布コード要素の2つのオプションコンポーネントを指定します。MMHS-Subject-Indicator-Codesヘッダーフィールドは、配布コードのSICコードコンポーネントのみをカバーしています。
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つのSICコードが含まれています：「SDM」（地上/土地の要件）、「KKZ」（ヘリコプターの出版物/マニュアル）、および「BRL」（Hilexインシデント）。
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.
MMHSハンドリングインストラクションヘッダーフィールドは、その存在により、トラフィックオペレーターによる手動処理を必要とする人間が読めるローカルハンドリング手順を示しています。このヘッダーフィールドがない場合、メッセージはトラフィックオペレーターによる手動処理を必要としないと見なされます。
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.
処理手順（「送信指示」とも呼ばれます）は、ACP 127 [ACP127]で定義されている形式の行4の一部であり、たとえば、メッセージの送信にメッセージの送信に関係しています。
This header field is used to support interoperability with ACP 127 systems.
このヘッダーフィールドは、ACP 127システムとの相互運用性をサポートするために使用されます。
Example: MMHS-Handling-Instructions: RXFPA ZOV MINDEF
例：MMHSハンドリングインストラクション：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.
上記の例には、1つのACP 131（f）処理命令「RXFPA ZOV MINDEF」が含まれています。「Zov Mindef」は、Mindefが何らかの理由でメッセージを再ルーティングしたことを示しており、正しいルーティングはRXFPAを介して行われます。
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.
MMHS-Message-Instructions Headerフィールドは、その存在により、メッセージに伴うメッセージの指示（「備考」とも呼ばれます）を示します（たとえば、ACP 131 [ACP131]で指定された動作信号と同様）。このヘッダーフィールドがない場合、メッセージはメッセージの指示なしに受信されたと見なされます。
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
例：MMHS-Message-Instructions：考慮される最小化。分布なし
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.
上記の例には、ACP123（b）[ACP123]で定義された2つのメッセージ命令が含まれています。「最小化された」元のユーザーの承認。
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.
MMHS-Codress-Message-Indicatorヘッダーフィールドは、その存在により、メッセージがCrodress形式であることを示しています。このヘッダーフィールドがない場合、メッセージはCodress形式なしで受信されたと見なされます。
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].
Codressメッセージは、すべてのアドレス、つまり送信者とすべての受信者がACP 127テキスト（Body）[ACP127]内で暗号化されるものです。Codressメッセージの見出しには、受信ステーションが特定の送信を適切かつ迅速に処理できるようにする最小の情報のみが含まれています。Codressメッセージの準備と送信に関する一般的なルールは、ACP 121 [ACP121]に記載されています。
This header field is used only to support interoperability with ACP 127 systems.
このヘッダーフィールドは、ACP 127システムとの相互運用性をサポートするためにのみ使用されます。
Example: MMHS-Codress-Message-Indicator: 23
例：MMHS-Codress-Message-Indicator：23
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.
MMHS-Originator-Reference Headerフィールドは、その存在により、「Originator's Number」と呼ばれるユーザー定義の参照を示します。このヘッダーフィールドがない場合、メッセージはユーザー定義の参照なしで受信されたと見なされます。
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
例：MMHS-Originator-Reference：IMSCOM-JIC-612-78
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.
MMHS-Primary-Precedenceヘッダーフィールドは、その存在により、プライマリ（「アクション」）受信者の優先レベルを示します。メッセージの発信ドメインは、メッセージに「to」（「アクション」）が含まれている場合、このヘッダーフィールドが常に存在することを確認する必要があります。
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.
MMHSプライマリ優先サービスの要素は、一次（アクション）受信者に対して軍事メッセージが処理される相対順序を示しています。より低いMMHS-PRIMARY-PRECEDENCEヘッダーフィールド値。
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.
ヘッダーフィールド値は、非陰性整数、または6つの事前定義されたケース非感受性ラベルの1つです：「延期」（「0」と同じ）、「ルーチン」（「1」と同じ）、「優先度」（「2」）、「即時」（「3」と同じ）、「フラッシュ」（「4」と同じ）、または「オーバーライド」（「5」と同じ）、オプションでコメントが続きます。ACP 123によれば、0〜15の範囲の値はNATO定義の優先順位レベルに予約されており、16〜31の範囲の値は全国ユーザー向けに予約されていることに注意してください。
Example 1: MMHS-Primary-Precedence: 0 (Deferred)
例1：MMHS-Primary-Precedence：0（延期）
Example 2: MMHS-Primary-Precedence: FLASH
例2：MMHS-Primary-Precedence：Flash
Example 3: MMHS-Primary-Precedence: 7
例3：MMHS-Primary-Precedence：7
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.
MMHS-Copy-Precedenceヘッダーフィールドは、その存在により、コピー（「情報」）受信者の優先順位レベルを示します。メッセージの発信ドメインは、メッセージに「CC：」または「BCC：」（「情報」）が含まれている場合、このヘッダーフィールドが常に存在することを確認する必要があります。
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.
MMHSコピーの優先順位要素は、コピー（情報）受信者に対して軍事メッセージを処理する相対順序を示します。すなわち、より高いMMHSコピープレシデンスヘッダーフィールド値を持つ軍事メッセージは、より低いMMHSコピー前処理ヘッダーフィールド値を持つ軍事メッセージの前に処理する必要があります。
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.
ヘッダーフィールド値は、非陰性整数、または6つの事前定義されたケース非感受性ラベルの1つです。「延期」（「0」と同じ）、「ルーチン」（「1」と同じ）、「優先度」（「2」）、「即時」（「3」と同じ）、「フラッシュ」（「4」と同じ）、または「オーバーライド」（「5」と同じ）、オプションでコメントが続きます。ACP 123によれば、0〜15の範囲の値はNATO定義の優先順位レベルに予約されており、16〜31の範囲の値は全国ユーザー向けに予約されています。
Example 1: MMHS-Copy-Precedence: 2 (priority)
例1：MMHS-Copy-Precedence：2（優先順位）
Example 2: MMHS-Copy-Precedence: Priority
例2：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-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).
MMHS-Messageタイプの見出し拡張機能は、その存在により、メッセージがエクササイズ、操作、プロジェクト、またはドリルと見なされるかどうかを示します。（タイプのリストは拡張可能であり、他のタイプは数値形式を使用して指定できることに注意してください。以下を参照）。
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.
ヘッダーフィールド値は、非陰性整数、または4つの事前定義されたケース非感受性ラベルの1つです：「エクササイズ」（「0」と同じ）、「操作」（「1」と同じ）、「プロジェクト」（「2」）、「ドリル」（「3」と同じ）。ACP 123によれば、0〜127の範囲の値はNATO定義のメッセージタイプ識別子と128〜255の範囲の値に予約されており、NATOによって定義されておらず、全国的または二国間で使用できます。
Example 1:
MMHS-Message-Type: 0(exercise); identifier="CANDLE FISH"
Example 2: MMHS-Message-Type: 3
例2：MMHS-Message-Type：3
Example 3: MMHS-Message-Type: 2 (projet)
例3：MMHS-Message-Type：2（Projet）
Example 4: MMHS-Message-Type: project
例4：MMHS-Message-Type：プロジェクト
Note that some of the examples above demonstrate use of optional comments. See Section 4 for the exact syntax of this header field.
上記の例のいくつかは、オプションのコメントの使用を示していることに注意してください。このヘッダーフィールドの正確な構文については、セクション4を参照してください。
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.
MMHS-Other-Recipients-Indicator-to Headerフィールドは、その存在により、MMHS以外の手段を介してメッセージを受け取るか、受信したプライマリ（「アクション」）受信者の名前を示します。このヘッダーフィールドとMMHS-Other-Recipients-Indicator-CCヘッダーフィールドの両方がないこと（セクション3.12を参照）は、すべての受信者が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.
このヘッダーフィールドにより、受信者は軍事メッセージのすべてのアクション受信者を決定できます。このヘッダーフィールドは、他のレシピエントインジケーターサービスの要素から派生しています。
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.
1. 受信者は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.
2. MMHSを介した受信者へのパスは安全ではない場合があります。したがって、創始者は代替メカニズムを使用して軍事メッセージを配布しました。
3. The recipient was already in receipt of the Military Message prior to the Military Message being inserted into the MMHS.
3. 受信者は、軍事メッセージがMMHSに挿入される前に、すでに軍事メッセージを受信していました。
Example: MMHS-Other-Recipients-Indicator-To: UK SHL COS; UK SHL IM
例：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.
上記の例には、MMHS以外の手段でメッセージを受け取った2人の主要な受信者の名前が含まれています。
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.
MMHS-OTHER-RECIPIENTS-INDICATOR-CCヘッダーフィールドは、その存在により、MMHS以外の手段を介してメッセージを受け取るか受信したコピー（「情報」）受信者の名前を示します。このヘッダーフィールドとMMHS-Other-Recipients-Indicator-to Headerフィールドの両方がないこと（セクション3.11を参照）は、すべての受信者が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.
1. 受信者は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.
2. MMHSを介した受信者へのパスは安全ではない場合があります。したがって、創始者は代替メカニズムを使用して軍事メッセージを配布しました。
3. The recipient was already in receipt of the Military Message prior to it being inserted into the MMHS.
3. 受信者は、MMHSに挿入される前に、すでに軍事メッセージを受信していました。
Example: MMHS-Other-Recipients-Indicator-CC: UK SHL LEGAD
例：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.
上記の例には、MMHS以外の手段でメッセージを受け取った1コピー（情報）受信者が含まれています。
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.
MMHS-ACP127-MESSAGE-IDENTIFIERヘッダーフィールドは、その存在により、ACP 127ドメインから発生したメッセージのACP 127メッセージ識別子[ACP127]を示します。この拡張機能がない場合、メッセージはACP 127ドメインに遭遇しませんでした。
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].
MMHS-ACP127-Message-Identifierには、3つのスペース分離されたフィールドで構成されるACP 127形式のライン3の内容が含まれています。。
This header field is used only to support interoperability with ACP 127 systems, it should be treated as opaque by a pure MMHS system.
このヘッダーフィールドは、ACP 127システムとの相互運用性をサポートするためにのみ使用されます。これは、純粋なMMHSシステムによって不透明として扱う必要があります。
Example: MMHS-Acp127-Message-Identifier: RPDLE 1234 0341215
例：MMHS-ACP127-MESSAGE-IDENTIFIER：RPDLE 1234 0341215
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.
MMHS-Originator-Plad（PLAD：Plain Language Address Designator）ヘッダーフィールドは、その存在により、相互参照目的で発信者に関連するプレーン言語アドレスを示します。このヘッダーフィールドがない場合、メッセージには、MMHSとACP 127ドメインの間にオリジナル層の相互参照がないと見なされます。
This header field is used only to support interoperability with ACP 127 systems.
このヘッダーフィールドは、ACP 127システムとの相互運用性をサポートするためにのみ使用されます。
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.
このヘッダーフィールドとMMHS-extended-authorisation-infoヘッダーフィールドは、ACP 127およびMMHSドメインの両方でメッセージ識別の相互参照を提供します。
Example: MMHS-Originator-PLAD: SACLANT
例：MMHS-Originator-Plad：Saclant
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].
次の構文仕様では、[RFC5234]で説明されているように、拡張されたバックスノール形式（ABNF）を使用します。ここで定義されていない用語は、[RFC5322]、[RFC5234]、および[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 )
軍事弦-Sequence = Military-String *（[fws] ";" [fws] Military-string）
Exempted-Address = "MMHS-Exempted-Address:" [FWS] address-list [FWS] CRLF
exected-address = "mmhs-exempted-address：" [fws]アドレスリスト[fws] crlf
Extended-Authorisation-Info = "MMHS-Extended-Authorisation-Info:" [FWS] date-time CRLF
extended-authorisation-info = "mmhs-extended-authorisation-info：" [fws] date-time crlf
Subject-Indicator-Codes = "MMHS-Subject-Indicator-Codes:" [FWS] sic-sequence [FWS] 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
Handling-instructions = "MMHSハンドリングインストラクション：" [FWS]軍事監視[FWS] CRLF
Message-Instructions = "MMHS-Message-Instructions:" [FWS] military-string-sequence [FWS] CRLF
Message-instructions = "mmhs-message-instructions：" [fws] sirility-string-sequence [fws] crlf
Codress-Message-Indicator = "MMHS-Codress-Message-Indicator:" [FWS] nonneg-integer [FWS] CRLF
Codress-Message-Indicator = "MMHS-Codress-Message-Indicator：" [FWS] Non-Neg-Integer [FWS] CRLF
Originator-Reference = "MMHS-Originator-Reference:" [FWS] military-string [FWS] CRLF
Originator-reference = "MMHS-Originator-Reference：" [fws] military-string [fws] crlf
PrimaryPrecedence = "MMHS-Primary-Precedence:" [FWS] precedence CRLF
PrimaryPrecedence = "MMHS-Primary-Precedence：" [fws]優先順位crlf
CopyPrecedence = "MMHS-Copy-Precedence:" [FWS] precedence CRLF
copyprecedence = "mmhs-copy-recedence：" [fws]優先順位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
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
messageTypeparam = "識別子" [fws] "=" [fws] quoted-military-string
Designator = military-string
OtherRecipIndicatorPrimary = "MMHS-Other-Recipients-Indicator-To:" [FWS] Designator *([FWS] ";" [FWS] Designator) [FWS] CRLF
その他のRecipIndicatorPrimary = "MMHS-OTHER-RECIPIENTS-INDICATOR-TO：" [fws]指定者 *（[fws] ";" [fws]指定者）[fws] crlf
OtherRecipIndicatorCopy = "MMHS-Other-Recipients-Indicator-CC:" [FWS] Designator *([FWS] ";" [FWS] Designator) [FWS] CRLF
その他のRecipIndicatorCopy = "MMHS-OTHER-RECIPIENTS-INDICATOR-CC：" [fws]指定者 *（[fws] ";" [fws]指定者）[fws] crlf
Acp127MessageIdentifier = "MMHS-Acp127-Message-Identifier:" [FWS] military-string [FWS] CRLF
ACP127MessageIdentifier = "MMHS-ACP127-Message-Identifier：" [fws] military-string [fws] crlf
OriginatorPLAD = "MMHS-Originator-PLAD:" [FWS] military-string [FWS] CRLF
OriginatorPlad = "MMHS-Originator-Plad：" [fws] Military-string [fws] crlf
address-list = <Defined in RFC 5322>
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.
このドキュメントで指定されているサービスは、[ACP123]の付録A1「ミリタリー見出し拡張」に記載されている機能のサブセットです。この機能の大部分は、このドキュメントでサポートされています。いくつかの機能が除外されており、この仕様の複雑さを大幅に増加させるでしょう。
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.
配布コード（A.1.3）の場合、サブジェクトインジケーターコードのみがサポートされ、配布拡張が省略されます。この文書の著者は、分布拡張が広く使用されていないと考えています。
Address List Indication (A.1.11) is not supported. This complex extension is deprecated in [ACP123].
アドレスリスト表示（A.1.11）はサポートされていません。この複雑な拡張は[ACP123]で非推奨されています。
Pilot Forwarding Information (A.1.13) is not supported.
パイロット転送情報（A.1.13）はサポートされていません。
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].
セキュリティ情報ラベル（A.1.16）はサポートされていません。この拡張は、[ACP123]の付録Aを支持して非推奨されます。これは、S/MIME [RFC5751]で直接互換性のある方法でサポートできる強化セキュリティサービス（ESS）ラベル[RFC2634]を使用します。
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.
ACP 127通知要求（[ACP123の付録A.2.1を参照）および応答（[ACP123]の付録A.3.1を参照）はサポートされていません。これらの拡張機能は、ACP 127ゲートウェイから通知を要求して返すために使用され、SMTPゲートウェイには関係ありません。
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].
この仕様で定義されているヘッダーフィールドは、[RFC2156]に従ってミキサーマッピングの一部として、ACP 123付録A1見出し拡張機能でマッピングされるように設計されています。これらの見出しの構文は、マッピングが機械的であるように定義されています。または、[RFC2156]に従って、インターネットメールアドレスで名前をマッピングする必要があります。
This section summarizes how a gateway between [ACP123] and [RFC5322] conformant to this specification operates.
このセクションでは、[ACP123]と[RFC5322]の間のゲートウェイがこの仕様に準拠している方法をまとめたものです。
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
着信X.400メッセージがP772としてエンコードされている場合、[RFC5322]ヘッダーフィールドは、この仕様で同等のヘッダーが定義されているすべてのACP 123見出し拡張機能のこの仕様に従って生成する必要があります。マッピングが定義されていない3つの見出し拡張機能の場合、見出し拡張機能は破棄またはマッピングされる場合があります
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>).
独自の方法。分布拡張機能がエンコードされている場合、これはコメントとして破棄または表される場合があります（<cfws>）。メッセージ全体は[RFC5652]に従って署名される場合があります。これらのルールは、転送されたメッセージの見出し拡張機能にも適用されます。MMメッセージは、ミキサーマッピングの目的で転送されたメッセージとして扱わなければなりません。ACP 127通知リクエストが存在する場合、これはコメント（<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.
着信X.400通知は[RFC2156]に従ってエンコードされます。ACP 127通知応答が存在する場合、これは独自の方法で破棄またはマッピングされる場合があります。
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.
着信SMTPメッセージに、この仕様で定義されているヘッダーフィールドのいずれかが含まれている場合、発信X.400メッセージはP772としてエンコードする必要があります。発信メッセージは、他の理由、たとえば軍事体の部分を含むメッセージなどのポリシー、特性など、P772としてエンコードされる場合があります。X.400メッセージは、ACP 123 Annex B [ACP123]またはStanag 4406 Annex G [Stanag-4406]に従って署名される場合があります。メッセージ/RFC822メッセージに含まれるボディパーツは、MMメッセージにマッピングし、適用される見出しマッピングルールにマッピングする必要があります。
Generated P772 messages SHOULD follow the following rules, generating heading extensions if needed.
生成されたP772メッセージは、次のルールに従い、必要に応じて見出し拡張機能を生成する必要があります。
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.
a. 拡張許可が必要です。MMHS-extended-authorization-infoヘッダーフィールドがない場合、デフォルト値は日付ヘッダーフィールドから取得されます。
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.
b. ヘッダーフィールドが存在する場合、主な優先順位が必要です。MMHS-Primary-Precedenceヘッダーフィールドがない場合、メッセージは軍事メッセージと見なされる必要はなく、ローカルポリシーに従って処理できます。
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.
c. CCヘッダーフィールドが存在し、MMHS-PRIMARY-PRECEDENCEヘッダーフィールドとは異なるMMHSコピー前処理ヘッダーフィールドがある場合、コピーの優先順位が必要です。
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.
d. メッセージIDフィールドの場合、ACP 123はX.400を超える追加の制約を適用し、[RFC2156]に加えて次のルールにつながり、この仕様に続いてゲートウェイが続くはずです。
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.
1. ローカル識別子は、少なくとも15文字の長さでなければなりません。[RFC2156]生成値がこれよりも短い場合、スペースが15文字にパッドで埋められます。この値はマップを正しく逆転させます。
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.
2. またはアドレス部分が必要であり、通常は[RFC2156]マッピングによって生成されません。ACP 123では必須です。ゲートウェイは、逆マッピングできる方法でまたはアドレスを生成する必要があります。ORアドレスを使用して、ローカル識別子でエンコードできない長いメッセージIDをエンコードできます。
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].
この仕様で定義されているヘッダーフィールドには、ACP 127に固有のサービス要素を運ぶフィールド[ACP127]が含まれます。この仕様は、これらのヘッダーフィールドのACP 127へのマッピングを定義するものではありません。このマッピングがない場合、これらの見出しはACP 123にマッピングし、したがって[stanag-のゲートウェイ翻訳）に続いてACP 127にマッピングすることをお勧めします。4406]。
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].
IANAは、セクション3のサブセクションで指定されたヘッダーフィールドのリストを、「メッセージヘッダーフィールドの登録手順」[RFC3864]で定義された「永続的なメッセージヘッダーフィールド名」レジストリに追加しました。
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).)
[ACP123]の付録Bは、X.400環境でMMHSメッセージをどのように保護することができるかを説明しています。同様の保護は、S/MIME [RFC5751]および/またはDKIM [RFC6376]を使用して提供できます。特に、DKIMは、この仕様をサポートするゲートウェイ/エンドポイントを受信することにより、保護されたインターネットメッセージの処理に適用される処分とサービスの質に影響を与える可能性のある、このドキュメントで指定されたヘッダーフィールドの変更、削除、または挿入から保護するために使用できます。（このドキュメントで定義されているヘッダーフィールドのほとんどは、受信ゲートウェイ/エンドシステム、MMHS-Subject-Indicator-Codes、MMHS-PRIMARY-PRECEDENCE/MMHS-COPY-PRECEDENCEヘッダーフィールドによるメッセージの処理に影響を与える可能性があることに注意してください。重要な例。たとえば、MMHS-Primary-Precedenceヘッダーフィールド値の変更は、受信者メッセージ転送エージェント（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.
元のメッセージヘッダーフィールドがデジタルで署名されている場合、ACP 123環境からインターネット環境との間、およびそのようなヘッダーフィールドを含むゲートウェイメッセージの行為は、デジタル署名を破ります。ゲートウェイは、翻訳されたメッセージ自体に署名することができます（例：DKIMを使用）が、メッセージの受信者は、メッセージが元の送信者によって生成されたことを確認できません。
[ACP123] CCEB, "Common Messaging Strategy and Procedures", ACP 123 (B), May 2009, http://jcs.dtic.mil/j6/cceb/acps/acp123/.
[ACP123] CCEB、「一般的なメッセージング戦略と手順」、ACP 123（b）、2009年5月、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/.
[ACP127] CCEB、「通信指示 - テープリレー手順」、ACP 127（g）、1988年11月、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.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2156] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[RFC2156] Kille、S。、「Mixer（Mime Internet X.400 Enhanced Relay）：X.400とRFC 822/MIMEの間のマッピング」、RFC 2156、1998年1月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864] Klyne、G.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。、およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009.
[RFC5652] Housley、R。、「暗号化メッセージ構文（CMS）」、STD 70、RFC 5652、2009年9月。
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[RFC6376] Crocker、D.、ed。、Hansen、T.、ed。、およびM. Kucherawy、ed。、「Domainkeys Idefied Mail（DKIM）署名」、RFC 6376、2011年9月。
[ACP121] CCEB, "Comms Instructions - General", ACP 121 (I), October 2010, http://jcs.dtic.mil/j6/cceb/acps/acp121/.
[ACP121] CCEB、「Comms Instructions -General」、ACP 121（i）、2010年10月、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/.
[ACP131] CCEB、「Comms Instructions -Operating Signals」、ACP 131（F）、2009年4月、http：//jcs.dtic.mil/j6/cceb/acps/acp131/。
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[RFC2634] Hoffman、P.、ed。、「S/MIMEの強化セキュリティサービス」、RFC 2634、1999年6月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2メッセージ仕様」、RFC 5751、2010年1月。
[STANAG-4406] NATO, "STANAG 4406 Edition 2: Military Message Handling System", STANAG 4406, March 2005.
[Stanag-4406] NATO、「Stanag 4406 Edition 2：軍事メッセージ処理システム」、Stanag 4406、2005年3月。
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.
このドキュメントでは、ジュリアンオニオンとグレアムルントとスタナグ4406（第2版）による「X.400 P772とRFC-822の間のマッピング」から多くのテキストをコピーします。したがって、この文書の著者は、これらの文書の著者による貢献を認めたいと考えています。
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.
スティーブ・キル、アラン・ロス、デビッド・ウィルソン、ジェームズ・ウスマー、キャシー・ナックルズ、アンディ・トレイラー、ケン・カールバーグ、クリス・ボナッティ、オエヴィンド・ジョンソン、マイキータ・イェフスティフェフ、ショーン・ターナー、スティーブン・ファレル、エイドリアン・ファレル、ペテット・セント - そしてre。
Authors' Addresses
著者のアドレス
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex, TW12 2BX UK
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton、ミドルセックス、TW12 2BX UK
EMail: Alexey.Melnikov@isode.com
Graeme Lunt SMHS Ltd Bescar Moss Farm Bescar Lane Ormskirk L40 9QN UK
graeme lunt smhs ltd bescar moss farm bescar lane ormskirk l40 9qn uk
EMail: graeme.lunt@smhs.co.uk