view Side-By-Side changes

INTERNET-DRAFT                                                   S. Legg
draft-legg-ldapext-component-matching-06.txt
draft-legg-ldapext-component-matching-07.txt         Adacel Technologies
Intended Category: Standard Track                         March 1, 27, 2002


                 LDAP & X.500 Component Matching Rules

    Copyright (C) The Internet Society (2002). All Rights Reserved.

   Status of this Memo


   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Distribution of this document is unlimited.  Comments should be sent
   to the LDAPEXT working group mailing list <ietf-ldapext@netscape.com>
   or to the author.

   This Internet-Draft expires on 1 27 September 2002.


1. Abstract

   The syntaxes of attributes in an LDAP a Lightweight Directory Access Protocol
   or X.500 directory range from simple data types, such as text string,
   integer, or boolean, to complex structured data types, such as the
   syntaxes of the directory schema operational attributes.  The
   matching rules defined for the complex syntaxes, if any, usually only
   provide the most immediately useful matching capability.  This
   document defines generic matching rules that can match any user
   selected component parts in an attribute value of any arbitrarily complex attribute syntax.  Generic



Legg                    Expires 1 27 September 2002               [Page 1]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 1, 27, 2002


   string encodings for


   complex attribute and assertion values of arbitrary
   syntax are also defined.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1]. syntax.


2. Table of Contents

   1. Abstract ......................................................  1
   2. Table of Contents .............................................  2
   3. Introduction ..................................................  3  2
   4. Conventions ...................................................  4
   5. ComponentAssertion ............................................  5
      4.1
      5.1 Component Reference .......................................  6
         4.1.1  5
         5.1.1 Component Type Substitutions .........................  7
         4.1.2
         5.1.2 Referencing SET, SEQUENCE and CHOICE Components ......  8
         4.1.3
         5.1.3 Referencing SET OF and SEQUENCE OF Components ........  9
         4.1.4
         5.1.4 Referencing Components of Parameterized Types ........ 10
         4.1.5
         5.1.5 Component Referencing Example ........................ 10
         4.1.6
         5.1.6 Referencing Components of Open Types ................. 11
            4.1.6.1
            5.1.6.1 Open Type Referencing Example ................... 12
         4.1.7
         5.1.7 Referencing Contained Types .......................... 13
            4.1.7.1
            5.1.7.1 Contained Type Referencing Example .............. 14
      4.2
      5.2 Matching of Components .................................... 15
         4.2.1
         5.2.1 Applicability of Existing Matching Rules ............. 16
            4.2.1.1
            5.2.1.1 String Matching ................................. 16
            4.2.1.2
            5.2.1.2 Telephone Number Matching ....................... 18
            4.2.1.3 17
            5.2.1.3 Distinguished Name Matching ..................... 19
         4.2.2 17
         5.2.2 Additional Useful Matching Rules ..................... 19
            4.2.2.1 17
            5.2.2.1 The rdnMatch Matching Rule ...................... 19
            4.2.2.2 18
            5.2.2.2 The OpenAssertionType Syntax .................... 20
            4.2.2.3 18
            5.2.2.3 The enumeratedMatch Matching Rule ............... 20
            4.2.2.4 19
            5.2.2.4 The presentMatch Matching Rule .................. 21
         4.2.3 19
         5.2.3 Summary of Useful Matching Rules ..................... 22
   5. 20
   6. ComponentFilter ............................................... 23
   6. 22
   7. The componentFilterMatch Matching Rule ........................ 24
   7. 23
   8. Equality Matching of Complex Components ....................... 26
      7.1 24
      8.1 The allComponentsMatch Matching Rule ...................... 26
      7.2 25
      8.2 Deriving Component Equality Matching Rules ................ 28
      7.3 27
      8.3 The directoryComponentsMatch Matching Rule ................ 30
   8. Generic String Encoding Rules ................................. 31
      8.1 GSER Transfer Syntax ...................................... 38 29
   9. Component Matching Examples ................................... 39 30
   10. Security Considerations ...................................... 45 36
   11. Acknowledgements ............................................. 45 37
   12. Normative References ......................................... 45 37
   13. Informative References ....................................... 46



Legg                    Expires 1 September 2002                [Page 2]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002 38
   14. Intellectual Property Notice ................................. 47 38
   15. Copyright Notice ............................................. 47 39
   16. Author's Address ............................................. 48 39


3. Introduction



Legg                    Expires 27 September 2002               [Page 2]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   The structure or data type of data held in an attribute of an LDAP
   [4]
   [3] or X.500 [18] directory is described by the attribute's syntax.
   Attribute syntaxes range from simple data types, such as text string,
   integer, or boolean, to complex data types, for example, the syntaxes
   of the directory schema operational attributes.

   In X.500, the attribute syntaxes are explicitly described by ASN.1
   [11] type definitions.  ASN.1 type notation has a number of simple
   data types (e.g. PrintableString, INTEGER, BOOLEAN), and combining
   types (i.e. SET, SEQUENCE, SET OF, SEQUENCE OF, and CHOICE) for
   constructing arbitrarily complex data types from simpler component
   types.  In LDAP, the attributes attribute syntaxes are usually described by ABNF [3]
   [2] though there is an implied association between the LDAP attribute
   syntaxes and the X.500 ASN.1 types.  To a large extent, the data
   types of attribute values in either an LDAP or X.500 directory are
   described by ASN.1 types.  This formal description can be exploited
   to identify component parts of an attribute value for a variety of
   purposes.  This document addresses attribute value matching.

   With any complex attribute syntax there is normally a requirement to
   partially match an attribute value of that syntax by matching only
   selected components of the value.  Typically, matching rules specific
   to the attribute syntax are defined to fill this need.  These highly
   specific matching rules usually only provide the most immediately
   useful matching capability.  Some complex attribute syntaxes don't
   even have an equality matching rule let alone any additional matching
   rules for partial matching.  This document defines a generic way of
   matching user selected components in an attribute value of any
   arbitrarily complex attribute syntax, where that syntax is described
   using ASN.1 type notation.  All of the type notations defined in [11]
   are supported.

   Section 4 5 describes the ComponentAssertion, a testable assertion
   about the value of a component of an attribute value of any complex
   syntax.

   Section 5 6 introduces the ComponentFilter assertion, which is an
   expression of ComponentAssertions.  The ComponentFilter enables more
   powerful filter matching of components in an attribute value.




Legg                    Expires 1 September 2002                [Page 3]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002

   Section 6 7 defines the componentFilterMatch matching rule, which
   enables a ComponentFilter to be evaluated against attribute values.

   Section 7 8 defines matching rules for component-wise equality matching
   of attribute values of any syntax described by an ASN.1 type
   definition.

   The native LDAP (i.e. "string") encodings for attribute syntaxes
   defined in ABNF do not clearly or consistently delineate the
   component parts of an attribute value.  A regular and uniform string
   encoding for arbitrary component data types is needed for

   Examples showing the
   assertion syntax usage of the componentFilterMatch matching rule. are in Section
   8 defines encoding rules, called 9.



Legg                    Expires 27 September 2002               [Page 3]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   For a new attribute syntax, the Generic String Encoding Rules or
   GSER, for a human readable text encoding (based on ASN.1 value
   notation) for an ASN.1 value of any ASN.1 type.  Though primarily
   intended for assertion syntaxes in component matching rules, these
   encoding rules could also be used for new attribute syntaxes, or in
   other domains where human readable renderings of ASN.1 values would
   be useful.  Note that "ASN.1 value" does not mean a BER encoded
   value.  The ASN.1 value is an abstract concept that is independent of
   any particular encoding.  BER is just one possible encoding of an
   ASN.1 value.  The component matching rules operate at the abstract
   level without regard for the possible encodings of a value.

   Examples showing the usage of componentFilterMatch are in Section 9.

   For a new attribute syntax, [7] and
   the specifications in sections 4 5 to 8 of this document make it
   possible to fully and precisely define, the
   native LDAP LDAP-specific encoding,
   the LDAP and X.500 binary encoding (and possibly other encodings in
   the future, e.g. XML via XER), a suitable equality matching rule, and
   a comprehensive collection of component matching capabilities, by
   simply writing down an ASN.1 type definition for the syntax.  These
   implicit definitions are also automatically extended if the ASN.1
   type is later extended.  The algorithmic relationship between the
   ASN.1 type definition, the various encodings and the component
   matching behaviour makes directory server implementation support for
   the component matching rules amenable to automatic code generation
   from ASN.1 type definitions.

   Schema designers have the choice of storing related items of data as
   a single attribute value of a complex syntax in some entry, or as a
   subordinate entry where the related data items are stored as separate
   attribute values of simpler syntaxes.  The inability to search
   component parts of a complex syntax has been used as an argument for
   favouring the subordinate entries approach.  The component matching
   rules provide the analogous matching capability on an attribute value
   of a complex syntax that a search filter has on a subordinate entry.




Legg                    Expires 1 September 2002                [Page 4]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002

   Most LDAP syntaxes have corresponding ASN.1 type definitions, though
   they are usually not reproduced or referenced alongside the formal
   definition of the LDAP syntax.  Syntaxes defined with only a
   character string encoding, i.e. without an explicit or implied
   corresponding ASN.1 type definition, cannot use the component
   matching capabilities described in this document unless and until a
   semantically equivalent ASN.1 type definition is defined for them.

   In the remainder of


4. Conventions

   Throughout this document "type" will shall be taken to mean an ASN.1 type
   unless explicitly qualified as an attribute type, and "value" will shall
   be taken to mean an ASN.1 value unless explicitly qualified as an
   attribute value.

   Note that "ASN.1 value" does not mean a BER [19] encoded value.  The
   ASN.1 value is an abstract concept that is independent of any
   particular encoding.  BER is just one possible encoding of an ASN.1
   value.  The component matching rules operate at the abstract level
   without regard for the possible encodings of a value.

   Attribute type and matching rule definitions in this document are
   provided in both the X.500 [8] and LDAP [5] [4] description formats. Note
   that the LDAP descriptions have been rendered with additional white-
   space



Legg                    Expires 27 September 2002               [Page 4]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   white-space and line breaks for the sake of readability.


4.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and  "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].


5. ComponentAssertion

   A ComponentAssertion is an assertion about the presence, or values
   of, components within an ASN.1 value, i.e. an instance of an ASN.1
   type.  The ASN.1 value is typically an attribute value, where the
   ASN.1 type is the syntax of the attribute.  However a
   ComponentAssertion may also be applied to a component part of an
   attribute value.  The assertion evaluates to either TRUE, FALSE or
   undefined for each tested ASN.1 value.

   A ComponentAssertion is described by the following ASN.1 type
   (assumed to be defined with "EXPLICIT TAGS" in force):

      ComponentAssertion ::= SEQUENCE {
          component         ComponentReference,
          useDefaultValues  BOOLEAN DEFAULT TRUE,
          rule              MATCHING-RULE.&id,
          value             MATCHING-RULE.&AssertionType }

      ComponentReference ::= UTF8String

   MATCHING-RULE.&id equates to the OBJECT IDENTIFIER of a matching
   rule.  MATCHING-RULE.&AssertionType is an open type (formally known
   as the ANY type).

   The "component" field of a ComponentAssertion identifies which
   component part of a value of some ASN.1 type is to be tested, the
   "useDefaultValues" field indicates whether DEFAULT values are to be
   substituted for absent component values, the "rule" field indicates



Legg                    Expires 1 September 2002                [Page 5]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002
   how the component is to be tested, and the "value" field is an
   asserted ASN.1 value against which the component is tested.  The
   ASN.1 type of the asserted value is determined by the chosen rule.

   The fields of a ComponentAssertion are described in detail in the
   following sections.


4.1


5.1 Component Reference

   The component field in a ComponentAssertion is a UTF8 character
   string [7] [6] whose textual content is a component reference,
   identifying a



Legg                    Expires 27 September 2002               [Page 5]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   identifying a component part of some ASN.1 type or value.  A
   component reference conforms to the following ABNF [3], [2], which extends
   the notation defined in Clause 14 of [11]:

      component-reference = ComponentId *( "." ComponentId )
      ComponentId         = identifier /
                            from-beginning /
                            count /
                            from-end /       ; extends Clause 14
                            content /        ; extends Clause 14
                            select /         ; extends Clause 14
                            all

      identifier          = lowercase *alphanumeric
                               *(hyphen 1*alphanumeric)
      alphanumeric        = uppercase / lowercase / decimal-digit
      uppercase           = %x41-5A  ; "A" to "Z"
      lowercase           = %x61-7A  ; "a" to "z"
      hyphen              = "-"

      from-beginning      = positive-number
      count               = "0"
      from-end            = "-" positive-number
      content             = %x63.6F.6E.74.65.6E.74 ; "content"
      select              = "(" Value *( "," Value ) ")"
      all                 = "*"


      positive-number     = non-zero-digit *decimal-digit

      decimal-digit       = %x30-39  ; "0" to "9"
      non-zero-digit      = %x31-39  ; "1" to "9"

   An <identifier> conforms to the definition of an identifier in ASN.1
   notation (Clause 11.3 of [11]).  It begins with a lowercase letter
   and is followed by zero or more letters, digits, and hyphens.  A



Legg                    Expires 1 September 2002                [Page 6]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002
   hyphen is not permitted to be the last character and a hyphen is not
   permitted to be followed by another hyphen.

   The <Value> rule is described in Section 8. [7].

   A component reference is a sequence of one or more ComponentIds where
   each successive ComponentId identifies either an inner component at
   the next level of nesting of an ASN.1 combining type, i.e. SET,
   SEQUENCE, SET OF, SEQUENCE OF, or CHOICE, or a specific type within
   an ASN.1 open type.

   A component reference is always considered in the context of a



Legg                    Expires 27 September 2002               [Page 6]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   particular complex ASN.1 type.  When applied to the ASN.1 type the
   component reference identifies a specific component type.  When
   applied to a value of the ASN.1 type a component reference identifies
   zero, one or more component values of that component type.  The
   component values are potentially in a DEFAULT value if
   useDefaultValues is TRUE.  The specific component type identified by
   the component reference determines what matching rules are capable of
   being used to match the component values.

   An empty string for a component reference, which would identify the
   whole ASN.1 value, is NOT supported since assertions about a whole
   value are already possible by the direct application of a matching
   rule to an attribute value.

   A valid component reference for a particular complex ASN.1 type is
   constructed by starting with the outermost combining type and
   repeatedly selecting one of the permissible forms of ComponentId to
   identify successively deeper nested components.  A component
   reference MAY identify a component with a complex ASN.1 type, i.e. it
   is NOT required that the component type identified by a component
   reference be a simple ASN.1 type.


4.1.1


5.1.1 Component Type Substitutions

   ASN.1 type notation has a number of constructs for referencing other
   defined types, and constructs that are irrelevant for matching
   purposes.  These constructs are not represented in a component
   reference in any way and substitutions of the component type are
   performed to eliminate them from further consideration.  These
   substitutions automatically occur prior to each ComponentId, whether
   constructing or interpreting a component reference, but do not occur
   after the last ComponentId, except as allowed by Section 4.2. 5.2.

   If the ASN.1 type is an ASN.1 type reference then the component type
   is taken to be the actual definition on the right hand side of the



