Independent Submission P. Saint-Andre
Request for Comments: 7259 &yet
Category: Informational May 2014
ISSN: 2070-1721
Independent Submission P. Saint-Andre
Request for Comments: 7259 &yet
Category: Informational May 2014
ISSN: 2070-1721
The Jabber-ID Header Field
Jabber ID头字段
Abstract
摘要
This document defines a header field that enables the author of an email or netnews message to include a Jabber ID in the message header block for the purpose of associating the author with a particular Extensible Messaging and Presence Protocol (XMPP) address.
本文档定义了一个标题字段，该字段允许电子邮件或netnews消息的作者在消息标题块中包含Jabber ID，以便将作者与特定的可扩展消息和状态协议（XMPP）地址关联。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
这是对RFC系列的贡献，独立于任何其他RFC流。RFC编辑器已选择自行发布此文档，并且未声明其对实现或部署的价值。RFC编辑批准发布的文件不适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7259.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7259.
Copyright Notice
版权公告
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Inclusion . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Generation . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Processing . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Disposition . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security and Privacy Considerations . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Inclusion . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Generation . . . . . . . . . . . . . . . . . . . . . . . 3
3.3. Processing . . . . . . . . . . . . . . . . . . . . . . . 4
3.4. Disposition . . . . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Security and Privacy Considerations . . . . . . . . . . . . . 5
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Normative References . . . . . . . . . . . . . . . . . . 5
6.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7
The Extensible Messaging and Presence Protocol (XMPP), documented in [RFC6120], is a streaming XML technology that enables any two entities on a network to exchange well-defined but extensible XML elements (called "XML stanzas") in close to real time. Given XMPP's heritage in the Jabber open-source community, one of the primary uses for XMPP is instant messaging and presence as documented in [RFC6121], and XMPP addresses are still referred to as Jabber IDs.
[RFC6120]中记录的可扩展消息和状态协议（XMPP）是一种流式XML技术，它使网络上的任何两个实体能够近实时地交换定义良好但可扩展的XML元素（称为“XML节”）。鉴于XMPP在Jabber开源社区的传统，XMPP的主要用途之一是即时消息和状态，如[RFC6121]中所述，XMPP地址仍被称为Jabber ID。
Because almost all human users of Jabber/XMPP instant messaging and presence systems also use email systems [RFC5322] and because many also use netnews systems [RFC5536], it can be helpful for them to associate their Jabber IDs with the messages they author. The Jabber-ID header field provides a standard location for that information.
由于Jabber/XMPP即时消息和状态系统的几乎所有人类用户也使用电子邮件系统[RFC5322]，而且许多人也使用netnews系统[RFC5536]，因此将Jabber ID与他们编写的消息相关联可能会对他们有所帮助。Jabber ID标头字段为该信息提供了一个标准位置。
Members of the XMPP instant messaging and presence community have been experimenting with the Jabber-ID header field for many years. This document defines the syntax and usage of the Jabber-ID header field, including the information necessary to register the field in the Provisional Message Header Field Names registry maintained by the IANA.
XMPP即时消息和状态社区的成员多年来一直在试验Jabber ID头字段。本文档定义了Jabber ID标头字段的语法和用法，包括在IANA维护的临时消息标头字段名称注册表中注册该字段所需的信息。
The syntax of the Jabber-ID header field is defined below using Augmented Backus-Naur Form [RFC5234], where the "pathxmpp" rule is defined in the XMPP URI specification [RFC5122] and the remaining rules are defined in the Internet Message Format specification [RFC5322]:
Jabber ID头字段的语法如下所示，使用扩展的Backus Naur表单[RFC5234]定义，其中“pathxmpp”规则在XMPP URI规范[RFC5122]中定义，其余规则在互联网消息格式规范[RFC5322]中定义：
Jabber-ID = SP *WSP pathxmpp *WSP CRLF
Jabber-ID = SP *WSP pathxmpp *WSP CRLF
Although a native XMPP address can contain virtually any Unicode character [UNICODE], the header of an email or netnews message is allowed to contain only printable ASCII characters (see Section 2 of [RFC5322]). Therefore, any characters outside the ASCII range [RFC20] in an XMPP address need to be converted to ASCII before inclusion in a Jabber-ID header field, in accordance with the rules defined in the XMPP URI specification [RFC5122]. In addition, characters allowed in XMPP localparts and XMPP resourceparts but disallowed by the relevant URI rules need to be percent-encoded in accordance with the rules defined in the URI specification [RFC3986].
尽管本机XMPP地址几乎可以包含任何Unicode字符[Unicode]，但电子邮件或netnews消息的标题仅允许包含可打印的ASCII字符（请参阅[RFC5322]第2节）。因此，根据XMPP URI规范[RFC5122]中定义的规则，XMPP地址中ASCII范围[RFC20]之外的任何字符在包含在Jabber ID头字段中之前都需要转换为ASCII。此外，XMPP localparts和XMPP resourceparts中允许但相关URI规则不允许的字符需要按照URI规范[RFC3986]中定义的规则进行百分比编码。
The Jabber-ID header field is associated with the author of the message; see [RFC5322]. If the "From:" header field of an email message contains more than one mailbox, it is best not to add the Jabber-ID header field to the message. To reduce the possibility of confusion, it is best to include only one instance of the Jabber-ID header field in a given message.
Jabber ID标头字段与消息的作者关联；参见[RFC5322]。如果电子邮件的“发件人：”标题字段包含多个邮箱，最好不要将Jabber ID标题字段添加到邮件中。为了减少混淆的可能性，最好在给定消息中只包含Jabber ID头字段的一个实例。
For a user whose XMPP address is "juliet@example.com", the corresponding Jabber-ID header field would be:
对于XMPP地址为“”的用户juliet@example.com“，相应的Jabber ID标头字段为：
Jabber-ID: juliet@example.com
Jabber ID:juliet@example.com
As noted, non-ASCII characters in XMPP addresses need to be converted into ASCII before inclusion in a Jabber-ID header field. Consider the following XMPP address:
如前所述，XMPP地址中的非ASCII字符在包含在Jabber ID头字段中之前需要转换为ASCII。考虑下面的XMPP地址：
jiři@čechy.example
jiři@čechy.example
In the foregoing example, the string "ř" stands for the Unicode character LATIN SMALL LETTER R WITH CARON and the string "č" stands for the Unicode character LATIN SMALL LETTER C WITH CARON,
在前面的示例中，字符串“ř；”表示带CARON的Unicode字符拉丁小写字母R，字符串“č；”表示带CARON的Unicode字符拉丁小写字母C，
following the "XML Notation" used in [RFC3987] to represent characters that cannot be rendered in ASCII-only documents. For those who do not read Czech, this example could be anglicized as "george@czech-lands.example".
遵循[RFC3987]中使用的“XML表示法”，表示仅在ASCII文档中无法呈现的字符。对于那些不懂捷克语的人来说，这个例子可以被英语化为“george@czech-土地，例如”。
Following the rules in [RFC5122] and the Jabber-ID header field syntax, the resulting header field might be as shown below (note that this representation includes folding white space, which is allowed in accordance with the ABNF):
按照[RFC5122]中的规则和Jabber ID标头字段语法，生成的标头字段可能如下所示（注意，此表示包括折叠空格，这是根据ABNF允许的）：
Jabber-ID: ji%C5%99i@%C4%8Dechy.example
Jabber ID:ji%C5%99i@%C4%8Dechy.example
Upon receiving an email message or netnews message containing a Jabber-ID header field, a user agent that supports the field ought to process the field by converting any escaped characters to characters outside the ASCII range in accordance with the rules defined in [RFC5122], thus yielding a Jabber ID that can be used for native communication on the XMPP network.
在收到包含Jabber ID标头字段的电子邮件或netnews消息后，支持该字段的用户代理应根据[RFC5122]中定义的规则，通过将任何转义字符转换为ASCII范围以外的字符来处理该字段，从而产生一个Jabber ID，可用于XMPP网络上的本机通信。
A user agent that has processed a Jabber-ID header field can provide appropriate interface elements if it has independent information linking the author of the email or netnews message with the specified Jabber ID (e.g., via a user-controlled address book or automated directory lookup). Such interface elements might include an indicator of "presence" (i.e., that the author is online and available for communication via XMPP) if the user is subscribed to the presence of the author, and an element that enables the user to send an instant message or initiate a text chat session with the author.
如果已处理Jabber ID标头字段的用户代理具有将电子邮件或netnews消息的作者与指定Jabber ID链接起来的独立信息（例如，通过用户控制的通讯簿或自动目录查找），则可以提供适当的接口元素。如果用户订阅了作者的存在，则此类界面元素可以包括“存在”的指示符（即，作者在线并且可通过XMPP进行通信），以及允许用户发送即时消息或发起与作者的文本聊天会话的元素。
The IANA has added "Jabber-ID" to the Provisional Message Header Field Names registry. The completed registration template follows.
IANA已将“Jabber ID”添加到临时消息头字段名称注册表中。完成的注册模板如下。
Header field name: Jabber-ID
标题字段名称：Jabber ID
Applicable protocol: mail, netnews
适用协议：邮件、网络新闻
Status: provisional
现状：临时
Author/Change controller Peter Saint-Andre <stpeter@jabber.org>
Author/Change controller Peter Saint-Andre <stpeter@jabber.org>
Specification document: RFC 7259
规范文件：RFC 7259
Related information: See RFC 6120
相关信息：见RFC 6120
Message headers are an existing standard and are designed to easily accommodate new types. Although the Jabber-ID header field could be forged, this problem is inherent in Internet email and netnews. However, because a forged Jabber-ID header field might break automated processing, applications are discouraged from depending on the Jabber-ID header field to indicate the authenticity of an email or netnews message, or the identity of its author or sender. Including the Jabber-ID header field among the signer header fields in DomainKeys Identified Mail (DKIM) can help to mitigate against forging of the header (see [RFC6376]).
消息头是一种现有的标准，设计用于方便地容纳新类型。虽然Jabber ID头字段可能是伪造的，但这是Internet电子邮件和netnews中固有的问题。但是，由于伪造的Jabber ID标头字段可能会中断自动处理，因此不鼓励应用程序依赖Jabber ID标头字段来指示电子邮件或netnews消息的真实性，或其作者或发件人的身份。在DomainKeys Identified Mail（DKIM）中的签名者标头字段中包含Jabber ID标头字段有助于减少标头伪造（请参见[RFC6376]）。
Advertising XMPP addresses in email or netnews headers might make it easier for malicious users to harvest XMPP addresses and therefore to send unsolicited bulk communications to the users or applications represented by those addresses. Providing such a binding between an email address and a Jabber ID can also increase the possibility of drawing a connection between different kinds of communications traffic for purposes of surveillance and other breaches of privacy. Care ought to be taken in balancing the benefits of open information exchange against the potential costs of security and privacy weaknesses. An email or netnews user agent that is capable of including the Jabber-ID header field in outgoing email or netnews messages needs to provide an option for its user to disable inclusion of the Jabber-ID header field generally, on a per-recipient basis, and on a per-message basis.
在电子邮件或netnews标题中公布XMPP地址可能会使恶意用户更容易获取XMPP地址，从而向这些地址所代表的用户或应用程序发送未经请求的批量通信。在电子邮件地址和Jabber ID之间提供这样的绑定还可以增加在不同类型的通信流量之间建立连接的可能性，以便进行监视和其他侵犯隐私的行为。在平衡开放信息交换的好处与安全和隐私弱点的潜在成本时，应当谨慎。能够在发出的电子邮件或netnews消息中包含Jabber ID标头字段的电子邮件或netnews用户代理需要为其用户提供一个选项，以禁止包含Jabber ID标头字段，该选项通常基于每个收件人和每条消息。
The security and privacy considerations discussed in [RFC3986], [RFC3987], [RFC5122], [RFC6120], and [RFC6121] also apply to the Jabber-ID message header.
[RFC3986]、[RFC3987]、[RFC5122]、[RFC6120]和[RFC6121]中讨论的安全和隐私注意事项也适用于Jabber ID消息头。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[RFC5122] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.
[RFC5122]Saint Andre，P.，“可扩展消息和状态协议（XMPP）的国际化资源标识符（IRI）和统一资源标识符（URI）”，RFC 5122，2008年2月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年10月。
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6120]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：核心”，RFC61202011年3月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 6.3", (Mountain View, CA: The Unicode Consortium, 2013. ISBN 978-1-936213-08-5), <http://www.unicode.org/versions/Unicode6.3.0/>.
[UNICODE]UNICODE联盟，“UNICODE标准，版本6.3”（加利福尼亚州山景城：UNICODE联盟，2013年，ISBN 978-1-936213-08-5）<http://www.unicode.org/versions/Unicode6.3.0/>.
[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20, October 1969.
[RFC20]Cerf，V.，“网络交换的ASCII格式”，RFC201969年10月。
[RFC5536] Murchison, K., Lindsey, C., and D. Kohn, "Netnews Article Format", RFC 5536, November 2009.
[RFC5536]Murchison，K.，Lindsey，C.，和D.Kohn，“网络新闻文章格式”，RFC5362009年11月。
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, March 2011.
[RFC6121]圣安德烈，P.，“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC61212011年3月。
[RFC6376] Crocker, D., Hansen, T., and M. Kucherawy, "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[RFC6376]Crocker，D.，Hansen，T.，和M.Kucherawy，“域密钥识别邮件（DKIM）签名”，RFC 63762011年9月。
Thanks to Dave Cridland, Stephen Farrell, Russ Housley, and Alexey Melnikov for their feedback.
感谢Dave Cridland、Stephen Farrell、Russ Housley和Alexey Melnikov的反馈。
Author's Address
作者地址
Peter Saint-Andre &yet
彼得·圣安德烈&还没有
EMail: ietf@stpeter.im
EMail: ietf@stpeter.im