RFC6121 - 版本历史

Llj098: /* 名册推送 */

2014-03-17T06:47:30Z

名册推送

Llj098: /* 出席信息原理 */

2014-03-17T03:37:20Z

出席信息原理

Llj098: /* Thread元素 */

2014-03-17T03:04:28Z

Thread元素

Llj098: /* 一对一聊天会话 */

2014-03-17T02:56:24Z

一对一聊天会话

Fengpxu: 修正文字错误

2014-01-20T01:45:53Z

修正文字错误

2013年7月24日 (三) 16:14 Admin

2013-07-24T16:14:37Z

2013年7月23日 (二) 15:56 Admin

2013-07-23T15:56:38Z

Admin: /* 附录F. 致谢 */

2013-07-23T15:56:00Z

附录F. 致谢

Admin: /* 附录F. 致谢 */

2013-07-23T15:54:33Z

附录F. 致谢

Admin: /* 附录E. 和RFC 3921的不同 */

2013-07-23T15:47:58Z

附录E. 和RFC 3921的不同

@@ 第282行： / 第282行： @@
 </source>
-作为[[RFC6121#规范引用|XMPP‑CORE]]定义的IQ节语义的强制要求, 每个接收一个来自服务器的名册推送的资源应该应答一个类型为"result"或"error"的IQ节(无论如何, 大家知道很多现有的客户端不应答名册推送).
+作为[[RFC6121#规范引用|XMPP‑CORE]]定义的IQ节语义的强制要求, 每个接收一个来自服务器的名册推送的资源应该应答一个类型为"result"或"error"的IQ节(然而, 大家知道很多现有的客户端不应答名册推送).
 <source lang="xml">

@@ 第1,350行： / 第1,350行： @@
 ===出席信息原理===
-出席信息的概念参考了一个在网络上通讯的实体的可用性. 在最基本的层面上, 出席信息是一个"on/off"的逻辑变量以标记一个实体可不可以通讯(也用术语"在线"和"离线"). 在XMPP中, 当客户端生成一个不带'type'属性的<presence/>节时就标记了一个实体的可用性, 当它的客户端生成一个'type'属性值为"unavailable"的<presence/>节时表示一个实体失去了可用性.
+出席信息是指在网络上通讯的一个实体的可用性. 在最基本的层面上, 出席信息是一个"on/off"的逻辑变量以标记一个实体可不可以通讯(也用术语"在线"和"离线"). 在XMPP中, 当客户端生成一个不带'type'属性的<presence/>节时就标记了一个实体的可用性, 当它的客户端生成一个'type'属性值为"unavailable"的<presence/>节时表示一个实体失去了可用性.
-XMPP出席信息典型地遵循一个"发布-订阅"或"观察者"模式, 在那里一个实体发送出席信息给它的服务器, 并且它的服务器接着广播那个信息给所有订阅了该实体的出席信息的联系人(在[http://xmpp.org/rfcs/rfc6121.html#IMP-MODEL IMP‑MODEL]的术语中, 一个生成出席信息的实体就是一个"presentity"并且那些接收出席信息的实体们是"subscribers"). 一个客户端通过发送一个不带'to'地址的出席信息节给它的服务器来生成出席信息用于广播给所有已订阅的实体们, 这里的出席信息既没有'type'属性又没有值为"unavailable"的'type'属性. 这种出席信息被称为"广播出席信息". (一个客户端也可以发送"定向出席信息", 即, 一个带'to'地址的出席信息节; 这不太常见但是有时被用于发送出席信息给那些没有订阅该用户的出席信息的实体们; 见[[RFC6121#定向出席信息|4.6.]])
+XMPP出席信息典型地遵循一个"发布-订阅"或"观察者"模式, 这里,一个实体发送出席信息给它的服务器, 它的服务器接着广播那个信息给所有订阅了该实体的出席信息的联系人(在[http://xmpp.org/rfcs/rfc6121.html#IMP-MODEL IMP‑MODEL]的术语中, 一个生成出席信息的实体就是一个"presentity"并且那些接收出席信息的实体们是"subscribers"). 一个客户端通过发送一个不带'to'地址的出席信息节给它的服务器来生成出席信息用于广播给所有已订阅的实体们, 这里的出席信息既没有'type'属性又没有值为"unavailable"的'type'属性. 这种出席信息被称为"广播出席信息". (一个客户端也可以发送"定向出席信息", 即, 一个带'to'地址的出席信息节; 这不太常见但是有时被用于发送出席信息给那些没有订阅该用户的出席信息的实体们; 见[[RFC6121#定向出席信息|4.6.]])
 在一个客户端完成[[RFC6121#规范引用|XMPP‑CORE]]定义的先决条件之后, 它能通过发送初始化出席信息在它的服务器建立一个"出席信息会话", 通过发送unavailable出席信息可以中止这个出席信息会话. 在它的出席信息会话期间, 一个已连接的资源([[RFC6121#规范引用|XMPP‑CORE]]中的术语)被称为一个"可用的资源".
-在XMPP中, 应用集合了消息和出席信息功能, 它的出席信息标记的可用性的缺省通讯类型是消息; 无论如何, 对于XMPP应用来说把消息和出席信息功能集合到一起是必要, 同时它们能提供独立的不带消息的出席信息特性(另外, XMPP服务器们不会为了成功地路由message和IQ节而强制要求关于网络可用性的信息).
+在XMPP中, 应用集合了消息和出席信息功能, 它的出席信息标记的可用性的缺省通讯类型是消息; 然而, 对于XMPP应用来说把消息和出席信息功能集合到一起并不是必要的, 它们能提供独立的不带消息的出席信息特性(另外, XMPP服务器们不会为了成功地路由message和IQ节而强制要求关于网络可用性的信息).
 :提示备注: 在接下来的例子中, 用户是<juliet@example.com>, 她有两个可用的资源("balcony"和"chamber"), 而在她的名册中有三个联系人且订阅状态为"from"或"both": <romeo@example.net>, <mercutio@example.com>, 和<benvolio@example.net>.

@@ 第2,071行： / 第2,071行： @@
 ====Thread元素====
-XMPP <thread/>元素主要用于唯一性地标识一个由类型为'chat'的<message/>节实例化的两个实体之间的交谈线索或"聊天会话". 无论如何, XMPP <thread/>元素也可以被用于唯一性地标识一个由类型为'headline'或'normal'的<message/>节实例化的两个实体之间, 或由类型为'groupchat'的<message/>节实例化的在一个多用户聊天室上下文中的多个实体之间的类似线索. 它也可用于和自然人无关的会话的<message/>节, 类似一个游戏会话或一个插件之间的互动. <thread/>元素不被用于标识个别的消息, 只用于交谈或消息会话.
+XMPP <thread/>元素主要用于唯一性地标识一个由类型为'chat'的<message/>节实例化的两个实体之间的交谈线索或"聊天会话". 然而, XMPP <thread/>元素也可以被用于唯一性地标识一个由类型为'headline'或'normal'的<message/>节实例化的两个实体之间, 或由类型为'groupchat'的<message/>节实例化的在一个多用户聊天室上下文中的多个实体之间的类似线索. 它也可用于和自然人无关的会话的<message/>节, 类似一个游戏会话或一个插件之间的互动. <thread/>元素不被用于标识个别的消息, 只用于交谈或消息会话.
 <thread/>元素是可选的. 因为<thread/>元素标识了一个消息所属的特定交谈线索, 一个消息节不能(MUST NOT)多个<thread/>元素.

@@ 第1,944行： / 第1,944行： @@
 该用户的客户端应该在一个聊天会话中把初始消息的地址指向该联系人的纯JID <contact@domainpart> (而不是基于任何它可能之前从联系人那收到的出席信息通知的 <show/>, <status/>, 或 <priority/> 值来尝试猜测一个适当的全JID <contact@domainpart/resourcepart> ). 直到和除非该用户的客户端从该联系人收到一个应答, 它应该发送任何更多的消息给该联系人的纯JID. 该联系人的客户端应该把它的应答的地址指向该用户的全JID <user@domainpart/resourcepart>,即初始消息中提供的'from'地址. 一旦该用户的客户端从该联系人的全JID收到一个应答, 它应该把它随后的消息指向该联系人的全JID，即在该联系人的应答中提供的'from'地址, 从而"锁定"在那个全JID. 一个客户端应该在接收到一个来自对方节点控制的任何其他资源的<message/>或<presence/>节(或一个来自已锁定的资源的出席信息节)的时候"解除锁定"; 结果是, 它应该在聊天会话的下一个消息中指向对方节点的纯JID(从而"解锁"之前的"锁定")，直到它从对方的全JIDs收到一个消息.
-当双方参加一个一个聊天会话但是没有基于一个出席信息订阅来互相分享出席信息, 他们应该互相发送定向出席信息，这样书官方能很容易地查询对方在该聊天会话期间是否下线. 无论如何, 一个客户端必须提供一个方法让一个用户能全局地禁止或只允许特定的实体进行这类出席信息分享. 更进一步的, 当出于某种原因相信该聊天会话结束了(例如, 如果, 在一段合理的时间之后, 双方没有交换随后的消息),一方应该发送定向unavailable出席信息给另一方 .
+当双方参加一个一个聊天会话但是没有基于一个出席信息订阅来互相分享出席信息, 他们应该互相发送定向出席信息，这样双方能很容易地查询对方在该聊天会话期间是否下线. 然而, 一个客户端必须提供一个方法让一个用户能全局地禁止或只允许特定的实体进行这类出席信息分享. 更进一步的, 当出于某种原因相信该聊天会话结束了(例如, 如果, 在一段合理的时间之后, 双方没有交换随后的消息),一方应该发送定向unavailable出席信息给另一方 .
 聊天会话的例子参见[[RFC6121#示例会话|第7章]].

@@ 第166行： / 第166行： @@
          该用户没有订阅一该联系人的出席信息, 并且联系人也没有订阅该用户的出席信息; 这是缺省值, 所以如果没有subscription属性，那么该状态被理解为"none"
      to:
-         该用户定于了该联系人的出席信息, 但是联系人没有订阅用户的出席信息
+         该用户订阅了该联系人的出席信息, 但是联系人没有订阅用户的出席信息
      from:
          该联系人订阅了该用户的出席信息, 但是该用户没有订阅联系人的出席信息

←上一版本		2013年7月24日 (三) 16:14的版本
第1行：		第1行：
−	"本文的英文原文来自[http://xmpp.org/rfcs/rfc6121.html RFC 6121]	+	'''本文的英文原文来自[http://xmpp.org/rfcs/rfc6121.html RFC 6121]'''

	{\|border="1" cellspacing="0" width="65%"		{\|border="1" cellspacing="0" width="65%"

@@ 第1行： / 第1行： @@
 "本文的英文原文来自[http://xmpp.org/rfcs/rfc6121.html RFC 6121]
@@ 第3,284行： / 第3,280行： @@
    Phone:+1-303-308-3282
    EMail:psaintan@cisco.com

←上一版本		2013年7月23日 (二) 15:56的版本
第3,273行：		第3,273行：

	工作组主席是 Ben Campbell 和 Joe Hildebrand. 责任区域编辑是 Gonzalo Camarillo.		工作组主席是 Ben Campbell 和 Joe Hildebrand. 责任区域编辑是 Gonzalo Camarillo.
		+
		+	==作者的地址==
		+
		+
		+	Peter Saint-Andre
		+	Cisco
		+	1899 Wyknoop Street, Suite 600
		+	Denver, CO 80202
		+	USA
		+	Phone:+1-303-308-3282
		+	EMail:psaintan@cisco.com

←上一版本		2013年7月23日 (二) 15:54的版本
第3,261行：		第3,261行：

	==附录F. 致谢==		==附录F. 致谢==
		+
		+	本文衍生自自RFC 3921，是对它的更新. 没有贡献者们和评论者们的工作，本文是不可能完成的.
		+
		+	从RFC 3921发布以来，数百人提供了实现反馈, 错误报告, 澄清的请求, 和改善建议. 尽管本文的编辑已经努力找出所有这类反馈, 但他独自对任何其余的错误和含糊的地方负责.
		+
		+	一些关于名册版本的文本来自[[RFC6121#参考文献\|XEP‑0237]]，而一些关于消息线索的文本来自[[RFC6121#参考文献\|XEP‑0201]].
		+
		+	特别感谢 Kevin Smith, Matthew Wild, Dave Cridland, Waqas Hussain, Philipp Hancke, Florian Zeitz, Jonas Lindberg, Jehan Pages, Tory Patnoe, 和其他在工作组最后召集期间做评论的人.
		+
		+	也感谢代表安全局进行复审的 Richard Barnes.
		+
		+	工作组主席是 Ben Campbell 和 Joe Hildebrand. 责任区域编辑是 Gonzalo Camarillo.

←上一版本		2013年7月23日 (二) 15:47的版本
第3,242行：		第3,242行：

	==附录E. 和RFC 3921的不同==		==附录E. 和RFC 3921的不同==
		+
		+	在来自实现和应用实践的一致性和延续性以及正式的互操作性测试的基础上, 对[[RFC6121#参考文献\|RFC3921]]做了以下大量修改(还有很多编辑方面的修改).
		+
		+	:* 会话建立的协议被决定是不必要的并且因而之前在RFC 3921的第3章定义的内容被移除. 无论如何, 为了向后兼容，鼓励服务器实现声明对该特性的支持, 即使会话建立是一个"no-op"（非选项）.
		+	:* 为了更加无缝地修复位于不同服务器上的名册之间缺少订阅状态同步的问题, 澄清和修改了和出席信息订阅请求，出席信息探测和出席信息通知相关的错误处理.
		+	:* 为出席信息探测修改了'from'地址，现在它是纯JID, 而不是全JID.
		+	:* 基于实现和部署实践调整和澄清了节递送规则.
		+	:* 显式地定义了一个服务器被允许递送一个类型为"normal"或"chat"的消息节给所有资源，如果它有办法允许所有的资源选择这一行为.
		+	:* 允许一个服务器使用它自己的机制来确定"最可用的"资源，用来递送消息, 但是提到了来自RFC 3921的机制(基于出席信息优先级)作为可能的机制.
		+	:* 添加了可选的名册信息版本以在多个会话之间名册没有变更(或只变更了很少)的时候节省带宽; 有关的协议交互开始是在[[RFC6121#参考文献\|XEP‑0237]]中描述的.
		+	:* 添加了可选的对预批准出席信息订阅的服务器支持，通过类型为"subscribed"的出席信息节, 包括一个新的'approved'属性，该属性能被设为"true" (用于一个预批准订阅) 或 "false" (缺省值).
		+	:* 给<thread/>元素添加了可选的'parent'属性.
		+	:* 把关于通讯限制的协议(定义于RFC 3921的第10章)移回到[[RFC6121#参考文献\|XEP‑0016]],那里是它最开始采用的地方.
		+	:* 建议在对探测的应答中返回出席信息不可用(离线).
		+	:* 澄清发送给全JIDs的出席信息探测的处理.
		+	:* 显式地定义了出席信息<priority/>元素的缺省值为零.
		+	:* 移除了对"_im"和"_pres"的SRV记录的支持的建议.
		+
	==附录F. 致谢==		==附录F. 致谢==