Internet Draft: CONVERT                               A. Melnikov (Ed.)
Document: draft-ietf-lemonade-convert-11                  Isode Limited
Intended status: Standard Track                       R. Cromwell (Ed.)
                                                       S. H. Maes (Ed.)
                                                                 Oracle
Expires: February 25, 2008                              August 24, 2007


                          IMAP CONVERT extension

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

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 its
   settings.

   This document also extends IMAP URL schema defined in
   draft-ietf-lemonade-rfc2192bis-XX.txt with a specifier for a
   converted body part.


Table of Contents

   Status of this Memo ....................................... 1
   Copyright Notice........................................... 1
   Abstract................................................... 1
   Conventions used in this document.......................... 1
   Table of Contents.......................................... 2
   1. Introduction............................................
   2. Relation with other E-mail specifications...............
   3. Scope of Conversions....................................
   4. Discovery with the CAPABILITY and GETMETADATA Commands..
     4.1. CAPABILITY..........................................
     4.2. GETMETADATA.........................................
   5. CONVERT and UID CONVERT commands........................
   6. CONVERT transcoding parameters..........................
     6.1. Mandatory Transcoding support.......................
       6.1.1. Additional features for mobile usage............
   7. Request/response data items to CONVERT/UID CONVERT
      commands................................................
     7.1. BODYPARTSTRUCTURE CONVERT request and response item.
     7.2. BINARY.SIZE CONVERT request and response item......
   8. Status responses, Response code extensions..............
   9. Formal Syntax...........................................
   10. IANA Considerations....................................
     10.1. IANA Entry and Attribute registrations.............
       10.1.1. IANA Entry "/convert"..........................
       10.1.2. IANA Entry "/convert/<type>/<subtype>/types"...
       10.1.3. IANA Entry "/convert/.../params"...............
     10.2. Registration of unknown-character-replacement media
           type parameter.....................................
   11. Security Considerations................................
   12. References.............................................
     12.1. Normative References...............................
     12.2. Informative References.............................
   13. Acknowledgments........................................
   14. Authors' Addresses.....................................
   Version History............................................
   Intellectual Property Statement............................
   Disclaimer of Validity.....................................
   Copyright Statement .......................................


1.    Introduction and Conventions used in this document

   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 server's
   knowledge of the client capabilities, user or administrator
   preferences or servers settings.

   This extension is primarily intended to be useful to mobile clients.
   It satisfies requirements specified in [MEMAIL] and [OMA-ME-RD].

   A server that supports CONVERT can convert body parts to other
   formats to be viewed 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 or can determine them (out of
   scope for CONVERT), the attachments can also be optimized for the
   capabilities of the devices (e.g. form factor of pictures).


1.2 Conventions used in this document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

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

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

   Editorial comments are surrounded with <<>>. [Note to RFC Editor:
   please remove this sentence before publication.]


2.   Relation with other IMAP specifications

   The CONVERT extension does not address conversion during streaming
   of attachments.

   CONVERT depends on the METADATA extension [METADATA] to support
   discovery of supported conversion formats. In addition,
   a server claiming compliance with this specification, MUST support
   the IMAP Binary specification [RFC3516].


3.   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.

4.   Discovery with the CAPABILITY and GETMETADATA Commands

4.1.         CAPABILITY

   A server that supports the CONVERT extension MUST return "CONVERT",
   "METADATA", and "BINARY" in the CAPABILITY response. (Client and
   server authors are reminded that the order of tokens returned in
   the CAPABILITY response is arbitrary.)

   Example: A server that implements CONVERT

      C: a001 CAPABILITY
      S: * CAPABILITY IMAP4rev1 CONVERT BINARY METADATA [...]
      S: a001 OK CAPABILITY completed