Legg                    Expires 1 September 2002                [Page 7]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002
   type assignment for the referenced type.

   If the ASN.1 type is a tagged type then the component type is taken
   to be the type without the tag.

   If the ASN.1 type is a constrained type (see [11] and [14] for the
   details of ASN.1 constraint notation). notation) then the component type is
   taken to be the type without the constraint.

   If the ASN.1 type is an ObjectClassFieldType (Clause 14 of [13]) that
   denotes a specific ASN.1 type (e.g. MATCHING-RULE.&id denotes the
   OBJECT IDENTIFIER type) then the component type is taken to be the



Legg                    Expires 27 September 2002               [Page 7]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   denoted type.  Section 4.1.6 5.1.6 describes the case where the
   ObjectClassFieldType denotes an open type.

   If the ASN.1 type is a selection type other than one used in the list
   of components for a SET or SEQUENCE type then the component type is
   taken to be the selected alternative type from the named CHOICE.

   If the ASN.1 type is a TypeFromObject (Clause 15 of [13]) then the
   component type is taken to be the denoted type.

   If the ASN.1 type is a ValueSetFromObjects (Clause 15 of [13]) then
   the component type is taken to be the governing type of the denoted
   values.


4.1.2


5.1.2 Referencing SET, SEQUENCE and CHOICE Components

   If the ASN.1 type is a SET or SEQUENCE type then the <identifier>
   form of ComponentId MAY be used to identify the component type within
   that SET or SEQUENCE having that identifier.  If <identifier>
   references an OPTIONAL component type and that component is not
   present in a particular value then there are no corresponding
   component values.  If <identifier> references a DEFAULT component
   type and useDefaultValues is TRUE (the default setting for
   useDefaultValues) and that component is not present in a particular
   value then the component value is taken to be the default value.  If
   <identifier> references a DEFAULT component type and useDefaultValues
   is FALSE and that component is not present in a particular value then
   there are no corresponding component values.

   If the ASN.1 type is a CHOICE type then the <identifier> form of
   ComponentId MAY be used to identify the alternative type within that
   CHOICE having that identifier.  If <identifier> references an
   alternative other than the one used in a particular value then there
   are no corresponding component values.




Legg                    Expires 1 September 2002                [Page 8]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002

   The COMPONENTS OF notation in Clause 24 of [11] augments the defined
   list of components in a SET or SEQUENCE type by including all the
   components of another defined SET or SEQUENCE type respectively.
   These included components are referenced directly by identifier as
   though they were defined in-line in the SET or SEQUENCE type
   containing the COMPONENTS OF notation.

   The SelectionType (Clause 29 of [11]), when used in the list of
   components for a SET or SEQUENCE type, includes a single component
   from a defined CHOICE type.  This included component is referenced
   directly by identifier as though it was defined in-line in the SET or
   SEQUENCE type.



Legg                    Expires 27 September 2002               [Page 8]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   The REAL type is treated as though it is the SEQUENCE type defined in
   Clause 20.5 of [11].

   The EMBEDDED PDV type is treated as though it is the SEQUENCE type
   defined in Clause 32.5 of [11].

   The EXTERNAL type is treated as though it is the SEQUENCE type
   defined in Clause 33.5 of [11].

   The unrestricted CHARACTER STRING type is treated as though it is the
   SEQUENCE type defined in Clause 39.5 of [11].

   The INSTANCE OF type is treated as though it is the SEQUENCE type
   defined in Annex C of [13].

   The <identifier> form MUST NOT be used on any other ASN.1 type.


4.1.3


5.1.3 Referencing SET OF and SEQUENCE OF Components

   If the ASN.1 type is a SET OF or SEQUENCE OF type then the <from-
   beginning>,
   <from-beginning>, <from-end>, <count> and <all> forms of ComponentId
   can be used.

   The <from-beginning> form of ComponentId MAY be used to identify one
   instance (i.e. value) of the component type of the SET OF or SEQUENCE
   OF type (e.g. if Foo ::= SET OF Bar, then Bar is the component type),
   where the instances are numbered from one upwards.  If <from-
   beginning>
   <from-beginning> references a higher numbered instance than the last
   instance in a particular value of the SET OF or SEQUENCE OF type then
   there is no corresponding component value.

   The <from-end> form of ComponentId MAY be used to identify one
   instance of the component type of the SET OF or SEQUENCE OF type,
   where "-1" is the last instance, "-2" is the second last instance,



Legg                    Expires 1 September 2002                [Page 9]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002
   and so on.  If <from-end> references a lower numbered instance than
   the first instance in a particular value of the SET OF or SEQUENCE OF
   type then there is no corresponding component value.

   The <count> form of ComponentId identifies a notional count of the
   number of instances of the component type in a value of the SET OF or
   SEQUENCE OF type.  This count is not explicitly represented but for
   matching purposes it has an assumed ASN.1 type of INTEGER (0..MAX).
   A ComponentId of the <count> form MUST be the last ComponentId in a
   component reference.

   The <all> form of ComponentId MAY be used to simultaneously identify
   all instances of the component type of the SET OF or SEQUENCE OF



Legg                    Expires 27 September 2002               [Page 9]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   type.  It is through the <all> form that a component reference can
   identify more than one component value.  However, if a particular
   value of the SET OF or SEQUENCE OF type is an empty list there are no
   corresponding component values.

   Where multiple component values are identified, the remaining
   ComponentIds in the component reference, if any, can identify zero,
   one or more subcomponent values for each of the higher level
   component values.

   The corresponding ASN.1 type for the <from-beginning>, <from-end>,
   and <all> forms of ComponentId is the component type of the SET OF or
   SEQUENCE OF type.

   The <from-beginning>, <count>, <from-end> and <all> forms MUST NOT be
   used on ASN.1 types other than SET OF or SEQUENCE OF.


4.1.4


5.1.4 Referencing Components of Parameterized Types

   A component reference cannot be formed for a parameterized type
   unless the type has been used with actual parameters, in which case
   the type is treated as though the DummyReferences [15] have been
   substituted with the actual parameters.


4.1.5


5.1.5 Component Referencing Example

   Consider the following ASN.1 type definitions.

      ExampleType ::= SEQUENCE {
          part1       [0] INTEGER,
          part2       [1] ExampleSet,
          part3       [2] SET OF OBJECT IDENTIFIER,
          part4       [3] ExampleChoice }



Legg                    Expires 1 September 2002               [Page 10]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002

      ExampleSet ::= SET {
          option      PrintableString,
          setting     BOOLEAN }

      ExampleChoice ::= CHOICE {
          eeny-meeny  BIT STRING,
          miney-mo    OCTET STRING }

   Following are component references constructed with respect to the
   type ExampleType.

   The component reference "part1" identifies a component of a value of



Legg                    Expires 27 September 2002              [Page 10]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   ExampleType having the ASN.1 tagged type [0] INTEGER.

   The component reference "part2" identifies a component of a value of
   ExampleType having the ASN.1 type of [1] ExampleSet

   The component reference "part2.option" identifies a component of a
   value of ExampleType having the ASN.1 type of PrintableString.  A
   ComponentAssertion could also be applied to a value of ASN.1 type
   ExampleSet, in which case the component reference "option" would
   identify the same kind of information.

   The component reference "part3" identifies a component of a value of
   ExampleType having the ASN.1 type of [2] SET OF OBJECT IDENTIFIER.

   The component reference "part3.2" identifies the second instance of
   the part3 SET OF.  The instance has the ASN.1 type of OBJECT
   IDENTIFIER.

   The component reference "part3.0" identifies the count of the number
   of instances in the part3 SET OF.  The count has the corresponding
   ASN.1 type of INTEGER (0..MAX).

   The component reference "part3.*" identifies all the instances in the
   part3 SET OF.  Each instance has the ASN.1 type of OBJECT IDENTIFIER.

   The component reference "part4" identifies a component of a value of
   ExampleType having the ASN.1 type of [3] ExampleChoice.

   The component reference "part4.miney-mo" identifies a component of a
   value of ExampleType having the ASN.1 type of OCTET STRING.


4.1.6


5.1.6 Referencing Components of Open Types

   If a sequence of ComponentIds identifies an ObjectClassFieldType
   denoting an open type (e.g. ATTRIBUTE.&Type denotes an open type)



Legg                    Expires 1 September 2002               [Page 11]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002
   then the ASN.1 type of the component varies.  An open type is
   typically constrained by some other component(s) in an outer
   enclosing type, either formally through the use of a component
   relation constraint [14], or informally in the accompanying text, so
   the actual ASN.1 type of a value of the open type will generally be
   known.  The constraint will also limit the range of permissible
   types.  The <select> form of ComponentId MAY be used to identify one
   of these permissible types in an open type.  Subcomponents of that
   type can then be identified with further ComponentIds.

   The other components constraining the open type are termed the
   referenced components (using the terminology in [14]).  The <select>



Legg                    Expires 27 September 2002              [Page 11]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   form contains a list of one or more values which take the place of
   the value(s) of the referenced component(s) to uniquely identify one
   of the permissable types of the open type.

   Where the open type is constrained by a component relation
   constraint, there is a <Value> in the <select> form for each of the
   referenced components in the component relation constraint, appearing
   in the same order.  The ASN.1 type of each of these values is the
   same as the ASN.1 type of the corresponding referenced component.
   The type of a referenced component is potentially any ASN.1 type
   however it is typically an OBJECT IDENTIFIER or INTEGER, which means
   that the <Value> in the <select> form of ComponentId will nearly
   always be an <ObjectIdentifierValue> or <IntegerValue> (see Section
   8). [7]).
   Furthermore, component relation constraints typically have only one
   referenced component.

   Where the open type is not constrained by a component relation
   constraint, the specification introducing the syntax containing the
   open type SHOULD explicitly nominate the referenced components and
   their order, so that the <select> form can be used.

   If an instance of <select> contains a value other than the value of
   the referenced component used in a particular value of the outer
   enclosing type then there are no corresponding component values for
   the open type.


4.1.6.1


5.1.6.1 Open Type Referencing Example

   The ASN.1 type AttributeTypeAndValue from [8] describes a single
   attribute value of a nominated attribute type.

      AttributeTypeAndValue ::= SEQUENCE {
          type    ATTRIBUTE.&id ({SupportedAttributes}),
          value   ATTRIBUTE.&Type ({SupportedAttributes}{@type}) }




Legg                    Expires 1 September 2002               [Page 12]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002

   ATTRIBUTE.&id denotes an OBJECT IDENTIFIER and
   ({SupportedAttributes}) constrains the OBJECT IDENTIFIER to be a
   supported attribute type.

   ATTRIBUTE.&Type denotes an open type, in this case an attribute
   value, and ({SupportedAttributes}{@type}) is a component relation
   constraint that constrains the open type to be of the attribute
   syntax for the attribute type.  The component relation constraint
   references only the "type" component, which has the ASN.1 type of
   OBJECT IDENTIFIER, thus if the <select> form of ComponentId is used
   to identify attribute values of specific attribute types it will
   contain a single OBJECT IDENTIFIER value.



Legg                    Expires 27 September 2002              [Page 12]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   The component reference "value" on AttributeTypeAndValue refers to
   the open type.

   One of the X.500 standard attributes is facsimileTelephoneNumber
   [10], which is identified with the OBJECT IDENTIFIER 2.5.4.23, and is
   defined to have the following syntax.

      FacsimileTelephoneNumber ::= SEQUENCE {
          telephoneNumber  PrintableString (SIZE(1.. ub-telephone-number)), PrintableString(SIZE(1..ub-telephone-number)),
          parameters      G3FacsimileNonBasicParameters OPTIONAL }

   The component reference "value.(2.5.4.23)" on AttributeTypeAndValue
   specifies an attribute value with the FacsimileTelephoneNumber
   syntax.

   The component reference "value.(2.5.4.23).telephoneNumber" on
   AttributeTypeAndValue identifies the telephoneNumber component of a
   facsimileTelephoneNumber attribute value.  The component reference
   "value.(facsimileTelephoneNumber)" is equivalent to
   "value.(2.5.4.23)".

   If the AttributeTypeAndValue ASN.1 value contains an attribute type
   other than facsimileTelephoneNumber then there are no corresponding
   component values for the component references "value.(2.5.4.23)" and
   "value.(2.5.4.23).telephoneNumber".


4.1.7


5.1.7 Referencing Contained Types

   Sometimes the contents of a BIT STRING or OCTET STRING value are
   required to be the encodings of other ASN.1 values of specific ASN.1
   types.  For example, the extnValue component of the Extension type
   component in the Certificate type [9] is an OCTET STRING that is
   required to contain a DER encoding of a certificate extension value.
   It is useful to be able to refer to the embedded encoded value and



Legg                    Expires 1 September 2002               [Page 13]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002
   its components.  An embedded encoded value is here referred to as a
   contained value and its associated type as the contained type.

   If the ASN.1 type is a BIT STRING or OCTET STRING type containing
   encodings of other ASN.1 values then the <content> form of
   ComponentId MAY be used to identify the contained type.
   Subcomponents of that type can then be identified with further
   ComponentIds.

   The contained type may be (effectively) an open type, constrained by
   some other component in an outer enclosing type (e.g. in a
   certificate Extension, extnValue is constrained by the chosen
   extnId).  In these cases the next ComponentId, if any, MUST be of the



Legg                    Expires 27 September 2002              [Page 13]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   <select> form.

   For the purpose of building component references, the content of the
   extnValue OCTET STRING in the Extension type is assumed to be an open
   type having a notional component relation constraint with the extnId
   component as the single referenced component, i.e.

      EXTENSION.&ExtnType ({ExtensionSet}{@extnId})

   The data-value component of the associated types for the EXTERNAL,
   EMBEDDED PDV and CHARACTER STRING types is an OCTET STRING containing
   the encoding of a data value described by the identification
   component.  For the purpose of building component references, the
   content of the data-value OCTET STRING in these types is assumed to
   be an open type having a notional component relation constraint with
   the identification component as the single referenced component.


4.1.7.1


5.1.7.1 Contained Type Referencing Example

   The Extension ASN.1 type from [9] describes a single certificate
   extension value of a nominated extension type.

      Extension ::= SEQUENCE {
          extnId     EXTENSION.&id ({ExtensionSet}),
          critical   BOOLEAN DEFAULT FALSE,
          extnValue  OCTET STRING
              -- contains a DER encoding of a value of type &ExtnType
              -- for the extension object identified by extnId -- }

   EXTENSION.&id denotes an OBJECT IDENTIFIER and ({ExtensionSet})
   constrains the OBJECT IDENTIFIER to be the identifier of a supported
   certificate extension.

   The component reference "extnValue" on Extension refers to a



Legg                    Expires 1 September 2002               [Page 14]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002
   component type of OCTET STRING.  The corresponding component values
   will be OCTET STRING values.  The component reference
   "extnValue.content" on Extension refers to the type of the contained
   type, which in this case is an open type.

   One of the X.509 [X.509] standard extensions is basicConstraints,
   which is identified with the OBJECT IDENTIFIER 2.5.29.19 and is
   defined to have the following syntax.

      BasicConstraintsSyntax ::= SEQUENCE {
          cA                 BOOLEAN DEFAULT FALSE,
          pathLenConstraint  INTEGER (0..MAX) OPTIONAL }




Legg                    Expires 27 September 2002              [Page 14]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   The component reference "extnValue.content.(2.5.29.19)" on Extension
   specifies a BasicConstraintsSyntax extension value and the component
   reference "extnValue.content.(2.5.29.19).cA" identifies the cA
   component of a BasicConstraintsSyntax extension value.


4.2


