and                [0] SET OF Filter,
             or                 [1] SET OF Filter,
             not                [2] Filter,
             equalityMatch      [3] AttributeValueAssertion,
             substrings         [4] SubstringFilter,
             greaterOrEqual     [5] AttributeValueAssertion,
             lessOrEqual        [6] AttributeValueAssertion,
             present            [7] AttributeType,
             approxMatch        [8] AttributeValueAssertion
         }

     SubstringFilter
         SEQUENCE {

             type               AttributeType,
             SEQUENCE OF CHOICE {
                 initial        [0] LDAPString,
                 any            [1] LDAPString,
                 final          [2] LDAPString
             }
         }

   查找請求的參數(shù)是:

   - baseObject: 一個相對于要進行查找操作的條目的基本對象條目
   - scope: 指示要查找的范圍.該域可能的語義上的值與目錄查找操作中的范圍域的語義值是一致的.
   - derefAliases :指示在操作中別名對象該如何處理.該域可能的語義上的值按照升序的順序進行.
          neverDerefAliases:在查找或定位查找的基本對象時不丟棄別名引用
          derefInSearching: 在查找過程中,丟棄基本對象的下一級的別名引用,但對基本對象進行定位時,不丟棄別名引用.           
          derefFindingBaseObject: 在定位基本對象時,丟棄別名引用,但在查找基本對象的下一級時,不丟棄別名引用.
          derefAlways: 在定位基本對象和查找基本對象的下一級時都丟棄別名引用.
   - sizelimit: 一個sizelimit限制了可以返回的最大查找結果的條目數(shù)量.如果該域的值為0,表示不限制查找的sizelimit .
   - timelimit: 一個timelimit 限制了一個查找最多允許的時間(以秒計算).如果該域的值為0,表示不限制查找的timelimit  .
   - attrsOnly: 指示在返回的查找結果中是否要包含屬性類型和屬性值,或者僅包含屬性類型.如果該域設為TRUE,僅返回屬性類型(沒有值),如果該域設為FALSE,同時返回屬性類型和屬性值.
   - filter: 一個過濾器定義了一個必須滿足的條件,以使該查找能匹配給定的條目.
   - attributes: 要返回的查找結果中的每一個條目的屬性列表.一個空的列表表示查找結果應該包含中每一個條目的所有屬性.

    在收到一個查找請求后,服務器返回如下定義的查找回應結果:

  Search Response ::=
      CHOICE {
           entry          [APPLICATION 4] SEQUENCE {
                               objectName     LDAPDN,
                               attributes     SEQUENCE OF SEQUENCE {
                                                   AttributeType,
                                                   SET OF AttributeValue
                                              }
                          },
           resultCode     [APPLICATION 5] LDAPResult
       }

   在收到一個查找請求后,一個服務器將對DIT進行必要的查找.

   服務器將把一序列的回應返回給客戶.這些回應包括:

   - 零個或多個查找回應,每個回應包含在查找時所找到的一個條目.在每個回應的后面跟著回應的序列號.
   
  - 一個包含操作成功或對所發(fā)生錯誤的詳細描述的單個查找回應.
        
     每個返回的條目必須包括所有的屬性,以及在查找請求的 'attributes'域中指定的所要求的關聯(lián)的值.

     注意一個X.500的"列表"操作可以通過具有檢查objectClass屬性是否存在這樣一個過濾器的一個LDAP查找操作來模擬. 同樣, 一個X.500的"讀"操作可以通過具有同樣過濾器的基本對象的LDAP查找操作來模擬.
4.4.  修改操作
    修改操作允許一個客戶請求一個代表他的服務器在DIB上實施 一個修改操作.修改請求定義如下:

