Subject: Re: CIM24 schema tweaks

From: <[email-masked]>
Date: Fri, 1 Dec 2000 20:13:19 -0500

>> It looks like the dlmHelperRefTo... should actually be: 
dlm...HelperRef.
>> This must have happen when applying a "new" naming 
convention to the
>> attributes type descriptions, but did not to modify their 
references in the
>> object class descriptions.
>> 
>> Can the DMTF team confirm this?

I can confirm that... they should be ..HelperRef,
but in editing the document we got them out of sync.

>I guessed the same. I substituted the dlm...HelperRef attrs 
in the 
>attachment to my initial message.
>
>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.

Ryan Moats

---

From: Mark Wahl <[email-masked]>
Date: Fri, 01 Dec 2000 18:21:05 -0800

[email-masked] wrote:

> declaring that as the matching rule for a syntax that holds

There can be other matching rules for Directory String syntax 
attributes besides case ignore.  Case ignore is just the most 
common.  You can have a Case Sensitive, or other more complex
ones if you define them.

Mark Wahl
Sun Microsystems Inc.

---

From: "Larry S. Bartz" <[email-masked]>
Date: Tue, 05 Dec 2000 08:04:11 -0500

[email-masked] wrote:
.[snip]
> What do you suggest as the
[snip]

I'm reading X.501 and X.520 from 
ftp://ftp.bull.com/pub/OSIdirectory/4thEditionTexts/ (hurry for your
copy). Although these are drafts from the 4th edition of the X.500
series, it does not appear that the sections which apply to this 
immediate issue are new or different from current/previous documents.  

X.501 requires that the assertion syntax of the matching rule and
the syntax of attributes to which the matching rule is applied
must be equivalent. See section 13.5.

X.520 defines a caseExactMatch rule which applies to directoryString
attributes. See section 6.1.4. 

Section 8 of RFC2252 does not mention a caseExactMatch rule which 
applies to directoryString attributes. But neither does it appear that
section 8 was intended to describe the entire universe of allowable
or appropriate matching rules. Nothing in RFC2252's section 8 precludes
a Directory implementation from supporting matching rules beyond those
which are enumerated.

Section 3.3 of RFC2251 asserts LDAP's relationship to X.500 and the
requirement for LDAP servers to support the X.500 data and service
models.

Based on these facts, think it is reasonable to specify caseExactMatch
for directoryString attributes. Further, I think it is reasonable to
expect that Directory implementations will support it. 

Also see http://www.alvestrand.no/objectid/2.5.13.5.html

Note that the specification of caseExactMatch for directoryString 
attributes did not prevent RFCs 2713 and 2714 from obtaining.

--
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz                           |                              |
#  [email-masked]      | Ooo, ooo,                    |
#                                       | Ooo, ooo, oooooo!            |
#                                       | I've got a gnu attitude!     |
#  voice (317) 226-7060                 |                              |
#  FAX   (317) 226-6378                 |                              |
#::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|

---

From: "Ryan Moats" <[email-masked]>
Date: Tue, 5 Dec 2000 09:21:36 -0600

Thank you, Thank you, Thank you!

Having looked at the relevant section, I am MUCH more comfortable
with this than with caseIgnoreMatch.

I think caseExactMatch should be used for

- orderedCimKeys in the 2.4 Mapping
- policyKeywords, policyGroupName, policyRuleName, policyConditionName,
policyActionName, policyInstanceName, policyRepositoryName in the PCLS
(Hey Bob, there's going to be a -09 isn't there ;-)

Ryan

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Larry S. Bartz
Sent: Tuesday, December 05, 2000 7:04 AM
To: [email-masked]
Cc: Quevedo, Felix; IETF Policy WG LIST; [email-masked];
[email-masked]
Subject: matching rules for directoryString [was: Re: CIM24 schema
tweaks]

[email-masked] wrote:
.[snip]
[snip]

---

From: "Lee Rafalow" <[email-masked]>
Date: Wed, 6 Dec 2000 10:29:05 -0500

So, now that we've resolved the question of what matching rules are
possible, let's address what matching rules we want to use.

Although the attributes listed below have been thought of as case exact in
the past (e.g., earlier drafts of PCLS when they were IA5string syntax), I'm
not sure we should stay with that interpretation.  The attributes listed
below are intended for search and/or rdn usage and requiring case exact
seems restrictive to me.  In most uses there's nothing about
policyGroupName=Atlanta Routers that's different from
policyGroupName=atlanta routers or policyRepositoryName=Southeast and
policyRepositoryName=southeast.   Further, if you look at other typically
used search and/or rdn attributes (e.g., cn, ou, o, l, etc.) they're cis.

Cheers, Lee

----- Original Message -----
From: "Ryan Moats" <[email-masked]>
To: "Larry S. Bartz" <[email-masked]>
Cc: "Quevedo, Felix" <[email-masked]>; "IETF Policy WG LIST"
<[email-masked]>
Sent: Tuesday, December 05, 2000 10:21 AM
Subject: RE: matching rules for directoryString [was: Re: CIM24 schema
tweaks]

---

From: "Larry S. Bartz" <[email-masked]>
Date: Wed, 06 Dec 2000 14:01:59 -0500

Lee,

I think the answer depends in part on how much we care about supporting
internationalization, and for which attributes. "Ignore case" is 
meaningless (maybe dangerous) if the string is a UTF-8 representation 
of a non-ASCII character set.

I inferred from the draft's initial assignment of octetStringMatch to 
the orderedCimKeys attribute that there was a significant potential for
non-ASCII characters in the value. Did I infer correctly?

Is internationalization an issue for orderedCimKeys or any other 
directoryString attribute? 

If not, then I agree with you, Lee. caseIgnoreMatch makes the data
easier to use.

How about substring matching rules?

Several attributes will possess meaningful substrings in their values.
The schema should facilitate discovering those substrings. The
following attribute descriptions should designate
caseIgnoreSubstringsMatch
in addition to the existing caseIgnoreMatch designation:

- policyRoles
- ptpConditionTime
- ptpConditionTimeOfDayMask

Depending upon whether "exact" or "ignore" is applied to orderedCimKeys,
it should also be assigned the corresponding substring matching rule.

---

From: "Steven Legg" <[email-masked]>
Date: Thu, 7 Dec 2000 15:53:41 +1100

Ryan,

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of [email-masked]
> Sent: Saturday, 2 December 2000 12:13
> To: Larry S. Bartz
> Cc: Quevedo, Felix; IETF Policy WG LIST; [email-masked];
> Subject: Re: CIM24 schema tweaks

[snip]

> ldapext and the newly minted ldapbis to see what those

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

---

From: "Ryan Moats" <[email-masked]>
Date: Thu, 7 Dec 2000 10:54:04 -0600

Since this is a standards track document, I do not
want to use something that creates a dependency and
will hold up the document.

Ryan

-----Original Message-----

Ryan,

[snip]

	<orderedCIMKeys>

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

Regards,
Steven