-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathxep-0149.xml
169 lines (168 loc) · 8.09 KB
/
xep-0149.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Time Periods</title>
<abstract>This document defines a method to specify the valid time periods for states, events, and activities communicated via Jabber/XMPP protocols.</abstract>
&LEGALNOTICE;
<number>0149</number>
<status>Active</status>
<type>Informational</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0082</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.0</version>
<date>2006-01-24</date>
<initials>psa</initials>
<remark>Per a vote of the Jabber Council, advanced status to Active.</remark>
</revision>
<revision>
<version>0.2</version>
<date>2005-12-21</date>
<initials>psa</initials>
<remark>Updated to reflect draft-ietf-simple-rpid-10.</remark>
</revision>
<revision>
<version>0.1</version>
<date>2005-04-21</date>
<initials>psa</initials>
<remark>Initial version.</remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2005-04-07</date>
<initials>psa</initials>
<remark>Modified to use SHIM headers rather than a structured data format qualified by a dedicated namespace.</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2005-03-17</date>
<initials>psa</initials>
<remark>First draft.</remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>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;).</p>
<p>This document defines a straightforward XMPP extension for encapsulating information about time periods, using new headers that adhere to the format specified in &xep0131;.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This document addresses the following requirements:</p>
<ol>
<li>Provide the ability to specify time periods for states, events, and activities communicated via Jabber/XMPP protocols.</li>
<li>Conform to &xep0082;.</li>
</ol>
</section1>
<section1 topic='Protocol' anchor='protocol'>
<p>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:</p>
<ol>
<li>All start and stop dates MUST conform to the dateTime profile specified in <cite>XEP-0082</cite>.</li>
<li>All dateTime information MUST be expressed in UTC (i.e., with no timezone offsets).</li>
<li>Start and stop times SHOULD be understood by the recipient as estimates or approximations.</li>
<li>If both a start time and a stop time are specified, the stop time MUST be later than the start time.</li>
</ol>
<p>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;).</p>
<p>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.</p>
</section1>
<section1 topic='Examples' anchor='examples'>
<section2 topic='Basic Presence' anchor='presence'>
<p>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.</p>
<example caption='Basic Presence With Time Period'><![CDATA[
<presence>
<show>dnd</show>
<status>In a Meeting</status>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='Stop'>2005-03-17T11:30:00Z</header>
</headers>
</presence>
]]></example>
</section2>
<section2 topic='User Activity' anchor='activity'>
<p>An XMPP extension for user activity is specified in <cite>XEP-0108</cite>. It may be desirable to include time period information when publishing one's activity.</p>
<example caption='User Activity With Time Period'><![CDATA[
<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='activity1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='generic/juliet-activity'>
<item id='current'>
<activity xmlns='http://jabber.org/protocol/activity'>
<relaxing>
<partying/>
</relaxing>
<text xml:lang='en'>My best friend's birthday!</text>
</activity>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='Start'>2005-03-17T19:00:00Z</header>
<header name='Stop'>2005-03-17T23:00:00Z</header>
</headers>
</item>
</publish>
</pubsub>
</iq>
]]></example>
</section2>
<section2 topic='User Mood' anchor='mood'>
<p>An XMPP extension for user mood is specified in <cite>XEP-0107</cite>. It may be desirable to include time period information when publishing one's mood.</p>
<example caption='User Mood With Time Period'><![CDATA[
<iq type='set'
from='juliet@capulet.com/balcony'
to='pubsub.shakespeare.lit'
id='mood1'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='generic/juliet-mood'>
<item id='current'>
<mood xmlns='http://jabber.org/protocol/mood'>
<annoyed/>
<text>She has been bothering me *all day*!</text>
</mood>
<headers xmlns='http://jabber.org/protocol/shim'>
<header name='Start'>2005-03-17T07:00:00Z</header>
</headers>
</item>
</publish>
</pubsub>
</iq>
]]></example>
<p>Note that the start time is (intended to be) retroactive.</p>
</section2>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>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;).</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>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.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<section2 topic='SHIM Headers' anchor='registrar-shim'>
<p>The ®ISTRAR; includes the following entries in its registry of SHIM headers (see &SHIMHEADERS;).</p>
<code><![CDATA[
<header>
<name>Start</name>
<desc>The dateTime at which a state, event, or activity starts</desc>
<doc>XEP-0149</doc>
</header>
<header>
<name>Stop</name>
<desc>The dateTime at which a state, event, or activity stops</desc>
<doc>XEP-0149</doc>
</header>
]]></code>
</section2>
</section1>
</xep>