RFC 6132

Sieve Notification Using Presence Information

📅 published July 2011, from ietf

RFC 6132: Sieve Notification Using Presence Information ✨

Okay bestie, this one is RFC 6132, titled Sieve Notification Using Presence Information 🎀 It's a Standards Track document by R. George and B. Leiba from Huawei Technologies, published in July 2011. It's listed under ISSN 2070-1721, and it doesn't list anything it Obsoletes or Updates, so it's standing on its own 💅

Abstract 🦋

Okay so this is an add-on for the Sieve mail filtering language's Notification extension 📬 It defines presence information you can check through the notify_method_capability feature, so your filters can actually see whether someone is around 🫶

Status of This Memo 📜

This is an Internet Standards Track document 🔥

It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the whole IETF community 🌈 It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 5741 📖

For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6132 🧚

Copyright (c) 2011 IETF Trust and the persons identified as the document authors 💜 All rights reserved, obviously.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date this document was published. Please actually read these, because they describe your rights and restrictions for this document 🙈 Also, any Code Components you pull out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Simplified BSD License ⚖️

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
  1.1.  Terminology Used in This Document . . . . . . . . . . . . . 2
2.  Testing Presence Information  . . . . . . . . . . . . . . . . . 2
3.  Examples  . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
  7.2.  Informative References  . . . . . . . . . . . . . . . . . . 8

1. Introduction ✨

Sometimes you want your Sieve [RFC5228] notifications to match what's going on with the user right now 🥹 That's where presence information comes in, since it tells you stuff about the user that's super useful in these moments. The Notification extension [RFC5435] already gives you a way to test for presence (the notify_method_capability feature), and it defines one presence test, the "online" notification-capability, which you can read about in Section 5 of RFC 5435 💖 This extension adds more presence tests by registering extra notification-capability parameters in the IANA registry, so you can test a much wider range of presence info 🌸

1.1. 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] 🎀

2. Testing Presence Information 💅

Okay so this extension uses the notify_method_capability test from the Sieve [RFC5228] Notify extension [RFC5435] to test presence info 🫧 Here's the vibe: when a Sieve event happens (mail arrives) for a user, a Sieve script running for that user can use the user's presence URI (in the "notification-uri" parameter) and test one specific item of notification presence, as defined below (in the "notification-capability" parameter). You compare it against one or more values (in the "key-list" parameter) ✨

This document defines a starter set of notification presence items you can put in the notification-capability parameter. It's expected that future extensions will add more presence items from different sources, like calendar info, geographic location, and so on 🗺️

Also, the items below are documented as being similar to items in the Extensible Messaging and Presence Protocol (XMPP) [RFC6121], but this extension is NOT meant to be tied to XMPP or any one source of presence 🙅‍♀️ Flexible implementations will be ready for future extensions, periodt 💜 If you want useful references for presence data and formats, check out the Presence Information Data Format (PIDF) [RFC3863], RPID: Rich Presence Extensions to PIDF [RFC4480], and the GEOPRIV Presence Information Data Format Location Object (PIDF-LO) [RFC5491] 📚

The script tests the values of the notification presence items in the key-list parameter. The values each item can have are listed below. Also, in addition to the presence values, ANY item can have the value "unknown" if it's not possible to figure out the correct presence value 🤷‍♀️

Now here's the rule I need you to remember, bestie 🚨 If a particular presence item gets tested more than once in the same script execution context, implementations MUST present the same value each time (for example, by caching the value on first use). This keeps things consistent within a single execution 🫶

Here are the supported presence items:

  • busy: This is an indication of whether the user is considered "busy" right now (the value "yes") or not (the value "no"), or "unknown" if it can't be determined 😭 What "busy" means is up to the implementation, and it may be a state that's made up from other info (including show, below) 🧠
  • show: This is the user's availability status, formally specified 🎀 It's similar to the presence element with the same name 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 actually up for chatting 💬
    • dnd: Do Not Disturb, so the user does not want to be disturbed right now 🔕
    • offline: The user is offline 🌙
    • xa: The user is away for an extended period (xa = "eXtended Away") 🧳
    • unknown: The correct presence value couldn't be determined 🫥
  • status: This is a human-readable description of the user's availability status, written in natural language 📝 There's no formal definition for the values it can take. It's free-form, and it can be in any language 🌍 Comparing directly against this value is unlikely to be useful, bestie. Instead, it's there so you can pull the value into a variable [RFC5229] and use it somewhere else (see example 3 in Section 3) 🪄 This is similar to the presence element with the same name 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 a user might type in directly, NO value, including "unknown", has any special meaning here 🙈 If the Sieve processor can't figure out the value of this item, it might be best to leave it as an empty string. Either way, this isn't meant for machine-readable processing, beyond possible XML interpretation 💀

There is no capability string associated with this extension, but it does require support for "enotify" [RFC5435] 🔥 If the implementation doesn't support the item being tested (meaning the specified notification-capability item isn't known to the Sieve interpreter), RFC 5435 already says the test fails without an error 😌

Even though this feature was made to help with notifications, and the test needs the Sieve Notify feature, it's only a condition test. That means ANY Sieve action can go inside it 🌈 There are no Sieve actions that conflict with this extension, so no drama there ✨

Part 1 of 2. Part 2 picks up with Section 3 (Examples).

4. Security Considerations 🔒✨

Okay bestie, this is the serious part 😤. The security considerations for Sieve [RFC5228] and the Notify extension [RFC5435] apply just as much here, no cap. On top of that, implementations MUST ensure that users cannot create scripts that access the presence information of others without the proper access controls 🚫🔐.

In some situations, a script might act on some of the recipient's presence information that the sender of the triggering message isn't allowed to see. Honestly, that can be a win for the recipient in lots of cases 🫶, but it also opens a door for a sender to poke around and probe the recipient's presence. Like, if messages sometimes get auto-replies and sometimes don't, the sender can work out what's going on 👀. So script authors, please think carefully about this whole aspect of presence-triggered actions 🧐.

Now the burst situation 💀. It's possible for a huge pile of messages to show up at or around the same time, and Sieve scripts that all test presence will process them together. If lots of users share the same presence server, that burst could put an unexpectedly heavy load on it 😩. Implementations might consider offering options for rate limiting, or for caching presence tests for some period of time, even across Sieve script instances 💅. When caching presence tests, the server must be careful not to violate any access controls the presence server might have 🙈. So cached results MUST NOT be used outside the context in which they were retrieved. For example, if 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 it MUST NOT be used to satisfy the same query in a script running on behalf of Cindy. Why? Because the presence server has to decide whether Cindy has access to that information in the first place 🔥.

5. IANA Considerations 📋🌈

This registers each presence item as a notification-capability parameter 🎀. Future extensions that add new presence items should register them the same way, using the instructions in Section 9.3 of RFC 5435 [RFC5435] 💜.

Here are the three registrations, verbatim:

To:  iana@iana.org
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, <sieve@ietf.org>

To:  iana@iana.org
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, <sieve@ietf.org>

To:  iana@iana.org
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, <sieve@ietf.org>

6. Acknowledgments 💖

The authors thank Alexey Melnikov for significant early feedback and suggestions 🫶.

7. References 📚

7.1. 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.

7.2. 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: robinsgv@gmail.com


Barry Leiba
Huawei Technologies

Phone: +1 646 827 0648
EMail: barryleiba@computer.org
URI:   http://internetmessagingtechnology.org/
📦 where this page comes from