rfc4511.txt

samba最新软件

4.5.1.6.  SearchRequest.typesOnly

   An indicator as to whether Search results are to contain both
   attribute descriptions and values, or just attribute descriptions.
   Setting this field to TRUE causes only attribute descriptions (and
   not values) to be returned.  Setting this field to FALSE causes both
   attribute descriptions and values to be returned.

4.5.1.7.  SearchRequest.filter

   A filter that defines the conditions that must be fulfilled in order
   for the Search to match a given entry.

   The 'and', 'or', and 'not' choices can be used to form combinations
   of filters.  At least one filter element MUST be present in an 'and'
   or 'or' choice.  The others match against individual attribute values
   of entries in the scope of the Search.  (Implementor's note: the
   'not' filter is an example of a tagged choice in an implicitly-tagged
   module.  In BER this is treated as if the tag were explicit.)

   A server MUST evaluate filters according to the three-valued logic of
   [X.511] (1993), Clause 7.8.1.  In summary, a filter is evaluated to
   "TRUE", "FALSE", or "Undefined".  If the filter evaluates to TRUE for
   a particular entry, then the attributes of that entry are returned as
   part of the Search result (subject to any applicable access control
   restrictions).  If the filter evaluates to FALSE or Undefined, then
   the entry is ignored for the Search.

   A filter of the "and" choice is TRUE if all the filters in the SET OF
   evaluate to TRUE, FALSE if at least one filter is FALSE, and
   Undefined otherwise.  A filter of the "or" choice is FALSE if all the
   filters in the SET OF evaluate to FALSE, TRUE if at least one filter
   is TRUE, and Undefined otherwise.  A filter of the 'not' choice is
   TRUE if the filter being negated is FALSE, FALSE if it is TRUE, and
   Undefined if it is Undefined.

   A filter item evaluates to Undefined when the server would not be
   able to determine whether the assertion value matches an entry.
   Examples include:





Sermersheim                 Standards Track                    [Page 23]

RFC 4511                         LDAPv3                        June 2006


   - An attribute description in an equalityMatch, substrings,
     greaterOrEqual, lessOrEqual, approxMatch, or extensibleMatch filter
     is not recognized by the server.

   - The attribute type does not define the appropriate matching rule.

   - A MatchingRuleId in the extensibleMatch is not recognized by the
     server or is not valid for the attribute type.

   - The type of filtering requested is not implemented.

   - The assertion value is invalid.

   For example, if a server did not recognize the attribute type
   shoeSize, the filters (shoeSize=*), (shoeSize=12), (shoeSize>=12),
   and (shoeSize<=12) would each evaluate to Undefined.

   Servers MUST NOT return errors if attribute descriptions or matching
   rule ids are not recognized, assertion values are invalid, or the
   assertion syntax is not supported.  More details of filter processing
   are given in Clause 7.8 of [X.511].

4.5.1.7.1.  SearchRequest.filter.equalityMatch

   The matching rule for an equalityMatch filter is defined by the
   EQUALITY matching rule for the attribute type or subtype.  The filter
   is TRUE when the EQUALITY rule returns TRUE as applied to the
   attribute or subtype and the asserted value.

4.5.1.7.2.  SearchRequest.filter.substrings

   There SHALL be at most one 'initial' and at most one 'final' in the
   'substrings' of a SubstringFilter.  If 'initial' is present, it SHALL
   be the first element of 'substrings'.  If 'final' is present, it
   SHALL be the last element of 'substrings'.

   The matching rule for an AssertionValue in a substrings filter item
   is defined by the SUBSTR matching rule for the attribute type or
   subtype.  The filter is TRUE when the SUBSTR rule returns TRUE as
   applied to the attribute or subtype and the asserted value.

   Note that the AssertionValue in a substrings filter item conforms to
   the assertion syntax of the EQUALITY matching rule for the attribute
   type rather than to the assertion syntax of the SUBSTR matching rule
   for the attribute type.  Conceptually, the entire SubstringFilter is
   converted into an assertion value of the substrings matching rule
   prior to applying the rule.




Sermersheim                 Standards Track                    [Page 24]

RFC 4511                         LDAPv3                        June 2006


4.5.1.7.3.  SearchRequest.filter.greaterOrEqual

   The matching rule for a greaterOrEqual filter is defined by the
   ORDERING matching rule for the attribute type or subtype.  The filter
   is TRUE when the ORDERING rule returns FALSE as applied to the
   attribute or subtype and the asserted value.

4.5.1.7.4.  SearchRequest.filter.lessOrEqual

   The matching rules for a lessOrEqual filter are defined by the
   ORDERING and EQUALITY matching rules for the attribute type or
   subtype.  The filter is TRUE when either the ORDERING or EQUALITY
   rule returns TRUE as applied to the attribute or subtype and the
   asserted value.

4.5.1.7.5.  SearchRequest.filter.present

   A present filter is TRUE when there is an attribute or subtype of the
   specified attribute description present in an entry, FALSE when no
   attribute or subtype of the specified attribute description is
   present in an entry, and Undefined otherwise.

4.5.1.7.6.  SearchRequest.filter.approxMatch

   An approxMatch filter is TRUE when there is a value of the attribute
   type or subtype for which some locally-defined approximate matching
   algorithm (e.g., spelling variations, phonetic match, etc.) returns
   TRUE.  If a value matches for equality, it also satisfies an
   approximate match.  If approximate matching is not supported for the
   attribute, this filter item should be treated as an equalityMatch.

