RFC3920 - 版本历史

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

2013-07-24T16:13:12Z

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

2013-07-24T16:11:55Z

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

2013-07-24T16:10:56Z

2012年11月26日 (一) 13:35 Admin

2012-11-26T13:35:11Z

2012年11月26日 (一) 13:30 Admin

2012-11-26T13:30:42Z

Admin: /* 绑定到TCP */

2012-07-26T12:22:10Z

绑定到TCP

2012年1月30日 (一) 04:08 Cn.popeye

2012-01-30T04:08:24Z

Admin: /* 流的特性 */

2011-06-02T11:13:05Z

流的特性

2011年6月2日 (四) 08:45 Admin

2011-06-02T08:45:20Z

2011年5月19日 (四) 04:30 Snowqiang

2011-05-19T04:30:15Z

@@ 第1行： / 第1行： @@
 [[Category:已废弃]]
-本文的原文来自[http://tools.ietf.org/html/rfc3920 RFC 3920]
+'''本文的英文原文来自[http://tools.ietf.org/html/rfc3920 RFC 3920]'''
 {|

@@ 第1行： / 第1行： @@
 [[Category:已废弃]]
-原文来自[http://tools.ietf.org/html/rfc3920 RFC 3920]
+本文的原文来自[http://tools.ietf.org/html/rfc3920 RFC 3920]
 {|

@@ 第1行： / 第1行： @@
 [[Category:已废弃]]
-"原文来自[http://tools.ietf.org/html/rfc3920 RFC 3920]"
+原文来自[http://tools.ietf.org/html/rfc3920 RFC 3920]
-Obsoleted by: 6120 PROPOSED STANDARD
-Updated by: 6122 Errata Exist
 {|
-|被[[RFC6120]]取代 || 建议的标准
+|'''被取代标准: [[RFC6120]]''' || '''建议的标准'''
 |-
-|被[http://tools.ietf.org/html/rfc6122 RFC6122]更新 || 存在勘误表
+|'''被更新标准: [[RFC6122]]''' || '''存在勘误表'''
 |-
 |网络工作组 || P. Saint-Andre, Ed.

←上一版本		2012年11月26日 (一) 13:35的版本
第1行：		第1行：
−	~~[[Category:已翻译]]~~
	[[Category:已废弃]]		[[Category:已废弃]]

@@ 第1行： / 第1行： @@
 [[Category:已翻译]]
-"原文来自[http://www.ietf.org/rfc/rfc3920.txt RFC 3920]"
+"原文来自[http://tools.ietf.org/html/rfc3920 RFC 3920]"
 {|
 |网络工作组 || P. Saint-Andre, Ed.
 |-

@@ 第175行： / 第175行： @@
 ===绑定到TCP===
-:虽然有很多非必需的连接使用XML流来绑定[TCP]连接（两个实体可以通过别的机制来互联，比如通过[HTPP]连接轮询），本规范只定义了 XMPP 到 TCP 的绑定。在客户和服务器通信的过程中，服务器必须（MUST）允许客户端共享一个TCP连接来传输XML节，包括从客户端传到服务器和从服务器传到客户端。在服务器之间的通信过程中，服务器必须（MUST）用一个 TCP连接 向对方发送 XML节，另一个 TCP连接（由对方初始化）接收对方的XML节，一共两个 TCP连接。
+:虽然有很多非必需的连接使用XML流来绑定[TCP]连接（两个实体可以通过别的机制来互联，比如通过[HTTP]连接轮询），本规范只定义了 XMPP 到 TCP 的绑定。在客户和服务器通信的过程中，服务器必须（MUST）允许客户端共享一个TCP连接来传输XML节，包括从客户端传到服务器和从服务器传到客户端。在服务器之间的通信过程中，服务器必须（MUST）用一个 TCP连接 向对方发送 XML节，另一个 TCP连接（由对方初始化）接收对方的XML节，一共两个 TCP连接。
 ===流的安全===

@@ 第230行： / 第230行： @@
 ===流的特性===
-:如果初始化的实体在初始化流的头信息中设置'version'属性的信息为"1.0",接收实体必须(MUST)向初始化实体发送一个 <features/> 子元素以声明任何可供协商的流一级的特性(或者其他需要声明的能力).目前,这仅用于声明本文中定义的 TLS的使用(第五章),SASL的使用（第六章）和资源绑定(第七章),以及 [XMPP-IM|XMPP文档列表/XMPP正式RFC标准/RFC3921] 中定义的会话的建立;无论如何,流特性这一功能将来可以用于声明任何可协商的特性.如果一个实体不理解或支持安全特性,它应该(SHOULD)忽略它.如果要在一个非安全相关的特性(比如资源绑定)被提议之前,完成一个或多个安全特性(比如TLS和SASL)的协商,这个非安全相关的特性不应该(SHOULD NOT)在相应的安全特性协商完毕之前被声明.
+:如果初始化的实体在初始化流的头信息中设置'version'属性的信息为"1.0",接收实体必须(MUST)向初始化实体发送一个 <features/> 子元素以声明任何可供协商的流一级的特性(或者其他需要声明的能力).目前,这仅用于声明本文中定义的 TLS的使用(第五章),SASL的使用（第六章）和资源绑定(第七章),以及 [[RFC3921|XMPP-IM]] 中定义的会话的建立;无论如何,流特性这一功能将来可以用于声明任何可协商的特性.如果一个实体不理解或支持安全特性,它应该(SHOULD)忽略它.如果要在一个非安全相关的特性(比如资源绑定)被提议之前,完成一个或多个安全特性(比如TLS和SASL)的协商,这个非安全相关的特性不应该(SHOULD NOT)在相应的安全特性协商完毕之前被声明.
 ===流错误===

←上一版本		2011年6月2日 (四) 08:45的版本
第1行：		第1行：
−	[[Category:~~XMPP正式RFC标准~~]]	+	[[Category:XMPP相关RFC]]
		+	[[Category:XMPP核心RFC]]
	[[Category:已翻译]]		[[Category:已翻译]]

@@ 第1,254行： / 第1,254行： @@
 ====出席信息语义学====
-:<presence/> 元素可以被看作一个基本的广播或“出版-订阅”机制,用于多个实体接收某个已订阅的实体的信息(在这里,是网络可用性信息). 通常,一个发行实体应该（SHOULD）不带'to'属性发送一个出席信息,这时这个实体所连接的服务器应该（SHOULD）广播或多播(multiplex?)那个节给所有订阅的实体.无论如何,一个发行实体也可以(MAY)带'to'属性发送一个出席信息节,这时服务器应该(SHOULD)路由或递送这个节给预定的接收者.见 Server Rules for Handling XML Stanzas (第十章)的XML节相关的通用路由和递送规则,以及[XMPP-IM|XMPP文档列表/XMPP正式RFC标准/RFC3921]中即时消息和出席信息应用中出席信息的特定规则.
+:<presence/> 元素可以被看作一个基本的广播或“出版-订阅”机制,用于多个实体接收某个已订阅的实体的信息(在这里,是网络可用性信息). 通常,一个发行实体应该（SHOULD）不带'to'属性发送一个出席信息,这时这个实体所连接的服务器应该（SHOULD）广播或复用(multiplex)那个节给所有订阅的实体.无论如何,一个发行实体也可以(MAY)带'to'属性发送一个出席信息节,这时服务器应该(SHOULD)路由或递送这个节给预定的接收者.见 Server Rules for Handling XML Stanzas (第十章)的XML节相关的通用路由和递送规则,以及[XMPP-IM|XMPP文档列表/XMPP正式RFC标准/RFC3921]中即时消息和出席信息应用中出席信息的特定规则.
 ====IQ语义学====
@@ 第1,263行： / 第1,263行： @@
 {image:img=iq}
 :为了强制执行这些语义学,要应用以下规则: