idnits 2.17.1 draft-ietf-sieve-convert-02.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 (July 25, 2011) is 4652 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: January 26, 2012 B. Leiba 6 K. Li 7 Huawei Technologies 8 July 25, 2011 10 Sieve Extension for converting messages before delivery 11 draft-ietf-sieve-convert-02 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 January 26, 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 actions . . . . . . . . . . . . . . . 4 58 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 The IMAP CONVERT extension [RFC5259] adds an IMAP command for 77 performing client-controlled conversions on whole messages or their 78 body parts. This document defines a similar extension to the Sieve 79 mail filtering language [RFC5228], which reuses the conversion 80 parameters and framework established by IMAP CONVERT. 82 1.1. Conventions Used in this Document 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in RFC 2119 [RFC2119]. 88 Conventions for notations are as in Sieve [RFC5228] section 1.1, 89 including the use of ABNF [RFC5234]. 91 2. "convert" action 93 Usage: convert 94 95 97 The "convert" action specifies that body parts with "quoted-from- 98 mime-type" MIME type be converted to "quoted-to-mime-type" MIME type 99 using conversion parameters specified in "transcoding-params". Each 100 conversion parameter value has the following syntax: "=", where and 102 are defined in CONVERT [RFC5259]. Messages 103 that don't have any body parts with the "quoted-from-mime-type" MIME 104 type are not affected by the conversion. 106 The "convert" action can be used with Sieve MIME Part Tests 107 [RFC5703], in the case that some, but not all of the body parts need 108 to be converted, or where different body parts might require 109 different conversions. When the "convert" action appears in a 110 "foreverypart" loop, it applies only to the body part being 111 processed, and not to any other body parts (see Section 3.2 for an 112 example). 114 When the "convert" action appears outside a "foreverypart" loop, the 115 conversion applies equally to all body parts -- that is, all body 116 parts that have the "quoted-from-mime-type" are converted, using the 117 same transcoding parameters. 119 Implementations ought to defer any actual conversion until the final 120 resolution of other actions, to avoid doing conversions unnecessarily 121 in cases where the message is not retained (such as where the 122 resolution is "discard"). 124 2.1. Interaction with other actions 126 Whether the actual conversion has been done yet or not, a "convert" 127 action effectively changes the message, and all subsequent actions, 128 including any other "convert" actions, apply to the changed message. 129 The "convert" action does not affect the applicability of other 130 actions; any action that was applicable before the "convert" is 131 equally applicable to the changed message afterward. 133 When a disposition-type action, such as "fileinto" or "redirect", is 134 encountered, the state of the message with respect to conversions is 135 "locked in" for that disposition-type action. Whether the 136 implementation performs the action at that point or batches it for 137 later, it MUST perform the action on the message as it stood at the 138 time, and MUST NOT include subsequent conversions encountered later 139 in the script processing. Therefore, the sequence "convert, 140 fileinto, convert, fileinto" will store two different versions of the 141 message: the first "fileinto" uses only the first conversion, while 142 the second uses both. See Section 3.4 for an example of how this can 143 be used. 145 Convert actions are cumulative, and each conversion operates on the 146 message as it stands after all prior conversions. See the fourth 147 block of Section 3.4 for an example of how this might be tricky. 149 Because the implicit keep, if it is in effect, acts on the final 150 state of the message, all conversions are performed before any 151 implicit keep. 153 3. Examples 155 3.1. Example 1 157 In the following example, all "image/tiff" body parts of the message 158 are converted to "image/jpeg" with image resolution of 320x240 159 pixels. The converted message is then subject to the implicit keep. 161 require ["convert"]; 162 convert "image/tiff" "image/jpeg" "pix-x" "320" "pix-y" "240"; 164 3.2. Example 2 166 In the following example, all "image/tiff" body parts of the message 167 are converted to "image/jpeg", as in Example 1. Those messages are 168 then filed into a mailbox called "INBOX.pics". Other messages (those 169 with no image/tiff body parts) are subject to the implicit keep, and 170 have not been converted. 172 require ["mime", "fileinto", "convert"]; 173 if header :mime :anychild :contenttype 174 "Content-Type" "image/tiff" 175 { 176 convert "image/tiff" "image/jpeg" "pix-x" "320" "pix-y" "240"; 177 fileinto "INBOX.pics"; 178 } 180 3.3. Example 3 182 In the following example, only "image/tiff" body parts with a 183 Content-Disposition of "inline" are converted. Matching parts that 184 are larger than 500 kilobytes are converted using an image resolution 185 of 640x480 pixels, and those smaller are converted to 320x240 pixels. 186 The message disposition is not changed, so the implicit keep will be 187 in effect unless something else in the script changes that. 189 require ["mime", "foreverypart", "fileinto", "convert"]; 190 foreverypart 191 { 192 if header :mime :param "filename" :contains 193 "Content-Disposition" "inline" 194 { 195 if size :over "500K" 196 { 197 convert "image/tiff" "image/jpeg" 198 "pix-x" "640" "pix-y" "480"; 199 } else { 200 convert "image/tiff" "image/jpeg" 201 "pix-x" "320" "pix-y" "240"; 202 } 203 } 204 } 206 [... script continues ...] 208 3.4. Example 4 210 The following example shows some tricky interactions between multiple 211 "convert" actions and other disposition-type actions. 213 require ["mime", "foreverypart", 214 "fileinto", "redirect" "convert"]; 216 # The first "if" block will convert all image/tiff body parts 217 # to 640x480 jpegs, and will file the message 218 # into the "INBOX.pics" mailbox as converted at this point. 219 if header :mime :anychild :contenttype 220 "Content-Type" "image/tiff" 221 { 222 convert "image/tiff" "image/jpeg" "pix-x" "640" "pix-y" "480"; 223 fileinto "INBOX.pics"; 224 } 226 # The second block, the "foreverypart" loop, will convert all 227 # inline jpegs to 320x240 resolution... including any tiff body 228 # parts that had been converted in the first block, above. 229 # Therefore, any tiff that had been converted to a 640x480 jpeg 230 # will be re-converted to a 320x240 jpeg here if its 231 # Content-Disposition is specified as "inline". 232 foreverypart 233 { 234 if header :mime :param "filename" :contains 235 "Content-Disposition" "inline" 236 { 237 convert "image/jpeg" "image/jpeg" 238 "pix-x" "320" "pix-y" "240"; 239 } 240 } 242 # The third block will take any message that contains a header 243 # field called "Mobile-Link" and redirect it to the user's 244 # mobile address. The redirected message will include both 245 # conversions above, from block one and block two. 246 if exists "Mobile-Link" 247 { 248 redirect "joe@mobile.example.com"; 249 } 251 # The fourth block will file the message into "Tiff" if it 252 # contains any tiff body parts. But because of the earlier 253 # conversion (in the first block), there will never be any 254 # tiff body parts, so this "fileinto" will never happen. 255 if header :mime :anychild :contenttype 256 "Content-Type" "image/tiff" 257 { 258 fileinto "Tiff"; 259 } 261 # Now, at the end of the script processing, the Sieve 262 # processor will perform an implicit keep if none of 263 # the "fileinto" and "redirect" actions were taken. 264 # The kept message will include any conversions that 265 # were done (that is, any from the second block). 267 4. Security Considerations 269 Security considerations given in IMAP CONVERT [RFC5259] and Sieve 270 [RFC5228] are relevant to this document. There are no additional 271 security considerations resulting from combining the two. 273 5. IANA Considerations 275 IANA is requested to add the following registration to the Sieve 276 Extensions registry, as defined in RFC 5228: 278 Capability name: convert 279 Description: adds a new tag to the fileinto action that enables 280 Sieve script to perform a conversion on the message being 281 delivered. 282 RFC number: this RFC 283 Contact address: The Sieve discussion list 285 6. Acknowledgements 287 The authors also want to thank all who have contributed key insight 288 and extensively reviewed and discussed the concepts of CONVERT. 290 7. Normative References 292 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 293 Requirement Levels", BCP 14, RFC 2119, March 1997. 295 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 296 Language", RFC 5228, January 2008. 298 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 299 Specifications: ABNF", STD 68, RFC 5234, January 2008. 301 [RFC5259] Melnikov, A. and P. Coates, "Internet Message Access 302 Protocol - CONVERT Extension", RFC 5259, July 2008. 304 [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 305 Tests, Iteration, Extraction, Replacement, and Enclosure", 306 RFC 5703, October 2009. 308 Authors' Addresses 310 Alexey Melnikov 311 Isode Limited 312 5 Castle Business Village 313 36 Station Road 314 Hampton, Middlesex TW12 2BX 315 UK 317 Email: Alexey.Melnikov@isode.com 318 URI: http://www.melnikov.ca/ 320 Qian Sun 321 Huawei Technologies 322 Bantian Longgang 323 Shenzhen, Guandong 518129 324 P.R China 326 Phone: +86 755 28780808 327 Email: sunqian@huawei.com 329 Barry Leiba 330 Huawei Technologies 332 Phone: +1 646 827 0648 333 Email: barryleiba@computer.org 334 URI: http://internetmessagingtechnology.org/ 336 Kepeng Li 337 Huawei Technologies 338 Huawei Base, Bantian, Longgang District 339 Shenzhen, Guangdong 518129 340 P. R. China 342 Phone: +86-755-28974289 343 Email: likepeng@huawei.com