Subject: Re: which syntax for which assertions?

From: "Jim Sermersheim" <[email-masked]>
Date: Thu, 06 May 2004 22:07:58 -0600

After reviewing protocol and models, I think I mostly agree, but I think
there is still room for confusion. For example, [Models] says that
matching rules are used "in determining which individual values are be
added or deleted during performance of a Modify operation,". This could
leave one wondering whether the assertion syntax is supposed to be
used.

However, I don't think this concern is sufficient to warrant any change
to models. I think if the three documents are read as a whole ([Models]
[Protocol] [Syntaxes]), then it's clear as you say. so... Nevermind!

One final suggestion is to clarify that matching rules which name
syntaxes different from the syntax of the attribute they are paired with
should provide a means whereby the assertion attribute syntax can be
derived by the attribute syntax (this is for the case of modify/add). It
may be that the third paragraph of Section 4.1 is saying just that and
I'm not reading it carefully enough. By example, the definitions and
usages of objectIdentifierFirstComponentMatch and
integerFirstComponentMatch follow this suggestion.

>>> "Kurt D. Zeilenga" <[email-masked]> 5/6/04 9:04:42 PM >>>
At 06:50 PM 5/6/2004, Jim Sermersheim wrote:
>I can't find it documented which syntax (the attribute syntax or the
>matching rule syntax) is used for which assertions in various
>operations.

Well, I think the models and X.501 is pretty clear that value in an
AVA is to conform to the assertion syntax, and an attribute value
is to conform to syntax of the attribute type. 

And I think [Protocol] is fairly clear as it uses
AttributeValueAssertion
(AVA) and AssertionValue for the former and PartialAttribute (PA) and
AttributeValue for the latter.

>I'll list what I think, but it may be wrong:
>
>AVAs in:                 (A)ttr or (M)atchRule

s/AVA/AVA or PA/ here.

>equality filter          M(of equality mr)
>ge and le filters        M(of ordering mr)
>substring filters        M(of equality mr)
>extensible filter        M(of extensible mr)
>compare                  M(of equality mr)
>add/mod                  A(of equality mr)
>DNs                      A(of equality mr)

DNs clearly are sequences of AVAs.

>So for example, a compare operation which specifies 'attributeTypes'
>will send an 'OID' and not an 'Attribute Type Description'.

Yes.  The assertion syntax of the AttributeType's equality matching
rule is OID.

>Whereas if
>the same attribute were passed in an add operation, it would send an
>'Attribute Type Description', rather than an 'OID'.

Yes, The attribute syntax of the AttributeTYpe is Attribute Type
Description.

>It's important to make this distinction because LDAP doesn't provide
>syntax knowledge in AVAs.

In either cases (AVAs or PAs), one has to have schema knowledge to
know
the assertion and attribute syntaxes of the attribute type.

>If an AVA also carried with it the syntax used
>for the assertion value, we could derive the 'OID' from the
'Attribute
>Type Description' in the compare example above.  But because we don't
>have this ability, we must state which syntax is used for each
operation
>so the server can know how to interpret it.

I don't follow this.  It's clear which attribute type is involved
and its clear from the context whether the value is an assertion
value or an attribute value.  So, with schema knowledge, the
syntax of value can be determined.

Kurt

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Thu, 06 May 2004 22:52:21 -0700

>leave one wondering whether the assertion syntax is supposed to be

Well, the abstract data type associated with the assertion syntax is
used in such matching.  For objectIdentifierFirstComponentMatch,
one key part of the rule is how the attribute value of the assertion
syntax is derived from the attribute value so that provided value
(of the assertion syntax) can be compared against it.  If we're
comparing two attribute values, then both need to transform to the
values of the assertion syntax for comparison.

This implies that equality rules need to define matching in terms of
assertion values.  Otherwise it won't work properly in both contexts
(add/modify v. AVA).

>to models.

I'd actually be worried that more text might be confusing.

>Nevermind!

Okay.

>may be that the third paragraph of Section 4.1 is saying just that and

Yes.

Kurt