RFC4141 日本語訳
4141 SMTP and MIME Extensions for Content Conversion. K. Toyoda, D.Crocker. November 2005. (Format: TXT=55606 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Toyoda
Request for Comments: 4141 PCC
Category: Standards Track D. Crocker
Brandenburg
November 2005
コメントを求めるワーキンググループK.豊田の要求をネットワークでつないでください: 4141年のPCCカテゴリ: 標準化過程D.医者ブランデンブルク2005年11月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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内容ヘッダーフィールドを統合します(許可証が認可した協力的なサービスを定義します)、仲介者による責任がある満足しているフォーム変換。
Toyoda & Crocker Standards Track [Page 1] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[1ページ]、2005年11月に内容変換のための拡大をまねます。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 バックグラウンド。 . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. 概要。 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. 記号法のコンベンション。 . . . . . . . . . . . . . . . . . 5 2. 適用性。 . . . . . . . . . . . . . . . . . . . . . . . . 5 3. 仕様を修理してください。 . . . . . . . . . . . . . . . . . . . . 5 3.1. 許可を送ります。 . . . . . . . . . . . . . . . . . . . 9 3.2. 能力を返します。 . . . . . . . . . . . . . . . . . 10 3.3. サービス. . . . . . . . . . . . . 12 4の次のホップ非サポート。 内容変換許可SMTP拡張子. . . . . . . . . 12 4.1。 内容変換許可サービス拡大定義。 . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. 郵送するCONPERMパラメタ。 . . . . . . . . . . . . . 13 4.3. 構文。 . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. 満足している交渉SMTP拡張子. . . . . . . . . . . . . . 13 5.1。 満足している交渉サービス拡大定義。 . . . . 13 5.2. CONNEGパラメタ、RCPT、-、.145.3 構文。 . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. 満足している特徴ヘッダーフィールド. . . . . . . . . . . . . . 16 7をまねてください。 満足している転向者ヘッダーフィールドをまねてください。 . . . . . . . . . . . . . . 16 8. 内容前のヘッダーフィールド. . . . . . . . . . . . . . 16 9をまねてください。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.1。 CONPERM交渉. . . . . . . . . . . . . . . . . . . 17 9.2。 例のCONNEG交渉。 . . . . . . . . . . . . . . . 18 9.3. 内容前です。 . . . . . . . . . . . . . . . . . . . . 19 10. セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 19 11. 承認. . . . . . . . . . . . . . . . . . . . . . . 20 12。 ダイレクトSMTPと参照. . . . . . . . . . . . . . . . . . . . . . . . . . 20付録A.CONNEG。 . . . . . . . . . . . . . . . 22 拡大. . . . . . . . . 23付録C.の付録B.使用組み合わせはコンテントタイプ登録証明書をまねます。 . . . . . . . . . . . 24
1. Introduction
1. 序論
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内容変換を可能にします。
Toyoda & Crocker Standards Track [Page 2] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[2ページ]、2005年11月に内容変換のための拡大をまねます。
1.1. Background
1.1. バックグラウンド
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]で使用される同じタイプの受入れられた表現情報を入れることです。 うまくいけば、受取人、または仲介者が限られた受取人によってサポートされたフォームにこれを翻訳できます。 この仕様はそのようなメカニズムを定義します。 それは受取人デバイスかシステムの能力にメッセージ内容フォームを合わせる手段を定義します、SMTPベースの交渉メカニズム[ESMTP1、ESMTP2]のMIME内容記述子と任意の使用を使用することによって。
1.2. Overview
1.2. 概要
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内容記述子で望ましい満足しているフォームについて説明します。 それは、それらのフォームの1つに内容を変換するために「許可」をどんな仲介者か受取人にも与えるかもしれません。別々に、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.
変換を実行するサービスが創始者によって提供された方向の間でバランスをとるために必要とする変換、受取人を代表して提供された方向、および仲介者の能力。 これは方向が顧問であるかどうか、または彼らが要件であることを意図するかどうか決定する必要性によって複雑にされます。 状況報告として指定された変換はできれば実行されますが、それらはメッセージ配送を変更しません。 対照的に、受取人が内容を処理できないと、要件として扱われる変換指定は配送を禁止するでしょう。
Toyoda & Crocker Standards Track [Page 3] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[3ページ]、2005年11月に内容変換のための拡大をまねます。
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,
* ホップごとの創始者によって発行された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 Contentヘッダーフィールド(Content満足している転向者、前、そして、*満足している特徴)が、満足しているヘッダーフィールドを当てて、実行された変換を記録します。
Toyoda & Crocker Standards Track [Page 4] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[4ページ]、2005年11月に内容変換のための拡大をまねます。
Figure 1: EXAMPLE RELAY ENVIRONMENT
図1: 例のリレー環境
+------------+ +-----------+
| Originator | | Recipient |
+------------+ +-----------+
||Posting Delivering/\
\/ ||
+--------+ +-----------------+ +--------+
| SMTP | | SMTP Relay | | SMTP |
| Client |--->| Server | Client |--->| Server |
+--------+ +--------+--------+ +--------+
+------------+ +-----------+ | 創始者| | 受取人| +------------+ +-----------+ ||任命配送/\\/|| +--------+ +-----------------+ +--------+ | SMTP| | SMTPリレー| | SMTP| | クライアント|、-、--、>| サーバ| クライアント|、-、--、>| サーバ| +--------+ +--------+--------+ +--------+
1.3. Notational Conventions
1.3. 記号法のコンベンション
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].
キーワード“MUST"、「必須NOT」“SHOULD"、「」 「5月」は「RFCsにおける使用が要件レベルを示すキーワード」[キーワード]で定義されるように本書では解釈されることになっているべきです。
2. Applicability
2. 適用性
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.
メカニズムは重要なリソース要件を変換を実行している仲介者に課すことができます。 さらに、仲介者はそれが変換を実行できるかどうかを知る前に、変換への責任を引き受けます。 また、デジタルに署名されるか、または暗号化された内容には、変換が可能でないことに注意してください、変換している仲介者が内容を解読して、再コード化できないなら。
3. Service Specification
3. サービス仕様
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ホスト(クライアントとサーバ)です。
Toyoda & Crocker Standards Track [Page 5] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[5ページ]、2005年11月に内容変換のための拡大をまねます。
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.
創始者はContent転向者MIME内容ヘッダーフィールドを通して都合のよいcontent typeを指定します。 満足しているヘッダーフィールドはそれらが適用するそれぞれの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サービス拡張子で要件のレベルに上げられます。 創始者が、変換制限が郵便為替サービスによって励行されるのを必要とするときだけ、CONPERMメカニズムが必要です。 許容できるcontent typeを提供できないなら、配送は全く行われることになっていません。
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.
目標システム能力はSMTPセッションのときにESMTP CONNEGサービス拡張子で伝えられます。 この情報は、実行されるかもしれませんが、配送に影響しない変換の範囲を制限するのに使用されます。
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が使用されているとき、変換は第1代受取人によってサポートされた創始者の許可と能力の情報の両方を得ることができる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リレーかサーバが内容変換を実行するとき、どの特定の変換をContent前にするかを記録します、そして、それぞれに関連しているContent-特徴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 Content-転向者ヘッダーフィールドを通して必要な変換結果を指定します。 また、創始者がContent-転向者ヘッダーフィールドを入れるなら、それは、内容の現在の書式を示すためにContent-特徴ヘッダーフィールドを含まなければなりません。 仲介者は、変換を実行するために承認としてこのヘッダーフィールドの存在を解釈するかもしれません。 そして、Content転向者ヘッダーフィールドが仲介者による誘導している変換のために唯一の手段であるときに、彼らは単に状況報告として機能します。 これらのヘッダーフィールドの指導を満たさない場合、最終的な配送に影響しません。
Toyoda & Crocker Standards Track [Page 6] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[6ページ]、2005年11月に内容変換のための拡大をまねます。
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 Content-転向者ヘッダーフィールドで指定されたものに制限しなければなりません。 変換を必要としますが、認可された変換を実行できないと、メッセージを創始者に返すでしょう。 CONPERMが使用されていなくて、また認可された変換を実行しないと、正常分娩取り扱いに影響しないでしょう。
Figure 2: CONPERM USAGE
図2: CONPERM用法
+------------+
| Originator |
+------------+
SMTP ||
or || CONPERM
SUBMIT \/
+--------+ +----------------+
| SMTP | SMTP | SMTP Relay |
| Client |----------->| Server | |
+--------+ CONPERM +--------+-------+
+------------+ | 創始者| +------------+ SMTP|| または|| CONPERMは\/+を提出します。--------+ +----------------+ | SMTP| SMTP| SMTPリレー| | クライアント|、-、-、-、-、-、-、-、-、-、--、>| サーバ| | +--------+ 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郵便為替サービス、受取人SHOULDを代表してサポートすることができる能力と、ESMTP CONNEGサービス拡張子で仲介者とコミュニケートしてください。
Figure 3: CONNEG USAGE
図3: CONNEG用法
+-----------+
| Recipient |
+-----------+
Capabilities||
\/
+----------------+ +--------+
| SMTP Relay | CONNEG | SMTP |
| | Client |<--------| Server |
+-------+--------+ +--------+
+-----------+ | 受取人| +-----------+ 能力|| \/ +----------------+ +--------+ | SMTPリレー| CONNEG| SMTP| | | クライアント| <、-、-、-、-、-、-、--、| サーバ| +-------+--------+ +--------+
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
仲介者にメッセージを受け取るとき、CONPERM方向を与えて、メッセージを送る前に、CONNEG指導を与えるかもしれません。 CONPERMとCONNEGは1メッセージあたり1個のベースを作動させて、ESMTP MAIL-FROM要求で発行されます。 CONNEG応答
Toyoda & Crocker Standards Track [Page 7] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[7ページ]、2005年11月に内容変換のための拡大をまねます。
information is provided on a per-recipient basis, through the
response to ESMTP RCPT-TO.
1受取人あたり1個のベースで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:
CONNEG能力情報を得る最初のCONPERM仲介者は変換を実行しなければなりません。 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.
* 受取人の部分集合の能力を合わせて、複数の変換されたコピーを作成してください。 各バージョンが別々の状態で次に、別々に受取人の適切な部分集合に送られて、別々の、そして、標準のSMTPセッションを使用している、規格、RFC2821.Rcpt、-、アドレスのリスト。
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.
変換に関する記録はContent前のヘッダーがさばくMIMEに置かれます。 内容の現在のフォームはMIME Content-特徴ヘッダーフィールドで説明されます。
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、-、リスト、分離してください、標準のSMTPセッション、そして、CONPERMメカニズムの継続的な使用でそれらの受取人にオリジナルコンテンツの伝達を続けてください。 したがって、まるで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の使用を終えるかもしれません。 しかしながら、新しい対象装置にメールを転送するものなどのいくつかのリレー環境がさらなる変換の利益を得るでしょう。 5月が使用し続けている仲介者
Toyoda & Crocker Standards Track [Page 8] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[8ページ]、2005年11月に内容変換のための拡大をまねます。
CONPERM or MAY re-initiate CONPERM use when they have knowledge of
possible variations in a target device.
CONPERMか彼らに対象装置の可能な変化に関する知識があるときの5月の再開始CONPERM使用。
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に変えるかもしれません。 次に、C.Howeverへの変換y変化B、変換yが直接フォームAを受け入れて、フォームDを製作したのは、可能です。(フォームには、Cオリジナルの情報の以上があります)。
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要求が「浸水してください」というパラメタを含んでいるなら、新聞販売店は提供された(変換される)メッセージ内容の正確なコピーを返すべきです。 これは、創始者がどんな変換の結果も点検することを許可するでしょう。
3.1. Sending Permission
3.1. 送付許可
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サービス拡張子とContent-転向者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を通してサポートされた能力
Toyoda & Crocker Standards Track [Page 9] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[9ページ]、2005年11月に内容変換のための拡大をまねます。
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サーバーを持っているのは許容できます--なにもCONNEGを提供していなく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を提供するかもしれません、変換を実行できないで、移行経路の残りに沿って、または、対象装置かシステムで変換を実行できるのを知っているなら。
3.2. Returning Capabilities
3.2. 戻っている能力
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サービスへの満足しているフォーム能力の発表をアレンジします。 サーバが受取人を代表してCONNEGに情報を発行するのを可能にするのが受取人とサーバの間のかなりのメカニズムを必要とするかもしれないことに注意してください。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つの局面、受取人とESMTPサーバの間では、CONNEG ESMTPサービス拡張子を提供するのは受取人によって直接サポートされたものを超えて能力を提供するのを含むかもしれません。 特に、サーバ(サーバと受取人の間の他の仲介者)はそれらが受取人の能力に変換できる能力をサポートするかもしれません。 結果が変換されるメッセージの関連Content転向者ヘッダーフィールドで指定されたセットに許容できる限り、これらの変換の詳細は、受取人/サーバメカニズムの一部であり、現在の仕様の範囲をそらせます。
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:
CONPERMメカニズムによると、メッセージが処理されているとき、次のホップESMTPサーバがそれを反応させるなら、CONNEGをサポートして、その時はSMTPクライアントです:
1) MUST request CONNEG information
1) CONNEG情報を要求しなければなりません。
Toyoda & Crocker Standards Track [Page 10] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[10ページ]、2005年11月に内容変換のための拡大をまねます。
2) MUST perform the requisite conversions, if possible, before
sending the message to the next-hop SMTP server
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:
Content-転向者MIMEヘッダーフィールドで指定されるように変換を実行するとき、Clientは実行しなければなりません:
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) Content前のヘッダーフィールドとContent-特徴ヘッダーフィールドを変換されたそれぞれのMIME身体部分に加えてください、どんな既存のContent-特徴ヘッダーフィールドも取り除いて。
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、-、受取人の部分集合に、可能な最も良い変換を提供する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.
この交差点の結果が受け取り人の表現の零集合であるなら、変換失敗としてその受け取り人への配送を扱わなければなりません。
If handling is subject to the CONPERM mechanism and:
そして、取り扱いはCONPERMメカニズムを受けることがある、:
* the next-hop SMTP host does not indicate that it can
represent the target's capabilities through CONNEG, but
* 次のホップSMTPホストは、しかし、CONNEGを通して目標の能力を表すことができるのを示しません。
Toyoda & Crocker Standards Track [Page 11] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[11ページ]、2005年11月に内容変換のための拡大をまねます。
* does respond that it can support CONPERM, then the client
SMTP MUST send the existing content, if all other SMTP
transmission requirements are satisfied.
* 他のすべてのSMTPトランスミッション要件が満たされているなら、それがCONPERMをサポートすることができて、次に、クライアントSMTP MUSTが既存の内容を送ると応答します。
If handling is not subject to the CONPERM mechanism, then
conversion failures do not affect message delivery.
取り扱いはCONPERMメカニズムを受けることがないなら、変換失敗がメッセージ配送に影響しません。
3.3. Next-Hop Non-Support of Service
3.3. サービスの次のホップ非サポート
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
ClientがCONPERMメカニズムに参加していますが、次のホップSMTPサーバがCONPERMかCONNEGをサポートしないで、その時がSMTPクライアントであるなら
1) MUST terminate the session to the next-hop SMTP server, without
sending the message
1) メッセージを送らないで、次のホップの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:
ClientがCONPERMメカニズムに参加していて、次のホップSMTPサーバが個々のRCPT-TO受け取り人にCONNEGをサポートしますが、能力を全く提供しないなら、その受取人のための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によると、受け取り人を処理し続けてください。
4. Content Conversion Permission SMTP Extension
4. 内容変換許可SMTP拡張子
4.1. Content Conversion Permission Service Extension Definition
4.1. 内容変換許可サービス拡大定義
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"
"CONPERM"
3) A parameter using the keyword "CONPERM" is added to the MAIL-FROM
command.
3) "CONPERM"が追加されるキーワードを使用するパラメタ、コマンドから、郵送してください。
4) The server responds with acceptance or rejection of support for
CONPERM, for this message.
4) サーバはCONPERM、このメッセージのサポートの承認か拒絶で反応します。
Toyoda & Crocker Standards Track [Page 12] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[12ページ]、2005年11月に内容変換のための拡大をまねます。
4.2. CONPERM Parameter to Mail-From
4.2. 郵送するCONPERMパラメタ
Parameter:
パラメタ:
CONPERM
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身体部分へのContent-転向者ヘッダーフィールドで位置しています。
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-CONPERMを発行して、クライアントがCONPERM要件でメッセージを受け取ったことなどのこのメッセージのためのCONPERMサービスに参加しているなら、クライアントはメール-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.
クライアントがメール-FROMでCONPERMを指定しますが、サーバがCONPERMパラメタをサポートしないなら、サーバは504-CONPERM回答でメール-FROMコマンドを拒絶しなければなりません。
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.
クライアントがメール-FROMのCONPERMパラメタを発行するなら、サーバはこの仕様に従わなければなりません。 CONPERMによると、メッセージをリレーしなければなりませんか、またはCONNEG情報によると、それはメッセージを変換しなければなりません。
4.3. Syntax
4.3. 構文
Content-Conversion-Permission = "CONPERM"
満足している変換許可は"CONPERM"と等しいです。
5. Content Negotiation SMTP Extension
5. 満足している交渉SMTP拡張子
5.1. Content Negotiation Service Extension Definition
5.1. 満足している交渉サービス拡大定義
1) The name of the SMTP service extension is:
1) SMTPサービス拡張子の名前は以下の通りです。
"Content-Negotiation"
「満足している交渉」
Toyoda & Crocker Standards Track [Page 13] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[13ページ]、2005年11月に内容変換のための拡大をまねます。
2) The EHLO keyword value associated with this extension is:
2) この拡大に関連しているEHLOキーワード価値は以下の通りです。
"CONNEG"
"CONNEG"
3) A parameter, using the keyword "CONNEG", is added to the RCPT-TO
command.
3) "CONNEG"というキーワードを使用して、パラメタに追加される、RCPT、-、命令してください。
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アドレスに関連しています。
5.2. CONNEG Parameter to RCPT-TO
5.2. CONNEGパラメタ、RCPT、-
Parameter:
パラメタ:
CONNEG
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-CONNEGを発行するなら、クライアントはRCPT-TO要求におけるCONNEGパラメタを発行しなければなりません。 メッセージはCONPERM要件を受けることがなくて、サーバが250-CONNEGを発行するなら、クライアントは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:
この交差点の結果が表現の零集合であるなら、Client処理は次のホップサーバがCONPERMを提供したかどうかによります、CONNEGと同様に:
Toyoda & Crocker Standards Track [Page 14] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[14ページ]、2005年11月に内容変換のための拡大をまねます。
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を受けることがあるなら、Clientが次のホップにオリジナルコンテンツを伝えて、CONPERM要件を続けるかもしれません。
2) Otherwise, the Client MUST treat the conversion as failed.
2) さもなければ、Clientは失敗されるとして変換を扱わなければなりません。
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.
交差点の結果がヌルでないなら、クライアントSHOULDは「最も高い」レベルのサーバの能力にデータを変換します。最も高いレベルの決断は変換を実行しているホストに任せます。
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.
それぞれが前の身体部分を示すContent前のヘッダーフィールドが身体部分で形成しなければならないMIMEとContent-特徴ヘッダーフィールドを変換しました、新しい身体部分書式を示して。
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を通してその情報を提供しなければなりません。 サーバはサーバが、受取人が提供された内容のフォームを処理できるのを確実にすることができるならまだ作者のContent-転向者仕様の規制を満たしている間、受取人によってサポートされるより広いリストを提供するかもしれません。
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要求への応答はマルチ系列RCPT-TO回答になるでしょう。 うまくいっている(250)応答のために、少なくとも応答の最初の系列はCONNEG以外のRCPT-TO情報を含まなければなりません。 追加応答系列はCONNEGのためのものです。 ラインバッファサイズの変化のため問題を避けるために、一連の系列として総パラメトリックリストを提供しなければなりません、"250-CONNEG"がある各始め、最終ラインを除いて。(それは、「250CONNEG」です)。
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]で受入れられた同じ範囲の仕様をカバーしなければなりません。
5.3. Syntax
5.3. 構文
Content-Negotiation = "CONNEG"
Capability = { <filter> specification,
as per [SYN] }
満足している交渉は"CONNEG"能力=と等しいです。[SYN]に従って<フィルタ>仕様
Toyoda & Crocker Standards Track [Page 15] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[15ページ]、2005年11月に内容変換のための拡大をまねます。
6. MIME Content-Features Header Field
6. MIME満足している特徴ヘッダーフィールド
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].
Content-特徴ヘッダーフィールドはヘッダーフィールドが起こるMIME身体部分のための内容の最新版の特性について説明します。 それぞれのMIME身体部分への別々のContent-特徴ヘッダーフィールドがあります。 このヘッダーフィールドのための仕様は[FEAT]に含まれています。
7. MIME Content-Convert Header Field
7. MIME満足している転向者ヘッダーフィールド
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.
満足している転向者であることは、関連内容のための都合のよい変換を指定するヘッダーフィールドです。 それは本書では定義された他のメカニズムなしで使用されるかもしれません。 存在しているなら、このヘッダーフィールドを変更されていなく運ばれて、受取人に提供しなければなりません。 不在には、満足している創始者は内容変換に関して指導を全く提供しません、そして、仲介者SHOULD NOTは内容変換を実行します。
In the extended ABNF notation, the Content-Convert header field is defined as follows:
拡張ABNF記法では、Content-転向者ヘッダーフィールドは以下の通り定義されます:
Convert = "Content-convert" ":"
permitted
「転向者は「満足している転向者」と等しい」:、」 受入れられます。
Permitted = "ANY" / "NONE" / permitted-list
「いくらかでもは= 」受入れられた/「なにも」/リストであることで受入れられます。
permitted-list = { explicit list of permitted
final forms, using <filter>
syntax in [SYN] }
受入れられたリスト=[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.
また、Content-転向者ヘッダーフィールドが存在しているなら、Content-特徴ヘッダーフィールドも、Contentの現在のフォームについて説明するために存在していなければなりません。
8. MIME Content-Previous Header Field
8. 内容前のヘッダーフィールドをまねてください。
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
仲介者が関連内容の変換を実行したとき、仲介者は前の表現の詳細を記録しなければなりません。(変換は表現から実行されました)。 この情報は部分であるContent前のヘッダーフィールドに置かれます。
Toyoda & Crocker Standards Track [Page 16] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[16ページ]、2005年11月に内容変換のための拡大をまねます。
of the MIME body-part with the converted content. There is a separate header field for each converted MIME body-part.
変換された内容があるMIME身体部分について。 それぞれの変換された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身体部分へのContent-特徴ヘッダーフィールドを作成するか、または改訂することによって、変換の結果の詳細を記録しなければなりません。
In the extended [ABNF] notation, the Content-Previous header field is defined as follows:
拡張[ABNF]記法では、Content前のヘッダーフィールドは以下の通り定義されます:
previous = "Content-Previous" [CFWS] ":"
[CFWS]
date by type
「「内容前」の前の=[CFWS]」:、」 [CFWS]はタイプでデートします。
date = "Date " [CFWS] date-time [CFWS] ";"
[CFWS]
「「」[CFWS]日付-時間[CFWS]の日付を入れてください」という日付=」 [CFWS]
by = "By " [CFWS] domain [CFWS] ";"
[CFWS]
「=」[CFWS]ドメイン[CFWS]」;、」 [CFWS]
type = { content characteristics, using
<filter> syntax in [SYN] }
=をタイプしてください。[SYN]の<フィルタ>構文を使用する満足している特性
The Date field specifies the date and time at which the indicated representation was converted into a newer representation.
Date分野は示された表現が、より新しい表現に変換された日時を指定します。
The By field specifies the domain name of the intermediary that performed the conversion.
By分野は変換を実行した仲介者のドメイン名を指定します。
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.
仲介者は、Content前のヘッダーフィールドを引き出すのを選ぶかもしれません、身体部分に、その身体部分の既に既存のContent-特徴ヘッダーフィールドから、そのヘッダーフィールドを現在の表現の記述に取り替える前に。
9. Examples
9. 例
9.1. CONPERM Negotiation
9.1. CONPERM交渉
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
S: 220 example.com IFAX C: EHLO example.com S: 250 example.com S: 250-DSN S: 250 CONPERM C: FROM: May@some.example.com CONPERM Sに郵送してください: 250 <May@some.example.com 、gt;、創始者OK C: RCPT TO:<June@some.example.com 、gt;、S: 250-<June@some.example.com 、gt;、受取人OK
Toyoda & Crocker Standards Track [Page 17] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[17ページ]、2005年11月に内容変換のための拡大をまねます。
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
C: データS: 354 間違いなく、データCを送ってください: MIMEコンテントタイプ: TIFF-FX Perがある<<RFC2822メッセージ: (JBIGサイズ-x=2150/254紙サイズ=400TIFF最小量のイメージファイル構造=dpi=画像符号化=手紙) MIME身体部分が含んでいて: 満足している転向者: (&(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メッセージはCを受け入れました: Sをやめてください: 221さよなら
9.2. Example CONNEG Negotiation
9.2. 例のCONNEG交渉
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: 220 example.com IFAX C: EHLO example.com S: 250 example.com S: 250-DSN S: 250 CONNEG C: FROM:<May@some.example.com に郵送してください、gt;、S: 250 <May@some.example.com 、gt;、創始者OK C: RCPT TO:<June@ifax1.jp 、gt;、CONNEG S: 250-<June@some.example.com 、gt;、受取人OK S: 250-CONNEG、((イメージファイル構造=いさかい最小量)のS: 250-CONNEG(MRC-モード=0)S: 250-CONNEG(=を着色して、2進にする)S: 250-CONNEG、(|、((dpi=204)
Toyoda & Crocker Standards Track [Page 18] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[18ページ]、2005年11月に内容変換のための拡大をまねます。
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
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(画像符号化は[MH、MR、MMR]と等しいです) S: 250-CONNEG(サイズx<は2150/254と等しいです) S: 250-CONNEG(紙サイズ=[手紙、A4]) S: 250 CONNEG(ua-メディアは文房具と等しいです) ) C: データS: 354 間違いなく、データCを送ってください: MIMEコンテントタイプ: TIFF-FX Perがある<<RFC2822メッセージ: (JBIGサイズ-x=2150/254紙サイズ=400TIFF最小量のイメージファイル構造=dpi=画像符号化=手紙) >>S: 250メッセージはCを受け入れました: Sをやめてください: 221さよなら
9.3. Content-Previous
9.3. 内容前です。
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) )
内容前: 10:52:37+0200と火曜日、2001年7月1日の日付を入れてください。 By relay.example.com。 ((イメージファイル構造=いさかい最小量の)(MRC-モード=0)(=を着色して、2進にします)((dpi=400)(dpi-xyratio=1))((画像符号化はJBIGと等しいです)(イメージをコード化する規制はJBIG-T85と等しいです)(JBIG-しまサイズ=128))(サイズ-x=2150/254)(紙サイズ=A4)(ua-メディア=文房具))
10. Security Considerations
10. セキュリティ問題
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.
このサービスは受取人を代表して能力の公開を求めます。 この仕様の範囲の外に要請者と応答者がアイデンティティを認証したことを決定するためのメカニズムがあります。 これらのメカニズムが公共の分配に、安全な情報の公開を可能にすることを意図します。 したがって、どんな固有のセキュリティー対策の必要性もありません。
Toyoda & Crocker Standards Track [Page 19] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[19ページ]、2005年11月に内容変換のための拡大をまねます。
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オプションの使用はメール移行経路に沿った仲介者で満足している変換を可能にします。 コンテンツが暗号化されているとき、仲介者は変換を実行できません、材料を合わせる関連秘密に近づく手段を持っていないと予想されるので。 内容が署名されますが、暗号化されないとき、変換は署名を無効にするでしょう。 自然によって、この仕様は仲介者MTAsによる潜在的に限りない計算に備えます、そして、変換の量が必要です。 さらに、この計算負担は-それを考えて、サービス攻撃では、インターネット・メールが、仲介者がすべてのインターネットソースからメッセージを受け取ることを通常許可するという否定に機会を与えるかもしれません。
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は以前に可能でなかった仲介者動作を可能にするよりむしろ協力的メカニズムを提供します。 仲介者はそれら自身のイニシアチブのときに既に変換をします。 したがって、メカニズムは本質的には受取人好みを明かす以外の安全上の配慮を全く導入しません。
11. Acknowledgements
11. 承認
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.
グラハムKlyneとエリックBurgerは大規模で、勤勉なレビューと提案を提供しました。 キース・ムーア、Giatハナ、およびジョエル・アルペルンは確立したメール習慣への仕様の統合を改良しながらもたらされるそれをフィードバックに提供しました。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Toyoda & Crocker Standards Track [Page 20] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[20ページ]、2005年11月に内容変換のための拡大をまねます。
[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.クロッカー、「メッセージサービスのためのNegotiationがメールに基礎づけた内容」、RFC3297、2002年7月。
[DSNSMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications (DSNs)", RFC
3461, January 2003.
[DSNSMTP]ムーア、K.、「配送状態通知(DSNs)のためのシンプルメールトランスファプロトコル(SMTP)サービス拡大」、RFC3461、2003年1月。
[DSNFMT] Moore, K. and G. Vaudreuil, "An Extensible Message Format
for Delivery Status Notifications", RFC 3464, January
2003.
[DSNFMT] ムーアとK.とG.ボードルイ、「配送状態通知のための広げることができるメッセージ・フォーマット」、RFC3464、2003年1月。
[SYSCOD] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC
3463, January 2003.
[SYSCOD] ボードルイ、G.、「高められたメールシステムステータスコード」、RFC3463、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. N.と解放されて、ローズとM.とStefferud、E.とD.クロッカー、「SMTPサービス拡張子」、STD10、RFC1869、1995年11月。
[ESMTP2] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[ESMTP2] Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
[FEAT] Klyne, G., "Indicating Media Features for MIME Content",
RFC 2912, September 2000.
[功績] Klyne、G.、「MIME内容のためのメディア機能を示します」、RFC2912、2000年9月。
[IMF] Resnick, P., "Internet Message Format", RFC 2822, April
2001.
[IMF] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[SYN] Klyne, G., "A Syntax for Describing Media Feature Sets",
RFC 2533, March 1999.
[SYN] 1999年3月のKlyne、G.、「特徴が設定するメディアを説明するための構文」RFC2533。
[MEDTYP] IANA, "MIME Media Types",
<http://www.iana.org/assignments/media-types>
[MEDTYP]IANA、「MIMEメディアタイプ」、<は>をhttp://www.iana.org/課題/メディアでタイプします。
[CFWS] Alvestrand, H., "Content Language Headers", RFC 3282, May
2002.
[CFWS]Alvestrand、H.(「満足している言語ヘッダー」、RFC3282)は2002がそうするかもしれません。
12.2. Informative References
12.2. 有益な参照
[RFC3238] Floyd, S. and L. Daigle, "IAB Architectural and Policy
Considerations for Open Pluggable Edge Services", RFC
3238, January 2002.
[RFC3238] フロイドとS.とL.Daigle、「開いているPluggable縁のサービスのためのIAB建築するのと方針問題」、RFC3238、2002年1月。
Toyoda & Crocker Standards Track [Page 21] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[21ページ]、2005年11月に内容変換のための拡大をまねます。
Appendix A. CONNEG with Direct SMTP
ダイレクトSMTPと付録A.CONNEG
This Appendix is descriptive. It only provides discussion of usage issues permitted or required by the normative text
このAppendixは描写的です。 それは標準のテキストによって受入れられたか、または必要とされた用法問題の議論を提供するだけです。
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.
Originatorのシステムはユーザレベル機能を創始者に提供します、そして、それは送付メッセージのためのSMTP Clientを含んでいます。 したがって、「任命」というメールの正式なステップはそうするプロセスです。Originatingシステムの中で内部である、または仮想です。 受取人のサービスは、受取人のためにユーザレベル機能を含んでいて、メッセージを受け取るためにSMTPサーバーを含んでいます。 したがって、「配送」というメールと「領収書」の正式なステップはそうです。Receivingシステムの中で内部である、または仮想です。
Figure 4: DIRECT CONNEG
図4: ダイレクトCONNEG
Originating system Receiving system
+------------------+ +------------------+
| +------------+ | | +-----------+ |
| | Originator | | | | Recipient | |
| +------------+ | | +-----------+ |
| ||Posting | | /\Receiving |
| \/ | | || |
| +---------+ | | +--------+ |
| | SMTP |<---|-------|----| SMTP | |
| | Client |----|-------|--->| Server | |
| +---------+ | | +--------+ |
+------------------+ +------------------+
システムReceivingシステム+を溯源します。------------------+ +------------------+ | +------------+ | | +-----------+ | | | 創始者| | | | 受取人| | | +------------+ | | +-----------+ | | ||任命| | /\受信| | \/ | | || | | +---------+ | | +--------+ | | | SMTP| <、-、--、|、-、-、-、-、-、--、|、-、-、--、| SMTP| | | | クライアント|、-、-、--、|、-、-、-、-、-、--、|、-、--、>| サーバ| | | +---------+ | | +--------+ | +------------------+ +------------------+
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.
この場合、CONPERMはSMTP Clientが起因するシステムの一部であるので必要でなく、既に必要な許可を持ちます。 同様に、受取人の能力を知るのはSMTPサーバーが確かになるでしょう、サーバが受電方式の一部であるので。
Therefore, Direct Mode email transmission can achieve content capability and form matching by having:
したがって、Direct Modeメール送信は、満足している能力を実現して、以下を持っていることによって、マッチングを形成できます。
Toyoda & Crocker Standards Track [Page 22] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[22ページ]、2005年11月に内容変換のための拡大をまねます。
* 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 Relayとそれが関連しているDelivering SMTPサーバーの間で入賞します。
* That is, the Client and Server MUST employ CONNEG and the
Client MUST perform any requisite conversions.
* すなわち、ClientとServerはCONNEGを使わなければなりません、そして、Clientはどんな必要な変換も実行しなければなりません。
Appendix B. Using Combinations of the Extensions
拡大の組み合わせを使用する付録B.
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.
この仕様は多くのメカニズムを定義します。それらが皆、一緒に使用されるのが必要ではありません。 例えば、Introductionで都合のよい変換を対実施された制限を変換に指定する記載するところの違いについて議論します。 このAppendixはこの仕様に基づき定義された完全なセットよりさらに使用するように求めないかもしれないシナリオについて説明します。 また、それは仲介者が変換を実行するのを強制する状態をまとめます。
This Appendix is descriptive. It only provides discussion of usage issues permitted or required by the normative text
このAppendixは描写的です。 それは標準のテキストによって受入れられたか、または必要とされた用法問題の議論を提供するだけです。
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. 2から郵送するCONPERMパラメタ。 RCPT-TO3へのCONNEGパラメタ。 満足している転向者ヘッダーフィールド4をまねてください。 内容前のヘッダーフィールド5をまねてください。 MIME満足している特徴ヘッダーフィールド
B.1. Specifying Suggested Conversion Constraints
B.1。 指定は変換規制を示しました。
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-転向者ヘッダーフィールドの使用は創始者の好みを指定します。 これはどんな要件も変換に課しません。 それは単に顧問です。
B.2. Specifying Required Conversion Constraints
B.2。 指定は変換規制を必要としました。
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 Content-転向者仕様がESMTP CONPERMオプションに結びつけられると、創始者の都合のよい変換の仕様は要件のレベルに上がります。 Content-転向者ヘッダーフィールドで指定されたもの以外に、他の変換は全く受入れられません。
Note that the presence of both mechanisms does not require that
conversions be performed. Rather, it constrains conversions,
should they occur.
両方のメカニズムの存在が、変換が実行されるのを必要としないことに注意してください。 むしろ、起こるなら、それは変換を抑制します。
Toyoda & Crocker Standards Track [Page 23] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[23ページ]、2005年11月に内容変換のための拡大をまねます。
B.3. Accepting All Forms of Content
B.3。 すべてのフォームの中身を受け入れます。
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要求は対象装置に伝播されるべきです。
B.4. When Conversion is Required
B.4。 ConversionがRequiredであるときに
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のContentひそかなヘッダーフィールドがメッセージに存在しています。
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 CONNEGも同じノードで有効です。
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. そして少なくとも1つの満足しているフォームがContent転向者リストとCONNEGリストに存在している。
6. The intermediary is able to convert from the current form to
one of the forms listed in both Content-Convert and CONNEG.
6. 仲介者は現在のフォームからContent-転向者とCONNEGの両方に記載された書式の1つに変えることができます。
Appendix C. MIME Content-Type Registrations
付録C.MIMEコンテントタイプ登録証明書
C.1. Content-Convert
C.1。 満足している転向者
Header field name:
Content-Convert
ヘッダーフィールド名: 満足している転向者
Applicable protocol:
Mail (RFC 2822)
適切なプロトコル: メール(RFC2822)
Status:
Proposed Standard
状態: 提案された標準
Author/Change controller:
IETF
コントローラを書くか、または変えてください: IETF
Specification document(s):
RFC 4141.
仕様ドキュメント: RFC4141。
Toyoda & Crocker Standards Track [Page 24] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[24ページ]、2005年11月に内容変換のための拡大をまねます。
Related information:
None.
関連情報: なし。
C.2. Content-Previous
C.2。 内容前です。
Header field name:
Content-Previous
ヘッダーフィールド名: 内容前です。
Applicable protocol:
Mail (RFC 2822)
適切なプロトコル: メール(RFC2822)
Status:
Proposed Standard
状態: 提案された標準
Author/Change controller:
IETF
コントローラを書くか、または変えてください: IETF
Specification document(s):
RFC 4141, Section 8
仕様ドキュメント: RFC4141、セクション8
Related information:
None.
関連情報: なし。
Authors' Addresses
作者のアドレス
Kiyoshi Toyoda Panasonic Communications Co., Ltd. 4-1-62 Minoshima Hakata-ku, Fukuoka 812-8531 Japan
株式会社4-1-62Minoshima博多区、パナソニックのコミュニケーション福岡日本の豊田清812-8531
EMail: toyoda.kiyoshi@jp.panasonic.com
メール: toyoda.kiyoshi@jp.panasonic.com
Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA
デーヴ医者ブランデンブルクインターネットワーキング675はDriveカリフォルニア94086サニーベル(米国)を小綺麗にします。
Phone: +1.408.246.8253 EMail: dcrocker@bbiw.net
以下に電話をしてください。 +1.408 .246 .8253 メール: dcrocker@bbiw.net
Toyoda & Crocker Standards Track [Page 25] RFC 4141 SMTP & MIME Extensions for Content Conversion November 2005
豊田と医者規格は、RFC4141SMTPを追跡して[25ページ]、2005年11月に内容変換のための拡大をまねます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Toyoda & Crocker Standards Track [Page 26]
豊田と医者標準化過程[26ページ]
一覧
スポンサーリンク