4.5.1.7.7.  SearchRequest.filter.extensibleMatch

   The fields of the extensibleMatch filter item are evaluated as
   follows:

   - If the matchingRule field is absent, the type field MUST be
     present, and an equality match is performed for that type.

   - If the type field is absent and the matchingRule is present, the
     matchValue is compared against all attributes in an entry that
     support that matchingRule.

   - If the type field is present and the matchingRule is present, the
     matchValue is compared against the specified attribute type and its
     subtypes.





Sermersheim                 Standards Track                    [Page 25]

RFC 4511                         LDAPv3                        June 2006


   - If the dnAttributes field is set to TRUE, the match is additionally
     applied against all the AttributeValueAssertions in an entry's
     distinguished name, and it evaluates to TRUE if there is at least
     one attribute or subtype in the distinguished name for which the
     filter item evaluates to TRUE.  The dnAttributes field is present
     to alleviate the need for multiple versions of generic matching
     rules (such as word matching), where one applies to entries and
     another applies to entries and DN attributes as well.

   The matchingRule used for evaluation determines the syntax for the
   assertion value.  Once the matchingRule and attribute(s) have been
   determined, the filter item evaluates to TRUE if it matches at least
   one attribute type or subtype in the entry, FALSE if it does not
   match any attribute type or subtype in the entry, and Undefined if
   the matchingRule is not recognized, the matchingRule is unsuitable
   for use with the specified type, or the assertionValue is invalid.

4.5.1.8.  SearchRequest.attributes

   A selection list of the attributes to be returned from each entry
   that matches the search filter.  Attributes that are subtypes of
   listed attributes are implicitly included.  LDAPString values of this
   field are constrained to the following Augmented Backus-Naur Form
   (ABNF) [RFC4234]:

      attributeSelector = attributedescription / selectorspecial

      selectorspecial = noattrs / alluserattrs

      noattrs = %x31.2E.31 ; "1.1"

      alluserattrs = %x2A ; asterisk ("*")

      The <attributedescription> production is defined in Section 2.5 of
      [RFC4512].

      There are three special cases that may appear in the attributes
      selection list:

      1. An empty list with no attributes requests the return of all
         user attributes.

      2. A list containing "*" (with zero or more attribute
         descriptions) requests the return of all user attributes in
         addition to other listed (operational) attributes.






Sermersheim                 Standards Track                    [Page 26]

RFC 4511                         LDAPv3                        June 2006


      3. A list containing only the OID "1.1" indicates that no
         attributes are to be returned.  If "1.1" is provided with other
         attributeSelector values, the "1.1" attributeSelector is
         ignored.  This OID was chosen because it does not (and can not)
         correspond to any attribute in use.

   Client implementors should note that even if all user attributes are
   requested, some attributes and/or attribute values of the entry may
   not be included in Search results due to access controls or other
   restrictions.  Furthermore, servers will not return operational
   attributes, such as objectClasses or attributeTypes, unless they are
   listed by name.  Operational attributes are described in [RFC4512].

   Attributes are returned at most once in an entry.  If an attribute
   description is named more than once in the list, the subsequent names
   are ignored.  If an attribute description in the list is not
   recognized, it is ignored by the server.

4.5.2.  Search Result

   The results of the Search operation are returned as zero or more
   SearchResultEntry and/or SearchResultReference messages, followed by
   a single SearchResultDone message.

        SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
             objectName      LDAPDN,
             attributes      PartialAttributeList }

        PartialAttributeList ::= SEQUENCE OF
                             partialAttribute PartialAttribute

        SearchResultReference ::= [APPLICATION 19] SEQUENCE
                                  SIZE (1..MAX) OF uri URI

        SearchResultDone ::= [APPLICATION 5] LDAPResult

   Each SearchResultEntry represents an entry found during the Search.
   Each SearchResultReference represents an area not yet explored during
   the Search.  The SearchResultEntry and SearchResultReference messages
   may come in any order.  Following all the SearchResultReference and
   SearchResultEntry responses, the server returns a SearchResultDone
   response, which contains an indication of success or details any
   errors that have occurred.

   Each entry returned in a SearchResultEntry will contain all
   appropriate attributes as specified in the attributes field of the
   Search Request, subject to access control and other administrative
   policy.  Note that the PartialAttributeList may hold zero elements.



Sermersheim                 Standards Track                    [Page 27]

RFC 4511                         LDAPv3                        June 2006


   This may happen when none of the attributes of an entry were
   requested or could be returned.  Note also that the partialAttribute
   vals set may hold zero elements.  This may happen when typesOnly is
   requested, access controls prevent the return of values, or other
   reasons.

   Some attributes may be constructed by the server and appear in a
   SearchResultEntry attribute list, although they are not stored
   attributes of an entry.  Clients SHOULD NOT assume that all
   attributes can be modified, even if this is permitted by access
   control.

   If the server's schema defines short names [RFC4512] for an attribute
   type, then the server SHOULD use one of those names in attribute
   descriptions for that attribute type (in preference to using the
   <numericoid> [RFC4512] format of the attribute type's object
   identifier).  The server SHOULD NOT use the short name if that name
   is known by the server to be ambiguous, or if it is otherwise likely
   to cause interoperability problems.

4.5.3.  Continuation References in the Search Result

   If the server was able to locate the entry referred to by the
   baseObject but was unable or unwilling to search one or more non-
   local entries, the server may return one or more
   SearchResultReference messages, each containing a reference to
   another set of servers for continuing the operation.  A server MUST
   NOT return any SearchResultReference messages if it has not located
   the baseObject and thus has not searched any entries.  In this case,
   it would return a SearchResultDone containing either a referral or
   noSuchObject result code (depending on the server's knowledge of the
   entry named in the baseObject).

   If a server holds a copy or partial copy of the subordinate naming
   context (Section 5 of [RFC4512]), it may use the search filter to
   determine whether or not to return a SearchRe