XMPP中文文档.pdf-资料库

XMPP 3920 最靠谱的中文翻译文档（一） xmpp 协议之可扩展消息出席协议：核心 RFC 3920 摘要：此文档定义了可扩展消息出席协议（XMPP）的核心特性：协议使用 XML 元素在任意两个网络端点间近实时的交换结构化信息。当 XMPP 为交换 XML 数据提供一般化，可扩展的框架时，它主要用于建立满足 RFC2779 的即时消息与出席应用的需求。 1 介绍 1.1 概要 XMPP 是一个开放的可扩展标记语言[XML]协议，用于近实时的消息、出席与请求-响应服务。基本语法语义最初是由 Jabber 开源社区在 1999 年开发的。2002 年， XMPP 工作组授权开发一个 Jabber 协议的改写本，将适用于 IETF 的即时消息（IM）与出席技术。作为 XMPP 工作组的成果，此文档定义了 XMPP 1.0 的核心内容；提供即时消息与出席功能的扩展需求定义在 RFC2779[IM-REQS]中，由 XMPP：即时消息与出席[XMPP-IM] 指定。 1.2 术语文档中的大写关键字："MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL"在 BCP14, 在 RFC 2119 [TERMS]中描述。 2 一般架构 2.1 概述虽然 XMPP 并未与任何特定网络架构结合，但到目前为止，它大致上已经由一个客户-服务器的架构实现了。其中，客户端利用 XMPP 访问基于[TCP]连接的一个服务器，并且，服务器间也通过 TCP 连接进行彼此间的通信。 XMPP Client------------Server------------Server

TCP TCP 下图为此架构的高层视图（“-”表示使用 XMPP 通信，“=”表示使用任何其它协议通信） C1----S1---S2---C3 | C2----+--G1===FN1===FC1 符号表示如下： 1） C1，C2，C3 = XMPP 客户端 2） S1，S2 = XMPP 服务器 3） G1 = 网关：在 XMPP 与外部协议（非 XMPP）的消息网络间转换。 4） FN1 = 外部消息网络 5） C1 = 外部消息网络的客户端 2.2 服务器服务器作为 XMPP 通信担当智能抽象层。它的主要责任是： 1）管理连接其它实体的会话，以 XML 流格式（第 4 节）在已授权的客户端、服务器以及其它实体间来回传送。 2）通过 XML 流在实体间路由具有合适地址的 XML 节（第 9 节）。大多数与 XMPP 兼容的服务器设想有能力存储客户端的数据（例：基于 XMPP 即时消息与出席应用的用户的联系列表）；在这种情况下，XML 数据由服务器自身代表客户端直接处理，并不路由到其它实体。 2.3 客户端大多数客户端通过[TCP]连接直接连到服务器，并且使用 XMPP，充分利用由服务器及任何相关服务所提供的功能。多种资源（例如：设备或位置）可能代表每个被授权客户端同时连到服务器上。每个资源均由定义在地址方案（第 3 节）下的 XMPP 地址的资源标识符来区别（例如：< [url=mailto:node@domain/home]node@domain/home[/url]> vs. <[url=mailto:node@domain/work]node@domain/work[/url]>）。客户端与服务器的推荐连接端口为 5222，已由 IANA 注册（参考端口编号（15.9 节））。 2.4 网关网关是服务器端的一种特殊服务，它的主要功能是将 XMPP 翻译成外部消息系统所使用的协议（非 XMPP），也可将数据翻译回 XMPP。例如 EMAIL 网关（参考[SMTP]），

