rfc4512.txt

samba最新软件

         [ SP "EQUALITY" SP oid ]      ; equality matching rule
         [ SP "ORDERING" SP oid ]      ; ordering matching rule
         [ SP "SUBSTR" SP oid ]        ; substrings matching rule
         [ SP "SYNTAX" SP noidlen ]    ; value syntax
         [ SP "SINGLE-VALUE" ]         ; single-value
         [ SP "COLLECTIVE" ]           ; collective
         [ SP "NO-USER-MODIFICATION" ] ; not user modifiable
         [ SP "USAGE" SP usage ]       ; usage
         extensions WSP RPAREN         ; extensions

     usage = "userApplications"     /  ; user
             "directoryOperation"   /  ; directory operational
             "distributedOperation" /  ; DSA-shared operational
             "dSAOperation"            ; DSA-specific operational

   where:
     <numericoid> is object identifier assigned to this attribute type;
     NAME <qdescrs> are short names (descriptors) identifying this
         attribute type;
     DESC <qdstring> is a short descriptive string;
     OBSOLETE indicates this attribute type is not active;
     SUP oid specifies the direct supertype of this type;
     EQUALITY, ORDERING, and SUBSTR provide the oid of the equality,
         ordering, and substrings matching rules, respectively;
     SYNTAX identifies value syntax by object identifier and may suggest
         a minimum upper bound;
     SINGLE-VALUE indicates attributes of this type are restricted to a
         single value;
     COLLECTIVE indicates this attribute type is collective
         [X.501][RFC3671];
     NO-USER-MODIFICATION indicates this attribute type is not user
         modifiable;
     USAGE indicates the application of this attribute type; and
     <extensions> describe extensions.

   Each attribute type description must contain at least one of the SUP
   or SYNTAX fields.  If no SYNTAX field is provided, the attribute type
   description takes its value from the supertype.



Zeilenga                    Standards Track                    [Page 25]

RFC 4512                      LDAP Models                      June 2006


   If SUP field is provided, the EQUALITY, ORDERING, and SUBSTRING
   fields, if not specified, take their value from the supertype.

   Usage of userApplications, the default, indicates that attributes of
   this type represent user information.  That is, they are user
   attributes.

   A usage of directoryOperation, distributedOperation, or dSAOperation
   indicates that attributes of this type represent operational and/or
   administrative information.  That is, they are operational
   attributes.

   directoryOperation usage indicates that the attribute of this type is
   a directory operational attribute.  distributedOperation usage
   indicates that the attribute of this type is a DSA-shared usage
   operational attribute.  dSAOperation usage indicates that the
   attribute of this type is a DSA-specific operational attribute.

   COLLECTIVE requires usage userApplications.  Use of collective
   attribute types in LDAP is discussed in [RFC3671].

   NO-USER-MODIFICATION requires an operational usage.

   Note that the <AttributeTypeDescription> does not list the matching
   rules that can be used with that attribute type in an extensibleMatch
   search filter [RFC4511].  This is done using the 'matchingRuleUse'
   attribute described in Section 4.1.4.

   This document refines the schema description of X.501 by requiring
   that the SYNTAX field in an <AttributeTypeDescription> be a string
   representation of an object identifier for the LDAP string syntax
   definition, with an optional indication of the suggested minimum
   bound of a value of this attribute.

   A suggested minimum upper bound on the number of characters in a
   value with a string-based syntax, or the number of bytes in a value
   for all other syntaxes, may be indicated by appending this bound
   count inside of curly braces following the syntax's OBJECT IDENTIFIER
   in an Attribute Type Description.  This bound is not part of the
   syntax name itself.  For instance, "1.3.6.4.1.1466.0{64}" suggests
   that server implementations should allow a string to be 64 characters
   long, although they may allow longer strings.  Note that a single
   character of the Directory String syntax may be encoded in more than
   one octet since UTF-8 [RFC3629] is a variable-length encoding.







Zeilenga                    Standards Track                    [Page 26]

