idnits 2.17.1 draft-melnikov-sieve-imapflags-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 10 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The abstract seems to contain references ([IMAP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 101: '... SHOULD ignore this extension....' RFC 2119 keyword, line 119: '... fileinto. It MUST be ignored if ...' RFC 2119 keyword, line 131: '... Server MUST ignore all flags that i...' RFC 2119 keyword, line 192: '... RECOMMENDED that IMAP \Flagged ...' RFC 2119 keyword, line 196: '... action. Unmark SHOULD at least clear...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 28 has weird spacing: '...listing conta...' == Line 29 has weird spacing: '...ctories on ...' == Line 34 has weird spacing: '...ting or using...' == Line 35 has weird spacing: '...rotocol are S...' == Line 44 has weird spacing: '...ussions have...' == (35 more instances...) -- 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 (19 June 1999) is 9079 days in the past. Is this intentional? 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 section? 'IMAP' on line 281 looks like a reference -- Missing reference section? 'SIEVE' on line 272 looks like a reference -- Missing reference section? 'KEYWORDS' on line 278 looks like a reference -- Missing reference section? 'ABNF' on line 275 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group 2 Internet Draft: Sieve -- IMAP flag Extension A. Melnikov 3 Document: draft-melnikov-sieve-imapflags-01.txt Messaging Direct, Inc. 4 Expires: 19 December 1999 19 June 1999 6 Sieve -- IMAP flag Extension 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. Internet-Drafts are 12 working documents of the Internet Engineering Task Force (IETF), its 13 areas, and its working groups. Note that other groups may also 14 distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other documents 18 at any time. It is inappropriate to use Internet- Drafts as 19 reference material or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet-Drafts 29 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 30 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 31 Coast), or ftp.isi.edu (US West Coast). 33 The protocol discussed in this document is experimental and subject 34 to change. Persons planning on either implementing or using this 35 protocol are STRONGLY URGED to get in touch with the author before 36 embarking on such a project. 38 Copyright 40 Copyright (C) The Internet Society 1998. All Rights Reserved. 42 Abstract 44 Recent discussions have shown that it was desirable to set 45 different [IMAP] flags on message delivery. This can be done, for 46 example, by SIEVE interpreter that works as a part of Mail Delivery 47 Agent. 49 This document describes an extension to the Sieve mail filtering 50 language for setting [IMAP] flags. 52 0. Meta-information on this draft 54 This information is intended to facilitate discussion. It will be 55 removed when this document leaves the Internet-Draft stage. 57 0.1. Discussion 59 This draft is intended to be compared with the Sieve mail filtering 60 language, an Internet-Draft being discussed on the MTA Filters 61 mailing list at . Subscription requests 62 can be sent to (send an email 63 message with the word "subscribe" in the body). More information on 64 the mailing list along with a WWW archive of back messages is 65 available at . 67 0.2. Changes from the version submitted to the SIEVE mailing list 69 1. Added addflag and removeflag actions 71 2. Changed the semantics of setflag (setflag is not additive any more) 73 3. Corrected section "Interaction with Other Sieve Actions". 74 Removed incorrect reference to the forward action as to an 75 action that prohibits setflag. 77 4. Added paragraph about the mutual order of fileinto/keep and 78 setflag/addflag/removeflag actions. 80 0.3. Changes from the version 00 82 1. Corrected Capability Identifier section (Section 2) 84 2. Corrected "Interaction with Other Sieve Actions" section (Section 4) 86 3. Examples were updated to be compatible with Sieve-07 draft 88 4. Added "mark" and "unmark" actions 90 1. Introduction 92 This is an extension to the Sieve language defined by [SIEVE] for 93 setting [IMAP] flags. It defines several new actions "setflag", 94 "addflag" and "removeflag". 96 This document doesn't dictate how SIEVE interpreter can set [IMAP] 97 flags. In particular, SIEVE interpreter may work as an IMAP client, 98 or may have direct access to the mailstore. 100 SIEVE interpreters, that doesn't support integration with IMAP 101 SHOULD ignore this extension. 103 Conventions for notations are as in [SIEVE] section 1.1, including 104 use of [KEYWORDS]. 106 2. Capability Identifier 108 The capability string associated with extension defined in this document 109 is "imapflags". 111 3. Actions 113 3.1. Setflag Action 115 Syntax: setflag 117 Setflag is used for setting [IMAP] flags. Setflag replaces any 118 previously set flags. It should be used together with keep or 119 fileinto. It MUST be ignored if mailstore doesn't support the 120 storing of any flags. 122 Flags can be set only for message that is currently processed by 123 SIEVE. When called with keep, setflag sets flags in user's main 124 mailbox. When called with fileinto, setflag sets flags in the 125 mailbox, indicated by the parameter. 127 The order of setflag/fileinto or setflag/keep is important in the 128 script. Any setflag action applies only to subsequent fileinto/keep 129 actions. 131 Server MUST ignore all flags that it can't store permanently. This 132 mean, in particular, that if user's main mailbox can't store any 133 flags, then the following SIEVE script produces no actions 135 Example: if size over 500K setflag "\Deleted"; 137 More substantial example is: 139 Example: 140 if header :contains "from" "boss@frobnitzm.edu" { 141 setflag "\Flagged"; 142 fileinto "INBOX.From Boss"; 143 } 145 3.2. Addflag action 147 Syntax: addflag 149 Addflag is used for setting [IMAP] flags. However unlike setflag it 150 doesn't replace any previously set flags. This means that multiple 151 occurrences of addflag are treated additive. 153 For example, the following two actions 155 addflag "\Deleted"; 156 addflag "\Answered"; 158 produce the same result as a single action 160 addflag ["\Deleted", "\Answered"]; 162 In all other respects addflag action behave the same way as 163 setflag. 165 3.3. Removeflag Action 167 Syntax: removeflag 169 Removeflag is used for setting [IMAP] flags. Removeflag clears 170 flags previously set by setflag/addflag. Calling removeflag with a 171 flag that wasn't set before is not an error and is ignored. 173 In all other respects removeflag action behave the same way as 174 setflag. 176 Example: 177 if header :contains "Disposition-Notification-To" "mel@example.com" { 178 addflag "$MDNRequired"; 179 } 180 if header :contains "from" "imap@cac.washington.edu" { 181 removeflag "$MDNRequired"; 182 fileinto "INBOX.imap-list"; 183 } 185 3.4. Mark and Unmark Actions 187 Syntax: mark 189 Syntax: unmark 190 Mark action allows to mark message as urgent. Implementers are free 191 to choose any flag or any combination of flags, however it is 192 RECOMMENDED that IMAP \Flagged flag is used. Mark action is 193 sematically equivalent to 'addflag "\Flagged"'. 195 Unmark action allows to reset urgent flag previously set by Mark 196 action. Unmark SHOULD at least clear IMAP \Flagged flag. Unmark MAY 197 clear other flags as well. Unmark action is sematically equivalent 198 to 'removeflag "\Flagged"'. 200 4. Interaction with Other Sieve Actions 202 Sieve actions sometimes prohibit each other in order to make 203 filtering scripts less likely to cause serious problems. 205 It is strongly discouraged to use setflag/addflag/removeflag 206 actions together with reject, because this action doesn't allow keeping 207 received message. 209 SIEVE interpreter MUST ignore any of setflag/addflag/removeflag commands, 210 when they are used with reject. SIEVE interpreter MUST ignore these commands 211 when no keep (implicit or explicit) or fileinto actions will be taken. 213 SIEVE verifier SHOULD reject script, which contains setflag/addflag/removeflag 214 together with reject. 216 5. Other Considerations 218 This extension intentionally doesn't allow setting [IMAP] flags on 219 arbitrary message in IMAP message store. 221 6. Security Considerations 223 Security considerations are discussed in the [IMAP] and [SIEVE]. 224 It is belived that this extension doesn't introduce any 225 additional security concerns. 227 7. Formal Grammar 229 The grammar used in this section is the same as the ABNF described in 230 [ABNF]. 232 action =/ setflag / addflag / removeflag / mark / unmark 234 setflag = "setflag" WSP string-list 235 ;; a list of [IMAP] flags 237 addflag = "addflag" WSP string-list 238 ;; a list of [IMAP] flags 240 removeflag = "removeflag" WSP string-list 241 ;; a list of [IMAP] flags 243 mark = "mark" 245 unmark = "unmark" 247 8. Acknowledgments 249 This document has been revised in part based on comments and 250 discussions which took place on and off the SIEVE mailing list. 251 The help of those who took the time to review the draft and made 252 suggestions is appreciated, especially that of Tim Showalter, 253 Barry Leiba, and Randall Gellens. 255 9. Author's Address 257 Alexey Melnikov 258 Messaging Direct, Inc. 260 Home address : 261 121293, Russia, Moscow, 262 general Ermolov street, 6 - 90 264 Email: alexey.melnikov@messagingdirect.com 266 Fax (San Diego, CA) : 1 (619) 8393837 268 Appendices 270 Appendix A. References 272 [SIEVE] Showalter, T., "Sieve: A Mail Filtering Language", Carnegie 273 Mellon, Work in Progress. 275 [ABNF] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", 276 Internet Mail Consortium, RFC 2234, November, 1997. 278 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", Harvard University, RFC 2119, March 1997. 281 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", 282 University of Washington, RFC 2060, December 1996. 284 Appendix B. Full Copyright Statement 286 Copyright (C) The Internet Society 1999. All Rights Reserved. 288 This document and translations of it may be copied and furnished to 289 others, and derivative works that comment on or otherwise explain it 290 or assist in its implementation may be prepared, copied, published 291 and distributed, in whole or in part, without restriction of any 292 kind, provided that the above copyright notice and this paragraph 293 are included on all such copies and derivative works. However, this 294 document itself may not be modified in any way, such as by removing 295 the copyright notice or references to the Internet Society or other 296 Internet organizations, except as needed for the purpose of 297 developing Internet standards in which case the procedures for 298 copyrights defined in the Internet Standards process must be 299 followed, or as required to translate it into languages other than 300 English. 302 The limited permissions granted above are perpetual and will not be 303 revoked by the Internet Society or its successors or assigns. 305 This document and the information contained herein is provided on an 306 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 307 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 308 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 309 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 310 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.