One document matched: draft-legg-xed-matching-01.txt
Differences from draft-legg-xed-matching-00.txt
INTERNET-DRAFT S. Legg
draft-legg-xed-matching-01.txt eB2Bcom
Intended Category: Standards Track D. Prager
Updates: RFC 3687 November 30, 2005
Obsoletes: RFC 3727
The XML Enabled Directory: Matching Rules
Copyright (C) The Internet Society (2005).
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.
By submitting this Internet-draft, I accept the provisions of
Section 3 of BCP 78.
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 <xeddev@eb2bcom.com>. Please send editorial
comments directly to the editor <steven.legg@eb2bcom.com>. Further
information is available on the XED website: www.xmled.info.
This Internet-Draft expires on 30 May 2006.
Abstract
The XML (Extensible Markup Language) Enabled Directory (XED) allows
Legg & Prager Expires 30 May 2006 [Page 1]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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
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 30 May 2006 [Page 2]
INTERNET-DRAFT XED: Matching Rules November 30, 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 . . . . . . . . . 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 . . . . . . . . . . . . 31
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 . . . . . . . . . . . 32
10.5.2. Examples for XML Schema Types. . . . . . . . . 50
11. Security Considerations. . . . . . . . . . . . . . . . . . . . 50
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 51
13. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 51
Appendix A. ASN.1 for Component Matching Rules . . . . . . . . . . 51
Appendix B. ASN.X for Component Matching Rules . . . . . . . . . . 53
Appendix C. XML Schema for Component Matching Rules. . . . . . . . 56
Normative References . . . . . . . . . . . . . . . . . . . . . . . 58
Informative References . . . . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 61
1. Introduction
Matching rules [MODELS] are used by Lightweight Directory Access
Protocol (LDAP) [LDAP] and X.500 [X.500] directory implementations to
Legg & Prager Expires 30 May 2006 [Page 3]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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
[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, 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
Legg & Prager Expires 30 May 2006 [Page 4]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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 [XMLNS10] "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
[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 30 May 2006 [Page 5]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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: 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 [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 30 May 2006 [Page 6]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
<* units="metres">19.5</*>
A content value containing attribute information items, element
information items and whitespace character information items:
<* units="metres">
<depth>4.56</depth>
</*>
There is a nested content value for the [normalized value] of the
units attribute:
<*>metres</*>
And a nested content value for the <depth> 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) 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 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 30 May 2006 [Page 7]
INTERNET-DRAFT XED: Matching Rules November 30, 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 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 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][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 30 May 2006 [Page 8]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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 30 May 2006 [Page 9]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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 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.
Legg & Prager Expires 30 May 2006 [Page 10]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
If an attribute with a particular [local name] and [namespace name]
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
Legg & Prager Expires 30 May 2006 [Page 11]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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 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:
Legg & Prager Expires 30 May 2006 [Page 12]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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 30 May 2006 [Page 13]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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 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:
Legg & Prager Expires 30 May 2006 [Page 14]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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
The directoryComponentsMatch matching rule [CMR] is derived from the
allComponentsMatch matching rule.
The matching semantics of directoryComponentsMatch are extended by
Legg & Prager Expires 30 May 2006 [Page 15]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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 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
Legg & Prager Expires 30 May 2006 [Page 16]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
{ -- 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 <component> child element is required
to be self-contained [RXER] since its type is (indirectly) AnyType.
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 an AnyType 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
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
Legg & Prager Expires 30 May 2006 [Page 17]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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
SimpleContentStep = fn-simpleContent sp "(" sp ")"
ItemStep = ItemValue [ sp PositionPredicate ]
ItemValue = fn-itemType sp "(" sp ")"
Legg & Prager Expires 30 May 2006 [Page 18]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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
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
Legg & Prager Expires 30 May 2006 [Page 19]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
; 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 <component> 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 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
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
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.
Legg & Prager Expires 30 May 2006 [Page 20]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
In ASN.1, an element definition corresponds to a NamedType that is
not subject to an RXER ATTRIBUTE, ATTRIBUTE-REF or GROUP encoding
instruction [RXEREI]. The set of child element definitions 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 definitions for the type of that NamedType. The
effective name of a NamedType [RXEREI] is used when attempting to
match the ElementName in a ChildAxisStep to a specific element
definition.
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,
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 (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]"
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.
Legg & Prager Expires 30 May 2006 [Page 21]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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 type of 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:
<xsd:complexType name="polygon">
<xsd:sequence>
<xsd:element name="filled" type="xsd:boolean"/>
<xsd:element name="colour" type="xsd:string"/>
<xsd:element name="vertex"
minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="x" type="xsd:decimal"/>
<xsd:attribute name="y" type="xsd:decimal"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<*>
<filled>true</filled>
<colour>red</colour>
<vertex x="1.0" y="1.0"/>
<vertex x="2.0" y="1.5"/>
<vertex x="1.7" y="1.7"/>
<vertex x="1.2" y="1.5"/>
</*>
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</*>.
Legg & Prager Expires 30 May 2006 [Page 22]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
The ChildAxisStep "vertex" applied to the polygon type selects the
anonymous complex type of the <vertex> 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).
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
defines attributes.
In ASN.1, an attribute definition corresponds to a NamedType that is
subject to an RXER ATTRIBUTE or ATTRIBUTE-REF encoding instruction
[RXEREI]. The set of attribute definitions 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 GROUP
encoding instruction, the attribute definitions for the type of that
NamedType. The effective name of a NamedType [RXEREI] is used when
attempting to match the AttributeName in an AttributeAxisStep to a
specific attribute definition.
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
Legg & Prager Expires 30 May 2006 [Page 23]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
corresponding attribute definition.
Example
Consider this type definition and content value:
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:decimal">
<xsd:attribute name="units" type="xsd:string"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<* 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:
<xsd:complexType>
<xsd:simpleContent>
<xsd:extension base="xsd:decimal">
<xsd:attribute name="units" type="xsd:string"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<* units="metres"> 0.788 </*>
Legg & Prager Expires 30 May 2006 [Page 24]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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:
<xsd:simpleType>
<xsd:list itemType="xsd:NCName"/>
</xsd:simpleType>
<*> 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
Legg & Prager Expires 30 May 2006 [Page 25]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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 <simpleType> 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
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
Legg & Prager Expires 30 May 2006 [Page 26]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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:
<xsd:simpleType>
<xsd:union memberTypes="xsd:positiveInteger">
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="zero"/>
<xsd:enumeration value="infinity"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:union>
</xsd:simpleType>
The MemberStep "member(1)" applied to this union type selects the
xsd:positiveInteger type. The MemberStep "member(2)" selects the
type defined by the <xsd:simpleType> child of the <xsd:union>
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 }
}
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.
Legg & Prager Expires 30 May 2006 [Page 27]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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 <simpleType> 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.
Examples
Consider this type definition:
<xsd:simpleType>
<xsd:union memberTypes="xsd:positiveInteger">
Legg & Prager Expires 30 May 2006 [Page 28]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
<xsd:simpleType>
<xsd:restriction base="xsd:string">
<xsd:enumeration value="zero"/>
<xsd:enumeration value="infinity"/>
</xsd:restriction>
</xsd:simpleType>
<xsd:union>
</xsd:simpleType>
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 <xsd:simpleType> child of the
<xsd:union> 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
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
Legg & Prager Expires 30 May 2006 [Page 29]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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:
<xsd:complexType name="polygon">
<xsd:sequence>
<xsd:element name="filled" type="xsd:boolean"/>
<xsd:element name="colour" type="xsd:string"/>
<xsd:element name="vertex"
minOccurs="0" maxOccurs="unbounded">
<xsd:complexType>
<xsd:attribute name="x" type="xsd:decimal"/>
<xsd:attribute name="y" type="xsd:decimal"/>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
</xsd:complexType>
<*>
<filled>true</filled>
<colour>red</colour>
<vertex x="1.0" y="1.0"/>
<vertex x="2.0" y="1.5"/>
<vertex x="1.7" y="1.7"/>
<vertex x="1.2" y="1.5"/>
</*>
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.
Legg & Prager Expires 30 May 2006 [Page 30]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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:
<xsd:simpleType>
<xsd:list itemType="xsd:string"/>
</xsd:simpleType>
<*> 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
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
Legg & Prager Expires 30 May 2006 [Page 31]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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 <matchValue> elements
after being extracted and renamed to <value>.
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 <matchValue> and <value>
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
Legg & Prager Expires 30 May 2006 [Page 32]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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",
rule objectIdentifierMatch, value 2.5.6.18 })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.21.6 <!--objectClasses--> </type></type>
<matchValue>
<term>
<component> identifier </component>
<rule> 2.5.13.0 <!--objectIdentifierMatch--> </rule>
<value> 2.5.6.18 </value>
</term>
</matchValue>
</extensibleMatch>
</filter>
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:
Legg & Prager Expires 30 May 2006 [Page 33]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
(objectClasses:componentFilterMatch:=
item:{ component "name.*",
rule caseIgnoreMatch, value "foobar" })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.21.6 <!--objectClasses--> </type></type>
<matchValue>
<term>
<component> name/item </component>
<rule> 2.5.13.2 <!--caseIgnoreMatch--> </rule>
<value>
foobar
<!-- Whitespace in this string value is significant from the
perspective of the RXER encoding (this comment is not),
however the caseIgnoreMatch matching rule treats the
leading and trailing whitespace as insignificant. -->
</value>
</term>
</matchValue>
</extensibleMatch>
</filter>
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 })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.21.6 <!--objectClasses--> </type></type>
<matchValue>
<term>
<component> name/count(item) </component>
<rule> 2.5.13.14 <!--integerMatch--> </rule>
<value> 1 </value>
Legg & Prager Expires 30 May 2006 [Page 34]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
</term>
</matchValue>
</extensibleMatch>
</filter>
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 })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.21.6 <!--objectClasses--> </type></type>
<matchValue>
<term>
<component> description </component>
<rule> 1.2.36.79672281.1.13.5 <!--presentMatch--> </rule>
<value/>
</term>
</matchValue>
</extensibleMatch>
</filter>
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 })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.21.6 <!--objectClasses--> </type></type>
<matchValue>
<not>
Legg & Prager Expires 30 May 2006 [Page 35]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
<term>
<component> description </component>
<rule> 1.2.36.79672281.1.13.5 <!--presentMatch--> </rule>
<value/>
</term>
</not>
</matchValue>
</extensibleMatch>
</filter>
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" } })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.21.6 <!--objectClasses--> </type></type>
<matchValue>
<term>
<component> description </component>
<rule> 2.5.13.4 <!--caseIgnoreSubstringsMatch--> </rule>
<value>
<item>
<any>bogus</any>
</item>
</value>
</term>
</matchValue>
</extensibleMatch>
</filter>
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
Legg & Prager Expires 30 May 2006 [Page 36]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
finds all obsolete object classes:
(objectClasses:componentFilterMatch:=
item:{ component "obsolete", rule booleanMatch, value TRUE })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.21.6 <!--objectClasses--> </type></type>
<matchValue>
<term>
<component> obsolete </component>
<rule> 2.5.13.13 <!--booleanMatch--> </rule>
<value> true </value>
</term>
</matchValue>
</extensibleMatch>
</filter>
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 })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.21.6 <!--objectClasses--> </type></type>
<matchValue>
<term>
<component> obsolete </component>
<rule> 2.5.13.13 <!--booleanMatch--> </rule>
<value> false </value>
</term>
</matchValue>
</extensibleMatch>
</filter>
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
Legg & Prager Expires 30 May 2006 [Page 37]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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 })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.21.6 <!--objectClasses--> </type></type>
<matchValue>
<term>
<component> obsolete </component>
<useDefaultValues> false </useDefaultValues>
<rule> 2.5.13.13 <!--booleanMatch--> </rule>
<value> false </value>
</term>
</matchValue>
</extensibleMatch>
</filter>
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 })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.21.6 <!--objectClasses--> </type></type>
<matchValue>
<term>
<component> information/kind </component>
Legg & Prager Expires 30 May 2006 [Page 38]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
<rule> 1.2.36.79672281.1.13.6 <!--allComponentsMatch--> </rule>
<value> auxiliary </value>
</term>
</matchValue>
</extensibleMatch>
</filter>
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 } })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.21.6 <!--objectClasses--> </type></type>
<matchValue>
<and>
<filter>
<term>
<component> information/kind </component>
<rule>
1.2.36.79672281.1.13.6 <!--allComponentsMatch--> </rule>
<value> auxiliary </value>
</term>
</filter>
<filter>
<term>
<component> information/mandatories/item </component>
<rule> 2.5.13.0 <!--objectIdentifierMatch--> </rule>
<value> 2.5.4.3 <!--commonName--> </value>
</term>
</filter>
</and>
</matchValue>
</extensibleMatch>
</filter>
The following search filter finds auxiliary object classes with
commonName as a mandatory or optional attribute:
(objectClasses:componentFilterMatch:=and:{
Legg & Prager Expires 30 May 2006 [Page 39]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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 } } })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.21.6 <!--objectClasses--> </type></type>
<matchValue>
<and>
<filter>
<term>
<component> information/kind </component>
<rule>
1.2.36.79672281.1.13.6 <!--allComponentsMatch-->
</rule>
<value> auxiliary </value>
</term>
</filter>
<filter>
<or>
<filter>
<term>
<component> information/mandatories/item </component>
<rule> 2.5.13.0 <!--objectIdentifierMatch--> </rule>
<value> 2.5.4.3 <!--commonName--> </value>
</term>
</filter>
<filter>
<term>
<component> information/optionals/item </component>
<rule> 2.5.13.0 <!--objectIdentifierMatch--> </rule>
<value> 2.5.4.3 <!--commonName--> </value>
</term>
</filter>
</or>
</filter>
</and>
</matchValue>
</extensibleMatch>
</filter>
Legg & Prager Expires 30 May 2006 [Page 40]
INTERNET-DRAFT XED: Matching Rules November 30, 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 })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.21.6 <!--objectClasses--> </type></type>
<matchValue>
<term>
<component> name/count(item) </component>
<rule> 2.5.13.15 <!--integerOrderingMatch--> </rule>
<value> 3 </value>
</term>
</matchValue>
</extensibleMatch>
</filter>
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 } })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.21.6 <!--objectClasses--> </type></type>
<matchValue>
Legg & Prager Expires 30 May 2006 [Page 41]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
<or>
<filter>
<not>
<term>
<component> name </component>
<rule> 1.2.36.79672281.1.13.5 <!--presentMatch--> </rule>
<value/>
</term>
</not>
</filter>
<filter>
<term>
<component> name/count(item) </component>
<rule> 2.5.13.15 <!--integerOrderingMatch--> </rule>
<value> 3 </value>
</term>
</filter>
</or>
</matchValue>
</extensibleMatch>
</filter>
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" })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.4.50 <!--uniqueMember--> </type></type>
<matchValue>
<term>
<component> dn </component>
<rule> 2.5.13.1 <!--distinguishedNameMatch--> </rule>
Legg & Prager Expires 30 May 2006 [Page 42]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
<value>
<item>
<item>
<type> 2.5.4.6 <!--countryName--> <type>
<value>AU</value>
</item>
</item>
<item>
<item>
<type> 2.5.4.10 <!--organizationName--> <type>
<value>eB2Bcom</value>
</item>
</item>
<item>
<item>
<type> 2.5.4.3 <!--commonName--> <type>
<value>Steven Legg</value>
</item>
</item>
</value>
</term>
</matchValue>
</extensibleMatch>
</filter>
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
Legg & Prager Expires 30 May 2006 [Page 43]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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" })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.4.34 <!--seeAlso--> </type></type>
<matchValue>
<term>
<component> item </component>
<rule> 1.2.36.79672281.1.13 <!--rdnMatch--> </rule>
<value>
<item>
<type> 2.5.4.10 <!--organizationName--> <type>
<value>eB2Bcom</value>
</item>
</value>
</term>
</matchValue>
</extensibleMatch>
</filter>
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" })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.4.34 <!--seeAlso--> </type></type>
<matchValue>
<term>
<component> item[last()] </component>
<rule> 1.2.36.79672281.1.13 <!--rdnMatch--> </rule>
Legg & Prager Expires 30 May 2006 [Page 44]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
<value>
<item>
<type> 2.5.4.3 <!--commonName--> <type>
<value>Steven Legg</value>
</item>
</value>
</term>
</matchValue>
</extensibleMatch>
</filter>
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" } })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.4.34 <!--seeAlso--> </type></type>
<matchValue>
<and>
<filter>
<term>
<component> item[1] </component>
<rule> 1.2.36.79672281.1.13 <!--rdnMatch--> </rule>
<value>
<item>
<type> 2.5.4.6 <!--countryName--> <type>
<value>AU</value>
</item>
</value>
</term>
</filter>
<filter>
<term>
<component> item[2] </component>
<rule> 1.2.36.79672281.1.13 <!--rdnMatch--> </rule>
<value>
<item>
<type> 2.5.4.10 <!--organizationName--> <type>
<value>eB2Bcom</value>
</item>
</value>
Legg & Prager Expires 30 May 2006 [Page 45]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
</term>
</filter>
</and>
</matchValue>
</extensibleMatch>
</filter>
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 } } })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.4.34 <!--seeAlso--> </type></type>
<matchValue>
<term>
<component> item </component>
<rule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</rule>
<value>
<and>
<filter>
<term>
<component> item/type </component>
<rule> 2.5.13.0 <!--objectIdentifierMatch--> </rule>
<value> 2.5.4.3 <!--commonName--> </value>
</term>
</filter>
<filter>
<term>
<component> item/type </component>
<rule> 2.5.13.0 <!--objectIdentifierMatch--> </rule>
<value> 2.5.4.20 <!--telephoneNumber--> </value>
</term>
</filter>
Legg & Prager Expires 30 May 2006 [Page 46]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
</and>
</value>
</term>
</matchValue>
</extensibleMatch>
</filter>
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 } })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.4.34 <!--seeAlso--> </type></type>
<matchValue>
<and>
<filter>
<term>
<component> item/item/type </component>
<rule> 2.5.13.0 <!--objectIdentifierMatch--> </rule>
<value> 2.5.4.3 <!--commonName--> </value>
</term>
</filter>
<filter>
<term>
<component> item/item/type </component>
<rule> 2.5.13.0 <!--objectIdentifierMatch--> </rule>
<value> 2.5.4.20 <!--telephoneNumber--> </value>
</term>
</filter>
</and>
</matchValue>
</extensibleMatch>
</filter>
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:
Legg & Prager Expires 30 May 2006 [Page 47]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
(seeAlso:componentFilterMatch:=
item:{ component "*.*.value.(2.5.4.11)",
rule caseIgnoreSubstringsMatch,
value { any:"eB2Bcom" } })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type><type> 2.5.4.34 <!--seeAlso--> </type></type>
<matchValue>
<term>
<component>
item/item/value/restrictBy(<value>2.5.4.11</value>)
</component>
<rule> 2.5.13.4 <!--caseIgnoreSubstringsMatch--> </rule>
<value>
<item>
<any>eB2Bcom</any>
</item>
</value>
</term>
</matchValue>
</extensibleMatch>
</filter>
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))
<filter>
<and>
<filter>
<not>
Legg & Prager Expires 30 May 2006 [Page 48]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
<extensibleMatch>
<matchingRule>
2.5.13.15 <!--integerOrderingMatch-->
</matchingRule>
<type>
<type> 1.3.6.1.4.1.21472.5.4.0.2 <!--productCodes--> </type>
</type>
<matchValue> 3 </matchValue>
</extensibleMatch>
</not>
</filter>
<filter>
<extensibleMatch>
<matchingRule>
2.5.13.15 <!--integerOrderingMatch-->
</matchingRule>
<type>
<type> 1.3.6.1.4.1.21472.5.4.0.2 <!--productCodes--> </type>
</type>
<matchValue> 8 </matchValue>
</extensibleMatch>
</filter>
</and>
</filter>
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 } })
<filter>
<extensibleMatch>
<matchingRule>
1.2.36.79672281.1.13.2 <!--componentFilterMatch-->
</matchingRule>
<type>
<type> 1.3.6.1.4.1.21472.5.4.0.2 <!--productCodes--> </type>
</type>
<matchValue>
<and>
<filter>
Legg & Prager Expires 30 May 2006 [Page 49]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
<not>
<term>
<rule> 2.5.13.15 <!--integerOrderingMatch--> </rule>
<value> 3 </value>
</term>
</not>
</filter>
<filter>
<term>
<rule> 2.5.13.15 <!--integerOrderingMatch--> </rule>
<value> 8 </value>
</term>
</filter>
</and>
</matchValue>
</extensibleMatch>
</filter>
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 <matchValue> and <value>
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
Legg & Prager Expires 30 May 2006 [Page 50]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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,
rule MATCHING-RULE.&id,
value MATCHING-RULE.&AssertionType }
Legg & Prager Expires 30 May 2006 [Page 51]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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"
END
Legg & Prager Expires 30 May 2006 [Page 52]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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 is non-normative.
<?xml version="1.0"?>
<asn1:module
xmlns:asn1="http://xmled.info/ns/ASN.1"
xmlns:if="http://xmled.info/ns/X.500/4/InformationFramework"
name="ComponentMatching"
identifier="1.3.6.1.4.1.21472.5.1.1"
schemaIdentity="http://xmled.info/id/XED/1/ComponentMatching"
xmlns:cmr="http://xmled.info/ns/XED/1/ComponentMatching"
targetNamespace="http://xmled.info/ns/XED/1/ComponentMatching"
tagDefault="explicit"
extensibilityImplied="true">
<annotation>
Copyright (C) The Internet Society 2005. This version of
this ASN.X module is part of RFC XXXX; see the RFC itself
for full legal notices.
</annotation>
<import
name="InformationFramework"
identifier="2.5.1.1.4"
schemaIdentity=
"http://xmled.info/id/X.500/4/InformationFramework"
namespace="http://xmled.info/ns/X.500/4/InformationFramework"/>
<namedType name="ComponentAssertion">
<type>
<sequence>
<optional>
<element name="component">
<type>
<constrained type="cmr:ComponentReference">
<size>
<range>
<minInclusive literalValue="1"/>
Legg & Prager Expires 30 May 2006 [Page 53]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
</range>
</size>
</constrained>
</type>
</element>
</optional>
<optional>
<element name="useDefaultValues" type="asn1:BOOLEAN"/>
<default literalValue="true"/>
</optional>
<element name="rule">
<type>
<fromClass class="if:MATCHING-RULE" fieldName="id"/>
</type>
</element>
<element name="value">
<type>
<fromClass class="if:MATCHING-RULE" fieldName="AssertionType"/>
</type>
</element>
</sequence>
</type>
</namedType>
<namedType name="ComponentReference" type="asn1:UTF8String"/>
<namedType name="PathAssertion">
<type>
<sequence>
<optional>
<element name="component" type="cmr:ComponentPath"/>
</optional>
<optional>
<element name="useDefaultValues" type="asn1:BOOLEAN"/>
<default literalValue="true"/>
</optional>
<element name="rule">
<type>
<fromClass class="if:MATCHING-RULE" fieldName="id"/>
</type>
</element>
<element name="value">
<type>
<fromClass class="if:MATCHING-RULE" fieldName="AssertionType"/>
</type>
</element>
</sequence>
</type>
Legg & Prager Expires 30 May 2006 [Page 54]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
</namedType>
<namedType name="ComponentPath">
<type>
<constrained type="asn1:AnyType">
<constrainedBy>
<annotation> contains a component path expression </annotation>
</constrainedBy>
</constrained>
</type>
</namedType>
<namedType name="ComponentFilter">
<type>
<choice>
<element name="item">
<type>
<tagged number="0" type="cmr:ComponentAssertion"/>
</type>
</element>
<element name="and">
<type>
<tagged number="1">
<type>
<sequenceOf>
<element name="filter" type="cmr:ComponentFilter"/>
</sequenceOf>
</type>
</tagged>
</type>
</element>
<element name="or">
<type>
<tagged number="2">
<type>
<sequenceOf>
<element name="filter" type="cmr:ComponentFilter"/>
</sequenceOf>
</type>
</tagged>
</type>
</element>
<element name="not">
<type>
<tagged number="3" type="cmr:ComponentFilter"/>
</type>
</element>
<extension>
Legg & Prager Expires 30 May 2006 [Page 55]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
<element name="term">
<type>
<tagged number="4" type="cmr:PathAssertion"/>
</type>
</element>
</extension>
</choice>
</type>
</namedType>
<namedObject name="componentFilterMatch" class="if:MATCHING-RULE">
<object>
<field name="AssertionType" type="cmr:ComponentFilter"/>
<field name="id" literalValue="1.2.36.79672281.1.13.2"/>
</object>
</namedObject>
<namedObject name="allComponentsMatch" class="if:MATCHING-RULE">
<object>
<field name="id" literalValue="1.2.36.79672281.1.13.6"/>
</object>
</namedObject>
<namedObject name="directoryComponentsMatch"
class="if:MATCHING-RULE">
<object>
<field name="id" literalValue="1.2.36.79672281.1.13.7"/>
</object>
</namedObject>
<namedObject name="rdnMatch" class="if:MATCHING-RULE">
<object>
<field name="AssertionType" type="if:RelativeDistinguishedName"/>
<field name="id" literalValue="1.2.36.79672281.1.13.3"/>
</object>
</namedObject>
<namedObject name="presentMatch" class="if:MATCHING-RULE">
<object>
<field name="AssertionType" type="asn1:NULL"/>
<field name="id" literalValue="1.2.36.79672281.1.13.5"/>
</object>
</namedObject>
</asn1:module>
Appendix C. XML Schema for Component Matching Rules
Legg & Prager Expires 30 May 2006 [Page 56]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
This appendix contains a compatible XML Schema [CXSD] translation of
the ComponentMatching module.
This appendix is non-normative.
<?xml version="1.0"?>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:asn1="http://xmled.info/ns/ASN.1"
xmlns:cmr="http://xmled.info/ns/XED/1/ComponentMatching"
targetNamespace="http://xmled.info/ns/XED/1/ComponentMatching"
blockDefault="#all">
<xsd:annotation>
<xsd:documentation>
Copyright (C) The Internet Society (2005). This version of
this XML Schema is part of RFC XXXX; see the RFC itself
for full legal notices.
</xsd:documentation>
</xsd:annotation>
<xsd:import namespace="http://xmled.info/ns/ASN.1"/>
<xsd:complexType name="ComponentAssertion">
<xsd:sequence>
<xsd:element name="component" minOccurs="0"
type="cmr:ComponentReference"/>
<xsd:element name="useDefaultValues" minOccurs="0"
type="asn1:BOOLEAN"/>
<xsd:element name="rule" type="asn1:OBJECT-IDENTIFIER"/>
<xsd:element name="value" type="xsd:anyType"/>
</xsd:sequence>
</xsd:complexType>
<xsd:simpleType name="ComponentReference">
<xsd:restriction base="asn1:UTF8String"/>
</xsd:simpleType>
<xsd:complexType name="PathAssertion">
<xsd:sequence>
<xsd:element name="component" minOccurs="0" type="xsd:anyType"/>
<xsd:element name="useDefaultValues" minOccurs="0"
type="asn1:BOOLEAN"/>
<xsd:element name="rule" type="asn1:OBJECT-IDENTIFIER"/>
<xsd:element name="value" type="xsd:anyType"/>
</xsd:sequence>
</xsd:complexType>
Legg & Prager Expires 30 May 2006 [Page 57]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
<xsd:complexType name="ComponentFilter">
<xsd:choice>
<xsd:element name="item" type="cmr:ComponentAssertion"/>
<xsd:element name="and">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="filter" minOccurs="0"
maxOccurs="unbounded" type="cmr:ComponentFilter"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="or">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="filter" minOccurs="0"
maxOccurs="unbounded" type="cmr:ComponentFilter"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="not" type="cmr:ComponentFilter"/>
<xsd:element name="term" type="cmr:PathAssertion"/>
</xsd:choice>
</xsd:complexType>
</xsd:schema>
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.
[ABNF] Crocker, D., and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[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 30 May 2006 [Page 58]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
September 2005.
[MODELS] Zeilenga, K., "LDAP: Directory Information Models",
draft-ietf-ldapbis-models-xx.txt, a work in progress,
February 2005.
[PROT] Sermersheim, J., "LDAP: The Protocol",
draft-ietf-ldapbis-protocol-xx.txt, a work in progress,
October 2005.
[SYNTAX] Legg, S., "Lightweight Directory Access Protocol (LDAP):
Syntaxes and Matching Rules",
draft-ietf-ldapbis-syntaxes-xx.txt, a work in progress,
June 2005.
[PREP] Zeilenga, K., "LDAP: Internationalized String
Preparation", draft-ietf-ldapbis-strprep-xx.txt, a work in
progress, September 2005.
[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)",
draft-legg-xed-rxer-xx.txt, a work in progress, October
2005.
[RXEREI] Legg, S., "Encoding Instructions for the Robust XML
Encoding Rules (RXER)", draft-legg-xed-rxer-ei-xx.txt, a
work in progress, October 2005.
[XED] Legg, S. and D. Prager, "The XML Enabled Directory",
draft-legg-xed-roadmap-xx.txt, a work in progress,
February 2005.
[SCHEMA] Legg, S. and D. Prager, "The XML Enabled Directory: Schema
Operational Attributes", draft-legg-xed-schema-xx.txt, a
work in progress, November 2005.
[X.500] 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
[X.501] ITU-T Recommendation X.501 (02/01) | ISO/IEC 9594-2:2001,
Information technology - Open Systems Interconnection -
The Directory: Models
Legg & Prager Expires 30 May 2006 [Page 59]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
[X.520] ITU-T Recommendation X.520 (02/01) | ISO/IEC 9594-6:2001,
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 (Third
Edition)", W3C Recommendation,
http://www.w3.org/TR/2004/REC-xml-20040204, February 2004.
[XML11] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E.,
Yergeau, F., and J. Cowan, "Extensible Markup Language
(XML) 1.1", W3C Recommendation,
http://www.w3.org/TR/2004/REC-xml11-20040204, February
2004.
[XMLNS10] 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 (Second
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.
Informative References
[GSER] Legg, S., "Generic String Encoding Rules (GSER) for ASN.1
Types", RFC 3641, October 2003.
Legg & Prager Expires 30 May 2006 [Page 60]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
[TRANSFER] Legg, S., "Lightweight Directory Access Protocol (LDAP):
Transfer Encoding Options",
draft-legg-ldap-transfer-xx.txt, a work in progress,
November 2005.
[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, November 2005.
[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
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
Legg & Prager Expires 30 May 2006 [Page 61]
INTERNET-DRAFT XED: Matching Rules November 30, 2005
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.
Changes in Draft 01
ASN.1 Schema has been renamed to Abstract Syntax Notation X (ASN.X)
and the <asn1:schema> element has been renamed to <asn1:module>.
Legg & Prager Expires 30 May 2006 [Page 62]
| PAFTECH AB 2003-2026 | 2026-04-24 05:48:55 |