Certain events and states may last for only a limited period of time. For example, when a person changes his availability to "dnd" and his status to "In a Meeting", the person (or his calendaring application) may know that the meeting is expected to last for 90 minutes; because those who subscribe to the person's presence may find it helpful to know how long the person will be in the meeting, it might be desirable to include that time period information in the presence stanza sent when the person's availability changes. Similar considerations apply to other states, events, and activities, such as various forms of "extended presence" (see Extended Presence Protocol Suite (XEP-0119)XEP-0119: Extended Presence Protocol Suite <https://xmpp.org/extensions/xep-0119.html>.).
This document defines a straightforward XMPP extension for encapsulating information about time periods, using new headers that adhere to the format specified in Stanza Headers and Internet Metadata (XEP-0131)XEP-0131: Stanza Headers and Internet Metadata <https://xmpp.org/extensions/xep-0131.html>..
This document addresses the following requirements:
Provide the ability to specify time periods for states, events, and activities communicated via Jabber/XMPP protocols.
Conform to XMPP Date and Time Profiles (XEP-0082)XEP-0082: XMPP Date and Time Profiles <https://xmpp.org/extensions/xep-0082.html>..
In order to specify the time period for a state, event, or activity, the generating entity SHOULD include both "Start" and "Stop" SHIM headers that specify the dateTimes at which the time period starts and stops. The following rules apply:
All start and stop dates MUST conform to the dateTime profile specified in XEP-0082.
All dateTime information MUST be expressed in UTC (i.e., with no timezone offsets).
Start and stop times SHOULD be understood by the recipient as estimates or approximations.
If both a start time and a stop time are specified, the stop time MUST be later than the start time.
These SHIM headers MAY be included wherever appropriate; however, it is expected that they will be included mainly to further specify basic presence states (see RFC 3921RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc3921>.) and various "extended presence" states, events, and activities (see, for example, User Mood (XEP-0107)XEP-0107: User Mood <https://xmpp.org/extensions/xep-0107.html>. and User Activity (XEP-0108)XEP-0108: User Activity <https://xmpp.org/extensions/xep-0108.html>.).
There is no requirement that the start time needs to be the time when the stanza is generated; for example, the start time may be retroactive to a dateTime in the past or may be an estimated dateTime in the future.
In order to specify that a basic presence state will last for a specific time period, the entity that generates the presence stanza SHOULD include the desired SHIM headers.
dndIn a Meeting2005-03-17T11:30:00Z
]]>
An XMPP extension for user activity is specified in XEP-0108. It may be desirable to include time period information when publishing one's activity.
My best friend's birthday!2005-03-17T19:00:00Z2005-03-17T23:00:00Z
]]>
An XMPP extension for user mood is specified in XEP-0107. It may be desirable to include time period information when publishing one's mood.
She has been bothering me *all day*!2005-03-17T07:00:00Z
]]>
Note that the start time is (intended to be) retroactive.
For the sake of interoperability, it may be desirable for certain kinds of implementations (e.g., gateways) to transform XMPP start and stop times into the formats used by other protocols (e.g., the 'from' and 'until' attributes specified in RFC 4480RFC 4480: RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF) <http://tools.ietf.org/html/rfc4480>., see also RFC 4481RFC 4481: Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals <http://tools.ietf.org/html/rfc4481>.).
It is possible that inclusion of time periods for particular states, events, or activities may reveal information that would enable a recipient to launch an attack while the sender is unavailable or away (e.g., if the sender specifies that he will be on vacation for the next three weeks, a recipient might therefore learn that this is a good time to break into the sender's house). Therefore, senders of time period information should balance the desire to share helpful information against the need for appropriate control over security-critical availability information.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA)The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>..
The XMPP RegistrarThe XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>. includes the following entries in its registry of SHIM headers (see <https://xmpp.org/registrar/shim.html>).
StartThe dateTime at which a state, event, or activity startsXEP-0149StopThe dateTime at which a state, event, or activity stopsXEP-0149
]]>