idnits 2.17.1 draft-freed-sieve-in-xml-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 987. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 998. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1005. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1011. 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 : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 516 has weird spacing: '...herwise messa...' == Line 522 has weird spacing: '...en file it in...' -- 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 (October 25, 2007) is 6000 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) == Outdated reference: A later version (-13) exists of draft-ietf-sieve-3028bis-12 -- Obsolete informational reference (is this intentional?): RFC 3431 (Obsoleted by RFC 5231) -- Obsolete informational reference (is this intentional?): RFC 3598 (Obsoleted by RFC 5233) -- Obsolete informational reference (is this intentional?): RFC 3685 (Obsoleted by RFC 5235) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 11 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: April 27, 2008 Sun Microsystems 5 October 25, 2007 7 Sieve Email Filtering: Representing Sieves and display directives in 8 XML 9 draft-freed-sieve-in-xml-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 27, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes a way to represent Sieve email filtering 43 language scripts in XML. Representing sieves in XML is intended not 44 as an alternate storage format for Sieve but rather as a means to 45 facilitate manipulation of scripts using XML tools. 47 The XML representation also defines additional elements that have no 48 counterparts in the regular Sieve language. These elements are 49 intended for use by graphical user interfaces and provide facilities 50 for labeling or grouping sections of a script so they can be 51 displayed more conveniently. These elements are represented as 52 specially structured comments in regular Sieve format. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions used in this document . . . . . . . . . . . . . . 4 58 3. Grammatical structure of Sieve . . . . . . . . . . . . . . . . 4 59 4. XML Representation of Sieve . . . . . . . . . . . . . . . . . 5 60 4.1. XML Display Directives . . . . . . . . . . . . . . . . . . 7 61 5. Extended Example . . . . . . . . . . . . . . . . . . . . . . . 8 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 63 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 64 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 65 7.2. Informative References . . . . . . . . . . . . . . . . . . 13 66 Appendix A. Schema for Sieves in XML . . . . . . . . . . . . . . 13 67 Appendix B. Stylesheet for conversion from XML . . . . . . . . . 16 68 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 21 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 70 Intellectual Property and Copyright Statements . . . . . . . . . . 23 72 1. Introduction 74 Sieve [I-D.ietf-sieve-3028bis] is a language for filtering email 75 messages at or around the time of final delivery. It is designed to 76 be implementable on either a mail client or mail server. It is meant 77 to be extensible, simple, and independent of access protocol, mail 78 architecture, and operating system and it is intended to be 79 manipulated by a variety of different user interfaces. 81 Some user interface environments have extensive existing facilities 82 for manipulating material represented in XML. While adding support 83 for alternate data syntaxes may be possible in most if not all of 84 these environments, it may not be particularly convenient to do so. 85 The obvious way to deal with this issue is to map sieves into XML, 86 possibly on a separate backend system, manipulate the XML, and 87 convert it back to normal Sieve format. 89 The fact that conversion into and out of XML may be done as a 90 separate operation on a different system argues strongly for defining 91 a common XML representation for Sieve. This way different front end 92 user interfaces can be used with different back end mapping and 93 storage facilities. 95 Another issue with the creation and manipulation of sieve scripts by 96 user interfaces is that the language is strictly focused on 97 describing email filtering operations. The language contains no 98 mechanisms for indicating how a given script should be presented in a 99 user interface. Such information can be represented in XML very 100 easily so it makes sense to define a framework to do this as part of 101 the XML format. Structured comments can then be used to retain this 102 information when the script is converted to normal Sieve format. 104 Several Sieve extensions have already been specified [RFC3431] 105 [RFC3598] [RFC3685] [RFC3934] and many more are planned. The set of 106 extensions available varies from one implementation to the next and 107 may even change as a result of configuration choices. It is 108 therefore essential that the XML representation of Sieve be able to 109 accommodate Sieve extensions without requiring schema changes. It is 110 also desirable that Sieve extensions not require changes to the code 111 that converts to and from the XML representation. 113 This specification defines an XML representation for sieve scripts 114 and explains how the conversion process to and from XML works. The 115 XML representation is capable of accommodating any future Sieve 116 extension as long as the underlying Sieve grammar remains unchanged. 117 Furthermore, code that converts from XML to the normal Sieve format 118 requires no changes to accommodate extensions, while code used to 119 convert from normal Sieve format to XML only requires changes when 120 new control commands are added - a rare event. An XML Schema and 121 sample code to convert to and from XML format are also provided in 122 the appendices. 124 2. Conventions used in this document 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in RFC 2119 [RFC2119]. 130 3. Grammatical structure of Sieve 132 The Sieve language is designed to be highly extensible without making 133 any changes to the basic language syntax. Accordingly the syntax of 134 Sieve, defined in section 8 of [I-D.ietf-sieve-3028bis], is entirely 135 structural in nature and employs no reserved words of any sort. 137 Structurally a sieve script consists of a series of commands. Each 138 command in turn consists of an identifier, zero or more arguments, a 139 optional test or test-list, and finally an optional block containing 140 another series of commands. Commands are further broken down into 141 controls and actions, although this distinction cannot be determined 142 from the grammar. 144 Some example Sieve controls are: 146 stop; <-- No arguments, test, or command block 147 require "fileinto"; <-- Control with a single argument 148 if true {stop;} <-- Control with test and command block 150 Some examples of Sieve actions are: 152 discard; <-- Action with no arguments, test, or command block 153 fileinto "folder"; <-- Action with an argument 155 At the time of this writing there are no controls defined that accept 156 both arguments and a test. Similarly, there are currently no defined 157 actions that allow either a test or a command block. Nevertheless, 158 the Sieve grammar allows such constructs to be defined by some future 159 extension. 161 A test consists of an identifier followed by zero or more arguments, 162 then another test or test-list. Unlike commands, tests cannot be 163 followed by a command block. 165 Here are some examples of Sieve tests. Note that such tests have to 166 appear as part of a command in order to be syntactically valid: 168 true <-- Test with no argument or subordinate test 169 header "to" "me@example.com" <-- Test with several arguments 171 Command or test arguments can be either string lists, whole numbers 172 or tags. (Tags are simply identifiers preceded by a colon.) Note 173 that although the Sieve grammar treats single strings as a degenerate 174 case of a string list, some tests or actions have arguments that can 175 only be individual strings, not lists. 177 Here is an example showing the use of both a test-list and a string 178 list: 180 if anyof (not exists ["From", "Date"], 181 header :contains "from" "fool@example.edu") { 182 discard; 183 } 185 Extensions can add new controls, actions, tests, or new arguments to 186 existing controls or actions. Extensions can also change how string 187 content is interpreted, although this is not relevant to this 188 specification. However, it is especially important to note that so 189 far no Sieve extension has added a new control to the language and it 190 seems safe to assume that due to their nature future addition of 191 controls will be rare. 193 Finally, comments are allowed between lexical elements in a Sieve 194 script. It is very important that comments be preserved in the XML 195 representation. 197 4. XML Representation of Sieve 199 Sieve controls and actions are represented in XML as control or 200 action elements respectively. The command's identifier appears as a 201 name attribute on the element itself. This is the only attribute 202 allowed on controls and actions - arguments, tests, test-lists, and 203 nest command blocks are all represented as nested elements. While 204 naming the element after the control or action itself may seem like a 205 better choice, doing so would result in extensions changing the XML 206 schema. 208 The example Sieve controls shown in the previous section would be 209 represented in XML as: 211 212 fileinto 213 215 The example Sieve actions shown about would appear in XML as: 217 218 folder 220 The separation of controls from actions in the XML representation 221 means that conversion from normal Sieve format to XML has to be able 222 to distinguish between controls and actions. This is easily done by 223 maintaining a list of all known controls since experience indicates 224 new controls are rarely added. 226 Tests are represented in the same basic way as controls and actions, 227 that is, as a test element with a name attribute giving the test 228 identifier. For example: 230 231 tome@example.com 233 String, number, and tag arguments are represented as str, num, and 234 tag elements respectively. The actual string, number, or tag 235 identifier appears as text inside the element. None of these 236 elements have any defined attributes. Several examples of arguments 237 have already appeared in the preceding control, action and test 238 examples. 240 String list arguments are represented as a list element which in turn 241 contains one or more str elements. Note that this the distinction 242 between a single string and a string list containing a single string 243 to be preserved. This is not essential since a list containing a 244 single string could simply be mapped to a string, but it seems 245 prudent to maintain the distinction when mapping to and from XML. 247 Nested command blocks appear as a series of control or action 248 elements inside of outer control or action element. No block element 249 is needed since an inner command block can only appear once and only 250 after any arguments, tests, or test-lists. For example: 252 254 255 260 contains 261 from 262 fool@example.edu 263 264 265 266 268 4.1. XML Display Directives 270 Sometimes graphical user interfaces are a convenient way to provide 271 sieve management functions to users. These interfaces typically 272 summarize/annotate/group/display sieve script(s) in an intuitive way 273 for end users. 275 To do this effectively, the graphical user interface may require 276 additional information about the sieve script itself. That 277 information or "meta-data" might include, but is not limited to - a 278 sieve name (identifying the current sieve), whether the sieve is 279 enabled or disabled, the order in which the part of the sieve are 280 presented to the user. The graphical user interface may also choose 281 to provide mechanisms to allow the user to modify the script. 283 It is often useful for a graphical user interface to group related 284 sieve script elements and provide an interface that display these 285 group separately and manage things via these groupings. Some 286 examples include Sieve statementss that together provide vacation 287 responders, blacklists/whitelists and other types of filtering 288 controls. 290 Some advanced graphical user interfaces may even provide a natural 291 language representation of a sieve script and/or an advanced 292 interface to present sieve statements directly to the user. 294 A graphical user interface may also choose to support only a subset 295 of action commands in the Sieve language (and its extensions) and so 296 a mechanism to indicate the extent of support and characterize the 297 relationships between those supported action commands and test (with 298 its arguments) is immensely useful and probably required for clients 299 that may not have complete knowledge of sieve grammar and semantics. 301 The Sieve language contains no mechanisms for indicating how a given 302 script should be presented in a user interface. The language also 303 does not contain any specific mechanisms to represent other sorts of 304 meta-data about the script. Providing support for such meta-data as 305 part of sieve script is currently totally implementation specific and 306 is usually done by imposing some type of structure on comments. 308 However, such information can be represented in XML very easily so it 309 makes sense to define a framework to do this as part of the XML 310 format. Implementations may choose to use structured comments to 311 retain this information when the script is converted to normal Sieve 312 format. 314 This XML representation defines two display directives - displayblock 315 and displaydata - as containers for meta-data needed by graphical 316 user interfaces. 318 The displayblock element can be used to enclose any number of sieve 319 statements at any level. It is semantically meaningless to the sieve 320 script itself. It allows an arbitrary set of attributes. 321 Implementations MAY use this to provide many simple, display related 322 meta-data for the sieve such as sieve identifier, group identifier, 323 order of processing, etc. This information SHOULD be preserved in 324 structured comments during conversion of XML to the normal Sieve 325 syntax. 327 The displaydata element supports an any number of arbitrary child 328 elements. Implementations MAY use this represent complex data about 329 that sieve such as a natural language representation of sieve or a 330 way to provide the sieve script directly. Again, this information 331 SHOULD be presered in structured comments when converted. 333 5. Extended Example 335 The example sieve script given in section 9 of 336 [I-D.ietf-sieve-3028bis] would be represented in XML as follows: 338 342 344 345 fileinto 346 347 351 352 353 is 354 Sender 355 owner-ietf-mta-filters@imc.org 356 357 358 filter 359 360 362 365 366 367 domain 368 is 369 370 From 371 To 372 373 example.com 374 375 376 378 382 383 384 385 386 all 387 contains 388 389 To 390 Cc 391 Bcc 392 393 me@example.com 394 396 397 398 matches 399 subject 400 401 *make*money*fast* 402 *university*dipl*mas* 403 404 405 406 407 spam 408 409 410 411 413 414 personal 415 416 418 420 The same script could be annotated with grahical display hints in 421 variety of ways. Two possibilities are: 423 425 426 fileinto 427 429 431 432 433 is 434 Sender 435 owner-ietf-mta-filters@imc.org 436 437 438 filter 439 440 441 443 445 446 447 domain 448 is 449 450 From 451 To 452 453 example.com 454 455 456 457 459 461 462 463 464 465 all 466 contains 467 468 To 469 Cc 470 Bcc 471 472 me@example.com 473 474 475 476 matches 477 subject 478 479 *make*money*fast* 480 *university*dipl*mas* 481 482 483 484 485 spam 486 487 488 490 493 494 495 personal 496 497 498 500 502 Note that since displayblock elements are semantically null as far as 503 the script itself is concerned they can be used to group structures 504 like elsif and else that are tied to statements in other groups. 506 508 509 510 If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org 511 then file it into the "filter" folder. 513 Otherwise if the address in the "From" or "To" has a domain that 514 is "example.com" then keep it. 516 Otherwise messages meeting with any of these conditions: 518 (1) None of the addresses in "To" or "Cc" or "Bcc" contains the 519 domain "example.com". 521 (2) The "Subject" field matches the pattern *make*money*fast* or 522 *university*dipl*mas* then file it into the "spam" folder. 524 If all else fails then file the message in the "personal" folder. 525 526 528 ... the actual sieve script ... 530 532 6. Security Considerations 534 Any syntactically valid sieve script can be represented in XML. 535 Accordingly, all security considerations applicable to Sieve and any 536 extensions used also apply to the XML representation. 538 The use of XML carries its own security risks. Section 7 of RFC 3470 539 [RFC3470] discussses these risks 540 Arbitrary data can be placed in the extensible displayblock and 541 displaydata constructs defined in this specification, possibly 542 including entire scripts in languages other than Sieve. Appropriate 543 security precautions should be taken when using these facilities. 545 7. References 547 7.1. Normative References 549 [I-D.ietf-sieve-3028bis] 550 Guenther, P. and T. Showalter, "Sieve: An Email Filtering 551 Language", draft-ietf-sieve-3028bis-12 (work in progress), 552 February 2007, . 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, March 1997. 558 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 559 the Use of Extensible Markup Language (XML) within IETF 560 Protocols", BCP 70, RFC 3470, January 2003. 562 7.2. Informative References 564 [RFC3431] Segmuller, W., "Sieve Extension: Relational Tests", 565 RFC 3431, December 2002. 567 [RFC3598] Murchison, K., "Sieve Email Filtering -- Subaddress 568 Extension", RFC 3598, September 2003. 570 [RFC3685] Daboo, C., "SIEVE Email Filtering: Spamtest and VirusTest 571 Extensions", RFC 3685, February 2004. 573 [RFC3934] Wasserman, M., "Updates to RFC 2418 Regarding the 574 Management of IETF Mailing Lists", BCP 94, RFC 3934, 575 October 2004. 577 Appendix A. Schema for Sieves in XML 579 The following defines a schema for the XML representation of Sieve 580 scripts. Note that aside from defining the displaydata and 581 displayblock elements this schema imposes no constraints on their 582 content. 584 585 588 589 590 591 592 593 594 595 596 597 598 599 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 620 622 624 625 626 627 628 629 630 631 632 633 635 636 637 638 640 641 642 643 645 646 647 649 651 653 655 656 657 658 659 661 662 663 664 665 666 667 668 669 670 671 672 673 675 676 677 678 679 680 682 684 686 Appendix B. Stylesheet for conversion from XML 688 690 692 695 698 699 700 702 705 706 709 710 711 713 715 716 717 718 719 720 721 723 724 \" 725 726 728 730 731 732 733 735 736 \\ 737 738 740 741 742 743 744 745 746 748 750 751 752 753 754 755 756 758 759 760 762 763 764 765 766 767 768 { 769 770 772 773 774 775 776 779 780 781 782 783 784 785 786 787 788 } 789 790 791 ; 792 793 794 796 797 798 799 801 802 ( 803 804 805 806 , 807 808 809 ) 810 811 813 814 " 815 816 817 818 " 819 821 822 823 824 825 826 827 G 828 829 830 831 M 832 833 834 835 K 836 837 838 839 840 841 843 844 [ 845 846 847 848 , 849 850 851 ] 852 854 855 : 856 857 859 860 861 862 863 864 /* 865 866 867 */ 868 870 871 872 873 874 875 876 /* [* 877 878 */ 879 882 883 884 885 886 887 /* *] */ 888 890 891 892 893 894 895 /* [| 896 897 899 900 901 902 903 |] */ 904 906 908 909 910 911 912 913 < 914 915 916 /> 917 919 920 921 922 923 924 < 925 926 927 > 928 929 931 932 933 934 935 936 937 </ 938 939 > 940 942 943 944 945 =" 946 947 " 948 950 952 Appendix C. Acknowledgements 954 The stylesheet copy mode code is loosely based on a sample code 955 posted to the xsl-list list by Americo Albuquerque. 957 Authors' Addresses 959 Ned Freed 960 Sun Microsystems 961 3401 Centrelake Drive, Suite 410 962 Ontario, CA 92761-1205 963 USA 965 Phone: +1 909 457 4293 966 Email: ned.freed@mrochek.com 967 Srinivas Saisatish Vedam 968 Sun Microsystems 970 Phone: +91 80669 27577 971 Email: Srinivas.Sv@Sun.COM 973 Full Copyright Statement 975 Copyright (C) The IETF Trust (2007). 977 This document is subject to the rights, licenses and restrictions 978 contained in BCP 78, and except as set forth therein, the authors 979 retain all their rights. 981 This document and the information contained herein are provided on an 982 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 983 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 984 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 985 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 986 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 987 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 989 Intellectual Property 991 The IETF takes no position regarding the validity or scope of any 992 Intellectual Property Rights or other rights that might be claimed to 993 pertain to the implementation or use of the technology described in 994 this document or the extent to which any license under such rights 995 might or might not be available; nor does it represent that it has 996 made any independent effort to identify any such rights. Information 997 on the procedures with respect to rights in RFC documents can be 998 found in BCP 78 and BCP 79. 1000 Copies of IPR disclosures made to the IETF Secretariat and any 1001 assurances of licenses to be made available, or the result of an 1002 attempt made to obtain a general license or permission for the use of 1003 such proprietary rights by implementers or users of this 1004 specification can be obtained from the IETF on-line IPR repository at 1005 http://www.ietf.org/ipr. 1007 The IETF invites any interested party to bring to its attention any 1008 copyrights, patents or patent applications, or other proprietary 1009 rights that may cover technology that may be required to implement 1010 this standard. Please address the information to the IETF at 1011 ietf-ipr@ietf.org. 1013 Acknowledgment 1015 Funding for the RFC Editor function is provided by the IETF 1016 Administrative Support Activity (IASA).