%ents; ]>
Time Periods This document defines a method to specify the valid time periods for states, events, and activities communicated via Jabber/XMPP protocols. &LEGALNOTICE; 0149 Active Informational Standards Council XMPP Core XEP-0082 N/A &stpeter; 1.0 2006-01-24 psa Per a vote of the Jabber Council, advanced status to Active. 0.2 2005-12-21 psa Updated to reflect draft-ietf-simple-rpid-10. 0.1 2005-04-21 psa Initial version. 0.0.2 2005-04-07 psa Modified to use SHIM headers rather than a structured data format qualified by a dedicated namespace. 0.0.1 2005-03-17 psa First draft.

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 &xep0119;).

This document defines a straightforward XMPP extension for encapsulating information about time periods, using new headers that adhere to the format specified in &xep0131;.

This document addresses the following requirements:

  1. Provide the ability to specify time periods for states, events, and activities communicated via Jabber/XMPP protocols.
  2. Conform to &xep0082;.

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:

  1. All start and stop dates MUST conform to the dateTime profile specified in XEP-0082.
  2. All dateTime information MUST be expressed in UTC (i.e., with no timezone offsets).
  3. Start and stop times SHOULD be understood by the recipient as estimates or approximations.
  4. 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 &rfc3921;) and various "extended presence" states, events, and activities (see, for example, &xep0107; and &xep0108;).

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.

dnd In a Meeting
2005-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:00Z
2005-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 &rfc4480;, see also &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 &IANA;.

The ®ISTRAR; includes the following entries in its registry of SHIM headers (see &SHIMHEADERS;).

Start The dateTime at which a state, event, or activity starts XEP-0149
Stop The dateTime at which a state, event, or activity stops XEP-0149
]]>