[要約] RFC 4141は、SMTPとMIMEの拡張機能であるContent Conversionに関する規格です。このRFCの目的は、電子メールのコンテンツ変換を容易にするための仕様を提供することです。
Network Working Group K. Toyoda
Request for Comments: 4141 PCC
Category: Standards Track D. Crocker
Brandenburg
November 2005
SMTP and MIME Extensions for Content Conversion
コンテンツ変換用のSMTPおよび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 (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
A message originator sometimes sends content in a form the recipient cannot process or would prefer not to process a form of lower quality than is preferred. Such content needs to be converted to an acceptable form, with the same information or constrained information (e.g., changing from color to black and white). In a store-and-forward environment, it may be convenient to have this conversion performed by an intermediary. This specification integrates two ESMTP extensions and three MIME content header fields, which defines a cooperative service that permits authorized, accountable content form conversion by intermediaries.
メッセージオリジネーターは、受信者が処理できない形式でコンテンツを送信することがあります。このようなコンテンツは、同じ情報または制約された情報（たとえば、色から白黒に変更）を使用して、許容可能なフォームに変換する必要があります。店舗とフォワードの環境では、この変換を仲介者によって実行するのが便利な場合があります。この仕様には、2つのESMTP拡張機能と3つのMIMEコンテンツヘッダーフィールドを統合します。これは、仲介者による認定された説明責任のあるコンテンツフォーム変換を許可する協同サービスを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Background. . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Overview. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Notational Conventions. . . . . . . . . . . . . . . . . . 5
2. Applicability. . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Service Specification. . . . . . . . . . . . . . . . . . . . . 5
3.1. Sending Permission. . . . . . . . . . . . . . . . . . . . 9
3.2. Returning Capabilities. . . . . . . . . . . . . . . . . . 10
3.3. Next-Hop Non-Support of Service . . . . . . . . . . . . . 12
4. Content Conversion Permission SMTP Extension . . . . . . . . . 12
4.1. Content Conversion Permission Service Extension
Definition. . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. CONPERM Parameter to Mail-From. . . . . . . . . . . . . . 13
4.3. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Content Negotiation SMTP Extension . . . . . . . . . . . . . . 13
5.1. Content Negotiation Service Extension Definition. . . . . 13
5.2. CONNEG Parameter to RCPT-TO . . . . . . . . . . . . . . . 14
5.3. Syntax. . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. MIME Content-Features Header Field . . . . . . . . . . . . . . 16
7. MIME Content-Convert Header Field. . . . . . . . . . . . . . . 16
8. MIME Content-Previous Header Field . . . . . . . . . . . . . . 16
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. CONPERM Negotiation . . . . . . . . . . . . . . . . . . . 17
9.2. Example CONNEG Negotiation. . . . . . . . . . . . . . . . 18
9.3. Content-Previous. . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations. . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Appendix A. CONNEG with Direct SMTP. . . . . . . . . . . . . . . . 22
Appendix B. USING Combinations of the Extensions . . . . . . . . . 23
Appendix C. MIME Content-Type Registrations. . . . . . . . . . . . 24
Internet specifications typically define common capabilities for a particular service that are supported by all participants. This permits the sending of basic data without knowing which additional capabilities individual recipients support. However, knowing those capabilities permits the sending of additional types of data and data of enhanced richness. Otherwise, a message originator will send content in a form the recipient cannot process or will send multiple forms of data. This specification extends the work of [CONMSG], which permits a recipient to solicit alternative content forms from the originator. The current specification enables MIME content conversion by intermediaries, on behalf of a message originator and a message recipient.
インターネット仕様は通常、すべての参加者によってサポートされている特定のサービスの共通機能を定義します。これにより、個々の受信者がどの追加機能をサポートするかを知らずに基本データを送信できます。ただし、これらの機能を知ることで、追加の種類のデータを送信し、豊かさの強化されたデータを送信できます。それ以外の場合、メッセージのオリジネーターは、受信者が処理できない形式でコンテンツを送信するか、複数のフォームのデータを送信します。この仕様は、[conmsg]の作業を拡張します。これにより、受信者はオリジネーターから代替コンテンツフォームを勧誘できます。現在の仕様により、メッセージのオリジネーターとメッセージ受信者に代わって、仲介者によるMIMEコンテンツの変換が可能になります。
MIME enables the distinguishing and labeling of different types of content [IMF, MEDTYP]. However, an email originator cannot know whether a recipient is able to support (interpret) a particular data type. To permit the basic use of MIME, a minimum set of data types is specified as its support base. How will an originator know whether a recipient can support any other data types?
MIMEは、さまざまな種類のコンテンツ[IMF、MedTyp]の際立ったラベル付けを可能にします。ただし、電子メールのオリジネーターは、受信者が特定のデータ型をサポート（解釈）できるかどうかを知ることができません。MIMEの基本的な使用を許可するために、データ型の最小セットがサポートベースとして指定されています。受信者は、受信者が他のデータ型をサポートできるかどうかをどのように知ることができますか？
A mechanism for describing MIME types is specified in [FEAT]. [CONMSG] specifies a mechanism that permits an originator to query a recipient about the types it supports using email messages for the control exchange. This permits a recipient to propagate information about its capabilities back to an originator. For the control exchange, using end-to-end email messages introduces considerable latency and some unreliability.
MIMEタイプを記述するためのメカニズムは[feat]で指定されています。[conmsg]は、コントロール交換の電子メールメッセージを使用してサポートするタイプについて受信者に受信者に照会できるメカニズムを指定します。これにより、受信者はその機能に関する情報を発信者に戻すことができます。制御交換の場合、エンドツーエンドの電子メールメッセージを使用すると、かなりの遅延といくつかの信頼性が導入されます。
An alternative approach is for an originator to use the "best" form of data that it can, and to include the same types of permitted representation information used in [CONMSG]. Hopefully, the recipient, or an intermediary, can translate this into a form supported by a limited recipient. This specification defines such a mechanism. It defines a means of matching message content form to the capabilities of a recipient device or system, by using MIME content descriptors and the optional use of an SMTP-based negotiation mechanism [ESMTP1, ESMTP2].
別のアプローチは、発信者ができる限り「最良の」形式のデータを使用し、[conmsg]で使用される同じタイプの許可された表現情報を含めることです。うまくいけば、受信者、または仲介者がこれを限られた受信者がサポートするフォームに変換できることを願っています。この仕様は、そのようなメカニズムを定義します。MIMEコンテンツの記述子を使用し、SMTPベースのネゴシエーションメカニズム[ESMTP1、ESMTP2]のオプションの使用を使用して、メッセージコンテンツフォームを受信者デバイスまたはシステムの機能に一致させる手段を定義します。
An originator describes desirable content forms in MIME content descriptors. It may give "permission", to any intermediary or the recipient, to convert the content to one of those forms. Separately, an SMTP server may report the target's content capabilities back to the SMTP client. The client is then able to convert the message content into a form that is both supported by the target system and acceptable to the originator.
オリジネーターは、MIMEコンテンツ記述子の望ましいコンテンツフォームについて説明します。中間または受信者に「許可」を与えて、コンテンツをそれらのフォームのいずれかに変換することができます。それとは別に、SMTPサーバーはターゲットのコンテンツ機能をSMTPクライアントに報告する場合があります。クライアントは、メッセージコンテンツをターゲットシステムによってサポートされ、オリジネーターに受け入れられるフォームに変換することができます。
A conversion service needs to balance between directions provided by the originator, directions provided on behalf of the recipient, and capabilities of the intermediary that performs the conversions. This is complicated by the need to determine whether the directions are advisory or whether they are intended to be requirements. Conversions specified as advisory are performed if possible, but they do not alter message delivery. In contrast, conversion specifications that are treated as a requirement will prohibit delivery if the recipient will not be able to process the content.
コンバージョンサービスは、発信者が提供する方向、受信者に代わって提供される指示、および変換を実行する仲介者の能力のバランスをとる必要があります。これは、指示がアドバイザリーであるかどうか、またはそれらが要件であることを意図しているかどうかを判断する必要性によって複雑になります。可能であればアドバイザリーとして指定された変換は実行されますが、メッセージ配信は変更されません。対照的に、要件として扱われる変換仕様は、受信者がコンテンツを処理できない場合、配信を禁止します。
These possibilities interact to form different processing scenarios, in the event that the intermediary cannot satisfy the desires of both the originator and the recipient:
これらの可能性は相互作用して、仲介者が発信者と受信者の両方の欲求を満たすことができない場合に、さまざまな処理シナリオを形成します。
Table 1: FAILURE HANDLING
表1：障害処理
\ RECEIVER| | |
+-------+ | Advise | Require |
ORIGINATOR\| | |
-----------+----------+----------+
| Deliver | Deliver |
Advise | original | original |
| content | content |
-----------+----------+----------+
| Return | Return |
Require | w/out | w/out |
| delivery | delivery |
-----------+----------+----------+
This table reflects a policy that determines failure handling solely based on the direction provided by the originator. Thus, information on behalf of the recipient is used to guide the details of conversion, but not delivery of the message.
この表は、オリジネーターが提供する方向のみに基づいて障害処理を決定するポリシーを反映しています。したがって、受信者に代わって情報を使用して、メッセージの配信ではなく変換の詳細を導くために使用されます。
This is intended to continue the existing email practice of delivering content that a recipient might not be able to process. Clearly, the above table could be modified to reflect a different policy. However, that would limit backward compatibility experienced by users.
これは、受信者が処理できない可能性のあるコンテンツを配信するという既存の電子メールプラクティスを継続することを目的としています。明らかに、上記の表は、異なるポリシーを反映するように変更できます。ただし、ユーザーが経験する後方互換性を制限します。
This specification provides mechanisms to support a controlled, transit-time mail content conversion service, through a series of mechanisms. These include:
この仕様は、一連のメカニズムを通じて、制御されたトランジット時間メールコンテンツ変換サービスをサポートするメカニズムを提供します。これらには以下が含まれます：
* an optional ESMTP hop-by-hop service that uses the CONPERM SMTP service extensions, issued by the originator,
* Originatorが発行したConperm SMTPサービス拡張機能を使用するオプションのESMTPホップバイホップサービス、
* an optional ESMTP hop-by-hop service that uses the CONNEG SMTP service extensions, issued on behalf of the recipient, and
* 受信者に代わって発行されたConneg SMTPサービス拡張機能を使用するオプションのESMTPホップバイホップサービスと
* three MIME Content header fields (Content-Convert, Content-Previous and * Content-Features) that specify appropriate content header fields and record conversions that have been performed.
* 適切なコンテンツヘッダーフィールドと実行されたレコード変換を指定する3つのMIMEコンテンツヘッダーフィールド（コンテンツコンバート、コンテンツと *コンテンツフィーチャー）。
Figure 1: EXAMPLE RELAY ENVIRONMENT
図1：リレー環境の例
+------------+ +-----------+
| Originator | | Recipient |
+------------+ +-----------+
||Posting Delivering/\
\/ ||
+--------+ +-----------------+ +--------+
| SMTP | | SMTP Relay | | SMTP |
| Client |--->| Server | Client |--->| Server |
+--------+ +--------+--------+ +--------+
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
例では、「C：」と「S：」は、それぞれクライアントとサーバーから送信された行を示します。
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS].
このドキュメントの「必須」、「そうでなければならない」、「そうでなければ」、「すべきではない」、「そうでない」は、「要件レベルを示すためにRFCで使用するためのキーワード」[キーワード]で定義されると解釈されます。
This specification defines a cooperative mechanism that facilitates early transformation of content. The mechanism can be used to save bandwidth and to permit rendering on recipient devices that have limited capabilities. In the first case, the assumption is that conversion will produce smaller content. In the latter case, the assumption is that the recipient device can render content in a form derived from the original, but cannot render the original form.
この仕様は、コンテンツの早期変換を促進する協同メカニズムを定義します。このメカニズムは、帯域幅を保存し、機能が限られているレシピエントデバイスのレンダリングを可能にするために使用できます。最初のケースでは、変換がより小さなコンテンツを生成するという仮定があります。後者の場合、レシピエントデバイスは元の形式から派生した形式でコンテンツをレンダリングできるが、元のフォームをレンダリングできないという仮定です。
The mechanism can impose significant resource requirements on intermediaries performing conversions. Further, the intermediary accepts responsibility for conversion prior to knowing whether it can perform the conversion. Also note that conversion is not possible for content that has been digitally signed or encrypted, unless the converting intermediary can decode and re-code the content.
このメカニズムは、変換を実行する仲介者に重要なリソース要件を課すことができます。さらに、仲介者は、変換を実行できるかどうかを知る前に、変換の責任を受け入れます。また、変換中間部がコンテンツをデコードして再コードできない限り、デジタル署名または暗号化されたコンテンツに対して変換は不可能であることに注意してください。
This service integrates two ESMTP extensions and three MIME content header fields, in order to permit authorized, accountable content form conversion by intermediaries. Intermediaries are ESMTP hosts (clients and servers) along the transmission path between an originator and a recipient.
このサービスは、2つのESMTP拡張機能と3つのMIMEコンテンツヘッダーフィールドを統合して、仲介者による承認された説明責任のあるコンテンツフォーム変換を許可します。仲介者は、発信者と受信者の間の送信パスに沿ったESMTPホスト（クライアントとサーバー）です。
An originator specifies preferred content-types through the Content-Convert MIME content header field. The content header fields occur in each MIME body-part to which they apply. That is, each MIME body-part contains its own record of conversion guidance and history.
オリジネーターは、コンテンツコンバートMIMEコンテンツヘッダーフィールドを介して優先コンテンツタイプを指定します。コンテンツヘッダーフィールドは、適用する各mimeボディパートで発生します。つまり、各マイムボディパートには、独自の変換ガイダンスと歴史の記録が含まれています。
The originator's preferences are raised to the level of requirement through the ESMTP CONPERM service extension. The CONPERM mechanism is only needed when an originator requires that conversion limitations be enforced by the mail transfer service. If an acceptable content type cannot be delivered, then no delivery is to take place.
オリジネーターの好みは、ESMTP ConPermサービス拡張を介して要件のレベルまで引き上げられます。コンパールメカニズムは、オリジネーターがメール転送サービスによって変換の制限を実施することを要求する場合にのみ必要です。許容可能なコンテンツタイプを配信できない場合、配達は行われません。
Target system capabilities are communicated in SMTP sessions through the ESMTP CONNEG service extension. This information is used to restrict the range of conversions that may be performed, but does not affect delivery.
ターゲットシステム機能は、ESMTP Connegサービス拡張機能を介したSMTPセッションで伝達されます。この情報は、実行される可能性のある変換の範囲を制限するために使用されますが、配信には影響しません。
When CONPERM is used, conversions are performed by the first ESMTP host that can obtain both the originator's permission and information about the capabilities supported by the recipient. If a relay or client is unable to transmit the message to a next-hop that supports CONPERM or to perform appropriate conversion, then it terminates message transmission and returns a [DSNSMTP, DSNFMT, SYSCOD] to the originator, with status code 5.6.3 (Conversion required but not supported).
Conpermを使用すると、受信者がサポートする機能に関する情報と情報の両方を取得できる最初のESMTPホストによってコンバージョンが実行されます。リレーまたはクライアントがConpermをサポートしたり、適切な変換を実行したりする次のホップにメッセージを送信できない場合、メッセージ送信を終了し、[DSNSMTP、DSNFMT、SYSCOD]をオリジネーターに返し、ステータスコード5.6.3（変換は必要ですが、サポートされていません）。
When an SMTP relay or server performs content conversion, it records which specific conversions are made into Content-Previous and Content-Features MIME header fields associated with each converted MIME body-part.
SMTPリレーまたはサーバーがコンテンツコンバージョンを実行すると、コンテンツとコンテンツフィーチュアに関連する特定の変換が、変換された各MIMEボディパートに関連付けられたMIMEヘッダーフィールドに記録されます。
If a message is protected by strong content authentication or privacy techniques, then an intermediary that converts message content MUST ensure that the results of its processing are similarly protected. Otherwise it MUST NOT perform conversion.
メッセージが強力なコンテンツ認証またはプライバシー技術によって保護されている場合、メッセージコンテンツを変換する仲介者は、その処理の結果が同様に保護されていることを確認する必要があります。それ以外の場合は、変換を実行してはなりません。
Originator Action:
オリジネーターアクション：
An originator specifies desired conversion results through the MIME Content-Convert header field. If the originator includes a Content-Convert header field, then it must also include a Content-Feature header field, to indicate the current form of the content. Intermediaries MAY interpret the presence of this header field as authorization to perform conversions. When Content-Convert header fields are the sole means for guiding conversions by intermediaries, then they serve only as advisories. Failure to satisfy the guidance of these header fields does not affect final delivery.
オリジネーターは、MIMEコンテンツコンバートヘッダーフィールドを介して望ましい変換結果を指定します。Originatorにコンテンツコンバートヘッダーフィールドが含まれている場合、コンテンツの現在の形式を示すために、コンテンツフィーチャーヘッダーフィールドも含める必要があります。仲介者は、このヘッダーフィールドの存在をコンバージョンを実行する許可として解釈する場合があります。コンテンツコンバートヘッダーフィールドが、仲介者による変換をガイドするための唯一の手段である場合、アドバイザリーとしてのみ機能します。これらのヘッダーフィールドのガイダンスを満たさないと、最終配信には影響しません。
When posting a new message, the originator MAY specify transit-service enforcement of conversion limitations by using the ESMTP CONPERM service extension. In each of the MIME body-parts for which conversion is authorized, conversions MUST be limited to those specified in MIME Content-Convert header fields. If conversion is needed, but an authorized conversion cannot be performed, then the message will be returned to the originator. If CONPERM is not used, then failure to perform an authorized conversion will not affect normal delivery handling.
新しいメッセージを投稿するとき、オリジネーターは、ESMTP ConPermサービス拡張を使用して、変換制限のトランジットサービス施行を指定することができます。コンバージョンが承認されているMIMEボディパートのそれぞれで、コンバージョンはMIMEコンテンツコンバートヘッダーフィールドで指定されたものに制限する必要があります。コンバージョンが必要であるが、承認された変換を実行できない場合、メッセージはオリジネーターに返されます。Conpermが使用されない場合、許可された変換を実行できないと、通常の配信処理には影響しません。
Figure 2: CONPERM USAGE
図2：Conpermの使用
+------------+
| Originator |
+------------+
SMTP ||
or || CONPERM
SUBMIT \/
+--------+ +----------------+
| SMTP | SMTP | SMTP Relay |
| Client |----------->| Server | |
+--------+ CONPERM +--------+-------+
Recipient Action:
受信者アクション：
With the ESMTP mail transfer service, capabilities that can be supported on behalf of the recipient SHOULD be communicated to intermediaries by the ESMTP CONNEG service extension.
ESMTPメール転送サービスにより、受信者に代わってサポートできる機能は、ESMTP Connegサービスエクステンションによって仲介者に伝える必要があります。
Figure 3: CONNEG USAGE
図3：Connegの使用
+-----------+
| Recipient |
+-----------+
Capabilities||
\/
+----------------+ +--------+
| SMTP Relay | CONNEG | SMTP |
| | Client |<--------| Server |
+-------+--------+ +--------+
Intermediary Actions:
仲介措置：
An intermediary MAY be given CONPERM direction when receiving a message, and MAY be given CONNEG guidance before sending the message. CONPERM and CONNEG operate on a per-message basis and are issued through the ESMTP MAIL-FROM request. CONNEG response information is provided on a per-recipient basis, through the response to ESMTP RCPT-TO.
メッセージを受信するときに中間監督にconperm方向が与えられる場合があり、メッセージを送信する前にconnegガイダンスが与えられる場合があります。ConpermとConnegは、1人あたりベースで動作し、ESMTP Mail-Fromリクエストを介して発行されます。Conneg応答情報は、ESMTP RCPT-toへの応答を通じて、レシピエントごとに提供されます。
Conversion MUST be performed by the first CONPERM intermediary that obtains the CONNEG capability information. The MIME Content-Type MUST conform to the result of the converted content, as per [MEDTYP]. When an intermediary obtains different capability information for different recipients of the same message, it MAY either:
コンバージョンは、コネグ機能情報を取得する最初のコンパール仲介者によって実行する必要があります。MIMEコンテンツタイプは、[MedTyp]に従って、変換されたコンテンツの結果に適合する必要があります。仲介者が同じメッセージの異なる受信者に対して異なる機能情報を取得する場合、次のとおりです。
* Create a single, converted copy of the content that can be supported by all of the recipients, or
* すべての受信者がサポートできるコンテンツの単一の変換されたコピーを作成するか、
* Create multiple converted copies, matching the capabilities of subsets of the recipients. Each version is then sent separately to an appropriate subset of the recipients, using separate, standard SMTP sessions with separate, standard RFC2821.Rcpt-To lists of addresses.
* 受信者のサブセットの機能に一致する複数の変換されたコピーを作成します。次に、各バージョンは、個別の標準RFC2821.rcpt-toアドレスリストを使用して、個別の標準SMTPセッションを使用して、受信者の適切なサブセットに個別に送信されます。
A record of conversions is placed into MIME Content-Previous header fields. The current form of the content is described in MIME Content-Features header fields.
コンバージョンの記録は、MIMEコンテンツに重大なヘッダーフィールドに配置されます。コンテンツの現在の形式は、MIMEコンテンツフィーチャーヘッダーフィールドで説明されています。
A special case of differential capabilities occurs when an intermediary receives capability information about some recipients, but no information about others. An example of this scenario can occur when sending a message to some recipients within one's own organization, along with recipients located elsewhere. The intermediary might have capability information about the local recipients, but will not have any for distant recipients. This is treated as a variation of the handling that is required for situations in which the permissible conversions are the null set -- that is, no valid conversions are possible for a recipient.
微分能力の特殊なケースは、中間者が一部の受信者に関する能力情報を受け取ったが、他のものに関する情報はない場合に発生します。このシナリオの例は、他の場所にある受信者とともに、自分の組織内の一部の受信者にメッセージを送信するときに発生する可能性があります。仲介者は地元の受信者に関する能力情報を持っているかもしれませんが、遠い受信者には何も持っていません。これは、許容される変換がヌルセットである状況に必要なハンドリングのバリエーションとして扱われます。つまり、受信者にとって有効な変換は不可能です。
Rather than simply failing transmission to the recipients for which there is no capability information, the intermediary MAY choose to split the list of addressees into subsets of separate, standard RFC2821.Rcpt-To lists and separate, standard SMTP sessions, and then continue the transmission of the original content to those recipients via the continued use of the CONPERM mechanism. Hence, the handling for such recipients is performed as if no CONNEG transaction took place.
能力情報がない受信者への送信を単に失敗させるのではなく、仲介者は、宛先のリストを個別の標準RFC2821.RCPT-toリストおよび個別の標準SMTPセッションのサブセットに分割することを選択できます。コンパーメカニズムの継続的な使用を介して、それらの受信者への元のコンテンツの。したがって、そのような受信者の取り扱いは、Connegトランザクションが行われなかったかのように実行されます。
Once an intermediary has performed conversion, it MAY terminate use of CONPERM. However, some relay environments, such as those re-directing mail to a new target device, will benefit from further conversion. Intermediaries MAY continue to use CONPERM or MAY re-initiate CONPERM use when they have knowledge of possible variations in a target device.
仲介者が変換を実行すると、コンパールの使用を終了する可能性があります。ただし、新しいターゲットデバイスへの郵便を再ダイレクトするなど、一部のリレー環境は、さらなる変換の恩恵を受けるでしょう。仲介者は、ターゲットデバイスのバリエーションの可能性について知識がある場合、コンパールの使用を継続したり、コンパールの使用を再開する場合があります。
NOTE: A new, transformed version of content may have less information than the earlier version. Of course, a sequence of transformations may lose additional information at each step. Perhaps surprisingly, this can result in more loss than might be necessary. For example, transformation x could change content form A to content form B; then transformation y changes B to C. However, it is possible that transformation y might have accepted form A directly and produced form D, which has more of the original information than C.
注：コンテンツの新しい変換バージョンは、以前のバージョンよりも少ない情報を持っている場合があります。もちろん、一連の変換は各ステップで追加情報を失う可能性があります。おそらく驚くべきことに、これは必要以上の損失をもたらす可能性があります。たとえば、変換XはコンテンツフォームAをコンテンツフォームBに変更できます。次に、変換yはBをCに変えます。ただし、変換yが直接Aを受け入れ、形式Dを生成した可能性があります。
NOTE: An originator MAY validate any conversions that are made by requesting a positive [DSNSMTP]. If the DSN request includes the "RET" parameter, the delivery agent SHOULD return an exact copy of the delivered (converted) message content. This will permit the originator to inspect the results of any conversion(s).
注：オリジネーターは、肯定的な[DSNSMTP]を要求することで行われた変換を検証することができます。DSN要求に「Ret」パラメーターが含まれている場合、配信エージェントは配信された（変換された）メッセージコンテンツの正確なコピーを返す必要があります。これにより、発信者は変換の結果を検査することができます。
A message originator that permits content conversion by intermediaries MAY use the CONPERM ESMTP service extension and Content-Convert MIME header fields to indicate what conversions are permitted by intermediaries. Other mechanisms, by which a message originator communicates this permission to the SMTP message transfer service, are outside the scope of this specification.
仲介者によるコンテンツ変換を許可するメッセージオリジネーターは、Conperm ESMTPサービス拡張機能とコンテンツコンバートMIMEヘッダーフィールドを使用して、仲介者が許可されている変換を示しています。メッセージオリジネーターがこの許可をSMTPメッセージ転送サービスに伝える他のメカニズムは、この仕様の範囲外です。
NOTE: This option requires that a server make an open-ended commitment to ensure that acceptable conversions are performed. In particular, it is possible that an intermediary will be required to perform conversion, but be unable to do so. The result will be that the intermediary will be required to perform conversion, but it will be performed in undelivered mail.
注：このオプションでは、サーバーが許容可能なコンバージョンが実行されることを保証するためにオープンエンドのコミットメントを行う必要があります。特に、仲介者が変換を実行するために必要である可能性がありますが、そうすることはできません。その結果、仲介者は変換を実行するために必要とされますが、それは配達のないメールで実行されます。
When an ESMTP client is authorized to participate in the CONPERM service, it MUST interact with the next SMTP hop server about:
ESMTPクライアントがConPermサービスに参加することを許可されている場合、次のSMTPホップサーバーと対話する必要があります。
* The server's ability to enforce authorized conversions, through ESMTP CONPERM
* esmtp conpermを介して、認定コンバージョンを実施するサーバーの能力
* The capabilities supported for the target device or system, through ESMTP CONNEG
* ESMTP Connegを介して、ターゲットデバイスまたはシステムでサポートされる機能
Successful use of CONPERM does not require that conversion take place along the message transfer path. Rather, it requires that conversion take place when a next-hop server reports capabilities that can be supported on behalf of the recipient (through CONNEG) and that those capabilities do not include support for the current representation of the content.
Conpermの使用に成功しても、メッセージ転送パスに沿って変換が行われる必要はありません。むしろ、（Connegを介して）受信者に代わってサポートできる機能をレポートし、それらの機能にコンテンツの現在の表現のサポートが含まれていない場合、次のホップサーバーがレポートされる場合に変換が行われる必要があります。
NOTE: It is acceptable to have every SMTP server -- including the last-hop server -- support CONPERM, with none offering CONNEG. In this case, the message is delivered to the recipient in its original form. Any possible conversions to be performed are left to the recipient. Thus, the recipient is given the original form of the content, along with an explicit list of conversions deemed acceptable by the originator.
注：ラストホップサーバーを含むすべてのSMTPサーバーをサポートConpermを使用することは受け入れられます。この場合、メッセージは元の形式で受信者に配信されます。実行される可能性のある変換は、受信者に残されます。したがって、受信者には、元の形式のコンテンツが与えられ、オリジネーターが受け入れられるとみなされる変換の明示的なリストが与えられます。
An SMTP server MAY offer ESMTP CONPERM, without being able to perform conversions, if it knows conversions can be performed along the remainder of the transfer path, or by the target device or system.
SMTPサーバーは、変換を実行できずにESMTP conpermを提供する場合があります。これは、転送パスの残りの部分に沿って、またはターゲットデバイスまたはシステムによって変換を実行できることを知っている場合です。
A target recipient device or system arranges announcements of its content form capabilities to the SMTP service through a means outside the scope of this specification. Note that enabling a server to issue CONNEG information on behalf of the recipient may require a substantial mechanism between the recipient and server. When an ESMTP server knows a target's capabilities, it MAY offer the CONNEG ESMTP service extension.
ターゲットレシピエントデバイスまたはシステムは、この仕様の範囲外の手段を通じて、そのコンテンツフォーム機能のアナウンスをSMTPサービスに配置します。サーバーが受信者に代わってコネグ情報を発行できるようにすると、受信者とサーバーの間にかなりのメカニズムが必要になる場合があることに注意してください。ESMTPサーバーがターゲットの機能を知っている場合、Conneg ESMTPサービス拡張機能を提供する場合があります。
NOTE: One aspect of that mechanism, between the recipient and an ESMTP server offering the CONNEG ESMTP service extension could include offering capabilities beyond those directly supported by the recipient. In particular, the server -- or other intermediaries between the server and the recipient -- could support capabilities that they can convert to a recipient's capability. As long as the result is acceptable to the set specified in the relevant Content-Convert header fields of the message being converted, the details of these conversions are part of the recipient/server mechanism, and fall outside the scope of the current specification.
注：そのメカニズムの1つの側面は、受信者とconneg esmtpサービス拡張機能を提供するESMTPサーバーの間で、受信者が直接サポートするものを超えて提供する機能を含めることができます。特に、サーバーまたはサーバーと受信者の間の他の仲介者は、受信者の機能に変換できる機能をサポートできます。結果が、変換されるメッセージの関連するコンテンツコンバートヘッダーフィールドで指定されたセットに受け入れられる限り、これらの変換の詳細は受信者/サーバーメカニズムの一部であり、現在の仕様の範囲外です。
If a next-hop ESMTP server responds that it supports CONNEG when a message is being processed according to the CONPERM mechanism, then the SMTP client:
Next-Hop ESMTPサーバーが、Conpermメカニズムに従ってメッセージが処理されているときにConnegをサポートすることを応答した場合、SMTPクライアント：
1) MUST request CONNEG information 2) MUST perform the requisite conversions, if possible, before sending the message to the next-hop SMTP server
1) コネグ情報を要求する必要があります2）次のホップSMTPサーバーにメッセージを送信する前に、可能であれば必要な変換を実行する必要があります
3) MUST fail message processing, if any conversion for the message fails, and MUST return a failure DSN to the originator with status code 5.6.5 (Conversion failed).
3) メッセージの変換が失敗した場合、メッセージ処理に失敗する必要があり、ステータスコード5.6.5で障害DSNをオリジネーターに返す必要があります（変換に失敗しました）。
When performing conversions, as specified in Content-Convert MIME header fields, the Client MUST:
コンテンツコンバートMIMEヘッダーフィールドで指定されているように、コンバージョンを実行する場合、クライアントは以下を行う必要があります。
1) Add a Content-Previous header field and a Content-Features header field to each MIME body-part that has been converted, removing any existing Content-Features header fields.
1) コンテンツに広がるヘッダーフィールドとコンテンツフィーチャーヘッダーフィールドを各MIMEボディパートに追加し、既存のコンテンツフィーチャーヘッダーフィールドを削除します。
2) Either:
2) また：
* Send a single copy to the next-hop SMTP server, using the best capabilities supported by all recipients along that path, or
* そのパスに沿ってすべての受信者がサポートする最良の機能を使用して、次のホップSMTPサーバーに単一のコピーを送信します。
* Separate the transfers into multiple, standard RFC2821.Rcpt-To and ESMTP sessions, in order to provide the best conversions possible for subsets of the recipients.
* 受信者のサブセットに可能な限り最高の変換を提供するために、転送を複数の標準RFC2821.RCPT-TOおよびESMTPセッションに分離します。
If the transfers are to be separated, then the current session MUST be terminated, and new sessions conducted for each subset.
転送を分離する場合、現在のセッションを終了し、各サブセットに対して新しいセッションを実施する必要があります。
The conversions to be performed are determined by the intersection of three lists:
実行される変換は、3つのリストの交差点によって決定されます。
* Conversions permitted by the originator
* オリジネーターが許可する変換
* Content capabilities of the target
* ターゲットのコンテンツ機能
* Conversions that can be performed by the SMTP client host
* SMTPクライアントホストが実行できる変換
Failed Conversion
変換に失敗しました
If the result of this intersection is the null set of representations, for an addressee, then delivery to that addressee MUST be handled as a conversion failure.
この交差点の結果がnullの表現セットである場合、宛先の場合、その宛先への配信は、変換障害として処理する必要があります。
If handling is subject to the CONPERM mechanism and:
取り扱いがコンパールメカニズムの対象となる場合：
* the next-hop SMTP host does not indicate that it can represent the target's capabilities through CONNEG, but
* Next-Hop SMTPホストは、Connegを通じてターゲットの機能を表すことができることを示していませんが、
* does respond that it can support CONPERM, then the client SMTP MUST send the existing content, if all other SMTP transmission requirements are satisfied.
* Conpermをサポートできると回答します。他のすべてのSMTP送信要件が満たされている場合、クライアントSMTPは既存のコンテンツを送信する必要があります。
If handling is not subject to the CONPERM mechanism, then conversion failures do not affect message delivery.
取り扱いがコンパールメカニズムの対象でない場合、変換障害はメッセージの配信に影響しません。
If a Client is participating in the CONPERM mechanism, but the next-hop SMTP server does not support CONPERM or CONNEG, then the SMTP client
クライアントがConpermメカニズムに参加しているが、Next-Hop SMTPサーバーがConpermまたはConnegをサポートしていない場合、SMTPクライアント
1) MUST terminate the session to the next-hop SMTP server, without sending the message
1) メッセージを送信せずに、セッションをnext-Hop SMTPサーバーに終了する必要があります
2) MUST return a DSN notification to the originator, with status code 5.6.3 (Conversion required but not supported). [DSNSMTP, DSNFMT, SYSCOD]
2) ステータスコード5.6.3（変換は必要ですがサポートされていない）を使用して、DSN通知をオリジネーターに返す必要があります。[dsnsmtp、dsnfmt、syscod]
If a Client is participating in the CONPERM mechanism and the next-hop SMTP server supports CONNEG, but provides no capabilities for an individual RCPT-TO addressee, then the SMTP client's processing for that recipient MUST be either to:
クライアントがConpermメカニズムに参加しており、Next-Hop SMTPサーバーがConnegをサポートしているが、個々のRCPT-toの宛先に機能を提供しない場合、その受信者のSMTPクライアントの処理は次のとおりです。
1) Treat the addressee as a conversion failure, or
1) 宛先を変換障害として扱う、または
2) Separate the addressee from the address list that is processed according to CONNEG, and continue to process the addressee according to CONPERM.
2) Connegに従って処理されたアドレスリストから宛先を分離し、Conpermに従って宛先を処理し続けます。
1) The name of the SMTP service extension is
1) SMTPサービス拡張機能の名前はです
"Content-Conversion-Permission"
「コンテンツコンバージョン - 許可」
2) The EHLO keyword value associated with this extension is
2) この拡張機能に関連付けられているEhloキーワード値はです
"CONPERM"
「コンパーム」
3) A parameter using the keyword "CONPERM" is added to the MAIL-FROM command.
3) キーワード「conperm」を使用したパラメーターがmail-fromコマンドに追加されます。
4) The server responds with acceptance or rejection of support for CONPERM, for this message.
4) サーバーは、このメッセージに対して、コンパールのサポートを受け入れるか拒否して応答します。
Parameter:
パラメーター：
CONPERM
コンパール
Arguments:
議論：
There are no arguments. Specification of permitted conversions is located in a Content-Convert header field for each MIME body-part in which conversion is permitted.
議論はありません。許可された変換の仕様は、変換が許可されているMIMEボディパートごとにコンテンツコンバートヘッダーフィールドにあります。
Client Action:
クライアントアクション：
If the server issued a 250-CONPERM as part of its EHLO response for the current session, and the client is participating in the CONPERM service for this message -- such as by having received the message with a CONPERM requirement -- then the client MUST issue the CONPERM parameter in the MAIL-FROM. If the server does not issue 250-CONPERM, and the client is participating in the CONPERM service for this message, then the client MUST treat the transmission as permanently rejected.
サーバーが現在のセッションのEHLO応答の一部として250コンパーマを発行し、クライアントがこのメッセージのコンパーマーサービスに参加している場合、コンパム要件でメッセージを受け取ったなどして、クライアントはクライアントがMail-FromでConPermパラメーターを発行します。サーバーが250 conpermを発行せず、クライアントがこのメッセージのConpermサービスに参加している場合、クライアントは送信を永久に拒否されたものとして扱う必要があります。
Server Action:
サーバーアクション：
If the client specifies CONPERM in the MAIL-FROM, but the server does not support the CONPERM parameter, the server MUST reject the MAIL-FROM command with a 504-CONPERM reply.
クライアントがMail-fromでConpermを指定しているが、サーバーがConpermパラメーターをサポートしていない場合、サーバーは504コンペルムの返信でメールからムーロムコマンドを拒否する必要があります。
If the client issues the CONPERM parameter in the MAIL-FROM, then the server MUST conform to this specification. Either it MUST relay the message according to CONPERM, or it MUST convert the message according to CONNEG information.
クライアントがMail-FromでConPermパラメーターを発行した場合、サーバーはこの仕様に準拠する必要があります。Conpermに従ってメッセージを中継する必要があるか、Conneg情報に従ってメッセージを変換する必要があります。
Content-Conversion-Permission = "CONPERM"
1) The name of the SMTP service extension is:
1) SMTPサービス拡張機能の名前は次のとおりです。
"Content-Negotiation"
「コンテンツネゴシエーション」
2) The EHLO keyword value associated with this extension is:
2) この拡張機能に関連付けられているEhloキーワード値は次のとおりです。
"CONNEG"
「コネグ」
3) A parameter, using the keyword "CONNEG", is added to the RCPT-TO command.
3) キーワード「conneg」を使用したパラメーターがRCPT-toコマンドに追加されます。
4) The server responds with a report indicating the content capabilities that can be received on behalf of the recipient device or system, associated with the target RCPT-TO address.
4) サーバーは、ターゲットRCPT-toアドレスに関連付けられた受信者デバイスまたはシステムに代わって受信できるコンテンツ機能を示すレポートで応答します。
Parameter:
パラメーター：
CONNEG
コネグ
Arguments:
議論：
There are no arguments.
議論はありません。
Client Action:
クライアントアクション：
If a message is subject to CONPERM requirements and the server issues a 250-CONNEG, as part of its EHLO response for the current session, the client MUST issue the CONNEG parameter in the RCPT-TO request. If the message is not subject to CONPERM requirements, and the server issues a 250-CONNEG, the client MAY issue the CONNEG parameter with RCPT-TO.
メッセージがConPerm要件の対象となり、サーバーが現在のセッションのEHLO応答の一部として250コネグルを発行する場合、クライアントはRCPT-toリクエストでconnegパラメーターを発行する必要があります。メッセージがConPerm要件の対象ではなく、サーバーが250コネグルを発行した場合、クライアントはRCPT-toでconnegパラメーターを発行する場合があります。
If the client issues the CONNEG parameter with RCPT-TO, then it MUST honor the capabilities returned in the CONNEG RCPT-TO replies for that message. In addition, it MUST convert the message content, if the current form of the content is not included in the capabilities listed, on behalf of the recipient.
クライアントがRCPT-toでconnegパラメーターを発行した場合、そのメッセージに対してconneg rcpt-toの返信で返された機能を尊重する必要があります。さらに、受信者に代わってコンテンツの現在の形式がリストされている機能に含まれていない場合、メッセージコンテンツを変換する必要があります。
The conversions that are performed are determined by the intersection of the:
実行される変換は、次の交差によって決定されます。
* Conversions permitted by the originator
* オリジネーターが許可する変換
* Content capabilities of the target
* ターゲットのコンテンツ機能
* Conversions that can be performed by the SMTP client host
* SMTPクライアントホストが実行できる変換
If the result of this intersection is the null set of representations, then the Client processing depends upon whether the next-hop server has offered CONPERM, as well as CONNEG:
この交差点の結果がNULLの表現セットである場合、クライアントの処理は、Next-HopサーバーがConpermとConnegを提供しているかどうかによって異なります。
1) If the message will be subject to CONPERM at the next hop, the Client MAY transmit the original content to the next hop and continue CONPERM requirements.
1) メッセージが次のホップでConpermの対象となる場合、クライアントは元のコンテンツを次のホップに送信し、ConPerm要件を継続することができます。
2) Otherwise, the Client MUST treat the conversion as failed.
2) それ以外の場合、クライアントは失敗したように変換を扱う必要があります。
If the result of the intersection is not null, the client SHOULD convert the data to the "highest" level of capability of the server. Determination of the level that is highest is left to the discretion of the host performing the conversion.
交差点の結果がnullでない場合、クライアントはデータをサーバーの「最高の」レベルの機能に変換する必要があります。最高のレベルの決定は、変換を実行するホストの裁量に任されます。
Each converted MIME body-part MUST have a Content-Previous header field that indicates the previous body-part form and a Content-Features header field, indicating the new body-part form.
変換された各マイムボディパートには、以前のボディパート形式とコンテンツフィーチャーズヘッダーフィールドを示すコンテンツが強化されたヘッダーフィールドが必要であり、新しいボディパート形式を示しています。
Server Action:
サーバーアクション：
If the client specifies CONNEG in the RCPT-TO, but the server does not support the CONNEG parameter, the server MUST reject the RCPT-TO addressees with 504 replies.
クライアントがRCPT-toでconnegを指定しますが、サーバーがconnegパラメーターをサポートしていない場合、サーバーは504回の返信でRCPT-toのアドレスを拒否する必要があります。
If the server does support the CONNEG parameter, and it knows the capabilities of the target device or system, then it MUST provide that information through CONNEG. The server MAY provide a broader list than is supported by the recipient if the server can ensure that the form of content delivered can be processed by the recipient, while still satisfying the constraints of the author's Content-Convert specification(s).
サーバーがConnegパラメーターをサポートし、ターゲットデバイスまたはシステムの機能を知っている場合、Connegを通じてその情報を提供する必要があります。サーバーは、サーバーが配信されたコンテンツの形式を受信者が処理できるようにしながら、著者のコンテンツコンバーント仕様の制約を満たしていることを確認できる場合、受信者がサポートするよりも広いリストを提供できます。
The response to a CONNEG RCPT-TO request will be multi-line RCPT-TO replies. For successful (250) responses, at least the first line of the response must contain RCPT-TO information other than CONNEG. Additional response lines are for CONNEG. To avoid problems due to variations in line buffer sizes, the total parametric listing must be provided as a series of lines, each beginning with "250-CONNEG", except for the last line, which is "250 CONNEG".
conneg rcpt-to requestへの応答は、マルチラインRCPT-to返信です。成功する（250）応答のために、少なくとも応答の最初の行には、conneg以外のRCPT-to情報を含める必要があります。追加の応答ラインはコネグ用です。ラインバッファーサイズの変動による問題を回避するには、パラメトリックの合計リストを一連の行として提供する必要があります。それぞれが「250コネグ」である「250コネグ」を除き、それぞれ「250コネグ」から始まります。
The contents of the capability listing MUST conform to the specifications in [SYN] and cover the same range of specifications permitted in [CONMSG].
機能リストの内容は、[syn]の仕様に準拠し、[conmsg]で許可されている同じ範囲の仕様をカバーする必要があります。
Content-Negotiation = "CONNEG"
Capability = { <filter> specification,
as per [SYN] }
The Content-Features header field describes the characteristics of the current version of the content for the MIME body-part in which the header field occurs. There is a separate Content-Features header field for each MIME body-part. The specification for this header field is contained in [FEAT].
コンテンツフィーチャーヘッダーフィールドは、ヘッダーフィールドが発生するMIMEボディパートのコンテンツの現在のバージョンの特性を説明しています。マイムボディパートごとに個別のコンテンツフィーチャーヘッダーフィールドがあります。このヘッダーフィールドの仕様は[feat]に含まれています。
Content-Convert is a header field that specifies preferred conversions for the associated content. It MAY be used without the other mechanisms defined in this document. If present, this header field MUST be carried unmodified and delivered to the recipient. In its absence, the content originator provides no guidance about content conversions, and intermediaries SHOULD NOT perform content conversion.
Content-Convertは、関連するコンテンツの優先変換を指定するヘッダーフィールドです。このドキュメントで定義されている他のメカニズムなしで使用できます。存在する場合、このヘッダーフィールドは変更されずに、受信者に配信される必要があります。コンテンツのオリジネーターは、コンテンツの変換に関するガイダンスを提供せず、仲介者はコンテンツ変換を実行してはなりません。
In the extended ABNF notation, the Content-Convert header field is defined as follows:
拡張されたABNF表記では、コンテンツコンバートヘッダーフィールドは次のように定義されます。
Convert = "Content-convert" ":" permitted
convert = "content contervert" "："許可
Permitted = "ANY" / "NONE" / permitted-list
permitted-list = { explicit list of permitted
final forms, using <filter>
syntax in [SYN] }
If the permitted conversions are specified as "ANY", then the intermediary may perform any conversions it deems appropriate.
許可された変換が「任意」として指定されている場合、仲介者は適切と思われる変換を実行できます。
If the permitted conversions are specified as "NONE", then the intermediary SHOULD NOT perform any conversions to this MIME body-part, even when the target device or system does not support the original form of the content.
許可された変換が「なし」として指定されている場合、ターゲットデバイスまたはシステムがコンテンツの元の形式をサポートしていない場合でも、仲介者はこのMIMEボディパートに変換を実行してはなりません。
If a Content-Convert header field is present, then a Content-Features header field MUST also be present to describe the current form of the Content.
コンテンツコンバートヘッダーフィールドが存在する場合、コンテンツのヘッダーフィールドも存在する必要があります。コンテンツの現在の形式を説明する必要があります。
When an intermediary has performed conversion of the associated content, the intermediary MUST record details of the previous representation, from which the conversion was performed. This information is placed in a Content-Previous header field that is part of the MIME body-part with the converted content. There is a separate header field for each converted MIME body-part.
仲介者が関連するコンテンツの変換を実行した場合、仲介者は以前の表現の詳細を記録する必要があり、そこから変換が実行されました。この情報は、変換されたコンテンツを備えたMIMEボディパートの一部であるコンテンツに及ぶヘッダーフィールドに配置されます。変換されたマイムボディパートごとに別のヘッダーフィールドがあります。
When an intermediary has performed conversion, the intermediary MUST record details of the result of the conversion by creating or revising the Content-Features header field for the converted MIME body-part.
仲介者が変換を実行した場合、仲介者は変換されたMIMEボディパートのコンテンツフィーチャーヘッダーフィールドを作成または改訂することにより、変換の結果の詳細を記録する必要があります。
In the extended [ABNF] notation, the Content-Previous header field is defined as follows:
拡張された[ABNF]表記では、コンテンツに及ぶヘッダーフィールドは次のように定義されます。
previous = "Content-Previous" [CFWS] ":" [CFWS] date by type
前= "content-previous" [cfws] "：" [cfws] date by type
date = "Date " [CFWS] date-time [CFWS] ";" [CFWS]
date = "date" [cfws] date-time [cfws] ";"[CFWS]
by = "By " [CFWS] domain [CFWS] ";" [CFWS]
by = "by" [cfws] domain [cfws] ";"[CFWS]
type = { content characteristics, using
<filter> syntax in [SYN] }
The Date field specifies the date and time at which the indicated representation was converted into a newer representation.
日付フィールドは、示された表現が新しい表現に変換された日付と時刻を指定します。
The By field specifies the domain name of the intermediary that performed the conversion.
バイフィールドは、変換を実行した仲介者のドメイン名を指定します。
An intermediary MAY choose to derive the Content-Previous header field, for a body-part, from an already-existing Content-Features header field in that body-part, before that header field is replaced with the description of the current representation.
仲介者は、そのヘッダーフィールドが現在の表現の説明に置き換える前に、そのボディパートの既存のコンテンツフィーチャーヘッダーフィールドから、ボディパートのコンテンツに広がるヘッダーフィールドを導き出すことを選択できます。
S: 220 example.com IFAX
C: EHLO example.com
S: 250- example.com
S: 250-DSN
S: 250 CONPERM
C: MAIL FROM:May@some.example.com CONPERM
S: 250 <May@some.example.com> originator ok
C: RCPT TO:<June@some.example.com>
S: 250-<June@some.example.com> recipient ok
C: DATA
S: 354 okay, send data
C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
Per:
( image-file-structure=TIFF-minimal
dpi=400
image-coding=JBIG
size-x=2150/254
paper-size=letter
)
with MIME body-parts including:
Content-Convert:
(&(image-file-structure=TIFF-minimal)
(MRC-mode=0)
(color=Binary)
(|(&(dpi=204)
(dpi-xyratio=[204/98,204/196]) )
(&(dpi=200)
(dpi-xyratio=[200/100,1]) )
(&(dpi=400)
(dpi-xyratio=1) ) )
(|(image-coding=[MH,MR,MMR])
(&(image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) ) )
(size-x<=2150/254)
(paper-size=[letter,A4])
(ua-media=stationery) )
>>
S: 250 message accepted
C: QUIT
S: 221 goodbye
S: 220 example.com IFAX
C: EHLO example.com
S: 250- example.com
S: 250-DSN
S: 250 CONNEG
C: MAIL FROM:<May@some.example.com>
S: 250 <May@some.example.com> originator ok
C: RCPT TO:<June@ifax1.jp> CONNEG
S: 250-<June@some.example.com> recipient ok
S: 250-CONNEG (&(image-file-structure=TIFF-minimal)
S: 250-CONNEG (MRC-mode=0)
S: 250-CONNEG (color=Binary)
S: 250-CONNEG (|(&(dpi=204)
S: 250-CONNEG (dpi-xyratio=[204/98,204/196]) )
S: 250-CONNEG (&(dpi=200)
S: 250-CONNEG (dpi-xyratio=[200/100,1]) ) )
S: 250-CONNEG (image-coding=[MH,MR,MMR])
S: 250-CONNEG (size-x<=2150/254)
S: 250-CONNEG (paper-size=[letter,A4])
S: 250 CONNEG (ua-media=stationery) )
C: DATA
S: 354 okay, send data
C: <<RFC 2822 message with MIME Content-Type:TIFF-FX
Per:
( image-file-structure=TIFF-minimal
dpi=400
image-coding=JBIG
size-x=2150/254
paper-size=letter
)
>>
S: 250 message accepted
C: QUIT
S: 221 goodbye
Content-Previous:
Date Tue, 1 Jul 2001 10:52:37 +0200;
By relay.example.com;
(&(image-file-structure=TIFF-minimal)
(MRC-mode=0)
(color=Binary)
(&(dpi=400)
(dpi-xyratio=1) )
(&(image-coding=JBIG)
(image-coding-constraint=JBIG-T85)
(JBIG-stripe-size=128) )
(size-x=2150/254)
(paper-size=A4)
(ua-media=stationery) )
This service calls for disclosure of capabilities, on behalf of recipients. Mechanisms for determining the requestor's and the respondent's authenticated identity are outside the scope of this specification. These mechanisms are intended to permit disclosure of information that is safe for public distribution; hence, there is no inherent need for security measures.
このサービスでは、受信者に代わって能力の開示が必要です。要求者と回答者の認証されたアイデンティティを決定するためのメカニズムは、この仕様の範囲外です。これらのメカニズムは、公共の配布に安全な情報の開示を許可することを目的としています。したがって、セキュリティ対策には固有の必要はありません。
Information that should have restricted distribution is still able to be disclosed. Therefore, it is the responsibility of the disclosing ESMTP server or disclosing ESMTP client to determine whether additional security measures should be applied to the use of this ESMTP option.
分布が制限されるべき情報は、まだ開示することができます。したがって、このESMTPオプションの使用に追加のセキュリティ対策を適用すべきかどうかを判断するために、ESMTPサーバーを開示するか、ESMTPクライアントを開示する責任です。
Use of the ESMTP CONNEG option permits content transformation by an intermediary, along the mail transfer path. When the contents are encrypted, the intermediary cannot perform the conversion, because it is not expected to have access to the relevant secret keying material. When the contents are signed, but not encrypted, conversion will invalidate the signature. This specification provides for potentially unbounded computation by intermediary MTAs, depending on the nature and amount of conversion required. Further, this computation burden might provide an opportunity for denial-of-service attacks, given that Internet mail typically permits intermediaries to receive messages from all Internet sources.
ESMTP Connegオプションの使用により、メール転送パスに沿って、仲介者によるコンテンツ変換が可能になります。コンテンツが暗号化されている場合、関連する秘密のキーイング資料にアクセスできると予想されていないため、仲介者は変換を実行できません。コンテンツが署名されているが暗号化されていない場合、変換は署名を無効にします。この仕様は、必要な変換の性質と量に応じて、中間MTAによる潜在的に無限の計算を提供します。さらに、インターネットメールがすべてのインターネットソースからメッセージを受け取ることができることを考えると、この計算の負担はサービス拒否攻撃の機会を提供する可能性があります。
This specification provides for content conversion by unspecified intermediaries. Use of this mechanism carries significant risk. Although intermediaries always have the ability to perform damaging transformations, use of this specification could result in more exploration of that potential and, therefore, more misbehavior. Use of intermediaries is discussed in [RFC3238].
この仕様は、不特定の仲介者によるコンテンツ変換を提供します。このメカニズムの使用には大きなリスクがあります。仲介者は常に損害を与える変換を実行する能力を持っていますが、この仕様を使用すると、その可能性をより調査し、したがって、より不正行為をもたらす可能性があります。仲介者の使用は[RFC3238]で説明されています。
CONPERM/CONNEG provide a cooperative mechanism, rather than enabling intermediary actions that were not previously possible. Intermediaries already make conversions on their own initiative. Hence, the mechanism introduces essentially no security concerns, other than divulging recipient preferences.
conperm/connegは、以前は不可能だった中間行動を可能にするのではなく、協同メカニズムを提供します。仲介者はすでに独自のイニシアチブでコンバージョンを行っています。したがって、メカニズムは、レシピエントの好みを漏らす以外に、本質的にセキュリティの懸念をもたらしません。
Graham Klyne and Eric Burger provided extensive, diligent reviews and suggestions. Keith Moore, Giat Hana, and Joel Halpern provided feedback that resulted in improving the specification's integration into established email practice.
Graham KlyneとEric Burgerは、広範で勤勉なレビューと提案を提供しました。Keith Moore、Giat Hana、およびJoel Halpernはフィードバックを提供し、その結果、仕様の確立された電子メールプラクティスへの統合が改善されました。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[CONMSG] Klyne, G., Iwazaki, R., and D. Crocker, "Content Negotiation for Messaging Services based on Email", RFC 3297, July 2002.
[Conmsg] Klyne、G.、Iwazaki、R。、およびD. Crocker、「電子メールに基づくメッセージングサービスのコンテンツネゴシエーション」、RFC 3297、2002年7月。
[DSNSMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DSNSMTP] Moore、K。、「Simple Mail Transfer Protocol（SMTP）Service Extension for Delivery Status通知（DSNS）」、RFC 3461、2003年1月。
[DSNFMT] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSNFMT] Moore、K。およびG. Vaudreuil、「配信ステータス通知の拡張可能なメッセージ形式」、RFC 3464、2003年1月。
[SYSCOD] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[Syscod] Vaudreuil、G。、「拡張メールシステムステータスコード」、RFC 3463、2003年1月。
[ESMTP1] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, "SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[ESMTP1] Klensin、J.、Freed、N.、Rose、M.、Stefferud、E。、およびD. Crocker、「SMTP Service Extensions」、STD 10、RFC 1869、1995年11月。
[ESMTP2] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[ESMTP2] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 2821、2001年4月。
[FEAT] Klyne, G., "Indicating Media Features for MIME Content", RFC 2912, September 2000.
[feat] Klyne、G。、「MIMEコンテンツのメディア機能を示す」、RFC 2912、2000年9月。
[IMF] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[IMF] Resnick、P。、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[SYN] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[Syn] Klyne、G。、「メディア機能セットを説明するための構文」、RFC 2533、1999年3月。
[MEDTYP] IANA, "MIME Media Types", <http://www.iana.org/assignments/media-types>
[MedTyp] Iana、「Mime Media Types」、<http://www.iana.org/assignments/media-types>
[CFWS] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[CFWS] Alvestrand、H。、「Content Language Headers」、RFC 3282、2002年5月。
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[RFC3238] Floyd、S。およびL. Daigle、「Open Pluggable Edge ServicesのIAB建築および政策上の考慮事項」、RFC 3238、2002年1月。
This Appendix is descriptive. It only provides discussion of usage issues permitted or required by the normative text
この付録は説明的です。規範的なテキストで許可または要求される使用法の問題の議論のみを提供します
In some configurations, it is possible to have direct, email-based interactions, where the originator's system conducts a direct, interactive TCP connection with the recipient's system. This configuration permits a use of the content form negotiation service that conforms to the specification here, but permits some simplifications. This single SMTP session does not have the complexity of multiple, relaying sessions and therefore does not have the requirement for propagating permissions to intermediaries.
一部の構成では、オリジネーターのシステムが受信者のシステムと直接的なインタラクティブなTCP接続を実行する直接的な電子メールベースのインタラクションを持つことができます。この構成により、ここでの仕様に準拠するが、いくつかの単純化を可能にするコンテンツフォームネゴシエーションサービスの使用が可能になります。この単一のSMTPセッションには、複数の中継セッションの複雑さがないため、仲介者に許可を伝播するための要件はありません。
The Originator's system provides user-level functions for the originator, and it contains the SMTP Client for sending messages. Hence, the formal step of email "posting" is a process that is internal or virtual, within the Originating system. The recipient's service contains the user-level functions for the recipient, and contains the SMTP server for receiving messages. Hence, the formal steps of email "delivering" and "receipt" are internal or virtual, within the Receiving system.
オリジネーターのシステムは、オリジネーターにユーザーレベルの機能を提供し、メッセージを送信するためのSMTPクライアントが含まれています。したがって、電子メール「投稿」の正式なステップは、発信システム内で内部または仮想のプロセスです。受信者のサービスには、受信者のユーザーレベルの関数が含まれており、メッセージを受信するためのSMTPサーバーが含まれています。したがって、電子メールの正式な手順「配信」と「領収書」は、受信システム内で内部または仮想です。
Figure 4: DIRECT CONNEG
図4：直接コネグ
Originating system Receiving system
+------------------+ +------------------+
| +------------+ | | +-----------+ |
| | Originator | | | | Recipient | |
| +------------+ | | +-----------+ |
| ||Posting | | /\Receiving |
| \/ | | || |
| +---------+ | | +--------+ |
| | SMTP |<---|-------|----| SMTP | |
| | Client |----|-------|--->| Server | |
| +---------+ | | +--------+ |
+------------------+ +------------------+
In this case, CONPERM is not needed because the SMTP Client is part of the originating system and already has the necessary permission. Similarly, the SMTP server will be certain to know the recipient's capabilities, because the server is part of the receiving system.
この場合、SMTPクライアントは発信元システムの一部であり、すでに必要な許可があるため、Conpermは必要ありません。同様に、サーバーは受信システムの一部であるため、SMTPサーバーは受信者の機能を確実に知ることができます。
Therefore, Direct Mode email transmission can achieve content capability and form matching by having:
したがって、ダイレクトモードの電子メール伝送は、以下を持つことにより、コンテンツ機能とフォームマッチングを実現できます。
* Originating systems that conform to this specification and a communication process between originator and recipient that is the same as would take place between a last-hop SMTP Relay and the Delivering SMTP server to which it is connected.
* この仕様と、ラストホップSMTPリレーと接続されている配信SMTPサーバーの間で行われるのと同じオリジネーターと受信者との間の通信プロセスに準拠する起源のシステム。
* That is, the Client and Server MUST employ CONNEG and the Client MUST perform any requisite conversions.
* つまり、クライアントとサーバーはConnegを使用する必要があり、クライアントは必要な変換を実行する必要があります。
This specification defines a number of mechanisms. It is not required that they all be used together. For example, the difference between listing preferred conversions -- versus specifying enforced limitations to conversions -- is discussed in the Introduction. This Appendix further describes scenarios that might call for using fewer than the complete set defined in this specification. It also summarizes the conditions which mandate that an intermediary perform conversion.
この仕様は、多くのメカニズムを定義しています。それらをすべて一緒に使用する必要はありません。たとえば、コンバージョンへの強制制限を指定することと、導入では、適切なコンバージョンの指定との違いについて説明します。この付録では、この仕様で定義されている完全なセットよりも少ない使用を必要とする可能性のあるシナリオについて説明します。また、仲介者が変換を実行することを義務付けている条件を要約します。
This Appendix is descriptive. It only provides discussion of usage issues permitted or required by the normative text
この付録は説明的です。規範的なテキストで許可または要求される使用法の問題の議論のみを提供します
The available mechanisms are:
利用可能なメカニズムは次のとおりです。
1. CONPERM Parameter to Mail-From 2. CONNEG parameter to RCPT-TO 3. MIME Content-Convert Header Field 4. MIME Content-Previous Header Field 5. MIME Content-Features Header Field
1. conpermパラメーターからメールから2.コネグパラメーターからRCPT-to 3. MIMEコンテンツコンバートヘッダーフィールド4. MIMEコンテンツと普及しているヘッダーフィールド5. MIMEコンテンツフィーチャーヘッダーフィールド
Use of the MIME Content-Convert header field specifies the originator's preferences, should conversion be performed. This does not impose any requirements on the conversion; it is merely advisory.
MIME Content Contervertヘッダーフィールドの使用は、コンバージョンが実行された場合に発信者の設定を指定します。これは、変換に要件を課しません。それは単なる助言です。
When the MIME Content-Convert specification is coupled with the ESMTP CONPERM option, then the originator's specification of preferred conversions rises to the level of requirement. No other conversions are permitted, except those specified in the Content-Convert header field.
MIMEコンテンツコンバート仕様がESMTP ConPermオプションと組み合わされている場合、優先変換のオリジネーターの仕様は要件のレベルに上昇します。コンテンツコンバートヘッダーフィールドで指定されているものを除き、他の変換は許可されていません。
Note that the presence of both mechanisms does not require that conversions be performed. Rather, it constrains conversions, should they occur.
両方のメカニズムの存在は、変換を実行する必要はないことに注意してください。むしろ、それらが発生した場合に変換を制約します。
Although it is unlikely that any device will always able to process every type of existing content, some devices can be upgraded easily (e.g., adding plug-in). Hence, such a device is able to process all content effectively.
あらゆるデバイスが常にあらゆる種類の既存のコンテンツを処理できる可能性は低いですが、一部のデバイスは簡単にアップグレードできます（たとえば、プラグインを追加）。したがって、そのようなデバイスはすべてのコンテンツを効果的に処理することができます。
For such devices, it is better to refrain from issuing a CONNEG assertion. Instead, the CONPERM request should be propagated to the target device.
このようなデバイスについては、Connegの主張の発行を控える方が良いです。代わりに、conpermリクエストをターゲットデバイスに伝播する必要があります。
A node is required to perform conversion when:
次の場合、コンバージョンを実行するにはノードが必要です。
1. At least one MIME Content-Covert header field is present in the message,
1. 少なくとも1つのMIMEコンテンツカバーヘッダーフィールドがメッセージに存在します、
2. ESMTP CONPERM is in force at the node processing the message,
2. ESMTP conpermは、メッセージを処理するノードで有効です、
3. ESMTP CONNEG is also in force at the same node,
3. ESMTPコネグも同じノードで有効です、
4. The current content form is not cited in the CONNEG list,
4. 現在のコンテンツフォームはConnegリストでは引用されていません。
5. At least one content form is present, both in the Content-Convert list and the CONNEG list, and
5. コンテンツコンバートリストとconnegリストの両方に、少なくとも1つのコンテンツフォームが存在します。
6. The intermediary is able to convert from the current form to one of the forms listed in both Content-Convert and CONNEG.
6. 仲介者は、現在のフォームから、コンテンツコンバートとコネグの両方にリストされているフォームの1つに変換できます。
Header field name: Content-Convert
ヘッダーフィールド名：コンテンツコンバート
Applicable protocol: Mail (RFC 2822)
該当するプロトコル：メール（RFC 2822）
Status: Proposed Standard
ステータス：提案された標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document(s): RFC 4141.
仕様文書：RFC 4141。
Related information: None.
関連情報：なし。
Header field name: Content-Previous
ヘッダーフィールド名：Content-Previous
Applicable protocol: Mail (RFC 2822)
該当するプロトコル：メール（RFC 2822）
Status: Proposed Standard
ステータス：提案された標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document(s): RFC 4141, Section 8
仕様文書：RFC 4141、セクション8
Related information: None.
関連情報：なし。
Authors' Addresses
著者のアドレス
Kiyoshi Toyoda Panasonic Communications Co., Ltd. 4-1-62 Minoshima Hakata-ku, Fukuoka 812-8531 Japan
Kiyoshi Toyoda Panasonic Communications Co.、Ltd。4-1-62 Minoshima Hakata-Ku、Fukuoka 812-8531 Japan
EMail: toyoda.kiyoshi@jp.panasonic.com
Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA
Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale、CA 94086 USA
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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 implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。