Re: 2.3.1alpha and ACL set matching

["Pierangelo Masarati" <ando@sys-net.it>]

> Pierangelo Masarati writes:
>> The point is that we don't know the attribute type of literals, and sets
>> are intended to match etherogeneous strings as well, as far as they
>> resolve to some string representation.
>
> Does this imply that sets do remember the attribute types of values
> fetched from the directory?

They don't (but they could); however, literals are not typed, so there's
little to remember.

>
>> I guess case-insensitive match might be a good trade-off, although
>> case-sensitive match might be desirable in few cases...
>
> I expect case-insensitive is the best choice.  I don't think I've ever
> needed to know whether normalized values are uppercase or lowercase.
> One must use the normalized value with dn.regex too, except that IIRC
> that is case-insensitive.

regexes are case-insensitive, so the parallel with sets sounds reasonable.
I won't object making the comparison case-insensitive, at the price of
dropping the possibility of case-exact matches.

>
> Still, one could have a <set>.normalize(attributeType) operation
> if or when someone needs to match a case-sensitive attribute.

That would be advisable for dynamically generated literals (e.g. from
regex substitutions); however, for static portions, I'd live with
delegating normalization to the administrator (because a few lookups and
typings are worth avoiding the penalty of normalizing static strings at
every access checking).  I note that the "." notation you use was the
original notation used for dereferencing an attribute; it was dropped in
favor of "/" (or the undocumented "->") because dots can appear inside an
OID, so "[<dn>].member.uid could be confusing if used as
"[<dn>].2.5.4.31.0.9.2342.19200300.100.1.1.

I guess we need to define a way to call attributeType-specific methods
either implicitly or explicitly, i.e.

    set/attributeType->normalize

to normalize (or any other method) the result of the "attributeType"
dereferentiation from "set" according to the syntax of "attributeType", or

    syntax->normalize(set)

to apply normalization (or whatever) to "set" according to "syntax" rules.
 With this mechanism, we could implement the escape/unescape rules you
were talking about in a related message:

    "[cn=] + distinguishedName->escape(user/cn) + [,o=foo]"

and

    "self/uid & distinguishedName->unescape([$1])"

In this case, the methods could be "normalize", "escape", "unescape"; more
could be added as required ("pretty"?).

>
> BTW, this reminds me: we ought to document what the normalized form of
> the various attribute types are, and maybe make a tool which normalizes
> input values according to a specified attribute type.

That would need to be a slap tool because it needs be schema-aware.  some
slapnormal?

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it


    SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497