RFC6120 - 版本历史

2016年6月14日 (二) 11:37 Xiangmingliu

2016-06-14T11:37:54Z

Zyhserry: /* 内容命名空间 */

2013-12-13T08:24:43Z

内容命名空间

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

2013-07-23T15:48:41Z

附录E. 致谢

Admin: /* 附录D. 和RFC 3920的不同 */

2013-07-23T09:25:45Z

附录D. 和RFC 3920的不同

Admin: /* 附录A. XML Schemas */

2013-07-23T09:25:03Z

附录A. XML Schemas

Admin: /* 附录B. 联系地址 */

2013-07-23T09:21:48Z

附录B. 联系地址

Admin: /* 附录C. 帐户设置 */

2013-07-23T09:21:32Z

附录C. 帐户设置

Admin: /* IANA事项 */

2013-02-05T07:41:40Z

IANA事项

Admin: /* 术语 */

2012-12-23T09:00:10Z

术语

Admin: /* 术语 */

2012-12-23T08:42:14Z

术语

@@ 第18行： / 第18行： @@
 '''摘要'''
-:可扩展的消息和出席信息协议(XMPP)是一个XML应用，让任何两个或多个网络实体之间进行结构化和可扩展的准实时信息交流. 本文定义了XMPP的核心协议方法: XML流的配置和解除, 通道加密, 验证, 错误处理, 以及消息通讯基础, 网络可用性 ("presence"), 和 请求-应答 交互. 本文取代了 RFC 3920.
+:可扩展的消息和出席信息协议(XMPP)是一个XML应用，它让任意两个或多个网络实体可以进行结构化和可扩展的准实时信息交流. 本文定义了XMPP的核心方法: XML流的配置和拆除, 通道加密, 验证, 错误处理, 以及基本的消息通讯, 网络可用性 ("presence"), 和 请求-应答 交互模式. 本文取代了 RFC 3920.
 '''本文的状态'''
@@ 第47行： / 第47行： @@
 ===功能汇总===
-这个不规范的章节提供了一个方便开发者的XMPP功能汇总; 接下来的其他章节则是XMPP的规范定义.
+这个非正规的章节提供了一个方便开发者的XMPP功能汇总; 接下来的其他章节则是XMPP的规范定义.
 XMPP的目标是允许两个(或多个)实体通过网络来交换相关的小件结构化数据(所谓"XML节"). XMPP典型地使用分布式的 客户端-服务器 体系结构来实现, 这里客户端需要连接到一个服务器以获得对网络的访问，从而被允许和其他实体(可能在其他服务器上)交换XML节. 一个客户端连接到一个服务器，交换XML节，以及结束连接，这样的流程如下:

@@ 第746行： / 第746行： @@
 ====内容命名空间====
-实体可以声明一个"内容命名空间" 作为缺省的命名空间用于在流上发送的数据 (也就是那些不属于由流命名空间限定的元素的数据). 如果这样做, (1) 内容命名空间必须不同于流命名空间, 并且 (2) 内容命名空间对于发起流和应答流必须是相同的，使得两个流的限定是一致的. 内容命名空间应用所有从流上发送的一级子元素,出非被显式地由另一个命名空间来限定 (即, 内容命名空间是缺省命名空间).
+实体可以声明一个"内容命名空间" 作为缺省的命名空间用于在流上发送的数据 (也就是那些不属于由流命名空间限定的元素的数据). 如果这样做, (1) 内容命名空间必须不同于流命名空间, 并且 (2) 内容命名空间对于发起流和应答流必须是相同的，使得两个流的限定是一致的. 内容命名空间应用所有从流上发送的一级子元素,除非被显式地由另一个命名空间来限定 (即, 内容命名空间是缺省命名空间).
 另外 (也就是说, 不定义内容命名空间作为缺省命名空间), 实体可以显式地为流的每个一级子元素限定命名空间, 使用所谓 "自由前缀规范". 这两种方式在下面的例子中展示.

@@ 第6,246行： / 第6,246行： @@
 :* 从本文中移除服务器回拨协议到由XMPP标准基金会维护的一个独立的协议.
-==附录E.  致谢==
+==附录E. 致谢==
 本文衍生自自RFC 3920，是对它的更新. 没有贡献者们和评论者们的工作，本文是不可能完成的.

