idnits 2.17.1 draft-ietf-lemonade-convert-20.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1347. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1358. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1365. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1371. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 20, 2008) is 5792 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'HEADER' is mentioned on line 492, but not defined -- Looks like a reference, but probably isn't: '3' on line 881 -- Looks like a reference, but probably isn't: '4' on line 812 -- Looks like a reference, but probably isn't: '2' on line 749 == Missing Reference: 'MAXCONVERTMESSAGES 1' is mentioned on line 742, but not defined -- Looks like a reference, but probably isn't: '1' on line 749 == Missing Reference: 'MAXCONVERTPARTS 1' is mentioned on line 751, but not defined == Missing Reference: 'RFC XXXX' is mentioned on line 1175, but not defined ** Obsolete normative reference: RFC 4288 (ref. 'MIME-MTSRP') (Obsoleted by RFC 6838) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov, Ed. 3 Internet-Draft Isode Ltd 4 Intended status: Standards Track P. Coates, Ed. 5 Expires: November 21, 2008 Sun Microsystems 6 May 20, 2008 8 IMAP CONVERT extension 9 draft-ietf-lemonade-convert-20.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on November 21, 2008. 36 Abstract 38 CONVERT defines extensions to IMAP allowing clients to request 39 adaptation and/or transcoding of attachments. Clients can specify 40 the conversion details or allow servers to decide based on knowledge 41 of client capabilities, on user or administrator preferences or its 42 settings. 44 Table of Contents 46 1. Introduction and Conventions used in this document . . . . . . 3 47 2. Conventions used in this document . . . . . . . . . . . . . . 3 48 3. Relation with other IMAP specifications . . . . . . . . . . . 4 49 3.1. CAPABILITY response . . . . . . . . . . . . . . . . . . . 4 50 4. Scope of Conversions . . . . . . . . . . . . . . . . . . . . . 4 51 5. Discovery of available conversions . . . . . . . . . . . . . . 4 52 5.1. CONVERSIONS command . . . . . . . . . . . . . . . . . . . 4 53 5.2. CONVERSION response . . . . . . . . . . . . . . . . . . . 6 54 6. CONVERT and UID CONVERT commands . . . . . . . . . . . . . . . 6 55 7. CONVERT conversion parameters . . . . . . . . . . . . . . . . 11 56 7.1. Mandatory to Implement Conversions and Conversion 57 Parameters . . . . . . . . . . . . . . . . . . . . . . . . 12 58 7.2. Additional features for mobile usage . . . . . . . . . . . 13 59 8. Request/response data items to CONVERT/UID CONVERT commands . 13 60 8.1. CONVERTED untagged response . . . . . . . . . . . . . . . 13 61 8.2. BODYPARTSTRUCTURE CONVERT request and response item . . . 14 62 8.3. BINARY.SIZE CONVERT request and response item . . . . . . 15 63 8.4. AVAILABLECONVERSIONS CONVERT request and response item . . 16 64 8.5. Implementation considerations . . . . . . . . . . . . . . 16 65 9. Status responses, Response code extensions . . . . . . . . . . 17 66 10. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 20 67 11. Manageability Considerations . . . . . . . . . . . . . . . . . 23 68 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 69 12.1. Registration of unknown-character-replacement media 70 type parameter . . . . . . . . . . . . . . . . . . . . . . 24 71 13. Security Considerations . . . . . . . . . . . . . . . . . . . 26 72 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 73 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 74 15.1. Normative References . . . . . . . . . . . . . . . . . . . 27 75 15.2. Informative References . . . . . . . . . . . . . . . . . . 28 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 77 Intellectual Property and Copyright Statements . . . . . . . . . . 30 79 1. Introduction and Conventions used in this document 81 This document defines the CONVERT extension to IMAP4 [RFC3501]. 82 CONVERT provides adaptation and transcoding of body parts as needed 83 by the client. Conversion (adaptation, transcoding) may be requested 84 by the client and performed by the server on a best effort basis or, 85 when requested by the client, decided by the server based on server's 86 knowledge of the client capabilities, user or administrator 87 preferences or server settings. 89 This extension is primarily intended to be useful to mobile clients. 90 It satisfies requirements specified in [OMA-ME-RD] 92 A server that supports CONVERT can convert body parts to other 93 formats to be viewed (for example) on a mobile device. The client 94 can explicitly request a particular conversion or ask the server to 95 select the best available conversion. When allowed by the client, 96 the server determines how to convert based on its own strategy (e.g. 97 based on knowledge of the client as discussed hereafter). If the 98 server knows the characteristics of the device (out of scope for 99 CONVERT) or can determine them, for example using a conversion 100 parameter containing device type, converted body parts can also be 101 optimized for capabilities of the device (e.g. form factor of 102 pictures). The client is able to control conversions using optional 103 conversion (also referred to as "transcoding" in this document) 104 parameters. 106 This document relies on the registry of conversion parameters 107 established by [MEDIAFEAT-REG]. The registry can be used to discover 108 the underlying legal values that these parameters can take. 109 Additional conversion parameters, such as those defined by [OMA-STI], 110 are expected to be registered in the future. 112 2. Conventions used in this document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 In examples, "C:" and "S:" indicate lines sent by the client and 119 server respectively. If a single "C:" or "S:" label applies to 120 multiple lines, then the line breaks between those lines are for 121 editorial clarity only and are not part of the actual protocol 122 exchange. The five characters [...] means that something has been 123 elided. 125 When describing the general syntax, some definitions are omitted as 126 they are defined in [RFC3501]. In particular, the term "session" is 127 used in this document as defined in Section 1.2 of [RFC3501]. 129 3. Relation with other IMAP specifications 131 Conversion of attachments during streaming is out of scope for the 132 CONVERT extension and is described in a separate Lemonade WG document 133 [lemonade-streaming]. 135 A server claiming compliance with this specification, MUST support 136 the IMAP Binary specification [RFC3516]. 138 3.1. CAPABILITY response 140 A server that supports the CONVERT extension MUST return "CONVERT", 141 and "BINARY" in the CAPABILITY response or response code. (Client 142 and server authors are reminded that the order of tokens returned in 143 the CAPABILITY response or response code is arbitrary.) 145 Example: A server that implements CONVERT 147 C: a000 CAPABILITY 148 S: * CAPABILITY IMAP4rev1 CONVERT BINARY [...] 149 S: a000 OK CAPABILITY completed 151 4. Scope of Conversions 153 Conversions only affect what is sent to the client; the original data 154 in the message store MUST NOT be altered. This document does not 155 specify how the server performs conversions. 157 Note: The requirement that original data be unaltered allows such 158 data to remain accessible by other clients, permits replies or 159 forwards of the original documents, permits signature verification 160 (the converted body parts are not likely to contain any signatures), 161 and preserves BODYSTRUCTURE and related information. 163 5. Discovery of available conversions 165 5.1. CONVERSIONS command 166 Arguments: source MIME type 167 target MIME type 169 Responses: untagged responses: CONVERSION 171 Result: OK - CONVERSIONS command completed 172 BAD - unrecognized syntax of an argument, 173 unexpected extra argument, missing argument, etc. 175 The CONVERSIONS command is allowed in Authenticated and Selected IMAP 176 states. 178 The first parameter to the CONVERSIONS command is a source MIME type, 179 the second parameter is the target MIME type. Both parameters are 180 partially (e.g. "text/*") or completely ("*") wildcardable. 182 Conversions matching the source/target pair and their associated 183 conversion parameters are returned in untagged CONVERSION responses. 184 If source/target doesn't match any conversion supported by the 185 server, no CONVERSION response is returned. 187 Examples: 189 For conversion information from GIF to JPEG image format (no untagged 190 CONVERSION response would be returned if no conversion is possible): 192 C: a CONVERSIONS "image/gif" "image/jpeg" 193 S: * CONVERSION "image/gif" "image/jpeg" ("pix-y" "pix-x" 194 "image-interleave") 195 S: a OK CONVERSIONS completed 197 For conversion information from GIF image format to anything: 199 C: b CONVERSIONS "image/gif" "*" 200 S: * CONVERSION "image/gif" "image/jpeg" ("pix-y" "pix-x" 201 "image-interleave") 202 S: * CONVERSION "image/gif" "image/png" ([...]) 203 [...] 204 S: b OK CONVERSIONS completed 206 For conversion of anything to JPEG: 208 C: c CONVERSIONS "*" "image/jpeg" 209 S: * CONVERSION "image/gif" "image/jpeg" ("pix-y" "pix-x" 210 "image-interleave") 211 S: * CONVERSION "image/png" "image/jpeg" (...) 212 [...] 213 S: c OK CONVERSIONS completed 215 For conversions from all image formats to all text formats the client 216 can issue the following command: 218 C: d CONVERSIONS "image/*" "text/*" 220 5.2. CONVERSION response 222 Contents: source MIME type 223 target MIME type 224 optional list of supported conversion parameters 226 As a result of executing a CONVERSIONS command, the server can return 227 one or more CONVERSION responses. Each CONVERSION response specifies 228 which source MIME type can be converted to the target MIME type, and 229 also list supported conversion parameters. 231 6. CONVERT and UID CONVERT commands 233 Arguments: sequence set 234 conversion parameters 235 CONVERT data item names 237 Responses: untagged responses: CONVERTED 239 Result: OK - convert completed 240 NO - convert error: can't fetch and/or convert that data 241 BAD - unrecognized syntax of an argument, 242 unexpected extra argument, missing argument, etc. 244 The CONVERT extension defines CONVERT and UID CONVERT commands which 245 are used to transcode the media type of a MIME part into another 246 media type, and/or the same media type with different encoding 247 parameters. These commands are structured and behave similarly to 248 FETCH/UID FETCH commands as extended by [RFC3516]: 250 o A successful CONVERT/UID CONVERT command results in one or more 251 untagged CONVERTED responses (one per message). They are similar 252 to the untagged FETCH responses. Note that a single CONVERT/ UID 253 CONVERT command can only perform a single type of conversion as 254 defined by the conversion parameters. A client that needs to 255 perform multiple different conversions needs to issue multiple 256 CONVERT/UID CONVERT commands. Such client MAY pipeline them. 258 o BINARY[...] data item requests conversion of a body part or of the 259 whole message according to conversion parameters and returning it 260 as binary. 262 o BINARY.SIZE data item is similar to RFC822.SIZE, but it requests 263 size of a converted body part/message. 265 o BODYPARTSTRUCTURE data item is similar to BODYSTRUCTURE FETCH data 266 item, but it returns the MIME structure of the converted body 267 part. 269 o BODY[...HEADER] encoded words in the requested headers are 270 converted to the specified charset. The CHARSET parameter is 271 REQUIRED for this conversion. 273 o BODY[...MIME] encoded words in the requested headers are converted 274 to the specified charset. The CHARSET parameter is REQUIRED for 275 this conversion. 277 o AVAILABLECONVERSIONS data item requests the list of target MIME 278 types the specified body part (or the whole message) can be 279 converted to. 281 The CONVERT extension also adds one new response code. See Section 9 282 for more details. 284 Typically clients will request conversion of leaf body parts. In 285 addition to support of leaf body part conversion, servers MAY offer 286 conversion of non-leaf body parts (e.g. conversion from multipart/ 287 related). 289 Instead of specifying the exact target MIME media type the client 290 wants to convert to, the client MAY use a special marker NIL (also 291 known as "default conversion") to request the server to pick a 292 suitable target media type. This document doesn't describe how 293 exactly the server makes such a choice, however some basic guidelines 294 are described in this paragraph. If the server knows characteristics 295 of the device using an in-band (such as device type specified in a 296 conversion parameter) or an out-of-band mechanism, then it should 297 convert the request body part to a media type the device is likely to 298 support and display/play successfully. Unless specifically 299 overridden by a conversion parameter, the server MAY also remove any 300 unnecessary detail that exceeds the capabilities of the device (e.g. 301 scaling images to just fit on the device's screen). In the absence 302 of any in-band or out-of-band mechanism for determining device 303 characteristics, the server should convert the request body part to 304 the most standard or widely deployed media type available in that 305 media category, for example to convert to text/plain, image/jpeg. In 306 such case the server should minimize quality loss. Servers are 307 REQUIRED to support "default conversion" requests. Server 308 implementations that support conversions to multiple target MIME 309 types SHOULD make the default conversion configurable. Clients 310 SHOULD avoid using the default conversion unless they provided a way 311 (in-band or out-band) to signal their capabilities to the server, as 312 there is no guaranty that the server would guess their capability 313 correctly. Client implementors should consider using 314 AVAILABLECONVERSIONS CONVERT data item or CONVERSIONS command instead 315 of the default conversion. 317 CONVERT's command syntax is modeled after the FETCH command syntax in 318 [RFC3501], as extended by [RFC3516]. CONVERT data items are 319 generally structured as: 321 BINARY[section-part] 323 BINARY.SIZE[section-part] 325 BODYPARTSTRUCTURE[section-part] 327 BODY[HEADER] 329 BODY[section-part.HEADER] 331 BODY[section-part.MIME] 333 AVAILABLECONVERSIONS[section-part] 335 The semantics of a partial CONVERT BINARY[...] command is the same as 336 for a partial FETCH BODY[...] command, with the exception that the 337 arguments refer to the TRANSCODED and DECODED section data. 339 Note that unlike the FETCH command, the CONVERT command never sets 340 the \Seen flag on converted messages. A client wishing to mark a 341 message with the \Seen flag would need to issue a STORE command 342 (possibly pipelined with the CONVERT request) to do that. 344 The UID CONVERT command is different from the CONVERT command in the 345 same way as the UID FETCH command is different from the FETCH 346 command: 348 o UID CONVERT takes as a parameter a sequence of UIDs instead of a 349 sequence of message numbers. 351 o UID CONVERT command MUST result in the UID data item in a 352 corresponding CONVERTED response. 354 o An EXPUNGE response MUST NOT be sent while responding to a CONVERT 355 command. This rule is necessary to prevent a loss of 356 synchronization of message sequence numbers between client and 357 server. Note that an EXPUNGE response MAY be sent during a UID 358 CONVERT command. 360 Example: The client fetches body part section 3 in the message with 361 the message sequence number of 2 and asks to have that attachment 362 converted to pdf format. 364 C: a001 CONVERT 2 ("APPLICATION/PDF") BINARY[3] 365 S: * 2 CONVERTED (TAG "a001") (BINARY[3] {2135} 366 367 ) 368 S: a001 OK CONVERT COMPLETED 370 Example: The client requests for conversion of a text/html body part 371 to text/plain and asks for a charset of us-ascii. The server cannot 372 respect the charset conversion request because there are non-us-ascii 373 characters in the text/html body part, so it fails the request by 374 returning an ERROR phrase in place of the converted data (see 375 Section 9). 377 C: b001 CONVERT 2 ("text/plain" ("charset" "us-ascii")) BINARY[3] 378 S: * 2 CONVERTED (tag "b001") (BINARY[3] 379 (ERROR "Source text has non us-ascii" BADPARAMETERS 380 "text/html" "text/plain" ("charset" "us-ascii"))) 381 S: b001 NO All conversions failed 383 If the client also specified the "unknown-character-replacement" 384 conversion parameter (see Section 12.1), the same example can look 385 like this: 387 C: b001 CONVERT 2 ("text/plain" ("charset" "us-ascii" 388 "unknown-character-replacement" "?")) BINARY[3] 389 S: * 2 CONVERTED (TAG "b001") (BINARY[3] {2135} 390 392 ) 393 S: b001 OK CONVERT COMPLETED 395 The server replaced non-us-ascii characters with a us-ascii character 396 such as "?". 398 Example: The client first requests the converted size of a text/html 399 body part converted to text/plain: 401 C: c000 CONVERT 2 ("TEXT/PLAIN" ("CHARSET" "us-ascii")) 402 BINARY.SIZE[4] 403 S: * 2 CONVERTED (TAG "c000") (BINARY.SIZE[4] 3135) 404 S: c000 OK CONVERT COMPLETED 406 Later on the client requests 1000 bytes from the converted body part, 407 starting from byte 2001: 409 C: c001 CONVERT 2 ("TEXT/PLAIN" ("CHARSET" "us-ascii")) 410 BINARY[4]<2001.1000> 411 S: * 2 CONVERTED (TAG "c001") (BINARY[4]<2001> {135} 412 413 ) 414 S: c001 OK CONVERT COMPLETED 416 The server MUST respect the target MIME type and conversion 417 parameters specified by the client in the transcoding request. Note 418 that some conversion parameters can restrict what kind of conversion 419 is possible, while others can remove some restrictions. 421 It is legal for a client to request conversion of a non leaf body 422 part, for example to request conversion of a multipart/* into a PDF 423 document. However servers implementing this extension are not 424 required to support such conversions. Servers that support such 425 conversions MUST return one or more CONVERSION responses, in response 426 to a 'CONVERSIONS "multipart/*" "*"' command. See Section 5.1 for 427 more details. 429 The client can request header conversions using the BODY[...HEADER] 430 CONVERT request, for example 432 C: D001 FETCH 2 BODY[HEADER] 433 S: * 2 FETCH (BODY[HEADER] {158} 434 S: Date: Mon, 20 Apr 2007 20:05:43 +0200 435 S: From: Peter 436 S: To: Alexey 437 S: Subject: =?KOI8-R?Q?why encode this?= 438 S: 439 S: ) 440 S: D001 OK 441 C: D002 CONVERT 2 (NIL ("CHARSET" "utf-8")) BODY[HEADER] 442 S: * 2 CONVERTED (TAG "d002") (BODY[HEADER] {157} 443 S: Date: Mon, 20 Apr 2007 20:05:43 +0200 444 S: From: Peter 445 S: To: Alexey 446 S: Subject: =?UTF-8?Q?why encode this?= 447 S: 448 S: ) 449 S: D002 OK 451 Any such request MUST include the CHARSET parameter. Upon receipt of 452 the request the server MUST decode any encoded words (as described in 453 [RFC2047]) in headers and return them re-encoded in the specified 454 charset. (Note that encoded-words might not be needed if the result 455 can be represented entirely in US-ASCII, so the server MAY replace 456 the resulting encoded-words with their pure US-ASCII representation.) 457 If the server can't decode any particular encoded word, for example 458 if the charset or encoding is not recognized, it MUST leave them as 459 is. Servers SHOULD also support decoding of any parameters as 460 described in [RFC2231]. Support for RFC 2231 parameters might 461 require reformatting of header fields during conversion. Consider 462 the following 464 C: D011 FETCH 3 BODY[1.MIME] 465 S: * 3 FETCH (BODY[1.MIME] {118} 466 S: Content-Type: text/plain; charset=utf-8; 467 S: foo*0*=utf-8'fr'tr%c0; 468 S: foo*1*(very)=%03s_m%c0; 469 S: foo*2*=(nasty)%09chant 470 S: 471 S: D011 OK 473 The server should preserve the headers during the conversion as much 474 as possible. In case the characters are split (legally!) between 475 fragments of an encoded parameter, the server MUST consolidate the 476 parameter fragments, and convert, emit and re-fragment them as 477 necessary in order to keep the line length less than 78. Comments 478 embedded like this SHOULD be preserved during conversion, but clients 479 MUST gracefully handle the situation where comments are removed 480 entirely. If the comments are preserved, they MAY be moved after the 481 parameter. For example (continuing the previous example): 483 C: D012 CONVERT 3 (NIL) BODY[1.MIME] 484 S: * 3 CONVERTED (TAG "D012") (BODY[1.MIME] {109} 485 S: Content-Type: text/plain; charset=utf-8; 486 S: foo*0*=utf-8'fr'tr%c0%03s_; 487 S: foo*1*=%m%c0%09chant (very)(nasty) 488 S: 489 S: D012 OK 491 No destination MIME type MUST be specified with BODY[HEADER], 492 BODY[section.HEADER], or BODY[section.MIME]. I.e. BODY[HEADER], 493 BODY[section.HEADER], or BODY[section.MIME] can only be used with the 494 "default conversion" . When performing these conversions the server 495 SHOULD leave encoded words as encoded words. A failure to do so may 496 alter the semantics of structured headers. 498 7. CONVERT conversion parameters 500 The registry established by [MEDIAFEAT-REG] defines names of 501 conversion parameters that can be used in the CONVERT command. 502 Support for some conversion parameters is mandatory, as described in 503 Section 7.1. 505 According to [MEDIAFEAT-REG], conversion parameter names are case- 506 insensitive. 508 The following example illustrates how target picture dimensions can 509 be specified in a CONVERT request using the PIX-X and PIX-Y 510 parameters defined in [DISPLAY-FEATURES]. 512 C: e001 UID CONVERT 100 ("IMAGE/JPEG" ("PIX-X" "128" 513 "PIX-Y" "96")) BINARY[2] 514 S: * 2 CONVERTED (TAG "e001") (UID 100 BINARY[2] ~{4182} 515 517 ) 518 S: e001 OK UID CONVERT COMPLETED 520 7.1. Mandatory to Implement Conversions and Conversion Parameters 522 A server implementing CONVERT MUST support charset conversions for 523 the text/plain MIME type, and MUST support charset conversions from 524 iso-8859-1, iso-8859-2, iso-8859-3, iso-8859-4, iso-8859-5, 525 iso-8859-6, iso-8859-7, iso-8859-8 and iso-8859-15 to utf-8. 527 The server MUST list "text/plain" as an allowed destination 528 conversion from "text/plain" MIME type (see Section 5.1). A command 529 'CONVERSIONS "text/plain" "text/plain"' MUST also return "charset" 530 and "unknown-character-replacement" (see Section 12.1) as supported 531 conversion parameters in the corresponding CONVERSION response. 533 IMAP servers implementing the CONVERT extension MUST support 534 recognition of the "charset" [CHARSET-REG] parameter for text/plain, 535 text/html, text/css, text/csv, text/enriched and text/xml MIME types. 536 Note, a server implementation is not required to support any 537 conversion from the text MIME subtypes specified above, except for 538 the mandatory to implement conversion described above. I.e., a 539 server implementation MUST support the "charset" parameter for text/ 540 csv, only if it supports any conversion from text/csv. 542 The server MUST support decoding of [RFC2047] headers and their 543 conversion to UTF-8 as long as the encoded words are in one of the 544 supported charsets. 546 Servers SHOULD offer additional character encoding conversions where 547 they make sense as character conversion libraries are generally 548 available on many platforms. 550 If the server cannot carry out the charset conversion while 551 preserving all the characters (i.e. a source character can't be 552 represented in the target charset), and the "unknown-character- 553 replacement" conversion parameter is not specified, then the server 554 MUST fail the conversion and MUST return the untagged ERROR 555 BADPARAMETERS response (see Section 9). If the value specified in 556 the "unknown-character-replacement" conversion itself can't be 557 represented in the target charset, then the server MUST also fail the 558 conversion and MUST return the untagged ERROR BADPARAMETERS response 559 (see Section 9). 561 7.2. Additional features for mobile usage 563 This section is informative. 565 Based on the expected usage of convert in mobile environments, server 566 implementors should consider support for the following conversions: 568 o Conversion of HTML and XHTML documents to text/plain in ways that 569 preserve at the minimum the document structure and tables. 571 o Image conversions among the types image/gif, image/jpeg and image/ 572 png for at least the following parameters: 574 * Size limit (i.e. reduce quality), 576 * width ("pix-x" parameter), 578 * height ("pix-y" parameter), 580 * resize directive (crop, stretch, aspect ratio) 582 The support for "depth" may also be of interest. 584 Audio conversion is also of interest but the relevant formats depend 585 significantly on the usage context. 587 8. Request/response data items to CONVERT/UID CONVERT commands 589 8.1. CONVERTED untagged response 591 Contents: convert correlator 592 CONVERTED return data items 594 The CONVERTED response may be sent as a result of a successful, 595 partially successful or unsuccessful CONVERT or UID CONVERT command 596 specified in Section 6. 598 The CONVERTED response starts with a message number, followed by the 599 "CONVERTED" label. The label is followed by a convert correlator, 600 which contains the tag of the command that caused the response to be 601 returned. This can be used by a client to match a CONVERTED response 602 against a corresponding CONVERT/UID CONVERT command. 604 The convert correlator is followed by a list of one or more CONVERT 605 return data items. If the UID data item is returned, it MUST be 606 returned as the first data item in the CONVERTED response. This 607 requirement is to simplify client implementations. See Section 10 608 and the remainder of Section 8 for more details. 610 8.2. BODYPARTSTRUCTURE CONVERT request and response item 612 BODYPARTSTRUCTURE[section-part] 614 The CONVERT extension defines the BODYPARTSTRUCTURE CONVERT data 615 item. Data contained in the BODYPARTSTRUCTURE return data item 616 follows the exact syntax specified in the [RFC3501] BODYSTRUCTURE 617 data item, but only contains information for the converted part. All 618 information contained in BODYPARTSTRUCTURE pertains to the state of 619 the part after it is converted, such as the converted MIME type, sub- 620 type, size, or charset. Note that the client can expect the returned 621 MIME type to match the one it requested (as the server is required to 622 obey the requested MIME type) and can treat mismatch as an error. 624 The returned BODYPARTSTRUCTURE data MUST match the BINARY data 625 returned for exactly the same conversion in the same IMAP "session". 626 This requirement allows a client to request BODYPARTSTRUCTURE and 627 BINARY data in separate commands in the same IMAP session. 629 If the client lists a BODYPARTSTRUCTURE data item for a section-part 630 before a BINARY data item for the same section-part, then, in the 631 CONVERTED response, the server MUST return the BODYPARTSTRUCTURE data 632 prior to the corresponding BINARY data. Also, any BODYSTRUCTURE data 633 items MUST be after the UID data item if the UID data item is 634 present. Both requirements are to simplify handling of converted 635 data in clients. 637 Example: 638 C: e002 CONVERT 2 (NIL ("PIX-X" "128" "PIX-Y" "96")) (BINARY[2] 639 BODYPARTSTRUCTURE[2]) 640 S: * 2 CONVERTED (TAG "e002") (BODYPARTSTRUCTURE[2] ("IMAGE" 641 "JPEG" () NIL NIL "8bit" 4182 NIL NIL NIL) BINARY[2] 642 ~{4182} 643 645 ) 647 S: e002 OK CONVERT COMPLETED 649 8.3. BINARY.SIZE CONVERT request and response item 651 BINARY.SIZE[section-part] 653 Requests the converted size of the section (i.e., the size to expect 654 in a response to the corresponding CONVERT BINARY request). The 655 returned value MUST be exact and MUST NOT change during a duration of 656 an IMAP "session", unless the message is expunged in another session 657 (see below). This allows a client to download a converted part in 658 chunks (using ""). This requirement means that in most 659 cases the server needs to perform conversion of the requested body 660 part before returning its size. 662 If the message is expunged in another session, then the server MAY 663 return the value 0 in response to the BINARY.SIZE request item later 664 in the same session. 666 In order to allow for upgrade of server transcoding components, 667 clients MUST NOT assume that repeating a particular body part 668 conversion in another IMAP "session" would yield the same result as a 669 previous conversion of the very same body part - any characteristics 670 of the converted body part might be different (format, size, etc). 671 In particular clients MUST NOT cache sizes of converted messages/body 672 parts beyond duration of any IMAP "session", or use sizes obtained in 673 one connection in another IMAP connection to the same server. 675 Historical Note: Previous experience with IMAP servers which returned 676 estimated RFC822.SIZE value shows that this caused interoperability 677 problems. If the server returns a value which is smaller that the 678 actual size, this will result in data truncation if 679 download is used. If the server returns a value which is bigger that 680 the actual size, this might mislead a client to believe that it 681 doesn't have enough storage to download a body part. 683 Note for client implementors: client authors are cautioned that this 684 might be an expensive operation for some server implementations. 685 Requesting BINARY.SIZE for a large number of converted body parts or 686 for multiple conversions of the same body part can result in slow 687 performance and/or excessive server load and is discouraged. Client 688 implementors should consider implementation approaches that limit 689 this request to only the most necessary cases and are encouraged to 690 test the performance impact of BINARY.SIZE with multiple server 691 implementations. 693 8.4. AVAILABLECONVERSIONS CONVERT request and response item 695 AVAILABLECONVERSIONS[section-part] allows the client to request the 696 list of target MIME types the specified body part of a message or the 697 whole message can be converted to. This data item is only useful 698 when the default conversion (see Section 6) is requested. 700 This data item MUST return a list of target MIME type which is a 701 subset of the list returned by the CONVERSIONS command for the same 702 source and target MIME type pairs. If specific conversion is 703 requested, it MUST return the target MIME type as requested in the 704 CONVERT command, or the ERROR phrase. 706 For both specific or default conversion requests, if conversion 707 parameters are specified, then the server must take them into 708 consideration when generating the list of target MIME types. For 709 example, if one or more of the conversion parameters doesn't apply to 710 a potential target MIME type, then such MIME type MUST be omitted 711 from the resulting list. If the server only had a single target MIME 712 type candidate and it was discarded due to the list of conversion 713 parameters, then the server SHOULD return the ERROR phrase instead of 714 the empty list of the target MIME types. 716 The AVAILABLECONVERSIONS request SHOULD be processed quickly if 717 specified by itself. Note that if a MIME type is returned in 718 response to the AVAILABLECONVERSIONS, there is no guaranty that the 719 corresponding BINARY/BINARY.SIZE/BODYPARTSTRUCTURE CONVERT request 720 will not fail. 722 Example: 723 C: f001 CONVERT 2 (NIL) (AVAILABLECONVERSIONS[2]) 724 S: * 2 CONVERTED (TAG "f001") (AVAILABLECONVERSIONS[2] 725 (("IMAGE/JPEG" "application/PostScript")) 726 S: f001 OK CONVERT COMPLETED 728 8.5. Implementation considerations 730 Note that this section is normative. 732 Servers MAY refuse to execute conversion requests that convert 733 multiple messages and/or body parts at once, e.g. a conversion 734 request that specifies multiple message numbers/UIDs. If the server 735 refuse a conversion because the request lists too many messages, the 736 server MUST return the MAXCONVERTMESSAGES response code (see 737 Section 9), e.g. 739 C: g001 CONVERT 1:* ("text/plain" ("charset" "us-ascii")) 740 BINARY[3] 742 S: g001 NO [MAXCONVERTMESSAGES 1] 744 If the server refuse a conversion because the request lists too many 745 body parts, the server MUST return the MAXCONVERTPARTS response code 746 (see Section 9). For example 748 C: h001 CONVERT 1 ("text/plain" ("charset" "us-ascii")) 749 (BINARY[1] BINARY[2]) 751 S: g001 NO [MAXCONVERTPARTS 1] You can only request 1 body part at 752 any given time 754 Note for server implementors: In order to improve performance, 755 implementations SHOULD cache converted body parts. For example, the 756 server may perform a body part conversion when it receives 757 BINARY.SIZE[...], BODYPARTSTRUCTURE[...] or BINARY[...] request and 758 cache it until the client requests conversion/download of another 759 body part, or until mailbox is closed. In order to mitigate Denial- 760 of-Service attacks from misbehaving or badly-written clients, a 761 server SHOULD limit the number of converted body parts it can cache. 762 Servers SHOULD be able to cache at least 2 conversions at any given 763 time. 765 9. Status responses, Response code extensions 767 A syntactically invalid MIME media type SHOULD generate a BAD tagged 768 response from the server. An unrecognized MIME media type generates 769 a NO tagged response. 771 Some transcodings may require parameters. If a transcoding request 772 with no parameters is sent for a format which requires parameters, 773 the server will return an ERROR MISSINGPARAMETERS phrase in place of 774 the data associated with the data items requested. This is analogous 775 to the NIL response in FETCH, but with structured data associated 776 with the failure. 778 If the server is unable to perform the requested conversion because a 779 resource is temporary unavailable (e.g., lack of disk space, 780 temporary internal error, transcoding service down) then the server 781 MUST return a tagged NO response that SHOULD contain the TEMPFAIL 782 response code (see below), or an ERROR TEMPFAIL phrase. 784 If the requested conversion cannot be performed because of a 785 permanent error, for example if a proprietary document format has no 786 existing transcoding implementation, the server MUST return a 787 CONVERTED response containing a ERROR BADPARAMETERS or ERROR 788 MISSINGPARAMETERS phrase. 790 The server MAY choose to return one ERROR phrase for a single 791 conversion if several related data items are requested. For 792 instance: 794 C: b002 CONVERT 2 ("text/plain" ("charset" "us-ascii")) 795 (BINARY[3] BODYPARTSTRUCTURE[3]) 796 S: * 2 CONVERTED (tag "b002") (BODYPARTSTRUCTURE[3] 797 (ERROR "Source text has non us-ascii" BADPARAMETERS 798 "text/html" "text/plain" ("charset" "us-ascii"))) 799 S: b002 NO All conversions failed 801 If at least one conversion succeeds the server MUST return an OK 802 response. If all conversions fail, the server MAY return OK or NO. 803 For instance 805 C: b002 CONVERT 2 ("text/plain" ("charset" "us-ascii")) 806 (BINARY[3] BODYPARTSTRUCTURE[3] BINARY[4] 807 BODYPARTSTRUCTURE[4]) 808 S: * 2 CONVERTED (tag "b002") (BODYPARTSTRUCTURE[3] 809 (ERROR "Source text has non us-ascii" BADPARAMETERS 810 "text/html" "text/plain" ("charset" "us-ascii")) 811 BODYSTRUCTURE[4] ("TEXT" "PLAIN" (CHARSET US-ASCII) 812 NIL NIL "8bit" 4182 NIL NIL NIL) BINARY[4] {4182} 813 814 ) 815 S: b002 OK Some conversions failed 817 The client in general can tell from the BODYPARTSTRUCTURE response 818 whether or not its request was honored exactly, but may not know the 819 reasons why. 821 This document defines the following response code which can be 822 returned in the tagged NO response code: 824 TEMPFAIL - the transcoding request failed temporarily. It might 825 succeed later, so the client MAY retry. 827 MAXCONVERTMESSAGES - the server is unable or unwilling to 828 convert more than messages in any given CONVERT/UID CONVERT 829 request. 831 MAXCONVERTPARTS - the server is unable or unwilling to 832 convert more than body parts of a message at once in any 833 given CONVERT/UID CONVERT request. 835 The word ERROR is always followed by an informal human readable 836 descriptive text, which is followed by the convert-error-code. The 837 convert-error-code, MUST be one of the following: 839 TEMPFAIL mm - the transcoding request failed temporarily. It might 840 succeed later, so the client MAY retry. The client SHOULD wait for 841 at least mm minutes before retrying. 843 BADPARAMETERS from-concrete-mime-type to-mime-type "(" transcoding- 844 params ")" - 845 the listed parameters were not understood, not valid for the source/ 846 destination MIME type pair, had invalid values or could not be 847 honored for another reason noted in the human readable text that was 848 specified after the ERROR label. The transcoding-params can be 849 omitted, in which case it means that the conversion from the from- 850 concrete-mime-type to the to-mime-type is not possible. If the from- 851 concrete-mime-type is NIL, this means that the specified body part 852 doesn't exist. All unrecognised or irrelevent parameters MUST be 853 listed in the transcoding-params. It is not legal behaviour to 854 ignore irrelevent parameters. 856 Note that if the client requested the "default conversion" (see 857 Section 6), the to-mime-type contains the destination MIME type 858 chosen by the server. 860 MISSINGPARAMETERS from-concrete-mime-type to-mime-type "(" 861 transcoding-params ")" - 862 the listed parameters are required for conversion of the specified 863 source MIME type to the destination MIME type, but were not seen in 864 the request. Note that if the client requested the "default 865 conversion" (see Section 6), the to-mime-type contains the 866 destination MIME type chosen by the server. 868 Examples: 870 C: b002 CONVERT 2 ("APPLICATION/PDF") BINARY[3] 871 S: b002 NO [TEMPFAIL] All conversions failed 873 C: b003 CONVERT 2 ("TEXT/PLAIN") BINARY[3] 874 S: * 2 CONVERTED (tag "b003") (BINARY[3] 875 (ERROR "CHARSET must be specified for text conversions" 876 MISSINGPARAMETERS (CHARSET))) 877 S: b003 NO All conversions failed 879 C: b005 CONVERT 2 ("TEXT/PLAIN" (CHARSET "US-ASCII" 880 UNKNOWN-CHARACTER-REPLACEMENT "")) BINARY[3] 881 S: * 2 CONVERTED (tag "b005") (BINARY[3] 882 (ERROR "UNKNOWN-CHARACTER-REPLACEMENT limited to 4 883 bytes" BADPARAMETERS (UNKNOWN-CHARACTER-REPLACEMENT 884 ""))) 885 S: b005 NO All conversions failed 887 10. Formal Syntax 889 The following syntax specification uses the augmented Backus-Naur 890 Form (ABNF) notation as used in [ABNF], and incorporates by reference 891 the Core Rules defined in that document. 893 This syntax augments the grammar specified in [RFC3501] and 894 [RFC3516]. Non-terminals not defined in this document can be found 895 in [RFC3501], [RFC3516], [IMAPABNF], [MIME-MTSRP] and 896 [MEDIAFEAT-REG]. 898 command-select =/ convert 900 uid =/ "UID" SP convert 901 ; Unique identifiers used instead of message 902 ; sequence numbers 904 convert = "CONVERT" SP sequence-set SP convert-params SP 905 ( convert-att / 906 "(" convert-att *(SP convert-att) ")" ) 908 convert-att = "UID" / 909 "BODYPARTSTRUCTURE" section-convert / 910 "BINARY" section-convert [partial] / 911 "BINARY.SIZE" section-convert / 912 "BODY[HEADER]" / 913 "BODY[" section-part ".HEADER]" / 914 "BODY[" section-part ".MIME]" / 915 "AVAILABLECONVERSIONS" section-convert 916 ; is defined in [RFC3516] 917 ; is defined in [RFC3501]. 919 convert-params = "(" (quoted-to-mime-type / default-conversion) 920 [SP "(" transcoding-params ")"] ")" 922 quoted-to-mime-type = DQUOTE to-mime-type DQUOTE 924 transcoding-params = transcoding-param 925 *(SP transcoding-param) 927 transcoding-param-names = transcoding-param-name 928 *(SP transcoding-param-name) 930 transcoding-param = transcoding-param-name SP 931 transcoding-param-value 933 transcoding-param-name = astring 934 ; represented as a quoted, 935 ; literal or atom. Note that 936 ; allows for "%" which is 937 ; not allowed in atoms. Such values must be 938 ; represented as quoted or literal. 940 transcod-param-name-nq = Feature-tag 941 ; is defined in [MEDIAFEAT-REG]. 943 transcoding-param-value = astring 945 default-conversion = "NIL" 947 message-data =/ nz-number SP "CONVERTED" SP convert-correlator 948 SP convert-msg-attrs 950 convert-correlator = "(" "TAG" SP tag-string ")" 952 tag-string = string 953 ; tag of the command that caused 954 ; the CONVERTED response, sent as 955 ; a string. 957 convert-msg-attrs = "(" convert-msg-att *(SP convert-msg-att) ")" 958 ; "UID" MUST be the first data item, if present. 960 convert-msg-att = msg-att-semistat / msg-att-conv-static 962 msg-att-conv-static = "UID" SP uniqueid 963 ; MUST NOT change for a message 965 msg-att-semistat = 966 ( "BINARY" section-convert ["<" number ">"] SP 967 (nstring / literal8 / converterror-phrase) ) / 968 ( "BINARY.SIZE" section-convert SP 969 (number / converterror-phrase) ) / 970 ( "BODYPARTSTRUCTURE" section-convert SP 971 (body / converterror-phrase) ) / 972 ( "AVAILABLECONVERSIONS" section-convert SP 973 (mimetype-list / converterror-phrase) ) 974 ; MUST NOT change during an IMAP "session", 975 ; but not necessarily static in a long term. 977 section-convert = section-binary 978 ; is defined in [RFC3516]. 979 ; 980 ; Note that unlike [RFC3516], conversion 981 ; of a top level multipart/* is allowed. 983 resp-text-code =/ "TEMPFAIL" / 984 "MAXCONVERTMESSAGES" SP nz-number / 985 "MAXCONVERTPARTS" SP nz-number 986 ; is defined in [RFC3501] 988 mimetype-and-params = quoted-to-mime-type 989 [SP "(" transcoding-params ")"] 990 ; always includes a specific MIME type 992 mimetype-list = "(" "(" [quoted-to-mime-type 993 *(SP quoted-to-mime-type)] ")" ")" 994 ; Unordered list of MIME types. It can be empty. 995 ; 996 ; Two levels of parenthesis is needed to distinguish this 997 ; data from . 999 converterror-phrase = "(" "ERROR" SP 1000 convert-err-descript SP convert-error-code ")" 1002 convert-error-code = "TEMPFAIL" [SP nz-number] 1003 / bad-params 1004 / missing-params 1006 convert-err-descript = string 1007 ; Human readable text explaining the conversion error. 1008 ; The default charset is US-ASCII, unless 1009 ; the LANGUAGE command [IMAP-I18N] is called, when 1010 ; the charset changes to UTF-8. 1012 quoted-from-mime-type = DQUOTE from-concrete-mime-type DQUOTE 1014 bad-params = "BADPARAMETERS" 1015 1*(SP (quoted-from-mime-type / nil) 1016 SP mimetype-and-params) 1017 ; nil is only returned when the body part doesn't exist 1019 missing-params = "MISSINGPARAMETERS" 1020 1*(SP quoted-from-mime-type SP 1021 mimetype-and-missing-params) 1023 mimetype-and-missing-params = quoted-to-mime-type 1024 "(" transcoding-param-names ")" 1025 ; always includes a specific MIME type 1027 concrete-mime-type = type-name "/" subtype-name 1028 ; i.e. "type/subtype". 1029 ; type-name and subtype-name 1030 ; are defined in [MIME-MTSRP]. 1032 from-concrete-mime-type = concrete-mime-type 1034 to-mime-type = concrete-mime-type 1036 command-auth =/ conversions-cmd 1038 conversions-cmd = "CONVERSIONS" SP from-mime-type-req SP 1039 to-mime-type-req 1041 from-mime-type-req = astring 1042 ; "mime-type-req" represented as IMAP , 1043 ; or 1045 to-mime-type-req = astring 1046 ; represented as IMAP , 1047 ; or . 1048 ; Note that allows for "*", 1049 ; which is not allowed in . Such values must 1050 ; be represented as or . 1052 any-mime-type = "*" 1054 mime-type-req = any-mime-type / 1055 (type-name "/" any-mime-type) / 1056 concrete-mime-type 1057 ; '*', 'type/*' or 'type/subtype'. 1058 ; type-name is defined in [MIME-MTSRP]. 1060 response-payload =/ conversion-data 1062 conversion-data = "CONVERSION" SP quoted-from-mime-type SP 1063 quoted-to-mime-type 1064 [SP "(" transcoding-param-name 1065 *(SP transcoding-param-name) ")"] 1067 11. Manageability Considerations 1069 The monitoring of CONVERT operation is similar to monitoring of the 1070 IMAP FETCH operation. 1072 At the time of writing this document there is no standard IMAP MIB 1073 defined. Similarly a standard MIB for monitoring CONVERT operations 1074 and their failures does not exist. However the authors believe that 1075 in the absence of such MIB, server implementations SHOULD provide 1076 operators with tools to report the following information: 1078 o which conversions (source and target MIME types and possibly 1079 conversion parameters used) are invoked more frequently and how 1080 long they take 1082 o information about conversion errors and which error condition 1083 caused them (see Section 9 1085 o information about users which invoke conversion operation. 1087 This information can help operators to detect client abuse of this 1088 extension and scalability issues that might arise from its use. 1090 Standardizing these tools may be the subject of future work. 1092 12. IANA Considerations 1094 IMAP4 capabilities are registered by publishing a standards track or 1095 IESG approved experimental RFC. The registry is currently located at 1096 . This document 1097 defines the CONVERT IMAP capability. IANA is requested to add this 1098 extension to the IANA IMAP Capability registry. 1100 IANA is also requested to perform registrations as defined in 1101 subsections of this section. 1103 12.1. Registration of unknown-character-replacement media type 1104 parameter 1106 IANA is requested to add the following registration to the registry 1107 established by RFC 2506. 1109 To: "Media feature tags mailing list" 1110 1111 Subject: Registration of media feature tag 1112 unknown-character-replacement 1114 Media feature tag name: 1115 unknown-character-replacement 1117 ASN.1 identifier associated with feature tag: 1118 New assignment by IANA 1120 Summary of the media feature indicated by this feature tag: 1121 Allows servers that can perform charset conversion for text/plain 1122 text/html, text/css, text/csv, text/enriched and text/xml MIME 1123 types to replace characters not supported by the target charset 1124 with a fixed string, such as "?". 1126 This feature tag is also applicable to other conversions 1127 to text, e.g. conversion of images using OCR. 1129 Values appropriate for use with this feature tag: 1130 The feature tag contains a UTF-8 string used to replace any 1131 characters from the source media type that can't be 1132 represented in the target media type. 1134 The feature tag is intended primarily for use in the following 1135 applications, protocols, services, or negotiation mechanisms: 1136 IMAP CONVERT extension [RFC XXXX] 1138 Examples of typical use: 1139 C: b001 CONVERT 2 BINARY[3 ("text/plain" ("charset" 1140 "us-ascii" "unknown-character-replacement" "?"))] 1142 Related standards or documents: 1143 [RFC XXXX] 1144 [CHARSET-REG] 1146 Considerations particular to use in individual applications, 1147 protocols, services, or negotiation mechanisms: 1148 None 1150 Interoperability considerations: None 1152 Security considerations: None 1154 Additional information: 1155 This media feature only make sense for MIME types that 1156 also support the "charset" media type parameter 1157 [CHARSET-REG]. 1159 Name(s) & email address(es) of person(s) to contact for further 1160 information: 1161 Alexey Melnikov 1163 Intended usage: 1164 COMMON 1166 Author/Change controller: 1167 IETF 1169 Requested IANA publication delay: 1170 None 1172 Other information: 1173 None 1175 Note to IANA/RFC-Editor: please replace [RFC XXXX] in the template 1176 above with the number of this RFC. 1178 13. Security Considerations 1180 It is to be noted that some conversions may present security threats 1181 (e.g. converting a document to a damaging executable, exploiting a 1182 buffer overflow in a media codec/parser, or a denial of service 1183 attack against a client or a server such as requesting an image be 1184 scaled to extremely large dimensions). Server SHOULD refuse to 1185 execute CPU expensive conversions. Servers should avoid dangerous 1186 conversions if possible. Whenever possible, servers should perform 1187 verification of the converted attachments before returning them to 1188 the client. Clients should be careful when requesting conversions or 1189 processing transformed attachments. Clients SHOULD use mutual SASL 1190 authentication and SASL/TLS integrity layer, to make sure they are 1191 talking to trusted servers. 1193 When the client requests a server-side conversion of a signed body 1194 part (e.g. a part inside multipart/signed), there is no way for the 1195 client to verify that the converted content is authentic. A client 1196 not trusting the server to perform conversion of a signed body part 1197 can download the signed object, verify the signature and perform the 1198 conversion itself. 1200 A client can create a carefully crafted bad message with the APPEND 1201 command followed by the CONVERT command to attack the server. If the 1202 server's conversion function or library has a security problem (such 1203 as vulnerability to a buffer overflow), this could result in 1204 privilege escalation or Denial of Service. In order to mitigate such 1205 attacks, servers SHOULD log the client authentication identity on 1206 APPEND and/or CONVERT operations in order to facilitate tracking of 1207 abusive clients. Also server implementors SHOULD isolate the 1208 conversion function or library from the priviledged mailstore, 1209 perhaps by running it within a distinct process. 1211 Deployments in which the actual transcoding is done outside the IMAP 1212 server in a separate server are recommended to keep the servers in 1213 the same trusted domain (e.g. subnet). 1215 14. Acknowledgments 1217 Stephane H. Maes and Ray Cromwell from Oracle edited several earlier 1218 versions of this document. Their contribution is gratefully 1219 acknowledged. 1221 Authors want to specifically acknowledge the excellent criticism and 1222 comments received from Randall Gellens (Qualcomm), Arnt Gulbrandsen 1223 (Oryx), Zoltan Ordogh (Nokia), Ben Last (Emccsoft), Dan Karp 1224 (Zimbra), Pete Resnick (Qualcomm), Chris Newman (Sun), Ted Hardie 1225 (Qualcomm), Larry Masinter (Adobe), Philip Guenther (Sendmail), Greg 1226 Vaudreuil (Alcatel-Lucent), David Harrington (Comcast), Dave Cridland 1227 (Isode), Pasi Eronen (Nokia), Magnus Westerlund (Ericsson) and Jari 1228 Arkko (Ericsson) which improved the quality of this specification 1229 considerably. 1231 Authors would also like to specially thank Dave Cridland for the 1232 MEDIACAPS command proposal and Dan Karp for the CONVERSIONS command 1233 proposal. 1235 Authors also want to thank all who have contributed key insight and 1236 extensively reviewed and discussed the concepts of CONVERT and its 1237 predecessor P-IMAP. In particular, this includes the authors of the 1238 LCONVERT draft: Rafiul Ahad (Oracle Corporation), Eugene Chiu (Oracle 1239 Corporation), Ray Cromwell (Oracle Corporation), Jia-der Day (Oracle 1240 Corporation), Vi Ha (Oracle Corporation), Wook- Hyun Jeong (Samsung 1241 Electronics Co. LTF), Chang Kuang (Oracle Corporation), Rodrigo Lima 1242 (Oracle Corporation), Stephane H. Maes (Oracle Corporation), Gustaf 1243 Rosell (Sony Ericsson), Jean Sini (Symbol Technologies), Sung-Mu Son 1244 (LG Electronics), Fan Xiaohui (CHINA MOBILE COMMUNICATIONS 1245 CORPORATION (CMCC)), Zhao Lijun (CHINA MOBILE COMMUNICATIONS 1246 CORPORATION (CMCC)). 1248 15. References 1250 15.1. Normative References 1252 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 1253 Syntax Specifications: ABNF", RFC 5234, January 2008. 1255 [CHARSET-REG] 1256 Hoffman, P., "Registration of Charset and Languages Media 1257 Features Tags", RFC 2987, November 2000. 1259 [IMAPABNF] 1260 Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 1261 ABNF", RFC 4466, April 2006. 1263 [MEDIAFEAT-REG] 1264 Holtman, K., Mutz, A., and T. Hardie, "Media Feature Tag 1265 Registration Procedure", BCP 31, RFC 2506, March 1999. 1267 [MIME-MTSRP] 1268 Freed, N. and J. Klensin, "Media Type Specifications and 1269 Registration Procedures", BCP 13, RFC 4288, December 2005. 1271 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 1272 Part Three: Message Header Extensions for Non-ASCII Text", 1273 RFC 2047, November 1996. 1275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1276 Requirement Levels", BCP 14, RFC 2119, March 1997. 1278 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 1279 Word Extensions: 1280 Character Sets, Languages, and Continuations", RFC 2231, 1281 November 1997. 1283 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 1284 4rev1", RFC 3501, March 2003. 1286 [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, 1287 April 2003. 1289 15.2. Informative References 1291 [DISPLAY-FEATURES] 1292 Masinter, L., Wing, D., Mutz, A., and K. Holtman, "Media 1293 Features for Display, Print, and Fax", RFC 2534, 1294 March 1999. 1296 [IMAP-I18N] 1297 Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet 1298 Message Access Protocol Internationalization", 1299 draft-ietf-imapext-i18n-15 (work in progress), 1300 February 2008. 1302 [OMA-ME-RD] 1303 OMA, "Open Mobile Alliance Mobile Email Requirement 1304 Document". 1306 [OMA-STI] OMA, "Open Mobile Alliance, Standard Transcoding Interface 1307 Specification". 1309 [lemonade-streaming] 1310 Cook, N., "Streaming Internet Messaging Attachments", 1311 draft-ietf-lemonade-streaming-04 (work in progress), 1312 February 2008. 1314 Authors' Addresses 1316 Alexey Melnikov (editor) 1317 Isode Ltd 1318 5 Castle Business Village 1319 36 Station Road 1320 Hampton, Middlesex TW12 2BX 1321 UK 1323 Email: Alexey.Melnikov@isode.com 1325 Peter Coates (editor) 1326 Sun Microsystems 1327 185 Falcon Drive 1328 Whitehorse, YT Y1A 6T2 1329 Canada 1331 Email: peter.coates@Sun.COM 1333 Full Copyright Statement 1335 Copyright (C) The IETF Trust (2008). 1337 This document is subject to the rights, licenses and restrictions 1338 contained in BCP 78, and except as set forth therein, the authors 1339 retain all their rights. 1341 This document and the information contained herein are provided on an 1342 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1343 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1344 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1345 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1346 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1347 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1349 Intellectual Property 1351 The IETF takes no position regarding the validity or scope of any 1352 Intellectual Property Rights or other rights that might be claimed to 1353 pertain to the implementation or use of the technology described in 1354 this document or the extent to which any license under such rights 1355 might or might not be available; nor does it represent that it has 1356 made any independent effort to identify any such rights. Information 1357 on the procedures with respect to rights in RFC documents can be 1358 found in BCP 78 and BCP 79. 1360 Copies of IPR disclosures made to the IETF Secretariat and any 1361 assurances of licenses to be made available, or the result of an 1362 attempt made to obtain a general license or permission for the use of 1363 such proprietary rights by implementers or users of this 1364 specification can be obtained from the IETF on-line IPR repository at 1365 http://www.ietf.org/ipr. 1367 The IETF invites any interested party to bring to its attention any 1368 copyrights, patents or patent applications, or other proprietary 1369 rights that may cover technology that may be required to implement 1370 this standard. Please address the information to the IETF at 1371 ietf-ipr@ietf.org.