RFC3296 日本語訳

Network Working Group                                        K. Zeilenga
Request for Comments: 3296                           OpenLDAP Foundation
Category: Standards Track                                      July 2002

Zeilengaがコメントのために要求するワーキンググループK.をネットワークでつないでください: 3296年のOpenLDAP財団カテゴリ: 標準化過程2002年7月

                    Named Subordinate References in
        Lightweight Directory Access Protocol (LDAP) Directories

ライトウェイト・ディレクトリ・アクセス・プロトコル(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 (2002).  All Rights Reserved.

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

Abstract

要約

   This document details schema and protocol elements for representing
   and managing named subordinate references in Lightweight Directory
   Access Protocol (LDAP) Directories.

表すのと管理のためのこのドキュメント詳細図式とプロトコル要素はライトウェイト・ディレクトリ・アクセス・プロトコル(LDAP)における下位参照をディレクトリと命名しました。

Conventions

コンベンション

   Schema definitions are provided using LDAPv3 description formats
   [RFC2252].  Definitions provided here are formatted (line wrapped)
   for readability.

LDAPv3記述形式[RFC2252]を使用することで図式定義を提供します。 ここに提供された定義は読み易さのためにフォーマットされます(包装された系列)。

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" used in
   this document are to be interpreted as described in BCP 14 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「」 「5月」、「推薦され」て、および中古の「任意」のコネはBCP14[RFC2119]で説明されるように解釈しないべきであるこれが、記録することですか?

1.  Background and Intended Usage

1. バックグラウンドと意図している用法

   The broadening of interest in LDAP (Lightweight Directory Access
   Protocol) [RFC2251] directories beyond their use as front ends to
   X.500 [X.500] directories has created a need to represent knowledge
   information in a more general way.  Knowledge information is
   information about one or more servers maintained in another server,
   used to link servers and services together.

X.500[X.500]ディレクトリの前の端としての彼らの使用を超えたLDAP(ライトウェイト・ディレクトリ・アクセス・プロトコル)[RFC2251]ディレクトリにおける興味がある広くなるのは、より一般的な方法で知識情報を表す必要性を作成しました。 知識情報はおよそ1つ以上のサーバがサーバとサービスを結びつけるのに使用される別のサーバで保守した情報です。

   This document details schema and protocol elements for representing
   and manipulating named subordinate references in LDAP directories.  A
   referral object is used to hold subordinate reference information in

表すのと操りのためのこのドキュメント詳細図式とプロトコル要素はLDAPの下位参照をディレクトリと命名しました。 紹介オブジェクトは、下位参照情報を抑制するのに使用されます。

Zeilenga                    Standards Track                     [Page 1]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002

ディレクトリ2002年7月にLDAPの下位参照といったZeilenga標準化過程[1ページ]RFC3296

   the directory.  These referral objects hold one or more URIs
   [RFC2396] contained in values of the ref attribute type and are used
   to generate protocol referrals and continuations.

ディレクトリ。 これらの紹介オブジェクトは、1つ以上のURI[RFC2396]が審判の属性タイプの値に含まれているままにし、プロトコル紹介と続刊を生成するのに使用されます。

   A control, ManageDsaIT, is defined to allow manipulation of referral
   and other special objects as normal objects.  As the name of control
   implies, it is intended to be analogous to the ManageDsaIT service
   option described in X.511(97) [X.511].

コントロール(ManageDsaIT)は、標準が反対するように紹介と他の特別なオブジェクトの操作を許すために定義されます。 コントロールの名前が含意するように、X.511(97)[X.511]で説明されたManageDsaITサービスオプションに類似しているのは意図しています。

   Other forms of knowledge information are not detailed by this
   document.  These forms may be described in subsequent documents.

知識情報の他の書式はこのドキュメントによって詳しく述べられません。 これらのフォームはその後のドキュメントで説明されるかもしれません。

   This document details subordinate referral processing requirements
   for servers.  This document does not describe protocol syntax and
   semantics.  This is detailed in RFC 2251 [RFC2251].

このドキュメントはサーバのために下位の紹介処理所要を詳しく述べます。 このドキュメントはプロトコル構文と意味論について説明しません。 これはRFC2251[RFC2251]で詳細です。

   This document does not detail use of subordinate knowledge references
   to support replicated environments nor distributed operations (e.g.,
   chaining of operations from one server to other servers).

このドキュメントはどんな模写された環境をサポートする下位の知識参照の詳細使用も分配された操作(例えば、操作の1つのサーバから他のサーバまでの推論)もしません。

2.  Schema

2. 図式

2.1.  The referral Object Class

2.1. 紹介Object Class

   A referral object is a directory entry whose structural object class
   is (or is derived from) the referral object class.

または、紹介オブジェクトが構造的なオブジェクトのクラスがあるディレクトリエントリである、(派生する、)、紹介オブジェクトのクラス。

      ( 2.16.840.1.113730.3.2.6
          NAME 'referral'
          DESC 'named subordinate reference object'
          STRUCTURAL
          MUST ref )

(2.16.840.1.113730.3.2.6NAME'紹介'DESC'命名された下位参照オブジェクト'STRUCTURAL MUST審判)

   The referral object class is a structural object class used to
   represent a subordinate reference in the directory.  The referral
   object class SHOULD be used in conjunction with the extensibleObject
   object class to support the naming attributes used in the entry's
   Distinguished Name (DN) [RFC2253].

紹介オブジェクトのクラスはディレクトリにおける下位参照を表すのに使用される構造的なオブジェクトのクラスです。 紹介オブジェクトはSHOULDを分類します。extensibleObjectオブジェクトのクラスに関連して使用されて、命名がエントリーのDistinguished Name(DN)[RFC2253]で使用される属性であるとサポートしてください。

   Referral objects are normally instantiated at DSEs immediately
   subordinate to object entries within a naming context held by the
   DSA.  Referral objects are analogous to X.500 subordinate knowledge
   (subr) DSEs [X.501].

通常、紹介オブジェクトはDSAによって保持された命名文脈の中にすぐにオブジェクトエントリーへの下位のDSEsに例示されます。 紹介オブジェクトはX.500の下位の知識(subr)DSEs[X.501]に類似しています。

Zeilenga                    Standards Track                     [Page 2]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002

ディレクトリ2002年7月にLDAPの下位参照といったZeilenga標準化過程[2ページ]RFC3296

   In the presence of a ManageDsaIT control, referral objects are
   treated as normal entries as described in section 3.  Note that the
   ref attribute is operational and will only be returned in a search
   entry response when requested.

ManageDsaITコントロールがあるとき、紹介オブジェクトはセクション3で説明されるように通常のエントリーとして扱われます。 審判属性が操作上であり、要求されると検索エントリー応答で返されるだけであることに注意してください。

   In the absence of a ManageDsaIT control, the content of referral
   objects are used to construct referrals and search references as
   described in Section 4 and, as such, the referral entries are not
   themselves visible to clients.

ManageDsaITコントロール、オブジェクトが使用されている紹介の内容がないとき、クライアントにとって、セクション4とそういうものとして紹介エントリーで説明される構造物紹介と検索参照は自分たちで目に見えません。

2.2  The ref Attribute Type

2.2 審判Attribute Type

      ( 2.16.840.1.113730.3.1.34
          NAME 'ref'
          DESC 'named reference - a labeledURI'
          EQUALITY caseExactMatch
          SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
          USAGE distributedOperation )

('審判'DESC'は参照を命名しました--labeledURI'という2.16.840.1.113730.3.1.34NAME EQUALITY caseExactMatch SYNTAX1.3.6、.1、.4、.1、.1466、.115、.121、.1、.15USAGE distributedOperation)

   The ref attribute type has directoryString syntax and is case
   sensitive.  The ref attribute is multi-valued.  Values placed in the
   attribute MUST conform to the specification given for the labeledURI
   attribute [RFC2079].  The labeledURI specification defines a format
   that is a URI, optionally followed by whitespace and a label.  This
   document does not make use of the label portion of the syntax.
   Future documents MAY enable new functionality by imposing additional
   structure on the label portion of the syntax as it appears in the ref
   attribute.

審判の属性タイプは、directoryString構文を持って、大文字と小文字を区別しています。 審判属性はマルチ評価されています。 属性に置かれた値はlabeledURI属性[RFC2079]のために与えられた仕様に従わなければなりません。 labeledURI仕様は空白とラベルがURIであると任意にいうことになった書式を定義します。 このドキュメントは構文のラベル部分を利用しません。 将来のドキュメントは、審判属性に現れるように構文のラベル部分に追加構造を課すことによって、新しい機能性を可能にするかもしれません。

   If the URI contained in a ref attribute value refers to a LDAP
   [RFC2251] server, it MUST be in the form of a LDAP URL [RFC2255].
   The LDAP URL SHOULD NOT contain an explicit scope specifier, filter,
   attribute description list, or any extensions.  The LDAP URL SHOULD
   contain a non-empty DN.  The handling of LDAP URLs with absent or
   empty DN parts or with explicit scope specifier is not defined by
   this specification.

審判属性値に含まれたURIがLDAP[RFC2251]サーバを示すなら、それはLDAP URL[RFC2255]の形にあるに違いありません。 LDAP URL SHOULD NOTは明白な範囲特許説明書の作成書、フィルタ、属性記述リスト、またはどんな拡大も含んでいます。 LDAP URL SHOULDは非空のDNを含んでいます。 休んでいるか空のDN部分か明白な範囲特許説明書の作成書とのLDAP URLの取り扱いはこの仕様で定義されません。

   Other URI schemes MAY be used so long as all operations returning
   referrals based upon the value could be performed.  This document
   does not detail use of non-LDAP URIs.  This is left to future
   specifications.

戻っている紹介が値に基礎づけたすべての操作を実行できた限り、他のURI体系は使用されるかもしれません。 このドキュメントは非LDAP URIの使用を詳しく述べません。 これは将来の仕様に残されます。

   The referential integrity of the URI SHOULD NOT be validated by the
   server holding or returning the URI (whether as a value of the
   attribute or as part of a referral result or search reference
   response).

サーバ把持で有効にされるか、またはURIを返すURI SHOULD NOT(属性の値か紹介結果か検索参照応答の一部にかかわらず)の参考の保全。

Zeilenga                    Standards Track                     [Page 3]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002

ディレクトリ2002年7月にLDAPの下位参照といったZeilenga標準化過程[3ページ]RFC3296

   When returning a referral result or search continuation, the server
   MUST NOT return the separator or label portions of the attribute
   values as part of the reference.  When the attribute contains
   multiple values, the URI part of each value is used to construct the
   referral result or search continuation.

紹介結果か検索継続を返すとき、サーバは参照の一部として属性値の分離符かラベル部分を返してはいけません。 属性が複数の値を含むとき、それぞれの価値のURI一部分が、紹介結果か検索継続を構成するのに使用されます。

   The ref attribute values SHOULD NOT be used as a relative name-
   component of an entry's DN [RFC2253].

審判は値のSHOULD NOTを結果と考えます。エントリーのDN[RFC2253]の相対的な名前の部品として、使用されてください。

   This document uses the ref attribute in conjunction with the referral
   object class to represent subordinate references.  The ref attribute
   may be used for other purposes as defined by other documents.

このドキュメントは、下位参照を表すのに紹介オブジェクトのクラスに関連して審判属性を使用します。 審判属性は他の目的に他のドキュメントによって定義されるように使用されるかもしれません。

3.  The ManageDsaIT Control

3. ManageDsaITコントロール

   The client may provide the ManageDsaIT control with an operation to
   indicate that the operation is intended to manage objects within the
   DSA (server) Information Tree.  The control causes Directory-specific
   entries (DSEs), regardless of type, to be treated as normal entries
   allowing clients to interrogate and update these entries using LDAP
   operations.

クライアントは、操作がDSA(サーバ)情報Treeの中でオブジェクトを管理することを意図するのを示すためにManageDsaITコントロールに操作を提供するかもしれません。 コントロールはディレクトリ特有のエントリー(DSEs)を引き起こします、タイプにかかわらず、クライアントがこれらのエントリーを査問して、LDAPを使用することでアップデートする通常のエントリーとして扱われた操作に。

   A client MAY specify the following control when issuing an add,
   compare, delete, modify, modifyDN, search request or an extended
   operation for which the control is defined.

発行するとき、クライアントが以下のコントロールを指定するかもしれない、加えてくださいといって、比較してください、削除、変更、コントロールが定義されるmodifyDN、検索要求または拡大手術。

   The control type is 2.16.840.1.113730.3.4.2.  The control criticality
   may be TRUE or, if FALSE, absent.  The control value is absent.

コントロールタイプはそうです。2.16 .840 .1 .113730 .3 .4 .2。 コントロールの臨界は、TRUEかFALSEであるなら欠けているかもしれません。 コントロール値は欠けています。

   When the control is present in the request, the server SHALL NOT
   generate a referral or continuation reference based upon information
   held in referral objects and instead SHALL treat the referral object
   as a normal entry.  The server, however, is still free to return
   referrals for other reasons.  When not present, referral objects
   SHALL be handled as described above.

コントロールが要求に存在しているとき、サーバSHALL NOTは、紹介か継続が紹介オブジェクトに保持された情報に基づく参照であると生成します、そして、代わりに、SHALLは紹介オブジェクトをノーマルエントリとして扱います。 しかしながら、サーバは他の理由でまだ無料で紹介を返すことができます。 現在の紹介オブジェクトでないSHALLであるときには、上で説明されるように、扱われてください。

   The control MAY cause other objects to be treated as normal entries
   as defined by subsequent documents.

コントロールで、その後のドキュメントによって定義されるように通常のエントリーとして他のオブジェクトを扱うかもしれません。

4.  Named Subordinate References

4. 下位参照と命名されます。

   A named subordinate reference is constructed by instantiating a
   referral object in the referencing server with ref attribute values
   which point to the corresponding subtree maintained in the referenced
   server.  In general, the name of the referral object is the same as
   the referenced object and this referenced object is a context prefix
   [X.501].

命名された下位参照は、参照をつけられたサーバで維持された対応する下位木を示す審判属性値で参照箇所サーバで紹介オブジェクトを例示することによって、構成されます。一般に、紹介オブジェクトの名前は参照をつけられたオブジェクトと同じです、そして、この参照をつけられた目的は文脈接頭語[X.501]です。

Zeilenga                    Standards Track                     [Page 4]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002

ディレクトリ2002年7月にLDAPの下位参照といったZeilenga標準化過程[4ページ]RFC3296

   That is, if server A holds "DC=example,DC=net" and server B holds
   "DC=sub,DC=example,DC=net", server A may contain a referral object
   named "DC=sub,DC=example,DC=net" which contains a ref attribute with
   value of "ldap://B/DC=sub,DC=example,DC=net".

すなわち、サーバAが「DCは例と等しいです、DC=ネット」を保持して、サーバBが「DCは潜水艦と等しいです、DC=例、DC=ネット」を保持するなら、サーバAは「ldap://B/DCが潜水艦と等しいです、DC=例、DC=ネット」の値がある審判属性を含む「DCは潜水艦と等しいです、DC=例、DC=ネット」という紹介オブジェクトを含むかもしれません。

      dn: DC=sub,DC=example,DC=net
      dc: sub
      ref: ldap://B/DC=sub,DC=example,DC=net
      objectClass: referral
      objectClass: extensibleObject

dn: DCは潜水艦と等しく、DCは例と等しく、DCはネットのdcと等しいです: 潜水艦審判: ldap://B/DCは潜水艦と等しく、DCは例と等しく、DCはネットのobjectClassと等しいです: 紹介objectClass: extensibleObject

   Typically the DN of the referral object and the DN of the object in
   the referenced server are the same.

紹介オブジェクトのDNと参照をつけられたサーバのオブジェクトのDNは通常、同じです。

   If the ref attribute has multiple values, all the DNs contained
   within the LDAP URLs SHOULD be equivalent.  Administrators SHOULD
   avoid configuring naming loops using referrals.

審判属性に値、すべての複数のDNsがあるなら、LDAP URL SHOULDの中に含まれて、同等であってください。 紹介を使用すると輪を命名しながら、管理者SHOULDは、構成するのを避けます。

   Named references MUST be treated as normal entries if the request
   includes the ManageDsaIT control as described in section 3.

要求がセクション3で説明されるようにManageDsaITコントロールを含んでいるなら、通常のエントリーとして命名された参照を扱わなければなりません。

5.  Scenarios

5. シナリオ

   The following sections contain specifications of how referral objects
   should be used in different scenarios followed by examples that
   illustrate that usage.  The scenarios described here consist of
   referral object handling when finding target of a non-search
   operation, when finding the base of a search operation, and when
   generating search references.  Lastly, other operation processing
   considerations are presented.

以下のセクションは紹介オブジェクトがその用法を例証する例があとに続いた異なったシナリオでどう使用されるべきであるかに関する仕様を含みます。 索敵行動、およびいつに関するベースを見つけるかときの非索敵行動の目標が検索参照を生成しているのがわかるとき、ここで説明されたシナリオは紹介オブジェクト取り扱いから成ります。 最後に、他の操作処理問題は提示されます。

   It is to be noted that, in this document, a search operation is
   conceptually divided into two distinct, sequential phases: (1)
   finding the base object where the search is to begin, and (2)
   performing the search itself.  The first phase is similar to, but not
   the same as, finding the target of a non-search operation.

索敵行動がこのドキュメントで概念的に2つの異なって、連続したフェーズに分割されることに注意されることになっています: (1) 検索が始まることになっているベースオブジェクト、および(2)が検索自体を実行しているのがわかります。 しかし、第1段階は、同様で、同じで、見つけていません。非索敵行動の目標。

   It should also be noted that the ref attribute may have multiple
   values and, where these sections refer to a single ref attribute
   value, multiple ref attribute values may be substituted and SHOULD be
   processed and returned (in any order) as a group in a referral or
   search reference in the same way as described for a single ref
   attribute value.

また、独身の審判のために述べられる同じ方法による紹介か検索参照におけるグループが値を結果と考えるとき、複数の値が審判属性にあるかもしれなくて、これらのセクションがただ一つの審判属性値を呼ぶところに、複数の審判属性値を代入するかもしれなくて、SHOULDが処理されて、(順不同に)戻ったことに注意されるべきです。

   Search references returned for a given request may be returned in any
   order.

順不同に与えられた要求のために返された検索参照を返すかもしれません。

Zeilenga                    Standards Track                     [Page 5]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002

ディレクトリ2002年7月にLDAPの下位参照といったZeilenga標準化過程[5ページ]RFC3296

5.1.  Example Configuration

5.1. 例の構成

   For example, suppose the contacted server (hosta) holds the entry
   "O=MNN,C=WW" and the entry "CN=Manager,O=MNN,C=WW" and the following
   referral objects:

例えば、連絡されたサーバ(ホスタ)船倉エントリー「O=MNN、C=WW」とエントリーが「CNはマネージャ(O=MNN)C=WWと等しく」て、以下の紹介オブジェクトであると仮定してください:

      dn: OU=People,O=MNN,C=WW
      ou: People
      ref: ldap://hostb/OU=People,O=MNN,C=US
      ref: ldap://hostc/OU=People,O=MNN,C=US
      objectClass: referral
      objectClass: extensibleObject

dn: OUは人々、O=MNNと等しく、CはWW ouと等しいです: 人々審判: ldap://hostb/OUは人々、O=MNNと等しく、Cは米国の審判と等しいです: ldap://hostc/OUは人々、O=MNN、C=米国objectClassと等しいです: 紹介objectClass: extensibleObject

      dn: OU=Roles,O=MNN,C=WW
      ou: Roles
      ref: ldap://hostd/OU=Roles,O=MNN,C=WW
      objectClass: referral
      objectClass: extensibleObject

dn: O=MNN、OUは役割と等しく、CはWW ouと等しいです: 役割の審判: O=MNN、ldap://hostd/OUは役割と等しく、CはWW objectClassと等しいです: 紹介objectClass: extensibleObject

   The first referral object provides the server with the knowledge that
   subtree "OU=People,O=MNN,C=WW" is held by hostb and hostc (e.g., one
   is the master and the other a shadow).  The second referral object
   provides the server with the knowledge that the subtree
   "OU=Roles,O=MNN,C=WW" is held by hostd.

オブジェクトがその下位木「OUは人々と等しいです、O=MNN、C=WW」という知識があるサーバを提供する最初の紹介はhostbとhostcによって保持されます(例えば、1はマスターであり、もう片方が影です)。 2番目の紹介オブジェクトが知識があるサーバにそれを提供する、下位木、「O=MNN、OUは役割と等しく、CはWWと等しいこと」がhostdによって保持されます。

   Also, in the context of this document, the "nearest naming context"
   means the deepest context which the object is within.  That is, if
   the object is within multiple naming contexts, the nearest naming
   context is the one which is subordinate to all other naming contexts
   the object is within.

また、このドキュメントの文脈では、「最も近い命名文脈」はオブジェクトが中のそうである中で最も深い文脈を意味します。 すなわち、複数の命名文脈の中にオブジェクトがあるなら、最も近い命名文脈はオブジェクトがある他のすべての命名文脈に下位であることのものです。

5.2.  Target Object Considerations

5.2. 目標オブジェクト問題

   This section details referral handling for add, compare, delete,
   modify, and modify DN operations.  If the client requests any of
   these operations, there are four cases that the server must handle
   with respect to the target object.

このセクションが紹介取り扱いを詳しく述べる、DN操作を加えて、比較して、削除して、変更して、変更してください。 クライアントがこれらの操作のどれかを要求するなら、サーバが目標オブジェクトに関して扱わなければならない4つのケースがあります。

   The DN part MUST be modified such that it refers to the appropriate
   target in the referenced server (as detailed below).  Even where the
   DN to be returned is the same as the target DN, the DN part SHOULD
   NOT be trimmed.

DN部分を変更しなければならないので、それは参照をつけられたサーバで適切な目標を示します(以下で詳しく述べられるように)。 返されるべきDNが同じでさえあるところで、目標DN、DNがSHOULD NOTを分けるように整えられてください。

   In cases where the URI to be returned is a LDAP URL, the server
   SHOULD trim any present scope, filter, or attribute list from the URI
   before returning it.  Critical extensions MUST NOT be trimmed or
   modified.

返されるURIがLDAP URLである場合では、それを返す前に、サーバSHOULDはURIからのどんな現在の範囲、フィルタ、または属性リストも整えます。 重要な拡大を、整えられてはいけないか、変更してはいけません。

Zeilenga                    Standards Track                     [Page 6]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002

ディレクトリ2002年7月にLDAPの下位参照といったZeilenga標準化過程[6ページ]RFC3296

   Case 1: The target object is not held by the server and is not within
      or subordinate to any naming context nor subordinate to any
      referral object held by the server.

ケース1: 目標オブジェクトが、サーバによって保持されないで、また中になかったか、またはどんな命名文脈への部下とどんな紹介オブジェクトへの部下もサーバを固守しました。

      The server SHOULD process the request normally as appropriate for
      a non-existent base which is not within any naming context of the
      server (generally return noSuchObject or a referral based upon
      superior knowledge reference information).  This document does not
      detail management or processing of superior knowledge reference
      information.

サーバSHOULDは通常適宜サーバ(優れた知識参考情報に基づく一般にリターンnoSuchObjectか紹介)のどんな命名文脈の中にもない実在しないベースに要求を処理します。 このドキュメントは優れた知識参考情報の管理か処理について詳述しません。

   Case 2: The target object is held by the server and is a referral
      object.

ケース2: 目標目的は、サーバによって保持されて、紹介オブジェクトです。

      The server SHOULD return the URI value contained in the ref
      attribute of the referral object appropriately modified as
      described above.

サーバSHOULDは上で説明されるように適切に変更された紹介オブジェクトの審判属性に含まれたURI値を返します。

   Example: If the client issues a modify request for the target object
      of "OU=People,O=MNN,c=WW", the server will return:

例: クライアントがaを発行するなら、「OUは人々、O=MNN、c=WWと等しいこと」の目標オブジェクトのために要求を変更してください、そして、サーバは戻るでしょう:

         ModifyResponse (referral) {
             ldap://hostb/OU=People,O=MNN,C=WW
             ldap://hostc/OU=People,O=MNN,C=WW
         }

ModifyResponse(紹介)ldap://hostb/OU=人々(O=MNN、C=WW ldap://hostc/OU=人々O=MNN、C)はWWと等しいです。

   Case 3: The target object is not held by the server, but the nearest
      naming context contains no referral object which the target object
      is subordinate to.

ケース3: 目標オブジェクトはサーバによって持たれていませんが、最も近い命名文脈は目標オブジェクトが下位である紹介オブジェクトを全く含んでいません。

      If the nearest naming context contains no referral object which
      the target is subordinate to, the server SHOULD process the
      request as appropriate for a nonexistent target (generally return
      noSuchObject).

最も近い命名文脈が目標が下位である紹介オブジェクトを全く含んでいないなら、サーバSHOULDは実在しない目標のために適宜要求を処理します(一般に、noSuchObjectを返してください)。

   Case 4: The target object is not held by the server, but the nearest
      naming context contains a referral object which the target object
      is subordinate to.

ケース4: 目標オブジェクトはサーバによって持たれていませんが、最も近い命名文脈は目標オブジェクトが下位である紹介オブジェクトを含んでいます。

      If a client requests an operation for which the target object is
      not held by the server and the nearest naming context contains a
      referral object which the target object is subordinate to, the
      server SHOULD return a referral response constructed from the URI
      portion of the ref value of the referral object.

クライアントが、目標オブジェクトがサーバと最も近い命名文脈によって持たれていない操作が目標オブジェクトが下位である紹介オブジェクトを含むよう要求するなら、サーバSHOULDは紹介オブジェクトの審判価値のURI部分から構成された紹介応答を返します。

Zeilenga                    Standards Track                     [Page 7]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002

ディレクトリ2002年7月にLDAPの下位参照といったZeilenga標準化過程[7ページ]RFC3296

   Example: If the client issues an add request where the target object
      has a DN of "CN=Manager,OU=Roles,O=MNN,C=WW", the server will
      return:

例: クライアント問題である、目標オブジェクトが「CNはマネージャ、OU=役割O=MNN、C=WWと等しいこと」のDNを持っているところに、サーバが戻るよう要求するように言い足してください:

         AddResponse (referral) {
             ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW"
         }

AddResponse(紹介)「ldap://hostd/CNがマネージャ、OU=役割O=MNN、C=WWと等しい、」

      Note that the DN part of the LDAP URL is modified such that it
      refers to the appropriate entry in the referenced server.

LDAP URLのDN部分が変更されているので参照をつけられたサーバにおける適切なエントリーについて言及することに注意してください。

5.3.  Base Object Considerations

5.3. 基地のオブジェクト問題

   This section details referral handling for base object processing
   within search operations.  Like target object considerations for
   non-search operations, there are the four cases.

このセクションは索敵行動の中でベースオブジェクト処理のための紹介取り扱いを詳しく述べます。 非索敵行動のための目標オブジェクト問題のように、4つのケースがあります。

   In cases where the URI to be returned is a LDAP URL, the server MUST
   provide an explicit scope specifier from the LDAP URL prior to
   returning it.  In addition, the DN part MUST be modified such that it
   refers to the appropriate target in the referenced server (as
   detailed below).

返されるURIがLDAP URLである場合では、それを返す前に、サーバはLDAP URLから明白な範囲特許説明書の作成書を提供しなければなりません。 さらに、DN部分を変更しなければならないので、それは参照をつけられたサーバで適切な目標を示します(以下で詳しく述べられるように)。

   If aliasing dereferencing was necessary in finding the referral
   object, the DN part of the URI MUST be replaced with the base DN as
   modified by the alias dereferencing such that the return URL refers
   to the new target object per [RFC2251, 4.1.11].

エイリアシングの「反-参照をつけ」が紹介オブジェクトを見つけるのにおいて必要であったなら、URIのDN部分を変更されるとしての別名によるそのようなものにリターンURLが新しい目標オブジェクトを参照する単位「反-参照をつけ」るベースDNに取り替えなければならない、[RFC2251、4.1、.11、]

   Critical extensions MUST NOT be trimmed nor modified.

重要な拡大を、整えて、変更してはいけません。

   Case 1: The base object is not held by the server and is not within
      nor subordinate to any naming context held by the server.

ケース1: ベースオブジェクトは、サーバを中に、サーバによって保持されないで、またなくて、固守されたどんな命名文脈にも下位に置かせます。

      The server SHOULD process the request normally as appropriate for
      a non-existent base which not within any naming context of the
      server (generally return a superior referral or noSuchObject).
      This document does not detail management or processing of superior
      knowledge references.

サーバのどんな命名文脈の中ではなくも実在しないベースにどれを当てるかとき、通常、サーバSHOULDは要求を処理します(一般に、優れた紹介かnoSuchObjectを返してください)。 このドキュメントは優れた知識参照の管理か処理について詳述しません。

   Case 2: The base object is held by the server and is a referral
      object.

ケース2: ベース目的は、サーバによって保持されて、紹介オブジェクトです。

      The server SHOULD return the URI value contained in the ref
      attribute of the referral object appropriately modified as
      described above.

サーバSHOULDは上で説明されるように適切に変更された紹介オブジェクトの審判属性に含まれたURI値を返します。

Zeilenga                    Standards Track                     [Page 8]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002

ディレクトリ2002年7月にLDAPの下位参照といったZeilenga標準化過程[8ページ]RFC3296

   Example: If the client issues a subtree search in which the base
      object is "OU=Roles,O=MNN,C=WW", the server will return

例: クライアントが「O=MNN、OUは役割と等しく、CはWWと等しいこと」をベースオブジェクトがある下位木検索に発行すると、サーバが戻るでしょう。

         SearchResultDone (referral) {
             ldap://hostd/OU=Roles,O=MNN,C=WW??sub
         }

SearchResultDone(紹介)O=MNN、ldap://hostd/OUは役割と等しく、CはWW?潜水艦と等しいです。

      If the client were to issue a base or oneLevel search instead of
      subtree, the returned LDAP URL would explicitly specify "base" or
      "one", respectively, instead of "sub".

クライアントが下位木の代わりにベースかoneLevel検索を産出するなら、返されたLDAP URLは「潜水艦」の代わりに明らかにそれぞれ「ベース」か「1つ」を指定するでしょうに。

   Case 3: The base object is not held by the server, but the nearest
      naming context contains no referral object which the base object
      is subordinate to.

ケース3: ベースオブジェクトはサーバによって持たれていませんが、最も近い命名文脈はベースオブジェクトが下位である紹介オブジェクトを全く含んでいません。

      If the nearest naming context contains no referral object which
      the base is subordinate to, the request SHOULD be processed
      normally as appropriate for a nonexistent base (generally return
      noSuchObject).

最も近いなら、文脈を命名する場合、ベースが下位である紹介オブジェクトは全く含んでいません、要求SHOULD。通常、適宜実在しないベースに処理されてください(一般に、noSuchObjectを返してください)。

   Case 4: The base object is not held by the server, but the nearest
      naming context contains a referral object which the base object is
      subordinate to.

ケース4: ベースオブジェクトはサーバによって持たれていませんが、最も近い命名文脈はベースオブジェクトが下位である紹介オブジェクトを含んでいます。

      If a client requests an operation for which the target object is
      not held by the server and the nearest naming context contains a
      referral object which the target object is subordinate to, the
      server SHOULD return a referral response which is constructed from
      the URI portion of the ref value of the referral object.

クライアントが、目標オブジェクトがサーバと最も近い命名文脈によって持たれていない操作が目標オブジェクトが下位である紹介オブジェクトを含むよう要求するなら、サーバSHOULDは紹介オブジェクトの審判価値のURI部分から構成される紹介応答を返します。

   Example: If the client issues a base search request for
      "CN=Manager,OU=Roles,O=MNN,C=WW", the server will return

例: クライアントが「CNはマネージャ、OU=役割O=MNN、C=WWと等しいこと」を求めるベース検索要求を発行すると、サーバが戻るでしょう。

         SearchResultDone (referral) {
             ldap://hostd/CN=Manager,OU=Roles,O=MNN,C=WW??base"
         }

SearchResultDone(紹介)「ldap://hostd/CNがWW?マネージャ、OU=役割O=MNN、C=ベースと等しい、」

      If the client were to issue a subtree or oneLevel search instead
      of subtree, the returned LDAP URL would explicitly specify "sub"
      or "one", respectively, instead of "base".

クライアントが下位木の代わりに下位木かoneLevel検索を発行するなら、返されたLDAP URLは「ベース」の代わりに明らかにそれぞれ「潜水艦」か「1つ」を指定するでしょうに。

      Note that the DN part of the LDAP URL is modified such that it
      refers to the appropriate entry in the referenced server.

LDAP URLのDN部分が変更されているので参照をつけられたサーバにおける適切なエントリーについて言及することに注意してください。

Zeilenga                    Standards Track                     [Page 9]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002

ディレクトリ2002年7月にLDAPの下位参照といったZeilenga標準化過程[9ページ]RFC3296

5.4.  Search Continuation Considerations

5.4. 検索継続問題

   For search operations, once the base object has been found and
   determined not to be a referral object, the search may progress.  Any
   entry matching the filter and scope of the search which is not a
   referral object is returned to the client normally as described in
   [RFC2251].

索敵行動のために、ベースオブジェクトがいったん見つけられて、紹介オブジェクトでないことを決定すると、検索は進歩をするかもしれません。 通常、[RFC2251]で説明されるように紹介オブジェクトでない検索のフィルタと範囲に合っているどんなエントリーもクライアントに返します。

   For each referral object within the requested scope, regardless of
   the search filter, the server SHOULD return a SearchResultReference
   which is constructed from the URI component of values of the ref
   attribute.  If the URI component is not a LDAP URL, it should be
   returned as is.  If the LDAP URL's DN part is absent or empty, the DN
   part must be modified to contain the DN of the referral object.  If
   the URI component is a LDAP URL, the URI SHOULD be modified to add an
   explicit scope specifier.

要求された範囲の中のそれぞれの紹介オブジェクトに関しては、検索フィルタにかかわらず、サーバSHOULDは審判属性の値のURIコンポーネントから組み立てられるSearchResultReferenceを返します。 URIコンポーネントがLDAP URLでないなら、そのままでそれを返すべきです。 LDAP URL DN部分が欠けるか、または空であるなら、紹介オブジェクトのDNを含むようにDN部分を変更しなければなりません。 URIコンポーネントであるなら、明白な範囲特許説明書の作成書を加えるように変更されていて、aはLDAP URL、URI SHOULDですか?

   Subtree Example:

下位木の例:

      If a client requests a subtree search of "O=MNN,C=WW", then in
      addition to any entries within scope which match the filter, hosta
      will also return two search references as the two referral objects
      are within scope.  One possible response might be:

また、クライアントが「O=MNN、CはWWと等しいこと」の下位木検索を要求すると、範囲の中のフィルタに合っているどんなエントリーに加えて、範囲の中に2個の紹介オブジェクトがあるとき、ホスタが2つの検索参照箇所を返すでしょう。 1つの可能な応答は以下の通りです。

          SearchEntry for O=MNN,C=WW
          SearchResultReference {
              ldap://hostb/OU=People,O=MNN,C=WW??sub
              ldap://hostc/OU=People,O=MNN,C=WW??sub
          }
          SearchEntry for CN=Manager,O=MNN,C=WW
          SearchResultReference {
              ldap://hostd/OU=Roles,O=MNN,C=WW??sub
          }
          SearchResultDone (success)

O=MNNであることのSearchEntry、CがWW SearchResultReferenceと等しい、CNのためのWW?ldap://hostb/OU=人々、C=WW?O=MNN、潜水艦ldap://hostc/OU=人々O=MNN、C=潜水艦SearchEntryはマネージャ、O=MNNと等しく、C=WW SearchResultReferenceはWW?役割、O=MNN、ldap://hostd/OU=C=潜水艦SearchResultDoneです。(成功)

   One Level Example:

1つの平らな例:

      If a client requests a one level search of "O=MNN,C=WW" then, in
      addition to any entries one level below the "O=MNN,C=WW" entry
      matching the filter, the server will also return two search
      references as the two referral objects are within scope.  One
      possible sequence is shown:

また、クライアントがその時「O=MNN、CはWWと等しいこと」の1つの平らな検索を要求すると、「O=MNN、CはWWと等しい」というフィルタに合っているエントリーの下のどんなエントリー1レベルに加えて、範囲の中に2個の紹介オブジェクトがあるとき、サーバが2つの検索参照箇所を返すでしょう。 1つの可能な系列が示されます:

Zeilenga                    Standards Track                    [Page 10]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002

ディレクトリ2002年7月にLDAPの下位参照といったZeilenga標準化過程[10ページ]RFC3296

          SearchResultReference {
              ldap://hostb/OU=People,O=MNN,C=WW??base
              ldap://hostc/OU=People,O=MNN,C=WW??base
          }
          SearchEntry for CN=Manager,O=MNN,C=WW
          SearchResultReference {
              ldap://hostd/OU=Roles,O=MNN,C=WW??base
          }
          SearchResultDone (success)

SearchResultReference、CNのためのWW?ldap://hostb/OU=人々、C=WW?O=MNN、ベースldap://hostc/OU=人々O=MNN、C=ベースSearchEntryはマネージャ、O=MNNと等しく、C=WW SearchResultReferenceはWW?役割、O=MNN、ldap://hostd/OU=C=ベースSearchResultDoneです。(成功)

   Note: Unlike the examples in Section 4.5.3.1 of RFC 2251, the LDAP
      URLs returned with the SearchResultReference messages contain, as
      required by this specification, an explicit scope specifier.

以下に注意してください。 .1RFC2251、LDAP URLはSearchResultReferenceメッセージとともに帰りました。セクション4.5.3における例、必要に応じて、この仕様、明白な範囲特許説明書の作成書で、含みます。

5.6.  Other Considerations

5.6. 他の問題

   This section details processing considerations for other operations.

このセクションは他の操作のために処理問題を詳しく述べます。

5.6.1 Bind

5.6.1 ひも

   Servers SHOULD NOT return referral result code if the bind name (or
   authentication identity or authorization identity) is (or is
   subordinate to) a referral object but MAY use the knowledge
   information to process the bind request (such as in support a future
   distributed operation specification).  Where the server makes no use
   of the knowledge information, the server processes the request
   normally as appropriate for a non-existent authentication or
   authorization identity (e.g., return invalidCredentials).

または、ひもの名(または、認証のアイデンティティか承認のアイデンティティ)が返すならサーバSHOULD NOTが紹介結果コードを返す、(下位である、)、a紹介オブジェクトにもかかわらず、5月は、ひもの要求を処理するのに知識情報を使用します(あれほど同じくらい中で将来の分配された操作仕様をサポートしてください)。 サーバが知識の無駄を情報にするところでは、サーバは実在しない認証か承認のアイデンティティのために通常適宜要求を処理します(例えば、invalidCredentialsを返してください)。

5.6.2 Modify DN

5.6.2 DNを変更してください。

   If the newSuperior is a referral object or is subordinate to a
   referral object, the server SHOULD return affectsMultipleDSAs.  If
   the newRDN already exists but is a referral object, the server SHOULD
   return affectsMultipleDSAs instead of entryAlreadyExists.

newSuperiorが紹介オブジェクトであるか紹介オブジェクトに下位であるなら、サーバSHOULDはaffectsMultipleDSAsを返します。 newRDNが既に存在していますが、紹介オブジェクトであるなら、サーバSHOULDはentryAlreadyExistsの代わりにaffectsMultipleDSAsを返します。

6.  Security Considerations

6. セキュリティ問題

   This document defines mechanisms that can be used to tie LDAP (and
   other) servers together.  The information used to tie services
   together should be protected from unauthorized modification.  If the
   server topology information is not public information, it should be
   protected from unauthorized disclosure as well.

このドキュメントはLDAPを結ぶのにおいて中古の、そして、(他)のサーバであるかもしれないメカニズムを一緒に定義します。 サービスを結びつけるのに使用される情報は権限のない変更から保護されるべきです。 サーバトポロジー情報が公開情報でないなら、それはまた、不当開示から保護されるべきです。

Zeilenga                    Standards Track                    [Page 11]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002

ディレクトリ2002年7月にLDAPの下位参照といったZeilenga標準化過程[11ページ]RFC3296

7.  Acknowledgments

7. 承認

   This document borrows heavily from previous work by IETF LDAPext
   Working Group.  In particular, this document is based upon "Named
   Referral in LDAP Directories" (an expired Internet Draft) by
   Christopher Lukas, Tim Howes, Michael Roszkowski, Mark C. Smith, and
   Mark Wahl.

このドキュメントはIETF LDAPext作業部会による前の仕事から大いに借ります。 特に、このドキュメントはクリストファー・ルーカス、ティム・ハウズ、マイケルRoszkowski、マーク・C.スミス、およびマーク・ウォールが「LDAPディレクトリにおける命名された紹介」(満期のインターネットDraft)に基づいています。

8. Normative References

8. 引用規格

   [RFC2079] Smith, M., "Definition of an X.500 Attribute Type and an
             Object Class to Hold Uniform Resource Identifiers (URIs)",
             RFC 2079, January 1997.

[RFC2079]スミス、M.、「X.500の定義はUniform Resource Identifier(URI)を保持するためにタイプとオブジェクトのクラスを結果と考えます」、RFC2079、1997年1月。

   [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月。

   [RFC2253] Wahl, M., Kille, S. and T. Howes, "Lightweight Directory
             Access Protocol (v3): UTF-8 String Representation of
             Distinguished Names", RFC 2253, December 1997.

[RFC2253] ウォール、M.、Kille、S.、およびT.ハウズ、「軽量のディレクトリアクセスは(v3)について議定書の中で述べます」。 「分類名のUTF-8ストリング表現」、RFC2253、1997年12月。

   [RFC2255] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
             December, 1997.

[RFC2255] ハウズとT.とM.スミス、「LDAP URL形式」、RFC2255、1997年12月。

   [RFC2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
             Resource Identifiers (URI): Generic Syntax", RFC 2396,
             August 1998.

[RFC2396] バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。

   [X.501]   ITU-T, "The Directory: Models", X.501, 1993.

[X.501]ITU-T、「ディレクトリ:」 「モデル」、X.501、1993。

9. Informative References

9. 有益な参照

   [X.500]   ITU-T, "The Directory: Overview of Concepts, Models, and
             Services", X.500, 1993.

[X.500]ITU-T、「ディレクトリ:」 「概念の、そして、モデルの、そして、サービスの概要」、X.500、1993。

   [X.511]   ITU-T, "The Directory: Abstract Service Definition", X.500,
             1997.

[X.511]ITU-T、「ディレクトリ:」 「抽象的なサービス定義」、X.500、1997。

Zeilenga                    Standards Track                    [Page 12]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002

ディレクトリ2002年7月にLDAPの下位参照といったZeilenga標準化過程[12ページ]RFC3296

10.  Author's Address

10. 作者のアドレス

   Kurt D. Zeilenga
   OpenLDAP Foundation

カートD.Zeilenga OpenLDAP財団

   EMail: Kurt@OpenLDAP.org

メール: Kurt@OpenLDAP.org

Zeilenga                    Standards Track                    [Page 13]

RFC 3296    Named Subordinate References in LDAP Directories   July 2002

ディレクトリ2002年7月にLDAPの下位参照といったZeilenga標準化過程[13ページ]RFC3296

11.  Full Copyright Statement

11. 完全な著作権宣言文

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

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

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

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

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

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

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

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Zeilenga                    Standards Track                    [Page 14]

Zeilenga標準化過程[14ページ]