RFC3920(XMPP协议)中文版.docx

RFC3920可扩展的消息和出席信息协议（GMP）P:核心协议关于本文的说明本文为互联网社区定义了一个互联网标准跟踪协议，并且申请讨论协议和提出了改进的建议请参照“互联网官方协议标准”的最新版本（STD1）获得这个协议的标准化进程和状态本文可以不受限制的分发版权声明本文版权属于互联网社区（C）TheInternetSocietP（20GG）.摘要本文定义了可扩展消息和出席信息协议（GMPP）的核心功能，这个协议采用GML流实现在任意两个网络终端接近实时的交换结构化信息GMP限供一个通用的可扩展的框架来交换GM嗷据，它主要用来建立即时消息和出席信息应用以实现RFC277弼需求目录1. 绪论2. 通用的架构3. 地址空间4. GML流5. TLS的使用6. SASL的使用7. 资源绑定8. 服务器回拨9. GML节10. 服务器处理GM市的规则11. GMPPh的GMLffl法12. 核心的兼容性要求13. 国际化事项14. 安全性事项15. IANA事项16. 参考1. 绪论1.1. 概览GMPP1一个开放式的GM的、议，设计用于准实时消息和出席信息以及请求-响应服务其基本的语法和语义最初主要是由Jabber开放源代码社区于1999年开发的。

20GG^,GMPPC作组被授权接手开发和改编Jabber协议以适应IETF的消息和出席信息技术作为GMPPC作组的成果，本文定义了GMPP1.0的核心功能；在RFC2779[IMP-REQ期指定的提供即时消息和出席信息功能的扩展，定义在GMPP-IM协议[theEGtensibleMessagingandPresenceProtocol(GMPP):lnstantMessagingandPresenee]中1.2. 术语本文中大写的关键字"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT","SHOULD","SHOULDNOT","RECOMMENDED","MAP"OPTIONAL的确切含义符合BCP14,RFC2119[TERMS].2. 通用的架构2.1. 概览尽管GMPP:有结合任何特定的网络结构，通常认为它是客户-服务器架构的一种实现,在这里客户端用GMPPJ方式访问服务器采用的是TC唯接，服务器之间的通信也是TC选接以下是这一架构的抽象的示意图（这里"-"表示使用GMPP1讯，"="表示可使用任何协议通讯）C1—S1—S2—C3|C2—+—G1===FN1===FC1符号代表的意思如下：*C1,C2,C3=GMPP客户端?S1,S2=GMP用艮务器.G仁一个GMP和外部（非GMPPP消息网络之间进行“翻译”的网关?FN1=一个外部消息网络?FC1W卜部消息网络上的一个客户端22服务器服务器充当GMPPI信的一个智能抽象层，它主要负责*管理发出的连接或其他实体的会话，在GML流（第四章）的表单中接收和发送给授权的客户端，服务器和其他实体。

用GM就通过实体转发特定地址的GML消息（第九章）大部分GMP廉容的服务器也负责存储客户端使用的数据（比如基于GMP版用的联系人名单）；在这种情况下，GM激据直接由服务器代替客户端处理而不需要转发到其他实体23客户端大部分客户端通过TCP连接直接连到服务器，并通过GMP肤得由服务器和任何相关的服务所提供的全部功能多个不同资源（比如不同的设备和地点）的客户端可以同时登陆并且并发的连接到一个服务器，每个不同资源的客户端通过GMP地址的资源标识符来区分（比如），参见地址空间（第三章）议__的客户端和服务器连接的端口是5222,这个端口已经在IANA（在第十G五章第九节查阅端口号码）注册了24网关网关是一个特殊用途的服务器端的服务，主要功能是把GMP翻译成外部（非GMPP消息系统，并把返回的消息翻译成GMPP例如到email（参见［SMTP）,IRC（参见［IRC］）,SIMPLE（参见［SIMPLE）,SMS勺网关；还有和别的消息服务的网关，比如AIM，ICQ，MSNMessenger，Pahoo!lnstantMessenger。

网关和服务器之间的通信，网关和外部消息系统的通信，不在本文描述范围之内2.5. 网络因为每个服务器都是由一个网络地址来标识的并且服务器之间的通信是客户-服务器协议的直接扩展，实际上整个系统是由很多互通的服务器构成的例如，vjuliet@eG>可以和交换消息，出席信息和其他信息这种模式常见于那些需要使网络地址标准化的协议（比如SMTP）任意两个服务器之间的通信是可选（OPTIONAL）的如果被激活，那么这种通信应该（SHOUL）D通过GMLM绑定到TCP连接上进行建议的（RECOMMENDE服务器之间的连接端口为5269,这个端口号已经在IANA（在第十G五章第九节查阅端口号码）注册了3. 地址空间3.1. 概览一个实体可以是任何一个被认为是一个网络端点的东西（例如网络上的一个ID）,而且它是通过GMP进行通信的所有这些实体都有一个具有唯一性的地址，并符合RFC2396URI]规范要求的格式由于历史原因，一个GMPP；体的地址被称为Jabberldentifier或JID一个合法的JID包括一组排列好的元素，包括域名(domainidentifier)，节点名(nodeidentifier)，和资源名(resourceidentifier)。