5.2 Matching of Components

   The rule in a ComponentAssertion specifies how the zero, one or more
   component values identified by the component reference are tested by
   the assertion.  Attribute matching rules are used to specify the
   semantics of the test.

   Each matching rule has a notional set of attribute syntaxes
   (typically one), defined as ASN.1 types, to which it may be applied.
   When used in a ComponentAssertion these matching rules apply to the
   same ASN.1 types, only in this context the corresponding ASN.1 values
   are not complete attribute values.

   Note that the referenced component type may be a tagged and/or
   constrained version of the expected attribute syntax (e.g. [0]
   INTEGER, whereas integerMatch would expect simply INTEGER), or an
   open type.  Additional type substitutions of the kind described in
   Section 4.1.1 5.1.1 are performed as required to reduce the component type
   to the same type as the attribute syntax expected by the matching
   rule.  If an open type is encountered the actual ASN.1 type of the
   component value is substituted before continuing.

   If a matching rule applies to more than one attribute syntax (e.g.
   objectIdentifierFirstComponentMatch [10]) then the minimum number of
   substitutions required to conform to any one of those syntaxes are
   performed.  If a matching rule can apply to any attribute syntax
   (e.g. the allComponentsMatch rule defined in Section 7.1) 8.1) then the
   referenced component type is used as is, with no additional
   substitutions.



Legg                    Expires 1 September 2002               [Page 15]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002

   The value in a ComponentAssertion will be of the assertion syntax
   (i.e. ASN.1 type) required by the chosen matching rule.  Note that
   the assertion syntax of a matching rule is not necessarily the same
   as the attribute syntax(es) to which the rule may be applied.

   Some matching rules do not have a fixed assertion syntax (e.g.
   allComponentsMatch).  The required assertion syntax is determined in
   each instance of use by the syntax of the attribute type to which the
   matching rule is applied.  For these rules the ASN.1 type of the
   referenced component is used in place of an attribute syntax to
   decide the required assertion syntax.




Legg                    Expires 27 September 2002              [Page 15]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   The ComponentAssertion is undefined if:

   i)

   a) the matching rule in the ComponentAssertion is not known to the
      evaluating procedure,

   ii)

   b) if no part of the component reference identifies an open type and
      the matching rule is not applicable to the referenced component
      type, even with the additional type substitutions,

   iii)

   c) the value in the ComponentAssertion does not conform to the
      assertion syntax defined for the matching rule,

   iv)

   d) an open type in the tested value cannot be decoded, or

   v)

   e) the implementation does not support the particular combination of
      component reference and matching rule.

   If the ComponentAssertion is not undefined then the
   ComponentAssertion evaluates to TRUE if there is at least one
   component value for which the matching rule applied to that component
   value returns TRUE, and evaluates to FALSE otherwise (which includes
   the case where there are no component values).

   If some part of the component reference identifies an open type and
   the matching rule is not applicable to the referenced component type
   the ComponentAssertion evaluates to FALSE.


4.2.1


5.2.1 Applicability of Existing Matching Rules

4.2.1.1

5.2.1.1 String Matching

   ASN.1 has a number of built in restricted character string types with
   different character sets and/or different character encodings.  A
   directory user generally has little interest in the particular
   character set or encoding used to represent a character string



Legg                    Expires 1 September 2002               [Page 16]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002
   component value, and some directory server implementations make no
   distinction between the different string types in their internal
   representation of values.  So rather than define string matching
   rules for each of the restricted character string types, the existing
   case ignore and case exact string matching rules are extended to
   apply to component values of any of the restricted character string
   types,
   types and any ChoiceOfStrings type [7], in addition to component
   values of the DirectoryString type.  This extension is only for the
   purposes of component matching described in this document.

   The relevant string matching rules are: caseIgnoreMatch,
   caseIgnoreOrderingMatch, caseIgnoreSubstringsMatch, caseExactMatch,



Legg                    Expires 27 September 2002              [Page 16]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   caseExactOrderingMatch and caseExactSubstringsMatch.  The relevant
   restricted character string types are: NumericString,
   PrintableString, VisibleString, IA5String, UTF8String, BMPString,
   UniversalString, TeletexString, VideotexString, GraphicString and
   GeneralString.  A ChoiceOfStrings type is a purely syntactic CHOICE
   of these ASN.1 string types.  Note that [7] declares each and every
   use of the DirectoryString{} parameterized type to be a
   ChoiceOfStrings type.

   The assertion syntax of the string matching rules is still
   DirectoryString regardless of the string syntax of the component
   being matched.  Thus an implementation will be called upon to compare
   a DirectoryString value to a value of one of the restricted character
   string types. types, or a ChoiceOfStrings type.  As is the case when
   comparing two DirectoryStrings where the chosen alternatives are of
   different string types, the comparison proceeds so long as the
   corresponding characters are representable in both character sets.
   Otherwise matching returns FALSE.

   It is not uncommon for ASN.1 specifications to define types that are


5.2.1.2 Telephone Number Matching

   Early editions of X.520 [10] gave the syntax of the telephoneNumber
   attribute as a CHOICE between two or more alternative constrained PrintableString.  The fourth edition of
   X.520 equates the ASN.1 string types, where type name TelephoneNumber to the particular alternative chosen carries no semantic significance
   (DirectoryString being a prime example).  Such types constrained
   PrintableString and uses TelephoneNumber as the attribute and
   assertion syntax.  For the purposes of component matching,
   telephoneNumberMatch and telephoneNumberSubstringsMatch are defined permitted
   to
   avoid having be applied to use a complicated character encoding for all values
   when most values could use a simpler string type, or any PrintableString value, as well as to deal with
   evolving requirements that compel the use of a broader character set
   while still maintaining backward compatibility.  It
   TelephoneNumber values.


5.2.1.3 Distinguished Name Matching

   The DistinguishedName type is convenient defined by assignment to
   also be able to use the existing character string matching rules on
   types that are a purely syntactic choice of string types.

   While there are certain ASN.1 constructs that betray the semantic
   significance of same as
   the alternatives within a CHOICE RDNSequence type, however RDNSequence is sometimes directly used
   in other type definitions.  For the absence purposes of
   those constructs does not necessarily mean a CHOICE type is purely
   syntactic.  Therefore, it component matching,
   distinguishedNameMatch is necessary for specifications also permitted to declare
   the purely syntactic CHOICE types so that they may be matched with applied to values of
   the existing string RDNSequence type.


5.2.2 Additional Useful Matching Rules

   This section defines additional matching rules. rules that may prove useful
   in ComponentAssertions.  These CHOICE types will be
   referred to as ChoiceOfStrings types.  The string matching rules
   above are extended to MAY also apply to any ChoiceOfStrings type. be used in
   extensibleMatch search filters [3].





Legg                    Expires 1 27 September 2002              [Page 17]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 1, 27, 2002


   To be eligible


5.2.2.1 The rdnMatch Matching Rule

   The distinguishedNameMatch matching rule can match whole
   distinguished names but it is sometimes useful to be declared able to match
   specific RDNs in a ChoiceOfStrings type an ASN.1 type
   MUST satisfy DN without regard for the following conditions.

   i) The type is a CHOICE type.

   ii) other RDNs in the DN.
   The rdnMatch matching rule allows component type RDNs of each alternative is one a DN to be
   tested.

   The LDAP-style definitions for rdnMatch and its assertion syntax are:

      ( 1.2.36.79672281.1.13.3 NAME 'rdnMatch'
          SYNTAX 1.2.36.79672281.1.5.0 )

      ( 1.2.36.79672281.1.5.0 DESC 'RDN' )

   The LDAP-specific encoding for a value of the following
   ASN.1 restricted string types: NumericString, PrintableString,
   TeletexString (T61String), VideotexString, IA5String, GraphicString,
   VisibleString (ISO646String), GeneralString, BMPString,
   UniversalString or UTF8String.

   iii) All the alternatives are of different restricted string types,
   i.e. no two alternatives have the same ASN.1 restricted string type.

   iv) Either none of the alternatives has a constraint, or all of the
   alternatives have exactly the same constraint.

   Tagging on the alternative types RDN syntax is ignored.

   Consider given by
   the ASN.1 parameterized type <RelativeDistinguishedNameValue> rule in [7].

   The X.500-style definition of DirectoryString.

   DirectoryString { INTEGER : maxSize } for rdnMatch is:

      rdnMatch MATCHING-RULE ::= CHOICE {
       teletexString     TeletexString (SIZE (1..maxSize)),
       printableString   PrintableString (SIZE (1..maxSize)),
       bmpString         BMPString (SIZE (1..maxSize)),
       universalString   UniversalString (SIZE (1..maxSize)),
       uTF8String        UTF8String (SIZE (1..maxSize))
          SYNTAX  RelativeDistinguishedName
          ID      { 1 2 36 79672281 1 13 3 } }

   Any use of the DirectoryString parameterized type with an actual
   parameter defines a ASN.1 type that satisfies the above conditions.
   Recognising that the alternative within a DirectoryString carries no
   semantic significance, this document declares (each and every use of)
   DirectoryString{} to be a ChoiceOfStrings type.

   Other specifications MAY declare other types satisfying the above
   conditions to be ChoiceOfStrings types.

   The declaration SHOULD be
   made at rdnMatch rule evaluates to true if the point where component value and
   assertion value are the ASN.1 type is defined, otherwise it
   SHOULD be made at same RDN, using the point where same RDN comparison
   method as distinguishedNameMatch.

   When using rdnMatch to match components of DNs it is introduced as, or in, an
   attribute syntax.


4.2.1.2 Telephone Number Matching

   Early editions of X.520 [10] gave important to
   note that the syntax LDAP-specific encoding of the telephoneNumber
   attribute as a constrained PrintableString.  The fourth edition DN [5] reverses the order
   of
   X.520 equates the ASN.1 type name TelephoneNumber to RDNs.  So for the constrained
   PrintableString and uses TelephoneNumber DN represented in LDAP as "cn=Steven
   Legg,o=Adacel,c=AU", the attribute and
   assertion syntax.  For RDN "cn=Steven Legg" corresponds to the purposes of
   component matching, reference "3", or alternatively, "-1".


5.2.2.2 The OpenAssertionType Syntax

   Some of the matching rules defined in this document have a variable
   assertion syntax.  In X.500 this is indicated by omitting the
   optional SYNTAX field in the MATCHING-RULE information object.  The
   assertion syntax then defaults to the target attribute's syntax in
   actual usage, unless the description of the matching rule says
   otherwise.  The SYNTAX field in the LDAP-specific encoding of a
   MatchingRuleDescription is mandatory, so the OpenAssertionType syntax
   is defined to fill the same role.  That is, the OpenAssertionType
   syntax is semantically equivalent to an omitted SYNTAX field in an
   X.500 MATCHING-RULE information object.  OpenAssertionType MUST NOT
   be used as the attribute syntax in an attribute type definition.



Legg                    Expires 1 27 September 2002              [Page 18]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 1, 27, 2002


   telephoneNumberMatch and telephoneNumberSubstringsMatch are permitted
   to be applied to any PrintableString value, as well as to
   TelephoneNumber values.


4.2.1.3 Distinguished Name Matching

   The DistinguishedName type


   Unless explicitly varied by the description of a particular matching
   rule, if an OpenAssertionType assertion value appears in a
   ComponentAssertion its LDAP-specific encoding is defined described by assignment the
   <Value> rule in [7], otherwise its LDAP-specific encoding is the
   encoding defined for the syntax of the attribute type to be which the same as
   matching rule with the RDNSequence type, however RDNSequence OpenAssertionType assertion syntax is sometimes directly used
   in other type definitions.  For applied.

   The LDAP definition for the purposes of component matching,
   distinguishedNameMatch OpenAssertionType syntax is:

      ( 1.2.36.79672281.1.5.3 DESC 'OpenAssertionType' )


5.2.2.3 The enumeratedMatch Matching Rule

   There is also permitted to no existing matching rule that could be applied used to values match a
   value of
   the RDNSequence an arbitrary ENUMERATED type.


4.2.2 Additional Useful Matching Rules

   This section defines additional matching rules that may prove useful
   in ComponentAssertions.  These rules MAY also be used in
   extensibleMatch search filters [4].


4.2.2.1 The rdnMatch Matching Rule  The distinguishedNameMatch enumeratedMatch matching
   rule can match whole
   distinguished names but it is sometimes useful defined to fill this role.  It may be able applied to match
   specific RDNs in a DN without regard for the other RDNs in the DN.
   The rdnMatch matching rule allows component RDNs values of
   any ENUMERATED type, or any INTEGER type (typically those with a DN to be
   tested.
   named number list).

   The LDAP-style definitions definition for rdnMatch and its assertion syntax are: enumeratedMatch is:

      ( 1.2.36.79672281.1.13.3 1.2.36.79672281.1.13.4 NAME 'rdnMatch' 'enumeratedMatch'
          SYNTAX 1.2.36.79672281.1.5.0 )

   ( 1.2.36.79672281.1.5.0 DESC 'RDN' 1.2.36.79672281.1.5.3 )

   The native LDAP encoding for

   This matching rule has a value variable assertion syntax.  Since
   enumeratedMatch only applies to values of an ENUMERATED or INTEGER
   type, the RDN syntax LDAP-specific encoding for an enumeratedMatch assertion
   value appearing in a ComponentAssertion is effectively constrained to
   the string encoding given by
   <RelativeDistinguishedNameValue> the <EnumeratedValue> rule or the
   <IntegerValue> rule respectively, in Section 8. [7].

   The X.500-style definition for rdnMatch enumeratedMatch is:

   rdnMatch

      enumeratedMatch MATCHING-RULE ::= {
       SYNTAX  RelativeDistinguishedName
          ID      { 1 2 36 79672281 1 13 3 4 } }

   The rdnMatch enumeratedMatch rule evaluates to true if the component value and
   assertion value are the same RDN, using the same RDN comparison
   method same.

   The enumeratedMatch rule MAY be used as distinguishedNameMatch. the equality matching rule
   for an attribute.


5.2.2.4 The presentMatch Matching Rule

   At times it would be useful to test not if a specific value of a
   particular component is present, but whether any value of a



Legg                    Expires 1 27 September 2002              [Page 19]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 1, 27, 2002


   When using rdnMatch to match components of DNs it


   particular component is important to
   note that present.  The presentMatch matching rule
   allows the native LDAP encoding presence of a DN [6] reverses the order of
   the RDNs.  So for the DN represented in LDAP as "cn=Steven
   Legg,o=Adacel,c=AU", the RDN "cn=Steven Legg" corresponds to the particular component reference "3", or alternatively, "-1".