4.2.         GETMETADATA

   To determine which conversions are supported, server annotations are
   used. For each MIME format (<type>/<subtype> [MIME-IMT]) that can be
   converted, an annotation with the name
   "/convert/<type>/<subtype>/types" SHOULD exist. The "value.shared"
   attribute of this annotation contains a semicolon separated list of
   type/subtype output formats.

   The selection of available conversions MAY be adjustable by the
   server administrator, and MAY be sensitive to the current user.
   The selection of available conversions MAY also depend on
   information about the client obtained through a different mechanism
   outside the scope of CONVERT (e.g. dynamically through device
   description mechanisms or when the device was associated to the
   account).

   For each source MIME type that the client is interested in, it
   SHOULD determine which target conversions are supported by reading
   the "value.shared" attribute.

   In addition to the subtype-specific annotations, a special "wildcard"
   annotation named "/convert/<type>/@/types" MAY be used to reference
   any subtype of <type> media type.  A client that
   doesn't find an "/convert/<type>/<subtype>/types" annotation SHOULD
   check the value of the "/convert/<type>/@/types" annotation.

   Note that names of server annotations are case-sensitive (see
   [METADATA]). In order to guaranty interoperability, clients and
   servers MUST use the lowercases version of <type> and <subtype> when
   constructing an annotation name described above.

   Example: Discover all image conversions

      C: a GETMETADATA "/convert/image/@/types" value.shared
      S: * METADATA "/convert/image/@/types"
          (value.shared "image/jpeg;image/png;image/gif")
      S: a OK GETMETADATA complete

   The above example shows that the server supports one kind of input
   image transcoding, from image/jpeg to four different outputs: JPEG,
   PNG, GIF, and WBMP.

   For a given conversion, optional transcoding parameters MAY be
   present. These are mapped into the "value.shared" attribute in the
   "/convert/<srctype>/<srcsubtype>/<desttype>/<destsubtype>/params"
   annotation. A client
   wishing to use a conversion parameter SHOULD check if the server
   will accept it by reading the "value.shared" attribute.

      Example: Discover optional parameters for image/jpeg -> image/gif.

      C: a GETMETADATA /convert/image/jpeg/image/gif/params
          "value.shared"
      S: * METADATA /convert/image/jpeg/image/gif/params
            ("value.shared" "pix-x;pix-y")
      S: a OK GETMETADATA complete

   The above example shows that to convert from image/jpeg to image/gif,
   the transcoding supports the following types of option parameters:
   pix-x (width), pix-y (height).

   A client MAY use these values to check whether or not a desired
   conversion is possible, or it might, for example,  present the
   parameters as a GUI
   preferences pane for the user to customize.

   This document relies on the registry of transcoding parameters
   established by [MEDIAFEAT-REG]. The registry can be used to
   discover the underlying legal values that these parameters may take.
   Additional transcoding parameters, such as those defined by [OMA-STI],
   are expected to be registered in the future.


5.   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 - command unknown or arguments invalid

   The CONVERT extension defines CONVERT and UID CONVERT commands
   which 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 client
       MAY pipeline them.
     o BINARY[...] data item requests conversion of a body part or of
       the whole message according to conversion parameters and
       returning it 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.

   The CONVERT extension also adds one new response code and
   the CONVERTERROR untagged response. See section 8 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 the
   server makes such a choice.  For example, the server can know
   characteristics of the device through a device description
   mechanism, or it can have a prioritized list of MIME types based
   on how widespread they are, how difficult their rendering is, etc.
   Note that servers are REQUIRED to support "default conversion"
   requests.

   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.PEEK[section-part]<partial>

    BINARY.SIZE[section-part]

    BODYPARTSTRUCTURE[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.

   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 requires that the server returns UID data item
      in a corresponding CONVERTED response.

   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 with
   tagged NO response, preceded by the CONVERTERROR BADPARAMETERS response
   (see section 8).

      C: b001 CONVERT 2 ("text/plain" ("charset" "us-ascii")) BINARY[3]
      S: * CONVERTERROR BADPARAMETERS text/html text/plain ("charset"
          "us-ascii")
      S: b001 NO Source text has non us-ascii

   If the client also specified the "unknown-character-replacement"
   conversion parameter (see Section 10.2), 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
           character set>
         )
      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

   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 transcoding
   parameters specified by the client in the transcoding request.
   Note that some transcoding parameters can restrict what kind of
   conversion is possible, while others can remove some restrictions.


