< draft-ietf-sieve-notify-11.txt   draft-ietf-sieve-notify-12.txt >
Sieve Working Group A. Melnikov, Ed. Sieve Working Group A. Melnikov, Ed.
Internet-Draft Isode Limited Internet-Draft Isode Limited
Intended status: Standards Track B. Leiba, Ed. Intended status: Standards Track B. Leiba, Ed.
Expires: June 9, 2008 W. Segmuller Expires: June 26, 2008 W. Segmuller
IBM T.J. Watson Research Center IBM T.J. Watson Research Center
T. Martin T. Martin
BeThereBeSquare Inc. BeThereBeSquare Inc.
December 7, 2007 December 24, 2007
SIEVE Email Filtering: Extension for Notifications SIEVE Email Filtering: Extension for Notifications
draft-ietf-sieve-notify-11 draft-ietf-sieve-notify-12
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 38 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 9, 2008. This Internet-Draft will expire on June 26, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
Users go to great lengths to be notified as quickly as possible that Users go to great lengths to be notified as quickly as possible that
they have received new mail. Most of these methods involve polling they have received new mail. Most of these methods involve polling
to check for new messages periodically. A push method handled by the to check for new messages periodically. A push method handled by the
final delivery agent gives users quicker notifications and saves final delivery agent gives users quicker notifications and saves
server resources. This document does not specify the notification server resources. This document does not specify the notification
method but it is expected that using existing instant messaging method but it is expected that using existing instant messaging
infrastructure such as XMPP, or SMS messages will be popular. This infrastructure such as XMPP, or GSM Short Message Service (SMS)
draft describes an extension to the Sieve mail filtering language messages will be popular. This draft describes an extension to the
that allows users to give specific rules for how and when Sieve mail filtering language that allows users to give specific
notifications should be sent. rules for how and when notifications should be sent.
Changes since draft-ietf-sieve-notify-11
o [As per DISCUSS from Cullen] Changed a SHOULD to a MUST in the
following requirement: A notification SHOULD include means to
identify/track its origin.
o [As per DISCUSS from Cullen] Changed sms: URIs to tel: URIs.
o [As per COMMENT from Chris] Updated the notify mechanism IANA
registration template to allow for specifications which are not
RFCs.
o Additional security considerations as per SecDir review from Sean
Turner.
o Added a new registry for the notification-capability parameter of
the notify_method_capability test (as per Pasi Eronen gen-art
review).
Changes since draft-ietf-sieve-notify-10 Changes since draft-ietf-sieve-notify-10
o Updated IANA registration template as per discussion in Vancouver. o Updated IANA registration template as per discussion in Vancouver.
o Added ABNF for :options names. o Added ABNF for :options names.
o Prohibit notification methods from defining new Sieve tags. o Prohibit notification methods from defining new Sieve tags.
Changes since draft-ietf-sieve-notify-09 Changes since draft-ietf-sieve-notify-09
skipping to change at page 6, line 32 skipping to change at page 6, line 32
4. Test valid_notify_method . . . . . . . . . . . . . . . . . . 13 4. Test valid_notify_method . . . . . . . . . . . . . . . . . . 13
5. Test notify_method_capability . . . . . . . . . . . . . . . 14 5. Test notify_method_capability . . . . . . . . . . . . . . . 14
6. Modifier encodeurl to the 'set' action . . . . . . . . . . . 15 6. Modifier encodeurl to the 'set' action . . . . . . . . . . . 15
7. Interactions with Other Sieve Actions . . . . . . . . . . . 16 7. Interactions with Other Sieve Actions . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18
9.1. Registration of Sieve extension . . . . . . . . . . . . . . 17 9.1. Registration of Sieve extension . . . . . . . . . . . . . . 18
9.2. New registry for Sieve notification mechanisms . . . . . . . 18 9.2. New registry for Sieve notification mechanisms . . . . . . . 18
9.3. New registry for notification-capability parameters . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . 23
1. Introduction 1. Introduction
This is an extension to the Sieve language defined by [Sieve] for This is an extension to the Sieve language defined by [Sieve] for
providing instant notifications. It defines the new action "notify". providing instant notifications. It defines the new action "notify".
This document does not specify the notification methods. Examples of This document does not specify the notification methods. Examples of
possible notification methods are email and XMPP. To allow a possible notification methods are email and XMPP. To allow a
mechanism for portability of scripts that use notifications, mechanism for portability of scripts that use notifications,
implementation of the [MailTo] method is mandatory. Other available implementation of the [MailTo] method is mandatory. Other available
skipping to change at page 8, line 4 skipping to change at page 8, line 4
The Notify action specifies that a notification should be sent to a The Notify action specifies that a notification should be sent to a
user. The format of the notification is implementation-defined and user. The format of the notification is implementation-defined and
is also affected by the notification method used (see Section 3.2). is also affected by the notification method used (see Section 3.2).
However, all content specified in the :message parameter SHOULD be However, all content specified in the :message parameter SHOULD be
included. included.
3.2. Notify parameter "method" 3.2. Notify parameter "method"
The method positional parameter identifies the notification method The method positional parameter identifies the notification method
that will be used; it is a URI [URI]. For example, the notification that will be used; it is a URI [URI]. For example, the notification
method can be an SMS URI [SMS-URI] containing a phone number, or an method can be a tel URI [TEL-URI] with a phone number to send SMS
XMPP [XMPP] URI containing an XMPP identifier [XMPP-URI]. messages to, or an XMPP [XMPP] URI containing an XMPP identifier
[XMPP-URI].
The supported URI values will be site-specific, but support for the The supported URI values will be site-specific, but support for the
[MailTo] method is REQUIRED in order to insure interoperability. If [MailTo] method is REQUIRED in order to insure interoperability. If
a URI schema is specified that the implementation does not support, a URI schema is specified that the implementation does not support,
the notification MUST cause an error condition. Sieve scripts can the notification MUST cause an error condition. Sieve scripts can
check the supported methods using the "valid_notify_method" test to check the supported methods using the "valid_notify_method" test to
be sure that they only use supported ones, to avoid such error be sure that they only use supported ones, to avoid such error
conditions. conditions.
If the method parameter contains a supported URI schema, then the URI If the method parameter contains a supported URI schema, then the URI
MUST be checked for syntactic validity. An invalid URI syntax or an MUST be checked for syntactic validity. An invalid URI syntax or an
unsupported URI extension MUST cause an error. An implementation MAY unsupported URI extension MUST cause an error. An implementation MAY
enforce other semantic restrictions on URIs -- for example to enforce other semantic restrictions on URIs -- for example to
restrict phone numbers in SMS URI to a particular geographical region restrict phone numbers in a tel: URI to a particular geographical
-- and will treat violations of such semantic restrictions as errors. region -- and will treat violations of such semantic restrictions as
errors.
3.3. Notify tag ":from" 3.3. Notify tag ":from"
A ":from" parameter may be used to specify an author of the A ":from" parameter may be used to specify an author of the
notification. The syntax of this parameter's value is method- notification. The syntax of this parameter's value is method-
specific. Implementations SHOULD check the syntax according to the specific. Implementations SHOULD check the syntax according to the
notification method specification and generate an error when a notification method specification and generate an error when a
syntactically invalid ":from" parameter is specified. syntactically invalid ":from" parameter is specified.
In order to minimize/prevent forgery of the author value, In order to minimize/prevent forgery of the author value,
implementations SHOULD impose restrictions on what values can implementations SHOULD impose restrictions on what values can
specified in a ":from" parameter. For example, an implementation may specified in a ":from" parameter. For example, an implementation may
restrict this value to be a member of a list of known author restrict this value to be a member of a list of known author
addresses or to belong to a particular domain. It is suggested that addresses or to belong to a particular domain. It is suggested that
values which don't satisfy such restrictions simply be ignored rather values which don't satisfy such restrictions simply be ignored rather
than causing the notify action to fail. than causing the notify action to fail.
3.4. Notify tag ":importance" 3.4. Notify tag ":importance"
The :importance tag specifies the importance of the delivery of the The :importance tag specifies the importance of quick delivery of the
notification. The :importance tag is followed by a numeric value notification as perceived by the Sieve script owner. The :importance
represented as a string: "1" (high importance), "2" (normal tag is followed by a numeric value represented as a string: "1" (high
importance), and "3" (low importance). If no importance is given, importance), "2" (normal importance), and "3" (low importance). If
the default value "2" SHOULD be assumed. A notification method can no importance is given, the default value "2" SHOULD be assumed. A
treat the importance value as a transport indicator. For example, it notification method MAY treat the importance value as a transport
might deliver notifications of high importance quicker than indicator. For example, it might deliver notifications of high
notifications of normal or low importance. Some notification methods importance quicker than notifications of normal or low importance.
allow users to specify their state of activity (for example "busy" or Some notification methods allow users to specify their state of
"away from keyboard"). If the notification method provides this activity (for example "busy" or "away from keyboard"). If the
information it SHOULD be used to selectively send notifications. If, notification method provides this information it SHOULD be used to
for example, the user marks herself as "busy", a notification method selectively send notifications. If, for example, the user marks
can require that a notification with importance of "3" is not to be herself as "busy", a notification method can require that a
sent, however the user should be notified of a notification with notification with importance of "3" is not to be sent, however the
higher importance. user should be notified of a notification with higher importance.
If the notification method allows users to filter messages based upon If the notification method allows users to filter messages based upon
certain parameters in the message, users SHOULD be able to filter certain parameters in the message, users SHOULD be able to filter
based upon importance. If the notification method does not support based upon importance. If the notification method does not support
importance, then this parameter MUST be ignored. An implementation importance, then this parameter MUST be ignored. An implementation
MAY include the importance value in the default message Section 3.6, MAY include the importance value in the default message Section 3.6,
if one is not provided. if one is not provided.
3.5. Notify tag ":options" 3.5. Notify tag ":options"
skipping to change at page 12, line 12 skipping to change at page 12, line 12
"mailto:alm@example.com"; "mailto:alm@example.com";
} }
Example 3: Example 3:
require ["enotify", "variables"]; require ["enotify", "variables"];
set "notif_method" set "notif_method"
"xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail"; "xmpp:tim@example.com?message;subject=SIEVE;body=You%20got%20mail";
if header :contains "subject" "Your dog" { if header :contains "subject" "Your dog" {
set "notif_method" "sms:+14085551212"; set "notif_method" "tel:+14085551212";
} }
if header :contains "to" "sievemailinglist@example.org" { if header :contains "to" "sievemailinglist@example.org" {
set "notif_method" ""; set "notif_method" "";
} }
if not string :is "${notif_method}" "" { if not string :is "${notif_method}" "" {
notify "${notif_method}"; notify "${notif_method}";
} }
if header :contains "from" "boss@example.org" { if header :contains "from" "boss@example.org" {
# :matches is used to get the value of the Subject header # :matches is used to get the value of the Subject header
if header :matches "Subject" "*" { if header :matches "Subject" "*" {
set "subject" "${1}"; set "subject" "${1}";
} }
# don't need high importance notification for # don't need high importance notification for
# a 'for your information' # a 'for your information'
if not header :contains "subject" "FYI:" { if not header :contains "subject" "FYI:" {
notify :importance "1" :message "BOSS: ${subject}" notify :importance "1" :message "BOSS: ${subject}"
"sms:+14085551212"; "tel:+14085551212";
} }
} }
3.8. Requirements on notification methods specifications 3.8. Requirements on notification methods specifications
This section describes requirements for documents that define This section describes requirements for documents that define
specific Sieve notification methods. specific Sieve notification methods.
Notification mechanisms MUST NOT add new Sieve tags to the notify Notification mechanisms MUST NOT add new Sieve tags to the notify
action. action.
skipping to change at page 13, line 16 skipping to change at page 13, line 16
action. action.
A notification method MAY recommend the default message value to be A notification method MAY recommend the default message value to be
used if the :message argument is not specified. used if the :message argument is not specified.
Notifications SHOULD include timestamps, if the notification method Notifications SHOULD include timestamps, if the notification method
allows for their transmission outside of the textual message. allows for their transmission outside of the textual message.
Implementation methods which can only transmit timestamps in the Implementation methods which can only transmit timestamps in the
textual message MAY include them in the textual message. textual message MAY include them in the textual message.
A notification SHOULD include means to identify/track its origin, in A notification MUST include means to identify/track its origin, in
order to allow a recipient to stop notifications or find out how to order to allow a recipient to stop notifications or find out how to
contact the sender. This requirement is to help tracking a contact the sender. This requirement is to help tracking a
misconfigured or abusive origin of notifications. misconfigured or abusive origin of notifications.
Methods SHOULD NOT include any other extraneous information not Methods SHOULD NOT include any other extraneous information not
specified in parameters to the notify action. specified in parameters to the notify action.
Methods MUST specify which URI parameters (if any) must be ignored, Methods MUST specify which URI parameters (if any) must be ignored,
which ones must be used in the resulting notification and which ones which ones must be used in the resulting notification and which ones
must cause an error. must cause an error.
Methods MUST specify what values are returned by the Methods MUST specify what values are returned by the
notify_method_capability test Section 5. notify_method_capability test Section 5, in particular for the
"online" notification-capability.
If there are errors sending the notification, the Sieve interpreter If there are errors sending the notification, the Sieve interpreter
SHOULD ignore the notification and not retry indefinitely. The Sieve SHOULD ignore the notification and not retry indefinitely. The Sieve
interpreter MAY throttle notifications; if it does, a request to send interpreter MAY throttle notifications; if it does, a request to send
a notification MAY be silently ignored. Documents describing a notification MAY be silently ignored. Documents describing
notification methods SHOULD describe how retries, throttling, notification methods SHOULD describe how retries, throttling,
duplicate suppression (if any), etc. are to be handled by duplicate suppression (if any), etc. are to be handled by
implementations. implementations.
4. Test valid_notify_method 4. Test valid_notify_method
skipping to change at page 14, line 25 skipping to change at page 14, line 26
<notification-capability: string> <notification-capability: string>
<key-list: string-list> <key-list: string-list>
The "notify_method_capability" test retrieves the notification The "notify_method_capability" test retrieves the notification
capability specified by the notification-capability string that is capability specified by the notification-capability string that is
specific to the notification-uri and matches it to the values specific to the notification-uri and matches it to the values
specified in the key-list. The test succeeds if a match occurs. The specified in the key-list. The test succeeds if a match occurs. The
type of match defaults to ":is" and the default comparator is type of match defaults to ":is" and the default comparator is
"i;ascii-casemap". "i;ascii-casemap".
The notification-capability is case insensitive. The notification-capability parameter is case insensitive.
The notify_method_capability test MUST fail unconditionally if the The notify_method_capability test MUST fail unconditionally if the
specified notification-uri is syntactically invalid (as determined by specified notification-uri is syntactically invalid (as determined by
the valid_notify_method test Section 4) or specifies an unsupported the valid_notify_method test Section 4) or specifies an unsupported
notification method. However this MUST NOT cause an error. notification method. However this MUST NOT cause an error.
The notify_method_capability test MUST fail unconditionally if the The notify_method_capability test MUST fail unconditionally if the
specified notification-capability item does not exist. A script MUST specified notification-capability item is not known to the Sieve
NOT fail with an error if the item does not exist. This allows interpreter. A script MUST NOT fail with an error if the item does
scripts to be written that handle nonexistent items gracefully. not exist. This allows scripts to be written that handle nonexistent
items gracefully.
This document defines a single notification-capability value This document defines a single notification-capability value
"online", which is described below. Additional notification- "online", which is described below. Additional notification-
capability values may be defined by a Standard Track or Experimental capability values may be defined by using the procedure defined in
RFC. Section 9.3.
The "relational" extension [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.
For the "online" notification-capability the notify_method_capability For the "online" notification-capability the notify_method_capability
test can match one of the following key-list values: test can match one of the following key-list values:
o "yes" - the entity identified by the notification-uri can receive o "yes" - the entity identified by the notification-uri can receive
a notify notification immediately. Note that even after this a notify notification immediately. Note that even after this
value is returned, there is no guarantee that the entity would value is returned, there is no guarantee that the entity would
actually be able to receive any notification immediately or even actually be able to receive any notification immediately or even
receive it at all. Transport errors, recipient policy, etc. can receive it at all. Transport errors, recipient policy, etc. can
prevent that. prevent that.
o "no" - the entity identified by the notification-uri is not o "no" - the entity identified by the notification-uri is not
currently available to receive an immediate notification. currently available to receive an immediate notification.
o "maybe" - Sieve interpreter can't determine if the the entity o "maybe" - Sieve interpreter can't determine if the the entity
identified by the notification-uri is online or not. identified by the notification-uri is online or not.
The "relational" extension [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.
Example 5: Example 5:
require ["enotify"]; require ["enotify"];
if notify_method_capability if notify_method_capability
"xmpp:tim@example.com?message;subject=SIEVE" "xmpp:tim@example.com?message;subject=SIEVE"
"Online" "Online"
"yes" { "yes" {
notify :importance "1" :message "You got mail" notify :importance "1" :message "You got mail"
"xmpp:tim@example.com?message;subject=SIEVE"; "xmpp:tim@example.com?message;subject=SIEVE";
} else { } else {
notify :message "You got mail" "sms:+14085551212"; notify :message "You got mail" "tel:+14085551212";
} }
6. Modifier encodeurl to the 'set' action 6. Modifier encodeurl to the 'set' action
Usage: ":encodeurl" Usage: ":encodeurl"
When the Sieve script specifies both "variables" [Variables] and When the Sieve script specifies both "variables" [Variables] and
"enotify" capabilities in the "require", a new "set" action modifier "enotify" capabilities in the "require", a new "set" action modifier
(see [Variables]) ":encodeurl" becomes available to Sieve scripts. (see [Variables]) ":encodeurl" becomes available to Sieve scripts.
This modifier performs percent-encoding of any octet in the string This modifier performs percent-encoding of any octet in the string
skipping to change at page 16, line 29 skipping to change at page 16, line 36
of the specific notification methods. of the specific notification methods.
The notify action is potentially very dangerous. The path the The notify action is potentially very dangerous. The path the
notification takes through the network may not be secure. An error notification takes through the network may not be secure. An error
in the options string may cause the message to be transmitted to in the options string may cause the message to be transmitted to
someone it was not intended for, or may expose information to someone it was not intended for, or may expose information to
eavesdroppers. eavesdroppers.
Just because a notification is received doesn't mean that it was sent Just because a notification is received doesn't mean that it was sent
by the Sieve implementation. It might be possible to forge by the Sieve implementation. It might be possible to forge
notifications with some notification methods. notifications or modify parts of valid notifications with some
notification methods.
Forgery of the :importance value (for example by unauthorized script
modification) can potentially result in slow down in notification
delivery.
Note that some components of notifications should not be trusted.
For example the timestamp field can be easily forged or modified when
some notification transports are used. Even if the timestamp is
believed to be correct by the sender and is not modified in transit,
it might be misleading on the receiving system due to clock
differences.
An organization may have a policy about the forwarding of classified An organization may have a policy about the forwarding of classified
information to unclassified networks. Unless the policy is also information to unclassified networks. Unless the policy is also
enforced in the module responsible for generating (or sending) of enforced in the module responsible for generating (or sending) of
notifications, users can use the extension defined in this document notifications, users can use the extension defined in this document
to extract classified information and bypass the policy. to extract classified information and bypass the policy.
Notifications can result in loops and bounces. Also, allowing a Notifications can result in loops and bounces. Also, allowing a
single script to notify multiple destinations can be used as a means single script to notify multiple destinations can be used as a means
of amplifying the number of messages in an attack. Moreover, if loop of amplifying the number of messages in an attack. Moreover, if loop
skipping to change at page 17, line 29 skipping to change at page 17, line 49
where Sieve scripts are associated with email accounts which are where Sieve scripts are associated with email accounts which are
freely-available and/or not trackable to a human who can be held freely-available and/or not trackable to a human who can be held
accountable for creating message bombs or other abuse. accountable for creating message bombs or other abuse.
Implementations that construct URIs internally from various notify Implementations that construct URIs internally from various notify
parameters MUST make sure that all components of such URIs are parameters MUST make sure that all components of such URIs are
properly percent-encoded (see [URI]). In particular this applies to properly percent-encoded (see [URI]). In particular this applies to
values of the :from and the :message tagged arguments and may apply values of the :from and the :message tagged arguments and may apply
to the :options values. to the :options values.
9. IANA Considerations Header/envelope tests [Sieve] together with Sieve variables can be
used to extract the list of users to receive notifications from the
incoming email message or its envelope. This is potentially quite
dangerous, as this can be used for Deny Of Service attacks on
recipients controlled by the message sender. For this reason
implementations SHOULD NOT allow use of variables containing values
extracted from the email message in the method parameter to the
notify action. Note that violation of this SHOULD NOT may result in
the creation of an open relay, i.e. any sender would be able to
create specially crafted email messages that would result in
notifications delivered to recipients under the control of the
sender. In worst case this might result in financial loss by user
controlling the Sieve script and/or by recipients of notifications
(e.g. if a notification is an SMS message).
9.1. Registration of Sieve extension Note that the last SHOULD NOT is not a generic prohibition of use of
variables in the notify action, as controlling the target of a
notification by extracting it from user owned data stores (such as
user's LDAP entry) is considered to be useful.
IANA is requested to create a new registry for Sieve notification 9. IANA Considerations
mechanisms. This registry contains both vendor-controlled
notification mechanism names (beginning with "vnd.") and IETF-
controlled notification mechanism names. Vendor-controlled
notification mechanism names have the format as defined in the
following paragraph and may be registered on a "First Come First
Served" basis [IANA-GUIDELINES], by applying to IANA with the form in
the following section. Registration of notification mechanisms that
do not begin with "vnd." are registered using the "Specification
Required" policy [IANA-GUIDELINES].
Vendor-controlled notification mechanism names MUST have the form 9.1. Registration of Sieve extension
"vnd.<vendor-name>.<mechanism-name>", where <vendor-name> is as
specified in the ACAP Vendor Subtree registry [ACAP].
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve extension Subject: Registration of new Sieve extension
Capability name: enotify Capability name: enotify
Description: adds the 'notify' action for notifying user about the Description: adds the 'notify' action for notifying user about the
received message. It also provides two new test: valid_notify_method received message. It also provides two new test: valid_notify_method
checks notification URIs for validity; notify_method_capability can checks notification URIs for validity; notify_method_capability can
check recipients capabilities. check recipients capabilities.
RFC number: this RFC RFC number: this RFC
Contact address: Contact address:
The Sieve discussion list <ietf-mta-filters@imc.org> The Sieve discussion list <ietf-mta-filters@imc.org>
This information should be added to the list of sieve extensions This information should be added to the list of sieve extensions
given on http://www.iana.org/assignments/sieve-extensions. given on http://www.iana.org/assignments/sieve-extensions.
9.2. New registry for Sieve notification mechanisms 9.2. New registry for Sieve notification mechanisms
IANA is requested to create a new registry for Sieve notification
mechanisms. This registry contains both vendor-controlled
notification mechanism names (beginning with "vnd.") and IETF-
controlled notification mechanism names. Vendor-controlled
notification mechanism names have the format as defined in the
following paragraph and may be registered on a "First Come First
Served" basis [IANA-GUIDELINES], by applying to IANA with the form
specified later in this section. Registration of notification
mechanisms that do not begin with "vnd." are registered using the
"Specification Required" policy [IANA-GUIDELINES].
Vendor-controlled notification mechanism names MUST have the form
"vnd.<vendor-name>.<mechanism-name>", where <vendor-name> is as
specified in the ACAP Vendor Subtree registry [ACAP].
This defines the template for a new registry for Sieve notification This defines the template for a new registry for Sieve notification
mechanisms, to be created as mechanisms, to be created as
http://www.iana.org/assignments/sieve-notification. There are no http://www.iana.org/assignments/sieve-notification. There are no
initial entries for this registry. initial entries for this registry.
To: iana@iana.org To: iana@iana.org
Subject: Registration of new Sieve notification mechanism Subject: Registration of new Sieve notification mechanism
Mechanism name: [the name of the mechanism] Mechanism name: [the name of the mechanism]
Mechanism URI: [the RFC number of the document that defines the URI Mechanism URI: [the RFC number of the document that defines the URI
used by this mechanism] used by this mechanism. Different mechanisms MUST use different URI
schema.]
Mechanism-specific options: [the names of any Sieve notify option Mechanism-specific options: [the names of any Sieve notify option
names (as used in the :options parameter) that are specific to this names (as used in the :options parameter) that are specific to this
mechanism, or "none"] mechanism, or "none"]
Standards Track/IESG-approved experimental RFC number: [the RFC Permanent and readily available reference: [the RFC number or an URL
number of the document that defines this notification mechanism] of the document that defines this notification mechanism]
Person and email address to contact for further information: [the Person and email address to contact for further information: [the
name and email address of the technical contact for information about name and email address of the technical contact for information about
this mechanism] this mechanism]
9.3. New registry for notification-capability parameters
IANA is requested to create a new registry for notification-
capability parameter of the notify_method_capability test. This
registry contains both vendor-controlled notification-capability
values (beginning with "vnd.") and IETF-controlled notification-
capability values. Vendor-controlled notification-capability values
have the format as defined in the following paragraph and may be
registered on a "First Come First Served" basis [IANA-GUIDELINES], by
applying to IANA with the form specified later in this section.
Registration of notification-capability values that do not begin with
"vnd." are registered using the "Specification Required" policy
[IANA-GUIDELINES].
Vendor-controlled notification-capability values MUST have the form
"vnd.<vendor-name>.<capability-name>", where <vendor-name> is as
specified in the ACAP Vendor Subtree registry [ACAP].
The following template must be used for registering notification-
capability parameters:
To: iana@iana.org
Subject: Registration of a new notification-capability parameter
Capability name: [the name of the notification-capability]
Description: [a description of what the notification-capability is
for]
Syntax: [formal definition of allowed values and their syntax]
Permanent and readily available reference(s): [the RFC number(s) or
an URL of the document that defines this notification mechanism]
Contact information: [the name and email address of the technical
contact for information about this mechanism]
Below is the registration form for the "online" notification-
capability:
To: iana@iana.org
Subject: Registration of a new notification-capability parameter
Capability name: online
Description: Returns whether the entity identified by the
notification-uri parameter to the notify_method_capability test can
receive a notify notification immediately.
Syntax: Can contain one of three values: "yes", "no" and "maybe".
Values MUST be in lowercase.
Permanent and readily available reference(s): This RFC
Contact information: The Sieve discussion list
<ietf-mta-filters@imc.org>
10. Acknowledgements 10. Acknowledgements
Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus Thanks to Larry Greenfield, Sarah Robeson, Tim Showalter, Cyrus
Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E. Daboo, Nigel Swinson, Kjetil Torgrim Homme, Michael Haardt, Mark E.
Mallett, Ned Freed, Lisa Dusseault, Dilyan Palauzov, Arnt Gulbrandsen Mallett, Ned Freed, Lisa Dusseault, Dilyan Palauzov, Arnt
and Peter Saint-Andre for help with this document. Gulbrandsen, Peter Saint-Andre, Sean Turner, Cullen Jennings and Pasi
Eronen for help with this document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[Kwds] Bradner, S., "Key words for use in RFCs to Indicate [Kwds] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
skipping to change at page 19, line 39 skipping to change at page 21, line 29
11.2. Informative References 11.2. Informative References
[ACAP] Newman, C. and J. Myers, "ACAP -- Application [ACAP] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997. Configuration Access Protocol", RFC 2244, November 1997.
[IANA-GUIDELINES] [IANA-GUIDELINES]
Narten, T. and H. Alvestrand, "Guidelines for Writing an Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[SMS-URI] Wilde, E. and A. Vaha-Sipila, "URI scheme for GSM Short [TEL-URI] Schulzrinne, H., "The tel URI for Telephone Numbers",
Message Service", work in progress, draft-wilde-sms-uri, RFC 3966, December 2004.
August 2005.
[XMPP] Saint-Andre, Ed., P., "Extensible Messaging and Presence [XMPP] Saint-Andre, Ed., P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP-URI] [XMPP-URI]
Saint-Andre, P., "Internationalized Resource Identifiers Saint-Andre, P., "Internationalized Resource Identifiers
(IRIs) and Uniform Resource Identifiers (URIs) for the (IRIs) and Uniform Resource Identifiers (URIs) for the
Extensible Messaging and Presence Protocol (XMPP)", work Extensible Messaging and Presence Protocol (XMPP)", work
in progress, draft-saintandre-rfc4622bis, June 2007. in progress, draft-saintandre-rfc4622bis, June 2007.
 End of changes. 33 change blocks. 
74 lines changed or deleted 177 lines changed or added

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