4.2.2.2 value to be tested.

   The OpenAssertionType Syntax

   Some of the matching rules defined in this document have a variable LDAP-style definitions for presentMatch and its assertion syntax.  In X.500 this is indicated by omitting the
   optional syntax
   are:

      ( 1.2.36.79672281.1.13.5 NAME 'presentMatch'
          SYNTAX field in the MATCHING-RULE information object. 1.2.36.79672281.1.5.1 )

      ( 1.2.36.79672281.1.5.1 DESC 'NULL' )

   The
   assertion syntax then defaults to LDAP-specific encoding for a value of the target attribute's NULL syntax in
   actual usage, unless the description of is given by
   the matching <NullValue> rule says
   otherwise. in [7].

   The X.500-style definition for presentMatch is:

      presentMatch MATCHING-RULE ::= {
          SYNTAX field  NULL
          ID      { 1 2 36 79672281 1 13 5 } }

   When used in a extensible match filter item, presentMatch behaves
   like the native LDAP encoding "present" case of a
   MatchingRuleDescription is mandatory, so the OpenAssertionType syntax
   is defined regular search filter.  In a
   ComponentAssertion, presentMatch evaluates to fill TRUE if and only if the same role.  That is,
   component reference identifies one or more component values,
   regardless of the OpenAssertionType
   syntax actual component value contents.  Note that if
   useDefaultValues is semantically equivalent to an omitted SYNTAX field in an
   X.500 MATCHING-RULE information object.  OpenAssertionType MUST NOT
   be used as TRUE then the attribute syntax in an attribute type definition.

   Unless explicitly varied identified component values may be
   (part of) a DEFAULT value.

   The notional count referenced by the description <count> form of a particular matching
   rule, ComponentId is
   taken to be present if an OpenAssertionType assertion the SET OF value appears in a
   ComponentAssertion its native LDAP encoding is described by <Value> present, and absent
   otherwise.  Note that in Section 8, otherwise its native LDAP encoding ASN.1 notation an absent SET OF value is
   distinctly different from a SET OF value that is present but empty.
   It is up to the encoding
   defined for the syntax of specification using the attribute type ASN.1 notation to which the matching
   rule with decide
   whether the OpenAssertionType assertion syntax distinction matters.  Often an empty SET OF component and
   an absent SET OF component are treated as semantically equivalent.
   If a SET OF value is applied.

   The LDAP definition for present, but empty, a presentMatch on the OpenAssertionType syntax is:

   ( 1.2.36.79672281.1.5.3 DESC 'OpenAssertionType' )


4.2.2.3 The enumeratedMatch Matching Rule

   There is no existing matching rule that could SET OF
   component SHALL return TRUE and the notional count SHALL be used regarded
   as present and equal to match a
   value zero.


5.2.3 Summary of an arbitrary ENUMERATED type. Useful Matching Rules

   The enumeratedMatch matching
   rule following is defined to fill this role.  It may be applied to values of
   any ENUMERATED type, or any INTEGER type (typically those with a
   named number list).

   The LDAP-style definition for enumeratedMatch is:

   ( 1.2.36.79672281.1.13.4 NAME 'enumeratedMatch'
       SYNTAX 1.2.36.79672281.1.5.3 )

   This non-exhaustive list of useful matching rule has a variable assertion syntax.  Since
   enumeratedMatch only applies rules and
   the ASN.1 types to values which they can be applied, taking account of an ENUMERATED or INTEGER all
   the extensions described in Section 5.2.1, and the new matching rules
   defined in Section 5.2.2.





Legg                    Expires 1 27 September 2002              [Page 20]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 1, 27, 2002


   type, the native LDAP encoding for an enumeratedMatch assertion value
   appearing in a ComponentAssertion is effectively constrained to the
   string encoding given by <EnumeratedValue> or <IntegerValue>
   respectively, in Section 8.

   The X.500-style definition for enumeratedMatch is:

   enumeratedMatch MATCHING-RULE ::= {
       ID      { 1 2 36 79672281 1 13 4 } }

   The enumeratedMatch rule evaluates to true if the component value and
   assertion value are the same.

   The enumeratedMatch rule MAY be used as the equality matching rule
   for an attribute.


4.2.2.4 The presentMatch


      +================================+==============================+
      | Matching Rule

   At times it would be useful to test not if a specific value of a
   particular component is present, but whether                  | ASN.1 Type                   |
      +================================+==============================+
      | bitStringMatch                 | BIT STRING                   |
      +--------------------------------+------------------------------+
      | booleanMatch                   | BOOLEAN                      |
      +--------------------------------+------------------------------+
      | caseIgnoreMatch                | NumericString                |
      | caseIgnoreOrderingMatch        | PrintableString              |
      | caseIgnoreSubstringsMatch      | VisibleString (ISO646String) |
      | caseExactMatch                 | IA5String                    |
      | caseExactOrderingMatch         | UTF8String                   |
      | caseExactSubstringsMatch       | BMPString (UCS-2, UNICODE)   |
      |                                | UniversalString (UCS-4)      |
      |                                | TeletexString (T61String)    |
      |                                | VideotexString               |
      |                                | GraphicString                |
      |                                | GeneralString                |
      |                                | any value of a
   particular component is present.  The presentMatch matching rule
   allows the presence of a particular component value to be tested.

   The LDAP-style definitions for presentMatch and its assertion syntax
   are:

   ( 1.2.36.79672281.1.13.5 NAME 'presentMatch'
       SYNTAX 1.2.36.79672281.1.5.1 )

   ( 1.2.36.79672281.1.5.1 DESC 'NULL' )

   The native LDAP encoding for a value of the NULL syntax is given by
   <NullValue> in Section 8.

   The X.500-style definition for presentMatch is:

   presentMatch MATCHING-RULE ::= {
       SYNTAX  NULL
       ID      { 1 2 36 79672281 1 13 5 } }

   When used in a extensible match filter item, presentMatch behaves
   like the "present" case of a regular search filter.  In a
   ComponentAssertion, presentMatch evaluates to TRUE if and only if the
   component reference identifies one or more component values,
   regardless of the actual component value contents.  Note that if
   useDefaultValues is TRUE then the identified component values may be
   (part of) a DEFAULT value.



Legg                    Expires 1 September 2002               [Page 21]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002


   The notional count referenced by the <count> form of ComponentId is
   taken to be present if the SET OF value is present, and absent
   otherwise.  Note that in ASN.1 notation an absent SET OF value is
   distinctly different from a SET OF value that is present but empty.
   It is up to the specification using the ASN.1 notation to decide
   whether the distinction matters.  Often an empty SET OF component and
   an absent SET OF component are treated as semantically equivalent.
   If a SET OF value is present, but empty, a presentMatch on the SET OF
   component SHALL return TRUE and the notional count SHALL be regarded
   as present and equal to zero.


4.2.3 Summary of Useful Matching Rules

   The following is a non-exhaustive list of useful matching rules and
   the ASN.1 types to which they can be applied, taking account of all
   the extensions described within Section 4.2.1, and the new matching
   rules defined in Section 4.2.2.

   +================================+==============================+
   | Matching Rule                  | ASN.1 Type                   |
   +================================+==============================+
   | bitStringMatch                 | BIT STRING                   |
   +--------------------------------+------------------------------+
   | booleanMatch                   | BOOLEAN ChoiceOfStrings type     |
      +--------------------------------+------------------------------+
      | caseIgnoreMatch                | NumericString                |
   | caseIgnoreOrderingMatch caseIgnoreIA5Match             | PrintableString IA5String                    |
      | caseIgnoreSubstringsMatch caseExactIA5Match              | VisibleString (ISO646String)                              |
      +--------------------------------+------------------------------+
      | caseExactMatch                 | IA5String                    |
   | caseExactOrderingMatch         | UTF8String                   |
   | caseExactSubstringsMatch       | BMPString (UCS-2, UNICODE)   |
   |                                | UniversalString (UCS-4)      |
   |                                | TeletexString (T61String)    |
   |                                | VideotexString               |
   |                                | GraphicString                |
   |                                | GeneralString                |
   |                                | any ChoiceOfStrings type     |
   +--------------------------------+------------------------------+
   | caseIgnoreIA5Match             | IA5String                    |
   | caseExactIA5Match              |                              |
   +--------------------------------+------------------------------+
   | distinguishedNameMatch distinguishedNameMatch         | DistinguishedName            |
      |                                | RDNSequence                  |
   +--------------------------------+------------------------------+
   | enumeratedMatch                | ENUMERATED                   |
   |                                | INTEGER                      |
   +--------------------------------+------------------------------+



Legg                    Expires 1 September 2002               [Page 22]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002


   | generalizedTimeMatch           | GeneralizedTime              |
   | generalizedTimeOrderingMatch   |                              |
   +--------------------------------+------------------------------+
   | integerMatch                   | INTEGER                      |
   | integerOrderingMatch           |                              |
   +--------------------------------+------------------------------+
   | numericStringMatch             | NumericString                |
   | numericStringOrderingMatch     |                              |
   | numericStringSubstringsMatch   |                              |
   +--------------------------------+------------------------------+
   | objectIdentifierMatch          | OBJECT IDENTIFIER            |
   +--------------------------------+------------------------------+
   | octetStringMatch               | OCTET STRING                 |
   | octetStringOrderingMatch       |                              |
   | octetStringSubstringsMatch     |                              |
   +--------------------------------+------------------------------+
   | presentMatch                   | any ASN.1 type               |
   +--------------------------------+------------------------------+
   | rdnMatch                       | RelativeDistinguishedName    |
   +--------------------------------+------------------------------+
   | telephoneNumberMatch           | PrintableString              |
   | telephoneNumberSubstringsMatch | TelephoneNumber              |
   +--------------------------------+------------------------------+
   | uTCTimeMatch                   | UTCTime                      |
   | uTCTimeOrderingMatch           |                              |
   +--------------------------------+------------------------------+


5. ComponentFilter

   The ComponentAssertion allows the value(s) of any one component type
   in a complex ASN.1 type to be matched, but there is often a desire to
   match the values of more than one component type.  A ComponentFilter
   is an assertion about the presence, or values of, multiple components
   within an ASN.1 value.

   The ComponentFilter assertion, an expression of ComponentAssertions,
   evaluates to either TRUE, FALSE or undefined for each tested ASN.1
   value.

   A ComponentFilter is described by the following ASN.1 type (assumed
   to be defined with "EXPLICIT TAGS" in force):

   ComponentFilter ::= CHOICE {
       item  [0] ComponentAssertion,
       and   [1] SEQUENCE OF ComponentFilter,
       or    [2] SEQUENCE OF ComponentFilter,
       not   [3] ComponentFilter }



Legg                    Expires 1 September 2002               [Page 23]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002


   Note: despite the use of SEQUENCE OF instead of SET OF for the "and"
   and "or" alternatives in ComponentFilter, the order of the component
   filters is not significant.

   A ComponentFilter that is a ComponentAssertion evaluates to TRUE if
   the ComponentAssertion is TRUE, evaluates to FALSE if the
   ComponentAssertion is FALSE, and evaluates to undefined otherwise.

   The "and" of a sequence of component filters evaluates to TRUE if the
   sequence is empty or if each component filter evaluates to TRUE,
   evaluates to FALSE if at least one component filter is FALSE, and
   evaluates to undefined otherwise.

   The "or" of a sequence of component filters evaluates to FALSE if the
   sequence is empty or if each component filter evaluates to FALSE,
   evaluates to TRUE if at least one component filter is TRUE, and
   evaluates to undefined otherwise.

   The "not" of a component filter evaluates to TRUE if the component
   filter is FALSE, evaluates to FALSE if the component filter is TRUE,
   and evaluates to undefined otherwise.


6. The componentFilterMatch Matching Rule

   The componentFilterMatch matching rule allows a ComponentFilter to be
   applied to an attribute value.  The result of the matching rule is
   the result of applying the ComponentFilter to the attribute value.

   The LDAP-style definitions for componentFilterMatch and its assertion
   syntax are:

   ( 1.2.36.79672281.1.13.2 NAME 'componentFilterMatch'
       SYNTAX 1.2.36.79672281.1.5.2 )

   ( 1.2.36.79672281.1.5.2 DESC 'ComponentFilter' )

   The native LDAP encoding of a ComponentAssertion is described by the
   following ABNF:

   ComponentAssertion = "{" sp component ","
                          [ sp useDefaultValues "," ]
                            sp rule ","
                            sp assertion-value sp "}"
   component          = component-label msp
                            dquote component-reference dquote
   useDefaultValues   = use-defaults-label msp BooleanValue
   rule               = rule-label msp ObjectIdentifierValue



Legg                    Expires 1 September 2002               [Page 24]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002


   assertion-value    = value-label msp Value

   component-label    = %x63.6F.6D.70.6F.6E.65.6E.74 ; "component"
   use-defaults-label = %x75.73.65.44.65.66.61.75.6C.74.56.61.6C.75.65.73
                                                     ; "useDefaultValues"
   rule-label         = %x72.75.6C.65                ; "rule"
   value-label        = %x76.61.6C.75.65             ; "value"

   sp                 =  *%x20  ; zero, one or more space characters
   msp                = 1*%x20  ; one or more space characters
   dquote             =   %x22  ; " (double quote)

   The ABNF for <Value>, <ObjectIdentifierValue> and <BooleanValue> is
   defined in Section 8.

   The native LDAP encoding of a ComponentFilter is described by the
   following ABNF:

   ComponentFilter = filter-item / and-filter / or-filter / not-filter

   filter-item     = item-chosen ComponentAssertion
   and-filter      = and-chosen  SequenceOfComponentFilter
   or-filter       = or-chosen   SequenceOfComponentFilter
   not-filter      = not-chosen  ComponentFilter

   item-chosen     = %x69.74.65.6D.3A  ; "item:"
   and-chosen      = %x61.6E.64.3A     ; "and:"
   or-chosen       = %x6F.72.3A        ; "or:"
   not-chosen      = %x6E.6F.74.3A     ; "not:"

   SequenceOfComponentFilter = "{" [ sp ComponentFilter
                                   *( "," sp ComponentFilter) ] sp "}"

   Note that the string encodings of ComponentAssertion and
   ComponentFilter conform to the generic string encodings defined in
   Section 8 (in the event that there is a discrepancy between the above
   ABNF and Section 8, Section 8 is to be taken as definitive).

   The X.500-style definition [8] for componentFilterMatch is:

   componentFilterMatch MATCHING-RULE ::= {
       SYNTAX  ComponentFilter
       ID      { 1 2 36 79672281 1 13 2 } }

   A ComponentAssertion can potentially use any matching rule, including
   componentFilterMatch, so componentFilterMatch MAY be nested.  The
   component references in a nested componentFilterMatch are relative to
   the component corresponding to the containing ComponentAssertion.  In



Legg                    Expires 1 September 2002               [Page 25]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002


   Section 9, an example search on the seeAlso attribute shows this
   usage.


7. Equality Matching of Complex Components

   It is possible to test if an attribute value of a complex ASN.1
   syntax is the same as some purported (i.e. assertion) value by using
   a complicated ComponentFilter that tests if corresponding components
   are the same.  However, it would be more convenient to be able to
   present a whole assertion value to a matching rule that could do the
   component-wise comparison of an attribute value with the assertion
   value for any arbitrary attribute syntax.  Similarly, the ability to
   do a straightforward equality comparison of a component value that is
   itself of a complex ASN.1 type would also be convenient.

   It would be difficult to define a single matching rule that
   simultaneously satisfies all notions of what the equality matching
   semantics should be.  For example, in some instances a case sensitive
   comparison of string components may be preferable to a case
   insensitive comparison.  Therefore a basic equality matching rule,
   allComponentsMatch, is defined in Section 7.1, and the means to
   derive new matching rules from it with slightly different equality
   matching semantics is described in Section 7.2.

   The directoryComponentsMatch defined in Section 7.3 is a derivation
   of allComponentsMatch that suits typical uses of the directory.
   Other specifications are free to derive new rules from
   allComponentsMatch or directoryComponentsMatch, that suit their usage
   of the directory.

   The allComponentsMatch rule, the directoryComponentsMatch rule and
   any matching rules derived from them are collectively called
   component equality matching rules.