ModifyRequest ::=
    [APPLICATION 6] SEQUENCE {
         object         LDAPDN,
         modification   SEQUENCE OF SEQUENCE {
                             operation      ENUMERATED {
                                                 add       (0),
                                                 delete    (1),
                                                 replace   (2)
                                            },
                             modification   SEQUENCE {
                                               type    AttributeType,
                                               values  SET OF
                                                         AttributeValue
                                            }
                        }
    }

   修改請求的參數(shù)是:

   - object: 要修改的對象.這個字段的值指定在丟棄所有的別名后的被修改的對象.服務器在決定哪個對象被修改時,不會進行任何別名丟棄.
   - 在要修改條目上要進行的修改操作的列表.整個對條目進行修改的操作列表通常按照他們在列表的順序,作為一個簡單的原子操作來進行操作.因為一個單獨的修改操作將導致目錄大綱的沖突,在整個操作列表中的操作完成后,結果條目必須符合目錄的大綱.在每個修改結構中可能會被實施的的"操作"字段分別有以下的語義:
              
             add: 把列出的值加到指定的屬性中,如有必要,建立該屬性               
             delete: 從指定的屬性中刪除列出的值.
             如果沒有值被列出來,或者該屬性的全部當前值已被列出來要求刪除,那么把整個屬性刪除掉.            
             replace: 用列出的新值來替換掉指定屬性中已存在的值,如果有必要,建立該屬性.

   在收到修改請求后,,服務器嘗試進行修改操作,結果在修改回應中返回.該回應定義如下

     ModifyResponse ::= [APPLICATION 7] LDAPResult

   在收到一個修改請求后,服務器將對DIB進行必要的修改操作.

   服務器將給客戶返回一個修改回應,該回應或者指明已成功完成修改DIB的操作,或者指明修改失敗的原因.注意到由于要保證修改請求的修改操作列表中的各個操作的原子性,客戶如果收到的回應指明了某種類型的錯誤,他可以期望并沒有對DIB進行任何的修改操作;如果收到的回應指明已成功完成操作,他可以期望所有對DIB進行任何的修改都已經(jīng)完成.
4.5.  添加操作
    添加操作允許客戶請求在目錄中添加新的條目.添加操作定義如下:

     AddRequest ::=
         [APPLICATION 8] SEQUENCE {
              entry          LDAPDN,
              attrs          SEQUENCE OF SEQUENCE {
                                  type          AttributeType,
                                  values        SET OF AttributeValue
                             }
         }

   添加操作的參數(shù)是:

   - entry: 要添加的條目的標識名稱.注意,為了成功添加一個條目,一個名稱除了RDN的最后一部分,其他部分必須要存在.
   - attrs: 組成要添加的條目的內容的屬性列表

     
   在收到添加請求后,,服務器嘗試進行添加操作,結果在添加回應中返回.該回應定義如下

     AddResponse ::= [APPLICATION 9] LDAPResult

 在收到添加請求后,服務器嘗試進行添加操作,添加的結果在添加回應中返回.
4.6.  刪除操作
        刪除操作允許客戶請求從目錄中刪除一個條目.刪除操作的定義如下:s:

     DelRequest ::= [APPLICATION 10] LDAPDN

        刪除請求只包含要刪除條目的標識名.在收到刪除請求后,,服務器嘗試進行刪除操作,結果在刪除回應中返回.該回應定義如下
   
     DelResponse ::= [APPLICATION 11] LDAPResult

       在收到刪除請求后,服務器嘗試進行刪除操作,刪除的結果在刪除回應中返回.注意這個操作只能刪除樹葉對象
4.7.  修改RDN操作
        修改RDN操作允許客戶改變目錄中一個條目名稱的最后一部分.修改RDN操作的定義如下:

     ModifyRDNRequest ::=
         [APPLICATION 12] SEQUENCE {
              entry          LDAPDN,
              newrdn         RelativeLDAPDN,
              deleteoldrdn   BOOLEAN
         }

   修改RDN操作的參數(shù)如下:

   - entry: 要改變的條目的名稱
   - newrdn: 形成新名字的最后一部分的RDN 
   - deleteoldrdn: 一個用來控制舊的RDN屬性值是作為條目的屬性值來保留,還是從條目中刪除的布爾參數(shù).

     在收到改變RDN請求后,服務器嘗試進行改變名字的操作,結果在改變RDN回應中返回.該回應定義如下

     ModifyRDNResponse ::= [APPLICATION 13] LDAPResult

     在收到改變RDN請求后,服務器嘗試進行改變名字的操作,改變名字的結果在改變RDN回應中返回.基于deleteoldrdn 參數(shù)的設置,形成舊的RDN的屬性或者被從條目中刪除,或者被保留下來.
