rfc1777.txt

RFC 的详细文档！


RFC 1777                          LDAP                        March 1995


     replace: replace existing values of the given attribute
     with the new values listed, creating the attribute if
     necessary.

   The result of the modify attempted by the server upon receipt of a
   Modify Request is returned in a Modify Response, defined as follows:

     ModifyResponse ::= [APPLICATION 7] LDAPResult

   Upon receipt of a Modify Request, a server will perform the necessary
   modifications to the DIB.

   The server will return to the client a single Modify Response
   indicating either the successful completion of the DIB modification,
   or the reason that the modification failed. Note that due to the
   requirement for atomicity in applying the list of modifications in
   the Modify Request, the client may expect that no modifications of
   the DIB have been performed if the Modify Response received indicates
   any sort of error, and that all requested modifications have been
   performed if the Modify Response indicates successful completion of
   the Modify Operation.

4.5.  Add Operation

   The Add Operation allows a client to request the addition of an entry
   into the Directory. The Add Request is defined as follows:

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

   Parameters of the Add Request are:

   - entry: the Distinguished Name of the entry to be added. Note that
     all components of the name except for the last RDN component must
     exist for the add to succeed.

   - attrs: the list of attributes that make up the content of the entry
     being added.

   The result of the add attempted by the server upon receipt of a Add
   Request is returned in the Add Response, defined as follows:




Yeong, Howes & Kille                                           [Page 12]

RFC 1777                          LDAP                        March 1995


     AddResponse ::= [APPLICATION 9] LDAPResult

   Upon receipt of an Add Request, a server will attempt to perform the
   add requested. The result of the add attempt will be returned to the
   client in the Add Response.

4.6.  Delete Operation

   The Delete Operation allows a client to request the removal of an
   entry from the Directory. The Delete Request is defined as follows:

     DelRequest ::= [APPLICATION 10] LDAPDN

   The Delete Request consists only of the Distinguished Name of the
   entry to be deleted.  The result of the delete attempted by the
   server upon receipt of a Delete Request is returned in the Delete
   Response, defined as follows:

     DelResponse ::= [APPLICATION 11] LDAPResult

   Upon receipt of a Delete Request, a server will attempt to perform
   the entry removal requested. The result of the delete attempt will be
   returned to the client in the Delete Response. Note that only leaf
   objects may be deleted with this operation.

4.7.  Modify RDN Operation

   The Modify RDN Operation allows a client to change the last component
   of the name of an entry in the Directory. The Modify RDN Request is
   defined as follows:

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

   Parameters of the Modify RDN Request are:

   - entry: the name of the entry to be changed.

   - newrdn: the RDN that will form the last component of the new name.

   - deleteoldrdn: a boolean parameter that controls whether the old RDN
     attribute values should be retained as attributes of the entry or
     deleted from the entry.




Yeong, Howes & Kille                                           [Page 13]

RFC 1777                          LDAP                        March 1995


   The result of the name change attempted by the server upon receipt of
   a Modify RDN Request is returned in the Modify RDN Response, defined
   as follows:

     ModifyRDNResponse ::= [APPLICATION 13] LDAPResult

   Upon receipt of a Modify RDN Request, a server will attempt to
   perform the name change. The result of the name change attempt will
   be returned to the client in the Modify RDN Response. The attributes
   that make up the old RDN are deleted from the entry, or kept,
   depending on the setting of the deleteoldrdn parameter.

4.8.  Compare Operation

   The Compare Operation allows a client to compare an assertion
   provided with an entry in the Directory. The Compare Request is
   defined as follows:

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

   Parameters of the Compare Request are:

   - entry: the name of the entry to be compared with.

   - ava: the assertion with which the entry is to be compared.

   The result of the compare attempted by the server upon receipt of a
   Compare Request is returned in the Compare Response, defined as
   follows:

     CompareResponse ::= [APPLICATION 15] LDAPResult

   Upon receipt of a Compare Request, a server will attempt to perform
   the requested comparison. The result of the comparison will be
   returned to the client in the Compare Response. Note that errors and
   the result of comparison are all returned in the same construct.

6.9.  Abandon Operation

   The function of the Abandon Operation is to allow a client to request
   that the server abandon an outstanding operation.  The Abandon
   Request is defined as follows:

     AbandonRequest ::= [APPLICATION 16] MessageID



Yeong, Howes & Kille                                           [Page 14]

RFC 1777                          LDAP                        March 1995


   There is no response defined in the Abandon Operation. Upon
   transmission of an Abandon Operation, a client may expect that the
   operation identityfied by the Message ID in the Abandon Request has
   been abandoned. In the event that a server receives an Abandon
   Request on a Search Operation in the midst of transmitting responses
   to that search, that server should cease transmitting responses to
   the abandoned search immediately.

5.  Protocol Element Encodings

   The protocol elements of LDAP are encoded for exchange using the
   Basic Encoding Rules (BER) [12] of ASN.1 [11]. However, due to the
   high overhead involved in using certain elements of the BER, the
   following additional restrictions are placed on BER-encodings of LDAP
   protocol elements:

   (1)  Only the definite form of length encoding will be used.

   (2)  Bitstrings and octet strings and all character string types
        will be encoded in the primitive form only.

6.  Security Considerations

   This version of the protocol provides facilities only for simple
   authentication using a cleartext password, and for kerberos version 4
   authentication.  Future versions of LDAP will likely include support
   for other authentication methods.

7.  Bibliography

   [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.






Yeong, Howes & Kille                                           [Page 15]

RFC 1777                          LDAP                        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.































Yeong, Howes & Kille                                           [Page 16]

RFC 1777                          LDAP                        March 1995


10.  Authors' Addresses

       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