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
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).
著作権（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.
メッセージ発信元は、時々、受信者が処理できないか、好ましいより低品質のフォームを処理しないことを好むだろう形でコンテンツを送信します。そのようなコンテンツは、同じ情報または制約情報と、許容可能な形態に変換する必要がある（例えば、黒と白の色の変化）。ストアアンドフォワードの環境では、仲介によって行われるこの変換を持っていると便利かもしれません。この仕様は、二つの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,
発信元によって発行された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：例RELAY ENVIRONMENT
+------------+ +-----------+
| 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].
キーワード「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」と「MAY」このドキュメントの「要件レベルを示すためにRFCsにおける使用のためのキーワード」[キーワード]で定義されているように解釈されます。
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拡張三個の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本体部分で起こります。つまり、各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機構がのみ必要です。許容可能なコンテンツタイプが配信できない場合は、何の配信が行われてはなりません。
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をサポートするか、または適切な変換を実行するために次のホップにメッセージを送信することができない場合、それはメッセージの送信を終了し、ステータスコード5.6.3で、創始者に[DSNSMTP、DSNFMT、SYSCOD]を返します（変換が必要なく、サポートされていません）。
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-前に行われ、それぞれに関連付けられたコンテンツ・機能の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コンテンツ変換ヘッダフィールドを介して所望の変換結果を指定します。発信者はコンテンツ変換ヘッダフィールドが含まれている場合、それはまた、コンテンツの現在形を示すために、コンテンツ・機能ヘッダフィールドを含める必要があります。仲介は、変換を実行するための権限として、このヘッダフィールドの存在を解釈するかもしれません。コンテンツ変換のヘッダフィールドは、仲介による変換を誘導するための唯一の手段である場合には、その後、彼らは唯一の勧告としての役割を果たす。これらのヘッダフィールドの指針を満たすために失敗すると、最終的な配送に影響を与えません。
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：USAGEを実現
+------------+
| 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のUSAGE
+-----------+
| 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は、メッセージごとに動作し、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:
変換は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.
*受信者のサブセットの能力をマッチング、複数の変換されたコピーを作成します。各バージョンは、その後独立し、標準RFC2821.Rcpt-にアドレスのリストを持つ独立した、標準の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-にリストと別の、標準の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の使用を終了することができます。しかし、そのような新しいターゲットデバイスにそれらの再指示メールなど一部のリレー環境では、さらに変換の恩恵を受ける。仲介は使い続けるかもしれません
CONPERM or MAY re-initiate CONPERM use when they have knowledge of possible variations in a target device.
CONPERMまたはそれらがターゲットデバイスで可能な変形の知識を持っている場合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は、コンテンツフォームBへのコンテンツのフォームAを変えることができます。その後、変換Yは、変換Yが直接フォームAを受け入れ、C.よりも元の情報をより多く有するフォームDを製造したかもしれない可能性がある、しかし、CにBを変更します
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」パラメータが含まれている場合、配信エージェントが配信（変換）メッセージ内容の正確なコピーを返すべきです。これは、任意の変換（S）の結果を検査する発信元を許可します。
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.
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サービスへのコンテンツのフォーム機能のアナウンスを配置します。受信者に代わって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.
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:
ネクストホップESMTPサーバーは、メッセージがCONPERMメカニズム、そしてSMTPクライアントに応じて処理されているとき、それはCONNEGをサポートしていると応答した場合：
1) MUST request CONNEG information
1）CONNEG情報を要求しなければなりません
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:
変換を行う際にコンテンツ変換の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
* 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を介してターゲットの機能を表現することができることを示すものではありませんが、
* 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伝送要件が満たされていれば、クライアントSMTPは、既存のコンテンツを送らなければなりません、それはCONPERMをサポートできることを応答します。
If handling is not subject to the CONPERM mechanism, then conversion failures do not affect message delivery.
取り扱いがCONPERMメカニズムの対象とならない場合は、変換エラーは、メッセージの配信には影響しません。
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メカニズムに参加しているが、次のホップの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:
：クライアントがCONPERMメカニズムに参加しているとネクストホップ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」を使用してパラメータは、メールからのコマンドに追加されます。
4) The server responds with acceptance or rejection of support for CONPERM, for this message.
4）サーバは、このメッセージを、CONPERMに対するサポートの受諾または拒否で応答します。
Parameter:
パラメータ：
CONPERM
conpero
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-CONPERMを発行し、クライアントがこのメッセージのCONPERMサービスに参加している場合 - などCONPERM要件を持つメッセージを受信したことなどによって - クライアントはMUST 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-CONPERM応答でMAIL-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.
クライアントは、MAIL FROM-にCONPERMパラメータを発行した場合、サーバはこの仕様に従わなければなりません。それはCONPERMに応じてメッセージを中継しなければならない、またはそれはCONNEG情報に従ってメッセージを変換する必要があります。
Content-Conversion-Permission = "CONPERM"
コンテンツ変換の許可=「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"
"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
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要件およびサーバーの問題250-CONNEGの対象となる場合は、現在のセッションのためにそのEHLO応答の一部として、クライアントは、RCPT-への要求に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:
この交差点の結果は、表現の空集合である場合、クライアント処理は、次ホップのサーバは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.
各新しい身体部分の形状を示す、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パラメータをサポートしていない場合、サーバーはRCPT TO-504の返信での受取を拒絶しなければなりません。
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を通じてその情報を提供しなければなりません。サーバは、サーバがまだ作者のコンテンツ変換仕様（S）の制約を満たしつつ、配信されるコンテンツの形式は、受信者が処理できるようにすることができた場合、受信者によってサポートされているよりも、より広範なリストを提供することができます。
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）応答のために、少なくとも応答の最初の行は、RCPT TO-情報CONNEG以外が含まれている必要があります。追加の応答ラインがCONNEGのためのものです。ラインバッファサイズの変動に起因する問題を回避するために、総パラメトリックリストは「250 CONNEG」である最後の行を除いて、一連のラインとして「250-CONNEG」の各先頭を設けなければなりません。
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本体部分のためのコンテンツの現在のバージョンの特性を記述する。個別のコンテンツの機能は、各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.
コンテンツ変換は、関連コンテンツのための好適な変換を指定するヘッダフィールドです。それは、この文書で定義された他のメカニズムせずに使用することができます。存在する場合、このヘッダーフィールドは、未修飾運ばれ、受信者に配信されなければなりません。その不在では、コンテンツ発信元は、コンテンツの変換についてのガイダンスを提供していない、との仲介は、コンテンツ変換を実行しないでください。
In the extended ABNF notation, the Content-Convert header field is defined as follows:
次のように拡張されたABNF表記法では、コンテンツ変換ヘッダフィールドが定義されています。
Convert = "Content-convert" ":" permitted
"= "のContent-変換" 変換：" 許可
Permitted = "ANY" / "NONE" / permitted-list
許可= "ANY" / "NONE" /許さないリスト
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.
許可変換が「ANY」として指定されている場合、仲介者は、それが適切とみなす任意の変換を実行することができます。
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.
許可変換が「NONE」として指定されている場合、仲介者は、ターゲットデバイスまたはシステムは、コンテンツの元の形式をサポートしていない場合でも、この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本体部分の一部であるコンテンツ前のヘッダフィールドに置かれます。各変換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]表記では、Content-前ヘッダフィールドが定義されます。
previous = "Content-Previous" [CFWS] ":" [CFWS] date by type
前の=の "Content-前の" [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.
日付フィールドには、指示された表現が、新しい表現に変換された日付と時刻を指定します。
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.
仲介者はそのヘッダフィールドは現在の表現の記述に置き換えされる前に、その身体部分に既存のContent-特長ヘッダフィールドから、身体部分のために、コンテンツ前のヘッダフィールドを導出することを選択するかもしれません。
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：May@some.example.com CONPERM S：MAIL FROM：いくつかの@ 250 <月。 example.com>創始OK C：RCPT TO：<June@some.example.com> S：250- <June@some.example.com>受信者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
C：データS：354さて、送信データC：<< RFC 2822のMIMEコンテンツタイプを有するメッセージ：TIFF-FX当たり：（イメージファイル構造= TIFF-最小DPI = 400画像符号化= JBIGサイズ-X = 2150/254用紙サイズ=レター）を含むMIMEボディパーツ付き：コンテンツ変換：（＆（画像ファイル構造= TIFF-最小限）（MRC-モード= 0）（色=バイナリ）（|（＆（ DPI = 204）（DPI-xyratio = [204/98204/196]））（＆（DPI = 200）（DPI-xyratio = [200 / 100,1]））（＆（DPI = 400）（DPI-xyratio = 1）））（|（画像符号化= [MH、MR、MMR]）（＆（画像符号化= JBIG）（画像符号化制約= JBIG-T85）（JBIGストライプサイズ= 128）） ）（サイズX <= 254分の2150）（用紙サイズ= [レター、A4]）（UAメディア=文房具））>> S：Sを終了：221別れ250メッセージは、Cを受け付け
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：<May@some.example.com> S：MAIL FROM：250 <月いくつかの@ .example.comの>発信OK C：RCPT TO：<June@ifax1.jp> CONNEG S：250- <June@some.example.com>受信者OK S：250 CONNEG（＆（イメージファイル構造= TIFF -minimal）S：250 CONNEG（MRC-MODE = 0）S：250 CONNEG（色=バイナリ）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
S：250 CONNEG（DPI-xyratio = [204/98204/196]））S：250 CONNEG（＆（DPI = 200）S：250 CONNEG（DPI-xyratio = [200 / 100,1]）） ）S：250 CONNEG（画像符号化= [MH、MR、MMR]）S：250 CONNEG（サイズX <= 254分の2150）S：250 CONNEG（用紙サイズ= [レター、A4]） S：250 CONNEG（UA-メディア=文具））C：データS：354大丈夫、送信データC：<< RFC 2822のMIMEのContent-Typeを持つメッセージ：TIFF-FXパー：（イメージファイル構造= TIFF-最小限DPI = 400画像符号化= JBIGサイズX = 254分の2150用紙サイズ=レター）>> S：250メッセージ受け入れC：Sを終了：221別れ
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.
このサービスは、受信者に代わって、能力の開示を求めています。要求者と回答者の認証されたIDを決定するためのメカニズムはこの仕様の範囲外です。これらのメカニズムは、公共の配布のために安全である情報の開示を許可することを意図しています。したがって、セキュリティ対策のためには固有の必要はありません。
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.
グラハムKlyneとエリック・バーガーは、大規模な、勤勉な口コミや提案を提供しました。キース・ムーア、GIAT花、とジョエル・ハルパーンは、確立された電子メールの練習に仕様の統合を向上させることの結果のフィードバックを提供します。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]クロッカー、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.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.クロッカー、 "電子メールに基づいて、メッセージングサービスのためのコンテントネゴシエーション"、RFC 3297、2002年7月。
[DSNSMTP] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DSNSMTP]ムーア、K.、RFC 3461 "配信状態通知（DSN）のための簡易メール転送プロトコル（SMTP）サービス拡張"、2003年1月。
[DSNFMT] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSNFMT]ムーア、K.とG.ボードルイ、RFC 3464、2003年1月、 "配信状態通知のための広げることができるメッセージフォーマット"。
[SYSCOD] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[SYSCOD]ヴォードルイユ、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.、フリード、N.、ローズ、M.、Stefferud、E.、およびD.クロッカー、 "SMTPサービス拡張"、STD 10、RFC 1869、1995年11月。
[ESMTP2] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[ESMTP2] Klensin、J.、 "簡易メール転送プロトコル"、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]レズニック、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メディアタイプ"、<http://www.iana.org/assignments/media-types>
[CFWS] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[CFWS] Alvestrand、H.、 "コンテンツ言語ヘッダ"、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]フロイド、S.とL. Daigle氏、 "オープン・プラグイン可能なエッジサービスのためのIAB建築・ポリシーに関する注意事項"、RFC 3238、2002年1月。
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
この付録では、記述的です。それが唯一の規範的なテキストによって許可または必要な使用上の問題についての議論を提供します
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：DIRECT CONNEG
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を使わなければなりませんし、クライアントが任意の必要な変換を実行しなければなりません。
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.
本明細書は多くのメカニズムを定義します。彼らのすべてを一緒に使用することは必要とされません。例えば、好適な変換をリスト間の差 - コンバージョンに適用制限を指定する対が - はじめに記載されています。この付録では、さらに、この仕様で定義された完全なセットよりも少ない使用のために呼ぶかもしれないシナリオについて説明します。また、条件の仲介が変換を実行する権限をまとめたもの。
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 CONNEGパラメータRCPT TO-する3. MIMEのContent-変換ヘッダーフィールド4. MIMEのContent-前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オプションで結合されると、その後、好適な変換の創始者の仕様は、要件のレベルに上昇します。他の変換は、コンテンツ変換ヘッダフィールドで指定されたものを除いて、許可されていません。
Note that the presence of both mechanisms does not require that conversions be performed. Rather, it constrains conversions, should they occur.
両方の機構の存在が変換が行われることを必要としないことに留意されたいです。彼らは起こるべきである。むしろ、それは、変換を制約します。
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。変換が必要なときに
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 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つのコンテンツの形式は、コンテンツ変換リストと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.仲介は、コンテンツ変換およびCONNEGの両方に記載されている形態のいずれかに現在の形式へ変換することができます。
Appendix C. MIME Content-Type Registrations
付録C. MIMEのContent-Type登録
C.1. Content-Convert
C.1。コンテンツ変換
Header field name: Content-Convert
ヘッダフィールド名：コンテンツ変換
Applicable protocol: Mail (RFC 2822)
適用可能プロトコル：Mail（RFC 2822）
Status: Proposed Standard
ステータス：標準案
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document(s): RFC 4141.
仕様書（S）：RFC 4141。
Related information: None.
関連情報：なし。
C.2. Content-Previous
C.2。コンテンツ-前
Header field name: Content-Previous
ヘッダフィールド名：コンテンツ前
Applicable protocol: Mail (RFC 2822)
適用可能プロトコル：Mail（RFC 2822）
Status: Proposed Standard
ステータス：標準案
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document(s): RFC 4141, Section 8
仕様書（S）：RFC 4141、セクション8
Related information: None.
関連情報：なし。
Authors' Addresses
著者のアドレス
Kiyoshi Toyoda Panasonic Communications Co., Ltd. 4-1-62 Minoshima Hakata-ku, Fukuoka 812-8531 Japan
きよし とよだ ぱなそにｃ こっむにかちおんｓ こ。、 Ｌｔｄ。 ４ー１ー６２ みのしま はかたーく、 ふくおか ８１２ー８５３１ じゃぱん
EMail: toyoda.kiyoshi@jp.panasonic.com
メールアドレス：toyoda.kiyoshi@jp.panasonic.com
Dave Crocker Brandenburg InternetWorking 675 Spruce Drive Sunnyvale, CA 94086 USA
デイブ・クロッカーブランデンブルクインターネットワーキング675スプルースドライブサニーベール、CA 94086 USA
Phone: +1.408.246.8253 EMail: dcrocker@bbiw.net
電話：+1.408.246.8253電子メール：dcrocker@bbiw.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。