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
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.
著作権（C）インターネット協会（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].
この文書のキーワード「MUST」、「MUST NOT」、「SHALL」、「NOT SHALL」、「べきではありません」、「推奨」、「すべきである」、「MAY」、および「省略可能」として解釈されるべきです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.
この文書内の単語「REQUIRED」は、この文書は、「REQUIRED」という名前のパラメータを定義するためであるRFC 2119で見つかった定義に従っていません。 「REQUIRED」であるこの文書の要件はありませんので、混乱はありません。
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.
この文書では、「送信エージェントは、」メッセージの発信元です。これは、SIP [3]メッセージのインターネットメッセージ、またはSIPユーザエージェントクライアント（UAC）のためのメールユーザエージェント（MUA）である可能性があります。 「エンドポイント」は、送信エージェントより低い能力の受信装置です。
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.
実装者が理解しなければならない一つの概念は、コンテンツゲートウェイです。セクション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によって述べたようにOPES IAB要件の全てを満たし、[4]。第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.
REQUIRED身体の部分は、1つの送信者が彼が配信されたメッセージを検討するために提供するために受信システムを必要としています。
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.
「= REQUIREDの取り扱い」を、この身体の部分は、送信者に重要であることを意味します。
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.
「取り扱い= OPTIONAL」は、送信者は、この身体の部分の通知レポートを気にしないことを意味します。
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.
本体部分を通過することができないコンテンツゲートウェイがOPTIONALマークされた場合、受信システムは静かに身体部分を削除してもよいです。必要な部品も失敗しているマークされない限り、受信システムは、配信失敗を返してはなりません。
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.
与えられた体の部分のための処理のためのデフォルト値は必須です。これは、コンテンツ通知実体を知らないエージェントを送信するために動作するように既存の通知メカニズムを有効にします。彼らは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の実装は、インターネットから任意の電子メールを受信することができます。しかし、これらのシステムは本当にインターネットボイスメールシステムの容量で行動しています。この場合、1は、実装は、インターネットボイスメールメッセージにインターネットボイスメールのセマンティクスを提供するために期待されます。
The content gateway MUST treat unrecognized values as REQUIRED. This is to provide backward compatibility with future uses of the Content-Criticality entity.
コンテンツゲートウェイは、必要に応じて認識されていない値を扱わなければなりません。これにより、Content-臨界実体の将来の使用との下位互換性を提供することです。
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
通知型= "REQUIRED" / "オプション" /その他のハンドリング/ジェネリック-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つの明白なアプリケーションは、インターネットメール環境における（非）配信通知を生成しています。フィールドの値がオプションである場合、コンテンツゲートウェイは、通知を生成してはいけません。フィールドの値が必要な場合、コンテンツゲートウェイは通常の通知要求メカニズムに基づいて、通知を生成することができます。正常通知要求メカニズムは、[9] SMTP RCPTコマンドにNOTIFYパラメータを指定する[8]及び配置-NOTIFICATION-Toヘッダーが挙げられます。
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を処理するための責任を負います。この場合、コンテンツゲートウェイに利用できる唯一のオプションは、開封通知を生成することです。コンテンツゲートウェイがMTAとして動作する場合、それはDSNを生成します。 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.
「適切な行動は、」コンテンツ・ゲートウェイは、実行のコンテキスト与え取るアクションです。送信者要求は領収書を返し、受信機がHANDLING本体部を読み出した場合、例えば、受信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の辞書に「プロトコル」を確認するために必要な制御情報には、対象の身体部分、または「コンテンツオブジェクト」をカプセル化します二MIMEボディ部インチここではRFC 1847から取られた例があります。
Content-Type: multipart/signed; protocol="TYPE/STYPE"; micalg="MICALG"; boundary="Signed Boundary"
コンテンツタイプ：マルチパート/署名しました。プロトコル= "TYPE / STYPE"。 micalg = "MICALG"。境界=「署名境界」
--Signed Boundary Content-Type: text/plain; charset="us-ascii"
--Signed境界のContent-Type：text / plainの。文字セット= "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
--Signed境界のContent-Type：TYPE / STYPE
CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
制御情報プロトコルのための「TYPE / STYPEは、」ここになります
--Signed Boundary--
--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.
1は、マルチパート/署名した身体の部分のためのクリティカルインジケータを置くことが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.
封入物に重要なコンテンツインジケータは、その材料は全体としてメッセージに重要であるかどうかを指定します。署名がオプションとしてマークされ、囲まれた材料はREQUIREDをマークされている場合、より少ない機能のシステムまたはネットワークは、署名検証を行うことができない場合、ゲートウェイは、署名情報を取り除くかもしれません。可能な場合は、私たちは強く、ゲートウェイが署名検証を行うと、受信者に改竄を示していることをお勧めします。
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の辞書に「プロトコル」）をカプセル化します。ここではRFC 1847から取られた例があります。
Content-Type: multipart/encrypted; protocol="TYPE/STYPE"; boundary="Encrypted Boundary"
コンテンツタイプ：マルチパート/暗号化されました。プロトコル= "TYPE / STYPE"。境界=「暗号化された境界」
--Encrypted Boundary Content-Type: TYPE/STYPE
--encrypted境界のContent-Type：TYPE / STYPE
CONTROL INFORMATION for protocol "TYPE/STYPE" would be here
制御情報プロトコルのための「TYPE / STYPEは、」ここになります
--Encrypted Boundary Content-Type: application/octet-stream
--encrypted境界のContent-Type：アプリケーション/オクテットストリーム
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.
--Encrypted Boundary--
--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.
一つは、賢明に暗号化された筐体（マルチパート/暗号化された）身体の部分のクリティカルインジケータを配置することがあります。エンドポイントがメッセージを解読できる場合、ゲートウェイはその全体が本体部を通過します。
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.
1が必要な制御対象をマークした場合、送信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.
制御オブジェクトは任意であり、エンドポイントがメッセージを解読することができず、ゲートウェイはメッセージを解読できる場合、ゲートウェイはメッセージを解読し、平文メッセージを転送することができます。送信ユーザが明示的に制御対象OPTIONALをマーキングしてメッセージを復号化するゲートウェイの許可を与えています。 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は、必要に応じて暗号化されたコンテンツをマークした場合、明らかに、ゲートウェイは、必要な処理ルールを適用します。送信UAがREQUIRED、ゲートウェイとして暗号化されたコンテンツをマークしていない場合、それはデータを復号化できない限り、また、必要に応じて暗号化されたコンテンツを扱います。ゲートウェイは常に（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または開封通知の内容は、このドキュメントの範囲を超えています。この文書では、唯一の重要な身体の部分をマークする方法を指定します。一方、我々は賢明なDSNとMDN内容を想像します。 [13]に列挙されたように、例えば、DSNは適切なエラーコードを含むべきです。 「失敗：」フィールド同様に、開封通知は、MDNの障害コードを含める必要があります。
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.
ボイスメールは、歴史的に、音声中心となっています。多くのボイスメールシステムは、音声のみをレンダリングします。このようファックスなどの拡張機能は、送信とファックス画像を受信だけでなく、マルチパートの音声およびファックスメッセージを作成するために、ボイスメールシステムを有効にします。いくつかのボイスメールシステムは、テキストを音声に変換するか、テキスト・ツー・ファックス技術を使用してテキストを描画することができます。理論的には可能であるが、どれも今日はビデオをレンダリングすることはできません。
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].
メッセージの重要な内容を示す一つの方法は、プロファイルを定義することです。プロファイルは、サイレントUA能力の知識に基づいて、メール本文部分を削除するための規則を定義します。上記の例を引用し、音声プロファイルは、容易なMTAまたはUAは黙っ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.
問題の一つの側面では、システムは、メッセージの一部を提供できないことを送信者に通知する際に、一方が所定の身体部分を送達するの問題を示すために、部分的不達通知メカニズムを使用することが決定されるからです。しかし、これは、ユーザの要求配信通知が必要です。また、送信者は送信ユーザエージェントによって追加された部品を認識しないかもしれません。この場合、障害通知が送信者を神秘でしょう。
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サーバは、BODYSTRUCTUREメソッドにクリティカル・コンテンツを入れたり、任意の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."
このセクションでは、我々は、用語のために[17] RFC 2156に見出される定義を使用する「ゲートウェイ」。
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.
我々は、厳密用語のために[18] RFC 2821で見つかった定義を使用しないでください「ゲートウェイ」。特に、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のネットワークへの最初のネットワークを接続するゲートウェイです。第二のネットワークは、多くの場合、最初のネットワークよりも低い能力を持っています。標準的なトポロジは次のとおりです。 「[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の前に最終ホップネットワークの間で、したがってことができません。コンテンツゲートウェイは、最初のMTA送信UAのコンタクトとすることができます。最後に、コンテンツ・ゲートウェイは、受信側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のケースでは、SIPユーザエージェントサーバとしてSIPユーザエージェントクライアント、および受信UAとしてSIPプロキシとして各MTA、送信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.
記載されているようにISUPとQSIGオブジェクトの処理は、[5]、統合されたゲートウェイの一例です。
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の後ろに座っている場合縮重場合は、発生しないものがあります。一方は正常分娩に、後処理工程としてコンテンツゲートウェイを実装する場合に発生します。例えば、1は、コンテンツのゲートウェイ・プロセスがメッセージをピックアップキューまたはディレクトリへのメッセージを配信するメール処理システムを構成することができます。 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.
取り扱い、すべてのContent-処分のパラメータにそうであるよう選択された代替のためにのみ有効です。選択された代替が重要なコンテンツの表示がある場合、全体の代替が示された重要度になります。すなわち、選択された代替HANDLING = OPTIONALがある場合、コンテンツゲートウェイは任意の送達通知を生成してはいけません、です。
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メッセージを囲む、または選択された代替は、マルチパートMIMEタイプ自体でメッセージ/ RFC822であれば、個々の最上位の本体部分は、この文書に記載さハンドリング機構に従います。
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のネットワークにメッセージを転送する前に、コンテンツゲートウェイは、第1のネットワークからのメッセージの内容を調べます。この例の目的のために、我々は、第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部を含むゲートウェイを介してきます。送信者は、必要なテキスト部分をマーク。ゲートウェイは、ショートメッセージサービスの能力を知って、静かにショートメッセージサービスネットワークに重要なコンテンツを渡し、非クリティカル、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）との音声メッセージにテキスト注釈（その1）で3つのパートメッセージ（パート2）を考えます。送信者は、必要な最初の2つの部分をマーク。さて、テキストを格納するためにも機能せず、ボイスメールシステムだけである私たちが受けたMTA（ゲートウェイ）を想定してみましょう。この場合、ゲートウェイは、受信側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部構成のメッセージの処理を検討します。最初の部分は、第二の部分、音声メッセージのテキスト注釈です。第三部では、送信者のvCardのです。送信者は、必要な第一及び第二の部分をマーク。また、送信者が開封確認のためのメッセージをマークします。
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は、メッセージの最初の部分、テキスト部分をレンダリングすることができません。また、メッセージ、vCardの部分の第3の部分をレンダリングすることができません。送信者がREQUIREDメッセージの3番目の部分に印を付けていなかったので、システムは、メッセージの3番目の部分をレンダリングするためのTUIの障害を無視します。送信者が必要な最初の部分をマークしました、と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は処分してMDNを返すようにするために、合理的なアクションがある場合は、「失敗した」と故障修飾語「5.6 0.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輸送サービスとの間の類似点を引き出すことができます。
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.
明らかに、一つのメール（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.
ゲートウェイは、署名処理を尊重しなければなりません。送信UA必要な署名コンポーネントをマークし、エンドポイントが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
To：IANA@IANA.ORG件名：新しいコンテンツ処分パラメータの登録
Content-Disposition parameter name: HANDLING
Content-Dispositionパラメータ名：取扱い
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.
説明：配信のために必要とされる（REQUIRED）身体部分をマークまたはサイレント（オプション）を廃棄することができます。 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ごとに、Content-Dispositionパラメータ名は大文字と小文字を区別しません。 RFC 3459ごとに、パラメータの値も大文字と小文字を区別しません。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、P.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 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、フロイド、S.とL. Daigle氏、 "オープン・プラグイン可能なエッジサービスのための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.、ピーターソン、E.、Vemuri、A.、オング、L.、Audet、F.、ワトソン、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.、ドルナー、S.とK.ムーア、エド、 "インターネット・メッセージでプレゼンテーション情報を伝える：コンテンツ-Dispositionヘッダーフィールド"。、RFC 2183、1997年8月。
[7] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[7]クロッカー、D.、およびP. Overell、編、 "構文仕様のための増大している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.、 "配信状態通知のための簡易メール転送プロトコル（SMTP）サービス拡張（DSNの）"、RFC 3461、2003年1月。
[9] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[9]ムーア、K.とG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、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]ガルビン、J.、マーフィー、S.、クロッカー、S.およびN.フリード、 "MIMEマルチパートのセキュリティ：マルチパート/署名およびマルチパート/暗号化"、RFC 1847、1995年10月。
[12] Freed, N., "Gateways and MIME Security Multiparts", RFC 2480, January 1999.
[12]解放され、N.、 "ゲートウェイとMIMEセキュリティマルチパート"、RFC 2480、1999年1月。
[13] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[13]ヴォードルイユ、G.、 "強化されたメールシステムステータスコード"、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]フリード、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）第一部：インターネットメッセージ本体のフォーマット"、RFC 2045、1996年11月。
[15] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[15]解放され、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]ヴォードルイユ、G.とG.パーソンズ、 "インターネットメール用の音声プロファイル - バージョン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インターネットX.400拡張リレー）：X.400およびRFC 822 / MIMEの間のマッピング"、RFC 2156、1998年1月。
[18] Klensin, J., Ed., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[18] Klensin、J.、エド。、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[19] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, August 1982.
、RFC 822、1982年8月 "ARPAインターネットテキストメッセージの形式の規格" [19]クロッカー、D.、。
[20] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[20]ドーソン、F.とT.ハウズ、 "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.
コンバースネットワークシステムのエミリーCandellはアデレードで-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 also was instrumental in crafting the sections on multipart/signed and multipart/encrypted. As AD, he provided invaluable commentary to help progress this document.
ネッドフリードも署名/マルチパートおよびマルチパート/暗号化された上でのセクションを作り上げるに尽力しました。 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!
重要重要なコンテンツタイプを削除すると、部分的に非配信通知の理由の一つを奪いました。それはユッタ・デッジナーはとても幸せになります！
Harald Alvestrand and Chris Newman suggested some implementation examples.
ハラルドAlvestrandとクリス・ニューマンは、いくつかの実装例を示唆しました。
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.
グレッグ・ホワイトは、私たちは重要なコンテンツの処理が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の考慮事項のセクションを作る助けるためと2002年1月にRFC 3204との機能重複を引くためにIANAでミシェルS.コットンをお願い致します。
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
エリックバーガーSnowShoreネットワークス株式会社285ビレリカRdを。チェルムズフォード、MA 01824-4120 USA
Phone: +1 978 367 8400 Fax: +1 603 457 5944 EMail: e.burger@ieee.org
電話：+1 978 367 8400ファックス：+1 603 457 5944 Eメール：e.burger@ieee.org
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。