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///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 (/ [MIME-IMT]) that can be converted, an annotation with the name "/convert///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//@/types" MAY be used to reference any subtype of media type. A client that doesn't find an "/convert///types" annotation SHOULD check the value of the "/convert//@/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 and 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/////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)] BINARY.PEEK[section-part] 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 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} ) 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} ) 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} ) 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} ) 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. <> 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} ) 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 ""). 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 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] <> 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 ; represented as a quoted, ; literal or atom. Note that ; 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 ; 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///types" annotation has the following syntax: types-shared-value = from-concrete-mime-type *(";" from-concrete-mime-type) The "value.shared" syntax of any "/convert/// //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. non-terminal from [IMAPURL] is updated as follows: enc-section = 1*bchar ; %-encoded version of [RFC3501] "extended-section-spec". ; 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 . 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///types" To: iana@iana.org Subject: IMAP METADATA Registration Please register the following IMAP METADATA item: [x] Entry [ ] Attribute [ ] Mailbox [x] Server Name: /convert///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//// /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" 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 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, . [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.