Internet Relay Chat（参考[IRC]），SIMPLE（参考[SIIMPLE]，Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions），短消息服务（SMS），遗留即时消息服务，诸如 AIM，ICQ，MSN Messenger，Yahoo! Instant Messenger。网关与服务器间的通信，网关与外部消息系统间的通信，均未在此文档中定义。 2.5 网络由于每个服务器由网络地址指定，并且由于服务器与服务器间的通信是客户与服务器协议的直接扩展，实际上，系统由互相通信的服务器网络组成。举个例子， <[url=mailto:juliet@example.com]juliet@example.com[/url]>能与& lt;[url=mailto:romeo@example.net]romeo@example.net[/url]>交换消息、出席，以及其它信息。这是使用网络寻址标准的消息协议（例如[SMTP]）所熟悉的模式。任意两服务器间的通信是可选的。如果可通信，此类通信就应当发生在绑定到 [TCP]连接的 XML 流上。服务器间连接的推荐端口为 5269，由 IANA 注册（参考端口编号（15.9 节）） 3 寻址方案 3.1 概述实体可被看作是使用 XMPP 进行通信的任意网络端点（例如：一个网络上的 ID）。任意此类实体均以与 RFC2396[URI]一致的格式来唯一设定地址。由于历史原因，XMPP 实体的地址称作 Jabber 标识符或 JID。一个有效 JID 包含一套有序元素：域标识符，结点标识符，资源标识符。 JID 的语法定义如下，使用增广巴斯科范式[ABNF]（Augmented Backus-Naur Form）。（Ipv4 地址与 Ipv6 地址规则定义在[Ipv6]的附录 B；符合结点规则的允许字符序列由 Nodeprep profile of [STRINGPREP]定义，编入本文档的附录 A；符合资源规则的允许字符序列由 Resourceprep profile of [STRINGPREP]定义，编入本文档的附录 B；子域规则参考国际化域标识的概念，在[IDNA]中有述）。 jid = [ node "@" ] domain [ "/" resource ] domain = fqdn / address-literal fqdn = (sub-domain 1*("." sub-domain)) sub-domain = (internationalized domain label) address-literal = IPv4address / IPv6address 所有 JID 均基于前述规则。此结构最普通的用法就是用户以 <[url=mailto:user@host/resource]user@host /resource[/url]>形式标识一个即时消息

用户、用户连接的服务器、用户连接的资源（例如：特别的客户端）。然而，结点类型可能不仅是客户端，举个例子，一个提供多用户聊天服务的特别聊天室，可以以< [url=mailto:room@service]room@service[/url]>（“room”是聊天室名，“service”是多用户聊天服务的主机名）作为地址。并且，此聊天室的特别拥有者可能以< [url=mailto:room@service/nick]room@service/nick[/url]>（“nick”是此拥有者的房间昵称）作地址，许多其它 JID 类型均有可能（例如：可能是一个服务器端脚本或服务）。 JID（结点标识符，域标识符，资源标识符）的每个可允许部分长度不准超过 1023 字节，结果，最大总长度（包括[url=mailto:‘@’]‘@’[/url]，‘/’分隔符）为 3071 字节。 3.2 域标识符域标识符是基本标识符，且是 JID 中仅有的一个必须的元素（仅有域标识符的 JID 是有效的）。它通常表示网络网关与“主要的”服务器，具有为其它实体间的连接进行 XML 路由与数据管理的能力。然而，由域标识符作为参考的实体并不总是服务器，它可能是一项以服务器子域为地址的服务，提供多于服务器（例：多用户聊天服务，用户目录，或外部消息系统的一个网关）的功能。每个服务器或服务的域标识符将通过网络进行通信，它可能是 IP 地址，并应当是完全合法的域名（参考[DNS]）。域标识符必须是一个“国际化的域名”，定义在 [IDNA]，Nameprep [NAMEPREP] profile of stringprep [STRINGPREP]可以无错应用。比较两个域标识符之前，服务器必须（客户端是应该）首先对标签（定义在[IDNA]）应用 Nameprep profile，以补足每个标识符。 3.3 节点标识符结点标识符是一个可选的辅助标识符，放在域标识符之前，后以 [url=mailto:‘@’]‘@’[/url]字符分隔。它通常表示实体请求与使用由服务器或网关（例如：一个客户端）提供的网络访问，虽然它也能表示其它种类的实体（例如：有多用户聊天服务功能的聊天室）。由结点标识符表示的实体，在特定域上下文中，在 XMPP 即时消息与出席应用中被加以地址，此类地址称作“bare JID”，形式为 <[url=mailto:node@domain]node@domain[/url]> 结点标识符必须像 the Nodeprep profile of [STRINGPREP]这样格式化，可以无错应用。比较两个结点标识符之前，服务器必须（客户端应该）首先对每个标识符应

