Network Working Group J. Peterson
Request for Comments: 3861 NeuStar
Category: Standards Track August 2004
Network Working Group J. Peterson
Request for Comments: 3861 NeuStar
Category: Standards Track August 2004
Address Resolution for Instant Messaging and Presence
即时消息和状态的地址解析
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
Presence and instant messaging are defined in RFC 2778. The Common Profiles for Presence and Instant Messaging define two Universal Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes.
RFC 2778中定义了状态和即时消息。状态和即时消息的通用配置文件定义了两种通用资源标识符（URI）方案：即时收件箱的“im”和状态实体的“pres”。本文档提供了定位与使用这些方案的URI关联的资源的指南。
Table of Contents
目录
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Address Resolution. . . . . . . . . . . . . . . . . . . . . . . 3
4. Domain Name Lookup. . . . . . . . . . . . . . . . . . . . . . . 4
5. Processing SRV RRs. . . . . . . . . . . . . . . . . . . . . . . 4
6. Processing Multiple Addresses . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
9. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . . 6
10. Normative References. . . . . . . . . . . . . . . . . . . . . . 6
11. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 7
12. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 8
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Address Resolution. . . . . . . . . . . . . . . . . . . . . . . 3
4. Domain Name Lookup. . . . . . . . . . . . . . . . . . . . . . . 4
5. Processing SRV RRs. . . . . . . . . . . . . . . . . . . . . . . 4
6. Processing Multiple Addresses . . . . . . . . . . . . . . . . . 5
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
9. Contributors. . . . . . . . . . . . . . . . . . . . . . . . . . 6
10. Normative References. . . . . . . . . . . . . . . . . . . . . . 6
11. Author's Address. . . . . . . . . . . . . . . . . . . . . . . . 7
12. Full Copyright Statement. . . . . . . . . . . . . . . . . . . . 8
Presence and instant messaging are defined in RFC 2778 [5]. The Common Profiles for Presence (CPP) [2] and Instant Messaging (CPIM) [1] define two Universal Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides rules for locating the resources associated with URIs that employ these schemes via the Domain Name Service (DNS) [4]. These rules could no doubt be applied to the resolution of other URI schemes that are unrelated to instant messaging and presence.
RFC 2778[5]中定义了状态和即时消息。状态（CPP）[2]和即时消息（CPIM）[1]的通用配置文件定义了两种通用资源标识符（URI）方案：即时收件箱的“im”和状态实体的“pres”。本文档提供了通过域名服务（DNS）定位与采用这些方案的URI相关联的资源的规则[4]。这些规则无疑可以应用于与即时消息和状态无关的其他URI方案的解析。
CPIM and CPP both specify operations that have 'source' and 'destination' attributes. While only the semantics, not the syntax, of these attributes are defined by CPIM and CPP, many instant messaging and presence protocols today support the use of URIs to reflect the source and destination of their operations. The 'im' and 'pres' URI schemes allow such protocols to express the identities of the principals associated with a protocol exchange. When these operations pass through a CPIM or CPP gateway, these URIs could be relayed without modification, which has a number of desirable properties for the purposes of interoperability.
CPIM和CPP都指定具有“源”和“目标”属性的操作。虽然CPIM和CPP只定义了这些属性的语义，而不是语法，但如今许多即时消息和状态协议支持使用URI来反映其操作的源和目标。“im”和“pres”URI方案允许此类协议表示与协议交换相关联的主体的身份。当这些操作通过CPIM或CPP网关时，这些URI可以在不进行修改的情况下进行中继，为了互操作性的目的，这些URI具有许多理想的属性。
These URI schemes are also useful in cases where no CPIM/CPP gatewaying will occur. If a particular principal's endpoint supports multiple instant messaging applications, for example, then a domain that identifies that host might use the sort of DNS records described in this document to provide greater compatibility with clients that support only one instant messaging protocol. A client would look up the corresponding record to the supported protocol, and learn how to contact the endpoint for that protocol. The principal in this instance would use an IM URI as their canonical address.
这些URI方案在不会发生CPIM/CPP网关的情况下也很有用。例如，如果特定主体的端点支持多个即时消息应用程序，则标识该主机的域可能会使用本文档中描述的DNS记录类型，以提供与仅支持一个即时消息协议的客户端的更大兼容性。客户端将查找受支持协议的相应记录，并了解如何联系该协议的端点。此实例中的主体将使用IM URI作为其规范地址。
In some architectures, these URIs might also be used to locate a CPIM or CPP gateway that serves a particular domain. If a particular IM service provider wishes to operate CPIM/CPP gateways in its own domain that map standard Internet protocols to an internal proprietary protocol, that gateway could be identified by an IM URI. In that case, the DNS records used to dereference the IM URI would serve a purpose similar to that of Mail Exchange (MX) records.
在某些体系结构中，这些URI还可用于定位服务于特定域的CPIM或CPP网关。如果特定IM服务提供商希望在其自己的域中操作将标准Internet协议映射到内部专有协议的CPIM/CPP网关，则可以通过IM URI来标识该网关。在这种情况下，用于取消引用IM URI的DNS记录的用途与邮件交换（MX）记录类似。
The system described in this document relies on the use of DNS service (SRV) [7] records and address (A) records.
本文档中描述的系统依赖于DNS服务（SRV）[7]记录和地址（A）记录的使用。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [3] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照BCP 14、RFC 2119[3]中的描述进行解释，并指出合规实施的要求级别。
This memo makes use of the vocabulary defined in RFC 2778 [5]. Terms such as CLOSED, INSTANT INBOX, INSTANT MESSAGE, and OPEN are used in the same meaning as defined therein.
本备忘录使用了RFC 2778[5]中定义的词汇表。诸如“关闭”、“即时收件箱”、“即时消息”和“打开”等术语的含义与其中的定义相同。
A client determines the address of an appropriate system running a server, on behalf of the system referenced by the domain, by resolving the destination domain name that is part of the identifier to either an intermediate relay system or a final target system.
客户端通过将作为标识符一部分的目标域名解析为中间中继系统或最终目标系统，代表域引用的系统确定运行服务器的适当系统的地址。
Only resolvable, fully-qualified, domain names (FQDNs) are permitted when domain names are used in an Instant Messaging (IM) URI (i.e., domain names that can be resolved to SRV [7] or A Resource Record (RR)).
当在即时消息（IM）URI中使用域名（即，可解析为SRV[7]或资源记录（RR）的域名）时，仅允许解析、完全限定的域名（FQDN）。
The symbolic name used in the Service field of the SRV record is "_im" for instant messaging and "_pres" for presence (matching their respective URI schemes). However, the advertisement of these services in the DNS is incomplete if it does not include the protocol that will be used to instantiate the instant messaging or presence operations. Thus, the Protocol field of the SRV record contains an IANA-registered label corresponding to the underlying instant messaging or presence protocol being advertised (see Section 8 for more information on valid Protocol fields).
SRV记录的服务字段中使用的符号名为“_im”表示即时消息，而“_pres”表示存在（与各自的URI方案相匹配）。然而，如果DNS中的这些服务的广告不包括将用于实例化即时消息传递或存在操作的协议，则这些服务的广告是不完整的。因此，SRV记录的协议字段包含一个IANA注册标签，该标签对应于正在发布的底层即时消息或状态协议（有关有效协议字段的更多信息，请参阅第8节）。
Taking the IM URI as a concrete example, a lookup is performed for SRVs for the target domain, a desired service (using the "_im" Service label) and a desired IM transfer protocol. If the destination INSTANT INBOX is "im:fred@example.com", and the sender wishes to use an IM transfer protocol called "BIP" (and supposing "_bip" were registered with IANA as a valid Protocol label for the IM Service), then a SRV lookup is performed for:
以IM URI为具体示例，对目标域、所需服务（使用“_IM”服务标签）和所需IM传输协议的srv执行查找。如果目标即时收件箱为“im:fred@example.com，并且发送方希望使用名为“BIP”的IM传输协议（假设“_BIP”已在IANA注册为IM服务的有效协议标签），则对以下各项执行SRV查找：
_im._bip.example.com.
_im._bip.example.com。
The same procedure is used for PRES URIs, with the "_pres" Service label.
相同的过程用于带有“\u PRES”服务标签的PRES URI。
Some clients may support multiple instant messaging or presence protocols; in these cases they may make several such SRV queries, in an application-specific order, until they find one supported in common with the target domain.
一些客户端可能支持多个即时消息或状态协议；在这些情况下，他们可能会按照特定于应用程序的顺序进行几个这样的SRV查询，直到找到目标域共同支持的查询为止。
Once a client lexically identifies a domain to which instant messaging or presence operations will be delivered for processing, a DNS lookup MUST be performed to resolve the domain. The names MUST be fully-qualified domain names (FQDNs) -- mechanisms for inferring FQDNs from partial names or local aliases are a local matter.
一旦客户机在词汇上确定了将向其发送即时消息或状态操作以进行处理的域，则必须执行DNS查找以解析该域。名称必须是完全限定域名（FQDN）——从部分名称或本地别名推断FQDN的机制是本地事务。
The lookup first attempts to locate SRV RRs associated with the domain. If a canonical name (CNAME) RR is found instead, the resulting domain is processed as if it were the initial domain.
查找首先尝试查找与域关联的SRV RRs。如果找到了规范名称（CNAME）RR，则生成的域将作为初始域进行处理。
If one or more SRV RRs are found for a given domain, a sender MUST NOT utilize any A RRs associated with that domain unless they are located using the SRV RRs. If no SRV RRs are found, but an A RR is found, then the A RR is treated as if it was associated with an implicit SRV RR, with a preference of 0, pointing to that domain.
如果为给定域找到一个或多个SRV RRs，则发送方不得使用与该域关联的任何a RRs，除非它们使用SRV RRs定位。如果未找到SRV RR，但找到了A RR，则A RR将被视为与隐式SRV RR关联，首选项为0，指向该域。
The returned DNS RRs, if any, specify the next-hop server, which may be a protocol gateway or an endpoint.
返回的DNS RRs（如果有）指定下一跳服务器，该服务器可以是协议网关或端点。
Receiving systems that are registered for this DNS-based SRV resolution service list the transfer protocols by which they can be reached, either directly or through a translating gateway (using combinations of Service and Protocol labels as described above). The transfer-time choice of the IM transfer protocol to be used (and, therefore, to be resolved) is a local configuration option for each sending system.
注册用于此基于DNS的SRV解析服务的接收系统列出了可直接或通过转换网关（使用如上所述的服务和协议标签组合）访问它们的传输协议。要使用（因此，要解决）的IM传输协议的传输时间选择是每个发送系统的本地配置选项。
Using this mechanism, seamless routing of IM traffic is possible, regardless of whether a gateway is necessary for interoperation. To achieve this transparency, a separate RR for a gateway must be present for each transfer protocol and domain pair that it serves.
使用这种机制，IM流量的无缝路由是可能的，无论是否需要网关进行互操作。为了实现这种透明性，必须为网关服务的每个传输协议和域对提供网关的单独RR。
When the lookup succeeds, the mapping can result in a list of alternative delivery addresses rather than a single address, because of multiple SRV records. For reliable operations, the client MUST be able to try each of the relevant addresses in this list in order, until a delivery attempt succeeds. However, there MAY also be a configurable limit on the number of alternate addresses that can be tried. In any case, the client SHOULD try at least two addresses.
当查找成功时，由于存在多个SRV记录，映射可能会产生一个替代传递地址列表，而不是一个地址。为了实现可靠的操作，客户端必须能够按顺序尝试此列表中的每个相关地址，直到传递尝试成功为止。但是，对可以尝试的备用地址的数量也可能有一个可配置的限制。在任何情况下，客户端都应该尝试至少两个地址。
Resolvers must follow the standard procedures in RFC 2782 [7] for handling the priority and weight fields of SRV records.
解析程序必须遵循RFC 2782[7]中的标准程序来处理SRV记录的优先级和权重字段。
The usage of IM and PRES URIs, and the DNS procedures in this document, introduce no security considerations beyond those described in the requirements for instant messaging and presence ([6]) and the SRV specification ([7]).
IM和PRES URI的使用以及本文档中的DNS程序，除了即时消息和状态要求（[6]）和SRV规范（[7]）中所述的安全注意事项外，没有引入其他安全注意事项。
Subsequent registrations of Protocol labels for use with the "_im" or "_pres" Service labels MUST, however, explain any security considerations that arise from the use of the protocol in question with SRV.
但是，与“_-im”或“_-pres”服务标签一起使用的协议标签的后续注册必须解释在SRV中使用相关协议时产生的任何安全注意事项。
This document reserves the use of "_im" and "_pres" Service labels. Since these relate to a service which may pass messages over a number of different message transports, they must be associated with a specific instant messaging or presence service.
本文件保留使用“im”和“pres”服务标签的权利。由于这些与可能通过许多不同的消息传输传递消息的服务相关，因此它们必须与特定的即时消息或状态服务相关联。
In order to ensure that the association between "_im" and "_pres" and their respective underlying services are deterministic, the IANA has created two independent registries: the Instant Messaging SRV Protocol Label registry and the Presence SRV Protocol Label registry. For each registry, an entry shall consist of a label name and a pointer to a specification describing how the protocol named in the label uses SRV. Specifications should conform to the requirements listed in RFC 2434 [8] for "specification required".
为了确保“_im”和“_pres”及其各自的基础服务之间的关联具有确定性，IANA创建了两个独立的注册表：即时消息SRV协议标签注册表和状态SRV协议标签注册表。对于每个注册表，条目应包括标签名称和指向描述标签中命名的协议如何使用SRV的规范的指针。规范应符合RFC 2434[8]中列出的“所需规范”要求。
Protocol labels compliant with this specification MUST begin with the underscore character "_" and follow all other rules for SRV Protocol labels described in [7].
符合本规范的协议标签必须以下划线字符“389;”开头，并遵循[7]中描述的SRV协议标签的所有其他规则。
Dave Crocker edited earlier versions of this document.
Dave Crocker编辑了此文档的早期版本。
The following individuals made substantial textual contributions to this document:
以下个人对本文件做出了实质性的文字贡献：
Athanassios Diacakis (thanos.diacakis@openwave.com)
塔诺斯（塔诺斯）。diacakis@openwave.com)
Florencio Mazzoldi (flo@networkprojects.com)
弗洛伦西奥·马佐尔迪(flo@networkprojects.com)
Christian Huitema (huitema@microsoft.com)
克里斯蒂安·惠特马(huitema@microsoft.com)
Graham Klyne (gk@ninebynine.org)
格雷厄姆·克莱恩(gk@ninebynine.org)
Jonathan Rosenberg (jdrosen@dynamicsoft.com)
乔纳森·罗森伯格(jdrosen@dynamicsoft.com)
Robert Sparks (rsparks@dynamicsoft.com)
罗伯特·斯帕克斯(rsparks@dynamicsoft.com)
Hiroyasu Sugano (suga@flab.fujitsu.co.jp)
杉野裕康(suga@flab.fujitsu.co.jp)
[1] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[1] 彼得森，J.，“即时通讯（CPIM）的通用配置文件”，RFC3860，2004年8月。
[2] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[2] 彼得森，J.，“在场的共同概况（CPP）”，RFC 3859，2004年8月。
[3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[4] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[5] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[5] Day，M.，Rosenberg，J.，和H.Sugano，“状态和即时信息模型”，RFC 27782000年2月。
[6] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[6] Day，M.，Aggarwal，S.，和J.Vincent，“即时消息传递/存在协议要求”，RFC 27792000年2月。
[7] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for Specifying the Location of Services (SRV)", RFC 2782, February 2000.
[7] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（SRV）的DNS RR”，RFC 2782，2000年2月。
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434, BCP 26, October 1998.
[8] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，RFC 2434，BCP 26，1998年10月。
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 US
美国加利福尼亚州康科德市萨特街1800号570室Jon Peterson NeuStar，Inc.94520
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。