RFC4512 日本語訳
4512 Lightweight Directory Access Protocol (LDAP): DirectoryInformation Models. K. Zeilenga, Ed.. June 2006. (Format: TXT=108377 bytes) (Obsoletes RFC2251, RFC2252, RFC2256, RFC3674) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Zeilenga Request for Comments: 4512 OpenLDAP Foundation Obsoletes: 2251, 2252, 2256, 3674 June 2006 Category: Standards Track
Zeilengaがコメントのために要求するワーキンググループK.をネットワークでつないでください: 4512年のOpenLDAP財団は以下を時代遅れにします。 2256、3674 2252、年2251、2006年6月のカテゴリ: 標準化過程
Lightweight Directory Access Protocol (LDAP):
Directory Information Models
ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP): ディレクトリ情報モデル
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
要約
The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document describes the X.500 Directory Information Models, as used in LDAP.
ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)は、X.500データとサービスモデルに従って行動する分配されたディレクトリサービスにアクセスするためのインターネットプロトコルです。 このドキュメントはLDAPで使用されるようにX.500ディレクトリ情報Modelsについて説明します。
Zeilenga Standards Track [Page 1] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[1ページ]。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Relationship to Other LDAP Specifications ..................3
1.2. Relationship to X.501 ......................................4
1.3. Conventions ................................................4
1.4. Common ABNF Productions ....................................4
2. Model of Directory User Information .............................6
2.1. The Directory Information Tree .............................7
2.2. Structure of an Entry ......................................7
2.3. Naming of Entries ..........................................8
2.4. Object Classes .............................................9
2.5. Attribute Descriptions ....................................12
2.6. Alias Entries .............................................16
3. Directory Administrative and Operational Information ...........17
3.1. Subtrees ..................................................17
3.2. Subentries ................................................18
3.3. The 'objectClass' attribute ...............................18
3.4. Operational Attributes ....................................19
4. Directory Schema ...............................................22
4.1. Schema Definitions ........................................23
4.2. Subschema Subentries ......................................32
4.3. 'extensibleObject' object class ...........................35
4.4. Subschema Discovery .......................................35
5. DSA (Server) Informational Model ...............................36
5.1. Server-Specific Data Requirements .........................36
6. Other Considerations ...........................................40
6.1. Preservation of User Information ..........................40
6.2. Short Names ...............................................41
6.3. Cache and Shadowing .......................................41
7. Implementation Guidelines ......................................42
7.1. Server Guidelines .........................................42
7.2. Client Guidelines .........................................42
8. Security Considerations ........................................43
9. IANA Considerations ............................................43
10. Acknowledgements ..............................................44
11. Normative References ..........................................45
Appendix A. Changes ...............................................47
A.1. Changes to RFC 2251 .......................................47
A.2. Changes to RFC 2252 .......................................49
A.3. Changes to RFC 2256 .......................................50
A.4. Changes to RFC 3674 .......................................51
1. 序論…3 1.1. 他のLDAP仕様との関係…3 1.2. X.501との関係…4 1.3. コンベンション…4 1.4. 一般的なABNF創作…4 2. ディレクトリユーザー情報のモデル…6 2.1. ディレクトリ情報木…7 2.2. エントリーの構造…7 2.3. エントリーの命名…8 2.4. クラスは反対します…9 2.5. 記述を結果と考えてください…12 2.6. 別名エントリー…16 3. ディレクトリの管理の、そして、操作上の情報…17 3.1. 下位木…17 3.2. 副次的記載…18 3.3. 'objectClass'属性…18 3.4. 操作上の属性…19 4. ディレクトリ図式…22 4.1. 図式定義…23 4.2. サブスキーマ副次的記載…32 4.3. 'extensibleObject'オブジェクトのクラス…35 4.4. サブスキーマ発見…35 5. DSAの(サーバ)情報のモデル…36 5.1. サーバ特有のデータ要件…36 6. 他の問題…40 6.1. ユーザー情報の保存…40 6.2. 短い名前…41 6.3. キャッシュとシャドウイング…41 7. 実装ガイドライン…42 7.1. サーバガイドライン…42 7.2. クライアントガイドライン…42 8. セキュリティ問題…43 9. IANA問題…43 10. 承認…44 11. 標準の参照…45 付録A.は変化します…47 A.1。 RFC2251への変化…47 A.2。 RFC2252への変化…49 A.3。 RFC2256への変化…50 A.4。 RFC3674への変化…51
Zeilenga Standards Track [Page 2] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[2ページ]。
1. Introduction
1. 序論
This document discusses the X.500 Directory Information Models [X.501], as used by the Lightweight Directory Access Protocol (LDAP) [RFC4510].
ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)[RFC4510]によって使用されるようにこのドキュメントはX.500ディレクトリ情報Models[X.501]について議論します。
The Directory is "a collection of open systems cooperating to provide directory services" [X.500]. The information held in the Directory is collectively known as the Directory Information Base (DIB). A Directory user, which may be a human or other entity, accesses the Directory through a client (or Directory User Agent (DUA)). The client, on behalf of the directory user, interacts with one or more servers (or Directory System Agents (DSA)). A server holds a fragment of the DIB.
ディレクトリは「ディレクトリサービスを提供するオープンシステム協力の収集」[X.500]です。 ディレクトリで保持された情報はディレクトリInformation基地(DIB)として一括して知られています。 ディレクトリユーザ(人間か他の実体であるかもしれない)はクライアント(または、ディレクトリUserエージェント(DUA))を通してディレクトリにアクセスします。 ディレクトリユーザを代表して、クライアントは1つ以上のサーバ(または、ディレクトリSystemエージェント(DSA))と対話します。 サーバはDIBの断片を支えます。
The DIB contains two classes of information:
DIBは2つの情報の種類を含みます:
1) user information (e.g., information provided and administrated
by users). Section 2 describes the Model of User Information.
1) ユーザー情報(例えばユーザによって提供されて、管理された情報)。 セクション2はUser情報のModelについて説明します。
2) administrative and operational information (e.g., information
used to administer and/or operate the directory). Section 3
describes the model of Directory Administrative and Operational
Information.
2) 管理の、そして、操作上の情報(例えば、情報は、ディレクトリを管理する、そして/または、以前はよく操作していました)。 セクション3はディレクトリAdministrativeとOperational情報のモデルについて説明します。
These two models, referred to as the generic Directory Information Models, describe how information is represented in the Directory. These generic models provide a framework for other information models. Section 4 discusses the subschema information model and subschema discovery. Section 5 discusses the DSA (Server) Informational Model.
ジェネリックディレクトリ情報Modelsと呼ばれたこれらの2つのモデルが情報がディレクトリでどう表されるかを説明します。 これらのジェネリックモデルは他の情報モデルにフレームワークを供給します。 セクション4はサブスキーマ情報モデルとサブスキーマ発見について論じます。 セクション5はDSA(サーバ)情報のModelについて論じます。
Other X.500 information models (such as access control distribution knowledge and replication knowledge information models) may be adapted for use in LDAP. Specification of how these models apply to LDAP is left to future documents.
他のX.500情報モデル(アクセス制御分配知識や模写知識情報モデルなどの)はLDAPにおける使用のために適合させられるかもしれません。 これらのモデルがどうLDAPに当てはまるかに関する仕様は将来のドキュメントに残されます。
1.1. Relationship to Other LDAP Specifications
1.1. 他のLDAP仕様との関係
This document is a integral part of the LDAP technical specification [RFC4510], which obsoletes the previously defined LDAP technical specification, RFC 3377, in its entirety.
このドキュメントはLDAP技術仕様書[RFC4510]の不可欠の部分です。(それは、以前に定義されたLDAP技術仕様書、RFC3377を全体として時代遅れにします)。
This document obsoletes RFC 2251, Sections 3.2 and 3.4, as well as portions of Sections 4 and 6. Appendix A.1 summarizes changes to these sections. The remainder of RFC 2251 is obsoleted by the [RFC4511], [RFC4513], and [RFC4510] documents.
このドキュメントはセクション4と6のRFC2251、セクション3.2と3.4、および一部を時代遅れにします。 付録A.1はこれらのセクションへの変化をまとめます。 RFC2251の残りは[RFC4511]、[RFC4513]、および[RFC4510]ドキュメントによって時代遅れにされます。
Zeilenga Standards Track [Page 3] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[3ページ]。
This document obsoletes RFC 2252, Sections 4, 5, and 7. Appendix A.2 summarizes changes to these sections. The remainder of RFC 2252 is obsoleted by [RFC4517].
このドキュメントはRFC2252、セクション4、5、および7を時代遅れにします。 付録A.2はこれらのセクションへの変化をまとめます。 RFC2252の残りは[RFC4517]によって時代遅れにされます。
This document obsoletes RFC 2256, Sections 5.1, 5.2, 7.1, and 7.2. Appendix A.3 summarizes changes to these sections. The remainder of RFC 2256 is obsoleted by [RFC4519] and [RFC4517].
このドキュメントはRFC2256、セクション5.1、5.2、7.1、および7.2を時代遅れにします。 付録A.3はこれらのセクションへの変化をまとめます。 RFC2256の残りは[RFC4519]と[RFC4517]によって時代遅れにされます。
This document obsoletes RFC 3674 in its entirety. Appendix A.4 summarizes changes since RFC 3674.
このドキュメントはRFC3674を全体として時代遅れにします。 付録A.4はRFC3674以来の変化をまとめます。
1.2. Relationship to X.501
1.2. X.501との関係
This document includes material, with and without adaptation, from [X.501] as necessary to describe this protocol. These adaptations (and any other differences herein) apply to this protocol, and only this protocol.
このドキュメントは、適合のあるなしにかかわらずこのプロトコルについて説明するために必要に応じて[X.501]から材料を含んでいます。 これらの適合、(いかなる他の違い、もここに)、このプロトコル、およびこのプロトコルだけに適用してください。
1.3. Conventions
1.3. コンベンション
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Schema definitions are provided using LDAP description formats (as defined in Section 4.1). Definitions provided here are formatted (line wrapped) for readability. Matching rules and LDAP syntaxes referenced in these definitions are specified in [RFC4517].
LDAP記述形式を使用することで(セクション4.1で定義されるように)図式定義を提供します。 ここに提供された定義は読み易さのためにフォーマットされます(包装された系列)。 これらの定義で参照をつけられる合っている規則とLDAP構文は[RFC4517]で指定されます。
1.4. Common ABNF Productions
1.4. 一般的なABNF創作
A number of syntaxes in this document are described using Augmented Backus-Naur Form (ABNF) [RFC4234]. These syntaxes (as well as a number of syntaxes defined in other documents) rely on the following common productions:
多くの構文が、Augmented BN記法(ABNF)[RFC4234]を使用することで本書では説明されます。 これらの構文(他のドキュメントで定義された多くの構文と同様に)は以下の一般的な創作を当てにします:
keystring = leadkeychar *keychar
leadkeychar = ALPHA
keychar = ALPHA / DIGIT / HYPHEN
number = DIGIT / ( LDIGIT 1*DIGIT )
アルファー/ DIGIT / HYPHEN leadkeychar*keychar leadkeychar=アルファーkeystring=keychar=番号はDIGIT/と等しいです。(LDIGIT1*ケタ)
ALPHA = %x41-5A / %x61-7A ; "A"-"Z" / "a"-"z"
DIGIT = %x30 / LDIGIT ; "0"-"9"
LDIGIT = %x31-39 ; "1"-"9"
HEX = DIGIT / %x41-46 / %x61-66 ; "0"-"9" / "A"-"F" / "a"-"f"
アルファー=%x41-5A/%x61-7A。 --「Z」/“a"--「z」ケタ=%x30 / LDIGIT。 「0インチ--」 9インチのLDIGIT=%x31-39。 「1インチ--」 9インチの十六進法はケタ/%x41-46/%x61-66と等しいです。 「0インチ--」 9インチ/「A」--「F」/“a"--「f」
SP = 1*SPACE ; one or more " "
WSP = 0*SPACE ; zero or more " "
SPは1*スペースと等しいです。 1以上、「「WSPは0*スペースと等しいです」。 ゼロか以上、「」
Zeilenga Standards Track [Page 4] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[4ページ]。
NULL = %x00 ; null (0)
SPACE = %x20 ; space (" ")
DQUOTE = %x22 ; quote (""")
SHARP = %x23 ; octothorpe (or sharp sign) ("#")
DOLLAR = %x24 ; dollar sign ("$")
SQUOTE = %x27 ; single quote ("'")
LPAREN = %x28 ; left paren ("(")
RPAREN = %x29 ; right paren (")")
PLUS = %x2B ; plus sign ("+")
COMMA = %x2C ; comma (",")
HYPHEN = %x2D ; hyphen ("-")
DOT = %x2E ; period (".")
SEMI = %x3B ; semicolon (";")
LANGLE = %x3C ; left angle bracket ("<")
EQUALS = %x3D ; equals sign ("=")
RANGLE = %x3E ; right angle bracket (">")
ESC = %x5C ; backslash ("\")
USCORE = %x5F ; underscore ("_")
LCURLY = %x7B ; left curly brace "{"
RCURLY = %x7D ; right curly brace "}"
ヌル=%x00。 ヌル(0)SPACE=%x20。 スペース、(「「)、DQUOTE=%x22;、」 引用始め、(「「「)、鋭い=%x23、」、。 シャープ記号(または、シャープ記号)(「#」)ドル=%x24。 ドル記号(「$」)SQUOTE=%x27。 ただ一つの引用文、(「'、「)、LPAREN=%x28;、」、' 左のparen、(「(「)、RPAREN=%x29(右のparen(「)」)と=%x2B)、」 (「+」)コンマ=%がx2Cであるとそのうえ、署名してください。 コンマ、(「」、)、=%x2Dをハイフンで結んでください。 (「-」)ドット=%x2Eをハイフンで結んでください。 以上、(「」、)、セミトレーラ=%x3B。 セミコロン、(「」、)、LANGLE=%x3C。 左の角ブラケット("<")は=%x3Dと等しいです。 同輩は、(「=」)RANGLE=%がx3Eであると署名します。 直角ブラケット(">")ESC=%x5C。 バックスラッシュ(「\」)USCORE=%x5F。 ("_")LCURLY=%x7Bの下線を引いてください。 「「RCURLYは%x7Dと等しいです; 正しい巻き毛の支柱」」巻き毛の支柱に残されて、
; Any UTF-8 [RFC3629] encoded Unicode [Unicode] character
UTF8 = UTF1 / UTFMB
UTFMB = UTF2 / UTF3 / UTF4
UTF0 = %x80-BF
UTF1 = %x00-7F
UTF2 = %xC2-DF UTF0
UTF3 = %xE0 %xA0-BF UTF0 / %xE1-EC 2(UTF0) /
%xED %x80-9F UTF0 / %xEE-EF 2(UTF0)
UTF4 = %xF0 %x90-BF 2(UTF0) / %xF1-F3 3(UTF0) /
%xF4 %x80-8F 2(UTF0)
; どんなUTF-8[RFC3629]もユニコード[ユニコード]キャラクタUTF8=UTF1 / UTFMB UTFMB=UTF2/UTF3/UTF4 UTF0=%x80-BF UTF1=%x00-7F UTF2=%xC2-DF UTF0 UTF3=%xE0%xA0-BF UTF0/%xE1EC2(UTF0)/%xED%x80-9F UTF0/%xEE-EF2(UTF0)UTF4=%xF0%x90-BF2(UTF0)/%xF1-F3 3(UTF0)/%xF4%x80-8F2をコード化しました。(UTF0)
OCTET = %x00-FF ; Any octet (8-bit data unit)
八重奏は%x00ffと等しいです。 どんな八重奏(8ビットのデータユニット)
Object identifiers (OIDs) [X.680] are represented in LDAP using a dot-decimal format conforming to the ABNF:
オブジェクト識別子(OIDs)[X.680]はABNFに従いながら、LDAPにドット小数形式を使用することで表されます:
numericoid = number 1*( DOT number )
numericoidはNo.1*と等しいです。(DOT番号)
Short names, also known as descriptors, are used as more readable aliases for object identifiers. Short names are case insensitive and conform to the ABNF:
また、記述子として知られている省略名はオブジェクト識別子により読み込み可能な別名として使用されます。 省略名は、大文字と小文字を区別しなく、ABNFに従います:
descr = keystring
descrはkeystringと等しいです。
Zeilenga Standards Track [Page 5] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[5ページ]。
Where either an object identifier or a short name may be specified, the following production is used:
オブジェクト識別子か省略名のどちらかが指定されるかもしれないところでは、以下の生産は使用されています:
oid = descr / numericoid
oidはdescr / numericoidと等しいです。
While the <descr> form is generally preferred when the usage is restricted to short names referring to object identifiers that identify like kinds of objects (e.g., attribute type descriptions, matching rule descriptions, object class descriptions), the <numericoid> form should be used when the object identifiers may identify multiple kinds of objects or when an unambiguous short name (descriptor) is not available.
オブジェクト識別子が複数の種類のオブジェクトを特定するかもしれないか、または明白な省略名(記述子)が利用可能でないときに、用法がオブジェクトの種類のように(例えば、属性型記述、合っている規則記述、オブジェクトクラス記述)を特定するオブジェクト識別子を示す省略名に制限されるとき、一般に、<descr>フォームが好まれている間、<numericoid>フォームは使用されるべきです。
Implementations SHOULD treat short names (descriptors) used in an ambiguous manner (as discussed above) as unrecognized.
実装SHOULDはあいまいな態度(上で議論するように)で認識されていないとして使用される省略名(記述子)を扱います。
Short Names (descriptors) are discussed further in Section 6.2.
セクション6.2で、より詳しく短いNames(記述子)について議論します。
2. Model of Directory User Information
2. ディレクトリユーザー情報のモデル
As [X.501] states:
[X.501]が述べるように:
The purpose of the Directory is to hold, and provide access to,
information about objects of interest (objects) in some 'world'.
An object can be anything which is identifiable (can be named).
興味があるオブジェクト(オブジェクト)の情報は、ディレクトリの目的が、'世界的に'で中にいくつか保つことになっていて、アクセスを提供します。 オブジェクトは何か身元保証可能な(命名できます)ものであるかもしれません。
An object class is an identified family of objects, or conceivable
objects, which share certain characteristics. Every object
belongs to at least one class. An object class may be a subclass
of other object classes, in which case the members of the former
class, the subclass, are also considered to be members of the
latter classes, the superclasses. There may be subclasses of
subclasses, etc., to an arbitrary depth.
オブジェクトのクラスはある特性を共有するオブジェクト、または想像できるオブジェクトの特定されたファミリーです。 あらゆるオブジェクトが少なくとも1つのクラスのものです。 オブジェクトのクラスは他のオブジェクトのクラスのサブクラスであるかもしれません、また前のクラスのメンバー(サブクラス)が後者のクラスのメンバーであると考えられるどの場合に、「スーパー-クラス」。 任意の深さへのサブクラスのサブクラスなどがあるかもしれません。
A directory entry, a named collection of information, is the basic unit of information held in the Directory. There are multiple kinds of directory entries.
ディレクトリエントリ(情報の命名された収集)はディレクトリで保持された情報の原単位です。 複数の種類のディレクトリエントリーがあります。
An object entry represents a particular object. An alias entry provides alternative naming. A subentry holds administrative and/or operational information.
オブジェクトエントリーは特定のオブジェクトを表します。 別名エントリーは代替の命名を提供します。 副次的記載は管理の、そして/または、操作上の情報を保持します。
The set of entries representing the DIB are organized hierarchically in a tree structure known as the Directory Information Tree (DIT).
DIBを表すエントリーのセットは階層的でディレクトリ情報Tree(DIT)として知られている木構造で組織化されます。
Section 2.1 describes the Directory Information Tree. Section 2.2 discusses the structure of entries. Section 2.3 discusses naming of entries.
セクション2.1はディレクトリ情報Treeについて説明します。 セクション2.2はエントリーの構造について論じます。 セクション2.3は、エントリーについて命名すると論じます。
Zeilenga Standards Track [Page 6] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[6ページ]。
Section 2.4 discusses object classes. Section 2.5 discusses attribute descriptions. Section 2.6 discusses alias entries.
セクション2.4はオブジェクトのクラスについて論じます。 セクション2.5は属性記述について論じます。 セクション2.6は別名エントリーについて論じます。
2.1. The Directory Information Tree
2.1. ディレクトリ情報木
As noted above, the DIB is composed of a set of entries organized hierarchically in a tree structure known as the Directory Information Tree (DIT); specifically, a tree where vertices are the entries.
上で述べたように、DIBは階層的でディレクトリ情報Tree(DIT)として知られている木構造で組織化された1セットのエントリーで構成されます。 明確に頭頂がエントリーである木。
The arcs between vertices define relations between entries. If an arc exists from X to Y, then the entry at X is the immediate superior of Y, and Y is the immediate subordinate of X. An entry's superiors are the entry's immediate superior and its superiors. An entry's subordinates are all of its immediate subordinates and their subordinates.
頭頂の間のアークはエントリーでの関係を定義します。 アークがXからYまで存在しているなら、XのエントリーはYの即座の上司です、そして、YはX.の即座の部下です。Anエントリーの上司は、エントリーの即座の上司とその上司です。 エントリーの部下は、即座の部下のすべてと彼らの部下です。
Similarly, the superior/subordinate relationship between object entries can be used to derive a relation between the objects they represent. DIT structure rules can be used to govern relationships between objects.
同様に、彼らが表すオブジェクトの関係を引き出すのにオブジェクトエントリーの間の優れたか下位の関係を使用できます。 オブジェクトの間の関係を治めるのにDIT構造規則を使用できます。
Note: An entry's immediate superior is also known as the entry's
parent, and an entry's immediate subordinate is also known as
the entry's child. Entries that have the same parent are known
as siblings.
以下に注意してください。 また、エントリーの即座の上司はエントリーの親として知られています、そして、また、エントリーの即座の部下はエントリーの子供として知られています。 同じ親がいるエントリーは兄弟として知られています。
2.2. Structure of an Entry
2.2. エントリーの構造
An entry consists of a set of attributes that hold information about the object that the entry represents. Some attributes represent user information and are called user attributes. Other attributes represent operational and/or administrative information and are called operational attributes.
エントリーはエントリーが表すオブジェクトの情報を保持する1セットの属性から成ります。 いくつかの属性が、ユーザー情報を表して、ユーザ属性と呼ばれます。 他の属性が表す、操作上、管理情報、呼ばれた操作上の属性はそうです。
An attribute is an attribute description (a type and zero or more options) with one or more associated values. An attribute is often referred to by its attribute description. For example, the 'givenName' attribute is the attribute that consists of the attribute description 'givenName' (the 'givenName' attribute type [RFC4519] and zero options) and one or more associated values.
属性は1つ以上の関連値がある属性記述(タイプとゼロか、より多くのオプション)です。 属性記述で属性はしばしば言及されます。 例えば、'givenName'属性は属性記述'givenName'('givenName'属性タイプ[RFC4519]にもかかわらず、オプションがない)と1か、より関連した値から成る属性です。
The attribute type governs whether the attribute can have multiple values, the syntax and matching rules used to construct and compare values of that attribute, and other functions. Options indicate subtypes and other functions.
属性タイプは、その属性、および他の機能の値を構成して、比較するために属性で複数の値、構文、および合っている規則を使用できるかどうかを治めます。 オプションは血液型亜型と他の機能を示します。
Attribute values conform to the defined syntax of the attribute type.
属性値は属性タイプの定義された構文に従います。
Zeilenga Standards Track [Page 7] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[7ページ]。
No two values of an attribute may be equivalent. Two values are considered equivalent if and only if they would match according to the equality matching rule of the attribute type. Or, if the attribute type is defined with no equality matching rule, two values are equivalent if and only if they are identical. (See 2.5.1 for other restrictions.)
属性のいいえtwo、値は同等であるかもしれません。 そして、2つの値が同等であると考えられる、属性の平等の合っている規則に従って合っている場合にだけ、タイプしてください。 そして、または、属性タイプが平等の合っている規則なしで定義されるなら、2つの値が同等である、それらが同じである場合にだけ。 (他の制限に関して2.5に.1を見てください。)
For example, a 'givenName' attribute can have more than one value, they must be Directory Strings, and they are case insensitive. A 'givenName' attribute cannot hold both "John" and "JOHN", as these are equivalent values per the equality matching rule of the attribute type.
例えば、'givenName'属性は1つ以上の値を持つことができます、そして、それらはディレクトリStringsであるに違いありません、そして、彼らは大文字と小文字を区別しないです。 'givenName'属性は「ジョン」と「ジョン」の両方を保持できません、属性タイプの平等の合っている規則あたりこれらが同等な値であるので。
Additionally, no attribute is to have a value that is not equivalent to itself. For example, the 'givenName' attribute cannot have as a value a directory string that includes the REPLACEMENT CHARACTER (U+FFFD) code point, as matching involving that directory string is Undefined per this attribute's equality matching rule.
さらに、どんな属性もそれ自体に同等でない値を持たないことです。 例えば、'givenName'属性は値としてディレクトリストリングがこの属性の平等の合っている規則あたりUndefinedであるというかかわることを合わせるとしてのREPLACEMENT CHARACTER(U+FFFD)コード・ポイントを含んでいるディレクトリストリングを持つことができません。
When an attribute is used for naming of the entry, one and only one value of the attribute is used in forming the Relative Distinguished Name. This value is known as a distinguished value.
属性がエントリーの命名に使用されるとき、属性の唯一無二の1つの値がRelative Distinguished Nameを形成する際に使用されます。 この値は顕著な値として知られています。
2.3. Naming of Entries
2.3. エントリーの命名
2.3.1. Relative Distinguished Names
2.3.1. 相対的な分類名
Each entry is named relative to its immediate superior. This relative name, known as its Relative Distinguished Name (RDN) [X.501], is composed of an unordered set of one or more attribute value assertions (AVA) consisting of an attribute description with zero options and an attribute value. These AVAs are chosen to match attribute values (each a distinguished value) of the entry.
各エントリーは即座の上司に比例して命名されます。 Relative Distinguished Name(RDN)[X.501]として知られているこの相対的な名前は1つ以上の属性値主張(AVA)がオプションがなくて属性値で属性記述から成る順不同のセットで構成されます。 これらはエントリーの値(各aは値を区別した)をマッチの結果と考えますAVAsが選ばれている。
An entry's relative distinguished name must be unique among all immediate subordinates of the entry's immediate superior (i.e., all siblings).
エントリーの相対的な分類名はエントリーの即座の上司(すなわちすべての兄弟)のすべての即座の部下の中でユニークであるに違いありません。
The following are examples of string representations of RDNs [RFC4514]:
↓これはRDNs[RFC4514]のストリング表現に関する例です:
UID=12345
OU=Engineering
CN=Kurt Zeilenga+L=Redwood Shores
工学UID=12345 OU=CNはアカスギカートZeilenga+L=岸と等しいです。
The last is an example of a multi-valued RDN; that is, an RDN composed of multiple AVAs.
最終はマルチ評価されたRDNに関する例です。 すなわち、RDNは複数のAVAsで構成しました。
Zeilenga Standards Track [Page 8] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[8ページ]。
2.3.2. Distinguished Names
2.3.2. 分類名
An entry's fully qualified name, known as its Distinguished Name (DN) [X.501], is the concatenation of its RDN and its immediate superior's DN. A Distinguished Name unambiguously refers to an entry in the tree. The following are examples of string representations of DNs [RFC4514]:
Distinguished Name(DN)[X.501]として知られているエントリーの完全に修飾された名前はRDNとその即座の上司のDNの連結です。 Distinguished Nameは明白に木のエントリーについて言及します。 ↓これはDNs[RFC4514]のストリング表現に関する例です:
UID=nobody@example.com,DC=example,DC=com
CN=John Smith,OU=Sales,O=ACME Limited,L=Moab,ST=Utah,C=US
○ = UIDは nobody@example.com と等しく、DCは例と等しく、DC=com CNはジョン・スミスと等しく、OUは販売と等しく、頂上株式会社、L==第モアブ(ユタ)Cは米国と等しいです。
2.3.3. Alias Names
2.3.3. 別名
An alias, or alias name, is "an name for an object, provided by the use of alias entries" [X.501]. Alias entries are described in Section 2.6.
別名、または別名が「別名エントリーの使用で提供されたオブジェクトのための名前」[X.501]です。 別名エントリーはセクション2.6で説明されます。
2.4. Object Classes
2.4. オブジェクトのクラス
An object class is "an identified family of objects (or conceivable objects) that share certain characteristics" [X.501].
オブジェクトのクラスは「ある特性を共有するオブジェクト(または、想像できるオブジェクト)の特定されたファミリー」[X.501]です。
As defined in [X.501]:
[X.501]で定義されるように:
Object classes are used in the Directory for a number of purposes:
オブジェクトのクラスは多くの目的にディレクトリに使用されます:
- describing and categorizing objects and the entries that
correspond to these objects;
- これらのオブジェクトに対応する説明、オブジェクトを分類して、およびエントリー。
- where appropriate, controlling the operation of the Directory;
- 適切であるところではディレクトリの操作を制御すること。
- regulating, in conjunction with DIT structure rule
specifications, the position of entries in the DIT;
- DIT構造規則仕様に関連して、DITでエントリーの位置を規制します。
- regulating, in conjunction with DIT content rule
specifications, the attributes that are contained in entries;
- DITの満足している規則仕様に関連して、エントリーに保管されている属性を規制します。
- identifying classes of entry that are to be associated with a
particular policy by the appropriate administrative authority.
- 適切な職務権限で特定の方針に関連させていることになっているエントリーのクラスを特定します。
An object class (a subclass) may be derived from an object class
(its direct superclass) which is itself derived from an even more
generic object class. For structural object classes, this process
stops at the most generic object class, 'top' (defined in Section
2.4.1). An ordered set of superclasses up to the most superior
object class of an object class is its superclass chain.
それ自体で同等の以上から派生しているジェネリックオブジェクトのクラスであるオブジェクトのクラス(ダイレクト「スーパー-クラス」)からオブジェクトのクラス(サブクラス)を得るかもしれません。 構造的なオブジェクトのクラスのために、このプロセスは'最高(セクション2.4.1では、定義される)'の最も多くのジェネリックオブジェクトのクラスに止まります。 最も優れたオブジェクトオブジェクトのクラスのクラスまでの「スーパー-クラス」の1つの順序集合がその「スーパー-クラス」チェーンです。
Zeilenga Standards Track [Page 9] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[9ページ]。
An object class may be derived from two or more direct
superclasses (superclasses not part of the same superclass chain).
This feature of subclassing is termed multiple inheritance.
2以上のダイレクト「スーパー-クラス」(部分ではなく、同じ「スーパー-クラス」チェーンの「スーパー-クラス」)からオブジェクトのクラスを得るかもしれません。 副分類のこの特徴は複数の継承と呼ばれます。
Each object class identifies the set of attributes required to be present in entries belonging to the class and the set of attributes allowed to be present in entries belonging to the class. As an entry of a class must meet the requirements of each class it belongs to, it can be said that an object class inherits the sets of allowed and required attributes from its superclasses. A subclass can identify an attribute allowed by its superclass as being required. If an attribute is a member of both sets, it is required to be present.
それぞれのオブジェクトのクラスは、クラスに属しながら、エントリーでクラスに属しながらエントリーに存在しているのが必要である属性のセットと存在しているのを許容された属性のセットを特定します。 クラスのエントリーがそれが属すそれぞれのクラスに関する必要条件を満たさなければならないとき、オブジェクトのクラスが「スーパー-クラス」から許容されて必要な属性のセットを引き継ぐと言うことができます。 サブクラスは、「スーパー-クラス」によって許容された属性が必要であることであると認識できます。 属性が両方のセットのメンバーであるなら、それが、存在しているのに必要です。
Each object class is defined to be one of three kinds of object classes: Abstract, Structural, or Auxiliary.
それぞれのオブジェクトのクラスは3種類のオブジェクトのクラスの1つになるように定義されます: 抽象的であるか、構造的であるか、または補助しています。
Each object class is identified by an object identifier (OID) and, optionally, one or more short names (descriptors).
オブジェクト識別子(OID)と任意に1つ以上の省略名(記述子)によってそれぞれのオブジェクトのクラスは特定されます。
2.4.1. Abstract Object Classes
2.4.1. 抽象的なオブジェクトのクラス
An abstract object class, as the name implies, provides a base of characteristics from which other object classes can be defined to inherit from. An entry cannot belong to an abstract object class unless it belongs to a structural or auxiliary class that inherits from that abstract class.
名前が含意するように抽象的なオブジェクトのクラスは他のオブジェクトのクラスを定義できる特性の世襲するベースを供給します。 その抽象クラスから世襲される構造的であるか補助のクラスに属さない場合、エントリーは抽象的なオブジェクトのクラスに属すことができません。
Abstract object classes cannot derive from structural or auxiliary object classes.
抽象的なオブジェクトのクラスは構造的であるか補助のオブジェクトからクラスを引き出すことができません。
All structural object classes derive (directly or indirectly) from the 'top' abstract object class. Auxiliary object classes do not necessarily derive from 'top'.
すべての構造的なオブジェクトのクラスが'先端'から抽象的なオブジェクトのクラスを引き出します(直接か間接的に)。 補助のオブジェクトのクラスが必ず'先端'に由来しているというわけではありません。
The following is the object class definition (see Section 4.1.1) for the 'top' object class:
↓これは'最高'のオブジェクトのクラスのためのオブジェクトクラス定義(セクション4.1.1を見る)です:
( 2.5.6.0 NAME 'top' ABSTRACT MUST objectClass )
(2.5要約がそうしなければならない.6.0名前'先端'objectClass)
All entries belong to the 'top' abstract object class.
すべてのエントリーが'最高'の抽象的なオブジェクトのクラスに属します。
Zeilenga Standards Track [Page 10] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[10ページ]。
2.4.2. Structural Object Classes
2.4.2. 構造的なオブジェクトのクラス
As stated in [X.501]:
[X.501]に述べられているように:
An object class defined for use in the structural specification of
the DIT is termed a structural object class. Structural object
classes are used in the definition of the structure of the names
of the objects for compliant entries.
DITの構造的な仕様に基づく使用のために定義されたオブジェクトのクラスは構造的なオブジェクトのクラスと呼ばれます。 構造的なオブジェクトのクラスは言いなりになっているエントリーにオブジェクトの名前の構造の定義に使用されます。
An object or alias entry is characterized by precisely one
structural object class superclass chain which has a single
structural object class as the most subordinate object class.
This structural object class is referred to as the structural
object class of the entry.
オブジェクトか通称エントリーが正確に最も下位のオブジェクトのクラスとして1つの構造的なオブジェクトのクラスを持っている1つの構造的なオブジェクトクラス「スーパー-クラス」チェーンによって特徴付けられます。 この構造的なオブジェクトのクラスはエントリーの構造的なオブジェクトのクラスと呼ばれます。
Structural object classes are related to associated entries:
構造的なオブジェクトのクラスは関連エントリーに関連します:
- an entry conforming to a structural object class shall
represent the real-world object constrained by the object
class;
- 構造的なオブジェクトのクラスに従うエントリーはオブジェクトのクラスによって抑制された本当の世界オブジェクトを表すものとします。
- DIT structure rules only refer to structural object classes;
the structural object class of an entry is used to specify the
position of the entry in the DIT;
- DIT構造規則は構造的なオブジェクトのクラスについて言及するだけです。 エントリーの構造的なオブジェクトのクラスはDITでエントリーの位置を指定するのに使用されます。
- the structural object class of an entry is used, along with an
associated DIT content rule, to control the content of an
entry.
- エントリーの構造的なオブジェクトのクラスは、エントリーの内容を制御するのに関連DIT満足している規則と共に使用されます。
The structural object class of an entry shall not be changed.
エントリーの構造的なオブジェクトのクラスを変えないものとします。
Each structural object class is a (direct or indirect) subclass of the 'top' abstract object class.
それぞれの構造的なオブジェクトのクラスは'最高'の抽象的なオブジェクトのクラスの(直接か間接的)のサブクラスです。
Structural object classes cannot subclass auxiliary object classes.
構造的なオブジェクトのクラスはサブクラスの補助のオブジェクトのクラスをそうすることができません。
Each entry is said to belong to its structural object class as well as all classes in its structural object class's superclass chain.
各エントリーは構造的なオブジェクトのクラスsの「スーパー-クラス」チェーンにおけるすべてのクラスと同様に構造的なオブジェクトのクラスに属すと言われています。
2.4.3. Auxiliary Object Classes
2.4.3. 補助のオブジェクトのクラス
Auxiliary object classes are used to augment the characteristics of entries. They are commonly used to augment the sets of attributes required and allowed to be present in an entry. They can be used to describe entries or classes of entries.
補助のオブジェクトのクラスは、エントリーの特性を増大させるのに使用されます。 それらはエントリーで存在しているのが必要であり、許容された属性のセットを増大させるのにおいて一般的に使用されています。 エントリーのエントリーかクラスについて説明するのにそれらを使用できます。
Auxiliary object classes cannot subclass structural object classes.
補助のオブジェクトのクラスはサブクラスの構造的なオブジェクトのクラスをそうすることができません。
Zeilenga Standards Track [Page 11] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[11ページ]。
An entry can belong to any subset of the set of auxiliary object classes allowed by the DIT content rule associated with the structural object class of the entry. If no DIT content rule is associated with the structural object class of the entry, the entry cannot belong to any auxiliary object class.
エントリーはエントリーの構造的なオブジェクトのクラスに関連しているDIT満足している規則で許容された補助のオブジェクトのクラスのセットのどんな部分集合にも属すことができます。 どんなDITの満足している規則もエントリーの構造的なオブジェクトのクラスに関連していないなら、エントリーはどんな補助のオブジェクトのクラスにも属すことができません。
The set of auxiliary object classes that an entry belongs to can change over time.
エントリーが属す補助のオブジェクトのクラスのセットは時間がたつにつれて、変化できます。
2.5. Attribute Descriptions
2.5. 属性記述
An attribute description is composed of an attribute type (see Section 2.5.1) and a set of zero or more attribute options (see Section 2.5.2).
属性記述は属性タイプで構成されます、そして、(セクション2.5.1を見てください)1セットのゼロか以上がオプションを結果と考えます(セクション2.5.2を見てください)。
An attribute description is represented by the ABNF:
属性記述はABNFによって表されます:
attributedescription = attributetype options
attributetype = oid
options = *( SEMI option )
option = 1*keychar
*(SEMIオプション)oid attributetypeオプションattributedescription=attributetype=オプション=オプションは1*keycharと等しいです。
where <attributetype> identifies the attribute type and each <option> identifies an attribute option. Both <attributetype> and <option> productions are case insensitive. The order in which <option>s appear is irrelevant. That is, any two <attributedescription>s that consist of the same <attributetype> and same set of <option>s are equivalent.
<attributetype>が属性を特定するところでは、タイプしてください。そうすれば、それぞれの<オプション>は属性オプションを特定します。 <attributetype>と<オプション>創作の両方が大文字と小文字を区別しないです。 <オプション>sが現れるオーダーは無関係です。 同じ<attributetype>と同じセットの<オプション>sから成るすなわちどんな2<attributedescription>sも同等です。
Examples of valid attribute descriptions:
有効な属性記述に関する例:
2.5.4.0
cn;lang-de;lang-en
owner
2.5.4.0 cn; lang-de; lang-アン所有者
An attribute description with an unrecognized attribute type is to be treated as unrecognized. Servers SHALL treat an attribute description with an unrecognized attribute option as unrecognized. Clients MAY treat an unrecognized attribute option as a tagging option (see Section 2.5.2.1).
認識されていない属性タイプとの属性記述は認識されていないとして扱われることです。 認識されていない属性オプションが認識されていない状態でサーバSHALLは属性記述を扱います。 セクション2.5を見てください。クライアントが認識されていない属性オプションをタグ付けオプションとして扱うかもしれない、(.2 .1)。
All attributes of an entry must have distinct attribute descriptions.
エントリーのすべての属性に、異なった属性記述がなければなりません。
2.5.1. Attribute Types
2.5.1. 属性タイプ
An attribute type governs whether the attribute can have multiple values, the syntax and matching rules used to construct and compare values of that attribute, and other functions.
属性タイプは、その属性、および他の機能の値を構成して、比較するために属性で複数の値、構文、および合っている規則を使用できるかどうかを治めます。
Zeilenga Standards Track [Page 12] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[12ページ]。
If no equality matching is specified for the attribute type:
平等でないなら、マッチングは属性タイプに指定されます:
- the attribute (of the type) cannot be used for naming;
- when adding the attribute (or replacing all values), no two
values may be equivalent (see 2.2);
- individual values of a multi-valued attribute are not to be
independently added or deleted;
- attribute value assertions (such as matching in search filters
and comparisons) using values of such a type cannot be
performed.
- 命名に、属性(タイプの)を使用できません。 - 属性(すべての値を取り替えて)、いいえと言い足すとき、2つの値が同等であるかもしれません(2.2を見てください)。 - マルチ評価された属性の個人価値は、独自に加えられないで、また削除されないことです。 - そのようなタイプの値を使用する属性値主張(検索フィルタと比較で合うことなどの)は実行できません。
Otherwise, the specified equality matching rule is to be used to evaluate attribute value assertions concerning the attribute type. The specified equality rule is to be transitive and commutative.
さもなければ、指定された平等合っている規則は属性タイプに関して属性値主張を評価するのに使用されることです。 指定された平等規則は、遷移的であって、交換可能であることです。
The attribute type indicates whether the attribute is a user attribute or an operational attribute. If operational, the attribute type indicates the operational usage and whether or not the attribute is modifiable by users. Operational attributes are discussed in Section 3.4.
属性タイプは、属性がユーザ属性かそれとも操作上の属性であるかを示します。 操作上であるなら、属性タイプは、操作上の用法であって属性がユーザが修正できるかどうかを示します。 セクション3.4で操作上の属性について議論します。
An attribute type (a subtype) may derive from a more generic attribute type (a direct supertype). The following restrictions apply to subtyping:
属性タイプ(「副-タイプ」)はaから、より多くのジェネリック属性タイプ(ダイレクト「スーパー-タイプ」)を引き出すかもしれません。 以下の制限は副タイプに適用されます:
- a subtype must have the same usage as its direct supertype,
- a subtype's syntax must be the same, or a refinement of, its
supertype's syntax, and
- a subtype must be collective [RFC3671] if its supertype is
collective.
- そして、「副-タイプ」には、ダイレクト「スーパー-タイプ」と同じ用法がなければなりません--「副-タイプ」の構文が同じくらい、または気品であるに違いない、「スーパー-タイプ」の構文、--「スーパー-タイプ」が集合的であるなら、「副-タイプ」は集合的であるに違いありません[RFC3671]。
An attribute description consisting of a subtype and no options is said to be the direct description subtype of the attribute description consisting of the subtype's direct supertype and no options.
「副-タイプ」にもかかわらず、オプションがないのから成る属性記述は「副-タイプ」のダイレクト「スーパー-タイプ」にもかかわらず、オプションがないのから成る属性記述のダイレクト記述「副-タイプ」であると言われています。
Each attribute type is identified by an object identifier (OID) and, optionally, one or more short names (descriptors).
オブジェクト識別子(OID)と任意に1つ以上の省略名(記述子)によって各属性タイプは特定されます。
2.5.2. Attribute Options
2.5.2. 属性オプション
There are multiple kinds of attribute description options. The LDAP technical specification details one kind: tagging options.
複数の種類の属性記述オプションがあります。 LDAP技術仕様書は1種類について詳述します: オプションにタグ付けをします。
Not all options can be associated with attributes held in the directory. Tagging options can be.
ディレクトリに保持される属性にすべてのオプションを関連づけることができるというわけではありません。 タグ付けオプションはそうであることができます。
Zeilenga Standards Track [Page 13] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[13ページ]。
Not all options can be used in conjunction with all attribute types. In such cases, the attribute description is to be treated as unrecognized.
すべての属性タイプに関連してすべてのオプションを使用できるというわけではありません。 そのような場合、属性記述は認識されていないとして扱われることです。
An attribute description that contains mutually exclusive options shall be treated as unrecognized. That is, "cn;x-bar;x-foo", where "x-foo" and "x-bar" are mutually exclusive, is to be treated as unrecognized.
互いに排他的なオプションを含む属性記述は認識されていないとして扱われるものとします。 すなわち、「cn; x-バー; x-foo」は認識されていないとして"x-foo"と「x-バー」が互いに排他的であるところに扱われることになっています。
Other kinds of options may be specified in future documents. These documents must detail how new kinds of options they define relate to tagging options. In particular, these documents must detail whether or not new kinds of options can be associated with attributes held in the directory, how new kinds of options affect transfer of attribute values, and how new kinds of options are treated in attribute description hierarchies.
他の種類のオプションは将来のドキュメントで指定されるかもしれません。 これらのドキュメントはそれらが定義するオプションの新しい種類がどうタグ付けオプションに関連するかを詳しく述べなければなりません。 特に、これらのドキュメントは、新しい種類のオプションがどう属性値と、新しい種類のオプションが属性記述階層構造でどう扱われるかに関する転送に影響するかというディレクトリに保持された属性に新しい種類のオプションを関連づけることができるかどうかを詳しく述べなければなりません。
Options are represented as short, case-insensitive textual strings conforming to the <option> production defined in Section 2.5 of this document.
大文字と小文字を区別しない原文のストリングがこのドキュメントのセクション2.5で定義された<オプション>生産に一致していて、オプションは短いとして表されます。
Procedures for registering options are detailed in BCP 64, RFC 4520 [RFC4520].
登録オプションのための手順はBCP64、RFC4520[RFC4520]で詳細です。
2.5.2.1. Tagging Options
2.5.2.1. タグ付けオプション
Attributes held in the directory can have attribute descriptions with any number of tagging options. Tagging options are never mutually exclusive.
ディレクトリに保持された属性はいろいろなタグ付けオプションによる属性記述を持つことができます。 タグ付けオプションは互いに決して排他的ではありません。
An attribute description with N tagging options is a direct
(description) subtype of all attribute descriptions of the same
attribute type and all but one of the N options. If the attribute
type has a supertype, then the attribute description is also a direct
(description) subtype of the attribute description of the supertype
and the N tagging options. That is, 'cn;lang-de;lang-en' is a direct
(description) subtype of 'cn;lang-de', 'cn;lang-en', and
'name;lang-de;lang-en' ('cn' is a subtype of 'name'; both are defined
in [RFC4519]).
Nタグ付けオプションによる属性記述は同じ属性タイプとNオプションの1つ以外のすべてのすべての属性記述のダイレクトな(記述)「副-タイプ」です。 属性タイプが「スーパー-タイプ」を持っているなら、また、属性記述は「スーパー-タイプ」の属性記述とNタグ付けオプションのダイレクトな(記述)「副-タイプ」です。 すなわち、'cn; lang-de; lang-アン、'cnに'ダイレクト(記述)は'cnの「副-タイプ」です; lang-de'; lang-アンと、''名; lang-de; lang-アン'('cn'は'名前'の「副-タイプ」です; [RFC4519]でともに定義されます)
2.5.3. Attribute Description Hierarchies
2.5.3. 属性記述階層構造
An attribute description can be the direct subtype of zero or more other attribute descriptions as indicated by attribute type subtyping (as described in Section 2.5.1) or attribute tagging option subtyping (as described in Section 2.5.2.1). These subtyping relationships are used to form hierarchies of attribute descriptions and attributes.
属性記述はゼロのダイレクト「副-タイプ」であるかもしれませんか属性によって示される他の、より多くの属性記述が副タイプ(セクション2.5.1で説明されるように)か属性タグ付けオプション副タイプをタイプします(セクション2.5.2で.1について説明するので)。 関係を副タイプするこれらは、属性記述と属性の階層構造を形成するのに使用されます。
Zeilenga Standards Track [Page 14] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[14ページ]。
As adapted from [X.501]:
[X.501]から適合させられるように:
Attribute hierarchies allow access to the DIB with varying degrees
of granularity. This is achieved by allowing the value components
of attributes to be accessed by using either their specific
attribute description (a direct reference to the attribute) or a
more generic attribute description (an indirect reference).
属性階層構造は異なった度合いの粒状でDIBへのアクセスを許します。 これは、彼らの明確な属性記述(属性の直接的な言及)を使用することによってアクセスされるべき属性のコンポーネントを値に許容するか、または、より多くのジェネリック属性記述(間接的な言及)をaに許容することによって、達成されます。
Semantically related attributes may be placed in a hierarchical
relationship, the more specialized being placed subordinate to the
more generalized. Searching for or retrieving attributes and
their values is made easier by quoting the more generalized
attribute description; a filter item so specified is evaluated for
the more specialized descriptions as well as for the quoted
description.
意味的に関連する属性は上下関係、より多くへの置かれた部下が一般化したより専門化している存在に置かれるかもしれません。 さらに一般化された属性記述を引用することによって、属性とそれらの値を捜し求めるか、または検索するのをより簡単にします。 そのように指定されたフィルタの品目は、より専門化している記述と引用された記述のために評価されます。
Where subordinate specialized descriptions are selected to be
returned as part of a search result these descriptions shall be
returned if available. Where the more general descriptions are
selected to be returned as part of a search result both the
general and the specialized descriptions shall be returned, if
available. An attribute value shall always be returned as a value
of its own attribute description.
下位の専門化している記述が検索結果の一部として返されるのが選択されるところに、利用可能であるなら、これらの記述を返すものとします。 一部の検索結果の両方として、より一般的な記述が返されるのが選択されるところでは、一般的な記述と専門化している記述は、返して、利用可能になるでしょう。 属性値はそれ自身の属性記述の値としていつも返されるものとします。
All of the attribute descriptions in an attribute hierarchy are
treated as distinct and unrelated descriptions for user
modification of entry content.
属性階層構造における属性記述のすべてがエントリー内容のユーザ変更のための異なって関係ない記述として扱われます。
An attribute value stored in an object or alias entry is of
precisely one attribute description. The description is indicated
when the value is originally added to the entry.
オブジェクトか通称エントリーに保存された属性値は正確に1つの属性記述のものです。 価値が元々エントリーに高められるとき、記述は示されます。
For the purpose of subschema administration of the entry, a specification that an attribute is required is fulfilled if the entry contains a value of an attribute description belonging to an attribute hierarchy where the attribute type of that description is the same as the required attribute's type. That is, a "MUST name" specification is fulfilled by 'name' or 'name;x-tag-option', but is not fulfilled by 'CN' or 'CN;x-tag-option' (even though 'CN' is a subtype of 'name'). Likewise, an entry may contain a value of an attribute description belonging to an attribute hierarchy where the attribute type of that description is either explicitly included in the definition of an object class to which the entry belongs or allowed by the DIT content rule applicable to that entry. That is, 'name' and 'name;x-tag-option' are allowed by "MAY name" (or by "MUST name"), but 'CN' and 'CN;x-tag-option' are not allowed by "MAY name" (or by "MUST name").
エントリーのサブスキーマ管理の目的のために、属性がある仕様が必要です。エントリーが必要な属性のものがタイプするようにその記述の属性タイプが同じである属性階層構造に属す属性記述の値を含んでいるなら、実現しています。 こと'''名を挙げてください; xタグオプション'実現して、ですが、'CN'がaが、それがそうであると「命名しなければならない」という仕様が実現していないか、または'CN; xはオプションにタグ付けをする'('CN'は'名前'の「副-タイプ」ですが)。 同様に、エントリーはその記述の属性タイプがエントリーが属するオブジェクトのクラスの定義に明らかに含まれているか、またはそのエントリーに適切なDIT満足している規則で許容されている属性階層構造に属す属性記述の値を含むかもしれません。 「5月の名」(または、「命名しなければならない」)によってすなわち、'''名前; xタグオプションが'しかし、「5月の名」(または、「命名しなければならない」)で、許容されている'というCN'と'CNを命名してください; xはオプションにタグ付けをすること'が許されていません。
Zeilenga Standards Track [Page 15] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[15ページ]。
For the purposes of other policy administration, unless stated otherwise in the specification of the particular administrative model, all of the attribute descriptions in an attribute hierarchy are treated as distinct and unrelated descriptions.
他の方針管理の目的のために、別の方法で特定の管理モデルの仕様に述べられない場合、属性階層構造における属性記述のすべてが異なって関係ない記述として扱われます。
2.6. Alias Entries
2.6. 別名エントリー
As adapted from [X.501]:
[X.501]から適合させられるように:
An alias, or an alias name, for an object is an alternative name
for an object or object entry which is provided by the use of
alias entries.
オブジェクトのための別名、または別名が別名エントリーの使用で提供されるオブジェクトかオブジェクトエントリーへの代替名です。
Each alias entry contains, within the 'aliasedObjectName'
attribute (known as the 'aliasedEntryName' attribute in X.500), a
name of some object. The distinguished name of the alias entry is
thus also a name for this object.
それぞれの別名エントリーは'aliasedObjectName'属性('aliasedEntryName'属性として、X.500では、知られている)の中に、あるオブジェクトの名前を含んでいます。 その結果、また、別名エントリーの分類名はこのオブジェクトのための名前です。
NOTE - The name within the 'aliasedObjectName' is said to be
pointed to by the alias. It does not have to be the
distinguished name of any entry.
注意--'aliasedObjectName'の中の名前は別名によって示されると言われています。 それはどんなエントリーの分類名である必要はありません。
The conversion of an alias name to an object name is termed
(alias) dereferencing and comprises the systematic replacement of
alias names, where found within a purported name, by the value of
the corresponding 'aliasedObjectName' attribute. The process may
require the examination of more than one alias entry.
オブジェクト名への別名の変換は、(別名)の「反-参照をつけ」と呼ばれて、別名の系統的な交換を包括します、主張された名前の中で見つけられるところで、対応する'aliasedObjectName'属性の値で。 プロセスは1つ以上の別名エントリーの試験を必要とするかもしれません。
Any particular entry in the DIT may have zero or more alias names.
It therefore follows that several alias entries may point to the
same entry. An alias entry may point to an entry that is not a
leaf entry and may point to another alias entry.
DITのどんな特定のエントリーにも、ゼロか、より通称名前があるかもしれません。 したがって、いくつかの別名エントリーが同じエントリーを示すかもしれないということになります。 別名エントリーは、葉のエントリーでないエントリーを示して、別の別名エントリーを示すかもしれません。
An alias entry shall have no subordinates, so that an alias entry
is always a leaf entry.
別名エントリーには部下が全くいないものとするので、いつも別名エントリーが葉のエントリーです。
Every alias entry shall belong to the 'alias' object class.
あらゆる別名エントリーが'別名'オブジェクトのクラスに属すものとします。
An entry with the 'alias' object class must also belong to an object class (or classes), or be governed by a DIT content rule, which allows suitable naming attributes to be present.
'別名'オブジェクトのクラスとのエントリーをまた、オブジェクトのクラス(または、クラス)に属さなければならないか、またはDITの満足している規則で治めなければなりません。(それは、適当な命名属性が現在であるのを許容します)。
Example:
例:
dn: cn=bar,dc=example,dc=com
objectClass: top
objectClass: alias
objectClass: extensibleObject
dn: dc=com objectClass、cnはバーと等しく、dcは例と等しいです: 最高objectClass: 別名objectClass: extensibleObject
Zeilenga Standards Track [Page 16] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[16ページ]。
cn: bar
aliasedObjectName: cn=foo,dc=example,dc=com
cn: aliasedObjectNameを禁じてください: 例、cn=foo、dc=dc=com
2.6.1. 'alias' Object Class
2.6.1. '通称'オブジェクトのクラス
Alias entries belong to the 'alias' object class.
別名エントリーは'別名'オブジェクトのクラスに属します。
( 2.5.6.1 NAME 'alias'
SUP top STRUCTURAL
MUST aliasedObjectName )
(2.5.6.1NAME'別名'SUP先端STRUCTURAL MUST aliasedObjectName)
2.6.2. 'aliasedObjectName' Attribute Type
2.6.2. 'aliasedObjectName'属性タイプ
The 'aliasedObjectName' attribute holds the name of the entry an alias points to. The 'aliasedObjectName' attribute is known as the 'aliasedEntryName' attribute in X.500.
'aliasedObjectName'属性は別名が示すエントリーの名前を保持します。 'aliasedObjectName'属性は'aliasedEntryName'属性としてX.500で知られています。
( 2.5.4.1 NAME 'aliasedObjectName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE )
(2.5.4.1名前'aliasedObjectName'平等distinguishedNameMatch構文1.3.6の.115の.121の.1の.12のただ一つの.1.4.1.1466価値)
The 'distinguishedNameMatch' matching rule and the DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
'distinguishedNameMatch'合っている規則とDistinguishedName、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .12) 構文は中[RFC4517]で定義されます。
3. Directory Administrative and Operational Information
3. ディレクトリの管理の、そして、操作上の情報
This section discusses select aspects of the X.500 Directory Administrative and Operational Information model [X.501]. LDAP implementations MAY support other aspects of this model.
このセクションはX.500ディレクトリAdministrativeとOperational情報モデル[X.501]の選んだ局面について論じます。 LDAP実装はこのモデルの他の局面をサポートするかもしれません。
3.1. Subtrees
3.1. 下位木
As defined in [X.501]:
[X.501]で定義されるように:
A subtree is a collection of object and alias entries situated at
the vertices of a tree. Subtrees do not contain subentries. The
prefix sub, in subtree, emphasizes that the base (or root) vertex
of this tree is usually subordinate to the root of the DIT.
下位木は木の頭頂に位置するオブジェクトと別名エントリーの収集です。 下位木は副次的記載を含んでいません。 下位木では、接頭語潜水艦は、通常、この木のベース(根づく)の頂点がDITの根に下位であると強調します。
A subtree begins at some vertex and extends to some identifiable
lower boundary, possibly extending to leaves. A subtree is always
defined within a context which implicitly bounds the subtree. For
example, the vertex and lower boundaries of a subtree defining a
replicated area are bounded by a naming context.
ことによると葉に達して、下位木は、いくつかの頂点で始まって、何らかの身元保証可能な低い境界に達します。 それとなくバウンドする文脈の中で定義されて、いつも下位木はそうです。下位木。 例えば、模写された領域を定義する下位木の頂点と低い限界は命名文脈で境界があります。
Zeilenga Standards Track [Page 17] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[17ページ]。
3.2. Subentries
3.2. 副次的記載
A subentry is a "special sort of entry, known by the Directory, used to hold information associated with a subtree or subtree refinement" [X.501]. Subentries are used in Directory to hold for administrative and operational purposes as defined in [X.501]. Their use in LDAP is detailed in [RFC3672].
副次的記載は「ディレクトリによって知られていた下位木か下位木気品に関連している情報を保持するのにおいて中古のエントリーの特殊活字」[X.501]です。 副次的記載は、管理の、そして、操作上の目的に[X.501]で定義されるように当てはまるのにディレクトリに使用されます。 LDAPにおける彼らの使用は[RFC3672]で詳細です。
The term "(sub)entry" in this specification indicates that servers implementing X.500(93) models are, in accordance with X.500(93) as described in [RFC3672], to use a subentry and that other servers are to use an object entry belonging to the appropriate auxiliary class normally used with the subentry (e.g., 'subschema' for subschema subentries) to mimic the subentry. This object entry's RDN SHALL be formed from a value of the 'cn' (commonName) attribute [RFC4519] (as all subentries are named with 'cn').
「(潜水艦)エントリー」というこの仕様による用語は、副次的記載を使用するために[RFC3672]で説明されるX.500(93)によると、X.500(93)モデルを実装するサーバがあるのを示します、そして、通常、適切な補助のクラスに属すオブジェクトエントリーを他のサーバがことである使用するのは副次的記載をまねるのに副次的記載と共に(例えば、サブスキーマ副次的記載のための'サブスキーマ')を使用しました。 このオブジェクトエントリーのRDN SHALL、'cn'(commonName)属性[RFC4519]の値から、形成されてください(すべての副次的記載が'cn'で命名されるように)。
3.3. The 'objectClass' attribute
3.3. 'objectClass'属性
Each entry in the DIT has an 'objectClass' attribute.
DITの各エントリーには、'objectClass'属性があります。
( 2.5.4.0 NAME 'objectClass'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
(2.5.4.0名前'objectClass'平等objectIdentifierMatch構文1.3.6.1.4.1、.1466、.115、.121、.1、.38)
The 'objectIdentifierMatch' matching rule and the OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax are defined in [RFC4517].
'objectIdentifierMatch'合っている規則とOBJECT IDENTIFIER、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .38) 構文は中[RFC4517]で定義されます。
The 'objectClass' attribute specifies the object classes of an entry, which (among other things) are used in conjunction with the controlling schema to determine the permitted attributes of an entry. Values of this attribute can be modified by clients, but the 'objectClass' attribute cannot be removed.
'objectClass'属性はエントリーのオブジェクトのクラスを指定します。(クラスは、エントリーの受入れられた属性を決定するのに制御図式に関連して(特に)使用されます)。 クライアントはこの属性の値を変更できますが、'objectClass'属性を取り除くことができません。
Servers that follow X.500(93) models SHALL restrict modifications of this attribute to prevent the basic structural class of the entry from being changed. That is, one cannot change a 'person' into a 'country'.
X.500(93)モデルのためにSHALLに続くサーバは、エントリーの基本的な構造的なクラスが変えられるのを防ぐためにこの属性の変更を制限します。 すなわち、1つは'人'を'国'に変えることができません。
When creating an entry or adding an 'objectClass' value to an entry, all superclasses of the named classes SHALL be implicitly added as well if not already present. That is, if the auxiliary class 'x-a' is a subclass of the class 'x-b', adding 'x-a' to 'objectClass' causes 'x-b' to be implicitly added (if is not already present).
エントリーを作成するか、またはエントリーへの'objectClass'値、命名されたクラスSHALLのすべての「スーパー-クラス」がそれとなくまた、加えられるか、または既に存在していると言い足すとき。 すなわち、補助のクラス'x-a'がクラス'x-b'のサブクラスであるなら、'objectClass'に'x-a'を加えるのにそれとなく'x-b'を加える、(既にプレゼントでない)
Servers SHALL restrict modifications of this attribute to prevent superclasses of remaining 'objectClass' values from being deleted. That is, if the auxiliary class 'x-a' is a subclass of the auxiliary
サーバSHALLは、'objectClass'値のままで残る「スーパー-クラス」が削除されるのを防ぐためにこの属性の変更を制限します。 補助のクラス'x-a'が補助物のサブクラスであるなら、それはそうです。
Zeilenga Standards Track [Page 18] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[18ページ]。
class 'x-b' and the 'objectClass' attribute contains 'x-a' and 'x-b', an attempt to delete only 'x-b' from the 'objectClass' attribute is an error.
クラス'x-b'、属性が含む'objectClass''x-a'、および'x-b'、'objectClass'属性から'x-b'だけ、を削除する試みは誤りです。
3.4. Operational Attributes
3.4. 操作上の属性
Some attributes, termed operational attributes, are used or maintained by servers for administrative and operational purposes. As stated in [X.501]: "There are three varieties of operational attributes: Directory operational attributes, DSA-shared operational attributes, and DSA-specific operational attributes".
操作上の属性と呼ばれたいくつかの属性が、管理の、そして、操作上の目的のためにサーバによって使用されるか、または維持されます。 [X.501]に述べられているように: 「3つのバラエティーの操作上の属性があります」 「ディレクトリの操作上の属性、DSAによって共有された操作上の属性、およびDSA特有の操作上の属性。」
A directory operational attribute is used to represent operational and/or administrative information in the Directory Information Model. This includes operational attributes maintained by the server (e.g., 'createTimestamp') as well as operational attributes that hold values administrated by the user (e.g., 'ditContentRules').
ディレクトリの操作上の属性が表すのにおいて使用されている、操作上、そして/または、ディレクトリ情報Modelの管理情報。 これはと同様にサーバ(例えば、'createTimestamp')によって維持された操作上の属性を含んでいます。
A DSA-shared operational attribute is used to represent information of the DSA Information Model that is shared between DSAs.
DSAによって共有された操作上の属性は、DSAsの間で共有されるDSA情報Modelの情報を表すのに使用されます。
A DSA-specific operational attribute is used to represent information of the DSA Information Model that is specific to the DSA (though, in some cases, may be derived from information shared between DSAs; e.g., 'namingContexts').
DSA特有の操作上の属性は、DSA(もっとも、いくつかの場合、例えばDSAsの間で共有された情報から派生している'namingContexts'であるかもしれない)に特定のDSA情報Modelの情報を表すのに使用されます。
The DSA Information Model operational attributes are detailed in [X.501].
DSAの情報のModelの操作上の属性は[X.501]で詳細です。
Operational attributes are not normally visible. They are not returned in search results unless explicitly requested by name.
通常、操作上の属性は目に見えません。 名前によって明らかに要求されない場合、それらは検索結果で返されません。
Not all operational attributes are user modifiable.
すべての操作上の属性がどんなユーザ修正できるというわけではありません。
Entries may contain, among others, the following operational attributes:
エントリーは特に以下の操作上の属性を含むかもしれません:
- creatorsName: the Distinguished Name of the user who added this
entry to the directory,
- creatorsName: このエントリーをディレクトリに追加したユーザのDistinguished Name
- createTimestamp: the time this entry was added to the directory,
- createTimestamp: このエントリーがディレクトリに追加された時
- modifiersName: the Distinguished Name of the user who last
modified this entry, and
- modifiersName: そして最後にこのエントリーを変更したユーザのDistinguished Name。
- modifyTimestamp: the time this entry was last modified.
- modifyTimestamp: このエントリーが最後に変更された時。
Zeilenga Standards Track [Page 19] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[19ページ]。
Servers SHOULD maintain the 'creatorsName', 'createTimestamp', 'modifiersName', and 'modifyTimestamp' attributes for all entries of the DIT.
サーバSHOULDは'creatorsName'、'createTimestamp'、'modifiersName'、および'modifyTimestamp'属性をDITのすべてのエントリーに維持します。
3.4.1. 'creatorsName'
3.4.1. 'creatorsName'
This attribute appears in entries that were added using the protocol (e.g., using the Add operation). The value is the distinguished name of the creator.
この属性はプロトコル(例えば、Add操作を使用する)を使用することで加えられたエントリーに現れます。 値はクリエイターの分類名です。
( 2.5.18.3 NAME 'creatorsName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
(2.5.18.3名前'creatorsName'平等distinguishedNameMatch構文1.3.6.1の.115の.121の.1の.12のただ一つの.4.1.1466価値のユーザ変更がない用法directoryOperation)
The 'distinguishedNameMatch' matching rule and the DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
'distinguishedNameMatch'合っている規則とDistinguishedName、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .12) 構文は中[RFC4517]で定義されます。
3.4.2. 'createTimestamp'
3.4.2. 'createTimestamp'
This attribute appears in entries that were added using the protocol (e.g., using the Add operation). The value is the time the entry was added.
この属性はプロトコル(例えば、Add操作を使用する)を使用することで加えられたエントリーに現れます。 値はエントリーが加えられた時です。
( 2.5.18.1 NAME 'createTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
(generalizedTimeOrderingMatch構文1.3.6.1の.115の.121の.1の.24のただ一つの.4.1.1466価値にユーザ変更がない用法directoryOperationを注文する2.5.18.1名の'createTimestamp'平等generalizedTimeMatch)
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
'generalizedTimeMatch'と'generalizedTimeOrderingMatch'合っている規則とGeneralizedTime、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .24) 構文は中[RFC4517]で定義されます。
3.4.3. 'modifiersName'
3.4.3. 'modifiersName'
This attribute appears in entries that have been modified using the protocol (e.g., using the Modify operation). The value is the distinguished name of the last modifier.
この属性はプロトコル(例えば、Modify操作を使用する)を使用することで変更されたエントリーに現れます。 値は最後の修飾語の分類名です。
( 2.5.18.4 NAME 'modifiersName'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
(2.5.18.4名前'modifiersName'平等distinguishedNameMatch構文1.3.6.1の.115の.121の.1の.12のただ一つの.4.1.1466価値のユーザ変更がない用法directoryOperation)
Zeilenga Standards Track [Page 20] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[20ページ]。
The 'distinguishedNameMatch' matching rule and the DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
'distinguishedNameMatch'合っている規則とDistinguishedName、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .12) 構文は中[RFC4517]で定義されます。
3.4.4. 'modifyTimestamp'
3.4.4. 'modifyTimestamp'
This attribute appears in entries that have been modified using the protocol (e.g., using the Modify operation). The value is the time the entry was last modified.
この属性はプロトコル(例えば、Modify操作を使用する)を使用することで変更されたエントリーに現れます。 値はエントリーが最後に変更された時です。
( 2.5.18.2 NAME 'modifyTimestamp'
EQUALITY generalizedTimeMatch
ORDERING generalizedTimeOrderingMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.24
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
(generalizedTimeOrderingMatch構文1.3.6.1の.115の.121の.1の.24のただ一つの.4.1.1466価値にユーザ変更がない用法directoryOperationを注文する2.5.18.2名の'modifyTimestamp'平等generalizedTimeMatch)
The 'generalizedTimeMatch' and 'generalizedTimeOrderingMatch' matching rules and the GeneralizedTime (1.3.6.1.4.1.1466.115.121.1.24) syntax are defined in [RFC4517].
'generalizedTimeMatch'と'generalizedTimeOrderingMatch'合っている規則とGeneralizedTime、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .24) 構文は中[RFC4517]で定義されます。
3.4.5. 'structuralObjectClass'
3.4.5. 'structuralObjectClass'
This attribute indicates the structural object class of the entry.
この属性はエントリーの構造的なオブジェクトのクラスを示します。
( 2.5.21.9 NAME 'structuralObjectClass'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
(2.5.21.9名前'structuralObjectClass'平等objectIdentifierMatch構文1.3.6.1の.115の.121の.1の.38のただ一つの.4.1.1466価値のユーザ変更がない用法directoryOperation)
The 'objectIdentifierMatch' matching rule and OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
'objectIdentifierMatch'合っている規則とOBJECT IDENTIFIER、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .38) 構文は[RFC4517]で定義されます。
3.4.6. 'governingStructureRule'
3.4.6. 'governingStructureRule'
This attribute indicates the structure rule governing the entry.
この属性はエントリーを治める構造規則を示します。
( 2.5.21.10 NAME 'governingStructureRule'
EQUALITY integerMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
(2.5.21.10名前'governingStructureRule'平等integerMatch構文1.3.6.1の.115の.121の.1の.27のただ一つの.4.1.1466価値のユーザ変更がない用法directoryOperation)
The 'integerMatch' matching rule and INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
'integerMatch'合っている規則とINTEGER、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .27) 構文は[RFC4517]で定義されます。
Zeilenga Standards Track [Page 21] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[21ページ]。
4. Directory Schema
4. ディレクトリ図式
As defined in [X.501]:
[X.501]で定義されるように:
The Directory Schema is a set of definitions and constraints
concerning the structure of the DIT, the possible ways entries are
named, the information that can be held in an entry, the
attributes used to represent that information and their
organization into hierarchies to facilitate search and retrieval
of the information and the ways in which values of attributes may
be matched in attribute value and matching rule assertions.
ディレクトリSchemaは1セットのDITの構造に関する定義と規制です、エントリーが命名される可能な方法、エントリー、情報の検索と検索を容易にするためにその情報と彼らの組織を階層構造に代表するのに使用される属性、および属性の値が属性値で合わせられていて、規則主張に合っているかもしれない方法で保持できる情報。
NOTE 1 - The schema enables the Directory system to, for example:
注意1--例えば、図式は、ディレクトリシステムがそうするのを可能にします:
- prevent the creation of subordinate entries of the wrong
object-class (e.g., a country as a subordinate of a person);
- 間違ったオブジェクトクラス(例えば、人の部下としての国)の下位のエントリーの作成を防いでください。
- prevent the addition of attribute-types to an entry
inappropriate to the object-class (e.g., a serial number to a
person's entry);
- オブジェクトクラス(例えば、人のエントリーへの通し番号)に不適当なエントリーに属性タイプの追加を防いでください。
- prevent the addition of an attribute value of a syntax not
matching that defined for the attribute-type (e.g., a printable
string to a bit string).
- 構文の属性値の追加が属性タイプ(例えば少し結ぶ印刷可能なストリング)のために定義されたそれに合っているのを防がないでください。
Formally, the Directory Schema comprises a set of:
正式に、ディレクトリSchemaは以下のセットを包括します。
a) Name Form definitions that define primitive naming relations
for structural object classes;
a) 構造的なオブジェクトのクラスにちなんで原始の命名を定義するForm定義を関係と命名してください。
b) DIT Structure Rule definitions that define the names that
entries may have and the ways in which the entries may be
related to one another in the DIT;
b) DITでエントリーが持っているかもしれない名前とエントリーはお互いに関係があるかもしれない方法を定義するDIT Structure Rule定義。
c) DIT Content Rule definitions that extend the specification of
allowable attributes for entries beyond those indicated by the
structural object classes of the entries;
c) エントリーの構造的なオブジェクトのクラスによって示されたものを超えたエントリーに許容できる属性の仕様を広げるDIT Content Rule定義。
d) Object Class definitions that define the basic set of mandatory
and optional attributes that shall be present, and may be
present, respectively, in an entry of a given class, and which
indicate the kind of object class that is being defined;
d) 与えられたクラスのエントリーでそれぞれ基本的なセットの存在している、存在するかもしれない義務的で任意の属性を定義して、定義されているオブジェクトのクラスの種類を示すオブジェクトClass定義。
Zeilenga Standards Track [Page 22] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[22ページ]。
e) Attribute Type definitions that identify the object identifier
by which an attribute is known, its syntax, associated matching
rules, whether it is an operational attribute and if so its
type, whether it is a collective attribute, whether it is
permitted to have multiple values and whether or not it is
derived from another attribute type;
e) 属性が知られているオブジェクト識別子を特定する属性Type定義(構文)が合っている規則を関連づけました、そして、タイプでありそれには複数の値があることが許可されているか否かに関係なく、それが集合的な属性であるかどうかと、別の属性からそれを得るかどうかがそれが操作上の属性であるか否かに関係なく、そうだとすれば、タイプされます。
f) Matching Rule definitions that define matching rules.
f) マッチングを定義するRule定義に合っているのは統治されます。
And in LDAP:
そして、LDAPで:
g) LDAP Syntax definitions that define encodings used in LDAP.
g) LDAPで使用されるencodingsを定義するLDAP Syntax定義。
4.1. Schema Definitions
4.1. 図式定義
Schema definitions in this section are described using ABNF and rely on the common productions specified in Section 1.2 as well as these:
このセクションとの図式定義は、ABNFを使用することで説明されて、これらと同様にセクション1.2で指定された一般的な創作を当てにします:
noidlen = numericoid [ LCURLY len RCURLY ]
len = number
noidlen=numericoid[LCURLY len RCURLY]lenは数と等しいです。
oids = oid / ( LPAREN WSP oidlist WSP RPAREN )
oidlist = oid *( WSP DOLLAR WSP oid )
oid/(LPAREN WSP oidlist WSP RPAREN)oids=oidlistはoid*と等しいです。(WSP DOLLAR WSP oid)
extensions = *( SP xstring SP qdstrings )
xstring = "X" HYPHEN 1*( ALPHA / HYPHEN / USCORE )
拡大は、=「X」ハイフン1*をxstringしながら、*(SP xstring SP qdstrings)と等しいです。(アルファ/ハイフン/USCORE)
qdescrs = qdescr / ( LPAREN WSP qdescrlist WSP RPAREN )
qdescrlist = [ qdescr *( SP qdescr ) ]
qdescr = SQUOTE descr SQUOTE
qdescrs=qdescr/(LPAREN WSP qdescrlist WSP RPAREN)qdescrlist=[qdescr*(SP qdescr)]qdescrはSQUOTE descr SQUOTEと等しいです。
qdstrings = qdstring / ( LPAREN WSP qdstringlist WSP RPAREN )
qdstringlist = [ qdstring *( SP qdstring ) ]
qdstring = SQUOTE dstring SQUOTE
dstring = 1*( QS / QQ / QUTF8 ) ; escaped UTF-8 string
qdstring/(LPAREN WSP qdstringlist WSP RPAREN)qdstrings=qdstringlistは=SQUOTE dstring SQUOTE dstring=1*(QS/QQ/QUTF8)をqdstringしながら、[*(SP qdstring)をqdstringします]と等しいです。 逃げられたUTF-8ストリング
QQ = ESC %x32 %x37 ; "\27"
QS = ESC %x35 ( %x43 / %x63 ) ; "\5C" / "\5c"
ESC QQ=%x32%x37。 「ESC\の27インチのQS=%x35(%x43/%x63)」。 「「5円のC」/」\5c」
; Any UTF-8 encoded Unicode character
; except %x27 ("\'") and %x5C ("\")
QUTF8 = QUTF1 / UTFMB
; どんなUTF-8もユニコード文字をコード化しました。 '%x27を除いてください、(「\'、」、)、%x5C(「\」)QUTF8はQUTF1 / UTFMBと等しいです。
; Any ASCII character except %x27 ("\'") and %x5C ("\")
QUTF1 = %x00-26 / %x28-5B / %x5D-7F
; '%x27以外のどんなASCII文字、も(「\'、」、)、%x00-26/%x28-5B/%x5D-7%x5C(「\」)QUTF1=F
Schema definitions in this section also share a number of common terms.
また、このセクションとの図式定義は多くの一般的な用語を共有します。
Zeilenga Standards Track [Page 23] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[23ページ]。
The NAME field provides a set of short names (descriptors) that are to be used as aliases for the OID.
NAME分野はOIDに別名として使用されることになっている1セットの省略名(記述子)を提供します。
The DESC field optionally allows a descriptive string to be provided by the directory administrator and/or implementor. While specifications may suggest a descriptive string, there is no requirement that the suggested (or any) descriptive string be used.
DESC分野は、描写的であるストリングがディレクトリ管理者、そして/または、作成者によって提供されるのを任意に許容します。 仕様は描写的であるストリングを示すかもしれませんが、提案された(いくらか)描写的であるストリングが使用されるという要件が全くありません。
The OBSOLETE field, if present, indicates the element is not active.
存在しているなら、OBSOLETE分野は、要素が活性でないことを示します。
Implementors should note that future versions of this document may expand these definitions to include additional terms. Terms whose identifier begins with "X-" are reserved for private experiments and are followed by <SP> and <qdstrings> tokens.
作成者は、このドキュメントの将来のバージョンが追加用語を含むようにこれらの定義を広くするかもしれないことに注意するべきです。識別子が「X」と共に始まる用語を個人的な実験のために取っておかれて、<SP>と<qdstrings>トークンは支えています。
4.1.1. Object Class Definitions
4.1.1. オブジェクトクラス定義
Object Class definitions are written according to the ABNF:
ABNFによると、オブジェクトClass定義は書かれています:
ObjectClassDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oids ] ; superior object classes
[ SP kind ] ; kind of class
[ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN
ObjectClassDescriptionはLPAREN WSP numericoidと等しいです。 識別子[SP「名前」SP qdescrs]は反対します。 省略名(記述子)[SP"DESC"SP qdstring]。 記述[「時代遅れSP」の]。 アクティブ[SP「一口」SP oids]でない。 優れたオブジェクトのクラス[SP種類]。 ちょっとクラス[SP “MUST" SP oids]。 タイプ[SP「5月」SP oids]を結果と考えてください。 属性は拡大WSP RPARENをタイプします。
kind = "ABSTRACT" / "STRUCTURAL" / "AUXILIARY"
「構造的である」か=「抽象的」親切な/「補助しています」。
where:
<numericoid> is object identifier assigned to this object class;
NAME <qdescrs> are short names (descriptors) identifying this
object class;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this object class is not active;
SUP <oids> specifies the direct superclasses of this object class;
the kind of object class is indicated by one of ABSTRACT,
STRUCTURAL, or AUXILIARY (the default is STRUCTURAL);
MUST and MAY specify the sets of required and allowed attribute
types, respectively; and
<extensions> describe extensions.
どこ: <numericoid>はこのオブジェクトのクラスに配属されたオブジェクト識別子です。 NAME<qdescrs>はこのオブジェクトのクラスを特定する省略名(記述子)です。 >をqdstringするDESC<は脆い描写的であるストリングです。 OBSOLETEは、このオブジェクトのクラスが活動的でないことを示します。 SUP<oids>はこのオブジェクトのクラスのダイレクト「スーパー-クラス」を指定します。 オブジェクトのクラスの種類は要約、STRUCTURAL、またはAUXILIARYのひとりによって示されます(デフォルトはSTRUCTURALです)。 必要で許容された属性タイプのセットは、それぞれ指定して、指定しなければならないかもしれません。 そして、<拡大>は拡大について説明します。
Zeilenga Standards Track [Page 24] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[24ページ]。
4.1.2. Attribute Types
4.1.2. 属性タイプ
Attribute Type definitions are written according to the ABNF:
ABNFによると、属性Type定義は書かれています:
AttributeTypeDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "SUP" SP oid ] ; supertype
[ SP "EQUALITY" SP oid ] ; equality matching rule
[ SP "ORDERING" SP oid ] ; ordering matching rule
[ SP "SUBSTR" SP oid ] ; substrings matching rule
[ SP "SYNTAX" SP noidlen ] ; value syntax
[ SP "SINGLE-VALUE" ] ; single-value
[ SP "COLLECTIVE" ] ; collective
[ SP "NO-USER-MODIFICATION" ] ; not user modifiable
[ SP "USAGE" SP usage ] ; usage
extensions WSP RPAREN ; extensions
AttributeTypeDescriptionはLPAREN WSP numericoidと等しいです。 識別子[SP「名前」SP qdescrs]は反対します。 省略名(記述子)[SP"DESC"SP qdstring]。 記述[「時代遅れSP」の]。 アクティブ[SP「一口」SP oid]でない。 「スーパー-タイプ」[SP「平等」SP oid]。 平等マッチングは[「注文SP」SP oid]を統治します。 注文マッチングは[SP"SUBSTR"SP oid]を統治します。 サブストリングマッチングは[SP「構文」SP noidlen]を統治します。 構文[SP「ただ一つの値」]を評価してください。 ただ一つの値[SP「集合体」]。 集合体[SP「ユーザ変更がありません」]。 ユーザ修正できない[SP「用法」SP用法]。 用法拡大WSP RPAREN。 拡大
usage = "userApplications" / ; user
"directoryOperation" / ; directory operational
"distributedOperation" / ; DSA-shared operational
"dSAOperation" ; DSA-specific operational
用法は「userApplications」/と等しいです。 ユーザ"directoryOperation"/。 ディレクトリの操作上の"distributedOperation"/。 DSAによって共有された操作上の"dSAOperation"。 DSA-詳細操作上です。
where:
<numericoid> is object identifier assigned to this attribute type;
NAME <qdescrs> are short names (descriptors) identifying this
attribute type;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this attribute type is not active;
SUP oid specifies the direct supertype of this type;
EQUALITY, ORDERING, and SUBSTR provide the oid of the equality,
ordering, and substrings matching rules, respectively;
SYNTAX identifies value syntax by object identifier and may suggest
a minimum upper bound;
SINGLE-VALUE indicates attributes of this type are restricted to a
single value;
COLLECTIVE indicates this attribute type is collective
[X.501][RFC3671];
NO-USER-MODIFICATION indicates this attribute type is not user
modifiable;
USAGE indicates the application of this attribute type; and
<extensions> describe extensions.
どこ: <numericoid>はこの属性タイプに割り当てられたオブジェクト識別子です。 NAME<qdescrs>はこの属性タイプを特定する省略名(記述子)です。 >をqdstringするDESC<は脆い描写的であるストリングです。 OBSOLETEは、この属性タイプが活発でないことを示します。 SUP oidはこのタイプのダイレクト「スーパー-タイプ」を指定します。 EQUALITY、ORDERING、およびSUBSTRはそれぞれ平等、注文、およびサブストリングのoidに合っている規則を供給します。 SYNTAXはオブジェクト識別子で値の構文を特定して、最小上界を勧めるかもしれません。 SINGLE-VALUEは、このタイプの属性がただ一つの値に制限されるのを示します。 COLLECTIVEは、この属性タイプが集合的な[X.501][RFC3671]であると示します。 どんなUSER-MODIFICATIONも、この属性タイプがユーザ修正できないのを示しません。 USAGEはこの属性タイプの適用を示します。 そして、<拡大>は拡大について説明します。
Each attribute type description must contain at least one of the SUP or SYNTAX fields. If no SYNTAX field is provided, the attribute type description takes its value from the supertype.
それぞれの属性型記述は少なくともSUPかSYNTAX分野の1つを含まなければなりません。 SYNTAX野原を全く供給しないなら、属性型記述は「スーパー-タイプ」から値を取ります。
Zeilenga Standards Track [Page 25] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[25ページ]。
If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING fields, if not specified, take their value from the supertype.
SUP野原を供給して、指定しないなら、EQUALITY、ORDERING、およびSUBSTRING分野は「スーパー-タイプ」からそれらの値を取ります。
Usage of userApplications, the default, indicates that attributes of this type represent user information. That is, they are user attributes.
userApplicationsの使用法(デフォルト)は、このタイプの属性がユーザー情報を表すのを示します。 すなわち、それらはユーザ属性です。
A usage of directoryOperation, distributedOperation, or dSAOperation indicates that attributes of this type represent operational and/or administrative information. That is, they are operational attributes.
directoryOperation、distributedOperation、またはdSAOperationのA使用法が、このタイプのその属性が表すのを示す、操作上、そして/または、管理情報。 すなわち、それらは操作上の属性です。
directoryOperation usage indicates that the attribute of this type is a directory operational attribute. distributedOperation usage indicates that the attribute of this type is a DSA-shared usage operational attribute. dSAOperation usage indicates that the attribute of this type is a DSA-specific operational attribute.
directoryOperation用法は、このタイプの属性がディレクトリの操作上の属性であることを示します。distributedOperation用法は、dSAOperation用法が、このタイプの属性がDSA特有の操作上の属性であることを示すのを示します。このタイプの属性はDSA-共通利用の操作上の属性です。
COLLECTIVE requires usage userApplications. Use of collective attribute types in LDAP is discussed in [RFC3671].
COLLECTIVEは用法userApplicationsを必要とします。 [RFC3671]でLDAPにおける集合的な属性タイプの使用について議論します。
NO-USER-MODIFICATION requires an operational usage.
どんなUSER-MODIFICATIONも操作上の用法を必要としません。
Note that the <AttributeTypeDescription> does not list the matching rules that can be used with that attribute type in an extensibleMatch search filter [RFC4511]. This is done using the 'matchingRuleUse' attribute described in Section 4.1.4.
<AttributeTypeDescription>がextensibleMatch検索フィルタ[RFC4511]のその属性タイプで使用できる合っている規則を記載しないことに注意してください。 これはセクション4.1.4で説明された'matchingRuleUse'属性を使用し終わっています。
This document refines the schema description of X.501 by requiring that the SYNTAX field in an <AttributeTypeDescription> be a string representation of an object identifier for the LDAP string syntax definition, with an optional indication of the suggested minimum bound of a value of this attribute.
<AttributeTypeDescription>のSYNTAX分野がLDAPストリング構文定義のためのオブジェクト識別子のストリング表現であることを必要とすることによって、このドキュメントはX.501のスキーマ記述を洗練します、この属性の価値の提案された最小のバウンドの任意のしるしで。
A suggested minimum upper bound on the number of characters in a
value with a string-based syntax, or the number of bytes in a value
for all other syntaxes, may be indicated by appending this bound
count inside of curly braces following the syntax's OBJECT IDENTIFIER
in an Attribute Type Description. This bound is not part of the
syntax name itself. For instance, "1.3.6.4.1.1466.0{64}" suggests
that server implementations should allow a string to be 64 characters
long, although they may allow longer strings. Note that a single
character of the Directory String syntax may be encoded in more than
one octet since UTF-8 [RFC3629] is a variable-length encoding.
ストリングベースの構文がある値における、キャラクタの数、または値における、他のすべての構文のバイト数における提案された最小上界は、Attribute Type記述で構文のOBJECT IDENTIFIERに続いて、巻き毛の支柱のこの制限されたカウント内部を追加することによって、示されるかもしれません。 このバウンドは構文名自体の一部ではありません。 例えば、「1.3 .6 .4 .1 .1466 .0 64 」 彼らは、より長いストリングを許すかもしれませんが、サーバ実装が、長い間ストリングが64のキャラクタであることを許容するべきであると示唆します。 UTF-8[RFC3629]が可変長のコード化であるので、ディレクトリString構文の単独のキャラクタが1つ以上の八重奏でコード化されるかもしれないことに注意してください。
Zeilenga Standards Track [Page 26] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[26ページ]。
4.1.3. Matching Rules
4.1.3. 合っている規則
Matching rules are used in performance of attribute value assertions, such as in performance of a Compare operation. They are also used in evaluating search filters, determining which individual values are to be added or deleted during performance of a Modify operation, and in comparing distinguished names.
合っている規則はCompare操作の性能などの属性値主張の性能で使用されます。 また、それらは検索フィルタを評価する際に使用されます、Modify操作の性能と、分類名を比較する際に加えられるか、または削除されるために個人価値がどれであるかを決定して。
Each matching rule is identified by an object identifier (OID) and, optionally, one or more short names (descriptors).
オブジェクト識別子(OID)と任意に1つ以上の省略名(記述子)によってそれぞれの合っている規則は特定されます。
Matching rule definitions are written according to the ABNF:
ABNFによると、合っている規則定義は書かれています:
MatchingRuleDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "SYNTAX" SP numericoid ; assertion syntax
extensions WSP RPAREN ; extensions
MatchingRuleDescriptionはLPAREN WSP numericoidと等しいです。 識別子[SP「名前」SP qdescrs]は反対します。 省略名(記述子)[SP"DESC"SP qdstring]。 記述[「時代遅れSP」の]。 アクティブなSP「構文」SP numericoidでない。 主張構文拡大WSP RPAREN。 拡大
where:
<numericoid> is object identifier assigned to this matching rule;
NAME <qdescrs> are short names (descriptors) identifying this
matching rule;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this matching rule is not active;
SYNTAX identifies the assertion syntax (the syntax of the assertion
value) by object identifier; and
<extensions> describe extensions.
どこ: <numericoid>はこの合っている規則に割り当てられたオブジェクト識別子です。 NAME<qdescrs>はこの合っている規則を特定する省略名(記述子)です。 >をqdstringするDESC<は脆い描写的であるストリングです。 OBSOLETEは、この合っている規則がアクティブでないことを示します。 SYNTAXはオブジェクト識別子で、主張構文(主張価値の構文)を特定します。 そして、<拡大>は拡大について説明します。
4.1.4. Matching Rule Uses
4.1.4. 合っている規則用途
A matching rule use lists the attribute types that are suitable for use with an extensibleMatch search filter.
合っている規則使用はextensibleMatch検索フィルタによる使用に適した属性タイプを記載します。
Matching rule use descriptions are written according to the following ABNF:
規則使用に合っていて、以下のABNFによると、記述は書かれています:
MatchingRuleUseDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "APPLIES" SP oids ; attribute types
extensions WSP RPAREN ; extensions
MatchingRuleUseDescriptionはLPAREN WSP numericoidと等しいです。 識別子[SP「名前」SP qdescrs]は反対します。 省略名(記述子)[SP"DESC"SP qdstring]。 記述[「時代遅れSP」の]。 どんなアクティブなSPもSP oidsを「適用しません」。 属性は拡大WSP RPARENをタイプします。 拡大
Zeilenga Standards Track [Page 27] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[27ページ]。
where:
<numericoid> is the object identifier of the matching rule
associated with this matching rule use description;
NAME <qdescrs> are short names (descriptors) identifying this
matching rule use;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this matching rule use is not active;
APPLIES provides a list of attribute types the matching rule
applies to; and
<extensions> describe extensions.
どこ: <numericoid>によるこの合っている規則に関連している合っている規則に関するオブジェクト識別子が記述を使用するということです。 NAME<qdescrs>はこの合っている規則使用を特定する省略名(記述子)です。 >をqdstringするDESC<は脆い描写的であるストリングです。 OBSOLETEは、この合っている規則使用が活発でないことを示します。 APPLIESは合っている規則が当てはまる属性タイプのリストを提供します。 そして、<拡大>は拡大について説明します。
4.1.5. LDAP Syntaxes
4.1.5. LDAP構文
LDAP Syntaxes of (attribute and assertion) values are described in terms of ASN.1 [X.680] and, optionally, have an octet string encoding known as the LDAP-specific encoding. Commonly, the LDAP-specific encoding is constrained to a string of Unicode [Unicode] characters in UTF-8 [RFC3629] form.
(属性と主張)値のLDAP SyntaxesはASN.1[X.680]に関して説明されて、八重奏にLDAP特有のコード化として知られているコード化を任意に結ばせます。 一般的に、LDAP特有のコード化はUTF-8[RFC3629]フォームの一連のユニコード[ユニコード]キャラクタに抑制されます。
Each LDAP syntax is identified by an object identifier (OID).
オブジェクト識別子(OID)によってそれぞれのLDAP構文は特定されます。
LDAP syntax definitions are written according to the ABNF:
ABNFによると、LDAP構文定義は書かれています:
SyntaxDescription = LPAREN WSP
numericoid ; object identifier
[ SP "DESC" SP qdstring ] ; description
extensions WSP RPAREN ; extensions
SyntaxDescriptionはLPAREN WSP numericoidと等しいです。 オブジェクト識別子[SP"DESC"SP qdstring]。 記述拡大WSP RPAREN。 拡大
where:
<numericoid> is the object identifier assigned to this LDAP syntax;
DESC <qdstring> is a short descriptive string; and
<extensions> describe extensions.
どこ: <numericoid>はこのLDAP構文に割り当てられたオブジェクト識別子です。 >をqdstringするDESC<は脆い描写的であるストリングです。 そして、<拡大>は拡大について説明します。
4.1.6. DIT Content Rules
4.1.6. デイット内容規則
A DIT content rule is a "rule governing the content of entries of a particular structural object class" [X.501].
DITの満足している規則は「特定の構造的なオブジェクトのクラスのエントリーの内容を支配する規則」[X.501]です。
For DIT entries of a particular structural object class, a DIT content rule specifies which auxiliary object classes the entries are allowed to belong to and which additional attributes (by type) are required, allowed, or not allowed to appear in the entries.
特定の構造的なオブジェクトのクラスのDITエントリーとして、DITの満足している規則は、どの追加属性(タイプによる)がエントリーがどの補助のオブジェクトのクラスに属すことができるか、そして、必要であることができない、許容できませんし、またエントリーに現れることができないかを指定します。
The list of precluded attributes cannot include any attribute listed as mandatory in the rule, the structural object class, or any of the allowed auxiliary object classes.
排除された属性のリストは規則で義務的であるとして記載されたどんな属性、構造的なオブジェクトのクラス、または許容補助のオブジェクトのクラスのいずれも含むことができません。
Zeilenga Standards Track [Page 28] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[28ページ]。
Each content rule is identified by the object identifier, as well as any short names (descriptors), of the structural object class it applies to.
それぞれの満足している規則はオブジェクト識別子によって特定されます、それが申し込む構造的なオブジェクトのクラスのどんな省略名(記述子)と同様に。
An entry may only belong to auxiliary object classes listed in the governing content rule.
エントリーは支配的な満足している規則で記載された補助のオブジェクトのクラスに属すだけであるかもしれません。
An entry must contain all attributes required by the object classes the entry belongs to as well as all attributes required by the governing content rule.
エントリーはエントリーが支配的な満足している規則によって必要とされたすべての属性と同様に属すオブジェクトのクラスによって必要とされたすべての属性を含まなければなりません。
An entry may contain any non-precluded attributes allowed by the object classes the entry belongs to as well as all attributes allowed by the governing content rule.
エントリーはエントリーが支配的な満足している規則で許容されたすべての属性と同様に属すオブジェクトのクラスによって許容されたどんな非排除された属性も含むかもしれません。
An entry cannot include any attribute precluded by the governing content rule.
エントリーは支配的な満足している規則によって排除されたどんな属性も含むことができません。
An entry is governed by (if present and active in the subschema) the DIT content rule that applies to the structural object class of the entry (see Section 2.4.2). If no active rule is present for the entry's structural object class, the entry's content is governed by the structural object class (and possibly other aspects of user and system schema). DIT content rules for superclasses of the structural object class of an entry are not applicable to that entry.
エントリーはエントリーの構造的なオブジェクトのクラスに適用される(サブスキーマで現在であってアクティブであるなら)DITの満足している規則で治められます(セクション2.4.2を見てください)。 どんなアクティブな規則もエントリーの構造的なオブジェクトのクラスのために存在していないなら、エントリーの内容は構造的なオブジェクトのクラス(そして、ユーザとシステム図式のことによると他の局面)によって支配されます。 エントリーの構造的なオブジェクトのクラスの「スーパー-クラス」のためのDITの満足している規則はそのエントリーに適切ではありません。
DIT content rule descriptions are written according to the ABNF:
ABNFによると、DITの満足している規則記述は書かれています:
DITContentRuleDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
[ SP "AUX" SP oids ] ; auxiliary object classes
[ SP "MUST" SP oids ] ; attribute types
[ SP "MAY" SP oids ] ; attribute types
[ SP "NOT" SP oids ] ; attribute types
extensions WSP RPAREN ; extensions
DITContentRuleDescriptionはLPAREN WSP numericoidと等しいです。 識別子[SP「名前」SP qdescrs]は反対します。 省略名(記述子)[SP"DESC"SP qdstring]。 記述[「時代遅れSP」の]。 アクティブ[SPの「補助」のSP oids]でない。 補助のオブジェクトのクラス[SP “MUST" SP oids]。 タイプ[SP「5月」SP oids]を結果と考えてください。 タイプ[SP「NOT」SP oids]を結果と考えてください。 属性は拡大WSP RPARENをタイプします。 拡大
where:
<numericoid> is the object identifier of the structural object
class associated with this DIT content rule;
NAME <qdescrs> are short names (descriptors) identifying this DIT
content rule;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this DIT content rule use is not active;
AUX specifies a list of auxiliary object classes that entries
subject to this DIT content rule may belong to;
どこ: <numericoid>はこのDITの満足している規則に関連している構造的なオブジェクトのクラスに関するオブジェクト識別子です。 NAME<qdescrs>はこのDITの満足している規則を特定する省略名(記述子)です。 >をqdstringするDESC<は脆い描写的であるストリングです。 OBSOLETEは、このDITの満足している規則使用が活発でないことを示します。 AUXはこのDITの満足している規則を条件としたエントリーが属すかもしれない補助のオブジェクトのクラスのリストを指定します。
Zeilenga Standards Track [Page 29] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[29ページ]。
MUST, MAY, and NOT specify lists of attribute types that are
required, allowed, or precluded, respectively, from appearing
in entries subject to this DIT content rule; and
<extensions> describe extensions.
エントリーにこのDITの満足している規則を条件として現れるので、5月であって、必要である属性タイプのリストを指定しないか、許容されていないか、またはそれぞれ排除されていません;でなければならない そして、<拡大>は拡大について説明します。
4.1.7. DIT Structure Rules and Name Forms
4.1.7. デイット構造規則と名前フォーム
It is sometimes desirable to regulate where object and alias entries can be placed in the DIT and how they can be named based upon their structural object class.
どこに反対してください。そうすれば、別名エントリーはDITに置くことができるか、そして、どうそれらの構造的なオブジェクトのクラスに基づいた状態でそれらを命名できるかを規制するのは時々望ましいです。
4.1.7.1. DIT Structure Rules
4.1.7.1. デイット構造規則
A DIT structure rule is a "rule governing the structure of the DIT by specifying a permitted superior to subordinate entry relationship. A structure rule relates a name form, and therefore a structural object class, to superior structure rules. This permits entries of the structural object class identified by the name form to exist in the DIT as subordinates to entries governed by the indicated superior structure rules" [X.501].
DIT構造規則は「エントリー関係を下位に置かせるために受入れられた上司を指定することによってDITの構造を決定する規則」です。 構造規則は、優れた構造規則に名前フォームを関係させて、したがって、構造的なオブジェクトのクラスを関係させます。 「エントリーへの部下が示された優れた構造規則で治めたので、これは、形成という名前によって特定された構造的なオブジェクトのクラスのエントリーがDITに存在することを許可する」[X.501]。
DIT structure rule descriptions are written according to the ABNF:
ABNFによると、DIT構造規則記述は書かれています:
DITStructureRuleDescription = LPAREN WSP
ruleid ; rule identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "FORM" SP oid ; NameForm
[ SP "SUP" ruleids ] ; superior rules
extensions WSP RPAREN ; extensions
DITStructureRuleDescriptionはLPAREN WSP ruleidと等しいです。 識別子[SP「名前」SP qdescrs]を統治してください。 省略名(記述子)[SP"DESC"SP qdstring]。 記述[「時代遅れSP」の]。 どんなアクティブなSPもSP oidを「形成しません」。 NameForm[SP「一口」ruleids]。 上司は拡大WSP RPARENを統治します。 拡大
ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
ruleidlist = ruleid *( SP ruleid )
ruleid = number
ruleid*(SP ruleid)ruleid/(LPAREN WSP ruleidlist WSP RPAREN)ruleids=ruleidlist=ruleidは数と等しいです。
where:
<ruleid> is the rule identifier of this DIT structure rule;
NAME <qdescrs> are short names (descriptors) identifying this DIT
structure rule;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this DIT structure rule use is not active;
FORM is specifies the name form associated with this DIT structure
rule;
SUP identifies superior rules (by rule id); and
<extensions> describe extensions.
どこ: <ruleid>はこのDIT構造規則に関する規則識別子です。 NAME<qdescrs>はこのDIT構造規則を特定する省略名(記述子)です。 >をqdstringするDESC<は脆い描写的であるストリングです。 OBSOLETEは、このDIT構造規則使用が活発でないことを示します。 FORMがそうである、このDIT構造規則に関連している名前フォームは指定します。 SUPは優れた規則(規則イドによる)を特定します。 そして、<拡大>は拡大について説明します。
Zeilenga Standards Track [Page 30] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[30ページ]。
If no superior rules are identified, the DIT structure rule applies to an autonomous administrative point (e.g., the root vertex of the subtree controlled by the subschema) [X.501].
どんな優れた規則も特定されないなら、DIT構造規則は自治の管理ポイントに適用されます(例えば下位木の根の頂点はサブスキーマによって制御されました)[X.501]。
4.1.7.2. Name Forms
4.1.7.2. 名前フォーム
A name form "specifies a permissible RDN for entries of a particular structural object class. A name form identifies a named object class and one or more attribute types to be used for naming (i.e., for the RDN). Name forms are primitive pieces of specification used in the definition of DIT structure rules" [X.501].
名前フォームは「特定の構造的なオブジェクトのクラスのエントリーに許されているRDNを指定します」。 名前フォームは、命名(すなわち、RDNのための)に使用されるために命名されたオブジェクトのクラスと1人以上の属性タイプを特定します。 「名前フォームはDIT構造規則の定義に使用される原始の仕様[X.501]です」。
Each name form indicates the structural object class to be named, a set of required attribute types, and a set of allowed attribute types. A particular attribute type cannot be in both sets.
それぞれの名前フォームは命名される構造的なオブジェクトのクラス、1セットの必要な属性タイプ、および1セットの許容属性タイプを示します。 両方のセットに特定の属性タイプがいるはずがありません。
Entries governed by the form must be named using a value from each required attribute type and zero or more values from the allowed attribute types.
各必要な属性タイプとゼロから値を使用するとフォームによって治められたエントリーを命名しなければならない、さもなければ、以上は許容属性からタイプを評価します。
Each name form is identified by an object identifier (OID) and, optionally, one or more short names (descriptors).
オブジェクト識別子(OID)と任意に1つ以上の省略名(記述子)によってそれぞれの名前フォームは特定されます。
Name form descriptions are written according to the ABNF:
ABNFによると、名前フォーム記述は書かれています:
NameFormDescription = LPAREN WSP
numericoid ; object identifier
[ SP "NAME" SP qdescrs ] ; short names (descriptors)
[ SP "DESC" SP qdstring ] ; description
[ SP "OBSOLETE" ] ; not active
SP "OC" SP oid ; structural object class
SP "MUST" SP oids ; attribute types
[ SP "MAY" SP oids ] ; attribute types
extensions WSP RPAREN ; extensions
NameFormDescriptionはLPAREN WSP numericoidと等しいです。 識別子[SP「名前」SP qdescrs]は反対します。 省略名(記述子)[SP"DESC"SP qdstring]。 記述[「時代遅れSP」の]。 アクティブなSP"OC"SP oidでない。 構造的なオブジェクトのクラスSP “MUST" SP oids。 タイプ[SP「5月」SP oids]を結果と考えてください。 属性は拡大WSP RPARENをタイプします。 拡大
where:
<numericoid> is object identifier that identifies this name form;
NAME <qdescrs> are short names (descriptors) identifying this name
form;
DESC <qdstring> is a short descriptive string;
OBSOLETE indicates this name form is not active;
OC identifies the structural object class this rule applies to,
MUST and MAY specify the sets of required and allowed,
respectively, naming attributes for this name form; and
<extensions> describe extensions.
どこ: <numericoid>はこの名前フォームを特定するオブジェクト識別子です。 NAME<qdescrs>はこの名前フォームを特定する省略名(記述子)です。 >をqdstringするDESC<は脆い描写的であるストリングです。 OBSOLETEは、この名前フォームがアクティブでないことを示します。 OCはこの規則が当てはまる構造的なオブジェクトのクラスを特定します、と指定して、必要であって許容されることのセットは指定しなければならないかもしれなくて、それぞれ、この名前のための命名属性は形成されます。 そして、<拡大>は拡大について説明します。
All attribute types in the required ("MUST") and allowed ("MAY")
lists shall be different.
すべての属性が必要な(“MUST")をタイプします、そして、許容(「5月」)リストは異なるでしょう。
Zeilenga Standards Track [Page 31] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[31ページ]。
4.2. Subschema Subentries
4.2. サブスキーマ副次的記載
Subschema (sub)entries are used for administering information about the directory schema. A single subschema (sub)entry contains all schema definitions (see Section 4.1) used by entries in a particular part of the directory tree.
サブスキーマ(潜水艦)エントリーは、ディレクトリ図式の情報を管理するのに使用されます。 単一のサブスキーマ(潜水艦)エントリーはディレクトリツリーの特定の部分でエントリーで使用されるすべての図式定義(セクション4.1を見る)を含んでいます。
Servers that follow X.500(93) models SHOULD implement subschema using the X.500 subschema mechanisms (as detailed in Section 12 of [X.501]), so these are not ordinary object entries but subentries (see Section 3.2). LDAP clients SHOULD NOT assume that servers implement any of the other aspects of X.500 subschema.
X.500サブスキーマメカニズムを使用することで([X.501]のセクション12で詳しく述べられるように)SHOULDがサブスキーマを実装するX.500(93)モデルに従うサーバ、したがって、これらは普通のオブジェクトエントリーではなく、副次的記載(セクション3.2を見る)です。 LDAPクライアントSHOULD NOTは、サーバがX.500サブスキーマの他の局面のどれかを実装すると仮定します。
Servers MAY allow subschema modification. Procedures for subschema modification are discussed in Section 14.5 of [X.501].
サーバはサブスキーマ変更を許すかもしれません。 [X.501]のセクション14.5でサブスキーマ変更のための手順について議論します。
A server that masters entries and permits clients to modify these entries SHALL implement and provide access to these subschema (sub)entries including providing a 'subschemaSubentry' attribute in each modifiable entry. This is so clients may discover the attributes and object classes that are permitted to be present. It is strongly RECOMMENDED that all other servers implement this as well.
'subschemaSubentry'属性をそれぞれの修正できるエントリーに提供するのを含むエントリーをマスタリングして、クライアントがSHALLが実装するこれらのエントリーを変更して、これらのサブスキーマ(潜水艦)エントリーへのアクセスを提供することを許可するサーバ。 これは、クライアントが存在していることが許可されている属性とオブジェクトのクラスを発見できるようにそうです。 強く、他のすべてのサーバがこれを実装するRECOMMENDEDが噴出するということです。
The value of the 'subschemaSubentry' attribute is the name of the subschema (sub)entry holding the subschema controlling the entry.
'subschemaSubentry'属性の値はエントリーを制御するサブスキーマを保持するサブスキーマ(潜水艦)エントリーの名前です。
( 2.5.18.10 NAME 'subschemaSubentry'
EQUALITY distinguishedNameMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
SINGLE-VALUE NO-USER-MODIFICATION
USAGE directoryOperation )
(2.5.18.10名前'subschemaSubentry'平等distinguishedNameMatch構文1.3.6.1の.115の.121の.1の.12のただ一つの.4.1.1466価値のユーザ変更がない用法directoryOperation)
The 'distinguishedNameMatch' matching rule and the DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax are defined in [RFC4517].
'distinguishedNameMatch'合っている規則とDistinguishedName、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .12) 構文は中[RFC4517]で定義されます。
Subschema is held in (sub)entries belonging to the subschema auxiliary object class.
サブスキーマは、サブスキーマの補助のオブジェクトのクラスに属しながら、(潜水艦)エントリーに保持されます。
( 2.5.20.1 NAME 'subschema' AUXILIARY
MAY ( dITStructureRules $ nameForms $ ditContentRules $
objectClasses $ attributeTypes $ matchingRules $
matchingRuleUse ) )
(2.5.20.1名の'サブスキーマ'補助の5月の(dITStructureRules$nameForms$ditContentRules$objectClasses$attributeTypes$matchingRules$matchingRuleUse))
The 'ldapSyntaxes' operational attribute may also be present in subschema entries.
また、'ldapSyntaxes'操作上の属性もサブスキーマエントリーに存在しているかもしれません。
Zeilenga Standards Track [Page 32] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[32ページ]。
Servers MAY provide additional attributes (described in other documents) in subschema (sub)entries.
サーバは追加属性(他のドキュメントでは、説明される)をサブスキーマ(潜水艦)エントリーに提供するかもしれません。
Servers SHOULD provide the attributes 'createTimestamp' and 'modifyTimestamp' in subschema (sub)entries, in order to allow clients to maintain their caches of schema information.
サーバSHOULDは属性'createTimestamp'と'modifyTimestamp'をサブスキーマ(潜水艦)エントリーに提供します、クライアントが彼らの図式情報のキャッシュを維持するのを許容するために。
The following subsections provide attribute type definitions for each of schema definition attribute types.
以下の小区分は図式定義属性タイプ各人に属性型定義を提供します。
4.2.1. 'objectClasses'
4.2.1. 'objectClasses'
This attribute holds definitions of object classes.
この属性はオブジェクトのクラスの定義を保持します。
( 2.5.21.6 NAME 'objectClasses'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.37
USAGE directoryOperation )
(2.5.21.6名前'objectClasses'平等objectIdentifierFirstComponentMatch構文1.3.6.1.4.1.1466.115.121.1.37用法directoryOperation)
The 'objectIdentifierFirstComponentMatch' matching rule and the ObjectClassDescription (1.3.6.1.4.1.1466.115.121.1.37) syntax are defined in [RFC4517].
'objectIdentifierFirstComponentMatch'合っている規則とObjectClassDescription、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .37) 構文は中[RFC4517]で定義されます。
4.2.2. 'attributeTypes'
4.2.2. 'attributeTypes'
This attribute holds definitions of attribute types.
この属性は属性タイプの定義を保持します。
( 2.5.21.5 NAME 'attributeTypes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.3
USAGE directoryOperation )
(2.5.21.5名前'attributeTypes'平等objectIdentifierFirstComponentMatch構文1.3.6.1.4.1.1466.115.121.1.3用法directoryOperation)
The 'objectIdentifierFirstComponentMatch' matching rule and the AttributeTypeDescription (1.3.6.1.4.1.1466.115.121.1.3) syntax are defined in [RFC4517].
'objectIdentifierFirstComponentMatch'合っている規則とAttributeTypeDescription、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .3) 構文は中[RFC4517]で定義されます。
4.2.3. 'matchingRules'
4.2.3. 'matchingRules'
This attribute holds definitions of matching rules.
この属性は合っている規則の定義を保持します。
( 2.5.21.4 NAME 'matchingRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.30
USAGE directoryOperation )
(2.5.21.4名前'matchingRules'平等objectIdentifierFirstComponentMatch構文1.3.6.1.4.1.1466.115.121.1.30用法directoryOperation)
The 'objectIdentifierFirstComponentMatch' matching rule and the MatchingRuleDescription (1.3.6.1.4.1.1466.115.121.1.30) syntax are defined in [RFC4517].
'objectIdentifierFirstComponentMatch'合っている規則とMatchingRuleDescription、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .30) 構文は中[RFC4517]で定義されます。
Zeilenga Standards Track [Page 33] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[33ページ]。
4.2.4 'matchingRuleUse'
4.2.4 'matchingRuleUse'
This attribute holds definitions of matching rule uses.
この属性は合っている規則用途の定義を保持します。
( 2.5.21.8 NAME 'matchingRuleUse'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.31
USAGE directoryOperation )
(2.5.21.8名前'matchingRuleUse'平等objectIdentifierFirstComponentMatch構文1.3.6.1.4.1.1466.115.121.1.31用法directoryOperation)
The 'objectIdentifierFirstComponentMatch' matching rule and the MatchingRuleUseDescription (1.3.6.1.4.1.1466.115.121.1.31) syntax are defined in [RFC4517].
'objectIdentifierFirstComponentMatch'合っている規則とMatchingRuleUseDescription、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .31) 構文は中[RFC4517]で定義されます。
4.2.5. 'ldapSyntaxes'
4.2.5. 'ldapSyntaxes'
This attribute holds definitions of LDAP syntaxes.
この属性はLDAP構文の定義を保持します。
( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.54
USAGE directoryOperation )
(1.3.6.1.4.1.1466.101.120.16名前'ldapSyntaxes'平等objectIdentifierFirstComponentMatch構文1.3.6.1.4.1.1466.115.121.1.54用法directoryOperation)
The 'objectIdentifierFirstComponentMatch' matching rule and the SyntaxDescription (1.3.6.1.4.1.1466.115.121.1.54) syntax are defined in [RFC4517].
'objectIdentifierFirstComponentMatch'合っている規則とSyntaxDescription、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .54) 構文は中[RFC4517]で定義されます。
4.2.6. 'dITContentRules'
4.2.6. 'dITContentRules'
This attribute lists DIT Content Rules that are present in the subschema.
この属性はサブスキーマで存在しているDIT Content Rulesを記載します。
( 2.5.21.2 NAME 'dITContentRules'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.16
USAGE directoryOperation )
(2.5.21.2名前'dITContentRules'平等objectIdentifierFirstComponentMatch構文1.3.6.1.4.1.1466.115.121.1.16用法directoryOperation)
The 'objectIdentifierFirstComponentMatch' matching rule and the DITContentRuleDescription (1.3.6.1.4.1.1466.115.121.1.16) syntax are defined in [RFC4517].
'objectIdentifierFirstComponentMatch'合っている規則とDITContentRuleDescription、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .16) 構文は中[RFC4517]で定義されます。
Zeilenga Standards Track [Page 34] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[34ページ]。
4.2.7. 'dITStructureRules'
4.2.7. 'dITStructureRules'
This attribute lists DIT Structure Rules that are present in the subschema.
この属性はサブスキーマで存在しているDIT Structure Rulesを記載します。
( 2.5.21.1 NAME 'dITStructureRules'
EQUALITY integerFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.17
USAGE directoryOperation )
(2.5.21.1名前'dITStructureRules'平等integerFirstComponentMatch構文1.3.6.1.4.1.1466.115.121.1.17用法directoryOperation)
The 'integerFirstComponentMatch' matching rule and the DITStructureRuleDescription (1.3.6.1.4.1.1466.115.121.1.17) syntax are defined in [RFC4517].
'integerFirstComponentMatch'合っている規則とDITStructureRuleDescription、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .17) 構文は中[RFC4517]で定義されます。
4.2.8 'nameForms'
4.2.8 'nameForms'
This attribute lists Name Forms that are in force.
この属性は有効なName Formsを記載します。
( 2.5.21.7 NAME 'nameForms'
EQUALITY objectIdentifierFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.35
USAGE directoryOperation )
(2.5.21.7名前'nameForms'平等objectIdentifierFirstComponentMatch構文1.3.6.1.4.1.1466.115.121.1.35用法directoryOperation)
The 'objectIdentifierFirstComponentMatch' matching rule and the NameFormDescription (1.3.6.1.4.1.1466.115.121.1.35) syntax are defined in [RFC4517].
'objectIdentifierFirstComponentMatch'合っている規則とNameFormDescription、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .35) 構文は中[RFC4517]で定義されます。
4.3. 'extensibleObject' object class
4.3. 'extensibleObject'オブジェクトのクラス
The 'extensibleObject' auxiliary object class allows entries that belong to it to hold any user attribute. The set of allowed attribute types of this object class is implicitly the set of all attribute types of userApplications usage.
'extensibleObject'補助のオブジェクトのクラスで、それに属すエントリーはどんなユーザ属性も保持できます。 このオブジェクトのクラスの許容属性タイプのセットはそれとなく、すべての属性のセットがuserApplications用法をタイプするということです。
( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject'
SUP top AUXILIARY )
(1.3.6.1.4.1.1466.101.120.111NAME'extensibleObject'SUP先端AUXILIARY)
The mandatory attributes of the other object classes of this entry are still required to be present, and any precluded attributes are still not allowed to be present.
このエントリーの他のオブジェクトのクラスの義務的な属性が存在しているのにまだ必要です、そして、どんな排除された属性も存在させているのをまだ許容されていません。
4.4. Subschema Discovery
4.4. サブスキーマ発見
To discover the DN of the subschema (sub)entry holding the subschema controlling a particular entry, a client reads that entry's 'subschemaSubentry' operational attribute. To read schema attributes from the subschema (sub)entry, clients MUST issue a Search operation [RFC4511] where baseObject is the DN of the subschema (sub)entry,
サブスキーマ(潜水艦)エントリーのDNが特定のエントリーを制御するサブスキーマを保持していると発見するために、クライアントはそのエントリーの'subschemaSubentry'操作上の属性を読みます。 サブスキーマ(潜水艦)エントリーから図式属性を読むために、クライアントはbaseObjectがサブスキーマ(潜水艦)エントリーのDNであるところで検索操作[RFC4511]を発行しなければなりません。
Zeilenga Standards Track [Page 35] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[35ページ]。
scope is baseObject, filter is "(objectClass=subschema)" [RFC4515], and the attributes field lists the names of the desired schema attributes (as they are operational). Note: the "(objectClass=subschema)" filter allows LDAP servers that gateway to X.500 to detect that subentry information is being requested.
範囲はbaseObjectです、そして、フィルタは「(objectClass=サブスキーマ)」[RFC4515]です、そして、属性分野は必要な図式属性の名前を記載します(それらが操作上であるときに)。 以下に注意してください。 「(objectClassはサブスキーマと等しいです)」フィルタはその副次的記載情報を検出するX.500へのゲートウェイがそうである要求されているサーバをLDAPに許容します。
Clients SHOULD NOT assume that a published subschema is complete, that the server supports all of the schema elements it publishes, or that the server does not support an unpublished element.
クライアントSHOULD NOTは、発行されたサブスキーマが完全であるか、サーバがそれが発行する図式要素のすべてをサポートするか、またはサーバが未発表の要素を支えないと仮定します。
5. DSA (Server) Informational Model
5. DSAの(サーバ)情報のモデル
The LDAP protocol assumes there are one or more servers that jointly provide access to a Directory Information Tree (DIT). The server holding the original information is called the "master" (for that information). Servers that hold copies of the original information are referred to as "shadowing" or "caching" servers.
LDAPプロトコルは、共同でディレクトリ情報Tree(DIT)へのアクセスを提供する1つ以上のサーバがあると仮定します。 オリジナルの情報を保持するサーバは「マスター」(その情報のための)と呼ばれます。 オリジナルの情報のコピーを支えるサーバがサーバが「影でおおう」か、または「キャッシュ」であると呼ばれます。
As defined in [X.501]:
[X.501]で定義されるように:
context prefix: The sequence of RDNs leading from the Root of the
DIT to the initial vertex of a naming context; corresponds to
the distinguished name of that vertex.
文脈接頭語: DITのRootから初期の命名文脈の頂点まで導くRDNsの系列。 その頂点の分類名に対応しています。
naming context: A subtree of entries held in a single master DSA.
命名文脈: エントリーの下位木は独身のマスターDSAで成立しました。
That is, a naming context is the largest collection of entries, starting at an entry that is mastered by a particular server, and including all its subordinates and their subordinates, down to the entries that are mastered by different servers. The context prefix is the name of the initial entry.
すなわち、命名文脈はエントリーの最も大きい収集です、特定のサーバによってマスタリングされるエントリーで始まって、すべての部下と彼らの部下を含んでいて、異なったサーバによってマスタリングされるエントリーまで。 文脈接頭語は初期のエントリーの名前です。
The root of the DIT is a DSA-specific Entry (DSE) and not part of any naming context (or any subtree); each server has different attribute values in the root DSE.
DITの根はどんな命名文脈の一部(または、どんな下位木も)ではなく、DSA特有のEntry(DSE)ですも。 各サーバには、根のDSEの異なった属性値があります。
5.1. Server-Specific Data Requirements
5.1. サーバ特有のデータ要件
An LDAP server SHALL provide information about itself and other information that is specific to each server. This is represented as a group of attributes located in the root DSE, which is named with the DN with zero RDNs (whose [RFC4514] representation is as the zero-length string).
属性のグループとして表されて、SHALLが各サーバに特定のそれ自体の情報と他の情報を提供するLDAPサーバは根でDSEの場所を見つけました。(DSEはRDNsがない(ゼロ長ストリングとして[RFC4514]表現がある)DNと共に命名されます)。
These attributes are retrievable, subject to access control and other restrictions, if a client performs a Search operation [RFC4511] with an empty baseObject, scope of baseObject, the filter
これらの属性はアクセスコントロールと他の制限を条件として回収可能です、クライアントが空のbaseObjectとの検索操作[RFC4511]を実行するなら、baseObjectの範囲、フィルタ
Zeilenga Standards Track [Page 36] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[36ページ]。
"(objectClass=*)" [RFC4515], and the attributes field listing the names of the desired attributes. It is noted that root DSE attributes are operational and, like other operational attributes, are not returned in search requests unless requested by name.
「(objectClassは*と等しいです)」 [RFC4515]、および必要な属性の名前を記載する属性分野。 根のDSE属性が操作上であり、名前によって要求されない場合他の操作上の属性のように検索要求で返されないことに注意されます。
The root DSE SHALL NOT be included if the client performs a subtree search starting from the root.
根から始めて、クライアントが下位木検索を実行するなら含まれていて、DSE SHALL NOTを根づかせてください。
Servers may allow clients to modify attributes of the root DSE, where appropriate.
サーバで、クライアントは適切であるところで根のDSEの属性を変更できるかもしれません。
The following attributes of the root DSE are defined below. Additional attributes may be defined in other documents.
根のDSEの以下の属性は以下で定義されます。 追加属性は他のドキュメントで定義されるかもしれません。
- altServer: alternative servers;
- altServer: 代替のサーバ。
- namingContexts: naming contexts;
- namingContexts: 命名文脈。
- supportedControl: recognized LDAP controls;
- supportedControl: 認識されたLDAPは制御します。
- supportedExtension: recognized LDAP extended operations;
- supportedExtension: 認識されたLDAPは操作を広げました。
- supportedFeatures: recognized LDAP features;
- supportedFeatures: 認識されたLDAPの特徴。
- supportedLDAPVersion: LDAP versions supported; and
- supportedLDAPVersion: サポートされたLDAPバージョン。 そして
- supportedSASLMechanisms: recognized Simple Authentication and
Security Layers (SASL) [RFC4422] mechanisms.
- supportedSASLMechanisms: Simple AuthenticationとSecurity Layers(SASL)[RFC4422]メカニズムを認識しました。
The values provided for these attributes may depend on session- specific and other factors. For example, a server supporting the SASL EXTERNAL mechanism might only list "EXTERNAL" when the client's identity has been established by a lower level. See [RFC4513].
これらの属性に提供された値はセッションの特定の、そして、他の要素に依存するかもしれません。 クライアントのアイデンティティが下のレベルによって確立されたときだけ、例えば、SASL EXTERNALメカニズムをサポートするサーバは「外部であること」の形で記載するかもしれません。 [RFC4513]を見てください。
The root DSE may also include a 'subschemaSubentry' attribute. If it does, the attribute refers to the subschema (sub)entry holding the schema controlling the root DSE. Clients SHOULD NOT assume that this subschema (sub)entry controls other entries held by the server. General subschema discovery procedures are provided in Section 4.4.
また、根のDSEは'subschemaSubentry'属性を含むかもしれません。 そうするなら、属性は、根のDSEを制御する図式を保持しながら、サブスキーマ(潜水艦)エントリーについて言及します。 クライアントSHOULD NOTは、このサブスキーマ(潜水艦)エントリーがサーバによって保持された他のエントリーを制御すると仮定します。一般サブスキーマ発見手順をセクション4.4に提供します。
Zeilenga Standards Track [Page 37] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[37ページ]。
5.1.1. 'altServer'
5.1.1. 'altServer'
The 'altServer' attribute lists URIs referring to alternative servers that may be contacted when this server becomes unavailable. URIs for servers implementing the LDAP are written according to [RFC4516]. Other kinds of URIs may be provided. If the server does not know of any other servers that could be used, this attribute will be absent. Clients may cache this information in case their preferred server later becomes unavailable.
'altServer'属性はこのサーバが入手できなくなるとき連絡されるかもしれない代替のサーバを示すURIを記載します。 [RFC4516]に従って、LDAPを実装するサーバのためのURIは書かれています。 他の種類のURIを提供するかもしれません。 サーバが使用できた他のサーバを知らないと、この属性は欠けるでしょう。 後で彼らの常用サーバーが入手できなくなるといけないので、クライアントはこの情報をキャッシュするかもしれません。
( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
USAGE dSAOperation )
(1.3.6.1.4.1.1466.101.120.6名前'altServer'構文1.3.6.1.4.1.1466.115.121.1.26用法dSAOperation)
The IA5String (1.3.6.1.4.1.1466.115.121.1.26) syntax is defined in [RFC4517].
IA5String、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .26) 構文は[RFC4517]で定義されます。
5.1.2. 'namingContexts'
5.1.2. 'namingContexts'
The 'namingContexts' attribute lists the context prefixes of the naming contexts the server masters or shadows (in part or in whole). If the server is a first-level DSA [X.501], it should list (in addition) an empty string (indicating the root of the DIT). If the server does not master or shadow any information (e.g., it is an LDAP gateway to a public X.500 directory) this attribute will be absent. If the server believes it masters or shadows the entire directory, the attribute will have a single value, and that value will be the empty string (indicating the root of the DIT).
'namingContexts'は文脈が前に置くサーバがマスタリングする命名文脈か影(一部か全部)のリストを結果と考えます。 サーバが最初に、レベルDSA[X.501]であるなら、それは空のストリングを記載するべきです(さらに)(DITの根を示して)。 サーバが少しの情報もマスタリングもしませんし、影でおおいもしないと(例えば、それは公共のX.500ディレクトリへのLDAPゲートウェイです)、この属性は欠けるでしょう。 サーバが、それが全ディレクトリ、属性がそうするマスターか影であると信じているなら、ただ一つの値を持ってください。そうすれば、その値は空のストリング(DITの根を示して)でしょう。
This attribute may be used, for example, to select a suitable entry name for subsequent operations with this server.
例えば、この属性は、このサーバによるその後の操作のために適当な入口名を選択するのに使用されるかもしれません。
( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.12
USAGE dSAOperation )
(1.3.6.1.4.1.1466.101.120.5名前'namingContexts'構文1.3.6.1.4.1.1466.115.121.1.12用法dSAOperation)
The DistinguishedName (1.3.6.1.4.1.1466.115.121.1.12) syntax is defined in [RFC4517].
DistinguishedName、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .12) 構文は[RFC4517]で定義されます。
5.1.3. 'supportedControl'
5.1.3. 'supportedControl'
The 'supportedControl' attribute lists object identifiers identifying the request controls [RFC4511] the server supports. If the server does not support any request controls, this attribute will be absent. Object identifiers identifying response controls need not be listed.
'supportedControl'属性はサーバがサポートする要求コントロール[RFC4511]を特定するオブジェクト識別子をリストアップします。 サーバが、どんな要求もコントロールであるとサポートしないと、この属性は欠けるでしょう。 応答制御を特定するオブジェクト識別子はリストアップされる必要はありません。
Procedures for registering object identifiers used to discovery of protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
プロトコルメカニズムの発見に使用されるオブジェクト識別子を登録するための手順はBCP64、RFC4520[RFC4520]で詳細です。
Zeilenga Standards Track [Page 38] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[38ページ]。
( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
(1.3.6.1.4.1.1466.101.120.13名前'supportedControl'構文1.3.6.1.4.1.1466.115.121.1.38用法dSAOperation)
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
OBJECT IDENTIFIER、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .38) 構文は[RFC4517]で定義されます。
5.1.4. 'supportedExtension'
5.1.4. 'supportedExtension'
The 'supportedExtension' attribute lists object identifiers identifying the extended operations [RFC4511] that the server supports. If the server does not support any extended operations, this attribute will be absent.
'supportedExtension'属性はサーバがサポートする拡大手術[RFC4511]を特定するオブジェクト識別子をリストアップします。 サーバが少しの拡大手術もサポートしないと、この属性は欠けるでしょう。
An extended operation generally consists of an extended request and an extended response but may also include other protocol data units (such as intermediate responses). The object identifier assigned to the extended request is used to identify the extended operation. Other object identifiers used in the extended operation need not be listed as values of this attribute.
拡大手術は、拡張要求と拡張応答から一般に成りますが、また、他のプロトコルデータ単位(中間的応答などの)を含むかもしれません。 拡張要求に割り当てられたオブジェクト識別子は、拡大手術を特定するのに使用されます。 拡大手術に使用される他のオブジェクト識別子はこの属性の値としてリストアップされる必要はありません。
Procedures for registering object identifiers used to discovery of protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
プロトコルメカニズムの発見に使用されるオブジェクト識別子を登録するための手順はBCP64、RFC4520[RFC4520]で詳細です。
( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
(1.3.6.1.4.1.1466.101.120.7名前'supportedExtension'構文1.3.6.1.4.1.1466.115.121.1.38用法dSAOperation)
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax is defined in [RFC4517].
OBJECT IDENTIFIER、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .38) 構文は[RFC4517]で定義されます。
5.1.5. 'supportedFeatures'
5.1.5. 'supportedFeatures'
The 'supportedFeatures' attribute lists object identifiers identifying elective features that the server supports. If the server does not support any discoverable elective features, this attribute will be absent.
'supportedFeatures'属性はサーバがサポートする選挙の特徴を特定するオブジェクト識別子をリストアップします。 サーバがどんな発見可能な選挙の特徴もサポートしないと、この属性は欠けるでしょう。
( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures'
EQUALITY objectIdentifierMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
USAGE dSAOperation )
(1.3.6.1.4.1.4203.1.3.5名前'supportedFeatures'平等objectIdentifierMatch構文1.3.6.1.4.1.1466.115.121.1.38用法dSAOperation)
Procedures for registering object identifiers used to discovery of protocol mechanisms are detailed in BCP 64, RFC 4520 [RFC4520].
プロトコルメカニズムの発見に使用されるオブジェクト識別子を登録するための手順はBCP64、RFC4520[RFC4520]で詳細です。
The OBJECT IDENTIFIER (1.3.6.1.4.1.1466.115.121.1.38) syntax and objectIdentifierMatch matching rule are defined in [RFC4517].
OBJECT IDENTIFIER、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .38) 構文とobjectIdentifierMatchの合っている規則は[RFC4517]で定義されます。
Zeilenga Standards Track [Page 39] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[39ページ]。
5.1.6. 'supportedLDAPVersion'
5.1.6. 'supportedLDAPVersion'
The 'supportedLDAPVersion' attribute lists the versions of LDAP that the server supports.
'supportedLDAPVersion'属性はサーバがサポートするLDAPのバージョンを記載します。
( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.27
USAGE dSAOperation )
(1.3.6.1.4.1.1466.101.120.15名前'supportedLDAPVersion'構文1.3.6.1.4.1.1466.115.121.1.27用法dSAOperation)
The INTEGER (1.3.6.1.4.1.1466.115.121.1.27) syntax is defined in [RFC4517].
INTEGER、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .27) 構文は[RFC4517]で定義されます。
5.1.7. 'supportedSASLMechanisms'
5.1.7. 'supportedSASLMechanisms'
The 'supportedSASLMechanisms' attribute lists the SASL mechanisms [RFC4422] that the server recognizes and/or supports [RFC4513]. The contents of this attribute may depend on the current session state. If the server does not support any SASL mechanisms, this attribute will not be present.
'supportedSASLMechanisms'属性はサーバが認識する、そして/または、サポートするSASLメカニズム[RFC4422][RFC4513]を記載します。 この属性のコンテンツは現在のセッション状態に依存するかもしれません。 サーバがどんなSASLメカニズムもサポートしないと、この属性は存在しないでしょう。
( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
USAGE dSAOperation )
(1.3.6.1.4.1.1466.101.120.14名前'supportedSASLMechanisms'構文1.3.6.1.4.1.1466.115.121.1.15用法dSAOperation)
The Directory String (1.3.6.1.4.1.1466.115.121.1.15) syntax is defined in [RFC4517].
ディレクトリString、(1.3 .6 .1 .4 .1 .1466 .115 .121 .1 .15) 構文は[RFC4517]で定義されます。
6. Other Considerations
6. 他の問題
6.1. Preservation of User Information
6.1. ユーザー情報の保存
Syntaxes may be defined that have specific value and/or value form (representation) preservation requirements. For example, a syntax containing digitally signed data can mandate that the server preserve both the value and form of value presented to ensure that the signature is not invalidated.
特定の値、そして/または、値が(表現)保存要件を形成する構文は定義されるかもしれません。 例えば、a構文含有は署名が無効にされないのを保証するために提示された値と価値形態の両方にサーバが保存するデータ缶の命令にデジタルに署名しました。
Where such requirements have not been explicitly stated, servers SHOULD preserve the value of user information but MAY return the value in a different form. And where a server is unable (or unwilling) to preserve the value of user information, the server SHALL ensure that an equivalent value (per Section 2.3) is returned.
そのような要件が明らかに述べられていないところでは、サーバSHOULDはユーザー情報の価値を守りますが、異なったフォームで値を返すかもしれません。 そして、サーバがユーザー情報の価値を守るために(不本意)であるところでは、サーバSHALLは、同等な値(セクション2.3あたりの)が返されるのを確実にします。
Zeilenga Standards Track [Page 40] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[40ページ]。
6.2. Short Names
6.2. 省略名
Short names, also known as descriptors, are used as more readable aliases for object identifiers and are used to identify various schema elements. However, it is not expected that LDAP implementations with human user interface would display these short names (or the object identifiers they refer to) to the user. Instead, they would most likely be performing translations (such as expressing the short name in one of the local national languages). For example, the short name "st" (stateOrProvinceName) might be displayed to a German-speaking user as "Land".
また、記述子として知られている省略名は、オブジェクト識別子により読み込み可能な別名として使用されて、様々な図式要素を特定するのに使用されます。 しかしながら、人間のユーザーインタフェースがあるLDAP実装がこれらの省略名(または、彼らが示すオブジェクト識別子)をユーザに表示しないと予想されます。 代わりに、彼らはたぶん、翻訳(現地雇用人言語の1つによる省略名を表すことなどの)を実行しているでしょう。 例えば、「陸」として省略名“st"(stateOrProvinceName)をドイツ語を話すユーザに表示するかもしれません。
The same short name might have different meaning in different subschemas, and, within a particular subschema, the same short name might refer to different object identifiers each identifying a different kind of schema element.
同じ省略名には、異なったサブスキーマにおける異なった意味があるかもしれません、そして、特定のサブスキーマの中では、同じ省略名は異種の図式要素を特定しながら、それぞれ異なったオブジェクト識別子を示すかもしれません。
Implementations MUST be prepared that the same short name might be used in a subschema to refer to the different kinds of schema elements. That is, there might be an object class 'x-fubar' and an attribute type 'x-fubar' in a subschema.
実装は準備されて、そんなに同じ省略名が図式要素の異種について言及するのにサブスキーマに使用されるかもしれないということであるに違いありません。 すなわち、'xめちゃくちゃ'、そして、属性がタイプするオブジェクトのクラスがサブスキーマで'xめちゃくちゃな'状態であるかもしれません。
Implementations MUST be prepared that the same short name might be used in the different subschemas to refer to the different schema elements. That is, there might be two matching rules 'x-fubar', each in different subschemas.
実装は準備されて、そんなに同じ省略名が異なった図式要素を示すのに異なったサブスキーマに使用されるかもしれないということであるに違いありません。 すなわち、それぞれ異なったサブスキーマで'xめちゃくちゃな'2つの合っている規則があるかもしれません。
Procedures for registering short names (descriptors) are detailed in BCP 64, RFC 4520 [RFC4520].
省略名(記述子)を登録するための手順はBCP64、RFC4520[RFC4520]で詳細です。
6.3. Cache and Shadowing
6.3. キャッシュとシャドウイング
Some servers may hold cache or shadow copies of entries, which can be used to answer search and comparison queries, but will return referrals or contact other servers if modification operations are requested. Servers that perform shadowing or caching MUST ensure that they do not violate any access control constraints placed on the data by the originating server.
いくつかのサーバが検索と比較質問に答えるのに使用できるエントリーのキャッシュか影のコピーを支えるかもしれません、変更操作が要求されると、紹介を返すか、または他のサーバに連絡するのを除いて。 シャドウイングかキャッシュを実行するサーバは、起因するサーバによってデータに置かれた少しのアクセス制御規制にも違反しないのを確実にしなければなりません。
Zeilenga Standards Track [Page 41] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[41ページ]。
7. Implementation Guidelines
7. 実施要綱
7.1. Server Guidelines
7.1. サーバガイドライン
Servers MUST recognize all names of attribute types and object classes defined in this document but, unless stated otherwise, need not support the associated functionality. Servers SHOULD recognize all the names of attribute types and object classes defined in Section 3 and 4, respectively, of [RFC4519].
サーバは、本書では定義された属性タイプとオブジェクトのクラスのすべての名前を認識しなければなりませんが、別の方法で述べられない場合、関連機能性をサポートする必要はありません。 サーバSHOULDは[RFC4519]についてセクション3と4でそれぞれ定義された属性タイプとオブジェクトのクラスのすべての名前を認識します。
Servers MUST ensure that entries conform to user and system schema rules or other data model constraints.
サーバは、エントリーがユーザとシステム図式規則か他のデータモデル規制に従うのを確実にしなければなりません。
Servers MAY support DIT Content Rules. Servers MAY support DIT Structure Rules and Name Forms.
サーバはDIT Content Rulesをサポートするかもしれません。 サーバはDIT Structure RulesとName Formsをサポートするかもしれません。
Servers MAY support alias entries.
サーバは別名エントリーをサポートするかもしれません。
Servers MAY support the 'extensibleObject' object class.
サーバは'extensibleObject'オブジェクトのクラスをサポートするかもしれません。
Servers MAY support subentries. If so, they MUST do so in accordance with [RFC3672]. Servers that do not support subentries SHOULD use object entries to mimic subentries as detailed in Section 3.2.
サーバは副次的記載をサポートするかもしれません。 そうだとすれば、[RFC3672]に従って、彼らはそうしなければなりません。 副次的記載がSHOULDであるとサポートしないサーバは、セクション3.2で詳しく述べられるように副次的記載をまねるのにオブジェクトエントリーを使用します。
Servers MAY implement additional schema elements. Servers SHOULD provide definitions of all schema elements they support in subschema (sub)entries.
サーバは追加図式要素を実装するかもしれません。 サーバSHOULDはそれらがサブスキーマ(潜水艦)エントリーで支えるすべての図式要素の定義を提供します。
7.2. Client Guidelines
7.2. クライアントガイドライン
In the absence of prior agreements with servers, clients SHOULD NOT assume that servers support any particular schema elements beyond those referenced in Section 7.1. The client can retrieve subschema information as described in Section 4.4.
サーバとの事前同意がないとき、クライアントSHOULD NOTは、サーバがセクション7.1で参照をつけられるそれらを超えたどんな特定の図式要素も支えると仮定します。 クライアントはセクション4.4で説明されるようにサブスキーマ情報を検索できます。
Clients MUST NOT display or attempt to decode a value as ASN.1 if the value's syntax is not known. Clients MUST NOT assume the LDAP- specific string encoding is restricted to a UTF-8 encoded string of Unicode characters or any particular subset of Unicode (such as a printable subset) unless such restriction is explicitly stated. Clients SHOULD NOT send attribute values in a request that are not valid according to the syntax defined for the attributes.
値の構文が知られていないなら、クライアントは、表示してはいけませんし、またASN.1として値を解読するのを試みてはいけません。 クライアントは、そのような制限が明らかに述べられない場合特定のストリングコード化が制限されるLDAP a UTF-8がユニコード文字のストリングかユニコードのどんな特定の部分集合(印刷可能な部分集合などの)もコード化したと仮定してはいけません。 クライアントSHOULD NOTは要求における属性のために定義された構文によると、有効でない属性値を送ります。
Zeilenga Standards Track [Page 42] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[42ページ]。
8. Security Considerations
8. セキュリティ問題
Attributes of directory entries are used to provide descriptive information about the real-world objects they represent, which can be people, organizations, or devices. Most countries have privacy laws regarding the publication of information about people.
ディレクトリエントリーの属性は、彼らが表す人々、組織、またはデバイスであるかもしれない本当の世界オブジェクトの描写的である情報を提供するのに使用されます。 ほとんどの国には、人々の情報の公表に関するプライバシー法があります。
General security considerations for accessing directory information with LDAP are discussed in [RFC4511] and [RFC4513].
[RFC4511]と[RFC4513]でLDAPと共にディレクトリ情報にアクセスするための総合証券問題について議論します。
9. IANA Considerations
9. IANA問題
The Internet Assigned Numbers Authority (IANA) has updated the LDAP descriptors registry as indicated in the following template:
インターネットAssigned民数記Authority(IANA)は以下のテンプレートにみられるようにLDAP記述子登録をアップデートしました:
Subject: Request for LDAP Descriptor Registration Update
Descriptor (short name): see comment
Object Identifier: see comment
Person & email address to contact for further information:
Kurt Zeilenga <kurt@OpenLDAP.org>
Usage: see comment
Specification: RFC 4512
Author/Change Controller: IESG
Comments:
Subject: LDAP Descriptor Registration Update Descriptor(省略名)のために以下を要求してください。 コメントObject Identifierを見てください: 詳細のために連絡するコメントPersonとEメールアドレスを見てください: カート Zeilenga <kurt@OpenLDAP.org 、gt;、用法: コメントSpecificationを見てください: RFC4512作者/変化コントローラ: IESGはコメントします:
The following descriptors (short names) has been added to
the registry.
以下の記述子(省略名)は登録に加えられます。
NAME Type OID
------------------------ ---- -----------------
governingStructureRule A 2.5.21.10
structuralObjectClass A 2.5.21.9
名前タイプOID------------------------ ---- ----------------- governingStructureRule A2.5.21.10structuralObjectClass A2.5.21、.9
The following descriptors (short names) have been updated to
refer to this RFC.
このRFCについて言及するために、以下の記述子(省略名)をアップデートしました。
NAME Type OID
------------------------ ---- -----------------
alias O 2.5.6.1
aliasedObjectName A 2.5.4.1
altServer A 1.3.6.1.4.1.1466.101.120.6
attributeTypes A 2.5.21.5
createTimestamp A 2.5.18.1
creatorsName A 2.5.18.3
dITContentRules A 2.5.21.2
dITStructureRules A 2.5.21.1
extensibleObject O 1.3.6.1.4.1.1466.101.120.111
ldapSyntaxes A 1.3.6.1.4.1.1466.101.120.16
名前タイプOID------------------------ ---- ----------------- 別名O2.5.6.1aliasedObjectName A2.5.4.1altServer A1.3.6.1.4.1.1466.101.120.6attributeTypes A2.5.21.5createTimestamp A2.5.18.1creatorsName A2.5.18.3dITContentRules A2.5.21.2dITStructureRules A2.5.21.1extensibleObject O1.3.6.1.4.1.1466.101.120.111ldapSyntaxes A1.3.6.1.4.1、.1466、.101、.120、.16
Zeilenga Standards Track [Page 43] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[43ページ]。
matchingRuleUse A 2.5.21.8
matchingRules A 2.5.21.4
modifiersName A 2.5.18.4
modifyTimestamp A 2.5.18.2
nameForms A 2.5.21.7
namingContexts A 1.3.6.1.4.1.1466.101.120.5
objectClass A 2.5.4.0
objectClasses A 2.5.21.6
subschema O 2.5.20.1
subschemaSubentry A 2.5.18.10
supportedControl A 1.3.6.1.4.1.1466.101.120.13
supportedExtension A 1.3.6.1.4.1.1466.101.120.7
supportedFeatures A 1.3.6.1.4.1.4203.1.3.5
supportedLDAPVersion A 1.3.6.1.4.1.1466.101.120.15
supportedSASLMechanisms A 1.3.6.1.4.1.1466.101.120.14
top O 2.5.6.0
matchingRuleUse A2.5.21.8matchingRules A2.5.21.4modifiersName A2.5.18.4modifyTimestamp A2.5.18.2nameForms A2.5.21.7namingContexts A1.3.6.1.4.1.1466.101.120.5objectClass A2.5.4.0objectClasses A2.5.21.6サブスキーマO2.5.20.1subschemaSubentry A2.5; 18.10がA1.3.6.1.4.1.1466.101.120.13supportedExtension A1.3.6.1.4.1.1466.101.120.7supportedFeatures A1.3.6.1.4.1.4203.1.3.5supportedLDAPVersion A1.3.6.1.4.1.1466.101.120.15supportedSASLMechanisms A1.3.6.1.4.1.1466.101.120.14先端O2.5に.6をsupportedControlする、.0
10. Acknowledgements
10. 承認
This document is based in part on RFC 2251 by M. Wahl, T. Howes, and S. Kille; RFC 2252 by M. Wahl, A. Coulbeck, T. Howes, S. Kille; and RFC 2556 by M. Wahl, all products of the IETF Access, Searching and Indexing of Directories (ASID) Working Group. This document is also based in part on "The Directory: Models" [X.501], a product of the International Telephone Union (ITU). Additional text was borrowed from RFC 2253 by M. Wahl, T. Howes, and S. Kille.
このドキュメントはM.ウォール、T.ハウズ、およびS.KilleによってRFC2251に一部基礎づけられています。 M.ウォール、A.Coulbeck、T.ハウズ、S.KilleによるRFC2252。 そして、M.ウォール、ディレクトリ(ASID)作業部会のIETF Access、Searching、およびIndexingのすべての製品によるRFC2556。 また、このドキュメントが一部基づいている、「ディレクトリ:」 「モデル」[X.501]、国際Telephone Unionの製品(ITU)。 追加テキストはM.ウォール、T.ハウズ、およびS.KilleによってRFC2253から借りられました。
This document is a product of the IETF LDAP Revision (LDAPBIS) Working Group.
このドキュメントはIETF LDAP Revision(LDAPBIS)作業部会の製品です。
Zeilenga Standards Track [Page 44] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[44ページ]。
11. Normative References
11. 引用規格
[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月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[RFC3671] Zeilenga, K., "Collective Attributes in the Lightweight
Directory Access Protocol (LDAP)", RFC 3671, December
2003.
[RFC3671] Zeilenga、K.、「ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)の集合的な属性」、RFC3671、2003年12月。
[RFC3672] Zeilenga, K., "Subentries in the Lightweight Directory
Access Protocol (LDAP)", RFC 3672, December 2003.
[RFC3672] Zeilenga、K.、「ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)の副次的記載」、RFC3672、2003年12月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422,
June 2006.
エド[RFC4422]メリニコフ、A.、K.Zeilenga、エド、「簡易認証とセキュリティは(SASL)を層にする」RFC4422、6月2006日
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
Protocol (LDAP): Technical Specification Road Map", RFC
4510, June 2006.
[RFC4510] Zeilenga、K.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「仕様書ロードマップ」、RFC4510、2006年6月。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「プロトコル」、RFC4511、2006年6月。
[RFC4513] Harrison, R., Ed., "Lightweight Directory Access
Protocol (LDAP): Authentication Methods and Security
Mechanisms", RFC 4513, June 2006.
[RFC4513] ハリソン、R.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「認証方法とセキュリティー対策」、RFC4513、6月2006日
[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月。
[RFC4515] Smith, M., Ed. and T. Howes, "Lightweight Directory
Access Protocol (LDAP): String Representation of Search
Filters", RFC 4515, June 2006.
[RFC4515] エドスミス、M.、T.ハウズ、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「検索フィルタのストリング表現」、RFC4515、2006年6月。
[RFC4516] Smith, M., Ed. and T. Howes, "Lightweight Directory
Access Protocol (LDAP): Uniform Resource Locator", RFC
4516, June 2006.
[RFC4516] エドスミス、M.、T.ハウズ、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「Uniform Resource Locator」、RFC4516、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月。
Zeilenga Standards Track [Page 45] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[45ページ]。
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
Protocol (LDAP): Schema for User Applications", RFC
4519, June 2006.
[RFC4519] Sciberras、A.、エド、「軽量のディレクトリアクセスは(LDAP)について議定書の中で述べます」。 「ユーザアプリケーションのための図式」、RFC4519、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月。
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version
3.0" (Reading, MA, Addison-Wesley, 2000. ISBN 0-201-
61633-5), as amended by the "Unicode Standard Annex
#27: Unicode 3.1"
(http://www.unicode.org/reports/tr27/) and by the
"Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
[ユニコード] ユニコードConsortium、「ユニコード規格、バージョン、3.2、0インチ、定義される、「ユニコード規格、修正されるバージョン3インチ(読書、MA、アディソン-ウエスリー、2000ISBN0-201- 61633-5)、「ユニコード規格別館#27:」 「ユニコード規格別館#28:」 ユニコード3.2インチ( http://www.unicode.org/reports/tr28/ )。
[X.500] International Telecommunication Union -
Telecommunication Standardization Sector, "The
Directory -- Overview of concepts, models and
services," X.500(1993) (also ISO/IEC 9594-1:1994).
[X.500]国際電気通信連合--電気通信Standardization Sector、「ディレクトリ--、概念の、そして、モデルの、そして、サービスの概要、」、X.500(1993)(ISO/IEC9594-1も: 1994)。
[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.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)。
Zeilenga Standards Track [Page 46] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[46ページ]。
Appendix A. Changes
付録A.変化
This appendix is non-normative.
この付録は非規範的です。
This document amounts to nearly a complete rewrite of portions of RFC 2251, RFC 2252, and RFC 2256. This rewrite was undertaken to improve overall clarity of technical specification. This appendix provides a summary of substantive changes made to the portions of these documents incorporated into this document. Readers should consult [RFC4510], [RFC4511], [RFC4517], and [RFC4519] for summaries of remaining portions of these documents.
このドキュメントはほとんどRFC2251、RFC2252、およびRFC2256の一部の完全な書き直しに達します。 この書き直しは、技術仕様書の総合的な明快を改良するために引き受けられました。 この付録はこのドキュメントに組み入れられたこれらのドキュメントの一部まで行われた実質的な変更の概要を提供します。 読者はこれらのドキュメントの残存部分の概要のために[RFC4510]、[RFC4511]、[RFC4517]、および[RFC4519]に相談するべきです。
A.1. Changes to RFC 2251
A.1。 RFC2251への変化
This document incorporates from RFC 2251, Sections 3.2 and 3.4, and portions of Sections 4 and 6 as summarized below.
このドキュメントは以下へまとめられるようにセクション4と6のRFC2251、セクション3.2と3.4、および一部から盛込まれます。
A.1.1. Section 3.2 of RFC 2251
A.1.1。 セクション3.2 RFC2251について
Section 3.2 of RFC 2251 provided a brief introduction to the X.500 data model, as used by LDAP. The previous specification relied on [X.501] but lacked clarity in how X.500 models are adapted for use by LDAP. This document describes the X.500 data models, as used by LDAP, in greater detail, especially in areas where adaptation is needed.
LDAPによって使用されるようにRFC2251のセクション3.2はX.500データモデルに簡潔な序論を供給しました。 前の仕様は、X.500モデルが使用のためにLDAPによってどう適合させられるかの明快を当てにしましたが[X.501]、欠いていました。 このドキュメントはX.500データモデルについて説明します、LDAPによって使用されるように、詳細によりすばらしい、特に適合が必要である領域で。
Section 3.2.1 of RFC 2251 described an attribute as "a type with one or more associated values". In LDAP, an attribute is better described as an attribute description, a type with zero or more options, and one or more associated values.
.1セクション3.2RFC2251が「1つ以上の関連値があるタイプ」として属性を記述しました。 LDAPでは、属性は属性記述として記述されているほうがよいです、とゼロか以上があるオプションの、そして、関連づけられたよりもののタイプは評価します。
Section 3.2.2 of RFC 2251 mandated that subschema subentries contain objectClasses and attributeTypes attributes, yet X.500(93) treats these attributes as optional. While generally all implementations that support X.500(93) subschema mechanisms will provide both of these attributes, it is not absolutely required for interoperability that all servers do. The mandate was removed for consistency with X.500(93). The subschema discovery mechanism was also clarified to indicate that subschema controlling an entry is obtained by reading the (sub)entry referred to by that entry's 'subschemaSubentry' attribute.
.2セクション3.2RFC2251が、サブスキーマ副次的記載がobjectClassesとattributeTypes属性を含んでいて、しかし、X.500(93)が任意であるとしてこれらの属性を扱うのを強制しました。 X.500(93)サブスキーマがメカニズムであるとサポートする一般にすべての実装がこれらの属性の両方を提供している間、それはすべてのサーバがする相互運用性に絶対に必要ではありません。 一貫性のためにX.500(93)と共に命令を取り除きました。 また、サブスキーマ発見メカニズムは、エントリーを制御するサブスキーマがそのエントリーの'subschemaSubentry'属性によって言及された(潜水艦)エントリーを読むことによって得られるのを示すためにはっきりさせられました。
Zeilenga Standards Track [Page 47] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[47ページ]。
A.1.2. Section 3.4 of RFC 2251
A.1.2。 セクション3.4 RFC2251について
Section 3.4 of RFC 2251 provided "Server-specific Data Requirements". This material, with changes, was incorporated in Section 5.1 of this document.
RFC2251のセクション3.4は「サーバ特有のデータ要件」を提供しました。 変化で、この材料はこのドキュメントのセクション5.1に組み込んでいました。
Changes:
変化:
- Clarify that attributes of the root DSE are subject to "other
restrictions" in addition to access controls.
- 「他の制限」を条件として根のDSEの属性に加えているそれをはっきりさせてください。アクセス制御。
- Clarify that only recognized extended requests need to be
enumerated 'supportedExtension'.
- 列挙された'supportedExtension'であるその唯一の認識された拡張要求の必要性をはっきりさせてください。
- Clarify that only recognized request controls need to be enumerated
'supportedControl'.
- コントロールが列挙された'supportedControl'になるように必要とするその唯一の認識された要求をはっきりさせてください。
- Clarify that root DSE attributes are operational and, like other
operational attributes, will not be returned in search requests
unless requested by name.
- その根のDSE属性をはっきりさせてください。他の操作上の属性のように、操作上であり、名前によって要求されないと、検索要求で返されないでしょう。
- Clarify that not all root DSE attributes are user modifiable.
- はっきりさせてください。すべての根のDSE属性がどんなユーザ修正できるというわけではありません。
- Remove inconsistent text regarding handling of the
'subschemaSubentry' attribute within the root DSE. The previous
specification stated that the 'subschemaSubentry' attribute held in
the root DSE referred to "subschema entries (or subentries) known
by this server". This is inconsistent with the attribute's
intended use as well as its formal definition as a single valued
attribute [X.501]. It is also noted that a simple (possibly
incomplete) list of subschema (sub)entries is not terribly useful.
This document (in Section 5.1) specifies that the
'subschemaSubentry' attribute of the root DSE refers to the
subschema controlling the root DSE. It is noted that the general
subschema discovery mechanism remains available (see Section 4.4 of
this document).
- 根のDSEの中で'subschemaSubentry'属性の取り扱いに関する矛盾したテキストを取り除いてください。 前の仕様は、根のDSEに保持された'subschemaSubentry'属性が「このサーバによって知られていたサブスキーマエントリー(または、副次的記載)」について言及したと述べました。 シングルが属性[X.501]を評価したので、これは公式の定義と同様に属性の意図している使用に矛盾しています。 また、サブスキーマ(潜水艦)エントリーの簡単な(ことによると不完全な)リストがものすごく役に立たないことに注意されます。 このドキュメント(セクション5.1における)は、根のDSEの'subschemaSubentry'属性が根のDSEを制御するサブスキーマについて言及すると指定します。 一般的なサブスキーマ発見メカニズムが利用可能なままで残っていることに(このドキュメントのセクション4.4を見てください)注意されます。
A.1.3. Section 4 of RFC 2251
A.1.3。 セクション4 RFC2251について
Portions of Section 4 of RFC 2251 detailing aspects of the information model used by LDAP were incorporated in this document, including:
LDAPによって使用された情報モデルの局面を詳しく述べるRFC2251のセクション4の部分は本書では法人組織でした、である:
- Restriction of distinguished values to attributes whose
descriptions have no options (from Section 4.1.3);
- 記述にはオプション(セクション4.1.3からの)が全くない属性への顕著な値の制限。
Zeilenga Standards Track [Page 48] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[48ページ]。
- Data model aspects of Attribute Types (from Section 4.1.4),
Attribute Descriptions (from 4.1.5), Attribute (from 4.1.8),
Matching Rule Identifier (from 4.1.9); and
- データはAttribute Types(セクション4.1.4からの)について局面をモデル化します、Attribute記述、(4.1、.5)、Attribute、(4.1、.8)、Matching Rule Identifier、(4.1、.9、)、。 そして
- User schema requirements (from Sections 4.1.6, 4.5.1, and 4.7).
- そして、ユーザ図式要件、(セクション4.1 .6 4.5 .1、4.7)
Clarifications to these portions include:
これらの部分への明確化は:
- Subtyping and AttributeDescriptions with options.
- オプションがあるSubtypingとAttributeDescriptions。
A.1.4. Section 6 of RFC 2251
A.1.4。 セクション6 RFC2251について
The Section 6.1 and the second paragraph of Section 6.2 of RFC 2251 where incorporated into this document.
セクション6.1と秒はこのドキュメントに組み入れられるところでRFC2251のセクション6.2について短い記事を書きます。
A.2. Changes to RFC 2252
A.2。 RFC2252への変化
This document incorporates Sections 4, 5, and 7 from RFC 2252.
このドキュメントはRFC2252からセクション4、5、および7を法人組織にします。
A.2.1. Section 4 of RFC 2252
A.2.1。 セクション4 RFC2252について
The specification was updated to use Augmented BNF [RFC4234]. The string representation of an OBJECT IDENTIFIER was tightened to disallow leading zeros as described in RFC 2252.
Augmented BNF[RFC4234]を使用するために仕様をアップデートしました。 OBJECT IDENTIFIERのストリング表現は、RFC2252で説明されるように先行ゼロを禁じるためにきびしくされました。
The <descr> syntax was changed to disallow semicolon (U+003B) characters in order to appear to be consistent its natural language specification "descr is the syntactic representation of an object descriptor, which consists of letters and digits, starting with a letter". In a related change, the statement "an AttributeDescription can be used as the value in a NAME part of an AttributeTypeDescription" was deleted. RFC 2252 provided no specification of the semantics of attribute options appearing in NAME fields.
<descr>構文は一貫しているように見えて、セミコロン(U+003B)キャラクタを禁じるために変えて、自然言語仕様が「descrに、手紙から始まって、手紙とケタから成るオブジェクト記述子の統語表示である」ということでした。 関連変化では、「値としてAttributeTypeDescriptionのNAME部分でAttributeDescriptionを使用できる」という声明は削除されました。 RFC2252はNAME分野に現れる属性オプションの意味論の仕様を全く提供しませんでした。
RFC 2252 stated that the <descr> form of <oid> SHOULD be preferred
over the <numericoid> form. However, <descr> form can be ambiguous.
To address this issue, the imperative was replaced with a statement
(in Section 1.4) that while the <descr> form is generally preferred,
<numericoid> should be used where an unambiguous <descr> is not
available. Additionally, an expanded discussion of descriptor issues
is in Section 6.2 ("Short Names").
RFC2252は、<oid>SHOULDの<descr>フォームが<numericoid>フォームより好まれると述べました。 しかしながら、<descr>フォームはあいまいである場合があります。 この問題を扱うために、命令を一般に、<descr>フォームが好まれている間<numericoid>が明白な<descr>が入手できないところで使用されるべきであるという声明(セクション1.4における)に取り替えました。 さらに、記述子問題の拡張議論がセクション6.2(「省略名」)にあります。
The ABNF for a quoted string (qdstring) was updated to reflect support for the escaping mechanism described in Section 4.3 of RFC 2252.
RFC2252のセクション4.3で説明されたエスケープメカニズムのサポートを反映するために引用文字列(qdstring)のためのABNFをアップデートしました。
Zeilenga Standards Track [Page 49] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[49ページ]。
A.2.2. Section 5 of RFC 2252
A.2.2。 セクション5 RFC2252について
Definitions of operational attributes provided in Section 5 of RFC 2252 where incorporated into this document.
操作上の属性の定義はこのドキュメントに組み入れられたどこをRFC2252のセクション5に提供したか。
The 'namingContexts' description was clarified. A first-level DSA should publish, in addition to other values, "" indicating the root of the DIT.
'namingContexts'記述ははっきりさせられました。 最初に、レベルDSAが他の値に加えて発行するはずである、「「デイットの根を示すこと」。
The 'altServer' description was clarified. It may hold any URI.
'altServer'記述ははっきりさせられました。 それはどんなURIも保持するかもしれません。
The 'supportedExtension' description was clarified. A server need only list the OBJECT IDENTIFIERs associated with the extended requests of the extended operations it recognizes.
'supportedExtension'記述ははっきりさせられました。 サーバはそれが認識する拡大手術の拡張要求に関連しているOBJECT IDENTIFIERsを記載するだけでよいです。
The 'supportedControl' description was clarified. A server need only list the OBJECT IDENTIFIERs associated with the request controls it recognizes.
'supportedControl'記述ははっきりさせられました。 サーバはそれが認識する要求コントロールに関連しているOBJECT IDENTIFIERsを記載するだけでよいです。
Descriptions for the 'structuralObjectClass' and 'governingStructureRule' operational attribute types were added.
'structuralObjectClass'と'governingStructureRule'操作上の属性タイプのための記述は加えられました。
The attribute definition of 'subschemaSubentry' was corrected to list the terms SINGLE-VALUE and NO-USER-MODIFICATION in proper order.
'subschemaSubentry'の属性定義は、SINGLE-VALUEを記載しますが、適切なオーダーにどんな用語USER-MODIFICATIONも記載しないように修正されました。
A.2.3. Section 7 of RFC 2252
A.2.3。 セクション7 RFC2252について
Section 7 of RFC 2252 provides definitions of the 'subschema' and 'extensibleObject' object classes. These definitions where integrated into Section 4.2 and Section 4.3 of this document, respectively. Section 7 of RFC 2252 also contained the object class implementation requirement. This was incorporated into Section 7 of this document.
RFC2252のセクション7は'サブスキーマ'と'extensibleObject'オブジェクトのクラスの定義を提供します。 これらの定義、それぞれこのドキュメントのセクション4.2とセクション4.3と統合されるところで。 また、RFC2252のセクション7はオブジェクトクラス実装要件を含みました。 これはこのドキュメントのセクション7に組み入れられました。
The specification of 'extensibleObject' was clarified regarding how it interacts with precluded attributes.
それがどう排除された属性と対話するかに関して'extensibleObject'の仕様ははっきりさせられました。
A.3. Changes to RFC 2256
A.3。 RFC2256への変化
This document incorporates Sections 5.1, 5.2, 7.1, and 7.2 of RFC 2256.
このドキュメントはRFC2256のセクション5.1、5.2、7.1、および7.2を法人組織にします。
Section 5.1 of RFC 2256 provided the definition of the 'objectClass' attribute type. This was integrated into Section 2.4.1 of this document. The statement "One of the values is either 'top' or 'alias'" was replaced with statement that one of the values is 'top' as entries belonging to 'alias' also belong to 'top'.
RFC2256のセクション5.1は'objectClass'属性タイプの定義を提供しました。 これはこの.1通のセクション2.4ドキュメントと統合されました。 「値の1つはどちらかの'先端'であるか'通称'」という声明を声明値の1つが'また、最高''別名に属すエントリー'は'先端に属します'であるに取り替えました。
Zeilenga Standards Track [Page 50] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[50ページ]。
Section 5.2 of RFC 2256 provided the definition of the 'aliasedObjectName' attribute type. This was integrated into Section 2.6.2 of this document.
RFC2256のセクション5.2は'aliasedObjectName'属性タイプの定義を提供しました。 これはこの.2通のセクション2.6ドキュメントと統合されました。
Section 7.1 of RFC 2256 provided the definition of the 'top' object class. This was integrated into Section 2.4.1 of this document.
RFC2256のセクション7.1は'最高'のオブジェクトのクラスの定義を提供しました。 これはこの.1通のセクション2.4ドキュメントと統合されました。
Section 7.2 of RFC 2256 provided the definition of the 'alias' object class. This was integrated into Section 2.6.1 of this document.
RFC2256のセクション7.2は'別名'オブジェクトのクラスの定義を提供しました。 これはこの.1通のセクション2.6ドキュメントと統合されました。
A.4. Changes to RFC 3674
A.4。 RFC3674への変化
This document made no substantive change to the 'supportedFeatures' technical specification provided in RFC 3674.
このドキュメントはRFC3674に提供された'supportedFeatures'技術仕様書へのどんな実質的な変更も行いませんでした。
Editor's Address
エディタのアドレス
Kurt D. Zeilenga OpenLDAP Foundation
カートD.Zeilenga OpenLDAP財団
EMail: Kurt@OpenLDAP.org
メール: Kurt@OpenLDAP.org
Zeilenga Standards Track [Page 51] RFC 4512 LDAP Models June 2006
Zeilenga規格は2006年6月にRFC4512LDAPモデルを追跡します[51ページ]。
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 52]
Zeilenga標準化過程[52ページ]
一覧
スポンサーリンク
