[要約] RFC 5259は、IMAPプロトコルの拡張であるCONVERT拡張についての仕様を提供しています。この拡張の目的は、メールメッセージの変換や変更をサポートし、クライアントとサーバ間での柔軟なメッセージ処理を可能にすることです。
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をサポートするサーバーは、モバイルデバイスで表示される（たとえば）他の形式に体の部分を変換できます。クライアントは、特定の変換を明示的に要求するか、利用可能な最良の変換を選択するようサーバーに依頼することができます。クライアントが許可する場合、サーバーは、独自の戦略に基づいて変換する方法を決定します（例えば、以下で説明したようにクライアントの知識に基づいて）。サーバーがデバイスの特性（変換の範囲外）を知っている場合、またはそれらを決定できる場合（たとえば、デバイスタイプを含む変換パラメーターを使用）、変換されたボディ部分もデバイスの機能（例えば、フォームファクター）に最適化できます。写真の）。クライアントは、オプションの変換（このドキュメントの「トランスコーディング」とも呼ばれる）パラメーターを使用してコンバージョンを制御できます。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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].
ストリーミング中のアタッチメントの変換は、変換拡張機能の範囲外であり、別のレモネード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.)
コンバート拡張機能をサポートするサーバーは、機能応答または応答コードで「コンバート」と「バイナリ」を返す必要があります。（クライアントとサーバーの著者は、機能の応答または応答コードで返されるトークンの順序が任意であることを思い出します。）
Example: A server that implements CONVERT.
例：変換を実装するサーバー。
C: a000 CAPABILITY
S: * CAPABILITY IMAP4rev1 CONVERT BINARY [...]
S: a000 OK CAPABILITY completed
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.
注：元のデータが変更されていないという要件により、そのようなデータが他のクライアントがアクセスできるようにし、元のドキュメントの返信またはフォワードを許可し、署名の検証を許可します（変換された身体部分には署名が含まれない可能性があります）、およびボディ構造と関連する関連を保持する情報。
Arguments: source MIME type target MIME type
引数：ソースMIMEタイプのターゲットMIMEタイプ
Responses: untagged responses: CONVERSION Result: OK - CONVERSIONS command completed BAD - unrecognized syntax of an argument, unexpected extra argument, missing argument, etc.
応答：拡大していない応答：変換結果：OK-変換コマンドが完了しました。
The CONVERSIONS command is allowed in Authenticated and Selected IMAP states.
コンバージョンコマンドは、認証された選択された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.
コンバージョンコマンドへの最初のパラメーターはソースMIMEタイプ、2番目のパラメーターはターゲットMIMEタイプです。両方のパラメーターは、部分的に（例： "text/*"）または完全に（ "*"）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.
ソース/ターゲットペアとそれに関連する変換パラメーターを一致させる変換は、じゅうたんの変換応答で返されます。ソース/ターゲットがサーバーによってサポートされている変換と一致しない場合、変換応答は返されません。
Examples:
例：
For conversion information from GIF to JPEG image format (no untagged CONVERSION response would be returned if no conversion is possible):
GIFからJPEGイメージ形式への変換情報の場合（変換が不可能な場合、攻撃のない変換応答は返されません）：
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.
コンバージョンコマンドを実行した結果、サーバーは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-コンバージョン完了してください - 変換エラー：そのデータが悪いデータを取得および/または変換することはできません - 引数の認識されていない構文、予期しない追加の引数、引数の欠落など。
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 Extensionは、MIMEパーツのメディアタイプを別のメディアタイプにトランスコードするために使用されるConvertおよびUID Convertコマンドを定義します。これらのコマンドは構造化されており、[RFC3516]によって拡張されたFetch/UID 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.
o 成功したconvert/uid convertコマンドは、1つまたは複数の攻撃されていない変換された応答（メッセージごとに1つ）になります。それらは、攻撃されていないフェッチの応答に似ています。単一のConvert/ UID Convertコマンドは、変換パラメーターで定義された単一のタイプの変換のみを実行できることに注意してください。複数の異なる変換を実行する必要があるクライアントは、複数のConvert/UID Convertコマンドを発行する必要があります。そのようなクライアントはそれらをパイプラインする場合があります。
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 バイナリ[...]データアイテムは、変換パラメーターに従ってボディパーツまたはメッセージ全体の変換を要求し、変換されたメッセージ/ボディパーツをバイナリとして返すように要求します。
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データ項目は、ボディストラクチャフェッチデータ項目に似ていますが、変換されたボディ部分の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 ボディ[...ヘッダー]要求されたヘッダー内のエンコードされた単語は、指定されたチャーセットに変換されます。この変換には、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 ボディ[... mime]要求されたヘッダー内のエンコードされた単語は、指定されたcharsetに変換されます。この変換には、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 baverableConversionsデータアイテムは、指定されたボディパーツ（またはメッセージ全体）を変換できるターゲットMIMEタイプのリストを要求します。
The CONVERT extension also adds one new response code. See Section 9 for more details.
Convert Extensionは、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タイプへの変換をサポートするサーバーの実装は、デフォルトの変換を構成可能にする必要があります。クライアントは、サーバーが正しく推測するという保証がないため、機能（インバンドまたはアウトバンド）を提供して機能を提供しない限り、デフォルトの変換を使用しないようにしないでください。クライアントの実装者は、デフォルトの変換ではなく、bavealeconversionsの使用データ項目または変換コマンドを使用することを検討する必要があります。
CONVERT's command syntax is modeled after the FETCH command syntax in [RFC3501], as extended by [RFC3516]. CONVERT data items are generally structured as:
Convertのコマンド構文は、[RFC3516]で拡張されたように、[RFC3501]のFetchコマンド構文の後にモデル化されます。データ項目は通常、次のように構成されています。
BINARY[section-part]<partial>
バイナリ[セクションパート] <Partial>
BINARY.SIZE[section-part]
binary.size [セクションパート]
BODYPARTSTRUCTURE[section-part]
ボディパートストラクチャ[セクションパート]
BODY[HEADER]
ボディ[ヘッダー]
BODY[section-part.HEADER]
body [section-part.header]
BODY[section-part.MIME]
body [section-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.
部分的な変換バイナリ[...]コマンドのセマンティクスは、部分的なフェッチ本体[...]コマンドの場合と同じです。
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コマンドは変換されたメッセージに\ Seedフラグを設定しないことに注意してください。\ Seedフラグでメッセージをマークしたいクライアントは、それを行うためにストアコマンド（おそらく変換リクエストでパイプライン化された）を発行する必要があります。
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 convertコマンドは、uid fetchコマンドがfetchコマンドとは異なるのと同じ方法で、convertコマンドとは異なります。
o UID CONVERT takes as a parameter a sequence of UIDs instead of a sequence of message numbers.
o UIDコンバートは、メッセージ番号のシーケンスの代わりに、パラメーターとして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.
o convertコマンドに応答している間は、抹消の応答を送信しないでください。このルールは、クライアントとサーバー間のメッセージシーケンス番号の同期の損失を防ぐために必要です。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
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).
例：クライアントは、テキスト/HTMLボディの部分をテキスト/プレーンに変換することを要求し、US-ASCIIのcharSetを要求します。サーバーは、テキスト/HTMLボディパーツに非US-ASCII文字がないため、charsetコンバージョン要求を尊重できないため、変換されたデータの代わりにエラー句を返すことで要求に失敗します（セクション9を参照）。
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
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
The server replaced non-us-ascii characters with a us-ascii character such as "?".
サーバーは、非US-ASCII文字を「？」などのUS-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
Later on, the client requests 1000 bytes from the converted body part, starting from byte 2001:
その後、クライアントは、2001年のBYTEから始まる変換されたボディ部分から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
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.
たとえば、マルチパート/*のPDFドキュメントへの変換をリクエストするために、クライアントが非葉のボディ部分の変換を要求することは合法です。ただし、この拡張機能を実装するサーバーは、そのような変換をサポートするために必要ではありません。このような変換をサポートするサーバーは、「変換」MultiPart/*""*"'コマンドに応じて1つ以上の変換応答を返す必要があります。詳細については、セクション5.1を参照してください。
The client can request header conversions using the BODY[...HEADER] CONVERT request, for example
クライアントは、ボディ[...ヘッダー]コンバートリクエストを使用してヘッダー変換を要求できます。たとえば
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. (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
このようなリクエストには、charsetパラメーターを含める必要があります。リクエストを受け取ると、サーバーはヘッダーのエンコードされた単語（[RFC2047]に記載されている）をデコードし、指定されたチャーセットで再エンコードされたものを返す必要があります。（結果が完全にus-asciiで表現できる場合、エンコードされたワードは必要ない場合があるため、サーバーは結果のエンコードされたワードを純粋なUS-ascii表現に置き換えることができます。）サーバーが特定のものをデコードできない場合たとえば、エンコードされた単語は、charsetまたはencodingが認識されていない場合、そのままにしておく必要があります。サーバーは、[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未満に保つために必要に応じて変換、エミット、および再編成する必要があります。これは、変換中に保存する必要がありますが、クライアントはコメントが完全に削除される状況を優雅に処理する必要があります。コメントが保存されている場合、パラメーターの後に移動する場合があります。たとえば（前の例を継続）：
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タイプは、ボディ[ヘッダー]、ボディ[セクション.header]、またはボディ[セクション.mime]で指定する必要はありません。つまり、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 Requentで指定する方法を示しています。
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を実装するサーバーは、テキスト/プレーンMIMEタイプのCharSetコンバージョンをサポートする必要があり、ISO-8859-1、ISO-8859-2、ISO-8859-3、ISO-8859-4、ISO-8859-からのcharsetコンバージョンをサポートする必要があります。5、ISO-8859-6、ISO-8859-7、ISO-8859-8、およびISO-8859-15からUTF-8。
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.
サーバーは、「テキスト/プレーン」を「テキスト/プレーン」MIMEタイプからの許可された宛先変換としてリストする必要があります（セクション5.1を参照）。コマンド「コンバージョン」テキスト/プレーン」「テキスト/プレーン」も、「charset」と「未知のキャラクター再配置」（セクション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 Extensionを実装するIMAPサーバーは、テキスト/プレーン、テキスト/HTML、テキスト/CSS、テキスト/CSV、テキスト/濃縮、およびテキスト/XML MIMEタイプの「charset」[charset-reg]パラメーターの認識をサポートする必要があります。注意してください。上記の必須の変換を除き、上記のテキストMIMEサブタイプからの変換をサポートするためにサーバーの実装は必要ありません。つまり、サーバーの実装は、テキスト/ CSVからの変換をサポートする場合にのみ、テキスト/ CSVの「charset」パラメーターをサポートする必要があります。
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への変換をサポートする必要があります。エンコードされた単語がサポートされている充電器の1つにある限り。
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).
サーバーがすべての文字（つまり、ソース文字をターゲットcharsetで表現することはできない）を保持している間にチャーセット変換を実行できず、「不明な文字再装置」変換パラメーターが指定されていない場合、サーバーはサーバーが必要です変換に失敗すると、UntaggedエラーBadParameters応答を返す必要があります（セクション9を参照）。「不明な文字置換」変換自体で指定された値をターゲットcharSetで表すことができない場合、サーバーは変換に失敗する必要があり、未積ばられたエラー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:
モバイル環境での変換の予想される使用に基づいて、サーバーの実装者は次の変換のサポートを検討する必要があります。
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の変換は、ドキュメント構造と表を最小限に維持する方法でテキスト/プレーンにドキュメント/プレーンに変換します。
o Image conversions among the types image/gif, image/jpeg, and image/png for at least the following parameters:
o 少なくとも次のパラメーターのタイプ画像/GIF、画像/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.
変換された応答は、セクション6で指定された成功、部分的に成功した、または失敗した変換またはUID変換コマンドの結果として送信される場合があります。
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.
変換された応答は、メッセージ番号から始まり、その後に「変換された」ラベルが続きます。ラベルの後に、応答が返される原因となったコマンドのタグが含まれるコンバート相関器が続きます。これは、クライアントが使用して、対応するConvert/UID Convertコマンドに対して変換された応答を一致させることができます。
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.
コンバート相関器の後に、1つ以上のコンバートリターンデータ項目のリストが続きます。UIDデータ項目が返される場合、変換された応答の最初のデータ項目として返す必要があります。この要件は、クライアントの実装を簡素化することです。詳細については、セクション10およびセクション8の残りを参照してください。
BODYPARTSTRUCTURE[section-part]
ボディパートストラクチャ[セクションパート]
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 Extensionは、ボディパートストラクチャコンバートデータ項目を定義します。ボディパートストラクチャリターンデータ項目に含まれるデータは、[RFC3501]ボディ構造データ項目で指定された正確な構文に従いますが、変換された部分の情報のみが含まれています。ボディパート構造に含まれるすべての情報は、変換されたMIMEタイプ、サブタイプ、サイズ、炭化など、変換された後の部分の状態に関係しています。クライアントは、返された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.
返されたボディパート構造データは、同じIMAP「セッション」でまったく同じ変換で返されたバイナリデータと一致する必要があります。この要件により、クライアントは同じIMAPセッションで個別のコマンドでボディパート構造とバイナリデータを要求できます。
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.
クライアントが同じセクションパートのバイナリデータ項目の前にセクションパートのボディパートストラクチャデータ項目をリストする場合、変換された応答で、サーバーは対応するバイナリデータの前にボディパート構造データを返す必要があります。また、UIDデータ項目が存在する場合、すべてのボディ構造データ項目は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
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.
このアイテムは、セクションの変換されたサイズ（つまり、対応する変換バイナリリクエストへの応答で予想されるサイズ）を要求します。返された値は正確でなければならず、メッセージが別のセッションで削除されない限り、IMAPの「セッション」の期間中に変更してはなりません（以下を参照）。これにより、クライアントは変換された部品をチャンクにダウンロードできます（「<partial>」を使用）。この要件は、ほとんどの場合、サーバーがそのサイズを返す前に、要求されたボディ部分の変換を実行する必要があることを意味します。
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.
別のセッションでメッセージが削除された場合、サーバーは同じセッションの後半でバイナリ.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接続である接続で取得したサイズを使用してはなりません。
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サーバーでの以前の経験は、これが相互運用性の問題を引き起こしたことを示しています。サーバーが実際のサイズよりも小さい値を返すと、<partial>ダウンロードが使用されるとデータの切り捨てが生じます。サーバーが実際のサイズよりも大きい値を返す場合、これにより、クライアントがボディパーツをダウンロードするのに十分なストレージがないと信じるようにクライアントを誤解させる可能性があります。
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.
クライアントの実装者への注意：クライアントの著者は、これが一部のサーバーの実装にとって高価な操作である可能性があることに注意してください。多数の変換されたボディ部分または同じボディパーツの複数の変換のためにバイナリ.sizeを要求すると、パフォーマンスが遅くなり、サーバーの負荷が過剰になり、落胆する可能性があります。クライアントの実装者は、この要求を最も必要なケースのみに制限する実装アプローチを考慮し、複数のサーバー実装でbinary.izeのパフォーマンスへの影響をテストすることを奨励する必要があります。
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.
baverableConversions [セクションパート]により、クライアントは、メッセージの指定されたボディ部分またはメッセージ全体を変換できるターゲット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コマンドまたはエラーフレーズで要求されているターゲット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タイプの候補者のみがあり、変換パラメーターのリストのために破棄された場合、サーバーはターゲット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タイプがAvaveLeConversionsに応じて返される場合、対応するバイナリ/バイナリ.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
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を指定する変換リクエスト。リクエストがあまりにも多くのメッセージをリストしているためにサーバーが変換を拒否した場合、サーバーはmaxConvertMessages応答コードを返す必要があります（セクション9を参照）。例えば：
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:
リクエストがボディの部分が多すぎるためにサーバーが変換を拒否した場合、サーバーはMaxConvertParts応答コードを返す必要があります（セクション9を参照）。例えば：
C: h001 CONVERT 1 ("text/plain" ("charset" "us-ascii")) (BINARY[1] BINARY[2])
C：H001変換1（ "Text/Plain"（ "charset" "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メディアタイプは、サーバーから悪いタグ付き応答を生成するはずです。認識されていないMIMEメディアタイプは、タグ付けされていない応答を生成します。
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.
一部のトランスコーディングにはパラメーターが必要になる場合があります。パラメーターが必要な形式のパラメーターがないトランスコーディング要求がパラメーターを必要とする場合、サーバーは要求されたデータ項目に関連付けられたデータの代わりにエラーMissionParametersフレーズを返します。これは、フェッチの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応答を返す必要があります（以下を参照）、またはエラー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.
たとえば、永続的なエラーのために要求された変換を実行できない場合、たとえば、独自のドキュメント形式に既存のトランスコーディング実装がない場合、サーバーはエラーバッドパラメーターまたはエラーMissionParametersフレーズを含む変換された応答を返す必要があります。
The server MAY choose to return one ERROR phrase for a single conversion if several related data items are requested. For instance:
サーバーは、いくつかの関連データ項目が要求された場合、1つの変換のために1つのエラーフレーズを返すことを選択できます。例えば：
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
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:
少なくとも1つの変換が成功した場合、サーバーは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
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.
一般に、クライアントは、その要求が正確に尊重されたかどうかをボディパートストラクチャの応答から知ることができますが、理由を知らないかもしれません。
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 <number> -サーバーは、任意のConvert/uid Convert requestで<number>以上のメッセージをコンバージョンすることができません。
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 <number> -サーバーは、任意のConvert/uid Convertリクエストで、メッセージの<number> body parts以上を一度に変換することができないか、変換することができません。
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:
単語のエラーの後には、常に非公式の人間が読める説明的なテキストが続き、その後に変換エラーコードが続きます。Convert-Error-Codeは次のいずれかでなければなりません。
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 MM-トランスコーディング要求は一時的に失敗しました。後で成功する可能性があるため、クライアントは再試行する可能性があります。クライアントは、再試行する前に少なくともmm分待つ必要があります。
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タイプのto-mime-type "（" transcoding-params "）"からのバッドパラメーター - リストされたパラメーターは理解されておらず、ソース/宛先MIMEタイプのペアに対して有効ではなく、無効な値があるか、名誉を与えられませんでしたエラーラベルの後に指定された人間の読み取り可能なテキストに記載されている別の理由。トランスコーディングパラムは省略できます。その場合、それは、コンクリートから型の型からto-mimeタイプへの変換が不可能であることを意味します。From Concrete-Mime-Typeがゼロの場合、これは指定された身体部分が存在しないことを意味します。すべての認識されていないまたは無関係なパラメーターは、トランスコーディングパラムにリストする必要があります。無関係なパラメーターを無視することは法的行動ではありません。
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.
クライアントが「デフォルト変換」を要求した場合（セクション6を参照）、To-Mimeタイプにはサーバーが選択した宛先MIMEタイプが含まれていることに注意してください。
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.
Concrete-Mimeタイプのto-mime-type "（" transcoding-Params "）"からのMissingParameters - 指定されたソースMIMEタイプを宛先MIMEタイプに変換するには、リストされたパラメーターが必要ですが、リクエストでは見られませんでした。クライアントが「デフォルト変換」を要求した場合（セクション6を参照）、To-Mimeタイプにはサーバーが選択した宛先MIMEタイプが含まれていることに注意してください。
Examples:
例：
C: b002 CONVERT 2 ("APPLICATION/PDF") BINARY[3]
S: b002 NO [TEMPFAIL] All conversions failed
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: 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
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]で使用される拡張されたBackus-Naurフォーム（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
command-select =/ convert
uid =/ "UID" SP convert
; Unique identifiers used instead of message
; sequence numbers
convert = "CONVERT" SP sequence-set SP convert-params SP ( convert-att / "(" convert-att *(SP convert-att) ")" )
convert = "convert" sp secence-set sp convert-params sp（convert-att / "（" convert-att *（sp convert-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
convert-att = "uid" / "body-partStructure" section contervert / "binary" section contervert [partial] / "binary.size" section contervert / "body [header]" / "body [" section-part "。ヘッダー] " /" body ["section-part" .mime] " /" availableConversions "セクションconvert
; <partial> is defined in [RFC3516]. ; <section-part> is defined in [RFC3501].
;<partial>は[RFC3516]で定義されています。;<セクションパート>は[RFC3501]で定義されています。
convert-params = "(" (quoted-to-mime-type / default-conversion)
[SP "(" transcoding-params ")"] ")"
quoted-to-mime-type = DQUOTE to-mime-type DQUOTE
transcoding-params = transcoding-param *(SP transcoding-param)
transcoding-Params = transcoding-Param *（SP Transcoding-Param）
transcoding-param-names = transcoding-param-name *(SP transcoding-param-name)
transcoding-param-names = transcoding-param-name *（sp transcoding-param-name）
transcoding-param = transcoding-param-name SP transcoding-param-value
Transcoding-Param = transcoding-Param-Name SP Transcoding-Param-Value
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.
transcod-param-name-nq = Feature-tag ; <Feature-tag> is defined in [MEDIAFEAT-REG].
transcod-param-name-nq = feature-tag;<feature-tag>は[MediaFeat-Reg]で定義されています。
transcoding-param-value = astring
default-conversion = "NIL"
message-data =/ nz-number SP "CONVERTED" SP convert-correlator
SP convert-msg-attrs
convert-correlator = "(" "TAG" SP tag-string ")"
convert-correlator = "（" "tag" sp tag-string "）"
tag-string = string
; tag of the command that caused
; the CONVERTED response, sent as
; a string.
convert-msg-attrs = "(" convert-msg-att *(SP convert-msg-att) ")" ; "UID" MUST be the first data item, if present.
convert-msg-attrs = "（" convert-msg-att *（sp convert-msg-att） "）";「UID」は、存在する場合は最初のデータ項目でなければなりません。
convert-msg-att = msg-att-semistat / msg-att-conv-static
msg-att-conv-static = "UID" SP uniqueid ; MUST NOT change for a message
msg-att-conv-static = "uid" sp uniquid;メッセージを変更してはなりません
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 =（ "binary" section contervert ["<" number ">"] sp（nstring / literal8 / converterror-phrase）） /（（ "binary.size" section convert sp（number / converterror-phrase） /（ "Body-PartStructure"セクションコンバートSP（Body / ConverterRor-Phrase）） /（（ "avavilableConversions"セクションコンバートSP（MIMETYPE-LIST / CONVERTERROR-PHRASE）））;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].
mimetype-and-params = quoted-to-mime-type [SP "(" transcoding-params ")"] ; always includes a specific MIME type
MimeType-and-Params = Quoted-to-mime-type [sp "（" transcoding-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>.
converterror-phrase = "(" "ERROR" SP convert-err-descript SP convert-error-code ")"
converterror-phrase = "（" "error" sp convert-desscript sp convert-error-code "）"
convert-error-code = "TEMPFAIL" [SP nz-number] / bad-params / missing-params
convert-error-code = "tempfail" [sp nz-number] / bad-params / missing-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.
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.
Quoted-from-mime-type = dquote from concrete-mime-mime-type dquote bad-params = "badparameters" 1*（sp（quoted-from-mime-type / nil）sp mimetype-and-params）;NILは、体の部分が存在しない場合にのみ返されます。
missing-params = "MISSINGPARAMETERS" 1*(SP quoted-from-mime-type SP mimetype-and-missing-params)
Missing-Params = "MissingParameters" 1*（sp quoted-from-mime-type sp mimetype-and-missing-params）
mimetype-and-missing-params = quoted-to-mime-type "(" transcoding-param-names ")" ; always includes a specific MIME type
MimeType-and-Missing-Params = Quoted-to-mime-type "（" transcoding-param-names "）";常に特定のMIMEタイプが含まれています
concrete-mime-type = type-name "/" subtype-name
; i.e., "type/subtype".
; type-name and subtype-name
; are defined in [MIME-MTSRP].
from-concrete-mime-type = concrete-mime-type
to-mime-type = concrete-mime-type
command-auth =/ conversions-cmd
command-auth =/ conventions-cmd
conversions-cmd = "CONVERSIONS" SP from-mime-type-req SP to-mime-type-req
Conversions-CMD = "Conversions" sp from-mime-type-req sp to-mime-type-req
from-mime-type-req = astring
; "mime-type-req" represented as IMAP <atom>,
; <quoted> or <literal>
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>.
any-mime-type = "*"
any-mime-type = "*"
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].
mime-type-req = any-mime-type /（type-name " /" any-mime-type） / concrete-mime-type;'*'、 'type/*'または 'type/subtype'。;タイプ名は[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) ")"]
Response-Payload =/ Conversion-Data Conversion-Data = "Conversion" SP QUOTED-MIME-TYPE SP QUOTED-TO-MIME-TYPE [SP "（" TransCoding-Param-Name *（SP Transcoding-Param-name）"）"]
The monitoring of CONVERT operation is similar to monitoring of the IMAP FETCH operation.
変換操作の監視は、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:
このドキュメントを書いている時点で、定義されている標準的なIMAP MIBはありません。同様に、操作を変換するための標準的な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を公開することにより登録されます。このドキュメントは、変換IMAP機能を定義します。IANAは、この拡張機能をIANA IMAP機能レジストリに追加しました。
IANA has performed registrations as defined in the following subsections.
IANAは、次のサブセクションで定義されているように登録を実行しました。
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>
Subject: Registration of media feature tag unknown-character-replacement
件名：メディア機能タグの不明 - 特徴の登録
Media feature tag name: unknown-character-replacement
メディア機能タグ名：不明-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、テキスト/濃縮、テキスト/XML MIMEタイプのチャーセット変換を実行できるサーバーを許可して、サポートされていない文字を置き換えます「？」などの固定された文字列を持つターゲットcharset。この機能タグは、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変換拡張[RFC5259]
Examples of typical use: C: b001 CONVERT 2 BINARY[3 ("text/plain" ("charset" "us-ascii" "unknown-character-replacement" "?"))]
典型的な使用の例：C：B001 2バイナリを変換[3（ "Text/Plain"（ "charset" "us-ascii" "unknown-character-replacement" "？"）]]]
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」メディアタイプパラメーター[charset-reg]もサポートするMIMEタイプについてのみ意味があります。
Name(s) & email address(es) of person(s) to contact for further
information:
Alexey Melnikov <alexey.melnikov@isode.com>
Intended usage: 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.
クライアントが署名されたボディパーツのサーバー側の変換（たとえば、MultiPart/Signed内部の部分）を要求する場合、クライアントが変換されたコンテンツが本物であることを確認する方法はありません。サーバーが署名されたボディパーツの変換を実行するようにサーバーを信頼していないクライアントは、署名されたオブジェクトをダウンロードし、署名を確認し、変換自体を実行できます。
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.
クライアントは、Appendコマンドを使用して慎重に作成された悪いメッセージを作成し、その後にサーバーを攻撃するためにConvertコマンドが続きます。サーバーの変換関数またはライブラリにセキュリティの問題がある場合（バッファオーバーフローに対する脆弱性など）、これにより特権のエスカレーションやサービスの拒否が生じる可能性があります。このような攻撃を緩和するには、サーバーは、虐待的なクライアントの追跡を容易にするために、操作の追加および/または変換するクライアント認証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.
OracleのStephane H. MaesとRay Cromwellは、このドキュメントのいくつかの以前のバージョンを編集しました。彼らの貢献は感謝されています。
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.
著者は、Randall Gellens（Qualcomm）、Arnt Gulbrandsen（Oryx）、Zoltan Ordogh（Nokia）、Ben Last（emccsoft）、Dan Karp（Zimbra）、Pete Resnick（Qualcomm）、Chrisの優れた批判とコメントを具体的に認めたいと考えています。ニューマン（サン）、テッド・ハーディ（Qualcomm）、Larry Masinter（Adobe）、Philip Guenther（Sendmail）、Greg Vaudreuil（Alcatel-Lucent）、David Harrington（Comcast）、Dave Cridland（Isode）、Pasi Eronen（Nokia）、MagnusWesterlund（Ericsson）、およびJari Arkko（Ericsson）は、この仕様の品質を大幅に向上させました。
The authors would also like to specially thank Dave Cridland for the MEDIACAPS command proposal and Dan Karp for the CONVERSIONS command proposal.
著者はまた、Mediacapsコマンド提案についてDave CridlandとConversions Command ProposalについてDan Karpに特別に感謝したいと思います。
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の概念を広範囲にレビューし、議論してくれたすべての人に感謝したいと考えています。特に、これには、lconvertドキュメントの著者が含まれます：Rafiul Ahad（Oracle Corporation）、Eugene Chiu（Oracle Corporation）、Ray Cromwell（Oracle Corporation）、Jia-Day 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（シンボルテクノロジー）、Sung-Mu Son（LG Electronics）、Fan Xiaohui（China Mobile Communications Corporation（CMCC））、およびZhao Lijun（China Mobile Communications Corporation（CMCC））。
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ABNF] Crocker、D.、ed。および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] Hoffman、P。、「Charset and Languages Media機能の登録タグ」、RFC 2987、2000年11月。
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[Imapabnf] Melnikov、A。and C. daboo、「拡張機能をIMAP4 ABNFに収集しました」、RFC 4466、2006年4月。
[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. Hardie、「メディア機能タグ登録手順」、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] Freed、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Freed、N。およびK. Moore、「MIMEパラメーター値とエンコードされた単語拡張：文字セット、言語、および継続」、RFC 2231、1997年11月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501] CRISPIN、M。、「インターネットメッセージアクセスプロトコル - バージョン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.、Wing、D.、Mutz、A。、およびK. Holtman、「ディスプレイ、印刷、FAXのメディア機能」、RFC 2534、1999年3月。
[IMAP-I18N] Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Message Access Protocol Internationalization", RFC 5255, June 2008.
[IMAP-I18N] Newman、C.、Gulbrandsen、A。、およびA. Melnikov、「インターネットメッセージアクセスプロトコル国際化」、RFC 5255、2008年6月。
[LEM-STREAMING] Cook, N., "Streaming Internet Messaging Attachments", Work in Progress, June 2008.
[Lem-Streaming] Cook、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
Alexey Melnikov（編集者）Isode Ltd 5 Castle Business Village 36 Station Road Hampton、Middlesex TW12 2BX UK
EMail: Alexey.Melnikov@isode.com
Peter Coates (editor) Sun Microsystems 185 Falcon Drive Whitehorse, YT Y1A 6T2 Canada
Peter Coates（編集者）Sun Microsystems 185 Falcon Drive Whitehorse、YT Y1A 6T2カナダ
EMail: peter.coates@Sun.COM
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。