RFC5223 日本語訳
5223 Discovering Location-to-Service Translation (LoST) Servers Usingthe Dynamic Host Configuration Protocol (DHCP). H. Schulzrinne, J.Polk, H. Tschofenig. August 2008. (Format: TXT=14936 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H. Schulzrinne
Request for Comments: 5223 Columbia University
Category: Standards Track J. Polk
Cisco
H. Tschofenig
Nokia Siemens Networks
August 2008
Schulzrinneがコメントのために要求するワーキンググループH.をネットワークでつないでください: 5223年のコロンビア大学カテゴリ: 規格は2008年8月にJ.ポークコクチマスH.Tschofenigノキアジーメンスネットワークを追跡します。
Discovering Location-to-Service Translation (LoST) Servers Using the
Dynamic Host Configuration Protocol (DHCP)
Dynamic Host Configuration Protocolを使用することで位置からサービスへの翻訳(失われている)サーバを発見します。(DHCP)
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
The Location-to-Service Translation (LoST) Protocol describes an XML- based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs). LoST servers can be located anywhere, but a placement closer to the end host, e.g., in the access network, is desirable. In disaster situations with intermittent network connectivity, such a LoST server placement provides benefits regarding the resiliency of emergency service communication.
LocationからサービスへのTranslation(LoST)プロトコルは、サービス接触Uniform Resource Locator(URL)にサービス識別子とgeospatialか都市の位置情報を写像するためにXMLのベースのプロトコルについて説明します。 LoSTサーバはどこでも位置できますが、終わりのホストの、より近く例えば、アクセスネットワークにおけるプレースメントは望ましいです。 間欠ネットワークの接続性がある災害状況に、そのようなLoSTサーバプレースメントは非常時のサービスコミュニケーションの弾性に関して利益を提供します。
This document describes how a LoST client can discover a LoST server using the Dynamic Host Configuration Protocol (DHCP).
このドキュメントは、LoSTクライアントがDynamic Host Configuration Protocol(DHCP)を使用することでどうしたらLoSTサーバを発見できるかを説明します。
Schulzrinne, et al. Standards Track [Page 1] RFC 5223 DHCP-Based LoST Discovery August 2008
Schulzrinne、他 無くなっている発見2008年8月のDHCPベースの標準化過程[1ページ]RFC5223
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Domain Name Encoding . . . . . . . . . . . . . . . . . . . . . 3
4. LoST Server DHCPv4 Option . . . . . . . . . . . . . . . . . . . 3
5. LoST Server DHCPv6 Option . . . . . . . . . . . . . . . . . . . 4
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
7.1. DHCPv4 Option . . . . . . . . . . . . . . . . . . . . . . . 5
7.2. DHCPv6 Option . . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1. Normative References . . . . . . . . . . . . . . . . . . . 6
10.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 用語. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 ドメイン名コード化. . . . . . . . . . . . . . . . . . . . . 3 4。 無くなっているサーバDHCPv4オプション. . . . . . . . . . . . . . . . . . . 3 5。 無くなっているサーバDHCPv6オプション. . . . . . . . . . . . . . . . . . . 4 6。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 5 7.1。 DHCPv4オプション. . . . . . . . . . . . . . . . . . . . . . . 5 7.2。 DHCPv6オプション. . . . . . . . . . . . . . . . . . . . . . . 5 8。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 5 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 5 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1。 引用規格. . . . . . . . . . . . . . . . . . . 6 10.2。 有益な参照. . . . . . . . . . . . . . . . . . 6
1. Introduction
1. 序論
The Location-to-Service Translation (LoST) Protocol [RFC5222] describes an XML-based protocol for mapping service identifiers and geospatial or civic location information to service contact Uniform Resource Locators (URLs).
LocationからサービスへのTranslation(LoST)プロトコル[RFC5222]は、サービス接触Uniform Resource Locator(URL)にサービス識別子とgeospatialか都市の位置情報を写像するためにXMLベースのプロトコルについて説明します。
In order to interact with a LoST server, the LoST client needs to discover the server's IP address. Several mechanisms can be used to learn this address, including manual configuration. In environments where the access network itself either deploys a LoST server or knows a third party that operates a LoST server, DHCP can provide the end host with a domain name. This domain name is then used as input to the DNS-based resolution mechanism described in LoST [RFC5222] that reuses the URI-enabled NAPTR specification (see [RFC4848]).
LoSTサーバと対話するために、LoSTクライアントは、サーバのIPアドレスを発見する必要があります。 手動の構成を含むこのアドレスを学ぶのに数個のメカニズムを使用できます。 アクセスネットワーク自体がLoSTサーバを配布するか、またはLoSTサーバを操作する第三者を知っている環境で、DHCPは終わりのホストにドメイン名を提供できます。 そして、このドメイン名はURIで可能にされたNAPTR仕様を再利用するLoST[RFC5222]で説明されたDNSベースの解決メカニズムに入力されるように使用されます([RFC4848]を見てください)。
This document specifies a DHCPv4 and a DHCPv6 option that allows LoST clients to discover local LoST servers.
このドキュメントはLoSTクライアントがローカルのLoSTサーバを発見できるDHCPv4とDHCPv6オプションを指定します。
Section 2 provides terminology. Section 3 shows the encoding of the domain name. Section 4 describes the DHCPv4 option while Section 5 describes the DHCPv6 option, with the same functionality. IANA and Security Considerations complete the document in Sections 7 and 8.
セクション2は用語を提供します。 セクション3はドメイン名のコード化を示しています。 セクション5は同じ機能性でDHCPv6オプションについて説明しますが、セクション4はDHCPv4オプションについて説明します。 IANAとSecurity Considerationsはセクション7と8のドキュメントを完成します。
2. Terminology
2. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119].
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように解釈されることであるべきですか?
Schulzrinne, et al. Standards Track [Page 2] RFC 5223 DHCP-Based LoST Discovery August 2008
Schulzrinne、他 無くなっている発見2008年8月のDHCPベースの標準化過程[2ページ]RFC5223
Within this document, we use terminology from [RFC5012] and [RFC5222].
このドキュメントの中では、私たちは[RFC5012]と[RFC5222]から用語を使用します。
3. Domain Name Encoding
3. ドメイン名コード化
This section describes the encoding of the domain name used in the DHCPv4 option shown in Section 4 and also used in the DHCPv6 option shown in Section 5.
このセクションはセクション4のDHCPv4オプションに使用されて、またセクション5のDHCPv6オプションに使用されるドメイン名のコード化について説明します。
The domain name is encoded according to Section 3.1 of RFC 1035 [RFC1035] whereby each label is represented as a one-octet length field followed by that number of octets. Since every domain name ends with the null label of the root, a domain name is terminated by a length byte of zero. The high-order two bits of every length octet MUST be zero, and the remaining six bits of the length field limit the label to 63 octets or less. To simplify implementations, the total length of a domain name (i.e., label octets and label length octets) is restricted to 255 octets or less.
その数の八重奏で1八重奏の長さの野原が続いたので各ラベルが表されるRFC1035[RFC1035]のセクション3.1によると、ドメイン名はコード化されます。 あらゆるドメイン名が根のヌルラベルで終わるので、ドメイン名はゼロの長さのバイト終えられます。 あらゆる長さの八重奏の高位2ビットはゼロであるに違いありません、そして、長さの分野の残っている6ビットはラベルを63以下の八重奏に制限します。 実装を簡素化するために、ドメイン名(すなわち、ラベル八重奏とラベル長さの八重奏)の全長は255以下の八重奏に制限されます。
4. LoST Server DHCPv4 Option
4. 無くなっているサーバDHCPv4オプション
The LoST server DHCPv4 option carries a DNS (RFC 1035 [RFC1035]) fully-qualified domain name (FQDN) to be used by the LoST client to locate a LoST server.
LoSTサーバの場所を見つけるのにLoSTクライアントによって使用されるように、LoSTサーバDHCPv4オプションはDNS(RFC1035[RFC1035])完全修飾ドメイン名(FQDN)を運びます。
The DHCP option for this encoding has the following format:
このコード化のためのDHCPオプションには、以下の形式があります:
Code Len LoST Server Domain Name
+-----+-----+-----+-----+-----+-----+-----+----
| 137 | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+-----+-----+-----+-----+-----+-----+----
レンLoSTのサーバドメイン名+をコード化してください。-----+-----+-----+-----+-----+-----+-----+---- | 137 | n| s1| s2| s3| s4| s5| ... +-----+-----+-----+-----+-----+-----+-----+----
Figure 1: LoST FQDN DHCPv4 Option
図1: 無くなっているFQDN DHCPv4オプション
The values s1, s2, s3, etc. represent the domain name labels in the domain name encoding. Note that the length field in the DHCPv4 option represents the length of the entire domain name encoding, whereas the length fields in the domain name encoding (see Section 3) is the length of a single domain name label.
値のs1、s2、s3などはドメイン名コード化でドメイン名ラベルを表します。 DHCPv4オプションにおける長さの分野が全体のドメイン名コード化の長さを表しますが、ドメイン名コード化(セクション3を見る)における長さの分野が単一領域ネームラベルの長さであることに注意してください。
Code: OPTION_V4_LOST (137)
コード: オプション_V4_は負けました。(137)
Len: Length of the 'LoST Server Domain Name' field
in octets; variable.
レン: 八重奏における、'LoST Server Domain Name'分野の長さ。 可変。
LoST Server Domain Name: The domain name of the LoST
server for the client to use.
無くなっているサーバドメイン名: クライアントが使用するLoSTサーバのドメイン名。
Schulzrinne, et al. Standards Track [Page 3] RFC 5223 DHCP-Based LoST Discovery August 2008
Schulzrinne、他 無くなっている発見2008年8月のDHCPベースの標準化過程[3ページ]RFC5223
A DHCPv4 client MAY request a LoST server domain name in a Parameter Request List option, as described in [RFC2131].
DHCPv4クライアントは[RFC2131]で説明されるようにParameter Request ListオプションにおけるLoSTサーバドメイン名を要求するかもしれません。
The encoding of the domain name is described in Section 3.
ドメイン名のコード化はセクション3で説明されます。
This option contains a single domain name and, as such, MUST contain precisely one root label.
このオプションは、単一領域名を含んでいて、そういうものとして正確に1個の根のラベルを含まなければなりません。
5. LoST Server DHCPv6 Option
5. 無くなっているサーバDHCPv6オプション
This section defines a DHCPv6 option to carry a domain name.
このセクションは、ドメイン名を運ぶためにDHCPv6オプションを定義します。
The DHCPv6 option has the format shown in Figure 2.
DHCPv6オプションには、図2に示された書式があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_V6_LOST | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LoST Server Domain Name |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション_V6_は負けました。| オプション長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 無くなっているサーバドメイン名| | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code: OPTION_V6_LOST (51)
オプションコード: オプション_V6_は負けました。(51)
option-length: Length of the 'LoST Server Domain Name' field
in octets; variable.
オプション長さ: 八重奏における、'LoST Server Domain Name'分野の長さ。 可変。
LoST Server Domain Name: The domain name of the LoST
server for the client to use.
無くなっているサーバドメイン名: クライアントが使用するLoSTサーバのドメイン名。
Figure 2: DHCPv6 Option for LoST Server Domain Name List
図2: 無くなっているサーバドメイン名リストのためのDHCPv6オプション
A DHCPv6 client MAY request a LoST server domain name in an Options Request Option (ORO), as described in [RFC3315].
DHCPv6クライアントは[RFC3315]で説明されるようにOptions Request Option(ORO)のLoSTサーバドメイン名を要求するかもしれません。
The encoding of the domain name is described in Section 3.
ドメイン名のコード化はセクション3で説明されます。
This option contains a single domain name and, as such, MUST contain precisely one root label.
このオプションは、単一領域名を含んでいて、そういうものとして正確に1個の根のラベルを含まなければなりません。
6. Example
6. 例
This section shows an example of a DHCPv4 option where the DHCP server wants to offer the "example.com" domain name to the client as input to the U-NAPTR LoST discovery procedure. This domain name would be encoded as follows:
このセクションは、DHCPサーバがU-NAPTR LoST発見手順に入力されるようにどこで"example.com"ドメイン名をクライアントに提供したがっているかをDHCPv4オプションに関する例に示します。 このドメイン名は以下の通りコード化されるでしょう:
Schulzrinne, et al. Standards Track [Page 4] RFC 5223 DHCP-Based LoST Discovery August 2008
Schulzrinne、他 無くなっている発見2008年8月のDHCPベースの標準化過程[4ページ]RFC5223
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|137 |13 | 7 | e | x | a | m | p | l | e | 3 | c | o | m | 0 |
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ |137 |13 | 7 | e| x| a| m| p| l| e| 3 | c| o | m| 0 | +----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Figure 3: Example for a LoST FQDN DHCPv4 Option
図3: 無くなっているFQDN DHCPv4オプションのための例
7. IANA Considerations
7. IANA問題
7.1. DHCPv4 Option
7.1. DHCPv4オプション
The following DHCPv4 option code for the Location-to-Service Translation (LoST) Protocol server option has been assigned by IANA:
LocationからサービスへのTranslation(LoST)プロトコルサーバオプションのための以下のDHCPv4オプションコードはIANAによって割り当てられました:
Option Name Value Described in
-----------------------------------------------
OPTION_V4_LOST 137 Section 4
中で説明されたオプション名前価値----------------------------------------------- オプション_V4_は137部4を失いました。
7.2. DHCPv6 Option
7.2. DHCPv6オプション
IANA has assigned the following DHCPv6 option code for the Location- to-Service Translation (LoST) Protocol option:
IANAはサービスへのLocation Translation(LoST)プロトコルオプションのために以下のDHCPv6オプションコードを割り当てました:
Option Name Value Described in
------------------------------------------------
OPTION_V6_LOST 51 Section 5
中で説明されたオプション名前価値------------------------------------------------ オプション_V6_は51部5を失いました。
8. Security Considerations
8. セキュリティ問題
If an adversary manages to modify the response from a DHCP server or insert its own response, a LoST client could be led to contact a rogue LoST server under the control of the adversary or be given an invalid address. These threats are documented in [RFC5069]. The security considerations in [RFC2131], [RFC2132], and [RFC3315] are applicable to this document.
DHCPサーバから応答を変更するか、または敵が何とかそれ自身の応答を挿入するなら、LoSTクライアントに敵のコントロールの下で凶暴なLoSTサーバに連絡するように導くか、または無効のアドレスを与えるかもしれません。 これらの脅威は[RFC5069]に記録されます。 [RFC2131]、[RFC2132]、および[RFC3315]のセキュリティ問題はこのドキュメントに適切です。
[RFC5222] enumerates the LoST security mechanisms.
[RFC5222]はLoSTセキュリティー対策を数え上げます。
9. Acknowledgements
9. 承認
Andrew Newton reviewed the document and helped simplify the mechanism. Other helpful input was provided by Jari Arkko, Leslie Daigle, Vijay K. Gurbani (Gen-ART Review), David W. Hankins, Russ Housley, Tim Polk, Mark Stapp, and Christian Vogt.
アンドリュー・ニュートンは、ドキュメントを再検討して、メカニズムを簡素化するのを助けました。 他の有用な入力はヤリArkko、レスリーDaigle、ビジェイK.Gurbani(ART Reviewに情報を得ている)、デヴィッド・W.ハンキンズ、ラスHousley、ティム・ポーク、マークStapp、およびクリスチャンのフォークトによって提供されました。
Schulzrinne, et al. Standards Track [Page 5] RFC 5223 DHCP-Based LoST Discovery August 2008
Schulzrinne、他 無くなっている発見2008年8月のDHCPベースの標準化過程[5ページ]RFC5223
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、BCP14、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2132] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTPベンダー拡大」、RFC2132、1997年3月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms(R.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
10.2. Informative References
10.2. 有益な参照
[RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007.
[RFC4848]Daigle、L.、「URIを使用するドメインベースのアプリケーション・サービス位置とダイナミックな委譲発見は(DDDS)を修理する」RFC4848、2007年4月。
[RFC5012] Schulzrinne, H. and R. Marshall, "Requirements for
Emergency Context Resolution with Internet Technologies",
RFC 5012, January 2008.
[RFC5012] SchulzrinneとH.とR.マーシャル、「インターネット技術との非常時の文脈解決のための要件」、RFC5012、2008年1月。
[RFC5069] Taylor, T., Tschofenig, H., Schulzrinne, H., and M.
Shanmugam, "Security Threats and Requirements for
Emergency Call Marking and Mapping", RFC 5069,
January 2008.
[RFC5069] テイラー、T.、Tschofenig、H.、Schulzrinne、H.、およびM.Shanmugam、「非常時の間の軍事的脅威と要件は、マークとマッピングと呼びます」、RFC5069、2008年1月。
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008.
[RFC5222] ハーディー、T.、ニュートン、A.、Schulzrinne、H.、H.Tschofenig、「失われました」。 「位置からサービスへの翻訳プロトコル」、RFC5222、2008年8月。
Schulzrinne, et al. Standards Track [Page 6] RFC 5223 DHCP-Based LoST Discovery August 2008
Schulzrinne、他 無くなっている発見2008年8月のDHCPベースの標準化過程[6ページ]RFC5223
Authors' Addresses
作者のアドレス
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
Buildingニューヨーク、コンピュータサイエンス450コンピュータサイエンスニューヨーク10027米国のヘニングSchulzrinneコロンビア大学部
EMail: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu
メール: hgs+ ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu
James Polk Cisco 2200 East President George Bush Turnpike Richardson, TX 75082 US
ジェイムズ・ポークシスコ2200の東社長のジョージ・ブッシュ・Turnpikeテキサス75082リチャードソン(米国)
EMail: jmpolk@cisco.com
メール: jmpolk@cisco.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenigノキアシーメンスはLinnoitustie6エスポー02600フィンランドをネットワークでつなぎます。
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.priv.at
以下に電話をしてください。 +358 (50) 4871445はメールされます: Hannes.Tschofenig@nsn.com ユリ: http://www.tschofenig.priv.at
Schulzrinne, et al. Standards Track [Page 7] RFC 5223 DHCP-Based LoST Discovery August 2008
Schulzrinne、他 無くなっている発見2008年8月のDHCPベースの標準化過程[7ページ]RFC5223
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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.
このドキュメントは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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を扱ってください。
Schulzrinne, et al. Standards Track [Page 8]
Schulzrinne、他 標準化過程[8ページ]
一覧
スポンサーリンク
