Network Working Group A. Melnikov, Ed.
Request for Comments: 5259 Isode Ltd
Category: Standards Track P. Coates, Ed.
Sun Microsystems
July 2008
Internet Message Access Protocol - CONVERT Extension
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
CONVERT defines extensions to IMAP allowing clients to request adaptation and/or transcoding of attachments. Clients can specify the conversion details or allow servers to decide based on knowledge of client capabilities, on user or administrator preferences, or on server settings.
CONVERTは、クライアントが適応および/または添付ファイルのトランスコーディングを要求することができIMAPへの拡張を定義します。クライアントは、変換の詳細を指定するか、サーバがユーザや管理者の好みに、またはサーバーの設定に、クライアント機能の知識に基づいて決定できるようにすることができます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. Relation with Other IMAP Specifications . . . . . . . . . . . 4
3.1. CAPABILITY Response . . . . . . . . . . . . . . . . . . . 4
4. Scope of Conversions . . . . . . . . . . . . . . . . . . . . . 4
5. Discovery of Available Conversions . . . . . . . . . . . . . . 4
5.1. CONVERSIONS Command . . . . . . . . . . . . . . . . . . . 4
5.2. CONVERSION Response . . . . . . . . . . . . . . . . . . . 6
6. CONVERT and UID CONVERT Commands . . . . . . . . . . . . . . . 6
7. CONVERT Conversion Parameters . . . . . . . . . . . . . . . . 12
7.1. Mandatory-to-Implement Conversions and Conversion
Parameters . . . . . . . . . . . . . . . . . . . . . . . . 12
7.2. Additional Features for Mobile Usage . . . . . . . . . . . 13
8. Request/Response Data Items to CONVERT/UID CONVERT Commands . 14
8.1. CONVERTED Untagged Response . . . . . . . . . . . . . . . 14
8.2. BODYPARTSTRUCTURE CONVERT Request and Response Item . . . 14
8.3. BINARY.SIZE CONVERT Request and Response Item . . . . . . 15
8.4. AVAILABLECONVERSIONS CONVERT Request and Response Item . . 16
8.5. Implementation Considerations . . . . . . . . . . . . . . 17
9. Status Responses and Response Code Extensions . . . . . . . . 17
10. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 20
11. Manageability Considerations . . . . . . . . . . . . . . . . . 24
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12.1. Registration of unknown-character-replacement Media
Type Parameter . . . . . . . . . . . . . . . . . . . . . . 25
13. Security Considerations . . . . . . . . . . . . . . . . . . . 26
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
15.1. Normative References . . . . . . . . . . . . . . . . . . . 28
15.2. Informative References . . . . . . . . . . . . . . . . . . 29
This document defines the CONVERT extension to IMAP4 [RFC3501]. CONVERT provides adaptation and transcoding of body parts as needed by the client. Conversion (adaptation, transcoding) may be requested by the client and performed by the server on a best effort basis or, when requested by the client, decided by the server based on the server's knowledge of the client capabilities, user or administrator preferences, or server settings.
この文書は、IMAP4 [RFC3501]に変換拡張を定義します。クライアントによって、必要に応じてCONVERTは、適応と体の部分のトランスコーディングを提供します。変換（適応、トランスコーディング）は、クライアントから要求され、ベストエフォートベースでサーバーが実行するか、クライアントによって要求されたとき、クライアントの機能、ユーザーまたは管理者の好みのサーバーの知識に基づいて、サーバによって決定してもよいし、サーバーの設定。
This extension is primarily intended to be useful to mobile clients. It satisfies requirements specified in [OMA-ME-RD].
この拡張は、主にモバイルクライアントに有用であることが意図されます。これは、[OMA-ME-RD]で指定された要件を満たします。
A server that supports CONVERT can convert body parts to other formats to be viewed (for example) on a mobile device. The client can explicitly request a particular conversion or ask the server to select the best available conversion. When allowed by the client, the server determines how to convert based on its own strategy (e.g., based on knowledge of the client as discussed hereafter). If the server knows the characteristics of the device (out of scope for CONVERT) or can determine them (for example, using a conversion parameter containing device type), converted body parts can also be optimized for capabilities of the device (e.g., form factor of pictures). The client is able to control conversions using optional conversion (also referred to as "transcoding" in this document) parameters.
CONVERTをサポートするサーバは、モバイルデバイス上で（例えば）見られることを他のフォーマットに体の部分を変換することができます。クライアントは、明示的に特定の変換を要求したり、利用可能な最善の変換を選択するようにサーバーを頼むことができます。クライアントによって許可される場合、サーバは、独自の戦略に基づいて変換する方法を決定し（例えば、議論以下、クライアントの知識に基づいて）。サーバは、（CONVERTの範囲外）デバイスの特性を知っているか、（例えば、デバイスタイプを含む変換パラメータを用いて）、それらを決定することができる場合、例えば、フォームファクタ（本体部分は、デバイスの機能のために最適化することができる変換絵の）。クライアントは、オプションの変換（この文書では「トランスコード」と呼ばれる）パラメータを用いて変換を制御することができます。
This document relies on the registry of conversion parameters established by [MEDIAFEAT-REG]. The registry can be used to discover the underlying legal values that these parameters can take. Additional conversion parameters, such as those defined by [OMA-STI], are expected to be registered in the future.
この文書では、[MEDIAFEAT-REG]によって確立された変換パラメータのレジストリに依存しています。レジストリは、これらのパラメータを取ることができます法律上の基本的な値を発見するために使用することができます。このような[OMA-STI]によって定義されたものなどの追加の変換パラメータは、将来的に登録されることが期待されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
In examples, "C:" and "S:" indicate lines sent by the client and server, respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange. The five characters [...] mean that something has been elided.
実施例において、「C：」および「S：」は、それぞれ、クライアントとサーバによって送信されたラインを示します。シングル「C：」場合や「S：」ラベルは複数行に適用され、その後、これらの線の間の改行は編集上明確にするためであり、実際のプロトコル交換の一部ではありません。 5つの文字[...]何かが省略されていることを意味します。
When describing the general syntax, some definitions are omitted as they are defined in [RFC3501]. In particular, the term "session" is used in this document as defined in Section 1.2 of [RFC3501].
一般的な構文を説明するとき、それらは[RFC3501]で定義されたように、いくつかの定義を省略しています。 [RFC3501]のセクション1.2で定義されるように、特に、用語「セッション」とは、本書で使用されています。
Conversion of attachments during streaming is out of scope for the CONVERT extension and is described in a separate Lemonade WG document [LEM-STREAMING].
ストリーミング中添付の変換は、CONVERT拡張の範囲外であり、別レモネードWGドキュメント[LEM-STREAMING]に記載されています。
A server claiming compliance with this specification MUST support the IMAP Binary specification [RFC3516].
この仕様への適合を主張するサーバーはIMAPバイナリ仕様[RFC3516]をサポートしなければなりません。
A server that supports the CONVERT extension MUST return "CONVERT" and "BINARY" in the CAPABILITY response or response code. (Client and server authors are reminded that the order of tokens returned in the CAPABILITY response or response code is arbitrary.)
CONVERT拡張をサポートするサーバは、能力応答または応答コードで「CONVERT」と「BINARY」を返さなければなりません。 （クライアントとサーバの著者は、能力応答または応答コードで返されるトークンの順序は任意であることに留意されます。）
Example: A server that implements CONVERT.
例：CONVERTを実装し、サーバー。
C: a000 CAPABILITY S: * CAPABILITY IMAP4rev1 CONVERT BINARY [...] S: a000 OK CAPABILITY completed
C：A000 CAPABILITYのS：* CAPABILITY IMAP4rev1のCONVERT BINARY [...] S：A000 OK機能が完成します
Conversions only affect what is sent to the client; the original data in the message store MUST NOT be altered. This document does not specify how the server performs conversions.
コンバージョンには、クライアントに送信されるものに影響を与えます。メッセージストア内の元のデータを変更しないでください。この文書では、サーバが変換を実行する方法を指定しません。
Note: The requirement that original data be unaltered allows such data to remain accessible by other clients, permits replies or forwards of the original documents, permits signature verification (the converted body parts are not likely to contain any signatures), and preserves BODYSTRUCTURE and related information.
注：元のデータが変更されていないことの要件は、そのようなデータは、他のクライアントによってアクセス可能なままであることを可能にする原稿の返信や転送を可能にする、署名検証を可能にする（変換された体の部分は、任意の署名を含む可能性はない）、そしてBODYSTRUCTUREと関連を保持情報。
Arguments: source MIME type target MIME type
引数：ソースMIMEタイプターゲットMIMEタイプ
Responses: untagged responses: CONVERSION
回答：タグなし応答：CONVERSION
Result: OK - CONVERSIONS command completed BAD - unrecognized syntax of an argument, unexpected extra argument, missing argument, etc.
結果：OK - 変換がBAD完了したコマンド - 引数の認識できない構文、予想外の追加の引数、引数がありません、など
The CONVERSIONS command is allowed in Authenticated and Selected IMAP states.
CONVERSIONSコマンドは、認証で許可されるとIMAPの状態を選択しています。
The first parameter to the CONVERSIONS command is a source MIME type,
the second parameter is the target MIME type. Both parameters are
partially (e.g., "text/*") or completely ("*") wildcardable.
Conversions matching the source/target pair and their associated conversion parameters are returned in untagged CONVERSION responses. If source/target doesn't match any conversion supported by the server, no CONVERSION response is returned.
ソース/ターゲットペアを一致コンバージョンとそれに関連付けられた変換パラメータは、タグなしCONVERSION応答で返されます。ソース/ターゲットは、サーバーでサポートされている任意の変換と一致しない場合は、変換なしの応答が返されません。
Examples:
例：
For conversion information from GIF to JPEG image format (no untagged CONVERSION response would be returned if no conversion is possible):
JPEG画像フォーマットへのGIFから変換情報のための（変換が可能でない場合は何もタグ無し変換応答が返されないことになります）。
C: a CONVERSIONS "image/gif" "image/jpeg"
S: * CONVERSION "image/gif" "image/jpeg" ("pix-y" "pix-x"
"image-interleave")
S: a OK CONVERSIONS completed
For conversion information from GIF image format to anything:
何のGIF画像フォーマットからの変換について：
C: b CONVERSIONS "image/gif" "*"
S: * CONVERSION "image/gif" "image/jpeg" ("pix-y" "pix-x"
"image-interleave")
S: * CONVERSION "image/gif" "image/png" ([...])
[...]
S: b OK CONVERSIONS completed
For conversion of anything to JPEG:
JPEGに何の変換のために：
C: c CONVERSIONS "*" "image/jpeg"
S: * CONVERSION "image/gif" "image/jpeg" ("pix-y" "pix-x"
"image-interleave")
S: * CONVERSION "image/png" "image/jpeg" (...)
[...]
S: c OK CONVERSIONS completed
For conversions from all image formats to all text formats, the client can issue the following command:
すべてのテキスト形式へのすべての画像フォーマットからの変換では、クライアントは、次のコマンドを発行できます。
C: d CONVERSIONS "image/*" "text/*"
Contents: source MIME type target MIME type optional list of supported conversion parameters
内容：サポートされている変換パラメータのソースMIMEタイプのターゲットMIMEタイプ、オプションのリスト
As a result of executing a CONVERSIONS command, the server can return one or more CONVERSION responses. Each CONVERSION response specifies which source MIME type can be converted to the target MIME type, and also lists supported conversion parameters.
CONVERSIONSコマンドを実行した結果として、サーバーは、1つの以上の変換応答を返すことができます。各変換応答は、対象のMIMEタイプに変換され、また、サポートされている変換パラメータを一覧表示することができるソースMIMEタイプを指定します。
Arguments: sequence set conversion parameters CONVERT data item names
引数：シーケンスセット変換パラメータは、データ項目名を変換します
Responses: untagged responses: CONVERTED
回答：タグなし応答：変換
Result: OK - convert completed NO - convert error: can't fetch and/or convert that data BAD - unrecognized syntax of an argument, unexpected extra argument, missing argument, etc.
結果：OK - 完了NOを変換する - エラーを変換： - 認識されない引数の構文、予想外の追加の引数、引数がありません、などそのデータBADをフェッチおよび/または変換することはできません。
The CONVERT extension defines CONVERT and UID CONVERT commands that are used to transcode the media type of a MIME part into another media type, and/or the same media type with different encoding parameters. These commands are structured and behave similarly to FETCH/UID FETCH commands as extended by [RFC3516]:
CONVERT拡張は、CONVERTを定義し、UIDは、他のメディアタイプにMIMEパートのメディアタイプをトランスコードするために使用されるコマンドを変換し、および/または異なる符号化パラメータと同じメディアタイプ。これらのコマンドは、構造化されて、[RFC3516]によって拡張としてUIDがコマンドをFETCH / FETCHと同様に振る舞います。
o A successful CONVERT/UID CONVERT command results in one or more untagged CONVERTED responses (one per message). They are similar to the untagged FETCH responses. Note that a single CONVERT/ UID CONVERT command can only perform a single type of conversion as defined by the conversion parameters. A client that needs to perform multiple different conversions needs to issue multiple CONVERT/UID CONVERT commands. Such a client MAY pipeline them.
一つ以上のタグ無しCONVERTED応答（メッセージごとに）中のO成功CONVERT / UID CONVERTコマンドの結果。彼らは、タグなしのFETCH応答に似ています。変換パラメータによって定義されるような単一CONVERT / UIDのCONVERTコマンドは、変換の単一のタイプを実行することができることに留意されたいです。複数の異なる変換を実行する必要があるクライアントは、複数のCONVERT / UIDのCONVERTコマンドを発行する必要があります。このようなクライアントMAYパイプラインそれら。
o BINARY[...] data item requests conversion of a body part or of the whole message according to conversion parameters and requests that the converted message/body part be returned as binary.
O BINARY [...]データ項目は、変換パラメータと変換メッセージ/本体部分はバイナリとして返される要求に応じて身体部分の、またはメッセージ全体の変換を要求します。
o BINARY.SIZE data item is similar to RFC822.SIZE, but it requests size of a converted body part/message.
O BINARY.SIZEデータ項目はRFC822.SIZEに類似しているが、それは、変換本体部/メッセージのサイズを要求します。
o BODYPARTSTRUCTURE data item is similar to BODYSTRUCTURE FETCH data item, but it returns the MIME structure of the converted body part.
O BODYPARTSTRUCTUREデータ項目は、データ項目をFETCH BODYSTRUCTUREと類似しているが、それは、変換身体部分のMIME構造を返します。
o BODY[...HEADER] encoded words in the requested headers are converted to the specified charset. The CHARSET parameter is REQUIRED for this conversion.
O BODY [... HEADER]要求ヘッダで符号化された単語は、指定された文字セットに変換されます。 charsetパラメータは、この変換のために必要です。
o BODY[...MIME] encoded words in the requested headers are converted to the specified charset. The CHARSET parameter is REQUIRED for this conversion.
O BODY [... MIME]要求ヘッダーのエンコードされた単語は、指定された文字セットに変換されます。 charsetパラメータは、この変換のために必要です。
o AVAILABLECONVERSIONS data item requests the list of target MIME types the specified body part (or the whole message) can be converted to.
O AVAILABLECONVERSIONSデータ項目は、指定された身体の一部（または全部メッセージ）に変換することができる目標MIMEタイプのリストを要求します。
The CONVERT extension also adds one new response code. See Section 9 for more details.
CONVERT延長も1つの新しい応答コードを追加します。詳細については、セクション9を参照してください。
Typically clients will request conversion of leaf body parts. In addition to support of leaf body part conversion, servers MAY offer conversion of non-leaf body parts (e.g., conversion from multipart/ related).
通常、クライアントは、葉の体の部分の変換を要求します。リーフ本体部の変換のサポートに加えて、サーバは、非リーフ本体部（マルチパート/関連から、例えば、変換）の変換を提供することができます。
Instead of specifying the exact target MIME media type the client wants to convert to, the client MAY use a special marker NIL (also known as "default conversion") to request the server to pick a suitable target media type. This document doesn't describe how exactly the server makes such a choice; however, some basic guidelines are described in this paragraph. If the server knows characteristics of the device using an in-band (such as device type specified in a conversion parameter) or an out-of-band mechanism, then it should convert the request body part to a media type the device is likely to support and display/play successfully. Unless specifically overridden by a conversion parameter, the server MAY also remove any unnecessary detail that exceeds the capabilities of the device (e.g., scaling images to just fit on the device's screen). In the absence of any in-band or out-of-band mechanism for determining device characteristics, the server should convert the request body part to the most standard or widely deployed media type available in that media category, for example, to convert to text/ plain, image/jpeg. In such case, the server should minimize quality loss. Servers are REQUIRED to support "default conversion" requests. Server implementations that support conversions to multiple target MIME types SHOULD make the default conversion configurable. Clients SHOULD avoid using the default conversion unless they provided a way (in-band or out-band) to signal their capabilities to the server, as there is no guaranty that the server would guess their capability correctly. Client implementors should consider using AVAILABLECONVERSIONS CONVERT data item or CONVERSIONS command instead of the default conversion.
代わりに、クライアントがに変換したいの正確なターゲットMIMEメディアタイプを指定すると、クライアントは、適切なターゲットメディアタイプを選択するためにサーバーを要求するために（また、「デフォルトの変換」として知られている）特別なマーカーNILを使用するかもしれません。この文書では、サーバがそのような選択を行う方法を正確に説明していません。しかし、いくつかの基本的なガイドラインは、この段落に記載されています。サーバは、インバンド（変換パラメータで指定されたような装置のようなタイプ）またはアウトオブバンドメカニズムを使用してデバイスの特性を知っている場合、それは、デバイスがしやすいメディアタイプに要求本体部を変換する必要がありますサポートと表示/成功裏に果たしています。特に変換パラメータによって上書きされない限り、サーバーは、（例えば、単にデバイスの画面に収まるように画像をスケーリング）デバイスの能力を超えた不要なディテールを削除することができます。任意のインバンドまたはアウトオブバンドメカニズムを決定するデバイスの特性の非存在下では、サーバは、テキストに変換するために、例えば、そのメディアカテゴリで利用可能な最も標準または広く展開メディアタイプに要求本体部を変換する必要があります/無地、画像/ JPEG。そのような場合には、サーバは品質の損失を最小限に抑える必要があります。サーバは、「デフォルトの変換」の要求をサポートする必要があります。複数のターゲットMIMEタイプへの変換をサポートするサーバ実装は、デフォルトの変換は、設定すべきです。彼らは、サーバーが正しく自分の能力を推測何の保証がないので、サーバにその機能を通知するための方法（インバンドまたはアウトバンド）を提供しない限り、クライアントは、デフォルトの変換を使用しないでください。クライアントの実装はAVAILABLECONVERSIONSは、データ項目を変換したり、変換が代わりにデフォルトの変換のコマンドを使用して検討すべきです。
CONVERT's command syntax is modeled after the FETCH command syntax in [RFC3501], as extended by [RFC3516]. CONVERT data items are generally structured as:
[RFC3516]によって拡張としてCONVERTのコマンドの構文は、[RFC3501]でFETCHコマンドの構文の後にモデル化されています。 CONVERTデータ項目は、一般的のように構成されています。
BINARY[section-part]<partial>
BINARY [セクションの部分<部分>
BINARY.SIZE[section-part]
BINARY.SIZE [セクションの部分]
BODYPARTSTRUCTURE[section-part]
BODYPARTSTRUCTURE [セクションの部分]
BODY[HEADER]
BODY [HEADER]
BODY[section-part.HEADER]
BODY [セクション-part.HEADER]
BODY[section-part.MIME]
BODY [セクション-part.MIME]
AVAILABLECONVERSIONS[section-part]
AVAILABLECONVERSIONS [セクションの部分]
The semantics of a partial CONVERT BINARY[...] command is the same as for a partial FETCH BODY[...] command, with the exception that the <partial> arguments refer to the TRANSCODED and DECODED section data.
部分CONVERTのBINARY [...]コマンドのセマンティクスは<部分>引数は、トランスコード、デコードセクションデータを参照することを除いて、部分的FETCH BODY [...]コマンドと同じです。
Note that unlike the FETCH command, the CONVERT command never sets the \Seen flag on converted messages. A client wishing to mark a message with the \Seen flag would need to issue a STORE command (possibly pipelined with the CONVERT request) to do that.
FETCHコマンドとは異なり、CONVERTコマンドは、変換後のメッセージに、\見フラグを設定しないことに注意してください。それを行うには、\見フラグ付きメッセージをマークしたいクライアントは、（おそらくCONVERT要求をパイプライン化）STOREコマンドを発行する必要があります。
The UID CONVERT command is different from the CONVERT command in the same way as the UID FETCH command is different from the FETCH command:
UIDは、FETCHコマンドとしてUIDのCONVERTコマンドは、同じ方法でCONVERTコマンドとは異なりFETCHコマンドとは異なります。
o UID CONVERT takes as a parameter a sequence of UIDs instead of a sequence of message numbers.
O UID CONVERTは、パラメータとしてのUIDの配列の代わりに、メッセージ番号の配列をとります。
o UID CONVERT command MUST result in the UID data item in a corresponding CONVERTED response.
O UID CONVERTコマンドは、対応する変換応じてUIDデータ項目をもたらさなければなりません。
o An EXPUNGE response MUST NOT be sent while responding to a CONVERT command. This rule is necessary to prevent a loss of synchronization of message sequence numbers between client and server. Note that an EXPUNGE response MAY be sent during a UID CONVERT command.
CONVERTコマンドに応答したまま、o EXPUNGE応答を送ってはいけません。このルールは、クライアントとサーバの間のメッセージのシーケンス番号の同期の損失を防止する必要があります。 EXPUNGE応答はUID CONVERTコマンド中に送信されるかもしれないことに注意してください。
Example: The client fetches body part section 3 in the message with the message sequence number of 2 and asks to have that attachment converted to pdf format.
例：クライアント2のメッセージ・シーケンス番号を持つメッセージで本体部部3を取り出し、その添付ファイルがPDF形式に変換したために尋ねます。
C: a001 CONVERT 2 ("APPLICATION/PDF") BINARY[3] S: * 2 CONVERTED (TAG "a001") (BINARY[3] {2135} <the document in .pdf format> ) S: a001 OK CONVERT COMPLETED
C：A001 CONVERT 2（ "アプリケーション/ PDF"）BINARY [3] S：* 2 CONVERTED（TAG "A001"）（BINARY [3] {2135} <PDF形式で文書>）S：A001 OK CONVERT COMPLETED
Example: The client requests for conversion of a text/html body part to text/plain and asks for a charset of us-ascii. The server cannot respect the charset conversion request because there are non-us-ascii characters in the text/html body part, so it fails the request by returning an ERROR phrase in place of the converted data (see Section 9).
例：text / htmlの本体部分の変換のためのクライアント要求は、/プレーンテキストにし、US-ASCIIの文字セットを要求します。 （セクション9を参照）text / htmlの本体部内の非US-ASCII文字があるため、サーバーは、文字セット変換要求を尊重することはできませんので、変換されたデータの代わりにERRORフレーズを返すことによって、要求を失敗しました。
C: b001 CONVERT 2 ("text/plain" ("charset" "us-ascii")) BINARY[3] S: * 2 CONVERTED (tag "b001") (BINARY[3] (ERROR "Source text has non us-ascii" BADPARAMETERS "text/html" "text/plain" ("charset" "us-ascii"))) S: b001 NO All conversions failed
C：B001 CONVERT 2（ "テキスト/平野"（ "文字セット" "US-ASCII"））BINARY [3] S：* 2 CONVERTED（タグ "B001"）（BINARY [3]（ERROR「ソース・テキストが非たちを持っています-ascii」BADPARAMETERS "text / htmlの" "text / plainの"（ "文字セット" "US-ASCII"）））S：B001はNOすべての変換が失敗しました
If the client also specified the "unknown-character-replacement" conversion parameter (see Section 12.1), the same example can look like this:
クライアントはまた、変換パラメータ（項12.1を参照してください）、「不明な文字置換」を指定した場合は、同じ例は次のようになります。
C: b001 CONVERT 2 ("text/plain" ("charset" "us-ascii" "unknown-character-replacement" "?")) BINARY[3] S: * 2 CONVERTED (TAG "b001") (BINARY[3] {2135} <the document in text/plain format with us-ascii charset> ) S: b001 OK CONVERT COMPLETED
C：B001 CONVERT 2（ "テキスト/平野"（ "文字セット" "US-ASCII" "未知の文字置換" ""）BINARY [3] S：* 2 CONVERTED（TAG？） "B001"）（BINARY [ 3] {2135}）S <US-ASCII文字セットを持つtext / plainの形式で文書>：COMPLETED B001 OK CONVERT
The server replaced non-us-ascii characters with a us-ascii character such as "?".
サーバーは、「？」として、US-ASCII文字と非ASCII文字を置き換えます。
Example: The client first requests the converted size of a text/html body part converted to text/plain:
例：クライアントは、最初のテキスト/ HTMLのボディ部分の変換後のサイズは、/プレーンテキストに変換要求します。
C: c000 CONVERT 2 ("TEXT/PLAIN" ("CHARSET" "us-ascii")) BINARY.SIZE[4] S: * 2 CONVERTED (TAG "c000") (BINARY.SIZE[4] 3135) S: c000 OK CONVERT COMPLETED
C： "：（C000"（BINARY.SIZE [4] 3135）、S 2（ "text / plainの"（ "CHARSET" "US-ASCII * 2 CONVERTED TAG）））BINARY.SIZE [4] Sを" 変換C000： C000はOK CONVERT COMPLETED
Later on, the client requests 1000 bytes from the converted body part, starting from byte 2001:
その後、クライアントは、バイト2001年から開始し、変換後の身体の一部から1000のバイトを要求します。
C: c001 CONVERT 2 ("TEXT/PLAIN" ("CHARSET" "us-ascii")) BINARY[4]<2001.1000> S: * 2 CONVERTED (TAG "c001") (BINARY[4]<2001> {135} <bytes 2001 - 2135 of the document in text/plain format> ) S: c001 OK CONVERT COMPLETED
C： "：（C001"（BINARY [4] <2001>、{135 * 2 CONVERTED TAG）BINARY [4] <2001.1000> S（）2 "text / plainの"（ "CHARSET" "US-ASCII）を" 変換C001 } <バイト2001 - text / plainの形式の文書の2135>）S：COMPLETED C001 OK CONVERT
The server MUST respect the target MIME type and conversion parameters specified by the client in the transcoding request. Note that some conversion parameters can restrict what kind of conversion is possible, while others can remove some restrictions.
サーバは、トランスコーディング要求でクライアントによって指定されたターゲットMIMEタイプと変換パラメータを尊重しなければなりません。他の人はいくつかの制限を削除することができますが、いくつかの変換パラメータは、可能である変換の種類を制限することに注意してください。
It is legal for a client to request conversion of a non-leaf body
part, for example, to request conversion of a multipart/* into a PDF
document. However, servers implementing this extension are not
required to support such conversions. Servers that support such
conversions MUST return one or more CONVERSION responses in response
to a 'CONVERSIONS "multipart/*" "*"' command. See Section 5.1 for
more details.
The client can request header conversions using the BODY[...HEADER] CONVERT request, for example
クライアントは、例えば、BODY [... HEADER] CONVERT要求を使用して、ヘッダの変換を要求することができます
C: D001 FETCH 2 BODY[HEADER]
S: * 2 FETCH (BODY[HEADER] {158}
S: Date: Mon, 20 Apr 2007 20:05:43 +0200
S: From: Peter <peter@siroe.example.com>
S: To: Alexey <alexey@siroe.example.com>
S: Subject: =?KOI8-R?Q?why encode this?=
S:
S: )
S: D001 OK
C: D002 CONVERT 2 (NIL ("CHARSET" "utf-8")) BODY[HEADER]
S: * 2 CONVERTED (TAG "d002") (BODY[HEADER] {157}
S: Date: Mon, 20 Apr 2007 20:05:43 +0200
S: From: Peter <peter@siroe.example.com>
S: To: Alexey <alexey@siroe.example.com>
S: Subject: =?UTF-8?Q?why encode this?=
S:
S: )
S: D002 OK
Any such request MUST include the CHARSET parameter. Upon receipt of the request, the server MUST decode any encoded words (as described in [RFC2047]) in headers and return them re-encoded in the specified
任意のそのような要求は、charsetパラメータを含まなければなりません。要求を受信すると、サーバは、ヘッダに（[RFC2047]に記載されているように）、任意の符号化ワードをデコードし、指定に再エンコードして返さなければなりません
charset. (Note that encoded-words might not be needed if the result can be represented entirely in US-ASCII, so the server MAY replace the resulting encoded-words with their pure US-ASCII representation.) If the server can't decode any particular encoded word, for example, if the charset or encoding is not recognized, it MUST leave them as is. Servers SHOULD also support decoding of any parameters as described in [RFC2231]. Support for RFC 2231 parameters might require reformatting of header fields during conversion. Consider the following
文字セット。サーバは、特定のをデコードすることができない場合は（結果はUS-ASCIIで完全に表現することができるので、サーバはそれらの純粋なUS-ASCII表現と結果のエンコードされたワードを置き換えることができます。エンコードされたワードが必要とされない可能性があることに注意してください）文字セットやエンコーディングが認識されない場合であるとしてエンコードされた単語は、例えば、それはそれらを残しておく必要があります。 [RFC2231]に記載されているように、サーバは、任意のパラメータの復号化をサポートしなければなりません。 RFC 2231個のパラメータをサポートするには、変換時のヘッダフィールドの再フォーマットが必要になることがあります。次のことを考えてみましょう
C: D011 FETCH 3 BODY[1.MIME]
S: * 3 FETCH (BODY[1.MIME] {118}
S: Content-Type: text/plain; charset=utf-8;
S: foo*0*=utf-8'fr'tr%c0;
S: foo*1*(very)=%03s_m%c0;
S: foo*2*=(nasty)%09chant
S:
S: D011 OK
The server should preserve the headers during the conversion as much as possible. In case the characters are split (legally!) between fragments of an encoded parameter, the server MUST consolidate the parameter fragments, and convert, emit, and re-fragment them as necessary in order to keep the line length less than 78. Comments embedded like this SHOULD be preserved during conversion, but clients MUST gracefully handle the situation where comments are removed entirely. If the comments are preserved, they MAY be moved after the parameter. For example (continuing the previous example):
サーバーは、できるだけ多くの変換時にヘッダを保存する必要があります。場合に文字が（合法的に！）に分割されている符号化パラメータのフラグメントとの間、サーバ未満78コメント埋め込み行の長さを維持するために必要に応じてパラメータ断片を統合し、変換し、放出、および再断片化それらMUSTこのように、変換中に保存される必要がありますが、クライアントは優雅にコメントが完全に削除されている状況に対処しなければなりません。コメントが保存されている場合は、パラメータの後に移動させてもよいです。例えば、（前の例を続けます）。
C: D012 CONVERT 3 (NIL) BODY[1.MIME]
S: * 3 CONVERTED (TAG "D012") (BODY[1.MIME] {109}
S: Content-Type: text/plain; charset=utf-8;
S: foo*0*=utf-8'fr'tr%c0%03s_;
S: foo*1*=%m%c0%09chant (very)(nasty)
S:
S: D012 OK
No destination MIME type MUST be specified with BODY[HEADER], BODY[section.HEADER], or BODY[section.MIME]. That is, BODY[HEADER], BODY[section.HEADER], or BODY[section.MIME] can only be used with the "default conversion". When performing these conversions, the server SHOULD leave encoded words as encoded words. A failure to do so may alter the semantics of structured headers.
いいえ先MIMEタイプは、[section.MIME] BODY [section.HEADER]、またはBODY、BODY [HEADER]で指定されてはなりません。それはBODY [HEADER]、BODY [section.HEADER]、またはBODYは[section.MIME] "デフォルトの変換" のみを使用することが可能です。これらの変換を実行するとき、サーバは、エンコードされたワードとして符号化された単語を残すべきです。これを怠ると、構造化されたヘッダのセマンティクスを変更することができます。
The registry established by [MEDIAFEAT-REG] defines names of conversion parameters that can be used in the CONVERT command. Support for some conversion parameters is mandatory, as described in Section 7.1.
[MEDIAFEAT-REG]によって確立されたレジストリは、CONVERTコマンドで使用することができる変換パラメータの名前を定義します。セクション7.1で説明したように、いくつかの変換パラメータのサポートは、必須です。
According to [MEDIAFEAT-REG], conversion parameter names are case-insensitive.
[MEDIAFEAT-REG]によれば、変換パラメータ名は大文字と小文字を区別しています。
The following example illustrates how target picture dimensions can be specified in a CONVERT request using the PIX-X and PIX-Y parameters defined in [DISP-FEATURES].
次の例では、対象ピクチャの寸法は[DISP-FEATURES]で定義されたPIX-XとPIX-Yパラメータを使用してCONVERT要求で指定することができる方法を示す図です。
C: e001 UID CONVERT 100 ("IMAGE/JPEG" ("PIX-X" "128"
"PIX-Y" "96")) BINARY[2]
S: * 2 CONVERTED (TAG "e001") (UID 100 BINARY[2] ~{4182}
<this part of a document is a rescaled image in
JPEG format with width=128, height=96.>
)
S: e001 OK UID CONVERT COMPLETED
A server implementing CONVERT MUST support charset conversions for the text/plain MIME type, and MUST support charset conversions from iso-8859-1, iso-8859-2, iso-8859-3, iso-8859-4, iso-8859-5, iso-8859-6, iso-8859-7, iso-8859-8, and iso-8859-15 to utf-8.
サーバ実装CONVERTは、text / plainのMIMEタイプに文字セットの変換をサポートしなければなりません、そしてISO-8859-1 ISO-8859-1、ISO-8859-2、ISO-8859-3、ISO-8859-4、から文字セットの変換をサポートしなければなりません図5に示すように、ISO-8859-6、ISO-8859-7、ISO-8859-8、及びUTF-8にISO-8859-15。
The server MUST list "text/plain" as an allowed destination conversion from "text/plain" MIME type (see Section 5.1). A command 'CONVERSIONS "text/plain" "text/plain"' MUST also return "charset" and "unknown-character-replacement" (see Section 12.1) as supported conversion parameters in the corresponding CONVERSION response.
サーバーは、「text / plainの」MIMEタイプから許可宛先変換として、「text / plainのを」（5.1項を参照）をリストする必要があります。コマンド「変換 『text / plainの』 『text / plainの』」も返さなければならない「文字セット」と「未知の文字の置換を」対応する変換応答でサポートされている変換パラメータとして（項12.1を参照してください）。
IMAP servers implementing the CONVERT extension MUST support recognition of the "charset" [CHARSET-REG] parameter for text/plain, text/html, text/css, text/csv, text/enriched, and text/xml MIME types. Note, a server implementation is not required to support any conversion from the text MIME subtypes specified above, except for the mandatory-to-implement conversion described above. That is, a server implementation MUST support the "charset" parameter for text/ csv, only if it supports any conversion from text/csv.
CONVERT拡張を実装するIMAPサーバはtext / plainで、text / htmlのための "文字セット" [CHARSET-REG]パラメータ、テキスト/ CSS、テキスト/ CSV、テキスト/濃縮、およびtext / xmlでのMIMEタイプの認識をサポートしなければなりません。メモは、サーバの実装は、上記強制的に実装変換を除いて、上記指定されたテキストMIMEサブタイプからの任意の変換をサポートするために必要とされません。これは、サーバーの実装は、それがテキスト/ CSVファイルからの任意の変換をサポートしている場合にのみ、テキスト/ CSVのための「文字セット」のパラメータをサポートしなければなりませんさ。
The server MUST support decoding of [RFC2047] headers and their conversion to UTF-8 as long as the encoded words are in one of the supported charsets.
サーバであれば符号化された単語がサポートされている文字セットのいずれかであるように[RFC2047]ヘッダーとUTF-8への変換の復号化をサポートしなければなりません。
Servers SHOULD offer additional character encoding conversions where they make sense, as character conversion libraries are generally available on many platforms.
文字変換ライブラリは多くのプラットフォームで一般的に利用可能であるとしてサーバは、彼らが意味をなす追加の文字エンコーディング変換を提供する必要があります。
If the server cannot carry out the charset conversion while preserving all the characters (i.e., a source character can't be represented in the target charset), and the "unknown-character-replacement" conversion parameter is not specified, then the server MUST fail the conversion and MUST return the untagged ERROR BADPARAMETERS response (see Section 9). If the value specified in the "unknown-character-replacement" conversion itself can't be represented in the target charset, then the server MUST also fail the conversion and MUST return the untagged ERROR BADPARAMETERS response (see Section 9).
すべての文字を維持しながら、サーバが文字セット変換を実行することができない場合（つまり、ソース文字がターゲット文字セットで表現できない）、および「未知の文字の置換」変換パラメータが指定されていない場合、サーバはMUST変換に失敗して（セクション9を参照）タグなしERROR BADPARAMETERS応答を返さなければなりません。 「不明な文字置換」変換自体に指定された値がターゲット文字セットで表現できない場合、サーバは、変換に失敗しなければなりませんし、タグなしERROR BADPARAMETERS応答を返さなければなりません（セクション9を参照）。
This section is informative.
このセクションは参考情報です。
Based on the expected usage of CONVERT in mobile environments, server implementors should consider support for the following conversions:
モバイル環境でのCONVERTの予想される使用に基づいて、サーバーの実装は、次の変換のための支援を検討する必要があります。
o Conversion of HTML and XHTML documents to text/plain in ways that preserve at the minimum the document structure and tables.
O HTMLとXHTMLドキュメントの変換は、最低でも文書構造とテーブルを保存する方法で、text / plainにします。
o Image conversions among the types image/gif, image/jpeg, and image/png for at least the following parameters:
タイプイメージ/ GIFうちOイメージ変換、画像/ JPEG、少なくとも以下のパラメータのための画像/ PNG：
* size limit (i.e., reduce quality)
*サイズ制限（即ち、品質を低下させます）
* width ("pix-x" parameter)
*幅（ "PIX-X" パラメータ）
* height ("pix-y" parameter)
*高さ（ "PIX-Y" パラメータ）
* resize directive (crop, stretch, aspect ratio)
*リサイズ指令（作物、ストレッチ、アスペクト比）
The support for "depth" may also be of interest.
「深さ」のためのサポートも重要である可能性があります。
Audio conversion is also of interest but the relevant formats depend significantly on the usage context.
オーディオ変換も重要であるが、関連するフォーマットは、使用状況に大きく依存します。
Contents: convert correlator CONVERTED return data items
内容：変換相関変換したものを返しますデータ項目
The CONVERTED response may be sent as a result of a successful, partially successful, or unsuccessful CONVERT or UID CONVERT command specified in Section 6.
CONVERTED応答はセクション6で指定された成功した、部分的に成功し、または失敗CONVERT又はUID CONVERTコマンドの結果として送信されてもよいです。
The CONVERTED response starts with a message number, followed by the "CONVERTED" label. The label is followed by a convert correlator, which contains the tag of the command that caused the response to be returned. This can be used by a client to match a CONVERTED response against a corresponding CONVERT/UID CONVERT command.
CONVERTED応答は、「変換」ラベルに続くメッセージ番号で始まります。ラベルは、応答が返される原因となったコマンドのタグを含む変換相関器、続いています。これは、対応するCONVERT / UIDのCONVERTコマンドに対するCONVERTED応答を一致させるために、クライアントで使用することができます。
The convert correlator is followed by a list of one or more CONVERT return data items. If the UID data item is returned, it MUST be returned as the first data item in the CONVERTED response. This requirement is to simplify client implementations. See Section 10 and the remainder of Section 8 for more details.
変換相関器は、一つ以上のCONVERT戻りデータ項目のリストが続いています。 UIDデータアイテムが返された場合、それは、変換された応答して第1データ項目として返さなければなりません。この要件は、クライアントの実装を簡素化することです。第10節やより詳細な情報については、セクション8の残りの部分を参照してください。
BODYPARTSTRUCTURE[section-part]
BODYPARTSTRUCTURE [セクションの部分]
The CONVERT extension defines the BODYPARTSTRUCTURE CONVERT data item. Data contained in the BODYPARTSTRUCTURE return data item follows the exact syntax specified in the [RFC3501] BODYSTRUCTURE data item, but only contains information for the converted part. All information contained in BODYPARTSTRUCTURE pertains to the state of the part after it is converted, such as the converted MIME type, sub-type, size, or charset. Note that the client can expect the returned MIME type to match the one it requested (as the server is required to obey the requested MIME type) and can treat mismatch as an error.
CONVERT拡張はBODYPARTSTRUCTUREのCONVERTデータ項目を定義します。 BODYPARTSTRUCTUREリターンデータ項目に含まれるデータは、[RFC3501] BODYSTRUCTUREデータ項目で指定された正確な構文に従うが、唯一の変換部分の情報を含んでいます。それは、このような変換MIMEタイプ、サブタイプ、サイズ、または文字セットとして、変換された後BODYPARTSTRUCTUREに含まれるすべての情報は、一部の状態に関係します。クライアントは、エラーとして不一致を扱うことができます（サーバは要求されたMIMEタイプに従うことが必要とされるように）返されたMIMEタイプは、それが要求されたものと一致することが期待できることに注意してください。
The returned BODYPARTSTRUCTURE data MUST match the BINARY data returned for exactly the same conversion in the same IMAP "session". This requirement allows a client to request BODYPARTSTRUCTURE and BINARY data in separate commands in the same IMAP session.
返さBODYPARTSTRUCTUREデータは同じIMAP「セッション」で、まったく同じ変換に返さBINARYデータと一致しなければなりません。この要件は、クライアントが同じIMAPセッションで別のコマンドにBODYPARTSTRUCTUREとBINARYデータを要求することができます。
If the client lists a BODYPARTSTRUCTURE data item for a section-part before a BINARY data item for the same section-part, then, in the CONVERTED response, the server MUST return the BODYPARTSTRUCTURE data prior to the corresponding BINARY data. Also, any BODYSTRUCTURE data items MUST be after the UID data item if the UID data item is present. Both requirements are to simplify handling of converted data in clients.
クライアントが同じセクション・パートのBINARYデータ項目の前にセクション・パートのBODYPARTSTRUCTUREデータ項目を一覧表示した場合、そして、変換応じて、サーバは前対応するバイナリデータにBODYPARTSTRUCTUREデータを返さなければなりません。 UIDデータ項目が存在する場合にも、任意BODYSTRUCTUREデータ項目は、UIDデータ項目の後でなければなりません。両方の要件は、クライアントに変換されたデータの取り扱いを簡素化することです。
Example: C: e002 CONVERT 2 (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY[2] BODYPARTSTRUCTURE[2]) S: * 2 CONVERTED (TAG "e002") (BODYPARTSTRUCTURE[2] ("IMAGE" "JPEG" () NIL NIL "8bit" 4182 NIL NIL NIL) BINARY[2] ~{4182} <this part of a document is a rescaled image in JPEG format with width=128, height=96.> ) S: e002 OK CONVERT COMPLETED
例：C：（ "* 2 CONVERTED（TAG（）（BINARY [2] BODYPARTSTRUCTURE [2]）S E002"）E002は、2 NIL（ "PIX-X" "128" "PIX-Y" "96）" 変換しますBODYPARTSTRUCTURE [2]（ "画像"、 "JPEG"（）NIL NIL "8ビット" 4182 NIL NIL NIL）BINARY [2]〜{4182} <文書のこの部分は、幅= 128、高さがJPEG形式の再スケーリング画像であります= 96>）S：COMPLETED E002 OK CONVERT
BINARY.SIZE[section-part]
BINARY.SIZE [セクションの部分]
This item requests the converted size of the section (i.e., the size to expect in a response to the corresponding CONVERT BINARY request). The returned value MUST be exact and MUST NOT change during a duration of an IMAP "session", unless the message is expunged in another session (see below). This allows a client to download a converted part in chunks (using "<partial>"). This requirement means that in most cases the server needs to perform conversion of the requested body part before returning its size.
この項目は、セクション（対応CONVERT BINARYの要求に応じて、期待する、すなわち、サイズ）の変換サイズを要求します。返される値は正確でなければなりません、メッセージが（下記参照）、別のセッションで抹消されない限り、IMAP「セッション」の期間中に変更してはいけません。これは、（「<部分>」を使用して）クライアントがチャンクで変換された部分をダウンロードすることができます。この要件は、ほとんどの場合、サーバはそのサイズを返す前に要求された身体部分の変換を実行する必要があることを意味します。
If the message is expunged in another session, then the server MAY return the value 0 in response to the BINARY.SIZE request item later in the same session.
メッセージが別のセッションで抹消されている場合、サーバーは、同じセッションの後半でBINARY.SIZE要求項目に応じて、値0を返すことがあります。
In order to allow for upgrade of server transcoding components, clients MUST NOT assume that repeating a particular body part conversion in another IMAP "session" would yield the same result as a previous conversion of the very same body part -- any characteristics of the converted body part might be different (format, size, etc.). In particular, clients MUST NOT cache sizes of converted messages/ body parts beyond duration of any IMAP "session", or use sizes obtained in one connection in another IMAP connection to the same server.
変換後の任意の特性 - サーバ・トランスコーディング・コンポーネントのアップグレードを可能にするために、クライアントは、別のIMAPに特定の身体部分の変換を繰り返す「セッション」は非常に同じ身体部分の前の変換と同じ結果をもたらすであろうと仮定してはいけません本体部分は、異なる（フォーマット、サイズ、等）であるかもしれません。具体的には、クライアントは任意のIMAP「セッション」の期間を越えて変換されたメッセージ/身体の部分のキャッシュサイズ、または使用サイズが同じサーバーに別のIMAP接続内の1つの接続で得られてはなりません。
Historical note: Previous experience with IMAP servers that returned estimated RFC822.SIZE value shows that this caused interoperability problems. If the server returns a value that is smaller than the actual size, this will result in data truncation if <partial> download is used. If the server returns a value that is bigger than the actual size, this might mislead a client to believe that it doesn't have enough storage to download a body part.
ヒストリカルノート：推定RFC822.SIZE値を返すIMAPサーバとの経験があると、これは相互運用性の問題を引き起こしたことを示しています。サーバーは、実際のサイズよりも小さい値を返す場合、<部分>ダウンロードが使用されている場合、これはデータの切り捨てになります。サーバーは、実際のサイズよりも大きい値を返す場合、これは身体の部分をダウンロードするための十分なストレージを持っていないことを信じるようにクライアントを欺くことがあります。
Note for client implementors: client authors are cautioned that this might be an expensive operation for some server implementations. Requesting BINARY.SIZE for a large number of converted body parts or for multiple conversions of the same body part can result in slow performance and/or excessive server load and is discouraged. Client implementors should consider implementation approaches that limit this request to only the most necessary cases and are encouraged to test the performance impact of BINARY.SIZE with multiple server implementations.
クライアントの実装のための注意：クライアントの著者は、これはいくつかのサーバの実装のために高価な操作であるかもしれないと警告しています。変換された身体部分の多数の又は同一の身体部分の複数の変換のためのBINARY.SIZEを要求すると、パフォーマンスの低下、および/または過剰なサーバ負荷と推奨さをもたらすことができます。クライアントの実装者は、唯一の最も必要な場合には、この要求を制限し、複数のサーバの実装とBINARY.SIZEのパフォーマンスへの影響をテストすることが奨励されている実装のアプローチを検討すべきです。
AVAILABLECONVERSIONS[section-part] allows the client to request the list of target MIME types the specified body part of a message or the whole message can be converted to. This data item is only useful when the default conversion (see Section 6) is requested.
AVAILABLECONVERSIONS [セクション部分]は、クライアントがメッセージの指定された身体の一部または全部のメッセージをに変換することができる目標MIMEタイプのリストを要求することを可能にします。デフォルトの変換は（セクション6を参照）が要求されたとき、このデータ項目にのみ有効です。
This data item MUST return a list of target MIME types that is a subset of the list returned by the CONVERSIONS command for the same source and target MIME type pairs. If specific conversion is requested, it MUST return the target MIME type as requested in the CONVERT command, or the ERROR phrase.
このデータ項目は、同じソースおよびターゲットMIMEタイプペアのコンバージョンコマンドによって返されたリストのサブセットである目標MIMEタイプのリストを返さなければなりません。具体的な変換が要求された場合CONVERTコマンド、またはERRORフレーズで要求され、それがターゲットMIMEタイプを返さなければなりません。
For both specific or default conversion requests, if conversion parameters are specified, then the server must take them into consideration when generating the list of target MIME types. For example, if one or more of the conversion parameters doesn't apply to a potential target MIME type, then such MIME type MUST be omitted from the resulting list. If the server only had a single target MIME type candidate and it was discarded due to the list of conversion parameters, then the server SHOULD return the ERROR phrase instead of the empty list of the target MIME types.
変換パラメータが指定されている場合は、ターゲットMIMEタイプのリストを生成するときに、両方の特定またはデフォルト変換要求については、サーバは考慮にそれらを取る必要があります。変換パラメータの1つ以上が潜在的な標的MIMEタイプに適用されない場合、例えば、そのようなMIMEタイプは、結果のリストから除外されなければなりません。サーバーが単一のターゲットMIMEタイプの候補を持っていたし、それは、変換パラメータのリストが原因で廃棄された場合、サーバはERROR句の代わりに、ターゲットMIMEタイプの空のリストを返すべきです。
The AVAILABLECONVERSIONS request SHOULD be processed quickly if specified by itself. Note that if a MIME type is returned in response to the AVAILABLECONVERSIONS, there is no guaranty that the corresponding BINARY/BINARY.SIZE/BODYPARTSTRUCTURE CONVERT request will not fail.
それ自体で指定されている場合AVAILABLECONVERSIONS要求はすぐに処理されるべきです。 MIMEタイプがAVAILABLECONVERSIONSに応答して返された場合、対応するバイナリ/ BINARY.SIZE / BODYPARTSTRUCTUREのCONVERT要求は失敗しないという保証がないことに注意してください。
Example: C: f001 CONVERT 2 (NIL) (AVAILABLECONVERSIONS[2]) S: * 2 CONVERTED (TAG "f001") (AVAILABLECONVERSIONS[2] (("IMAGE/JPEG" "application/PostScript")) S: f001 OK CONVERT COMPLETED
例：C：F001のCONVERT 2（NIL）（AVAILABLECONVERSIONS [2]）S * 2 CONVERTED（TAG "F001"）（AVAILABLECONVERSIONS [2]（（ "IMAGE / JPEG" "アプリケーション/ポストスクリプト"））S：F001 OK CONVERT COMPLETED
Note that this section is normative.
このセクションは規範的であることに注意してください。
Servers MAY refuse to execute conversion requests that convert multiple messages and/or body parts at once, e.g., a conversion request that specifies multiple message numbers/UIDs. If the server refuses a conversion because the request lists too many messages, the server MUST return the MAXCONVERTMESSAGES response code (see Section 9). For example:
サーバは、例えば、一度に複数のメッセージおよび/または体の部分を変換する変換要求を実行するために、複数のメッセージ番号/ UIDを指定する変換要求を拒否することができます。要求があまりにも多くのメッセージを一覧表示するので、サーバーが変換を拒否した場合、サーバは（セクション9を参照）MAXCONVERTMESSAGESレスポンスコードを返さなければなりません。例えば：
C: g001 CONVERT 1:* ("text/plain" ("charset" "us-ascii"))
BINARY[3]
S: g001 NO [MAXCONVERTMESSAGES 1]
If the server refuses a conversion because the request lists too many body parts, the server MUST return the MAXCONVERTPARTS response code (see Section 9). For example:
要求があまりにも多くの体の部分を示していますので、サーバーが変換を拒否した場合、サーバは（セクション9を参照）MAXCONVERTPARTSレスポンスコードを返さなければなりません。例えば：
C: h001 CONVERT 1 ("text/plain" ("charset" "us-ascii")) (BINARY[1] BINARY[2])
C：H001 1（ "text / plainの"（ "文字セット" "US-ASCII"））を変換（BINARY [1] BINARY [2]）
S: g001 NO [MAXCONVERTPARTS 1] You can only request 1 body part at any given time
S：G001 NO [MAXCONVERTPARTS 1]あなたは、任意の時点で1体の一部のみを要求することができます
Note for server implementors: In order to improve performance, implementations SHOULD cache converted body parts. For example, the server may perform a body part conversion when it receives the first BINARY.SIZE[...], BODYPARTSTRUCTURE[...], or BINARY[...] request and cache it until the client requests conversion/download of another body part, a different conversion of the same body part, or until the mailbox is closed. In order to mitigate denial-of-service attacks from misbehaving or badly-written clients, a server SHOULD limit the number of converted body parts it can cache. Servers SHOULD be able to cache at least 2 conversions at any given time.
サーバーの実装者への注意：パフォーマンスを改善するために、実装は、変換された体の部分をキャッシュすべきです。例えば、それは最初BINARY.SIZEを受信したとき、サーバは[...]ボディ部の変換を行うことができる、BODYPARTSTRUCTURE [...]、またはBINARY [...]要求し、クライアントは、変換/ダウンロードを要求するまで、それをキャッシュ別の身体部分、同一の身体部分の異なる変換、またはメールボックスが閉じられるまで。誤動作またはひどく書かれたクライアントからのサービス拒否攻撃を軽減するために、サーバーは、それがキャッシュできる変換後の体の部分の数を制限する必要があります。サーバーは、任意の時点で、少なくとも2つの変換をキャッシュすることができるべきです。
A syntactically invalid MIME media type SHOULD generate a BAD tagged response from the server. An unrecognized MIME media type generates a NO tagged response.
構文的に不正なMIMEメディアタイプは、サーバーからのBADタグ付けされた応答を生成する必要があります。認識されないMIMEメディアタイプはNOタグ付けされた応答を生成します。
Some transcodings may require parameters. If a transcoding request with no parameters is sent for a format which requires parameters, the server will return an ERROR MISSINGPARAMETERS phrase in place of the data associated with the data items requested. This is analogous to the NIL response in FETCH, but with structured data associated with the failure.
いくつかのトランスコーディングにはパラメータが必要な場合があります。パラメータなしでトランスコーディング要求はパラメータを必要とする形式のために送られた場合、サーバは要求されたデータ項目に関連付けられたデータの代わりにERRORのMISSINGPARAMETERSフレーズを返します。これは、FETCHでNIL応答と類似しているが、故障に関連した構造化データを有します。
If the server is unable to perform the requested conversion because a resource is temporary unavailable (e.g., lack of disk space, temporary internal error, transcoding service down), then the server MUST return a tagged NO response that SHOULD contain the TEMPFAIL response code (see below), or an ERROR TEMPFAIL phrase.
サーバはリソースが一時的であるため、要求された変換を実行することができない場合には使用できません（例えば、ディスク・スペース、一時的な内部エラー、トランスコーディングサービスダウンの欠如）は、サーバは（TEMPFAIL応答コードを含むべきタグ付きNO応答を返さないしなければなりません下記を参照）、またはERRORのTEMPFAILフレーズ。
If the requested conversion cannot be performed because of a permanent error, for example, if a proprietary document format has no existing transcoding implementation, the server MUST return a CONVERTED response containing a ERROR BADPARAMETERS or ERROR MISSINGPARAMETERS phrase.
要求された変換が原因で永続的なエラーで実行できない場合は、独自の文書フォーマットは既存のトランスコーディングの実装を持っていない場合、例えば、サーバはERRORのBADPARAMETERSまたはERRORのMISSINGPARAMETERSフレーズを含むCONVERTED応答を返さなければなりません。
The server MAY choose to return one ERROR phrase for a single conversion if several related data items are requested. For instance:
サーバーは、いくつかの関連データ項目が要求されている場合は、単一の変換のために1つのERRORフレーズを返すために選ぶかもしれません。例えば：
C: b002 CONVERT 2 ("text/plain" ("charset" "us-ascii")) (BINARY[3] BODYPARTSTRUCTURE[3]) S: * 2 CONVERTED (tag "b002") (BODYPARTSTRUCTURE[3] (ERROR "Source text has non us-ascii" BADPARAMETERS "text/html" "text/plain" ("charset" "us-ascii"))) S: b002 NO All conversions failed
C：B002 CONVERT 2（ "text / plainの"（ "文字セット" "US-ASCII"））（BINARY [3] BODYPARTSTRUCTURE [3]）S * 2 CONVERTED（タグ "B002"）（BODYPARTSTRUCTURE [3]（ERROR ））S BADPARAMETERS "text / htmlの" "text / plainの"（ "文字セット" "US-ASCII"） "ソース・テキストがUS-ASCII以外を持っていない"：B002はNOすべての変換に失敗しました
If at least one conversion succeeds, the server MUST return an OK response. If all conversions fail, the server MAY return OK or NO. For instance:
少なくとも一つの変換が成功すると、サーバーはOK応答を返さなければなりません。すべての変換が失敗した場合、サーバはOKかNO返してもよいです。例えば：
C: b002 CONVERT 2 ("text/plain" ("charset" "us-ascii")) (BINARY[3] BODYPARTSTRUCTURE[3] BINARY[4] BODYPARTSTRUCTURE[4]) S: * 2 CONVERTED (tag "b002") (BODYPARTSTRUCTURE[3] (ERROR "Source text has non us-ascii" BADPARAMETERS "text/html" "text/plain" ("charset" "us-ascii")) BODYSTRUCTURE[4] ("TEXT" "PLAIN" (CHARSET US-ASCII) NIL NIL "8bit" 4182 NIL NIL NIL) BINARY[4] {4182} <body in text plain> ) S: b002 OK Some conversions failed
C：B002 CONVERT 2（ "text / plainの"（ "文字セット" "US-ASCII"））（BINARY [3] BODYPARTSTRUCTURE [3] BINARY [4] BODYPARTSTRUCTURE [4]）S * 2 CONVERTED（タグ "B002" ）（BODYPARTSTRUCTURE [3]（ERROR BADPARAMETERS "ソース・テキストがUS-ASCII以外を持っている" "text / htmlの" "text / plainの"（ "文字セット" "US-ASCII"））BODYSTRUCTURE [4]（ "TEXT" "PLAIN" （CHARSET US-ASCII）NIL NIL "8ビット" 4182 NIL NIL NIL）BINARY）S [4] {4182} <テキスト普通ボディ>：B002 OK一部の変換が失敗しました
In general, the client can tell from the BODYPARTSTRUCTURE response whether or not its request was honored exactly, but may not know the reasons why.
一般的には、クライアントはその要求を正確に受賞したかどうかBODYPARTSTRUCTURE応答から伝えることができますが、理由がわからないかもしれません。
This document defines the following response codes that can be returned in the tagged NO response code.
この文書は、タグ付けされたNO応答コードに返すことができる次の応答コードを定義します。
TEMPFAIL - The transcoding request failed temporarily. It might succeed later, so the client MAY retry.
TEMPFAIL - 要求が一時的に失敗したトランスコーディング。それは後に成功するかもしれないので、クライアントが再試行するかもしれません。
MAXCONVERTMESSAGES <number> - The server is unable or unwilling to convert more than <number> messages in any given CONVERT/UID CONVERT request.
MAXCONVERTMESSAGES <番号> - サーバーが任意のCONVERT / UIDのCONVERT要求で<番号>のメッセージよりも多くを変換することができないか、不本意です。
MAXCONVERTPARTS <number> - The server is unable or unwilling to convert more than <number> body parts of a message at once in any given CONVERT/UID CONVERT request.
MAXCONVERTPARTS <番号> - サーバーは、任意のCONVERT / UIDのCONVERT要求に一度メッセージの<番号>身体の部分よりも変換することができない、または不本意です。
The word ERROR is always followed by an informal human-readable descriptive text, which is followed by the convert-error-code. The convert-error-code MUST be one of the following:
ワードERRORは、常に変換・エラー・コードが続いている非公式の人間が読める記述テキスト、が続いています。変換エラー・コードは、次のいずれかを指定します。
TEMPFAIL mm - The transcoding request failed temporarily. It might succeed later, so the client MAY retry. The client SHOULD wait for at least mm minutes before retrying.
TEMPFAILミリメートル - トランスコーディング要求が一時的に失敗しました。それは後に成功するかもしれないので、クライアントが再試行するかもしれません。クライアントが再試行する前に、少なくともミリメートル分間待つ必要があります。
BADPARAMETERS from-concrete-mime-type to-mime-type "(" transcoding-params ")" - The listed parameters were not understood, not valid for the source/destination MIME type pair, had invalid values or could not be honored for another reason noted in the human-readable text that was specified after the ERROR label. The transcoding-params can be omitted, in which case, it means that the conversion from the from-concrete-mime-type to the to-mime-type is not possible. If the from-concrete-mime-type is NIL, this means that the specified body part doesn't exist. All unrecognized or irrelevant parameters MUST be listed in the transcoding-params. It is not legal behavior to ignore irrelevant parameters.
コンクリート-MIMEタイプへのMIMEタイプ「（」トランスコーディング-paramsは「）」BADPARAMETERS - リストされたパラメータは、送信元/宛先MIMEタイプペアに対して有効ではない、理解されていないし、無効な値を有していたか、のために受け入れられませんでしたもう一つの理由は、ERRORラベルの後に指定されていた人間が読めるテキストで述べました。トランス-paramsが、その場合、それが、MIMEタイプにから、コンクリートMIMEタイプからの変換が可能でないことを意味し、省略することができます。コンクリート-MIMEタイプがNILであるならば、これは指定された身体の部分が存在しないことを意味します。すべての認識できないか、無関係なパラメータは、トランスコーディング-のparamsにリストされなければなりません。無関係なパラメータを無視する法的動作ではありません。
Note that if the client requested the "default conversion" (see
Section 6), the to-mime-type contains the destination MIME type
chosen by the server.
MISSINGPARAMETERS from-concrete-mime-type to-mime-type "(" transcoding-params ")" - The listed parameters are required for conversion of the specified source MIME type to the destination MIME type, but were not seen in the request. Note that if the client requested the "default conversion" (see Section 6), the to-mime-type contains the destination MIME type chosen by the server.
列挙されたパラメータは、先のMIMEタイプに指定されたソースMIMEタイプの変換のために必要とされるが、要求には見られなかった - からコンクリート-MIMEタイプへのMIMEタイプ「（」トランスコーディング-paramsは「）」MISSINGPARAMETERS。クライアントは、「デフォルトの変換を」（第6章を参照してください）要求された場合に、MIMEタイプのサーバによって選択された宛先のMIMEタイプが含まれていることに注意してください。
Examples:
例：
C: b002 CONVERT 2 ("APPLICATION/PDF") BINARY[3] S: b002 NO [TEMPFAIL] All conversions failed
C：B002 CONVERT 2（ "アプリケーション/ PDF"）BINARY [3] S：B002は、NO [TEMPFAIL]すべての変換に失敗しました
C: b003 CONVERT 2 ("TEXT/PLAIN") BINARY[3] S: * 2 CONVERTED (tag "b003") (BINARY[3] (ERROR "CHARSET must be specified for text conversions" MISSINGPARAMETERS (CHARSET))) S: b003 NO All conversions failed
C：B003のCONVERT 2（ "TEXT / PLAIN"）BINARY [3] S：* 2 CONVERTED（タグ "B003"）S（BINARY [3]（ERROR MISSINGPARAMETERS（CHARSET））、 "文字セットがテキスト変換のために指定されなければなりません"） ：B003 NOすべての変換が失敗しました
C: b005 CONVERT 2 ("TEXT/PLAIN" (CHARSET "US-ASCII" UNKNOWN-CHARACTER-REPLACEMENT "<badchar>")) BINARY[3] S: * 2 CONVERTED (tag "b005") (BINARY[3] (ERROR "UNKNOWN-CHARACTER-REPLACEMENT limited to 4 bytes" BADPARAMETERS (UNKNOWN-CHARACTER-REPLACEMENT "<badchar>"))) S: b005 NO All conversions failed
C：B005 CONVERT 2（ "text / plainの"（CHARSET "US-ASCII" UNKNOWN文字置換 "<badchar>"））BINARY [3] S：* 2 CONVERTED（タグ "B005"）（BINARY [3] （ERROR BADPARAMETERS（UNKNOWN文字置換 "<badchar>"） "4バイトに制限UNKNOWN文字置換"））S：B005はNOすべての変換に失敗しました
The following syntax specification uses the augmented Backus-Naur Form (ABNF) notation as used in [ABNF], and incorporates by reference the core rules defined in that document.
以下の構文仕様は、[ABNF]で使用される拡張バッカス・ナウアフォーム（ABNF）表記を使用し、参照によりその文書に定義されているコア・ルールを組み込みます。
This syntax augments the grammar specified in [RFC3501] and [RFC3516]. Non-terminals not defined in this document can be found in [RFC3501], [RFC3516], [IMAPABNF], [MIME-MTSRP], and [MEDIAFEAT-REG].
この構文は、[RFC3501]と[RFC3516]で指定された文法を強化します。この文書で定義されていない非端末は[RFC3501]、[RFC3516]、[IMAPABNF]、[MIME-MTSRP]、および[MEDIAFEAT-REG]に見出すことができます。
command-select =/ convert
コマンド選択= /変換
uid =/ "UID" SP convert ; Unique identifiers used instead of message ; sequence numbers
UID = / "UID" SPコンバート。代わりに、メッセージの使用一意の識別子。シーケンス番号
convert = "CONVERT" SP sequence-set SP convert-params SP ( convert-att / "(" convert-att *(SP convert-att) ")" )
変換= "変換" SPシーケンスセット変換SP-SPのparamsは（変換-ATT / "（" 変換-ATTの*（SP変換-ATT）を "）"）
convert-att = "UID" / "BODYPARTSTRUCTURE" section-convert / "BINARY" section-convert [partial] / "BINARY.SIZE" section-convert / "BODY[HEADER]" / "BODY[" section-part ".HEADER]" / "BODY[" section-part ".MIME]" / "AVAILABLECONVERSIONS" section-convert
-ATT、変換= "UID" / "BODYPARTSTRUCTURE" セクションコンバート/ "バイナリ" セクションコンバート[パーシャル] / "BINARY.SIZE" セクションコンバート/ "BODY [HEADER]" / "BODY [" セクション部分」。 HEADER] "/ "BODY [" セクション部" .MIME]」/ "AVAILABLECONVERSIONS" セクションコンバート
; <partial> is defined in [RFC3516].
; <section-part> is defined in [RFC3501].
convert-params = "(" (quoted-to-mime-type / default-conversion) [SP "(" transcoding-params ")"] ")"
変換-paramsは= "（"（引用ツーMIMEタイプ/デフォルト変換）[SP "（" トランスコーディング-paramsは "）"] "）"
quoted-to-mime-type = DQUOTE to-mime-type DQUOTE
引用されたツーMIMEタイプ= DQUOTEへのMIMEタイプのDQUOTE
transcoding-params = transcoding-param *(SP transcoding-param)
トランスコーディング-のparams =トランスコーディング-のparam *（SPトランスコーディング-PARAM）
transcoding-param-names = transcoding-param-name *(SP transcoding-param-name)
トランスコーディング-PARAM-名=トランスコーディング-PARAM名*（SPトランスコーディング-のparam-名）
transcoding-param = transcoding-param-name SP transcoding-param-value
トランスコーディング-PARAM =トランスコーディング-PARAM名SPトランスコーディング-PARAM値
transcoding-param-name = astring ; <transcod-param-name-nq> represented as a quoted, ; literal or atom. Note that ; <transcod-param-name-nq> allows for "%", which is ; not allowed in atoms. Such values must be ; represented as quoted or literal.
トランスコーディング-のparam-nameはのAStringを=。 <transcod-PARAM名-NQ>引用されたとして、表現。リテラルまたは原子です。ご了承ください ; <transcod-PARAM名-NQ>は "％" を可能にします。原子では使用できません。このような値でなければなりません。引用されたか、リテラルとして表現。
transcod-param-name-nq = Feature-tag ; <Feature-tag> is defined in [MEDIAFEAT-REG].
transcod-PARAM名-NQ =機能タグ; <特集タグ>は、[MEDIAFEAT-REG]で定義されています。
transcoding-param-value = astring
トランスコーディング-PARAM値=文字列
default-conversion = "NIL"
デフォルトの変換=「NIL」
message-data =/ nz-number SP "CONVERTED" SP convert-correlator SP convert-msg-attrs
SP変換相関器のSPコンバート-MSG-attrsに "変換" メッセージデータ= / NZ-番号SP
convert-correlator = "(" "TAG" SP tag-string ")"
変換相関器= "（" "TAG" SPタグ文字列 "）"
tag-string = string ; tag of the command that caused ; the CONVERTED response, sent as ; a string.
タグ文字列=文字列。原因となったコマンドのタグ; CONVERTED応答は、のように送られました。文字列。
convert-msg-attrs = "(" convert-msg-att *(SP convert-msg-att) ")" ; "UID" MUST be the first data item, if present.
変換-MSG-ATTRS = "（" 変換-MSG-のatt *（SP変換-MSG-ATT）を "）"。存在する場合、「UID」は、最初のデータ項目でなければなりません。
convert-msg-att = msg-att-semistat / msg-att-conv-static
変換対MSG = MSG半状態/ MSGツーCONV静的に
msg-att-conv-static = "UID" SP uniqueid ; MUST NOT change for a message
MSG-ATT-CONV-静的= "UID" SPの一意ID。メッセージを変えてはいけません
msg-att-semistat = ( "BINARY" section-convert ["<" number ">"] SP (nstring / literal8 / converterror-phrase) ) / ( "BINARY.SIZE" section-convert SP (number / converterror-phrase) ) / ( "BODYPARTSTRUCTURE" section-convert SP (body / converterror-phrase) ) / ( "AVAILABLECONVERSIONS" section-convert SP (mimetype-list / converterror-phrase) ) ; MUST NOT change during an IMAP "session", ; but not necessarily static in the long term.
MSG-ATT-semistat =（ "バイナリ" セクションコンバート[ "<" 番号 ">"] SP（nstring / literal8 / converterrorフレーズ））/（ "BINARY.SIZE" セクションコンバートSP（数/ converterrorフレーズ））/（ "BODYPARTSTRUCTURE" セクションコンバートSP（本体/ converterrorフレーズ））/（ "AVAILABLECONVERSIONS" セクションコンバートSP（MIMEタイプリスト/ converterrorフレーズ））。 、IMAP「セッション」の間に変化してはなりません。しかし、長期的には必ずしも静的ではありません。
section-convert = section-binary
; <section-binary> is defined in [RFC3516].
;
; Note that unlike [RFC3516], conversion
; of a top level multipart/* is allowed.
resp-text-code =/ "TEMPFAIL" / "MAXCONVERTMESSAGES" SP nz-number / "MAXCONVERTPARTS" SP nz-number ; <resp-text-code> is defined in [RFC3501].
RESPテキストコード= / "TEMPFAIL" / "MAXCONVERTMESSAGES" SP NZ-数/ "MAXCONVERTPARTS" SPのNZ-番号。 <RESPテキストコード> [RFC3501]で定義されています。
mimetype-and-params = quoted-to-mime-type [SP "(" transcoding-params ")"] ; always includes a specific MIME type
引用ツーMIMEタイプMIMEタイプアンドのparams = [SP "（" トランスコーディング-paramsは "）"]。常に特定のMIMEタイプを含み
mimetype-list = "(" "(" [quoted-to-mime-type *(SP quoted-to-mime-type)] ")" ")" ; Unordered list of MIME types. It can be empty. ; ; Two levels of parenthesis is needed to distinguish this ; data from <converterror-phrase>.
MIMEタイプリスト=「（」「（」[引用ツーMIMEタイプ*（SP引用ツーMIMEタイプ）]「）」「）」。 MIMEタイプの順序なしリスト。それは空にすることができます。 ; ;括弧の二つのレベルがこれを区別するために必要とされています。 <converterrorフレーズ>からのデータ。
converterror-phrase = "(" "ERROR" SP convert-err-descript SP convert-error-code ")"
converterrorフレーズは= "（" "ERROR" SP変換-ERR-descriptのSPのconverterrorコード "）"
convert-error-code = "TEMPFAIL" [SP nz-number] / bad-params / missing-params
-paramsは欠落= "TEMPFAIL" [SP NZ-数] /不良のparams /エラーコードを変換します
convert-err-descript = string ; Human-readable text explaining the conversion error. ; The default charset is US-ASCII, unless ; the LANGUAGE command [IMAP-I18N] is called, when ; the charset changes to UTF-8.
=文字列-ERR-descriptのを変換します。変換エラーを説明する人間が読めるテキスト。 ;デフォルトの文字セットがない限り、US-ASCII、です。 LANGUAGEコマンド[IMAP-I18N]は、ときに呼び出されます。文字セットはUTF-8に変更します。
quoted-from-mime-type = DQUOTE from-concrete-mime-type DQUOTE bad-params = "BADPARAMETERS" 1*(SP (quoted-from-mime-type / nil) SP mimetype-and-params) ; nil is only returned when the body part doesn't exist.
引用-から、MIMEタイプ= DQUOTEからコンクリート-MIMEタイプDQUOTE不良のparams = "BADPARAMETERS" 1 *（SP（引用-から、MIMEタイプ/ NIL）SPのMIMEタイプ・アンド・paramsは）。 nilは身体の部分が存在しない場合にのみ返されます。
missing-params = "MISSINGPARAMETERS" 1*(SP quoted-from-mime-type SP mimetype-and-missing-params)
行方不明のparams = "MISSINGPARAMETERS" 1 *（SP引用し-から、MIMEタイプSPのMIMEタイプ-と欠落-のparams）
mimetype-and-missing-params = quoted-to-mime-type "(" transcoding-param-names ")" ; always includes a specific MIME type
引用されたツーMIMEタイプMIMEタイプ-と欠落-のparams = "（" トランスコーディング-PARAM-名 "）";常に特定のMIMEタイプを含み
concrete-mime-type = type-name "/" subtype-name ; i.e., "type/subtype". ; type-name and subtype-name ; are defined in [MIME-MTSRP].
コンクリートMIMEタイプ=タイプ名「/」サブタイプ名;すなわち、「タイプ/サブタイプ」。 ;型名およびサブタイプ名; [MIME-MTSRP]で定義されています。
from-concrete-mime-type = concrete-mime-type
コンクリート-MIMEタイプ=コンクリートMIMEタイプ
to-mime-type = concrete-mime-type
MIMEタイプ=コンクリートMIMEタイプ
command-auth =/ conversions-cmd
コマンド-AUTH = /コンバージョン-CMD
conversions-cmd = "CONVERSIONS" SP from-mime-type-req SP to-mime-type-req
コンバージョン-CMD = "変換" SPから、MIMEタイプ-REQ SPへのMIMEタイプ-REQ
from-mime-type-req = astring ; "mime-type-req" represented as IMAP <atom>, ; <quoted> or <literal>
-MIMEタイプ-REQ =のAString。 IMAP <原子>として表さ "MIMEタイプ-REQ"。 <引用さ>や<リテラル>
to-mime-type-req = astring ; <mime-type-req> represented as IMAP <atom>, ; <quoted> or <literal>. ; Note that <mime-type-req> allows for "*", ; which is not allowed in <atom>. Such values must ; be represented as <quoted> or <literal>.
MIMEタイプ-REQ =のAString。 <MIMEタイプ-REQ> <原子> IMAPとして表され、; <引用さ>や<リテラル>。 ; "*" を可能にすること、<MIMEタイプ-REQ>に注意してください; <原子>で許可されていません。このような値なければなりません。以下のように表すことが<引用さ>や<リテラル>。
any-mime-type = "*"
任意の-MIMEタイプ= "*"
mime-type-req = any-mime-type /
(type-name "/" any-mime-type) /
concrete-mime-type
; '*', 'type/*' or 'type/subtype'.
; type-name is defined in [MIME-MTSRP].
response-payload =/ conversion-data conversion-data = "CONVERSION" SP quoted-from-mime-type SP quoted-to-mime-type [SP "(" transcoding-param-name *(SP transcoding-param-name) ")"]
応答ペイロード= / A変換データ変換データ= "変換" SP引用-から-MIMEタイプSP引用ツーMIMEタイプ[SP "（" トランスコーディング-PARAM名*（SPトランスコーディング-PARAM名） "）"]
The monitoring of CONVERT operation is similar to monitoring of the IMAP FETCH operation.
CONVERT操作の監視がIMAPフェッチオペレーションのモニタリングと同様です。
At the time of writing this document, there is no standard IMAP MIB defined. Similarly, a standard MIB for monitoring CONVERT operations and their failures does not exist. However, the authors believe that in the absence of such a MIB, server implementations SHOULD provide operators with tools to report the following information:
この文書を書いている時点で、MIBが定義された標準的なIMAPはありません。同様に、監視のための標準MIBは、操作を変換し、それらの障害は存在しません。しかし、著者は、このようなMIBがない場合には、サーバーの実装は、以下の情報を報告するためのツールをオペレータに提供すべきであると信じています：
o which conversions (source and target MIME types and possibly conversion parameters used) are invoked more frequently and how long they take,
O、どの変換が（MIMEタイプとおそらくは用いる変換パラメータをソースおよびターゲット）より頻繁に呼び出され、それらは取るどのくらい
o information about conversion errors and which error condition caused them (see Section 9), and
O変換エラーに関する情報と条件がそれらの原因となったエラー（9章を参照のこと）、及び
o information about users which invoke conversion operation.
O変換動作を呼び出すユーザーに関する情報。
This information can help operators to detect client abuse of this extension and scalability issues that might arise from its use.
この情報は、事業者は、その使用から生じる可能性のあるこの拡張性とスケーラビリティの問題のクライアントの乱用を検出することができます。
Standardizing these tools may be the subject of future work.
これらのツールを標準化する今後の作業の対象となる場合があります。
IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC. This document defines the CONVERT IMAP capability. IANA has added this extension to the IANA IMAP Capability registry.
IMAP4機能は標準化過程かIESGが承認した実験的RFCを公開することにより、登録されています。この文書では、CONVERTのIMAP機能を定義します。 IANAはIANA IMAP能力のレジストリにこの拡張機能を追加しました。
IANA has performed registrations as defined in the following subsections.
以下のサブセクションで定義されているIANAは登録を行っています。
12.1. Registration of unknown-character-replacement Media Type Parameter
12.1. 未知の文字の置換メディアタイプパラメータの登録
IANA has added the following registration to the registry established by RFC 2506.
IANAはRFC 2506によって確立されたレジストリに以下の登録を追加しました。
To: "Media feature tags mailing list" <media-feature-tags@apps.ietf.org>
To：「メーリングリストメディア機能タグ」<media-feature-tags@apps.ietf.org>
Subject: Registration of media feature tag unknown-character-replacement
件名：メディア特徴タグ未知の文字の置換の登録
Media feature tag name: unknown-character-replacement
メディアフィーチャータグ名：不明な文字の置換
ASN.1 identifier associated with feature tag: 1.3.6.1.8.1.33
フィーチャータグに関連するASN.1識別子：1.3.6.1.8.1.33
Summary of the media feature indicated by this feature tag: Allows servers that can perform charset conversion for text/plain text/html, text/css, text/csv, text/enriched, and text/xml MIME types to replace characters not supported by the target charset with a fixed string, such as "?". This feature tag is also applicable to other conversions to text, e.g., conversion of images using OCR (optical character recognition).
この機能のタグで示されるメディアフィーチャーの概要：テキスト/プレーンテキスト/ HTML、テキスト/ CSS、テキスト/ CSV、テキスト/濃縮、およびtext / xmlでのMIMEタイプに対して文字セット変換を実行することができ、サーバがでサポートされていない文字を置換することができます以下のような固定文字列とターゲット文字セット、「？」。この特徴タグは、テキストへの他の変換にも適用可能である、例えば、OCR（光学式文字認識）を使用して画像の変換。
Values appropriate for use with this feature tag: The feature tag contains a UTF-8 string used to replace any characters from the source media type that can't be represented in the target media type.
この機能タグで使用するための適切な値：フィーチャータグは、ターゲットメディアタイプでは表現できないソースメディアの種類から任意の文字を置き換えるために使用されるUTF-8文字列が含まれています。
The feature tag is intended primarily for use in the following applications, protocols, services, or negotiation mechanisms: IMAP CONVERT extension [RFC5259]
IMAPのCONVERT拡張[RFC5259]：フィーチャータグは、主に以下のアプリケーション、プロトコル、サービス、または交渉メカニズムにおける使用を意図しています
Examples of typical use: C: b001 CONVERT 2 BINARY[3 ("text/plain" ("charset" "us-ascii" "unknown-character-replacement" "?"))]
典型的な使用例：C：B001 CONVERT 2 BINARY [3（ "text / plainの"（ "文字セット" "US-ASCII" "未知の文字置換" ""）？）]
Related standards or documents: [RFC5259] [CHARSET-REG]
関連の規格や文書：[RFC5259] [CHARSET-REG]
Considerations particular to use in individual applications, protocols, services, or negotiation mechanisms: None
個々のアプリケーション、プロトコル、サービス、または交渉メカニズムで使用する特定の考慮事項：なし
Interoperability considerations: None
相互運用性に関する注意事項：なし
Security considerations: None
セキュリティの考慮事項：なし
Additional information: This media feature only make sense for MIME types that also support the "charset" media type parameter [CHARSET-REG].
追加情報：このメディア機能だけでも、「文字セット」のメディアタイプパラメータ[CHARSET-REG]をサポートするMIMEタイプのために意味をなします。
Name(s) & email address(es) of person(s) to contact for further information: Alexey Melnikov <alexey.melnikov@isode.com>
名（複数可）＆電子メールアドレス詳細のために連絡する人（複数可）の（ES）：アレクセイ・メルニコフ<alexey.melnikov@isode.com>
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: IETF
著者/変更コントローラ：IETF
Requested IANA publication delay: None
要求されたIANA公開ディレイ：なし
Other information: None
その他の情報：なし
It is to be noted that some conversions may present security threats (e.g., converting a document to a damaging executable, exploiting a buffer overflow in a media codec/parser, or a denial-of-service attack against a client or a server such as requesting an image be scaled to extremely large dimensions). Server SHOULD refuse to execute CPU-expensive conversions. Servers should avoid dangerous conversions if possible. Whenever possible, servers should perform verification of the converted attachments before returning them to the client. Clients should be careful when requesting conversions or processing transformed attachments. Clients SHOULD use mutual Simple Authentication and Security Layer (SASL) authentication and the SASL/ TLS integrity layer, to make sure they are talking to trusted servers.
これは、いくつかの変換は、（セキュリティ上の脅威を提示してもよいことに留意すべきである、例えば、メディアコーデック/パーサのバッファオーバーフロー、またはクライアントまたはサーバなどに対するサービス拒否攻撃を利用する、損傷実行に文書を変換します）画像非常に大きな寸法にスケーリングすることを要求します。サーバーは、CPU-高価な変換を実行することを拒否すべきです。可能な場合、サーバーが危険な変換を避ける必要があります。可能な限り、サーバーは、クライアントに戻す前に、変換された添付ファイルの検証を行う必要があります。変換を要求するか、変換の添付ファイルを処理する際に、クライアントは注意する必要があります。クライアントは、信頼されたサーバーへの話していることを確認するために、相互簡易認証セキュリティー層（SASL）認証およびSASL / TLSの整合層を使用すべきです。
When the client requests a server-side conversion of a signed body part (e.g., a part inside multipart/signed), there is no way for the client to verify that the converted content is authentic. A client not trusting the server to perform conversion of a signed body part can download the signed object, verify the signature, and perform the conversion itself.
クライアントは、（例えば、マルチ内側部/署名された）署名された身体部分のサーバー側の変換を要求すると、クライアントは、変換されたコンテンツが真正であることを確認するための方法はありません。署名された身体部分の変換を実行するサーバを信頼しないクライアントは、署名されたオブジェクトをダウンロード署名を検証し、変換自体を行うことができます。
A client can create a carefully crafted bad message with the APPEND command followed by the CONVERT command to attack the server. If the server's conversion function or library has a security problem (such as vulnerability to a buffer overflow), this could result in privilege escalation or denial of service. In order to mitigate such attacks, servers SHOULD log the client authentication identity on APPEND and/or CONVERT operations in order to facilitate tracking of abusive clients. Also server implementors SHOULD isolate the conversion function or library from the privileged mailstore, perhaps by running it within a distinct process.
クライアントは、サーバーを攻撃するためにCONVERTコマンドに続いてAPPENDコマンドを使用して、巧妙に作成された不正なメッセージを作成することができます。サーバーの変換機能やライブラリが（例えばバッファオーバーフローに対する脆弱性など）のセキュリティ上の問題がある場合、これは、特権の昇格やサービス拒否につながる可能性があります。このような攻撃を軽減するために、サーバは、APPENDにクライアント認証IDをログに記録する、および/または不正なクライアントの追跡を容易にするために、操作を変換します。また、サーバの実装は、おそらく別個のプロセス内でそれを実行することによって、特権メールストアから変換関数やライブラリを分離すべきです。
Deployments in which the actual transcoding is done outside the IMAP server in a separate server are recommended to keep the servers in the same trusted domain (e.g., subnet).
実際のトランスコーディングは、別のサーバーにIMAPサーバ外で行われている展開は、同じ信頼されたドメイン（例えば、サブネット）内のサーバーを維持することが推奨されます。
Stephane H. Maes and Ray Cromwell from Oracle edited several earlier versions of this document. Their contribution is gratefully acknowledged.
ステファンH.マースとOracleからのレイ・クロムウェルは、このドキュメントのいくつかの以前のバージョンを編集しました。彼らの貢献は深く感謝しています。
The authors want to specifically acknowledge the excellent criticism and comments received from Randall Gellens (Qualcomm), Arnt Gulbrandsen (Oryx), Zoltan Ordogh (Nokia), Ben Last (Emccsoft), Dan Karp (Zimbra), Pete Resnick (Qualcomm), Chris Newman (Sun), Ted Hardie (Qualcomm), Larry Masinter (Adobe), Philip Guenther (Sendmail), Greg Vaudreuil (Alcatel-Lucent), David Harrington (Comcast), Dave Cridland (Isode), Pasi Eronen (Nokia), Magnus Westerlund (Ericsson), and Jari Arkko (Ericsson), which improved the quality of this specification considerably.
著者は、具体的ランドールGellens（クアルコム）、ARNT Gulbrandsenの（オリックス）、ゾルタンOrdogh（ノキア）、ベン・ラスト（Emccsoft）、ダン・カープ（Zimbraの）、ピート・レズニック（クアルコム）、クリスから受信した優れた批判やコメントを確認したいですニューマン（日）、テッドハーディー（クアルコム）、ラリーMasinter（アドビシステムズ社）、フィリップ・ギュンター（Sendmailの）、グレッグボードルイ（アルカテル・ルーセント）、デヴィッド・ハリントン（コムキャスト）、デイヴ・Cridland（ISODE）、パシEronen（ノキア）、マグナスウェスター（エリクソン）、かなり本明細書の品質を向上させるヤリArkko（エリクソン）。
The authors would also like to specially thank Dave Cridland for the MEDIACAPS command proposal and Dan Karp for the CONVERSIONS command proposal.
著者らはまた、特別な提案をコマンド変換にMEDIACAPSコマンドの提案のためのデイブCridlandとダン・カープに感謝したいと思います。
The authors also want to thank all who have contributed key insight and extensively reviewed and discussed the concepts of CONVERT and its predecessor P-IMAP. In particular, this includes the authors of the LCONVERT document: Rafiul Ahad (Oracle Corporation), Eugene Chiu (Oracle Corporation), Ray Cromwell (Oracle Corporation), Jia-der Day (Oracle Corporation), Vi Ha (Oracle Corporation), Wook-Hyun Jeong (Samsung Electronics Co. LTF), Chang Kuang (Oracle Corporation), Rodrigo Lima (Oracle Corporation), Stephane H. Maes (Oracle Corporation), Gustaf Rosell (Sony Ericsson), Jean Sini (Symbol Technologies), Sung-Mu Son (LG Electronics), Fan Xiaohui (China Mobile Communications Corporation (CMCC)), and Zhao Lijun (China Mobile Communications Corporation (CMCC)).
著者らはまた、主要な洞察力を貢献し、広く概説およびCONVERTの概念とその前身P-IMAPを議論してきたすべての人に感謝したいと思います。 Rafiul Ahad（オラクル・コーポレーション）、ユージン・チウ（オラクル・コーポレーション）、レイ・クロムウェル（オラクル・コーポレーション）、嘉-DER日（オラクル・コーポレーション）、Viのハ（オラクル・コーポレーション）、ジェウク：特に、これはLCONVERT文書の作成者を含み-Hyunチョン（サムスン電子LTF）、チャンクァン（オラクル・コーポレーション）、ロドリゴ・リマ（オラクル・コーポレーション）、ステファン・H.マース（オラクル・コーポレーション）、グスタフRosell（ソニー・エリクソン）、ジーン・シーニ（シンボル・テクノロジーズ）、Sung-ムー息子（LG電子）、ファンXiaohui（チャイナモバイルコミュニケーションズ株式会社（CMCC））、および趙Lijun（チャイナモバイルコミュニケーションズ株式会社（CMCC））。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[CHARSET-REG] Hoffman, P., "Registration of Charset and Languages Media Features Tags", RFC 2987, November 2000.
[CHARSET-REG]ホフマン、P.、 "文字セットと言語の登録メディアは、タグ機能"、RFC 2987、2000年11月に。
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[IMAPABNF]メルニコフ、A.およびC. Dabooは、RFC 4466、2006年4月 "IMAP4 ABNFへの拡張を集めました"。
[MEDIAFEAT-REG] Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag Registration Procedure", BCP 31, RFC 2506, March 1999.
[MEDIAFEAT-REG] Holtman、K.、MUTZ、A.、およびT.ハーディ、 "メディア特徴タグの登録手順"、BCP 31、RFC 2506、1999年3月。
[MIME-MTSRP] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[MIME-MTSRP]フリード、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]ムーア、K.、 "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、1996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997.
[RFC2231]解放され、N.とK.ムーア、 "MIMEパラメータ値およびエンコードされたWordの機能拡張：文字セット、言語、および継続の"、RFC 2231、1997年11月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、2003年3月。
[RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003.
[RFC3516] Nerenberg、L.、 "IMAP4バイナリコンテンツ拡張"、RFC 3516、2003年4月。
[DISP-FEATURES] Masinter, L., Wing, D., Mutz, A., and K. Holtman, "Media Features for Display, Print, and Fax", RFC 2534, March 1999.
[DISP-FEATURES] Masinter、L.、ウイング、D.、MUTZ、A.、およびK. Holtman、 "表示、印刷用メディアの機能、およびファックス"、RFC 2534、1999年3月。
[IMAP-I18N] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, June 2008.
[IMAP-I18N]ニューマン、C.、Gulbrandsenの、A.、およびA.メルニコフ、 "インターネットメッセージアクセスプロトコル国際化"、RFC 5255、2008年6月。
[LEM-STREAMING] Cook, N., "Streaming Internet Messaging Attachments", Work in Progress, June 2008.
[LEM-ストリーミング]クック、N.、 "ストリーミングインターネットメッセージング添付ファイル"、進歩、2008年6月の作業。
[OMA-ME-RD] OMA, "Open Mobile Alliance Mobile Email Requirement Document", OMA 55.919 3.0.0, December 2007.
[OMA-ME-RD] OMA、 "オープン・モバイル・アライアンスモバイルメール要件文書"、OMA 55.919 3.0.0、2007年12月。
[OMA-STI] OMA, "Open Mobile Alliance, Standard Transcoding Interface Specification", OMA OMA-STI-V1_0, December 2005.
[OMA-STI] OMA、 "オープン・モバイル・アライアンス、標準トランスコーディング・インタフェース仕様"、OMA OMA-STI-V1_0、2005年12月。
Authors' Addresses
著者のアドレス
Alexey Melnikov (editor) Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK
アレクセイ・メルニコフ（エディタ）ISODE株式会社5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国
EMail: Alexey.Melnikov@isode.com
メールアドレス：Alexey.Melnikov@isode.com
Peter Coates (editor) Sun Microsystems 185 Falcon Drive Whitehorse, YT Y1A 6T2 Canada
ピーター・コーツ（編集者）Sun Microsystemsの185ファルコンドライブホワイトホース、YT Y1A 6T2カナダ
EMail: peter.coates@Sun.COM
メールアドレス：peter.coates@Sun.COM
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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, THE IETF TRUST 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が表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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に情報を記述してください。