RFC 3045 - Storing Vendor Information in the LDAP root DSE 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3045
タイトル : RFC 3045 - LDAPルートDSEにベンダー情報を保存します
翻訳編集 : 自動生成

[要約] RFC 3045は、LDAPサーバーのルートDSE（Specific Entry）に、ベンダー独自の情報を格納するための属性を定義しています。サーバーの実装名やバージョン情報を標準化された方法で提供するためのスキーマを規定しています。クライアントが接続先のLDAPサーバーの特性や実装の詳細を容易に識別できるようにすることを目的としています。

Network Working Group                                        M. Meredith
Request for Comments: 3045                                   Novell Inc.
Category: Informational                                     January 2001

Storing Vendor Information in the LDAP root DSE

LDAPルートDSEにベンダー情報を保存します

Status of this Memo

本文書の状態

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

著作権表示

Abstract

概要

This document specifies two Lightweight Directory Access Protocol (LDAP) attributes, vendorName and vendorVersion that MAY be included in the root DSA-specific Entry (DSE) to advertise vendor-specific information. These two attributes supplement the attributes defined in section 3.4 of RFC 2251.

このドキュメントは、ベンダー固有の情報を宣伝するためにルートDSA固有のエントリ（DSE）に含まれる可能性のある2つのLightweight Directory Access Protocol（LDAP）属性、vendorNameおよびvendorVersionを指定します。これらの2つの属性は、RFC 2251のセクション3.4で定義されている属性を補完します。

The information held in these attributes MAY be used for display and informational purposes and MUST NOT be used for feature advertisement or discovery.

これらの属性に保持されている情報は、表示および情報提供の目的で使用される場合があり (MAY)、機能広告や発見に使用してはなりません (MUST NOT)。

Conventions used in this document

このドキュメントで使用されている規則

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 [RFC2219]

このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119 または関連する仕様で説明されているように解釈されるものとします。

1. Overview

1. 概要

LDAP clients discover server-specific data--such as available controls, extensions, etc.--by reading the root DSE. See section 3.4 of [RFC2251] for details.

LDAPクライアントは、ルートDSEを読み取ることにより、利用可能なコントロール、拡張機能など、サーバー固有のデータを発見します。詳細については、[RFC2251]のセクション3.4を参照してください。

For display, information, and limited function discovery, it is desirable to be able to query an LDAP server to determine the vendor name of that server and also to see what version of that vendor's code is currently installed.

ディスプレイ、情報、および限られた関数の発見については、LDAPサーバーを照会してそのサーバーのベンダー名を決定し、そのベンダーのコードのバージョンが現在インストールされていることを確認できるようにすることが望ましいです。

1.1 Function discovery

1.1 関数発見

There are many ways in which a particular version of a vendor's LDAP server implementation may be functionally incomplete, or may contain software anomalies. It is impossible to identify every known shortcoming of an LDAP server with the given set of server data advertisement attributes. Furthermore, often times, the anomalies of an implementation are not found until after the implementation has been distributed, deployed, and is in use.

ベンダーのLDAPサーバーの実装の特定のバージョンが機能的に不完全であるか、ソフトウェアの異常を含む可能性がある多くの方法があります。特定のサーバーデータ広告属性のセットを備えたLDAPサーバーのすべての既知の欠点を特定することは不可能です。さらに、多くの場合、実装の異常は、実装が配布され、展開され、使用されるまでは見つかりません。

The attributes defined in this document MAY be used by client implementations in order to identify a particular server implementation so that it can 'work around' such anomalies.

このドキュメントで定義されている属性は、特定のサーバーの実装を識別して、そのような異常を「回避」できるようにするために、クライアントの実装で使用できます (MAY)。

The attributes defined in this document MUST NOT be used to gather information related to supported features of an LDAP implementation. All LDAP features, mechanisms, and capabilities--if advertised--MUST be advertised through other mechanisms, preferably advertisement mechanisms defined in concert with said features, mechanisms, and capabilities.

このドキュメントで定義されている属性は、LDAP実装のサポートされている機能に関連する情報を収集するために使用してはなりません。すべてのLDAP機能、メカニズム、および機能（宣伝されている場合）は、他のメカニズム、できれば上記の機能、メカニズム、および機能と協調して定義された広告メカニズムを通じて宣伝されます。

2. Attribute Types

2. 属性タイプ

