[要約] RFC 3861は、インスタントメッセージングとプレゼンスのためのアドレス解決に関する規格です。その目的は、インスタントメッセージングやプレゼンスシステムでのアドレス解決の問題を解決し、相互運用性を向上させることです。
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）The Internet Society（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で定義されています。存在とインスタントメッセージングの共通プロファイルは、2つのユニバーサルリソース識別子（URI）スキームを定義します。このドキュメントは、これらのスキームを使用する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
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]の共通プロファイルは、2つのユニバーサルリソース識別子（URI）スキームを定義します。このドキュメントは、ドメイン名サービス（DNS）[4]を介してこれらのスキームを使用するURIに関連するリソースを見つけるためのルールを提供します。これらのルールは、インスタントメッセージングと存在とは無関係の他の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によって定義されていますが、今日の多くのインスタントメッセージングと存在プロトコルは、操作のソースと目的地を反映するためのURISの使用をサポートしています。「IM」および「Pres」URIスキームにより、このようなプロトコルは、プロトコル交換に関連するプリンシパルのアイデンティティを表現できます。これらの操作がCPIMまたはCPPゲートウェイを通過すると、これらの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レコードの種類を使用して、1つのインスタントメッセージングプロトコルのみをサポートするクライアントとのより大きな互換性を提供する可能性があります。クライアントは、サポートされているプロトコルに対応するレコードを検索し、そのプロトコルのエンドポイントに連絡する方法を学びます。この例の校長は、標準的なアドレスとして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サービスプロバイダーが、標準のインターネットプロトコルを内部専有プロトコルにマッピングする独自のドメインでCPIM/CPPゲートウェイを操作したい場合、そのゲートウェイはIM URIによって識別できます。その場合、Im uriを控除するために使用されたDNSレコードは、Mail Exchange（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.
このドキュメントでは、キーワードが「必要はない」、「必須」、「「必要」」、「しなければ」、「そうしない」、「そうはならない」、「そうでない」、「推奨」、「推奨」、「5月」、および「オプション」は、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）（RR）に解決できるドメイン名）で使用される場合、解決可能で完全に適格なドメイン名（FQDNS）のみが許可されます。
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を具体的な例として、ターゲットドメインのSRV、目的のサービス（「_IM」サービスラベルを使用）、および目的のIM転送プロトコルのルックアップが実行されます。宛先インスタント受信トレイが「im：fred@example.com」であり、送信者が「bip」と呼ばれるIM転送プロトコルを使用することを希望する場合（および「_BIP」はIMサービスの有効なプロトコルラベルとしてIANAに登録されています）、次に、SRVルックアップが実行されます。
_im._bip.example.com.
_im._bip.example.com。
The same procedure is used for PRES URIs, with the "_pres" Service label.
同じ手順は、「_pres」サービスラベルを使用して、pres urisに使用されます。
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ルックアップを実行する必要があります。名前は完全に適格なドメイン名（FQDNS）である必要があります - 部分名またはローカルエイリアスから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 RRを見つけようとします。代わりに標準名（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.
特定のドメインに対して1つ以上のSRV RRが見つかった場合、送信者は、SRV RRSを使用して配置されていない限り、そのドメインに関連付けられたRRを使用してはなりません。SRV RRが見つからないが、A RRが見つかった場合、A RRは、そのドメインを指して、0の優先順位を持つ暗黙のSRV RRに関連付けられているかのように扱われます。
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レコードのため、単一のアドレスではなく代替配信アドレスのリストになる可能性があります。信頼できる操作のために、クライアントは、配達の試みが成功するまで、このリストの関連する各アドレスを順番に試すことができる必要があります。ただし、試行可能な代替アドレスの数に構成可能な制限もある場合があります。いずれにせよ、クライアントは少なくとも2つのアドレスを試す必要があります。
Resolvers must follow the standard procedures in RFC 2782 [7] for handling the priority and weight fields of SRV records.
リゾルバーは、SRVレコードの優先フィールドと重量フィールドを処理するために、RFC 2782 [7]の標準手順に従う必要があります。
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は2つの独立したレジストリを作成しました。各レジストリについて、エントリは、ラベル名とラベルで指定されたプロトコルが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].
この仕様に準拠したプロトコルラベルは、アンダースコア文字「_」から始まり、[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)
athanassios diacakis（sanos.diacakis@openwave.com）
Florencio Mazzoldi (flo@networkprojects.com)
Florencio Mazzoldi（flo@networkprojects.com）
Christian Huitema (huitema@microsoft.com)
ChristianHuitema（huitema@microsoft.com）
Graham Klyne (gk@ninebynine.org)
Graham Klyne（gk@ninebynine.org）
Jonathan Rosenberg (jdrosen@dynamicsoft.com)
Jonathan Rosenberg（jdrosen@dynamicsoft.com）
Robert Sparks (rsparks@dynamicsoft.com)
ロバートスパークス（rsparks@dynamicsoft.com）
Hiroyasu Sugano (suga@flab.fujitsu.co.jp)
Hiroyasu sugano（suga@flab.fujitsu.co.jp）
[1] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[1] ピーターソン、J。、「インスタントメッセージングの共通プロファイル（CPIM）」、RFC 3860、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 2778、2000年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 2779、2000年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
Jon Peterson Neustar、Inc。1800 Sutter St Suite 570 Concord、CA 94520 US
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）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンライン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-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。