directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Emmanuel Lecharny" <elecha...@gmail.com>
Subject Re: directoryStringFirstComponentMatch & LDAP & ACIs
Date Wed, 10 Jan 2007 10:47:22 GMT
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 <ersin.er@gmail.com> 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

Mime
View raw message