These attributes are an addition to the Server-specific Data Requirements defined in section 3.4 of [RFC2251]. The associated syntaxes are defined in section 4 of [RFC2252].

これらの属性は、[RFC2251]のセクション3.4で定義されているサーバー固有のデータ要件に追加されています。関連する構文は、[RFC2252]のセクション4で定義されています。

Servers MAY restrict access to vendorName or vendorVersion and clients MUST NOT expect these attributes to be available.

サーバーはvendorNameまたはvendorVersionへのアクセスを制限する場合があり (MAY)、クライアントはこれらの属性が利用可能になることを期待してはなりません (MUST NOT)。

2.1 vendorName

2.1 業者名

This attribute contains a single string, which represents the name of the LDAP server implementer.

この属性には、LDAPサーバー実装者の名前を表す単一の文字列が含まれています。

All LDAP server implementations SHOULD maintain a vendorName, which is generally the name of the company that wrote the LDAP Server code like "Novell, Inc."

すべてのLDAPサーバーの実装は、「Novell、Inc。」のようなLDAPサーバーコードを書いた会社の名前であるvendorNameを維持すべきです (SHOULD)。

( 1.3.6.1.1.4 NAME 'vendorName' EQUALITY 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )

（1.3.6.1.1.4名「vendorName 'Equality 1.3.6.1.4.1.1466.109.114.1 Syntax 1.3.6.1.4.1.1466.115.121.1.15」

2.2 vendorVersion

2.2 ベンダーバージョン

This attribute contains a string which represents the version of the LDAP server implementation.

この属性には、LDAPサーバーの実装のバージョンを表す文字列が含まれています。

All LDAP server implementations SHOULD maintain a vendorVersion. Note that this value is typically a release value--comprised of a string and/or a string of numbers--used by the developer of the LDAP server product (as opposed to the supportedLDAPVersion, which specifies the version of the LDAP protocol supported by this server). This is single-valued so that it will only have one version value. This string MUST be unique between two versions, but there are no other syntactic restrictions on the value or the way it is formatted.

すべてのLDAPサーバーの実装は、ベンダーバージョンを維持すべきです (SHOULD)。この値は通常、LDAPサーバー製品の開発者が使用しているリリース値（文字列および/または一連の数字）が使用されていることに注意してください（supportedLDAPVersionとは対照的に、このサーバー）。これは単一値であるため、バージョン値が1つしかありません。この文字列は、2つのバージョン間で一意でなければなりません (MUST)が、値またはフォーマットの方法に他の構文制限はありません。

( 1.3.6.1.1.5 NAME 'vendorVersion' EQUALITY 1.3.6.1.4.1.1466.109.114.1 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation )

（1.3.6.1.1.5名 'ベンダーバージョン'平等1.3.6.1.4.1.1466.109.114.1構文1.3.6.1.4.1.1466.115.121.1.1.15

The intent behind the equality match on vendorVersion is to not allow a less than or greater than type of query. Say release "LDAPv3 8.0" has a problem that is fixed in the next release "LDAPv3 8.5", but in the mean time there is also an update release say version "LDAPv3 8.01" that fixes the problem. This will hopefully stop the client from saying it will not work with a version less than "LDAPv3 8.5" when it would also work with "LDAPv3 8.01". With the equality match the client would have to exactly match what it is looking for.

vendorVersionの平等試合の背後にある意図は、クエリのタイプ以下を許可しないことです。「LDAPV3 8.0」のリリースには、次のリリース「LDAPV3 8.5」で修正された問題がありますが、その間に問題を修正するバージョン「LDAPV3 8.01」などの更新リリースもあります。これにより、クライアントが「LDAPV38.01」でも動作する場合、「LDAPV3 8.5」よりも少ないバージョンで動作しないと言うのを止めることができます。平等マッチを使用すると、クライアントが探しているものを正確に一致させる必要があります。

3. Notes to Server Implementers

3. サーバー実装者へのメモ

Server implementers may consider tying the vendorVersion attribute value to the build mechanism so that it is automatically updated when the version value changes.

サーバーの実装者は、バージョン値が変更されたときに自動的に更新されるように、ベンダーバージョン属性値をビルドメカニズムに結び付けることを検討する場合があります。

4. Notes to Client Developers

4. クライアント開発者へのメモ

As mentioned in section 2.1, the use of vendorName and vendorVersion MUST NOT be used to discover features.

