Well, good question.
If the syntax starts with a '{' and end with a '}' for all
DirectoryStringFirstComponent (DSFC in the following discussion), then I
think we can remove them.
syntax ::= '{' <xxx> '}'
is strictly equivalent to
syntax ::= '{' <xxx> '}'
if we can't have an isolated '}' in <xxx>.
The very same for the identificationTag : if all <xxx> start with <
identificationTag "someId" >, then no need to have this identificationTag
token because it's implicit.
At the end, we could perfectly have :
syntax ::= " <ID> " <xxx>
instead of
syntax ::= '{' identificationTag " <ID> " <xxx> '}'
wdyt ?
On 1/9/07, Ersin Er <[EMAIL PROTECTED]> wrote:
Hi all,
I think directoryStringFirstComponentMatch matching rule was designed
with respect to X.500 semantics in the old days (which were really
cool). Here is the definition for it from RFC 4517:
-------
The directoryStringFirstComponentMatch rule compares an assertion
value of the Directory String syntax to an attribute value of a
syntax whose corresponding ASN.1 type is a SEQUENCE with a mandatory
first component of the DirectoryString ASN.1 type.
Note that the assertion syntax of this matching rule differs from the
attribute syntax of attributes for which this is the equality
matching rule.
The rule evaluates to TRUE if and only if the assertion value matches
the first component of the attribute value using the rules of
caseIgnoreMatch.
The LDAP definition for the directoryStringFirstComponentMatch
matching rule is:
( 2.5.13.31 NAME 'directoryStringFirstComponentMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
The directoryStringFirstComponentMatch rule is an equality matching
rule. When using directoryStringFirstComponentMatch to compare two
attribute values (of an applicable syntax), an assertion value must
first be derived from one of the attribute values. An assertion
value can be derived from an attribute value by taking the first
component of that attribute value.
-------
As X.500 was not as verbose as LDAP for string representations, the
first component of an SEQUENCE was really the value of the first
component. However when translating ASN.1 definitions to LDAP string
representations as suggested by RFC 3641, the "first component" in
SEQUENCES are no longer kept. For example prescriptiveACI attribute
type is defined as follows:
-------
attributetype ( 1.3.6.1.4.1.18060.0.4.1.2.12 NAME 'prescriptiveACI'
DESC 'Access control information that applies to a set of entries'
EQUALITY directoryStringFirstComponentMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.1
USAGE directoryOperation )
-------
So it uses the directoryStringFirstComponentMatch for equality checks.
The first component of an ACI is the identificationTag, a simple
identifier string. However in LDAP string representation an ACI starts
as follows:
{ identificationTag "SomeID", ...
The intended first component here is "SomeID", but as you see we have
'{' and "identificationTag" before it. So one question arises here:
"How should we implement directoryStringFirstComponentMatch for LDAP?"
Should it skip a '{' and an identifier ("identificationTag" here) and
then handle the third component?
If we do not do this properly, we'll not be able to compare ACIs
correctly.
WDYT?
--
Ersin
--
Cordialement,
Emmanuel Lécharny
www.iktek.com
