RFC4530 日本語訳
4530 Lightweight Directory Access Protocol (LDAP) entryUUIDOperational Attribute. K. Zeilenga. June 2006. (Format: TXT=15191 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Zeilenga Request for Comments: 4530 OpenLDAP Foundation Category: Standards Track June 2006
Zeilengaがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4530年のOpenLDAP財団カテゴリ: 標準化過程2006年6月
Lightweight Directory Access Protocol (LDAP)
entryUUID Operational Attribute
ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のentryUUIDの操作上の属性
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document describes the LDAP/X.500 'entryUUID' operational attribute and associated matching rules and syntax. The attribute holds a server-assigned Universally Unique Identifier (UUID) for the object. Directory clients may use this attribute to distinguish objects identified by a distinguished name or to locate an object after renaming.
このドキュメントはLDAP/X.500の'entryUUID'操作上の属性、関連合っている規則、および構文について説明します。 属性はオブジェクトのためのサーバで割り当てられたUniversally Unique Identifier(UUID)を持っています。 ディレクトリクライアントは、分類名によって特定されたオブジェクトを区別するか、または改名の後にオブジェクトの場所を見つけるのにこの属性を使用するかもしれません。
Zeilenga Standards Track [Page 1] RFC 4530 LDAP entryUUID June 2006
Zeilenga規格はLDAP entryUUID2006年6月にRFC4530を追跡します[1ページ]。
Table of Contents
目次
1. Background and Intended Use .....................................2
2. UUID Schema Elements ............................................3
2.1. UUID Syntax ................................................3
2.2. 'uuidMatch' Matching Rule ..................................3
2.3. 'uuidOrderingMatch' Matching Rule ..........................3
2.4. 'entryUUID' Attribute ......................................4
3. Security Considerations .........................................4
4. IANA Considerations .............................................5
4.1. Object Identifier Registration .............................5
4.2. UUID Syntax Registration ...................................5
4.3. 'uuidMatch' Descriptor Registration ........................5
4.4. 'uuidOrderingMatch' Descriptor Registration ................5
4.5. 'entryUUID' Descriptor Registration ........................6
5. Acknowledgements ................................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................7
1. バックグラウンドと意図している使用…2 2. UUID Schema Elements…3 2.1. UUID構文…3 2.2. 'uuidMatch'マッチングは統治されます…3 2.3. 'uuidOrderingMatch'マッチングは統治されます…3 2.4. 'entryUUID'属性…4 3. セキュリティ問題…4 4. IANA問題…5 4.1. オブジェクト識別子登録…5 4.2. UUID構文登録…5 4.3. 'uuidMatch'記述子登録…5 4.4. 'uuidOrderingMatch'記述子登録…5 4.5. 'entryUUID'記述子登録…6 5. 承認…6 6. 参照…6 6.1. 標準の参照…6 6.2. 有益な参照…7
1. Background and Intended Use
1. バックグラウンドと意図している使用
In X.500 Directory Services [X.501], such as those accessible using the Lightweight Directory Access Protocol (LDAP) [RFC4510], an object is identified by its distinguished name (DN). However, DNs are not stable identifiers. That is, a new object may be identified by a DN that previously identified another (now renamed or deleted) object.
ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)[RFC4510]を使用するアクセスしやすいものなどのX.500ディレクトリサービス[X.501]では、分類名(DN)によってオブジェクトは特定されます。 しかしながら、DNsは安定した識別子ではありません。 すなわち、新しいオブジェクトは以前に別の(現在、改名されるか、または削除されています)のオブジェクトを特定したDNによって特定されるかもしれません。
A Universally Unique Identifier (UUID) is "an identifier unique across both space and time, with respect to the space of all UUIDs" [RFC4122]. UUIDs are used in a wide range of systems.
Universally Unique Identifier(UUID)は「スペースと時間の両方の向こう側にすべてのUUIDsのスペースに関してユニークな識別子」[RFC4122]です。 UUIDsはさまざまなシステムで使用されます。
This document describes the 'entryUUID' operational attribute, which holds the UUID assigned to the object by the server. Clients may use this attribute to distinguish objects identified by a particular distinguished name or to locate a particular object after renaming.
このドキュメントは'entryUUID'操作上の属性について説明します。(それは、サーバでUUIDをオブジェクトに割り当てるように主張します)。クライアントは、特定の分類名によって特定されたオブジェクトを区別するか、または改名の後に特定のオブジェクトの場所を見つけるのにこの属性を使用するかもしれません。
This document defines the UUID syntax, the 'uuidMatch' and 'uuidOrderingMatch' matching rules, and the 'entryUUID' attribute type.
このドキュメントはUUID構文、'uuidMatch'と'uuidOrderingMatch'合っている規則、および'entryUUID'属性タイプを定義します。
Schema definitions are provided using LDAP description formats [RFC4512]. Definitions provided here are formatted (line wrapped) for readability.
LDAP記述形式[RFC4512]を使用することで図式定義を提供します。 ここに提供された定義は読み易さのためにフォーマットされます(包装された系列)。
Zeilenga Standards Track [Page 2] RFC 4530 LDAP entryUUID June 2006
Zeilenga規格はLDAP entryUUID2006年6月にRFC4530を追跡します[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 BCP 14 [RFC2119].
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14[RFC2119]で説明されるように解釈されることであるべきですか?
2. UUID Schema Elements
2. UUID Schema Elements
2.1. UUID Syntax
2.1. UUID構文
A Universally Unique Identifier (UUID) [RFC4122] is a 16-octet (128- bit) value that identifies an object. The ASN.1 [X.680] type UUID is defined to represent UUIDs as follows:
Universally Unique Identifier(UUID)[RFC4122]はオブジェクトを特定する16八重奏(128ビット)の値です。 ASN.1[X.680]タイプUUIDは以下のUUIDsを表すために定義されます:
UUID ::= OCTET STRING (SIZE(16))
-- constrained to an UUID [RFC4122]
UUID:、:= OCTET STRING、(SIZE(16))--UUIDに抑制されます。[RFC4122]
In LDAP, UUID values are encoded using the [ASCII] character string representation described in [RFC4122]. For example, "597ae2f6-16a6-1027-98f4-d28b5365dc14".
LDAPでは、UUID値は、[RFC4122]で説明された[ASCII]文字列表現を使用することでコード化されます。 例えば、"597ae2f6-16a6-1027-98f4-d28b5365dc14""。
The following is an LDAP syntax description suitable for publication in subschema subentries.
↓これはサブスキーマ副次的記載での公表に適したLDAP構文記述です。
( 1.3.6.1.1.16.1 DESC 'UUID' )
(1.3、.6、.1、.1、.16、.1DESC'UUID')
2.2. 'uuidMatch' Matching Rule
2.2. 'uuidMatch'合っている規則
The 'uuidMatch' matching rule compares an asserted UUID with a stored UUID for equality. Its semantics are the same as the 'octetStringMatch' [X.520][RFC4517] matching rule. The rule differs from 'octetStringMatch' in that the assertion value is encoded using the UUID string representation instead of the normal OCTET STRING string representation.
'uuidMatch'合っている規則は平等のために保存されたUUIDと断言されたUUIDを比べます。 意味論は'octetStringMatch'[X.520][RFC4517]マッチングが統治されるのと同じです。 規則は主張値が通常のOCTET STRINGストリング表現の代わりにUUIDストリング表現を使用することでコード化されるという点において'octetStringMatch'と異なっています。
The following is an LDAP matching rule description suitable for publication in subschema subentries.
↓これはサブスキーマ副次的記載での公表に適したLDAP合っている規則記述です。
( 1.3.6.1.1.16.2 NAME 'uuidMatch'
SYNTAX 1.3.6.1.1.16.1 )
(1.3.6.1.1.16.2名'uuidMatch'構文1.3.6.1の.1、.16、.1)
2.3. 'uuidOrderingMatch' Matching Rule
2.3. 'uuidOrderingMatch'合っている規則
The 'uuidOrderingMatch' matching rule compares an asserted UUID with a stored UUID for ordering. Its semantics are the same as the 'octetStringOrderingMatch' [X.520][RFC4517] matching rule. The rule differs from 'octetStringOrderingMatch' in that the assertion value is encoded using the UUID string representation instead of the normal OCTET STRING string representation.
'uuidOrderingMatch'合っている規則は、注文するために保存されたUUIDと断言されたUUIDを比べます。 意味論は'octetStringOrderingMatch'[X.520][RFC4517]マッチングが統治されるのと同じです。 規則は主張値が通常のOCTET STRINGストリング表現の代わりにUUIDストリング表現を使用することでコード化されるという点において'octetStringOrderingMatch'と異なっています。
Zeilenga Standards Track [Page 3] RFC 4530 LDAP entryUUID June 2006
Zeilenga規格はLDAP entryUUID2006年6月にRFC4530を追跡します[3ページ]。
The following is an LDAP matching rule description suitable for publication in subschema subentries.
↓これはサブスキーマ副次的記載での公表に適したLDAP合っている規則記述です。
( 1.3.6.1.1.16.3 NAME 'uuidOrderingMatch'
SYNTAX 1.3.6.1.1.16.1 )
(1.3.6.1.1.16.3名'uuidOrderingMatch'構文1.3.6.1の.1、.16、.1)
Note that not all UUID variants have a defined ordering; and even where it does, servers are not obligated to assign UUIDs in any particular order. This matching rule is provided for completeness.
すべてのUUID異形には定義された注文があるというわけではないことに注意してください。 そして、義務付けさえするところで、サーバがどんな特定のオーダーでもUUIDsを割り当てるのが義務付けられません。 この合っている規則を完全性に提供します。
2.4. 'entryUUID' Attribute
2.4. 'entryUUID'属性
The 'entryUUID' operational attribute provides the Universally Unique Identifier (UUID) assigned to the entry.
'entryUUID'操作上の属性はエントリーに割り当てられたUniversally Unique Identifier(UUID)を提供します。
The following is an LDAP attribute type description suitable for publication in subschema subentries.
↓これはサブスキーマ副次的記載での公表に適したLDAP属性型記述です。
( 1.3.6.1.1.16.4 NAME 'entryUUID'
DESC 'UUID of the entry'
EQUALITY uuidMatch
ORDERING uuidOrderingMatch
SYNTAX 1.3.6.1.1.16.1
SINGLE-VALUE
NO-USER-MODIFICATION
USAGE directoryOperation )
(1.3.6.1.1.16.4NAME'エントリーのentryUUID'DESC'UUID'EQUALITY uuidMatch ORDERING uuidOrderingMatch SYNTAX1.3.6、.1、.1、.16、.1SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation)
Servers SHALL generate and assign a new UUID to each entry upon its addition to the directory and provide that UUID as the value of the 'entryUUID' operational attribute. An entry's UUID is immutable.
SHALLが'entryUUID'操作上の属性の値としてディレクトリへの追加の各エントリーに新しいUUIDを生成して、割り当てて、そのUUIDを提供するサーバ。 エントリーのUUIDは不変です。
UUID are to be generated in accordance with Section 4 of [RFC4122]. In particular, servers MUST ensure that each generated UUID is unique in space and time.
[RFC4122]のセクション4によると、UUIDは生成されることになっています。 特に、サーバはそれぞれの発生しているUUIDが確実にスペースと時間でユニークになるようにしなければなりません。
3. Security Considerations
3. セキュリティ問題
An entry's relative distinguish name (RDN) is composed from attribute values of the entry, which are commonly descriptive of the object the entry represents. Although deployers are encouraged to use naming attributes whose values are widely disclosable [RFC4514], entries are often named using information that cannot be disclosed to all parties. As UUIDs do not contain any descriptive information of the object they identify, UUIDs may be used to identify a particular entry without disclosure of its contents.
エントリーの親類はエントリーの属性値と構成された名前(RDN)を区別します。(属性値はエントリーが表すオブジェクトで一般的に描写的です)。 デプロイヤが値が広く明らかに可能である命名属性[RFC4514]を使用するよう奨励されますが、エントリーはすべてのパーティーに明らかにすることができない情報を使用するとしばしば命名されます。 UUIDsが彼らが特定するオブジェクトに関するどんな記述的な情報も含んでいなくて、UUIDsは、コンテンツの公開なしで特定のエントリーを特定するのに使用されるかもしれません。
General UUID security considerations [RFC4122] apply.
一般UUIDセキュリティ問題[RFC4122]は適用します。
Zeilenga Standards Track [Page 4] RFC 4530 LDAP entryUUID June 2006
Zeilenga規格はLDAP entryUUID2006年6月にRFC4530を追跡します[4ページ]。
General LDAP security considerations [RFC4510] apply.
一般LDAPセキュリティ問題[RFC4510]は適用します。
4. IANA Considerations
4. IANA問題
The IANA has registered the LDAP values [RFC4520] specified in this document.
IANAは本書では指定されたLDAP値[RFC4520]を示しました。
4.1. Object Identifier Registration
4.1. オブジェクト識別子登録
Subject: Request for LDAP OID Registration
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC 4530
Author/Change Controller: IESG
Comments:
Identifies the UUID schema elements
Subject: 詳細のために連絡するLDAP OID Registration PersonとEメールアドレスのために以下を要求してください。 カート Zeilenga <kurt@OpenLDAP.org 、gt;、仕様: RFC4530作者/変化コントローラ: IESGはコメントします: UUID図式要素を特定します。
4.2. UUID Syntax Registration
4.2. UUID構文登録
Subject: Request for LDAP Syntax Registration
Object Identifier: 1.3.6.1.1.16.1
Description: UUID
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Specification: RFC 4530
Author/Change Controller: IESG
Comments:
Identifies the UUID syntax
Subject: LDAP構文登録オブジェクト識別子のために以下を要求してください。 1.3.6.1.1.16.1 記述: 詳細のために連絡するUUID PersonとEメールアドレス: カート Zeilenga <kurt@OpenLDAP.org 、gt;、仕様: RFC4530作者/変化コントローラ: IESGはコメントします: UUID構文を特定します。
4.3. 'uuidMatch' Descriptor Registration
4.3. 'uuidMatch'記述子登録
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): uuidMatch
Object Identifier: 1.3.6.1.1.16.2
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: Matching Rule
Specification: RFC 4530
Author/Change Controller: IESG
Subject: LDAP Descriptor Registration Descriptor(省略名)のために以下を要求してください。 uuidMatchオブジェクト識別子: 1.3.6.1.1.16.2 詳細のために連絡する人とEメールアドレス: カート Zeilenga <kurt@OpenLDAP.org 、gt;、用法: マッチングは仕様を統治します: RFC4530作者/変化コントローラ: IESG
4.4. 'uuidOrderingMatch' Descriptor Registration
4.4. 'uuidOrderingMatch'記述子登録
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): uuidOrderingMatch
Object Identifier: 1.3.6.1.1.16.3
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: Matching Rule
Subject: LDAP Descriptor Registration Descriptor(省略名)のために以下を要求してください。 uuidOrderingMatchオブジェクト識別子: 1.3.6.1.1.16.3 詳細のために連絡する人とEメールアドレス: カート Zeilenga <kurt@OpenLDAP.org 、gt;、用法: マッチング規則
Zeilenga Standards Track [Page 5] RFC 4530 LDAP entryUUID June 2006
Zeilenga規格はLDAP entryUUID2006年6月にRFC4530を追跡します[5ページ]。
Specification: RFC 4530
Author/Change Controller: IESG
仕様: RFC4530作者/変化コントローラ: IESG
4.5. 'entryUUID' Descriptor Registration
4.5. 'entryUUID'記述子登録
The IANA has registered the LDAP 'entryUUID' descriptor.
IANAはLDAP'entryUUID'記述子を登録しました。
Subject: Request for LDAP Descriptor Registration
Descriptor (short name): entryUUID
Object Identifier: 1.3.6.1.1.16.4
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: Attribute Type
Specification: RFC 4530
Author/Change Controller: IESG
Subject: LDAP Descriptor Registration Descriptor(省略名)のために以下を要求してください。 entryUUIDオブジェクト識別子: 1.3.6.1.1.16.4 詳細のために連絡する人とEメールアドレス: カート Zeilenga <kurt@OpenLDAP.org 、gt;、用法: タイプ仕様を結果と考えてください: RFC4530作者/変化コントローラ: IESG
5. Acknowledgements
5. 承認
This document is based upon discussions in the LDAP Update and Duplication Protocols (LDUP) WG. Members of the LDAP Directorate provided review.
このドキュメントはLDAP UpdateとDuplicationプロトコル(LDUP)WGでの議論に基づいています。 LDAP Directorateのメンバーはレビューを提供しました。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[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月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, July
2005.
[RFC4122] リーチ、P.、食事、M.、およびR.ザルツ、「一般にユニークな識別子(UUID)つぼの名前空間」、RFC4122、2005年7月。
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
Protocol (LDAP): Technical Specification Road Map", RFC
4510, June 2006.
[RFC4510] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「仕様書ロードマップ」、RFC4510、2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
[RFC4512] Zeilenga、K.、「軽量のディレクトリアクセスは以下について議定書の中で述べ(LDAP)」。 「ディレクトリ情報モデル」、RFC4512、2006年6月。
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
(LDAP): Syntaxes and Matching Rules", RFC 4517, June
2006.
[RFC4517] Legg、S.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「構文とマッチングは統治する」RFC4517、2006年6月。
[ASCII] Coded Character Set--7-bit American Standard Code for
Information Interchange, ANSI X3.4-1986.
[ASCII]は文字コードをコード化しました--7ビットの情報交換用米国標準コード、ANSI X3.4-1986。
Zeilenga Standards Track [Page 6] RFC 4530 LDAP entryUUID June 2006
Zeilenga規格はLDAP entryUUID2006年6月にRFC4530を追跡します[6ページ]。
[X.501] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory -- Models," X.501(1993) (also ISO/IEC 9594-
2:1994).
[X.501]国際電気通信連合--電気通信標準化セクター、「ディレクトリ--、モデル、」、X.501(1993)(ISO/IEC9594- 2も: 1994)。
[X.520] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory: Selected Attribute Types", X.520(1993) (also
ISO/IEC 9594-6:1994).
[X.520]国際電気通信連合--電気通信標準化セクター、「ディレクトリ:」 「選択された属性タイプ」、X.520(1993)(ISO/IEC9594-6も: 1994)。
[X.680] International Telecommunication Union -
Telecommunication Standardization Sector, "Abstract
Syntax Notation One (ASN.1) - Specification of Basic
Notation", X.680(2002) (also ISO/IEC 8824-1:2002).
[X.680]国際電気通信連合--電気通信標準化セクター、「構文記法1(ASN.1)を抜き取ってください--基本的な記法の仕様」、X.680(2002)(ISO/IEC8824-1も: 2002)。
6.2. Informative References
6.2. 有益な参照
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
Protocol (LDAP): String Representation of Distinguished
Names", RFC 4514, June 2006.
[RFC4514] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「分類名のストリング表現」、RFC4514、2006年6月。
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
(IANA) Considerations for the Lightweight Directory
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[RFC4520]Zeilenga、K.、「インターネットはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のために数の権威(IANA)に問題を割り当てました」、BCP64、RFC4520、2006年6月。
Author's Address
作者のアドレス
Kurt D. Zeilenga OpenLDAP Foundation
カートD.Zeilenga OpenLDAP財団
EMail: Kurt@OpenLDAP.org
メール: Kurt@OpenLDAP.org
Zeilenga Standards Track [Page 7] RFC 4530 LDAP entryUUID June 2006
Zeilenga規格はLDAP entryUUID2006年6月にRFC4530を追跡します[7ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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 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 provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Zeilenga Standards Track [Page 8]
Zeilenga標準化過程[8ページ]
一覧
スポンサーリンク
