RE: CIM24 schema tweaks

["Steven Legg" <steven.legg@adacel.com.au>]

Ryan,

> -----Original Message-----
> From: owner-ietf-ldapbis@OpenLDAP.org
> [mailto:owner-ietf-ldapbis@OpenLDAP.org]On Behalf Of rmoats@coreon.net
> Sent: Saturday, 2 December 2000 12:13
> To: Larry S. Bartz
> Cc: Quevedo, Felix; IETF Policy WG LIST; ietf-ldapbis@OpenLDAP.org;
> ietf-ldapext@netscape.com
> Subject: Re: CIM24 schema tweaks

[snip]

> >I've spotted another potential difficulty with the schema of
> DSP0117.
> >
> >See this description:
> >
> >attributetype    ( 1.3.6.1.4.1.412.100.1.2.1
> >     NAME 'orderedCimKeys'
> >     SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE
> >     EQUALITY octetStringMatch
> >   )
> >
> >The matching rule syntax does not match the attribute's
> syntax. This
> >must be corrected.
>
> Well, as an editor, I get to play the "no complaints without
> making a suggestion" card.  What do you suggest as the
> equality match?  Based on my reading of the X.500-series and
> LDAP RFCs the only option for Directory Strings is
> caseIgnoreMatch, and I'm not at all comfortable with
> declaring that as the matching rule for a syntax that holds
> UTF-8 strings.
>
> Actually, the more I think about this, I think this is a
> bigger issue than just Policy, so I'm cross posting to
> ldapext and the newly minted ldapbis to see what those
> folks can add.

It was attributes like orderedCimKeys that motivated me to write the
component
matching rules draft (draft-legg-ldapext-component-matching-00.txt).
The content of the orderedCimKeys attribute is structured data with a well
defined format, rather than free text, so a specific new attribute
syntax is warranted. Stuffing highly structured data into attributes
with the Directory String syntax means that the directory can do nothing
more than treat values as opaque blobs of bytes. Almost inevitably the
question of a suitable equality matching rule is raised because the
existing string matching rules are not designed for matching structured
data.

The component matching rules are intended to provide convenient default
equality matching rules for structured data, as well as a generic capability
(that is more expressive than simple substring matching) to filter match
component parts of the structured attribute values. The key to all this
is a formal way to describe the structure of the data, which for the
component matching rules is ASN.1 type notation.

I note that the structure of an LDAP string encoded value of orderedCimKeys
is described by:

    <className>.<key>=<value>[,<key>=<value>]*

Without looking into the details, I'm guessing that something like the
following ASN.1 type would adequately describe the conceptual structure
of the syntax.

	OrderedCIMKeys ::= SEQUENCE {
		className	UTF8String,
		keys		SEQUENCE SIZE (1..MAX) OF {
			key			UTF8String,
			value		UTF8String } }

This is enough to completely define the behaviour of the
directoryComponentsMatch matching rule (a component by component equality
match) on a value of orderedCimKeys. If the default matching of
directoryComponentsMatch doesn't quite suit a particular application then
there is an easy way of extending it to define, for example, a
policyComponentsMatch matching rule that is more generally suitable for
policy attribute syntaxes.

The ASN.1 type definition for the syntax is also sufficient to completely
define the behaviour of the componentFilterMatch matching rule. This
matching
rule would provide the ability to search for orderCimKeys values with
particular class names, particular key types, or particular (key, value)
pairs, etc, in whatever filter combinations a user might want.

These matching capabilities are completely specified just by writing down an
ASN.1 definition of a syntax. Having that definition also opens up the
possibility of the directory doing other useful things with values.
For example, in the not too distant future directory servers may be
receiving and returning XML encoded versions of attribute values.
If the attribute syntax is a bland directory string then the XML
encoding of, say, a value of orderedCimKeys will look something like this:

	<orderedCIMKeys>
		whatever.abc=vvvv,def=wwww
	</orderedCIMKeys>

whereas a knowledge of the structure of the data will allow the directory
to produce XML encodings that are more meaningfully marked up (and more
verbose of course) as in the following:

	<orderedCIMKeys>
		<className>
			whatever
		</className>
		<keys>
			<instance>
				<key>abc</key>
				<value>vvvv</value>
			</instance>
			<instance>
				<key>def</key>
				<value>wwww</value>
			</instance>
		</keys>
	</orderedCIMKeys>

The component matching rules make it easy for applications to define
powerful
matching capabilities, but the directory servers have to implement those
capabilities, so there is an initial implementation barrier on the
directory server side. My hope is that directory server vendors will take
advantage of the fact that the component matching framework lends itself
to high levels of automation, whereby exotic new application syntaxes can
be easily and quickly accommodated (through run-time interpretation or
compiled plug-ins).

Regards,
Steven

>
> Ryan Moats
>