Out-of-Office Messages

%ents; ]>

Out-of-Office Messages This document defines an XMPP protocol extension for communicating out-of-office status. &LEGALNOTICE; 0109 Deferred Standards Track Standards XEP-0060 XEP-0163 ooo Darrell Piner dpiner@cisco.com dpiner@cisco.com Robert Norris rob@cataclysm.cx rob@cataclysm.cx 0.3.1 2018-11-03 pep Fix a bunch of typos, batch-style. 0.3 2010-05-24 rdp Modified specification to use PEP instead of a dedicated protocol; streamlined use cases; changed namespace to urn:xmpp:ooo:0. 0.2 2003-08-12 rn Added use cases for removing vacation settings; described semantics when start and end times are not specified; changed document type to Informational; small editorial changes. 0.1 2003-07-28 rn Initial version.

Popular electronic mail systems include features allowing users to set up automated messages that are returned to message senders when the user is not able to deal with the message immediately. This feature is commonly known as "out-of-office" or "vacation" messages, because it is most commonly used when a user is unable to read their messages because they are out of the office (e.g., on vacation).

This document describes a similar system that enables XMPP users to setup out-of-office messages when they are away.

The basis for the e-mail system mechanism is considering an incoming message at the server level and determining whether to respond with a canned out-of-office message. While a system may send a response for each incoming message, many systems provide an optimization where a response to subsequent e-mail messages is sent after some period of time expires.

The requirements for this feature are fairly straightforward. A user MUST be able to:

Retrieve their current out-of-office settings.
Set new out-of-office settings.
Remove out-of-office settings.
Notify interested parties of the out-of-office settings when it is in effect.

All these requirements are satisfied by &xep0163;, which is a subset of &xep0060;.

The out-of-office setting contains a start-time, an end-time and a short message text.

The start and end times are informational only; i.e., the server does nothing with these values other than store them. PEP does not include node lifetime management (i.e., start and end times for the node); therefore, the server is unable to enforce any start and end times included in the settings.

Using the PEP mechanism a client creates out-of-office settings on a PEP node with the desired access model (such as Presence or Open). When a user (or their client) sends presence containing CAPS (see &xep0115;) with an entry for out-of-office to a contact with an out-of-office message, the user's client is notified of the out-of-office message and may display, in a client-defined fashion, the out-of-office settings information.

Clients may rely on the PEP node for notifications of changes as well as automatic notification when the user logs-in (i.e., a user is notified of the current item on the out-of-office PEP node of another user on sending initial presence).

A user may request their current out-of-office message by sending an IQ get to the local server like so:

]]> 2003-07-06T10:30:00+10:00 2003-07-13T08:00:00+10:00 I'm attending OSCON in sunny Portland and won't be able to read your message until I get back. If it's urgent, please send email to rob@cataclysm.cx. ]]>

The <start/> and <end/> elements define the times between which this vacation message should be considered valid by a supporting client; the times are in the format specified by &xep0082;.

The <message/> element contains the text of the message which the client may display for the user (when appropriate).

If the user has no stored vacation message, the user will receive a result like the following:

]]>

A user may set new vacation message by publishing a new item with an id of 'current' to the out-of-office node:

2003-07-06T10:30:00+10:00 2003-07-13T08:00:00+10:00 I'm attending OSCON in sunny Portland and won't be able to read your message until I get back. If it's urgent, please send email to rob@cataclysm.cx. ]]> 2003-07-06T10:30:00+10:00 2003-07-13T08:00:00+10:00 I'm attending OSCON in sunny Portland and won't be able to read your message until I get back. If it's urgent, please send email to rob@cataclysm.cx. ]]>

And by design, PEP sends a notification to all the user's resources.

The meaning of each element is as outlined above. All elements are required.

Additionally, the <start/> and <end/> elements MAY be empty (i.e., have no CDATA). When <start/> is empty, the client MUST take this to mean that the settings should take effect immediately. Similarly, when <end/> is empty, the client MUST take this to mean that the settings should never expire (unless they are explicitly removed).

A user may remove all stored vacation settings by sending an IQ to the local server like so:

]]> ]]>

TODO: Is the Delete And Notify functionality described in XEP-0060 7.2.2.1 widely implemented? If so, should that case be included here?

In PEP, a node's default access model is 'presence' (i.e., any other user with a subscription type "from" or "both" may subscribe to the node. PEP provides other access models including a 'whitelist.' See &xep0060; section 4.5 for a list of Node Access Models.

The whitelist access model can be used to hide the current out-of-office message. With an empty whitelist, no other users receive notification when the node changes. The client may also use this fact to allow the client's user to set up an out-of-office message before it becomes active.

See &xep0060; Section 8.2 for details on configuration the out-of-office node's access model.