idnits 2.17.1 draft-ietf-sieve-convert-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 and authors Copyright Line does not match the current year == Line 10 has weird spacing: '...ion for conve...' -- The document date (September 19, 2011) is 4574 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Sieve Working Group A. Melnikov 3 Internet-Draft Isode Limited 4 Intended status: Standards Track Q. Sun 5 Expires: March 22, 2012 B. Leiba 6 K. Li 7 Huawei Technologies 8 September 19, 2011 10 Sieve Extension for converting messages before delivery 11 draft-ietf-sieve-convert-03 13 Abstract 15 This document describes how IMAP CONVERT can be used within Sieve to 16 transform messages before final delivery. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 22, 2012. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1. Conventions Used in this Document . . . . . . . . . . . . . . 3 55 2. "convert" action . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Interaction with other tests and actions . . . . . . . . . . 4 57 2.2. "convert" as a test . . . . . . . . . . . . . . . . . . . . . 4 59 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 69 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 71 7. Normative References . . . . . . . . . . . . . . . . . . . . 8 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 75 1. Introduction 77 The IMAP CONVERT extension [RFC5259] adds an IMAP command for 78 performing client-controlled conversions on whole messages or their 79 body parts. This document defines a similar extension to the Sieve 80 mail filtering language [RFC5228], which reuses the conversion 81 parameters and framework established by IMAP CONVERT. 83 1.1. Conventions Used in this Document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 Conventions for notations are as in Sieve [RFC5228] section 1.1, 90 including the use of ABNF [RFC5234]. 92 2. "convert" action 94 Usage: convert 95 96 98 The "convert" action specifies that body parts with "quoted-from- 99 mime-type" MIME type be converted to "quoted-to-mime-type" MIME type 100 using conversion parameters specified in "transcoding-params". Each 101 conversion parameter value has the following syntax: "=", where and 103 are defined in CONVERT [RFC5259]. Messages 104 that don't have any body parts with the "quoted-from-mime-type" MIME 105 type are not affected by the conversion. 107 The "convert" action can be used with Sieve MIME Part Tests 108 [RFC5703], in the case that some, but not all of the body parts need 109 to be converted, or where different body parts might require 110 different conversions. When the "convert" action appears in a 111 "foreverypart" loop, it applies only to the body part being 112 processed, and not to any other body parts (see Section 3.2 for an 113 example). 115 When the "convert" action appears outside a "foreverypart" loop, the 116 conversion applies equally to all body parts -- that is, all body 117 parts that have the "quoted-from-mime-type" are converted, using the 118 same transcoding parameters. 120 If a "convert" action cannot be completed -- perhaps because the 121 conversion failed, or because the requested conversion is not 122 available -- the message MUST remain unchanged, and the script 123 processing continues. In particular, no error condition is raised, 124 and no partial conversions are allowed. 126 Implementations might defer any actual conversion until the the 127 results of the conversion are needed for script processing, to avoid 128 doing conversions unnecessarily. Consider the case wherein a 129 "convert" action is processed, but a "discard" action results without 130 the need to actually perform the conversion. 132 2.1. Interaction with other tests and actions 134 Whether the actual conversion has been done yet or not, a successful 135 "convert" action effectively changes the message, and all subsequent 136 actions, including any other "convert" actions, apply to the changed 137 message. The "convert" action does not affect the applicability of 138 other actions; any action that was applicable before the "convert" is 139 equally applicable to the changed message afterward. 141 When a disposition-type action, such as "fileinto" or "redirect", is 142 encountered, the state of the message with respect to conversions is 143 "locked in" for that disposition-type action. Whether the 144 implementation performs the action at that point or batches it for 145 later, it MUST perform the action on the message as it stood at the 146 time, and MUST NOT include subsequent conversions encountered later 147 in the script processing. Therefore, the sequence "convert, 148 fileinto, convert, fileinto" will store two different versions of the 149 message: the first "fileinto" uses only the first conversion, while 150 the second uses both. See Section 3.4 for an example of how this can 151 be used. 153 In addition, any tests done on the message and its parts will test 154 the message after prior conversions have been done. The fourth block 155 of Section 3.4 shows an example of this situation. 157 Convert actions are cumulative, and each conversion operates on the 158 message as it stands after all prior conversions. See the fourth 159 block of Section 3.4 for an example of how this might be tricky. 161 Because the implicit keep, if it is in effect, acts on the final 162 state of the message, all conversions are performed before any 163 implicit keep. 165 2.2. "convert" as a test 167 To simplify testing for supported and successful conversions, the 168 "convert" action can also be used as a test. As such, it will 169 attempt to perform the requested conversion(s), and will evaluate to 170 "false" if and only if at least one conversion failed. The failure 171 can be because a conversion was unsupported, or because the data 172 could not be converted (perhaps it had been corrupted in transit, or 173 mislabelled at its origin). 175 This creates a new time of Sieve action, a "testable action". The 176 usage as a test is exactly the same as for an action, and it doubles 177 as an action and a test of the action's result at the same time. See 178 Section 3.2 for an example of how this test can be used. 180 Note that defining this new testable action does not change the 181 definitions of any other actions -- it does not imply that other 182 actions can be used as tests. Future extensions might define other 183 testable actions, but those specifications would be responsible for 184 clearly specifying that. 186 3. Examples 188 3.1. Example 1 190 In the following example, all "image/tiff" body parts of the message 191 are converted to "image/jpeg" with image resolution of 320x240 192 pixels. The converted message is then subject to the implicit keep. 194 require ["convert"]; 195 convert "image/tiff" "image/jpeg" "pix-x" "320" "pix-y" "240"; 197 3.2. Example 2 199 In the following example, all "image/tiff" body parts of the message 200 are converted to "image/jpeg", as in Example 1. If the conversions 201 were successful, those messages are then filed into a mailbox called 202 "INBOX.pics". Other messages (those with no image/tiff body parts) 203 are subject to the implicit keep, and have not been converted. 205 require ["mime", "fileinto", "convert"]; 206 if header :mime :anychild :contenttype 207 "Content-Type" "image/tiff" 208 { 209 if (convert "image/tiff" "image/jpeg" 210 "pix-x" "320" "pix-y" "240") { 211 fileinto "INBOX.pics"; 212 } 213 } 215 3.3. Example 3 217 In the following example, only "image/tiff" body parts with a 218 Content-Disposition of "inline" are converted. Matching parts that 219 are larger than 500 kilobytes are converted using an image resolution 220 of 640x480 pixels, and those smaller are converted to 320x240 pixels. 221 The message disposition is not changed, so the implicit keep will be 222 in effect unless something else in the script changes that. 224 require ["mime", "foreverypart", "fileinto", "convert"]; 225 foreverypart 226 { 227 if header :mime :param "filename" :contains 228 "Content-Disposition" "inline" 229 { 230 if size :over "500K" 231 { 232 convert "image/tiff" "image/jpeg" 233 "pix-x" "640" "pix-y" "480"; 234 } else { 235 convert "image/tiff" "image/jpeg" 236 "pix-x" "320" "pix-y" "240"; 237 } 238 } 239 } 241 [... script continues ...] 243 3.4. Example 4 245 The following example shows some tricky interactions between multiple 246 "convert" actions and other disposition-type actions. 248 require ["mime", "foreverypart", 249 "fileinto", "redirect" "convert"]; 251 # The first "if" block will convert all image/tiff body parts 252 # to 640x480 jpegs, and will file the message 253 # into the "INBOX.pics" mailbox as converted at this point. 254 if header :mime :anychild :contenttype 255 "Content-Type" "image/tiff" 256 { 257 convert "image/tiff" "image/jpeg" "pix-x" "640" "pix-y" "480"; 258 fileinto "INBOX.pics"; 259 } 261 # The second block, the "foreverypart" loop, will convert all 262 # inline jpegs to 320x240 resolution... including any tiff body 263 # parts that had been converted in the first block, above. 264 # Therefore, any tiff that had been converted to a 640x480 jpeg 265 # will be re-converted to a 320x240 jpeg here if its 266 # Content-Disposition is specified as "inline". 267 foreverypart 268 { 269 if header :mime :param "filename" :contains 270 "Content-Disposition" "inline" 271 { 272 convert "image/jpeg" "image/jpeg" 273 "pix-x" "320" "pix-y" "240"; 274 } 275 } 277 # The third block will take any message that contains a header 278 # field called "Mobile-Link" and redirect it to the user's 279 # mobile address. The redirected message will include both 280 # conversions above, from block one and block two. 281 if exists "Mobile-Link" 282 { 283 redirect "joe@mobile.example.com"; 284 } 286 # The fourth block will file the message into "Tiff" if it 287 # contains any tiff body parts. But because of the earlier 288 # conversion (in the first block), there will never be any 289 # tiff body parts, so this "fileinto" will never happen. 290 if header :mime :anychild :contenttype 291 "Content-Type" "image/tiff" 292 { 293 fileinto "Tiff"; 294 } 296 # Now, at the end of the script processing, the Sieve 297 # processor will perform an implicit keep if none of 298 # the "fileinto" and "redirect" actions were taken. 299 # The kept message will include any conversions that 300 # were done (that is, any from the second block). 302 4. Security Considerations 304 Security considerations given in IMAP CONVERT [RFC5259] and Sieve 305 [RFC5228] are relevant to this document. There are no additional 306 security considerations resulting from combining the two. 308 5. IANA Considerations 310 IANA is requested to add the following registration to the Sieve 311 Extensions registry, as defined in RFC 5228: 313 Capability name: convert 314 Description: adds a new tag to the fileinto action that enables 315 Sieve script to perform a conversion on the message being 316 delivered. 317 RFC number: this RFC 318 Contact address: The Sieve discussion list 320 6. Acknowledgements 322 The authors also want to thank all who have contributed key insight 323 and extensively reviewed and discussed the concepts of CONVERT. 325 7. Normative References 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 331 Language", RFC 5228, January 2008. 333 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 334 Specifications: ABNF", STD 68, RFC 5234, January 2008. 336 [RFC5259] Melnikov, A. and P. Coates, "Internet Message Access 337 Protocol - CONVERT Extension", RFC 5259, July 2008. 339 [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 340 Tests, Iteration, Extraction, Replacement, and Enclosure", 341 RFC 5703, October 2009. 343 Authors' Addresses 345 Alexey Melnikov 346 Isode Limited 347 5 Castle Business Village 348 36 Station Road 349 Hampton, Middlesex TW12 2BX 350 UK 352 Email: Alexey.Melnikov@isode.com 353 URI: http://www.melnikov.ca/ 355 Qian Sun 356 Huawei Technologies 357 Bantian Longgang 358 Shenzhen, Guandong 518129 359 P.R China 361 Phone: +86 755 28780808 362 Email: sunqian@huawei.com 364 Barry Leiba 365 Huawei Technologies 367 Phone: +1 646 827 0648 368 Email: barryleiba@computer.org 369 URI: http://internetmessagingtechnology.org/ 371 Kepeng Li 372 Huawei Technologies 373 Huawei Base, Bantian, Longgang District 374 Shenzhen, Guangdong 518129 375 P. R. China 377 Phone: +86-755-28974289 378 Email: likepeng@huawei.com