Subject: RE: matching rules for directoryString [was: Re: CIM24 schema twe aks]

From: "Quevedo, Felix" <[email-masked]>
Date: Wed, 6 Dec 2000 23:32:04 -0000

Larry, Lee,

I like the proposal for caseIgnoreMatch. Per the DSP0100 the content of
orderedCimKeys looks a lot like a DN. The DN Match is not a trivial MR to
implement. I can see developers validating components of the attribute
following similar rules as the ones for a DN. This means that string
pre-validation may well be base on the MR of the components.

The next question, is the usage. How will we build search filters? Does a
DirectoryString meet our need? I bet somebody thought about this. For a
orderedCimKeys of:

	DLM_Rack.CreationClassName=DLM_Rack,Tag=AcmeRack4279B

A valid filter for a caseIgnoreMatch DirectoryString would be:

	OrderedCimKeys=*_Rack.creationClass*b

Is this valid? Would there be a search per orderedCimKeys? Will all the
components be known for an exact match? Would the expected usage is that we
will always know exactly how an orderedCimKeys look like?

Quite interesting.

Félix E Quevedo
:) Smile, everything is possible!
E-Mail: [email-masked]
Voice: 614 923 6242
Fax: 614 923 6299

 -----Original Message-----
From: 	Larry S. Bartz [mailto:[email-masked]] 
Sent:	Wednesday, December 06, 2000 14:02
To:	Lee Rafalow
Cc:	[email-masked]; [email-masked]
Subject:	Re: matching rules for directoryString [was: Re: CIM24
schema tweaks]

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.

Lee Rafalow wrote:
> 
> 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]
> 
> > 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]
> > > 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.
> > [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                 |                              |
> > #::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
> >

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

---

From: "Ayers, Mike" <[email-masked]>
Date: Fri, 8 Dec 2000 11:47:15 -0600

> of a non-ASCII character set.

	Not quite true.  Since, in UTF-8, all octets which comprise a
character higher than 0x7F have the MSB set, the case folding rules will
ignore everything except the ASCII range.  However, folding case in only
this range produces quirky results with European languages which use
characters outside the ASCII range (umlauted vowels, etc.), since the
algorithm will fold everything except a few characters.  See
http://www.unicode.org/unicode/reports/tr21/ for more.

	HTH,

/|/|ike