One document matched: draft-ietf-sieve-notify-09.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<!-- !ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml' -->
<!-- ?xml-stylesheet type='text/xsl' href='http://xml.resource.org/authoring/rfc2629.xslt' ? -->
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocompact="no" ?>
<?rfc tocindent="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std"
ipr="full3978"
docName="draft-ietf-sieve-notify-09">
<front>
<!--An alternative title: SIEVE Email Filtering Extension: Notifications-->
<title>SIEVE Email Filtering: Notifications</title>
<author initials='A.' surname="Melnikov" fullname="Alexey Melnikov" role="editor">
<organization>Isode Limited</organization>
<address>
<postal>
<street>5 Castle Business Village</street>
<street>36 Station Road</street>
<city>Hampton</city>
<region>Middlesex</region>
<code>TW12 2BX</code>
<country>UK</country>
</postal>
<email>Alexey.Melnikov@isode.com</email>
</address>
</author>
<author initials='B.' surname="Leiba" fullname="Barry Leiba" role="editor">
<organization>IBM T.J. Watson Research Center</organization>
<address>
<postal>
<street>19 Skyline Drive</street>
<city>Hawthorne</city>
<region>NY</region>
<code>10532</code>
<country>US</country>
</postal>
<phone>+1 914 784 7941</phone>
<email>leiba@watson.ibm.com</email>
</address>
</author>
<author initials='W.' surname="Segmuller" fullname="Wolfgang Segmuller">
<organization>IBM T.J. Watson Research Center</organization>
<address>
<postal>
<street>19 Skyline Drive</street>
<city>Hawthorne</city>
<region>NY</region>
<code>10532</code>
<country>US</country>
</postal>
<phone>+1 914 784 7408</phone>
<email>werewolf@us.ibm.com</email>
</address>
</author>
<author initials='T.' surname="Martin" fullname="Tim Martin">
<organization>BeThereBeSquare Inc.</organization>
<address>
<postal>
<street>672 Haight st.</street>
<city>San Francisco</city>
<region>CA</region>
<code>94117</code>
<country>US</country>
</postal>
<phone>+1 510 260-4175</phone>
<email>timmartin@alumni.cmu.edu</email>
</address>
</author>
<date year="2007"/>
<area>Applications</area>
<workgroup>Sieve Working Group</workgroup>
<keyword>Sieve</keyword>
<keyword>email</keyword>
<keyword>filter</keyword>
<keyword>notify</keyword>
<keyword>notification</keyword>
<abstract>
<t>
Users go to great lengths to be notified as quickly as possible that
they have received new mail. Most of these methods involve polling
to check for new messages periodically. A push method handled by the
final delivery agent gives users quicker notifications and saves
server resources. This document does not specify the notification
method but it is expected that using existing instant messaging
infrastructure such as XMPP, or SMS messages will be popular.
This draft describes an extension to the Sieve mail filtering
language that allows users to give specific rules for how and when
notifications should be sent.
</t>
</abstract>
<note title="Changes since draft-ietf-sieve-notify-08">
<t><list style="symbols">
<t>Added missing IANA registry for notification methods.</t>
</list></t>
</note>
<note title="Changes since draft-ietf-sieve-notify-07">
<t><list style="symbols">
<t>Added a new "set" modifier for URL percent-encoding.</t>
<t>Clarified that notification methods must address notification loops.</t>
<t>Added an implementation consideration for implementations that use URIs internally.</t>
</list></t>
</note>
<note title="Changes since draft-ietf-sieve-notify-06">
<t><list style="symbols">
<t>Remove extract_text. The WG consensus was to move it to another document, such as Sieve MIME loops.</t>
<t>Deleted markers for open issues from the document.</t>
<t>Clarified that a notification mechanism can treat some URI parameters as an error.</t>
<t>Added notify_method_capability test and example.</t>
<t>Minor corrections to the IANA registration as a result of other changes.</t>
</list></t>
</note>
<note title="Changes since draft-ietf-sieve-notify-05">
<t><list style="symbols">
<t>Fixed XMPP URI in one example.</t>
<t>Addressed Michael's issue with how timestamp are described.</t>
<t>Renamed "valid_notif_method" to "valid_notify_method".</t>
<t>Added text about truncation of a textual part when it is stored in a variable using extract_text.</t>
<t>Changed tagged :method argument to positional argument.</t>
<t>Added text about notification throttling, identifying notification source and restricting values of the :from parameter.</t>
<t>Added a requirement on documents describing notification methods to list which URI parameters must be ignored.</t>
</list></t>
</note>
<note title="Changes since draft-ietf-sieve-notify-04">
<t><list style="symbols">
<t>Made notification method required.</t>
<t>Defined "mailto" as a mandatory-to-implement method.</t>
<t>Added normative reference to mailto.</t>
<t>Clarified that :importance may be treated as a transport indicator.</t>
<t>Clarified that :importance value can be included in the default :message, if one is not specified.</t>
<t>Made the default :message implementation specific.</t>
<t>Renamed the capability name from "notify" to "enotify"</t>
<t>Updated IANA registration.</t>
<t>Moved text about ManageSieve capability to the ManageSieve document itself.</t>
<t>Removed reference to IANA registry for options.</t>
<t>Some miscellaneous text cleanup and clarification.</t>
</list></t>
</note>
<note title="Changes since draft-ietf-sieve-notify-03">
<t><list style="symbols">
<t>Added a warning that "notify" must not be used as a crappy form of "redirect".</t>
<t>Added a warning about using "notify" to forward confidential information in order to bypass organization's policy.</t>
<t>Fixed syntax of the :options argument - it is a string list, each string containing "<attribute>=<value>"</t>
<t>Renamed :priority to :importance</t>
<t>Cleaned up section about requirements on methods.</t>
</list></t>
</note>
<note title="Changes since draft-ietf-sieve-notify-02">
<t><list style="symbols">
<t>Added :from tagged argument.</t>
<t>Added Extract_text action, which allows to extract content of the first text/* part.</t>
<t>Added back the ":options" parameter to the notify action.</t>
<t>Added new section talking about requirements on notification method specs.</t>
<t>Added more examples.</t>
</list></t>
</note>
<note title="Changes since draft-ietf-sieve-notify-00">
<t><list style="symbols">
<t>Updated references, etc.</t>
<t>Added IANA considerations section.</t>
<t>Removed denotify action.</t>
<t>Updated examples to use the variables extension.</t>
<t>Replaced notification method with URI.</t>
<t>Removed text suggesting that this extension can be used to track all Sieve actions taken.</t>
<t>Changed priority to be a string.</t>
<t>Added text about URI verification.</t>
<t>Clarified that a notification method is allowed to perform adaptation of notification context (e.g. truncation, charset conversion, etc.). These adaptations must be documented in a document describing the notification method.</t>
<t>Clarified that notify is compatible with all existing actions.</t>
<t>Removed the :id parameter to the notify action.</t>
<t>Added valid_notif_method test that allows to test if an notification method (URI) is supported.</t>
<t>Added a new capability response to ManageSieve that allows to report supported notification types.</t>
</list></t>
</note>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
This is an extension to the Sieve language defined by <xref target="Sieve"/> for
providing instant notifications. It defines the new action "notify".
</t>
<t>
This document does not specify the notification methods.
Examples of possible notification methods are email and XMPP.
To allow a mechanism for portability of scripts that use notifications,
implementation of the <xref target="MailTo"/> method is mandatory.
Other available methods shall depend upon the implementation and configuration of the system.
</t>
<section title="Conventions used in this document">
<t>
Conventions for notations are as in <xref target="Sieve"/> section 1.1, including
the use of <xref target="ABNF"/>.
</t>
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="Kwds"/>.
</t>
</section>
</section>
<section anchor="capability" title="Capability Identifier">
<t>
The capability string associated with the extension defined in this
document is "enotify".
</t>
</section>
<section anchor="notify-action" title="Notify Action">
<section anchor="syntax" title="Notify Action Syntax and Semantics">
<t>
<list style="hanging" hangIndent="8">
<t hangText="Usage:">
notify [":from" string]<vspace/>
[":importance" <"1" / "2" / "3">]<vspace/>
[":options" string-list]<vspace/>
[":message" string]<vspace/>
<method: string>
</t>
</list>
</t>
<t>
The Notify action specifies that a notification should be sent to
a user.
The format of the notification is implementation-defined and
is also affected by the notification method used (see <xref target="tag-method"/>).
However, all content specified in the :message parameter SHOULD be included.
</t>
</section>
<section anchor="tag-method" title='Notify parameter "method"'>
<t>
The method positional parameter identifies the notification method that will be
used; it is a URI <xref target="URI"/>.
For example, the notification method can
be an SMS URI <xref target="SMS-URI"/> containing a phone number,
or an XMPP <xref target="XMPP"/> URI containing an XMPP
identifier <xref target="XMPP-URI"/>.
</t>
<t>
The supported URI values will be site-specific, but support for the
<xref target="MailTo"/> method is REQUIRED in order to insure interoperability.
If a URI schema is
specified that the implementation does not support, the notification
MUST cause an error condition. Sieve scripts can check the supported
methods using the "valid_notify_method" test to be sure that they only use
supported ones, to avoid such error conditions.
</t>
<t>
If the method parameter contains a supported URI schema, then the URI MUST
be checked for syntactic validity. An invalid URI syntax or an unsupported URI
extension MUST cause an error. An implementation MAY enforce
other semantic restrictions on URIs -- for example an SMS URI can only
contain phone numbers in a particular geographical region -- and will treat
violations of such semantic restrictions as errors.
</t>
</section>
<section anchor="tag-from" title='Notify tag ":from"'>
<t>A ":from" parameter may be used to specify an author of the notification.
The syntax of this parameter's value is method-specific.
Implementations SHOULD check the
syntax according to the notification method specification
and generate an error when a syntactically invalid ":from"
parameter is specified.
In order to minimize/prevent forgery of the author value,
implementations SHOULD impose restrictions on what values can specified
in a ":from" parameter; it is suggested that values which fail
such a validity check simply be ignored rather than causing
the notify action to fail.
</t>
</section>
<section anchor="tag-importance" title='Notify tag ":importance"'>
<t>
The :importance tag specifies the importance of the delivery of the notification.
The :importance tag is followed by a numeric value represented
as a string: "1" (high importance), "2" (normal importance),
and "3" (low importance). If no importance is given,
the default value "2" SHOULD be assumed.
A notification method can treat the importance value as a transport indicator.
For example, it might deliver notifications of high importance quicker
than notifications of normal or low importance.
Some notification methods allow users to specify their
state of activity (for example "busy" or "away from keyboard"). If
the notification method provides this information it SHOULD be used
to selectively send notifications. If, for example, the user marks
herself as "busy", a notification method can require that
a notification with importance of "3" is not to be sent,
however the user should be notified of a notification with higher importance.
</t>
<t>
If the notification method allows users to filter messages based upon
certain parameters in the message, users SHOULD be able to filter
based upon importance. If the notification method does not support
importance, then this parameter MUST be ignored. An implementation
MAY include the importance value in the default message <xref target="tag-message"/>,
if one is not provided.
</t>
</section>
<section anchor="tag-options" title='Notify tag ":options"'>
<t>
The :options tag is used to send additional parameters to the notification
method. Interpretation of the parameters is method-specific. This document
doesn't specify any such additional parameter.
</t>
<t>Each string in the options string list has the following syntax:<vspace/>
"<optionname>=<value>"
<!--cref:
Should we say something about implementation prefix for implementation
specific options? Something like "x-Vendor-zzz". If we don't say it now,
it might be too late to say it later.-->
</t>
</section>
<section anchor="tag-message" title='Notify tag ":message"'>
<t>
The :message tag specifies the message data to be included in the
notification. The entirety of the string SHOULD be sent but
implementations MAY shorten the message for technical or aesthetic
reasons. If the message parameter is absent, a default
implementation-specific message is used. Unless specified otherwise by a particular
notification mechanism, an implementation default containing
at least the value of the "From" header field and the value of the
"Subject" header field is RECOMMENDED.
</t>
<t>
In order to construct more complex messages
the notify extension can be used together with the Sieve variables
extension <xref target="Variables"/>, as shown in the examples below.
</t>
</section>
<section anchor="examples" title='Examples'>
<t>
<figure>
<artwork><![CDATA[
Example 1:
require ["enotify", "fileinto", "variables"];
if header :contains "from" "boss@example.org" {
notify :importance "1"
:message "This is probably very important"
"mailto:alm@example.com";
# Don't send any further notifications
stop;
}
if header :contains "to" "sievemailinglist@example.org" {
# :matches is used to get the value of the Subject header
if header :matches "Subject" "*" {
set "subject" "${1}";
}
# :matches is used to get the value of the From header
if header :matches "From" "*" {
set "from" "${1}";
}
notify :importance "3"
:message "[SIEVE] ${from}: ${subject}"
"mailto:alm@example.com";
fileinto "INBOX.sieve";
}
]]></artwork>
</figure>
</t>
<t>
<figure>
<artwork><![CDATA[
Example 2:
require ["enotify", "fileinto", "variables", "envelope"];
if header :matches "from" "*@*.example.org" {
# :matches is used to get the MAIL FROM address
if envelope :all :matches "from" "*" {
set "env_from" " [really: ${1}]";
}
# :matches is used to get the value of the Subject header
if header :matches "Subject" "*" {
set "subject" "${1}";
}
# :matches is used to get the address from the From header
if address :matches :all "from" "*" {
set "from_addr" "${1}";
}
notify :message "${from_addr}${env_from}: ${subject}"
"mailto:alm@example.com";
}
]]></artwork>
</figure>
</t>
<t>
<figure>
<artwork><![CDATA[
Example 3:
require ["enotify", "variables"];
set "notif_method"
"xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail";
if header :contains "subject" "Your dog" {
set "notif_method" "sms:+14085551212";
}
if header :contains "to" "sievemailinglist@example.org" {
set "notif_method" "";
}
if not string :is "${notif_method}" "" {
notify "${notif_method}";
}
if header :contains "from" "boss@example.org" {
# :matches is used to get the value of the Subject header
if header :matches "Subject" "*" {
set "subject" "${1}";
}
# don't need high importance notification for
# a 'for your information'
if not header :contains "subject" "FYI:" {
notify :importance "1" :message "BOSS: ${subject}"
"sms:+14085551212";
}
}
]]></artwork>
</figure>
</t>
</section>
<section anchor="method-reqs" title='Requirements on notification methods specifications'>
<t>This section describes requirements for documents that define specific
Sieve notification methods.
</t>
<t>A notification method MAY allow modification of the
final notification text -- for example, truncating it if it exceeds
a length limit, or modifying characters that can not be represented
in the target character set. Characters in the notification text
which can't be represented by the notification method SHOULD be
replaced with a symbol indicating an unknown character.
Allowed modifications MUST be documented
in the document describing the notification method.</t>
<t>A notification method MAY ignore parameters specified in the Notify
action.</t>
<t>A notification method MAY recommend the default message value to be
used if the :message argument is not specified.</t>
<t>Notifications SHOULD include timestamps, if the notification method allows
for their transmission outside of the textual message. Implementation methods
which can only transmit timestamps in the textual message MAY include them
in the textual message.</t>
<t>A notification SHOULD include means to identify/track its origin, in order
to allow a recipient to stop notifications or find out how to contact the sender.
This requirement is to help tracking a misconfigured or abusive origin of
notifications.</t>
<t>Methods SHOULD NOT include any other extraneous information not
specified in parameters to the notify action.</t>
<t>Methods MUST specify which URI parameters (if any) must be ignored,
which ones must be used in the resulting notification and which ones
must cause an error.</t>
<t>Methods MUST specify what values are returned by the notify_method_capability
test <xref target="capas"/>.</t>
<t>If there are errors sending the notification, the Sieve interpreter
SHOULD ignore the notification and not retry indefinitely.
The Sieve interpreter MAY throttle notifications; if it does,
a request to send a notification can be silently ignored.
Documents describing notification methods SHOULD describe how
retries, throttling, duplicate suppression (if any), etc. are
to be handled by implementations.
</t>
</section>
</section>
<section anchor="valid" title="Test valid_notify_method">
<t>
<list style="hanging" hangIndent="8">
<t hangText="Usage:">
valid_notify_method <notification-uris: string-list>
</t>
</list>
</t>
<t>
The "valid_notify_method" test is true if the notification methods listed in the notification-uris
argument are supported and they are syntactically (including URI parameters) and semantically (including implementation-specific
semantic restrictions) valid. This test MUST perform exactly the same validation as would be performed
on the "method" parameter to the "notify" action.
</t>
<t>
The test is true only if ALL of the listed notification methods are supported and valid.
</t>
<t>
<figure>
<artwork>
<![CDATA[
Example 4 (partial):
if not valid_notify_method ["mailto:",
"http://gw.example.net/notify?test"] {
stop;
}
]]></artwork>
</figure>
</t>
</section>
<section anchor="capas" title="Test notify_method_capability">
<t>
<list style="hanging" hangIndent="8">
<t hangText="Usage:">
notify_method_capability [COMPARATOR] [MATCH-TYPE]<vspace/>
<notification-uri: string><vspace/>
<notification-capability: string><vspace/>
<key-list: string-list>
</t>
</list>
</t>
<t>
The "notify_method_capability" test retrieves the notification capability
specified by the notification-capability string that is specific to the
notification-uri and matches it to the values specified
in the key-list. The test succeeds if a match occurs. The type of
match defaults to ":is" and the default comparator is "i;ascii-casemap".
</t>
<t>The notification-capability is case insensitive.</t>
<t>
The notify_method_capability test MUST fail unconditionally if the specified
notification-uri is syntactically invalid (as determined by the valid_notify_method
test <xref target="valid"/>) or specifies an unsupported notification
method. However this MUST NOT cause an error.
</t>
<t>
The notify_method_capability test MUST fail unconditionally if the specified
notification-capability item does not exist. A script MUST NOT fail with an
error if the item does not exist. This allows scripts to be written
that handle nonexistent items gracefully.
</t>
<t>
This document defines a single notification-capability value "online",
which is described below. Additional notification-capability values may
be defined by a Standard Track or Experimental RFC.
</t>
<t>
For the "online" notification-capability the notify_method_capability test
can match one of the following key-list values:
</t>
<t><list style="symbols">
<t>"yes" - the entity identified by the notification-uri can receive a notify
notification immediately.
Note that even after this value is returned, there is no guaranty that the entity
would actually be able to receive any notification immediately or even receive
it at all. Transport errors, recipient policy, etc. can prevent that.</t>
<t>"no" - the entity identified by the notification-uri is not currently available
to receive an immediate notification.
<!--cref: However the entity may receive the notification when it becomes available.-->
</t>
<t>"maybe" - Sieve interpreter can't determine if the the entity identified by
the notification-uri is online or not.</t>
</list></t>
<t>
The "relational" extension <xref target="Relational"/> adds a match type
called ":count". The count of an notify_method_capability test is 0 if the
returned information is the empty string, or 1 otherwise.
</t>
<t>
<figure>
<artwork>
<![CDATA[
Example 5:
require ["enotify"];
if notify_method_capability
"xmpp:tim@example.com?message;subject=SIEVE"
"Online"
"yes" {
notify :importance "1" :message "You got mail"
"xmpp:tim@example.com?message;subject=SIEVE";
} else {
notify :message "You got mail" "sms:+14085551212";
}
]]></artwork>
</figure>
</t>
</section>
<section anchor="url_escape" title="Modifier encodeurl to the 'set' action">
<t>
<list style="hanging" hangIndent="8">
<t hangText="Usage:">
":encodeurl"
</t>
</list>
</t>
<t>When the Sieve script specifies both "variables" <xref target="Variables"/>
and "enotify" capabilities in the "require", a new "set" action modifier
(see <xref target="Variables"/>) ":encodeurl" becomes available to Sieve
scripts. This modifier performs percent-encoding of any octet in the string
which doesn't belong to the "unreserved" set (see <xref target="URI"/>).
The percent-encoding procedure is described in <xref target="URI"/>.
</t>
<t>The ":encodeurl" modifier has precedence 15.
</t>
<t>
<figure>
<artwork>
<![CDATA[
Example 6:
require ["enotify", "variables"];
set :encodeurl "body_param" "Safe body&evil=evilbody";
notify "mailto:tim@example.com?body=${body_param}";
]]></artwork>
</figure>
</t>
</section>
<section anchor="interactions" title="Interactions with Other Sieve Actions">
<t>
The notify action is compatible with all other actions, and does not
affect the operation of other actions. In particular,
the notify action MUST NOT cancel the implicit keep.
</t>
<t>
Multiple executed notify actions are allowed.
Specific notification methods MAY allow multiple notifications
from the same script to be collapsed into one.
</t>
</section>
<section anchor="security" title="Security Considerations">
<t>
Security considerations are discussed in <xref target="Sieve"/>.
Additionally,
implementations must be careful to follow the security
considerations of the specific notification methods.
</t>
<t>
The notify action is potentially very dangerous. The path the
notification takes through the network may not be secure. An error
in the options string may cause the message to be transmitted to
someone it was not intended for, or may expose information to
eavesdroppers.
</t>
<t>
Just because a notification is received doesn't mean that
it was sent by the Sieve implementation. It might be possible to forge
notifications with some notification methods.
</t>
<t>
An organization may have a policy about the forwarding of classified
information to unclassified networks. Unless the policy is also enforced
in the module responsible for generating (or sending) of notifications,
users can use the extension defined in this document to extract classified
information and bypass the policy.
</t>
<t>
Notifications can result in loops and bounces.
<!--cref: Michael suggested to delete this example-->In particular,
a notification to an email address will not contain necessary Received
header fields that might be otherwise used to prevent mail loops.
All notification methods MUST take care to provide mechanisms for
avoiding notification loops.
</t>
<t>Implementations that construct URIs internally from various notify
parameters MUST make sure that all components of such URIs are
properly percent-encoded (see <xref target="URI"/>). In particular
this applies to values of the :from and the :message tagged arguments
and may apply to the :options values.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<section title="Registration of Sieve extension">
<t>
The following template specifies the IANA registration of the
notify Sieve extension specified in this document:
</t>
<t>
To: iana@iana.org
<vspace/>
Subject: Registration of new Sieve extension
<vspace/>
Capability name: enotify
<vspace/>
Description: adds the 'notify' action for notifying user about
the received message. It also provides two new test:
valid_notify_method checks notification URIs for validity;
notify_method_capability can check recipients capabilities.
<vspace/>
RFC number: this RFC
<vspace/>
Contact address:
<vspace/>
The Sieve discussion list <ietf-mta-filters@imc.org>
</t>
<t>
This information should be added to the list of sieve extensions
given on http://www.iana.org/assignments/sieve-extensions.
</t>
</section>
<section title="New registry for Sieve notification mechanisms">
<t>
This defines the template for a new registry for Sieve notification mechanisms,
to be created as http://www.iana.org/assignments/sieve-notification. There are
no initial entries for this registry.
</t>
<t>
To: iana@iana.org
<vspace/>
Subject: Registration of new Sieve notification mechanism
<vspace/>
Mechanism name: [the name of the mechanism]
<vspace/>
Mechanism URI: [the RFC number of the document that defines the URI used by
this mechanism]
<vspace/>
Mechanism-specific tags: [the names of any Sieve notify tags that are specific to
this mechanism, or "none"]
<vspace/>
Standards Track/IESG-approved experimental RFC number: [the RFC number of the document
that defines this notification mechanism]
<vspace/>
Person and email address to contact for further information: [the name and email
address of the technical contact for information about this mechanism]
<vspace/>
</t>
</section>
</section>
<section anchor="acknowledgements" title="Acknowledgements">
<t>
Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter,
Cyrus Daboo, Nigel Swinson, Kjetil Torgrim Homme,
Michael Haardt, Mark E. Mallett, Ned Freed, Lisa Dusseault,
Dilyan Palauzov, Arnt Gulbrandsen and Peter Saint-Andre
for help with this document.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="Kwds">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997" />
</front>
<seriesInfo name="RFC" value="2119" />
</reference>
<reference anchor="ABNF">
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
<organization>Internet Mail Consortium</organization>
</author>
<author initials="P." surname="Overell" fullname="Paul Overell">
<organization>Demon Internet Ltd.</organization>
</author>
<date month="October" year="2005" />
</front>
<seriesInfo name="RFC" value="4234" />
</reference>
<reference anchor="Sieve">
<front>
<title>Sieve: An Email Filtering Language</title>
<author initials="P." surname="Guenther" fullname="Philip Guenther">
<organization>Sendmail, Inc.</organization>
</author>
<author initials="T." surname="Showalter" fullname="Tim Showalter">
<organization />
</author>
<date month="August" year="2006" />
</front>
<seriesInfo name="work in progress," value="draft-ietf-sieve-3028bis" />
</reference>
<reference anchor="Relational">
<front>
<title>Sieve Extension: Relational Tests</title>
<author initials="W." surname="Segmuller" fullname="Wolfgang Segmuller">
<organization>IBM T.J. Watson Research Center</organization>
</author>
<author initials="B." surname="Leiba" fullname="Barry Leiba">
<organization>IBM T.J. Watson Research Center</organization>
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="work in progress," value="draft-ietf-sieve-3431bis" />
</reference>
<reference anchor="Variables">
<front>
<title>Sieve Extension: Variables</title>
<author initials="K." surname="Homme" fullname="Kjetil Torgrim Homme">
<organization>University of Oslo</organization>
</author>
<date month="December" year="2005" />
</front>
<seriesInfo name="work in progress," value="draft-ietf-sieve-variables" />
</reference>
<reference anchor="MailTo">
<front>
<title>Sieve Notification Mechanism: mailto</title>
<author initials="B." surname="Leiba" fullname="Barry Leiba">
<organization>IBM T.J. Watson Research Center</organization>
</author>
<author initials="M." surname="Haardt" fullname="Michael Haardt">
<organization>freenet.de AG</organization>
</author>
<date month="October" year="2006" />
</front>
<seriesInfo name="work in progress," value="draft-ietf-sieve-notify-mailto" />
</reference>
<reference anchor="URI">
<front>
<title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
<organization abbrev="W3C/MIT">World Wide Web Consortium</organization>
</author>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="Day Software">Day Software</organization>
</author>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization abbrev="Adobe Systems">Adobe Systems Incorporated</organization>
</author>
<date year="2005" month="January"/>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<format type="TXT" octets="141811" target="ftp://ftp.isi.edu/in-notes/rfc3986.txt"/>
<format type="HTML" octets="200858" target="http://xml.resource.org/public/rfc/html/rfc3986.html"/>
<format type="XML" octets="165759" target="http://xml.resource.org/public/rfc/xml/rfc3986.xml"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="XMPP">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials="P." surname="Saint-Andre, Ed." fullname="Peter Saint-Andre">
<organization>Jabber Software Foundation</organization>
</author>
<date month="October" year="2004" />
</front>
<seriesInfo name="RFC" value="3920" />
</reference>
<reference anchor="XMPP-URI">
<front>
<title>Internationalized Resource Identifiers (IRIs) and Uniform
Resource Identifiers (URIs) for the Extensible Messaging and
Presence Protocol (XMPP)</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Jabber Software Foundation</organization>
</author>
<date month="September" year="2005" />
</front>
<seriesInfo name="work in progress," value="draft-saintandre-xmpp-iri" />
</reference>
<reference anchor="SMS-URI">
<front>
<title>URI scheme for GSM Short Message Service</title>
<author initials="E." surname="Wilde" fullname="E. Wilde">
<organization>Swiss Federal Institute of Technology</organization>
</author>
<author initials="A." surname="Vaha-Sipila" fullname="A. Vaha-Sipila">
<organization>Nokia</organization>
</author>
<date month="August" year="2005" />
</front>
<seriesInfo name="work in progress," value="draft-wilde-sms-uri" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:11:41 |