INTERNET-DRAFT S. Legg draft-legg-xed-matching-00.txt eB2Bcom Intended Category: Standards Track D. Prager Updates: RFC 3687 February 14, 2005 Obsoletes: RFC 3727 The XML Enabled Directory: Matching Rules Copyright (C) The Internet Society (2005). All Rights Reserved. Status of this Memo By submitting this Internet-draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, or will be disclosed, and any of which we become aware will be disclosed, in accordance with RFC 3668. By submitting this Internet-draft, we accept the provisions of Section 3 of RFC 3667. 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/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. 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 14 August 2005. Abstract Legg & Prager Expires 14 August 2005 [Page 1] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 Document Type Declaration (DTD) element type declarations. This document enables 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 14 August 2005 [Page 2] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 . . . . . . . . . 22 10.3.1.3. SimpleContentStep . . . . . . . . . 23 10.3.1.4. ItemStep. . . . . . . . . . . . . . 24 10.3.1.5. MemberStep. . . . . . . . . . . . . 25 10.3.1.6. MemberTypeStep. . . . . . . . . . . 27 10.3.1.7. CountStep . . . . . . . . . . . . . 28 10.3.1.8. ContentStep . . . . . . . . . . . . 30 10.3.1.9. RestrictByStep. . . . . . . . . . . 30 10.4. The presentMatch Matching Rule. . . . . . . . . . . . . 30 10.5. Component Matching Examples . . . . . . . . . . . . . . 31 10.5.1. Examples for ASN.1 Types . . . . . . . . . . . 31 10.5.2. Examples for XML Schema Types. . . . . . . . . 49 11. Security Considerations. . . . . . . . . . . . . . . . . . . . 49 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50 13. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 50 Appendix A. ASN.1 for Component Matching Rules . . . . . . . . . . 50 Appendix B. ASN.1 Schema for Component Matching Rules. . . . . . . 52 Appendix C. XML Schema for Component Matching Rules. . . . . . . . 56 Normative References . . . . . . . . . . . . . . . . . . . . . . . 57 Informative References . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 60 Intellectual Property. . . . . . . . . . . . . . . . . . . . . . . 60 1. Introduction Matching rules [MODELS] are used by Lightweight Directory Access Legg & Prager Expires 14 August 2005 [Page 3] INTERNET-DRAFT XED: Matching Rules February 14, 2005 Protocol (LDAP) [LDAP] and X.500 [X500] directory implementations to compare directory attribute values against assertion values when performing Search and Compare operations [PROT], to compare a 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 [XML] 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 Document Type Declaration (DTD) [XML] 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, 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) [X680] 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 are presented per the Infoset, e.g., [local name]. In the sections that follow, the term "element" shall be taken to mean an Infoset element information item. Legg & Prager Expires 14 August 2005 [Page 4] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 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 [XMLNS] "asn1:" to stand for the namespace name "http://xmled.info/ns/ASN.1", 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: 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: An attribute information item is type-visible if its [namespace name] is not "http://www.w3.org/2001/XMLSchema-instance" or "http://xmled.info/ns/ASN.1". 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 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, Legg & Prager Expires 14 August 2005 [Page 5] INTERNET-DRAFT XED: Matching Rules February 14, 2005 therefore entity references should be avoided. 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 [XMLNS] in content values. The type of a content value for an element is the type against which the element's content is validated. Definition: 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: 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: 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: 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 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 14 August 2005 [Page 6] INTERNET-DRAFT XED: Matching Rules February 14, 2005 <* 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 AnyType ASN.1 type [RXER] holds the content of an element. That content will have an associated content value, possibly with nested content values. If AnyType values are constrained by Robust XML Encoding Rules (RXER) 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 AnyType 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 AnyType ASN.1 type. An ASN.1 abstract value of an ASN.1 type other than AnyType 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 an AnyType abstract value, the type of a content value is never the AnyType 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 14 August 2005 [Page 7] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 AnyType 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 AnyType 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 AnyType 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 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 (represented in ASN.1 terms as a constrained form of the AnyType 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][X520] 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. Note that the assertion syntax of the booleanMatch matching rule is still the LDAP Boolean syntax (corresponding to the ASN.1 BOOLEAN Legg & Prager Expires 14 August 2005 [Page 8] INTERNET-DRAFT XED: Matching Rules February 14, 2005 type) even when the rule is used to match content values of the XML Schema boolean type. 6. Character String Matching The caseIgnoreMatch [SYNTAX][X520], caseExactMatch [RULES][X520], caseIgnoreOrderingMatch [SYNTAX][X520], caseExactOrderingMatch [RULES][X520], caseIgnoreSubstringsMatch [SYNTAX][X520], caseExactSubstringsMatch [RULES][X520], storedPrefixMatch [RULES][X520], wordMatch [RULES][X520, keywordMatch [RULES][X520], generalWordMatch [X520] and approximateStringMatch [X520] 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, IDREF and ENTITY types are all simple types derived by restriction from the string type. 7. Date/Time Matching The generalizedTimeMatch [SYNTAX][X520] and generalizedTimeOrderingMatch [SYNTAX][X520] 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][X520] and integerOrderingMatch [X520] matching rules may be applied to content values whose type is the XML Schema integer type [XSD2], or a simple type derived by Legg & Prager Expires 14 August 2005 [Page 9] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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][X520], octetStringOrderingMatch [X520] and octetStringSubstringsMatch [X520] 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 AnyType values the extension of allComponentsMatch is effected by altering how abstract values of the AnyType ASN.1 type are matched. Thus AnyType is not treated like an ordinary ASN.1 CHOICE type by allComponentsMatch. Two AnyType 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. If an attribute with a particular [local name] and [namespace name] Legg & Prager Expires 14 August 2005 [Page 10] INTERNET-DRAFT XED: Matching Rules February 14, 2005 is absent from only one of the attribute subsets and the associated attribute definition 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 "http://xmled.info/ns/ASN.1" 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 [children] and the associated element definition specifies a default value then the element is assumed to have that default value. Legg & Prager Expires 14 August 2005 [Page 11] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 definition specifies a default value then the element is assumed to have that default value. Subject to the preceding paragraph, when comparing two information items: 1) if they are both element information items then the result is the result of comparing the elements, Legg & Prager Expires 14 August 2005 [Page 12] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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, 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 Legg & Prager Expires 14 August 2005 [Page 13] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 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 with element-only content: 1) if the result of comparing their attribute subsets is FALSE then the result is FALSE, Legg & Prager Expires 14 August 2005 [Page 14] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 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]. Legg & Prager Expires 14 August 2005 [Page 15] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 a limited subset of unqualified names. 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, value MATCHING-RULE.&AssertionType } ComponentPath ::= AnyType (CONSTRAINED BY { -- contains a component path expression -- }) ComponentFilter ::= CHOICE { Legg & Prager Expires 14 August 2005 [Page 16] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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. 10.3.1. Component Path The component field of a PathAssertion contains a component path; a structured sequence of character and element 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 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 [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 Legg & Prager Expires 14 August 2005 [Page 17] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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. Ignoring any XML comments and processing instructions, a component path conforms to the following ABNF [2]: ComponentPath = *( sp Step sp "/" ) sp (Step / CountStep) Step = ChildAxisStep / AttributeAxisStep / SimpleContentStep / ItemStep / MemberStep / MemberTypeStep / ContentStep / RestrictByStep ChildAxisStep = ElementName [ sp PositionPredicate ] AttributeAxisStep = AttributeName 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 Legg & Prager Expires 14 August 2005 [Page 18] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 Letter = UTF8-Char ; the UTF-8 encoding of any character ; permitted by the Letter production ; of XML [XML] Digit = UTF8-Char ; the UTF-8 encoding of any character ; permitted by the Digit production ; of XML [XML] CombiningChar = UTF8-Char ; the UTF-8 encoding of any character ; permitted by the CombiningChar ; production of XML [XML] Extender = UTF8-Char ; the UTF-8 encoding of any character ; permitted by the Extender production ; of XML [XML] 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 Legg & Prager Expires 14 August 2005 [Page 19] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 context and attribute fields of the component field, which is an AnyType value). 10.3.1.1. ChildAxisStep A ChildAxisStep applied to a type selects, from amongst the type's child element definitions, the type of the element whose element name (in ASN.1, the effective name of a NamedType [RXEREI]) matches 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 content, an ASN.1 SEQUENCE, SET, or SET OF type, an ASN.1 CHOICE type (except where the ChoiceType is subject to an RXER UNION encoding instruction [RXEREI]), or an ASN.1 SEQUENCE OF type (except where the SequenceOfType is subject to an RXER LIST encoding instruction [RXEREI]). ASIDE: A ChildAxisStep will always select a single distinct type because, in XML Schema, all child element definitions with a particular qualified name are required to have the same type, in DTDs, element names and types are indivisible, and in ASN.1 (where an element definition corresponds to a NamedType), distinct instances of NamedType notation are required to have different effective 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 elements whose names match the indicated qualified name (QName). 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. Legg & Prager Expires 14 August 2005 [Page 20] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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]" 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 definition. 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 definition. 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 corresponding element definition or a derivation by restriction of the type of the element definition. If ElementName selects the type of a child element corresponding to an XML Schema element definition 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: Legg & Prager Expires 14 August 2005 [Page 21] INTERNET-DRAFT XED: Matching Rules February 14, 2005 <*> true red 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 definition, 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 definitions, the type of the attribute whose attribute name matches the indicated qualified name (AttributeName). The type to which an AttributeAxisStep is applied MUST be a type that Legg & Prager Expires 14 August 2005 [Page 22] INTERNET-DRAFT XED: Matching Rules February 14, 2005 defines attributes. An AttributeAxisStep applied to a content value selects, from amongst the content value's attribute information items, the content value of the attribute whose name matches 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 definition. 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 (an XML Schema complex type with simple content). A SimpleContentStep applied to such a type selects the simple type definition for the simple content. A SimpleContentStep applied to a content value selects the character subset of the content value. The character subset is itself a 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: Legg & Prager Expires 14 August 2005 [Page 23] INTERNET-DRAFT XED: Matching Rules February 14, 2005 <* 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. Examples Consider this type definition: <*> red yellow green Legg & Prager Expires 14 August 2005 [Page 24] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 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 a NamedType (one of the alternatives of the ChoiceType) nominated either by the effective name of the NamedType [RXEREI] (MemberName) or by the position of the NamedType in the list of alternatives. The NamedType instances are numbered from one upwards in the order of Legg & Prager Expires 14 August 2005 [Page 25] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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. 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 } } Legg & Prager Expires 14 August 2005 [Page 26] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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, 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 qualified name (TypeName); one of the atomic values of the memberTypes attribute. The children of a union type cannot be selected by a MemberTypeStep. For an ASN.1 CHOICE type where the ChoiceType is subject to an RXER UNION encoding instruction, the member type is nominated by the TypeName. The TypeName MUST be the Qualified Reference Name [RXER] of a type that results from substitutions of the kind described in Section 3.1.1 of the specification for component matching [CMR] applied to the type of at least one of the alternatives of the CHOICE. ASIDE: More latitude is permitted in associating the TypeName with one or more alternatives of the CHOICE type because the user may be using the XML Schema translation [CXSD] of the ASN.1 type as the point of reference. ASN.1 tagging, some type reference notations, and some kinds of constraint won't be evident in the translation. 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. 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 same as an alternative selected by the TypeName then the MemberTypeStep selects the entire content value, otherwise no content value is selected. Note that content values of more than one of the alternatives can be selected by the MemberTypeStep. Legg & Prager Expires 14 August 2005 [Page 27] INTERNET-DRAFT XED: Matching Rules February 14, 2005 Examples Consider this type definition: 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. Consider this type definition: [RXER:UNION] CHOICE { small [0] INTEGER (1..9), large [1] INTEGER (10..MAX), special [2] ENUMERATED { zero, infinity } } The MemberTypeStep "memberType(asn1:INTEGER)" applied to this type selects the INTEGER type. Note that this differs from the MemberStep "member(small)", which selects the type "[0] INTEGER (1..9)", and the MemberStep "member(large)", which selects the type "[0] INTEGER (10..MAX)". If <*>5 and <*>27 are content values of the type then the MemberTypeStep "memberType(asn1:INTEGER)" selects both of these content values. 10.3.1.7. CountStep Legg & Prager Expires 14 August 2005 [Page 28] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 whose element names match 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: <*> 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 Legg & Prager Expires 14 August 2005 [Page 29] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 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 Legg & Prager Expires 14 August 2005 [Page 30] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 [18], 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). The elements are also valid as the "transfer-rxer" encoding of the assertion value in LDAP. 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 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 [X501], 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 OF DirectoryString {ub-schema} OPTIONAL, description DirectoryString {ub-schema} OPTIONAL, obsolete BOOLEAN DEFAULT FALSE, Legg & Prager Expires 14 August 2005 [Page 31] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 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", 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. Legg & Prager Expires 14 August 2005 [Page 32] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 Legg & Prager Expires 14 August 2005 [Page 33] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 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 Legg & Prager Expires 14 August 2005 [Page 34] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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" } }) 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} } Legg & Prager Expires 14 August 2005 [Page 35] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 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 Legg & Prager Expires 14 August 2005 [Page 36] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 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 Legg & Prager Expires 14 August 2005 [Page 37] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 } }) 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 Legg & Prager Expires 14 August 2005 [Page 38] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 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 Legg & Prager Expires 14 August 2005 [Page 39] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 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 Legg & Prager Expires 14 August 2005 [Page 40] INTERNET-DRAFT XED: Matching Rules February 14, 2005 2.5.21.6 name 1.2.36.79672281.1.13.5 name/count(item) 2.5.13.15 3 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 Legg & Prager Expires 14 August 2005 [Page 41] INTERNET-DRAFT XED: Matching Rules February 14, 2005 dn 2.5.13.1 2.5.4.6 AU 2.5.4.10 eB2Bcom 2.5.4.3 Steven Legg 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 Legg & Prager Expires 14 August 2005 [Page 42] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 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 Legg & Prager Expires 14 August 2005 [Page 43] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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" } }) 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 Legg & Prager Expires 14 August 2005 [Page 44] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 } } }) 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 Legg & Prager Expires 14 August 2005 [Page 45] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 } }) 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 Legg & Prager Expires 14 August 2005 [Page 46] INTERNET-DRAFT XED: Matching Rules February 14, 2005 (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 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)) Legg & Prager Expires 14 August 2005 [Page 47] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 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 Legg & Prager Expires 14 August 2005 [Page 48] INTERNET-DRAFT XED: Matching Rules February 14, 2005 2.5.13.15 3 2.5.13.15 8 An entry whose productCodes attribute contains only the values 1 and 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 Legg & Prager Expires 14 August 2005 [Page 49] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 This document and the technology it describes are in part a product of a joint research project between Adacel Technologies Limited and Deakin University on leveraging existing directory technology to produce an XML-based directory service. 13. IANA Considerations This document has no actions for IANA. Appendix A. ASN.1 for Component Matching Rules This appendix is normative. ComponentMatching { 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 Internet Society (2005). 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) 4 } AnyType FROM AdditionalBasicDefinitions { iso(1) identified-organization(3) dod(6) internet(1) private(4) enterprise(1) xmled(21472) asn1(1) module(0) basic(0) } ; ComponentAssertion ::= SEQUENCE { component ComponentReference (SIZE(1..MAX)) OPTIONAL, useDefaultValues BOOLEAN DEFAULT TRUE, Legg & Prager Expires 14 August 2005 [Page 50] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 ::= AnyType (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 } 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 "http://xmled.info/id/XED/1/ComponentMatching" TARGET-NAMESPACE "http://xmled.info/ns/XED/1/ComponentMatching" Legg & Prager Expires 14 August 2005 [Page 51] INTERNET-DRAFT XED: Matching Rules February 14, 2005 END The InformationFramework ASN.1 module from which the MATCHING-RULE and RelativeDistinguishedName definitions are imported is defined in X.501 [X501]. 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.1 Schema for Component Matching Rules This appendix is non-normative. Legg & Prager Expires 14 August 2005 [Page 52] INTERNET-DRAFT XED: Matching Rules February 14, 2005 Legg & Prager Expires 14 August 2005 [Page 53] INTERNET-DRAFT XED: Matching Rules February 14, 2005 Legg & Prager Expires 14 August 2005 [Page 54] INTERNET-DRAFT XED: Matching Rules February 14, 2005 Legg & Prager Expires 14 August 2005 [Page 55] INTERNET-DRAFT XED: Matching Rules February 14, 2005 Appendix C. XML Schema for Component Matching Rules This appendix contains a compatible XML Schema [CXSD] translation of the ComponentMatching module. This appendix is non-normative. Legg & Prager Expires 14 August 2005 [Page 56] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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. [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. [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", draft-ietf-ldapbis-roadmap-xx.txt, a work in progress, Legg & Prager Expires 14 August 2005 [Page 57] INTERNET-DRAFT XED: Matching Rules February 14, 2005 October 2004. [MODELS] Zeilenga, K., "LDAP: Directory Information Models", draft-ietf-ldapbis-models-xx.txt, a work in progress, October 2004. [PROT] Sermersheim, J., "LDAP: The Protocol", draft-ietf-ldapbis-protocol-xx.txt, a work in progress, February 2005. [SYNTAX] Legg, S. and K. Dally, "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress, October 2004. [PREP] Zeilenga, K., "LDAP: Internationalized String Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in progress, February 2005. [RXER] Legg, S. and D. Prager, "Robust XML Encoding Rules for Abstract Syntax Notation One (ASN.1)", draft-legg-xed-rxer-xx.txt, a work in progress, February 2005. [RXEREI] Legg, S., "Encoding Instructions for the Robust XML Encoding Rules (RXER)", draft-legg-xed-rxer-ei-xx.txt, a work in progress, February 2005. [XED] Legg, S. and D. Prager, "The XML Enabled Directory", draft-legg-xed-roadmap-xx.txt, a work in progress, June 2004. [SCHEMA] Legg, S. and D. Prager, "The XML Enabled Directory: Schema Operational Attributes", draft-legg-xed-schema-xx.txt, a work in progress, June 2004. [X500] ITU-T Recommendation X.500 (02/01) | ISO/IEC 9594-1:2001, Information technology - Open Systems Interconnection - The Directory: Overview of concepts, models and services [X501] ITU-T Recommendation X.501 (02/01) | ISO/IEC 9594-2:2001, Information technology - Open Systems Interconnection - The Directory: Models [X520] ITU-T Recommendation X.520 (02/01) | ISO/IEC 9594-6:2001, Information technology - Open Systems Interconnection - The Directory: Selected attribute types Legg & Prager Expires 14 August 2005 [Page 58] INTERNET-DRAFT XED: Matching Rules February 14, 2005 [X680] ITU-T Recommendation X.680 (07/02) | ISO/IEC 8824-1:2002, Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation. [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E. and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C Recommendation, http://www.w3.org/TR/2004/REC-xml-20040204, February 2004. [XMLNS] Bray, T., Hollander, D. and A. Layman, "Namespaces in XML", http://www.w3.org/TR/1999/REC-xml-names-19990114, January 1999. [ISET] Cowan, J. and R. Tobin, "XML Information Set", W3C Recommendation, http://www.w3.org/TR/2001/REC-xml- infoset-20011024, October 2001. [XSD1] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C Recommendation, http://www.w3.org/TR/2001/REC-xmlschema-1-20010502, May 2001. [XSD2] Biron, P.V. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C Recommendation, http://www.w3.org/TR/2001/REC-xmlschema-2-20010502, May 2001. [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. Informative References [XPATH] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Kay, M., Robie, J. and J. Simeon, "XML Path Language (XPath) 2.0", W3C Working Draft, http://www.w3.org/TR/2003/WD- xpath20-20030502, a work in progress, May 2003. [XLDAP] Legg, S. and D. Prager, "The XML Enabled Directory: Protocols", draft-legg-xed-protocols-xx.txt, a work in progress, May 2004. [CXSD] Legg, S. and D. Prager, "Translation of ASN.1 Specifications into XML Schema", draft-legg-xed-xsd-xx.txt, a work in progress, to be published. Authors' Addresses Legg & Prager Expires 14 August 2005 [Page 59] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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 Dr. Daniel Prager EMail: dan@layabout.net Full Copyright Statement Copyright (C) The Internet Society (2005). 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 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 Legg & Prager Expires 14 August 2005 [Page 60] INTERNET-DRAFT XED: Matching Rules February 14, 2005 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. Legg & Prager Expires 14 August 2005 [Page 61]