idnits 2.17.1 draft-freed-sieve-in-xml-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 760 has weird spacing: '...herwise messa...' == Line 766 has weird spacing: '...en file it in...' == Line 790 has weird spacing: '...herwise messa...' == Line 796 has weird spacing: '...en file it in...' == Line 819 has weird spacing: '...herwise messa...' == (1 more instance...) -- 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 (March 9, 2009) is 5527 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'OASISRNC' Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group N. Freed 3 Internet-Draft S. Vedam 4 Expires: September 10, 2009 Sun Microsystems 5 March 9, 2009 7 Sieve Email Filtering: Sieves and display directives in XML 8 draft-freed-sieve-in-xml-03 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on September 10, 2009. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 This document describes a way to represent Sieve email filtering 47 language scripts in XML. Representing sieves in XML is intended not 48 as an alternate storage format for Sieve but rather as a means to 49 facilitate manipulation of scripts using XML tools. 51 The XML representation also defines additional elements that have no 52 counterparts in the regular Sieve language. These elements are 53 intended for use by graphical user interfaces and provide facilities 54 for labeling or grouping sections of a script so they can be 55 displayed more conveniently. These elements are represented as 56 specially structured comments in regular Sieve format. 58 Change History (to be removed prior to publication as an RFC 60 Changed representation of comments in XML to use a comment element. 62 Update references. 64 Added an IANA registration of a URN for the Sieve namespace. 66 Updated XML Schema to allow largely unrestricted use of material in 67 other namespaces. 69 Add compact Relax NG schema. 71 Updated example stylesheet to handle material in other namespaces. 73 Corrected stylesheet handling of elements. 75 Added a section defining the structured comment convention. 77 Moved the examples section to an appendix. 79 Added text to clarify that the examples in the various appendices are 80 in fact code components and may therefore be reused. 82 Added a section on validation requirements. 84 Clarified various editor requirements and trust issues, restricted 85 the use of "*/" in non-Sieve XML content. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 90 2. Conventions used in this document . . . . . . . . . . . . . . 5 91 3. Grammatical structure of Sieve . . . . . . . . . . . . . . . . 5 92 4. XML Representation of Sieve . . . . . . . . . . . . . . . . . 6 93 4.1. XML Display Directives . . . . . . . . . . . . . . . . . . 8 94 4.2. Structured Comments . . . . . . . . . . . . . . . . . . . 10 95 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 10 96 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 97 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 98 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 99 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 100 7.2. Informative References . . . . . . . . . . . . . . . . . . 12 101 Appendix A. Extended Example . . . . . . . . . . . . . . . . . . 13 102 Appendix B. XML Schema for Sieves in XML . . . . . . . . . . . . 20 103 Appendix C. Relax NG Schema for Sieves in XML . . . . . . . . . . 23 104 Appendix D. Stylesheet for conversion from XML . . . . . . . . . 24 105 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 30 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 108 1. Introduction 110 Sieve [RFC5228] is a language for filtering email messages at or 111 around the time of final delivery. It is designed to be 112 implementable on either a mail client or mail server. It is meant to 113 be extensible, simple, and independent of access protocol, mail 114 architecture, and operating system and it is intended to be 115 manipulated by a variety of different user interfaces. 117 Some user interface environments have extensive existing facilities 118 for manipulating material represented in XML. While adding support 119 for alternate data syntaxes may be possible in most if not all of 120 these environments, it may not be particularly convenient to do so. 121 The obvious way to deal with this issue is to map sieves into XML, 122 possibly on a separate backend system, manipulate the XML, and 123 convert it back to normal Sieve format. 125 The fact that conversion into and out of XML may be done as a 126 separate operation on a different system argues strongly for defining 127 a common XML representation for Sieve. This way different front end 128 user interfaces can be used with different back end mapping and 129 storage facilities. 131 Another issue with the creation and manipulation of sieve scripts by 132 user interfaces is that the language is strictly focused on 133 describing email filtering operations. The language contains no 134 mechanisms for indicating how a given script should be presented in a 135 user interface. Such information can be represented in XML very 136 easily so it makes sense to define a framework to do this as part of 137 the XML format. A structured comment convention is then used to 138 retain this information when the script is converted to normal Sieve 139 format. 141 Various sieve extensions have already been defined, e.g., [RFC5183] 142 [RFC5229] [RFC5230] [RFC5231] [RFC5232] [RFC5233] [RFC5235] 143 [RFC5293], and more are planned. The set of extensions available 144 varies from one implementation to the next and may even change as a 145 result of configuration choices. It is therefore essential that the 146 XML representation of Sieve be able to accommodate Sieve extensions 147 without requiring schema changes. It is also desirable that Sieve 148 extensions not require changes to the code that converts to and from 149 the XML representation. 151 This specification defines an XML representation for sieve scripts 152 and explains how the conversion process to and from XML works. The 153 XML representation is capable of accommodating any future Sieve 154 extension as long as the underlying Sieve grammar remains unchanged. 155 Furthermore, code that converts from XML to the normal Sieve format 156 requires no changes to accommodate extensions, while code used to 157 convert from normal Sieve format to XML only requires changes when 158 new control commands are added - a rare event. An XML Schema, Relax 159 NG Schema, and a sample stylesheet to convert from XML format are 160 also provided in the appendices. 162 2. Conventions used in this document 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 166 document are to be interpreted as described in RFC 2119 [RFC2119]. 168 3. Grammatical structure of Sieve 170 The Sieve language is designed to be highly extensible without making 171 any changes to the basic language syntax. Accordingly the syntax of 172 Sieve, defined in section 8 of [RFC5228], is entirely structural in 173 nature and employs no reserved words of any sort. 175 Structurally a sieve script consists of a series of commands. Each 176 command in turn consists of an identifier, zero or more arguments, a 177 optional test or test-list, and finally an optional block containing 178 another series of commands. Commands are further broken down into 179 controls and actions, although this distinction cannot be determined 180 from the grammar. 182 Some example Sieve controls are: 184 stop; <-- No arguments, test, or command block 185 require "fileinto"; <-- Control with a single argument 186 if true {stop;} <-- Control with test and command block 188 Some examples of Sieve actions are: 190 discard; <-- Action with no args, test, or command block 191 fileinto "folder"; <-- Action with an argument 193 At the time of this writing there are no controls defined that accept 194 both arguments and a test. Similarly, there are currently no defined 195 actions that allow either a test or a command block. Nevertheless, 196 the Sieve grammar allows such constructs to be defined by some future 197 extension. 199 A test consists of an identifier followed by zero or more arguments, 200 then another test or test-list. Unlike commands, tests cannot be 201 followed by a command block. 203 Here are some examples of Sieve tests. Note that such tests have to 204 appear as part of a command in order to be syntactically valid: 206 true <-- Test with no argument or subordinate test 207 envelope "to" "me@example.com" <-- Test with several arguments 208 header :is "from" "you@example.com" <-- Test with tagged argument 210 Command or test arguments can be either string lists, whole numbers 211 or tags. (Tags are simply identifiers preceded by a colon.) Note 212 that although the Sieve grammar treats single strings as a degenerate 213 case of a string list, some tests or actions have arguments that can 214 only be individual strings, not lists. 216 Here is an example showing the use of both a test-list and a string 217 list: 219 if anyof (not exists ["From", "Date"], 220 header :contains "from" "fool@example.edu") { 221 discard; 222 } 224 Extensions can add new controls, actions, tests, or new arguments to 225 existing controls or actions. Extensions have also changed how 226 string content is interpreted, although this is not relevant to this 227 specification. However, it is especially important to note that so 228 far no Sieve extension has added a new control to the language and it 229 seems safe to assume that due to their nature future addition of 230 controls will be rare. 232 Finally, comments are allowed between lexical elements in a Sieve 233 script. Finally, comments are allowed between lexical elements in a 234 Sieve script. One important use case for comments is encoding meta- 235 data about the script, a facility which is lacking in the Sieve 236 language. Therefore comments need to be preserved in the XML 237 representation. 239 4. XML Representation of Sieve 241 Sieve controls and actions are represented in XML as "control" or 242 "action" elements respectively. The command's identifier appears as 243 a name attribute on the element itself. This is the only attribute 244 allowed on controls and actions - arguments, tests, test-lists, and 245 nested command blocks are all represented as nested elements. While 246 naming the element after the control or action itself may seem like a 247 better choice, doing so would result in extensions requiring 248 corresponding schema changes. 250 The example Sieve controls shown in the previous section would be 251 represented in XML as: 253 254 fileinto 255 256 257 259 The example Sieve actions shown above would appear in XML as: 261 262 folder 264 The separation of controls from actions in the XML representation 265 means that conversion from normal Sieve format to XML has to be able 266 to distinguish between controls and actions. This is easily done by 267 maintaining a list of all known controls since experience indicates 268 new controls are rarely added. 270 Tests are represented in the same basic way as controls and actions, 271 that is, as a "test" element with a name attribute giving the test 272 identifier. For example: 274 275 276 tome@example.com 277 278 279 isfromyou@example.com 280 282 String, number, and tag arguments are represented as "str", "num", 283 and "tag" elements respectively. The actual string, number, or tag 284 identifier appears as text inside the element. None of these 285 elements have any defined attributes. Several examples of arguments 286 have already appeared in the preceding control, action and test 287 examples. Any whitespace in the str body content MUST be preserved 288 by the processor. 290 String list arguments are represented as a "list" element which in 291 turn contains one or more str elements. Note that this allows the 292 distinction between a single string and a string list containing a 293 single string to be preserved. This is not essential since a list 294 containing a single string could simply be mapped to a string, but it 295 seems prudent to maintain the distinction when mapping to and from 296 XML. 298 Nested command blocks appear as a series of control or action 299 elements inside of an outer control or action element. No block 300 element is needed since an inner command block can only appear once 301 and only after any arguments, tests, or test-lists. For example: 303 305 306 311 contains 312 from 313 fool@example.edu 314 315 316 317 319 Finally, Sieve comments are mapped to a special "comment" element in 320 XML. Both hash and bracketed comments are mapped to the same 321 construct so the distinction between the two is lost in XML. XML 322 comments are not used because some XML tools do not make it 323 convenient to access comment nodes. 325 4.1. XML Display Directives 327 Sometimes graphical user interfaces are a convenient way to provide 328 sieve management functions to users. These interfaces typically 329 summarize/annotate/group/display sieve script(s) in an intuitive way 330 for end users. 332 To do this effectively, the graphical user interface may require 333 additional information about the sieve script itself. That 334 information or "meta-data" might include, but is not limited to - a 335 sieve name (identifying the current sieve), whether the sieve is 336 enabled or disabled, the order in which the part of the sieve are 337 presented to the user. The graphical user interface may also choose 338 to provide mechanisms to allow the user to modify the script. 340 It is often useful for a graphical user interface to group related 341 sieve script elements and provide an interface that display these 342 groups separately so they can be managed as a single object. Some 343 examples include Sieve statements that together provide vacation 344 responders, blacklists/whitelists and other types of filtering 345 controls. 347 Some advanced graphical user interfaces may even provide a natural 348 language representation of a sieve script and/or an advanced 349 interface to present sieve statements directly to the user. 351 A graphical user interface may also choose to support only a subset 352 of action commands in the Sieve language (and its extensions) and so 353 a mechanism to indicate the extent of support and characterize the 354 relationships between those supported action commands and test (with 355 its arguments) is immensely useful and probably required for clients 356 that may not have complete knowledge of sieve grammar and semantics. 358 The Sieve language contains no mechanisms for indicating how a given 359 script should be presented in a user interface. The language also 360 does not contain any specific mechanisms to represent other sorts of 361 meta-data about the script. Providing support for such meta-data as 362 part of a sieve script is currently totally implementation specific 363 and is usually done by imposing some type of structure on comments. 365 However, such information can be represented in XML very easily so it 366 makes sense to define a framework to do this as part of the XML 367 format. Implementations MAY choose to use structured comments to 368 retain this information when the script is converted to normal Sieve 369 format. 371 The sample schemata for the XML representation of Sieve allows XML in 372 foreign namespaces to be inserted in most places in Sieve scripts. 373 This is the preferred means of including additional information. 374 Alternately, the schema defines two display directives - displayblock 375 and displaydata - as containers for meta-data needed by graphical 376 user interfaces. 378 Editors MAY use displayblock, displaydata and foreign namespaces to 379 associate meta-data. Some editors find it inconvenient to preserve 380 this additional data during an editing session. Editors MAY preserve 381 this data during an editing session for compatibility with other 382 editors. 384 The displayblock element can be used to enclose any number of sieve 385 statements at any level. It is semantically meaningless to the sieve 386 script itself. It allows an arbitrary set of attributes. 387 Implementations MAY use this to provide many simple, display related 388 meta-data for the sieve such as sieve identifier, group identifier, 389 order of processing, etc. 391 The displaydata element supports any number of arbitrary child 392 elements. Implementations MAY use this to represent complex data 393 about that sieve such as a natural language representation of sieve 394 or a way to provide the sieve script directly. 396 4.2. Structured Comments 398 Since the XML representation is not intended as a storage format 399 there needs to be a way to preserve the additional information that 400 can be included in the XML representation in the normal Sieve syntax. 401 This is done through the use of three structured comment conventions: 403 1. XML content in other namespaces is placed in Sieve bracketed 404 comments beginning with the string "/* [/" and ending with the 405 string "/] */". 407 2. The content of displaydata elements is placed in Sieve bracketed 408 comments beginning with the string "/* [|" and ending with the 409 string "|] */". 411 3. The beginning of a displayblock element is mapped to a bracketed 412 Sieve comment beginning with the string "/* [*" which then lists 413 any displayblock attribute names and values in XML format. The 414 end of a displayblock element is mapped to a comment of the form 415 "/* *] */". 417 Processors MUST preserve the additional information allowed in the 418 XML format and SHOULD use the structured comment format shown above. 420 Note: If "*/" is found in the XML content, when mapped into a comment 421 it would prematurely terminate that comment. Escaping of this 422 sequence would often be inconvenient for processors. Editors SHALL 423 NOT include "*/" within displayblock, displaydata or foreign markup. 424 Processors MAY regard documents containing "*/" in foreign markup, 425 displayblock or displaydata as invalid. 427 4.3. Validation 429 A processor MAY validate documents against a schema and MAY reject 430 any which do not conform. For any document that a processor does not 431 reject as invalid, any markup that the processor cannot understand by 432 reference to this specification MAY be discarded. 434 Note that example Relax NG and XML Schema are given in the appendices 435 below. 437 5. Security Considerations 439 Any syntactically valid sieve script can be represented in XML. 440 Accordingly, all security considerations applicable to Sieve and any 441 extensions used also apply to the XML representation. 443 The use of XML carries its own security risks. Section 7 of RFC 3470 444 [RFC3470] discusses these risks. 446 It is axiomatic that a Sieve editor must be trusted to do what the 447 user specifies. If XML formats are used this trust necessarily must 448 extent to the components involved in converting to and from XML 449 format. 451 Arbitrary data can be included using other namespaces or placed in 452 the extensible displayblock and displaydata constructs defined in 453 this specification, possibly including entire scripts and other 454 executable content in languages other than Sieve. Appropriate 455 security precautions should be taken when using these facilities. 457 6. IANA Considerations 459 This section registers a new XML namespace per the procedures in RFC 460 3688 [RFC3688]. 462 URI: urn:ietf:params:xml:ns:sieve 464 Registrant Contact: IETF Sieve working group 465 467 XML: 469 BEGIN 470 471 473 474 475 477 Sieve Namespace 478 479 480

Namespace for Sieve Language objects expressed in XML

481

urn:ietf:params:xml:ns:sieve

482

See 483 RFC XXXX. 484

485 486 487 END 489 7. References 491 7.1. Normative References 493 [OASISRNC] 494 Clark, J., "RELAX NG Compact Syntax", OASIS Committee 495 Specification rnc, November 2002. 497 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 498 Requirement Levels", BCP 14, RFC 2119, March 1997. 500 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 501 the Use of Extensible Markup Language (XML) 502 within IETF Protocols", BCP 70, RFC 3470, January 2003. 504 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 505 January 2004. 507 [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering 508 Language", RFC 5228, January 2008. 510 7.2. Informative References 512 [RFC5183] Freed, N., "Sieve Email Filtering: Environment Extension", 513 RFC 5183, May 2008. 515 [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", 516 RFC 5229, January 2008. 518 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: 519 Vacation Extension", RFC 5230, January 2008. 521 [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: 522 Relational Extension", RFC 5231, January 2008. 524 [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags 525 Extension", RFC 5232, January 2008. 527 [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress 528 Extension", RFC 5233, January 2008. 530 [RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest 531 Extensions", RFC 5235, January 2008. 533 [RFC5293] Degener, J. and P. Guenther, "Sieve Email Filtering: 534 Editheader Extension", RFC 5293, August 2008. 536 Appendix A. Extended Example 538 The example sieve script given in section 9 of [RFC5228] would be 539 represented in XML as the following code component: 541 542 543 Example Sieve Filter 544 Declare any optional features or extensions used by the script 545 547 548 fileinto 549 551 552 Handle messages from known mailing lists 553 Move messages from IETF filter discussion list to filter mailbox 554 555 556 557 is 558 Sender 559 owner-ietf-mta-filters@imc.org 560 561 562 filter 563 move to "filter" mailbox 564 566 567 Keep all messages to or from people in my company 568 569 570 571 domain 572 is 573 574 From 575 To 576 577 example.com 578 579 580 582 583 Try and catch unsolicited email. If a message is not to me, 584 or it contains a subject known to be spam, file it away. 585 586 587 588 589 590 all 591 contains 592 593 To 594 Cc 595 Bcc 596 597 me@example.com 598 599 600 601 matches 602 subject 603 604 *make*money*fast* 605 *university*dipl*mas* 606 607 608 609 610 spam 611 612 613 614 615 Move all other (non-company) mail to "personal" 616 mailbox. 617 618 619 personal 620 621 623 625 The same script could be annotated with graphical display hints in a 626 variety of ways. Three possible code components that do this are: 628 630 631 fileinto 633 635 637 638 639 is 640 Sender 641 owner-ietf-mta-filters@imc.org 642 643 644 filter 645 646 647 649 651 652 653 domain 654 is 655 656 From 657 To 658 659 example.com 660 661 662 663 665 667 668 669 670 671 all 672 contains 673 674 To 675 Cc 676 Bcc 677 678 me@example.com 679 680 681 682 matches 683 subject 684 685 *make*money*fast* 686 *university*dipl*mas* 687 688 689 690 691 spam 692 693 694 696 698 699 700 personal 701 702 703 705 707 Note that since displayblock elements are semantically null as far as 708 the script itself is concerned they can be used to group structures 709 like elsif and else that are tied to statements in other groups. 711 The representation of this script in regular Sieve syntax uses 712 structured comments: 714 require "fileinto"; 715 /* [* name="File filter list mail" order="1" 716 group="FILE_TO_FOLDER" enable="true" */ 717 if header :is "Sender" "owner-ietf-mta-filters@imc.org" 718 { 719 fileinto "filter"; 720 } 721 /* *] */ 722 /* [* name="Keep all company mail" order="2" 723 group="KEEP_MESSAGE" enable="true" */ 724 elsif address :domain :is [ "From", "To" ] "example.com" 725 { 726 keep; 727 } 728 /* *] */ 729 /* [* name="File suspected spam" order="3" 730 group="FILE_TO_FOLDER" enable="true" */ 731 elsif anyof ( not ( address :all :contains [ "To", "Cc", "Bcc" ] 732 "me@example.com" ), 733 header :matches "subject" [ "*make*money*fast*", 734 "*university*dipl*mas*" ] ) 735 { 736 fileinto "spam"; 737 } 738 /* *] */ 739 /* [* name="File noncompany mail as personal" order="4" 740 group="FILE_TO_FOLDER" enable="true" */ 741 else 742 { 743 fileinto "personal"; 744 } 745 /* *] */ 747 A separate namespace can be used to embed text or structured 748 information: 750 753 754 If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org 755 then file it into the "filter" folder. 757 Otherwise if the address in the "From" or "To" has a domain 758 that is "example.com" then keep it. 760 Otherwise messages meeting with any of these conditions: 762 (1) None of the addresses in "To" or "Cc" or "Bcc" contains 763 the domain "example.com". 765 (2) The "Subject" field matches the pattern *make*money*fast* 766 or *university*dipl*mas* then file it into the "spam" 767 folder. 769 If all else fails then file the message in the "personal" 770 folder. 771 773 ... the actual sieve script ... 775 777 Alternately, displaydata elements can be used to accomplish the same 778 thing: 780 782 783 784 If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org 785 then file it into the "filter" folder. 787 Otherwise if the address in the "From" or "To" has a domain 788 that is "example.com" then keep it. 790 Otherwise messages meeting with any of these conditions: 792 (1) None of the addresses in "To" or "Cc" or "Bcc" contains 793 the domain "example.com". 795 (2) The "Subject" field matches the pattern *make*money*fast* 796 or *university*dipl*mas* then file it into the "spam" 797 folder. 799 If all else fails then file the message in the "personal" 800 folder. 801 802 804 ... the actual sieve script ... 806 808 Again, structured comments are used to represent this in regular 809 Sieve syntax: 811 /* [| 812 813 If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org 814 then file it into the "filter" folder. 816 Otherwise if the address in the "From" or "To" has a domain 817 that is "example.com" then keep it. 819 Otherwise messages meeting with any of these conditions: 821 (1) None of the addresses in "To" or "Cc" or "Bcc" contains 822 the domain "example.com". 824 (2) The "Subject" field matches the pattern *make*money*fast* 825 or *university*dipl*mas* then file it into the "spam" 826 folder. 828 If all else fails then file the message in the "personal" 829 folder. 830 831 |] */ 833 ... the actual sieve script ... 835 Appendix B. XML Schema for Sieves in XML 837 This appendix is informative. The following code component is an XML 838 Schema for the XML representation of Sieve scripts. Most of the 839 elements employing a complex content model allow use of elements in 840 other namespaces, subject to lax XML Schema validation rules. 841 Additionally, displaydata elements can be used to encapsulate 842 arbitrary XML content. Finally, displayblock elements can be used as 843 a general-purpose grouping mechanism - arbitrary attributes are 844 allowed on displayblock elements. 846 848 852 853 854 855 856 857 858 859 860 861 862 863 864 865 867 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 893 895 897 898 899 900 901 902 903 904 905 906 907 908 909 911 912 913 914 916 917 918 919 921 922 923 925 927 929 931 932 933 934 935 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 953 954 955 956 957 958 959 961 963 Appendix C. Relax NG Schema for Sieves in XML 965 This appendix is informative. The following code component defines a 966 Relax NG schema using compact notation OASISRNC [OASISRNC] for the 967 XML representation of Sieve scripts. Most of the elements employing 968 a complex content model allow unrestricted use of elements in other 969 namespaces. Additionally, displaydata elements can be used to 970 encapsulate arbitrary XML content. Finally, displayblock elements 971 can be used as a general-purpose grouping mechanism - arbitrary 972 attributes are allowed on displayblock elements. 974 namespace sieve = "urn:ietf:params:xml:ns:sieve" 976 start = element sieve:sieve { ( control | action | displayblock | 977 displaydata | comment | ext )* } 979 comment = element sieve:comment { xsd:string } 981 command = 982 ( 983 attribute name { 984 xsd:token { 985 pattern = "[A-Za-z_][A-Za-z0-9_]*" } }, 986 ( str | num | \list | tag | 987 displaydata | comment | ext )*, 988 test?, 989 ( control | action | displayblock | 990 displaydata | comment | ext )* 991 ), 992 empty 994 control = element sieve:control { command } 996 action = element sieve:action { command } 998 test = 999 element sieve:test 1000 { 1001 attribute name { 1002 xsd:token { 1003 pattern = "[A-Za-z_][A-Za-z0-9_]*" } }, 1004 ( str | num | \list | tag | comment | ext )*, 1005 test* 1006 } 1008 \list = element sieve:list { str+ } 1010 tag = element sieve:tag { 1011 xsd:token { 1012 pattern = "[A-Za-z_][A-Za-z0-9_]*" } } 1014 str = element sieve:str { xsd:string } 1016 num = element sieve:num { xsd:nonNegativeInteger } 1018 any = ( element * { any } | attribute * { text } | text )* 1020 ext = element * - sieve:* { any }* 1022 displayblock = 1023 element sieve:displayblock 1024 { 1025 ( control | action | displayblock | 1026 displaydata | comment | ext )*, 1027 attribute * { text }* 1028 } 1030 displaydata = element sieve:displaydata { any* } 1032 Appendix D. Stylesheet for conversion from XML 1034 This appendix is informative. The following code component is a 1035 stylesheet that can be used to convert the Sieve in XML 1036 representation to regular Sieve format. Content in other namespaces, 1037 displaydata, and displayblock elements are converted to structured 1038 comments as appropriate. 1040 1042 1044 1048 1051 1052 1053 1055 1058 1059 1060 1061 1062 1064 1066 1067 1068 1069 1070 1071 1072 1074 1075 \" 1076 1077 1079 1080 1081 1082 1083 1085 1086 \\ 1087 1088 1090 1091 1092 1093 1094 1095 1097 1099 1101 1102 1103 1104 1105 1106 1107 1109 1110 1111 1113 1114 1115 1116 1117 1118 1119 { 1120 1121 1123 1124 1125 1126 1127 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 } 1139 1140 1141 ; 1142 1143 1144 1145 1146 1147 1148 1149 1150 ( 1151 1152 1153 1154 , 1155 1156 1157 ) 1158 1159 1161 1162 " 1163 1164 1165 1166 " 1167 1169 1170 1171 1172 1173 1174 1175 G 1176 1177 1178 1179 M 1180 1181 1182 1183 K 1184 1185 1186 1187 1188 1189 1191 1192 [ 1193 1194 1195 1196 , 1197 1198 1199 ] 1200 1202 1203 : 1204 1205 1207 1208 1209 1210 1211 1212 /* 1213 1214 1215 */ 1216 1218 1219 1220 1221 1222 1223 1224 /* [* 1225 1226 */ 1227 1228 1229 1230 1231 1232 1233 /* *] */ 1234 1236 1237 1238 1239 1240 1241 /* [| 1242 1243 1245 1246 1247 1248 1249 |] */ 1250 1252 1254 1255 1256 1257 1258 1259 /* [/ 1260 1261 1263 1264 1265 1266 1267 /] */ 1268 1270 1272 1273 1274 1275 1276 1277 < 1278 1279 1280 /> 1281 1283 1284 1285 1286 1287 1288 < 1289 1290 1291 > 1292 1293 1295 1296 1297 1298 1299 1300 1301 </ 1302 1303 > 1304 1306 1307 1308 1309 =" 1310 1311 " 1312 1314 1316 Appendix E. Acknowledgements 1318 The stylesheet copy mode code is loosely based on a sample code 1319 posted to the xsl-list list by Americo Albuquerque. Robert Burrell 1320 Donkin, Andrew McKeon, Alexey Melnikov, and Aaron Stone provided 1321 useful comments on the document. 1323 Authors' Addresses 1325 Ned Freed 1326 Sun Microsystems 1327 800 Royal Oaks 1328 Monrovia, CA 91016-6347 1329 USA 1331 Phone: +1 909 457 4293 1332 Email: ned.freed@mrochek.com 1333 Srinivas Saisatish Vedam 1334 Sun Microsystems 1336 Phone: +91 80669 27577 1337 Email: Srinivas.Sv@Sun.COM