查看源代码

[[Category:XMPP扩展]]
[[Category:已翻译]]

'''本文的英文原文来自[http://www.xmpp.org/extensions/xep-0085.html XEP-0085]'''

'''XEP-0085:聊天状态通知'''
	
本文定义了一个XMPP协议扩展,用于沟通用户的聊天状态，从而表明聊天的好友是否正积极参与聊天，撰写邮件，暂时中止，无效的，或消失。本协议可用于一对一聊天会话的上下文或多用户聊天室。

注意: 这里定义的协议是XMPP标准化基金会的一个草案标准.对本协议的执行是被鼓励的,也适于部署到生产系统,但是在它成为最终标准之前可能还会有一些变动.

'''文档信息'''

系列: [http://www.xmpp.org/extensions/ XEP] [[XMPP扩展|译文]]

编号: 0085

发行者: [http://www.xmpp.org/xsf/ XMPP标准化基金会] [[XMPP标准基金会|译文]]

状态: 草案

类型: 标准跟踪

版本: 1.2

最后更新日期: 2006-07-12

批准机构: [http://www.xmpp.org/council/ XMPP理事会] [[XMPP理事会|译文]]

依赖于: [[RFC3920|XMPP Core]], [[RFC3921|XMPP IM]], XEP-0030

上文: XEP-0022(部分)

下文: 无

简称: chatstates

名字空间的XML方案: <http://www.xmpp.org/schemas/chatstates.xsd>

注册项: <http://www.xmpp.org/registrar/amp.html>

Wiki页: <http://wiki.jabber.org/index.php/Chat State Notifications (XEP-0085)>

'''作者信息'''

'''Peter Saint-Andre'''

:JID: [xmpp:stpeter@jabber.org stpeter@jabber.org]

:URI: <https://stpeter.im/>

'''Dave Smith'''

:Email: [mailto:dizzyd@jabber.org dizzyd@jabber.org]

:JabberID: [xmpp:dizzyd@jabber.org dizzyd@jabber.org]

'''法律通告'''

'''版权'''

XMPP扩展协议的版权(1999-2008)归XMPP标准化基金会(XSF)所有.

'''权限'''

特此授权,费用全免,对任何获得本协议副本的人,对使用本协议没有限制,包括不限制在软件程序中实现本协议,不限制在网络服务中布署本协议,不限制拷贝,修改,合并,发行,翻译,分发,转授,或销售本协议的副本,被允许使用本协议做了以上工作的人士,应接受前述的版权声明和本许可通知并且必须包含在所有的副本或实质性部分的规格中.除非单独的许可，被重新分发的修改工作，不得含有关于作者，标题，编号，或出版者的规格的误导性资料，并不得宣称修改工作是由本文的作者，作者所属的任何组织或项目，或XMPP标准基金会签注。
 	
'''免责声明'''

注意：本协议是提供的“原样”的基础，没有担保或任何形式的条件，明示或暗示，包括，但不限于任何担保或关于名称，非侵权性，适销性或适合作某一特定目的的条件.在任何情况XMPP标准基金会或作者不对此协议承担任何责任索赔，损害赔偿，或其他责任，无论是在一项行动的合同，侵权，或否则，所产生的，运出，或在他涉嫌与规格或执行，部署或以其它方式使用本协议. ##

'''责任限制'''

在任何情况下以及没有任何法律规定时，不论是侵权行为（包括疏忽），合同或其它方面，除非根据适用法律的要求（如蓄意和有严重疏忽行为）或同意以书面形式，XMPP标准基金会或任何作者不对本协议承担所造成的损失，包括任何直接，间接，特殊，偶发，或相应的损害赔偿的任何字符利用所产生的或不能使用的规格（包括但不限于善意的损失，停止作业，电脑失灵或故障，或任何和所有其他商业损害或损失） ，即使XMPP标准基金会或作者已被告知此类损害的可能性。

'''知识产权的一致性'''

XMPP扩展协议完全遵守XSF的知识产权策略(可在<http://www.xmpp.org/extensions/ipr-policy.shtml>找到副本或写信给XSF, P.O. Box 1641, Denver, CO 80201 USA). 

'''讨论地点'''

首选的讨论的地方是标准讨论邮件列表: <http://mail.jabber.org/mailman/listinfo/standards>.
勘误表发送到[mailto:editor@xmpp.org editor@xmpp.org]

'''XMPP 相关信息'''

XMPP 是由XSF(XMPP标准化基金会)按互联网标准程序贡献的,和 IETF的RFC 2026兼容的规范,包括 XMPP核心(RFC 3920)和 XMPP IM(RFC 3921).在本文中定义的任何协议,都是在互联网标准程序之外开发的,是扩展XMPP，而不是改变、发展和修改 XMPP本身。

'''一致性术语'''

本文中以下关键词的含义如 RFC 2119 所述: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

==绪论==

许多即时通讯系统包含了一对一聊天的聊天状态的提醒(或者，有时，在多对多聊天中也包含)。通常在用户的伙伴在正在输入的时候会被限制。比如 在XEP-0022定义的 Composing事件(参考消息事件)。然而，一个composing事件实质上是关于个人参与或者涉及的聊天会话的信息，比如在XEP-0022中的分发和显示事件。当一个 composing事件引起兴趣并被关注时，会话等级状态的概念能够被扩展以说明关于即时聊天的参与者的一些问题如下:

* 这个参与者是否已经停止了输入？

* 这个参与者是否注意这次聊天？

* 这个参与者是否暂时没有激活这个会话(换言之，此时没有注意这次聊天)？

* 这个参与者是否已离开(也就是说不再参与这次聊天了)？

为了回答这些问题，本文档通过定义4种附加状态(paused, active, inactive, gone)来提供表明传统输入的状态，一共(是本协议期望的)5种状态一起完整的描述在参与者参与的或者涉及的聊天会话的可能能的状态。

==定义==

实质上，聊天状态的通知可以被看作是特定会话的出席信息的一种形式。比如，考虑下可能发生如下状况，如果用户在桌面上丢失了一个聊天窗口；用户可能仍旧被他的消息客户端影响(因此，不会自动改变基础的出席消息为away)，但是用户的聊天会话的状态可能从active状态转换为inactive，然后又转换为gone。这些信息将会帮助用户的聊天伙伴了解为什么没有从她那里受到回复消息。聊天状态通知能够出现在<message/>节中。

* 一个“文本消息”————包含了<body/>, <subject/>, and <thread/> 子元素的标准消息，该消息在XMPP IM中定义，或者包含其他命名空间的子元素。

* 一个“单独的通知”————没有包含标准的消息文本的消息，而是只包含了期望的指定的聊天状态，也就是只包含了"http://jabber.org/protocol/chatstates" 命名的空间限定的子元素(或者也可以包含<thread/>元素；参考下面的threads部分)

本文档的5种状态在下文中有描述。建议的触发状况和状态的改变是很简单的。这取决于具体实现来决定何时生成聊天状态通知以及生成什么通知。

'''表格 1: Chat States'''


{|border="1" cellspacing="0" 
!状态 !!定义 !!建议的触发状况 !!建议的状态变化
|-
|<active/> ||用户激活并参与聊天会话中。 ||用户接收初始文本消息，并发送一条文本消息，聊天界面获取焦点，或者用户注意到了聊天对话。 ||<inactive/>, <composing/>
|-
|<composing/> ||用户正在输入消息 ||用户在指定的聊天会话中受消息输入的影响(比如， 在聊天窗口的输入区域中输入) ||<active/>, <paused/>
|-
|<paused/> ||用户之前在输入但是现在停止了 ||用户正在输入消息但是短时间内没有对输入界面操作(比如5秒) ||<active/>, <composing/>, <inactive/>
|-
|<inactive/> ||用户在会话中没有激活 ||用户有一段时间没有对聊天界面进行操作。(比如30秒) ||<active/>, <gone/>
|-
|<gone/> ||用户终止参与聊天会话。 ||用户长时间没有对聊天界面或者系统或者设备进行操作(比如2分钟)，或者终止关闭了聊天界面(比如关闭了聊天窗口) ||<active/>
|}

==状态图==

以下状态图试图用可视化的方式记录了可能的状态转换。

{image:img=状态图}

注意：这4种显示的状态都可能转换成gone状态

==查询是否支持==

如果一个实体支持聊天状态通知,它必须(MUST)根据“服务发现”中的信息("disco#info")，对于请求返回"http://jabber.org/protocol/chatstates"的feature：

'''例子1. 一个 disco#info查询'''

<source lang="xml">
<iq type='get' 
    from='romeo@shakespeare.lit/orchard'
    to='juliet@capulet.com/balcony'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
</source>

'''例子2. 一个 disco#info回应'''

<source lang="xml">
<iq type='result' 
    from='juliet@capulet.com/balcony'
    to='romeo@shakespeare.lit/orchard'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='http://jabber.org/protocol/chatstates'/>
    ...
  </query>
</iq>
</source>

另外，可以通过在“实体能力”中定义的服务发现的动态情况来决定是否支持聊天状态通知。

==商业规则==

===通知的生成===

在生成聊天状态通知前，用户应该(SHOULD)明确的查询联系人是否支持在此定义的协议(参考本文当的“服务发现”部分描述的)或者明确的与联系人协商聊天状态通知的使用(通过“节点会话协商”)。

如果没有明确地查询或者协商，用户可以(MAY)通过下如附加的商业规则来暗示在一对一聊天中使用聊天状态通知。

# 如果用户希望得到聊天状态通知，那么发送给联系人的初始文本消息必须(MUST)包含聊天状态扩展，扩展应该(SHOULD)是<active/>。
# 直到收到一个从联系人那里发送的初始文本消息的回复(或者一个单纯的通知)，用户不能(MUST NOT)继续发送聊天状态通知给联系人。
# 如果联系人对初始文本消息的回复中没有包含聊天状态通知扩展，用户不能(MUST NOT)继续发送聊天状态通知给联系人。
# 如果联系人对初始文本消息的回复中包含了<active/>通知(或者发送一个单独的通知给用户)，用户和联系人应该(SHOULD)继续发送聊天状态通知(就如以下部分指出的)，该通知包含一个<active/>通知，并且在每条文本消息中或者单纯的状态通知中包含他们所支持的聊天状态通知(至少包含<composing/>状态)

前述的规则意味着发送聊天状态是双向的(换言之，用户和联系人要么都发送聊天状态通知要么都不发送)而不是单向的(比如一个伙伴发送聊天状态通知而另一个不发送)；这是设计决定的。

===支持要求===

'''表格 2: 对所有聊天状态的支持要求'''

{|border="1" cellspacing="0" 
!聊天状态 !!要求
|-
|<active/> ||必须(MUST)
|-
|<composing/> ||必须(MUST)
|-
|<paused/> ||应该(SHOULD)
|-
|<inactive/> ||应该(SHOULD)
|-
|<gone/> ||应该(SHOULD)
|}

客户端必须(MUST)允许用户配置是否愿意发送聊天状态通知。

注意：只支持<active/>  <composing/>状态在功能上等同于支持XEP-0022的输入事件

===重复===

即使用户持续输入的很长一段时间(比如，如果在输入一个很长，内容很多的回复)，客户端不能(MUST NOT)发送更多的单独的<composing/>通知。更通常的说，客户端不能(MUST NOT)发送第二个任何已经发送的单独的状态通知(换言之，一个单独的状态通知必须(MUST)有不同的状态，不能重复相同的状态)。然而，每个文本消息都应该(SHOULD)包含<active/>通知。

===上下文使用===

# 本协议不能(MUST NOT)在其他<message/>节点中使用
# 本协议不应该(SHOULD NOT)在chat或者groupchat类型以外的消息中使用。
# 文本消息或者单独的状态通知的type属性应该(SHOULD)设置为chat(一对一会话中)或者	groupchat(多对多会话中)
# 一个聊天会话可能(MAY)延伸持续为多人用户会话(换言之, 聊天状态对于多方都是可用的已经对	话伙伴的出席信息)，虽然对于建议的事件触发器的计时是不太可能的。

===在多人聊天中使用===

聊天状态通知可以(MAY)发送到群聊房间中(比如，“多用户聊天”中定义的)。以下商业规则将会被应用：

# 客户端可以(MAY)发送聊天状态通知，即使不是所有的驻留者这么做。
# 客户端不应该(SHOULD NOT)生成<gone/>通知。
# 客户端应该(SHOULD)忽略从房间其他驻留者发送的<gone/>通知

注意：在群聊的上下文中使用状态通知会导致这些通知的多播。凡事预则立，事先应该预料一下。

===通知语法===

# 消息节点中不能(MUST NOT)包含超过一个用'http://jabber.org/protocol/chatstates'限定的子元素
# 消息节点包含标准的消息文本(换言之，就是包含在XMPP IM中定义的<body/><subject/><thread/>子元素或其他命名空间的子元素，不应该包含除了<active/>扩展以外的状态通知。)
# 一条未包含标准文本并且要包含特定聊天状态的消息不能(MUST NOT)包含除聊天状态通知以外的子元素,而且也应该(SHOULD)排除<active/>；然而，如果使用了thread(参考下文)那么单独的状态通知必须(MUST)包含<thread/>元素。

===线索===

聊天状态通知提供了管理聊天线索的机制(比如，<thread/>元素),对于threads的支持是可选的(OPTIONAL)。然而，如果所有参与聊天的客户端都支持和使用threads，那么将应用以下商业规则：

# 客户端必须(MUST)在回复中复制并返回threadID(就是指<thread/>元素的值)
# 当一个客户端终止一对一聊天会话的时候(比如，用户关闭了聊天会话界面)，它必须(MUST)生	成一个<gone/>事件。
# 在接收到<gone/>事件后，客户端不能(MUST NOT)重用相同的thread ID，必须(MUST)	在之后的任何聊天消息中使用新生成的thread ID发送对方。

===服务对通知的处理===

当服务器在网络环境较差的环境中(比如，正在通过“Jabber HTTP Polling”或者 BOSH为带宽较低的客户端服务)或者服务在重复的广播消息节点时(比如，多用户聊天服务)可能(MAY)以不同于其他消息的处理方式处理单独的状态通知。特别的，服务器或者服务可能(MAY)拒绝分发单独的状态通知给其他用户，而且不应该(SHOULD NOT)保留离线的状态通知。与之相反的是XEP-0022,聊天状态通知完全是客户端的责任，不允许(MUST NOT)由服务器或者服务生成。

==一个简单例子==

现在下面的会话中，用户和联系人都支持聊天状态通知。

'''例子3. 用户发送带有<active/>通知的初始文本消息。'''

<source lang="xml">
<message 
    from='bernardo@shakespeare.lit/pda'
    to='francisco@shakespeare.lit'
    type='chat'>
  <body>Who's there?</body>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

'''例子4. 联系人客户端返回带有<active/>通知的文本消息。'''

<source lang="xml">
<message 
    from='francisco@shakespeare.lit/elsinore'
    to='bernardo@shakespeare.lit/pda'
    type='chat'>
  <body>Nay, answer me: stand, and unfold yourself.</body>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

因为用户现在知道联系人支持聊天状态通知，用户就能发送其他状态类型了。

'''例子5. 用户发送单独的<composing/>通知'''

<source lang="xml">
<message 
    from='bernardo@shakespeare.lit/pda'
    to='francisco@shakespeare.lit/elsinore'
    type='chat'>
  <composing xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

'''例子6. 用户返回带有<active/>通知的文本消息'''

<source lang="xml">
<message 
    from='bernardo@shakespeare.lit/pda'
    to='francisco@shakespeare.lit/elsinore'
    type='chat'>
  <body>Long live the king!</body>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

以此类推。

==会话细节==

接下来的会话中说明了聊天状态通知的更多细节(在例子中也使用了threads)

'''例子7. 用户发送初始文本消息'''

<source lang="xml">
<message 
    from='romeo@shakespeare.lit/orchard'
    to='juliet@capulet.com'
    type='chat'>
  <thread>act2scene2chat1</thread>
  <body>
    I take thee at thy word:
    Call me but love, and I'll be new baptized;
    Henceforth I never will be Romeo.
  </body>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

在此，Juliet的客户端知道Romeo的客户端支持聊天状态通知。那么她就回复一个带有状态通知的初始文本消息

'''例子 8. 联系人客户端回复带有<actiev/>状态的文本消息'''

<source lang="xml">
<message 
    from='juliet@capulet.com/balcony'
    to='romeo@shakespeare.lit/orchard'
    type='chat'>
  <thread>act2scene2chat1</thread>
  <body>
    What man art thou that thus bescreen'd in night
    So stumblest on my counsel?
  </body>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

那么会话继续。过了一会，Juliet问了Romeo一个问题，激活了Romeo的客户端。Romeo开始输入针对Juliet真诚的问题的回复，那么他的Jabber客户端通知Juliet，他正在输入。

'''例子 9. 用户的客户端发送单独的<composing/>通知。'''

<source lang="xml">
<message 
    from='romeo@montague.net/orchard' 
    to='juliet@capulet.com/balcony'
    type='chat'>
  <thread>act2scene2chat1</thread>
  <composing xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

Romeo意识到他的回答太草率了，然后暂停并选择正确的语句；过了一会儿(可以配置的),他的Jabber客户端判断出了延迟并发送<paused/>状态

'''例子10. 用户客户端发送单独的<paused/>通知'''

<source lang="xml">
<message 
    from='romeo@montague.net/orchard' 
    to='juliet@capulet.com/balcony'
    type='chat'>
  <thread>act2scene2chat1</thread>
  <paused xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

Romeo又开始输入，他的Jabber客户端发送<composing/>通知给Juliet客户端。

'''例子11. 用户客户端发送单独的<composing/>通知'''

<source lang="xml">
<message 
    from='romeo@montague.net/orchard' 
    to='juliet@capulet.com/balcony'
    type='chat'>
  <thread>act2scene2chat1</thread>
  <composing xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

Romeo最后发送了回复。

'''例子12. 用户回复'''

<source lang="xml">
<message 
    from='romeo@montague.net/orchard' 
    to='juliet@capulet.com/balcony'
    type='chat'>
  <thread>act2scene2chat1</thread>
  <body>Neither, fair saint, if either thee dislike.</body>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

对话像潮水一样一次一次，直到Juliet被她的护士叫去。

'''例子13. 联系人发送文本消息'''

<source lang="xml">
<message 
    from='juliet@capulet.com/balcony'
    to='romeo@shakespeare.lit/orchard'
    type='chat'>
  <thread>act2scene2chat1</thread>
  <body>
    I hear some noise within; dear love, adieu!
    Anon, good nurse! Sweet Montague, be true.
    Stay but a little, I will come again.
  </body>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

我们假定Juliet最小化了聊天窗口,那么她的客户端生成<inactive/> 通知

'''例子14. 联系人客户端发送单独的<inactive/> 通知'''

<source lang="xml">
<message 
    from='juliet@capulet.com/balcony'
    to='romeo@shakespeare.lit/orchard'
    type='chat'>
  <thread>act2scene2chat1</thread>
  <inactive xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

当她回来并还原窗口，她的客户端生成一个<active/>通知：

'''例子15. 联系人客户端发送单独的<active/>通知'''

<source lang="xml">
<message 
    from='juliet@capulet.com/balcony'
    to='romeo@shakespeare.lit/orchard'
    type='chat'>
  <thread>act2scene2chat1</thread>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

对话继续，但是Juliet被那么爱唠叨的护士又叫去了。

'''例子16. 联系人客户端发送文本消息'''

<source lang="xml">
<message 
    from='juliet@capulet.com/balcony'
    to='romeo@shakespeare.lit/orchard'
    type='chat'>
  <thread>act2scene2chat1</thread>
  <body>
    A thousand times good night!
  </body>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

我们假设Juliet关闭了聊天窗口，那么她的客户端生成<gone/>通知：

'''例子17. 联系人发送单独的<gone/>状态'''

<source lang="xml">
<message 
    from='juliet@capulet.com/balcony'
    to='romeo@shakespeare.lit/orchard'
    type='chat'>
  <thread>act2scene2chat1</thread>
  <gone xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

Romeo的客户端现在认为这个聊天线索结束了，当他发送一条新消息时，生成一个新的thread ID

'''例子18. 用户的客户端用新的thread ID发送文本消息'''

<source lang="xml">
<message 
    from='romeo@shakespeare.lit/orchard'
    to='juliet@capulet.com/balcony'
    type='chat'>
  <thread>act2scene2chat2</thread>
  <body>
    A thousand times the worse, to want thy light.
    Love goes toward love, as schoolboys from their books,
    But love from love, toward school with heavy looks.
  </body>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

当juliet返回在她楼厅里的电脑时，她发现来自Romeo的新消息。当她回复时，她的客户端回复包含了<active/>的通知和新的thread ID。

'''例子19. 联系人客户端发送文本消息'''

<source lang="xml">
<message 
    from='juliet@capulet.com/balcony'
    to='romeo@shakespeare.lit/orchard'
    type='chat'>
  <thread>act2scene2chat2</thread>
  <body>
    Hist! Romeo, hist! O, for a falconer's voice,....
  </body>
  <active xmlns='http://jabber.org/protocol/chatstates'/>
</message>
</source>

以此类推。

天哪，这些倒霉的恋人确实会继续下去，不是么？

==实现注意==

从另一个实体收到状态通知的客户端应该预计到它可能再也不会收到对方的下一个消息或者聊天状态通知(比如，因为其他实体死机或者下线)并应该对此应该有相应的计划。

==安全事项==

聊天线索的状态说明了用户和他的计算机之间的交互，包括物理上的出席状况；这类信息不应该(SHOULD NOT)显示给不被信任的参与会话的用户。客户端的实现必须(MUST)提供使用户能够根据需要禁止聊天状态通知的机制。

==IANA事项==

本文档不需要IANA事项。

==XMPP注册事项==

===协议命名空间===

XMPP Register在所注册的协议空间中包含了'http://jabber.org/protocol/chatstates' 。

==XML Schema==

<source lang="xml">
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='http://jabber.org/protocol/chatstates'
    xmlns='http://jabber.org/protocol/chatstates'
    elementFormDefault='qualified'>

  <xs:annotation>
    <xs:documentation>
      The protocol documented by this schema is defined in
      XEP-0085: http://www.xmpp.org/extensions/xep-0085.html
    </xs:documentation>
  </xs:annotation>

  <xs:element name='active' type='empty'/>
  <xs:element name='composing' type='empty'/>
  <xs:element name='gone' type='empty'/>
  <xs:element name='inactive' type='empty'/>
  <xs:element name='paused' type='empty'/>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
</source>

==备注==

# XEP-0022: Message Events <http://www.xmpp.org/extensions/xep-0022.html>.
# These states do not necessarily refer to the state of the client interface and certainly not to the disposition of a particular message. However, the user's involvement with the system, device, chat interface, or input interface can provide important clues regarding the user's involvement with the chat session, which should be used by the client in determining when to generate chat state notifications.
# RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc3921>.
# An implementation may 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.
# XEP-0030: Service Discovery <http://www.xmpp.org/extensions/xep-0030.html>.
# XEP-0115: Entity Capabilities <http://www.xmpp.org/extensions/xep-0115.html>.
# XEP-0155: Stanza Session Negotiation <http://www.xmpp.org/extensions/xep-0155.html>.
# XEP-0045: Multi-User Chat <http://www.xmpp.org/extensions/xep-0045.html>.
# RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc3921>.
# XEP-0025: Jabber HTTP Polling <http://www.xmpp.org/extensions/xep-0025.html>.
# XEP-0124: Bidirectional-streams Over Synchronous HTTP <http://www.xmpp.org/extensions/xep-0124.html>.
# 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 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 <http://www.xmpp.org/registrar/>.

==修订历史==

Version 1.2 (2006-07-12)

Added service discovery use case.

(psa) 

Version 1.1 (2005-10-05)

Clarified suggested triggers to discourage prospective notifications.

(psa) 

Version 1.0 (2005-08-26)

Per a vote of the Jabber Council, advanced status to Draft.

(psa) 

Version 0.14 (2005-07-20)

Clarified terminology; specified suggested state changes; removed section on superseding XEP-0022.

(psa) 

Version 0.13 (2005-07-19)

Further clarified business rules regarding generation of notifications.

(psa) 

Version 0.12 (2005-07-15)

Clarified business rules regarding generation of notifications; added reference to XEP-0155; rewrote introduction; moved previous introductory text to section on superseding XEP-0022.

(psa) 

Version 0.11 (2005-07-05)

Removed <initial/> state.

(psa) 

Version 0.10 (2005-06-28)

Added optional <initial/> state; added business rule on repetition of notifications; added implementation note.

(psa) 

Version 0.9 (2004-10-28)

Made <inactive/> state definition consistent with <paused/> per list discussion; made slight adjustments to wording throughout.

(psa) 

Version 0.8 (2004-10-28)

Further clarified state definitions and adjusted suggested event timing.

(psa) 

Version 0.7 (2004-10-27)

Clarified the meaning of the <gone/> state; adjusted suggested timing for events.

(psa) 

Version 0.6 (2004-02-19)

Added <paused/> state; defined the chat states; clarified the state chart; simplified the business rules.

(psa) 

Version 0.5 (2003-09-18)

Clarified that 'type' must be "chat" or "groupchat" for chat state notification messages.

(psa) 

Version 0.4 (2003-05-22)

Made Thread IDs optional; made <inactive/> and <gone/> states optional if Thread IDs are not used; removed requirement for explicit service discovery in favor of implicit discovery.

(psa) 

Version 0.3 (2003-05-20)

Clarified terminology; added support for groupchat; added several implementation notes.

(psa) 

Version 0.2 (2003-05-19)

General cleanup; added schema.

(psa) 

Version 0.1 (2003-05-19)

Initial version.

(dss/psa) 

结束