7.1 The allComponentsMatch Matching Rule

   The LDAP-style definition for allComponentsMatch is:

   ( 1.2.36.79672281.1.13.6 NAME 'allComponentsMatch'
       SYNTAX 1.2.36.79672281.1.5.3 )

   The X.500-style definition for allComponentsMatch is:

   allComponentsMatch MATCHING-RULE ::= {
       ID      { 1 2 36 79672281 1 13 6 } }




Legg                    Expires 1 September 2002               [Page 26]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002


   When allComponentsMatch is used in a ComponentAssertion the assertion
   syntax is the same as the ASN.1 type of the identified component.
   Otherwise, the assertion syntax of allComponentsMatch is the same as
   the attribute syntax of the attribute to which the matching rule is
   applied.

   Broadly speaking, this matching rule evaluates to true if and only if
   corresponding components of the assertion value and the attribute or
   component value are the same.

   In detail, equality is determined by the following cases applied
   recursively.

   a) Two values of a SET or SEQUENCE type are the same if and only if,
   for each component type, the corresponding component values are
   either,

      i) both absent,

      ii) both present and the same, or

      iii) absent or the same as the DEFAULT value for the component, if
      a DEFAULT value is defined.

      Values of an EMBEDDED PDV, EXTERNAL, unrestricted CHARACTER
      STRING, or INSTANCE OF type are compared according to their
      respective SEQUENCE type (see Section 4.1.2).

   b) Two values of a SEQUENCE OF type are the same if and only if, the
   values have the same number of (possibly duplicated) instances and
   corresponding instances are the same.

   c) Two values of a SET OF type are the same if and only if, the
   values have the same number of instances and each distinct instance
   occurs in both values the same number of times, i.e. both values have
   the same instances, including duplicates, but in any order.

   d) Two values of a CHOICE type are the same if and only if, both
   values are of the same chosen alternative and the component values
   are the same.

   e) Two BIT STRING values are the same if and only if the values have
   the same number of bits and corresponding bits are the same.  If the
   BIT STRING type is defined with a named bit list then trailing zero
   bits in the values are treated as absent for the purposes of this
   comparison.

   f) Two BOOLEAN values are the same if and only if both are TRUE or



Legg                    Expires 1 September 2002               [Page 27]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002


   both are FALSE.

   g) Two values of a string type are the same if and only if the values
   have the same number of characters and corresponding characters are
   the same.  Letter case is significant.  For the purposes of
   allComponentsMatch, the string types are NumericString,
   PrintableString, TeletexString (T61String), VideotexString,
   IA5String, GraphicString, VisibleString (ISO646String),
   GeneralString, UniversalString, BMPString, UTF8String,
   GeneralizedTime, UTCTime and ObjectDescriptor.

   h) Two INTEGER values are the same if and only if the integers are
   equal.

   i) Two ENUMERATED values are the same if and only if the enumeration
   item identifiers are the same (equivalently, if the integer values
   associated with the identifiers are equal).

   j) Two NULL values are always the same, unconditionally.

   k) Two OBJECT IDENTIFIER values are the same if and only if the
   values have the same number of arcs and corresponding arcs are the
   same.

   l) Two OCTET STRING values are the same if and only if the values
   have the same number of octets and corresponding octets are the same.

   m) Two REAL values are the same if and only if they are both the same
   special value, or neither is a special value and they have the same
   base and represent the same real number.  The special values for REAL
   are zero, PLUS-INFINITY and MINUS-INFINITY.

   n) Two RELATIVE-OID [12] values are the same if and only if the
   values have the same number of arcs and corresponding arcs are the
   same.  The respective starting nodes for the RELATIVE-OID values are
   disregarded in the comparison, i.e. they are assumed to be the same.

   o) Two values of an open type are the same if and only if both are of
   the same ASN.1 type and are the same according to that type.

   Tags and constraints, being part of the type definition and not part
   of the abstract values, are ignored for matching purposes.

   The allComponentsMatch rule MAY be used as the defined equality
   matching rule for an attribute.


7.2 Deriving Component Equality Matching Rules



Legg                    Expires 1 September 2002               [Page 28]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002


   A new component equality matching rule with more refined matching
   semantics MAY be derived from allComponentsMatch, or any other
   component equality matching rule, using the convention described in
   this section.

   The matching behaviour of a derived component equality matching rule
   is specified by nominating, for each of one or more identified
   components, a commutative equality matching rule that will be used to
   match values of that component.  This overrides the matching that
   would otherwise occur for values of that component using the base
   rule for the derivation.  These overrides can be conveniently
   represented as rows in a table of the following form.

     Component   |  Matching Rule
     ============+===============
                 |
                 |

   Usually, all component values of a particular ASN.1 type are to be
   matched the same way.  An ASN.1 type reference (e.g.
   DistinguishedName) or an ASN.1 built-in type name (e.g. INTEGER) in
   the Component column of the table specifies that the nominated
   equality matching rule is to be applied to all values of the named
   type, regardless of context.

   An ASN.1 type reference with a component reference appended
   (separated by a ".")  specifies that the nominated matching rule
   applies only to the identified components of values of the named
   type.  Other component values that happen to be of the same ASN.1
   type are not selected.

   Additional type substitutions as described in Section 4.2 are assumed
   to be performed to align the component type with the matching rule
   assertion syntax.

   Conceptually, the rows in a table for the base rule are appended to
   the rows in the table for a derived rule for the purpose of deciding
   the matching semantics of the derived rule.  Notionally,
   allComponentsMatch has an empty table.

   A row specifying values of an outer containing type (e.g.
   DistinguishedName) takes precedence over a row specifying values of
   an inner component type (e.g. RelativeDistinguishedName), regardless
   of their order in the table.  Specifying a row for component values
   of an inner type is only useful if a value of the RDNSequence                  |
      +--------------------------------+------------------------------+
      | enumeratedMatch                | ENUMERATED                   |
      |                                | INTEGER                      |
      +--------------------------------+------------------------------+
      | generalizedTimeMatch           | GeneralizedTime              |
      | generalizedTimeOrderingMatch   |                              |
      +--------------------------------+------------------------------+
      | integerMatch                   | INTEGER                      |
      | integerOrderingMatch           |                              |
      +--------------------------------+------------------------------+
      | numericStringMatch             | NumericString                |
      | numericStringOrderingMatch     |                              |
      | numericStringSubstringsMatch   |                              |
      +--------------------------------+------------------------------+
      | objectIdentifierMatch          | OBJECT IDENTIFIER            |
      +--------------------------------+------------------------------+
      | octetStringMatch               | OCTET STRING                 |
      | octetStringOrderingMatch       |                              |
      | octetStringSubstringsMatch     |                              |
      +--------------------------------+------------------------------+
      | presentMatch                   | any ASN.1 type can also
   appear on its own, or as a component of values of a different outer
   type.  For example, if there is a row for DistinguishedName then a
   row for               |
      +--------------------------------+------------------------------+
      | rdnMatch                       | RelativeDistinguishedName can only ever apply to    |



Legg                    Expires 1 27 September 2002              [Page 29] 21]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 1, 27, 2002


   RelativeDistinguishedName component values that are not part of a
   DistinguishedName.  A row for values


      +--------------------------------+------------------------------+
      | telephoneNumberMatch           | PrintableString              |
      | telephoneNumberSubstringsMatch | TelephoneNumber              |
      +--------------------------------+------------------------------+
      | uTCTimeMatch                   | UTCTime                      |
      | uTCTimeOrderingMatch           |                              |
      +--------------------------------+------------------------------+


6. ComponentFilter

   The ComponentAssertion allows the value(s) of an outer any one component type
   in the table
   for the base rule takes precedence over a row for values of an inner complex ASN.1 type in the table for to be matched, but there is often a desire to
   match the derived rule.

   Where values of more than one row applies to a particular component value type.  A ComponentFilter
   is an assertion about the
   earlier row takes precedence over presence, or values of, multiple components
   within an ASN.1 value.

   The ComponentFilter assertion, an expression of ComponentAssertions,
   evaluates to either TRUE, FALSE or undefined for each tested ASN.1
   value.

   A ComponentFilter is described by the later row.  Thus rows following ASN.1 type (assumed
   to be defined with "EXPLICIT TAGS" in force):

      ComponentFilter ::= CHOICE {
          item  [0] ComponentAssertion,
          and   [1] SEQUENCE OF ComponentFilter,
          or    [2] SEQUENCE OF ComponentFilter,
          not   [3] ComponentFilter }

   Note: despite the
   table for the derived rule take precedence over any rows use of SEQUENCE OF instead of SET OF for the same
   component "and"
   and "or" alternatives in ComponentFilter, the table for order of the base rule.


7.3 The directoryComponentsMatch Matching Rule

   The directoryComponentsMatch matching rule component
   filters is derived from not significant.

   A ComponentFilter that is a ComponentAssertion evaluates to TRUE if
   the
   allComponentsMatch matching rule.

   The LDAP-style definition for directoryComponentsMatch is:

   ( 1.2.36.79672281.1.13.7 NAME 'directoryComponentsMatch'
       SYNTAX 1.2.36.79672281.1.5.3 )

   The X.500-style definition for directoryComponentsMatch is:

   directoryComponentsMatch MATCHING-RULE ::= {
       ID      { 1 2 36 79672281 1 13 7 } } ComponentAssertion is TRUE, evaluates to FALSE if the
   ComponentAssertion is FALSE, and evaluates to undefined otherwise.

   The matching semantics "and" of directoryComponentsMatch are described by a sequence of component filters evaluates to TRUE if the following table, using
   sequence is empty or if each component filter evaluates to TRUE,
   evaluates to FALSE if at least one component filter is FALSE, and
   evaluates to undefined otherwise.

   The "or" of a sequence of component filters evaluates to FALSE if the convention described in Section 7.2.

     ASN.1 Type                               | Matching Rule
     =========================================+=========================
     RDNSequence                              | distinguishedNameMatch
     RelativeDistinguishedName                | rdnMatch
     TelephoneNumber                          | telephoneNumberMatch
     FacsimileTelephoneNumber.telephoneNumber | telephoneNumberMatch
     NumericString                            | numericStringMatch
     GeneralizedTime                          | generalizedTimeMatch
     UTCTime                                  | uTCTimeMatch
     DirectoryString{}                        | caseIgnoreMatch
     BMPString                                | caseIgnoreMatch
     GeneralString                            | caseIgnoreMatch
     GraphicString                            | caseIgnoreMatch
     IA5String                                | caseIgnoreMatch
     PrintableString                          | caseIgnoreMatch
     TeletexString                            | caseIgnoreMatch
     UniversalString                          | caseIgnoreMatch
     UTF8String                               | caseIgnoreMatch
     VideotexString                           | caseIgnoreMatch
   sequence is empty or if each component filter evaluates to FALSE,
   evaluates to TRUE if at least one component filter is TRUE, and
   evaluates to undefined otherwise.




Legg                    Expires 1 27 September 2002              [Page 30] 22]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 1, 27, 2002


     VisibleString                            | caseIgnoreMatch

   Notes.

   1) The DistinguishedName type is defined by assignment to be the same
   as the RDNSequence type.  Some types (e.g. Name and LocalName)
   directly reference RDNSequence rather than DistinguishedName.
   Specifying RDNSequence captures all these DN-like types.

   2) A RelativeDistinguishedName value is only matched by rdnMatch if
   it is not part of an RDNSequence value.

   3)


   The telephone number component "not" of the FacsimileTelephoneNumber
   ASN.1 type [10] is defined as a constrained PrintableString.
   PrintableString component values that are part of a
   FacsimileTelephoneNumber value can be identified separately from
   other components of PrintableString type by the specifier
   FacsimileTelephoneNumber.telephoneNumber, so that
   telephoneNumberMatch can be selectively applied.  The fourth edition
   of X.520 defines filter evaluates to TRUE if the telephoneNumber component of
   FacsimileTelephoneNumber
   filter is FALSE, evaluates to be of the type TelephoneNumber, making FALSE if the row for FacsimileTelephoneNumber.telephoneNumber components
   redundant. component filter is TRUE,
   and evaluates to undefined otherwise.


7. The directoryComponentsMatch rule MAY be used as the defined equality componentFilterMatch Matching Rule

   The componentFilterMatch matching rule for an attribute.


8. Generic String Encoding Rules

   This section defines allows a human readable UTF8 string encoding for ComponentFilter to be
   applied to an
   ASN.1 value of any given ASN.1 type. attribute value.  The primary use result of this
   encoding method the matching rule is for
   the string encoding result of assertion values
   appearing in ComponentAssertions, however applying the encoding method can
   also be nominated ComponentFilter to define the string encoding for new attribute
   syntaxes. value.

   The string encodings are based on ASN.1 value notation [11], with
   changes to accommodate the notation's use as a transfer syntax, LDAP-style definitions for componentFilterMatch and
   to support well established ad-hoc string encodings its assertion
   syntax are:

      ( 1.2.36.79672281.1.13.2 NAME 'componentFilterMatch'
          SYNTAX 1.2.36.79672281.1.5.2 )

      ( 1.2.36.79672281.1.5.2 DESC 'ComponentFilter' )

   The LDAP-specific encoding for directory
   data types.

   Referencing the ComponentFilter assertion syntax
   is specified by the Generic String Encoding Rules (GSER) is sufficient to
   define the string encoding of values of in [7].

   As a specific ASN.1 type, though
   other specifications may wish convenience to provide a customized version of the implementors, an equivalent ABNF as a convenience for description of
   the implementor (for example, as has been
   done GSER encoding for ComponentAssertion and ComponentFilter in Section 6).  Such
   a specification SHOULD state is provided here.  In the event
   that if there is a discrepancy between this ABNF and the encoding
   determined by [7], [7] is to be taken as definitive.  The GSER
   encoding of a ComponentFilter is described by the following
   equivalent ABNF:

      ComponentFilter = filter-item /
                        and-filter /
                        or-filter /
                        not-filter

      filter-item     = item-chosen ComponentAssertion
      and-filter      = and-chosen  SequenceOfComponentFilter
      or-filter       = or-chosen   SequenceOfComponentFilter
      not-filter      = not-chosen  ComponentFilter

      item-chosen     = %x69.74.65.6D.3A  ; "item:"
      and-chosen      = %x61.6E.64.3A     ; "and:"
      or-chosen       = %x6F.72.3A        ; "or:"
      not-chosen      = %x6E.6F.74.3A     ; "not:"

      SequenceOfComponentFilter = "{" [ sp ComponentFilter
                                     *( "," sp ComponentFilter) ] sp "}"

      ComponentAssertion = "{" sp component ","



