RFC3672 日本語訳
3672 Subentries in the Lightweight Directory Access Protocol (LDAP).K. Zeilenga. December 2003. (Format: TXT=24447 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group K. Zeilenga
Request for Comments: 3672 OpenLDAP Foundation
Category: Standards Track S. Legg
Adacel Technologies
December 2003
Zeilengaがコメントのために要求するワーキンググループK.をネットワークでつないでください: 3672年のOpenLDAP財団カテゴリ: 標準化過程S.Legg Adacel技術2003年12月
Subentries in the Lightweight Directory Access Protocol (LDAP)
ライトウェイト・ディレクトリ・アクセス・プロトコルの副次的記載(LDAP)
Status of this Memo
この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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
In X.500 directories, subentries are special entries used to hold information associated with a subtree or subtree refinement. This document adapts X.500 subentries mechanisms for use with the Lightweight Directory Access Protocol (LDAP).
X.500ディレクトリでは、副次的記載は、下位木に関連している情報を保持するのに使用される特別なエントリーか下位木気品です。 このドキュメントはライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)との使用のためにX.500副次的記載メカニズムを適合させます。
1. Overview
1. 概観
From [X.501]:
[X.501]から:
A subentry is a special kind of entry immediately subordinate to
an administrative point. It contains attributes that pertain to
a subtree (or subtree refinement) associated with its
administrative point. The subentries and their administrative
point are part of the same naming context.
副次的記載はすぐに管理ポイントへの下位のエントリーの特別な種類です。 それは管理ポイントに関連している下位木(または、下位木気品)に関係する属性を含んでいます。 副次的記載とそれらの管理ポイントは同じ命名文脈の一部です。
A single subentry may serve all or several aspects of
administrative authority. Alternatively, a specific aspect of
administrative authority may be handled through one or more of
its own subentries.
ただ一つの副次的記載は職務権限のすべてかいくつかの局面に役立つかもしれません。 あるいはまた、職務権限の特定の局面はそれ自身の副次的記載の1つ以上を通して扱われるかもしれません。
Subentries in the Lightweight Directory Access Protocol (LDAP) [RFC3377] SHALL behave in accordance with X.501 unless noted otherwise in this specification.
別の方法でこの仕様に述べられない場合X.501によると、SHALLが振る舞わせるライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)[RFC3377]の副次的記載。
Zeilenga & Legg Standards Track [Page 1] RFC 3672 Subentries in LDAP December 2003
Zeilenga&Legg規格は2003年12月にLDAPのRFC3672副次的記載を追跡します[1ページ]。
In absence of the subentries control (detailed in Section 3), subentries SHALL NOT be considered in one-level and subtree scope search operations. For all other operations, including base scope search operations, subentries SHALL be considered.
副次的記載SHALL NOT、副次的記載の欠如では、制御してください(セクション3で詳細な)。1レベルと下位木範囲索敵行動では、考えられてください。 ベース範囲索敵行動、副次的記載SHALLを含む他のすべての操作には、考えられてください。
1.1. Conventions
1.1. コンベンション
Schema definitions are provided using LDAP description formats [RFC2252]. Definitions provided here are formatted (line wrapped) for readability.
LDAP記述形式[RFC2252]を使用することで図式定義を提供します。 ここに提供された定義は読み易さのためにフォーマットされます(包装された線)。
Protocol elements are described using ASN.1 [X.680]. The term "BER- encoded" means the element is to be encoded using the Basic Encoding Rules [X.690] under the restrictions detailed in Section 5.1 of [RFC2251].
プロトコル要素は、ASN.1[X.680]を使用することで説明されます。 「コード化されたBER」という用語は、要素が[RFC2251]のセクション5.1で詳細な制限でBasic Encoding Rules[X.690]を使用することでコード化されることであることを意味します。
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]で説明されるように本書では解釈されることであるべきですか?
2. Subentry Schema
2. 副次的記載図式
2.1. Subtree Specification Syntax
2.1. 下位木仕様構文
The Subtree Specification syntax provides a general purpose mechanism for the specification of a subset of entries in a subtree of the Directory Information Tree (DIT). A subtree begins at some base entry and includes the subordinates of that entry down to some identified lower boundary, possibly extending to the leaf entries. A subtree specification is always used within a context or scope which implicitly determines the bounds of the subtree. For example, the scope of a subtree specification for a subschema administrative area does not include the subtrees of any subordinate administrative point entries for subschema administration. Where a subtree specification does not identify a contiguous subset of the entries within a single subtree the collection is termed a subtree refinement.
Subtree Specification構文はディレクトリ情報Tree(DIT)の下位木でエントリーの部分集合の仕様に汎用のメカニズムを提供します。 下位木は、何らかの特定された低い境界までいくらかのベースエントリーで始まって、そのエントリーの部下を含んでいます、ことによると葉のエントリーに達して。 下位木仕様はそれとなく下位木の領域を決定する文脈か範囲の中でいつも使用されます。 例えば、サブスキーマ行政区域のための下位木仕様の範囲はサブスキーマ管理のためのどんな下位の管理ポイントエントリーの下位木も含んでいません。 下位木仕様がただ一つの下位木の中でエントリーの隣接の部分集合を特定しないところでは、収集は下位木気品と呼ばれます。
This syntax corresponds to the SubtreeSpecification ASN.1 type described in [X.501], Section 11.3. This ASN.1 data type definition is reproduced here for completeness.
この構文は[X.501]、セクション11.3で説明されたSubtreeSpecification ASN.1タイプに文通されます。 このASN.1データ型定義は完全性のためにここで再生します。
SubtreeSpecification ::= SEQUENCE {
base [0] LocalName DEFAULT { },
COMPONENTS OF ChopSpecification,
specificationFilter [4] Refinement OPTIONAL }
SubtreeSpecification:、:= 系列[0] LocalName DEFAULTを基礎づけてください、COMPONENTS OF ChopSpecification、specificationFilter[4]気品OPTIONAL
LocalName ::= RDNSequence
LocalName:、:= RDNSequence
Zeilenga & Legg Standards Track [Page 2] RFC 3672 Subentries in LDAP December 2003
Zeilenga&Legg規格は2003年12月にLDAPのRFC3672副次的記載を追跡します[2ページ]。
ChopSpecification ::= SEQUENCE {
specificExclusions [1] SET OF CHOICE {
chopBefore [0] LocalName,
chopAfter [1] LocalName } OPTIONAL,
minimum [2] BaseDistance DEFAULT 0,
maximum [3] BaseDistance OPTIONAL }
ChopSpecification:、:= 系列specificExclusions[1]SET OF CHOICE、chopBefore[0]LocalName、chopAfter[1]LocalName、OPTIONAL、最小限[2]BaseDistance DEFAULT0、最大[3]BaseDistance OPTIONAL
BaseDistance ::= INTEGER (0 .. MAX)
BaseDistance:、:= 整数(0 マックス)
Refinement ::= CHOICE {
item [0] OBJECT-CLASS.&id,
and [1] SET OF Refinement,
or [2] SET OF Refinement,
not [3] Refinement }
気品:、:= 選択項目[0]OBJECT-CLASS[3]気品ではなく、イドと、[1]SET OF Refinementか、[2]SET OF Refinement
The components of SubtreeSpecification are: base, which identifies
the base entry of the subtree or subtree refinement, and
specificExclusions, minimum, maximum and specificationFilter, which
then reduce the set of subordinate entries of the base entry. The
subtree or subtree refinement contains all the entries within scope
that are not excluded by any of the components of the subtree
specification. When all of the components of SubtreeSpecification
are absent (i.e., when a value of the Subtree Specification syntax is
the empty sequence, {}), the specified subtree implicitly includes
all the entries within scope.
SubtreeSpecificationの部品は以下の通りです。 次にベースエントリーの下位のエントリーのセットを減少させるベース、最小の、そして、最大のspecificExclusions、およびspecificationFilter。(それは、下位木か下位木気品のベースエントリーを特定します)。 下位木か下位木気品が範囲の中の下位木仕様の成分のいずれによっても除かれないすべてのエントリーを含んでいます。 SubtreeSpecificationの部品のすべてが休んでいます。いつ、(すなわち、aであるときに、Subtree Specification構文の値が空の系列であるか、)、指定された下位木は範囲の中にそれとなくすべてのエントリーを含んでいます。
Any particular use of this mechanism MAY impose limitations or constraints on the components of SubtreeSpecification.
このメカニズムのどんな特定の使用も制限か規制をSubtreeSpecificationの部品に課すかもしれません。
The LDAP syntax specification is:
LDAP構文仕様は以下の通りです。
( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' )
(1.3、.6、.1、.4、.1、.1466、.115、.121、.1、.45DESC'SubtreeSpecification')
The LDAP-specific encoding of values of this syntax is defined by the Generic String Encoding Rules [RFC3641]. Appendix A provides an equivalent Augmented Backus-Naur Form (ABNF) [RFC2234] for this syntax.
この構文の値のLDAP特有のコード化はGeneric String Encoding Rules[RFC3641]によって定義されます。 付録Aは同等なAugmented BN記法(ABNF)[RFC2234]をこの構文に提供します。
2.1.1. Base
2.1.1. 基地
The base component of SubtreeSpecification nominates the base entry of the subtree or subtree refinement. The base entry may be an entry which is subordinate to the root entry of the scope in which the subtree specification is used, in which case the base component contains a sequence of Relative Distinguished Names (RDNs) relative to the root entry of the scope, or may be the root entry of the scope itself (the default), in which case the base component is absent or contains an empty sequence of RDNs.
SubtreeSpecificationの基底部門は下位木か下位木気品のベースエントリーを指名します。 ベースエントリーが下位木仕様が使用されている範囲の根のエントリーへの下位のエントリーであるかもしれない、その場合、基底部門が範囲の根のエントリーに比例してRelative Distinguished Names(RDNs)の系列を含んでいるか、または範囲(デフォルト)自体の根のエントリーであるかもしれない、その場合、基底部門は休むか、またはRDNsの空の系列を含んでいます。
Zeilenga & Legg Standards Track [Page 3] RFC 3672 Subentries in LDAP December 2003
Zeilenga&Legg規格は2003年12月にLDAPのRFC3672副次的記載を追跡します[3ページ]。
Entries that are not subordinates of the base entry are excluded from the subtree or subtree refinement.
ベースエントリーの部下でないエントリーは下位木か下位木気品から除かれます。
2.1.2. Specific Exclusions
2.1.2. 特定の除外
The specificExclusions component of a ChopSpecification is a list of exclusions that specify entries and their subordinates to be excluded from the subtree or subtree refinement. The entry is specified by a sequence of RDNs relative to the base entry (i.e., a LocalName). Each exclusion is of either the chopBefore or chopAfter form. If the chopBefore form is used then the specified entry and its subordinates are excluded from the subtree or subtree refinement. If the chopAfter form is used then only the subordinates of the specified entry are excluded from the subtree or subtree refinement.
ChopSpecificationのspecificExclusionsの部品は下位木か下位木気品から除かれるためにエントリーと彼らの部下を指定する除外のリストです。 エントリーはRDNsの系列によってベースエントリー(すなわち、LocalName)に比例して指定されます。 各除外はchopBeforeかchopAfterフォームのものです。 chopBeforeフォームが使用されているなら、指定されたエントリーとその部下は下位木か下位木気品から除かれます。 chopAfterフォームが使用されているなら、指定されたエントリーの部下だけが下位木か下位木気品から除かれます。
2.1.3. Minimum and Maximum
2.1.3. 最小であって、最大です。
The minimum and maximum components of a ChopSpecification allow the exclusion of entries based on their depth in the DIT.
ChopSpecificationの最小の、そして、最大の部品はDITでそれらの深さに基づくエントリーの除外を許します。
Entries that are less than the minimum number of RDN arcs below the base entry are excluded from the subtree or subtree refinement. A minimum value of zero (the default) corresponds to the base entry.
RDNアークの最小の数以下であるエントリーはベースエントリーの下で下位木か下位木気品から除かれます。 ゼロ(デフォルト)の最小値はベースエントリーに対応しています。
Entries that are more than the maximum number of RDN arcs below the base entry are excluded from the subtree or subtree refinement. An absent maximum component indicates that there is no upper limit on the number of RDN arcs below the base entry for entries in the subtree or subtree refinement.
RDNアークの最大数以上であるエントリーはベースエントリーの下で下位木か下位木気品から除かれます。 欠けている最大のコンポーネントは、下位木か下位木気品におけるエントリーのためのベースエントリーの下に上限が全くRDNアークの数にないのを示します。
2.1.4. Specification Filter
2.1.4. 仕様フィルタ
The specificationFilter component is a boolean expression of assertions about the values of the objectClass attribute of the base entry and its subordinates. A Refinement assertion item evaluates to true for an entry if that entry's objectClass attribute contains the OID nominated in the assertion. Entries for which the overall filter evaluates to false are excluded from the subtree refinement. If the specificationFilter is absent then no entries are excluded from the subtree or subtree refinement because of their objectClass attribute values.
specificationFilterの部品はベースエントリーとその部下のobjectClass属性の値に関する主張の論理演算子表現です。 Refinement主張の品目は、そのエントリーのobjectClass属性が主張で指名されたOIDを含むかどうかエントリーに本当に評価します。 フィルタが誤っているのに評価する総合的が下位木気品から除かれるエントリー。 specificationFilterが欠けるなら、エントリーは全くそれらのobjectClass属性値のために下位木か下位木気品から除かれません。
Zeilenga & Legg Standards Track [Page 4] RFC 3672 Subentries in LDAP December 2003
Zeilenga&Legg規格は2003年12月にLDAPのRFC3672副次的記載を追跡します[4ページ]。
2.2. Administrative Role Attribute Type
2.2. 管理役割の属性タイプ
The Administrative Model defined in [X.501], clause 10 requires that administrative entries contain an administrativeRole attribute to indicate that the associated administrative area is concerned with one or more administrative roles.
[X.501]で定義されたAdministrative Model、10番目の節は関連行政区域は1つ以上の管理役割に関係があるのを示すために管理エントリーがadministrativeRole属性を含むのを必要とします。
The administrativeRole operational attribute is specified as follows:
administrativeRoleの操作上の属性は以下の通り指定されます:
( 2.5.18.5 NAME 'administrativeRole'
EQUALITY objectIdentifierMatch
USAGE directoryOperation
SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
(2.5.18.5名'administrativeRole'平等objectIdentifierMatch用法directoryOperation構文1.3.6.1.4.1.1466.115の.121、.1、.38)
The possible values of this attribute defined in X.501 are:
X.501で定義されたこの属性の可能な値は以下の通りです。
OID NAME
-------- -------------------------------
2.5.23.1 autonomousArea
2.5.23.2 accessControlSpecificArea
2.5.23.3 accessControlInnerArea
2.5.23.4 subschemaAdminSpecificArea
2.5.23.5 collectiveAttributeSpecificArea
2.5.23.6 collectiveAttributeInnerArea
OID名-------- ------------------------------- 2.5.23.1 autonomousArea2.5.23.2accessControlSpecificArea2.5.23.3accessControlInnerArea2.5.23.4subschemaAdminSpecificArea2.5.23.5collectiveAttributeSpecificArea2.5.23、.6collectiveAttributeInnerArea
Other values may be defined in other specifications. Names associated with each administrative role are Object Identifier Descriptors [RFC3383].
他の値は他の仕様に基づき定義されるかもしれません。 それぞれの管理役割に関連している名前はObject Identifier Descriptors[RFC3383]です。
The administrativeRole operational attribute is also used to regulate the subentries permitted to be subordinate to an administrative entry. A subentry not of a class permitted by the administrativeRole attribute cannot be subordinate to the administrative entry.
また、administrativeRoleの操作上の属性は、管理エントリーに下位であることが許可された副次的記載を規制するのに使用されます。 administrativeRole属性によって受入れられなかったどんなクラスの副次的記載も管理エントリーに下位であるはずがありません。
2.3. Subtree Specification Attribute Type
2.3. 下位木仕様属性タイプ
The subtreeSpecification operational attribute is defined as follows:
subtreeSpecificationの操作上の属性は以下の通り定義されます:
( 2.5.18.6 NAME 'subtreeSpecification'
SINGLE-VALUE
USAGE directoryOperation
SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 )
(2.5.18.6名'subtreeSpecification'ただ一つの価値の用法directoryOperation構文1.3.6.1.4.1の.1466、.115、.121、.1、.45)
This attribute is present in all subentries. See [X.501], clause 10. Values of the subtreeSpecification attribute nominate collections of entries within the DIT for one or more aspects of administrative authority.
この属性はすべての副次的記載に存在しています。 [X.501]、10番目の節を見てください。 subtreeSpecification属性の値はDITの中で職務権限の1つ以上の局面にエントリーの収集を指名します。
Zeilenga & Legg Standards Track [Page 5] RFC 3672 Subentries in LDAP December 2003
Zeilenga&Legg規格は2003年12月にLDAPのRFC3672副次的記載を追跡します[5ページ]。
2.4. Subentry Object Class
2.4. 副次的記載物のクラス
The subentry object class is a structural object class.
副次的記載物のクラスは構造的な物のクラスです。
( 2.5.17.0 NAME 'subentry'
SUP top STRUCTURAL
MUST ( cn $ subtreeSpecification ) )
(2.5.17.0NAME'副次的記載'SUP先端STRUCTURAL MUST(cn$subtreeSpecification))
3. Subentries Control
3. 副次的記載コントロール
The subentries control MAY be sent with a searchRequest to control the visibility of entries and subentries which are within scope. Non-visible entries or subentries are not returned in response to the request.
範囲の中にあるエントリーと副次的記載の目に見えることを制御するためにsearchRequestと共に副次的記載コントロールを送るかもしれません。 非目に見えるエントリーか副次的記載が要求に対応して返されません。
The subentries control is an LDAP Control whose controlType is 1.3.6.1.4.1.4203.1.10.1, criticality is TRUE or FALSE (hence absent), and controlValue contains a BER-encoded BOOLEAN indicating visibility. A controlValue containing the value TRUE indicates that subentries are visible and normal entries are not. A controlValue containing the value FALSE indicates that normal entries are visible and subentries are not.
コントロールはcontrolTypeがあるLDAP Controlです。副次的記載、1.3 .6 .1 .4 .1 .4203 .1 .10 .1 臨界は、TRUEかFALSE(したがって、休んでいる)であり、controlValueはBERによってコード化されたブール表示目に見えることを含んでいます。 値のTRUEを含むcontrolValueは、副次的記載が目に見えるのを示します、そして、通常のエントリーはそのように示しません。 値のFALSEを含むcontrolValueは、通常のエントリーが目に見えるのを示します、そして、副次的記載はそのように示しません。
Note that TRUE visibility has the three octet encoding { 01 01 FF }
and FALSE visibility has the three octet encoding { 01 01 00 }.
TRUE目に見えることには01 01FFをコード化する3八重奏があって、FALSE目に見えることに01 01 00をコード化する3八重奏があることに注意してください。
The controlValue SHALL NOT be absent.
controlValue SHALL NOT、休んでください。
In absence of this control, subentries are not visible to singleLevel and wholeSubtree scope Search requests but are visible to baseObject scope Search requests.
このコントロールの欠如では、副次的記載は、singleLevelとwholeSubtree範囲検索要求に目に見えませんが、baseObject範囲検索要求に目に見えます。
There is no corresponding response control.
どんな対応する応答制御もありません。
This control is not appropriate for non-Search operations.
非索敵行動には、このコントロールは適切ではありません。
4. Security Considerations
4. セキュリティ問題
Subentries often hold administrative information or other sensitive information and should be protected from unauthorized access and disclosure as described in [RFC2829][RFC2830].
副次的記載は、[RFC2829][RFC2830]で説明されるようにしばしば管理情報か他の機密情報を保持して、不正アクセスと公開から保護されるべきです。
General LDAP [RFC3377] security considerations also apply.
また、LDAP司令官[RFC3377]セキュリティ問題は適用されます。
Zeilenga & Legg Standards Track [Page 6] RFC 3672 Subentries in LDAP December 2003
Zeilenga&Legg規格は2003年12月にLDAPのRFC3672副次的記載を追跡します[6ページ]。
5. IANA Considerations
5. IANA問題
5.1. Descriptors
5.1. 記述子
The IANA has registered the LDAP descriptors detailed in this technical specification. The following registration template is suggested:
IANAはこの技術仕様書で詳細なLDAP記述子を登録しました。 以下の登録テンプレートは示されます:
Subject: Request for LDAP Descriptor Registration
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: RFC3672
Author/Change Controller: IESG
Comments:
Subject: LDAP Descriptor Registration Descriptor(省略名)のために以下を要求してください。 コメントObject Identifierを見てください: 詳細のために連絡するコメントPersonとEメールアドレスを見てください: カート Zeilenga <kurt@OpenLDAP.org 、gt;、用法: コメントSpecificationを見てください: RFC3672はコントローラを書くか、または変えます: IESGはコメントします:
NAME Type OID
------------------------ ---- --------
accessControlInnerArea R 2.5.23.3
accessControlSpecificArea R 2.5.23.2
administrativeRole A 2.5.18.5
autonomousArea R 2.5.23.1
collectiveAttributeInnerArea R 2.5.23.6
collectiveAttributeSpecificArea R 2.5.23.5
subentry O 2.5.17.0
subschemaAdminSpecificArea R 2.5.23.4
subtreeSpecification A 2.5.18.6
名前タイプOID------------------------ ---- -------- accessControlInnerArea R2.5.23.3accessControlSpecificArea R2.5.23.2administrativeRole A2.5.18.5autonomousArea R2.5.23.1collectiveAttributeInnerArea R2.5.23.6collectiveAttributeSpecificArea R2.5.23.5副次的記載O2.5.17.0subschemaAdminSpecificArea R2.5.23.4subtreeSpecification A2.5.18.6
where Type A is Attribute, Type O is ObjectClass, and Type R is
Administrative Role.
Type AがAttributeであるところでは、Type OはObjectClassです、そして、Type RはAdministrative Roleです。
5.2. Object Identifiers
5.2. 物の識別子
This document uses the OID 1.3.6.1.4.1.4203.1.10.1 to identify an LDAP protocol element defined herein. This OID was assigned [ASSIGN] by OpenLDAP Foundation, under its IANA-assigned private enterprise allocation [PRIVATE], for use in this specification.
このドキュメントはOID1.3を使用します。.6 .1 .4 .1 .4203 .1 .10 .1 ここに定義されたLDAPプロトコル要素を特定するために。 [ASSIGN]はOpenLDAP財団によってこのOIDにこの仕様に基づく使用のためのIANAによって割り当てられた私企業配分[兵士]で割り当てられました。
Other OIDs which appear in this document were either assigned by the ISO/IEC Joint Technical Committee 1 - Subcommittee 6 to identify elements of X.500 schema or assigned in RFC 2252 for the use described here.
現れる他のOIDsがISO/IEC Joint Technical Committee1によって本書では割り当てられました--図式の、または、ここで説明された使用のためにRFC2252で割り当てられたX.500の要素を特定する小委員会6。
Zeilenga & Legg Standards Track [Page 7] RFC 3672 Subentries in LDAP December 2003
Zeilenga&Legg規格は2003年12月にLDAPのRFC3672副次的記載を追跡します[7ページ]。
5.3. Protocol Mechanisms
5.3. プロトコルメカニズム
The IANA has registered the LDAP protocol mechanisms [RFC3383] detailed in this specification.
IANAはこの仕様で詳細なLDAPプロトコルメカニズム[RFC3383]を登録しました。
Subject: Request for LDAP Protocol Mechanism Registration
Subject: LDAPには、プロトコルメカニズム登録を要求してください。
Description: Subentries
記述: 副次的記載
Person & email address to contact for further information:
Kurt Zeilenga <kurt@openldap.org>
詳細のために連絡する人とEメールアドレス: カート Zeilenga <kurt@openldap.org 、gt。
Usage: Control
用法: コントロール
Specification: RFC3672
仕様: RFC3672
Author/Change Controller: IESG
コントローラを書くか、または変えてください: IESG
Comments: none
コメント: なし
6. Acknowledgment
6. 承認
This document is based on engineering done by IETF LDUP and LDAPext Working Groups including "LDAP Subentry Schema" by Ed Reed. This document also borrows from a number of ITU documents including X.501.
このドキュメントはエド・リードで「LDAP副次的記載図式」を含むIETF LDUPとLDAPext Working Groupsによって行われた工学に基づいています。 また、このドキュメントはX.501を含む多くのITUドキュメントから借ります。
7. Intellectual Property Statement
7. 知的所有権声明
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
Zeilenga & Legg Standards Track [Page 8] RFC 3672 Subentries in LDAP December 2003
Zeilenga&Legg規格は2003年12月にLDAPのRFC3672副次的記載を追跡します[8ページ]。
A. Subtree Specification ABNF
A。 下位木仕様ABNF
This appendix is non-normative.
この付録は非規範的です。
The LDAP-specific string encoding for the Subtree Specification syntax is specified by the Generic String Encoding Rules [RFC3641]. The ABNF [RFC2234] in this appendix for this syntax is provided only as a convenience and is equivalent to the encoding specified by the application of [RFC3641]. Since the SubtreeSpecification ASN.1 type may be extended in future editions of [X.501], the provided ABNF should be regarded as a snapshot in time. The LDAP-specific encoding for any extension to the SubtreeSpecification ASN.1 type can be determined from [RFC3641].
Subtree Specification構文のためのLDAP特有のストリングコード化はGeneric String Encoding Rules[RFC3641]によって指定されます。 この構文のためのこの付録のABNF[RFC2234]は単に便利として提供されて、[RFC3641]のアプリケーションで指定されたコード化に同等です。 SubtreeSpecification ASN.1タイプが将来版を重ねるにあたって[X.501]について広げられるかもしれないので、提供されたABNFは時間内に、スナップと見なされるべきです。 SubtreeSpecification ASN.1タイプへのどんな拡大のためのLDAP特有のコード化も[RFC3641]から決定できます。
In the event that there is a discrepancy between this ABNF and the encoding determined by [RFC3641], [RFC3641] is to be taken as definitive.
[RFC3641]で決定しているこのABNFとコード化の間には、食い違いがある場合、[RFC3641]は決定的であるとしてみなされることになっています。
SubtreeSpecification = "{" [ sp ss-base ]
[ sep sp ss-specificExclusions ]
[ sep sp ss-minimum ]
[ sep sp ss-maximum ]
[ sep sp ss-specificationFilter ]
sp "}"
SubtreeSpecificationは「「[sp ss-ベース][9月のsp ss-specificExclusions][9月のsp ss-最小限][9月のsp ss-最大][9月のsp ss-specificationFilter]sp」」と等しいです。
ss-base = id-base msp LocalName
ss-specificExclusions = id-specificExclusions msp
SpecificExclusions
ss-minimum = id-minimum msp BaseDistance
ss-maximum = id-maximum msp BaseDistance
ss-specificationFilter = id-specificationFilter msp Refinement
イドspecificExclusions msp SpecificExclusions ss最小限ss-ベース=イドベースmsp LocalName ss-specificExclusions==イド最小のmsp BaseDistance ss最大の=イド最大のmsp BaseDistance ss-specificationFilterはイド-specificationFilter msp Refinementと等しいです。
id-base = %x62.61.73.65 ; "base"
id-specificExclusions = %x73.70.65.63.69.66.69.63.45.78.63.6C.75.73
%x69.6F.6E.73 ; "specificExclusions"
id-minimum = %x6D.69.6E.69.6D.75.6D ; "minimum"
id-maximum = %x6D.61.78.69.6D.75.6D ; "maximum"
id-specificationFilter = %x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46
%x69.6C.74.65.72 ; "specificationFilter"
イドベース=%x62.61.73.65。 「ベース」イド-specificExclusions=%x73.70.65.63.69.66.69.63.45.78.63.6C.75.73%x69.6F.6E.73。 "specificExclusions"イド最小の=%x6D.69.6E.69.6D.75.6D。 「最小」のイド最大の=%x6D.61.78.69.6D.75.6D。 「最大」のイド-specificationFilter=%x73.70.65.63.69.66.69.63.61.74.69.6F.6E.46%x69.6C.74.65.72。 "specificationFilter"
SpecificExclusions = "{" [ sp SpecificExclusion
*( "," sp SpecificExclusion ) ] sp "}"
SpecificExclusion = chopBefore / chopAfter
chopBefore = id-chopBefore ":" LocalName
chopAfter = id-chopAfter ":" LocalName
id-chopBefore = %x63.68.6F.70.42.65.66.6F.72.65 ; "chopBefore"
id-chopAfter = %x63.68.6F.70.41.66.74.65.72 ; "chopAfter"
「SpecificExclusionsが等しい、「「[sp SpecificExclusion*、(「」 sp SpecificExclusion] sp」、」 SpecificExclusion=chopBefore / chopAfter chopBeforeがイド-chopBeforeと等しい、」、:、」 「LocalName chopAfterはイド-chopAfterと等しい」:、」 LocalNameイド-chopBefore=%x63.68.6F.70.42.65.66.6F.72.65。 "chopBefore"イド-chopAfter=%x63.68.6F.70.41.66.74.65.72。 "chopAfter"
Zeilenga & Legg Standards Track [Page 9] RFC 3672 Subentries in LDAP December 2003
Zeilenga&Legg規格は2003年12月にLDAPのRFC3672副次的記載を追跡します[9ページ]。
Refinement = item / and / or / not
item = id-item ":" OBJECT-IDENTIFIER
and = id-and ":" Refinements
or = id-or ":" Refinements
not = id-not ":" Refinement
Refinements = "{" [ sp Refinement
*( "," sp Refinement ) ] sp "}"
id-item = %x69.74.65.6D ; "item"
id-and = %x61.6E.64 ; "and"
id-or = %x6F.72 ; "or"
id-not = %x6E.6F.74 ; "not"
「気品は項目=イド品目ではなく、項目/と/か/と等しい」:、」 そして、「OBJECT-IDENTIFIERと=、イド、-、」、:、」 または、「気品か=、イド、-、」、:、」 「気品が等しくない、イド、-、」、:、」 気品Refinementsが等しい、「「[sp気品*、(「」、sp気品] sp、」、」 イド項目=%x69.74.65.6D。 そして、「項目」、イド、-、=%x61.6E.64。 または、"and"、イド、-、=%x6F.72。 "or"、イド、-、=%x6E.6F.74。 "not"
BaseDistance = INTEGER-0-MAX
BaseDistanceは整数0最大と等しいです。
The <sp>, <msp>, <sep>, <INTEGER>, <INTEGER-0-MAX>, <OBJECT- IDENTIFIER> and <LocalName> rules are defined in [RFC3642].
<sp>、<msp>、<sep>、<INTEGER>、<のINTEGER-0マックスの>、<OBJECT- IDENTIFIER>、および<LocalName>規則は[RFC3642]で定義されます。
Normative References
引用規格
[X.501] ITU-T, "The Directory -- Models," X.501, 1993.
[X.501]ITU-T、「ディレクトリ--モデル、」、X.501、1993
[X.680] ITU-T, "Abstract Syntax Notation One (ASN.1) -
Specification of Basic Notation", X.680, 1994.
[X.680]ITU-T、「構文記法1(ASN.1)を抜き取ってください--基本的な記法の仕様」、X.680、1994
[X.690] ITU-T, "Specification of ASN.1 encoding rules: Basic,
Canonical, and Distinguished Encoding Rules", X.690,
1994.
[X.690]ITU-T、「ASN.1コード化の仕様は統治します」。 「基本的で、正準で、顕著な符号化規則」、X.690、1994。
[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月。
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2251]ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
[RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
"Lightweight Directory Access Protocol (v3): Attribute
Syntax Definitions", RFC 2252, December 1997.
[RFC2252] ウォール、M.、Coulbeck、A.、ハウズ、T.、およびS.Kille、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「属性構文定義」、RFC2252、1997年12月。
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
"Authentication Methods for LDAP", RFC 2829, May 2000.
[RFC2829] ウォール、M.、Alvestrand、H.、ホッジズ、J.、およびR.モーガン(「LDAPのための認証方法」、RFC2829)は2000がそうするかもしれません。
[RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight
Directory Access Protocol (v3): Extension for Transport
Layer Security", RFC 2830, May 2000.
[RFC2830] ホッジズ、J.、モーガン、R.、およびM.ウォール、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「トランスポート層セキュリティのための拡大」(RFC2830)は2000がそうするかもしれません。
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access
Protocol (v3): Technical Specification", RFC 3377,
September 2002.
[RFC3377] ホッジズ、J.、およびR.モーガン、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「技術的な仕様」、RFC3377、2002年9月。
Zeilenga & Legg Standards Track [Page 10] RFC 3672 Subentries in LDAP December 2003
Zeilenga&Legg規格は2003年12月にLDAPのRFC3672副次的記載を追跡します[10ページ]。
[RFC3383] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
Considerations for the Lightweight Directory Access
Protocol (LDAP)", RFC 3383, September 2002.
[RFC3383] Zeilenga、K.、「ライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)のためのインターネット規定番号権威(IANA)問題」、RFC3383、2002年9月。
[RFC3641] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
Types", RFC 3641, October 2003.
[RFC3641]Legg、2003年10月のS.、「ASN.1タイプのための一般的なストリング符号化規則(GSER)」RFC3641。
Informative References
有益な参照
[RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[RFC2234] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[RFC3642] Legg, S., "Common Elements of Generic String Encoding
Rules (GSER) Encodings", RFC 3642, October 2003.
[RFC3642]Legg、S.、「一般的なストリング符号化規則(GSER)Encodingsの一般的なElements」、RFC3642、2003年10月。
[ASSIGN] OpenLDAP Foundation, "OpenLDAP OID Delegations",
http://www.openldap.org/foundation/oid-delegate.txt
[割り当てます] OpenLDAP財団、「OpenLDAP OID代表団」、 http://www.openldap.org/foundation/oid-delegate.txt
[PRIVATE] IANA, "Private Enterprise Numbers",
http://www.iana.org/assignments/enterprise-numbers
[個人的]のIANA、「私企業番号」、 http://www.iana.org/assignments/enterprise-numbers
Authors' Addresses
作者のアドレス
Kurt D. Zeilenga OpenLDAP Foundation
カートD.Zeilenga OpenLDAP財団
EMail: Kurt@OpenLDAP.org
メール: Kurt@OpenLDAP.org
Steven Legg Adacel Technologies Ltd. 250 Bay Street Brighton, Victoria 3186 AUSTRALIA
スティーブンLegg Adacel Technologies株式会社250のカナダ金融界のビクトリア・3186ブライトン(オーストラリア)
Phone: +61 3 8530 7710 Fax: +61 3 8530 7888 EMail: steven.legg@adacel.com.au
以下に電話をしてください。 +61 3 8530 7710、Fax: +61 3 8530 7888はメールされます: steven.legg@adacel.com.au
Zeilenga & Legg Standards Track [Page 11] RFC 3672 Subentries in LDAP December 2003
Zeilenga&Legg規格は2003年12月にLDAPのRFC3672副次的記載を追跡します[11ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Zeilenga & Legg Standards Track [Page 12]
Zeilenga&Legg標準化過程[12ページ]
一覧
スポンサーリンク
