RFC3832 日本語訳
3832 Remote Service Discovery in the Service Location Protocol (SLP)via DNS SRV. W. Zhao, H. Schulzrinne, E. Guttman, C. Bisdikian, W.Jerome. July 2004. (Format: TXT=15602 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group W. Zhao
Request for Comments: 3832 H. Schulzrinne
Category: Experimental Columbia University
E. Guttman
Sun Microsystems
C. Bisdikian
W. Jerome
IBM
July 2004
コメントを求めるワーキンググループW.チャオ要求をネットワークでつないでください: 3832時間Schulzrinneカテゴリ: 実験的なコロンビア大学のC.Bisdikian W.ジェロームIBM E.Guttmanサン・マイクロシステムズ2004年7月
Remote Service Discovery in the
Service Location Protocol (SLP) via DNS SRV
DNS SRVを通したService Locationプロトコル(SLP)のリモートServiceディスカバリー
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
Abstract
要約
Remote service discovery refers to discovering desired services in given remote (i.e., non-local) DNS domains. This document describes remote service discovery in the Service Location Protocol (SLP) via DNS SRV. It defines the DNS SRV Resource Records for SLP Directory Agent services, discusses various issues in using SLP and DNS SRV together for remote service discovery, and gives the steps for discovering desired services in remote DNS domains.
リモートサービス発見は遠く離れた(すなわち、非ローカルの)DNSドメインを考えて、中で必要なサービスを発見するのを示します。 このドキュメントはDNS SRVを通してService Locationプロトコル(SLP)におけるリモートサービス発見について説明します。 それは、SLPディレクトリエージェントサービスのためにDNS SRV Resource Recordsを定義して、リモートサービス発見のためにSLPとDNS SRVを一緒に使用する際に様々な問題について議論して、必要なサービスを発見するために遠く離れたDNSドメインでステップを与えます。
1. Introduction
1. 序論
This document describes remote service discovery in the Service Location Protocol (SLP) [RFC2608] via DNS SRV [RFC2782]. We consider remote service discovery as discovering desired services in given remote DNS domains, and local service discovery as discovering desired services within the local administrative domain.
このドキュメントはDNS SRV[RFC2782]を通してService Locationプロトコル(SLP)[RFC2608]でリモートサービス発見について説明します。 私たちは、リモートサービス発見を与えられた遠く離れたDNSドメインで必要なサービスを発見すると考えて、地方の管理ドメインの中で必要なサービスを発見するとしてローカル・サービス発見を考えます。
SLP provides a scalable framework for local service discovery and selection. In SLP, User Agents (UAs) discover desired services in the local administrative domain by querying all Service Agents (SAs) via multicast or querying a Directory Agent (DA) via unicast. To
SLPはローカル・サービス発見と選択にスケーラブルなフレームワークを提供します。 SLPでは、マルチキャストかユニキャストでディレクトリエージェント(DA)について質問することを通してUserエージェント(UAs)は、地方の管理ドメインですべてのServiceエージェント(SAs)について質問することによって、必要なサービスを発見します。 to
Zhao, et al. Experimental [Page 1] RFC 3832 Remote Discovery in SLP via DNS SRV July 2004
チャオ、他 DNS SRV2004年7月を通したSLPの実験的な[1ページ]RFC3832Remoteディスカバリー
query a DA using unicast, a UA needs to first learn about the DA via DHCP, static configuration or multicast (listening for DAAdvert multicast or issuing DA discovery SrvRqst multicast).
ユニキャストを使用することでDAについて質問してください、最初にへの必要性がDHCP、静的な構成またはマルチキャストを通したDAに関して学ぶUA(DAAdvertマルチキャストの聞こうとするか、またはDA発見SrvRqstマルチキャストを発行して)。
DNS SRV provides good support for remote service discovery. However, if multiple servers are discovered via DNS SRV for a service, only priority and weight can be used to make a selection. If additional service properties (such as cost, speed and service quality) need to be considered in the selection process, DNS SRV becomes insufficient.
DNS SRVはリモートサービス発見の良いサポートを提供します。 しかしながら、複数のサーバがサービスのためのDNS SRVを通して発見されるなら、選定するのに優先権と重りしか使用できません。 追加公共用財産(費用や、速度やサービス品質などの)が、選択プロセスで考えられる必要があるなら、DNS SRVは不十分になります。
We propose that using SLP and DNS SRV together can provide better support for remote service discovery. First, a UA uses DNS SRV to find SLP DAs at a remote DNS domain. Then, the UA uses SLP to query one of those DAs to discover desired services. In this way, we can avoid the limitations in using SLP and DNS SRV separately. On one hand, without DNS SRV, an SLP UA needs to depend on static configuration to learn about remote DAs because DHCP and multicast DA discovery are not generally applicable beyond the local administrative domain. On the other hand, without SLP, DNS SRV has limited support for service selection.
私たちは、SLPとDNS SRVを一緒に使用するとリモートサービス発見の、より良いサポートを提供できるよう提案します。 まず最初に、UAは、遠く離れたDNSドメインでSLP DAsを見つけるのにDNS SRVを使用します。 そして、UAは、必要なサービスを発見するためにそれらのDAsの1つについて質問するのにSLPを使用します。 このように、私たちは別々にSLPとDNS SRVを使用する際に制限を避けることができます。 一方では、DNS SRVがなければ、SLP UAは、DHCPとマルチキャストDA発見が一般に地方の管理ドメインを超えて適切でないのでリモートDAsに関して学ぶために静的な構成に依存する必要があります。 他方では、SLPがなければ、DNS SRVはサービス選択のサポートを制限しました。
In this document, we first define the DNS SRV Resource Records (RRs) for SLP DA services, which are used to map a given DNS domain to remotely accessible (i.e., accessible from the Internet) DAs in that domain. Then, we discuss various issues in using SLP and DNS SRV together for remote service discovery. Finally, we give the steps for discovering services in remote DNS domains.
本書では、私たちは最初に、SLP DAサービスのために、DNS SRV Resource Records(RRs)を定義します。(サービスは、そのドメインのほんの少しアクセスしやすい(すなわち、インターネットからアクセスしやすい)DAsに与えられたDNSドメインを写像するのに利用されます)。 そして、私たちはリモートサービス発見にSLPとDNS SRVを一緒に使用する際に様々な問題について議論します。 最終的に、私たちは遠く離れたDNSドメインでサービスを発見するためのステップを与えます。
1.1. Notation Conventions
1.1. 記法コンベンション
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
2. The DNS SRV RRs for SLP DA services
2. SLP DAサービスのためのDNS SRV RRs
According to RFC 2782 [RFC2782], the DNS SRV RRs for SLP DA services are defined as follows:
RFC2782[RFC2782]によると、SLP DAサービスのためのDNS SRV RRsは以下の通り定義されます:
_slpda._Proto.Name TTL Class SRV Priority Weight Port Target
_slpda_Proto.Name TTLクラスSRV優先権重さのポート目標
where "slpda" is the symbolic name for SLP DA services, the Proto field is either "tcp" or "udp", and the Target field is the domain name of an SLP DA. Please refer to [RFC2782] for detailed explanation of each field in DNS SRV RRs.
"slpda"がSLP DAサービスのための英字名であるところでは、プロト分野は、"tcp"か"udp"のどちらかです、そして、Target分野はSLP DAのドメイン名です。 DNS SRV RRsでのそれぞれの分野の詳説について[RFC2782]を参照してください。
Zhao, et al. Experimental [Page 2] RFC 3832 Remote Discovery in SLP via DNS SRV July 2004
チャオ、他 DNS SRV2004年7月を通したSLPの実験的な[2ページ]RFC3832Remoteディスカバリー
Next we show an example of using DNS SRV RRs to map a given DNS domain to remotely accessible DAs in that domain. To discover remotely accessible DAs in a remote domain (say, example.com), a UA makes a DNS query [RFC1034,RFC1035] for QNAME=_slpda._tcp.example.com (or QNAME=_slpda._udp.example.com), QCLASS=IN, and QTYPE=SRV. Then the UA will receive a list of DNS SRV RRs in a DNS reply, which gives all remotely accessible DAs in the domain example.com, such as:
次に、私たちはそのドメインのほんの少しアクセスしやすいDAsに与えられたDNSドメインを写像するのにDNS SRV RRsを使用する例を示しています。 UAは、遠く離れたドメイン(たとえば、example.com)でほんの少しアクセスしやすいDAsを発見するために、QNAME=_slpdaのためにDNS質問を[RFC1034、RFC1035]にします。_tcp.example.com(QNAMEは_slpda_udp.example.comと等しい)、QCLASSはIN、およびQTYPE=SRVと等しいです。 次に、UAはDNS回答でDNS SRV RRsのリストを受け取るでしょう、以下のように。(回答はドメインexample.comのすべてのほんの少しアクセスしやすいDAsに与えます)。
;; Priority Weight Port Target _slpda._tcp.example.com IN SRV 0 0 427 da1.example.com _slpda._tcp.example.com IN SRV 0 0 427 da2.example.com
;; 優先権Weight Port Target_slpda_tcp.example.com IN SRV0 0 427da1.example.com_slpda_tcp.example.com IN SRV0 0 427da2.example.com
3. Remote Service Discovery in SLP via DNS SRV
3. DNS SRVを通したSLPのリモートServiceディスカバリー
SLP DAs can be discovered in two ways: (1) using the mechanisms described in RFC 2608, and (2) using DNS SRV RRs as described in this document. The second approach is useful for UAs to acquire service information for remote DNS domains. For example, a mobile node visiting a network (without the use of mobile IP) may want to obtain information about services in its home network.
2つの方法でSLP DAsを発見できます: (1) RFC2608で説明されたメカニズム、および本書では説明されるようにDNS SRV RRsを使用する(2)を使用します。 UAsが遠く離れたDNSドメインのためのサービス情報を取得するように、2番目のアプローチは役に立ちます。 例えば、ネットワーク(モバイルIPの使用のない)を訪問するモバイルノードはホームネットワークにおけるサービスの情報を得たがっているかもしれません。
3.1. The DNS Domain of Interest for Remote Service Discovery
3.1. リモートサービス発見のための興味があるDNSドメイン
Using DNS SRV RRs to discover SLP DAs requires knowledge of the domain where SLP DAs are registered. For remote service discovery, it is assumed that the DNS domain of interest is known via a priori knowledge. For example, a UA is configured with a domain name or the user provides the domain name manually.
SLP DAsを発見するのにDNS SRV RRsを使用するのはSLP DAsが登録されているドメインに関する知識を必要とします。 リモートサービス発見において、興味があるDNSドメインが先験的な知識で知られていると思われます。 例えば、UAがドメイン名によって構成されるか、またはユーザは手動でドメイン名を提供します。
Note that there is no implied "search order" of DNS domains in finding remote DAs. For instance, if a UA is looking for remote DAs in the domain foo.bar.example.com, it SHOULD only look for _slp._tcp.foo.bar.example.com (or _slp._udp.foo.bar.example.com), and MUST NOT fall back to look for _slp._tcp.bar.example.com, _slp._tcp.example.com, and so on.
リモートDAsを見つけることにおける、DNSドメインのどんな暗示している「検索命令」もないことに注意してください。 UAはドメインfoo.bar.example.comでリモートDAsを探していて、それはSHOULDです。例えば、_slp_tcp.foo.bar.example.com(_slp_または、udp.foo.bar.example.com)を探すだけであり、_slp_tcp.bar.example.com、_slp_tcp.example.comなどを探すために後ろへ下がってはいけません。
3.2. SLP DAs for Remote Service Discovery
3.2. リモートサービス発見のためのSLP DAs
A UA discovers desired services in a given remote DNS domain by unicasting requests to DAs in that domain. The UA uses remote DAs according to these prioritized rules: (1) using DAs which it has been configured with, and (2) using DAs which it has discovered via DNS SRV.
UAは、与えられた遠く離れたDNSドメインでそのドメインのDAsに要求をunicastingすることによって、必要なサービスを発見します。 これらに従ったUA用途のリモートDAsは規則を最優先させました: (1) それが構成されたDAs、およびDAsを使用するそれがDNS SRVを通して発見した(2)を使用します。
Zhao, et al. Experimental [Page 3] RFC 3832 Remote Discovery in SLP via DNS SRV July 2004
チャオ、他 DNS SRV2004年7月を通したSLPの実験的な[3ページ]RFC3832Remoteディスカバリー
3.3. SLP Scopes for Remote Service Discovery
3.3. SLPはリモートサービス発見に関して見ます。
As SLP scopes are intended to be used only within one administrative domain, they are likely incomprehensible to users outside of the administrative domain. Thus, any remotely accessible service MUST be registered in the "default" scope, but it MAY be registered in other scopes at the same time. Similarly, all DAs advertised via DNS SRV MUST serve the "default" scope, but they MAY serve other scopes at the same time. As a result, users wishing to discover services at a remote DNS domain SHOULD only search the "default" scope.
1つの管理ドメインだけの中でSLP範囲が使用されることを意図するとき、それらは管理ドメインにおいて外部のユーザにとって不可解な状態で傾向があります。 したがって、「デフォルト」範囲にどんなほんの少しアクセスしやすいサービスも登録しなければなりませんが、それは同時に、他の範囲に登録されるかもしれません。 同様に、DNS SRV MUSTを通しての広告に掲載されたすべてのDAsが「デフォルト」範囲に役立ちますが、彼らは同時に、他の範囲に役立つかもしれません。 結果、遠く離れたDNSドメインでサービスを発見したがっているユーザとして、SHOULDは「デフォルト」範囲を捜すだけです。
4. Steps for Remote Service Discovery
4. リモートサービス発見のためのステップ
The steps for a User Agent U to discover desired services in a remote DNS domain D are as follows.
発見するUserエージェントUが遠く離れたDNSドメインDでサービスを望んでいたので、ステップは以下の通りです。
(1) U makes a DNS query for QNAME=_slpda._tcp.D (or
QNAME=_slpda._udp.D), QCLASS=IN, and QTYPE=SRV. Then, U gets a
list of DNS SRV RRs (referred to as L) in a DNS reply, which
gives all remotely accessible DAs in D.
(1) UはQNAME=_slpda_のためのDNS質問をtcp.D(QNAMEは_slpda_udp.Dと等しい)、QCLASS=INとQTYPE=SRVにします。 そして、UはDNS回答でDNS SRV RRs(Lと呼ばれる)のリストを得ます。(それは、Dですべてのほんの少しアクセスしやすいDAsに与えます)。
(2) U selects a DA X from L based on the priority and weight
information per RFC 2782.
(2) UはRFC2782あたりの優先権と重さの情報に基づくLからDA Xを選択します。
(3) U queries X in the "default" scope to discover desired services
in D.
(3) Uは、Dで必要なサービスを発見するために「デフォルト」範囲でXについて質問します。
Note that the services discovered in the above steps may not necessarily be remotely accessible.
上のステップで発見されたサービスが必ずほんの少しアクセスしやすいかもしれないというわけではないことに注意してください。
5. Security Considerations
5. セキュリティ問題
To support remote service discovery, a domain exposes its service information to the Internet. Standard SLP authentication SHOULD be used to protect valuable service information. First, there is a risk that any SA could advertise any service on a DA accessible from the Internet. Such a DA SHOULD reject all registrations and deregistrations that cannot be authenticated. Secondly, to avoid disclosing unintended service information to remote users, a DA accessible from the Internet SHOULD at least authenticate service queries that are not in the "default" scope. In addition, the security considerations for DNS SRV [RFC2782] apply to this document. Also, the DNS security extensions [RFC 2535] SHOULD be used to provide origin authentication and integrity protection for DNS data.
リモートサービスが発見であるとサポートするために、ドメインは、サービスが情報であるとインターネットに暴露します。 標準のSLP認証SHOULD、使用されて、貴重なサービス情報を保護してください。 まず最初に、どんなSAもどんなサービスもa DAアクセスしやすい状態で広告を出すことができたリスクはインターネットから来ています。 認証できないそのようなDA SHOULD廃棄物のすべての登録証明書と「反-登録証明書」。 第二に、リモート・ユーザー、インターネットからアクセスしやすいDAに故意でないサービス情報を明らかにするのを避けるために、SHOULDは「デフォルト」範囲にないサービス質問を少なくとも認証します。 さらに、DNS SRV[RFC2782]のためのセキュリティ問題はこのドキュメントに適用されます。 DNSセキュリティ拡大[RFC2535]SHOULD、も使用されて、DNSデータのための発生源認証と保全保護を提供してください。
Zhao, et al. Experimental [Page 4] RFC 3832 Remote Discovery in SLP via DNS SRV July 2004
チャオ、他 DNS SRV2004年7月を通したSLPの実験的な[4ページ]RFC3832Remoteディスカバリー
6. Applicability Statements
6. 適用性証明
This specification describes remote service discovery in SLP via DNS SRV. It facilitates discovering services at a remote DNS domain if the domain name is known via a priori knowledge. However, it does not intend to solve the problem of Internet-wide service discovery.
この仕様はDNS SRVを通してSLPでリモートサービス発見について説明します。 それは、ドメイン名が先験的な知識で知られているなら遠く離れたDNSドメインでサービスを発見するのを容易にします。 しかしながら、それはインターネット全体のサービス発見の問題を解決しないつもりです。
Users should be aware of two constraints in using DNS SRV to discover SLP DAs: (1) they SHOULD only use DNS SRV to discover DAs in the "default" scope, and (2) an administrator may choose to register only a subset of all DAs in the "default" scope via DNS SRV. Thus, to discover local DAs, implementations MUST use the standard SLP mechanisms per RFC 2608. In addition, implementations supporting this specification MAY use DNS SRV to discover local DAs in the "default" scope.
ユーザはSLP DAsを発見するというDNS SRVを使用することにおける2つの規制を意識しているべきです: (1) それら、(2) SHOULDは「デフォルト」範囲でDAsを発見するのにDNS SRVを使用するだけであり、管理者は、DNS SRVを通して「デフォルト」範囲のすべてのDAsの部分集合だけを登録するのを選ぶかもしれません。 したがって、地方のDAsを発見するために、実装はRFC2608あたりの標準のSLPメカニズムを使用しなければなりません。 さらに、この仕様をサポートする実装は、「デフォルト」範囲で地方のDAsを発見するのにDNS SRVを使用するかもしれません。
As SLP scopes are not intended to be used outside the local administrative domain, all remote service discovery in SLP SHOULD be carried only in the "default" scope.
地方の管理ドメイン、SLP SHOULDでのすべてのリモートサービス発見の外に使用されて、SLP範囲による意図しないように、「デフォルト」範囲だけで運ばれてください。
Note that the services discovered via DNS SRV and remote SLP DAs may not necessarily be remotely accessible.
DNS SRVとリモートSLP DAsを通して発見されたサービスが必ずほんの少しアクセスしやすいかもしれないというわけではないことに注意してください。
7. IANA Considerations
7. IANA問題
In the DNS SRV RRs for SLP DA services, the symbolic name for the Service field is "slpda", supported protocols are "tcp" and "udp". The following values have been registered with IANA:
SLP DAサービスのためのDNS SRV RRsでは、Service分野への英字名はこと"slpda"、サポートしているプロトコルが"tcp"と"udp"であるです。 以下の値はIANAに示されました:
Service Field Protocol Field Reference
------------- -------------- ---------
slpda tcp [RFC3832]
slpda udp [RFC3832]
サービス分野プロトコル分野参照------------- -------------- --------- slpda tcp[RFC3832]slpda udp[RFC3832]
8. Acknowledgments
8. 承認
The authors would like to thank Bernard Aboba, Kevin Arnold, Steven Bellovin, Ted Hardie, James Kempf, Thomas Narten, Erik Nordmark, and Jon Peterson for their valuable comments.
作者は彼らの貴重なコメントについてバーナードAboba、ケビン・アーノルド、スティーブンBellovin、テッド・ハーディー、ジェームス・ケンフ、トーマスNarten、エリックNordmark、およびジョン・ピーターソンに感謝したがっています。
9. Normative References
9. 引用規格
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service
Location Protocol, Version 2 ", RFC 2608, June 1999.
[RFC2608]Guttman、E.、パーキンス、C.、Veizades、J.、およびM.日、「サービス位置のプロトコル、バージョン2」RFC2608、6月1999日
[RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC2782]GulbrandsenとA.とVixieとP.とL.Esibov、「サービス(DNS SRV)の位置を指定するためのDNS RR」、RFC2782、2000年2月。
Zhao, et al. Experimental [Page 5] RFC 3832 Remote Discovery in SLP via DNS SRV July 2004
チャオ、他 DNS SRV2004年7月を通したSLPの実験的な[5ページ]RFC3832Remoteディスカバリー
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC2535] Eastlake 3rd, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2535] イーストレーク3番目、D.、「ドメインネームシステムセキュリティ拡大」、RFC2535、1999年3月。
10. Authors' Addresses
10. 作者のアドレス
Weibin Zhao Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
Weibinチャオコンピュータサイエンス学部Columbia University1214アムステルダムアベニュー、ニューヨーク、ニューヨークのM.C.0401 10027-7003
EMail: zwb@cs.columbia.edu
メール: zwb@cs.columbia.edu
Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
ヘニングSchulzrinneコンピュータサイエンス学部Columbia University1214アムステルダムアベニュー、ニューヨーク、ニューヨークのM.C.0401 10027-7003
EMail: hgs@cs.columbia.edu
メール: hgs@cs.columbia.edu
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
エリックGuttmanサン・マイクロシステムズEichhoelzelstr。 7 74915Waibstadtドイツ
EMail: Erik.Guttman@sun.com
メール: Erik.Guttman@sun.com
Zhao, et al. Experimental [Page 6] RFC 3832 Remote Discovery in SLP via DNS SRV July 2004
チャオ、他 DNS SRV2004年7月を通したSLPの実験的な[6ページ]RFC3832Remoteディスカバリー
Dr. Chatschik Bisdikian IBM T. J. Watson Research Center 30 Saw Mill River Road, M/S 3S-B34 Hawthorne, NY 10532, USA
Chatschik Bisdikian IBM T.J.ワトソン研究所博士30製材機械Road川、M/S3S-B34ホーソーン、ニューヨーク 10532、米国
Phone: +1 914 784 7439 Fax: +1 914 784 6225 EMail: bisdik@us.ibm.com
以下に電話をしてください。 +1 914 784、7439Fax: +1 6225年の914 784メール: bisdik@us.ibm.com
William F. Jerome IBM Corp. Thomas J. Watson Research Center 19 Skyline Drive Hawthorne, NY 10532, USA
ニューヨーク 10532、ウィリアムF.ジェロームIBM社のトーマスJワトソンリサーチセンター19地平線Driveホーソーン(米国)
EMail: wfj@us.ibm.com
メール: wfj@us.ibm.com
Zhao, et al. Experimental [Page 7] RFC 3832 Remote Discovery in SLP via DNS SRV July 2004
チャオ、他 DNS SRV2004年7月を通したSLPの実験的な[7ページ]RFC3832Remoteディスカバリー
11. Full Copyright Statement
11. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Zhao, et al. Experimental [Page 8]
チャオ、他 実験的[8ページ]
一覧
スポンサーリンク