Legg                    Expires 1 27 September 2002              [Page 31] 23]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 1, 27, 2002


   the customized


                             [ sp useDefaultValues "," ]
                               sp rule ","
                               sp assertion-value sp "}"
      component          = component-label msp
                               dquote component-reference dquote
      useDefaultValues   = use-defaults-label msp BooleanValue
      rule               = rule-label msp ObjectIdentifierValue
      assertion-value    = value-label msp Value

      component-label    = %x63.6F.6D.70.6F.6E.65.6E.74  ; "component"
      use-defaults-label = %x75.73.65.44.65.66.61.75.6C.74.56.61.6C.75
                           %x65.73                  ; "useDefaultValues"
      rule-label         = %x72.75.6C.65            ; "rule"
      value-label        = %x76.61.6C.75.65         ; "value"

      sp                 =  *%x20  ; zero, one or more space characters
      msp                = 1*%x20  ; one or more space characters
      dquote             =   %x22  ; " (double quote)

   The ABNF for <Value>, <ObjectIdentifierValue> and the GSER encoding <BooleanValue> is
   defined in this section,
   that [7].

   The ABNF descriptions of LDAP-specific encodings for attribute
   syntaxes typically do not clearly or consistently delineate the GSER
   component parts of an attribute value.  A regular and uniform
   character string encoding takes precedence. for arbitrary component data types is
   needed to encode the assertion value in a ComponentAssertion.  The string
   <Value> rule from [7] provides a human readable text encoding of for a
   component value of any arbitrary ASN.1 type is described by the
   following ABNF:

   Value = BitStringValue /
           BooleanValue /
           ChoiceValue /
           EmbeddedPDVValue /
           EnumeratedValue /
           ExternalValue /
           GeneralizedTimeValue /
           IntegerValue /
           InstanceOfValue /
           NullValue /
           ObjectDescriptorValue /
           ObjectIdentifierValue /
           OctetStringValue /
           RealValue /
           RelativeOIDValue /
           SequenceOfValue /
           SequenceValue /
           SetOfValue /
           SetValue /
           StringValue /
           UTCTimeValue /
           VariantEncoding

   A value of a type with a defined type name is encoded according to
   the type type.

   The X.500-style definition on the right hand side of the type assignment [8] for
   the type name. componentFilterMatch is:

      componentFilterMatch MATCHING-RULE ::= {
          SYNTAX  ComponentFilter
          ID      { 1 2 36 79672281 1 13 2 } }

   A value of a type denoted by the ComponentAssertion can potentially use of any matching rule, including
   componentFilterMatch, so componentFilterMatch MAY be nested.  The
   component references in a parameterized type with
   actual parameters is encoded according nested componentFilterMatch are relative to
   the parameterized type with
   the DummyReferences substituted with the actual parameters.

   A value of a tagged or constrained type is encoded as a value of the
   type without the tag or constraint, respectively.  Tags do not appear
   in the string encodings defined by this document.

   A value of an open type denoted by an ObjectClassFieldType is encoded
   according component corresponding to the specific type of the value.

   A value of a fixed type denoted by containing ComponentAssertion.  In
   Section 9, an ObjectClassFieldType example search on the seeAlso attribute shows this
   usage.


8. Equality Matching of Complex Components

   It is encoded
   according possible to that fixed type.

   A test if an attribute value of a selection type complex ASN.1
   syntax is encoded according to the type same as some purported (i.e. assertion) value by using



Legg                    Expires 1 27 September 2002              [Page 32] 24]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 1, 27, 2002


   referenced by the selection type.

   A value of


   a type described by TypeFromObject notation is encoded
   according to complicated ComponentFilter that tests if corresponding components
   are the denoted type.

   A value of same.  However, it would be more convenient to be able to
   present a type described by ValueSetFromObjects notation is
   encoded according whole assertion value to a matching rule that could do the governing type.

   ASN.1 identifiers figure prominently in the string encodings.  The
   ABNF for an identifier was first given in Section 4.1 but is repeated
   here for convenience.  The case
   component-wise comparison of letters in an identifier is always
   significant.

   identifier    = lowercase *alphanumeric *(hyphen 1*alphanumeric)
   alphanumeric  = uppercase / lowercase / decimal-digit
   uppercase     = %x41-5A  ; "A" to "Z"
   lowercase     = %x61-7A  ; "a" to "z"
   decimal-digit = %x30-39  ; "0" attribute value with the assertion
   value for any arbitrary attribute syntax.  Similarly, the ability to "9"
   hyphen        = "-"

   A
   do a straightforward equality comparison of a component value that is
   itself of the BIT STRING a complex ASN.1 type is encoded according would also be convenient.

   It would be difficult to the
   <BitStringValue> rule.  If the definition define a single matching rule that
   simultaneously satisfies all notions of what the BIT STRING type
   includes equality matching
   semantics should be.  For example, in some instances a named bit list, the <bit-list> form case sensitive
   comparison of <BitStringValue>
   rule MAY string components may be used.  If preferable to a case
   insensitive comparison.  Therefore a basic equality matching rule,
   allComponentsMatch, is defined in Section 8.1, and the number of bits means to
   derive new matching rules from it with slightly different equality
   matching semantics is described in a BIT STRING value Section 8.2.

   The directoryComponentsMatch defined in Section 8.3 is a
   multiple derivation
   of allComponentsMatch that suits typical uses of four the <hstring> form directory.
   Other specifications are free to derive new rules from
   allComponentsMatch or directoryComponentsMatch, that suit their usage
   of <BitStringValue> MAY be used. the directory.

   The <bstring> form of <BitStringValue> allComponentsMatch rule, the directoryComponentsMatch rule and
   any matching rules derived from them are collectively called
   component equality matching rules.


8.1 The allComponentsMatch Matching Rule

   The LDAP-style definition for allComponentsMatch is:

      ( 1.2.36.79672281.1.13.6 NAME 'allComponentsMatch'
          SYNTAX 1.2.36.79672281.1.5.3 )

   The X.500-style definition for allComponentsMatch is:

      allComponentsMatch MATCHING-RULE ::= {
          ID      { 1 2 36 79672281 1 13 6 } }

   When allComponentsMatch is used otherwise.

   BitStringValue = bstring / hstring / bit-list

   The <bit-list> rule encodes the one bits in the bit string value as a
   comma separated list of identifiers.  Each <identifier> MUST be one
   of those in ComponentAssertion the named bit list.  An <identifier> MUST NOT appear more
   than once in assertion
   syntax is the same <bit-list>.  The <bstring> rule encodes each
   bit as the character "0" or "1" in order from ASN.1 type of the first bit to identified component.
   Otherwise, the
   last bit.  The <hstring> rule encodes each group assertion syntax of four bits as a
   hexadecimal number where the first bit allComponentsMatch is the most significant.  An
   odd number same as
   the attribute syntax of hexadecimal digits is permitted.

   bit-list          = "{" [ sp identifier
                          *( "," sp identifier ) ] sp "}"

   hstring           = squote *hexadecimal-digit squote %x48  ; '...'H
   hexadecimal-digit = %x30-39 /  ; "0" to "9"
                       %x41-46    ; "A" the attribute to "F"

   bstring           = squote *binary-digit squote %x42  ; '...'B
   binary-digit      = "0" / "1" which the matching rule is
   applied.

   Broadly speaking, this matching rule evaluates to true if and only if
   corresponding components of the assertion value and the attribute or



Legg                    Expires 1 27 September 2002              [Page 33] 25]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 1, 27, 2002


   sp                = *%x20  ; zero, one or more space characters
   squote            =  %x27  ; ' (single quote)

   A


   component value of are the BOOLEAN type same.

   In detail, equality is encoded according to determined by the
   <BooleanValue> rule.

   BooleanValue = %x54.52.55.45 /   ; "TRUE"
                  %x46.41.4C.53.45  ; "FALSE"

   A value following cases applied
   recursively.

   a) Two values of the INTEGER a SET or SEQUENCE type is encoded according to the
   <IntegerValue> rule.  If are the definition of same if and only if,
      for each component type, the INTEGER type includes
   a named number list, corresponding component values are
      either,

      1) both absent,

      2) both present and the <identifier> form of <IntegerValue> MAY be
   used, in which case same, or

      3) absent or the <identifier> MUST be one of those in same as the
   named number list.  The ABNF for <positive-number> was first given in
   Section 4.1 but is repeated here DEFAULT value for convenience.

   IntegerValue    = "0" /
                     positive-number /
                     ("-" positive-number) /
                     identifier

   positive-number = non-zero-digit *decimal-digit
   non-zero-digit  = %x31-39  ; "1" to "9"

   A the component, if a
         DEFAULT value is defined.

      Values of the ENUMERATED an EMBEDDED PDV, EXTERNAL, unrestricted CHARACTER
      STRING, or INSTANCE OF type is encoded are compared according to the
   <EnumeratedValue> rule.  The <identifier> MUST be one their
      respective SEQUENCE type (see Section 5.1.2).

   b) Two values of those in a SEQUENCE OF type are the
   list of enumerations in same if and only if, the definition of
      values have the ENUMERATED type.

   EnumeratedValue = identifier

   A value same number of (possibly duplicated) instances and
      corresponding instances are the NULL same.

   c) Two values of a SET OF type is encoded according to are the <NullValue>
   rule.

   NullValue = %x4E.55.4C.4C  ; "NULL"

   A value of same if and only if, the OBJECT IDENTIFIER type is encoded according to
      values have the
   <ObjectIdentifierValue> rule.  The <ObjectIdentifierValue> rule
   allows either a dotted decimal representation same number of instances and each distinct
      instance occurs in both values the OBJECT
   IDENTIFIER value or an object descriptor name, same number of times, i.e. <descr>.  The
   <descr> rule is described both
      values have the same instances, including duplicates, but in [5].  An object descriptor name is
   potentially ambiguous and should be used with care.

   ObjectIdentifierValue = numeric-oid / descr
   numeric-oid           = oid-component 1*( "." oid-component )
   oid-component         = "0" / positive-number

   A value any
      order.

   d) Two values of the RELATIVE-OID a CHOICE type is encoded according to are the
   <RelativeOIDValue> rule.



Legg                    Expires 1 September 2002               [Page 34]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002


   RelativeOIDValue = oid-component *( "." oid-component )

   A value same if and only if, both
      values are of the OCTET STRING type is encoded according to same chosen alternative and the
   <OctetStringValue> rule.  The octets component values
      are encoded in order from the
   first octet to same.

   e) Two BIT STRING values are the last octet.  Each octet is encoded as a pair of
   hexadecimal digits where same if and only if the first digit corresponds to values have
      the four most
   significant bits same number of bits and corresponding bits are the octet. same.  If
      the hexadecimal string does not
   have an even number of digits the four least significant BIT STRING type is defined with a named bit list then trailing
      zero bits in the
   last octet values are treated as absent for the purposes of
      this comparison.

   f) Two BOOLEAN values are the same if and only if both are TRUE or
      both are assumed to be zero.

   OctetStringValue = hstring

   The contents FALSE.

   g) Two values of a string value type are encoded as a UTF8 character string
   between double quotes.  Depending on the ASN.1 string type, same if and an
   application's internal representation only if the values
      have the same number of that string type, a
   translation to or from characters and corresponding characters
      are the UTF8 character encoding may be required. same.  Letter case is significant.  For the purposes of
      allComponentsMatch, the string types are NumericString,
      PrintableString, TeletexString (T61String), VideotexString,



Legg                    Expires 27 September 2002              [Page 26]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


      IA5String, GraphicString, VisibleString
   (ISO646String) are compatible with UTF8 and do not require any
   translation.  BMPString (UCS-2) and UniversalString (UCS-4) have a
   direct mapping to (ISO646String),
      GeneralString, UniversalString, BMPString, UTF8String,
      GeneralizedTime, UTCTime and from UTF8 [7].  For ObjectDescriptor.

   h) Two INTEGER values are the remaining string types
   see [11].  Any embedded double quotes in same if and only if the resulting UTF8 character
   string integers are
      equal.

   i) Two ENUMERATED values are escaped by repeating the double quote characters.

   StringValue       = dquote *SafeUTF8Character dquote

   dquote            = %x22 ; " (double quote)

   SafeUTF8Character = %x00-21 / %x23-7F /   ; ASCII minus dquote
                       dquote dquote /       ; escaped double quote
                       %xC0-DF %x80-BF /     ; 2 byte UTF8 character
                       %xE0-EF 2(%x80-BF) /  ; 3 byte UTF8 character
                       %xF0-F7 3(%x80-BF) /  ; 4 byte UTF8 character
                       %xF8-FB 4(%x80-BF) /  ; 5 byte UTF8 character
                       %xFC-FD 5(%x80-BF)    ; 6 byte UTF8 character

   A value of the GeneralizedTime type, UTCTime type or ObjectDescriptor
   type is encoded as a string value.  GeneralizedTime same if and UTCTime use only if the VisibleString character set so enumeration
      item identifiers are the conversion to UTF8 is trivial.
   ObjectDescriptor uses same (equivalently, if the GraphicString type.

   GeneralizedTimeValue  = StringValue
   UTCTimeValue          = StringValue
   ObjectDescriptorValue = StringValue

   A value of a CHOICE type is encoded according to integer values
      associated with the identifiers are equal).

   j) Two NULL values are always the same, unconditionally.

   k) Two OBJECT IDENTIFIER values are the <ChoiceValue>
   rule.  The <ChoiceOfStringsValue> encoding MAY be used same if and only if the
   corresponding CHOICE type has been declared a ChoiceOfStrings type.
   This document declares DirectoryString to be a ChoiceOfStrings type



Legg                    Expires 1 September 2002               [Page 35]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002


   (see Section 4.2.1.1).  The <IdentifiedChoiceValue> form of
   <ChoiceValue> is used otherwise.

   ChoiceValue           = IdentifiedChoiceValue /
                           ChoiceOfStringsValue

   IdentifiedChoiceValue = identifier ":" Value
   ChoiceOfStringsValue  = StringValue

   For implementations that recognise
      values have the internal structure same number of arcs and corresponding arcs are the
   DirectoryString CHOICE type (e.g. X.500 directories),
      same.

   l) Two OCTET STRING values are the same if and only if the
   character string between values
      have the quotes in a <StringValue> contains same number of octets and corresponding octets are the
      same.

   m) Two REAL values are the same if and only
   characters that if they are permitted in a PrintableString both the
   DirectoryString same
      special value, or neither is assumed to use a special value and they have the printableString alternative,
   otherwise it is assumed to use
      same base and represent the uTF8String alternative. same real number.  The
   <IdentifiedChoiceValue> rule MAY be used special values
      for a value REAL are zero, PLUS-INFINITY and MINUS-INFINITY.

   n) Two RELATIVE-OID [12] values are the same if and only if the
      values have the same number of type
   DirectoryString to indicate a different alternative to arcs and corresponding arcs are the one that
   would otherwise be assumed from
      same.  The respective starting nodes for the string contents.  No matter what
   alternative is chosen, RELATIVE-OID values
      are disregarded in the <Value> will still comparison, i.e. they are assumed to be a UTF8 encoded
   character string, however it is a syntax error if the characters in
      same.

   o) Two values of an open type are the UTF8 string cannot be represented in same if and only if both are of
      the string same ASN.1 type of and are the
   chosen alternative.

   Implementations same according to that don't care about type.

   Tags and constraints, being part of the internal structure type definition and not part
   of a
   DirectoryString value MUST be able to parse the
   <IdentifiedChoiceValue> form abstract values, are ignored for a DirectoryString value, though the
   particular identifier found will matching purposes.

   The allComponentsMatch rule MAY be of no interest. used as the defined equality
   matching rule for an attribute.


8.2 Deriving Component Equality Matching Rules

   A value of a SEQUENCE type is encoded according to new component equality matching rule with more refined matching
   semantics MAY be derived from allComponentsMatch, or any other
   component equality matching rule, using the
   <SequenceValue> rule. convention described in
   this section.



