ldapACI syntax and matching rules and more

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Just did very quick read of the latest draft.  A few comments
and questions.

Please note that I (still) believe ldapACI should have a syntax
which requires values to conform to the BNF described by Section 6.1
of the draft and that the equality matching rule be "syntax
aware".  In particular, the equality matching rule should
treat any two ACI which have same meaning but different form
to be equal.  That is:

ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:X#group#cn="Dept, XYZ",c=US
ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:x#group#CN="dept, xyz",c=us
ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:x#group#cn=Dept\, XYZ,c=US
ldapACI:1.2.3.4#subtree#grant;c,s,r;attribute:xx#group#cn="Dept, XYZ",c=US
ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:1.1.1#group#cn="Dept, XYZ",c=US

where x is defined as
  ( 1.1.1 NAME ( 'x' $ 'xx' ) SUP 'name' )
should all be considerred equal.  CaseIgnoreString does cut it...
besides not handling the above, it would consider these as
being the same:

ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:X#KerberosID#user@REALM
ldapACI:1.2.3.4#subtree#grant;r,s,c;attribute:X#KerberosID#USER@realm

user != USER and REALM != realm.

Also, I think KerberosId should be generalized.  I suggest
referring to it as a UserId which allows any UTF-8 printable
string.  This maps better onto authmeth's authzid "u:".
If left as a KerberosId, it should not be a SHOULD.

The BNFs appear underspecified.  < printable string > allows
too many characters which hinder (or disallow) parsing.  A
< subject DN > should be an RFC 2253 DN string.  < oid >
should be a RFC 2252 numericoid.  

A few questions:

How does a ACL granting access to an attribute types superior affect
access the attribute type?  Ie: does granting access to 'name'
allow access to 'cn'?

I see that ACLs on attribute subtypes (cn;lang-US) are disallowed.
Is this intentional?  If so, why?  If not, any syntax issues due
to the attribute description's ';'(s) (could have more than one).

Why is ipAddress restricted to the "dotted-decimal string
representation"?  This restricts ipAddress to IPv4 addresses.
A reference to exact ipAddress form should be provided.
[I'd like wildcard support... ie: 10.*.*.* or 10.0.0.0/8
or 10.0.0.0:255.0.0.0]

Kurt