JID的语法定义，使用[ABNF中的AugmentedBackus-Naur格式IPv4地址和IPv6地址规则在附录B中的[IPv6]中定义；确定节点规则的合法字符顺序由附录A的[STRINGPREP的Nodeprep部分来定义；确定资源规则的合法字符顺序由附录B的[STRINGPREP的Resourceprep部分来定义；子域名规则参考[IDNA]中关于国际域名标签的描述jid=[node"@"]domain["/"resource]domain=fqdn/address-literalfqdn=(sub-domain1G("."sub-domain))sub-domain=(internationalizeddomainiabel)address-literal=IPv4address/IPv6address所有JID都是基于上述的结构类似这种结构，最常用来标识一个即时消息用户，这个用户所连接的服务器，以及这个用户用于连接的资源(比如特定类型的客户端软件)不过，节点类型不是客户端也是有可能的，比如一个用来提供多用户聊天服务的特定的聊天室，地址可以是 ( 这里“room “是聊天室的名字而”service “是多用户聊 天服务的主机名），而加入了这个聊天室的某个特定的用户的地址则是（这里”nick“是用户在聊天室的昵称）。

许多其他的JID类型都是可能的（例如vdomain/resource>可能是一个服务器端的脚本或服务）一个JID的每个合法部分（节点名，域名，资源名）的长度不能（MUSTNO）T超过1023字节也就是整体长度（包括’@'和7'）不能超过3071字节3.2. 域名域名是一个主要的ID并且是JID中唯一必需（REQUIRED的元素（一个纯粹的域名也是一个合法的JID）它通常代表网络的网关或者“主”服务器，其他实体通过连接它来实现GML专发和数据管理功能然而，由一个域名标识引用的实体，并非总是一个服务器，它也可能是一个服务器的子域地址，提供额外的功能（比如多用户聊天服务，用户目录，或一个到外部消息系统的网关）每个服务器或者服务的域名，可以（MAP是一个IP地址，但应该（SHOULD是一个完全合法的域名（参见［DNS）.一个域名ID必须（MUST是［IANA］里定义的“国际化域名”，并且按［STRINGPREP中的［NAMEPREfprofile进行成功的字符转换在比较两个域名ID之前，服务器必须（MUST，客户端应该（SHOULD首先按照Nameprepprofile（定义在［IANA］中）来转换每个域名的字符。

3.3. 节点名节点名是一个可选（OPTIONAL）的第二ID,放在域名之前并用符号"@"分开.它通常表示一个向服务器或网关请求和使用网络服务的实体（比如一个客户端）,当然它也能够表示其他的实体（比如在多用户聊天系统中的一个房间）.节点名所代表的实体，它的地址依赖于一个特定的域名；在GMPP勺即时消息和出席信息应用系统中，这个地址是“纯JID”＜node@domain＞中的——部分一个节点名必须按［STRINGPREP中的Nodeprepprofile进行成功的字符转换在比较两个节点ID之前，服务器必须（MUST）,客户端应该（SHOULD首先按Nodeprepprofile转换每个ID的字符34资源名资源名是一个可选的第三ID,它放在域名的后面并由符号"/"分开资源名可以跟在＜node@domain＞后面也可以跟在＜domain＞后面它通常表示一个特定的会话，连接（比如设备或者所在位置），或者一个附属于某个节点ID实体相关实体的对象（比如多用户聊天室中的一个参加者）对于服务器和和其他客户端来说，资源名是不透明的当它提供必需的信息以完成资源绑定（参见第七章）的时候，通常是由客户端来实现的（尽管可以由客户端向服务器请求完成），然后显示为“已连接的资源”。

一个实体可以（MAP并发维护多个已连接的资源每个已连接的资源由不同的资源ID来区分一个资源名必须（MUST按［STRINGPREP中的Resourceprepprofile进行成功的格式化在比较两个资源ID之前，服务器必须（MUST），客户端应该（SHOULD首先按Resourceprepprofile转换每个ID的字符3.5. 地址的确认在SASL（见第六章）握手之后（如果必要的话，也在资源绑定（见第七章）之后），正在接收流信息的实体必须（MUST）确认初始实体的ID对于服务器间的通信，在SASL®手时，如果没有指明授权的ID,这个初始的实体应该（SHOULD是经过认证实体（参见简单认证和安全层协议[SAS口中的定义）授权的ID（见第六章）对于客户端和服务器的通信，在SASL握手时，如果没有指明授权的ID,“纯JID"（＜node@domain）应该SHOULD是经过认证实体（参见[SASL中的定义）授权的ID,“全JID"（＜node@domain/resource〉）的资源部分应该（SHOULD是由客户端和服务器在资源绑定的时候商定的（参见第七章）接收的实体必须（MUST）确保结果JID（包括节点名，域名，资源名以及分隔符）与本章前面部分描述的规则和格式相一致；为了满足这些约束条件，接收实体可能（MAP）需要把初始实体的发送方JID替换成接收实体认可的规范JIDO4. GML流4.1. 概览两个基本概念，GM就和GML?,使得在出席信息已知的实体之间，异步交换低负载的结构化信息成为可能。