Legg                    Expires 27 September 2002              [Page 27]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   The <ComponentList> matching behaviour of a derived component equality matching rule encodes
   is specified by nominating, for each of one or more identified
   components, a comma
   separated list commutative equality matching rule that will be used to
   match values of that component.  This overrides the particular component matching that
   would otherwise occur for values present in the
   SEQUENCE value, where each of that component value is preceded by using the
   corresponding identifier from base
   rule for the SEQUENCE type definition.  The
   components are encoded derivation.  These overrides can be conveniently
   represented as rows in the order a table of their definition in the
   SEQUENCE type.

   SequenceValue = ComponentList

   ComponentList = "{" [ sp NamedValue *( "," sp NamedValue) ] sp "}"
   NamedValue    = identifier msp Value
   msp           = 1*%x20  ; one or more space characters

   A value following form.

      Component   |  Matching Rule
      ============+===============
                  |
                  |

   Usually, all component values of a SET particular ASN.1 type is encoded according are to be
   matched the <SetValue> rule.
   The components are encoded same way.  An ASN.1 type reference (e.g.
   DistinguishedName) or an ASN.1 built-in type name (e.g. INTEGER) in
   the order Component column of their definition in the SET table specifies that the nominated
   equality matching rule is to be applied to all values of the named
   type, regardless of context.

   An ASN.1 type (i.e. just like reference with a SEQUENCE value).
   This is component reference appended
   (separated by a deliberate departure from ASN.1 value notation where ".")  specifies that the nominated matching rule
   applies only to the identified components of a SET can values of the named
   type.  Other component values that happen to be written in any order.




Legg                    Expires 1 September 2002               [Page 36]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002


   SetValue = ComponentList

   SEQUENCE and SET of the same ASN.1
   type definitions are sometimes extended by not selected.

   Additional type substitutions as described in Section 5.2 are assumed
   to be performed to align the
   inclusion of additional component types, so an implementation SHOULD
   be capable of skipping over any <NamedValue> encoding type with an
   identifier that is not recognised, on the assumption that matching rule
   assertion syntax.

   Conceptually, the sender
   is using rows in a more recent definition of table for the SEQUENCE or SET type.

   A value of a SEQUENCE OF type is encoded according base rule are appended to
   the
   <SequenceOfValue> rule, as a comma separated list of the instances rows in the value.  Each instance is encoded according to table for a derived rule for the component type purpose of deciding
   the SEQUENCE OF type.

   SequenceOfValue = "{" [ sp Value *( "," sp Value) ] sp "}" matching semantics of the derived rule.  Notionally,
   allComponentsMatch has an empty table.

   A value row specifying values of a SET OF an outer containing type is encoded according to the <SetOfValue>
   rule, as (e.g.
   DistinguishedName) takes precedence over a list row specifying values of the instances in the value.  Each instance is
   encoded according to the
   an inner component type (e.g. RelativeDistinguishedName), regardless
   of their order in the SET OF type.

   SetOfValue      = "{" [ sp Value *( "," sp Value) ] sp "}"

   A value table.  Specifying a row for component values
   of an EMBEDDED PDV, EXTERNAL, unrestricted CHARACTER STRING,
   or INSTANCE OF inner type is encoded according to the corresponding
   SEQUENCE type (see Section 4.1.2).

   EmbeddedPDVValue = SequenceValue
   ExternalValue    = SequenceValue
   InstanceOfValue  = SequenceValue

   A only useful if a value of the REAL type MUST be encoded can also
   appear on its own, or as "0" a component of values of a different outer
   type.  For example, if it is zero,
   otherwise it there is encoded as either the special value <PLUS-INFINITY>,
   the special value <MINUS-INFINITY>, a row for DistinguishedName then a
   row for RelativeDistinguishedName can only ever apply to
   RelativeDistinguishedName component values that are not part of a
   DistinguishedName.  A row for values of an optionally signed <realnumber>
   (based on outer type in the extended value notation table
   for REAL from [19]) or as the base rule takes precedence over a
   value row for values of the corresponding SEQUENCE an inner
   type in the table for REAL (see Section
   4.1.2).

   RealValue  = "0"               ; zero REAL value
                / PLUS-INFINITY   ; positive infinity
                / MINUS-INFINITY  ; negative infinity
                / realnumber      ; positive base 10 REAL value
                / "-" realnumber  ; negative base 10 REAL value
                / SequenceValue   ; non-zero REAL value, base 2 or 10
   realnumber = mantissa exponent
   mantissa   = (positive-number [ "." *decimal-digit ])
                / ( "0." *("0") positive-number )
   exponent   = "E" ( "0" / ([ "-" ] positive-number))

   PLUS-INFINITY  = %x50.4C.55.53.2D.49.4E.46.49.4E.49.54.59 the derived rule.




Legg                    Expires 1 27 September 2002              [Page 37] 28]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 1, 27, 2002


                       ; "PLUS-INFINITY"
   MINUS-INFINITY = %x4D.49.4E.55.53.2D.49.4E.46.49.4E.49.54.59
                       ; "MINUS-INFINITY"

   The values of some named complex ASN.1 types have special string
   encodings.  These special encodings are always used instead of


   Where more than one row applies to a particular component value the
   encoding that would otherwise apply based on
   earlier row takes precedence over the type definition.

   VariantEncoding = RDNSequenceValue /
                     RelativeDistinguishedNameValue /
                     ORAddressValue

   A value of later row.  Thus rows in the RDNSequence type, i.e. a distinguished name, is
   encoded according to
   table for the <RDNSequenceValue> rule, as a quoted LDAPDN
   character string. derived rule take precedence over any rows for the same
   component in the table for the base rule.


8.3 The character string directoryComponentsMatch Matching Rule

   The directoryComponentsMatch matching rule is first derived according to from the <distinguishedName> rule
   allComponentsMatch matching rule.

   The LDAP-style definition for directoryComponentsMatch is:

      ( 1.2.36.79672281.1.13.7 NAME 'directoryComponentsMatch'
          SYNTAX 1.2.36.79672281.1.5.3 )

   The X.500-style definition for directoryComponentsMatch is:

      directoryComponentsMatch MATCHING-RULE ::= {
          ID      { 1 2 36 79672281 1 13 7 } }

   The matching semantics of directoryComponentsMatch are described by
   the following table, using the convention described in Section 3 of [6], and then it 8.2.

      ASN.1 Type                               | Matching Rule
      =========================================+========================
      RDNSequence                              | distinguishedNameMatch
      RelativeDistinguishedName                | rdnMatch
      TelephoneNumber                          | telephoneNumberMatch
      FacsimileTelephoneNumber.telephoneNumber | telephoneNumberMatch
      NumericString                            | numericStringMatch
      GeneralizedTime                          | generalizedTimeMatch
      UTCTime                                  | uTCTimeMatch
      DirectoryString{}                        | caseIgnoreMatch
      BMPString                                | caseIgnoreMatch
      GeneralString                            | caseIgnoreMatch
      GraphicString                            | caseIgnoreMatch
      IA5String                                | caseIgnoreMatch
      PrintableString                          | caseIgnoreMatch
      TeletexString                            | caseIgnoreMatch
      UniversalString                          | caseIgnoreMatch
      UTF8String                               | caseIgnoreMatch
      VideotexString                           | caseIgnoreMatch
      VisibleString                            | caseIgnoreMatch

   Notes.

   1) The DistinguishedName type is
   encoded defined by assignment to be the same



Legg                    Expires 27 September 2002              [Page 29]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


      as if it were a UTF8String value, i.e. between double quotes
   with any embedded double quotes escaped by being repeated.

   RDNSequenceValue = StringValue the RDNSequence type.  Some types (e.g. Name and LocalName)
      directly reference RDNSequence rather than DistinguishedName.
      Specifying RDNSequence captures all these DN-like types.

   2) A RelativeDistinguishedName value that is only matched by rdnMatch if
      it is not part of an RDNSequence
   value is encoded according to the <RelativeDistinguishedNameValue>
   rule as a quoted character string. value.

   3) The character string is first
   derived according to the <name-component> rule in Section 3 telephone number component of [6],
   and then it the FacsimileTelephoneNumber
      ASN.1 type [10] is encoded defined as if it were a UTF8String value.

   RelativeDistinguishedNameValue = StringValue

   A constrained PrintableString.
      PrintableString component values that are part of a
      FacsimileTelephoneNumber value can be identified separately from
      other components of the ORAddress PrintableString type is encoded according to by the
   <ORAddressValue> rule as a quoted character string. specifier
      FacsimileTelephoneNumber.telephoneNumber, so that
      telephoneNumberMatch can be selectively applied.  The character
   string is first derived according to fourth
      edition of X.520 defines the textual representation telephoneNumber component of
   MTS.ORAddress from [2], and then it is encoded as if it were an
   IA5String value.

   ORAddressValue = StringValue


8.1 GSER Transfer Syntax

   The following OBJECT IDENTIFIER has been assigned
      FacsimileTelephoneNumber to identify the
   Generic String Encoding Rules:

   { 1 2 36 79672281 0 0 }

   This OBJECT IDENTIFIER would be used, of the type TelephoneNumber, making
      the row for example, to describe FacsimileTelephoneNumber.telephoneNumber components
      redundant.

   The directoryComponentsMatch rule MAY be used as the
   transfer syntax defined equality
   matching rule for a GSER encoded data-value in an EXTERNAL or
   EMBEDDED PDV value.



Legg                    Expires 1 September 2002               [Page 38]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002 attribute.


9. Component Matching Examples

   This section contains examples of search filters using the
   componentFilterMatch matching rule.  The filters are described using
   the string representation of LDAP search filters from [17].  Note
   that [17] requires asterisks to be escaped in assertion values (in
   these examples the assertion values are all <ComponentAssertion>
   encodings).  The asterisks have not been escaped in these examples
   for the sake of clarity, and to avoid confusing the LDAP protocol
   representation of search filter assertion values, where such escaping
   does not apply.  Line breaks and indenting have been added only as an
   aid to readability.

   The example search filters are all single extensible match filter
   items, though there is no reason why componentFilterMatch can't be
   used in more complicated search filters.

   The first examples describe searches over the objectClasses schema
   operational attribute, which has an attribute syntax described by the
   ASN.1 type ObjectClassDescription [8], and holds the definitions of
   the object classes known to a directory server.  The definition of
   ObjectClassDescription is as follows:

      ObjectClassDescription ::= SEQUENCE {
          identifier       OBJECT-CLASS.&id,



Legg                    Expires 27 September 2002              [Page 30]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


          name             SET OF DirectoryString { ub-schema } {ub-schema} OPTIONAL,
          description      DirectoryString { ub-schema } {ub-schema} OPTIONAL,
          obsolete         BOOLEAN DEFAULT FALSE,
          information  [0] ObjectClassInformation }

      ObjectClassInformation ::= SEQUENCE {
          subclassOf       SET OF OBJECT-CLASS.&id OPTIONAL,
          kind             ObjectClassKind DEFAULT structural,
          mandatories  [3] SET OF ATTRIBUTE.&id OPTIONAL,
          optionals    [4] SET OF ATTRIBUTE.&id OPTIONAL }

      ObjectClassKind ::= ENUMERATED {
          abstract     (0),
          structural   (1),
          auxiliary    (2) }

   OBJECT-CLASS.&id and ATTRIBUTE.&id are equivalent to the OBJECT
   IDENTIFIER ASN.1 type.  A value of OBJECT-CLASS.&id is an OBJECT
   IDENTIFIER for an object class.  A value of ATTRIBUTE.&id is an
   OBJECT IDENTIFIER for an attribute type.

   The following search filter finds the object class definition for the
   object class identified by the OBJECT IDENTIFIER 2.5.6.18:



