Internet Draft: CONVERT                               A. Melnikov (Ed.)
Document: draft-ietf-lemonade-convert-08                  Isode Limited
Intended status: Standard Track                       R. Cromwell (Ed.)
                                                       S. H. Maes (Ed.)
                                                                 Oracle
Expires: November 2007                                         May 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. 
    
    
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].   
 
 
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............................................ 3 
   2. Relation with other E-mail specifications............... 3 
   3. Scope of Conversions.................................... 4 
   4. Discovery with the CAPABILITY and GETMETADATA Commands.. 4 
      4.1. CAPABILITY......................................... 4 
      4.2. GETMETADATA ....................................... 4 
   5. CONVERT extension to BODY and BINARY FETCH data items... 5 
   6. CONVERT transcoding parameters.......................... 7 
      6.1. Mandatory Transcoding support...................... 7 
         6.1.1. Additional features for mobile usage.......... 8 
   7. FETCH response extensions............................... 8 
   8. Status responses, Response code extensions.............. 8 
   9. Formal Syntax........................................... 9 
   10. IANA Considerations.................................... 11 
   11. IANA Entry and Attribute registrations ................ 11 
      11.1. IANA Entry "/convert"............................. 11 
      11.2. IANA Attribute "types"............................ 12 
      11.3. IANA Attribute "params"........................... 12 
   Security Considerations.................................... 12 
   Normative References....................................... 13 
   Informative References..................................... 14 
   Version History............................................ 14 
   Acknowledgments............................................ 15 
   Authors' Addresses........................................ 15 
   Intellectual Property Statement........................... 16 
   Disclaimer of Validity.................................... 16 
   Copyright Statement .......................................16 
    
    
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 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).

      
2.   Relation with other E-mail 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, to use 
   CONVERT, the server 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. 
     
   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;image/wbmp") 
      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 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 defined by [OMA-STI],
   are expected to be standardized in the future.
    
    
5.   CONVERT extension to BODY and BINARY FETCH data items
    
   CONVERT defines a FETCH extension used to transcode
   the media type of a MIME part into another media type, and/or the
   same media type with different encoding parameters. It adds new
   options to the section-spec part of the BODY data item, a new
   FETCH data item CONVERT.SIZE, a new FETCH
   response data item BODYPARTSTRUCTURE, and new response codes. It is
   also expected to work with the IMAP BINARY data item extension, whose
   grammar is modified as well. The response to a CONVERT request
   always includes a BODYPARTSTRUCTURE. 
    
   Each request for a BODY or BINARY FETCH data item that contains
   CONVERT MUST result in a FETCH response containing BODY/BINARY
   and BODYPARTSTRUCTURE data items containing the same section
   specifier (including the CONVERT keyword and its parameters).
   This is needed so that the client can match the requested
   data items with the received ones. This also allows the client
   to request multiple conversions of the same body part in a single
   request.

   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 choice.  For example, the server can know
   characteristics of the device through a device description
   mechanism, or it can have a prioritized lists 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 syntax is modeled after the HEADER.FIELDS syntax in 
   [RFC3501], and is generally structured as: 
    
   BODY[section-part.CONVERT ("media type/subtype" 
   (parameters))]

   BODY.PEEK[section-part.CONVERT ("media type/subtype" 
   (parameters))]<partial> 
    
   BINARY[section-part.CONVERT ("media type/subtype" 
   (parameters))]<partial> 
    
   BINARY.PEEK[section-part.CONVERT ("media type/subtype" 
   (parameters))]<partial> 
    
   BINARY.SIZE[section-part.CONVERT ("media type/subtype" 
   (parameters))]<partial>

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

   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 FETCH 2 BODY[3.CONVERT ("APPLICATION/PDF")] 
      S: * 2 FETCH (BODYPARTSTRUCTURE[3.CONVERT ("APPLICATION/PDF")]
          ("APPLICATION" "PDF" () NIL NIL "Base64" 2135 NIL NIL NIL)
          BODY[3.CONVERT ("APPLICATION/PDF")] {2135} 
         <the document in .pdf format> 
         ) 
      S: a001 OK FETCH COMPLETED 
 
   Example:  The client requests for conversion of a text/html section 
   as 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 html code, so it fails the request with tagged NO
   response, containing the BADPARAMETERS response code (see section 8).
    
      C: b001 FETCH 2 BODY[3.CONVERT ("text/plain" ("charset"
          "us-ascii"))]
      S: b001 NO [BADPARAMETERS text/html text/plain (charset)] Source
          text has non us-ascii

   If the client also specified the "replace-unknown-character"
   conversion parameter (see Section 10.2), the same example can look
   like this:

      C: b001 FETCH 2 BODY[3.CONVERT ("text/plain" ("charset"
          "us-ascii" "replace-unknown-character" "TRUE"))]
      S: * 2 FETCH (BODYPARTSTRUCTURE[3.CONVERT ("text/plain" ("charset"
          "us-ascii" "replace-unknown-character" "TRUE"))] ("TEXT"
          "PLAIN" ("charset" "us-ascii") NIL NIL
          "Base64" 2135 181 NIL NIL NIL) BODY
         [3.CONVERT ("text/plain" ("charset" "us-ascii"
         "replace-unknown-character" "TRUE"))] {2135}
           <the document in text/plain format with us-ascii
           character set>
         )
      S: b001 OK FETCH 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 FETCH 2 CONVERT.SIZE[4 ("TEXT/PLAIN" ("CHARSET"
          "us-ascii"))]
      S: * 2 FETCH (CONVERT.SIZE[4 ("TEXT/PLAIN" ("CHARSET"
          "us-ascii"))] 3135)
      S: c000 OK FETCH COMPLETED 

   Later on the client requests 1000 bytes from the converted bodypart,
   starting from byte 2001:

      C: c001 FETCH 2 BODY[4.CONVERT ("TEXT/PLAIN" ("CHARSET"
          "us-ascii"))]<2001.1000>  
      S: * 2 FETCH (BODYPARTSTRUCTURE[4.CONVERT ("TEXT/PLAIN"
          ("CHARSET" "us-ascii"))] ("TEXT" "PLAIN" ("charset"
          "us-ascii") NIL NIL "7bit" 2135 181 NIL NIL NIL)
          BODY[4.CONVERT ("TEXT/PLAIN" ("CHARSET" "us-ascii"))]
          <2001>{135} 
           <bytes 2001 - 2135 of the document in text/plain format>
           ) 
      S: c001 OK FETCH 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 FETCH 100 BINARY[2.CONVERT ("IMAGE/JPG" (
            "PIX-X" "128" "PIX-Y" "96"))]  
         S: * 2 FETCH (UID 100 BODYPARTSTRUCTURE[2.CONVERT (
             "IMAGE/JPG" ("PIX-X" "128" "PIX-Y" "96"))] ("IMAGE/JPG"
             () NIL NIL "8bit" 4182 NIL NIL NIL)
             BINARY[2.CONVERT ("IMAGE/JPG" ("PIX-X" "128" "PIX-Y"
             "96"))] ~{4182}   
            <this part of a document is a rescaled image in
             JPG format with width=128, height=96.>  
            )  
         S: d001 OK UID FETCH 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 "replace-unknown-character" (see Section 10.2) as a
   supported transcoding parameter.
    
   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
   "replace-unknown-character" conversion parameter is not specified
   or specified with the value "FALSE", then the server MUST fail the
   conversion and MUST return the BADPARAMETERS response code (see
   Section 8).

    