@@ 第6,215行： / 第6,215行： @@
 帐户设置超出了本文的范围. 对于帐户设置可能的方法包括由一个服务器管理员创建帐户和使用[[XEP-0077]]所述的'jabber:iq:register'命名空间进行带内帐户注册. 一个XMPP服务器实现或管理功能必须确保在帐户设置期间被分配的任何JID(包括 本地部分, 域部分, 资源部分, 和分隔符)符合[[RFC6120#规范引用|XMPP‑ADDR]]定义的XMPP地址的规范格式.
-==附录D.  和RFC 3920的不同==
+==附录D. 和RFC 3920的不同==
 基于从实现和部署经验衍生的共识以及正式的互操作性测试, 以下是对 RFC 3920的实质性修改(除了许多编辑性质的修改).

@@ 第5,330行： / 第5,330行： @@
 [XMPP-URI] 	Saint-Andre, P., “Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP),” RFC 5122, February 2008 (TXT).
-==附录A.  XML Schemas==
+==附录A. XML Schemas==
 以下schemas正式定义了本文用到的各命名空间, 符合[[RFC6120#参考文献|XML‑SCHEMA]]. 因为XML流和节的验证是可选的, 这些schemas不是规范性的并且只被提供为描述的目的.
-===A.1.  Stream命名空间===
+===A.1. Stream命名空间===
 <source lang="xml">
@@ 第5,422行： / 第5,422行： @@
 </source>
-===A.2.  Stream Error命名空间===
+===A.2. Stream Error命名空间===
 <source lang="xml">
@@ 第5,511行： / 第5,511行： @@
 </source>
-===A.3.  STARTTLS命名空间===
+===A.3. STARTTLS命名空间===
 <source lang="xml">
@@ 第5,545行： / 第5,545行： @@
 </source>
-===A.4.  SASL命名空间===
+===A.4. SASL命名空间===
 <source lang="xml">
@@ 第5,633行： / 第5,633行： @@
 </source>
-===A.5.  Client命名空间===
+===A.5. Client命名空间===
 <source lang="xml">
@@ 第5,853行： / 第5,853行： @@
 </source>
-===A.6.  Server命名空间===
+===A.6. Server命名空间===
 <source lang="xml">
@@ 第6,086行： / 第6,086行： @@
 </source>
-===A.7.  Resource Binding命名空间===
+===A.7. Resource Binding命名空间===
 <source lang="xml">
@@ 第6,125行： / 第6,125行： @@
 </source>
-===A.8.  Stanza Error命名空间===
+===A.8. Stanza Error命名空间===
 <source lang="xml">

@@ 第6,207行： / 第6,207行： @@
 </source>
-==附录B.  联系地址==
+==附录B. 联系地址==
 和[[RFC6120#参考文献|MAILBOXES]]一致, 提供XMPP服务的组织被鼓励提供一个"XMPP"的互联网邮箱用于查询那个服务相关的事情, 这里最终的mailto URI的host部分是组织的域, 而不是XMPP服务本身的域(例如, XMPP服务可以在im.example.com提供但是互联网邮箱是<xmpp@example.com>).

@@ 第6,211行： / 第6,211行： @@
 和[[RFC6120#参考文献|MAILBOXES]]一致, 提供XMPP服务的组织被鼓励提供一个"XMPP"的互联网邮箱用于查询那个服务相关的事情, 这里最终的mailto URI的host部分是组织的域, 而不是XMPP服务本身的域(例如, XMPP服务可以在im.example.com提供但是互联网邮箱是<xmpp@example.com>).
-==附录C.  帐户设置==
+==附录C. 帐户设置==
 帐户设置超出了本文的范围. 对于帐户设置可能的方法包括由一个服务器管理员创建帐户和使用[[XEP-0077]]所述的'jabber:iq:register'命名空间进行带内帐户注册. 一个XMPP服务器实现或管理功能必须确保在帐户设置期间被分配的任何JID(包括 本地部分, 域部分, 资源部分, 和分隔符)符合[[RFC6120#规范引用|XMPP‑ADDR]]定义的XMPP地址的规范格式.

@@ 第4,432行： / 第4,432行： @@
 ==IANA事项==
-以下小节更新了[[RFC3920]]提供的注册项. 本章是根据[RFC6120#参考文献|IANA‑GUIDE]]来解释的.
+以下小节更新了[[RFC3920]]提供的注册项. 本章是根据[[RFC6120#参考文献|IANA‑GUIDE]]来解释的.
 ===TLS数据的XML命名空间名===

@@ 第111行： / 第111行： @@
 当术语 "ignore" (忽略)用于客户端处理收到的数据时, 短语 "without acting upon it" (不做任何处理)明确的包括不展示任何数据给使用者(人).
-接下来的 "XML符号" 被 [[RFC6120#IRI|IRI]] 用于展示无法用仅用ASCII码呈现的字符, 本文的一些例子使用了类似 "&#x...." 的格式来表现 [[RFC6120#UNICODE|UNICODE]] 字符串 (例如, 字符串 "&#x0159;" 表示Unicode字符 LATIN SMALL LETTER R WITH CARON); 这种形式是绝对不会在XMPP系统将通过网络发送的.
+接下来的 "XML符号" 被 [[RFC6120#参考文献|IRI]] 用于展示无法用仅用ASCII码呈现的字符, 本文的一些例子使用了类似 "&#x...." 的格式来表现 [[RFC6120#参考文献|UNICODE]] 字符串 (例如, 字符串 "&#x0159;" 表示Unicode字符 LATIN SMALL LETTER R WITH CARON); 这个格式在XMPP系统中绝对不会在网络上被发送.
 和 [[RFC6120#URI|URI]] 展现统一资源定位符的规则一样, XMPP地址文本也是用 '<' 和 '>' 括起来的(尽管基本上它们不属于 URIs).

@@ 第78行： / 第78行： @@
 ===术语===
-本文中的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和 "OPTIONAL" 的解释参见RFC 2119 [[RFC6120#关键字|关键字]] .
+本文中的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和 "OPTIONAL" 的解释参见RFC 2119 [[RFC6120#规范引用|关键字]] .
 特定的安全相关的术语的含义参见 [[RFC6120#安全术语|安全术语]] ; 这些术语包括但不限于, "assurance", "attack", "authentication", "authorization", "certificate", "certification authority", "certification path", "confidentiality", "credential", "downgrade", "encryption", "hash value", "identity", "integrity", "signature", "self-signed certificate", "sign", "spoof", "tamper", "trust", "trust anchor", "validate", and "verify".