[要約] RFC 3459は、MIMEパラメータの拡張であるCritical Contentに関するものであり、その目的は、メールの重要なコンテンツを識別し、適切な処理を行うための仕組みを提供することです。
Network Working Group E. Burger
Request for Comments: 3459 SnowShore Networks
Updates: 3204 January 2003
Category: Standards Track
Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter
重要なコンテンツ多目的インターネットメールエクステンション（MIME）パラメーター
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes the use of a mechanism for identifying body parts that a sender deems critical in a multi-part Internet mail message. The mechanism described is a parameter to Content-Disposition, as described by RFC 3204.
このドキュメントでは、送信者がマルチパートのインターネットメールメッセージで重要とみなす身体部分を識別するためのメカニズムの使用について説明します。記載されているメカニズムは、RFC 3204で説明されているように、コンテンツ拡張のパラメーターです。
By knowing what parts of a message the sender deems critical, a content gateway can intelligently handle multi-part messages when providing gateway services to systems of lesser capability. Critical content can help a content gateway to decide what parts to forward. It can indicate how hard a gateway should try to deliver a body part. It can help the gateway to pick body parts that are safe to silently delete when a system of lesser capability receives a message. In addition, critical content can help the gateway chose the notification strategy for the receiving system. Likewise, if the sender expects the destination to do some processing on a body part, critical content allows the sender to mark body parts that the receiver must process.
送信者が重要と見なすメッセージの部分を知ることにより、コンテンツゲートウェイは、より低い機能のシステムにゲートウェイサービスを提供する際に、マルチパートメッセージをインテリジェントに処理できます。重要なコンテンツは、コンテンツゲートウェイがどのパーツを転送するかを決定するのに役立ちます。ゲートウェイが身体の部分を届けようとするのがどれほど難しいかを示すことができます。より少ない機能のシステムがメッセージを受信したときに、静かに削除できるように安全な身体部分を選択するのに役立ちます。さらに、重要なコンテンツは、ゲートウェイが受信システムの通知戦略を選択するのに役立ちます。同様に、送信者が宛先がボディ部分で何らかの処理を行うことを期待している場合、クリティカルコンテンツにより、送信者はレシーバーが処理する必要があるボディ部分をマークすることができます。
Table of Contents
目次
1. Conventions used in this document..............................3
2. Introduction...................................................3
3. Handling Parameter.............................................4
3.1. REQUIRED..................................................4
3.2. OPTIONAL..................................................5
3.3. Default Values............................................5
3.4. Other Values..............................................5
4. Collected Syntax...............................................6
5. Notification...................................................6
5.1. DSN vs. MDN Generation....................................7
5.2. Summary...................................................7
6. Signed Content.................................................8
7. Encrypted Content..............................................9
8. Status Code...................................................10
9. Requirements for Critical Content.............................11
9.1. Needs....................................................11
9.2. Current Approaches.......................................12
10. The Content Gateway...........................................13
10.1. Integrated Content Gateway..............................14
10.2. Disaggregated Delivery Network..........................14
11. Backward Compatibility Considerations.........................15
12. MIME Interactions.............................................15
12.1. multipart/alternative...................................15
12.2. multipart/related.......................................15
12.3. message/rfc822..........................................15
12.4. multipart/signed........................................16
12.5. multipart/encrypted.....................................16
13. Implementation Examples.......................................16
13.1. Content Gateways........................................16
13.2. Disaggregated Content Gateway...........................17
14. OPES Considerations...........................................18
14.1. Consideration (2.1): One-Party Consent..................18
14.2. Consideration (2.2): IP-layer Communications............18
14.3. Consideration (3.1): Notification - Sender..............18
14.4. Consideration (3.2): Notification - Receiver............18
14.5. Consideration (3.3): Non-Blocking.......................18
14.6. Consideration (4.1): URI Resolution.....................18
14.7. Consideration (4.2): Reference Validity.................19
14.8. Consideration (4.3): Architecture Extensions............19
14.9. Consideration (5.1): Privacy............................19
15. Security Considerations.......................................19
16. IANA Considerations...........................................19
17. References....................................................20
17.1 Normative References.....................................20
17.2 Informative Reference....................................21
18. Acknowledgments...............................................22
19. Intellectual Property Notice..................................23
20. Author's Address..............................................23
21. Full Copyright Statement......................................24
This document refers generically to the sender of a message in the masculine (he/him/his) and the recipient of the message in the feminine (she/her/hers). This convention is purely for convenience and makes no assumption about the gender of a message sender or recipient.
このドキュメントは、男性（彼/彼/彼）のメッセージの送信者と、女性（彼女/彼女/彼女）のメッセージの受信者を一般的に参照します。この条約は純粋に便利なものであり、メッセージ送信者または受信者の性別については想定していません。
The key words "MUST", "MUST NOT", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].
「必須」、「そうしない」、「そうしない」、「しなければ」、「そうしない」、「そうではない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [2]に記載されています。
The word "REQUIRED" in this document does not follow the definition found in RFC 2119. This is because this document defines a parameter named "REQUIRED". There is no requirement in this document that is "REQUIRED", so there is no confusion.
このドキュメントの「必須」という単語は、RFC 2119にある定義には従いません。これは、このドキュメントが「必須」という名前のパラメーターを定義しているためです。このドキュメントには「必須」の要件はないため、混乱はありません。
In this document, the "sending agent" is the originator of the message. It could be a mail user agent (MUA) for an Internet message, or a SIP User Agent Client (UAC) for a SIP [3] message. The "endpoint" is the receiving device, of lesser capability than the sending agent.
このドキュメントでは、「送信エージェント」がメッセージの発信者です。インターネットメッセージのメールユーザーエージェント（MUA）、またはSIP [3]メッセージのSIPユーザーエージェントクライアント（UAC）である可能性があります。「エンドポイント」は受信デバイスであり、送信エージェントよりも能力が低いです。
NOTE: Notes, such as this one, provide additional nonessential information that the reader may skip without missing anything essential. The primary purpose of these non-essential notes is to convey information about the rationale of this document, or to place this document in the proper historical or evolutionary context. Readers whose sole purpose is to construct a conformant implementation may skip such information. However, it may be of use to those who wish to understand why we made certain design choices.
注：このようなメモは、読者が重要なものを欠落せずにスキップする可能性のある追加の非必須情報を提供します。これらの非必須メモの主な目的は、この文書の理論的根拠に関する情報を伝えるか、この文書を適切な歴史的または進化的な文脈に配置することです。唯一の目的である読者は、コンフォーマントの実装を構築することであり、そのような情報をスキップする可能性があります。ただし、特定のデザインの選択をした理由を理解したい人には役に立つかもしれません。
The specification of Critical Content is small and compact. For the benefit of developers, the specification comes first, the rationale after.
重要なコンテンツの仕様は小さくてコンパクトです。開発者の利益のために、仕様が最初に、その後の根拠があります。
One concept that an implementer must understand is the content gateway. Section 10 describes the content gateway. In brief, a content gateway has knowledge of the receiving system's capabilities. The content gateway passes messages the receiving system can process, render or store. The content gateway can modify a message, for example by deleting unrenderable or storable body parts, for delivery to the receiving system. Finally, the content gateway can reject a message that the receiving system cannot handle.
実装者が理解しなければならない概念の1つは、コンテンツゲートウェイです。セクション10では、コンテンツゲートウェイについて説明します。簡単に言えば、コンテンツゲートウェイには、受信システムの機能に関する知識があります。コンテンツゲートウェイは、受信システムが処理、レンダリング、または保存できるメッセージを渡します。コンテンツゲートウェイは、受信システムへの配信のために、無限または保存可能なボディパーツを削除することにより、メッセージを変更できます。最後に、コンテンツゲートウェイは、受信システムが処理できないメッセージを拒否できます。
Although Critical Content processing is not an OPES service, the protocol machinery described in this document meets all of the OPES IAB requirements as stated by RFC 3238 [4]. Section 14 describes this in detail. In particular, unlike the current situation where content gateways silently modified messages, or had abstract rules for modifying them (see the content transformation rules in VPIM, for example), the Critical Content mechanism allows for the sending user to explicitly indicate desired content handling by content gateways
重要なコンテンツ処理はOPESサービスではありませんが、このドキュメントで説明されているプロトコル機械は、RFC 3238 [4]で述べられているすべてのOPES IAB要件を満たしています。セクション14では、これについて詳しく説明します。特に、コンテンツゲートウェイが静かに修正された、またはそれらを変更するための抽象的なルールがある現在の状況とは異なり（たとえば、VPIMのコンテンツ変換ルールを参照）、重要なコンテンツメカニズムにより、送信ユーザーが希望するコンテンツの処理を明示的に示すことができます。コンテンツゲートウェイ
NOTE: This document updates RFC 3204 [5] to separate the Handling parameter from the ISUP/QSIG transport mechanism. The protocol described here is identical in functionality to RFC 3204 with respect to SIP. Future versions of RFC 3204 should reference this document for the Handling parameter, as it is orthogonal to the tunneling of signaling.
注：このドキュメントは、RFC 3204 [5]を更新して、ハンドリングパラメーターをISUP/QSIGトランスポートメカニズムから分離します。ここで説明するプロトコルは、SIPに関してRFC 3204と機能が同一です。RFC 3204の将来のバージョンは、シグナリングのトンネルに直交するため、このドキュメントを処理パラメーターに参照する必要があります。
The Handling parameter is a Content-Disposition [6] parameter inserted by the sending agent to indicate to the content gateway whether to consider the marked body part critical.
処理パラメーターは、送信エージェントによって挿入されたコンテンツディスポジション[6]パラメーターで、マークされたボディの部分が重要であると考えるかどうかをコンテンツゲートウェイに示すパラメーターです。
A REQUIRED body part is one the sender requires the receiving system to deliver for him to consider the message delivered.
必要なボディの部分は、送信者が受信システムが配信されるメッセージを検討するために配信するように要求するものです。
An OPTIONAL body part is one the sender doesn't care whether the receiving system delivers it or not. A content gateway can silently delete such body parts if the receiving system cannot deliver the part.
オプションのボディパートは、送信者が受信システムがそれを配信するかどうかを気にしないものです。コンテンツゲートウェイは、受信システムが部品を配信できない場合、そのようなボディパーツを静かに削除できます。
The terms "entity" and "body part" have the meanings defined in [6].
「エンティティ」と「身体部分」という用語には、[6]で定義されている意味があります。
"Handling=REQUIRED" signifies that this body part is critical to the sender.
「処理=必須」は、この体の部分が送信者にとって重要であることを意味します。
If the content gateway cannot pass a body part marked REQUIRED, then the entire message has failed. In this case, the content gateway MUST take the appropriate failure action.
コンテンツゲートウェイが必要とされるボディパーツを通過できない場合、メッセージ全体が失敗しました。この場合、コンテンツゲートウェイは適切な障害アクションを実行する必要があります。
NOTE: We say "appropriate action", because the sender may have suppressed all notifications. In this case, the appropriate action is to silently discard the message. In addition, as a general MIME parameter, the MIME body part may not be in an Internet Mail message.
注：送信者がすべての通知を抑制した可能性があるため、「適切なアクション」と言います。この場合、適切なアクションは、メッセージを静かに破棄することです。さらに、一般的なMIMEパラメーターとして、MIMEボディの部分はインターネットメールメッセージに含まれていない可能性があります。
Moreover, in the SIP case, the appropriate notification is a status return code, not a delivery notification.
さらに、SIPの場合、適切な通知は配信通知ではなく、ステータスリターンコードです。
"Handling=OPTIONAL" signifies that the sender does not care about notification reports for this body part.
「処理=オプション」は、送信者がこの身体部分の通知レポートを気にしないことを意味します。
If the content gateway cannot pass a body part marked OPTIONAL, the receiving system may silently delete the body part. The receiving system MUST NOT return a delivery failure, unless parts marked REQUIRED have also failed.
コンテンツゲートウェイがオプションとマークされたボディパーツを通過できない場合、受信システムはボディパーツを静かに削除する場合があります。必要な部品も失敗していない限り、受信システムは配送の失敗を返してはなりません。
The default value for Handling for a given body part is REQUIRED. This enables the existing notification mechanisms to work for sending agents that do not know about the content notification entity. All body parts are critical, because they have the default marking of REQUIRED.
特定のボディパーツの処理のデフォルト値が必要です。これにより、既存の通知メカニズムは、コンテンツ通知エンティティについて知らないエージェントを送信するために機能します。必要なデフォルトのマーキングがあるため、すべての体の部分が重要です。
NOTE: In the case of Internet mail, critical content processing is a function of the content gateway and not the mail transfer agent (MTA) or user agent (UA). Often, the entity performing content gateway processing is the receiving UA. However, in this case the UA is acting as a content gateway. Thus the default action for any Content-Disposition [6]-compliant user agent to ignore unrecognized disposition parameters ensures that this mechanism is compatible with the Internet architecture.
注：インターネットメールの場合、重要なコンテンツ処理はコンテンツゲートウェイの関数であり、メール転送エージェント（MTA）またはユーザーエージェント（UA）ではありません。多くの場合、コンテンツゲートウェイ処理を実行するエンティティは受信UAです。ただし、この場合、UAはコンテンツゲートウェイとして機能しています。したがって、コンテンツ拡散[6] - 統合されたユーザーエージェントのデフォルトアクションは、認識されていない気質パラメーターを無視することにより、このメカニズムがインターネットアーキテクチャと互換性があることを保証します。
NOTE: This parameter is fully backwards compatible and works as expected for Internet mail and SIP.
注：このパラメーターは完全に後方互換性があり、インターネットメールとSIPに期待どおりに機能します。
NOTE: Some VPIMv2 implementations can receive arbitrary e-mail from the Internet. However, these systems are really acting in the capacity of an Internet Voice Mail system. In this case, one would expect the implementation to provide Internet Voice Mail semantics to Internet Voice Mail messages.
注：一部のVPIMV2実装は、インターネットから任意の電子メールを受信できます。ただし、これらのシステムは、インターネットボイスメールシステムの能力で実際に作用しています。この場合、インターネットボイスメールメッセージにインターネットボイスメールセマンティクスを実装することが期待されます。
The content gateway MUST treat unrecognized values as REQUIRED. This is to provide backward compatibility with future uses of the Content-Criticality entity.
コンテンツゲートウェイは、必要に応じて認識されていない値を扱う必要があります。これは、コンテンツクリティカリティエンティティの将来の使用との後方互換性を提供することです。
NOTE: A possible new value is IMPORTANT. An IMPORTANT body part is something the sender wants the receiver to get, but would not want the message rejected outright if the IMPORTANT body part fails, but they do want notification of the failure. However, as no implementations do IMPORTANT, it is not important to this version of this document.
注：可能な新しい値が重要です。重要な身体の部分は、送信者が受信者に取得したいものですが、重要な身体の部分が失敗した場合、メッセージを完全に拒否したくないが、失敗の通知を望んでいる。ただし、実装が重要ではないため、このドキュメントのこのバージョンにとって重要ではありません。
The format of the collected syntax is in accordance with the ABNF of [7]. Note that per RFC 2183 [6], the HANDLING Content-Disposition parameter is not case sensitive. In addition, the notification-type is not case sensitive.
収集された構文の形式は、[7]のABNFに準拠しています。RFC 2183 [6]によると、コンテンツ拡張パラメーターはケースに敏感ではないことに注意してください。さらに、通知タイプは症例に敏感ではありません。
"handling" "=" notification-type CRLF
「ハンドリング」 "="通知タイプCRLF
notification-type = "REQUIRED" / "OPTIONAL" /
other-handling / generic-param
other-handling = token
One obvious application of critical content is generating a (non-) delivery notification in the Internet mail environment. If the value of the field is OPTIONAL, the content gateway MUST NOT generate a notification. If the value of the field is REQUIRED, the content gateway MAY generate a notification, based on the normal notification request mechanisms. Normal notification request mechanisms include specifying the NOTIFY parameter to the SMTP RCPT command [8] and the Disposition-Notification-To header [9].
重要なコンテンツの明らかなアプリケーションの1つは、インターネットメール環境で（非）配信通知を生成することです。フィールドの値がオプションの場合、コンテンツゲートウェイは通知を生成してはなりません。フィールドの値が必要な場合、コンテンツゲートウェイは、通常の通知要求メカニズムに基づいて通知を生成する場合があります。通常の通知要求メカニズムには、SMTP RCPTコマンド[8]および気質解合ヘッダー[9]にNotifyパラメーターを指定することが含まれます。
In SIP, all requests have responses. These responses provide notification in the status code of the response. For the RFC 3204 case, a content gateway generates a 415 (Unsupported Media Type) response if the field is REQUIRED.
SIPでは、すべてのリクエストに応答があります。これらの応答は、応答のステータスコードで通知を提供します。RFC 3204の場合、コンテンツゲートウェイは、フィールドが必要な場合は415（サポートされていないメディアタイプ）応答を生成します。
If the sending system requests a notification, and a REQUIRED part fails, the content gateway MUST generate a notification for the whole message. Conversely, if the gateway cannot pass on a body part marked OPTIONAL, the gateway MUST NOT generate a notification.
送信システムが通知を要求し、必要な部分が失敗した場合、コンテンツゲートウェイはメッセージ全体の通知を生成する必要があります。逆に、ゲートウェイがオプションとマークされたボディパーツを通過できない場合、ゲートウェイは通知を生成してはなりません。
NOTE: This implies that the content gateway must examine the entire message to determine whether it needs to generate a notification. However, the content gateway need not examine the message if it knows it can store and forward all media types. Said differently, Internet e-mail MTAs or gateways can, by default, handle any arbitrary MIME-encapsulated type. Some voice mail systems, on the other hand, cannot store binary attachments at all, such as application/ms-word. The voice mail content gateway, in this example, would be scanning for non-renderable body parts in any event.
注：これは、コンテンツゲートウェイがメッセージ全体を調べて、通知を生成する必要があるかどうかを判断する必要があることを意味します。ただし、コンテンツゲートウェイは、すべてのメディアタイプを保存および転送できることを知っている場合、メッセージを調べる必要はありません。別の言い方をすれば、インターネットの電子メールMTAまたはゲートウェイは、デフォルトでは、任意のMIMEカプセル化されたタイプを処理できます。一方、一部のボイスメールシステムは、アプリケーション/MSワードなど、バイナリ添付ファイルをまったく保存できません。この例では、ボイスメールのコンテンツゲートウェイは、いずれにしてもレンダリング不可能なボディパーツをスキャンします。
The content gateway generates a delivery status notification (DSN) [9] if it operates as a gateway. The content gateway generates a Message Disposition Notification (MDN) [10] if it operates as a mail user agent. Section 6 describes the operating modes of a content gateway. In short, if there is a MTA that "delivers" the message to the content gateway for processing, the MTA takes responsibility for DSN processing. In this case, the only option available to the content gateway is to generate MDNs. If the content gateway operates as a MTA, then it generates DSNs. DSN generation is the preferred option.
コンテンツゲートウェイは、ゲートウェイとして動作する場合、配信ステータス通知（DSN）[9]を生成します。コンテンツゲートウェイは、メールユーザーエージェントとして動作する場合、メッセージ処分通知（MDN）[10]を生成します。セクション6では、コンテンツゲートウェイの動作モードについて説明します。要するに、処理のためにコンテンツゲートウェイにメッセージを「配信」するMTAがある場合、MTAはDSN処理の責任を負います。この場合、コンテンツゲートウェイで利用可能な唯一のオプションは、MDNを生成することです。コンテンツゲートウェイがMTAとして動作する場合、DSNSを生成します。DSN生成が好ましいオプションです。
If the content gateway is part of a SIP endpoint, then it generates the appropriate success or error response code.
コンテンツゲートウェイがSIPエンドポイントの一部である場合、適切な成功またはエラー応答コードが生成されます。
The following table summarizes the actions expected of a conforming content gateway.
次の表は、適合コンテンツゲートウェイに期待されるアクションをまとめたものです。
NOTE: This section is normative: it suggests what a content gateway should put into the DSN or MDN.
注：このセクションは規範的です。コンテンツゲートウェイがDSNまたはMDNにどのようなものを配置するかを示唆しています。
NOTE: In the case of SIP, this section is informative. See RFC 3204 for the normative set of actions on failure.
注：SIPの場合、このセクションは有益です。失敗時の規範的な一連のアクションについては、RFC 3204を参照してください。
Table 1 - Expected Actions
表1-予想されるアクション
+--------------------------------------+
| Sending UA Has Marked Body Part |
|---------------------+----------------|
| REQUIRED | OPTIONAL |
+--------------------+---------------------+----------------+
| Body Part is | | |
| Deliverable | Appropriate Action | ignore |
+--------------------+---------------------+----------------+
| Body Part is | | |
| Undeliverable | Fail Entire Message | ignore |
+--------------------+--------------------------------------+
The "Appropriate Action" is the action the content gateway would take given the context of execution. For example, if a sender requests return receipt and the receiver reads a HANDLING body part, the receiving UA must generate the appropriate MDN (following the rules for MDN). Likewise, if the content gateway cannot deliver the body part and the body part is critical, the content gateway generates the appropriate DSN or MDN.
「適切なアクション」は、実行のコンテキストを考慮して、コンテンツゲートウェイが取るアクションです。たとえば、送信者が返された領収書を要求し、受信者がハンドリング本体の部分を読み取る場合、受信UAは適切なMDNを生成する必要があります（MDNの規則に従ってください）。同様に、コンテンツゲートウェイが本体部分を配信できず、ボディの部分が重要である場合、コンテンツゲートウェイは適切なDSNまたはMDNを生成します。
"Optional" means the content gateway ignores the disposition of the body part. The content gateway treats the message as if the body part was not present in the message.
「オプション」とは、コンテンツゲートウェイが身体部分の処分を無視することを意味します。コンテンツゲートウェイは、メッセージをメッセージに存在していないかのようにメッセージを扱います。
RFC 1847 [11] describes how to apply digital signatures to a MIME body part. In brief, a multipart/signed body part encapsulates the body part of interest, or the "content object", in a MIME body part and the control information needed to verify the object, or the "protocol" in the lexicon of RFC 1847, in a second MIME body part. Here is an example taken from RFC 1847.
RFC 1847 [11]は、MIMEの身体部分にデジタル署名を適用する方法について説明しています。簡単に言えば、マルチパート/署名されたボディパーツは、MIMEボディの部分と、オブジェクトの検証に必要なコントロール情報、またはRFC 1847のレキシコンの「プロトコル」をカプセル化します。2番目のmime体の部分。RFC 1847から撮影した例を以下に示します。
Content-Type: multipart/signed; protocol="TYPE/STYPE";
micalg="MICALG"; boundary="Signed Boundary"
--Signed Boundary
Content-Type: text/plain; charset="us-ascii"
This is some text to be signed although it could be any type of data, labeled accordingly, of course.
これは、もちろん、それに応じてラベル付けされたあらゆるタイプのデータである可能性がありますが、署名されるテキストです。
--Signed Boundary Content-Type: TYPE/STYPE
- 署名された境界コンテンツタイプ：Type/Stype
CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
プロトコルの制御情報「Type/Stype」はここにあります
--Signed Boundary--
- 署名境界 -
Figure 1 - Signed Content MIME Type
図1-署名されたコンテンツMIMEタイプ
There are three places where one may place the criticality indicator for a multipart/signed body part. One could mark the multipart/signed object, the content object, the control object, or any combination of the three.
マルチパート/署名されたボディパーツのクリティカリティインジケーターを配置できる3つの場所があります。マルチパート/署名されたオブジェクト、コンテンツオブジェクト、制御オブジェクト、または3つの組み合わせをマークすることができます。
The disposition of REQUIRED body parts follow the guidelines found in RFC 2480 [12].
必要な身体部分の処分は、RFC 2480 [12]にあるガイドラインに従います。
A critical content indicator on a multipart/signed body part means the sending party requires true end-to-end signature verification. Thus the gateway needs to pass the enclosure intact. If the system or network of lesser capability cannot do signature verification and the signed enclosure is REQUIRED, the gateway MUST reject the message.
マルチパート/署名されたボディパーツの重要なコンテンツインジケーターは、送信者が真のエンドツーエンドの署名検証を必要とすることを意味します。したがって、ゲートウェイはエンクロージャーをそのまま渡す必要があります。より低い機能のシステムまたはネットワークが署名検証を行うことができず、署名されたエンクロージャーが必要である場合、ゲートウェイはメッセージを拒否する必要があります。
A critical content indicator on a signature means that either the receiving endpoint must be able to do signature verification, or the gateway needs to verify the signature before forwarding the message. If the content does not pass verification, the gateway MUST reject the message.
署名の重要なコンテンツインジケーターは、受信エンドポイントが署名検証を行うことができなければならないか、ゲートウェイがメッセージを転送する前に署名を検証する必要があることを意味します。コンテンツが検証に合格しない場合、ゲートウェイはメッセージを拒否する必要があります。
A critical content indicator on the enclosed material specifies whether that material is critical to the message as a whole. If the signature is marked OPTIONAL and the enclosed material is marked REQUIRED, the gateway MAY strip out the signature information if the system or network of lesser capability cannot do signature verification. However, if possible, we STRONGLY RECOMMEND the gateway do signature verification and indicate tampering to the recipient.
囲まれた資料の重要なコンテンツインジケーターは、その資料がメッセージ全体にとって重要であるかどうかを指定します。署名がオプションとマークされ、囲まれた資料が必要とマークされている場合、より低い機能のシステムまたはネットワークが署名検証を行うことができない場合、ゲートウェイは署名情報を削除する場合があります。ただし、可能であれば、Gatewayは署名検証を行い、受信者への改ざんを示すことを強くお勧めします。
RFC 1847 [11] describes how to encrypt a MIME body part. In brief, a multipart/encrypted body part encapsulates the control information ("protocol" in the lexicon of RFC 1847) for the encrypted object and the second containing the encrypted data (application/octet-stream). Here is an example taken from RFC 1847.
RFC 1847 [11]は、mime体の部分を暗号化する方法について説明しています。簡単に言えば、マルチパート/暗号化されたボディパーツは、暗号化されたオブジェクトの制御情報（RFC 1847の辞書の「プロトコル」）と、暗号化されたデータ（アプリケーション/オクテットストリーム）を含む2番目のコントロール情報（「プロトコル」）をカプセル化します。RFC 1847から撮影した例を以下に示します。
Content-Type: multipart/encrypted; protocol="TYPE/STYPE";
boundary="Encrypted Boundary"
--Encrypted Boundary Content-Type: TYPE/STYPE
- 暗号化された境界コンテンツタイプ：Type/Stype
CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
プロトコルの制御情報「Type/Stype」はここにあります
--Encrypted Boundary Content-Type: application/octet-stream
- 暗号化された境界コンテンツタイプ：アプリケーション/オクテットストリーム
Content-Type: text/plain; charset="us-ascii" All of this indented text, including the indented headers, would be unreadable since it would have been encrypted by the protocol "TYPE/STYPE". Also, this encrypted data could be any type of data, labeled accordingly, of course.
コンテンツタイプ：テキスト/プレーン;charset = "us-ascii"インデントヘッダーを含むこのインデントされたテキストはすべて、プロトコル「タイプ/スタイプ」によって暗号化されていたため、読めません。また、この暗号化されたデータは、もちろん、それに応じてラベル付けされたあらゆる種類のデータになる可能性があります。
--Encrypted Boundary--
- 暗号化された境界 -
One may sensibly place a criticality indicator on the encrypted enclosure (multipart/encrypted) body part. If the endpoint can decrypt the message, then the gateway passes the body part in its entirety.
暗号化されたエンクロージャー（MultiPart/暗号化）ボディパーツに批判的な指標を賢明に配置することができます。エンドポイントがメッセージを解読できる場合、ゲートウェイは体全体を渡します。
If one marks the control object REQUIRED, then the sending UA requires end-to-end encryption. If the endpoint cannot decrypt the message, then the gateway MUST reject the message.
必要な制御オブジェクトをマークする場合、送信UAにはエンドツーエンドの暗号化が必要です。エンドポイントがメッセージを解読できない場合、ゲートウェイはメッセージを拒否する必要があります。
If the control object is OPTIONAL, and the endpoint cannot decrypt the message, and the gateway can decrypt the message, then the gateway MAY decrypt the message and forward the cleartext message. The sending user has explicitly given permission for the gateway to decrypt the message by marking the control object OPTIONAL. Recall that the default indication for MIME body parts is REQUIRED. Thus if the user takes no explicit action, the content gateway will assume the user wished end-to-end encryption.
コントロールオブジェクトがオプションであり、エンドポイントがメッセージを解読できず、ゲートウェイがメッセージを解読できない場合、ゲートウェイはメッセージを復号化してクリアテキストメッセージを転送できます。送信ユーザーは、コントロールオブジェクトをオプションにマークすることにより、メッセージを復号化するゲートウェイの許可を明示的に与えています。MIMEボディ部分のデフォルトの表示が必要であることを思い出してください。したがって、ユーザーが明示的なアクションを取得しない場合、コンテンツゲートウェイはユーザーがエンドツーエンドの暗号化を望んでいると想定します。
Marking the encrypted content, without marking the encrypted enclosure, is problematic. This is because the gateway has to decrypt the encrypted data to retrieve the header. However, it is unlikely for the gateway to have the capability (e.g., keys) to decrypt the encrypted data. If a sending UA wishes to mark encrypted data as not REQUIRED, the sending UA MUST mark the encrypted content as not REQUIRED. Clearly, if the sending UA marks the encrypted content as REQUIRED, the gateway will apply the REQUIRED processing rules. Moreover, if the sending UA does not mark the encrypted content as REQUIRED, the gateway, unless it can decrypt the data, will treat the encrypted content as REQUIRED. This occurs because gateways always treat unmarked content as REQUIRED (see Section 3.3).
暗号化されたエンクロージャーをマークすることなく、暗号化されたコンテンツをマークすることに問題があります。これは、ゲートウェイが暗号化されたデータを復号化してヘッダーを取得する必要があるためです。ただし、ゲートウェイが暗号化されたデータを復号化する機能（キーなど）を持つことはほとんどありません。送信UAが暗号化されたデータを不要であるとマークしたい場合、送信UAは暗号化されたコンテンツを必要としないようにマークする必要があります。明らかに、送信が必要に応じて暗号化されたコンテンツをマークする場合、ゲートウェイは必要な処理ルールを適用します。さらに、送信UAが必要に応じて暗号化されたコンテンツをマークしない場合、ゲートウェイは、データを解読できない限り、必要に応じて暗号化されたコンテンツを扱います。これは、ゲートウェイが必要に応じて常にマークのないコンテンツを扱うために発生します（セクション3.3を参照）。
The critical content indication, in itself, does not guarantee any notification. Notification follows the rules described in [3], [8], and [9].
重要なコンテンツの表示自体は、通知を保証しません。通知は、[3]、[8]、および[9]で説明されている規則に従います。
NOTE: The content of actual DSNs or MDNs are beyond the scope of this document. This document only specifies how to mark a critical body part. On the other hand, we do envision sensible DSN and MDN contents. For example, DSNs should include the appropriate failure code as enumerated in [13]. Likewise, MDNs should include the failure code in the MDN "Failure:" field.
注：実際のDSNまたはMDNの内容は、このドキュメントの範囲を超えています。このドキュメントは、重要な本体部分をマークする方法のみを指定します。一方、賢明なDSNおよびMDNの内容を想像しています。たとえば、DSNSには[13]で列挙されている適切な障害コードを含める必要があります。同様に、MDNSには、MDN "Faily："フィールドに障害コードを含める必要があります。
If the receiving system is to generate a notification based on its inability to render or store the media type, the notification should use the status code 5.6.1, "Media not supported", from [10].
受信システムがメディアタイプをレンダリングまたは保存できないことに基づいて通知を生成することである場合、通知は[10]からステータスコード5.6.1「サポートされていない」を使用する必要があります。
For the SIP case, all requests have notification provided by the status response message. Per RFC 3204, a content gateway generates a 415 (Unsupported Media Type) response.
SIPケースの場合、すべてのリクエストには、ステータス応答メッセージによって提供された通知があります。RFC 3204ごとに、コンテンツゲートウェイは415（サポートされていないメディアタイプ）応答を生成します。
This section is informative.
このセクションは有益です。
The need for a critical content identification mechanism comes about because of the internetworking of Internet mail systems with messaging systems that do not fulfill all of the semantics of Internet mail. Such legacy systems have a limited ability to render or store all parts of a given message. This document will use the case of an Internet mail system exchanging electronic messages with a legacy voice messaging system for illustrative purposes.
重要なコンテンツ識別メカニズムの必要性は、インターネットメールのすべてのセマンティクスを満たさないメッセージングシステムを備えたインターネットメールシステムのインターネットワーキングのために生じています。このようなレガシーシステムには、特定のメッセージのすべての部分をレンダリングまたは保存する能力が限られています。このドキュメントでは、電子メッセージをレガシー音声メッセージングシステムと交換するインターネットメールシステムのケースを使用します。
Electronic mail has historically been text-centric. Extensions such as MIME [14] enable the user agents to send and receive multi-part, multimedia messages. Popular multimedia data types include binary word processing documents, binary business presentation graphics, voice, and video.
電子メールは歴史的にテキスト中心でした。MIME [14]などの拡張機能は、ユーザーエージェントがマルチパートのマルチメディアメッセージを送信および受信できるようにします。人気のあるマルチメディアデータ型には、バイナリワードプロセッシングドキュメント、バイナリビジネスプレゼンテーショングラフィック、音声、ビデオが含まれます。
Voice mail has historically been audio-centric. Many voice-messaging systems only render voice. Extensions such as fax enable the voice mail system to send and receive fax images as well as create multi-part voice and fax messages. A few voice mail systems can render text using text-to-speech or text-to-fax technology. Although theoretically possible, none can today render video.
ボイスメールは歴史的にオーディオ中心でした。多くの音声メッセージシステムは音声のみをレンダリングします。FAXなどの拡張機能は、ボイスメールシステムがファックス画像を送信および受信したり、マルチパートの音声とファックスメッセージを作成したりできるようにします。いくつかのボイスメールシステムは、テキストからスピーチまたはテキスト間テクノロジーを使用してテキストをレンダリングできます。理論的には可能ですが、今日ビデオをレンダリングすることはできません。
An important aspect of the interchange between voice messaging services and desktop e-mail client applications is that the rendering capability of the voice-messaging platform is often much less than the rendering capability of a desktop e-mail client. In the e-mail case, the sender has the expectation that the recipient receives all components of a multimedia message. This is so even if the recipient cannot render all body parts. In most cases, the recipient can either find the appropriate rendering tool or tell the sender that she cannot read the particular attachment.
音声メッセージングサービスとデスクトップ電子メールクライアントアプリケーションの間のインターチェンジの重要な側面は、ボイスメスングプラットフォームのレンダリング機能がデスクトップ電子メールクライアントのレンダリング機能よりもはるかに少ないことです。電子メールの場合、送信者は、受信者がマルチメディアメッセージのすべてのコンポーネントを受信することを期待しています。これは、受信者がすべての体の部分をレンダリングできない場合でもそうです。ほとんどの場合、受信者は適切なレンダリングツールを見つけるか、送信者に特定の添付ファイルを読むことができないことを伝えることができます。
This is an important issue. By definition, a MIME-enabled user agent, conforming to [15], will present or make available all of the body parts to the recipient. However, a voice mail system may not be capable of storing non-voice objects. Moreover, the voice mail system may not be capable of notifying the recipient that there were undeliverable message parts.
これは重要な問題です。定義上、[15]に準拠したMIME対応ユーザーエージェントは、レシピエントにすべての身体部分を提示または利用できるようにします。ただし、ボイスメールシステムは、非声オブジェクトを保存できない場合があります。さらに、ボイスメールシステムは、配信不可能なメッセージパーツがあることを受信者に通知することができない場合があります。
The inability of the receiving system to render a body part is usually a permanent failure. Retransmission of the message will not improve the likelihood of a future successful delivery. Contrast this with the case with normal data delivery. Traditional message failures, such as a garbled message or disabled link will benefit from retransmission.
受信システムが身体部分をレンダリングできないことは、通常、永続的な障害です。メッセージの再送信は、将来の成功した配信の可能性を改善しません。これを通常のデータ配信とは対照的です。文字化けのメッセージや無効化リンクなどの従来のメッセージの障害は、再送信の恩恵を受けるでしょう。
This situation is fundamentally different from normal Internet mail. In the Internet mail case, either the system delivered the message, or it didn't. There is no concept of a system partially delivering a message.
この状況は、通常のインターネットメールと根本的に異なります。インターネットメールケースでは、システムがメッセージを配信するか、そうではありませんでした。部分的にメッセージを配信するシステムの概念はありません。
In addition, there are many situations where the sender would not mind if the system did not deliver non-critical parts of a message. For example, the sender's user agent may add body parts to a message unbeknownst to the sender. If the receiving system rejected the message because it could not render a hidden body part, the sender would be understandably confused and upset.
さらに、システムがメッセージの非批判的な部分を配信しなかった場合、送信者が気にしない多くの状況があります。たとえば、送信者のユーザーエージェントは、送信者に知られていないメッセージにボディパーツを追加する場合があります。受信システムが隠された身体の部分をレンダリングできなかったためにメッセージを拒否した場合、送信者は当然のことながら混乱して動揺します。
Thus, there is a need for a method of indicating to a Mail Transfer Agent (MTA) or User Agent (UA) that the sender considers parts of a message to be critical. From the sender's perspective, he would not consider the message delivered if the system did not deliver the critical parts.
したがって、送信者がメッセージの一部が重要であると考えていることを、メール転送エージェント（MTA）またはユーザーエージェント（UA）に示す方法が必要です。送信者の観点から、システムが重要な部分を配信しなかった場合、彼はメッセージが配信されたメッセージを考慮しません。
One method of indicating critical content of a message is to define a profile. The profile defines rules for silently deleting mail body parts based on knowledge of the UA capabilities. Citing the example above, a voice profile can easily declare that MTAs or UAs can silently delete TNEF data and yet consider the message successfully delivered. This is, in fact, the approach taken by VPIMv2 [16].
メッセージの重要なコンテンツを示す1つの方法は、プロファイルを定義することです。このプロファイルは、UA機能の知識に基づいて、電子機関の部分を静かに削除するためのルールを定義します。上記の例を引用すると、音声プロファイルは、MTAまたはUASがTNEFデータを静かに削除できることを簡単に宣言できますが、メッセージが正常に配信されると考えることができます。実際、これはVPIMV2によって採用されたアプローチです[16]。
Since one aspect of the issue is deciding when to notify the sender that the system cannot deliver part of a message, one could use a partial non-delivery notification mechanism to indicate a problem with delivering a given body part. However, this requires the user request a delivery notification. In addition, the sender may not be aware of parts added by the sending user agent. In this case, a failure notice would mystify the sender.
問題の1つの側面は、システムがメッセージの一部を配信できないことを送信者にいつ通知するかを決定することであるため、部分的な非配信通知メカニズムを使用して、特定の身体部分の配信に関する問題を示すことができます。ただし、これにはユーザーが配信通知を要求する必要があります。さらに、送信者は、送信ユーザーエージェントによって追加された部品を認識していない場合があります。この場合、失敗通知は送信者を神秘化します。
A straightforward alternative implementation method for marking a body part critical is to use a Critical-Content MIME entity. This has the benefit that criticality is meta information for the body part. However, IMAP servers in particular would need to either put Critical-Content into the BODYSTRUCTURE method or create a new method to retrieve arbitrary MIME entities. Given the experience of trying to get Content-Location accepted by IMAP vendors, we chose not to go that route.
重要な部分をマークするための簡単な代替実装方法は、重要なコンテンツMIMEエンティティを使用することです。これには、重要性が身体部分のメタ情報であるという利点があります。ただし、特にIMAPサーバーは、ボディ構造法にクリティカルコンテンツを入力するか、任意のMIMEエンティティを取得する新しい方法を作成する必要があります。IMAPベンダーがコンテンツロケーションを受け入れようとした経験を考えると、そのルートには行かないことを選択しました。
What we need is a way of letting the sender indicate what body parts he considers to be critical. The mechanism must not burden the sender with failure notifications for non-critical body parts. The mechanism must conform to the general notification status request mechanism for positive or negative notification. When requested, the mechanism must indicate to the sender when a receiving system cannot deliver a critical body part.
私たちに必要なのは、送信者に自分がどの体の部分が批判的であると考えるかを示す方法です。メカニズムは、非批判的な身体部分の障害通知を送信者に負担してはなりません。メカニズムは、正または負の通知のために一般通知ステータス要求メカニズムに準拠する必要があります。要求された場合、メカニズムは、受信システムが重要な身体部分を提供できない場合、送信者に示す必要があります。
This section is informative.
このセクションは有益です。
In this section, we use the definition found in RFC 2156 [17] for the term "gateway."
このセクションでは、「ゲートウェイ」という用語でRFC 2156 [17]にある定義を使用します。
We do not strictly use the definition found in RFC 2821 [18] for the term "gateway." In particular, RFC 2821 is discussing a gateway that should not examine the message itself. An RFC 2821 gateway is a transport gateway, that mostly deals with transformations of the SMTP information.
「ゲートウェイ」という用語について、RFC 2821 [18]にある定義を厳密に使用しません。特に、RFC 2821は、メッセージ自体を調べてはならないゲートウェイについて議論しています。RFC 2821ゲートウェイはトランスポートゲートウェイであり、主にSMTP情報の変換を扱っています。
A content gateway is a gateway that connects a first network to a second network. The second network often has lesser capability than the first network. The canonical topology follows. "[MTA]", with square brackets, signifies an optional component.
コンテンツゲートウェイは、最初のネットワークを2番目のネットワークに接続するゲートウェイです。2番目のネットワークは、多くの場合、最初のネットワークよりも能力が低いことがよくあります。標準的なトポロジーが続きます。「[MTA]」は、角括弧付きで、オプションのコンポーネントを意味します。
+---------+
+---------+ +-----+ | | +-------+ +-----------+
| Sending |=...=|[MTA]|===| Content |=...=| [MTA] |===| Receiving |
| UA | +-----+ | Gateway | +-------+ | UA |
+---------+ | | +-----------+
+---------+
First Network Second Network
Figure 2 - Content Gateway Topology
図2-コンテンツゲートウェイトポロジ
The content gateway can be the last hop before the receiving MTA. The content gateway can be between networks, and thus not the last hop before the receiving MTA. The content gateway can be the first MTA the sending UA contacts. Finally, the content gateway can be an integrated component of the receiving MTA.
コンテンツゲートウェイは、受信MTAの前の最後のホップになります。コンテンツゲートウェイはネットワーク間にある可能性があるため、受信MTAの前の最後のホップではありません。コンテンツゲートウェイは、送信UA連絡先の最初のMTAになることができます。最後に、コンテンツゲートウェイは、受信MTAの統合コンポーネントにすることができます。
For the SIP case, consider each MTA as a SIP Proxy, the Sending UA as a SIP User Agent Client, and the Receiving UA as a SIP User Agent Server.
SIPケースについては、各MTAをSIPプロキシ、SIPユーザーエージェントクライアントとして送信するUA、およびSIPユーザーエージェントサーバーとしての受信UAと考えてください。
In this situation, the receiving user agent is integrated with the content gateway. The integrated content gateway knows the capabilities of the user agent. The topology is as follows.
この状況では、受信ユーザーエージェントはコンテンツゲートウェイと統合されています。統合コンテンツゲートウェイは、ユーザーエージェントの機能を知っています。トポロジーは次のとおりです。
+---------------------+
+---------+ +-----+ | : |
| Sending |=...=|[MTA]|===| Content : Receiving |
| UA | +-----+ | Gateway : UA |
+---------+ | : |
+---------------------+
First Network Second Network
Figure 3 - Integrated Content Gateway
図3-統合コンテンツゲートウェイ
The processing of ISUP and QSIG objects, as described in [5], is an example of an integrated gateway.
[5]に記載されているように、ISUPおよびQSIGオブジェクトの処理は、統合されたゲートウェイの例です。
A degenerate case, although one that does occur, is where the content gateway sits behind the final MTA. This happens when one implements the content gateway as a post-processing step to a normal delivery. For example, one could configure a mail handling system to deliver the message to a queue or directory, where the content gateway process picks up the message. If there were any directives for DSN processing, the delivering MTA would execute them. For example, the message could have requested notification on successful delivery. The delivering MTA, having delivered the message to the queue, would consider the message delivered and thus notify the sender of such. However, the content gateway process could then discover that the receiving UA cannot render the message. In this case, the content gateway generates a NDN, as it is the only option available.
縮退したケースは、発生するものですが、コンテンツゲートウェイが最終的なMTAの後ろにある場所です。これは、通常の配信への後処理ステップとしてコンテンツゲートウェイを実装するときに発生します。たとえば、コンテンツゲートウェイプロセスがメッセージを選択するキューまたはディレクトリにメッセージを配信するようにメール処理システムを構成できます。DSN処理の指令がある場合、MTAを配信すると実行されます。たとえば、メッセージは配信の成功に関する通知を要求できた可能性があります。メッセージをキューに配信したMTAを配信すると、メッセージが配信されたメッセージを検討し、そのような送信者に通知します。ただし、コンテンツゲートウェイプロセスは、受信UAがメッセージをレンダリングできないことを発見する可能性があります。この場合、コンテンツゲートウェイは、利用可能な唯一のオプションであるため、NDNを生成します。
Delivered
| +---------+
+---------+ +-----+ v | | +-----------+
| Sending |=...=| MTA |--> File -->| Content |=...=| Receiving |
| UA | +-----+ | Gateway | | UA |
+---------+ | | +-----------+
+---------+
First Network Second Network
Figure 4 - Disaggregated Delivery Network
図4-分解された配信ネットワーク
DSN requires ESMTP. If MTAs in the path from the sending UA to the receiving UA do not support ESMTP, then that MTA will reject the DSN request. In addition, the message will default to notification on delay or failure. While not ideal, the sender will know that DSN is not available, and that critical content that fails will get notification.
DSNにはESMTPが必要です。送信UAから受信UAへのパス内のMTAがESMTPをサポートしていない場合、そのMTAはDSN要求を拒否します。さらに、メッセージはデフォルトで遅延または障害に関する通知になります。理想的ではありませんが、送信者はDSNが利用できないことを知っており、失敗する重要なコンテンツは通知を受け取ります。
As is true for all Content-Disposition parameters, handling is only in effect for the selected alternative. If the selected alternative has the critical content indicator, then the entire alternative takes on the criticality indicated. That is, if the alternative selected has HANDLING=OPTIONAL, then the content gateway MUST NOT generate any delivery notifications.
すべてのコンテンツディスポジションパラメーターに当てはまるように、選択した代替案では取り扱いは有効です。選択された代替に重要なコンテンツインジケーターがある場合、代替案全体が示された重要性を引き受けます。つまり、選択された代替が処理=オプションの場合、コンテンツゲートウェイは配信通知を生成してはなりません。
NOTE: This statement explicitly shows that HANDLING overrides the DSN and MDN request mechanisms.
注：このステートメントは、処理がDSNおよびMDN要求メカニズムをオーバーライドすることを明示的に示しています。
It is unlikely for a selected alternative to fail, as the content gateway presumably picks the alternative specifically because it can render it.
コンテンツゲートウェイが特にレンダリングできるために特に代替手段を選択するため、選択された選択肢が失敗する可能性は低いです。
If the selected alternative is a message/rfc822 that encloses a multipart MIME message or the selected alternative is itself a multipart MIME type, the individual top-level body parts follow the HANDLING mechanism described in this document.
選択した代替案がマルチパートMIMEメッセージを囲むメッセージ/RFC822である場合、または選択された代替案自体がマルチパートMIMEタイプである場合、個々のトップレベルのボディパーツは、このドキュメントで説明されている処理メカニズムに従います。
NOTE: This means that a forwarded message's criticality will not affect the forwarding agent's intentions.
注：これは、転送されたメッセージの重要性が転送エージェントの意図に影響しないことを意味します。
Criticality fits in rather well with the multipart/related construction. For example, consider a multipart/related message consisting of a Macintosh data fork and a Macintosh resource fork. For a Microsoft Word document, the data fork is likely to be critical. The receiving system can safely ignore the resource fork.
臨界性は、マルチパート/関連構造にかなりよく適合しています。たとえば、MacintoshデータフォークとMacintoshリソースフォークで構成されるマルチパート/関連メッセージを検討してください。Microsoft Wordドキュメントの場合、データフォークが重要である可能性があります。受信システムは、リソースフォークを安全に無視できます。
Criticality only affects the outermost level of the message or, in the case of multipart/alternative, the outermost level of the selected alternative. Specifically, the receiving system ignores criticality indicators in embedded body parts. This avoids the situation of a forwarded message triggering or suppressing undesired reporting. This simply implements the procedures described in [6].
臨界性は、メッセージの最も外側のレベル、またはマルチパート/代替の場合にのみ、選択された代替の最も外側のレベルに影響します。具体的には、受信システムは、埋め込まれた身体部分の重要性指標を無視します。これにより、転送されたメッセージが望ましくないレポートのトリガーまたは抑制の状況が回避されます。これは、[6]に記載されている手順を単純に実装します。
See Section 6.
セクション6を参照してください。
See Section 7.
セクション7を参照してください。
This section is an informative part of the definition of Criticality. We hope it helps implementers understand the mechanics of the Handling mechanism.
このセクションは、臨界性の定義の有益な部分です。実装者が取り扱いメカニズムのメカニズムを理解するのに役立つことを願っています。
We will examine two cases. They are how a content gateway processes a message and how a disaggregated content gateway processes a message.
2つのケースを調べます。それらは、コンテンツゲートウェイがメッセージをどのように処理するか、および分解されたコンテンツゲートウェイがメッセージをどのように処理するかです。
Content gateways examine the contents of a message from a first network before the gateway forwards the message to a second network. For the purposes of this example, we assume the second network has less capability than the first network. In particular, we expect there will be certain message body types that the gateway cannot pass onto the second network.
コンテンツゲートウェイゲートウェイがメッセージを2番目のネットワークに転送する前に、最初のネットワークからのメッセージのコンテンツを調べます。この例の目的のために、2番目のネットワークが最初のネットワークよりも能力が低いと仮定します。特に、ゲートウェイが2番目のネットワークに渡すことができない特定のメッセージ本文があると予想されます。
Consider a gateway between the Internet and a text-only short message service. A message comes through the gateway containing a text part and a tnef part. The sender marks the text part REQUIRED. The gateway, knowing the capability of the short message service, silently deletes the non-critical, tnef part, passing the critical content to the short message service network. Any subsequent notifications, such as failure notices or delivery notices, follow the normal rules for notification.
インターネットとテキストのみの短いメッセージサービスの間のゲートウェイを検討してください。メッセージは、テキストパーツとTNEFパーツを含むゲートウェイを介して行われます。送信者は、必要なテキスト部分をマークします。Gatewayは、短いメッセージサービスの機能を知っており、非批判的でないTNEF部分を静かに削除し、重要なコンテンツを短いメッセージサービスネットワークに渡します。失敗通知や配送通知などの後続の通知は、通知のための通常の規則に従ってください。
Note the gateway, by silently deleting non-critical content, may affect proprietary message correlation schemes. One can envision the sending UA inserting a body part for tracking purposes. By deleting non-critical content, the content gateway will break such a scheme. If a sending UA understands how to mark critical content, it should use Internet standard mechanisms for tracking messages, such as Message-ID [19].
注意して非批判的なコンテンツを静かに削除することにより、ゲートウェイは独自のメッセージ相関スキームに影響を与える可能性があります。追跡目的で身体の部分を挿入するuaを送信することを想定することができます。非クリティカルなコンテンツを削除することにより、コンテンツゲートウェイはそのようなスキームを破ります。送信UAが重要なコンテンツをマークする方法を理解している場合、メッセージ-ID [19]などのメッセージを追跡するためにインターネット標準メカニズムを使用する必要があります。
What if no body parts have critical content indicators? In this case, the entire message is critical. Thus, when the gateway sees the tnef part, it will reject the entire message, generating a DSN with a status code 5.6.1, "Media not supported".
体の部分が重要なコンテンツインジケーターがない場合はどうなりますか？この場合、メッセージ全体が重要です。したがって、ゲートウェイがTNEF部分を見ると、メッセージ全体を拒否し、ステータスコード5.6.1「メディアはサポートされていない」でDSNを生成します。
Likewise, consider a three part message with a text annotation (part 1) to a voice message (part 2) with a vCard [20] (part 3). The sender marks the first two parts REQUIRED. Now, let us assume the receiving MTA (gateway) is a voice mail only system, without even the capability to store text. In this case, the gateway, acting as the receiving MTA, will reject the message, generating a DSN with the status code 5.6.1, "Media not supported".
同様に、VCARD [20]（パート3）を使用して、音声メッセージ（パート2）にテキスト注釈（パート1）を備えた3つの部分メッセージを検討してください。送信者は、必要な最初の2つの部分をマークします。次に、受信MTA（Gateway）は、テキストを保存する機能さえないボイスメールのみのシステムであると仮定します。この場合、受信MTAとして機能するゲートウェイはメッセージを拒否し、ステータスコード5.6.1「メディアはサポートされていない」でDSNを生成します。
For this example, we will examine the processing of a three-part message. The first part is a text annotation of the second part, an audio message. The third part is the sender's vCard. The sender marks the first and second parts REQUIRED. In addition, the sender marks the message for read receipt.
この例では、3部構成のメッセージの処理を調べます。最初の部分は、2番目の部分のテキスト注釈、オーディオメッセージです。3番目の部分は、送信者のVCardです。送信者は、必要な最初と2番目のパーツをマークします。さらに、送信者は読み取り領収書のメッセージをマークします。
For the purposes of example, the telephone user interface (TUI) does not perform text-to-speech conversion. A TUI is a mail user agent (UA) that uses DTMF touch-tone digits for input and audio for output (display).
例の目的のために、電話ユーザーインターフェイス（TUI）はテキストからスピーチへの変換を実行しません。TUIは、出力に入力にDTMFタッチトーンディジットとオーディオ（ディスプレイ）を使用するメールユーザーエージェント（UA）です。
The TUI is unable to render the first part of the message, the text part. In addition, it is unable to render the third part of the message, the vCard part. Since the sender did not mark the third part of the message REQUIRED, the system ignores the failure of the TUI to render the third part of the message. However, since the sender did mark the first part REQUIRED, and the TUI is unable to render text, the message fails.
TUIは、メッセージの最初の部分であるテキスト部分をレンダリングできません。さらに、メッセージの3番目の部分であるVCard部分をレンダリングすることはできません。送信者は必要なメッセージの3番目の部分をマークしなかったため、システムはTUIがメッセージの3番目の部分をレンダリングできないことを無視します。ただし、送信者は必要な最初の部分をマークし、TUIがテキストをレンダリングできないため、メッセージは失敗します。
What happens next is implementation dependent. If the TUI is part of a unified messaging system, a reasonable action is to hold the message for the user. The user can access the message at a later time from a terminal that can render all of the critical body parts. It would be reasonable for the TUI to notify the user about the undeliverable body part.
次に起こるのは、実装依存です。TUIが統一されたメッセージングシステムの一部である場合、合理的なアクションはユーザーへのメッセージを保持することです。ユーザーは、すべての重要な身体部分をレンダリングできる端末から後でメッセージにアクセスできます。TUIがユーザーに配信不可能なボディの部分について通知することは合理的です。
If the TUI is part of a voice messaging system, or if the user does not subscribe to a text-to-speech service, a reasonable action is for the TUI to return a MDN with the disposition "failed" and the failure modifier "5.6.1 (Media not supported)".
TUIが音声メッセージングシステムの一部である場合、またはユーザーがテキストからスピーチへのサービスに登録していない場合、TUIが気質「失敗」と故障修飾子 "5.6を持つMDNを返すことが合理的なアクションです。.1（メディアがサポートされていない）」。
Critical Content processing is not a web service. However, some in the Internet community may draw parallels between web services that modify content and an e-mail, SIP, or other MIME-transport service that modifies content.
重要なコンテンツ処理はWebサービスではありません。ただし、インターネットコミュニティの一部は、コンテンツを変更するWebサービスと、コンテンツを変更する電子メール、SIP、またはその他のMime-Transportサービス間の類似点を引き出す場合があります。
This section will analyze the Critical Content protocol machinery against the requirements stated in RFC 3238 [4]. The summary is that the protocol described in this document meets all of the requirements of RFC 3238.
このセクションでは、RFC 3238 [4]に記載されている要件に対して、重要なコンテンツプロトコル機械を分析します。要約は、このドキュメントで説明されているプロトコルがRFC 3238のすべての要件を満たしていることです。
This is the heart of Critical Content. Critical Content enables the sending party to give consent to have the message modified. Gateways that conform to this document will ensure that gateways only modify messages that the sending party has given consent to modify.
これは重要なコンテンツの中心です。重要なコンテンツにより、送信者はメッセージを変更することに同意することができます。このドキュメントに準拠するゲートウェイにより、ゲートウェイが送信者が変更することに同意したメッセージのみを変更することを保証します。
The content gateway is an addressable IP-entity. Moreover, all of the relevant protocols (SMTP, SIP, HTTP, etc.) all explicitly make the presence of the gateway known to the endpoints.
コンテンツゲートウェイは、アドレス指定可能なIPエンティティです。さらに、関連するすべてのプロトコル（SMTP、SIP、HTTPなど）はすべて、ゲートウェイの存在をエンドポイントに明示的に知られています。
Again, this is the point of this document. The sender explicitly gets notification if the gateway would remove a Critical Content body part.
繰り返しますが、これがこのドキュメントのポイントです。ゲートウェイが重要なコンテンツ本体の部分を削除する場合、送信者は明示的に通知を取得します。
The nature of the receiving system dictates that end users understand that the messages have been changed.
受信システムの性質は、エンドユーザーがメッセージが変更されたことを理解していることを決定します。
By definition, the endpoint cannot receive non-modified content, so this requirement does not apply.
定義上、エンドポイントは変更されていないコンテンツを受信できないため、この要件は適用されません。
Clearly, one is sending mail (SMTP), a message (SIP), or fetching a document (HTTP). The machinery described in this document does not alter the content itself or the access mechanism. Thus it is compliant with this requirement.
明らかに、1つはメール（SMTP）、メッセージ（SIP）を送信するか、ドキュメント（HTTP）の取得です。このドキュメントで説明されている機械は、コンテンツ自体やアクセスメカニズムを変更しません。したがって、この要件に準拠しています。
Since the protocol described in this document does not alter the content itself, inter- and intra-document references are not altered. However, intra-document references to removed body parts will fail. On the other hand, the sender explicitly marked those body parts as being disposable. Thus the sender is aware of the possibility the parts may not arrive at the receiver.
このドキュメントで説明されているプロトコルはコンテンツ自体を変更しないため、ドキュメント間参照とドキュメント内参照は変更されません。ただし、除去された身体部分への文書内参照は失敗します。一方、送信者は、これらの体の部分を使い捨てであると明示的にマークしました。したがって、送信者は、部品が受信機に到達しない可能性を認識しています。
Since the protocol described in this document meets Considerations 4.1 and 4.2, this requirement does not apply.
このドキュメントで説明されているプロトコルは考慮事項4.1と4.2を満たしているため、この要件は適用されません。
The privacy policy of this protocol is explicit. In particular, the protocol honors end-to-end security.
このプロトコルのプライバシーポリシーは明示的です。特に、プロトコルはエンドツーエンドのセキュリティを称えます。
Sending UA's can use signatures over critical content indicators to ensure the integrity of the indicator.
UAを送信すると、重要なコンテンツインジケーターを介して署名を使用して、インジケータの整合性を確保できます。
The gateway MUST honor signature processing. In particular, if the sending UA marks the signature components REQUIRED, and the endpoint cannot do MIME signature processing, the gateway MUST establish an appropriate signature mechanism between the gateway and the endpoint. In this case, the gateway must be secure, as it can become a target point for tampering with the signed components of the message.
ゲートウェイは、署名処理を尊重する必要があります。特に、送信が必要な署名コンポーネントをマークし、エンドポイントがMIME署名処理を実行できない場合、ゲートウェイはゲートウェイとエンドポイントの間に適切な署名メカニズムを確立する必要があります。この場合、ゲートウェイは、メッセージの署名されたコンポーネントを改ざんするためのターゲットポイントになる可能性があるため、安全でなければなりません。
Receiving systems and users should not place any authentication value on the Handling parameter.
受信システムとユーザーは、取り扱いパラメーターに認証値を配置しないでください。
Note that by design, and under the sending user's request, a content gateway will silently delete unimportant body parts. Critical content gives the sender the ability to determine the acceptable level integrity of the delivered message. That is, the message as the content gateway actually passes it on is, in fact, representative of the sender's intentions.
設計上、および送信ユーザーのリクエストの下で、コンテンツゲートウェイは重要でないボディパーツを静かに削除することに注意してください。重要なコンテンツにより、送信者は、配信されたメッセージの許容レベルの完全性を決定する機能を提供します。つまり、コンテンツゲートウェイが実際に渡すメッセージは、実際には送信者の意図を代表しています。
RFC 3204 already registered the Handling parameter. It is collected here only for reference and as a placeholder for use both for further expansion in the future and as the normative reference for other documents that need to reference the Handling parameter.
RFC 3204はすでに処理パラメーターを登録しています。ここでは、参照のためにのみ、および将来のさらなる拡張のために、また処理パラメーターを参照する必要がある他のドキュメントの規範的参照としての両方を使用するためのプレースホルダーとして収集されます。
Per section 9 of [6], here is the IANA registration for Handling.
[6]のセクション9ごとに、取り扱いのためのIANA登録があります。
To: IANA@IANA.ORG Subject: Registration of new Content-Disposition parameter
宛先：iana@iana.org件名：新しいコンテンツ閉鎖パラメーターの登録
Content-Disposition parameter name: HANDLING
コンテンツ - 分散パラメーター名：処理
Allowable values for this parameter: REQUIRED OPTIONAL
このパラメーターの許容値：オプションが必要です
Description: Marks the body part as required for delivery (REQUIRED) or can be silently discarded (OPTIONAL). See RFC <this document> and RFC 3204.
説明：配達に必要な体の部分をマーク（必要）または静かに廃棄することができます（オプション）。RFC <このドキュメント>およびRFC 3204を参照してください。
Per RFC 2183, the Content-Disposition parameter name is not case sensitive. Per RFC 3459, the values of the parameter are also not case sensitive.
RFC 2183によると、コンテンツ拡散パラメーター名はケースに敏感ではありません。RFC 3459ごとに、パラメーターの値も症例に敏感ではありません。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, P., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、P.、Sparks、R.、Handley、M.、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[4] IAB, Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[4] IAB、Floyd、S。、およびL. Daigle、「Open Pluggable Edge ServicesのIAB建築および政策上の考慮事項」、RFC 3238、2002年1月。
[5] Zimmerer, E., Peterson, E., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, "MIME media types for ISUP and QSIG Objects", RFC 3204, December 2001.
[5] Zimmerer、E.、Peterson、E.、Vemuri、A.、Ong、L.、Audet、F.、Watson、M.、M。Zonoun、「ISUPおよびQSIGオブジェクトのMIMEメディアタイプ」、RFC 3204、2001年12月。
[6] Troost, R., Dorner, S. and K. Moore, Ed., "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[6] Troost、R.、Dorner、S。and K. Moore、ed。、「インターネットメッセージでのプレゼンテーション情報の伝達：コンテンツ拡散ヘッダーフィールド」、RFC 2183、1997年8月。
[7] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[7] Crocker、D。and P. Overell、eds。、「構文仕様のためのBNFの増強：ABNF」、RFC 2234、1997年11月。
[8] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[8] ムーア、K。、「配信ステータス通知（DSNS）のSimple Mail Transfer Protocol（SMTP）サービス拡張」、RFC 3461、2003年1月。
[9] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[9] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 3464、2003年1月。
[10] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998.
[10] Fajman、R。、「メッセージ処分通知のための拡張可能なメッセージ形式」、RFC 2298、1998年3月。
[11] Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
[11] Galvin、J.、Murphy、S.、Crocker、S。、およびN. Freed、「Mimeのセキュリティマルチパート：MultiPart/Signed and MultiPart/暗号化」、RFC 1847、1995年10月。
[12] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, January 1999.
[12] Freed、N。、「ゲートウェイとマイムセキュリティマルチパート」、RFC 2480、1999年1月。
[13] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[13] Vaudreuil、G。、「Enhanced Mail System Status Codes」、RFC 3463、2003年1月。
[14] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[14] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート1：インターネットメッセージボディの形式」、RFC 2045、1996年11月。
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[15] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、1996年11月。
[16] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2", RFC 2421, September 1998.
[16] Vaudreuil、G。およびG. Parsons、「インターネットメールの音声プロファイル - バージョン2」、RFC 2421、1998年9月。
[17] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, January 1998.
[17] Kille、S。、「Mixer（Mime Internet X.400 Enhanced Relay）：X.400とRFC 822/MIMEの間のマッピング」、RFC 2156、1998年1月。
[18] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[18] Klensin、J.、ed。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[19] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982.
[19] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、RFC 822、1982年8月。
[20] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[20] Dawson、F。and T. Howes、「Vcard Mimeディレクトリプロファイル」、RFC 2426、1998年9月。
Emily Candell of Comverse Network Systems was instrumental in helping work out the base issues in the -00 document in Adelaide.
Comverse Network SystemsのEmily Candellは、Adelaideの-00ドキュメントの基本問題を解決するのに役立ちました。
Ned Freed pointed out that this mechanism was about criticality, not notification. That insight made the concept and descriptions infinitely more straightforward. If it's still confusing, it's my fault!
Ned Freedは、このメカニズムは通知ではなく、重要性に関するものであると指摘しました。その洞察は、概念と説明をより簡単により簡単にしました。それがまだ混乱しているなら、それは私のせいです！
Ned Freed also was instrumental in crafting the sections on multipart/signed and multipart/encrypted. As AD, he provided invaluable commentary to help progress this document.
Ned Freedは、MultiPart/SignedおよびMultiPart/暗号化のセクションの作成にも貢献しました。ADとして、彼はこの文書の進行を支援するために非常に貴重な解説を提供しました。
Keith Moore for helped tighten-up the explanations, and he approved of the use of Content-Disposition.
キース・ムーアは説明を引き締めるのを助け、彼はコンテンツ偏見の使用を承認しました。
Dropping the IMPORTANT critical content type took away one of the reasons for partial non-delivery notification. That makes Jutta Degener very happy!
重要な重要なコンテンツタイプを削除すると、部分的な非配信通知の理由の1つが奪われました。それはJutta DeGenerをとても幸せにします！
Harald Alvestrand and Chris Newman suggested some implementation examples.
Harald AlvestrandとChris Newmanは、いくつかの実装の例を提案しました。
Greg White asked THE key question that let us realize that critical content processing was a gateway function, and not a MTA or UA function.
Greg Whiteは、重要なコンテンツ処理がMTAまたはUA関数ではなくゲートウェイ関数であることを認識できる重要な質問をしました。
Jon Peterson cleared up how handling actually does work in the SIP environment.
ジョン・ピーターソンは、SIP環境で実際にどのように処理が機能するかを明らかにしました。
An enormous thank you to Michelle S. Cotton at IANA for helping me craft the original IANA Considerations section in 2000, and for catching the functional overlap with RFC 3204 in January 2002.
2000年に元のIANAの考慮事項セクションを作成してくれたIANAのMichelle S. Cottonに、2002年1月にRFC 3204との機能オーバーラップをキャッチしてくれたことに大いに感謝します。
Any errors, omissions, or silliness are my fault.
エラー、省略、または愚かさは私のせいです。
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスに基づく免許にある範囲に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、利害関係者に、この基準を実践するために必要なテクノロジーをカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
Eric Burger SnowShore Networks, Inc. 285 Billerica Rd. Chelmsford, MA 01824-4120 USA
Eric Burger Snowshore Networks、Inc。285 Billerica Rd。Chelmsford、MA 01824-4120 USA
Phone: +1 978 367 8400
Fax: +1 603 457 5944
EMail: e.burger@ieee.org
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。