RFC 4512                      LDAP Models                      June 2006


4.1.3.  Matching Rules

   Matching rules are used in performance of attribute value assertions,
   such as in performance of a Compare operation.  They are also used in
   evaluating search filters, determining which individual values are to
   be added or deleted during performance of a Modify operation, and in
   comparing distinguished names.

   Each matching rule is identified by an object identifier (OID) and,
   optionally, one or more short names (descriptors).

   Matching rule definitions are written according to the ABNF:

     MatchingRuleDescription = LPAREN WSP
         numericoid                 ; object identifier
         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
         [ SP "DESC" SP qdstring ]  ; description
         [ SP "OBSOLETE" ]          ; not active
         SP "SYNTAX" SP numericoid  ; assertion syntax
         extensions WSP RPAREN      ; extensions

   where:
     <numericoid> is object identifier assigned to this matching rule;
     NAME <qdescrs> are short names (descriptors) identifying this
         matching rule;
     DESC <qdstring> is a short descriptive string;
     OBSOLETE indicates this matching rule is not active;
     SYNTAX identifies the assertion syntax (the syntax of the assertion
         value) by object identifier; and
     <extensions> describe extensions.

4.1.4.  Matching Rule Uses

   A matching rule use lists the attribute types that are suitable for
   use with an extensibleMatch search filter.

   Matching rule use descriptions are written according to the following
   ABNF:

     MatchingRuleUseDescription = LPAREN WSP
         numericoid                 ; object identifier
         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
         [ SP "DESC" SP qdstring ]  ; description
         [ SP "OBSOLETE" ]          ; not active
         SP "APPLIES" SP oids       ; attribute types
         extensions WSP RPAREN      ; extensions





Zeilenga                    Standards Track                    [Page 27]

RFC 4512                      LDAP Models                      June 2006


   where:
     <numericoid> is the object identifier of the matching rule
         associated with this matching rule use description;
     NAME <qdescrs> are short names (descriptors) identifying this
         matching rule use;
     DESC <qdstring> is a short descriptive string;
     OBSOLETE indicates this matching rule use is not active;
     APPLIES provides a list of attribute types the matching rule
         applies to; and
     <extensions> describe extensions.

4.1.5.  LDAP Syntaxes

   LDAP Syntaxes of (attribute and assertion) values are described in
   terms of ASN.1 [X.680] and, optionally, have an octet string encoding
   known as the LDAP-specific encoding.  Commonly, the LDAP-specific
   encoding is constrained to a string of Unicode [Unicode] characters
   in UTF-8 [RFC3629] form.

   Each LDAP syntax is identified by an object identifier (OID).

   LDAP syntax definitions are written according to the ABNF:

     SyntaxDescription = LPAREN WSP
         numericoid                 ; object identifier
         [ SP "DESC" SP qdstring ]  ; description
         extensions WSP RPAREN      ; extensions

   where:
     <numericoid> is the object identifier assigned to this LDAP syntax;
     DESC <qdstring> is a short descriptive string; and
     <extensions> describe extensions.

4.1.6.  DIT Content Rules

   A DIT content rule is a "rule governing the content of entries of a
   particular structural object class" [X.501].

   For DIT entries of a particular structural object class, a DIT
   content rule specifies which auxiliary object classes the entries are
   allowed to belong to and which additional attributes (by type) are
   required, allowed, or not allowed to appear in the entries.

   The list of precluded attributes cannot include any attribute listed
   as mandatory in the rule, the structural object class, or any of the
   allowed auxiliary object classes.





Zeilenga                    Standards Track                    [Page 28]

