RFC3045 日本語訳

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

コメントを求めるワーキンググループM.メレディスの要求をネットワークでつないでください: 3045年のノベル株式会社カテゴリ: 情報の2001年1月

            Storing Vendor Information in the LDAP root DSE

LDAP根のDSEのVendor情報を保存します。

Status of this Memo

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

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

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特有のEntry(DSE)に含まれるかもしれない2ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)の属性、vendorName、およびvendorVersionを指定します。 これらの2つの属性がRFC2251のセクション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.

これらの属性で保持された情報は、ディスプレイと情報の目的に使用するかもしれなくて、特徴広告か発見に使用してはいけません。

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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは中で説明されるように本書では解釈されることであるべきです。[RFC2219]

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サーバについて質問できるのは望ましいです。

Meredith                     Informational                      [Page 1]

RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001

メレディス情報[1ページ]のRFC3045LDAPは、売り主情報2001年1月に表示するためにDSEを根づかせます。

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.

'問題に取りかかってください'というそのような例外を使用できて、本書では定義された属性は、特定のサーバ実装を特定するのにクライアント実装によって使用されるかもしれません。

   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で定義されたServer特有のData Requirementsへの追加です。 関連構文は[RFC2252]のセクション4で定義されます。

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

サーバはvendorNameかvendorVersionへのアクセスを制限するかもしれません、そして、クライアントはこれらの属性が利用可能であると予想してはいけません。

2.1 vendorName

2.1 vendorName

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

この属性は一連を含んでいます。(それは、LDAPサーバimplementerの名前を表します)。

   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サーバ実装SHOULDはvendorNameを維持します。(一般に、vendorNameは「ノベルInc.」のようにLDAP Serverコードを書いた会社の名前です)。

      ( 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'平等1.3.6.1.4.1.1466.109.114.1構文1.3.6.1の.115の.121の.1の.15のただ一つの.4.1.1466価値のユーザ変更がない用法dSAOperation)

2.2 vendorVersion

2.2 vendorVersion

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

この属性はLDAPサーバ実装のバージョンを表すストリングを含んでいます。

Meredith                     Informational                      [Page 2]

RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001

メレディス情報[2ページ]のRFC3045LDAPは、売り主情報2001年1月に表示するためにDSEを根づかせます。

   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はvendorVersionを維持します。 通常、この値がLDAPサーバ製品(このサーバによってサポートされたLDAPプロトコルのバージョンを指定するsupportedLDAPVersionと対照的に)の開発者によって使用されたリリース値(ストリング、そして/または、一連の数から成る)であることに注意してください。 これは、それには1つのバージョン値しかないように、単一に評価されています。 このストリングは2つのバージョンの間でユニークであるに違いありませんが、他のどんな構文の制限も値かそれがフォーマットされる方法にありません。

      ( 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名前'vendorVersion'平等1.3.6.1.4.1.1466.109.114.1構文1.3.6.1の.115の.121の.1の.15のただ一つの.4.1.1466価値のユーザ変更がない用法dSAOperation)

   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の上の平等マッチの後ろの意図は質問で、より少ないかタイプよりすばらしいaを許容しないことです。 リリースを言ってください、「LDAPv3、8インチには次のリリースで修正されている問題がある、「LDAPv3、8.5インチにもかかわらず、その間にあって、また、アップデートリリースがバージョンを書く、「LDAPv3、問題を修正する8.01インチ、」 これによって、クライアントが、バージョンが、より少ない状態でそれが働かないと希望をいだいて言うことができない、「LDAPv3、8.5インチ、また、いつで働いているだろうか、「LDAPv3、8.01インチ、」 平等マッチと、クライアントはまさに、それが探しているものを合わせなければならないでしょう。

3. Notes to Server Implementers

3. サーバImplementersへの注意

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

サーバimplementersは、バージョン値が変化するとき、自動的にそれをアップデートするようにvendorVersion属性値を体格メカニズムに結ぶと考えるかもしれません。

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の使用は特徴を発見するのにおいて使用されているはずがありません。

   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.

クライアント実装SHOULD、vendorNameとvendorVersion属性におけるどんな値も受け入れるほどそのような方法で書かれてください。 クライアント実装が、特定のvendorNameかvendorVersionがそれが認識する1つであると認めないなら、'問題に取りかかり'例外の目的のために、クライアントは、サーバが完全であって、正しいと仮定しなければなりません。 クライアントはこれらの属性を発行しない実装で働かなければなりません。

Meredith                     Informational                      [Page 3]

RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001

メレディス情報[3ページ]のRFC3045LDAPは、売り主情報2001年1月に表示するためにDSEを根づかせます。

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属性を提供します。クライアントとアプリケーションimplementersは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.

サーバimplementersはサーバが特徴か欠点で提供するセキュリティーホールを利用するのにこの情報を使用できたのを意識しているべきです。

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.

(IANAはvendorVersionを作成するでしょう)。このドキュメントは主として2つの属性、vendorName、およびvendorVersionを作成しようとします。責任があってください。 これは1つの時間取り組みです。 この段階の後に、どんな再発課題の必要も全くありません。

7. References

7. 参照

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

[RFC2219] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」

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

[RFC2251]ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 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] ウォール、M.、Coulbeck、A.、ハウズ、T.、およびS.Kille、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「属性構文定義」、RFC2252、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.

入力された寛大に感謝します、そして、他のジムSermersheim、マーク・ヒンクリー、Reneaキャンベル、およびロジャー・ハリソンを含んでいて、作者はノベルで個人で論評したがっています。 IETF貢献者カートZeilenga、マーク・スミス、マーク・ウォール、ピーターStrong、トーマスSalter、ゴードンGood、ポール・リーチ、ヘルマットVolpersも。

Meredith                     Informational                      [Page 4]

RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001

メレディス情報[4ページ]のRFC3045LDAPは、売り主情報2001年1月に表示するためにDSEを根づかせます。

9. Author's Address

9. 作者のアドレス

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

マークメレディスノベル株式会社1800秒間ノベルPlaceプロボ(ユタ)84606

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

以下に電話をしてください。 801-861-2645 メールしてください: mark_meredith@novell.com

Meredith                     Informational                      [Page 5]

RFC 3045      LDAP Root DSE to Display Vendor Information   January 2001

メレディス情報[5ページ]のRFC3045LDAPは、売り主情報2001年1月に表示するためにDSEを根づかせます。

10. Full Copyright Statement

10. 完全な著作権宣言文

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

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

Meredith                     Informational                      [Page 6]

メレディスInformationalです。[6ページ]