6.   CONVERT transcoding parameters

   IMAP servers which support CONVERT MAY support additional transcoding
   parameters for each media type, as defined by the registry
   established by [MEDIAFEAT-REG]. All such servers MUST minally
   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 implement any
   conversion from the text MIME subtypes specified above, except for
   the mandatory to implement conversion described in section 6.1.
   I.e., a server implementation MUST support the "charset" parameter
   for text/csv, only if it supports any conversion from text/csv.)

   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 [DISPLAY-FEATURES].

         C: d001 UID CONVERT 100 ("IMAGE/JPG" ("PIX-X" "128"
             "PIX-Y" "96")) BINARY[2]
         S: * 2 CONVERTED (TAG "d001") (UID 100 BINARY[2] ~{4182}
            <this part of a document is a rescaled image in
             JPG format with width=128, height=96.>
            )
         S: d001 OK UID CONVERT COMPLETED


6.1.         Mandatory Transcoding support

   A server implementing CONVERT MUST support character set conversions
   for the text/plain MIME type, and MUST support character set
   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 in the "/convert/text/plain/types" annotation. A request
   for annotation "/convert/text/plain/text/plain/params" MUST return
   "charset" and "unknown-character-replacement" (see Section 10.2) as
   supported transcoding parameters.

   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 character set), and the
   "unknown-character-replacement" conversion parameter is not
   specified, then the server MUST fail the conversion and MUST return
   the untagged CONVERTERROR BADPARAMETERS response (see Section 8).
   If the value specified in the "unknown-character-replacement"
   conversion itself can't be represented in the target character set,
   then the server MUST also fail the conversion and MUST return
   the untagged CONVERTERROR BADPARAMETERS response (see Section 8).


6.1.1.           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:

   - Conversion of HTML and XHTML documents to
     text/plain in ways that preserve at the minimum the document
     structure and tables.
   - Image conversions among the types image/gif,
     image/jpeg and image/png for at least the following parameters:
        o Size limit (i.e. reduce quality),
        o width,
        o height,
        o 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.


7.   Request/response data items to CONVERT/UID CONVERT commands

7.1.   CONVERTED untagged response

   Contents:   convert correlator
               CONVERT return data items

   The CONVERTED response is sent as a result of a successful CONVERT
   or UID CONVERT command specified in section 5 of this document.

   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, see section 9 and the remainder of
   section 7 for more details.


7.2.   BODYPARTSTRUCTURE CONVERT request and response item

   The BODYPARTSTRUCTURE data item is introduced when using the CONVERT
   extension.  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.

   A response to a CONVERT command containing the BODYPARTSTRUCTURE
   data item MUST return the BODYPARTSTRUCTURE as the first data item
   in the CONVERTED response. This requirement is to simplify handling
   of converted data in clients. <<Should it be the first after the
   UID data item?>>

   Example:
         C: e001 CONVERT 2 (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY[2]
             BODYPARTSTRUCTURE[2])
         S: * 2 CONVERTED (TAG "e001") (BODYPARTSTRUCTURE[2] ("IMAGE"
             "JPG" () NIL NIL "8bit" 4182 NIL NIL NIL) BINARY[2]
             ~{4182}
            <this part of a document is a rescaled image in
             JPG format with width=128, height=96.>
            )
         S: e001 OK UID CONVERT COMPLETED


