Difference between revisions of "RFC6132"
imported>Admin (Created page with " Internet Engineering Task Force (IETF) R. GeorgeRequest for Comments: 6132 B. LeibaCategory: Standards Track...") |
|||
(One intermediate revision by the same user not shown) | |||
Line 1: | Line 1: | ||
+ | Internet Engineering Task Force (IETF) R. George | ||
+ | Request for Comments: 6132 B. Leiba | ||
+ | Category: Standards Track Huawei Technologies | ||
+ | ISSN: 2070-1721 July 2011 | ||
+ | Sieve Notification Using Presence Information | ||
− | + | '''Abstract''' | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | Abstract | ||
This is a further extension to the Sieve mail filtering language | This is a further extension to the Sieve mail filtering language | ||
Line 14: | Line 12: | ||
checked through the notify_method_capability feature. | checked through the notify_method_capability feature. | ||
− | Status of This Memo | + | '''Status of This Memo''' |
This is an Internet Standards Track document. | This is an Internet Standards Track document. | ||
Line 28: | Line 26: | ||
http://www.rfc-editor.org/info/rfc6132. | http://www.rfc-editor.org/info/rfc6132. | ||
− | Copyright Notice | + | '''Copyright Notice''' |
Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 IETF Trust and the persons identified as the | ||
Line 42: | Line 40: | ||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | ||
described in the Simplified BSD License. | described in the Simplified BSD License. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Introduction == | == Introduction == | ||
− | Sometimes, it's desirable to tailor Sieve [RFC5228] notifications to | + | Sometimes, it's desirable to tailor Sieve [[RFC5228]] notifications to |
a user's current situation. Presence information provides some | a user's current situation. Presence information provides some | ||
information about the user that would be useful to have access to in | information about the user that would be useful to have access to in | ||
− | these cases. The Notification extension [RFC5435] defines a | + | these cases. The Notification extension [[RFC5435]] defines a |
mechanism to test for presence (the notify_method_capability | mechanism to test for presence (the notify_method_capability | ||
feature), and defines one test for presence (the "online" | feature), and defines one test for presence (the "online" | ||
Line 71: | Line 59: | ||
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and | "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and | ||
"OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | ||
− | [RFC2119]. | + | [[RFC2119]]. |
== Testing Presence Information == | == Testing Presence Information == | ||
This extension uses the notify_method_capability test, as defined in | This extension uses the notify_method_capability test, as defined in | ||
− | the Sieve [RFC5228] Notify extension [RFC5435], to test presence | + | the Sieve [[RFC5228]] Notify extension [[RFC5435]], to test presence |
information. When a Sieve event occurs (mail arrives) for a user, a | 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 | Sieve script running on behalf of that user can present the user's | ||
Line 83: | Line 71: | ||
"notification-capability" parameter) against one or more values (in | "notification-capability" parameter) against one or more values (in | ||
the "key-list" parameter). | the "key-list" parameter). | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
This document defines an initial set of items of notification | This document defines an initial set of items of notification | ||
Line 100: | Line 79: | ||
Note that, while the items below are documented as similar to items | Note that, while the items below are documented as similar to items | ||
− | in Extensible Messaging and Presence Protocol (XMPP) [RFC6121], it is | + | in Extensible Messaging and Presence Protocol (XMPP) [[RFC6121]], it is |
not the intent that this extension be tied to XMPP, nor to any | not the intent that this extension be tied to XMPP, nor to any | ||
particular source of presence, and flexible implementations will be | particular source of presence, and flexible implementations will be | ||
ready for future extensions. Useful informational references for | ready for future extensions. Useful informational references for | ||
presence data and formats include Presence Information Data Format | presence data and formats include Presence Information Data Format | ||
− | (PIDF) [RFC3863], RPID: Rich Presence Extensions to PIDF [RFC4480], | + | (PIDF) [[RFC3863]], RPID: Rich Presence Extensions to PIDF [[RFC4480]], |
and GEOPRIV Presence Information Data Format Location Object | and GEOPRIV Presence Information Data Format Location Object | ||
− | (PIDF-LO) [RFC5491]. | + | (PIDF-LO) [[RFC5491]]. |
The script tests the values of notification presence items in the | The script tests the values of notification presence items in the | ||
Line 131: | Line 110: | ||
Note that this is similar to the presence element with the | Note that this is similar to the presence element with the | ||
same name that's defined in Section 4.7.2.1 of [[RFC6121|RFC 6121]] | same name that's defined in Section 4.7.2.1 of [[RFC6121|RFC 6121]] | ||
− | [RFC6121]. The value of this item is one of the following: | + | [[RFC6121]]. The value of this item is one of the following: |
away: The user is temporarily away. | away: The user is temporarily away. | ||
Line 140: | Line 119: | ||
dnd: Do Not Disturb; the user does not wish to be | dnd: Do Not Disturb; the user does not wish to be | ||
disturbed now. | disturbed now. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
offline: The user is offline. | offline: The user is offline. | ||
Line 158: | Line 132: | ||
be in any language. Direct comparisons against the value of | be in any language. Direct comparisons against the value of | ||
this field are unlikely to be useful; rather, it is provided | this field are unlikely to be useful; rather, it is provided | ||
− | to enable extraction of the value into a variable [RFC5229] | + | to enable extraction of the value into a variable [[RFC5229]] |
for use elsewhere (see example 3 in Section 3). Note that | for use elsewhere (see example 3 in Section 3). Note that | ||
this is similar to the presence element with the same name | this is similar to the presence element with the same name | ||
− | that's defined in Section 4.7.2.2 of [[RFC6121|RFC 6121]] [RFC6121], and | + | that's defined in Section 4.7.2.2 of [[RFC6121|RFC 6121]] [[RFC6121]], and |
to the <note> element defined in section 4.1.6 of PIDF | to the <note> element defined in section 4.1.6 of PIDF | ||
− | [RFC3863]. | + | [[RFC3863]]. |
Because this is a free-form value that might be created | Because this is a free-form value that might be created | ||
Line 174: | Line 148: | ||
There is no capability string associated with this extension, but | There is no capability string associated with this extension, but | ||
− | this requires support for "enotify" [RFC5435]. If the implementation | + | this requires support for "enotify" [[RFC5435]]. If the implementation |
does not support the item being tested (that is, the specified | does not support the item being tested (that is, the specified | ||
notification-capability item is not known to the Sieve interpreter), | notification-capability item is not known to the Sieve interpreter), | ||
Line 189: | Line 163: | ||
not "busy". If the test for "busy" is not supported, this | not "busy". If the test for "busy" is not supported, this | ||
example will not send a notification. | example will not send a notification. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
require ["enotify"]; | require ["enotify"]; | ||
Line 206: | Line 171: | ||
"xmpp:[email protected]?message;subject=SIEVE"; | "xmpp:[email protected]?message;subject=SIEVE"; | ||
} | } | ||
− | |||
2. This example will send a notification only if the recipient is | 2. This example will send a notification only if the recipient is | ||
Line 220: | Line 184: | ||
} | } | ||
− | + | 3. This example uses the vacation extension [[RFC5230]] to generate an | |
− | 3. This example uses the vacation extension [RFC5230] to generate an | + | auto-reply [[RFC6133]] if the sender is in the recipient's address |
− | auto-reply [RFC6133] if the sender is in the recipient's address | + | book [[RFC6134]] and the recipient's presence shows "extended |
− | book [RFC6134] and the recipient's presence shows "extended | + | away". The variables extension [[RFC5229]] is used to extract the |
− | away". The variables extension [RFC5229] is used to extract the | ||
value of the recipient's presence status message, which will be | value of the recipient's presence status message, which will be | ||
used in the response to the sender. If the test for "show" is | used in the response to the sender. If the test for "show" is | ||
Line 244: | Line 207: | ||
vacation :handle "ext-away" "${resp_msg}"; | vacation :handle "ext-away" "${resp_msg}"; | ||
} | } | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Security Considerations == | == Security Considerations == | ||
− | Security considerations for Sieve [RFC5228] and the Notify extension | + | Security considerations for Sieve [[RFC5228]] and the Notify extension |
− | [RFC5435] apply equally here. In addition, implementations MUST | + | [[RFC5435]] apply equally here. In addition, implementations MUST |
ensure that users cannot create scripts that access the presence | ensure that users cannot create scripts that access the presence | ||
information of others without the proper access controls. | information of others without the proper access controls. | ||
Line 289: | Line 245: | ||
parameter. Future extensions that add new presence items should | parameter. Future extensions that add new presence items should | ||
register those items similarly, using the instructions in Section 9.3 | register those items similarly, using the instructions in Section 9.3 | ||
− | of [[RFC5435|RFC 5435]] [RFC5435]. | + | of [[RFC5435|RFC 5435]] [[RFC5435]]. |
Line 300: | Line 256: | ||
Syntax: Has one of the values "yes", "no", or "unknown". The value | Syntax: Has one of the values "yes", "no", or "unknown". The value | ||
MUST be in lower case. | MUST be in lower case. | ||
− | |||
− | |||
− | |||
− | |||
Permanent and readily available reference(s): [[RFC6132|RFC 6132]] | Permanent and readily available reference(s): [[RFC6132|RFC 6132]] | ||
Line 340: | Line 292: | ||
=== Normative References === | === Normative References === | ||
− | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | + | [[RFC2119]] Bradner, S., "Key words for use in RFCs to Indicate |
− | + | Requirement Levels", [[BCP14|BCP 14]], [[RFC2119|RFC 2119]], March 1997. | |
− | |||
− | |||
+ | [[RFC5228]] Guenther, P. and T. Showalter, "Sieve: An Email Filtering | ||
+ | Language", [[RFC5228|RFC 5228]], January 2008. | ||
+ | [[RFC5435]] Melnikov, A., Leiba, B., Segmuller, W., and T. Martin, | ||
+ | "Sieve Email Filtering: Extension for Notifications", | ||
+ | [[RFC5435|RFC 5435]], January 2009. | ||
+ | [[RFC6121]] Saint-Andre, P., "Extensible Messaging and Presence | ||
+ | Protocol (XMPP): Instant Messaging and Presence", RFC | ||
+ | 6121, March 2011. | ||
=== Informative References === | === Informative References === | ||
− | [RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, | + | [[RFC3863]] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, |
− | [RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. | + | W., and J. Peterson, "Presence Information Data Format |
− | [RFC5229] Homme, K., "Sieve Email Filtering: Variables Extension", | + | (PIDF)", [[RFC3863|RFC 3863]], August 2004. |
− | [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: | + | |
− | [RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV | + | [[RFC4480]] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. |
− | [RFC6133] George, R., Leiba, B., and A. Melnikov, "Sieve Email | + | Rosenberg, "RPID: Rich Presence Extensions to the Presence |
− | [RFC6134] Melnikov, A. and B. Leiba, "Sieve Extension: Externally | + | Information Data Format (PIDF)", [[RFC4480|RFC 4480]], July 2006. |
+ | |||
+ | [[RFC5229]] Homme, K., "Sieve Email Filtering: Variables Extension", | ||
+ | [[RFC5229|RFC 5229]], January 2008. | ||
+ | |||
+ | [[RFC5230]] Showalter, T. and N. Freed, "Sieve Email Filtering: | ||
+ | Vacation Extension", [[RFC5230|RFC 5230]], January 2008. | ||
+ | |||
+ | [[RFC5491]] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV | ||
+ | Presence Information Data Format Location Object (PIDF-LO) | ||
+ | Usage Clarification, Considerations, and Recommendations", | ||
+ | [[RFC5491|RFC 5491]], March 2009. | ||
+ | |||
+ | [[RFC6133]] George, R., Leiba, B., and A. Melnikov, "Sieve Email | ||
+ | Filtering: Use of Presence Information with Auto-Responder | ||
+ | Functionality", [[RFC6134|RFC 6134]], July 2011. | ||
+ | |||
+ | [[RFC6134]] Melnikov, A. and B. Leiba, "Sieve Extension: Externally | ||
+ | Stored Lists", [[RFC6134|RFC 6134]], July 2011. | ||
+ | |||
Authors' Addresses | Authors' Addresses | ||
Line 366: | Line 343: | ||
Phone: +91-080-41117676 | Phone: +91-080-41117676 | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
Barry Leiba | Barry Leiba | ||
Line 374: | Line 350: | ||
EMail: [email protected] | EMail: [email protected] | ||
URI: http://internetmessagingtechnology.org/ | URI: http://internetmessagingtechnology.org/ | ||
− | |||
− | |||
− | |||
− | |||
− | |||
[[Category:Standards Track]] | [[Category:Standards Track]] |
Latest revision as of 03:51, 22 October 2020
Internet Engineering Task Force (IETF) R. George Request for Comments: 6132 B. Leiba Category: Standards Track Huawei Technologies ISSN: 2070-1721 July 2011
Sieve Notification Using Presence Information
Abstract
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.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6132.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Contents
Introduction
Sometimes, it's desirable to tailor Sieve 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 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.
Terminology Used in This Document
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 RFC2119.
Testing Presence Information
This extension uses the notify_method_capability test, as defined in the Sieve RFC5228 Notify extension 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).
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.
Note that, while the items below are documented as similar to items in Extensible Messaging and Presence Protocol (XMPP) RFC6121, 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) RFC3863, RPID: Rich Presence Extensions to PIDF RFC4480, and GEOPRIV Presence Information Data Format Location Object (PIDF-LO) RFC5491.
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.
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.
Supported presence items are as follows:
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).
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 4.7.2.1 of RFC 6121 RFC6121. The value of this item is one of the following:
away: The user is temporarily away.
chat: The user is online and actively interested in chatting.
dnd: Do Not Disturb; the user does not wish to be disturbed now.
offline: The user is offline.
xa: The user is away for an extended period (xa = "eXtended Away").
unknown: The correct presence value could not be determined.
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 RFC5229 for use elsewhere (see example 3 in Section 3). Note that this is similar to the presence element with the same name that's defined in Section 4.7.2.2 of RFC 6121 RFC6121, and to the <note> element defined in section 4.1.6 of PIDF RFC3863.
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.
There is no capability string associated with this extension, but this requires support for "enotify" 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.
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.
Examples
1. 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.
require ["enotify"];
if notify_method_capability "xmpp:[email protected]" "busy" "no"
{ notify :message "You got mail" "xmpp:[email protected]?message;subject=SIEVE"; }
2. 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.
require ["enotify"];
if not notify_method_capability "xmpp:[email protected]" "busy" "yes"
{ notify :message "You got mail" "xmpp:[email protected]?message;subject=SIEVE"; }
3. This example uses the vacation extension RFC5230 to generate an
auto-reply RFC6133 if the sender is in the recipient's address book RFC6134 and the recipient's presence shows "extended away". The variables extension 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 auto-reply.
require ["extlists", "vacation", "enotify", "variables"];
if allof (
envelope :list "from" ":addrbook:default", notify_method_capability "xmpp:[email protected]" "show" "xa" ) { # :matches "*" is used here to extract the value if notify_method_capability :matches "xmpp:[email protected]" "status" "*" { set "resp_msg" "${1}"; } else { set "resp_msg" "I'm away from email for a while." } vacation :handle "ext-away" "${resp_msg}"; }
Security Considerations
Security considerations for Sieve RFC5228 and the Notify extension RFC5435 apply equally here. In addition, implementations MUST ensure that users cannot create scripts that access the presence information of others without the proper access controls.
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.
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. When caching presence tests, the server must be careful not to violate access controls that the presence server might have. Thus, cached results MUST NOT be used outside the context in which they were retrieved. If, for example, a script running on behalf of Adam requests presence information for Barbara, that information MAY be cached for a future script running on behalf of Adam, but MUST NOT be used to satisfy the same query in a script running on behalf of Cindy -- because the presence server will have to decide whether Cindy has access to that information.
IANA Considerations
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 RFC5435.
To: [email protected] Subject: Registration of a new notification-capability parameter Capability name: busy 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.
Syntax: Has one of the values "yes", "no", or "unknown". The value
MUST be in lower case.
Permanent and readily available reference(s): RFC 6132 Contact information: The Sieve discussion list, <[email protected]>
To: [email protected] Subject: Registration of a new notification-capability parameter Capability name: show Description: The availability status of the user. This is similar
to the presence element with the same name that's defined in Section 4.7.2.1 of RFC 6121.
Syntax: Has one of the values "away", "chat", "dnd", "offline",
"xa", or "unknown". The value MUST be in lower case.
Permanent and readily available reference(s): RFC 6132 Contact information: The Sieve discussion list, <[email protected]>
To: [email protected] Subject: Registration of a new notification-capability parameter Capability name: status 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 4.7.2.2 of RFC 6121.
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.
Permanent and readily available reference(s): RFC 6132 Contact information: The Sieve discussion list, <[email protected]>
Acknowledgments
The authors thank Alexey Melnikov for significant early feedback and suggestions.
References
Normative References
RFC2119 Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
RFC5228 Guenther, P. and T. Showalter, "Sieve: An Email Filtering
Language", RFC 5228, January 2008.
RFC5435 Melnikov, A., Leiba, B., Segmuller, W., and T. Martin,
"Sieve Email Filtering: Extension for Notifications", RFC 5435, January 2009.
RFC6121 Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011.
Informative References
RFC3863 Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr,
W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
RFC4480 Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
RFC5229 Homme, K., "Sieve Email Filtering: Variables Extension",
RFC 5229, January 2008.
RFC5230 Showalter, T. and N. Freed, "Sieve Email Filtering:
Vacation Extension", RFC 5230, January 2008.
RFC5491 Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
RFC6133 George, R., Leiba, B., and A. Melnikov, "Sieve Email
Filtering: Use of Presence Information with Auto-Responder Functionality", RFC 6134, July 2011.
RFC6134 Melnikov, A. and B. Leiba, "Sieve Extension: Externally
Stored Lists", RFC 6134, July 2011.
Authors' Addresses
Robins George Huawei Technologies Bangalore, Karnataka 560071 India
Phone: +91-080-41117676 EMail: [email protected]
Barry Leiba Huawei Technologies
Phone: +1 646 827 0648 EMail: [email protected] URI: http://internetmessagingtechnology.org/