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