4.8.  比較操作
     比較操作允許客戶對一個斷言和目錄中提供的條目進行比較.比較操作定義如下:

     CompareRequest ::=
         [APPLICATION 14] SEQUENCE {
              entry          LDAPDN,
              ava            AttributeValueAssertion
         }

   比較操作的參數(shù)是:

   - entry: 要比較的條目的名稱
   - ava: 與要比較的條目的進行比較的斷言

    服務器在收到一個比較操作請求后,進行比較操作后的結果在比較回應中返回.比較回應定義如下:

     CompareResponse ::= [APPLICATION 15] LDAPResult

    在收到一個比較操作請求后,服務器嘗試進行需要進行的比較.比較結果將在比較回應中返回給客戶.要注意到,出錯信息和比較結果都在同樣的結果中返回.
4.9.  丟棄操作
    丟棄操作的功能是允許客戶請求服務器終止一個已發(fā)出的操作請求.丟棄操作定義如下:

     AbandonRequest ::= [APPLICATION 16] MessageID

    在丟棄操作中沒有定義相應的回應.在發(fā)送一個丟棄操作后,一個客戶可能期望丟棄請求中包含的消息ID標識的操作已被丟棄.如果服務器在把一個查找操作的
回應發(fā)送給客戶時,收到對該查找操作的丟棄請求,服務器應停止發(fā)送回應,并立即終止該查找操作.
5.  協(xié)議元素的編碼
   LDAP中的協(xié)議元素被編碼以便使用ASN.1 [11]中的基本編碼規(guī)則(BER) [12]來進行交換.然而,在使用BER中的某些元素時,將導致非常高的開銷,在進行LDAP元素的BER編碼時,有以下的附加限制:
   (1) 只使用長度編碼的已定義格式.
   (2) 位串和八位字節(jié)串及所有字符串類型只使用原始格式進行編碼.
6.  安全方面的考慮
     本協(xié)議的這個版本只提供明文口令這種簡單的鑒別手段,及版本4的kerberos 鑒別手段.未來版本的LDAP將可能包括對其他鑒別手段的支持.
7.  參考書目
   [1] The Directory: Overview of Concepts, Models and Service.  CCITT
       Recommendation X.500, 1988.

   [2] Information Processing Systems -- Open Systems Interconnection --
       The Directory: Overview of Concepts, Models and Service.  ISO/IEC
       JTC 1/SC21; International Standard 9594-1, 1988

   [3] Rose, M., "Directory Assistance Service", RFC 1202, Performance
       Systems International, Inc., February 1991.

   [4] Howes, T., Smith, M., and B. Beecher, "DIXIE Protocol
       Specification, RFC 1249, University of Michigan, August 1991.

   [5] Kille, S., "A String Representation of Distinguished Names", RFC
       1779, ISODE Consortium, March 1995.

   [6] Howes, T., Kille, S., Yeong, W., and C. Robbins, "Lightweight
       Directory Access Protocol", RFC 1488, University of Michigan,
       ISODE Consortium, Performance Systems International, NeXor Ltd.,
       July 1993.

   [7] Kerberos Authentication and Authorization System.  S.P. Miller,
       B.C. Neuman, J.I. Schiller, J.H. Saltzer; MIT Project Athena
       Documentation Section E.2.1, December 1987.

   [8] The Directory: Models.  CCITT Recommendation X.501 ISO/IEC JTC
       1/SC21; International Standard 9594-2, 1988.

  [10] The Directory: Abstract Service Definition.  CCITT Recommendation
       X.511, ISO/IEC JTC 1/SC21; International Standard 9594-3, 1988.

  [11] Specification of Abstract Syntax Notation One (ASN.1).  CCITT
       Recommendation X.208, 1988.

  [12] Specification of Basic Encoding Rules for Abstract Syntax
       Notation One (ASN.1).  CCITT Recommendation X.209, 1988.
8.  作者地址
       Wengyik Yeong
       PSI Inc.
       510 Huntmar Park Drive
       Herndon, VA 22070
       USA

       Phone:  +1 703-450-8001
       EMail:  yeongw@psilink.com

       Tim Howes
       University of Michigan
       ITD Research Systems
       535 W William St.
       Ann Arbor, MI 48103-4943
       USA

       Phone:  +1 313 747-4454
       EMail:   tim@umich.edu

       Steve Kille
       ISODE Consortium
       PO Box 505
       London
       SW11 1DX
       UK