One document matched: draft-ietf-sieve-notify-presence-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC '' '../../bibxml/reference.RFC.2119.xml'>
<!ENTITY RFC3863 PUBLIC '' '../../bibxml/reference.RFC.3863.xml'>
<!ENTITY RFC3921 PUBLIC '' '../../bibxml/reference.RFC.3921.xml'>
<!ENTITY RFC4480 PUBLIC '' '../../bibxml/reference.RFC.4480.xml'>
<!ENTITY RFC5228 PUBLIC '' '../../bibxml/reference.RFC.5228.xml'>
<!ENTITY RFC5229 PUBLIC '' '../../bibxml/reference.RFC.5229.xml'>
<!ENTITY RFC5230 PUBLIC '' '../../bibxml/reference.RFC.5230.xml'>
<!ENTITY RFC5435 PUBLIC '' '../../bibxml/reference.RFC.5435.xml'>
<!ENTITY RFC5491 PUBLIC '' '../../bibxml/reference.RFC.5491.xml'>
<!ENTITY autoreply PUBLIC '' '../../bibxml3/reference.I-D.draft-ietf-sieve-autoreply-02.xml'>
<!ENTITY extlists PUBLIC '' '../../bibxml3/reference.I-D.draft-ietf-sieve-external-lists-02.xml'>
]>
<?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="trust200902"
docName="draft-ietf-sieve-notify-presence-04">
<front>
<title abbrev="Sieve Notify: Presence">
Sieve Notification Using Presence Information
</title>
<author initials="R." surname="George" fullname="Robins George">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street />
<city>Bangalore</city>
<region>Karnataka</region>
<code>560071</code>
<country>India</country>
</postal>
<phone>+91-080-41117676</phone>
<email>robinsgv@gmail.com</email>
</address>
</author>
<author initials='B.' surname="Leiba" fullname='Barry Leiba'>
<organization>Huawei Technologies</organization>
<address>
<phone>+1 646 827 0648</phone>
<email>barryleiba@computer.org</email>
<uri>http://internetmessagingtechnology.org/</uri>
</address>
</author>
<date year="2010" />
<area>APP</area>
<workgroup>Sieve working group</workgroup>
<abstract>
<t>
This is a further extension to the Sieve mail filtering language
Notification extension, defining presence information that may be
checked through the notify_method_capability feature.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Sometimes, it's desirable to tailor Sieve <xref target='RFC5228' />
notifications to a user's current situation.
Presence information provides some information
about the user that would be useful to have access to in these cases.
The Notification extension <xref target='RFC5435' /> defines a mechanism to
test for presence (the notify_method_capability feature), and defines
one test for presence (the "online"
notification-capability, described in Section 5 of RFC 5435).
This extension defines more presence tests by registering
additional notification-capability parameters in the IANA
registry, allowing testing of a wider variety of presence
information.
</t>
<section anchor="terms" title="Terminology Used in This Document">
<t>
The upper-case 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='RFC2119' />.
</t>
</section>
</section>
<section anchor="nmc-test" title="Testing presence information">
<t>
This extension uses the notify_method_capability test, as defined in the
Sieve <xref target='RFC5228' /> Notify extension <xref target='RFC5435' />,
to test presence information. When a Sieve event occurs (mail arrives) for
a user, a Sieve script running on behalf of that user can present the
user's presence URI (in the "notification-uri" parameter) and test a
specific item of notification presence as defined below (in the "notification-capability"
parameter) against one or more values (in the "key-list" parameter).
</t>
<t>
This document defines an initial set of items of notification presence,
which may be specified in the notification-capability parameter.
It is expected that future extensions will add additional
presence items derived from diverse sources,
including calendar information, geographic location, and so on.
</t>
<t>
Note that, while the items below are documented as similar to items in XMPP,
it is not the intent that this extension be tied to XMPP, nor to any particular
source of presence, and flexible implementations will be ready for future
extensions. Useful informational references for presence data and formats include
Presence Information Data Format (PIDF) <xref target="RFC3863"/>,
RPID: Rich Presence Extensions to PIDF <xref target="RFC4480"/>, and
GEOPRIV Presence Information Data Format Location Object (PIDF-LO) <xref target="RFC5491"/>.
</t>
<t>
The script tests the values of notification presence items in the key-
list parameter. The values that each item may have are specified in
the list below. Note that in addition to the presence values, any
item may have the value "unknown" if it is not possible to determine
the correct presence value of the item.
</t>
<t>
If a particular presence item is tested multiple times within the same script
execution context, implementations MUST present the same value each time
(for example, by caching the value on first use). This provides consistency
within a single execution.
</t>
<t>
Supported presence items are as follows:
<list style="hanging" hangIndent="5">
<t hangText="busy">-
An indication of whether the user is considered "busy" now
(the value "yes") or not (the value "no"),
or "unknown" if it cannot be determined.
The meaning of "busy" is left to the implementation,
and may be a state that's synthesized from other information
(including "show", below).
</t>
<t hangText="show">-
The availability status of the user, formally specified.
Note that this is similar to
the presence element with the same name that's defined in
Section 2.2.2.1 of RFC 3921.<xref target="RFC3921" />
The value of this item is one of the following:
<list style="hanging" hangIndent="5">
<t hangText="away">-
The user is temporarily away.
</t>
<t hangText="chat">-
The user is online and actively interested in chatting.
</t>
<t hangText="dnd">-
Do Not Disturb; the user does not wish to be disturbed now.
</t>
<t hangText="offline">-
The user is offline.
</t>
<t hangText="xa">-
The user is away for an extended period (xa = "eXtended Away").
</t>
<t hangText="unknown">-
The correct presence value could not be determined.
</t>
</list>
</t>
<t hangText="status">-
A human-readable description of the user's availability status,
in natural language.
There is no formal definition for the values this item may take.
It is free-form, and may be in any language.
Direct comparisons against the value of this field are unlikely to be useful;
rather, it is provided to enable extraction of the value into a
variable <xref target="RFC5229" /> for use elsewhere
(see example 3 in <xref target="examples" />).
Note that this is similar to
the presence element with the same name that's defined in
Section 2.2.2.2 of RFC 3921 <xref target="RFC3921" />,
and to the <note> element defined in section 4.1.6 of
PIDF <xref target="RFC3863"/>.
<vspace blankLines="1"/>
Because this is a free-form value that might be created directly by a user,
no value, including "unknown", can have any special meaning.
If the Sieve processor is unable to determine the value of this item,
it might be best to leave it as an empty string.
In any case, it is not meant for machine-readable processing,
beyond possible XML interpretation.
</t>
</list>
</t>
<t>
There is no capability string associated with this extension, but this requires
support for "enotify".<xref target='RFC5435' />
If the implementation does not support the item being tested
(that is, the specified
notification-capability item is not known to the Sieve interpreter),
RFC 5435 already specifies that the test fail without an error.
</t>
<t>
Although this feature was conceived to assist in notifications, and the test
requires support of the Sieve Notify feature, it is only a condition test,
and any Sieve action can appear inside it. There are no Sieve actions that
conflict with this extension.
</t>
</section>
<section anchor="examples" title="Examples">
<t><list style="numbers">
<t>
This example will send a notification only if the recipient is not "busy".
If the test for "busy" is not supported, this example will not send a notification.
<figure>
<artwork>
<![CDATA[
require ["enotify"];
if notify_method_capability "xmpp:tim@example.com" "busy" "no"
{
notify :message "You got mail"
"xmpp:tim@example.com?message;subject=SIEVE";
}
]]>
</artwork>
</figure>
</t>
<t>
This example will send a notification only if the recipient is not "busy".
If the test for "busy" is not supported, this example will send a notification.
<figure>
<artwork>
<![CDATA[
require ["enotify"];
if not notify_method_capability "xmpp:tim@example.com" "busy" "yes"
{
notify :message "You got mail"
"xmpp:tim@example.com?message;subject=SIEVE";
}
]]>
</artwork>
</figure>
</t>
<t>
This example uses the vacation extension <xref target="RFC5230" /> to generate an
autoreply <xref target='I-D.ietf-sieve-autoreply' /> if the sender is in
the recipient's address book <xref target='I-D.ietf-sieve-external-lists' />
and the recipient's presence shows "extended away".
The variables extension <xref target="RFC5229" /> is used to extract the value
of the recipient's presence status message, which will be used in the
response to the sender.
If the test for "show" is not supported, this example will not send an autoreply.
<figure>
<artwork>
<![CDATA[
require ["extlists", "vacation", "enotify", "variables"];
if allof (
envelope :list "from" "tag:example.com,2009-05-28:mylist",
notify_method_capability "xmpp:myjid@example.com" "show" "xa"
) {
# :matches "*" is used here to extract the value
if notify_method_capability :matches
"xmpp:myjid@example.com" "status" "*" {
set "resp_msg" "${1}";
} else {
set "resp_msg" "I'm away from email for a while."
}
vacation :handle "ext-away" "${resp_msg}";
}
]]>
</artwork>
</figure>
</t>
</list></t>
</section>
<section anchor="security" title="Security Considerations">
<t>
Security considerations for Sieve <xref target='RFC5228' />
and the Notify extension <xref target='RFC5435' />
apply equally here.
In addition, implementations MUST ensure that users can not create
scripts that access the presence information of others without the
proper access controls.
</t>
<t>
In some situations, scripts may act on some of the recipient's
presence information that the sender of the triggering message is not
allowed to see.
This can be a benefit to the recipient in many cases, but it can also
present an opportunity for a sender to use messages to probe the
recipient's presence (if, for example, messages sometimes result in
auto-replies, and sometimes do not).
Script authors should take care in considering this aspect of
presence-triggered actions.
</t>
<t>
It's possible for a large number of messages to arrive at or around the
same time and be processed by Sieve scripts that all test presence.
If many of the users share the same presence server, such a burst
could put an unexpectedly heavy load on the presence server.
Implementations might consider providing options for rate limiting,
or for caching presence tests for periods of time, even across Sieve
script instances.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>
This registers each presence item as a notification-capability parameter.
Future extensions that add new presence items should register those items
similarly, using the instructions in Section 9.3 of RFC 5435.<xref target="RFC5435" />
</t>
<?rfc subcompact="yes"?>
<t><list style="hanging" hangIndent="5">
<t hangText="To:">iana@iana.org</t>
<t hangText="Subject:">Registration of a new notification-capability parameter</t>
<t hangText="Capability name:">busy</t>
<t hangText="Description:">
An indication of whether the user is considered "busy" now
(the value "yes") or not (the value "no").
The meaning of "busy" is left to the implementation,
and may be a state that's synthesized from other information.
</t>
<t hangText="Syntax:">
Has one of the values "yes", "no", or "unknown".
The value MUST be in lower case.
</t>
<t hangText="Permanent and readily available reference(s):">this RFC</t>
<t hangText="Contact information:">The Sieve discussion list, <sieve@ietf.org></t>
</list></t>
<?rfc subcompact="no"?>
<?rfc subcompact="yes"?>
<t><list style="hanging" hangIndent="5">
<t hangText="To:">iana@iana.org</t>
<t hangText="Subject:">Registration of a new notification-capability parameter</t>
<t hangText="Capability name:">show</t>
<t hangText="Description:">
The availability status of the user. This is similar to
the presence element with the same name that's defined in
Section 2.2.2.1 of RFC 3921.
</t>
<t hangText="Syntax:">
Has one of the values "away", "chat", "dnd", "offline", "xa", or "unknown".
The value MUST be in lower case.
</t>
<t hangText="Permanent and readily available reference(s):">this RFC</t>
<t hangText="Contact information:">The Sieve discussion list, <sieve@ietf.org></t>
</list></t>
<?rfc subcompact="no"?>
<?rfc subcompact="yes"?>
<t><list style="hanging" hangIndent="5">
<t hangText="To:">iana@iana.org</t>
<t hangText="Subject:">Registration of a new notification-capability parameter</t>
<t hangText="Capability name:">status</t>
<t hangText="Description:">
A human-readable description of the user's availability status.
This is similar to
the presence element with the same name that's defined in
Section 2.2.2.2 of RFC 3921.
</t>
<t hangText="Syntax:">
There is no formal definition for the values this item may take.
It is free-form and may be in any language, and is meant for human consumption.
</t>
<t hangText="Permanent and readily available reference(s):">this RFC</t>
<t hangText="Contact information:">The Sieve discussion list, <sieve@ietf.org></t>
</list></t>
<?rfc subcompact="no"?>
</section>
<section anchor="acknowledgments" title="Acknowledgments">
<t>
The authors thank Alexey Melnikov for significant early feedback and suggestions.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
&RFC3921; <!-- XMPP Instant Messaging and Presence -->
&RFC5228; <!-- sieve -->
&RFC5435; <!-- notify -->
</references>
<references title="Informative References">
&autoreply;
&extlists;
&RFC3863; <!-- PIDF -->
&RFC4480; <!-- RPID -->
&RFC5491; <!-- PIDF-LO -->
&RFC5229; <!-- variables -->
&RFC5230; <!-- vacation -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 07:31:55 |