RFC6122

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

互联网工程任务组(IETF)	P. Saint-Andre
申请讨论: 6122	Cisco
更新: 3920	2011年3月
类别: 标准跟踪
ISSN: 2070-1721

可扩展的消息和出席信息协议 (XMPP): 地址格式

摘要

本文定义了可扩展的消息和出席信息协议(XMPP)中使用的地址的格式, 包括支持非ASCII的字符串. 本文更新了 RFC 3920.

本文的状态

这是一个互联网标准跟踪文档.

本文是互联网工程工作组(IETF)的一个成果. 它代表了IETF社区的一致意见. 它已经公开审核并由互联网工程控制组(IESG)批准发布了. 更多关于互联网标准的信息请参见RFC 5741第2章.

关于本文当前状态的信息, 任何错误, 以及如何对它提出反馈，请到 http://www.rfc-editor.org/info/rfc6122 .

版权通知

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 应用规范，用于在任意两个或多个网络实体之间接近实时的传输XML数据流. XMPP实体的地址格式在1999年就已经 由Jabber开源社区开发出来, 第一次出现在 XEP‑0029 中是2002年, 规范化定义是2004年的 RFC3920 .

正如RFC 3920中所定义的, XMPP地址格式重用了 "stringprep" 技术来预备非ASCII字符串 STRINGPREP , 包括用于国际化域名的名字空间规范，定义于 NAMEPREP 和 IDNA2003 ，对应于两个XMPP特有的用于 localpart(本地部分) 和resourcepart(资源部分)的规范.