用 Nameprep profile。 3.4 资源标识符资源标识符是一个可选的第三位标识符，位于域标识符之后，后跟‘/’作为分隔符。资源标识符可以修改< [url=mailto:node@domain]node@domain[/url]>也可以只是地址。它通常表示一个特别的会话、连接（例如：一个设备或位置），或属于带有节点标识符的对象（例如：在多用户聊天室的一个参与者）。当提供必要的信息来完成资源绑定（第 7 节）时，资源标识符对服务器与其它客户端均不透明，并且由客户端实现来定义，以后，它作为一个“已连接资源”参考。实体可能同时维护多连接，每个已连接的资源均由资源标识符来进行区别。资源标识符必须按 Resourceprep profile of [STRINGPREP]格式化，才能无错应用。比较两个资源标识符前，服务器必须（客户端应该）首先为每个标识符应用 Resourceprep profile。 3.5 决定地址 SASL 协商后（第 6 节），如果正确，资源绑定（第 7 节），流接收实体必须决定初始实体的 JID。如果 SASL 协商（第 6 节）期间未指定授权身份，对服务器与服务器间的通信，初始实体的 JID 应当被授权身份，派生于认证身份，在 SASL（Simple Authentication and Security Layer 简单授权与安全层）说明[SASL]中定义。如果 SASL 协商（第 6 节）期间未指定授权身份，对客户端到服务器的通信， “bare JID”（<[url=mailto:node@domain]node@domain[/url]>）应该被授权身份，被派生于授权认证，定义在[SASL]。在资源绑定期间（第 7 节）“full JID” （<[url=mailto:node@domain/resource]node@domain/resource[/url]& gt;）的资源标识符部分应当是客户端与服务器间协商的资源标识符。接收实体必须确保结果 JID（包括结点标识符，域标识符，资源标识符，分隔符）遵从此节中前面所定义的规则与格式；为满足此限制，接收实体可能需要替代由接收实体所决定的规范的 JID 初始实体所发送的 JID。 XMPP 3920 最靠谱的中文翻译文档（二） XML 流 4.1 概述

使 presence-‐aware 实体间能够相互迅速的、异步交换相关的小负载的结构化信息有两种基本元素：XML 流与 XML 节。术语定义如下： XML 流定义：XML 流是一个容器，用于网络上任意两实体间交换 XML 元素。XML 流的开始是以一个起始的 XML标记（有合适的属性与命名空间声明）表示，XML 流的结尾以一个结束的 XML标记表示。在流的生命周期中，初始化它的实体能够通过流发送极多的 XML 元素，元素与 XML 节（定义在此，, , 或元素由缺省命名空间验证）都用于协商流（例：协商使用 TLS（第 5 节）或使用 SASL（第 6 节））。“初始流”是从初始实体（通常是一个客户端或服务器）到接收实体（通常是一个服务器）的协商，并被看作与从初始实体到接收实体的会话一致。初始流能从初始实体到接收实体单向通信；为了能够从接收实体到初始实体的信息交换，接收实体必须在反方向协商一个流（“响应流”）。 XML 节定义：XML 节是一个不连续的结构化信息语义单元，通过 XML 流从一个实体发送到另一个实体。XML 节以根的直接子层存在，如果它匹配产品[43]内容[XML]，则可以很好的平衡。任何 XML 节的开始都由深度为 1 的 XML 流（例如：）的开始标记元素来清楚的表示，XML 节的结尾由相应的深度为 1 的关闭标记来清楚的表示。为传送想要的信息，一个 XML 节可能包含必要的子元素（带有属性，元素，XML 字符数据）。在此定义的仅有的 XML 节是，，元素，由流的缺省命名空间验证，在 XML 节（第 9 节）中描述；为传输层安全（TLS：Transport Layer Security）协商，SASL 协商，或服务器回叫（第 8 节）而发送的 XML 元素，并不会当作 XML 节来考虑。考虑一个客户端与服务器的会话例子。为了连接到服务器，客户端必须初始化一个 XML 流：发送一个起始的标记给服务，可选先于一个指定 XML 版本的文本声明与字符编码支持（参考文本声明的内容（11.4）；也可参考字符编码（11.5））。服从本地策略与所提供的服务，服务器接下来应该回复另一个 XML 流给客户端，再次可选先于一个文本声明。一但客户端完成了 SASL 协商（第 6 节），客户端可以通过流发送极多的 XML 节给网络上的任意容器。当客户端想关闭流时，它简单发送一个关闭标记给服务器（也可以由