7.3.   BINARY.SIZE CONVERT request and response item

      BINARY.SIZE[section-part ("media type/subtype" (parameters))]

         Requests the converted size of the section (i.e., the size to
         expect in a response to the corresponding CONVERT BINARY request).
         The return value MUST be exact and MUST NOT change during
         a duration of an IMAP "session". 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.

         Clients MUST NOT remember sizes of converterted messages/
         body parts across multiple IMAP "sessions". (This requirement
         allows an server implementation to upgrade its transcoding
         component without breaking interoperability.)

         Historical Note: Previous experience with
         IMAP servers which returned estimated RFC822.SIZE value shows
         that this caused interoperability problems. If the server
         returns a value which is smaller that the actual size, this
         will result in data truncation if <partial> download is used.
         If the server returns a value which is bigger that 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. Needlessly issuing this request could result
         in degraded performance due to servers having to calculate
         the value every time the request is issued.
         For that reason it is not a good idea to needlessly request
         BINARY.SIZE and use it in a UI to allow a user to chose between
         multiple conversions.

         Servers may disallow a conversion request on multiple
         messages at once, e.g.

            C: g001 CONVERT 1:* ("text/plain" ("charset" "us-ascii"))
                BINARY[3]

         <<Does this need a new response code?>>

         Note for server implementors: In order to improve performance,
         implementations are encouraged to cache converted body parts.
         For example, the server may perform a body part conversion
         when it receives BINARY.SIZE[...], BODYPARTSTRUCTURE[...]
         or BINARY[...] request and cache it until the client requests
         conversion/download of another body part, or until mailbox is
         closed. In order to mitigiate Deny-of-Service attacks from
         misbehaving or badly-written clients, a servers 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.
         Servers MAY refuse to execute a conversion request that converts
         multiple messages at once, i.e. a conversion request that
         specifies multiple message numbers/UIDs.


8.   Status responses, Response code extensions, CONVERTERROR response

   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 MUST reply with a tagged NO response that is preceded
   by the untagged CONVERTERROR MISSINGPARAMETERS response.

   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. The response SHOULD contain the
   TEMPFAIL response code (see below).

   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 tagged
   NO response.

   Otherwise, the server returns an OK response. The client in
   general 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 code which can be
   returned in the tagged NO response code:

   TEMPFAIL - the transcoding request failed temporarily. It might
   succeed later, so the client may retry.


   The CONVERTERROR response is used to communicate error conditions
   related to a conversion request. It can be followed by BADPARAMETERS
   or MISSINGPARAMETERS, which are defined below:

   BADPARAMETERS from-concrete-mime-type to-mime-type
   "(" convert-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
   follows the response code.

   MISSINGPARAMETERS from-concrete-mime-type to-mime-type
   "(" convert-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.


