RFC6121

来自Jabber/XMPP中文翻译计划
（版本间的差异）
跳转到： 导航, 搜索
(→功能汇总)
(→术语)
第84行： 第84行：
  
 
===术语===
 
===术语===
 +
 +
本文中的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和 "OPTIONAL" 的解释参见RFC 2119 [[RFC6121#规范引用|关键字]] .
 +
 +
本文继承了 [[RFC6120|XMPP‑CORE]] 中定义的术语.
 +
 +
术语 "automated client" 和 "interactive client" 的含义和 [[RFC6121#参考文献|TLS‑CERTS]] 中定义的相同.
 +
 +
为了方便, 本文借用了术语 "user" 来指代一个XMPP帐号的所有者; 无论如何, 帐号所有者不需要是自然人并且可以是机器人, 设备, 或其他自动化的应用.
 +
 +
一些其他的术语, 类似 "interested resource", 在本文的正文中定义.
 +
 +
接下来的"XML Notation"用在[[RFC6121#参考文献|IRI]]中展示无法用纯ASCII文档表达的字符串, 本文的一些例子中使用了格式 "&#x...." 作为一个符号设备来展示 [[RFC6121#参考文献|UNICODE]] 字符串(例如, 字符串 "ř" 代表 Unicode 字符串 LATIN SMALL LETTER R WITH CARON); 这个格式在XMPP系统中绝对不会在网络上被发送.
 +
 +
在例子中, 每一行已经被封装成便于阅读的样子, "[...]" 意味着省略, 并且使用了以下前缀(这些前缀不会在通讯中被发送):
 +
 +
:* C: = 客户端
 +
:* CC: = 联系人的客户端
 +
:* CS: = 联系人的服务器
 +
:* S: = 服务器
 +
:* UC: = 用户的客户端
 +
:* US: = 用户的服务器
 +
 +
读者需要注意这些例子不包括细节, 并且例子里的一些协议流程中, 展示的备用步骤不一定是由前一个步骤发送的确切的数据触发的; 本文或常用参考文档中的协议规范所用到的所有用例里面提供的例子都遵从上述规则. 所有例子都是虚构的并且交换的信息 (例如, 用户名和密码) 不代表任何现存的用户和服务器.
  
 
==管理花名册 Managing the Roster==
 
==管理花名册 Managing the Roster==

2012年12月23日 (日) 09:04的版本


"本文的英文原文来自RFC 6121

互联网工程任务组(IETF) P. Saint-Andre
申请讨论: 6121 Cisco
取代: 3921 2011年3月
类别: 标准跟踪
ISSN: 2070-1721
可扩展的消息和出席信息协议 (XMPP): 即时消息和出席信息

摘要

本文定义提供了遵循RFC2779要求的基本的即时消息(IM)和出席信息功能的可扩展的消息和出席信息协议(XMPP)的核心功能的扩展. 本文取代了 RFC 3921.

本文的状态

这是一个互联网标准跟踪文档.
本文是互联网工程工作组(IETF)的一个成果. 它代表了IETF社区的一致意见. 它已经公开审核并由互联网工程控制组(IESG)批准发布了. 更多关于互联网标准的信息请参见RFC 5741第2章.
关于本文当前状态的信息, 任何错误, 以及如何对它提出反馈，请到 http://www.rfc-editor.org/info/rfc6121 .

版权声明

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

目录

序论

概述

可扩展的消息和出席信息协议(XMPP)是可扩展的标记语言XML的一个应用范畴,它能使两个或更多网络实体之间的结构化并且可扩展的数据进行准实时的交换. 在XMPP‑CORE中定义的XMPP的核心特性提供了各种类型的准实时应用的积木, 通过发送由特定的XML命名空间(参考XML‑NAMES)所限定的应用特有的数据,它们可被叠加在核心之上. 本文定义的XMPP扩展提供一个IMP‑REQS所述的即时消息(IM)和出席信息应用所预期的基本功能.

历史

XMPP的基本语法和语义最开始是由Jabber开源社区开发的, 主要是在1999年. 2002年, 根据 IMP‑REQS ，XMPP工作组被允许基于Jabber协议开发一个适合IETF的即时消息和出席信息技术. 到了2004年10月, 发布了 RFC3920 和 RFC3921 , 意味着那时候XMPP的主要定义完成了.

从2004年开始，互联网社区已经获得了广泛的XMPP实现和布署经验, 包括XMPP标准基金会(XSF)主持下开展的正式的互操作性测试. 本文全面整合了从软件开发者和XMPP服务提供者得到的反馈, 包含了一系列向后兼容的修改，见 附录E . 结果是, 本文反映了互联网社区对于XMPP1.0的即时消息和出席信息特性的初步共识, 因此废止了RFC 3921.

需求

传统上, IM应用组合了以下因素:

  1. 关注的中心点是某人的联系人的列表或 "好友们" (在XMPP中这个列表被称为一个 "roster"(名册)).
  2. 使用这类应用的目标是和特定的联系人准实时地交换相关的短文本消息 -- 在章节5.1描述的一对一形式的"聊天会话"中, 快速连续的相关消息的数量经常是很大的.
  3. 交换消息的催化剂是 "presence" -- 即, 关于特定联系人们的网络可用性的信息(这样就知道谁在线并且有空进行一对一的聊天会话).
  4. 出席信息仅提供给通过一个被称为"出席信息订阅"的明确协议被授权的联系人.

所以在高层上本文假定用户能完成下列用例:

  • 在某人的联系人列表中管理条目
  • 和某人的联系人们交换消息
  • 和某人的联系人们交换出席信息
  • 管理对某人的联系人们发出和接受出席信息的订阅

这些功能性领域的详细定义被包含在 RFC 2779 IMP‑REQS 中, 关于深度需求感兴趣的读者可以参考那个文档. 尽管 XMPP IM 和这里定义的出席信息扩展满足了 RFC 2779 的需求, 它们不是特意为那个协议设计的, 因为在 RFC 2779 出现之前，Jabber开源社区就通过一个开放的开发流程进化出了基本协议. 尽管在XMP标准基金会的XEP系列中发表了一些其他功能领域的XMPP协议扩展(例如, XEP-0045定义的多用户文本聊天), 这类扩展未在本文中定义，因为它们未被 RFC 2779 授权.

实现备注: RFC 2779 规定出席信息服务必须独立于IM服务，反之亦然; 即, 必须有可能使用本协议提供一个出席信息服务, 一个消息服务, 或同时提供两者. 尽管本文的文本假定实现和部署会希望提供统一的IM和出席信息服务, 对于一个XMPP服务来说，并不强制同时提供一个出席信息服务和一个消息服务, 并且协议使得为出席信息和为消息提供独立和特别的服务成为可能. (例如, 如果一个客户端尝试发送一个<message/>节, 一个只有出席信息的服务可能返回一个<service-unavailable/>节错误.)

功能汇总

这个非规范性的章节提供一个对开发者友好的, 基于XMPP的IM和出席信息特性的功能汇总; 参考接下来的的章节来察看这些特性的规范性的定义.

XMPP‑CORE 定义了一个XMPP客户端如何连接到一个XMPP服务器. 特别是, 它定义了客户端在一个XMPP网络中被允许发送XML节(XMPP中的基本含意单位)给其他实体之前需要满足的前提条件. 这些前提条件包括，XML流的协商，XML流头的交换, 可选的通过传输层安全TLS的通道加密, 通过简单验证和安全层SASL强制验证, 和把资源绑定到客户端所在的流上. 关于这些前提条件的细节，读者可以参考 XMPP‑CORE, XMPP‑CORE 的知识假定已经在此.

互操作性备注: RFC3921 定义了一个额外的前提条件: 一个即时消息和出席信息会话的正式建立. 实现和部署经验已经表明这个额外的步骤是不必要的. 无论如何, 为了向后兼容，一个实现可以仍提供那个特性. 这使得新软件节省一个回合而旧软件能够连接.

满足了XMPP‑CORE中的前提条件之后, XMPP客户端就有了一个和一个XMPP服务器长连的XML流, 这使得该用户能控制客户端在该流上发送和接收基本上不限数量的XML节. 这样一个流可被用于交换消息, 分享出席信息, 并且准实时地进行结构化的 请求-应答 交互. 在XML流的协商之后, 即时消息和出席信息会话的典型流程如下:

  1. 接收某人的名册. (见 章节2.2.)
  2. 发送最初的出席信息给服务器用于广播给所有已订阅的联系人, 也就是从XMPP通讯角度来看的 "上线" . (见 章节4.2 .)
  3. 交换消息, 管理出席信息订阅, 执行名册更新, 以及在一般过程中，贯穿该会话生命周期的以特定语义生成的其他XML节. (见 章节 5, 3, 2, 和 6.)
  4. 当需要的时候，通过发送unavailable出席信息并关闭下面的XML流来中止该会话. (见 章节4.5.)

术语

本文中的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和 "OPTIONAL" 的解释参见RFC 2119 关键字 .

本文继承了 XMPP‑CORE 中定义的术语.

术语 "automated client" 和 "interactive client" 的含义和 TLS‑CERTS 中定义的相同.

为了方便, 本文借用了术语 "user" 来指代一个XMPP帐号的所有者; 无论如何, 帐号所有者不需要是自然人并且可以是机器人, 设备, 或其他自动化的应用.

一些其他的术语, 类似 "interested resource", 在本文的正文中定义.

接下来的"XML Notation"用在IRI中展示无法用纯ASCII文档表达的字符串, 本文的一些例子中使用了格式 "&#x...." 作为一个符号设备来展示 UNICODE 字符串(例如, 字符串 "ř" 代表 Unicode 字符串 LATIN SMALL LETTER R WITH CARON); 这个格式在XMPP系统中绝对不会在网络上被发送.

在例子中, 每一行已经被封装成便于阅读的样子, "[...]" 意味着省略, 并且使用了以下前缀(这些前缀不会在通讯中被发送):

  • C: = 客户端
  • CC: = 联系人的客户端
  • CS: = 联系人的服务器
  • S: = 服务器
  • UC: = 用户的客户端
  • US: = 用户的服务器

读者需要注意这些例子不包括细节, 并且例子里的一些协议流程中, 展示的备用步骤不一定是由前一个步骤发送的确切的数据触发的; 本文或常用参考文档中的协议规范所用到的所有用例里面提供的例子都遵从上述规则. 所有例子都是虚构的并且交换的信息 (例如, 用户名和密码) 不代表任何现存的用户和服务器.

管理花名册 Managing the Roster

在XMPP中， 一个用户的花名册(roster)包含任意数量的特定联系人。一个用户的花名册由用户的服务器代替用户储存，从而使用户可以从任何资源设备访问花名册信息。当用户添加或修改花名册项目，并且无错误发生时，服务器如果有可能应该(SHOULD)不加修改的存储数据，并且当一个授权的客户端请求花名册时，服务器必须(MUST)返回已存储的数据。

安全警告: 因为用户的花名册包含机密的数据，因此服务器必须(MUST)限制对这些数据的访问，只有经授权验证的实体(典型的为帐户拥有者)才有权利检索，修改和删除它。

语法和语义

来自“http://wiki.jabbercn.org/index.php?title=RFC6121&oldid=2883”
个人工具