diff options
Diffstat (limited to 'doc/rfc/rfc5259.txt')
| -rw-r--r-- | doc/rfc/rfc5259.txt | 1683 |
1 files changed, 1683 insertions, 0 deletions
diff --git a/doc/rfc/rfc5259.txt b/doc/rfc/rfc5259.txt new file mode 100644 index 0000000..9d6ab8a --- /dev/null +++ b/doc/rfc/rfc5259.txt @@ -0,0 +1,1683 @@ + + + + + + +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. + +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. + + + + + + + + + + + + + + + + + + + + + + + + + + + +Melnikov & Coates Standards Track [Page 1] + +RFC 5259 IMAP CONVERT extension July 2008 + + +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 + + + + + + + + + + + + + + + + + + + +Melnikov & Coates Standards Track [Page 2] + +RFC 5259 IMAP CONVERT extension July 2008 + + +1. Introduction + + 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. + + This extension is primarily intended to be useful to mobile clients. + It satisfies requirements specified in [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. + + 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. + +2. Conventions Used in This Document + + 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]. + + 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. + + + + + + +Melnikov & Coates Standards Track [Page 3] + +RFC 5259 IMAP CONVERT extension July 2008 + + + 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]. + +3. Relation with Other IMAP Specifications + + Conversion of attachments during streaming is out of scope for the + CONVERT extension and is described in a separate Lemonade WG document + [LEM-STREAMING]. + + A server claiming compliance with this specification MUST support the + IMAP Binary specification [RFC3516]. + +3.1. CAPABILITY Response + + 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 + +4. Scope of Conversions + + 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. + +5. Discovery of Available Conversions + +5.1. CONVERSIONS Command + + Arguments: source MIME type + target MIME type + + Responses: untagged responses: CONVERSION + + + + + +Melnikov & Coates Standards Track [Page 4] + +RFC 5259 IMAP CONVERT extension July 2008 + + + Result: OK - CONVERSIONS command completed + BAD - unrecognized syntax of an argument, unexpected extra + argument, missing argument, etc. + + The CONVERSIONS command is allowed in Authenticated and Selected IMAP + states. + + The first parameter to the CONVERSIONS command is a source MIME type, + the second parameter is the target MIME type. Both parameters are + partially (e.g., "text/*") or completely ("*") wildcardable. + + Conversions matching the source/target pair and their associated + conversion parameters are returned in untagged CONVERSION responses. + If source/target doesn't match any conversion supported by the + server, no CONVERSION response is returned. + + Examples: + + For conversion information from GIF to JPEG image format (no untagged + CONVERSION response would be returned if no conversion is possible): + + 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: + + 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: + + 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/*" + + + +Melnikov & Coates Standards Track [Page 5] + +RFC 5259 IMAP CONVERT extension July 2008 + + +5.2. CONVERSION Response + + Contents: source MIME type + target MIME type + optional list of supported conversion parameters + + 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. + +6. CONVERT and UID CONVERT Commands + + 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. + + 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]: + + 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 BINARY[...] data item requests conversion of a body part or of the + whole message according to conversion parameters and requests that + the converted message/body part be returned as binary. + + o BINARY.SIZE data item is similar to RFC822.SIZE, but it requests + size of a converted body part/message. + + o BODYPARTSTRUCTURE data item is similar to BODYSTRUCTURE FETCH data + item, but it returns the MIME structure of the converted body + part. + + + +Melnikov & Coates Standards Track [Page 6] + +RFC 5259 IMAP CONVERT extension July 2008 + + + 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[...MIME] encoded words in the requested headers are converted + to the specified charset. The CHARSET parameter is REQUIRED for + this conversion. + + o AVAILABLECONVERSIONS data item requests the list of target MIME + types the specified body part (or the whole message) can be + converted to. + + The CONVERT extension also adds one new response code. See Section 9 + for more details. + + 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. + + + + +Melnikov & Coates Standards Track [Page 7] + +RFC 5259 IMAP CONVERT extension July 2008 + + + CONVERT's command syntax is modeled after the FETCH command syntax in + [RFC3501], as extended by [RFC3516]. CONVERT data items are + generally structured as: + + BINARY[section-part]<partial> + + BINARY.SIZE[section-part] + + BODYPARTSTRUCTURE[section-part] + + BODY[HEADER] + + BODY[section-part.HEADER] + + BODY[section-part.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. + + 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. + + 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: + + o UID CONVERT takes as a parameter a sequence of UIDs instead of a + sequence of message numbers. + + o UID CONVERT command MUST result in the UID data item in a + corresponding CONVERTED response. + + 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. + + + + + + + + + +Melnikov & Coates Standards Track [Page 8] + +RFC 5259 IMAP CONVERT extension July 2008 + + + 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. + + 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). + + 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: + + 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 "?". + + Example: The client first requests the converted size of a text/html + body part converted to text/plain: + + 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 + + + + + + +Melnikov & Coates Standards Track [Page 9] + +RFC 5259 IMAP CONVERT extension July 2008 + + + Later on, the client requests 1000 bytes from the converted body + part, starting from byte 2001: + + 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. + + 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 + + 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 + + + +Melnikov & Coates Standards Track [Page 10] + +RFC 5259 IMAP CONVERT extension July 2008 + + + 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 + + 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): + + 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. + + + + + + + + +Melnikov & Coates Standards Track [Page 11] + +RFC 5259 IMAP CONVERT extension July 2008 + + +7. CONVERT Conversion Parameters + + 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. + + According to [MEDIAFEAT-REG], conversion parameter names are case- + insensitive. + + 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]. + + 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 + +7.1. Mandatory-to-Implement Conversions and Conversion Parameters + + 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. + + 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. + + 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. + + 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. + + + + +Melnikov & Coates Standards Track [Page 12] + +RFC 5259 IMAP CONVERT extension July 2008 + + + 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). + +7.2. Additional Features for Mobile Usage + + 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 Image conversions among the types image/gif, image/jpeg, and + image/png for at least the following parameters: + + * size limit (i.e., reduce quality) + + * width ("pix-x" parameter) + + * height ("pix-y" parameter) + + * 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. + + + + + + + + + + + +Melnikov & Coates Standards Track [Page 13] + +RFC 5259 IMAP CONVERT extension July 2008 + + +8. Request/Response Data Items to CONVERT/UID CONVERT Commands + +8.1. CONVERTED Untagged Response + + 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. + + 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. + + 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. + +8.2. BODYPARTSTRUCTURE CONVERT Request and Response Item + + 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. + + 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. + + 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 + + + + + +Melnikov & Coates Standards Track [Page 14] + +RFC 5259 IMAP CONVERT extension July 2008 + + + 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. + + 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 + +8.3. BINARY.SIZE CONVERT Request and Response Item + + 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. + + 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. + + 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. + + 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> + + + + + +Melnikov & Coates Standards Track [Page 15] + +RFC 5259 IMAP CONVERT extension July 2008 + + + 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. + +8.4. AVAILABLECONVERSIONS CONVERT Request and Response Item + + 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. + + 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. + + 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. + + 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. + + Example: + C: f001 CONVERT 2 (NIL) (AVAILABLECONVERSIONS[2]) + S: * 2 CONVERTED (TAG "f001") (AVAILABLECONVERSIONS[2] + (("IMAGE/JPEG" "application/PostScript")) + S: f001 OK CONVERT COMPLETED + + + +Melnikov & Coates Standards Track [Page 16] + +RFC 5259 IMAP CONVERT extension July 2008 + + +8.5. Implementation Considerations + + 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: + + 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: + + C: h001 CONVERT 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 + + 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. + +9. Status Responses and Response Code Extensions + + 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. + + 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. + + + +Melnikov & Coates Standards Track [Page 17] + +RFC 5259 IMAP CONVERT extension July 2008 + + + 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. + + 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. + + 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 + + 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: + + 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. + + TEMPFAIL - The transcoding request failed temporarily. It might + succeed later, so the client MAY retry. + + + +Melnikov & Coates Standards Track [Page 18] + +RFC 5259 IMAP CONVERT extension July 2008 + + + MAXCONVERTMESSAGES <number> - The server is unable or unwilling to + convert more than <number> messages in any given CONVERT/UID + CONVERT request. + + 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. + + 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. + + 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. + + Note that if the client requested the "default conversion" (see + Section 6), the to-mime-type contains the destination MIME type + chosen by the server. + + MISSINGPARAMETERS from-concrete-mime-type to-mime-type + "(" transcoding-params ")" - + The listed parameters are required for conversion of the + specified source MIME type to the destination MIME type, but + were not seen in the request. Note that if the client + requested the "default conversion" (see Section 6), the to- + mime-type contains the destination MIME type chosen by the + server. + + + + + + + + + +Melnikov & Coates Standards Track [Page 19] + +RFC 5259 IMAP CONVERT extension July 2008 + + + 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 + +10. Formal Syntax + + 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. + + 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]. + + 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-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 + + + +Melnikov & Coates Standards Track [Page 20] + +RFC 5259 IMAP CONVERT extension July 2008 + + + ; <partial> is defined in [RFC3516]. + ; <section-part> is defined in [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-param-names = transcoding-param-name + *(SP transcoding-param-name) + + 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]. + + 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 ")" + + 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-att = msg-att-semistat / msg-att-conv-static + + msg-att-conv-static = "UID" SP uniqueid + ; MUST NOT change for a message + + + +Melnikov & Coates Standards Track [Page 21] + +RFC 5259 IMAP CONVERT extension July 2008 + + + 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. + + 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-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 ")" + + 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 + + + +Melnikov & Coates Standards Track [Page 22] + +RFC 5259 IMAP CONVERT extension July 2008 + + + 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. + + 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 + + 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 + + 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 = "*" + + mime-type-req = any-mime-type / + (type-name "/" any-mime-type) / + concrete-mime-type + ; '*', 'type/*' or 'type/subtype'. + ; type-name is defined in [MIME-MTSRP]. + + response-payload =/ conversion-data + + + + +Melnikov & Coates Standards Track [Page 23] + +RFC 5259 IMAP CONVERT extension July 2008 + + + conversion-data = "CONVERSION" SP quoted-from-mime-type SP + quoted-to-mime-type + [SP "(" transcoding-param-name + *(SP transcoding-param-name) ")"] + +11. Manageability Considerations + + The monitoring of CONVERT operation is similar to monitoring of the + IMAP FETCH operation. + + 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: + + o which conversions (source and target MIME types and possibly + conversion parameters used) are invoked more frequently and how + long they take, + + o information about conversion errors and which error condition + caused them (see Section 9), and + + o information about users which invoke conversion operation. + + 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. + +12. IANA Considerations + + 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. + + IANA has performed registrations as defined in the following + subsections. + + + + + + + + + + + + +Melnikov & Coates Standards Track [Page 24] + +RFC 5259 IMAP CONVERT extension July 2008 + + +12.1. Registration of unknown-character-replacement Media Type + Parameter + + IANA has added the following registration to the registry established + by 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 + + ASN.1 identifier associated with feature tag: + 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). + + 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. + + The feature tag is intended primarily for use in the following + applications, protocols, services, or negotiation mechanisms: + IMAP CONVERT extension [RFC5259] + + Examples of typical use: + C: b001 CONVERT 2 BINARY[3 ("text/plain" ("charset" + "us-ascii" "unknown-character-replacement" "?"))] + + Related standards or documents: + [RFC5259] + [CHARSET-REG] + + Considerations particular to use in individual applications, + protocols, services, or negotiation mechanisms: + None + + + + +Melnikov & Coates Standards Track [Page 25] + +RFC 5259 IMAP CONVERT extension July 2008 + + + 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]. + + 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 + + Requested IANA publication delay: + None + + Other information: + None + +13. Security Considerations + + 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. + + 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. + + + + +Melnikov & Coates Standards Track [Page 26] + +RFC 5259 IMAP CONVERT extension July 2008 + + + 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. + + 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). + +14. Acknowledgments + + Stephane H. Maes and Ray Cromwell from Oracle edited several earlier + versions of this document. Their contribution is gratefully + acknowledged. + + 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. + + The authors would also like to specially thank Dave Cridland for the + MEDIACAPS command proposal and Dan Karp for the CONVERSIONS command + proposal. + + 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)). + + + + +Melnikov & Coates Standards Track [Page 27] + +RFC 5259 IMAP CONVERT extension July 2008 + + +15. References + +15.1. Normative References + + [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", STD 68, RFC 5234, + January 2008. + + [CHARSET-REG] Hoffman, P., "Registration of Charset and Languages + Media Features Tags", RFC 2987, November 2000. + + [IMAPABNF] Melnikov, A. and C. Daboo, "Collected Extensions to + IMAP4 ABNF", RFC 4466, April 2006. + + [MEDIAFEAT-REG] Holtman, K., Mutz, A., and T. Hardie, "Media Feature + Tag Registration Procedure", BCP 31, RFC 2506, + March 1999. + + [MIME-MTSRP] Freed, N. and J. Klensin, "Media Type Specifications + and Registration Procedures", BCP 13, RFC 4288, + December 2005. + + [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail + Extensions) Part Three: Message Header Extensions + for Non-ASCII Text", RFC 2047, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and + Encoded Word Extensions: + Character Sets, Languages, and Continuations", + RFC 2231, November 1997. + + [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - + VERSION 4rev1", RFC 3501, March 2003. + + [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", + RFC 3516, April 2003. + + + + + + + + + + + + +Melnikov & Coates Standards Track [Page 28] + +RFC 5259 IMAP CONVERT extension July 2008 + + +15.2. Informative References + + [DISP-FEATURES] Masinter, L., Wing, D., Mutz, A., and K. Holtman, + "Media Features for Display, Print, and Fax", + RFC 2534, March 1999. + + [IMAP-I18N] Newman, C., Gulbrandsen, A., and A. Melnikov, + "Internet Message Access Protocol + Internationalization", RFC 5255, June 2008. + + [LEM-STREAMING] Cook, N., "Streaming Internet Messaging + Attachments", Work in Progress, June 2008. + + [OMA-ME-RD] OMA, "Open Mobile Alliance Mobile Email Requirement + Document", OMA 55.919 3.0.0, December 2007. + + [OMA-STI] OMA, "Open Mobile Alliance, Standard Transcoding + Interface Specification", OMA OMA-STI-V1_0, + December 2005. + +Authors' Addresses + + Alexey Melnikov (editor) + 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 + + EMail: peter.coates@Sun.COM + + + + + + + + + + + + +Melnikov & Coates Standards Track [Page 29] + +RFC 5259 IMAP CONVERT extension July 2008 + + +Full Copyright Statement + + Copyright (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. + + 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. + +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. + + 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. + + 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. + + + + + + + + + + + + +Melnikov & Coates Standards Track [Page 30] + |