Network Working Group A. Melnikov, Ed.
Request for Comments: 5259 Isode Ltd
Category: Standards Track P. Coates, Ed.
Sun Microsystems
July 2008
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
Internet消息访问协议-转换扩展
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
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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:”标签适用于多行，则这些行之间的换行符仅用于编辑清晰性，不属于实际协议交换的一部分。这五个字符[…]意味着某些东西被省略了。
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扩展的范围，在单独的Lemonade 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.
示例：实现转换的服务器。
C: a000 CAPABILITY
S: * CAPABILITY IMAP4rev1 CONVERT BINARY [...]
S: a000 OK CAPABILITY completed
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-CONVERSIONS命令完成错误-无法识别参数的语法、意外的额外参数、缺少参数等。
The CONVERSIONS command is allowed in Authenticated and Selected IMAP states.
在已验证和选定的IMAP状态下，允许使用CONVERSIONS命令。
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命令的第一个参数是源MIME类型，第二个参数是目标MIME类型。这两个参数都部分（例如，“text/*”）或完全（“*”）可通配符。
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
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
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
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/*"
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.
执行转换命令后，服务器可以返回一个或多个转换响应。每个转换响应都指定可以将哪个源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-convert completed NO-convert错误：无法获取和/或转换该数据错误-无法识别参数的语法、意外的额外参数、缺少参数等。
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 CONVERT命令，用于将MIME部件的媒体类型转换为其他媒体类型和/或具有不同编码参数的相同媒体类型。这些命令的结构和行为类似于[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命令将导致一个或多个未标记的已转换响应（每条消息一个）。它们类似于未标记的获取响应。请注意，单个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数据项类似于BODYSTRUCTURE FETCH数据项，但它返回转换的身体部位的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扩展还添加了一个新的响应代码。详见第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.
客户端可以使用特殊的标记NIL（也称为“默认转换”）来请求服务器选择合适的目标媒体类型，而不是指定客户端要转换为的确切目标MIME媒体类型。本文档没有描述服务器是如何做出这样的选择的；然而，本段描述了一些基本准则。如果服务器知道使用带内（如转换参数中指定的设备类型）或带外机制的设备的特性，则应将请求正文部分转换为设备可能支持的媒体类型，并成功显示/播放。除非被转换参数特别覆盖，否则服务器还可以删除超出设备能力的任何不必要细节（例如，缩放图像以刚好适合设备屏幕）。在没有任何带内或带外机制用于确定设备特性的情况下，服务器应将请求正文部分转换为该媒体类别中可用的最标准或广泛部署的媒体类型，例如，转换为文本/普通、图像/jpeg。在这种情况下，服务器应将质量损失降至最低。服务器需要支持“默认转换”请求。支持转换为多个目标MIME类型的服务器实现应使默认转换可配置。客户端应该避免使用默认转换，除非它们提供了一种向服务器发送功能信号的方式（带内或带外），因为无法保证服务器会正确猜测它们的功能。客户端实现者应该考虑使用AsvabliOnVoice转换数据项或转换命令，而不是默认转换。
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的命令语法按照[RFC3501]中的FETCH命令语法建模，并由[RFC3516]扩展。转换数据项的结构通常为：
BINARY[section-part]<partial>
二进制[部分]<partial>
BINARY.SIZE[section-part]
二进制.大小[部分]
BODYPARTSTRUCTURE[section-part]
车身零件结构[截面零件]
BODY[HEADER]
正文[标题]
BODY[section-part.HEADER]
正文[部分标题]
BODY[section-part.MIME]
正文[部分.MIME]
AVAILABLECONVERSIONS[section-part]
可用版本[章节部分]
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.
partial CONVERT BINARY[…]命令的语义与partial FETCH BODY[…]命令的语义相同，只是<partial>参数指的是转码和解码的节数据。
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命令从不在已转换的消息上设置\Seen标志。希望使用\Seen标志标记消息的客户机需要发出STORE命令（可能与CONVERT请求通过管道连接）来执行此操作。
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命令与CONVERT命令的不同之处与UID FETCH命令与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.
o 响应CONVERT命令时，不得发送EXPUNGE响应。此规则对于防止客户端和服务器之间的消息序列号同步丢失是必需的。请注意，在UID CONVERT命令期间可能会发送EXPUNGE响应。
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 ("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).
示例：客户机请求将text/html主体部分转换为text/plain，并请求us ascii字符集。服务器无法尊重字符集转换请求，因为文本/html正文部分中存在非us ascii字符，因此它通过返回错误短语来代替转换的数据，从而使请求失败（请参阅第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
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
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 "?".
服务器将非美国ascii字符替换为美国ascii字符，如“？”。
Example: The client first requests the converted size of a text/html body part converted to text/plain:
示例：客户端首先请求转换为text/plain的text/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 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开始，从转换的身体部位请求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 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.
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
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
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
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.
不能使用BODY[HEADER]、BODY[section.HEADER]或BODY[section.MIME]指定目标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参数在转换请求中指定目标图片尺寸。
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
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.
实现转换的服务器必须支持文本/纯MIME类型的字符集转换，并且必须支持从iso-8859-1、iso-8859-2、iso-8859-3、iso-8859-4、iso-8859-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.
服务器必须将“text/plain”列为允许从“text/plain”MIME类型转换的目标（见第5.1节）。命令“CONVERSIONS”text/plain“text/plain”还必须返回“charset”和“unknown character replacement”（参见第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.
实现转换扩展的IMAP服务器必须支持识别text/plain、text/html、text/css、text/csv、text/experiment和text/xml MIME类型的“charset”[charset-REG]参数。请注意，服务器实现不需要支持上述文本MIME子类型的任何转换，但必须实现上述转换的情况除外。也就是说，服务器实现必须支持text/csv的“charset”参数，前提是它支持从text/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).
如果服务器无法在保留所有字符（即，源字符不能在目标字符集中表示）的同时执行字符集转换，并且未指定“未知字符替换”转换参数，则服务器必须使转换失败，并且必须返回Untaged ERROR BADPARAMETERS响应（参见第9节）。如果“未知字符替换”转换本身中指定的值不能在目标字符集中表示，则服务器也必须使转换失败，并且必须返回未标记的错误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 至少针对以下参数在Image/gif、Image/jpeg和Image/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节中指定的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.
转换后的响应以消息编号开始，后跟“已转换”标签。标签后面是convert correlator，它包含导致返回响应的命令的标记。客户机可以使用它将转换后的响应与相应的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.
convert correlator后面是一个或多个convert return数据项的列表。如果返回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扩展定义BODYPARTSTRUCTURE转换数据项。BODYPARTSTRUCTURE返回数据项中包含的数据遵循[RFC3501]BODYSTRUCTURE数据项中指定的确切语法，但仅包含转换零件的信息。BODYPARTSTRUCTURE中包含的所有信息都与转换后的部件状态有关，例如转换的MIME类型、子类型、大小或字符集。请注意，客户端可以期望返回的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.
返回的BODYPARTSTRUCTURE数据必须与在同一IMAP“会话”中为完全相同的转换返回的二进制数据匹配。此要求允许客户端在同一IMAP会话中以单独的命令请求BODYPARTSTRUCTURE和二进制数据。
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
如果客户端在同一截面零件的二进制数据项之前列出截面零件的BODYPARTSTRUCTURE数据项，则在转换的响应中，服务器必须在相应二进制数据之前返回BODYPARTSTRUCTURE数据。此外，任何车身结构数据
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
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]
二进制.大小[部分]
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.
如果消息在另一个会话中被删除，则服务器可能会在同一会话中稍后返回值0以响应BINARY.SIZE请求项。
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>
历史注释：以前使用IMAP服务器返回估计的RFC822.SIZE值的经验表明，这导致了互操作性问题。如果服务器返回的值小于实际大小，则如果<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.
使用下载。如果服务器返回的值大于实际大小，这可能会误导客户机认为它没有足够的存储空间来下载身体部位。
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进行大量转换的身体部位或同一身体部位的多次转换可能会导致性能降低和/或服务器负载过大，因此不鼓励这样做。客户端实现者应该考虑将此请求限制在最必要的情况下的实现方法，并鼓励使用多个服务器实现测试二进制大小的性能影响。
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.
AvailableVersions[section part]允许客户端请求目标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类型列表时必须考虑这些参数。例如，如果一个或多个转换参数不适用于潜在的目标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类型以响应AvailableVersions，则无法保证相应的BINARY/BINARY.SIZE/BODYPARTSTRUCTURE转换请求不会失败。
Example:
C: f001 CONVERT 2 (NIL) (AVAILABLECONVERSIONS[2])
S: * 2 CONVERTED (TAG "f001") (AVAILABLECONVERSIONS[2]
(("IMAGE/JPEG" "application/PostScript"))
S: f001 OK CONVERT COMPLETED
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]
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（“文本/普通”（“字符集”“us ascii”）（二进制[1]二进制[2]）
S: g001 NO [MAXCONVERTPARTS 1] You can only request 1 body part at any given time
S:g001否[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.
某些转码可能需要参数。如果为需要参数的格式发送不带参数的代码转换请求，服务器将返回一个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.
如果由于资源暂时不可用（例如，磁盘空间不足、临时内部错误、代码转换服务关闭），服务器无法执行请求的转换，则服务器必须返回一个标记的NO响应，该响应应包含TEMPFAIL响应代码（见下文）或错误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.
如果由于永久性错误而无法执行请求的转换，例如，如果专有文档格式没有现有的转码实现，则服务器必须返回包含错误BADPARAMETERS或错误MISSINGPARAMETERS短语的转换响应。
The server MAY choose to return one ERROR phrase for a single conversion if several related data items are requested. For instance:
如果请求多个相关数据项，服务器可能会选择为单个转换返回一个错误短语。例如：
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" ("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:
如果至少有一个转换成功，服务器必须返回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" ("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.
通常，客户机可以从BODYPARTSTRUCTURE响应中判断其请求是否得到了准确的响应，但可能不知道原因。
This document defines the following response codes that can be returned in the tagged NO response code.
本文档定义了以下可在标记的无响应代码中返回的响应代码。
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请求中转换超过<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>正文部分。
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:
“错误”一词后面总是紧跟着一个非正式的人类可读的描述性文本，该文本后面紧跟着转换错误代码。转换错误代码必须是以下代码之一：
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.
BADPARAMETERS从具体mime类型到mime类型“（“transcoding params”）”—列出的参数未被理解、对源/目标mime类型对无效、值无效或由于错误标签后指定的人类可读文本中指出的其他原因而无法使用。可以省略转码参数，在这种情况下，这意味着无法从具体mime类型转换为to mime类型。如果from-concrete mime类型为NIL，则表示指定的主体部分不存在。转码参数中必须列出所有无法识别或不相关的参数。忽略不相关的参数是不合法的行为。
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.
MISSINGPARAMETERS从具体mime类型转换为mime类型“（“transcoding params”）”—将指定的源mime类型转换为目标mime类型需要列出的参数，但在请求中找不到这些参数。请注意，如果客户端请求“默认转换”（请参见第6节），则to mime类型包含服务器选择的目标mime类型。
Examples:
示例：
C: b002 CONVERT 2 ("APPLICATION/PDF") BINARY[3]
S: b002 NO [TEMPFAIL] All conversions failed
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: 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
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 Form（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
命令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) ")" )
convert=“convert”SP序列集SP convert参数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”/“BODYPARTSTRUCTURE”section convert/“BINARY”section convert[partial]/“BINARY.SIZE”section convert/“BODY[HEADER]”/“BODY[“section part.HEADER]”/“BODY[“section part.MIME]”/“AVAILABLECONVERSIONS”section convert
; <partial> is defined in [RFC3516]. ; <section-part> is defined in [RFC3501].
; <[RFC3516]中定义了部分><[RFC3501]中定义了截面零件>。
convert-params = "(" (quoted-to-mime-type / default-conversion)
[SP "(" transcoding-params ")"] ")"
convert-params = "(" (quoted-to-mime-type / default-conversion)
[SP "(" transcoding-params ")"] ")"
quoted-to-mime-type = DQUOTE to-mime-type DQUOTE
quoted-to-mime-type = DQUOTE to-mime-type DQUOTE
transcoding-params = transcoding-param *(SP transcoding-param)
转码参数=转码参数*（SP转码参数）
transcoding-param-names = transcoding-param-name *(SP transcoding-param-name)
转码参数名称=转码参数名称*（SP转码参数名称）
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.
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参数名称nq=特征标签<功能标签>在[MEDIAFEAT-REG]中定义。
transcoding-param-value = astring
transcoding-param-value = astring
default-conversion = "NIL"
default-conversion = "NIL"
message-data =/ nz-number SP "CONVERTED" SP convert-correlator SP convert-msg-attrs
消息数据=/nz number SP“已转换”SP convert correlator SP convert msg attrs
convert-correlator = "(" "TAG" SP tag-string ")"
convert correlator=“（“”标记“SP标记字符串”）”
tag-string = string
; tag of the command that caused
; the CONVERTED response, sent as
; a 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 ATTR=“（“convert msg att*（SP convert msg att）”）”；“UID”必须是第一个数据项（如果存在）。
convert-msg-att = msg-att-semistat / msg-att-conv-static
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 uniqueid；不能为消息更改
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”节转换[“<”number“>”]SP（nstring/literal8/converterror短语））/（“BINARY.SIZE”节转换SP（number/converterror短语））/（“BODYPARTSTRUCTURE”节转换SP（body/converterror短语））/（“AVAILABLECONVERSIONS”节转换SP（mimetype列表/converterror短语））；在IMAP“会话”期间不得更改；但从长远来看，不一定是静态的。
section-convert = section-binary
; <section-binary> is defined in [RFC3516].
;
; Note that unlike [RFC3516], conversion
; of a top level multipart/* is allowed.
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编号<[RFC3501]中定义了resp text code>。
mimetype-and-params = quoted-to-mime-type [SP "(" transcoding-params ")"] ; always includes a specific MIME type
mimetype和params=引用到mime类型[SP”（“转码参数”）”]；始终包含特定的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>.
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 PHASE=“（“错误”SP convert err DESRIPT SP convert ERROR code”）“
convert-error-code = "TEMPFAIL" [SP nz-number] / bad-params / missing-params
转换错误代码=“TEMPFAIL”[SP nz编号]/参数错误/缺少参数
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.
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
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.
坏参数=“坏参数”1*（SP（引用自mime类型/nil）SP mimetype和参数）；只有当主体部分不存在时，才会返回nil。
missing-params = "MISSINGPARAMETERS" 1*(SP quoted-from-mime-type SP mimetype-and-missing-params)
缺少params=“MISSINGPARAMETERS”1*（SP引用mime类型SP mimetype和缺少的参数）
mimetype-and-missing-params = quoted-to-mime-type "(" transcoding-param-names ")" ; always includes a specific MIME type
mimetype和缺少的参数=引用到mime类型“（“转换参数名称”）”；始终包含特定的MIME类型
concrete-mime-type = type-name "/" subtype-name
; i.e., "type/subtype".
; type-name and subtype-name
; are defined in [MIME-MTSRP].
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
from-concrete-mime-type = concrete-mime-type
to-mime-type = concrete-mime-type
to-mime-type = concrete-mime-type
command-auth =/ conversions-cmd
命令auth=/conversions cmd
conversions-cmd = "CONVERSIONS" SP from-mime-type-req SP to-mime-type-req
conversions cmd=“conversions”SP从mime类型req SP转换为mime类型req SP
from-mime-type-req = astring
; "mime-type-req" represented as IMAP <atom>,
; <quoted> or <literal>
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>.
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 = "*"
任意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].
mime type req=任何mime类型/（类型名称”/“任何mime类型）/具体mime类型；'*'，'类型/*'或类型/子类型'；类型名称在[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) ")"]
conversion data=“conversion”SP从mime类型SP quoted到mime类型[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类型和目标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已经按照以下小节的规定进行了注册。
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 mailing list"
<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、文本/浓缩和文本/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转换扩展[RFC5259]
Examples of typical use: C: b001 CONVERT 2 BINARY[3 ("text/plain" ("charset" "us-ascii" "unknown-character-replacement" "?"))]
典型使用示例：C:b001转换2二进制[3（“文本/普通”（“字符集”“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”媒体类型参数[charset-REG]的MIME类型。
Name(s) & email address(es) of person(s) to contact for further
information:
Alexey Melnikov <alexey.melnikov@isode.com>
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.
当客户端请求服务器端转换已签名的正文部分（例如，多部分内的部分/已签名）时，客户端无法验证转换的内容是否真实。不信任服务器执行签名身体部位转换的客户端可以下载签名对象、验证签名并自行执行转换。
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命令创建精心编制的错误消息，从而攻击服务器。如果服务器的转换函数或库存在安全问题（例如缓冲区溢出漏洞），则可能导致权限提升或拒绝服务。为了减轻此类攻击，服务器应在附加和/或转换操作中记录客户端身份验证，以便于跟踪滥用的客户端。此外，服务器实现者应该将转换函数或库与特权邮件存储区隔离，可能是通过在不同的进程中运行它。
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.
甲骨文公司的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（高通公司）、Arnt Gulbrandsen（Oryx）、Zoltan Ordogh（诺基亚）、Ben Last（Emccsoft）、Dan Karp（Zimbra）、Pete Resnick（高通公司）、Chris Newman（太阳公司）、Ted Hardie（高通公司）、Larry Masinter（Adobe公司）、Philip Guenther（Sendmail公司）、Greg Vaudreuil公司提出的出色批评和评论（阿尔卡特-朗讯）、大卫·哈林顿（康卡斯特）、戴夫·克里德兰（Isode）、帕西·奥宁（诺基亚）、马格努斯·维斯特隆德（爱立信）和贾里·阿尔科（爱立信），大大提高了本规范的质量。
The authors would also like to specially thank Dave Cridland for the MEDIACAPS command proposal and Dan Karp for the CONVERSIONS command proposal.
作者还要特别感谢Dave Cridland提出的MEDIACAPS命令建议，以及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（甲骨文公司）、Eugene Chiu（甲骨文公司）、Ray Cromwell（甲骨文公司）、Jia der Day（甲骨文公司）、Vi Ha（甲骨文公司）、Wook Hyun Jeong（三星电子有限公司）、Chang Kuang（甲骨文公司）、Rodrigo Lima（甲骨文公司），Stephane H.Maes（甲骨文公司）、Gustaf Rosell（索尼爱立信）、Jean Sini（符号技术）、Song Mu Son（LG电子）、樊晓辉（中国移动通信公司）和赵立军（中国移动通信公司）。
[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.，“字符集和语言媒体功能标签的注册”，RFC 2987，2000年11月。
[IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.
[IMAPABNF]Melnikov，A.和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]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非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 22311997年11月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, April 2003.
[RFC3516]Nerenberg，L.，“IMAP4二进制内容扩展”，RFC3516，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，“用于显示、打印和传真的媒体功能”，RFC 25341999年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 52552008年6月。
[LEM-STREAMING] Cook, N., "Streaming Internet Messaging Attachments", Work in Progress, June 2008.
[LEM-STREAMING]库克，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.012007年12月。
[OMA-STI] OMA, "Open Mobile Alliance, Standard Transcoding Interface Specification", OMA OMA-STI-V1_0, December 2005.
[OMA-STI]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
亚历克赛·梅尔尼科夫（编辑）英国米德尔塞克斯郡汉普顿车站路36号城堡商业村5号Isode有限公司TW12 2BX
EMail: Alexey.Melnikov@isode.com
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
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.