Sieve Email Filtering: Sieves and Display Directives in XML
Extracted elements (24)
Comments must be preserved in the XML representation because one important use case is encoding metadata about a Sieve script, a facility otherwise lacking in the Sieve language.
Controls and actions are represented as 'control' or 'action' elements with a name attribute rather than using the command name as the element name, because naming elements after commands would require frequent schema changes to accommodate extensions.
The XML representation can accommodate any future Sieve extension without schema changes as long as the underlying Sieve grammar remains unchanged; only new control commands require changes to the Sieve-to-XML converter, and these are rare.
The XML representation is intended not as an alternate storage format for Sieve but as a means to facilitate manipulation of scripts using XML tools, enabling different front-end user interfaces to work with different back-end mapping and storage facilities.
The ability for different front ends to share the same mapping and storage facilities does not mean that display directive XML produced by different front ends will interoperate with each other.
Unknown controls encountered during Sieve-to-XML conversion are treated as actions; while this may cause semantic issues, the conversion can pass such constructs through both representations since knowledge of a control's semantics is almost always needed to exploit it.
A processor MAY validate documents against a schema and MAY reject non-conforming documents; for documents not rejected, any markup the processor cannot understand MAY be discarded.
Any whitespace in the body content of 'str' elements MUST be preserved by the processor.
Editors SHALL NOT include the string '*/' within displayblock, displaydata, or foreign markup because it would prematurely terminate a bracketed Sieve comment when the XML is converted to normal Sieve format.
Implementations MAY choose to use structured comments to retain display directive information when converting to normal Sieve format; editors MAY preserve this data during an editing session for compatibility.
Processors MUST preserve the additional information allowed in the XML format (display directives and foreign namespaces) and SHOULD use the structured comment format when converting to normal Sieve.
A Sieve script is represented as a root 'sieve' element in the namespace 'urn:ietf:params:xml:ns:sieve', containing zero or more control, action, displayblock, displaydata, comment, or foreign-namespace elements.
'preamble' and 'postamble' elements wrap comment content that appears before or after arguments/tests inside a command element, due to XML Schema limitations that prevent comments from appearing directly inside commands.
Sieve comments (both hash and bracketed) map to a 'comment' element; XML comments are not used because some XML tools do not make comment nodes conveniently accessible.
Sieve controls and actions map to 'control' and 'action' XML elements respectively, each with a required 'name' attribute holding the command identifier; arguments, tests, and nested command blocks appear as nested child elements.
String list arguments are represented as a 'list' element containing one or more 'str' elements, preserving the distinction between a single string and a single-element string list.
Tests are represented as 'test' elements with a required 'name' attribute; string, number, and tag arguments appear as 'str', 'num', and 'tag' child elements respectively, and subordinate tests appear as nested 'test' elements.
The 'displayblock' element encloses any number of Sieve statements and carries arbitrary attributes for GUI metadata such as name, order, group, and enable; it is semantically meaningless to the Sieve script itself.
The 'displaydata' element supports any number of arbitrary child elements and is used to represent complex metadata about a Sieve script, such as natural language descriptions.
This document registers the XML namespace 'urn:ietf:params:xml:ns:sieve' in the IETF XML Registry per RFC 3688, with registrant contact being the IETF Sieve working group.
A Sieve editor must be trusted to do what the user specifies; when XML formats are used, this trust necessarily extends to the components involved in converting to and from XML format.
Any syntactically valid Sieve script can be represented in XML, so all security considerations for Sieve and its extensions apply equally to the XML representation; the use of XML also carries additional risks described in RFC 3470 Section 7.
Arbitrary data, including entire scripts and other executable content in languages other than Sieve, can be included via foreign namespaces or the extensible displayblock and displaydata constructs; such material has its own security considerations beyond this document's scope.
Foreign-namespace XML content is encoded in Sieve bracketed comments delimited by '/* [/' and '/] */'; displaydata content uses '/* [|' and '|] */'; displayblock start uses '/* [*' followed by attribute name-value pairs in XML format, and end uses '/* *] */'.