RFC 4512                      LDAP Models                      June 2006


   Each content rule is identified by the object identifier, as well as
   any short names (descriptors), of the structural object class it
   applies to.

   An entry may only belong to auxiliary object classes listed in the
   governing content rule.

   An entry must contain all attributes required by the object classes
   the entry belongs to as well as all attributes required by the
   governing content rule.

   An entry may contain any non-precluded attributes allowed by the
   object classes the entry belongs to as well as all attributes allowed
   by the governing content rule.

   An entry cannot include any attribute precluded by the governing
   content rule.

   An entry is governed by (if present and active in the subschema) the
   DIT content rule that applies to the structural object class of the
   entry (see Section 2.4.2).  If no active rule is present for the
   entry's structural object class, the entry's content is governed by
   the structural object class (and possibly other aspects of user and
   system schema).  DIT content rules for superclasses of the structural
   object class of an entry are not applicable to that entry.

   DIT content rule descriptions are written according to the ABNF:

     DITContentRuleDescription = LPAREN WSP
         numericoid                 ; object identifier
         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
         [ SP "DESC" SP qdstring ]  ; description
         [ SP "OBSOLETE" ]          ; not active
         [ SP "AUX" SP oids ]       ; auxiliary object classes
         [ SP "MUST" SP oids ]      ; attribute types
         [ SP "MAY" SP oids ]       ; attribute types
         [ SP "NOT" SP oids ]       ; attribute types
         extensions WSP RPAREN      ; extensions

   where:
     <numericoid> is the object identifier of the structural object
         class associated with this DIT content rule;
     NAME <qdescrs> are short names (descriptors) identifying this DIT
         content rule;
     DESC <qdstring> is a short descriptive string;
     OBSOLETE indicates this DIT content rule use is not active;
     AUX specifies a list of auxiliary object classes that entries
         subject to this DIT content rule may belong to;



Zeilenga                    Standards Track                    [Page 29]

RFC 4512                      LDAP Models                      June 2006


     MUST, MAY, and NOT specify lists of attribute types that are
         required, allowed, or precluded, respectively, from appearing
         in entries subject to this DIT content rule; and
     <extensions> describe extensions.

4.1.7.  DIT Structure Rules and Name Forms

   It is sometimes desirable to regulate where object and alias entries
   can be placed in the DIT and how they can be named based upon their
   structural object class.

4.1.7.1.  DIT Structure Rules

   A DIT structure rule is a "rule governing the structure of the DIT by
   specifying a permitted superior to subordinate entry relationship.  A
   structure rule relates a name form, and therefore a structural object
   class, to superior structure rules.  This permits entries of the
   structural object class identified by the name form to exist in the
   DIT as subordinates to entries governed by the indicated superior
   structure rules" [X.501].

   DIT structure rule descriptions are written according to the ABNF:

     DITStructureRuleDescription = LPAREN WSP
         ruleid                     ; rule identifier
         [ SP "NAME" SP qdescrs ]   ; short names (descriptors)
         [ SP "DESC" SP qdstring ]  ; description
         [ SP "OBSOLETE" ]          ; not active
         SP "FORM" SP oid           ; NameForm
         [ SP "SUP" ruleids ]       ; superior rules
         extensions WSP RPAREN      ; extensions

     ruleids = ruleid / ( LPAREN WSP ruleidlist WSP RPAREN )
     ruleidlist = ruleid *( SP ruleid )
     ruleid = number

   where:
     <ruleid> is the rule identifier of this DIT structure rule;
     NAME <qdescrs> are short names (descriptors) identifying this DIT
         structure rule;
     DESC <qdstring> is a short descriptive string;
     OBSOLETE indicates this DIT structure rule use is not active;
     FORM is specifies the name form associated with this DIT structure
         rule;
     SUP identifies superior rules (by rule id); and
     <extensions> describe extensions.





Zeilenga                    Standards Track                    [Page 30]

RFC 4512                      LDAP Models                      June 2006


   If no superior rules are identified, the DIT structure rule applies
   to an autonomous administrative point (e.g., the root vertex of the
   subtree controlled by the subschema) [X.501].

4.1.7.2.  Name Forms

   A name form "specifies a permissible RDN for entries of a particular
   structural object class.  A name form identifies a named object class
   and one or more attribute types to be used for naming (i.e., for the
   RDN).  Name forms are primitive pieces of specification used in the
   definition of DIT structure rules