RFC3921 - 版本历史

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

2013-07-24T16:13:35Z

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

2013-07-24T16:11:25Z

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

2013-07-24T16:05:30Z

2013年7月24日 (三) 15:49 Admin

2013-07-24T15:49:47Z

2013年7月23日 (二) 16:01 Admin

2013-07-23T16:01:39Z

2011年12月12日 (一) 18:03 Chruse arroyo

2011-12-12T18:03:25Z

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

2011-06-02T08:46:30Z

2011年5月18日 (三) 12:12 Snowqiang

2011-05-18T12:12:23Z

2011年5月18日 (三) 12:09 Snowqiang

2011-05-18T12:09:33Z

Fantasysoft: /* 会话的建立 */

2010-06-04T04:03:38Z

会话的建立

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

@@ 第1行： / 第1行： @@
-[[Category:XMPP相关RFC]]
+[[Category:已废弃]]
-[[Category:XMPP核心RFC]]
-[[Category:已翻译]]
 本文的英文原文来自[http://tools.ietf.org/html/rfc3921 RFC 3921]
 {|
-!被替代标准: [[RFC6121|6121]] !!建议标准
+|'''被替代标准: [[RFC6121|6121]]''' || '''建议标准'''
 |-
 |网络工作组      || Saint-Andre, Ed.

@@ 第3行： / 第3行： @@
 [[Category:已翻译]]
-本文的英文原文来自[http://www.ietf.org/rfc/rfc3921.txt RFC 3921]
+本文的英文原文来自[http://tools.ietf.org/html/rfc3921 RFC 3921]
 {|
 |网络工作组      || Saint-Andre, Ed.
 |-

@@ 第1行： / 第1行： @@
-[[Category:已废弃]]
+[[Category:XMPP相关RFC]]
 本文的英文原文来自[http://www.ietf.org/rfc/rfc3921.txt RFC 3921]
@@ 第3,503行： / 第3,505行： @@
 :目前为RFC编辑活动提供资金的Internet Society.

@@ 第1行： / 第1行： @@
-[[Category:XMPP相关RFC]]
+[[Category:已废弃]]
-[[Category:XMPP核心RFC]]
-[[Category:已翻译]]
 本文的英文原文来自[http://www.ietf.org/rfc/rfc3921.txt RFC 3921]

←上一版本		2011年12月12日 (一) 18:03的版本
第3,505行：		第3,505行：

	:目前为RFC编辑活动提供资金的Internet Society.		:目前为RFC编辑活动提供资金的Internet Society.
		+	[http://essaywritingservices.org/prices.php write my essay]

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

@@ 第1,177行： / 第1,177行： @@
 :6. 收到"subscribed"类型的出席信息节之后, 联系人应该(SHOULD)承认收到订阅请求通知,要么发送一个"subscribe"的出席信息节给用户证实它,要么发送一个"unsubscribe"类型的出席信息节给用户否认它; 这一步骤不影响订阅状态(细节见 订阅状态Subscription States(第九章)), 但是让联系人的服务器知道它必须(MUST)不再发送订阅状态变更通知给联系人(见第九章第四节).
-:用户和联系人现在有了对双方的出席信息的一个相互订阅 \-\- 换言之, 这个订阅类型为 "both".
+:用户和联系人现在有了对双方的出席信息的一个相互订阅 -- 换言之, 这个订阅类型为 "both".
 ====替代流程: 用户拒绝订阅请求====
@@ 第1,662行： / 第1,662行： @@
 |"From" || 是 || "None"
 |-
-|"From \+ Pending Out" || 是 || "None \+ Pending Out"
+|"From + Pending Out" || 是 || "None + Pending Out"
 |-
 |"Both" || 是 || "To"
@@ 第1,712行： / 第1,712行： @@
 |"None + Pending In" || 是 * || "None"
 |-
-|"None + Pending Out/In" || 是 * || "None \+ Pending Out"
+|"None + Pending Out/In" || 是 * || "None + Pending Out"
 |-
 |"To" || 否 || 状态不变
@@ 第1,720行： / 第1,720行： @@
 |"From" || 是 * || "None"
 |-
-|"From + Pending Out" || 是 * || "None \+ Pending Out
+|"From + Pending Out" || 是 * || "None + Pending Out
 |-
 |"Both" || 是 * || "To"
@@ 第1,740行： / 第1,740行： @@
 |"None + Pending In" || 否 || 状态不变
 |-
-|"None + Pending Out/In" || 是 || "To \+ Pending In"
+|"None + Pending Out/In" || 是 || "To + Pending In"
 |-
 |"To" || 否 || 状态不变
@@ 第1,766行： / 第1,766行： @@
 |"None + Pending In" || 否 || 状态不变
 |-
-|"None + Pending Out/In" || 是 || "None \+ Pending In"
+|"None + Pending Out/In" || 是 || "None + Pending In"
 |-
 |"To" || 是 || "None"
 |-
-|"To + Pending In" || 是 || "None \+ Pending In"
+|"To + Pending In" || 是 || "None + Pending In"
 |-
 |"From" || 否 || 状态不变
@@ 第1,871行： / 第1,871行： @@
 ::<item/>元素可以(MAY)包含一个或更多子元素,使得一个实体可以指明更多的细微控制包括屏蔽哪些种类的节(换言之, 不只是简单地屏蔽所有节). 允许的子元素包括:
-:* <message/> \-\- 屏蔽引入消息节
+:* <message/> -- 屏蔽引入消息节
-:* <iq/> \-\- 屏蔽引入 IQ 节
+:* <iq/> -- 屏蔽引入 IQ 节
-:* <presence-in/> \-\- 屏蔽引入出席信息通知
+:* <presence-in/> -- 屏蔽引入出席信息通知
-:* <presence-out/> \-\- 屏蔽外出出席信息通知
+:* <presence-out/> -- 屏蔽外出出席信息通知
 :在"jabber:iq:privacy'名字空间之内, 一个"set"类型的IQ节的<query/>子元素不能(MUST NOT)包含超过一个子元素(换言之, 这个节必须(MUST)只包含一个<active/>元素, 一个<default/>元素, 或一个<list/>元素); 如果一个发送中的实体违反了这个规则, 接收中的实体必须(MUST)返回一个 return a <bad-request/>节错误.

@@ 第52行： / 第52行： @@
 :本文继承了 [XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]定义的术语.
-:大写关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",  "SHOULD NOT", "RECOMMENDED",  "MAY", 和 "OPTIONAL" 在本文中的含义定义在 BCP 14, RFC 2119 \[TERMS\].
+:大写关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",  "SHOULD NOT", "RECOMMENDED",  "MAY", 和 "OPTIONAL" 在本文中的含义定义在 BCP 14, RFC 2119 [TERMS].
 ==XML 节的语法==
@@ 第70行： / 第70行： @@
 :*error -- 发生了一个和上次发送者发送的消息有关的错误(关于节错误语法的详细信息, 参考      [XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]). 一个兼容客户端应该(SHOULD)在一个适当的界面展示它以通知发送者这个错误的种类.
-:*groupchat -- 消息是在一个多用户聊天环境的语境下发送的(类似\[IRC\]). 一个兼容客户端应该(SHOULD)在允许多对多聊天的界面显示这个消息,包括, 包括这个聊天室的名册和适当的会话历史. 基于XMPP的群聊协议的完整定义超出了本文的范围.
+:*groupchat -- 消息是在一个多用户聊天环境的语境下发送的(类似[IRC]). 一个兼容客户端应该(SHOULD)在允许多对多聊天的界面显示这个消息,包括, 包括这个聊天室的名册和适当的会话历史. 基于XMPP的群聊协议的完整定义超出了本文的范围.
 :*headline -- 一个消息可能是由一个递送或广播内容的自动化服务生成的(新闻, 体育, 市场信息, RSS feeds, 等等.).  这个消息是不需要回复的, 一个兼容客户端应该(SHOULD) 在一个适当的和单独消息,聊天会话,或群聊会话不同的界面显示这个消息(例如, 不给接收者提供回复能力).
@@ 第92行： / 第92行： @@
 =====主题=====
-:<subject/> 元素包含了人类可读的 XML 字符数据指明这个消息的主题. <subject/>元素不能(MUST NOT)拥有任何属性, 除了'xml:lang'属性. <subject/> 元素可以(MAY)包含多个实例用于为同一主题提供备用版本, 但是仅在每个实例的拥有的'xml:lang'属性的值互不相同的时候才可以. <subject/> 元素不能(MUST NOT)包含混合的内容(定义在 \[XML\]第三章第二节第二小节).
+:<subject/> 元素包含了人类可读的 XML 字符数据指明这个消息的主题. <subject/>元素不能(MUST NOT)拥有任何属性, 除了'xml:lang'属性. <subject/> 元素可以(MAY)包含多个实例用于为同一主题提供备用版本, 但是仅在每个实例的拥有的'xml:lang'属性的值互不相同的时候才可以. <subject/> 元素不能(MUST NOT)包含混合的内容(定义在 [XML]第三章第二节第二小节).
 =====主体=====
-:<body/> 元素包含人类可读的XML字符数据表达消息的文本内容; 这个子元素通常会有但是是可选的(OPTIONAL). <body/>元素不能(MUST NOT)拥有任何属性, 除非是'xml:lang'属性. <body/> 元素可以(MAY)包含多个实例用于为同一主体提供备用版本, 但是仅在每个实例的拥有的'xml:lang'属性的值互不相同的时候才可以. <body/>元素不能(MUST NOT)包含混合的内容(定义在 \[XML\]第三章第二节第二小节).
+:<body/> 元素包含人类可读的XML字符数据表达消息的文本内容; 这个子元素通常会有但是是可选的(OPTIONAL). <body/>元素不能(MUST NOT)拥有任何属性, 除非是'xml:lang'属性. <body/> 元素可以(MAY)包含多个实例用于为同一主体提供备用版本, 但是仅在每个实例的拥有的'xml:lang'属性的值互不相同的时候才可以. <body/>元素不能(MUST NOT)包含混合的内容(定义在 [XML]第三章第二节第二小节).
 =====线索=====
@@ 第278行： / 第278行： @@
 :建立一个会话之后, 客户端应该(SHOULD)按以下描述来发送初始化出席信息并请求它的名册, 尽管这些动作是可选的(OPTIONAL).
-:注意: 在允许建立即时消息和出席信息会话之前, 一个服务器可能(MAY)需要先提供帐号. 可能的提供帐号的方法包括由服务器管理员新建帐号以及使用'jabber:iq:register'名字空间进行带内帐号注册; 后一个方法超出了本文的范围, 但是记录在\[JEP-0077\]（译者注：这个协议已改名为 XEP-0077）, 由 Jabber Software Foundation \[JSF\]发行（译者注：这个组织也已改名为XSF）.
+:注意: 在允许建立即时消息和出席信息会话之前, 一个服务器可能(MAY)需要先提供帐号. 可能的提供帐号的方法包括由服务器管理员新建帐号以及使用'jabber:iq:register'名字空间进行带内帐号注册; 后一个方法超出了本文的范围, 但是记录在[JEP-0077]（译者注：这个协议已改名为 XEP-0077）, 由 Jabber Software Foundation [JSF]发行（译者注：这个组织也已改名为XSF）.
 ==交换消息==
@@ 第380行： / 第380行： @@
 ==交换出席信息==
-:交换出席信息通过使用出席信息节直接和XMPP相关. 无论如何, 我们看到在这里和消息处理形成一个对比:尽管一个客户端可以(MAY)通过包含一个'to'地址直接给另一个实体发送出席信息, 通常出席信息通知(例如,不包含'type'的或类型为"unavailable"的并且没有'to'地址的出席信息节) 被客户端发送给它的服务器然后由服务器广播给任何订阅了发送实体的出席信息的实体(在 RFC 2778 \[IMP-MODEL\]术语中, 这些实体称为订阅者). 这个广播模式不适用于和订阅相关的节或类型为"error"的出席信息, 而仅适用于以上定义的出席信息通知.  (注意: 虽然出席信息可以(MAY)由一个自动化服务代替用户提供, 通常它还是由用户的客户端提供.)
+:交换出席信息通过使用出席信息节直接和XMPP相关. 无论如何, 我们看到在这里和消息处理形成一个对比:尽管一个客户端可以(MAY)通过包含一个'to'地址直接给另一个实体发送出席信息, 通常出席信息通知(例如,不包含'type'的或类型为"unavailable"的并且没有'to'地址的出席信息节) 被客户端发送给它的服务器然后由服务器广播给任何订阅了发送实体的出席信息的实体(在 RFC 2778 [IMP-MODEL]术语中, 这些实体称为订阅者). 这个广播模式不适用于和订阅相关的节或类型为"error"的出席信息, 而仅适用于以上定义的出席信息通知.  (注意: 虽然出席信息可以(MAY)由一个自动化服务代替用户提供, 通常它还是由用户的客户端提供.)
 :关于出席信息节的语法以及它们的已定义的属性和子元素的信息, 参考[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920].
@@ 第1,803行： / 第1,803行： @@
 ==屏蔽通信==
-:大多数即时消息系统已发现有必要实现一些方法来为用户屏蔽来自某些特定的其他用户的通信(这在\[IMP-REQS\]的第五章第一节第五小节, 第五章第一节第十五小节,第五章第三节第二小节, 和第五章第四节第十小节中也有要求). 在XMPP中这是由管理某人的隐私列表来实现的(使用'jabber:iq:privacy'名字空间).
+:大多数即时消息系统已发现有必要实现一些方法来为用户屏蔽来自某些特定的其他用户的通信(这在[IMP-REQS]的第五章第一节第五小节, 第五章第一节第十五小节,第五章第三节第二小节, 和第五章第四节第十小节中也有要求). 在XMPP中这是由管理某人的隐私列表来实现的(使用'jabber:iq:privacy'名字空间).
 :服务器端的隐私列表使得以下用例能够完成:
@@ 第2,741行： / 第2,741行： @@
 :如果出站节的'to'属性的地址的域标识符部分的主机名不和服务器自身的一个主机名吻合, 服务器必须(MUST)尝试路由这个节到外部域. 推荐的动作顺序定义如下:
-:# 首先尝试用一个"xmpp-server"服务和"tcp"协议的\[SRV\]服务解析这个外部的主机名,结果得到的资源记录格式如"_xmpp-server._tcp.example.com.", 定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920].
+:# 首先尝试用一个"xmpp-server"服务和"tcp"协议的[SRV]服务解析这个外部的主机名,结果得到的资源记录格式如"_xmpp-server._tcp.example.com.", 定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920].
-:# 如果"xmpp-server"地址记录解析失败, 尝试解析"_im"或"_pres"\[SRV\]服务(定义在\[IMP-SRV\]), 使用"_im"服务用语<message/>节,使用"_pres"服务用语<presence/>节(如何处理<iq/>节取决于具体实现). 这样得到的结果是一个或多个格式为"_im.<proto>.example.com."或     "_pres.<proto>.example.com."的记录, 这里"<proto>"是一个注册在 即时消息SRV协议标签注册表Instant Messaging SRV Protocol Label registry中的一个标签,或者是 出席信息SRV协议标签注册表Presence SRV Protocol Label registry中的标签: 要么是"_xmpp",用于XMPP-aware的域,要么是一些 IANA注册的标签IANA-registered label (例如,"_simple") 用于 non-XMPP-aware 的域.
+:# 如果"xmpp-server"地址记录解析失败, 尝试解析"_im"或"_pres"[SRV]服务(定义在[IMP-SRV]), 使用"_im"服务用语<message/>节,使用"_pres"服务用语<presence/>节(如何处理<iq/>节取决于具体实现). 这样得到的结果是一个或多个格式为"_im.<proto>.example.com."或     "_pres.<proto>.example.com."的记录, 这里"<proto>"是一个注册在 即时消息SRV协议标签注册表Instant Messaging SRV Protocol Label registry中的一个标签,或者是 出席信息SRV协议标签注册表Presence SRV Protocol Label registry中的标签: 要么是"_xmpp",用于XMPP-aware的域,要么是一些 IANA注册的标签IANA-registered label (例如,"_simple") 用于 non-XMPP-aware 的域.
 :# 如果这两种SRV地址记录解析都失败了, 尝试执行一个通用的 IPv4/IPv6 地址记录解析来决定IP地址,使用"xmpp-server"端口号5269(已在IANA注册, 定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]).
@@ 第2,765行： / 第2,765行： @@
 :* 所有本文定义的客户端相关的即时消息语法和语义, 包括出席信息订阅, 名册管理, 和隐私列表
-:* 端到端的对象加密(定义在 XMPP中的端到端对象加密End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP) \[XMPP-E2E\])
+:* 端到端的对象加密(定义在 XMPP中的端到端对象加密End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP) [XMPP-E2E])
-:一个客户端也必须(MUST)处理编码为"im:" URIs的地址(定义在\[CPIM\]), 并且可以(MAY)移除"im:"scheme并把地址解析委托给服务器(定义在 出站节Outbound Stanzas(第十一章第二节).
+:一个客户端也必须(MUST)处理编码为"im:" URIs的地址(定义在[CPIM]), 并且可以(MAY)移除"im:"scheme并把地址解析委托给服务器(定义在 出站节Outbound Stanzas(第十一章第二节).
 ==国际化事项==
@@ 第2,793行： / 第2,793行： @@
 ===会话数据的XML名字空间名===
-:以下为XMPP中会话相关的数据定义了一个 URN 子名字空间. (这个名字空间名的格式遵循 IETF XML Registry \[XML-REG\].)
+:以下为XMPP中会话相关的数据定义了一个 URN 子名字空间. (这个名字空间名的格式遵循 IETF XML Registry [XML-REG].)
 ::URI: urn:ietf:params:xml:ns:xmpp-session
@@ 第2,817行： / 第2,817行： @@
 ===出席信息SRV协议标签注册===
-:确定即时消息和出席信息地址\[IMP-SRV\],为那些能够提供遵守"_pres"SRV服务标签的服务定义了一个出席信息SRV协议标签注册项. 因为XMPP是其中一个协议, IANA在适当的注册项中注册了"_xmpp"协议标签,如下:
+:确定即时消息和出席信息地址[IMP-SRV],为那些能够提供遵守"_pres"SRV服务标签的服务定义了一个出席信息SRV协议标签注册项. 因为XMPP是其中一个协议, IANA在适当的注册项中注册了"_xmpp"协议标签,如下:
 ::Protocol label: _xmpp
@@ 第3,465行： / 第3,465行： @@
 ===C.1  Session Establishment===
-:The client-to-server authentication protocol developed in the Jabber community assumed that every client is an IM client and therefore initiated an IM session upon successful authentication and resource binding, which are performed simultaneously (documentation of this protocol is contained in \[JEP-0078\], published by the Jabber Software Foundation \[JSF\]).  XMPP maintains a stricter separation between core functionality and IM functionality; therefore, an IM session is not created until the client specifically requests one using the protocol defined under Session Establishment (Section 3).
+:The client-to-server authentication protocol developed in the Jabber community assumed that every client is an IM client and therefore initiated an IM session upon successful authentication and resource binding, which are performed simultaneously (documentation of this protocol is contained in [JEP-0078], published by the Jabber Software Foundation [JSF]).  XMPP maintains a stricter separation between core functionality and IM functionality; therefore, an IM session is not created until the client specifically requests one using the protocol defined under Session Establishment (Section 3).
 ===C.2  Privacy Lists===

@@ 第254行： / 第254行： @@
 </source>
-:如果已经同一名字已经存在一个激活的资源,服务器必须(MUST) (1) 终止这个激活的资源并允许新请求的会话, 或者 (2) 不允许新申请的会话并继续激活的资源. 服务器做哪一步取决于具体的实现, 尽管建议的(RECOMMENDED)实现 情景 #1. 在 情景 #1, 服务器应该(SHOULD)发送一个<conflict/>流错误给激活的资源, 终止用于这个激活的资源的XML流和相关的TCP连接, 并返回一个类型为"result" 的IQ节(表示成功)给新申请的会话. 在 情景 #2, 服务器应该(SHOULD)发送一个<conflict/>节错误给新申请的会话但是继续那个连接的XML流使得新申请的会话在发送另一个会话建立申请之前有机会协商出一个不冲突的资源ID.
+:如果同一名字已经存在一个激活的资源,服务器必须(MUST) (1) 终止这个激活的资源并允许新请求的会话, 或者 (2) 不允许新申请的会话并继续激活的资源. 服务器做哪一步取决于具体的实现, 尽管建议的(RECOMMENDED)实现 情景 #1. 在 情景 #1, 服务器应该(SHOULD)发送一个<conflict/>流错误给激活的资源, 终止用于这个激活的资源的XML流和相关的TCP连接, 并返回一个类型为"result" 的IQ节(表示成功)给新申请的会话. 在 情景 #2, 服务器应该(SHOULD)发送一个<conflict/>节错误给新申请的会话但是继续那个连接的XML流使得新申请的会话在发送另一个会话建立申请之前有机会协商出一个不冲突的资源ID.
 :步骤 2 (替代): 服务器通知现有的激活的资源 资源冲突(情景 #1):