セクション2.1で述べたように、vendorNameおよびvendorVersionの使用を使用して機能を発見するために使用してはなりません (MUST NOT)。

It should be noted that an anomalies often on affect subset of implementations reporting the same version information. Most implementations support multiple platforms, have numerous configuration options, and often support plug-ins.

多くの場合、同じバージョン情報を報告する実装のサブセットに影響を与えることが多いことに注意する必要があります。ほとんどの実装は、複数のプラットフォームをサポートし、多数の構成オプションがあり、多くの場合、プラグインをサポートしています。

Client implementations SHOULD be written in such a way as to accept any value in the vendorName and vendorVersion attributes. If a client implementation does not recognize the specific vendorName or vendorVersion as one it recognizes, then for the purposes of 'working around' anomalies, the client MUST assume that the server is complete and correct. The client MUST work with implementations that do not publish these attributes.

クライアントの実装は、vendorNameおよびvendorVersion属性の価値を受け入れるような方法で記述すべきです (SHOULD)。クライアントの実装が特定のvendorNameまたはvendorVersionを認識しているものとして認識していない場合、「回避」の異常を目的として、クライアントはサーバーが完全かつ正しいと想定しなければなりません (MUST)。クライアントは、これらの属性を公開していない実装で動作しなければなりません (MUST)。

5. Security Considerations

5. セキュリティに関する考慮事項

The vendorName and vendorVersion attributes are provided only as display or informational mechanisms, or as anomaly identifying mechanisms. Client and application implementers must consider that the existence of a given value in the vendorName or vendorVersion attribute is no guarantee that the server was actually built by the asserted vendor or that its version is the asserted version and should act accordingly.

vendorNameおよびvendorVersion属性は、ディスプレイまたは情報メカニズム、または異常識別メカニズムとしてのみ提供されます。クライアントとアプリケーションの実装者は、vendorNameまたはvendorVersion属性に特定の値の存在が、サーバーが実際に主張されたベンダーによって構築されたこと、またはそのバージョンが主張されたバージョンであり、それに応じて行動する必要があることを保証しないことを考慮する必要があります。

Server implementers should be aware that this information could be used to exploit a security hole a server provides either by feature or flaw.

サーバーの実装者は、この情報を使用して、サーバーが機能または欠陥によって提供するセキュリティホールを活用するために使用できることに注意する必要があります。

6. IANA Considerations

6. IANAの考慮事項

This document seeks to create two attributes, vendorName and vendorVersion, which the IANA will primarily be responsible. This is a one time effort; there is no need for any recurring assignment after this stage.

このドキュメントは、vendorNameとvendorVersionの2つの属性を作成しようとしています。これは、IANAが主に責任を負います。これは一度の努力です。この段階の後、繰り返しの割り当ては必要ありません。

7. References

7. 参考文献

[RFC2219] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2219] Bradner, S.、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[RFC2026] Bradner, S.、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。

[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997.

[RFC2251] Wahl, M., Howes, T. and S. Kille、「Lightweight Directory Access Protocol（V3）」、RFC 2251、1997年12月。

[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997.

[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille、「Lightweight Directory Access Protocol（V3）：属性構文定義」、RFC 2252、1997年12月。

8. Acknowledgments

8. 謝辞

The author would like to thank the generous input and review by individuals at Novell including but not limited to Jim Sermersheim, Mark Hinckley, Renea Campbell, and Roger Harrison. Also IETF contributors Kurt Zeilenga, Mark Smith, Mark Wahl, Peter Strong, Thomas Salter, Gordon Good, Paul Leach, Helmut Volpers.

著者は、Jim Sermersheim、Mark Hinckley、Renea Campbell、およびRoger Harrisonを含むがこれらに限定されない、Novellの個人による寛大な意見とレビューに感謝したいと思います。また、IETFの貢献者Kurt Zeilenga、Mark Smith、Mark Wahl、Peter Strong、Thomas Salter、Gordon Good、Paul Leach、Helmut Volpers。

9. Author's Address

9. 著者の連絡先

Mark Meredith Novell Inc. 1800 S. Novell Place Provo, UT 84606

Mark Meredith Novell Inc. 1800 S. Novell Place Provo、UT 84606

Phone: 801-861-2645 EMail: mark_meredith@novell.com

電話：801-861-2645メール：mark_meredith@novell.com

10. Full Copyright Statement

10. 完全な著作権声明

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.

この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFCエディター機能の資金は現在、インターネット協会によって提供されています。