[要約] RFC 4876は、LDAPベースのエージェントのための設定プロファイルスキーマに関するものであり、その目的は、エージェントの設定情報を効率的に管理するための標準化を提供することです。
Network Working Group B. Neal-Joslin, Ed.
Request for Comments: 4876 HP
Category: Informational L. Howard
PADL
M. Ansari
Infoblox
May 2007
A Configuration Profile Schema for Lightweight Directory Access Protocol (LDAP)-Based Agents
軽量ディレクトリアクセスプロトコル（LDAP）ベースのエージェントの構成プロファイルスキーマ
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
IESG Note
IESGノート
This RFC is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this RFC for any purpose and in particular notes that the decision to publish is not based on IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information.
このRFCは、インターネット標準のレベルの候補者ではありません。IETFは、あらゆる目的のためにこのRFCのフィットネスに関する知識を放棄します。特に、公開する決定は、セキュリティ、混雑制御、または展開プロトコルとの不適切な相互作用のIETFレビューに基づいていないことに注意しています。RFCエディターは、その裁量でこのドキュメントを公開することを選択しました。このドキュメントの読者は、実装と展開の価値を評価する際に注意する必要があります。詳細については、RFC 3932を参照してください。
Abstract
概要
This document consists of two primary components, a schema for agents that make use of the Lightweight Directory Access protocol (LDAP) and a proposed use case of that schema, for distributed configuration of similar directory user agents. A set of attribute types and an object class are proposed. In the proposed use case, directory user agents (DUAs) can use this schema to determine directory data location and access parameters for specific services they support. In addition, in the proposed use case, attribute and object class mapping allows DUAs to reconfigure their expected (default) schema to match that of the end user's environment. This document is intended to be a skeleton for future documents that describe configuration of specific DUA services.
このドキュメントは、2つの主要なコンポーネント、LightWeight Directory Access Protocol（LDAP）を使用するエージェントのスキーマと、同様のディレクトリユーザーエージェントの分散構成のためのそのスキーマの提案されたユースケースで構成されています。一連の属性タイプとオブジェクトクラスが提案されています。提案されたユースケースでは、ディレクトリユーザーエージェント（DUAS）がこのスキーマを使用して、サポートする特定のサービスのディレクトリデータの場所とアクセスパラメーターを決定できます。さらに、提案されているユースケースでは、属性およびオブジェクトクラスマッピングにより、DUAは予想される（デフォルト）スキーマを再構成して、エンドユーザーの環境と一致させることができます。このドキュメントは、特定のDUAサービスの構成を説明する将来のドキュメントのスケルトンになることを目的としています。
Table of Contents
目次
1. Background and Motivation . . . . . . . . . . . . . . . . . . 3
2. General Information . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
2.2. Attributes Summary . . . . . . . . . . . . . . . . . . . . 5
2.3. Object Classes Summary . . . . . . . . . . . . . . . . . . 5
2.4. Common Syntax/Encoding Definitions . . . . . . . . . . . . 5
3. Schema Definition . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Attribute Definitions . . . . . . . . . . . . . . . . . . 6
3.2. Class Definition . . . . . . . . . . . . . . . . . . . . . 9
4. DUA Implementation Details . . . . . . . . . . . . . . . . . . 10
4.1. Interpreting the preferredServerList Attribute . . . . . . 10
4.2. Interpreting the defaultServerList Attribute . . . . . . . 11
4.3. Interpreting the defaultSearchBase Attribute . . . . . . . 12
4.4. Interpreting the authenticationMethod Attribute . . . . . 13
4.5. Interpreting the credentialLevel Attribute . . . . . . . . 15
4.6. Interpreting the serviceSearchDescriptor Attribute . . . . 16
4.7. Interpreting the attributeMap Attribute . . . . . . . . . 20
4.8. Interpreting the searchTimeLimit Attribute . . . . . . . . 23
4.9. Interpreting the bindTimeLimit Attribute . . . . . . . . . 23
4.10. Interpreting the followReferrals Attribute . . . . . . . . 24
4.11. Interpreting the dereferenceAliases Attribute . . . . . . 24
4.12. Interpreting the profileTTL Attribute . . . . . . . . . . 24
4.13. Interpreting the objectclassMap Attribute . . . . . . . . 25
4.14. Interpreting the defaultSearchScope Attribute . . . . . . 27
4.15. Interpreting the serviceAuthenticationMethod Attribute . . 27
4.16. Interpreting the serviceCredentialLevel Attribute . . . . 28
5. Binding to the Directory Server . . . . . . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8.1. Registration of Object Classes . . . . . . . . . . . . . . 31
8.2. Registration of Attribute Types . . . . . . . . . . . . . 31
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.1. Normative References . . . . . . . . . . . . . . . . . . . 33
9.2. Informative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 35
LDAP [RFC4510] has brought about a nearly ubiquitous acceptance of the directory server. Many client applications (DUAs) are being created that use LDAP directories for many different services. And although the LDAP protocol has eased the development of these applications, some challenges still exist for both developers and directory administrators.
LDAP [RFC4510]は、ディレクトリサーバーをほぼ遍在する受け入れをもたらしました。多くの異なるサービスにLDAPディレクトリを使用する多くのクライアントアプリケーション（DUAS）が作成されています。また、LDAPプロトコルはこれらのアプリケーションの開発を緩和しましたが、開発者とディレクトリ管理者の両方に依然としていくつかの課題が存在します。
The authors of this document are implementers of DUAs described by [RFC2307]. In developing these agents, we felt there were several issues that still need to be addressed to ease the deployment and configuration of a large network of these DUAs.
この文書の著者は、[RFC2307]によって記述されたDUASの実装者です。これらのエージェントの開発において、これらのDUAの大規模なネットワークの展開と構成を容易にするために、まだ対処する必要があるいくつかの問題があると感じました。
One of these challenges stems from the lack of a utopian schema. A utopian schema would be one that every application developer could agree upon and that would support every application. Unfortunately today, many DUAs define their own schema, even when they provide similar services (like RFC 2307 vs. Microsoft's Services for Unix [MSSFU]). These schemas contain similar attributes, but use different attribute names. This can lead to data redundancy within directory entries and cause directory administrators unwanted challenges, updating schemas and synchronizing data. Or, in a more common case, two or more applications may agree on common schema elements, but choose a different schema for other elements of data that might also be shareable between the applications. While data synchronization and translation tools exist, the authors of this document believe there is value in providing this capability in the directory user agent itself.
これらの課題の1つは、ユートピアスキーマの欠如に起因しています。ユートピアスキーマは、すべてのアプリケーション開発者が同意できるものであり、すべてのアプリケーションをサポートします。残念ながら、今日、多くのDUAは、同様のサービスを提供している場合でも、独自のスキーマを定義しています（RFC 2307とMicrosoftのUNIX [MSSFU]サービスなど）。これらのスキーマには同様の属性が含まれていますが、異なる属性名を使用します。これにより、ディレクトリエントリ内のデータ冗長性につながり、ディレクトリ管理者が望ましくない課題を引き起こし、スキーマの更新と同期データを引き起こします。または、より一般的なケースでは、2つ以上のアプリケーションが一般的なスキーマ要素に同意する場合がありますが、アプリケーション間で共有可能なデータの他の要素に対して別のスキーマを選択します。データの同期と翻訳ツールは存在しますが、このドキュメントの著者は、ディレクトリユーザーエージェント自体にこの機能を提供することには価値があると考えています。
Aside from proposing a schema for general use, one goal of this document is to eliminate data redundancy by having DUAs configure themselves to the schema of the deployed directory, instead of forcing the DUA's own schema on the directory.
一般的な使用のスキーマを提案することとは別に、このドキュメントの1つの目標は、DUA自身のスキーマをディレクトリに強制する代わりに、DUASを展開ディレクトリのスキーマに設定することにより、データ冗長性を排除することです。
Another goal of this document is to provide the DUA with enough configuration information so that it can discover how to retrieve its data in the directory, such as what locations to search in the directory tree.
このドキュメントのもう1つの目標は、DUAに十分な構成情報を提供して、ディレクトリツリーで検索する場所など、ディレクトリ内のデータを取得する方法を発見できるようにすることです。
Finally, this document intends to describe a configuration method for DUAs that can be shared among many DUAs on various platforms, providing, as such, a configuration profile. The purpose of this profile is to centralize and simplify management of DUAs.
最後に、このドキュメントは、さまざまなプラットフォーム上の多くのDUA間で共有できるDUAの構成方法を記述する予定であり、そのように構成プロファイルを提供します。このプロファイルの目的は、DUAの管理を一元化して簡素化することです。
This document is intended to provide the skeleton framework for future documents that will describe the individual implementation details for the particular services provided by that DUA. The authors of this document plan to develop such a document for the Network Information Service DUA, described by RFC 2307 or its successor.
このドキュメントは、そのDUAが提供する特定のサービスの個々の実装の詳細を説明する将来のドキュメントのスケルトンフレームワークを提供することを目的としています。このドキュメントの著者は、RFC 2307またはその後継者によって記述されたネットワーク情報サービスDUAのこのようなドキュメントを開発する計画です。
We expect that as DUAs take advantage of this configuration scheme, each DUA will require additional configuration parameters, not specified by this document. Thus, we would expect that new auxiliary object classes that contain new configuration attributes will be created and then joined with the structural class defined by this document to create a configuration profile for a particular DUA service. By joining various auxiliary object classes for different DUA services, the configuration of various DUA services can be controlled by a single configuration profile entry.
DUAがこの構成スキームを利用するにつれて、各DUAにはこのドキュメントで指定されていない追加の構成パラメーターが必要になると予想されます。したがって、新しい構成属性を含む新しい補助オブジェクトクラスが作成され、このドキュメントで定義された構造クラスと結合して、特定のDUAサービスの構成プロファイルを作成することが期待されます。さまざまなDUAサービスのさまざまな補助オブジェクトクラスを結合することにより、さまざまなDUAサービスの構成を単一の構成プロファイルエントリによって制御できます。
The schema defined by this document is defined under the "DUA Configuration Schema". This schema is derived from the object identifier (OID): iso (1) org (3) dod (6) internet (1) private (4) enterprises (1) Hewlett-Packard Company (11) directory (1) LDAP-UX Integration Project (3) DUA Configuration Schema (1). This OID is represented in this document by the keystring "DUAConfSchemaOID" (1.3.6.1.4.1.11.1.3.1).
このドキュメントで定義されたスキーマは、「DUA構成スキーマ」で定義されています。このスキーマは、オブジェクト識別子（OID）から派生しています：ISO（1）org（3）dod（6）インターネット（1）プライベート（4）エンタープライズ（1）Hewlett-Packard Company（11）Directory（1）ldap-ux統合プロジェクト（3）DUA構成スキーマ（1）。このoidは、キーストリング「Duaconfschemaoid」（1.3.6.1.4.1.11.1.1.1.1.1.3.1）によってこのドキュメントで表されています。
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 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The following attributes are defined in this document:
このドキュメントでは、次の属性が定義されています。
preferredServerList defaultServerList defaultSearchBase defaultSearchScope authenticationMethod credentialLevel serviceSearchDescriptor serviceCredentialLevel serviceAuthenticationMethod attributeMap objectclassMap searchTimeLimit bindTimeLimit followReferrals dereferenceAliases profileTTL
優先順序ゼルバーリストdefaultsearchbase defaultsearchscope authenticationmethod credentienterlevel servicesedescriptor servicedentiallevel serviceauthenticationmethod astributemap objectclassmap searchtimelimit bindtimelimit efferreferrals dereferencealise
The following object class is defined in this document:
次のオブジェクトクラスは、このドキュメントで定義されています。
DUAConfigProfile
duaconfigprofile
The proposed string encodings used by the attributes defined in this document can be found in Section 4. This document makes use of ABNF [RFC4234] for defining new encodings.
このドキュメントで定義されている属性で使用される提案された文字列エンコーディングは、セクション4に記載されています。このドキュメントでは、新しいエンコーディングを定義するためにABNF [RFC4234]を使用しています。
The following syntax definitions are used throughout this document.
次の構文定義は、このドキュメント全体で使用されています。
The list of used syntaxes are:
使用される構文のリストは次のとおりです。
+---------------------------+---------------------------------------+
| Key | Source |
+---------------------------+---------------------------------------+
| keystring | as defined by [RFC4512] Section 1.4 |
| descr | as defined by [RFC4512] Section 1.4 |
| SP | as defined by [RFC4512] Section 1.4 |
| WSP | as defined by [RFC4512] Section 1.4 |
| base | as defined by distinguishedName in |
| | [RFC4514] |
| distinguishedName | as defined by [RFC4514] Section 2 |
| relativeDistinguishedName | as defined by [RFC4514] Section 2 |
| scope | as defined by [RFC4516] Section 2 |
| host | as defined by [RFC3986] Section 3.2.2 |
| hostport | host [":" port ] |
| port | as defined by [RFC3986] Section 3.2.3 |
| serviceID | same as keystring |
+---------------------------+---------------------------------------+
This document does not define new syntaxes that must be supported by the directory server. Instead, these syntaxes are merely expected to be interpreted by the DUA. As referenced in the schema definition in Section 3, most encodings are expected to be stored in attributes using common syntaxes, such as the Directory String syntax, as defined in Section 3.3.6 of [RFC4517]. Refer to RFC 4517 for additional syntaxes used by this schema.
このドキュメントは、ディレクトリサーバーによってサポートされている必要がある新しい構文を定義しません。代わりに、これらの構文は単にDUAによって解釈されることが期待されています。セクション3のスキーマ定義で参照されているように、ほとんどのエンコーディングは、[RFC4517]のセクション3.3.6で定義されているように、ディレクトリ文字列構文などの一般的な構文を使用して属性に保存されると予想されます。このスキーマで使用される追加の構文については、RFC 4517を参照してください。
This section defines a proposed schema. This schema does not require definition of new matching rules or syntaxes, and it may be used for any purpose seen. A proposed use of this schema to support elements of configuration of a directory user agent is described in Section 4.
このセクションでは、提案されたスキーマを定義します。このスキーマでは、新しいマッチングルールや構文の定義は必要ありません。また、見られる目的に使用される場合があります。ディレクトリユーザーエージェントの構成要素をサポートするためにこのスキーマを提案した使用については、セクション4で説明します。
This section contains attribute definitions used by agents. The syntax used to describe these attributes is defined in [RFC4512], Section 4.1.2. Individual syntaxes and matching rules used within these descriptions are described in [RFC4517], Sections 3.3 and 4.2, respectively.
このセクションには、エージェントが使用する属性定義が含まれています。これらの属性を記述するために使用される構文は、[RFC4512]、セクション4.1.2で定義されています。これらの説明内で使用される個々の構文と一致するルールは、それぞれ[RFC4517]、セクション3.3および4.2で説明されています。
( 1.3.6.1.4.1.11.1.3.1.1.0 NAME 'defaultServerList' DESC 'List of default servers' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（1.3.6.1.4.1.11.11.1.1.1.0名「DefaultServerlist」DESC '' Default Servers 'equality Caseignorematch Subtringsubstringsmatch Syntax 1.3.6.1.4.1.1466.115.121.1.15単一値））
( 1.3.6.1.4.1.11.1.3.1.1.1 NAME 'defaultSearchBase' DESC 'Default base for searches' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.1.1.1.1.1 'name' defaultsearchbase 'desc'検索のデフォルトベース 'equality distinguednamematch Syntax 1.3.6.1.4.1.1466.115.121.1.1.12単価）
( 1.3.6.1.4.1.11.1.3.1.1.2 NAME 'preferredServerList' DESC 'List of preferred servers' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.1.1.1.1.2名「優先サーバー」のリスト '優先サーバーのリスト' caseignorematch substringsubstringsmatch Syntax 1.3.6.1.1.1466.115.121.1.15単一値））
( 1.3.6.1.4.1.11.1.3.1.1.3 NAME 'searchTimeLimit' DESC 'Maximum time an agent or service allows for a search to complete' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.1.1.1.1.1.3名 'SearchTimelimit' DESC '最大時間エージェントまたはサービスにより、検索が完了することができます。））
( 1.3.6.1.4.1.11.1.3.1.1.4 NAME 'bindTimeLimit' DESC 'Maximum time an agent or service allows for a bind operation to complete' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.1.1.1.1.1.4名 'bindtimelimit' desc '最大時間エージェントまたはサービスにより、バインド操作がequality integerorderingmatch Syntaxを完了することができます。価値 ）
( 1.3.6.1.4.1.11.1.3.1.1.5 NAME 'followReferrals' DESC 'An agent or service does or should follow referrals' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.1.1.1.1.1.5名「FollowReferrals」desc 'エージェントまたはサービスは、紹介またはサービスに従うべきです。
( 1.3.6.1.4.1.11.1.3.1.1.6 NAME 'authenticationMethod' DESC 'Identifies the types of authentication methods either used, required, or provided by a service or peer' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.1.1.1.1.6名「AuthenticationMethod 'DESC」は、使用、必要、または提供されたCaseignoreMatch Substringsubstrings Syntax 1.3.6.1.1.4.1.146666.115で使用される、必要、または提供される認証方法のタイプを識別します。121.1.15単一価値）
( 1.3.6.1.4.1.11.1.3.1.1.7 NAME 'profileTTL' DESC 'Time to live, in seconds, before a profile is considered stale' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.1.3.1.1.7名 'Profiletll' Desc '' '時間、数秒で、プロファイルが古く見なされる前に、integerorder-ingmatch Syntax 1.3.6.4.1.1466.115.121.1.27単一 - 価値 ）
( 1.3.6.1.4.1.11.1.3.1.1.9 NAME 'attributeMap' DESC 'Attribute mappings used, required, or supported by an agent or service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（1.3.6.1.4.1.11.1.1.1.1.1.9名 'AttributeMap' desc '属性マッピングは、エージェントまたはサービスによって使用、必要、またはサポートされています。
( 1.3.6.1.4.1.11.1.3.1.1.10 NAME 'credentialLevel' DESC 'Identifies type of credentials either used, required, or supported by an agent or service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.1.1.1.10名「資格情報レベル」DESC 'は、エージェントまたはサービスによって使用、必要、またはサポートされている資格情報のタイプを識別します。-価値 ）
( 1.3.6.1.4.1.11.1.3.1.1.11 NAME 'objectclassMap' DESC 'Object class mappings used, required, or supported by an agent or service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（1.3.6.1.4.1.11.1.1.1.1.1111111111111111111111.NAME 'objectClassMap' DESC 'オブジェクトクラスマッピングは、エージェントまたはサービスによって使用、必要、またはサポートされています。
( 1.3.6.1.4.1.11.1.3.1.1.12 NAME 'defaultSearchScope' DESC 'Default scope used when performing a search' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.1.1.1.1.12 name 'defaultsearchscope' desc 'equality caseignoreia5match構文を実行するときに使用されるデフォルトスコープ
( 1.3.6.1.4.1.11.1.3.1.1.13 NAME 'serviceCredentialLevel' DESC 'Specifies the type of credentials either used, required, or supported by a specific service' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（1.3.6.1.4.1.11.1.1.1.1.1.13名 'ServicecredentialLevel' DESC ''特定のサービス「Caseignoreia5Match Syntax 1.3.6.1.4.1.1.1466.115.12121.121.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.1.
( 1.3.6.1.4.1.11.1.3.1.1.14 NAME 'serviceSearchDescriptor' DESC 'Specifies search descriptors required, used, or supported by a particular service or agent' EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
（1.3.6.1.4.1.11.1.1.1.1.1.14名 'ServicesearchDescriptor' DESC ''特定のサービスまたはエージェントが必要、使用、またはサポートする検索記述子を指定します。））
( 1.3.6.1.4.1.11.1.3.1.1.15 NAME 'serviceAuthenticationMethod' DESC 'Specifies types authentication methods either used, required, or supported by a particular service' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
（1.3.6.1.4.1.11.1.1.3.1.1.15 Name 'ServiceAuthenticationMethod' DESC 'は、特定のサービスで使用、必須、またはサポートされているタイプの認証方法を指定します。））
( 1.3.6.1.4.1.11.1.3.1.1.16 NAME 'dereferenceAliases' DESC 'Specifies if a service or agent either requires, supports, or uses dereferencing of aliases.' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
（1.3.6.1.4.1.11.1.1.1.1.1.16名「Dereferencealiase 'DESC'サービスまたはエージェントがエイリアスの宣言を要求、サポート、または使用するかどうかを指定します。単一価値）
The object class below is constructed from the attributes defined in Section 3.1, with the exception of the "cn" attribute, which is defined in [RFC4519]. "cn" is used to represent the name of the DUA configuration profile and is recommended for the relative distinguished name (RDN) [RFC4514] naming attribute. This object class is used specifically by the DUA described in Section 4. The syntax used to describe this object class is defined in [RFC4512], Section 4.1.1.
以下のオブジェクトクラスは、[RFC4519]で定義されている「CN」属性を除き、セクション3.1で定義された属性から構築されています。「CN」は、DUA構成プロファイルの名前を表すために使用され、相対識別名（RDN）[RFC4514]ネーミング属性に推奨されます。このオブジェクトクラスは、セクション4で説明されているDUAによって特異的に使用されます。このオブジェクトクラスを説明するために使用される構文は、[RFC4512]、セクション4.1.1で定義されています。
( 1.3.6.1.4.1.11.1.3.1.2.5 NAME 'DUAConfigProfile' SUP top STRUCTURAL DESC 'Abstraction of a base configuration for a DUA' MUST ( cn ) MAY ( defaultServerList $ preferredServerList $ defaultSearchBase $ defaultSearchScope $ searchTimeLimit $ bindTimeLimit $ credentialLevel $ authenticationMethod $ followReferrals $ dereferenceAliases $ serviceSearchDescriptor $ serviceCredentialLevel $ serviceAuthenticationMethod $ objectclassMap $ attributeMap $ profileTTL ) )
（1.3.6.1.4.1.11.1.1.3.1.2.5名 'Duaconfigprofile' Sup Top Structural Desc 'DUAのベース構成の抽出'マスト（CN）5月（DefaultServerlist $ PreferredServerlist $ DefaultSearchBase $ DefaultSearchBase $ Search $ Bindtimelimit $ credentienterive $ creadentienterimit $ bindtimelimit $ bindtimelimitAuthenticationMethod $ followReferrals $ dereferencealiase $ servicesearchdescriptor $ servicecredentiallevel $ serviceauthenticationmethod $ objectclassmap $ astributemap $ profiletll）））））
This section describes an implementation of the schema described in Section 3. Details about how a DUA should format and interpret the defined attributes are described below. Agents that make use of the DUAConfigProfile object class are expected to follow the specifications in this section.
このセクションでは、セクション3で説明したスキーマの実装について説明します。DUAが定義された属性をフォーマットおよび解釈する方法の詳細については、以下に説明します。DuaconFigProfileオブジェクトクラスを使用するエージェントは、このセクションの仕様に従うことが期待されています。
Note: Many of the subsections below contain examples. Unless otherwise specified, these examples are rendered using the LDAP Data Interchange Format (LDIF) [RFC2849].
注：以下のサブセクションの多くには、例が含まれています。特に指定されていない限り、これらの例は、LDAPデータインターチェンジ形式（LDIF）[RFC2849]を使用してレンダリングされます。
Interpretation:
解釈：
As described by the syntax, the preferredServerList parameter is a whitespace-separated list of server addresses and associated port numbers. When the DUA needs to contact a directory server agent (DSA), the DUA MUST first attempt to contact one of the servers listed in the preferredServerList attribute. The DUA MUST contact the DSA specified by the first server address in the list. If that DSA is unavailable, the remaining DSAs MUST be queried in the order provided (left to right) until a connection is established with a DSA. Once a connection with a DSA is established, the DUA SHOULD NOT attempt to establish a connection with the remaining DSAs. The purpose of enumerating multiple DSAs is not for supplemental data, but for high availability of replicated data. This is also the main reason why an LDAP URL [RFC3986] syntax was not selected for this document.
構文で説明されているように、PreferredServerListパラメーターは、サーバーアドレスと関連するポート番号の白文学的なリストのリストです。DUAがディレクトリサーバーエージェント（DSA）に連絡する必要がある場合、DUAは最初にPreferredServerList属性にリストされているサーバーの1つに連絡しようとする必要があります。DUAは、リスト内の最初のサーバーアドレスで指定されたDSAに連絡する必要があります。そのDSAが利用できない場合、DSAで接続が確立されるまで、残りのDSAを提供された順序（左から右）に照会する必要があります。DSAとの接続が確立されると、DUAは残りのDSAとの接続を確立しようとしてはなりません。複数のDSAを列挙する目的は、補足データのためではなく、複製されたデータの高可用性です。これが、このドキュメントでLDAP URL [RFC3986]構文が選択されなかった主な理由でもあります。
If the DUA is unable to contact any of the DSAs specified by the preferredServerList, the defaultServerList attribute MUST be examined, as described in Section 4.2. The servers identified by the preferredServerList MUST be contacted before attempting to contact any of the servers specified by the defaultServerList.
DUAがPreferredServerlistによって指定されたDSAのいずれかに接触できない場合、セクション4.2で説明されているように、DefaultServerList属性を調べる必要があります。defaultserverlistで指定されたサーバーのいずれかに連絡しようとする前に、優先順位で識別されたサーバーに連絡する必要があります。
Syntax:
構文：
serverList = hostport *(SP [hostport])
serverlist = hostport *（sp [hostport]）
Default Value:
デフォルト値：
The preferredServerList attribute does not have a default value. Instead a DUA MUST examine the defaultServerList attribute.
PreferredServerList属性にはデフォルト値がありません。代わりに、DUAはdefaultServerList属性を調べる必要があります。
Other attribute notes:
その他の属性メモ：
This attribute is used in conjunction with the defaultServerList attribute. Please see Section 4.2 for additional implementation notes. Determining how the DUA should query the DSAs also depends on the additional configuration attributes, credentialLevel, serviceCredentialLevel, bindTimeLimit, serviceAuthenticationMethod, and authenticationMethod. Please review Section 5 for details on how a DUA should properly bind to a DSA.
この属性は、defaultServerList属性と組み合わせて使用されます。追加の実装ノートについては、セクション4.2を参照してください。DUAがDSASを照会する方法を決定することは、追加の構成属性、SredentialLevel、ServicecredentialLevel、Bindtimelimit、ServiceouthenticationMethod、およびAuthenticationMethodにも依存します。DUAがDSAに適切にバインドする方法の詳細については、セクション5をご覧ください。
Example:
例：
preferredServerList: 192.168.169.170 ldap1.mycorp.com
ldap2:1389 [1080::8:800:200C:417A]:389
Interpretation:
解釈：
The defaultServerList attribute MUST only be examined if the preferredServerList attribute is not provided, or the DUA is unable to establish a connection with any of the DSAs specified by the preferredServerList.
DefaultServerList属性は、優先順位の属性が提供されていない場合のみ、またはDUAが優先順位で指定されたDSAのいずれかとの接続を確立できない場合にのみ検査する必要があります。
If more than one address is provided, the DUA may choose either to accept the order provided or to create its own order, based on what the DUA determines is the "best" order of DSAs to query. For example, the DUA may choose to examine the server list and to query the DSAs in order based on the "closest" server or the server with the least amount of "load". Interpretation of the "best" server order is entirely up to the DUA, and not part of this document.
複数の住所が提供されている場合、DUAは、DUAが決定するものに基づいて、提供された注文を受け入れるか、独自の注文を作成するかを選択することができます。たとえば、DUAは、サーバーリストを調べ、「最も近い」サーバーまたは「ロード」の量が少ないサーバーに基づいてDSAを照会することを選択できます。「最良の」サーバーの注文の解釈は、完全にDUA次第であり、このドキュメントの一部ではありません。
Once the order of server addresses is determined, the DUA contacts the DSA specified by the first server address in the list. If that DSA is unavailable, the remaining DSAs SHOULD be queried until an available DSA is found, or no more DSAs are available. If a server address or port is invalid, the DUA SHOULD proceed to the next server address as described just above.
サーバーアドレスの順序が決定されると、DUAはリスト内の最初のサーバーアドレスで指定されたDSAに連絡します。そのDSAが利用できない場合、利用可能なDSAが見つかるまで残りのDSAを照会する必要があります。サーバーアドレスまたはポートが無効である場合、DUAは上記のように次のサーバーアドレスに進む必要があります。
Syntax:
構文：
serverList = hostport *(SP [hostport])
serverlist = hostport *（sp [hostport]）
Default Value:
デフォルト値：
If a defaultServerList attribute is not provided, the DUA MAY attempt to contact the same DSA that provided the configuration profile entry itself. The default DSA is contacted only if the preferredServerList attribute is also not provided.
DefaultServerList属性が提供されていない場合、DUAは、構成プロファイルエントリ自体を提供する同じDSAに接触しようとする場合があります。デフォルトのDSAは、PreferredServerList属性も提供されていない場合にのみ連絡されます。
Other attribute notes:
その他の属性メモ：
This attribute is used in conjunction with the preferredServerList attribute. Please see Section 4.1 for additional implementation notes. Determining how the DUA should query the DSAs also depends on the additional configuration attributes, credentialLevel, serviceCredentialLevel, bindTimeLimit, serviceAuthenticationMethod, and authenticationMethod. Please review Section 5 for details on how a DUA should properly contact a DSA.
この属性は、PreferredServerList属性と組み合わせて使用されます。追加の実装ノートについては、セクション4.1を参照してください。DUAがDSASを照会する方法を決定することは、追加の構成属性、SredentialLevel、ServicecredentialLevel、Bindtimelimit、ServiceouthenticationMethod、およびAuthenticationMethodにも依存します。DUAがDSAに適切に連絡する方法の詳細については、セクション5をご覧ください。
Example:
例：
defaultServerList: 192.168.169.170 ldap1.mycorp.com
ldap2:1389 [1080::8:800:200C:417A]:5912
Interpretation:
解釈：
When a DUA needs to search the DSA for information, this attribute provides the base for the search. This parameter can be overridden or appended by the serviceSearchDescriptor attribute. See Section 4.6.
DUAが情報をDSAに検索する必要がある場合、この属性は検索のベースを提供します。このパラメーターは、ServicesearchDescriptor属性によってオーバーライドまたは追加される可能性があります。セクション4.6を参照してください。
Syntax:
構文：
Defined by OID 1.3.6.1.4.1.1466.115.121.1.12 [RFC4517].
OID 1.3.6.1.4.1.146.115.121.1.12 [RFC4517]によって定義されています。
Default Value:
デフォルト値：
There is no default value for the defaultSearchBase. A DUA MAY define its own method for determining the search base, if the defaultSearchBase is not provided.
DefaultSearchBaseにデフォルト値はありません。DUAは、DefaultSearchBaseが提供されていない場合、検索ベースを決定する独自の方法を定義する場合があります。
Other attribute notes:
その他の属性メモ：
This attribute is used in conjunction with the serviceSearchDescriptor attribute. See Section 4.6.
この属性は、ServicesearchDescriptor属性と組み合わせて使用されます。セクション4.6を参照してください。
Example:
例：
defaultSearchBase: dc=mycompany,dc=com
Interpretation:
解釈：
The authenticationMethod attribute defines an ordered list of LDAP bind methods to be used when attempting to contact a DSA. The serviceAuthenticationMethod overrides this value for a particular service (see Section 4.15). Each method MUST be attempted in the order provided by the attribute, until a successful LDAP bind is performed ("none" is assumed to always be successful). However, the DUA MAY skip over one or more methods. See Section 5 for more information.
AuthenticationMethod属性は、DSAに連絡しようとするときに使用するLDAPバインドメソッドの順序付けられたリストを定義します。ServiceOuthenticationMethodは、特定のサービスのこの値を上書きします（セクション4.15を参照）。成功したLDAPバインドが実行されるまで、各メソッドは、属性によって提供される順序で試みる必要があります（「なし」は常に成功すると想定されます）。ただし、DUAは1つ以上の方法をスキップする場合があります。詳細については、セクション5を参照してください。
none - The DUA does not perform an LDAP bind.
なし - DUAはLDAPバインドを実行しません。
simple - The DUA performs an LDAP simple bind.
シンプル-DUAはLDAPのシンプルなバインドを実行します。
sasl - The DUA performs an LDAP Simple Authentication and Security Layer (SASL) [RFC4422] bind using the specified SASL mechanism and options.
SASL -DUAは、指定されたSASLメカニズムとオプションを使用して、LDAP Simple認証およびセキュリティレイヤー（SASL）[RFC4422]を実行します。
tls - The DUA performs an LDAP StartTLS operation followed by the specified bind method (for more information refer to Section 4.14 of [RFC4511]).
TLS -DUAはLDAP startTLS操作を実行し、その後指定されたバインド法を実行します（詳細については、[RFC4511]のセクション4.14を参照）。
Syntax:
構文：
authMethod = method *(";" method)
method = none / simple / sasl / tls
none = "none"
simple = "simple"
sasl = "sasl/" saslmech [ ":" sasloption ]
sasl = "sasl/" saslmech ["：" sasloption]
sasloption = "auth-conf" / "auth-int"
tls = "tls:" (none / simple / sasl)
saslmech = SASL mechanism name as defined in [SASLMECH]
saslmech = [saslmech]で定義されているSASLメカニズム名
Note: Although multiple authentication methods may be specified in the syntax, at most one of each type is allowed. That is, "simple;simple" is invalid.
注：複数の認証メソッドは構文で指定されている場合がありますが、各タイプのせいぜい1つが許可されています。つまり、「シンプル」は無効です。
Default Value:
デフォルト値：
If the authenticationMethod or serviceAuthenticationMethod (for that particular service) attributes are not provided, the DUA MAY choose to bind to the DSA using any method defined by the DUA. However, if either authenticationMethod or serviceAuthenticationMethod is provided, the DUA MUST only use the methods specified.
AuthenticationMethodまたはServiceAuthenticationMethod（その特定のサービスに対して）属性が提供されていない場合、DUAはDUAで定義された方法を使用してDSAにバインドすることを選択できます。ただし、authenticationmethodまたはserviceAuthenticationMethodのいずれかが提供されている場合、DUAは指定されたメソッドのみを使用する必要があります。
Other attribute notes:
その他の属性メモ：
When using TLS, the string "tls:sasl/EXTERNAL" implies that both client and server (DSA and DUA) authentications are to be performed. Any other TLS authentication method implies server-only (DSA side credential) authentication, along with the other SASL method used for DUA-side authentication.
TLSを使用する場合、文字列「TLS：SASL/外部」は、クライアントとサーバー（DSAとDUA）の両方の認証が実行されることを意味します。他のTLS認証方法は、DUA側認証に使用される他のSASLメソッドとともに、サーバーのみの（DSA側の資格情報）認証を意味します。
Determining how the DUA should bind to the DSAs also depends on the additional configuration attributes, credentialLevel, serviceCredentialLevel, serviceAuthenticationMethod, and bindTimeLimit. Please review Section 5 for details on how to properly bind to a DSA.
DUAがDSASにどのように結合するかを判断することは、追加の構成属性、SredentialLevel、ServiceCredentialLevel、ServiceAuthenticationMethod、およびBindtimelimitにも依存します。DSAに適切にバインドする方法の詳細については、セクション5をご覧ください。
Example:
例：
authenticationMethod: tls:simple;sasl/DIGEST-MD5
(see [RFC2831])
（[RFC2831]を参照）
Interpretation:
解釈：
The credentialLevel attribute defines what type(s) of credential(s) the DUA MUST use when contacting the DSA. The serviceCredentialLevel overrides this value for a particular service (Section 4.16). The credentialLevel can contain more than one credential type, separated by whitespace.
資格のLevel属性は、DSAに連絡するときにDUAが使用する必要がある資格情報のタイプを定義します。ServeCredentialLevelは、特定のサービスのこの値をオーバーライドします（セクション4.16）。資格のLevelには、Whitespaceで区切られた複数の資格型タイプを含めることができます。
anonymous The DUA SHOULD NOT use a credential when binding to the DSA.
匿名DUAは、DSAに拘束するときに資格情報を使用しないでください。
proxy The DUA SHOULD use a known proxy identity when binding to the DSA. A proxy identity is a specific credential that was created to represent the DUA. This document does not define how the proxy user should be created, or how the DUA should determine what the proxy user's credential is. This functionality is up to each implementation.
プロキシDUAは、DSAにバインディングするときに既知のプロキシIDを使用する必要があります。プロキシIDは、DUAを表すために作成された特定の資格情報です。このドキュメントでは、プロキシユーザーの作成方法、またはDUAがプロキシユーザーの資格情報が何であるかを決定する方法を定義しません。この機能は、各実装次第です。
self When the DUA is acting on behalf of a known identity, the DUA MUST attempt to bind to the DSA as that identity. The DUA should contain methods to determine the identity of the user such that the identity can be authenticated by the directory server using the defined authentication methods.
自己DUAが既知のアイデンティティに代わって行動しているとき、DUAはそのアイデンティティとしてDSAに結合しようとしなければなりません。DUAには、定義された認証方法を使用してディレクトリサーバーによってIDを認証できるように、ユーザーのIDを決定する方法を含める必要があります。
If the credentialLevel contains more than one credential type, the DUA MUST use the credential types in the order specified. However, the DUA MAY skip over one or more credential types. As soon as the DUA is able to successfully bind to the DSA, the DUA SHOULD NOT attempt to bind using the remaining credential types.
資格のあるLevelに複数の資格情報タイプが含まれている場合、DUAは指定された順序で資格情報型を使用する必要があります。ただし、DUAは1つ以上の資格情報をスキップする場合があります。DUAがDSAにうまくバインドできるようになるとすぐに、DUAは残りの資格情報タイプを使用してバインドしようとしないはずです。
Syntax:
構文：
credentialLevel = level *(SP level)
credentienceLevel = level *（SPレベル）
level = self / proxy / anonymous
self = "self"
proxy = "proxy"
anonymous = "anonymous"
Note: Although multiple credential levels may be specified in the syntax, at most one of each type is allowed. Refer to implementation notes in Section 5 for additional syntax requirements for the credentialLevel attribute.
注：構文では複数の資格情報レベルが指定される場合がありますが、各タイプの最大1つが許可されています。資格のLevel属性の追加の構文要件については、セクション5の実装ノートを参照してください。
Default Value:
デフォルト値：
If the credentialLevel attribute is not defined, the DUA SHOULD NOT use a credential when binding to the DSA (also known as anonymous).
資格情報の属性が定義されていない場合、DUAはDSA（匿名とも呼ばれる）にバインディングするときに資格情報を使用しないでください。
Other attribute notes:
その他の属性メモ：
Determining how the DUA should bind to the DSAs also depends on the additional configuration attributes, authenticationMethod, serviceAuthenticationMethod, serviceCredentialLevel, and bindTimeLimit. Please review Section 5 for details on how to properly bind to a DSA.
DUAがDSASにどのように結合するかを判断することは、追加の構成属性、AuthenticationMethod、ServiceAuthenticationMethod、ServicredentialLevel、およびBindtimelimitにも依存します。DSAに適切にバインドする方法の詳細については、セクション5をご覧ください。
Example:
例：
credentialLevel: proxy anonymous
資格情報レベル：匿名のプロキシ
Interpretation:
解釈：
The serviceSearchDescriptor attribute defines how and where a DUA SHOULD search for information for a particular service. The serviceSearchDescriptor contains a serviceID, followed by one or more base-scope-filter triples. These base-scope-filter triples are used to define searches only for the specific service. Multiple base-scope-filters allow the DUA to search for data in multiple locations in the directory information tree (DIT). Although this syntax is very similar to the LDAP URL [RFC3986], this document requires the ability to supply multiple hosts as part of the configuration of the DSA. In addition, an ordered list of search descriptors is required, which cannot be specified by the LDAP URL.
ServicesearchDescriptor属性は、DUAが特定のサービスの情報を検索する方法と場所を定義します。ServicesearchDescriptorにはServiceIDが含まれており、その後に1つ以上のベーススコープフィルタートリプルが続きます。これらのベーススコープフィルタートリプルは、特定のサービスのみの検索のみを定義するために使用されます。複数のベーススコープフィルターにより、DUAはディレクトリ情報ツリー（DIT）の複数の場所でデータを検索できます。この構文はLDAP URL [RFC3986]に非常に似ていますが、このドキュメントでは、DSAの構成の一部として複数のホストを提供する機能が必要です。さらに、検索記述子の順序付けられたリストが必要です。これはLDAP URLでは指定できません。
The serviceSearchDescriptor might also contain the DN of an entry that will contain an alternate profile. The DSA SHOULD re-evaluate the alternate profile and perform searches as specified by that profile.
ServicesearchDescriptorには、代替プロファイルを含むエントリのDNも含まれている場合があります。DSAは、代替プロファイルを再評価し、そのプロファイルで指定された検索を実行する必要があります。
If the base, as defined in the serviceSearchDescriptor, is followed by the "," (ASCII 0x2C) character, this base is known as a relative base. This relative base may be constructed of one or more RDN components. In this case, the DUA MUST define the search base by appending the relative base with the defaultSearchBase.
ServicesearchDescriptorで定義されているように、ベースに「、」（ASCII 0x2C）文字が続く場合、このベースは相対的なベースとして知られています。この相対ベースは、1つ以上のRDNコンポーネントで構成できます。この場合、DUAは、DefaultSearchBaseを使用して相対ベースを追加することにより、検索ベースを定義する必要があります。
Syntax:
構文：
serviceSearchList = serviceID ":" serviceSearchDesc *(";"
serviceSearchDesc)
serviceSearchDesc = confReferral / searchDescriptor
searchDescriptor = [base] ["?" [scopeSyntax] ["?" [filter]]]
confReferral = "ref:" distinguishedName
confreferral = "ref：" distinguedname
base = distinguishedName / relativeBaseName
relativeBaseName = 1*(relativeDistinguishedName ",")
filter = UTF-8 encoded string
If the confReferral, base, relativeBaseName, or filter contains the ";" (ASCII 0x3B), "?" (ASCII 0x3F), """ (ASCII 0x22), or "\" (ASCII 0x5C) characters, those characters MUST be escaped (preceded by the "\" character). Alternately, the DN may be surrounded by quotes (ASCII 0x22). Refer to RFC 4514. If the confReferral, base, relativeBaseName, or filter are surrounded by quotes, only the """ character needs to be escaped. Any character that does not need to be escaped, and yet is preceded by the "\" character, results in both the "\" character and the character itself.
freferral、base、relativebaseName、またはフィルターに「;」が含まれている場合（ASCII 0x3B）、「？」（ASCII 0x3F）、 "" "（ASCII 0x22）、または" \ "（ascii 0x5c）文字、それらの文字は逃げる必要があります（「\"文字の前）。）。RFC4514を参照してください。Confferral、Base、Relative、またはFilterが引用符に囲まれている場合、「 ""キャラクターのみが逃げる必要があります。逃げる必要はないが、「\」の文字が先行するキャラクターは、「\」文字とキャラクター自体の両方になります。
The usage and syntax of the filter string MUST be defined by the DUA service. A suggested syntax would be that defined by [RFC4515].
フィルター文字列の使用法と構文は、DUAサービスで定義する必要があります。推奨される構文は、[RFC4515]によって定義されるものです。
If a DUA is performing a search for a particular service that has a serviceSearchDescriptor defined, the DUA MUST set the base, scope, and filter as defined. Each base-scope-filter triple represents a single LDAP search operation. If multiple base-scope-filter triples are provided in the serviceSearchDescriptor, the DUA SHOULD perform multiple search requests, and in that case, it MUST be in the order specified by the serviceSearchDescriptor.
DUAがServicesearchDescriptorが定義されている特定のサービスの検索を実行している場合、DUAは定義どおりにベース、スコープ、フィルターを設定する必要があります。各ベーススコープフィルタートリプルは、単一のLDAP検索操作を表します。ServicesearchDescriptorで複数のベーススコープフィルタートリプルが提供されている場合、DUAは複数の検索リクエストを実行する必要があり、その場合、ServicesearchDescriptorによって指定された順序で必要です。
FYI: Service search descriptors do not exactly follow the LDAP URL syntax [RFC4516]. The reasoning for this difference is to separate the host name(s) from the filter. This allows the DUA to have a more flexible solution in choosing its DSA.
FYI：サービス検索記述子は、LDAP URL構文[RFC4516]に正確に従うことはありません。この違いの理由は、ホスト名をフィルターから分離することです。これにより、DUAはDSAを選択する際のより柔軟なソリューションを持つことができます。
Default Value:
デフォルト値：
If a serviceSearchDescriptor, or an element thereof, is not defined for a particular service, the DUA SHOULD create the base, scope, and filter as follows:
ServicesearchDescriptor、またはその要素が特定のサービスに対して定義されていない場合、DUAは次のようにベース、スコープ、フィルターを作成する必要があります。
base - Same as the defaultSearchBase.
ベース - defaultsearchbaseと同じ。
scope - Same as the defaultSearchScope.
スコープ - defaultsearchScopeと同じ。
filter - Use defaults as defined by DUA's service.
フィルター - DUAのサービスで定義されているデフォルトを使用します。
If the defaultSearchBase or defaultSearchScope is not defined, then the DUA service MAY use its own default.
DefaultSearchBaseまたはDefaultSearchScopeが定義されていない場合、DUAサービスは独自のデフォルトを使用する場合があります。
Other attribute notes:
その他の属性メモ：
If a serviceSearchDescriptor exists for a given service, the service MUST use at least one base-scope-filter triple in performing searches. It SHOULD perform multiple searches per service if multiple base-scope-filter triples are defined for that service.
特定のサービスにServicesearchDescriptorが存在する場合、サービスは検索の実行に少なくとも1つのベーススコープフィルタートリプルを使用する必要があります。そのサービス用に複数のベーススコープフィルタートリプルが定義されている場合、サービスごとに複数の検索を実行する必要があります。
The details of how the "filter" is interpreted by each DUA's service is defined by that service. This means the filter is NOT REQUIRED to be a legal LDAP filter [RFC4515]. Furthermore, determining how attribute and object class mapping affects that search filter MUST be defined by the service. That is, the DUA SHOULD specify if the attributes in the filter are assumed to already have been mapped, or if it is expected that attribute mapping (see Section 4.7) would be applied to the filter. In general practice, implementation and usability suggests that attribute and object class mapping (Sections 4.7 and 4.13) SHOULD NOT be applied to the filter defined in the serviceSearchDescriptor.
各DUAのサービスによって「フィルター」がどのように解釈されるかの詳細は、そのサービスによって定義されます。これは、フィルターが合法的なLDAPフィルターである必要がないことを意味します[RFC4515]。さらに、属性とオブジェクトのクラスマッピングがどのように影響するかを決定する検索フィルターは、サービスによって定義する必要があります。つまり、DUAは、フィルター内の属性が既にマッピングされていると想定されているかどうか、または属性マッピング（セクション4.7を参照）がフィルターに適用されるかどうかを指定する必要があります。一般的な慣行では、実装とユーザビリティは、属性とオブジェクトのクラスマッピング（セクション4.7および4.13）をServicesearchDescriptorで定義されたフィルターに適用しないでください。
The serviceID is unique to a given service within the scope of any DUA that might use the given profile, and should be defined by that service. Registration of serviceIDs is not addressed by this document. However, as per the guidance at the end of Section 1, when DUA developers define their use of the DUAConfigProfile schema, they will define the serviceIDs used by that DUA.
ServiceIDは、指定されたプロファイルを使用する可能性のあるDUAの範囲内で特定のサービスに固有のものであり、そのサービスによって定義される必要があります。ServiceIDSの登録は、このドキュメントでは対処されていません。ただし、DUA開発者がDuaConfigProfileスキーマの使用を定義するセクション1の最後のガイダンスによると、そのDUAが使用するServiceIDを定義します。
searchGuide and enhancedSearchGuide [RFC4517]:
SearchGuideおよびEnhancedSearchGuide [RFC4517]：
There are a few reasons why the authors chose not to take advantage of the existing searchGuide and enhancedSearchGuide attributes and related syntaxes. While the enhancedSearchGuide met a number of the serviceSearchDescriptor requirements, serviceSearchDescriptor was developed primarily to support associating search operations with services. Multiple services could be configured using the same profile, thus requiring the serviceID to be specified together with the search descriptor information. A few other reasons for not using enhancedSearchGuide include:
著者が既存のSearchGuideを利用しないことを選択し、検索ガイド属性と関連する構文を強化する理由がいくつかあります。EnhancedSearchGuideは多くのServicesearchDescriptor要件を満たしていますが、ServicesearchDescriptorは主に検索操作の関連付けをサポートするために開発されました。同じプロファイルを使用して複数のサービスを構成できるため、検索記述子情報とともにServiceIDを指定する必要があります。EnhancedSearchGuideを使用しない他のいくつかの理由は次のとおりです。
The need to specify alternate search bases, including the ability to specify search bases that are relative to the parent defaultSearchBase.
親DefaultSearchBaseに関連する検索ベースを指定する機能など、代替検索ベースを指定する必要性。
The need to specify alternate profiles using the "ref:" syntax.
「ref：」構文を使用して代替プロファイルを指定する必要があります。
The ability for individual services to specify their own syntaxes for the format of the search filter.
個々のサービスが検索フィルターの形式に独自の構文を指定する機能。
The authors' belief that the user community is more familiar with the search filter syntax described by RFC 4515 than with that described by the enhancedSearchGuide syntax.
ユーザーコミュニティは、RFC 4515によって記述された検索フィルターの構文に精通しているという著者の信念は、EnhancedSearchGuideの構文によって説明されているものよりも精通しています。
Example:
例：
defaultSearchBase: dc=mycompany,dc=com
serviceSearchDescriptor: email:ou=people,ou=org1,?
one;ou=contractor,?one;
ref:cn=profile,dc=mycompany,dc=com
In this example, the DUA MUST search in "ou=people,ou=org1,dc=mycompany,dc=com" first. The DUA then SHOULD search in "ou=contractor,dc=mycompany,dc=com", and finally it SHOULD search other locations as specified in the profile described at "cn=profile,dc=mycompany,dc=com". For more examples, see Appendix A.
この例では、DUAは「OU = People、ou = org1、dc = mycompany、dc = com」で検索する必要があります。その後、DUAは「ou =請負業者、dc = mycompany、dc = com」で検索する必要があります。最後に、「cn = profile、dc = mycompany、dc = com」で説明されているプロファイルで指定されている他の場所を検索する必要があります。その他の例については、付録Aを参照してください。
Interpretation:
解釈：
A DUA SHOULD perform attribute mapping for all LDAP operations performed for a service that has an attributeMap entry. Because attribute mapping is specific to each service within the DUA, a "serviceID" is required as part of the attributeMap syntax. That is, not all DUA services should necessarily perform the same attribute mapping.
DUAは、属性エントリを持つサービスに対して実行されるすべてのLDAP操作に対して属性マッピングを実行する必要があります。属性マッピングはDUA内の各サービスに固有であるため、astributemap構文の一部として「serviceID」が必要です。つまり、すべてのDUAサービスが必ずしも同じ属性マッピングを実行する必要はありません。
Attribute mapping in general is expected to be used to map attributes of similar syntaxes as specified by the service supported by the DUA. However, a DUA is NOT REQUIRED to verify syntaxes of mapped attributes. If the DUA does discover that the syntax of the mapped attribute does not match that of the original attribute, the DUA MAY perform translation between the original syntax and the new syntax. When DUAs do support attribute value translation, the method and list of capable translations SHOULD be documented in a description of the DUA service.
一般に属性マッピングは、DUAがサポートするサービスで指定されているように、同様の構文の属性をマッピングするために使用されることが期待されています。ただし、マッピングされた属性の構文を検証するためにDUAは必要ありません。DUAがマッピングされた属性の構文が元の属性の構文と一致しないことを発見した場合、DUAは元の構文と新しい構文の間の翻訳を実行する場合があります。DUASが属性値の翻訳をサポートする場合、有能な翻訳の方法とリストをDUAサービスの説明に文書化する必要があります。
Syntax:
構文：
attributeMap = serviceID ":" origAttribute "=" attributes
origAttribute = attribute
attributes = wattribute *( SP wattribute )
属性= wattribute *（sp wattribute）
wattribute = WSP newAttribute WSP
newAttribute = descr / "*NULL*"
attribute = descr
Values of the origAttribute are defined by and SHOULD be documented for the DUA service, as a list of known supported attributes.
由来の値は、既知のサポートされた属性のリストとして、DUAサービスのために定義され、文書化されるべきです。
Default Value:
デフォルト値：
By default, attributes that are used by a DUA service are not mapped unless mapped by the attributeMap attributes. The DUA SHOULD NOT map an attribute unless it is explicitly defined by an attributeMap attribute.
デフォルトでは、DUAサービスで使用される属性は、AttributeMap属性によってマッピングされない限りマッピングされません。DUAは、属性属性によって明示的に定義されていない限り、属性をマップしないでください。
Other attribute notes:
その他の属性メモ：
When an attribute is mapped to the special keystring "*NULL*", the DUA SHOULD NOT request that attribute from the DSA, when performing a search or compare request. If the DUA is also capable of performing modification on the DSA, the DUA SHOULD NOT attempt to modify any attribute which has been mapped to "*NULL*".
属性が特別なキーストリング「*null*」にマッピングされた場合、DUAは検索または比較要求を実行するときに、DSAからその属性を要求してはなりません。DUAがDSAで変更を実行できる場合、DUAは「*null*」にマッピングされた属性を変更しようとしてはなりません。
It is assumed the serviceID is unique to a given service within the scope of the DSA.
ServiceIDは、DSAの範囲内で特定のサービスに固有のものであると想定されています。
A DUA SHOULD support attribute mapping. If it does, the following additional rules apply:
DUAは属性マッピングをサポートする必要があります。もしそうなら、次の追加ルールが適用されます。
1. The list of attributes that are allowed to be mapped SHOULD be defined by and documented for the service.
1. マップされることが許可されている属性のリストは、サービス用に定義され、文書化する必要があります。
2. Any supported translation of mapping from attributes of dissimilar syntax SHOULD also be defined and documented.
2. 類似の構文の属性からのマッピングのサポートされている翻訳も定義および文書化する必要があります。
3. If an attribute may be mapped to multiple attributes, the DSA SHOULD define a syntax or usage statement for how the new attribute value will be constructed. Furthermore, the resulting translated syntax of the combined attributes MUST be the same as the attribute being mapped.
3. 属性が複数の属性にマッピングされる場合がある場合、DSAは、新しい属性値の構築方法の構文または使用ステートメントを定義する必要があります。さらに、結果の翻訳された翻訳された属性の構文は、マッピングされている属性と同じでなければなりません。
4. A DUA MUST support mapping of attributes using the attribute OID. It SHOULD support attribute mapping based on the attribute name.
4. DUAは、属性OIDを使用して属性のマッピングをサポートする必要があります。属性名に基づいて属性マッピングをサポートする必要があります。
5. It is recommended that attribute mapping not be applied to parents of the target entries.
5. 属性マッピングをターゲットエントリの親に適用しないことをお勧めします。
6. Attribute mapping is not recursive. In other words, if an attribute has been mapped to a target attribute, that new target attribute MUST NOT be mapped to a third attribute.
6. 属性マッピングは再帰的ではありません。言い換えれば、属性がターゲット属性にマッピングされている場合、その新しいターゲット属性を3番目の属性にマッピングする必要はありません。
7. A given attribute MUST only be mapped once for a given service.
7. 特定の属性は、特定のサービスに対して1回のみマッピングする必要があります。
Example:
例：
Suppose a DUA is acting on behalf of an email service. By default the "email" service uses the "mail", "cn", and "sn" attributes to discover mail addresses. However, the email service has been deployed in an environment that uses "employeeName" instead of "cn". Also, instead of using the "mail" attribute for email addresses, the "email" attribute is used. In this case, the attribute "cn" can be mapped to "employeeName", allowing the DUA to perform searches using the "employeeName" attribute as part of the search filter, instead of "cn". Also, "mail" can be mapped to "email" when attempting to retrieve the email address. This mapping is performed by adding the attributeMap attributes to the configuration profile entry as follows (represented in LDIF [RFC2849]):
DUAが電子メールサービスに代わって行動しているとします。デフォルトでは、「電子メール」サービスでは、「メール」、「CN」、および「SN」属性を使用して、メールアドレスを発見します。ただし、電子メールサービスは、「CN」の代わりに「EmployeName」を使用する環境に展開されています。また、電子メールアドレスに「メール」属性を使用する代わりに、「電子メール」属性が使用されます。この場合、属性「CN」を「EmployeName」にマッピングすることができ、DUAは「CN」ではなく検索フィルターの一部として「EmployeName」属性を使用して検索を実行できます。また、電子メールアドレスを取得しようとするときに、「メール」を「電子メール」にマッピングできます。このマッピングは、次のように構成プロファイルエントリに属性属性を追加することにより実行されます（LDIF [RFC2849]で表されます）：
attributeMap: email:cn=employeeName
attributeMap: email:mail=email
As described above, the DUA MAY also map a single attribute to multiple attributes. When mapping a single attribute to more than one attribute, the new syntax or usage of the mapped attribute must be intrinsically defined by the DUAs service.
上記のように、DUAは単一の属性を複数の属性にマッピングする場合があります。単一の属性を複数の属性にマッピングする場合、マッピングされた属性の新しい構文または使用法は、DUASサービスによって本質的に定義されなければなりません。
attributeMap: email:cn=firstName lastName
In the above example, the DUA creates the new value by generating a space-separated string using the values of the mapped attributes. In this case, a special mapping must be defined so that a proper search filter can be created. For further information on this example, please refer to Appendix A.
上記の例では、DUAは、マッピングされた属性の値を使用してスペース分離文字列を生成することにより、新しい値を作成します。この場合、適切な検索フィルターを作成できるように、特別なマッピングを定義する必要があります。この例の詳細については、付録Aを参照してください。
Another possibility for multiple attribute mapping might come in when constructing returned attributes. For example, perhaps all email addresses are of a guaranteed syntax of "uid@domain". In this example, the uid and domain are separate attributes in the directory. The email service may define that if the "mail" attribute is mapped to two different attributes, it will construct the email address as a concatenation of the two attributes (uid and domain), placing the "@" character between them.
返された属性を構築するときに、複数の属性マッピングの別の可能性が発生する可能性があります。たとえば、おそらくすべてのメールアドレスは、「uid@domain」の保証された構文のものです。この例では、UIDとドメインはディレクトリ内の個別の属性です。電子メールサービスは、「メール」属性が2つの異なる属性にマッピングされた場合、2つの属性（UIDとドメイン）の連結として電子メールアドレスを構築し、それらの間に「@」文字を配置することを定義する場合があります。
attributeMap: email:mail=uid domain
Note: The attributeMap attribute contains only a list of attribute names that should be mapped, not the definition of how syntax translation should be performed. The process used to perform attribute value syntax translation (such as translating a uid to a DN) and/or joining of multiple attribute values to form the target syntax (such as in the above email example) is up to the service. The attribute list defined in the attributeMap merely provides the attributes that would be used as inputs to the translation function provided by the service.
注：AttributeMap属性には、構文変換の実行方法の定義ではなく、マッピングする必要がある属性名のリストのみが含まれています。属性値の構文変換を実行するために使用されるプロセス（UIDをDNに変換するなど）や複数の属性値を結合してターゲット構文（上記の電子メール例など）を形成するのはサービス次第です。AttributeMapで定義された属性リストは、サービスによって提供される変換関数への入力として使用される属性を単に提供するだけです。
Interpretation:
解釈：
The searchTimeLimit attribute defines the maximum time, in seconds, that the DUA SHOULD allow for a search request to complete.
SearchTimElimit属性は、DUAが検索リクエストを完了できるようにする必要がある数秒で最大時間を定義します。
Syntax:
構文：
Defined by OID 1.3.6.1.4.1.1466.115.121.1.27 [RFC4517].
OID 1.3.6.1.4.1.146.115.121.1.1.1.1.27 [RFC4517]によって定義されています。
Default Value:
デフォルト値：
If the searchTimeLimit attribute is not defined or is zero, the searchTimeLimit SHOULD NOT be enforced by the DUA.
searchTimElimit属性が定義されていないか、ゼロである場合、SearchTimElimitをDUAによって施行するべきではありません。
Other attribute notes:
その他の属性メモ：
This time limit only includes the amount of time required to perform the LDAP search operation. If other operations are required, they do not need to be considered part of the search time. See bindTimeLimit for the LDAP bind operation.
この時間制限には、LDAP検索操作を実行するのに必要な時間のみが含まれます。他の操作が必要な場合、検索時間の一部と見なす必要はありません。LDAPバインド操作については、bindtimelimitを参照してください。
Interpretation:
解釈：
The bindTimeLimit attribute defines the maximum time, in seconds, that a DUA SHOULD allow for the bind request to complete when performed against each server on the preferredServerList or defaultServerList.
Bindtimelimit属性は、DUAがBINDリクエストをPreferredServerlistまたはDefaultServerListで各サーバーに対して実行したときに完了できるようにする必要がある秒単位で最大時間を定義します。
Syntax:
構文：
Defined by OID 1.3.6.1.4.1.1466.115.121.1.27.
OID 1.3.6.1.4.1.1466.115.121.1.1.1.27によって定義されています。
Default Value:
デフォルト値：
If the bindTimeLimit attribute is not defined or is zero, the bindTimeLimit SHOULD NOT be enforced by the DUA.
bindtimelimit属性が定義されていないか、ゼロである場合、bindtimelimitはDUAによって施行されるべきではありません。
Other attribute notes:
その他の属性メモ：
This time limit only includes the amount of time required to perform the LDAP bind operation. If other operations are required, those operations do not need to be considered part of the bind time. See searchTimeLimit for the LDAP search operation.
この時間制限には、LDAPバインド操作を実行するのに必要な時間のみが含まれます。他の操作が必要な場合、それらの操作はバインド時間の一部と見なす必要はありません。LDAP検索操作については、searchtimelimitを参照してください。
Interpretation:
解釈：
If set to TRUE, the DUA SHOULD follow any referrals if discovered.
Trueに設定されている場合、DUAは発見された場合は紹介に従う必要があります。
If set to FALSE, the DUA MUST NOT follow referrals.
falseに設定した場合、DUAは紹介に従ってはなりません。
Syntax:
構文：
Defined by OID 1.3.6.1.4.1.1466.115.121.1.7 [RFC4517].
OID 1.3.6.1.4.1.146.115.121.1.7 [RFC4517]によって定義されています。
Default Value:
デフォルト値：
If the followReferrals attribute is not set or set to an invalid value, the default value is TRUE.
followReferrals属性が無効な値に設定または設定されていない場合、デフォルト値は真です。
Interpretation:
解釈：
If set to TRUE, the DUA SHOULD enable alias dereferencing.
Trueに設定されている場合、DUAはエイリアスの解消を有効にする必要があります。
If set to FALSE, the DUA MUST NOT enable alias dereferencing.
falseに設定した場合、DUAはエイリアスの解消を有効にしてはなりません。
Syntax:
構文：
Defined by OID 1.3.6.1.4.1.1466.115.121.1.7.
OID 1.3.6.1.4.1.146.115.121.1.7によって定義されています。
Default Value:
デフォルト値：
If the dereferenceAliases attribute is not set or set to an invalid value, the default value is TRUE.
dereferencealiase属性が無効な値に設定または設定されていない場合、デフォルト値は真です。
Interpretation:
解釈：
The profileTTL attribute defines how often the DUA SHOULD reload and reconfigure itself using the corresponding configuration profile entry. The value is represented in seconds. Once a DUA reloads the profile entry, it SHOULD reconfigure itself with the new values.
PREPRETTL属性は、DUAが対応する構成プロファイルエントリを使用して自体をリロードし、再構成する頻度を定義します。値は数秒で表されます。DUAがプロファイルエントリをリロードすると、新しい値でそれ自体を再構成する必要があります。
Syntax:
構文：
Defined by OID 1.3.6.1.4.1.1466.115.121.1.27.
OID 1.3.6.1.4.1.1466.115.121.1.1.1.27によって定義されています。
Default Value:
デフォルト値：
If not specified, the DUA MAY use its own reconfiguration policy.
指定されていない場合、DUAは独自の再構成ポリシーを使用する場合があります。
Other attribute notes:
その他の属性メモ：
If the profileTTL value is zero, the DUA SHOULD NOT automatically reload the configuration profile.
Profilettl値がゼロの場合、DUAは構成プロファイルを自動的にリロードしてはなりません。
Interpretation:
解釈：
A DUA MAY perform object class mapping for all LDAP operations performed for a service that has an objectclassMap entry. Because object class mapping is specific for each service within the DUA, a "serviceID" is required as part of the objectclassMap syntax. That is, not all DUA services should necessarily perform the same object class mapping.
DUAは、ObjectClassMapエントリを持つサービスに対して実行されるすべてのLDAP操作に対してオブジェクトクラスマッピングを実行できます。オブジェクトクラスマッピングはDUA内の各サービスに固有であるため、ObjectClassMap構文の一部として「ServiceID」が必要です。つまり、すべてのDUAサービスが必ずしも同じオブジェクトクラスマッピングを実行する必要はありません。
Object class mapping SHOULD be used in conjunction with attribute mapping to map the schema required by the service to an equivalent schema that is available in the directory.
オブジェクトクラスマッピングは、属性マッピングと組み合わせて使用して、サービスに必要なスキーマをディレクトリで使用できる同等のスキーマにマッピングする必要があります。
Object class mapping may or may not be required by a DUA. Often, the objectclass attribute is used in search filters. Section 4.7 recommends that attribute mapping not be applied to the serviceSearchDescriptor. Thus, if the default object classes are not used in a DUA deployment, typically only the serviceSearchDescriptor needs to be defined to reflect that mapping. However, when the service search descriptor is not provided, and the default search filter for that service contains the objectclass attribute, that search filter SHOULD be redefined by object class mapping, if defined. If a default search filter is not used, it SHOULD be redefined through the serviceSearchDescriptor. If a serviceSearchDescriptor is defined for a particular service, it SHOULD NOT be remapped by either the objectclassMap or attributeMap values.
Objectクラスマッピングは、DUAが必要とする場合とそうでない場合があります。多くの場合、ObjectClass属性は検索フィルターで使用されます。セクション4.7では、属性マッピングをServicesearchDescriptorに適用しないことを推奨しています。したがって、デフォルトのオブジェクトクラスがDUAの展開で使用されていない場合、通常、ServicesearchDescriptorのみを定義してそのマッピングを反映する必要があります。ただし、サービス検索記述子が提供されておらず、そのサービスのデフォルト検索フィルターにObjectClass属性が含まれている場合、その検索フィルターは、定義されている場合はオブジェクトクラスマッピングによって再定義される必要があります。デフォルトの検索フィルターを使用していない場合は、ServicesearchDescriptorを介して再定義する必要があります。ServicesearchDescriptorが特定のサービスに対して定義されている場合、ObjectClassMapまたはAttributeMap値のいずれでも再マッピングしないでください。
One condition where the objectclassMap SHOULD be used is when the DUA is providing gateway functionality. In this case, the DUA is acting on behalf of another service, which may pass in a search filter itself. In this type of DUA, the DUA may alter the search filter according to the appropriate attributeMap and objectclassMap values. In this case, it is also assumed that a serviceSearchDescriptor is not defined.
ObjectClassMapを使用する必要がある条件の1つは、DUAがゲートウェイ機能を提供している場合です。この場合、DUAは別のサービスに代わって行動しており、検索フィルター自体を渡すことができます。このタイプのDUAでは、DUAは適切な属性およびObjectClassMap値に従って検索フィルターを変更する場合があります。この場合、ServicesearchDescriptorが定義されていないことも想定されています。
Syntax:
構文：
objectclassMap = serviceID ":" origObjectclass "=" objectclass
origObjectclass = objectclass
objectclass = keystring
Values of the origObjectclass depend on the type of DUA Service using the object class mapping feature.
OrigonObjectClassの値は、オブジェクトクラスマッピング機能を使用してDUAサービスのタイプに依存します。
Default Value:
デフォルト値：
The DUA MUST NOT remap an object class unless it is explicitly defined by an objectclassMap attribute.
DUAは、ObjectClassMap属性によって明示的に定義されていない限り、オブジェクトクラスを再表示してはなりません。
Other attribute notes:
その他の属性メモ：
A DUA SHOULD support object class mapping. If it does, the DUA MUST support mapping of object classes using the objectclass OID. It SHOULD support object class mapping based on the object class name.
DUAはオブジェクトクラスマッピングをサポートする必要があります。もしそうなら、DUAはObjectClass Oidを使用してオブジェクトクラスのマッピングをサポートする必要があります。オブジェクトクラス名に基づいてオブジェクトクラスマッピングをサポートする必要があります。
It is assumed the serviceID is unique to a given service within the scope of the DSA.
ServiceIDは、DSAの範囲内で特定のサービスに固有のものであると想定されています。
Example:
例：
Suppose a DUA is acting on behalf of an email service. By default the "email" service uses the "mail", "cn", and "sn" attributes to discover mail addresses in entries created using inetOrgPerson object class [RFC2789]. However, the email service has been deployed in an environment that uses entries created using "employee" object class. In this case, the attribute "cn" can be mapped to "employeeName", and "inetOrgPerson" can be mapped to "employee", allowing the DUA to perform LDAP operations using the entries that exist in the directory. This mapping is performed by adding attributeMap and objectclassMap attributes to the configuration profile entry as follows (represented in LDIF [RFC2849]):
DUAが電子メールサービスに代わって行動しているとします。デフォルトでは、「電子メール」サービスは、「メール」、「CN」、および「SN」属性を使用して、InetorgPersonオブジェクトクラス[RFC2789]を使用して作成されたエントリでメールアドレスを発見します。ただし、電子メールサービスは、「従業員」オブジェクトクラスを使用して作成されたエントリを使用する環境に展開されています。この場合、属性「CN」は「EmployeName」にマッピングでき、「Inetorgperson」は「従業員」にマッピングでき、DUAはディレクトリに存在するエントリを使用してLDAP操作を実行できます。このマッピングは、次のように構成プロファイルエントリにastributeMapおよびobjectClassMap属性を追加することにより実行されます（LDIF [RFC2849]で表されます）：
attributeMap: email:cn=employeeName
objectclassMap: email:inetOrgPerson=employee
Interpretation:
解釈：
When a DUA needs to search the DSA for information, this attribute provides the "scope" for the search. This parameter can be overridden by the serviceSearchDescriptor attribute. See Section 4.6.
DUAが情報をDSAに検索する必要がある場合、この属性は検索の「スコープ」を提供します。このパラメーターは、ServicesearchDescriptor属性によってオーバーライドできます。セクション4.6を参照してください。
Syntax:
構文：
scopeSyntax = "base" / "one" / "sub"
Default Value:
デフォルト値：
The default value for the defaultSearchScope SHOULD be defined by the DUA service. If the default search scope for a service is not defined, then the scope SHOULD be for the DUA to perform a subtree search.
DefaultSearchScopeのデフォルト値は、DUAサービスによって定義される必要があります。サービスのデフォルトの検索スコープが定義されていない場合、ScopeはDUAがサブツリー検索を実行するためのものです。
Interpretation:
解釈：
The serviceAuthenticationMethod attribute defines an ordered list of LDAP bind methods to be used when attempting to contact a DSA for a particular service. Interpretation and use of this attribute is the same as Section 4.4, but specific for each service.
ServiceAuthenticationMethod属性は、特定のサービスのためにDSAに連絡しようとするときに使用するLDAPバインドメソッドの順序付けられたリストを定義します。この属性の解釈と使用は、セクション4.4と同じですが、各サービスに固有です。
Syntax:
構文：
svAuthMethod = serviceID ":" method *(";" method)
Note: Although multiple authentication methods may be specified in the syntax, at most one of each type is allowed.
注：複数の認証メソッドは構文で指定されている場合がありますが、各タイプのせいぜい1つが許可されています。
Default Value:
デフォルト値：
If the serviceAuthenticationMethod attribute is not provided, the authenticationMethod SHOULD be followed, or its default.
ServiceAuthenticationMethod属性が提供されていない場合、AuthenticationMethodに従うか、そのデフォルトに従う必要があります。
Other attribute notes:
その他の属性メモ：
Determining how the DUA should bind to the DSAs also depends on the additional configuration attributes, credentialLevel, serviceCredentialLevel, and bindTimeLimit. Please review Section 5 for details on how to properly bind to a DSA.
DUAがDSASにどのように結合するかを判断することは、追加の構成属性、SredentienceLevel、ServicedentialLevel、およびBindtimelimitにも依存します。DSAに適切にバインドする方法の詳細については、セクション5をご覧ください。
Example:
例：
serviceAuthenticationMethod: email:tls:simple;sasl/DIGEST-MD5
Interpretation:
解釈：
The serviceCredentialLevel attribute defines what type(s) of credential(s) the DUA SHOULD use when contacting the DSA for a particular service. Interpretation and use of this attribute are the same as Section 4.5.
ServiceCredentialLevel属性は、DUAがDSAに連絡するときに使用する資格情報のタイプを特定のサービスに連絡する際に使用すべき資格情報を定義します。この属性の解釈と使用は、セクション4.5と同じです。
Syntax:
構文：
svCredentialLevel = serviceID ":" level *(SP level)
Refer to implementation notes in Section 5 for additional syntax requirements for the credentialLevel attribute.
資格のLevel属性の追加の構文要件については、セクション5の実装ノートを参照してください。
Note: Although multiple credential levels may be specified in the syntax, at most one of each type is allowed.
注：構文では複数の資格情報レベルが指定される場合がありますが、各タイプの最大1つが許可されています。
Default Value:
デフォルト値：
If the serviceCredentialLevel attribute is not defined, the DUA MUST examine the credentialLevel attribute, or if one is not provided, the DUA must follow its default.
ServiceCredentialLevel属性が定義されていない場合、DUAは資格情報レベル属性を調べる必要があります。または、提供されていない場合、DUAはデフォルトに従う必要があります。
Other attribute notes:
その他の属性メモ：
Determining how the DUA should bind to the DSAs also depends on the additional configuration attributes, serviceAuthenticationMethod, authenticationMethod, and bindTimeLimit. Please review Section 5 for details on how to properly bind to a DSA.
DUAがDSASにどのように結合するかを判断することは、追加の構成属性、ServiceAuthenticationMethod、AuthenticationMethod、およびBindtimelimitにも依存します。DSAに適切にバインドする方法の詳細については、セクション5をご覧ください。
Example:
例：
serviceCredentialLevel: email:proxy anonymous
ServiceCredentialLevel：電子メール：プロキシAnonymous
The DUA SHOULD use the following algorithm when binding to the server:
DUAは、サーバーにバインディングするときに次のアルゴリズムを使用する必要があります。
for (clevel in credLevel) [see Note 1]
if (clevel is "anonymous")
for (host in hostnames) [see Note 2]
if (server is responding)
return success
return failure
else
for (amethod in authMethod) [see Note 3]
if (amethod is none)
for (host in hostnames)
if (server is responding)
return success
return failure
else
for (host in hostnames)
authenticate using amethod and clevel
if (authentication passed)
return success
return failure
Note 1: The credLevel is a list of credential levels as defined in serviceCredentialLevel (Section 4.16) for a given service. If the serviceCredentialLevel is not defined, the DUA MUST examine the credentialLevel attribute.
注1：CredLevelは、特定のサービスのServiceCredentialLevel（セクション4.16）で定義されている資格レベルのリストです。ServiceCredentialLevelが定義されていない場合、DUAは資格のあるレベル属性を調べなければなりません。
Note 2: hostnames is the list of servers to contact as defined in Sections 4.1 and 4.2.
注2：ホスト名は、セクション4.1および4.2で定義されているように連絡するサーバーのリストです。
Note 3: The authMethod is a list of authentication methods as defined in serviceAuthenticationMethod (Section 4.15) for a given service. If the serviceAuthenticationMethod is not defined, the DUA MUST examine the authenticationMethod attribute.
注3：AuthMethodは、特定のサービスのServiceAuthicationMethod（セクション4.15）で定義されている認証方法のリストです。ServiceAuthenticationMethodが定義されていない場合、DUAはAuthenticationMethod属性を調べなければなりません。
The profile entries MUST be protected against unauthorized modification. Each service needs to consider implications of providing its service configuration as part of this profile and limit access to the profile entries accordingly.
プロファイルエントリは、不正な変更から保護する必要があります。各サービスは、このプロファイルの一部としてサービス構成を提供することの意味を考慮し、それに応じてプロファイルエントリへのアクセスを制限する必要があります。
The management of the authentication credentials for the DUA is outside the scope of this document and needs to be handled by the DUA.
DUAの認証資格情報の管理は、このドキュメントの範囲外であり、DUAが処理する必要があります。
Since the DUA needs to know how to properly bind to the directory server, the access control configuration of the DSA MUST assure that the DSA can view all the elements of the DUAConfigProfile attributes. For example, if the credentialLevel attribute contains "Self", but the DSA is unable to access the credentialLevel attribute, the DUA will instead attempt an anonymous connection to the directory server.
DUAはディレクトリサーバーに適切にバインドする方法を知る必要があるため、DSAのアクセス制御構成は、DSAがDuaconFigProfile属性のすべての要素を表示できることを保証する必要があります。たとえば、資格のあるレベルの属性に「self」が含まれているが、DSAが資格のあるレベル属性にアクセスできない場合、DUAは代わりにディレクトリサーバーへの匿名接続を試みます。
The algorithm described by Section 5 also has security considerations. Altering that design will alter the security aspects of the configuration profile.
セクション5で説明されているアルゴリズムには、セキュリティ上の考慮事項もあります。その設計を変更すると、構成プロファイルのセキュリティの側面が変更されます。
At times, DUAs connect to multiple directory servers in order to support potential high-availability and/or performance requirements. As such, each directory server specified in the preferredServer list and defaultServerList MUST contain the same (replicated) data and be part of the same security domain. This means the directory-supported authentication methods, authentication policies, and access control policies for directory data are exactly the same across all the defined directory servers.
時には、DUASは、潜在的な高可用性および/またはパフォーマンス要件をサポートするために、複数のディレクトリサーバーに接続します。そのため、PreferredServerリストとDefaultServerListで指定された各ディレクトリサーバーには、同じ（複製された）データを含み、同じセキュリティドメインの一部である必要があります。これは、ディレクトリサポートされた認証方法、認証ポリシー、およびディレクトリデータのアクセス制御ポリシーが、定義されたすべてのディレクトリサーバーでまったく同じであることを意味します。
There were several additional authors of this document. However, we chose to represent only one author per company in the heading. From Sun, we would like to acknowledge Roberto Tam for his design work on Sun's first LDAP name service product and his input for this document. From Hewlett-Packard, we'd like to acknowledge Dave Binder for his work architecting Hewlett-Packard's LDAP name service product as well as his design guidance on this document. We'd also like to acknowledge Grace Lu from HP, for her input and implementation of HP's configuration profile manager code.
この文書の追加の著者がいくつかありました。ただし、見出しの会社ごとに1人の著者のみを代表することを選択しました。Sunから、Roberto TamがSunの最初のLDAPネームサービス製品とこのドキュメントの入力に関する彼のデザイン作業について認めたいと思います。Hewlett-Packardから、Hewlett-PackardのLDAP Nameサービス製品とこのドキュメントへの設計ガイダンスをアーキテクテクタリングしている彼の作品について、Dave Binderに感謝します。また、HPの構成プロファイルマネージャーコードの入力と実装について、HPのGrace Luに感謝します。
This document defines new LDAP attributes and an object class for object identifier descriptors. As specified by Section 3.4 and required by Section 4 of [RFC4520], this document registers new descriptors as follows per the Expert Review.
このドキュメントでは、新しいLDAP属性とオブジェクト識別子記述子のオブジェクトクラスを定義します。セクション3.4で指定され、[RFC4520]のセクション4で要求されているように、このドキュメントは、専門家のレビューに従って新しい記述子を次のように登録します。
Subject: Request for LDAP Descriptor Registration
件名：LDAP記述子登録のリクエスト
Descriptor (short name): DUAConfigProfile
記述子（ショート名）：duaconfigprofile
Object Identifier: 1.3.6.1.4.1.11.1.3.1.2.5
オブジェクト識別子：1.3.6.1.4.1.11.1.1.3.1.2.5
Person & email address to contact for further information: See "Author/Change Controller"
詳細については、連絡先への個人およびメールアドレス：「著者/変更コントローラー」を参照してください
Usage: object class
使用法：オブジェクトクラス
Specification: RFC 4876
仕様：RFC 4876
Author/Change Controller:
著者/変更コントローラー：
Bob Neal-Joslin Hewlett-Packard Company 19420 Homestead RD Cupertino, CA 95014 USA Phone: +1 408-447-3044 EMail: bob_joslin@hp.com
Bob Neal-Joslin Hewlett-Packard Company 19420 HomeStead Rd Cupertino、CA 95014 USA電話：1 408-447-3044メール：bob_joslin@hp.com
Comments:
コメント：
See also the associated request for the defaultServerList, defaultSearchBase, preferredServerList, searchTimeLimit, bindTimeLimit, followReferrals, authenticationMethod, profileTTL, attributeMap, credentialLevel, objectclassMap, defaultSearchScope, serviceCredentialLevel, serviceSearchDescriptor, serviceAuthenticationMethod, and dereferenceAliases attribute types.
DefaultServerlist、DefaultSearchBase、PreferredServerlist、SearchTimelimit、Bindtimelimit、FollowReferrals、AuthenticationMethod、ProfileTll、AttributeMap、credentienceLevel、ObjectClassMap、DefaultsearchScope、ServiceCredenteremethedの属性、ServerfereNTICERENTOR、ServiceDesctripcrection -searchScope、ServiCeCrection -searchScope、objectclassmap、defaultsearchScope、
Subject: Request for LDAP Descriptor Registration
件名：LDAP記述子登録のリクエスト
Descriptor (short name): See comments
記述子（ショート名）：コメントを参照してください
Object Identifier: See comments
オブジェクト識別子：コメントを参照してください
Person & email address to contact for further information: See "Author/Change Controller"
詳細については、連絡先への個人およびメールアドレス：「著者/変更コントローラー」を参照してください
Usage: attribute type Specification: RFC 4876
使用法：属性タイプ仕様：RFC 4876
Author/Change Controller:
著者/変更コントローラー：
Bob Neal-Joslin Hewlett-Packard Company 19420 Homestead RD Cupertino, CA 95014 USA Phone: +1 408-447-3044 EMail: bob_joslin@hp.com
Bob Neal-Joslin Hewlett-Packard Company 19420 HomeStead Rd Cupertino、CA 95014 USA電話：1 408-447-3044メール：bob_joslin@hp.com
Comments:
The following object identifiers and associated attribute types have been registered.
次のオブジェクト識別子と関連属性タイプが登録されています。
OID Attribute Type
-------------------------- ---------------------------
1.3.6.1.4.1.11.1.3.1.1.0 defaultServerList
1.3.6.1.4.1.11.1.3.1.1.1 defaultSearchBase
1.3.6.1.4.1.11.1.3.1.1.2 preferredServerList
1.3.6.1.4.1.11.1.3.1.1.3 searchTimeLimit
1.3.6.1.4.1.11.1.3.1.1.4 bindTimeLimit
1.3.6.1.4.1.11.1.3.1.1.5 followReferrals
1.3.6.1.4.1.11.1.3.1.1.6 authenticationMethod
1.3.6.1.4.1.11.1.3.1.1.7 profileTTL
1.3.6.1.4.1.11.1.3.1.1.9 attributeMap
1.3.6.1.4.1.11.1.3.1.1.10 credentialLevel
1.3.6.1.4.1.11.1.3.1.1.11 objectclassMap
1.3.6.1.4.1.11.1.3.1.1.12 defaultSearchScope
1.3.6.1.4.1.11.1.3.1.1.13 serviceCredentialLevel
1.3.6.1.4.1.11.1.3.1.1.14 serviceSearchDescriptor
1.3.6.1.4.1.11.1.3.1.1.15 serviceAuthenticationMethod
1.3.6.1.4.1.11.1.3.1.1.16 dereferenceAliases
Please also see the associated registration request for the DUAConfigProfile object class.
また、Duaconfigprofileオブジェクトクラスの関連する登録リクエストもご覧ください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：ジェネリック構文」、STD 66、RFC 3986、2005年1月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、RFC 4234、2005年10月。
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：技術仕様ロードマップ」、RFC 4510、2006年6月。
[RFC4511] Sermersheim, J., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4511] Sermersheim、J。、「Lightweight Directory Access Protocol（LDAP）：The Protocol」、RFC 4511、2006年6月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：ディレクトリ情報モデル」、RFC 4512、2006年6月。
[RFC4514] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names", RFC 4514, June 2006.
[RFC4514] Zeilenga、K。、「Lightweight Directory Access Protocol（LDAP）：著名な名前の文字列表現」、RFC 4514、2006年6月。
[RFC4516] Smith, M. and T. Howes, "Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator", RFC 4516, June 2006.
[RFC4516] Smith、M。およびT. Howes、「Lightweight Directory Access Protocol（LDAP）：ユニフォームリソースロケーター」、RFC 4516、2006年6月。
[RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517] Legg、S。、「Lightweight Directory Access Protocol（LDAP）：構文と一致するルール」、RFC 4517、2006年6月。
[RFC4519] Sciberras, A., "Lightweight Directory Access Protocol (LDAP): Schema for User Applications", RFC 4519, June 2006.
[RFC4519] Sciberras、A。、「Lightweight Directory Access Protocol（LDAP）：ユーザーアプリケーションのスキーマ」、RFC 4519、2006年6月。
[SASLMECH] IANA, "SIMPLE AUTHENTICATION AND SECURITY LAYER (SASL) MECHANISMS", July 2006, <http://www.iana.org/assignments/sasl-mechanisms>.
[Saslmech] Iana、「Simple Authentication and Security Layer（SASL）メカニズム」、2006年7月、<http://www.iana.org/assignments/sasl-mechanisms>。
[MSSFU] Microsoft Corporation, "Windows Services for Unix 3.5", <http://www.microsoft.com/windows/sfu/>.
[MSSFU] Microsoft Corporation、「UNIX 3.5のWindows Services」、<http://www.microsoft.com/windows/sfu/>。
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC 2307, March 1998.
[RFC2307] Howard、L。、「LDAPをネットワーク情報サービスとして使用するためのアプローチ」、RFC 2307、1998年3月。
[RFC2789] Freed, N. and S. Kille, "Mail Monitoring MIB", RFC 2789, March 2000.
[RFC2789] Freed、N。およびS. Kille、「Mail Monitoring MIB」、RFC 2789、2000年3月。
[RFC2831] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.
[RFC2831] Leach、P。およびC. Newman、「SASLメカニズムとして消化認証を使用」、RFC 2831、2000年5月。
[RFC2849] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000.
[RFC2849] Good、G。、「LDAPデータインターチェンジ形式（LDIF） - 技術仕様」、RFC 2849、2000年6月。
[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[RFC4422] Melnikov、A。およびK. Zeilenga、「Simple Authentication and Security Layer（SASL）」、RFC 4422、2006年6月。
[RFC4515] Smith, M. and T. Howes, "Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters", RFC 4515, June 2006.
[RFC4515] Smith、M。およびT. Howes、「Lightweight Directory Access Protocol（LDAP）：検索フィルターの文字列表現」、RFC 4515、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。、「Internet Assigned Numbers Authority（IANA）Lightweight Directory Access Protocol（LDAP）の考慮事項」、BCP 64、RFC 4520、2006年6月。
In this section, we will describe a fictional DUA that provides one service, called the "email" service. This service would be similar to an email client that uses an LDAP directory to discover email addresses based on a textual representation of the recipient's colloquial name.
このセクションでは、「電子メール」サービスと呼ばれる1つのサービスを提供する架空のDUAについて説明します。このサービスは、LDAPディレクトリを使用して、受信者の口語名のテキスト表現に基づいて電子メールアドレスを発見するメールクライアントに似ています。
This email service is defined by default to expect that users with email addresses will be of the "inetOrgPerson" object class type [RFC2789]. And by default, the "email" service expects the colloquial name to be stored in the "cn" attribute, while it expects the email address to be stored in the "mail" attribute (as one would expect as defined by the inetOrgPerson object class).
この電子メールサービスは、デフォルトで、電子メールアドレスを持つユーザーが「inetorgperson」オブジェクトクラスタイプ[RFC2789]のユーザーになることを期待するように定義されています。デフォルトでは、「電子メール」サービスは、口語名が「CN」属性に保存されることを期待していますが、電子メールアドレスが「メール」属性に保存されることを期待しています（InetORGPersonオブジェクトクラスで定義されていると予想されるように）。
As a special feature, the "email" service will perform a special type of attribute mapping when performing searches. If the "cn" attribute has been mapped to two or more attributes, the "email" service will parse the requested search string and map each whitespace-separated token into the mapped attributes, respectively.
特別な機能として、「電子メール」サービスは、検索を実行するときに特別なタイプの属性マッピングを実行します。「CN」属性が2つ以上の属性にマッピングされている場合、「電子メール」サービスは、要求された検索文字列を解析し、それぞれ各白文化されたトークンをマッピングしてマッピングされた属性にマッピングします。
The default search filter for the "email" service is "(objectclass=inetOrgPerson)". The email service also defines that when it performs a name-to-address discovery, it will wrap the search filter inside a complex search filter as follows:
「電子メール」サービスのデフォルトの検索フィルターは「（ObjectClass = InetorgPerson）」です。電子メールサービスは、名前からアドレスの発見を実行すると、次のように複雑な検索フィルター内で検索フィルターをラップすることも定義しています。
(&(<filter>)(cn~=<name string>))
Or, if "cn" has been mapped to multiple attributes, that wrapping would appear as follows:
または、「CN」が複数の属性にマッピングされている場合、そのラッピングは次のように表示されます。
(&(<filter>)(attr1~=<token1>)(attr2~=<token2>)...)
The below examples show how the "email" service builds its search requests, based on the defined profile. In all cases, the defaultSearchBase is "o=airius.com", and the defaultSearchScope is undefined.
以下の例は、「電子メール」サービスが定義されたプロファイルに基づいて検索要求をどのように構築するかを示しています。すべての場合において、DefaultSearchBaseは「O = Airius.com」であり、DefaultSearchScopeは未定義です。
In addition, for all examples, we assume that the "email" service has been requested to discover the email address for "Jane Hernandez".
さらに、すべての例について、「電子メール」サービスが「Jane Hernandez」の電子メールアドレスを発見するように要求されていると想定しています。
Example 1:
例1：
serviceSearchDescriptor: email:"ou=marketing,"
base: ou=marketing,o=airius.com scope: sub filter: (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez)) Example 2:
ベース：ou =マーケティング、o = airius.comスコープ：サブフィルター：（＆（objectclass = inetorgperson）（cn〜 = jane hernandez））例2：
serviceSearchDescriptor: email:"ou=marketing,"?one?
(&(objectclass=inetOrgPerson)(c=us))
attributeMap: email:cn=2.5.4.42 sn
Note: 2.5.4.42 is the OID that represents the "givenName" attribute.
注：2.5.4.42は、「与えられた」属性を表すOIDです。
In this example, the email service performs <name string> parsing as described above to generate a complex search filter. The above example results in one search.
この例では、電子メールサービスは、上記のように<Name String>解析を実行して、複雑な検索フィルターを生成します。上記の例では、1回の検索が表示されます。
base: ou=marketing,o=airius.com
scope: one
filter: (&(&(objectclass=inetOrgPerson)(c=us))
(2.5.4.42~=Jane)(sn~=Hernandez))
Example 3:
例3：
serviceSearchDescriptor: email:ou=marketing,"?base
attributeMap: email:cn=name
This example is invalid, because either the quote should have been escaped, or there should have been a leading quote.
この例は無効です。なぜなら、引用が逃げられたはずだったか、主要な引用があるべきだったからです。
Example 4:
例4：
serviceSearchDescriptor: email:ou=\\mar\\\\keting,\\"?base
attributeMap: email:cn=name
base: ou=\\mar\\keting,"
scope: base
filter (&(objectclass=inetOrgPerson)(name~=Jane Hernandez))
Example 5:
例5：
serviceSearchDescriptor: email:ou="marketing",o=supercom
This example is invalid, since the quote was not a leading quote, and thus should have been escaped.
この例は無効であり、引用は主要な引用ではなかったため、逃げるべきだったからです。
Example 6:
例6：
serviceSearchDescriptor: email:??(&(objectclass=person)
(ou=Org1 \\\\(temporary\\\\)))
base: o=airius.com
scope: sub
filter: (&((&(objectclass=person)(ou=Org1 \\(Temporary\\)))
(cn~=Jane Henderson)))
Example 7:
例7：
serviceSearchDescriptor: email:"ou=funny?org,"
base: ou=funny?org,o=airius.com
scope: sub
filter (&(objectclass=inetOrgPerson)(cn~=Jane Hernandez))
Authors' Addresses
著者のアドレス
Bob Neal-Joslin (editor) Hewlett-Packard Company 19420 Homestead RD M/S 4029 Cupertino, CA 95014 US
Bob Neal-Joslin（編集者）Hewlett-Packard Company 19420 HomeStead RD M/S 4029 Cupertino、CA 95014 US
Phone: +1 408 447 3044
EMail: bob_joslin@hp.com
URI: http://www.hp.com
Luke Howard PADL Software Pty. Ltd. PO Box 59 Central Park, Vic 3145 AU
Luke Howard Padl SoftwarePty。Ltd。PO Box 59 Central Park、Vic 3145 AU
EMail: lukeh@padl.com
URI: http://www.padl.com
Morteza Ansari Infoblox 475 Potrero Avenue Sunnyvale, CA 94085 US
Morteza Ansari Infoblox 475 Potrero Avenue Sunnyvale、CA 94085 US
Phone: +1 408 716 4300
EMail: morteza@infoblox.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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は、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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 currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。