idnits 2.17.1 draft-ietf-sieve-convert-01.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...' == Line 210 has weird spacing: '...will be run b...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 8, 2011) is 4676 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 (~~), 4 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 9, 2012 B. Leiba 6 K. Li 7 Huawei Technologies 8 July 8, 2011 10 Sieve Extension for converting messages before delivery 11 draft-ietf-sieve-convert-01 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 9, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 7 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 All conversions are performed before any disposition-type actions. 134 Therefore, the sequence "convert, fileinto, convert" is the same as 135 "convert, convert, fileinto": in both cases, all conversions are done 136 before the message is filed. 138 Repeating for emphasis: note that disposition-type actions, such as 139 "fileinto" and "redirect", will work on the converted message, filing 140 or redirecting it after all conversions are done. 142 See Section 3.4 for an example of how this might be tricky. 144 3. Examples 146 3.1. Example 1 148 In the following example, all "image/tiff" body parts of the message 149 are converted to "image/jpeg" with image resolution of 320x240 150 pixels. The message is then subject to the implicit keep. 152 require ["convert"]; 153 convert "image/tiff" "image/jpeg" "pix-x" "320" "pix-y" "240"; 155 3.2. Example 2 157 In the following example, all "image/tiff" body parts of the message 158 are converted to "image/jpeg", as in Example 1. Those messages are 159 then filed into a mailbox called "INBOX.pics". Other messages (those 160 with no image/tiff body parts) are subject to the implicit keep. 162 require ["mime", "fileinto", "convert"]; 163 if header :mime :anychild :contenttype 164 "Content-Type" "image/tiff" 165 { 166 convert "image/tiff" "image/jpeg" "pix-x" "320" "pix-y" "240"; 167 fileinto "INBOX.pics"; 169 } 171 3.3. Example 3 173 In the following example, only "image/tiff" body parts with a 174 Content-Disposition of "inline" are converted. Matching parts that 175 are larger than 500 kilobytes are converted using an image resolution 176 of 640x480 pixels, and those smaller are converted to 320x240 pixels. 177 The message disposition is not changed, so the implicit keep will be 178 in effect unless something else in the script changes that. 180 require ["mime", "foreverypart", "fileinto", "convert"]; 181 foreverypart 182 { 183 if header :mime :param "filename" :contains 184 "Content-Disposition" "inline" 185 { 186 if size :over "500K" 187 { 188 convert "image/tiff" "image/jpeg" 189 "pix-x" "640" "pix-y" "480"; 190 } else { 191 convert "image/tiff" "image/jpeg" 192 "pix-x" "320" "pix-y" "240"; 193 } 194 } 195 } 197 [... script continues ...] 199 3.4. Example 4 201 The following example shows some tricky interactions between multiple 202 "convert" actions and other disposition-type actions. 204 require ["mime", "foreverypart", 205 "fileinto", "redirect" "convert"]; 207 # The first "if" block will convert all image/tiff body parts 208 # to 640x480 jpegs, and will register the message to be filed 209 # into the "INBOX.pics" mailbox. But the rest of the script 210 # will be run before the "fileinto" is done. 211 if header :mime :anychild :contenttype 212 "Content-Type" "image/tiff" 213 { 214 convert "image/tiff" "image/jpeg" "pix-x" "640" "pix-y" "480"; 215 fileinto "INBOX.pics"; 216 } 218 # The second block, the "foreverypart" loop, will convert all 219 # inline jpegs to 320x240 resolution... including any tiff body 220 # parts that had been converted in the first block, above. 221 # Therefore, any tiff that had been converted to a 640x480 jpeg 222 # will be re-converted to a 320x240 jpeg here if its 223 # Content-Disposition is specified as "inline". 224 foreverypart 225 { 226 if header :mime :param "filename" :contains 227 "Content-Disposition" "inline" 228 { 229 convert "image/jpeg" "image/jpeg" 230 "pix-x" "320" "pix-y" "240"; 231 } 232 } 234 # The third block will redirect the message to Joe if it 235 # contains any tiff body parts. But because of the earlier 236 # conversion (in the first block), there will never be any 237 # tiff body parts, so the message will never be redirected. 238 if header :mime :anychild :contenttype 239 "Content-Type" "image/tiff" 240 { 241 redirect "joe@example.com"; 242 } 244 # Now, at the end of the script processing, after all 245 # conversions, the message will be filed into "INBOX.pics" 246 # if the first "if" block was taken, or will be implicitly 247 # kept if not. 249 4. Security Considerations 251 Security considerations given in IMAP CONVERT [RFC5259] and Sieve 252 [RFC5228] are relevant to this document. There are no additional 253 security considerations resulting from combining the two. 255 5. IANA Considerations 257 IANA is requested to add the following registration to the Sieve 258 Extensions registry, as defined in RFC 5228: 260 Capability name: convert 261 Description: adds a new tag to the fileinto action that enables 262 Sieve script to perform a conversion on the message being 263 delivered. 264 RFC number: this RFC 265 Contact address: The Sieve discussion list 267 6. Acknowledgements 269 The authors also want to thank all who have contributed key insight 270 and extensively reviewed and discussed the concepts of CONVERT. 272 7. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, March 1997. 277 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 278 Language", RFC 5228, January 2008. 280 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 281 Specifications: ABNF", STD 68, RFC 5234, January 2008. 283 [RFC5259] Melnikov, A. and P. Coates, "Internet Message Access 284 Protocol - CONVERT Extension", RFC 5259, July 2008. 286 [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Part 287 Tests, Iteration, Extraction, Replacement, and Enclosure", 288 RFC 5703, October 2009. 290 Authors' Addresses 292 Alexey Melnikov 293 Isode Limited 294 5 Castle Business Village 295 36 Station Road 296 Hampton, Middlesex TW12 2BX 297 UK 299 Email: Alexey.Melnikov@isode.com 300 URI: http://www.melnikov.ca/ 302 Qian Sun 303 Huawei Technologies 304 Bantian Longgang 305 Shenzhen, Guandong 518129 306 P.R China 308 Phone: +86 755 28780808 309 Email: sunqian@huawei.com 311 Barry Leiba 312 Huawei Technologies 314 Phone: +1 646 827 0648 315 Email: barryleiba@computer.org 316 URI: http://internetmessagingtechnology.org/ 318 Kepeng Li 319 Huawei Technologies 320 Huawei Base, Bantian, Longgang District 321 Shenzhen, Guangdong 518129 322 P. R. China 324 Phone: +86-755-28974289 325 Email: likepeng@huawei.com