服务器来关闭流），从这以后，客户端与服务器都应终止潜在的连接（通常是一个 TCP 连接）。习惯于将 XML 考虑成以文档为中心的人可能希望看到客户端与服务器的会话作为两个末端开口的（自由回答的）XML 文档的组成部分：一个从客户端到服务器，另一个从服务器到客户端。从这个观点看，根元素可被认为是每个“文档”的文档实体，两个“文档”都由通过两个 XML 流发送的 XML 节的集聚来建立。然而，这种观点仅是一种方便；XMPP 并不以文档处理，而是以 XML 流或 XML 节来处理。本质上，那么，一个 XML 流充当了所有通过会话发送的 XML 节的信封。可用图简单表示如下： |-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐| | | |-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐| | | | | | | |-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐| | | | | | | |-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐| | | | | | | |-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐| | ... | |-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐| | | |-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐|

4.2 绑定到 TCP 虽然将一个 XML 流结合到一个[TCP]连接上不是必须的（例如：两个实体能通过其它诸如[HTTP]投票选举机制而彼此互连），此说明也只定义了 XMPP 到 TCP 的绑定。在客户端到服务器端通信的上下文中，服务器必须允许客户端为了从客户端到服务器与服务器到客户端的 XML 节发送共享的一个单 TCP 连接。在服务器到服务器的通信上下文中，服务器必须使用一条 TCP 连接用于从服务器到其对等服务器的 XML 节传送，另一条 TCP 连接（由对等初始化）用于对其等服务器到服务器的 XML 节传送，总共有两条 TCP 连接。 4.3 流安全当在 XMPP1.0 中协商 XML 流时，TLS 应当按 TLS 应用（第 5 节）所定义的来使用，SASL 必须按 SASL（第 6 节）所定义的来使用。“初始流” （例如：从初始实体到接收实体的流）与“响应流”（例如：从接收实体到初始实体的流）必须被分别保护，即使双向安全可能已通过相互的认证机制所建立。实体不应当在流被认证之前，尝试通过流发送 XML 节（第 9 节），但如果这样做了，那么，其它实体不准接受此类节，并应当返回一个流错误，然后终止两端的 XML 流与潜在的 TCP 连接；注意，这只适用于 XML 节（例如：, , 元素，由缺省命名空间检查）并不适用于流协商（例如：用于协商使用 TLS（第 5 节）或使用 SASL（第 6 节））的 XML 元素。 4.4 流属性流元素属性如下： 1） to—‘ to’属性应当仅用于从初始实体到接收实体的 XML 流头中，并且必须被设成一个接收实体服务的主机名。‘to’属性不应当设在接收实体回应初始实体的 XML 流头中；然而，如果‘to’属性包括在内，它应当被初始实体默默忽略。 2） from—‘ from’属性应当仅用于从接收实体到初始实体的 XML 流头中，并且必须被设成一个接收实体服务的主机名，此接收实体正授权访问初始实体。‘from’属性不应在初始实体发送到接收实体的流头中；然而，如果‘from’属性包括在内，它应当被接收实体忽略。 3） id—‘ id’属性应当仅用于从接收实体到初始实体的 XML 流头中。此属性是唯一一个由接收实体创建的，作为初始实体流与接收实体间会话的密钥，并且，在接收应用（通常是一个服务器）中是唯一的。注意：流 ID 可能是严格安全的，并且因此必须是即不能预测也不能重复的（参考[RANDOM]推荐关于随机安全观点）。 ‘id’属性不应在初始实体到接收实

资料库

XMPP中文文档.pdf

相关推荐

移动开发

热门标签

最新资料