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.
軍事メッセージ処理システム（MMHS）は、国内および国際的な戦略的、戦術的なネットワーク間でのリリース、配布、セキュリティ、およびタイムリーな配信を保証する正式なメッセージを処理します。サービスのMMHS要素ITU-T X.400（1992）国際規格の拡張セットとして定義され、この文書は（RFC 5322のメッセージヘッダフィールドおよび関連する処理を指定STANAG 4406盤2及びACP 123で指定されています比較可能なメッセージングサービスを提供するために、インターネットメッセージ形式）。また、この文書では、メッセージの変換をサポートしていSTANAG 4406 /インターネットメールゲートウェイを提供します。
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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は[ACP123（また、STANAG 4406に指定された[STANAG-4406]）、基本的なX.400（1992）軍事メッセージングによって、必要なサービスのためのプロトコルへの拡張の数を定義するACP 123で定義された軍用仕様です。
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
この文書は、インターネットメッセージヘッダフィールド（詳細については、セクション5を参照）ACP 123 [ACP123]で定義されたサービスの要素のほとんどを変換サポート。この仕様はMimeインターネットX.400の強化リレー（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] 123 / STANAG 4406、附属書A ACPで定義された拡張を見出しX.400対人メッセージングシステム（IPMS）とMIXERゲートウェイで相互変換を可能にします
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節では、彼らのために増補バッカス記法（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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]
該当するプロトコル：メール[RFC5322]ステータス：情報提供者/変更コントローラ：IESG（iesg@ietf.org）IETF仕様書（複数可）に代わって：[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免除アドレスヘッダフィールドは、その存在によって、メッセージを受け取るべきでないアドレス一覧（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>
例：MMHS-免除-住所：イギリスのSHL CGT Samuals G <graham.samuals@shl.example.com>、英国SHLデューティオフィサー<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]]
該当するプロトコル：メール[RFC5322]ステータス：情報提供者/変更コントローラ：IESG（iesg@ietf.org）IETF仕様書（複数可）に代わって：[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-拡張 - 許可 - 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
例：MMHS-拡張 - 許可 - インフォメーション：月、2010年8月9日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]
該当するプロトコル：メール[RFC5322]ステータス：情報提供者/変更コントローラ：IESG（iesg@ietf.org）IETF仕様書（複数可）に代わって：[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）が正式にメッセージのトピックを識別するための機構です。 SICSはレシピエントの組織への送達後に、メッセージ配信のための情報を提供するコードをネストされています。 SICSは通常3つの文字または3つの文字と数字ですが、長い8文字までであり得ます。 SICSを使用して国連や組織は、通常、中央のレジストリを維持します。
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-サブジェクト・インジケータ・コードのヘッダフィールドは、受信者または受信者のユーザエージェントに配信情報を示しており、一つ以上のSICSを含有します。この情報は、メッセージの自動または手動のローカル配信を行うために使用することができます。 MMHS-サブジェクト・インジケータ・コードのヘッダフィールドが存在しない場合、ローカル配信は、受信者のドメインのポリシーをメッセージ処理に従ってあろう。
[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-サブジェクト・インジケータ・コードは、フィールドが分布コードのみSICコードコンポーネントを覆うヘッダ。
Example: MMHS-Subject-Indicator-Codes: SDM; KKZ ; BRL
例：MMHS-件名-インジケータ-コード：SDM; KKZ; BRL
The example above includes three SIC codes: "SDM" (GROUND/LAND REQUIREMENTS), "KKZ" (HELICOPTER PUBLICATIONS/MANUALS), and "BRL" (HILEX INCIDENTS).
"SDM"（GROUND / LAND要件）、 "KKZ"（ヘリコプターの出版物/マニュアル）、および "BRL"（HILEX事件）の例では、上記の3つのSICコードを含みます。
Applicable protocol: mail [RFC5322] Status: informational Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF Specification document(s): [RFC6477]
該当するプロトコル：メール[RFC5322]ステータス：情報提供者/変更コントローラ：IESG（iesg@ietf.org）IETF仕様書（複数可）に代わって：[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.
【ACP127】ACP 127で定義された命令（また、「送信指示」と呼ぶ）は、フォーマットライン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.
"RXFPA ZOV MINDEF"：上記の例では、1 ACP 131（F）処理命令を含みます。 「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]
該当するプロトコル：メール[RFC5322]ステータス：情報提供者/変更コントローラ：IESG（iesg@ietf.org）IETF仕様書（複数可）に代わって：[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-メッセージ命令のヘッダフィールドは、その存在によって、（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-メッセージ指示：MINIMIZE考えられ; 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.
上記の例では、ACP123（B）で定義される2つのメッセージ命令を含む[ACP123]：発信ユーザは、受信者の最小化状態と受信者はせずにさらにメッセージを配布するべきではないことを示す「NO分布」と考えたことを示す「考えを最小化」発信ユーザの承認。
Applicable protocol: mail [RFC5322] Status: informational Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF Specification document(s): [RFC6477]
該当するプロトコル：メール[RFC5322]ステータス：情報提供者/変更コントローラ：IESG（iesg@ietf.org）IETF仕様書（複数可）に代わって：[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-メッセージインジケータヘッダフィールドは、その存在により、メッセージはCodress形式であることを示しています。このヘッダフィールドが存在しない場合、メッセージは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テキスト（本体）[ACP127]内に暗号化されたものです。任意Codressメッセージの見出しは、特定の送信に適切かつ迅速に対処するために受信局を可能にする情報の唯一の最小量を含有します。 Codressメッセージの準備と送信のための一般的なルールは、[ACP121] ACP 121に示されています。
This header field is used only to support interoperability with ACP 127 systems.
このヘッダーフィールドは、ACP 127システムとの相互運用性をサポートするためにのみ使用されます。
Example: MMHS-Codress-Message-Indicator: 23
例：MMHS-Codress - メッセージインジケータ：23
Applicable protocol: mail [RFC5322] Status: informational Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF Specification document(s): [RFC6477]
該当するプロトコル：メール[RFC5322]ステータス：情報提供者/変更コントローラ：IESG（iesg@ietf.org）IETF仕様書（複数可）に代わって：[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オリジネータリファレンスヘッダフィールドは、その存在により、「発信者番号」と呼ばれるユーザー定義の基準を示しています。このヘッダフィールドが存在しない場合、メッセージは、任意のユーザ定義の基準なく受信考えます。
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-発信-参考：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]
該当するプロトコル：メール[RFC5322]ステータス：情報提供者/変更コントローラ：IESG（iesg@ietf.org）IETF仕様書（複数可）に代わって：[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プライマリ優先順位のヘッダフィールドは、その存在により、一次（「アクション」）受信者の優先レベルを示しています。 （「アクション」）アドレス：メッセージ「が」含まれている場合は、ドメインを発信するメッセージは、このヘッダフィールドは常に存在していることを保証しなければなりません。
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原色優先順位ヘッダフィールド値を持つ軍事メッセージに処理されるべき相対的な順序を示します下部MMHS原色優先順位ヘッダフィールド値。
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"）、同（ "即時" は "4" と同じ "3"）、 "フラッシュ"（）、または "オーバーライド"（ "5" と同じ）として、必要に応じてコメントが続きます。 ACP 123によると、なお、0から15の範囲の値は、NATO定義の優先レベルのために予約され、そして16から31の範囲の値は、国家のユーザのために予約されています。
Example 1: MMHS-Primary-Precedence: 0 (Deferred)
実施例1：MMHSプライマリ・優先順位：0（遅延）
Example 2: MMHS-Primary-Precedence: FLASH
例2：MMHSプライマリ・優先順位：FLASH
Example 3: MMHS-Primary-Precedence: 7
例3：MMHSプライマリ・優先順位：7
Applicable protocol: mail [RFC5322] Status: informational Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF Specification document(s): [RFC6477]
該当するプロトコル：メール[RFC5322]ステータス：情報提供者/変更コントローラ：IESG（iesg@ietf.org）IETF仕様書（複数可）に代わって：[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コピー優先順位のヘッダフィールドは、その存在によって、（「情報」）受信者のコピーの優先レベルを示しています。又は「のBcc：」（「情報」）アドレス：メッセージ発信ドメインは、メッセージが「CC」が含まれている場合、このヘッダーフィールドが常に存在することを確実にしなければなりません。
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"）、同（ "即時" は "4" と同じ "3"）、 "フラッシュ"（）、または "オーバーライド"（ "5" と同じ）として、必要に応じてコメントが続きます。 ACP 123によれば、0から15の範囲の値は、16から31の範囲のNATOに定義された優先レベルと値のために予約されているが、国家のユーザのために予約されていることに留意されたいです。
Example 1: MMHS-Copy-Precedence: 2 (priority)
実施例1：MMHS-コピー優先順位：2（優先）
Example 2: MMHS-Copy-Precedence: Priority
例2：MMHS-コピー優先順位：優先順位
Applicable protocol: mail [RFC5322] Status: informational Author/change controller: IESG (iesg@ietf.org) on behalf of the IETF Specification document(s): [RFC6477]
該当するプロトコル：メール[RFC5322]ステータス：情報提供者/変更コントローラ：IESG（iesg@ietf.org）IETF仕様書（複数可）に代わって：[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-メッセージタイプ見出し拡張は、その存在により、メッセージが運動、操作、プロジェクト、またはドリルと考えられるべきであるかどうかを示します。 （下記参照、タイプのリストは拡張可能であり、他の種類の数値形式を使用して指定することができることに留意されたいです）。
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の範囲の値が128から255の範囲のNATO定義メッセージタイプ識別子と値のために予約されていることに留意されたいNATOによって定義されておらず、全国的又は両側に使用することができます。
Example 1: MMHS-Message-Type: 0(exercise); identifier="CANDLE FISH"
実施例1：MMHS-メッセージタイプ：0（運動）。識別子=「キャンドルFISH」
Example 2: MMHS-Message-Type: 3
例2：MMHS - メッセージの種類：3
Example 3: MMHS-Message-Type: 2 (projet)
例3：MMHS - メッセージタイプ2（プロジェクト）
Example 4: MMHS-Message-Type: project
例4：MMHS - メッセージの種類：プロジェクト
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]
該当するプロトコル：メール[RFC5322]ステータス：情報提供者/変更コントローラ：IESG（iesg@ietf.org）IETF仕様書（複数可）に代わって：[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-受信者インジケータ-へのその存在によって、フィールドヘッダ、一次（「アクション」）の名前を示して受信するように意図された受信者、または受信した介してメッセージがMMHS以外の手段。このヘッダフィールドとMMHS - その他 - 受信者-インジケータ-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:
軍事メッセージの受信者は、このヘッダによって識別することができる理由として、いくつかの理由があります。
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-その他-受信者-インジケータ-TO：英国SHL COS;英国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]
該当するプロトコル：メール[RFC5322]ステータス：情報提供者/変更コントローラ：IESG（iesg@ietf.org）IETF仕様書（複数可）に代わって：[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-受信者インジケータ-CCヘッダフィールド、その存在によって、コピー（「情報」）の名前を示して受信するように意図された受信者、または受信した、メッセージMMHS以外の手段を介し。 ToヘッダーフィールドMMHS - その他 - 受信者-インジケータ - このヘッダフィールドとの両方が存在しない場合は、（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:
軍事メッセージの受信者は、このヘッダによって識別することができる理由として、いくつかの理由があります。
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-その他-受信者-インジケータ-CC：英国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]
該当するプロトコル：メール[RFC5322]ステータス：情報提供者/変更コントローラ：IESG（iesg@ietf.org）IETF仕様書（複数可）に代わって：[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-メッセージ識別子ヘッダフィールドは、その存在により、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].
コールステーション（DERI）、ステーションシリアル番号（SSN）、及びファイリング時間（JFT）ACP127]：MMHS-Acp127-メッセージ識別子ACP 127フォーマット3スペースで区切られたフィールドから成る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-メッセージ識別子：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]
該当するプロトコル：メール[RFC5322]ステータス：情報提供者/変更コントローラ：IESG（iesg@ietf.org）IETF仕様書（複数可）に代わって：[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オリジネータ-PLAD（PLAD：平易な言葉アドレス指定子）、その存在によってヘッダフィールドは、相互参照目的のために発信元に関連付けられている平易言語のアドレスを示します。このヘッダフィールドが存在しない場合、メッセージはMMHS及びACP 127個のドメイン間の発信PLAD相互参照を持たないとみなされます。
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-拡張認可-Infoヘッダーフィールドは両方ACP 127とMMHSドメイン内のメッセージ識別のための相互参照を提供します。
Example: MMHS-Originator-PLAD: SACLANT
例：MHS-発信-サラダ：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"
NZ-DIGIT =％x31-39。 "1" .. "9"
nonneg-integer = "0" / (NZ-DIGIT *DIGIT)
nonneg整数= "0" /（NZ-DIGIT * DIGIT）
military-string = 1*69( ps-char )
軍事文字列= 1 * 69（PS-CHAR）
quoted-military-string = DQUOTE military-string DQUOTE
引用された軍事文字列= DQUOTE軍事列DQUOTE
military-string-sequence = military-string *( [FWS] ";" [FWS] military-string )
軍事文字列シーケンス=軍事文字列*（[FWS]「;」[FWS]軍事文字列）
Exempted-Address = "MMHS-Exempted-Address:" [FWS] address-list [FWS] CRLF
免除・アドレス= "MMHS免除-住所：" [FWS]アドレスリスト[FWS] CRLF
Extended-Authorisation-Info = "MMHS-Extended-Authorisation-Info:" [FWS] date-time CRLF
拡張認証-情報= "MMHS-拡張 - 許可 - インフォメーション：" [FWS]日時CRLF
Subject-Indicator-Codes = "MMHS-Subject-Indicator-Codes:" [FWS] sic-sequence [FWS] CRLF
被写体インジケータ・コード= "MMHS-被写体インジケータ・コード：" [FWS] SIC-配列[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-配列= SIC×（[FWS] "" [FWS] SIC）。 ACP 123は、最大数のことを指定します。 SICS以上8 SICSでの8.です。許可が、追加SICSはないかもしれません。 ACP 123システムに転送します。
sic = 3*8( ps-char )
SIC = 3 * 8（PS-CHAR）
Handling-Instructions = "MMHS-Handling-Instructions:" [FWS] military-string-sequence [FWS] CRLF
取り扱い命令= "MMHS-取扱い-指示：" [FWS]軍事文字シーケンス[FWS] CRLF
Message-Instructions = "MMHS-Message-Instructions:" [FWS] military-string-sequence [FWS] CRLF
メッセージ命令= "MMHS-メッセージ指示：" [FWS]軍事文字シーケンス[FWS] CRLF
Codress-Message-Indicator = "MMHS-Codress-Message-Indicator:" [FWS] nonneg-integer [FWS] CRLF
Codress-メッセージインジケータ= "MMHS-Codress-メッセージインジケータ：" [FWS] nonneg整数[FWS] CRLF
Originator-Reference = "MMHS-Originator-Reference:" [FWS] military-string [FWS] CRLF
オリジネーターリファレンス= "MMHS-創始-参考：" [FWS]軍事文字列[FWS] CRLF
PrimaryPrecedence = "MMHS-Primary-Precedence:" [FWS] precedence CRLF
PrimaryPrecedence = "MMHS-PrimaryPrecedence：" [FWS]優先CRLF
CopyPrecedence = "MMHS-Copy-Precedence:" [FWS] precedence CRLF
CopyPrecedence = "MMHS-CopyPrecedence：" [FWS]優先CRLF
precedence = (nonneg-integer / std-precedence) [CFWS]
優先度=（nonneg整数/ STD-優先）[CFWS]
std-precedence = "deferred" / "routine" / "priority" / "immediate" / "flash" / "override" ; deferred == 0 ; routine == 1 ; priority == 2 ; immediate == 3 ; flash == 4 ; override == 5
STD-優先= "延期" / "日常" / "優先順位" / "即時" / "フラッシュ" / "上書き";繰延== 0;ルーチン== 1;優先順位== 2;即時== 3。フラッシュ== 4。オーバーライド== 5
MessageType = "MMHS-Message-Type:" [FWS] message-type [CFWS] [";" [FWS] MessageTypeParam [FWS] ] CRLF
MessageType = "MMIS-のMessageType：" "？" [FOS]メッセージタイプ[SFOS] [ 【FOS] MessageTypeParam [FOS] KRLY
message-type = nonneg-integer / std-message-type
メッセージタイプ= nonneg整数/ STD-メッセージタイプ
std-message-type = "exercise" / "operation" / "project" / "drill" ; exercise == 0 ; operation == 1 ; project == 2 ; drill == 3
STD-のメッセージタイプ= "エクササイズ" / "操作" / "プロジェクト" / "ドリル";エクササイズ== 0;操作== 1;プロジェクト== 2;ドリル== 3
MessageTypeParam = "identifier" [FWS] "=" [FWS] quoted-military-string
MessageTypeParam = "識別子" [FWS] "=" [FWS]引用された軍事文字列
Designator = military-string
指示子=軍事列
OtherRecipIndicatorPrimary = "MMHS-Other-Recipients-Indicator-To:" [FWS] Designator *([FWS] ";" [FWS] Designator) [FWS] CRLF
OtierRekipIndikatorPrimary = "MMIS-Otier-Rekipients-Indikator-へ：" [FOS]指定子の*（[FOS] [FOS]指定子 "？"）[FOS] KRLY
OtherRecipIndicatorCopy = "MMHS-Other-Recipients-Indicator-CC:" [FWS] Designator *([FWS] ";" [FWS] Designator) [FWS] CRLF
OtierRekipIndikatorKopy = "MMIS-Otier-Rekipients-Indikator-KK：" [FOS]デジグネータ×（ "？" [FOS] [FOS]デジグネータ）FOS] KRLY
Acp127MessageIdentifier = "MMHS-Acp127-Message-Identifier:" [FWS] military-string [FWS] CRLF
Acp127MessageIdentifier = "MMHS-Acp127 - メッセージ識別子：" [FWS]軍事文字列[FWS] CRLF
OriginatorPLAD = "MMHS-Originator-PLAD:" [FWS] military-string [FWS] CRLF
OriginatorPLAD = "MMHS-OriginatorPLAD：" [FWS]軍事文字列[FWS] CRLF
address-list = <Defined in RFC 5322>
<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）がサポートされていません。この拡張は、S / MIME [RFC5751]で直接互換性のある方法でサポートできる拡張セキュリティサービス（ESS）ラベル[RFC2634]を使用しています[ACP123]の附属書Aの賛成で廃止されました。
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].
本明細書で定義されたヘッダフィールドは、ACP 123附属書A1は[RFC2156]に記載MIXERマッピングの一部として、拡張を見出しにマッピングされるように設計されています。これらの見出しの構文は、マッピングが機械的であるように定義されています。または名前は、[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 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>).
着信X.400メッセージがP772として符号化されている場合は、[RFC5322]のヘッダフィールドは、同等のヘッダは、本明細書で定義されている全てのACP 123見出し拡張のための本明細書に従って生成されなければなりません。マッピングが定義されていない3つの見出し拡張のために、見出し拡張は廃棄してもよく、または独自の方法でマッピングされました。配布拡張が符号化されている場合、これはコメントとして廃棄又は表現することができる（<CFWS>）。メッセージ全体は、[RFC5652]に従って署名されるかもしれません。これらのルールは、転送されたメッセージに拡張を見出しに適用されます。 MM-メッセージMIXERマッピングの目的のために転送されたメッセージとして扱わなければなりません。 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付属書B [ACP123]またはSTANAG 4406付属書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-拡張認証-Infoヘッダーフィールドが存在しない場合は、デフォルト値がDateヘッダーフィールドから取得されます。
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。 Toヘッダフィールドが存在する場合、一次優先順位が必要です。 MMHS原色優先順位ヘッダフィールドが存在しない場合、メッセージは、軍事メッセージ考慮する必要はないとローカルポリシーに従って処理することができます。
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原色優先順位ヘッダフィールドは異なる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は、本明細書以下ゲートウェイ続くすべき、[RFC2156]に加えて、以下のルールにつながる、X.400超える追加の制約を適用します。
1. The local identifier MUST be at least 15 characters long. If
the [RFC2156] generated value is shorter than this, then it
is padded with spaces to 15 characters. This value will
correctly reverse map.
2. The OR Address part is required, and 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にこれらのヘッダフィールドのマッピングを定義していない、附属書Dの（ゲートウェイ翻訳）[STANAG-以下、したがってACP 127にこれらの見出しは、ACP 123にマッピングすることが推奨されます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は、「メッセージヘッダフィールドの登録手順」[RFC3864]で定義される「永続的メッセージヘッダーフィールド名」レジストリに第3のサブセクションで指定されたヘッダフィールドのリストを追加しました。
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はMMHSメッセージがX.400環境で保護する方法について説明します。同様の保護は、S / MIME [RFC5751]及び/又はDKIM [RFC6376]を使用して提供することができます。特に、DKIMは、変更、削除、またはこの仕様をサポートするゲートウェイ/エンドポイントを受信することにより、配置と保護インターネットメッセージの処理に適用されるサービスの品質に影響を与えることができ、この文書で指定されたヘッダフィールドの挿入から保護するために使用することができます。 （本書で定義されたヘッダフィールドの大部分は受信ゲートウェイ/エンドシステムによってメッセージの処理に影響を与える可能性があることに注意してください、MMHS-サブジェクト・インジケータ・コードとMMHS原色優先順位/ MMHSコピー優先順位のヘッダフィールドは、ほとんどです重要な例は、例えば、MMHSプライマリ優先順位のヘッダフィールド値の変更は、受信者のメッセージ転送エージェント（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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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インターネットX.400拡張リレー）：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.、ノッティンガム、M.、およびJ.モーグル、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.
"構文仕様のための増大しているBNF：ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、STD 68、RFC 5234、2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、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]クロッカー、D.、編、ハンセン、T.編、及びM. Kucherawy、エド。、 "ドメインキー・アイデンティファイド・メール（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、 "途切れの取扱説明書 - 一般"、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、 "途切れ手順 - 操作信号"、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]ホフマン、P.、エド。、 "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.ターナー、 "/セキュア多目的インターネットメール拡張（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版2：軍事メッセージ処理システム"、STANAG 4406、2005年3月。
Appendix A. Acknowledgements
付録A.謝辞
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.
このドキュメントのコピージュリアンタマネギとグレアムラントとSTANAG 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.
スティーブKille、アラン・ロス、デビッド・ウィルソン、ジェームズUsmar、キャシーNuckles、アンディTrayler、ケン・カールバーグ、クリスBonatti、Oeyvindヨンソン、Mykyta Yevstifeyev、ショーン・ターナー、スティーブン・ファレル、エードリアンファレル、ピーターサンが提供する口コミやテキストのための多くのおかげで-Andre。
Authors' Addresses
著者のアドレス
Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex, TW12 2BX UK
アレクセイ・メルニコフISODE株式会社5つのキャッスルビジネス村の36の駅道ハンプトン、ミドルセックス、TW12 2BX英国
EMail: Alexey.Melnikov@isode.com
メールアドレス：Alexey.Melnikov@isode.com
Graeme Lunt SMHS Ltd Bescar Moss Farm Bescar Lane Ormskirk L40 9QN UK
グレアム・ラントSMHS株式会社Besco BescoモスファームレーンオームスカークL40 9QN英国
EMail: graeme.lunt@smhs.co.uk
メールアドレス：graeme.lunt@smhs.co.uk