rfc1777.txt

很多RFC的中文文档

             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
             }
         }

   查找请求的参数是:

   - baseObject: 一个相对于要进行查找操作的条目的基本对象条目
   - scope: 指示要查找的范围.该域可能的语义上的值与目录查找操作中的范围域的语义值是一致的.
   - derefAliases :指示在操作中别名对象该如何处理.该域可能的语义上的值按照升序的顺序进行.
          neverDerefAliases:在查找或定位查找的基本对象时不丢弃别名引用
          derefInSearching: 在查找过程中,丢弃基本对象的下一级的别名引用,但对基本对象进行定位时,不丢弃别名引用.           
          derefFindingBaseObject: 在定位基本对象时,丢弃别名引用,但在查找基本对象的下一级时,不丢弃别名引用.
          derefAlways: 在定位基本对象和查找基本对象的下一级时都丢弃别名引用.
   - sizelimit: 一个sizelimit限制了可以返回的最大查找结果的条目数量.如果该域的值为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进行必要的查找.

   服务器将把一序列的回应返回给客户.这些回应包括:

   - 零个或多个查找回应,每个回应包含在查找时所找到的一个条目.在每个回应的后面跟着回应的序列号.
   
  - 一个包含操作成功或对所发生错误的详细描述的单个查找回应.
        
     每个返回的条目必须包括所有的属性,以及在查找请求的 'attributes'域中指定的所要求的关联的值.

     注意一个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
                                            }
                        }
    }

   修改请求的参数是:

   - object: 要修改的对象.这个字段的值指定在丢弃所有的别名后的被修改的对象.服务器在决定哪个对象被修改时,不会进行任何别名丢弃.
   - 在要修改条目上要进行的修改操作的列表.整个对条目进行修改的操作列表通常按照他们在列表的顺序,作为一个简单的原子操作来进行操作.因为一个单独的修改操作将导致目录大纲的冲突,在整个操作列表中的操作完成后,结果条目必须符合目录的大纲.在每个修改结构中可能会被实施的的"操作"字段分别有以下的语义:
              
             add: 把列出的值加到指定的属性中,如有必要,建立该属性               
             delete: 从指定的属性中删除列出的值.
             如果没有值被列出来,或者该属性的全部当前值已被列出来要求删除,那么把整个属性删除掉.            
             replace: 用列出的新值来替换掉指定属性中已存在的值,如果有必要,建立该属性.

   在收到修改请求后,,服务器尝试进行修改操作,结果在修改回应中返回.该回应定义如下

     ModifyResponse ::= [APPLICATION 7] LDAPResult

   在收到一个修改请求后,服务器将对DIB进行必要的修改操作.

   服务器将给客户返回一个修改回应,该回应或者指明已成功完成修改DIB的操作,或者指明修改失败的原因.注意到由于要保证修改请求的修改操作列表中的各个操作的原子性,客户如果收到的回应指明了某种类型的错误,他可以期望并没有对DIB进行任何的修改操作;如果收到的回应指明已成功完成操作,他可以期望所有对DIB进行任何的修改都已经完成.
4.5.  添加操作
    添加操作允许客户请求在目录中添加新的条目.添加操作定义如下:

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

   添加操作的参数是:

   - 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操作的参数如下:

   - entry: 要改变的条目的名称
   - newrdn: 形成新名字的最后一部分的RDN 
   - deleteoldrdn: 一个用来控制旧的RDN属性值是作为条目的属性值来保留,还是从条目中删除的布尔参数.

     在收到改变RDN请求后,服务器尝试进行改变名字的操作,结果在改变RDN回应中返回.该回应定义如下

     ModifyRDNResponse ::= [APPLICATION 13] LDAPResult

     在收到改变RDN请求后,服务器尝试进行改变名字的操作,改变名字的结果在改变RDN回应中返回.基于deleteoldrdn 参数的设置,形成旧的RDN的属性或者被从条目中删除,或者被保留下来.
4.8.  比较操作
     比较操作允许客户对一个断言和目录中提供的条目进行比较.比较操作定义如下:

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

   比较操作的参数是:

   - entry: 要比较的条目的名称
   - ava: 与要比较的条目的进行比较的断言

    服务器在收到一个比较操作请求后,进行比较操作后的结果在比较回应中返回.比较回应定义如下:

     CompareResponse ::= [APPLICATION 15] LDAPResult

    在收到一个比较操作请求后,服务器尝试进行需要进行的比较.比较结果将在比较回应中返回给客户.要注意到,出错信息和比较结果都在同样的结果中返回.
4.9.  丢弃操作
    丢弃操作的功能是允许客户请求服务器终止一个已发出的操作请求.丢弃操作定义如下:

     AbandonRequest ::= [APPLICATION 16] MessageID

    在丢弃操作中没有定义相应的回应.在发送一个丢弃操作后,一个客户可能期望丢弃请求中包含的消息ID标识的操作已被丢弃.如果服务器在把一个查找操作的
回应发送给客户时,收到对该查找操作的丢弃请求,服务器应停止发送回应,并立即终止该查找操作.
5.  协议元素的编码
   LDAP中的协议元素被编码以便使用ASN.1 [11]中的基本编码规则(BER) [12]来进行交换.然而,在使用BER中的某些元素时,将导致非常高的开销,在进行LDAP元素的BER编码时,有以下的附加限制:
   (1) 只使用长度编码的已定义格式.
   (2) 位串和八位字节串及所有字符串类型只使用原始格式进行编码.
6.  安全方面的考虑
     本协议的这个版本只提供明文口令这种简单的鉴别手段,及版本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:  [phone]
       EMail:  [e-mail]

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

       Phone:  [phone]
       EMail:   [e-mail]

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