doc: Add RFC documents

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]
+