draft-freed-sieve-in-xml-07.txt   rfc5784.txt 
Network Working Group N. Freed Internet Engineering Task Force (IETF) N. Freed
Internet-Draft S. Vedam Request for Comments: 5784 S. Vedam
Expires: April 24, 2010 Sun Microsystems Category: Standards Track Sun Microsystems
October 21, 2009 ISSN: 2070-1721 March 2010
Sieve Email Filtering: Sieves and display directives in XML
draft-freed-sieve-in-xml-07
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 24, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Sieve Email Filtering: Sieves and Display Directives in XML
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This document describes a way to represent Sieve email filtering This document describes a way to represent Sieve email filtering
language scripts in XML. Representing sieves in XML is intended not language scripts in XML. Representing Sieves in XML is intended not
as an alternate storage format for Sieve but rather as a means to as an alternate storage format for Sieve but rather as a means to
facilitate manipulation of scripts using XML tools. facilitate manipulation of scripts using XML tools.
The XML representation also defines additional elements that have no The XML representation also defines additional elements that have no
counterparts in the regular Sieve language. These elements are counterparts in the regular Sieve language. These elements are
intended for use by graphical user interfaces and provide facilities intended for use by graphical user interfaces and provide facilities
for labeling or grouping sections of a script so they can be for labeling or grouping sections of a script so they can be
displayed more conveniently. These elements are represented as displayed more conveniently. These elements are represented as
specially structured comments in regular Sieve format. specially structured comments in regular Sieve format.
Change History (to be removed prior to publication as an RFC Status of This Memo
Changed representation of comments in XML to use a comment element.
Update references.
Added an IANA registration of a URN for the Sieve namespace.
Updated XML Schema to allow largely unrestricted use of material in
other namespaces.
Add compact Relax NG schema.
Updated example stylesheet to handle material in other namespaces.
Corrected stylesheet handling of <comment> elements.
Added a section defining the structured comment convention.
Moved the examples section to an appendix.
Added text to clarify that the examples in the various appendices are
in fact code components and may therefore be reused.
Added a section on validation requirements.
Clarified various editor requirements and trust issues, restricted
the use of "*/" in non-Sieve XML content.
Added XML reference. This is an Internet Standards Track document.
Added a list of all presently defined controls, explained how unknown This document is a product of the Internet Engineering Task Force
controls would be handled. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Added a note about the need to remove quotes and other syntax Information about the current status of this document, any errata,
elements when converting to XML. and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc5784.
Added a note about the fact that different front ends employing Copyright Notice
different medadata may not interopate with each other.
Added preamble and postamble containers for displaydata, comment, and Copyright (c) 2010 IETF Trust and the persons identified as the
external elements in command blocks. This addresses a unique document authors. All rights reserved.
particle attribution constraint violation in XML schema.
Added information about the MIME loops extension defining two new This document is subject to BCP 78 and the IETF Trust's Legal
controls: foreverypart and break. Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions used in this document . . . . . . . . . . . . . . 5 2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Grammatical structure of Sieve . . . . . . . . . . . . . . . . 5 3. Grammatical Structure of Sieve . . . . . . . . . . . . . . . . 4
4. XML Representation of Sieve . . . . . . . . . . . . . . . . . 7 4. XML Representation of Sieve . . . . . . . . . . . . . . . . . 6
4.1. XML Display Directives . . . . . . . . . . . . . . . . . . 10 4.1. XML Display Directives . . . . . . . . . . . . . . . . . . 9
4.2. Structured Comments . . . . . . . . . . . . . . . . . . . 11 4.2. Structured Comments . . . . . . . . . . . . . . . . . . . 10
4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. Validation . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Extended Example . . . . . . . . . . . . . . . . . . 14 Appendix A. Extended Example . . . . . . . . . . . . . . . . . . 14
Appendix B. XML Schema for Sieves in XML . . . . . . . . . . . . 22 Appendix B. XML Schema for Sieves in XML . . . . . . . . . . . . 21
Appendix C. Relax NG Schema for Sieves in XML . . . . . . . . . . 25 Appendix C. Relax NG Schema for Sieves in XML . . . . . . . . . . 24
Appendix D. Stylesheet for conversion from XML . . . . . . . . . 27 Appendix D. Stylesheet for Conversion from XML . . . . . . . . . 26
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 33 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
1. Introduction 1. Introduction
Sieve [RFC5228] is a language for filtering email messages at or Sieve [RFC5228] is a language for filtering email messages at or
around the time of final delivery. It is designed to be around the time of final delivery. It is designed to be
implementable on either a mail client or mail server. It is meant to implementable on either a mail client or mail server. It is meant to
be extensible, simple, and independent of access protocol, mail be extensible, simple, and independent of access protocol, mail
architecture, and operating system and it is intended to be architecture, and operating system, and it is intended to be
manipulated by a variety of different user interfaces. manipulated by a variety of different user interfaces.
Some user interface environments have extensive existing facilities Some user interface environments have extensive existing facilities
for manipulating material represented in XML [XML]. While adding for manipulating material represented in XML [XML]. While adding
support for alternate data syntaxes may be possible in most if not support for alternate data syntaxes may be possible in most if not
all of these environments, it may not be particularly convenient to all of these environments, it may not be particularly convenient to
do so. The obvious way to deal with this issue is to map sieves into do so. The obvious way to deal with this issue is to map Sieves into
XML, possibly on a separate backend system, manipulate the XML, and XML, possibly on a separate back-end system, manipulate the XML, and
convert it back to normal Sieve format. convert it back to normal Sieve format.
The fact that conversion into and out of XML may be done as a The fact that conversion into and out of XML may be done as a
separate operation on a different system argues strongly for defining separate operation on a different system argues strongly for defining
a common XML representation for Sieve. This way different front end a common XML representation for Sieve. This way, different front-end
user interfaces can be used with different back end mapping and user interfaces can be used with different back-end mapping and
storage facilities. storage facilities.
Another issue with the creation and manipulation of sieve scripts by Another issue with the creation and manipulation of Sieve scripts by
user interfaces is that the language is strictly focused on user interfaces is that the language is strictly focused on
describing email filtering operations. The language contains no describing email filtering operations. The language contains no
mechanisms for indicating how a given script should be presented in a mechanisms for indicating how a given script should be presented in a
user interface. Such information can be represented in XML very user interface. Such information can be represented in XML very
easily so it makes sense to define a framework to do this as part of easily, so it makes sense to define a framework to do this as part of
the XML format. A structured comment convention is then used to the XML format. A structured comment convention is then used to
retain this information when the script is converted to normal Sieve retain this information when the script is converted to normal Sieve
format. format.
It should be noted, however, that the ability for different front It should be noted, however, that the ability for different front
ends to use the same mapping and storage facilities does not mean ends to use the same mapping and storage facilities does not mean
that the additional XML information produced by different front ends that the additional XML information produced by different front ends
will interoperate. will interoperate.
Various sieve extensions have already been defined, e.g., [RFC5183] Various Sieve extensions have already been defined, e.g., [RFC5183],
[RFC5229] [RFC5230] [RFC5231] [RFC5232] [RFC5233] [RFC5235] [RFC5229], [RFC5230], [RFC5231], [RFC5232], [RFC5233], [RFC5235],
[RFC5293], and more are planned. The set of extensions available [RFC5293], and more are planned. The set of extensions available
varies from one implementation to the next and may even change as a varies from one implementation to the next and may even change as a
result of configuration choices. It is therefore essential that the result of configuration choices. It is therefore essential that the
XML representation of Sieve be able to accommodate Sieve extensions XML representation of Sieve be able to accommodate Sieve extensions
without requiring schema changes. It is also desirable that Sieve without requiring schema changes. It is also desirable that Sieve
extensions not require changes to the code that converts to and from extensions not require changes to the code that converts to and from
the XML representation. the XML representation.
This specification defines an XML representation for sieve scripts This specification defines an XML representation for Sieve scripts
and explains how the conversion process to and from XML works. The and explains how the conversion process to and from XML works. The
XML representation is capable of accommodating any future Sieve XML representation is capable of accommodating any future Sieve
extension as long as the underlying Sieve grammar remains unchanged. extension as long as the underlying Sieve grammar remains unchanged.
Furthermore, code that converts from XML to the normal Sieve format Furthermore, code that converts from XML to the normal Sieve format
requires no changes to accommodate extensions, while code used to requires no changes to accommodate extensions, while code used to
convert from normal Sieve format to XML only requires changes when convert from normal Sieve format to XML only requires changes when
new control commands are added - a rare event. An XML Schema, Relax new control commands are added -- a rare event. An XML Schema, Relax
NG Schema, and a sample stylesheet to convert from XML format are NG Schema, and a sample stylesheet to convert from XML format are
also provided in the appendices. also provided in the appendices.
2. Conventions used in this document 2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
The term "processor" is used throughout this document to refer to The term "processor" is used throughout this document to refer to
agents that convert Sieve to and from the XML representation. The agents that convert Sieve to and from the XML representation. The
term "editor" refers to agents that operate on, possibly creating or term "editor" refers to agents that operate on, possibly creating or
modifying, Sieves in XML format. modifying, Sieves in XML format.
3. Grammatical structure of Sieve 3. Grammatical Structure of Sieve
The Sieve language is designed to be highly extensible without making The Sieve language is designed to be highly extensible without making
any changes to the basic language syntax. Accordingly the syntax of any changes to the basic language syntax. Accordingly, the syntax of
Sieve, defined in section 8 of [RFC5228], is entirely structural in Sieve, defined in Section 8 of [RFC5228], is entirely structural in
nature and employs no reserved words of any sort. nature and employs no reserved words of any sort.
Structurally a sieve script consists of a series of commands. Each Structurally, a Sieve script consists of a series of commands. Each
command in turn consists of an identifier, zero or more arguments, a command, in turn, consists of an identifier, zero or more arguments,
optional test or test-list, and finally an optional block containing an optional test or test-list, and finally an optional block
another series of commands. Commands are further broken down into containing another series of commands. Commands are further broken
controls and actions, although this distinction cannot be determined down into controls and actions, although this distinction cannot be
from the grammar. determined from the grammar.
Some example Sieve controls are: Some example Sieve controls are:
stop; <-- No arguments, test, or command block stop; <-- No arguments, test, or command block
require "fileinto"; <-- Control with a single argument require "fileinto"; <-- Control with a single argument
if true {stop;} <-- Control with test and command block if true {stop;} <-- Control with test and command block
Some examples of Sieve actions are: Some examples of Sieve actions are:
discard; <-- Action with no args, test, or command block discard; <-- Action with no arguments, test, or command block
fileinto "folder"; <-- Action with an argument fileinto "folder"; <-- Action with an argument
At the time of this writing there are no controls defined that accept At the time of this writing, there are no controls defined that
both arguments and a test. Similarly, there are currently no defined accept both arguments and a test. Similarly, there are currently no
actions that allow either a test or a command block. Nevertheless, defined actions that allow either a test or a command block.
the Sieve grammar allows such constructs to be defined by some future Nevertheless, the Sieve grammar allows such constructs to be defined
extension. by some future extension.
A test consists of an identifier followed by zero or more arguments, A test consists of an identifier followed by zero or more arguments,
then another test or test-list. Unlike commands, tests cannot be then another test or test-list. Unlike commands, tests cannot be
followed by a command block. followed by a command block.
Here are some examples of Sieve tests. Note that such tests have to Here are some examples of Sieve tests. Note that such tests have to
appear as part of a command in order to be syntactically valid: appear as part of a command in order to be syntactically valid:
true <-- Test with no argument or subordinate test true <-- Test with no argument or subordinate test
envelope "to" "me@example.com" <-- Test with several arguments envelope "to" "me@example.com" <-- Test with several arguments
header :is "from" "you@example.com" <-- Test with tagged argument header :is "from" "you@example.com" <-- Test with tagged argument
Command or test arguments can be either string lists, whole numbers Command or test arguments can be either string lists, whole numbers,
or tags. (Tags are simply identifiers preceded by a colon.) Note or tags. (Tags are simply identifiers preceded by a colon.) Note
that although the Sieve grammar treats single strings as a degenerate that although the Sieve grammar treats single strings as a degenerate
case of a string list, some tests or actions have arguments that can case of a string list, some tests or actions have arguments that can
only be individual strings, not lists. only be individual strings, not lists.
Here is an example showing the use of both a test-list and a string Here is an example showing the use of both a test-list and a string
list: list:
if anyof (not exists ["From", "Date"], if anyof (not exists ["From", "Date"],
header :contains "from" "fool@example.edu") { header :contains "from" "fool@example.edu") {
discard; discard;
} }
Extensions can add new controls, actions, tests, or new arguments to Extensions can add new controls, actions, tests, or arguments to
existing controls or actions. Extensions have also changed how existing controls or actions. Extensions have also changed how
string content is interpreted, although this is not relevant to this string content is interpreted, although this is not relevant to this
specification. However, it is especially important to note that so specification. However, it is especially important to note that so
far only one of the many defined Sieve extensions - the foreverypart far, only one of the many defined Sieve extensions -- the
extension [I-D.ietf-sieve-mime-loop] - has added new controls to the foreverypart extension [RFC5703] -- has added new controls to the
language. It seems safe to assume that due to their nature future language. It seems safe to assume that, due to their nature, future
addition of controls will be relatively rare. addition of controls will be relatively rare.
Finally, comments are allowed between lexical elements in a Sieve Finally, comments are allowed between lexical elements in a Sieve
script. One important use case for comments is encoding meta-data script. One important use case for comments is encoding meta-data
about the script, a facility which is lacking in the Sieve language. about the script, a facility that is lacking in the Sieve language.
Therefore comments need to be preserved in the XML representation. Therefore, comments need to be preserved in the XML representation.
4. XML Representation of Sieve 4. XML Representation of Sieve
Sieve controls and actions are represented in XML as "control" or Sieve controls and actions are represented in XML as "control" or
"action" elements respectively. The command's identifier appears as "action" elements, respectively. The command's identifier appears as
a name attribute on the element itself. This is the only attribute a name attribute on the element itself. This is the only attribute
allowed on controls and actions - arguments, tests, test-lists, and allowed on controls and actions -- arguments, tests, test-lists, and
nested command blocks are all represented as nested elements. While nested command blocks are all represented as nested elements. While
naming the element after the control or action itself may seem like a naming the element after the control or action itself may seem like a
better choice, doing so would result in extensions requiring frequent better choice, doing so would result in extensions requiring frequent
corresponding schema changes. corresponding schema changes.
The example Sieve controls shown in the previous section would be The example Sieve controls shown in the previous section would be
represented in XML as: represented as these XML fragments:
<control name="stop"/> <control name="stop"/>
<control name="require"><str>fileinto</str></control>
<control name="if"> <control name="require"><str>fileinto</str></control>
<control name="if">
<test name="true"/><control name="stop"/> <test name="true"/><control name="stop"/>
</control> </control>
The example Sieve actions shown above would appear in XML as: The example Sieve actions shown above would appear in XML as:
<action name="discard"/> <action name="discard"/>
<action name="fileinto"><str>folder</str></action> <action name="fileinto"><str>folder</str></action>
The separation of controls from actions in the XML representation The separation of controls from actions in the XML representation
means that conversion from normal Sieve format to XML has to be able means that conversion from normal Sieve format to XML has to be able
to distinguish between controls and actions. This is easily done by to distinguish between controls and actions. This is easily done by
maintaining a list of all known controls since experience indicates maintaining a list of all known controls since experience indicates
new controls are rarely added. At the time of this writing the list new controls are rarely added. At the time of this writing, the list
of defined controls consists of: of defined controls consists of:
1. if [RFC5228], 1. if [RFC5228],
2. stop [RFC5228], 2. stop [RFC5228],
3. require [RFC5228], 3. require [RFC5228],
4. foreverypart [I-D.ietf-sieve-mime-loop], and 4. foreverypart [RFC5703], and
5. break [I-D.ietf-sieve-mime-loop]. 5. break [RFC5703].
It should be noted that with this approach unknown controls will It should be noted that with this approach unknown controls will
simply be treated as actions and can be passed back and forth between simply be treated as actions and can be passed back and forth between
the two representations. The treatment of a control as an action is the two representations. The treatment of a control as an action is
unlikely to cause other issues since knowledge of a control's unlikely to cause other issues since knowledge of a control's
language semantics is almost always required to take of advantage of language semantics is almost always required to take advantage of it.
it.
Tests are represented in the same basic way as controls and actions, Tests are represented in the same basic way as controls and actions,
that is, as a "test" element with a name attribute giving the test that is, as a "test" element with a name attribute giving the test
identifier. For example: identifier. For example, the following XML fragments show various
types of tests:
<test name="true"/> <test name="true"/>
<test name="envelope"/> <test name="envelope"/>
<str>to</str><str>me@example.com</str> <str>to</str><str>me@example.com</str>
</test> </test>
<test name="header"/> <test name="header"/>
<tag>is</tag><str>from</str><str>you@example.com</str> <tag>is</tag><str>from</str><str>you@example.com</str>
</test> </test>
String, number, and tag arguments are represented as "str", "num", String, number, and tag arguments are represented as "str", "num",
and "tag" elements respectively. The actual string, number, or tag and "tag" elements, respectively. The actual string, number, or tag
identifier appears as text inside the element. None of these identifier appears as text inside the element. None of these
elements have any defined attributes. Several examples of arguments elements have any defined attributes. Several examples of arguments
have already appeared in the preceding control, action and test have already appeared in the preceding control, action, and test
examples. Any whitespace in the str body content MUST be preserved examples. Any whitespace in the str body content MUST be preserved
by the processor. Also note that since strings and tags are by the processor. Also, note that since strings and tags are
represented as element text any quotes or other syntactic elements represented as element text, any quotes or other syntactic elements
required in the regular Sieve representation are dropped rather than required in the regular Sieve representation are dropped rather than
being carried over into the XML. being carried over into the XML.
String list arguments are represented as a "list" element which in String list arguments are represented as a "list" element, which in
turn contains one or more str elements. Note that this allows the turn contains one or more str elements. Note that this allows the
distinction between a single string and a string list containing a distinction between a single string and a string list containing a
single string to be preserved. This is not essential since a list single string to be preserved. This is not essential since a list
containing a single string could simply be mapped to a string, but it containing a single string could simply be mapped to a string, but it
seems prudent to maintain the distinction when mapping to and from seems prudent to maintain the distinction when mapping to and from
XML. XML.
Nested command blocks appear as a series of control or action Nested command blocks appear as a series of control or action
elements inside of an outer control or action element. No block elements inside of an outer control or action element. No block
element is needed since an inner command block can only appear once element is needed since an inner command block can only appear once
and only after any arguments, tests, or test-lists. For example: and only after any arguments, tests, or test-lists. For example:
<control name="if"> <control name="if">
<test name="anyof"> <test name="anyof">
<test name="not"> <test name="not">
<test name="exists> <test name="exists">
<list><str>From</str><str>Date</str></list> <list><str>From</str><str>Date</str></list>
</test> </test>
</test> </test>
<test name="header"> <test name="header">
<tag>contains</tag> <tag>contains</tag>
<str>from</str> <str>from</str>
<str>fool@example.edu</str> <str>fool@example.edu</str>
</test> </test>
</test> </test>
<action name="discard"/> <action name="discard"/>
</control> </control>
Sieve comments are mapped to a special "comment" element in XML. Sieve comments are mapped to a special "comment" element in XML.
Both hash and bracketed comments are mapped to the same construct so Both hash and bracketed comments are mapped to the same construct so
the distinction between the two is lost in XML. XML comments are not the distinction between the two is lost in XML. XML comments are not
used because some XML tools do not make it convenient to access used because some XML tools do not make it convenient to access
comment nodes. comment nodes.
Comments are allowed between commands and inside "test" elements. Comments are allowed between commands and inside "test" elements.
But comments aren't allowed directly inside commands - due to But comments aren't allowed directly inside commands -- due to
limitations of XML schema special enclosing "preamble" and limitations of XML Schema, special enclosing "preamble" and
"postamble" elements are needed: "postamble" elements are needed:
<control name="if"> <control name="if">
<preamble> <preamble>
<comment>Check to see if message should be discarded</comment> <comment>Check to see if message should be discarded</comment>
</preamble> </preamble>
<test name="anyof"> <test name="anyof">
<test name="not"> <test name="not">
<test name="exists> <test name="exists">
<list><str>From</str><str>Date</str></list> <list><str>From</str><str>Date</str></list>
</test> </test>
</test> </test>
<test name="header"> <test name="header">
<tag>contains</tag> <tag>contains</tag>
<str>from</str> <str>from</str>
<str>fool@example.edu</str> <str>fool@example.edu</str>
</test> </test>
</test> </test>
<action name="discard"/> <action name="discard"/>
<postamble> <postamble>
<comment>End of discard check</comment> <comment>End of discard check</comment>
</postamble> </postamble>
</control> </control>
4.1. XML Display Directives 4.1. XML Display Directives
Sometimes graphical user interfaces are a convenient way to provide Sometimes graphical user interfaces are a convenient way to provide
sieve management functions to users. These interfaces typically Sieve management functions to users. These interfaces typically
summarize/annotate/group/display sieve script(s) in an intuitive way summarize/annotate/group/display Sieve script(s) in an intuitive way
for end users. for end users.
To do this effectively, the graphical user interface may require To do this effectively, the graphical user interface may require
additional information about the sieve script itself. That additional information about the Sieve script itself. That
information or "meta-data" might include, but is not limited to - a information or "meta-data" might include, but is not limited to, a
sieve name (identifying the current sieve), whether the sieve is Sieve name (identifying the current Sieve), whether the Sieve is
enabled or disabled, the order in which the part of the sieve are enabled or disabled, and the order in which the parts of the Sieve
presented to the user. The graphical user interface may also choose are presented to the user. The graphical user interface may also
to provide mechanisms to allow the user to modify the script. choose to provide mechanisms to allow the user to modify the script.
It is often useful for a graphical user interface to group related It is often useful for a graphical user interface to group related
sieve script elements and provide an interface that display these Sieve script elements and provide an interface that displays these
groups separately so they can be managed as a single object. Some groups separately so they can be managed as a single object. Some
examples include Sieve statements that together provide vacation examples include Sieve statements that together provide vacation
responders, blacklists/whitelists and other types of filtering responders, blacklists/whitelists, and other types of filtering
controls. controls.
Some advanced graphical user interfaces may even provide a natural Some advanced graphical user interfaces may even provide a natural
language representation of a sieve script and/or an advanced language representation of a Sieve script and/or an advanced
interface to present sieve statements directly to the user. interface to present Sieve statements directly to the user.
A graphical user interface may also choose to support only a subset A graphical user interface may also choose to support only a subset
of action commands in the Sieve language (and its extensions) and so of action commands in the Sieve language (and its extensions), and so
a mechanism to indicate the extent of support and characterize the a mechanism to indicate the extent of support and characterize the
relationships between those supported action commands and test (with relationships between those supported action commands and the test
its arguments) is immensely useful and probably required for clients (with its arguments) is immensely useful and probably required for
that may not have complete knowledge of sieve grammar and semantics. clients that may not have complete knowledge of Sieve grammar and
semantics.
The Sieve language contains no mechanisms for indicating how a given The Sieve language contains no mechanisms for indicating how a given
script should be presented in a user interface. The language also script should be presented in a user interface. The language also
does not contain any specific mechanisms to represent other sorts of does not contain any specific mechanisms to represent other sorts of
meta-data about the script. Providing support for such meta-data as meta-data about the script. Providing support for such meta-data as
part of a sieve script is currently totally implementation specific part of a Sieve script is currently totally implementation specific
and is usually done by imposing some type of structure on comments. and is usually done by imposing some type of structure on comments.
However, such information can be represented in XML very easily so it However, such information can be represented in XML very easily, so
makes sense to define a framework to do this as part of the XML it makes sense to define a framework to do this as part of the XML
format. Implementations MAY choose to use structured comments to format. Implementations MAY choose to use structured comments to
retain this information when the script is converted to normal Sieve retain this information when the script is converted to normal Sieve
format. format.
The sample schemata for the XML representation of Sieve allows XML in The sample schemata for the XML representation of Sieve allows XML in
foreign namespaces to be inserted in the same places "comment" foreign namespaces to be inserted in the same places "comment"
elements can appear in Sieve scripts. This is the preferred means of elements can appear in Sieve scripts. This is the preferred means of
including additional information. Alternately, the schema defines including additional information. Alternately, the schema defines
two display directives - displayblock and displaydata - as containers two display directives -- displayblock and displaydata -- as
for meta-data needed by graphical user interfaces. containers for meta-data needed by graphical user interfaces.
Editors MAY use displayblock, displaydata and foreign namespaces to Editors MAY use displayblock, displaydata, and foreign namespaces to
associate meta-data. Some editors find it inconvenient to preserve associate meta-data. Some editors find it inconvenient to preserve
this additional data during an editing session. Editors MAY preserve this additional data during an editing session. Editors MAY preserve
this data during an editing session for compatibility with other this data during an editing session for compatibility with other
editors. editors.
The displayblock element can be used to enclose any number of sieve The displayblock element can be used to enclose any number of Sieve
statements at any level. It is semantically meaningless to the sieve statements at any level. It is semantically meaningless to the Sieve
script itself. It allows an arbitrary set of attributes. script itself. It allows an arbitrary set of attributes.
Implementations MAY use this to provide many simple, display related Implementations MAY use this to provide many simple, display-related
meta-data for the sieve such as sieve identifier, group identifier, meta-data for the Sieve such as Sieve identifier, group identifier,
order of processing, etc. order of processing, etc.
The displaydata element supports any number of arbitrary child The displaydata element supports any number of arbitrary child
elements. Implementations MAY use this to represent complex data elements. Implementations MAY use this to represent complex data
about that sieve such as a natural language representation of sieve about that Sieve such as a natural language representation of Sieve
or a way to provide the sieve script directly. or a way to provide the Sieve script directly.
4.2. Structured Comments 4.2. Structured Comments
Since the XML representation is not intended as a storage format Since the XML representation is not intended as a storage format,
there needs to be a way to preserve the additional information that there needs to be a way to preserve the additional information that
can be included in the XML representation in the normal Sieve syntax. can be included in the XML representation in the normal Sieve syntax.
This is done through the use of three structured comment conventions: This is done through the use of three structured comment conventions:
1. XML content in other namespaces is placed in Sieve bracketed 1. XML content in other namespaces is placed in Sieve bracketed
comments beginning with the string "/* [/" and ending with the comments beginning with the string "/* [/" and ending with the
string "/] */". string "/] */".
2. The content of displaydata elements is placed in Sieve bracketed 2. The content of displaydata elements is placed in Sieve bracketed
comments beginning with the string "/* [|" and ending with the comments beginning with the string "/* [|" and ending with the
string "|] */". string "|] */".
3. The beginning of a displayblock element is mapped to a bracketed 3. The beginning of a displayblock element is mapped to a bracketed
Sieve comment beginning with the string "/* [*" which then lists Sieve comment beginning with the string "/* [*", which then lists
any displayblock attribute names and values in XML format. The any displayblock attribute names and values in XML format. The
end of a displayblock element is mapped to a comment of the form end of a displayblock element is mapped to a comment of the form
"/* *] */". "*] */".
Processors MUST preserve the additional information allowed in the Processors MUST preserve the additional information allowed in the
XML format and SHOULD use the structured comment format shown above. XML format and SHOULD use the structured comment format shown above.
Note: If "*/" is found in the XML content, when mapped into a comment Note: If "*/" is found in the XML content, when mapped into a
it would prematurely terminate that comment. Escaping of this comment, it would prematurely terminate that comment. Escaping this
sequence would often be inconvenient for processors. Editors SHALL sequence would often be inconvenient for processors. Editors SHALL
NOT include "*/" within displayblock, displaydata or foreign markup. NOT include "*/" within displayblock, displaydata, or foreign markup.
Processors MAY regard documents containing "*/" in foreign markup, Processors MAY regard documents containing "*/" in foreign markup,
displayblock or displaydata as invalid. displayblock, or displaydata as invalid.
4.3. Validation 4.3. Validation
A processor MAY validate documents against a schema and MAY reject A processor MAY validate documents against a schema, and it MAY
any which do not conform. For any document that a processor does not reject any that do not conform. For any document that a processor
reject as invalid, any markup that the processor cannot understand by does not reject as invalid, any markup that the processor cannot
reference to this specification MAY be discarded. understand by reference to this specification MAY be discarded.
Note that example Relax NG and XML Schema are given in the appendices Note that example Relax NG and XML Schema are given in the appendices
below. below.
5. Security Considerations 5. Security Considerations
Any syntactically valid sieve script can be represented in XML. Any syntactically valid Sieve script can be represented in XML.
Accordingly, all security considerations applicable to Sieve and any Accordingly, all security considerations applicable to Sieve and any
extensions used also apply to the XML representation. extensions used also apply to the XML representation.
The use of XML carries its own security risks. Section 7 of RFC 3470 The use of XML carries its own security risks. Section 7 of RFC 3470
[RFC3470] discusses these risks. [RFC3470] discusses these risks.
It is axiomatic that a Sieve editor must be trusted to do what the It is axiomatic that a Sieve editor must be trusted to do what the
user specifies. If XML formats are used this trust necessarily must user specifies. If XML formats are used, this trust necessarily must
extend to the components involved in converting to and from XML extend to the components involved in converting to and from XML
format. format.
Arbitrary data can be included using other namespaces or placed in Arbitrary data can be included using other namespaces or placed in
the extensible displayblock and displaydata constructs defined in the extensible displayblock and displaydata constructs defined in
this specification, possibly including entire scripts and other this specification, possibly including entire scripts and other
executable content in languages other than Sieve. Such material will executable content in languages other than Sieve. Such material will
necessarily have its own security considerations, which are beyond necessarily have its own security considerations, which are beyond
the scope of this document. the scope of this document.
skipping to change at page 13, line 25 skipping to change at page 12, line 25
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>Sieve Namespace</title> <title>Sieve Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for Sieve Language objects expressed in XML</h1> <h1>Namespace for Sieve Language objects expressed in XML</h1>
<h2>urn:ietf:params:xml:ns:sieve</h2> <h2>urn:ietf:params:xml:ns:sieve</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfcXXXX.txt"> <p>See <a href="http://www.rfc-editor.org/rfc/rfc5784.txt">
RFC XXXX</a>. RFC 5784</a>.
</p> </p>
</body> </body>
</html> </html>
END END
7. References 7. References
7.1. Normative References 7.1. Normative References
[OASISRNC] [OASISRNC] Clark, J., "RELAX NG Compact Syntax", OASIS Committee
Clark, J., "RELAX NG Compact Syntax", OASIS Committee Specification rnc, November 2002.
Specification rnc, November 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines
the Use of Extensible Markup Language (XML) for the Use of Extensible Markup Language (XML)
within IETF Protocols", BCP 70, RFC 3470, January 2003. within IETF Protocols", BCP 70, RFC 3470, January 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering [RFC5228] Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", RFC 5228, January 2008. Language", RFC 5228, January 2008.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", W3C REC-xml-20081126, November 2008, Edition)", W3C REC-xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126/>. <http://www.w3.org/TR/2008/REC-xml-20081126/>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-sieve-mime-loop] [RFC5183] Freed, N., "Sieve Email Filtering: Environment
Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME Extension", RFC 5183, May 2008.
part Tests, Iteration, Extraction, Replacement and
Enclosure", draft-ietf-sieve-mime-loop (work in progress),
July 2009,
<http://tools.ietf.org/id/draft-ietf-sieve-mime-loop>.
[RFC5183] Freed, N., "Sieve Email Filtering: Environment Extension", [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension",
RFC 5183, May 2008. RFC 5229, January 2008.
[RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering:
RFC 5229, January 2008. Vacation Extension", RFC 5230, January 2008.
[RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: [RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering:
Vacation Extension", RFC 5230, January 2008. Relational Extension", RFC 5231, January 2008.
[RFC5231] Segmuller, W. and B. Leiba, "Sieve Email Filtering: [RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags
Relational Extension", RFC 5231, January 2008. Extension", RFC 5232, January 2008.
[RFC5232] Melnikov, A., "Sieve Email Filtering: Imap4flags [RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress
Extension", RFC 5232, January 2008. Extension", RFC 5233, January 2008.
[RFC5233] Murchison, K., "Sieve Email Filtering: Subaddress [RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest
Extension", RFC 5233, January 2008. Extensions", RFC 5235, January 2008.
[RFC5235] Daboo, C., "Sieve Email Filtering: Spamtest and Virustest [RFC5293] Degener, J. and P. Guenther, "Sieve Email Filtering:
Extensions", RFC 5235, January 2008. Editheader Extension", RFC 5293, August 2008.
[RFC5293] Degener, J. and P. Guenther, "Sieve Email Filtering: [RFC5703] Hansen, T. and C. Daboo, "Sieve Email Filtering: MIME
Editheader Extension", RFC 5293, August 2008. Part Tests, Iteration, Extraction, Replacement, and
Enclosure", RFC 5703, October 2009.
Appendix A. Extended Example Appendix A. Extended Example
The example sieve script given in section 9 of [RFC5228] would be The example Sieve script given in Section 9 of [RFC5228] would be
represented in XML as the following code component: represented in XML as the following code component:
<sieve xmlns="urn:ietf:params:xml:ns:sieve"> <sieve xmlns="urn:ietf:params:xml:ns:sieve">
<comment> <comment>
Example Sieve Filter Example Sieve Filter
Declare any optional features or extensions used by the script Declare any optional features or extensions used by the script
</comment> </comment>
<control name="require"> <control name="require">
<str>fileinto</str> <str>fileinto</str>
</control> </control>
<comment> <comment>
Handle messages from known mailing lists Handle messages from known mailing lists.
Move messages from IETF filter discussion list to filter mailbox Move messages from IETF filter discussion list to filter mailbox.
</comment> </comment>
<control name="if"> <control name="if">
<test name="header"> <test name="header">
<tag>is</tag> <tag>is</tag>
<str>Sender</str> <str>Sender</str>
<str>owner-ietf-mta-filters@imc.org</str> <str>owner-ietf-mta-filters@imc.org</str>
</test> </test>
<action name="fileinto"> <action name="fileinto">
<str>filter</str> <str>filter</str>
</action> </action>
<postamb ,le> <postamble>
<comment>move to "filter" mailbox</comment> <comment>move to "filter" mailbox</comment>
</postamble> </postamble>
</control> </control>
<comment> <comment>
Keep all messages to or from people in my company Keep all messages to or from people in my company.
</comment> </comment>
<control name="elsif"> <control name="elsif">
<test name="address"> <test name="address">
<tag>domain</tag> <tag>domain</tag>
<tag>is</tag> <tag>is</tag>
<list> <list>
<str>From</str> <str>From</str>
<str>To</str> <str>To</str>
</list> </list>
<str>example.com</str> <str>example.com</str>
skipping to change at page 18, line 27 skipping to change at page 17, line 38
<control name="else"> <control name="else">
<action name="fileinto"> <action name="fileinto">
<str>personal</str> <str>personal</str>
</action> </action>
</control> </control>
</displayblock> </displayblock>
</sieve> </sieve>
Note that since displayblock elements are semantically null as far as Note that since displayblock elements are semantically null as far as
the script itself is concerned they can be used to group structures the script itself is concerned, they can be used to group structures
like elsif and else that are tied to statements in other groups. like elsif and else that are tied to statements in other groups.
The representation of this script in regular Sieve syntax uses The representation of this script in regular Sieve syntax uses
structured comments: structured comments:
require "fileinto"; require "fileinto";
/* [* name="File filter list mail" order="1" /* [* name="File filter list mail" order="1"
group="FILE_TO_FOLDER" enable="true" */ group="FILE_TO_FOLDER" enable="true" */
if header :is "Sender" "owner-ietf-mta-filters@imc.org" if header :is "Sender" "owner-ietf-mta-filters@imc.org"
{ {
skipping to change at page 19, line 37 skipping to change at page 19, line 4
fileinto "spam"; fileinto "spam";
} }
/* *] */ /* *] */
/* [* name="File noncompany mail as personal" order="4" /* [* name="File noncompany mail as personal" order="4"
group="FILE_TO_FOLDER" enable="true" */ group="FILE_TO_FOLDER" enable="true" */
else else
{ {
fileinto "personal"; fileinto "personal";
} }
/* *] */ /* *] */
A separate namespace can be used to embed text or structured A separate namespace can be used to embed text or structured
information: information:
<sieve xmlns="urn:ietf:params:xml:ns:sieve" <sieve xmlns="urn:ietf:params:xml:ns:sieve"
xmlns:nls="http://example.com/nls"> xmlns:nls="http://example.com/nls">
<nls:interpretation> <nls:interpretation>
If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org If the email header "Sender" is owner-ietf-mta-filters@imc.org,
then file it into the "filter" folder. then file it into the "filter" folder.
Otherwise if the address in the "From" or "To" has a domain Otherwise, if the address in the "From" or "To" has a domain
that is "example.com" then keep it. that is "example.com", then keep it.
Otherwise messages meeting with any of these conditions: Otherwise, messages meeting with any of these conditions:
(1) None of the addresses in "To" or "Cc" or "Bcc" contains (1) None of the addresses in "To", "Cc", or "Bcc" contain
the domain "example.com". the domain "example.com".
(2) The "Subject" field matches the pattern *make*money*fast* (2) The "Subject" field matches the pattern *make*money*fast*
or *university*dipl*mas* then file it into the "spam" or *university*dipl*mas*, then file it into the "spam"
folder. folder.
If all else fails then file the message in the "personal" If all else fails, then file the message in the "personal"
folder. folder.
</nls:interpretation> </nls:interpretation>
... the actual sieve script ... ... the actual Sieve script ...
</sieve> </sieve>
Alternately, displaydata elements can be used to accomplish the same Alternately, displaydata elements can be used to accomplish the same
thing: thing:
<sieve xmlns="urn:ietf:params:xml:ns:sieve"> <sieve xmlns="urn:ietf:params:xml:ns:sieve">
<displaydata> <displaydata>
<nls-interpretation> <nls-interpretation>
If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org If the email header "Sender" is owner-ietf-mta-filters@imc.org,
then file it into the "filter" folder. then file it into the "filter" folder.
Otherwise if the address in the "From" or "To" has a domain Otherwise, if the address in the "From" or "To" has a domain
that is "example.com" then keep it. that is "example.com", then keep it.
Otherwise messages meeting with any of these conditions: Otherwise, messages meeting with any of these conditions:
(1) None of the addresses in "To" or "Cc" or "Bcc" contains (1) None of the addresses in "To","Cc", or "Bcc" contain
the domain "example.com". the domain "example.com".
(2) The "Subject" field matches the pattern *make*money*fast* (2) The "Subject" field matches the pattern *make*money*fast*
or *university*dipl*mas* then file it into the "spam" or *university*dipl*mas*, then file it into the "spam"
folder. folder.
If all else fails then file the message in the "personal" If all else fails, then file the message in the "personal"
folder. folder.
</nls-interpretation> </nls-interpretation>
</displaydata> </displaydata>
... the actual sieve script ... ... the actual Sieve script ...
</sieve> </sieve>
Again, structured comments are used to represent this in regular Again, structured comments are used to represent this in regular
Sieve syntax: Sieve syntax:
/* [| /* [|
<nls-interpretation> <nls-interpretation>
If the e-mail header "Sender" is owner-ietf-mta-filters@imc.org If the email header "Sender" is owner-ietf-mta-filters@imc.org,
then file it into the "filter" folder. then file it into the "filter" folder.
Otherwise if the address in the "From" or "To" has a domain Otherwise, if the address in the "From" or "To" has a domain
that is "example.com" then keep it. that is "example.com", then keep it.
Otherwise messages meeting with any of these conditions: Otherwise, messages meeting with any of these conditions:
(1) None of the addresses in "To" or "Cc" or "Bcc" contains (1) None of the addresses in "To","Cc", or "Bcc" contain
the domain "example.com". the domain "example.com".
(2) The "Subject" field matches the pattern *make*money*fast* (2) The "Subject" field matches the pattern *make*money*fast*
or *university*dipl*mas* then file it into the "spam" or *university*dipl*mas*, then file it into the "spam"
folder. folder.
If all else fails then file the message in the "personal" If all else fails, then file the message in the "personal"
folder. folder.
</nls-interpretation> </nls-interpretation>
|] */ |] */
... the actual sieve script ... ... the actual Sieve script ...
Appendix B. XML Schema for Sieves in XML Appendix B. XML Schema for Sieves in XML
This appendix is informative. The following code component is an XML This appendix is informative. The following code component is an XML
Schema for the XML representation of Sieve scripts. Most of the Schema for the XML representation of Sieve scripts. Most of the
elements employing a complex content model allow use of elements in elements employing a complex content model allow use of elements in
other namespaces, subject to lax XML Schema validation rules. other namespaces, subject to lax XML Schema validation rules.
Additionally, displaydata elements can be used to encapsulate Additionally, displaydata elements can be used to encapsulate
arbitrary XML content. Finally, displayblock elements can be used as arbitrary XML content. Finally, displayblock elements can be used as
a general-purpose grouping mechanism - arbitrary attributes are a general-purpose grouping mechanism -- arbitrary attributes are
allowed on displayblock elements. allowed on displayblock elements.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:sieve" xmlns="urn:ietf:params:xml:ns:sieve"
targetNamespace="urn:ietf:params:xml:ns:sieve"> targetNamespace="urn:ietf:params:xml:ns:sieve">
<xsd:element name="sieve"> <xsd:element name="sieve">
<xsd:complexType> <xsd:complexType>
skipping to change at page 25, line 23 skipping to change at page 24, line 24
<xsd:any processContents="skip"/> <xsd:any processContents="skip"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:schema> </xsd:schema>
Appendix C. Relax NG Schema for Sieves in XML Appendix C. Relax NG Schema for Sieves in XML
This appendix is informative. The following code component defines a This appendix is informative. The following code component defines a
Relax NG schema using compact notation OASISRNC [OASISRNC] for the Relax NG Schema using compact notation OASISRNC [OASISRNC] for the
XML representation of Sieve scripts. Most of the elements employing XML representation of Sieve scripts. Most of the elements employing
a complex content model allow unrestricted use of elements in other a complex content model allow unrestricted use of elements in other
namespaces. Additionally, displaydata elements can be used to namespaces. Additionally, displaydata elements can be used to
encapsulate arbitrary XML content. Finally, displayblock elements encapsulate arbitrary XML content. Finally, displayblock elements
can be used as a general-purpose grouping mechanism - arbitrary can be used as a general-purpose grouping mechanism -- arbitrary
attributes are allowed on displayblock elements. attributes are allowed on displayblock elements.
namespace sieve = "urn:ietf:params:xml:ns:sieve" namespace sieve = "urn:ietf:params:xml:ns:sieve"
start = element sieve:sieve { ( control | action | displayblock | start = element sieve:sieve { ( control | action | displayblock |
displaydata | comment | ext )* } displaydata | comment | ext )* }
comment = element sieve:comment { xsd:string } comment = element sieve:comment { xsd:string }
ambles = ambles =
skipping to change at page 27, line 5 skipping to change at page 26, line 5
displayblock = displayblock =
element sieve:displayblock element sieve:displayblock
{ {
( control | action | displayblock | ( control | action | displayblock |
displaydata | comment | ext )*, displaydata | comment | ext )*,
attribute * { text }* attribute * { text }*
} }
displaydata = element sieve:displaydata { any* } displaydata = element sieve:displaydata { any* }
Appendix D. Stylesheet for conversion from XML Appendix D. Stylesheet for Conversion from XML
This appendix is informative. The following code component is a This appendix is informative. The following code component is a
stylesheet that can be used to convert the Sieve in XML stylesheet that can be used to convert the Sieve in XML
representation to regular Sieve format. Content in other namespaces, representation to regular Sieve format. Content in other namespaces,
displaydata, and displayblock elements are converted to structured displaydata, and displayblock elements are converted to structured
comments as appropriate. comments as appropriate.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<!-- Convert Sieve in XML to standard Sieve syntax --> <!-- Convert Sieve in XML to standard Sieve syntax -->
skipping to change at page 33, line 26 skipping to change at page 32, line 26
Authors' Addresses Authors' Addresses
Ned Freed Ned Freed
Sun Microsystems Sun Microsystems
800 Royal Oaks 800 Royal Oaks
Monrovia, CA 91016-6347 Monrovia, CA 91016-6347
USA USA
Phone: +1 909 457 4293 Phone: +1 909 457 4293
Email: ned.freed@mrochek.com EMail: ned.freed@mrochek.com
Srinivas Saisatish Vedam Srinivas Saisatish Vedam
Sun Microsystems Sun Microsystems
Phone: +91 80669 27577 Phone: +91 80669 27577
Email: Srinivas.Sv@Sun.COM EMail: Srinivas.Sv@Sun.COM
 End of changes. 124 change blocks. 
276 lines changed or deleted 218 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/