INTERNET-DRAFT S. Legg draft-legg-xed-matching-02.txt eB2Bcom Intended Category: Standards Track D. Prager Updates: RFC 3687 November 16, 2006 Obsoletes: RFC 3727 The XML Enabled Directory: Matching Rules Copyright (C) The IETF Trust (2006). Status of This Memo By submitting this Internet-draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Technical discussion of this document should take place on the XED developers mailing list . Please send editorial comments directly to the editor . Further information is available on the XED website: www.xmled.info. This Internet-Draft expires on 16 May 2007. Abstract The XML (Extensible Markup Language) Enabled Directory (XED) allows the definition of directory attributes whose syntaxes are defined in terms of XML Schema types, RELAX NG patterns or XML document type definition (DTD) element type declarations. This document enables Legg & Prager Expires 16 May 2007 [Page 1] INTERNET-DRAFT XED: Matching Rules November 16, 2006 the matching of directory attribute values of such syntaxes by extending existing Lightweight Directory Access Protocol (LDAP) and X.500 directory matching rules. Legg & Prager Expires 16 May 2007 [Page 2] INTERNET-DRAFT XED: Matching Rules November 16, 2006 Table of Contents 1. Introduction ....................................................3 2. Conventions .....................................................4 3. Content Values ..................................................5 4. Extended Applicability of Matching Rules ........................7 5. Boolean Matching ................................................8 6. Character String Matching .......................................9 7. Date/Time Matching ..............................................9 8. Integer Matching ................................................9 9. Octet String Matching ..........................................10 10. Component Matching ............................................10 10.1. The allComponentsMatch Matching Rule .....................10 10.1.1. Attribute Subset Comparison ......................10 10.1.2. Element Subset Comparison ........................11 10.1.3. Child Subset Comparison ..........................12 10.1.4. Content Value Comparison .........................13 10.2. The directoryComponentsMatch Matching Rule ...............15 10.3. The componentFilterMatch Matching Rule ...................16 10.3.1. Component Path ...................................17 10.3.1.1. ChildAxisStep ..........................20 10.3.1.2. AttributeAxisStep ......................23 10.3.1.3. SimpleContentStep ......................24 10.3.1.4. ItemStep ...............................25 10.3.1.5. MemberStep .............................26 10.3.1.6. MemberTypeStep .........................28 10.3.1.7. CountStep ..............................29 10.3.1.8. ContentStep ............................30 10.3.1.9. RestrictByStep .........................31 10.4. The presentMatch Matching Rule ...........................31 10.5. Component Matching Examples ..............................31 10.5.1. Examples for ASN.1 Types .........................31 10.5.2. Examples for XML Schema Types ....................50 11. Security Considerations .......................................50 12. Acknowledgements ..............................................50 13. IANA Considerations ...........................................50 14. References ....................................................51 14.1. Normative References ........................................51 14.2. Informative References ......................................53 Appendix A. ASN.1 for Component Matching Rules ....................53 Appendix B. ASN.X for Component Matching Rules ....................55 1. Introduction Matching rules [MODELS] are used by Lightweight Directory Access Protocol (LDAP) [LDAP] and X.500 [X.500] directory implementations to compare directory attribute values against assertion values when performing Search and Compare operations [PROT], to compare a Legg & Prager Expires 16 May 2007 [Page 3] INTERNET-DRAFT XED: Matching Rules November 16, 2006 purported distinguished name [MODELS] with the name of an entry, to identify values to be deleted, and to prevent a directory attribute from containing two equal values. The subschema operational attributes [SCHEMA] of the XML [XML10][XML11] Enabled Directory (XED) [XED] allow the definition of directory attributes whose syntaxes are defined in terms of XML Schema [XSD1] types, RELAX NG [RNG] patterns or XML document type definition (DTD) [XML10] element type declarations. This document enables the matching of directory attribute values of such syntaxes by extending existing LDAP and X.500 matching rules. Note: The coverage of DTD element types and RELAX NG patterns is incomplete in this version of the document. This will be corrected in a revision of this document. Section 3 defines a concept, the content value, that is useful for describing the extended semantics of matching rules. The content value concept unifies the treatment of XML element content and XML attribute values, and bridges a terminology gap between Abstract Syntax Notation One (ASN.1) [X.680] and XML Schema. ASN.1 has an abstract concept of "value" for both simple and combining types which is independent of any particular encoding. XML Schema defines a similar concept only for values of simple types and is exclusively focused on the XML encoding format. Sections 4 to 9 use the content value concept in extending selected basic matching rules to apply to values of non-ASN.1 types. Section 10 extends the component matching framework [CMR] to apply to values of non-ASN.1 types. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED" and "MAY" in this document are to be interpreted as described in BCP 14, RFC 2119 [BCP14]. The key word "OPTIONAL" is exclusively used with its ASN.1 meaning. This specification makes use of definitions from the XML Information Set (Infoset) [ISET]. In particular, information item property names follow the Infoset convention of being shown in square brackets, e.g., [local name]. In the sections that follow, the term "element" shall be taken to mean an Infoset element information item. The term "attribute" is ambiguous. To avoid this ambiguity an attribute in the directory sense will always be referred to as a directory attribute. Any other use of the term "attribute" is Legg & Prager Expires 16 May 2007 [Page 4] INTERNET-DRAFT XED: Matching Rules November 16, 2006 assumed to mean an attribute in the XML sense. A directory attribute type will be referred to as such, otherwise the term "type" shall be taken to mean a type in a schema language (an ASN.1 type, an XML Schema type, a RELAX NG pattern or a DTD element type). This document uses the namespace prefix [XMLNS10] "asnx:" to stand for the namespace name "urn:ietf:params:xml:ns:asnx", uses the namespace prefix "xsd:" to stand for the namespace name "http://www.w3.org/2001/XMLSchema" and uses the namespace prefix "xsi:" to stand for the namespace name "http://www.w3.org/2001/XMLSchema-instance", though in practice any valid namespace prefixes are permitted. 3. Content Values Definition (content value): A content value is a set containing zero, one or more attribute, character, element and unexpanded entity reference information items. The order of the attribute information items is not significant. The order of the other information items is significant. Content values describe the content of attribute and element information items for matching purposes. Each content value has an associated type, either an ASN.1 type, an XML Schema type, a RELAX NG pattern or a DTD element type. The content value of an attribute information item is the set of character information items formed from the sequence of characters making up the attribute's [normalized value]. The type of a content value for an attribute information item is the type against which its [normalized value] is validated. Definition (type-visible): An attribute information item is type-visible if its [namespace name] is not "http://www.w3.org/2001/XMLSchema-instance" or "urn:ietf:params:xml:ns:asnx". The content value of an element is the set of the type-visible attribute information items in the element's [attributes] and the character, element and unexpanded entity reference information items in the element's [children] (in order). A consequence of this definition is that XML processing instructions and comments [XML10][XML11] are ignored for matching purposes. Although unexpanded entity references are part of the content value, their presence will cause the result of a match to be Undefined, therefore entity references should be avoided. Legg & Prager Expires 16 May 2007 [Page 5] INTERNET-DRAFT XED: Matching Rules November 16, 2006 Note that the [attributes] of an element does not include namespace declaration attribute information items. Namespace declarations are not directly matched, though they are significant to the matching of qualified names [XMLNS10] in content values. The type of a content value for an element is the type against which the element's content is validated. Definition (attribute subset): The attribute subset of a content value is the set, possibly empty, of attribute information items from the content value (not including attribute information items from nested content values). Definition (element subset): The element subset of a content value is the set, possibly empty, of element information items from the content value (not including element information items from nested content values). Definition (character subset): The character subset of a content value is the set, possibly empty, of character information items from the content value (not including character information items from nested content values). Definition (child subset): The child subset of a content value is the set, possibly empty, of character and element information items from the content value (not including character and element information items from nested content values). For illustrative purposes, a content value will be represented as an XML element where the Name [XML10][XML11] is replaced by the asterisk character. Examples An empty content value: <*/> A content value containing only character information items: <*>Hello World! A content value containing only attribute information items: <* height="37.5" width="70"/> A content value containing attribute information items and character information items: Legg & Prager Expires 16 May 2007 [Page 6] INTERNET-DRAFT XED: Matching Rules November 16, 2006 <* units="metres">19.5 A content value containing attribute information items, element information items and whitespace character information items: <* units="metres"> 4.56 There is a nested content value for the [normalized value] of the units attribute: <*>metres And a nested content value for the child element: <*>4.56 An ASN.1 abstract value of the Markup ASN.1 type [RXER] holds the content and attributes of an element. That content will have an associated content value, possibly with nested content values. If Markup values are constrained by Robust XML Encoding Rules (RXER) reference encoding instructions [RXEREI] to represent valid markup for a nominated type (e.g., an XML Schema type), then the associated content values are regarded as being of that nominated type. If Markup values are unconstrained, then the associated content values are regarded as being of the XML Schema ur-type [XSD1]. Conversely, a content value of a non-ASN.1 type is represented in ASN.1 terms as an abstract value of the Markup ASN.1 type. An ASN.1 abstract value of an ASN.1 type other than Markup also has an associated content value determined by the Infoset representation of the abstract value's RXER encoding [RXER]. The type of the content value is the same as type of the abstract value. Though a content value may be represented as a Markup abstract value, the type of a content value is never the Markup ASN.1 type. 4. Extended Applicability of Matching Rules Directory matching rules have traditionally been defined to apply to abstract values of ASN.1 types. This specification extends the applicability of certain matching rules so that they can be applied to content values of XML Schema types, RELAX NG patterns and DTD element types. Legg & Prager Expires 16 May 2007 [Page 7] INTERNET-DRAFT XED: Matching Rules November 16, 2006 A directory attribute syntax defined in terms of an XML Schema type, RELAX NG pattern or DTD element type is actually a constrained form of the Markup ASN.1 type. When a matching rule is applied to a directory attribute value of such a syntax it is applied to the associated content value of the constrained Markup value. A matching rule can also be applied to a component part [CMR] of a directory attribute value of such a syntax, in which case it is applied to a nested content value of the constrained Markup value. Where a matching rule is extended to apply to content values of a particular XML Schema type it is also extended to apply to content values of any type directly or indirectly derived by restriction, and only by restriction, from the nominated type. Extending the applicability of a matching rule with a fixed assertion syntax does not alter the definition of that assertion syntax. The LDAP-specific encoding of assertion values in LDAP does not change, nor does the underlying ASN.1 type. Note however, that XML Lightweight Directory Access Protocol (XLDAP) [XLDAP] uses the RXER encoding of the assertion value (not the LDAP-specific encoding) where the distinction between the ASN.1 type of the assertion value and the type of the content value of a directory attribute value being matched may not be apparent. For example, a value of the ASN.1 BOOLEAN type (the assertion syntax for booleanMatch) is represented in XLDAP in the same way as a content value of the XML Schema boolean type. Most matching rules have a fixed assertion syntax. Matching rules with a variable assertion syntax are defined for LDAP as having the OpenAssertionType syntax (1.2.36.79672281.1.5.3) [CMR]. The allComponentsMatch matching rule [CMR] is an example of a matching rule with a variable assertion syntax. Depending on the circumstances, the notional type of an assertion value of such a matching rule can be, in addition to an ASN.1 type, an XML Schema type, RELAX NG pattern or DTD element type. The non-ASN.1 types are represented in ASN.1 terms as a constrained form of the Markup ASN.1 type. Any string preparation requirements for a matching rule [PREP] [SYNTAX] also apply when the rule is evaluated on the character subset of a content value. 5. Boolean Matching The booleanMatch [RULES][X.520] matching rule may be applied to content values whose type is the XML Schema boolean type [XSD2], or a simple type derived by restriction from the boolean type. Legg & Prager Expires 16 May 2007 [Page 8] INTERNET-DRAFT XED: Matching Rules November 16, 2006 Note that the assertion syntax of the booleanMatch matching rule is still the LDAP Boolean syntax (corresponding to the ASN.1 BOOLEAN type) even when the rule is used to match content values of the XML Schema boolean type. 6. Character String Matching The caseIgnoreMatch [SYNTAX][X.520], caseExactMatch [RULES][X.520], caseIgnoreOrderingMatch [SYNTAX][X.520], caseExactOrderingMatch [RULES][X.520], caseIgnoreSubstringsMatch [SYNTAX][X.520], caseExactSubstringsMatch [RULES][X.520], storedPrefixMatch [RULES][X.520], wordMatch [RULES][X.520, keywordMatch [RULES][X.520], generalWordMatch [X.520] and approximateStringMatch [X.520] matching rules may be applied to content values whose type is the XML Schema string type [XSD2], or a simple type derived by restriction [XSD2] from the string type. This extension to the applicability of the aforementioned character string matching rules does not alter their assertion syntax in any way. For example, the assertion syntax of the caseIgnoreMatch matching rule is always the LDAP Directory String syntax (corresponding to the X.500 DirectoryString{} ASN.1 type) even when the rule is used to match content values of the XML Schema string type or one of its derivatives. Note that the XML Schema normalizedString, token, language, NMTOKEN, Name, NCName, ID and IDREF types are all simple types derived by restriction from the string type. 7. Date/Time Matching The generalizedTimeMatch [SYNTAX][X.520] and generalizedTimeOrderingMatch [SYNTAX][X.520] matching rules may be applied to content values whose type is the XML Schema dateTime type [XSD2], or a simple type derived by restriction [XSD2] from the dateTime type. If the ordering between the time represented by the content value and the time represented by the assertion value is indeterminate, according to the order relation on dateTime defined by XML Schema [XSD2], then the matching rule evaluates to Undefined. For the generalizedTimeMatch matching rule this means that a local time (i.e., without "Z" or a time zone) will never match TRUE against a coordinated universal time (i.e., with "Z" or a time zone). 8. Integer Matching The integerMatch [SYNTAX][X.520] and integerOrderingMatch [X.520] Legg & Prager Expires 16 May 2007 [Page 9] INTERNET-DRAFT XED: Matching Rules November 16, 2006 matching rules may be applied to content values whose type is the XML Schema integer type [XSD2], or a simple type derived by restriction [XSD2] from the integer type. Note that the XML Schema nonPositiveInteger, negativeInteger, positiveInteger, long, int, short, byte unsignedLong, unsignedInt, unsignedShort and unsignedByte types are all simple types derived by restriction from the integer type. 9. Octet String Matching The octetStringMatch [SYNTAX][X.520], octetStringOrderingMatch [RULES][X.520] and octetStringSubstringsMatch [X.520] matching rules may be applied to content values whose type is the XML Schema hexBinary type [XSD2], a simple type derived by restriction from the hexBinary type, the XML Schema base64Binary type [XSD2], or a simple type derived by restriction from the base64Binary type. Note that the assertion syntaxes of the octet string matching rules are based on the OCTET STRING ASN.1 type, so assertion values for these matching rules will use a hexadecimal encoding in XLDAP messages, even when being used to match content values of the base64Binary type. 10. Component Matching 10.1. The allComponentsMatch Matching Rule This specification extends the allComponentsMatch matching rule so that it may be used to compare for equality two content values of any arbitrary type, including non-ASN.1 types in particular. Since content values of non-ASN.1 types are necessarily represented in ASN.1 terms as Markup values the extension of allComponentsMatch is effected by altering how abstract values of the Markup ASN.1 type are matched. Thus Markup is not treated like an ordinary ASN.1 CHOICE type by allComponentsMatch. Two Markup values match if their associated content values are semantically the same according to their type, as determined by the following sections. Sections 10.1.1, 10.1.2 and 10.1.3 describe comparisons on various content value subsets which are then used in Section 10.1.4 in describing the comparison of complete content values. 10.1.1. Attribute Subset Comparison In some cases, the comparison of two content values depends on the comparison of their attribute subsets. Legg & Prager Expires 16 May 2007 [Page 10] INTERNET-DRAFT XED: Matching Rules November 16, 2006 If an attribute with a particular [local name] and [namespace name] is absent from only one of the attribute subsets and the associated attribute declaration for that [local name] and [namespace name] specifies a default value, then the absent attribute is assumed to be present with that default value. Subject to the preceding paragraph, when comparing two attribute subsets: (1) if either subset contains an attribute for which there is no corresponding attribute (i.e., with the same [local name] and [namespace name]) in the other subset, then the result of the attribute subset comparison is FALSE, (2) otherwise, if there is a pair of corresponding attributes (one in each subset) where the comparison of their content values is FALSE, then the result of the attribute subset comparison is FALSE, (3) otherwise, if there is a pair of corresponding attributes (one in each subset) where the comparison of their content values is Undefined, then the result of the attribute subset comparison is Undefined, (4) otherwise, the result of the attribute subset comparison is TRUE. Note that the order of the attributes is not significant for matching purposes. Note also that namespace declaration attributes and attributes from the "http://www.w3.org/2001/XMLSchema-instance" and "urn:ietf:params:xml:ns:asnx" namespaces are excluded from content values and their attribute subsets by definition. 10.1.2. Element Subset Comparison In some cases, the comparison of two content values depends on the comparison of their element subsets. The comparison of two element subsets proceeds by the pair-wise comparison of the contained elements. That is, the first element in one subset is compared to the first element in the other subset, the second element in one subset is compared to the second element in the other subset, and so on. Recall that the order of the elements in an element subset is significant. Note that an element subset does not include character information items, so the whitespace between element children is not significant. If an element has no character or element information items in its Legg & Prager Expires 16 May 2007 [Page 11] INTERNET-DRAFT XED: Matching Rules November 16, 2006 [children] and the associated element declaration specifies a default value, then the element is assumed to have that default value. Subject to the preceding paragraph, when comparing two elements: (1) if they do not have the same [local name] and [namespace name] or their content values are of different types, then the result is FALSE, (2) otherwise, the result is the result of comparing the elements' content values. Aside: Two elements with the same qualified name can have different types if one or both carry an xsi:type attribute [XSD1]. When comparing two element subsets: (1) if they have different numbers of elements, then the result is FALSE, (2) otherwise, if the result of any of the element comparisons is FALSE, then the result of the element subset comparison is FALSE, (3) otherwise, if the result of any of the element comparisons is Undefined, then the result of the element subset comparison is Undefined, (4) otherwise, the result of the element subset comparison is TRUE. 10.1.3. Child Subset Comparison In some cases, the comparison of two content values depends on the comparison of their child subsets. The comparison of two child subsets proceeds by the pair-wise comparison of the contained character and element information items. That is, the first information item in one subset is compared to the first information item in the other subset, the second information item in one subset is compared to the second information item in the other subset, and so on. Recall that the order of the information items in a child subset is significant. If an element has no character or element information items in its [children] and the associated element declaration specifies a default value, then the element is assumed to have that default value. Subject to the preceding paragraph, when comparing two information items: Legg & Prager Expires 16 May 2007 [Page 12] INTERNET-DRAFT XED: Matching Rules November 16, 2006 (1) if they are both element information items, then the result is the result of comparing the elements, (2) otherwise, if they are not both character information items, then the result is FALSE, (3) otherwise (they are both character information items) if they have the same [character code], then the result is TRUE, (4) otherwise the result is FALSE. When comparing two child subsets: (1) if they have different numbers of information items, then the result is FALSE, (2) otherwise, if the result of any of the information item comparisons is FALSE, then the result of the child subset comparison is FALSE, (3) otherwise, if the result of any of the information item comparisons is Undefined, then the result of the child subset comparison is Undefined, (4) otherwise, the result of the child subset comparison is TRUE. 10.1.4. Content Value Comparison For the purposes of allComponentsMatch, the result of comparing two content values is determined by the following cases applied recursively. (a) When comparing two content values, if the types of the two content values are different, then the result is FALSE. Aside: A difference in the types may arise because of the presence of xsi:type attributes. A future revision of this document may allow two content values of different types to be compared provided one type is a derivation by restriction of the other type, or both types are derivations by restriction from a common base type. (b) When comparing two content values of an XML Schema simple type [XSD2]: (1) if either content value contains an unexpanded entity reference information item, then the result is Undefined, Legg & Prager Expires 16 May 2007 [Page 13] INTERNET-DRAFT XED: Matching Rules November 16, 2006 (2) otherwise, if the strings formed by concatenating their character information items are lexical representations of the same value in the value space [XSD2] of the simple type, then the result is TRUE, (3) otherwise, if the value space for the simple type has an order relation and the order relation is a partial order and the relative ordering of the values is indeterminate, then the result is Undefined, (4) otherwise, the result is FALSE. (c) When comparing two content values of an XML Schema complex type [XSD1] with empty content: (1) if either content value contains an unexpanded entity reference information item, then the result is Undefined, (2) otherwise, the result is the result of comparing their attribute subsets. (d) When comparing two content values of an XML Schema complex type with simple content: (1) if the result of comparing their attribute subsets is FALSE, then the result is FALSE, (2) otherwise, if either content value contains an unexpanded entity reference information item, then the result is Undefined, (3) otherwise, if the strings formed by concatenating their character information items are not lexical representations of the same value in the value space [XSD2] of the simple type and the relative ordering of the values, if applicable, is determinate, then the result is FALSE, (4) otherwise, if the result of comparing their attribute subsets is Undefined, then the result is Undefined, (5) otherwise (where applicable), if the relative ordering of the values formed by concatenating the content values' character information items is indeterminate, then the result is Undefined, (6) otherwise, the result is TRUE. (e) When comparing two content values of an XML Schema complex type Legg & Prager Expires 16 May 2007 [Page 14] INTERNET-DRAFT XED: Matching Rules November 16, 2006 with element-only content: (1) if the result of comparing their attribute subsets is FALSE, then the result is FALSE, (2) otherwise, if either content value contains an unexpanded entity reference information item, then the result is Undefined, (3) otherwise, if the result of comparing their element subsets is FALSE, then the result is FALSE, (4) otherwise, if the result of comparing their attribute subsets is Undefined or the result of comparing their element subsets is Undefined, then the result is Undefined, (5) otherwise, the result is TRUE. (f) When comparing two content values of an XML Schema complex type with mixed content: (1) if the result of comparing their attribute subsets is FALSE, then the result is FALSE, (2) otherwise, if either content value contains an unexpanded entity reference information item, then the result is Undefined, (3) otherwise, if the result of comparing their child subsets is FALSE, then the result is FALSE, (4) otherwise, if the result of comparing their attribute subsets is Undefined or the result of comparing their child subsets is Undefined, then the result is Undefined, (5) otherwise, the result is TRUE. (g) When comparing two content values of an ASN.1 type: (1) if either content value contains an unexpanded entity reference information item, then the result is Undefined, (2) otherwise, the result is the result of comparing their corresponding abstract values according to the pre-existing definition of allComponentsMatch [CMR]. 10.2. The directoryComponentsMatch Matching Rule Legg & Prager Expires 16 May 2007 [Page 15] INTERNET-DRAFT XED: Matching Rules November 16, 2006 The directoryComponentsMatch matching rule [CMR] is derived from the allComponentsMatch matching rule. The matching semantics of directoryComponentsMatch are extended by the following table notionally appended to the table in Section 7.4 of the specification for component matching [CMR]. Type | Matching Rule =========================================+======================== xsd:string | caseIgnoreMatch 10.3. The componentFilterMatch Matching Rule The component matching specification [CMR] defines the means to selectively match component parts of directory attribute values of any directory attribute syntax defined in ASN.1 type notation. This section extends the assertion syntax of the componentFilterMatch matching rule so that nested content values of directory attribute values of syntaxes defined in terms of XML Schema types, RELAX NG patterns or DTD element types can also be selectively matched. The original component matching specification uses component references to identify component parts of directory attribute values. A component reference only has to deal with component names that are not namespace qualified. A more general referencing mechanism, called a component path, is required to support the full range of qualified names allowed by XML element and attribute names. Since a component path is dependent on namespace declaration attributes it cannot easily replace the component reference in a ComponentAssertion [CMR]. An alternative assertion, called a PathAssertion, is provided instead. A PathAssertion is an assertion about the presence, or content of, nested content values within an enclosing content value. The enclosing content value is typically the content value for a directory attribute value. However, a PathAssertion may also be applied to a nested content value of a directory attribute value. The assertion evaluates to either TRUE, FALSE or Undefined for each tested content value. The ComponentFilter [CMR] ASN.1 type is replaced by the following ASN.1 type definitions (assumed to be defined with "EXPLICIT TAGS" in force): PathAssertion ::= SEQUENCE { component ComponentPath OPTIONAL, useDefaultValues BOOLEAN DEFAULT TRUE, rule MATCHING-RULE.&id, Legg & Prager Expires 16 May 2007 [Page 16] INTERNET-DRAFT XED: Matching Rules November 16, 2006 value MATCHING-RULE.&AssertionType } ComponentPath ::= Markup (CONSTRAINED BY { -- contains a component path expression -- }) ComponentFilter ::= CHOICE { item [0] ComponentAssertion, and [1] SEQUENCE OF filter ComponentFilter, or [2] SEQUENCE OF filter ComponentFilter, not [3] ComponentFilter, ..., term [4] PathAssertion } The complete ASN.1 module specification for the revised component matching is presented in Appendix A. It replaces the previous ASN.1 module specification [CMRM]. A ComponentFilter that is a PathAssertion evaluates to TRUE if the PathAssertion is TRUE, evaluates to FALSE if the PathAssertion is FALSE, and evaluates to Undefined otherwise. Note that in the RXER encoding of an abstract value of the PathAssertion ASN.1 type, the child element is required to be self-contained [RXER] since its type is (indirectly) Markup. Aside: An element is self-contained if all namespace prefixes used by the element and its contents are declared within the element. Aside: In LDAP, a componentFilterMatch assertion value is typically encoded according to the Generic String Encoding Rules (GSER) [GSER], however the GSER encoding of a Markup abstract value is somewhat esoteric. As a consequence, if a PathAssertion is used, then one would typically express a componentFilterMatch assertion value in RXER (e.g, using the "transfer-rxer" transfer encoding option [TRANSFER]) rather than GSER. 10.3.1. Component Path The component field of a PathAssertion contains a component path; a structured sequence of character and element information items, optionally interspersed with comment and processing instruction (PI) information items. A component path is always considered in the context of a particular type, either an ASN.1 type, an XML Schema type, a RELAX NG pattern or a DTD element type. When applied to the type definition, the component path selects a specific component type. When applied to a content value of the type, the component path selects zero, one or more nested content values. The nested Legg & Prager Expires 16 May 2007 [Page 17] INTERNET-DRAFT XED: Matching Rules November 16, 2006 content values are typically of the specific component type, but might also be of a type derived by restriction from the specific component type. The nested content values are potentially in a default value specification in the type definition if the useDefaultValues field of a PathAssertion is TRUE ("true" or "1" in the RXER encoding of a PathAssertion). The specific component type selected by the component path determines what matching rules are capable of being used to match the selected content values. The component field in a PathAssertion may also be absent, in which case the selected type is the type of the content value to which the PathAssertion is applied, and the selected content value is that same content value. Aside: The component path syntax is based on the XPath abbreviated syntax [XPATH], but a component path is not an XPath expression as it operates under different model. The evaluation of an XPath expression on an XML document results in an ordered collection of atomic values, document nodes, element nodes, attribute nodes, text nodes, namespace nodes, processing instruction nodes and comment nodes, whereas the evaluation of a component path on a type definition results in another type definition and the evaluation of a component path on a content value results in an ordered collection of nested content values. For the most part, a component path offers only a subset of the functionality of XPath, though it does have features that have no counterpart in XPath, and some of the omitted functionality is instead provided by path assertions, component filters and matching rules. A component path is correctly formed if, after ignoring any comment or PI information items, it is identical to the Infoset representation of a character string conforming to the following Augmented Backus-Naur Form (ABNF) [ABNF]: ComponentPath = *( sp Step sp "/" ) sp (Step / CountStep) Step = ChildAxisStep / AttributeAxisStep / SimpleContentStep / ItemStep / MemberStep / MemberTypeStep / ContentStep / RestrictByStep ChildAxisStep = ElementName [ sp PositionPredicate ] AttributeAxisStep = AttributeName Legg & Prager Expires 16 May 2007 [Page 18] INTERNET-DRAFT XED: Matching Rules November 16, 2006 SimpleContentStep = fn-simpleContent sp "(" sp ")" ItemStep = ItemValue [ sp PositionPredicate ] ItemValue = fn-itemType sp "(" sp ")" MemberStep = fn-member sp "(" sp ( positive-number / MemberName ) sp ")" MemberName = QName MemberTypeStep = fn-memberType sp "(" sp TypeName ) sp ")" TypeName = QName ContentStep = fn-content sp "(" sp ")" RestrictByStep = fn-restrictBy sp "(" [ sp ValueList ] sp ")" ValueList = XMLValue *( sp "," sp XMLValue ) XMLValue = 1*UTF8-Char ; a Standalone RXER Encoding CountStep = ChildCount / ItemCount ChildCount = fn-count sp "(" sp ElementName sp ")" ItemCount = fn-count sp "(" sp ItemValue sp ")" ElementName = QName AttributeName = "@" sp QName fn-simpleContent = %x73.69.6D.70.6C.65.43.6F.6E.74.65.6E.74 ; "simpleContent" fn-itemType = %x69.74.65.6D.54.79.70.65 ; "itemType" fn-member = %x6D.65.6D.62.65.72 ; "member" fn-memberType = %x6D.65.6D.62.65.72.54.79.70.65 ; "memberType" fn-count = %x63.6F.75.6E.74 ; "count" fn-content = %x63.6F.6E.74.65.6E.74 ; "content" fn-restrictBy = %x72.65.73.74.72.69.63.74.42.79 ; "restrictBy" fn-last = %x6C.61.73.74 ; "last" PositionPredicate = "[" sp Position sp "]" Position = positive-number / ( fn-last sp "(" sp ")" [ sp "-" sp positive-number ] ) QName = [ Prefix ":" ] LocalPart ; the XML representation of a qualified name Prefix = NCName LocalPart = NCName NCName = (Letter / "_" ) *NCNameChar NCNameChar = Letter / Digit / "." / "-" / "_" / CombiningChar / Extender Legg & Prager Expires 16 May 2007 [Page 19] INTERNET-DRAFT XED: Matching Rules November 16, 2006 Letter = UTF8-Char ; the UTF-8 encoding of any character ; permitted by the Letter production ; of XML [XML10] Digit = UTF8-Char ; the UTF-8 encoding of any character ; permitted by the Digit production ; of XML [XML10] CombiningChar = UTF8-Char ; the UTF-8 encoding of any character ; permitted by the CombiningChar ; production of XML [XML10] Extender = UTF8-Char ; the UTF-8 encoding of any character ; permitted by the Extender production ; of XML [XML10] UTF8-Char = %x2D-7A / ; 1 octet UTF-8 character %xC0-DF %x80-BF / ; 2 octet UTF-8 character %xE0-EF 2(%x80-BF) / ; 3 octet UTF-8 character %xF0-F7 3(%x80-BF) ; 4 octet UTF-8 character The positive-number rule is defined by the specification for component matching [CMR]. A valid component path for a particular non-trivial type is constructed by starting with the outermost type definition and repeatedly choosing one of the permissible forms of Step to select successively deeper nested component types. A component path MAY identify a component with a type that allows element content (i.e., child elements). Thus it is not required that the type selected by a component path be a simple type. Where a Step selects multiple content values the remaining Steps in the component path, if any, can select zero, one or more nested content values for each of the higher level content values. The [in-scope namespaces] for the element in the RXER encoding of a PathAssertion value are used to interpret any qualified names in the contained component path (in the other encodings of a PathAssertion value these namespace declarations appear in the attribute field of the component field, which is a Markup value). 10.3.1.1. ChildAxisStep A ChildAxisStep applied to a type selects, from amongst the type's child element declarations, the type of the element declaration that validates an element with the indicated qualified name (ElementName). The type to which a ChildAxisStep is applied MUST be a type that defines element content, e.g., an XML Schema complex type with complex content, a DTD element type with element content or mixed Legg & Prager Expires 16 May 2007 [Page 20] INTERNET-DRAFT XED: Matching Rules November 16, 2006 content, an ASN.1 SEQUENCE, SET, or SET OF type, an ASN.1 CHOICE type where the ChoiceType is not subject to an RXER UNION encoding instruction [RXEREI], or an ASN.1 SEQUENCE OF type where the SequenceOfType is not subject to an RXER LIST encoding instruction. In ASN.1, an element declaration corresponds to a NamedType that is not subject to an RXER ATTRIBUTE, ATTRIBUTE-REF, GROUP or SIMPLE-CONTENT encoding instruction [RXEREI]. The set of child element declarations for an ASN.1 type that is directly or indirectly a SEQUENCE, SET, SEQUENCE OF, SET OF or CHOICE type includes each such NamedType plus, for each NamedType that is subject to a GROUP encoding instruction, the child element declarations for the type of that NamedType. Each NamedType has an associated expanded name (see [RXEREI]). The ElementName is a qualified name, which has an associated expanded name [XMLNS10]. The ElementName in the ChildAxisStep selects the NamedType that has the same associated expanded name. Aside: A ChildAxisStep will always select a single distinct type because, in XML Schema, all child element declarations with a particular name and target namespace are required to have the same type, in DTDs, element names and types are indivisible, and in ASN.1, distinct instances of NamedType notation are required to have different expanded names [RXEREI]. The optional PositionPredicate does not alter the type selected by a ChildAxisStep. The ElementName in a ChildAxisStep applied to a content value selects, from amongst the content value's element information items, the content values of those element items where the [namespace name] and [local name] match the expanded name corresponding to the indicated qualified name (ElementName). Zero, one or more nested content values may be selected by the ElementName. These content values are numbered from one upwards in the order in which their associated elements appear in the XML document. If a PositionPredicate is not present in the ChildAxisStep, then the ChildAxisStep selects all the content values selected by the ElementName. If a PositionPredicate is present in the ChildAxisStep, then only the content value in the nominated position is selected by the ChildAxisStep. Taking the content values in the order in which their associated elements appear in the Infoset, the first content value is in position 1, the second in position 2, and so on. The PositionPredicate "[last()]" selects the last content value, "[last()-1]" selects the second last content value, "[last()-2]" Legg & Prager Expires 16 May 2007 [Page 21] INTERNET-DRAFT XED: Matching Rules November 16, 2006 selects the third last content value, and so on. If there is no content value for the nominated position, then no content value is selected by the ChildAxisStep. If the type to which a ChildAxisStep is applied is not an XML Schema type, then the type of each of the nested content values selected by the ChildAxisStep will be the type of the corresponding element declaration. If the type to which a ChildAxisStep is applied is an XML Schema type, then the type of each of the nested content values selected by the ChildAxisStep will be the type referenced by the xsi:type attribute, if present in the associated element's [attributes], otherwise it will be the type of the corresponding element declaration. Aside: If an xsi:type attribute is present in the element's [attributes], then by the rules of XML Schema, the type must be the same as the type of the corresponding element declaration or a derivation by restriction of the type of the element declaration. If ElementName selects the type of a child element corresponding to an XML Schema element declaration that specifies a default value and the content of the element is empty in a particular content value, then the selected nested content value is taken to be the default value. The setting of useDefaultValues is ignored in such cases. Example Consider this type definition and content value: <*> true red Legg & Prager Expires 16 May 2007 [Page 22] INTERNET-DRAFT XED: Matching Rules November 16, 2006 The ChildAxisStep "filled" applied to the polygon type selects the xsd:boolean type. The ChildAxisStep "filled" applied to the content value selects the nested content value <*>true. The ChildAxisStep "vertex" applied to the polygon type selects the anonymous complex type of the element declaration, as does the ChildAxisStep "vertex[1]", the ChildAxisStep "vertex[5]", and the ChildAxisStep "vertex[last()]". The ChildAxisStep "vertex" applied to the content value selects four nested content values: <* x="1.0" y="1.0"/> <* x="2.0" y="1.5"/> <* x="1.7" y="1.7"/> <* x="1.2" y="1.5"/> The ChildAxisStep "vertex[1]" applied to the content value selects the nested content value <* x="1.0" y="1.0"/>. The ChildAxisStep "vertex[5]" applied to the content value selects no nested content value. The ChildAxisStep "vertex[last()]" applied to the content value selects the nested content value <* x="1.2" y="1.5"/>. 10.3.1.2. AttributeAxisStep An AttributeAxisStep applied to a type selects, from amongst the type's attribute declarations, the type of the attribute declaration that validates an attribute with the indicated qualified name (AttributeName). A namespace declaration for the default namespace does not apply to an unprefixed AttributeName. The type to which an AttributeAxisStep is applied MUST be a type that declares attributes. In ASN.1, an attribute declaration corresponds to a NamedType that is subject to an RXER ATTRIBUTE or ATTRIBUTE-REF encoding instruction [RXEREI]. The set of attribute declarations for an ASN.1 type that is directly or indirectly a SEQUENCE, SET or CHOICE type includes each such NamedType plus, for each NamedType that is subject to a Legg & Prager Expires 16 May 2007 [Page 23] INTERNET-DRAFT XED: Matching Rules November 16, 2006 GROUP encoding instruction, the attribute declarations for the type of that NamedType. Each NamedType has an associated expanded name (see [RXEREI]). The AttributeName is a qualified name, which has an associated expanded name [XMLNS10]. The AttributeName in the AttributeAxisStep selects the NamedType that has the same associated expanded name. An AttributeAxisStep applied to a content value selects, from amongst the content value's attribute information items, the content value of the attribute information item where the [namespace name] and [local name] match the expanded name corresponding to the indicated qualified name (AttributeName). Zero or one nested content values will be selected. The type of a selected content value will be the type of the corresponding attribute declaration. Example Consider this type definition and content value: <* units="metres"> 0.788 The AttributeAxisStep "@units" applied to the complex type selects the xsd:string type. The AttributeAxisStep "@units" applied to the content value selects the content value <*>metres. 10.3.1.3. SimpleContentStep The type to which a SimpleContentStep is applied MUST be a type that defines simple content, either an XML Schema complex type with simple content, or an ASN.1 SEQUENCE or SET type with a NamedType that is subject to a SIMPLE-CONTENT encoding instruction [RXEREI]. A SimpleContentStep applied to an eligible XML Schema type selects the simple type definition for the simple content. A SimpleContentStep applied to an eligible ASN.1 type selects the type of the NamedType that is subject to the SIMPLE-CONTENT encoding instruction. A SimpleContentStep applied to a content value selects the character subset of the content value. The character subset is itself a Legg & Prager Expires 16 May 2007 [Page 24] INTERNET-DRAFT XED: Matching Rules November 16, 2006 content value and may be empty. The type of a selected content value will either be the simple type definition for the simple content or a type derived by restriction from it. Example Consider this type definition and content value: <* units="metres"> 0.788 The SimpleContentStep "simpleContent()" applied to the complex type selects the xsd:decimal type. The SimpleContentStep "simpleContent()" applied to the content value selects the nested content value <*> 0.788 . 10.3.1.4. ItemStep An ItemStep selects the item type from an XML Schema list type, or the component type from an ASN.1 SEQUENCE OF type where the SequenceOfType is subject to an RXER LIST encoding instruction [RXEREI]. The optional PositionPredicate does not alter the type selected by an ItemStep. The ItemValue in an ItemStep selects from a content value of a list type the zero, one or more subsequences of character information items corresponding to the atomic values of the list. Each subsequence is a content value. If a PositionPredicate is not present in the ItemStep, then the ItemStep selects all the content values selected by the ItemValue. If a PositionPredicate is present in the ItemStep, then only the content value in the nominated position is selected by the ItemStep. Taking the content values in the order in which their associated atomic values appear, the first content value is in position 1, the second in position 2, and so on. The PositionPredicate "[last()]" selects the last content value, "[last()-1]" selects the second last content value, "[last()-2]" selects the third last content value, and so on. If there is no content value for the nominated position, then no content value is selected by the ItemStep. Legg & Prager Expires 16 May 2007 [Page 25] INTERNET-DRAFT XED: Matching Rules November 16, 2006 Examples Consider this type definition: <*> red yellow green The ItemStep "itemType()" applied to the list type selects the xsd:NCName type, as does the ItemStep "itemType()[2]" and the ItemStep "itemType()[last()]". Consider this type definition: [RXER:LIST] SEQUENCE OF item NCName The ItemStep "itemType()" applied to the type selects the NCName type [RXER], as does the ItemStep "itemType()[2]" and the ItemStep "itemType()[last()]". Consider this content value, which is a valid content value for either of the two preceding type definitions: <*> red yellow green The ItemStep "itemType()" applied to the content value selects three content values: <*>red <*>yellow <*>green The ItemStep "itemType()[2]" applied to the content value selects only the content value <*>yellow. The ItemStep "itemType()[last()]" applied to the content value selects only the content value <*>green. 10.3.1.5. MemberStep A MemberStep selects a nominated member type from an XML Schema union type, or an ASN.1 CHOICE type where the ChoiceType is subject to an RXER UNION encoding instruction [RXEREI]. For an XML Schema union type, the member type is nominated by its position in the list of member types. The member types are numbered Legg & Prager Expires 16 May 2007 [Page 26] INTERNET-DRAFT XED: Matching Rules November 16, 2006 from one upwards beginning with the atomic values of the memberTypes attribute, followed by the child elements of the union type definition. For an ASN.1 CHOICE type where the ChoiceType is subject to an RXER UNION encoding instruction, the member type is the Type in the NamedType (one of the alternatives of the ChoiceType) nominated either by a qualified name (MemberName) corresponding to the expanded name of the NamedType [RXEREI], or by the position of the NamedType in the list of alternatives. The NamedType instances are numbered from one upwards in the order of their appearance in the ChoiceType. MemberName MUST NOT be used if the type is an XML Schema union type. If the member type of a content value of an XML Schema union type is the same as the member type selected by a MemberStep, then the MemberStep selects the entire content value, otherwise no content value is selected. Thus a MemberStep filters content values based on their actual member type. If the chosen alternative of a content value of an ASN.1 CHOICE type (where the ChoiceType is subject to an RXER UNION encoding instruction) is the same as the alternative selected by the MemberStep, then the MemberStep selects the entire content value, otherwise no content value is selected. Examples Consider this type definition: The MemberStep "member(1)" applied to this union type selects the xsd:positiveInteger type. The MemberStep "member(2)" selects the type defined by the child of the element. If <*>infinity is a content value of the union type, then the MemberStep "memberType(2)" selects this content value. Legg & Prager Expires 16 May 2007 [Page 27] INTERNET-DRAFT XED: Matching Rules November 16, 2006 If <*>27 is a content value of the union type, then the MemberStep "memberType(2)" does not select this content value. Consider this type definition: [RXER:UNION] CHOICE { number [0] INTEGER (1..MAX), special [1] ENUMERATED { zero, infinity } } The MemberStep "member(1)" applied to this type selects the anonymous type "[0] INTEGER (1..MAX)", as does the MemberStep "member(number)". If <*>infinity is a content value of the type, then the MemberStep "member(2)" selects this content value. If <*>27 is a content value of the type, then the MemberStep "member(2)" does not select this content value. 10.3.1.6. MemberTypeStep A MemberTypeStep selects a nominated member type from an XML Schema union type. For an XML Schema union type, the member type is nominated by a qualified name (TypeName) with the same underlying expanded name as one of the atomic values of the memberType attribute (each of which will correspond to a specific member type definition). The children of a union type cannot be selected by a MemberTypeStep. If the member type of a content value of an XML Schema union type is the same as the member type selected by a MemberTypeStep, then the MemberTypeStep selects the entire content value, otherwise no content value is selected. Thus a MemberTypeStep filters content values based on their actual member type. Examples Consider this type definition: Legg & Prager Expires 16 May 2007 [Page 28] INTERNET-DRAFT XED: Matching Rules November 16, 2006 The MemberTypeStep "memberType(xsd:positiveInteger)" applied to this union type selects the xsd:positiveInteger type (as does the MemberStep "member(1)"). There is no MemberTypeStep that can select the type defined by the child of the element (use the MemberStep "member(2)" instead). If <*>27 is a content value of the union type, then the MemberTypeStep "memberType(xsd:positiveInteger)" selects this content value. If <*>infinity is a content value of the union type, then the MemberTypeStep "memberType(xsd:positiveInteger)" does not select this content value. 10.3.1.7. CountStep A ChildCount CountStep applied to a type selects the ASN.1 type INTEGER (0..MAX). The type to which a ChildCount CountStep is applied MUST be a type that defines element content. A ChildCount CountStep applied to a content value generates a new content value that contains a sequence of decimal digit character information items representing the number of elements where the [namespace name] and [local name] match the expanded name corresponding to the indicated qualified name (ElementName). A ChildCount CountStep generates no new content value if the preceding steps in the component path selected no content values. Example Consider this type definition and content value: Legg & Prager Expires 16 May 2007 [Page 29] INTERNET-DRAFT XED: Matching Rules November 16, 2006 <*> true red The CountStep "count(vertex)" generates the content value <*>4. An ItemCount CountStep applied to a type selects the ASN.1 type INTEGER (0..MAX). The type to which an ItemCount CountStep is applied MUST be a list type, either an XML Schema list type or an ASN.1 SEQUENCE OF type where the SequenceOfType is subject to an RXER LIST encoding instruction [RXEREI]. An ItemCount CountStep generates a new content value that contains a sequence of decimal digit character information items representing the number of whitespace separated substrings in the content value to which the CountStep is applied. For an XML Schema list type, the substrings are the atomic values. For an ASN.1 SEQUENCE OF type where the SequenceOfType is subject to an RXER LIST encoding instruction, the substrings are values of the component type. An ItemCount CountStep generates no new content value if the preceding steps in the component path selected no content values. Example Consider this type definition and content value: <*> red yellow green The CountStep "count(itemType())" generates the content value <*>3. 10.3.1.8. ContentStep A ContentStep is the component path counterpart to the content form of ComponentId for a component reference [CMR]. The type to which a Legg & Prager Expires 16 May 2007 [Page 30] INTERNET-DRAFT XED: Matching Rules November 16, 2006 ContentStep is applied MUST be an ASN.1 BIT STRING or OCTET STRING type containing encodings of abstract values of some other ASN.1 type. 10.3.1.9. RestrictByStep A RestrictByStep is the component path counterpart to the select form of ComponentId for a component reference [CMR]. The type to which a RestrictByStep is applied MUST be an ASN.1 open type. Each ASN.1 abstract value standing in for one of the referenced components [CMR] is represented in a RestrictByStep as the Standalone RXER Encoding [RXER] of the abstract value (XMLValue in the ABNF). 10.4. The presentMatch Matching Rule In a PathAssertion, presentMatch evaluates to TRUE if and only if the component path selects one or more content values. Note that if useDefaultValues is TRUE, then the selected content values may be (part of) a default value. Note also that if the final step in a component path is a CountStep but the preceding steps selected no content values, then the CountStep will generate no content value and presentMatch will evaluate to FALSE. 10.5. Component Matching Examples 10.5.1. Examples for ASN.1 Types This section contains examples of search filters using the componentFilterMatch matching rule to match attributes with syntaxes defined by ASN.1 types. Each example filter is described firstly using component references and the string representation of LDAP search filters [STRFILT], and secondly, using component paths and the actual representation of the filter in an XLDAP search operation (i.e., the RXER encoding of the filter component of a Uniform LDAP search operation). For LDAP, the "transfer-rxer" encoding [TRANSFER] of the assertion value is equivalent to the elements after being extracted and renamed to . The examples and their string representations are reproduced from Section 7 of the original component matching specification [CMR]. The XLDAP representations are added by this specification. Note that the string representation of LDAP search filters requires asterisks to be escaped in assertion values. The asterisks have not been escaped in these examples for the sake of clarity, and to avoid Legg & Prager Expires 16 May 2007 [Page 31] INTERNET-DRAFT XED: Matching Rules November 16, 2006 confusing the protocol representation of LDAP search filter assertion values, where such escaping does not apply. Line breaks and indenting have been added only as an aid to readability. The optional xsi:type attributes on the and elements have been omitted to reduce clutter. The example search filters using componentFilterMatch are all single extensible match filter items, though there is no reason why componentFilterMatch cannot be used in more complicated search filters. The first examples describe searches over the objectClasses schema operational directory attribute, which has a directory attribute syntax described by the ASN.1 type ObjectClassDescription [X.501], 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, name SET SIZE (1..MAX) OF DirectoryString {ub-schema} OPTIONAL, description DirectoryString {ub-schema} OPTIONAL, obsolete BOOLEAN DEFAULT FALSE, information [0] ObjectClassInformation } ObjectClassInformation ::= SEQUENCE { subclassOf SET SIZE (1..MAX) OF OBJECT-CLASS.&id OPTIONAL, kind ObjectClassKind DEFAULT structural, mandatories [3] SET SIZE (1..MAX) OF ATTRIBUTE.&id OPTIONAL, optionals [4] SET SIZE (1..MAX) 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 a directory attribute type. The following search filter finds the object class definition for the object class identified by the OBJECT IDENTIFIER 2.5.6.18: (objectClasses:componentFilterMatch:= item:{ component "identifier", Legg & Prager Expires 16 May 2007 [Page 32] INTERNET-DRAFT XED: Matching Rules November 16, 2006 rule objectIdentifierMatch, value 2.5.6.18 }) 1.2.36.79672281.1.13.2 2.5.21.6 identifier 2.5.13.0 2.5.6.18 A match on the "identifier" component of objectClasses values is equivalent to the objectIdentifierFirstComponentMatch matching rule applied to directory attribute values of the objectClasses directory 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:{ component "name.*", rule caseIgnoreMatch, value "foobar" }) 1.2.36.79672281.1.13.2 2.5.21.6 name/item 2.5.13.2 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" selects the notional count of the number of names in an object class definition. The following search filter finds object class definitions with exactly one name: (objectClasses:componentFilterMatch:= item:{ component "name.0", rule integerMatch, value 1 }) 1.2.36.79672281.1.13.2 2.5.21.6 name/count(item) 2.5.13.14 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 }) 1.2.36.79672281.1.13.2 Legg & Prager Expires 16 May 2007 [Page 34] INTERNET-DRAFT XED: Matching Rules November 16, 2006 2.5.21.6 description 1.2.36.79672281.1.13.5 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:{ component "description", rule presentMatch, value NULL }) 1.2.36.79672281.1.13.2 2.5.21.6 description 1.2.36.79672281.1.13.5 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" } }) Legg & Prager Expires 16 May 2007 [Page 35] INTERNET-DRAFT XED: Matching Rules November 16, 2006 1.2.36.79672281.1.13.2 2.5.21.6 description 2.5.13.4 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 }) 1.2.36.79672281.1.13.2 2.5.21.6 obsolete 2.5.13.13 true Legg & Prager Expires 16 May 2007 [Page 36] INTERNET-DRAFT XED: Matching Rules November 16, 2006 An object class is not obsolete if the "obsolete" component is not 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 }) 1.2.36.79672281.1.13.2 2.5.21.6 obsolete 2.5.13.13 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 }) 1.2.36.79672281.1.13.2 2.5.21.6 obsolete false 2.5.13.13 Legg & Prager Expires 16 May 2007 [Page 37] INTERNET-DRAFT XED: Matching Rules November 16, 2006 false With the useDefaultValues flag set to FALSE, if the "obsolete" component is absent the component reference selects 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 ENUMERATED type. The allComponentsMatch matching rule can be used to match values of an ENUMERATED type. The following search filter finds object class definitions for auxiliary object classes: (objectClasses:componentFilterMatch:= item:{ component "information.kind", rule allComponentsMatch, value auxiliary }) 1.2.36.79672281.1.13.2 2.5.21.6 information/kind 1.2.36.79672281.1.13.6 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 allComponentsMatch, value auxiliary }, item:{ component "information.mandatories.*", rule objectIdentifierMatch, value cn } }) Legg & Prager Expires 16 May 2007 [Page 38] INTERNET-DRAFT XED: Matching Rules November 16, 2006 1.2.36.79672281.1.13.2 2.5.21.6 information/kind 1.2.36.79672281.1.13.6 auxiliary information/mandatories/item 2.5.13.0 2.5.4.3 The following search filter finds auxiliary object classes with commonName as a mandatory or optional attribute: (objectClasses:componentFilterMatch:=and:{ item:{ component "information.kind", rule allComponentsMatch, value auxiliary }, or:{ item:{ component "information.mandatories.*", rule objectIdentifierMatch, value cn }, item:{ component "information.optionals.*", rule objectIdentifierMatch, value cn } } }) 1.2.36.79672281.1.13.2 2.5.21.6 information/kind Legg & Prager Expires 16 May 2007 [Page 39] INTERNET-DRAFT XED: Matching Rules November 16, 2006 1.2.36.79672281.1.13.6 auxiliary information/mandatories/item 2.5.13.0 2.5.4.3 information/optionals/item 2.5.13.0 2.5.4.3 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 }) 1.2.36.79672281.1.13.2 2.5.21.6 Legg & Prager Expires 16 May 2007 [Page 40] INTERNET-DRAFT XED: Matching Rules November 16, 2006 name/count(item) 2.5.13.15 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:{ not:item:{ component "name", rule presentMatch, value NULL }, item:{ component "name.0", rule integerOrderingMatch, value 3 } }) 1.2.36.79672281.1.13.2 2.5.21.6 name 1.2.36.79672281.1.13.5 name/count(item) 2.5.13.15 3 Legg & Prager Expires 16 May 2007 [Page 41] INTERNET-DRAFT XED: Matching Rules November 16, 2006 Distinguished names embedded in other syntaxes can be matched with a componentFilterMatch. The uniqueMember directory 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 first author's DN: (uniqueMember:componentFilterMatch:= item:{ component "dn", rule distinguishedNameMatch, value "cn=Steven Legg,o=eB2Bcom,c=AU" }) 1.2.36.79672281.1.13.2 2.5.4.50 dn 2.5.13.1 2.5.4.6 AU 2.5.4.10 eB2Bcom 2.5.4.3 Steven Legg Legg & Prager Expires 16 May 2007 [Page 42] INTERNET-DRAFT XED: Matching Rules November 16, 2006 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. 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 directory 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 directory attribute values containing the RDN, "o=eB2Bcom", anywhere in the DN: (seeAlso:componentFilterMatch:= item:{ component "*", rule rdnMatch, value "o=eB2Bcom" }) 1.2.36.79672281.1.13.2 2.5.4.34 item 1.2.36.79672281.1.13 Legg & Prager Expires 16 May 2007 [Page 43] INTERNET-DRAFT XED: Matching Rules November 16, 2006 2.5.4.10 eB2Bcom The following search filter finds all seeAlso directory 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" }) 1.2.36.79672281.1.13.2 2.5.4.34 item[last()] 1.2.36.79672281.1.13 2.5.4.3 Steven Legg The following search filter finds all seeAlso directory attribute values naming entries in the DIT subtree of "o=eB2Bcom,c=AU": (seeAlso:componentFilterMatch:=and:{ item:{ component "1", rule rdnMatch, value "c=AU" }, item:{ component "2", rule rdnMatch, value "o=eB2Bcom" } }) Legg & Prager Expires 16 May 2007 [Page 44] INTERNET-DRAFT XED: Matching Rules November 16, 2006 1.2.36.79672281.1.13.2 2.5.4.34 item[1] 1.2.36.79672281.1.13 2.5.4.6 AU item[2] 1.2.36.79672281.1.13 2.5.4.10 eB2Bcom The following search filter finds all seeAlso directory attribute values containing the naming directory attribute types commonName (cn) and telephoneNumber in the same RDN: (seeAlso:componentFilterMatch:= item:{ component "*", rule componentFilterMatch, value and:{ item:{ component "*.type", rule objectIdentifierMatch, value cn }, item:{ component "*.type", rule objectIdentifierMatch, value telephoneNumber } } }) Legg & Prager Expires 16 May 2007 [Page 45] INTERNET-DRAFT XED: Matching Rules November 16, 2006 1.2.36.79672281.1.13.2 2.5.4.34 item 1.2.36.79672281.1.13.2 item/type 2.5.13.0 2.5.4.3 item/type 2.5.13.0 2.5.4.20 The following search filter would find all seeAlso directory attribute values containing the directory 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 } }) Legg & Prager Expires 16 May 2007 [Page 46] INTERNET-DRAFT XED: Matching Rules November 16, 2006 1.2.36.79672281.1.13.2 2.5.4.34 item/item/type 2.5.13.0 2.5.4.3 item/item/type 2.5.13.0 2.5.4.20 The following search filter finds all seeAlso directory attribute values containing the word "eB2Bcom" in any organizationalUnitName (ou) directory attribute value in any AttributeTypeAndValue of any RDN: (seeAlso:componentFilterMatch:= item:{ component "*.*.value.(2.5.4.11)", rule caseIgnoreSubstringsMatch, value { any:"eB2Bcom" } }) 1.2.36.79672281.1.13.2 2.5.4.34 item/item/value/restrictBy(2.5.4.11) 2.5.13.4 Legg & Prager Expires 16 May 2007 [Page 47] INTERNET-DRAFT XED: Matching Rules November 16, 2006 eB2Bcom The component reference "*.*.value" selects an open type, in this case a directory attribute value. In a particular AttributeTypeAndValue, if the directory attribute type is not organizationalUnitName, then the ComponentAssertion evaluates to FALSE. Otherwise the substring assertion is evaluated against the directory attribute value. Absent component references in ComponentAssertions can be exploited to avoid false positive matches on multi-valued attributes. For example, suppose there is a multi-valued attribute named productCodes (1.3.6.1.4.1.21472.5.4.0.2), defined to have the Integer syntax (1.3.6.1.4.1.1466.115.121.1.27). Consider the following search filter: (&(!(productCodes:integerOrderingMatch:=3)) (productCodes:integerOrderingMatch:=8)) 2.5.13.15 1.3.6.1.4.1.21472.5.4.0.2 3 2.5.13.15 1.3.6.1.4.1.21472.5.4.0.2 Legg & Prager Expires 16 May 2007 [Page 48] INTERNET-DRAFT XED: Matching Rules November 16, 2006 8 An entry whose productCodes attribute contains only the values 1 and 10 will match the above filter. The first subfilter is satisfied by the value 10 (10 is not less than 3), and the second subfilter is satisfied by the value 1 (1 is less than 8). The following search filter can be used instead to only match entries that have a productCodes value in the range 3 to 7, because the ComponentFilter is evaluated against each productCodes value in isolation: (productCodes:componentFilterMatch:= and:{ not:item:{ rule integerOrderingMatch, value 3 }, item:{ rule integerOrderingMatch, value 8 } }) 1.2.36.79672281.1.13.2 1.3.6.1.4.1.21472.5.4.0.2 2.5.13.15 3 2.5.13.15 8 An entry whose productCodes attribute contains only the values 1 and Legg & Prager Expires 16 May 2007 [Page 49] INTERNET-DRAFT XED: Matching Rules November 16, 2006 10 will not match the above filter. 10.5.2. Examples for XML Schema Types This section contains examples of search filters using the componentFilterMatch matching rule to match attributes with syntaxes defined by XML Schema types. Each example filter is described using the actual representation of the filter in an XLDAP search operation. These examples necessarily use component paths since component references cannot select component parts of XML Schema types. The optional xsi:type attributes on the and elements have been omitted to reduce clutter. Examples TO BE SUPPLIED. 11. Security Considerations This document extends the applicability of directory matching rules to new data types not previously used in directories, but does not alter their essential nature, and does not alter their behaviour when used in the traditional context. Hence the general security considerations that already apply to the use of directory matching rules [SYNTAX][RULES][CMR] still apply in full. However, directory server support for the extended matching rules specified in this document may allow searching of directory attributes that are otherwise unsearchable by virtue of there not being a suitable matching rule. Such directory attribute types ought to be properly protected with appropriate access controls. 12. Acknowledgements The technology described in this document is the product of a research project begun jointly by Adacel Technologies Limited and Deakin University, and subsequently refined and completed by eB2Bcom. 13. IANA Considerations The Internet Assigned Numbers Authority (IANA) is requested to register a new XML namespace in accordance with RFC 3688 [XMLREG]. URI: urn:ietf:params:xml:ns:xed-cmr Registrant Contact: Steven Legg XML: None Legg & Prager Expires 16 May 2007 [Page 50] INTERNET-DRAFT XED: Matching Rules November 16, 2006 14. References 14.1. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [CMR] Legg, S., "Lightweight Directory Access Protocol (LDAP) and X.500 Component Matching Rules", RFC 3687, February 2004. [RFC3688] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004. [CMRM] Legg, S., "ASN.1 Module Definition for the LDAP and X.500 Component Matching Rules", RFC 3727, February 2004. [RULES] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Additional Matching Rules", RFC 3698, February 2004. [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [LDAP] Zeilenga, K., Ed., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006. [MODELS] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006. [PROT] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, June 2006. [SYNTAX] Legg, S., Ed., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006. [PREP] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation", RFC 4518, June 2006. [STRFILT] Smith, M. and T. Howes, "LDAP: String Representation of Search Filters", draft-ietf-ldapbis-filter-xx.txt, a work in progress, November 2004. [RXER] Legg, S. and D. Prager, "Robust XML Encoding Rules (RXER) for Abstract Syntax Notation One (ASN.1)", Legg & Prager Expires 16 May 2007 [Page 51] INTERNET-DRAFT XED: Matching Rules November 16, 2006 draft-legg-xed-rxer-xx.txt, a work in progress, October 2006. [RXEREI] Legg, S., "Encoding Instructions for the Robust XML Encoding Rules (RXER)", draft-legg-xed-rxer-ei-xx.txt, a work in progress, October 2006. [XED] Legg, S. and D. Prager, "The XML Enabled Directory", draft-legg-xed-roadmap-xx.txt, a work in progress, October 2006. [SCHEMA] Legg, S. and D. Prager, "The XML Enabled Directory: Schema Operational Attributes", draft-legg-xed-schema-xx.txt, a work in progress, November 2006. [X.500] ITU-T Recommendation X.500 (08/05) | ISO/IEC 9594-1:2005, Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services [X.501] ITU-T Recommendation X.501 (08/05) | ISO/IEC 9594-2:2005, Information technology - Open Systems Interconnection - The Directory: Models [X.520] ITU-T Recommendation X.520 (08/05) | ISO/IEC 9594-6:2005, Information technology - Open Systems Interconnection - The Directory: Selected attribute types [X.680] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation. [XML10] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C Recommendation, http://www.w3.org/TR/2006/REC-xml-20060816, August 2006. [XML11] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., Yergeau, F., and J. Cowan, "Extensible Markup Language (XML) 1.1 (Second Edition)", W3C Recommendation, http://www.w3.org/TR/2006/REC-xml11-20060816, August 2006. [XMLNS10] Bray, T., Hollander, D., Layman, A., and R. Tobin, "Namespaces in XML 1.0 (Second Edition)", W3C Recommendation, http://www.w3.org/TR/2006/REC-xml-names-20060816, August 2006. [ISET] Cowan, J. and R. Tobin, "XML Information Set (Second Legg & Prager Expires 16 May 2007 [Page 52] INTERNET-DRAFT XED: Matching Rules November 16, 2006 Edition)", W3C Recommendation, http://www.w3.org/TR/2004/REC-xml-infoset-20040204, February 2004. [XSD1] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C Recommendation, http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/, October 2004. [XSD2] Biron, P.V. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C Recommendation, http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/, October 2004. [RNG] Clark, J. and M. Makoto, "RELAX NG Tutorial", OASIS Committee Specification, http://www.oasis- open.org/committees/relax-ng/tutorial-20011203.html, December 2001. 14.2. Informative References [GSER] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1 Types", RFC 3641, October 2003. [TRANSFER] Legg, S., "Lightweight Directory Access Protocol (LDAP): Transfer Encoding Options", draft-legg-ldap-transfer-xx.txt, a work in progress, August 2006. [XPATH] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Kay, M., Robie, J. and J. Simeon, "XML Path Language (XPath) 2.0", W3C Candidate Recommendation, http://www.w3.org/TR/2006/CR-xpath20-20060608, June 2006. [XLDAP] Legg, S. and D. Prager, "The XML Enabled Directory: Protocols", draft-legg-xed-protocols-xx.txt, a work in progress, November 2006. [ASN.X] Legg, S., "Abstract Syntax Notation X (ASN.X)", draft-legg-xed-asd-xx.txt, a work in progress, October 2006. Appendix A. ASN.1 for Component Matching Rules This appendix is normative. ComponentMatching Legg & Prager Expires 16 May 2007 [Page 53] INTERNET-DRAFT XED: Matching Rules November 16, 2006 { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) xmled(21472) ds(5) module(1) component-matching(1) } -- Copyright (C) The IETF Trust (2006). This version of -- this ASN.1 module is part of RFC XXXX; see the RFC itself -- for full legal notices. DEFINITIONS EXPLICIT TAGS EXTENSIBILITY IMPLIED ::= BEGIN IMPORTS MATCHING-RULE, RelativeDistinguishedName FROM InformationFramework { joint-iso-itu-t ds(5) module(1) informationFramework(1) 5 } Markup FROM AdditionalBasicDefinitions { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) xmled(21472) asnx(1) module(0) basic(0) } ; ComponentAssertion ::= SEQUENCE { component ComponentReference (SIZE(1..MAX)) OPTIONAL, useDefaultValues BOOLEAN DEFAULT TRUE, rule MATCHING-RULE.&id, value MATCHING-RULE.&AssertionType } ComponentReference ::= UTF8String PathAssertion ::= SEQUENCE { component ComponentPath OPTIONAL, useDefaultValues BOOLEAN DEFAULT TRUE, rule MATCHING-RULE.&id, value MATCHING-RULE.&AssertionType } ComponentPath ::= Markup (CONSTRAINED BY { -- contains a component path expression -- }) ComponentFilter ::= CHOICE { item [0] ComponentAssertion, and [1] SEQUENCE OF filter ComponentFilter, or [2] SEQUENCE OF filter ComponentFilter, not [3] ComponentFilter, Legg & Prager Expires 16 May 2007 [Page 54] INTERNET-DRAFT XED: Matching Rules November 16, 2006 ..., term [4] PathAssertion } componentFilterMatch MATCHING-RULE ::= { SYNTAX ComponentFilter ID { 1 2 36 79672281 1 13 2 } } allComponentsMatch MATCHING-RULE ::= { ID { 1 2 36 79672281 1 13 6 } } directoryComponentsMatch MATCHING-RULE ::= { ID { 1 2 36 79672281 1 13 7 } } -- Additional Useful Matching Rules -- rdnMatch MATCHING-RULE ::= { SYNTAX RelativeDistinguishedName ID { 1 2 36 79672281 1 13 3 } } presentMatch MATCHING-RULE ::= { SYNTAX NULL ID { 1 2 36 79672281 1 13 5 } } ENCODING-CONTROL RXER SCHEMA-IDENTITY "urn:oid:1.3.6.1.4.1.21472.5.1.1" TARGET-NAMESPACE "urn:ietf:params:xml:ns:xed-cmr" PREFIX "cmr" END The InformationFramework ASN.1 module from which the MATCHING-RULE and RelativeDistinguishedName definitions are imported is defined in X.501 [X.501]. The object identifier for the ComponentMatching module has been assigned by xmled.org under an arc assigned to xmled.org by IANA. The other object identifiers were previously assigned in RFC 3687 [CMR]. Appendix B. ASN.X for Component Matching Rules This appendix contains the ASN.X [ASN.X] translation of the ComponentMatching module. This appendix is non-normative. Legg & Prager Expires 16 May 2007 [Page 55] INTERNET-DRAFT XED: Matching Rules November 16, 2006 Copyright (C) The IETF Trust (2006). This version of this ASN.X module is part of RFC XXXX; see the RFC itself for full legal notices. Legg & Prager Expires 16 May 2007 [Page 56] INTERNET-DRAFT XED: Matching Rules November 16, 2006 contains a component path expression Legg & Prager Expires 16 May 2007 [Page 57] INTERNET-DRAFT XED: Matching Rules November 16, 2006 Legg & Prager Expires 16 May 2007 [Page 58] INTERNET-DRAFT XED: Matching Rules November 16, 2006 Authors' Addresses Dr. Steven Legg eB2Bcom Suite 3, Woodhouse Corporate Centre 935 Station Street Box Hill North, Victoria 3129 AUSTRALIA Phone: +61 3 9896 7830 Fax: +61 3 9896 7801 EMail: steven.legg@eb2bcom.com Legg & Prager Expires 16 May 2007 [Page 59] INTERNET-DRAFT XED: Matching Rules November 16, 2006 Dr. Daniel Prager EMail: dap@austhink.com Full Copyright Statement Copyright (C) The IETF Trust (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Note to the RFC Editor: the remainder of this document is to be removed before final publication. Changes in Draft 01 Legg & Prager Expires 16 May 2007 [Page 60] INTERNET-DRAFT XED: Matching Rules November 16, 2006 ASN.1 Schema has been renamed to Abstract Syntax Notation X (ASN.X) and the element has been renamed to . Changes in Draft 02 Appendix C, an XML Schema translation of the ComponentMatching module, has been removed. The AnyType ASN.1 type has been renamed to Markup. The SimpleContentStep may be applied to an ASN.1 SEQUENCE or SET type with a NamedType that is subject to a SIMPLE-CONTENT encoding instruction. The MemberTypeStep can no longer be applied to an ASN.1 CHOICE type. Legg & Prager Expires 16 May 2007 [Page 61]