Legg                    Expires 1 September 2002               [Page 39]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002


   (objectClasses:componentFilterMatch:=item:{

      (objectClasses:componentFilterMatch:=
          item:{ component "identifier",
                 rule objectIdentifierMatch, value 2.5.6.18 })

   A match on the "identifier" component of objectClasses values is
   equivalent to the objectIdentifierFirstComponentMatch matching rule
   applied to attribute values of the objectClasses attribute type.  The
   componentFilterMatch matching rule subsumes the functionality of the
   objectIdentifierFirstComponentMatch, integerFirstComponentMatch and
   directoryStringFirstComponentMatch matching rules.

   The following search filter finds the object class definition for the
   object class called foobar:

   (objectClasses:componentFilterMatch:=item:{

      (objectClasses:componentFilterMatch:=
          item:{ component "name.*",
                 rule caseIgnoreMatch, value "foobar" })

   An object class definition can have multiple names and the above
   filter will match an objectClasses value if any one of the names is
   "foobar".

   The component reference "name.0" identifies the notional count of the
   number of names in an object class definition.  The following search



Legg                    Expires 27 September 2002              [Page 31]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   filter finds object class definitions with exactly one name:

      (objectClasses:componentFilterMatch:=
          item:{ component "name.0", rule integerMatch, value 1 })

   The "description" component of an ObjectClassDescription is defined
   to be an OPTIONAL DirectoryString.  The following search filter finds
   object class definitions that have descriptions, regardless of the
   contents of the description string.

      (objectClasses:componentFilterMatch:=
          item:{ component "description",
                 rule presentMatch, value NULL })

   The presentMatch returns TRUE if the description component is present
   and FALSE otherwise.

   The following search filter finds object class definitions that don't
   have descriptions.

   (objectClasses:componentFilterMatch:=not:
       item:{

      (objectClasses:componentFilterMatch:=
          not:item:{ component "description",
                     rule presentMatch, value NULL })




Legg                    Expires 1 September 2002               [Page 40]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002

   The following search filter finds object class definitions with the
   word "bogus" in the description:

      (objectClasses:componentFilterMatch:=
          item:{ component "description",
                 rule caseIgnoreSubstringsMatch,
                 value { any:"bogus" } })

   The assertion value is of the SubstringAssertion syntax, i.e.

      SubstringAssertion ::= SEQUENCE OF CHOICE {
          initial      [0] DirectoryString {ub-match},
          any          [1] DirectoryString {ub-match},
          final        [2] DirectoryString {ub-match} }

   The "obsolete" component of an ObjectClassDescription is defined to
   be DEFAULT FALSE.  An object class is obsolete if the "obsolete"
   component is present and set to TRUE.  The following search filter
   finds all obsolete object classes:

      (objectClasses:componentFilterMatch:=
          item:{ component "obsolete", rule booleanMatch, value TRUE })

   An object class is not obsolete if the "obsolete" component is not



Legg                    Expires 27 September 2002              [Page 32]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   present, in which case it defaults to FALSE, or is present but is
   explicitly set to FALSE.  The following search filter finds all non-
   obsolete object classes.

      (objectClasses:componentFilterMatch:=
          item:{ component "obsolete", rule booleanMatch, value FALSE })

   The useDefaultValues flag in the ComponentAssertion defaults to TRUE
   so the componentFilterMatch rule treats an absent "obsolete"
   component as being present and set to FALSE.  The following search
   filter finds only object class definitions where the "obsolete"
   component has been explicitly set to FALSE, rather than implicitly
   defaulting to FALSE.

      (objectClasses:componentFilterMatch:=
          item:{ component "obsolete", useDefaultValues FALSE,
                 rule booleanMatch, value FALSE })

   With the useDefaultValues flag set to FALSE, if the "obsolete"
   component is absent the component reference identifies no component
   value and the matching rule will return FALSE.  The matching rule can
   only return TRUE if the component is present and set to FALSE.

   The "information.kind" component of the ObjectClassDescription is an



Legg                    Expires 1 September 2002               [Page 41]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002
   ENUMERATED type.  The following search filter finds object class
   definitions for auxiliary object classes.

      (objectClasses:componentFilterMatch:=
          item:{ component "information.kind",
                 rule enumeratedMatch, value auxiliary })

   The following search filter finds auxiliary object classes with
   commonName (cn or 2.5.4.3) as a mandatory attribute:

      (objectClasses:componentFilterMatch:=and:{
          item:{ component "information.kind",
                 rule enumeratedMatch, value auxiliary },
          item:{ component "information.mandatories.*",
                 rule objectIdentifierMatch, value cn } })

   The following search filter finds auxiliary object classes with
   commonName as a mandatory or optional attribute:

      (objectClasses:componentFilterMatch:=and:{
          item:{ component "information.kind",
                 rule enumeratedMatch, value auxiliary },
          or:{
              item:{ component "information.mandatories.*",



Legg                    Expires 27 September 2002              [Page 33]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


                     rule objectIdentifierMatch, value cn },
              item:{ component "information.optionals.*",
                     rule objectIdentifierMatch, value cn } } })

   Extra care is required when matching optional SEQUENCE OF or SET OF
   components because of the distinction between an absent list of
   instances and a present, but empty, list of instances.  The following
   search filter finds object class definitions with less than three
   names, including object class definitions with a present but empty
   list of names, but does not find object class definitions with an
   absent list of names.

      (objectClasses:componentFilterMatch:=
          item:{ component "name.0",
                 rule integerOrderingMatch, value 3 })

   If the "name" component is absent the "name.0" component is also
   considered to be absent and the ComponentAssertion evaluates to
   FALSE.  If the "name" component is present, but empty, the "name.0"
   component is also present and equal to zero, so the
   ComponentAssertion evaluates to TRUE.  To also find the object class
   definitions with an absent list of names the following search filter
   would be used:

      (objectClasses:componentFilterMatch:=or:{



Legg                    Expires 1 September 2002               [Page 42]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002
          not:item:{ component "name", rule presentMatch, value NULL },
          item:{ component "name.0",
                 rule integerOrderingMatch, value 3 } })

   Distinguished names embedded in other syntaxes can be matched with a
   componentFilterMatch.  The uniqueMember attribute type has an
   attribute syntax described by the ASN.1 type NameAndOptionalUID.

      NameAndOptionalUID ::= SEQUENCE {
          dn        DistinguishedName,
          uid       UniqueIdentifier OPTIONAL }

   The following search filter finds values of the uniqueMember
   attribute containing the author's DN:

   (uniqueMember:componentFilterMatch:=item:{

      (uniqueMember:componentFilterMatch:=
          item:{ component "dn",
                 rule distinguishedNameMatch,
                 value "cn=Steven Legg,o=Adacel,c=AU" })

   The DistinguishedName and RelativeDistinguishedName ASN.1 types are
   also complex ASN.1 types so the component matching rules can be
   applied to their inner components.



Legg                    Expires 27 September 2002              [Page 34]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


      DistinguishedName   ::= RDNSequence

      RDNSequence ::= SEQUENCE OF RelativeDistinguishedName

      RelativeDistinguishedName ::= SET SIZE (1..MAX) OF
          AttributeTypeAndValue

      AttributeTypeAndValue ::= SEQUENCE {
          type        AttributeType ({SupportedAttributes}),
          value       AttributeValue ({SupportedAttributes}{@type}) }

      AttributeType ::= ATTRIBUTE.&id

      AttributeValue ::= ATTRIBUTE.&Type

   ATTRIBUTE.&Type is an open type.  A value of ATTRIBUTE.&Type is
   constrained by the type component of AttributeTypeAndValue to be of
   the attribute syntax of the nominated attribute type.  Note: the
   fourth edition of X.500 extends and renames the AttributeTypeAndValue
   SEQUENCE type.

   The seeAlso attribute has the DistinguishedName syntax.  The
   following search filter finds seeAlso attribute values containing the
   RDN, "o=Adacel", anywhere in the DN:




Legg                    Expires 1 September 2002               [Page 43]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002

      (seeAlso:componentFilterMatch:=
          item:{ component "*", rule rdnMatch, value "o=Adacel" })

   The following search filter finds all seeAlso attribute values with
   "cn=Steven Legg" as the RDN of the named entry (i.e. the "first" RDN
   in an LDAPDN or the "last" RDN in an X.500 DN).

      (seeAlso:componentFilterMatch:=
          item:{ component "-1",
                 rule rdnMatch, value "cn=Steven Legg" })

   The following search filter finds all seeAlso attribute values naming
   entries in the DIT subtree of "o=Adacel,c=AU":

      (seeAlso:componentFilterMatch:=and:{
          item:{ component "1", rule rdnMatch, value "c=AU" },
          item:{ component "2", rule rdnMatch, value "o=Adacel" } })

   The following search filter finds all seeAlso attribute values
   containing the naming attribute types commonName (cn) and
   telephoneNumber in the same RDN:

      (seeAlso:componentFilterMatch:=



Legg                    Expires 27 September 2002              [Page 35]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


          item:{ component "*", rule componentFilterMatch,
                 value and:{
                     item:{ component "*.type",
                            rule objectIdentifierMatch, value cn },
                     item:{ component "*.type",
                            rule objectIdentifierMatch,
                            value telephoneNumber } } })

   The following search filter would find all seeAlso attribute values
   containing the attribute types commonName and telephoneNumber, but
   not necessarily in the same RDN:

      (seeAlso:componentFilterMatch:=and:{
          item:{ component "*.*.type",
                 rule objectIdentifierMatch, value cn },
          item:{ component "*.*.type",
                 rule objectIdentifierMatch, value telephoneNumber } })

   The following search filter finds all seeAlso attribute values
   containing the word "Adacel" in any organizationalUnitName (ou)
   attribute value in any AttributeTypeAndValue of any RDN:

      (seeAlso:componentFilterMatch:=
          item:{ component "*.*.value.(2.5.4.11)",
                 rule caseIgnoreSubstringsMatch,
                 value { any:"Adacel" } })



Legg                    Expires 1 September 2002               [Page 44]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002

   The component reference "*.*.value" identifies an open type, in this
   case an attribute value.  In a particular AttributeTypeAndValue, if
   the attribute type is not organizationalUnitName then the
   ComponentAssertion evaluates to FALSE.  Otherwise the substring
   assertion is evaluated against the attribute value.


10. Security Considerations

   The component matching rules described in this document allow for a
   compact specification of matching capabilities that could otherwise
   have been defined by a plethora of specific matching rules, i.e.
   despite their expressiveness and flexibility the component matching
   rules do not behave in a way uncharacteristic of other matching
   rules, so the security issues for component matching rules are no
   different than for any other matching rule.  However, because the
   component matching rules are applicable to any attribute syntax,
   support for them in a directory server may allow searching of
   attributes that were previously unsearchable by virtue of there not
   being a suitable matching rule.  Such attribute types ought to be
   properly protected with appropriate access controls.

   The generic string encodings in Section 8 do not necessarily enable
   the exact octet encoding of values of the TeletexString,
   VideotexString, GraphicString or GeneralString types to be
   reconstructed, so a transformation from DER to GSER and back to DER
   may not reproduce the original DER encoding.  This has consequences
   for the verification of digital signatures.



Legg                    Expires 27 September 2002              [Page 36]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


11. Acknowledgements

   The author would like to thank Tom Gindin for private email
   discussions that clarified and refined the ideas presented in this
   document.


12. Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]  Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay): Mapping
        between X.400 and RFC 822/MIME", RFC 2156, January 1998.

   [3] 2119, March 1997.

   [2]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
         Specifications: ABNF", RFC 2234, November 1997.




Legg                    Expires 1 September 2002               [Page 45]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002


   [4]

   [3]   Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
         Protocol (v3)", RFC 2251, December 1997.

   [5]

   [4]   Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
         Directory Access Protocol (v3): Attribute Syntax Definitions",
         RFC 2252, December 1997.

   [6]

   [5]   Wahl, M., Kille S. and T. Howes. "Lightweight Directory Access
         Protocol (v3): UTF-8 String Representation of Distinguished
         Names", RFC 2253, December 1997.

   [7]

   [6]   Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
         2279, January 1998.

   [7]   Legg, S., "Generic String Encoding Rules for ASN.1 Types",
         draft-legg-ldap-gser-xx.txt, a work in progress, March 2002.

   [8]   ITU-T Recommendation X.501 (1993) | ISO/IEC 9594-2:1994,
         Information Technology - Open Systems Interconnection - The
         Directory: Models

   [9]   ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1998,
         Information Technology - Open Systems Interconnection - The
         Directory: Authentication Framework

   [10]  ITU-T Recommendation X.520 (1993) | ISO/IEC 9594-6:1994,
         Information Technology - Open Systems Interconnection - The
         Directory: Selected attribute types

   [11]  ITU-T Recommendation X.680 (1997) | ISO/IEC 8824-1:1998
         Information Technology - Abstract Syntax Notation One (ASN.1):
         Specification of basic notation




Legg                    Expires 27 September 2002              [Page 37]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   [12]  ITU-T Recommendation X.680 - Amendment 1 (06/99) | ISO/IEC
         8824-1:1998/Amd 1:2000 Relative object identifiers

   [13]  ITU-T Recommendation X.681 (1997) | ISO/IEC 8824-2:1998
         Information Technology - Abstract Syntax Notation One (ASN.1):
         Information object specification

   [14]  ITU-T Recommendation X.682 (1997) | ISO/IEC 8824-3:1998
         Information Technology - Abstract Syntax Notation One (ASN.1):
         Constraint specification

   [15]  ITU-T Recommendation X.683 (1997) | ISO/IEC 8824-4:1998
         Information Technology - Abstract Syntax Notation One (ASN.1):
         Parameterization of ASN.1 specifications


13. Informative References




Legg                    Expires 1 September 2002               [Page 46]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002

   [16]  Hovey, R. and S. Bradner, "The Organizations Involved in the
         IETF Standards Process", BCP 11, RFC 2028, October 1996.

   [17]  Howes, T., "The String Representation of LDAP Search Filters",
         RFC 2254, December 1997.

   [18]  ITU-T Recommendation X.500 (1993) | ISO/IEC 9594-1:1994,
         Information Technology - Open Systems Interconnection - The
         Directory: Overview of concepts, models and services

   [19]  ITU-T Recommendation X.680 X.690 (1997) | ISO/IEC 8825-1:1998
         Information Technology - Corrigendum 3 (02/2001) ASN.1 encoding rules: Specification of
         Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and
         Distinguished Encoding Rules (DER)


14. Intellectual Property Notice

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. [16] Copies
   of claims of rights made available for publication and any assurances
   of licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can



Legg                    Expires 27 September 2002              [Page 38]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.


15. Copyright Notice

      Copyright (C) The Internet Society (2002). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other



Legg                    Expires 1 September 2002               [Page 47]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


16. Author's Address

   Steven Legg
   Adacel Technologies Ltd.
   405-409 Ferntree Gully Road
   Mount Waverley, Victoria 3149
   AUSTRALIA

   Phone: +61 3 9451 2107
     Fax: +61 3 9541 2121



Legg                    Expires 27 September 2002              [Page 39]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   EMail: steven.legg@adacel.com.au


17. Appendix A - Changes From Previous Drafts

17.1 Changes in Draft 01

   Section 4.1.7 (now 5.1.7) was added to enable component matching of
   values embedded in encoded form into BIT STRINGs or OCTET STRINGs.
   In particular, this is to allow component matching of values in
   Certificate extensions.  The <content> rule was added in Section 4.1
   (now 5.1) to allow the OCTET STRING contents to be treated as either
   raw octets or as an embedded value.

   References to a companion document summarizing the ASN.1 types of
   LDAP syntaxes were removed to avoid holding up this document.

   The OpenType syntax was renamed to OpenAssertionType.

   Object identifiers for the new syntax and matching rule definitions
   have been allocated from an arc belonging to Adacel Technologies Ltd.



Legg                    Expires 1 September 2002               [Page 48]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002

17.2 Changes in Draft 02

   The context specific tagging in the ComponentAssertion ASN.1 type was
   unnecessary and has been removed.

   The encoding of OpenAssertionType assertion values outside of
   ComponentAssertions has been clarified, and the description of
   OpenAssertionType has been promoted to its own section.

17.3 Changes in Draft 03

   The default matching by allComponentsMatch of component values of BIT
   STRING types with named bit lists has been changed to ignore trailing
   zero bits.

   Typographical errors in the <SafeUTF8Character> rule have been fixed.

17.4 Changes in Draft 04

   When the matching rule in a ComponentAssertion has a variable
   assertion syntax it is not possible to determine the syntax of the
   value component from the ComponentAssertion alone when the associated
   component reference has referenced through an open type.  Deducing
   what that syntax should be from inspection of the other
   ComponentAssertions in a ComponentFilter is difficult to implement in
   any comprehensive way.  The <select> form of ComponentId has been



Legg                    Expires 27 September 2002              [Page 40]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


   introduced so that the syntax can always be determined from the
   contents of the ComponentAssertion alone.  This not only simplifies
   implementation but can lead to simpler ComponentFilters since there
   is no longer a requirement to test that the components constraining
   an open type have particular values.  The open type referencing
   example has been changed accordingly.  The contained type referencing
   example has also been changed because it is an example of a contained
   open type.

   The presentationAddressMatch rule is not commutative so it has been
   removed from the table defining directoryComponentsMatch. The default
   behaviour of allComponentsMatch is already a suitable commutative
   substitute for matching PresentationAddress values.

   The null character has been included in the range of legal characters
   for <SafeUTF8Character>.

   The ASN.1 type of the notional iteration count associated with SET OF
   and SEQUENCE OF values has been refined to INTEGER (0..MAX).

   The encoding rules in Section 8 (now draft-legg-ldap-gser-xx.txt)
   have been formally named the Generic String Encoding Rules (GSER) and
   a transfer syntax object identifier



Legg                    Expires 1 September 2002               [Page 49]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules    March 1, 2002 has been assigned.

   The term "LDAP string encoding" has been replaced by the term "native
   LDAP
   LDAP-specific encoding" to align with terminology anticipated to be
   used in the revision of RFC 2252.

17.5 Changes in Draft 05

   Reformatted the draft to conform to recent and proposed RFC editorial
   policy.

   The use of the <oid> rule from RFC 2252 has been replaced by a local
   definition to specifically outlaw leading zero characters in OBJECT
   IDENTIFIER components.

   Provisions for the RELATIVE-OID ASN.1 type defined in Amendment 1 to
   X.680 have been added.

   The comparison of REAL values has been clarified and the GSER
   encoding of REAL values has been extended.

   Removed extraneous spaces from example DNs.

17.6 Changes in Draft 06

   An ABNF syntax error in the <exponent> rule was fixed.



Legg                    Expires 1 27 September 2002              [Page 41]

INTERNET-DRAFT    LDAP & X.500 Component Matching Rules   March 27, 2002


17.7 Changes in Draft 07

   The term "native LDAP encoding" has been replaced by the term "LDAP-
   specific encoding" to align with terminology anticipated to be used
   in the revision of RFC 2252.

   Section 8 has been extracted to become a separate Internet draft,
   draft-legg-ldap-gser-00.txt.  The specifications for ChoiceOfStrings
   types have also been moved to this new Internet draft.  Various
   editorial changes have been made to this draft to accommodate this
   split.








































Legg                    Expires 27 September 2002              [Page 50] 42]

----