摘要：
此文档定义了可扩展消息出席协议（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地址的资源标识符来区别（例如：<node@domain/home> vs. <node@domain/work>）。客户端与服务器的推荐连接端口为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 网络
由于每个服务器由网络地址指定，并且由于服务器与服务器间的通信是客户与服务器协议的直接扩展，实际上，系统由互相通信的服务器网络组成。举个例子，<juliet@example.com>能与<romeo@example.net>交换消息、出席，以及其它信息。这是使用网络寻址标准的消息协议（例如[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均基于前述规则。此结构最普通的用法就是用户以<user@host/resource>形式标识一个即时消息用户、用户连接的服务器、用户连接的资源（例如：特别的客户端）。
然而，结点类型可能不仅是客户端，举个例子，一个提供多用户聊天服务的特别聊天室，可以以<room@service>（“room”是聊天室名，“service”是多用户聊天服务的主机名）作为地址。并且，此聊天室的特别拥有者可能以<room@service/nick> （“nick”是此拥有者的房间昵称）作地址，许多其它JID类型均有可能（例如：<domain/resource>可能是一个服务器端脚本或服务）。
JID（结点标识符，域标识符，资源标识符）的每个可允许部分长度不准超过1023字节，结果，最大总长度（包括‘@’，‘/’分隔符）为3071字节。
3.2 域标识符
域标识符是基本标识符，且是JID中仅有的一个必须的元素（仅有域标识符的JID是有效的）。它通常表示网络网关与“主要的”服务器，具有为其它实体间的连接进行XML路由与数据管理的能力。然而，由域标识符作为参考的实体并不总是服务器，它可能是一项以服务器子域为地址的服务，提供多于服务器（例：多用户聊天服务，用户目录，或外部消息系统的一个网关）的功能。
每个服务器或服务的域标识符将通过网络进行通信，它可能是IP地址，并应当是完全合法的域名（参考[DNS]）。域标识符必须是一个“国际化的域名”，定义在[IDNA]，Nameprep [NAMEPREP] profile of stringprep [STRINGPREP]可以无错应用。比较两个域标识符之前，服务器必须（客户端是应该）首先对标签（定义在[IDNA]）应用Nameprep profile，以补足每个标识符。
3.3 节点标识符
结点标识符是一个可选的辅助标识符，放在域标识符之前，后以‘@’字符分隔。它通常表示实体请求与使用由服务器或网关（例如：一个客户端）提供的网络访问，虽然它也能表示其它种类的实体（例如：有多用户聊天服务功能的聊天室）。由结点标识符表示的实体，在特定域上下文中，在XMPP即时消息与出席应用中被加以地址，此类地址称作“bare JID”，形式为<node@domain>
结点标识符必须像the Nodeprep profile of [STRINGPREP]这样格式化，可以无错应用。比较两个结点标识符之前，服务器必须（客户端应该）首先对每个标识符应用Nameprep profile。
3.4 资源标识符
资源标识符是一个可选的第三位标识符，位于域标识符之后，后跟‘/’作为分隔符。资源标识符可以修改<node@domain>也可以只是<domain>地址。它通常表示一个特别的会话、连接（例如：一个设备或位置），或属于带有节点标识符的对象（例如：在多用户聊天室的一个参与者）。当提供必要的信息来完成资源绑定（第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”（<node@domain>）应该被授权身份，被派生于授权认证，定义在[SASL]。在资源绑定期间（第7节）“full JID”（<node@domain/resource>）的资源标识符部分应当是客户端与服务器间协商的资源标识符。
接收实体必须确保结果JID（包括结点标识符，域标识符，资源标识符，分隔符）遵从此节中前面所定义的规则与格式；为满足此限制，接收实体可能需要替代由接收实体所决定的规范的JID初始实体所发送的JID。
此文档定义了可扩展消息出席协议（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地址的资源标识符来区别（例如：<node@domain/home> vs. <node@domain/work>）。客户端与服务器的推荐连接端口为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 网络
由于每个服务器由网络地址指定，并且由于服务器与服务器间的通信是客户与服务器协议的直接扩展，实际上，系统由互相通信的服务器网络组成。举个例子，<juliet@example.com>能与<romeo@example.net>交换消息、出席，以及其它信息。这是使用网络寻址标准的消息协议（例如[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均基于前述规则。此结构最普通的用法就是用户以<user@host/resource>形式标识一个即时消息用户、用户连接的服务器、用户连接的资源（例如：特别的客户端）。
然而，结点类型可能不仅是客户端，举个例子，一个提供多用户聊天服务的特别聊天室，可以以<room@service>（“room”是聊天室名，“service”是多用户聊天服务的主机名）作为地址。并且，此聊天室的特别拥有者可能以<room@service/nick> （“nick”是此拥有者的房间昵称）作地址，许多其它JID类型均有可能（例如：<domain/resource>可能是一个服务器端脚本或服务）。
JID（结点标识符，域标识符，资源标识符）的每个可允许部分长度不准超过1023字节，结果，最大总长度（包括‘@’，‘/’分隔符）为3071字节。
3.2 域标识符
域标识符是基本标识符，且是JID中仅有的一个必须的元素（仅有域标识符的JID是有效的）。它通常表示网络网关与“主要的”服务器，具有为其它实体间的连接进行XML路由与数据管理的能力。然而，由域标识符作为参考的实体并不总是服务器，它可能是一项以服务器子域为地址的服务，提供多于服务器（例：多用户聊天服务，用户目录，或外部消息系统的一个网关）的功能。
每个服务器或服务的域标识符将通过网络进行通信，它可能是IP地址，并应当是完全合法的域名（参考[DNS]）。域标识符必须是一个“国际化的域名”，定义在[IDNA]，Nameprep [NAMEPREP] profile of stringprep [STRINGPREP]可以无错应用。比较两个域标识符之前，服务器必须（客户端是应该）首先对标签（定义在[IDNA]）应用Nameprep profile，以补足每个标识符。
3.3 节点标识符
结点标识符是一个可选的辅助标识符，放在域标识符之前，后以‘@’字符分隔。它通常表示实体请求与使用由服务器或网关（例如：一个客户端）提供的网络访问，虽然它也能表示其它种类的实体（例如：有多用户聊天服务功能的聊天室）。由结点标识符表示的实体，在特定域上下文中，在XMPP即时消息与出席应用中被加以地址，此类地址称作“bare JID”，形式为<node@domain>
结点标识符必须像the Nodeprep profile of [STRINGPREP]这样格式化，可以无错应用。比较两个结点标识符之前，服务器必须（客户端应该）首先对每个标识符应用Nameprep profile。
3.4 资源标识符
资源标识符是一个可选的第三位标识符，位于域标识符之后，后跟‘/’作为分隔符。资源标识符可以修改<node@domain>也可以只是<domain>地址。它通常表示一个特别的会话、连接（例如：一个设备或位置），或属于带有节点标识符的对象（例如：在多用户聊天室的一个参与者）。当提供必要的信息来完成资源绑定（第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”（<node@domain>）应该被授权身份，被派生于授权认证，定义在[SASL]。在资源绑定期间（第7节）“full JID”（<node@domain/resource>）的资源标识符部分应当是客户端与服务器间协商的资源标识符。
接收实体必须确保结果JID（包括结点标识符，域标识符，资源标识符，分隔符）遵从此节中前面所定义的规则与格式；为满足此限制，接收实体可能需要替代由接收实体所决定的规范的JID初始实体所发送的JID。