6.1.1.           Additional features for mobile usage 

   This section is non normative.
    
   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.   FETCH request/response extensions 

7.1.   BODYPARTSTRUCTURE FETCH response item
    
   The BODYPARTSTRUCTURE data item is introduced when using the CONVERT 
   extension.  Its data follows the exact syntax specified in the
   [RFC3501] BODYSTRUCTURE data item, but contains information for only
   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.


7.2.   CONVERT.SIZE FETCH request and response item

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

         Requests the converted size of the section (i.e., the size to
         expect in response to the corresponding FETCH BODY request).

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

    
8.   Status responses, 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 MUST reply with a tagged NO response that contains the
   MISSINGPARAMETERS response code. 
    
   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. 
    
   The following extension response codes are provided for OK and NO 
   responses to disambiguate those situations:

   TEMPFAIL - the transcoding request failed temporarily. It might
   succeed later, so the client may retry.
    
   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], [MIME-MTSRP] and [MEDIAFEAT-REG].

   In the ABNF section-msgtext grammar in section 9 of [RFC3501], 
   Section-msgtext is hereby amended to read: 

      section-convert =  "CONVERT" SP convert-params

      section-msgtext =/ section-convert
    
      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"

      fetch-att =/ "CONVERT.SIZE" convert-size-section

      msg-att-static =/ "CONVERT.SIZE" convert-size-section SP number

      convert-size-section = "[" section-part SP convert-params "]"

   In the ABNF syntax "section-binary" of [RFC3516], is amended to: 

          section-binary =   "[" [section-binary-spec] "]"

          section-binary-spec = section-part ["." section-convert] /
                                section-convert
                              ; Note that conversion of a top level
                              ; multipart/* is allowed.

   In the ABNF syntax "msg-att-static" of [RFC3501], is amended to: 
    
          msg-att-static =/ "BODYPARTSTRUCTURE" section SP body

   In the ABNF syntax "resp-text-code" of [RFC3501], is amended to: 
    
          resp-text-code =/ "TEMPFAIL" /
                            bad-params-resp-code /
                            missing-params-resp-code /

          mimetype-and-params = from-concrete-mime-type SP to-mime-type
              SP "(" transcoding-params ")"
              ; The values can't include the ']' character, as this
              ; non-terminal is returned in an IMAP response code.

<<Does this include param values? If not, then the value in ()
  must be changed to "transcod-param-name-nq *(SP transcod-param-name-nq)"
  >>

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

          missing-params-resp-code = "MISSINGPARAMETERS" SP
                                 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].

<<Are '.' allowed in annotation names? Yes, as long
as the name doesn't contain "priv" or "shared" component,
e.g. foo.priv.bar is disallowed.>>

         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)


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 replace-unknown-character 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 replace-unknown-character

   Media feature tag name:
      replace-unknown-character

   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 character, such as '?'.

   Values appropriate for use with this feature tag:
       The feature tag is Boolean and may have values of TRUE or FALSE.
       When this media feature is not specified in an IMAP CONVERT
       request, the default of FALSE is assumed.

   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 FETCH 2 BODY[3.CONVERT ("text/plain" ("charset"
          "us-ascii" "replace-unknown-character" "TRUE"))]

   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.

   A client can create a carefully crafted bad message with the APPEND
   command followed by the FETCH command to attack the server. If the
   server's conversion function or library has a security problem,
   this could result in provilege 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.


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) which
   improved the quality of the CONVERT 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 
    
   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     

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

    
Version History

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

   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.