Subject: Re: Models: Matching Rule Uses

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 10 Feb 2003 13:48:59 -0800

At 02:34 PM 1/30/2003, Hallvard B Furuseth wrote:
>[Models] says:
>
>> 4.1.4. Matching Rule Uses
>>
>>  A matching rule use lists the attributes which are suitable for use
>>  with an extensible matching rule
>
>Please add something like "(in addition to those uses expressed in
>AttributeType descriptions)".

Such an addition could be viewed as calling for the
publication of non-extensible matching rules in matching rule use
attribute.  The matching rule use attribute publishes those
type/rules combinations which can used in assertions of the
form (type:rule:=value).  Whether the rule can be used in
other contexts (such as an equality rule for a type) is
not relevant here.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Wed, 12 Feb 2003 22:58:44 +0100

>>>  with an extensible matching rule
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^
I just noticed: I think that should be "an extensibleMatch filter".
I can't find a definition of what extensible matching rules are.
Should have noticed that after Ron Ramsay's response.

> attribute.

OK, how about:

  "extensibleMatch filters can also use matching rules from an
  attribute type's AttributeType description."

At least that's what you said in a private mail earlier.  Or if
I misundersood, add an explicit note about the opposite instead.

> Whether the rule can be used in other contexts (such
> as an equality rule for a type) is not relevant here.

True, but that's not what I'm talking about.

Also, am I right in assuming that a matching rule use may only
list attributes with a syntax which satisfies the restrictions
specified in the matching rule defintion in [Syntaxes] 5.2.*?
If not, something needs to be said about what these restrictions
mean.

Finally, it must be specified which attributes a Matching Rule
may be used with if it has no corresponding Matching Rule Use.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Wed, 12 Feb 2003 15:37:37 -0800

>>>>  with an extensible matching rule

I concur.

>  attribute type's AttributeType description."

I don't think that's correct.  Listing a rule in
an attribute type description doesn't imply that
rule can be used in an extensibleMatch filter.

>I misundersood, add an explicit note about the opposite instead.

I could have been confused...

I can think of a number of possible opposites, but none
make sense to me.  Please clarify.

>If not, something needs to be said about what these restrictions

I'm not sure which restrictions you refer to here.  Can you
be more specific?

>may be used with if it has no corresponding Matching Rule Use.

Not publishing a rule use (or any schema element)
only means the server doesn't know that use (or isn't willing
to let you know it knows that use).

Maybe 4.4 addition we previously discussed should say:
  Clients SHOULD NOT assume a published subschema is complete nor
  assume the server supports all of the schema elements it publishes 
  nor assume the server does not support any elements it did not publish.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 13 Feb 2003 08:42:16 +0100

> make sense to me.  Please clarify.

Never mind for now.  I think the discussion below will cover it.

> I'm not sure which restrictions you refer to here.  Can you

Example: [Syntaxes] 5.2.3 caseIgnoreIA5Match says:

   The caseIgnoreIA5Match rule compares an assertion value of the IA5
   String syntax to an attribute value of a syntax (e.g the IA5 String
   syntax) whose corresponding ASN.1 type is IA5String.

So caseIgnoreIA5Match can be used with attributes whose corresponding
ASN.1 type is IA5String, but not e.g. bit string syntax.  I'm hoping
that this also means that a caseIgnoreIA5Match matching rule use can
only list attributes whose corresponding ASN.1 type is IA5String.

>   nor assume the server does not support any elements it did not publish.

Heh.  It gets complicated, but I guess that's the right text.

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 13 Feb 2003 00:54:14 -0800

>   syntax) whose corresponding ASN.1 type is IA5String.

This wording, I think, is overly restrictive.  It's not necessary
for the assertion value here to be an IA5String or even contain an
IA5String.  What is necessary is a well-defined algorithm for
performing the assertion against a value of the attribute type's
syntax.

>only list attributes whose corresponding ASN.1 type is IA5String.

No, the assertion syntax and attribute value syntax can be quite
different.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 13 Feb 2003 10:17:37 +0100

> No, the assertion syntax and attribute value syntax can be quite

Well, the point is that if it may be a syntax which is not permitted by
the restrictions I quoted from [Syntaxes], or whatever they are modified
to say, that must be mentioned in [Models].

-- 
Hallvard

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 13 Feb 2003 07:54:39 -0800

>to say, that must be mentioned in [Models].

The data model places no restrictions on the specification
of matching rules in this area.

Can you offer a specific change to [Models] which attempts
to address your concern?

Thanks, Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 13 Feb 2003 11:05:25 -0800

At 10:08 AM 2/13/2003, Hallvard B Furuseth wrote:
>If there are no restrictions,

The directory models place no restrictions on what kinds of
matching rules can be defined, but a matching rule certainly
is only (well-)defined for use with specific attribute value
syntaxes.  A server may publish any matching rule use it
knows as being defined.

>that would be:
>
>4.1.4:
>  "An attribute type can appear in a matching rule use even
>  if the corresponding matching rule definition in [Syntaxes]
>  does not allow the attribute type's syntax."

Just like rules listed in the attribute type description,
rules listed in matching rule use are listed when appropriate
per the technical specification of the attribute type, its
syntax, and the matching rule.

>I might note that this is _not_ how OpenLDAP works now.
>That creates e.g. a matchingRuleUse for caseIgnoreMatch
>which does not allow seeAlso, which has a different syntax.

Yes, because there is no specification is known by the server
which details the use of caseIgnoreMatch against attribute
values of distinguished name syntax.  But if such specification
were to come into existence and be known by the server, then
the server could publish it if it so chooses.