9.   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" [".PEEK"] section-convert [partial] /
                        "BINARY.SIZE" section-convert
                    ; "partial" is defined in [RFC3516].

      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  = 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) ")"

      convert-msg-att = msg-att-semistat / msg-att-conv-static

      msg-att-conv-static  = "UID" SP uniqueid
                    ; MUST NOT change for a message

      msg-att-semistat =
                   ( "BINARY" section-convert ["<" number ">"] SP
                      (nstring / literal8) ) /
                   "BINARY.SIZE" section-convert SP number /
                   "BODYPARTSTRUCTURE" section-convert SP body
                    ; MUST NOT change during an IMAP "session",
                    ; but not necessarily static in a long term.

      section-convert = section-binary
                    ; <section-binary> is defined in [RFC3516].
                    ;
                    ; Note that unlike [RFC3516], conversion
                    ; of a top level multipart/* is allowed.

   In the ABNF syntax "resp-text-code" of [RFC3501], is amended to:

          resp-text-code =/ "TEMPFAIL"

          mimetype-and-params = from-concrete-mime-type SP to-mime-type
              SP "(" transcoding-params ")"

          response-payload =/ convert-cond
              ; response-payload is defined in [IMAPABNF]

          convert-cond = "CONVERTERROR" SP (bad-params / missing-params)

          bad-params = "BADPARAMETERS" 1*(SP mimetype-and-params)

          missing-params = "MISSINGPARAMETERS"
                           1*(SP mimetype-and-params)

   In addition, the following ABNF describes the syntax of the
   GETMETADATA entries in Section 4.2

         convert-entry-req = available-conversions /
                             available-transcoding-parameters

         available-conversions = "/convert/" from-mime-type "/types"

         any-mime-type  = "@"

         from-mime-type = (type-name "/" any-mime-type) /
                          concrete-mime-type
                          ; "type/@" or "type/subtype"
                          ; type-name is defined in [MIME-MTSRP].

         concrete-mime-type = type-name "/" subtype-name
                          ; i.e.  "type/subtype".
                          ; type-name and subtype-name
                          ; are defined in [MIME-MTSRP].
                          ;
                          ; Note that [METADATA] allows for '.'
                          ; in annotation names, but prohibits
                          ; use of "priv" or "shared" as
                          ; a component of an annotation name,
                          ; e.g. e.g. foo.priv.bar is disallowed.
                          ; But note that such conflict is
                          ; unlikely.

         from-concrete-mime-type = concrete-mime-type

         to-mime-type = concrete-mime-type

         available-transcoding-parameters = "/convert/"
                          from-concrete-mime-type "/"
                          to-mime-type "/params"
            ; Name of an annotation containing transcoding parameters.
            ; i.e. /convert/frmtype/frmsubtype/totype/tosubtype/params.

   The "value.shared" syntax of any "/convert/<type>/<subtype>/types"
   annotation has the following syntax:

         types-shared-value = from-concrete-mime-type
                              *(";" from-concrete-mime-type)

   The "value.shared" syntax of any "/convert/<fromtype>/<fromsubtype>/
   <totype>/<tosubtype>/params" annotation has the following syntax:

         params-shared-value = transcoding-param-name
                               *(";" transcoding-param-name)


9.1.   CONVERT extension to IMAP URLs

   This document extends [IMAPURL] ";SECTION=" to allow referencing
   converted body parts. <enc-section> non-terminal from [IMAPURL] is
   updated as follows:

     enc-section      = 1*bchar
            ; %-encoded version of [RFC3501] "extended-section-spec".
            ; <bchar> is defined in [IMAPURL].

     extended-section-spec = section-spec
                / "CONVERT" SP convert-params
                      ; for the whole message
                / "CONVERT." section-part SP convert-params
                      ; for a body part


10.    IANA Considerations

   IMAP4 capabilities are registered by publishing a standards track or
   IESG approved experimental RFC.  The registry is currently located at
   <http://www.iana.org/assignments/imap4-capabilities>. This document
   defines the CONVERT IMAP capability.  IANA is requested to add this
   extension to the IANA IMAP Capability registry.

   IANA is also requested to perform registrations as defined in
   sections 10.1 and 10.2 of this document.


10.1.    IANA Entry and Attribute registrations

   The following sections specify IANA registrations for entries and
   attributes used in this document.

10.1.1.          IANA Entry "/convert"

          To: iana@iana.org
          Subject: IMAP METADATA Registration

          Please register the following IMAP METADATA item:

          [x] Entry        [ ] Attribute

          [ ] Mailbox      [x] Server

          Name: /convert

          Description: All annotations below this one are reserved
                       for use by [this RFC] and its extensions.

          Content-type:   text/plain; charset=utf-8

          Contact person: Alexey Melnikov

                  email:  alexey.melnikov@isode.com


10.1.2.          IANA Entry "/convert/<type>/<subtype>/types"

          To: iana@iana.org
          Subject: IMAP METADATA Registration

          Please register the following IMAP METADATA item:

          [x] Entry        [ ] Attribute

          [ ] Mailbox      [x] Server

          Name: /convert/<type>/<subtype>/types

          Description: Defined in [this RFC], Section 4.2.

          Content-type:   text/plain; charset=us-ascii

          Contact person: Alexey Melnikov

                  email:  alexey.melnikov@isode.com

10.1.3.          IANA Entry "/convert/.../params"

          To: iana@iana.org
          Subject: IMAP METADATA Registration

          Please register the following IMAP METADATA item:

          [x] Entry        [ ] Attribute

          [ ] Mailbox      [x] Server

          Name: /convert/<fromtype>/<fromsubtype>/<totype>/
          <tosubtype>/params

          Description: Defined in [this RFC], Section 4.2.

          Content-type:   text/plain; charset=utf-8

          Contact person: Alexey Melnikov

                  email:  alexey.melnikov@isode.com


10.2.    Registration of unknown-character-replacement media type
         parameter

   IANA is requested to add 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:
      New assignment by IANA

   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.

   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 [RFC XXXX]

   Examples of typical use:
      C: b001 CONVERT 2 BINARY[3 ("text/plain" ("charset"
          "us-ascii" "unknown-character-replacement" "?"))]

   Related standards or documents:
      [RFC XXXX]
      [CHARSET-REG]

   Considerations particular to use in individual applications,
   protocols, services, or negotiation mechanisms:
      None

   Interoperability considerations: None

   Security considerations: None

   Additional information:
      This media feature only make sense for MIME types that
      also support the "charset" media type parameter
      [CHARSET-REG].

   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


11.    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 server such as requesting an image be
   scaled to extremely large dimensions). Clients should be careful when
   requesting conversions or processing transformed attachments. Servers
   should avoid dangerous conversions if possible. Whenever possible,
   servers should perform verification of the converted
   attachments before returning them to the client.

   When the client requests a server-side conversion of a signed body
   part (e.g. a part inside multipart/signed), there is no way for
   the client to verify that the converted content is authentic.
   A client not trusting the server to perform conversion of a signed
   body part can download the signed object, verify the signature and
   perform the conversion itself.

   A client can create a carefully crafted bad message with the APPEND
   command followed by the CONVERT command to attack the server. If the
   server's conversion function or library has a security problem,
   this could result in privilege escalation or Denial of Service.

   On bandwidth limited mobile networks where users pay per data
   volumes, spam may become an important issue. It can be mitigated with
   appropriate filters and server-side spam prevention tools. These are
   of course outside the scope of CONVERT.

   Deployments in which the actual transcoding is done outside the IMAP
   server in a separate server are recommended to keep the servers in
   the same trusted domain (e.g. subnet).

12.    References

12.1.  Normative References

   [METADATA]  Daboo, C., "IMAP METADATA Extension",
      work in progress, draft-daboo-imap-annotatemore-11, 2007.

   [ABNF] D. Crocker, et al. "Augmented BNF for Syntax Specifications:
      ABNF", RFC 4234, October 2005.
      http://www.ietf.org/rfc/rfc4234

   [RFC2119] Brader, S.  "Keywords for use in RFCs to Indicate
      Requirement Levels", RFC 2119, March 1997.
      http://www.ietf.org/rfc/rfc2119

   [RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol
      Version 4 rev1", RFC 3501, March 2003.
      http://www.ietf.org/rfc/rfc3501

   [RFC3516] Nerenberg, L. "IMAP4 Binary Content Extension", RFC 3516,
      April 2003.
      http://www.ietf.org/rfc/rfc3516.txt

   [MIME-IMT] Freed, N. and N. Borenstein, "MIME (Multipurpose
      Internet Mail Extensions) Part Two: Media Types", RFC 2046,
      November 1996.

   [MIME-MTSRP] Freed, N. and J. Klensin, "Media Type Specifications
   and Registration Procedures", RFC 4288, December 2005.

   [MEDIAFEAT-REG] Holtman, K., Mutz, A. and T. Hardie, "Media Feature
   Tag Registration Procedure", RFC 2506, BCP 31, March 1999.

   [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.

   [IMAPURL] Melnikov, A., Newman, C. and S. H. Maes, "IMAP URL
   Scheme", work in progress, draft-ietf-lemonade-rfc2192bis-XX.txt


12.2.  Informative References

   [MEMAIL] Maes, S.H., "Lemonade and Mobile e-mail", draft-maes-
      lemonade-mobile-email-xx.txt, (work in progress).

   [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement Document,
      work in progress, http://www.openmobilealliance.org/

   [OMA-STI] Open Mobile Alliance, Standard Transcoding Interface
      Specification, version 1.0, work in progress,
      <http://member.openmobilealliance.org/ftp/Public_documents/BAC/STI
      /Permanent_documents/OMA-STI-V1_0-20050209-D.zip>.

   [DISPLAY-FEATURES] Masinter, L., Holtman, K., Mutz, A. and D. Wing,
     "Media Features for Display, Print, and Fax", RFC 2534, March 1999.


13.  Acknowledgments

   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), Peter Coates (Sun),
   Chris Newman (Sun) and Dave Cridland (Isode) which improved the
   quality of this specification considerably.

   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 draft: 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)), Zhao Lijun (CHINA
   MOBILE COMMUNICATIONS CORPORATION (CMCC)).


14.  Authors' Addresses

   Alexey Melnikov (Editor)
   Isode Limited
   5 Castle Business Village, 36 Station Road,
   Hampton, Middlesex, TW12 2BX, UK
   Email: Alexey.Melnikov@isode.com

   Stephane H. Maes (Editor)
   Oracle Corporation
   500 Oracle Parkway
   M/S 4op634
   Redwood Shores, CA 94065
   USA
   Phone: +1-650-607-6296
   Email: stephane.maes@oracle.com

   Ray Cromwell (Editor)
   Oracle Corporation
   500 Oracle Parkway
   Redwood Shores, CA 94065
   USA
   Email: ray@specified.invalid


15.  Version History

   Note to RFC-editor: Please delete this section before publication

   Release 11
   - Don't return BODYPARTSTRUCTURE automatically, unless requested by
     the client
   - Removed BODY and CONVERT.SIZE
   - Fixed examples to use () in a CONVERT command containing multiple
     data items
   - Changed the CONVERT command syntax to only allow for a single
     conversion. The conversion parameters are now a separate parameter
     to the CONVERT/UID CONVERT command. Added TAG correlator to the
     CONVERTED response.
   - Changed "bodypart" to "body part" everywhere to be consistent with
     RFC 3501

   Release 10
   - Allow for an empty body part specifier in CONVERT.SIZE
   - Corrected the BADPARAMETERS example
   - Deleted an incorrect comment from ABNF
   - Allow BODYPARTSTRUCTURE to be requested by a client
   - Some other editorial changes
   - Change CONVERT to become a separate command. Updated description,
     ABNF and examples as the result

   Release 09
   - Renamed replace-unknown-character media feature tag to
     unknown-character-replacement.
   - Changed BADPARAMETERS and MISSINGPARAMETERS response codes
     into parameters to a CONVERT response.

   Release 08
   - Updated the document to use the media feature IANA registry
     established by RFC 2506
   - Allow for conversion to non-leaf body parts
   - Removed .STRICT (all conversion is strict now)
   - Added replace-unknown-character media feature tag

   Release 07
   - Made default conversion mandatory for servers to support
   - Added CONVERT.SIZE FETCH data item
   - Removed INFORMATIONLOSS and SERVEROVERRIDE response codes
   - Added TEMPFAIL and MISSINGPARAMETERS response codes
   - Addressed editorial comments from Randy Gellens
   - Updated examples and ABNF

   Release 06
   - Allow conversion of non-leaf body parts.
   - Clarified that the target MIME type must be obeyed.
   - Changed from using new annotation attributes to standard ones
   - Major corrections to the ABNF section.
   - Disallow /convert/* annotation entry.
   - The * character is not allowed in annotation names, so the @
     character is used instead.
   - Clarified handling of default conversion.
   - Updated examples to match ABNF.
   - Updated or added missing references.

   Release 05
   - Client not mandated to support BINARY
   - Misc syntax and spelling fixes
   - New abstract contributed by Randall Gellens

   Release 04
   - Remove compression and encryption
   - Update to use latest METADATA draft
   - Add IANA registrations

   Release 03
   - Add mandatory character set conversions.
   - Add object level compression
   - Add object level encryption

   Release 02
      Fixed a normative example to be informative. Added formal syntax
      for BODYPARTSTUCTURE, response text codes, and formal structure
      of composite GETANNOTATE values.

   Release 01

   Corrected some grammatical mistakes.  Clarified meaning of
   GETTANNOTATION response properties. Changed CONVERT grammar to merge
   media type and subtype into a single parameter instead of two
   parameters. Clarified that BODYSTRUCTURERESPONSE is always returned
   for CONVERT requests. Moved transcoding parameter discussion to main
   body from appendix.

   Release 00

   Initial release published in October 2005 based on draft-maes-
   lemonade-lconvert-00 and the comments received at the London face to
   face meeting end of September 2005.

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.

Full Copyright Statement

    Copyright (C) The IETF Trust (2007).

    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.

Acknowledgement

    Funding for the RFC Editor function is currently provided by the
    Internet Society.