《XMPP 3920 最靠谱的中文翻译文档》由会员分享，可在线阅读，更多相关《XMPP 3920 最靠谱的中文翻译文档（47页珍藏版）》请在金锄头文库上搜索。
1、XMPP 3920 最靠谱的中文翻译文档（一）xmpp 协议之 可扩展消息出席协议：核 心 RFC 3920摘要：此文档定义了可扩展消息出席协议（XMPP）的核心特性：协议使用XML元素在任意 两个网络端点间近实时的交换结构化信息。当XMPP为交换XML数据提供一般化，可扩展的 框架时，它主要用于建立满足RFC2779的即时消息与出席应用的需求。1 介绍1.1 概要XMPP是一个开放的可扩展标记语言XML协议，用于近实时的消息、出席与请求- 响应服务。基本语法语义最初是由Jabber开源社区在1999年开 发的。2002年，XMPP工作 组授权开发一个Jabber协议的改写本，将适用于IETF
2、的即时消息（IM）与出席技术。作为XMPP工作组的成果，此文档定义了XMPP 1.0的核心内容；提供即时消息与出 席功能的扩展需求定义在RFC2779IM-REQS冲，由XMPP：即时消息与出席XMPP-IM指定。1.2 术语文档中的大写关键字： MUST,MUSTNOT,REQUIRED,SHALL,SHALLNOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL在 BCP14,在 RFC 2119 TERMS 中描述。2 一般架构2.1 概述虽然XMPP并未与任何特定网络架构结合，但到目前为止，它大致上已经由一个客 户-服务器的架构实现了。其
3、中，客户端利用XMPP访问基于TCP连接的一个服务器，并且， 服务器间也通过TCP连接进行彼此间的通信。XMPPClientServerServerTCPTCPF图为此架构的高层视图（“-”表示使用XMPP通信，“=”表示使用任何其它协议通信）C1S1-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） 管理连接
4、其它实体的会话，以XML流格式（第4节）在已授权的客户端、服务器以及其 它实体间来回传送。2）通过XML流在实体间路由具有合适地址的XML节（第9节）。大多数与XMPP兼容的服务器设想有能力存储客户端的数据（例：基于XMPP即时消 息与出席应用的用户的联系列表）；在这种情况下，XML数据由服务器自身代表客户端直接 处理，并不路由到其它实体。2.3 客户端大多数客户端通过TCP 连接直接连到服务器，并且使用XMPP，充分利用由服务器 及任何相关服务所提供的功能。多种资源（例如：设备或位置）可能代表 每个被授权客户 端同时连到服务器上。每个资源均由定义在地址方案（第3节）下的XMPP地址的资源标识
5、 符来区别（例如： vs.url=mailto:nodedomain/worknodedomain/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 Presen
6、ce Leveraging Extensions），短消息服务（SMS），遗留 即时消息服务，诸如 AIM, ICQ, MSN Messenger, Yahoo! Instant Messenger。网关与服务器间的通信，网关与外部消息系统间的通信，均未在此文档中定义。2.5 网络由于每个服务器由网络地址指定,并且由于服务器与服务器间的通信是客户与服务 器协议的直接扩展,实际上,系统由互相通信的服务器网络组成。举个例 子,交换消息、出席，以及其 它信息。这是使用网络寻址标准的消息协议（例如SMTP）所熟悉的模式。任意两服务器 间的通信是可选的。如果可通信，此类通信就应当发生在绑定到TCP连接的
7、XML流上。服 务器间连接的推荐端口为5269，由IANA注册（参考端口编号（15.9节）3 寻址方案3.1 概述实体可被看作是使用XMPP进行通信的任意网络端点（例如：一个网络上的ID）。 任意此类实体均以与RFC2396URI 致的格式来唯一设定地址。由于历史原因，XMPP实体 的地址称作Jabber标识符或JID。一个有效JID包含一套有序元素：域标识符，结点标识 符，资源标识符。JID的语法定义如下，使用增广巴斯科范式ABNF（Augmented Backus-Naur Form）。（Ipv4地址与Ipv6地址规则定义在Ipv6的附录B；符合结点规则的允许字符序列由Nodeprep p
8、rofile of STRINGPREP定义，编入本文档的附录A；符合资源规则的允许字符 序列由Resourceprep profile of STRINGPREP定义，编入本文档的附录B；子域规则参考 国际化域标识的概念，在IDNA中有述）。jid= node domain / resource domain=fqdn / address-literalfqdn=（sub-domain 1*（. sub-domain）sub-domain=（internationalized domainlabel）address-literal =IPv4address / IPv6address所有JI
9、D均基于前述规则。此结构最普通的用法就是用户以url=mai lto: userhos t/resourceuserhos t /resource/url 形式标识一个即时消息 用户、用户连接的服务器、用户连接的资源（例如：特别的客户端）。然而，结点类型可能不仅是客户端，举个例子，一个提供多用户聊天服务的特别聊 天室，可以以url=mai lto:r oomserviceroomservice/url（“room ” 是聊天室名， “service”是多用户聊天服务的主机名）作为地址。并且，此聊天室的特别拥有者可能以fe 可以只是 domain地址。它通常表示一个特别的会话、连接（例如：一个设
10、备或位置），或属于带 有节点标识符的对象（例如：在多用户聊天室的一个参与者）。当提供必要的信息来完成资 源绑定（第 7节）时，资源标识符对服务器与其它客户端均不透明，并且由客户端实现来 定义，以后，它作为一个“已连接资源”参考。实体可能同时维护多连接，每个已连接的 资源均由资源标识符来进行区别。资源标识符必须按Resourceprep profile of STRINGPREP格式化，才能无错应 用。比较两个资源标识符前，服务器必须（客户端应该）首先为每个标识符应用Resourceprep profile。3.5 决定地址SASL协商后（第6节），如果正确，资源绑定（第7节），流接收实体必须决
11、定 初始实体的JID。如果SASL协商（第6节）期间未指定授权身份，对服务器与服务器间的通信，初 始实体的JID应当被授权身份，派生于认证身份，在SASL（Simple Authentication and Security Layer简单授权与安全层）说明SASL中定义。如果SASL协商（第6节）期间未指定授权身份，对客户端到服务器的通信，“bare JID”（url二mailto:nodedomainnodedomain/url）应该被授权身份，被派生于授权 认证，定义在SASL。在资源绑定期间（第7节）“full JID”（url=mai lto: nodedomain/resourcenodedomain/resource/ur l& gt;）的资源标识 符部分应当是客户端与服务器间协商的资源标识符。接收实体必须确保结果JID （包括结点标识符，域标识符，资源标识符，分隔符） 遵从此节中前面所定义的规则与格式；为满足此限制，接收