>Furthermore,
>  "If a matching rule has no corresponding matching rule use,"
>  ..."it can be used with any attribute type."?
>  ...or if not, when can it be used?

A matching rule can be used in an extensbleMatch search
filter any time the usage is well-defined.

Kurt

---

From: Hallvard B Furuseth <[email-masked]>
Date: Thu, 13 Feb 2003 19:08:11 +0100

> Can you offer a specific change to [Models] which attempts

If there are no restrictions, that would be:

4.1.4:

Furthermore,

-- 
Hallvard

---

From: David Chadwick <[email-masked]>
Date: Fri, 14 Feb 2003 00:18:32 +0000

> performing the assertion against a value of the attribute type's

I disagree. If you have a well defined algorithm, say Katakana to ASCII,
then you should have a new matching rule for this, called KatakanaIA5
matching rule, and describe the algorithm in this new rule.

The IA5 matching rule should be purely for IA5 strings, as per the
existing definition.

> No, the assertion syntax and attribute value syntax can be quite

Currently this is not so. They can be different, but only if the
assertion syntax is a subtype of the attribute value syntax e.g, you can
have an assertion syntax in IA5, for an attribute value syntax that is a
sequence of things with a string as the first component (as in string
first component match), or in IA5 for an attribute value of directory
string (which can be a range of different character sets)

David

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: +44 161 295 5351  Fax +44 01484 532930
Mobile: +44 77 96 44 7184
Email: [email-masked]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 13 Feb 2003 17:07:26 -0800

At 04:18 PM 2/13/2003, David Chadwick wrote:
>Currently this is not so.

X.501(93) does not restrict how "different" the syntaxes might
be.  It only requires that there be "rules for deriving a value of
the assertion syntax from a value of the attribute syntax, if required."

And while X.501 says these rules are to be defined as part of the matching
rule specification, I believe (as is the common practice) that new syntax
specifications may define new value derivation rules such that existing
matching rules may be re-used with the new syntax.

There are a wide variety of uses of the "core" matching rules with attribute
value syntaxes not considered by the "core" specification.

Kurt

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 14 Feb 2003 15:27:29 +1100

Kurt,

> matching rules may be re-used with the new syntax.

While there has been some tweaking of the X.500 string matching rules
over time (because of changes to the Directory String syntax), I believe
that the common practice in the X.500 universe is to define new matching
rules for new syntaxes that don't fall within the set of specified
applicable syntaxes of existing matching rules. Note that for some
matching rules the set of applicable syntaxes is open-ended
(e.g. objectIdentifierFirstComponentMatch applies to any existing syntax
and any future syntax that is a SEQUENCE with an OBJECT IDENTIFER as its
first component). Abuses of the X.500 model are all too common in the
LDAP universe.

Regards,
Steven

---

From: "Steven Legg" <[email-masked]>
Date: Fri, 14 Feb 2003 15:43:09 +1100

Kurt,

Kurt D. Zeilenga wrote:
> This wording, I think, is overly restrictive.

For this rule in particular, or as an example ?  

> It's not necessary
> IA5String.

The matching rule definition requires the *assertion* syntax to
be of the IA5 String syntax. Perhaps you mean't the *attribute*
syntax of an attribute to which the rule is applied ?

Regards,
Steven

> What is necessary is a well-defined algorithm for

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 13 Feb 2003 22:05:00 -0800

>For this rule in particular, or as an example ?  

I think I'll reserve myself and say the langauge is fine.  So,
returning to Hallvard's [Models] issue:

>ASN.1 type is IA5String, but not e.g. bit string syntax.

As specified here, yes.  But this specification can be revised
(by update or extension) to support matching against attribute
values of other syntaxes.

>I'm hoping that this also means that a caseIgnoreIA5Match
>matching rule use can only list attributes whose corresponding
>ASN.1 type is IA5String.

If the implementation has knowledge of an revised specification
allowing other uses, it may publish them.

Kurt

---

From: David Chadwick <[email-masked]>
Date: Fri, 14 Feb 2003 12:58:39 +0000

> rule can be used in an extensibleMatch filter.

I disagree. I think it is correct. For example, if you want to use
typeless matching you can specify just the matching rule without the
attribute type, and every AT that has that matching rule in its AT
description will be matched against.

David

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 14 Feb 2003 07:36:36 -0800

>description will be matched against.

In an extensibleMatch search filter, if the type is absent and
the rule present, then the value is matched against all attribute
types which support that rule.   The set of attribute types may
include attribute types which have no defined EQUALITY rule,
attribute types which have a different EQUALITY rule, or attribute
types which have the same EQUALITY rule.

Suitability of rule for use against values of an attribute type
is NOT indicated in the specification of the attribute type
description for the type, but by specification of a matching rule
description for the rule.  This, I believe, is quite clear by
the language used in RFC 2251 and 2252.  In particular,

RFC 2252, 4.2, Attribute Types:
   Note that the AttributeTypeDescription does not list the matching
   rules which can can be used with that attribute type in an
   extensibleMatch search filter.  This is done using the
   matchingRuleUse attribute described in section 4.5.

RFC 2252, 4.5, Matching Rules: 
   Values of the matchingRuleUse list the attributes which are
   suitable for use with an extensible matching rule.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Fri, 14 Feb 2003 10:27:32 -0800

>types which have the same EQUALITY rule.

This is more correct (in my opinion):
  The set of attribute types may include attribute types
  which have the same or different EQUALITY rule.  The set
  cannot contain any attribute type which has no EQUALITY
  rule as no comparisons whatsoever are possible without an
  EQUALITY rule (per X.501(93), 12.4.5).

The following, however, is still correct (in my opinion).