1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00

2.1rc1 /psa

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@3388 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Unknown User 2009-09-02 20:55:21 +00:00
parent 2330632983
commit 4e4b381d19

View File

@ -28,6 +28,12 @@
</schemaloc>
&stpeter;
&dizzyd;
<revision>
<version>2.1rc1</version>
<date>in progress, last updated 2009-09-02</date>
<initials>psa</initials>
<remark><p>Clarified that any state change is allowed.</p></remark>
</revision>
<revision>
<version>2.0</version>
<date>2008-11-26</date>
@ -154,59 +160,54 @@
<li>A "content message" -- that is, a message stanza whose primary meaning is contained in standard messaging content such as the XMPP &lt;body/&gt; or any other properly-namespaced child element(s) other than those defined for chat state notifications in this specification.</li>
<li>A "standalone notification" -- that is, a message stanza that does not contain standard messaging content but instead is intended to specify only the chat state since it contains only a child element qualified by the "http://jabber.org/protocol/chatstates" namespace (or possibly also the XMPP &lt;thread/&gt; element; see the <link url='#bizrules-threads'>Threads</link> section below).</li>
</ul>
<p>The five chat states specified in this document are described below. The suggested triggers and state changes are simply that: <em>suggestions</em>. It is up to the implementation to determine when to generate chat state notifications and which notifications to generate.</p>
<p>The five chat states specified in this document are described below. The suggested triggers are simply that: <em>suggestions</em>. It is up to the implementation to determine when to generate chat state notifications and which notifications to generate.</p>
<table caption='Chat States'>
<tr>
<th>State</th>
<th>Definition</th>
<th>Suggested Triggers</th>
<th>Suggested State Changes</th>
</tr>
<tr>
<td>&lt;active/&gt;</td>
<td>User is actively participating in the chat session.</td>
<td>User accepts an initial content message, sends a content message, gives focus to the chat session interface, or is otherwise paying attention to the conversation.</td>
<td>&lt;inactive/&gt;, &lt;composing/&gt;</td>
</tr>
<tr>
<td>&lt;composing/&gt;</td>
<td>User is composing a message.</td>
<td>User is interacting with a message input interface specific to this chat session (e.g., by typing in the input area of a chat window).</td>
<td>&lt;active/&gt;, &lt;paused/&gt;</td>
</tr>
<tr>
<td>&lt;paused/&gt;</td>
<td>User had been composing but now has stopped.</td>
<td>User was composing but has not interacted with the message input interface for a short period of time (e.g., 30 seconds). <note>An implementation could also "guess" that composing has been paused based on a change in the user's interaction with the message input interface, e.g. if the user switches window or application focus.</note></td>
<td>&lt;active/&gt;, &lt;composing/&gt;, &lt;inactive/&gt;</td>
<td>User accepts an initial content message, sends a content message, gives focus to the chat session interface (perhaps after being inactive), or is otherwise paying attention to the conversation.</td>
</tr>
<tr>
<td>&lt;inactive/&gt;</td>
<td>User has not been actively participating in the chat session.</td>
<td>User has not interacted with the chat session interface for an intermediate period of time (e.g., 2 minutes).</td>
<td>&lt;active/&gt;, &lt;paused/&gt;, &lt;gone/&gt;</td>
</tr>
<tr>
<td>&lt;gone/&gt;</td>
<td>User has effectively ended their participation in the chat session.</td>
<td>User has not interacted with the chat session interface, system, or device for a relatively long period of time (e.g., 10 minutes).</td>
<td>&lt;active/&gt;</td>
</tr>
<tr>
<td>&lt;composing/&gt;</td>
<td>User is composing a message.</td>
<td>User is actively interacting with a message input interface specific to this chat session (e.g., by typing in the input area of a chat window).</td>
</tr>
<tr>
<td>&lt;paused/&gt;</td>
<td>User had been composing but now has stopped.</td>
<td>User was composing but has not interacted with the message input interface for a short period of time (e.g., 30 seconds).</td>
</tr>
</table>
<p>Note that the &lt;active/&gt;, &lt;inactive/&gt;, and &lt;gone/&gt; states refer to the overall chat session interface whereas the &lt;composing/&gt; and &lt;paused/&gt; states refer to the message input interface (and are in some sense a subset of &lt;active/&gt;). Some implementations might support only events related to the message input interface, some implementations might support only events related to the overall chat session interface, and some implementations might support both kinds of events.</p>
</section1>
<section1 topic='State Chart' anchor='statechart'>
<p>The following figure attempts to capture the possible state transitions in visual form.</p>
<p>The following figure attempts to capture the most common state transitions in visual form (all four of the states shown can also transition to the GONE state).</p>
<code><![CDATA[
o (start)
|
|
INACTIVE <--> ACTIVE <--> COMPOSING
| ^ |
| | |
+ <------ PAUSED <-----> +
INACTIVE <--> ACTIVE <--> COMPOSING <--> PAUSED
| |
| |
+---<---<---<---<---<---<---<---<---<---+
]]></code>
<p>Note: All four of the states shown can transition to the GONE state.</p>
<p>Note: Other transitions are not forbidden if the developers of an implementation feel that such transitions are desirable (e.g., INACTIVE to PAUSED if a user returns to a chat session interface containing an unfinished message).</p>
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>If an entity supports the Chat State Notifications protocol, it MUST advertise that fact in its responses to &xep0030; information ("disco#info") requests by returning a feature of "http://jabber.org/protocol/chatstates":</p>