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.で定義されているプレゼンスとインスタントメッセージングのための共通プロファイル2ユニバーサルリソース識別子（URI）スキームを定義：インスタント受信ボックスは「イム」とプレゼンのための「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
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]。インスタント受信トレイとプレゼンティティのために「PRES」の「IM」：一般的な存在についてプロファイル（CPP）[2]、インスタントメッセージング（CPIM）[1]は2つのユニバーサルリソース識別子（URI）スキームを定義します。この文書では、ドメインネームサービス（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は、相互運用性の目的のために望ましい特性の数を有し、変形することなく中継することができます。
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サービスプロバイダが内部独自のプロトコルに標準インターネットプロトコルをマップする独自のドメインに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.
この文書で、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "推奨NOT"、 "MAY" 、および「OPTIONAL」[3] BCP 14、RFC 2119に記載されるように解釈されるべきであり、対応する実装の要求レベルを示します。
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]。その中で定義されているようなCLOSED、INSTANT INBOX、インスタントメッセージ、およびOPENなどの用語は同じ意味で使用されています。
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で使用される場合にのみ解決、完全修飾ドメイン名（FQDN）が許可されている（すなわち、SRVに解決することができるドメイン名[7]またはリソースレコード（RR））。
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レコードのサービスの分野で使用されるシンボル名は、インスタントメッセージングとプレゼンスのための「_pres」の「_im」（それぞれの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行われます。先INSTANT INBOXは「イム：fred@example.com」であれば、送信者は、（IMサービスのための有効なプロトコルラベルとIANAに登録されていたと仮定「_bip」と）「BIP」と呼ばれるIM転送プロトコルを使用したいです、その後、SRVルックアップがために実行されます。
_im._bip.example.com.
＿いｍ。＿びｐ。えぁｍｐぇ。こｍ。
The same procedure is used for PRES URIs, with the "_pres" Service label.
同じ手順が「_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 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.
一の以上のSRV RRのは、特定のドメインのために発見された場合、送信者は、彼らがSRVのRRを使用して配置されていない限り、そのドメインに関連するすべてのAのRRを利用してはなりません。何SRV資源レコードが見つからないが、A RRが見つかった場合、それがそのドメインを指し、0の嗜好と、暗黙のSRV RRと関連していたかのように、その後、A RRが治療されます。
The returned DNS RRs, if any, specify the next-hop server, which may be a protocol gateway or an endpoint.
返されるDNS RRは、もしあれば、プロトコルゲートウェイまたはエンドポイントとすることができる、次ホップのサーバを指定します。
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レコードの優先度と重みフィールドを処理するための[7] RFC 2782で標準的な手順に従わなければなりません。
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".
インスタントメッセージングSRVプロトコルラベルレジストリおよびプレゼンスSRVプロトコルラベルレジストリ：「_im」と「_pres」とそれぞれの基本的なサービス間の関連付けが決定論的であることを確実にするために、IANAは、2つの独立したレジストリを作成しました。各レジストリについて、エントリはラベル名とラベルで指定されたプロトコルはSRVを使用する方法を記述した仕様へのポインタで構成されなければなりません。仕様は、「要求仕様」のために[8] RFC 2434に記載されている要件に適合しなければなりません。
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.
デイブ・クロッカーはこのドキュメントの以前のバージョンを編集しました。
The following individuals made substantial textual contributions to this document:
以下の個人は、この文書にかなりのテキストの貢献をしました。
Athanassios Diacakis (thanos.diacakis@openwave.com)
Athanassios Diacakis（thanos.diacakis@openwave.com）
Florencio Mazzoldi (flo@networkprojects.com)
がflorencio Mazzoldi（flo@networkprojects.com）
Christian Huitema (huitema@microsoft.com)
クリスチャン・ハイテマ（huitema@microsoft.com）
Graham Klyne (gk@ninebynine.org)
グラハムKlyne（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)
ひろやす すがの （すが＠ｆぁｂ。ふじつ。こ。ｊｐ）
[1] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[1]ピーターソン、J.、RFC 3860、2004年8月 "インスタントメッセージング（CPIM）のための共通プロファイル"。
[2] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[2]ピーターソン、J.、RFC 3859、2004年8月、 "共通プロファイルプレゼンス（CPP）のために"。
[3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、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]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
[6] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[6日目、M.、アガルワル、S.、およびJ.ヴィンセント、 "インスタントメッセージング/プレゼンスプロトコル要件"、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
ジョンピーターソンNeuStar、Inc.の1800サッターセントスイート570コンコード、CA 94520米国
Phone: +1 925/363-8720 EMail: jon.peterson@neustar.biz
電話：+1 925/363から8720 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。