由于RFC 3920的发布, IDNA2003被IDNA2008取代 (见 IDNA‑PROTO , 它不是基于stringprep的. 随着IDNA社区的倡导, 其他使用stringprep的技术社区开始讨论从stringprep迁移到更"现代的"方法. XMPP社区(主要是 PRECIS 工作组)为了寻找RFC3920中定义的stringprep中的Nodeprep和Resourceprep的替代品，参与了那些讨论. 因为XMPP修订文档的所有其他问题都合并到 XMPP 了, XMPP工作组决定暂时分离出XMPP地址格式到一个独立的文档，这样不会延迟改进的XMPP文档的发布. 一旦新的国际化地址的预备和比较方法被完成，预期本文将被废弃.

所以, 本协议提供更正过的XMPP地址格式文档，使用2004年可用的国际化技术(当时RFC 3920发布了). 尽管本文主要参考了 IDNA2003 和 NAMEPREP , 但是鼓励XMPP软件开发者开始迁移到IDNA2008 (见 IDNA‑PROTO 以及相关文档) ，因为将来取代本协议的新协议将使用IDNA2008而不是IDNA2003.

本文更新了RFC 3920.

术语

本文使用的很多重要术语定义于 IDNA2003 , [RFC6122#STRINGPREP|STRINGPREP]] , UNICODE , 和XMPP .

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

地址

基础

一个XMPP实体就是任何可网址化并能使用XMPP通讯的东西. 由于历史原因, 一个XMPP实体的本地地址叫Jabber身份或JID. 一个合法的JID就是一个 UNICODE 代码所代表的字符串, 使用 UTF‑8 编码, 结构顺序是 localpart(本地部分), domainpart(域部分), 和resourcepart (资源部分)(这里前两个部分使用 '@' 字符分割, 而后两个部分使用 '/' 字符分割).

JID的语法定义如下，使用增强巴科斯-诺尔范式(ABNF).

   jid           = [ 本地部分 "@" ] 域部分 [ "/" 资源部分 ]
   本地部分        = 1*(节点)
                   ;
                   ; 一个 "节点" 就是一个UTF-8编码的Unicode代码点
                   ; 这个点满足 stringprep 中的 Nodeprep 范例
                   ;
   域部分         = IP文字 / IPv4地址 / 合法域名ifqdn
                   ;
                   ; "IPv4地址" 和 "IP文字" 规则 定义于 RFC 3986,
                   ; 匹配过程应用 RFC 3986 定义的
                   ; 先到先得匹配(又名 "贪婪的") 机制
                   ;
                   ; 注意从RFC 3986中对于 IP文字规则的重用
                   ; 意味着 IPv6地址由方括号包住
                   ; (也就是, 用 '[' 开始用 ']' 结束), 
                   ; 这个 RFC 3920 不管了
                   ;
   ifqdn         = 1*(名字点)
                   ;
                   ; 一个 "名字点" 就是一个UTF-8编码的Unicode码点，
                   ; 符合 stringprep 的 Nameprep 规范
                   ;
   resourcepart  = 1*(资源点)
                   ;
                   ; 一个 "资源点" 就是一个UTF-8编码的Unicode码,
                   ; 符合 stringprep 的 Resourceprep 规范
                   ;

所有JID都是基于上述结构.

一个JID的每个允许的部分 (本地部分, 域部分, 和资源部分) 的字节数必须不(MUST NOT)为零并且必须不(MUST NOT)大于1023, 也就是总的最大字节数 (包含 '@' 和 '/' 分割符) 为3071.

为了达到通过一个XMPP网络(例如, 一个XMPP节的 'to' 或 'from' 地址)来通讯的目的, 实体的地址必须(MUST)展现为一个JID, 而不是统一资源标识符 URI 或 国际化资源标识符 IRI . 一个 XMPP‑URI 本质上是一个JID带上一个 'xmpp:' 前缀; 无论如何, 用于XMPP的本地地址格式仅仅是一个不带URI方案的JID. XMPP‑URI 仅被用于XMPP自身的上下文在外部的标识和交互, 例如当从一个web页面连接到一个JID. XMPP‑URI 描述了这个如何安全的从一个XMPP URI 或 IRI 提取出一个JID的过程.

实现备注: 当把一个JID分解成它的各个部分时, 一个应用在使用任何转换机制之前需要匹配分隔符 '@' 和 '/' , 因为转换可能导致把特定的Unicode码点分解成分隔符(例如, U+FE6B SMALL COMMERCIAL AT 可能分解成 U+0040 COMMERCIAL AT).

域部分

一个JID的域部分就是 '@' 符号(如果有这个符号)后面和 '/' 符号(如果有)前面的部分; 它是一个主要的标识符并且是一个JID唯一必需的(REQUIRED)元素(仅仅是域部分就可以成为一个合法的JID). 一个典型的域部分标识了客户端连接的 "家" 服务器，它用来做XML路由和数据管理功能. 无论如何, 一个XMPP域部分不一定就是标识一个提供核心XMPP服务功能的实体 (例如, 一个域部分可能标识其他实体，例如一个多用户聊天服务, 一个发行-订阅服务, 或一个用户目录).

每个XMPP服务的域部分必须(MUST)是一个完全规范的域名(FQDN; 见 DNS ), IPv4地址, IPv6地址, 或自定义的主机名(也就是说, 一个文本标签，可在本地网络解析).

互操作性备注: 域部分是IP地址，可能无法被其他服务接受来进行服务器到服务器的通讯, 域部分是自定义的主机名不能用于公共网络，因为它只能被本地网络解析.

如果域部分的最后一个字符被认为是 IDNA2003 或 DNS 中的分隔标签 (点) , 在使用JID的域部分来路由一个XML节,和另一个JID做比较，或构建一个 XMPP‑URI 之前，必须把这个字符从域部分剥离出来. 特别是, 在进行任何其他规范化步骤 (例如应用 STRINGPREP 的 NAMEPREP 范本，或完成 IDNA2003 描述的转化成ASCII的操作)之前，这个字符必须剥离出来.

A domainpart consisting of a fully qualified domain name MUST be an "internationalized domain name" as defined in [IDNA2003] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.); that is, it MUST be "a domain name in which every label is an internationalized label" and MUST follow the rules for construction of internationalized domain names specified in [IDNA2003] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.). When preparing a text label (consisting of a sequence of UTF-8 encoded Unicode code points) for representation as an internationalized label in the process of constructing an XMPP domainpart or comparing two XMPP domainparts, an application MUST ensure that for each text label it is possible to apply without failing the ToASCII operation specified in [IDNA2003] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.) with the UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other than letters, digits, and hyphens). If the ToASCII operation can be applied without failing, then the label is an internationalized label. (Note: The ToASCII operation includes application of the [NAMEPREP] (Hoffman, P. and M. Blanchet, “Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN),” March 2003.) profile of [STRINGPREP] (Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings ("stringprep"),” December 2002.) and encoding using the algorithm specified in [PUNYCODE] (Costello, A., “Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA),” March 2003.); for details, see [IDNA2003] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.).) Although XMPP applications do not communicate the output of the ToASCII operation (called an "ACE label") over the wire, it MUST be possible to apply that operation without failing to each internationalized label. If an XMPP application receives as input an ACE label, it SHOULD convert that ACE label to an internationalized label using the ToUnicode operation (see [IDNA2003] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.)) before including the label in an XMPP domainpart that will be communicated over the wire on an XMPP network (however, instead of converting the label, there are legitimate reasons why an application might instead refuse the input altogether and return an error to the entity that provided the offending data).

A domainpart MUST NOT be zero bytes in length and MUST NOT be more than 1023 bytes in length. This rule is to be enforced after any mapping or normalization resulting from application of the Nameprep profile of stringprep (e.g., in Nameprep some characters can be mapped to nothing, which might result in a string of zero length). Naturally, the length limits of [DNS] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.) apply, and nothing in this document is to be interpreted as overriding those more fundamental limits.

In the terms of IDNA2008 [IDNA‑DEFS] (Klensin, J., “Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework,” August 2010.), the domainpart of a JID is a "domain name slot".