RFC3861 日本語訳

Network Working Group                                        J. Peterson
Request for Comments: 3861                                       NeuStar
Category: Standards Track                                    August 2004

コメントを求めるワーキンググループJ.ピーターソン要求をネットワークでつないでください: 3861年のNeuStarカテゴリ: 標準化過程2004年8月

         Address Resolution for Instant Messaging and Presence

インスタントメッセージングと存在のためのアドレス解決

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2004).

Copyright(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.

存在とインスタントメッセージングはRFC2778で定義されます。 PresenceとInstant MessagingのためのCommon Profilesは2Universal Resource Identifier(URI)体系を定義します: '、不-、'PRESENTITIESのための即時の受信トレイと'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. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. 用語. . . . . . . . . . . . . . . . . . . . . . . . . . 3 3。 解決を扱ってください。 . . . . . . . . . . . . . . . . . . . . . . 3 4. ドメイン名ルックアップ。 . . . . . . . . . . . . . . . . . . . . . . 4 5. SRV RRsを処理します。 . . . . . . . . . . . . . . . . . . . . . . 4 6. 処理倍数は.5 7を扱います。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 5 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 5 9。 貢献者。 . . . . . . . . . . . . . . . . . . . . . . . . . 6 10. 引用規格。 . . . . . . . . . . . . . . . . . . . . . 6 11. 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . . 7 12. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . 8

Peterson                    Standards Track                     [Page 1]

RFC 3861                        IM&P SRV                     August 2004

ピーターソンStandardsがRFC3861を追跡する、[1ページ]不-、P SRV2004年8月

1.  Introduction

1. 序論

   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.

存在とインスタントメッセージングはRFC2778[5]で定義されます。 Presence(CPP)[2]とInstant Messaging(CPIM)[1]のためのCommon Profilesは2Universal Resource Identifier(URI)体系を定義します: '、不-、'PRESENTITIESのための即時の受信トレイと'pres'のために。 このドキュメントはDomain Name Service(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によって定義されないで、多くのインスタントメッセージングと存在プロトコルが、今日、彼らの操作のソースと目的地を反映するためにURIの使用をサポートします。 '不-''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 gatewayingも起こらない場合で役に立ちます。 例えば、特定の主体の終点が、複数のインスタントメッセージングがアプリケーションであるとサポートするなら、そのホストを特定するドメインは1つのインスタントメッセージングプロトコルだけをサポートするクライアントをより大きい互換性に提供するために本書では説明された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記録はメール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)記録の使用に依存します。

Peterson                    Standards Track                     [Page 2]

RFC 3861                        IM&P SRV                     August 2004

ピーターソンStandardsがRFC3861を追跡する、[2ページ]不-、P SRV2004年8月

2.  Terminology

2. 用語

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「お勧めでなく」て「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[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.

このメモはRFC2778[5]で定義されたボキャブラリーを利用します。 CLOSEDや、INSTANT INBOXや、INSTANT MESSAGEや、オープンなどの諸条件はそこに定義されるのと同じ意味で使用されます。

3.  Address Resolution

3. アドレス解決

   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)).

ドメイン名がInstant Messaging(IM)URI(すなわち、SRV[7]かA Resource Record(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).

」 インスタントメッセージングと_はpresされます。「SRV記録のService分野で使用される英字名はそうです」_、不-、」、」 存在(それらのそれぞれの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をみなして、ルックアップはSRVsのためにターゲット・ドメインに実行されます、必要なサービス、(使用、」 _、不-、」 Serviceラベル) そして、必要なIM転送プロトコル。 「目的地INSTANT受信トレイがそうである、「不-、: 」 送付者がIM転送プロトコルを使用したがっている fred@example.com が、"BIP"と呼んだ、(」 _がbipであると思う、」、ともに記名されて、a有効であるとしてのIANAが不-サービスのためにラベルについて議定書の中で述べるということであった、)、そして、SRVルックアップは以下のために実行されます。

   _im._bip.example.com.

_、不-. _bip.example.com。

   The same procedure is used for PRES URIs, with the "_pres" Service
   label.

「同じ手順がPRES URIに用いられる、」 _」 Serviceがラベルするpres。

Peterson                    Standards Track                     [Page 3]

RFC 3861                        IM&P SRV                     August 2004

ピーターソンStandardsがRFC3861を追跡する、[3ページ]不-、P SRV2004年8月

   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質問をするかもしれません、アプリケーション特有のオーダーで、彼らがターゲット・ドメインと共用してサポートされたものを見つけるまで。

4.  Domain Name Lookup

4. ドメイン名ルックアップ

   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)--部分的な名前かローカルの別名からFQDNsを推論するためのメカニズムは地域にかかわる事柄です。

   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.

1SRV RRsが与えられたドメインに見つけられて、彼らがSRV RRsを使用することで見つけられていない場合、送付者はそのドメインに関連している少しのA RRsも利用してはいけません。 SRV RRsが全く見つけられませんが、A RRが見つけられるなら、まるでそれが内在しているSRV RRに関連しているかのようにA RRは扱われます、0の優先で、そのドメインを示して。

5.  Processing SRV RRs

5. 処理SRV RRs

   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解決サービスのために登録される受電方式はそれらに直接か翻訳ゲートウェイを通して達することができる転送プロトコルを記載します(上で説明されるようにServiceとプロトコルラベルの組み合わせを使用して)。 使用されるべき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.

このメカニズムを使用して、ゲートウェイがinteroperationに必要であるかどうかにかかわらずIMトラフィックのシームレスのルーティングは可能です。 この透明を達成するために、ゲートウェイへの別々のRRはそれが役立つそれぞれの転送プロトコルとドメイン組のために存在していなければなりません。

Peterson                    Standards Track                     [Page 4]

RFC 3861                        IM&P SRV                     August 2004

ピーターソンStandardsがRFC3861を追跡する、[4ページ]不-、P SRV2004年8月

6.  Processing Multiple Addresses

6. 複数のアドレスを処理します。

   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記録のために。 信頼できる操作において、クライアントはこのリストのオーダーにおける、それぞれの関連アドレスを試みることができなければなりません、配送試みが成功するまで。 しかしながら、また、構成可能な限界が試みることができる代替アドレスの数にあるかもしれません。 どのような場合でも、クライアントSHOULDは少なくとも2つのアドレスを試みます。

   Resolvers must follow the standard procedures in RFC 2782 [7] for
   handling the priority and weight fields of SRV records.

レゾルバは、優先権を扱うためのRFC2782[7]で標準手続きに従って、SRV記録の分野に重みを加えなければなりません。

7.  Security Considerations

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.

「プロトコルのその後の登録証明書が使用のためにラベルする、」 _、不-、」 」 _しかしながら、」 ServiceがラベルするpresはSRVと共に問題のプロトコルの使用から起こるどんなセキュリティ問題についても説明しなければなりません。

8.  IANA Considerations

8. IANA問題

   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.

「このドキュメントが」 _の使用を控える、不-、」 」 _」 Serviceがラベルする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".

「それを確実にする、」 _の間の協会、不-、」 」 _」 彼らがそれぞれの基本的さが調整するpresが決定論的である、IANAは2つの独立している登録を作成しました: Instant Messaging SRVプロトコルLabel登録とPresence SRVプロトコルLabel登録。 各登録に関しては、エントリーはラベルで指定されたプロトコルがどうSRVを使用するかを説明する仕様にラベル名と指針から成るものとします。 仕様は「仕様が必要である」RFC2434[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プロトコルラベルのために他のすべての規則に従わなければなりません。

Peterson                    Standards Track                     [Page 5]

RFC 3861                        IM&P SRV                     August 2004

ピーターソンStandardsがRFC3861を追跡する、[5ページ]不-、P SRV2004年8月

9.  Contributors

9. 貢献者

   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( 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)

菅野寛裕( suga@flab.fujitsu.co.jp )

10.  Normative References

10. 引用規格

   [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)のための一般的なプロフィール」、RFC3859、2004年8月。

   [3]  Bradner, S., "Key words for use in RFCs to indicate requirement
        levels", BCP 14, RFC 2119, March 1997.

[3] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。

   [4]  Mockapetris, P., "Domain Names - Concepts and Facilities", STD
        13, RFC 1034, November 1987.

[4]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

   [5]  Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and
        Instant Messaging", RFC 2778, February 2000.

2000年2月の[5] 日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。

   [6]  Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging /
        Presence Protocol Requirements", RFC 2779, February 2000.

[6] 日、M.とAggarwal、S.とJ.ヴィンセント、「インスタントメッセージング/存在プロトコル要件」、RFC2779、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、「サービスの位置を指定するためのDNS RR(SRV)」、RFC2782(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問題部に書くためのガイドライン」RFC2434、BCP26(1998年10月)。

Peterson                    Standards Track                     [Page 6]

RFC 3861                        IM&P SRV                     August 2004

ピーターソンStandardsがRFC3861を追跡する、[6ページ]不-、P SRV2004年8月

11.  Author's Address

11. 作者のアドレス

   Jon Peterson
   NeuStar, Inc.
   1800 Sutter St
   Suite 570
   Concord, CA  94520
   US

ジョンピーターソンNeuStar Inc.1800サター通りスイート570一致、カリフォルニア94520米国

   Phone: +1 925/363-8720
   EMail: jon.peterson@neustar.biz

以下に電話をしてください。 +1 925/363-8720 メールしてください: jon.peterson@neustar.biz

Peterson                    Standards Track                     [Page 7]

RFC 3861                        IM&P SRV                     August 2004

ピーターソンStandardsがRFC3861を追跡する、[7ページ]不-、P SRV2004年8月

12.  Full Copyright Statement

12. 完全な著作権宣言文

   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.

Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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機能のための基金は現在、インターネット協会によって提供されます。

Peterson                    Standards Track                     [Page 8]

ピーターソン標準化過程[8ページ]