[ldapext] Additional constraints for attribute values in subschema

[Michael Ströder <[e-mail]>]

HI!

I'd like to discuss the idea of defining and publishing additional 
constraints on attribute values in the subschema subentry in a 
standardized way so that schema-aware clients can obey these constraints 
guiding the user and servers can enforce these constraints when entries 
are added or modified.

Please let me know what you think about explanations below.

Ciao, Michael.

----------------------------------------------------------------------

Sometimes it's not sufficient to simply specify an existing LDAP syntax
or SINGLE-VALUE flag for an attribute type to express more specific 
constraints on attribute values.

Such constraints are considered most times to be part of a local 
directory profile defined by the DSA administrator, but it is not 
limited to this purpose. Schema designers MAY also define additional 
constraints in published standards. Also servers MAY enforce constraints 
not specified like explained herein (e.g. a unique value constraint).

There are several possible approaches for this:

1. Extend attributeTypes in subschema subentry with additional 
parameters. This would require to change standard schema definitions for 
locally profiling a directory which is widely considered bad practice. 
Also compability to older implementations is a risk.

2. Proprietary server-configuration like already implemented in server 
products. The caveat is that an interactive schema-aware client cannot 
retrieve this constraint information in a standardized way. So guiding 
the user to do the right thing is not possible.

3. A subentry specification for a part of the DIT. Unfortunately this 
mechanism is AFAIK not widely supported in current server 
implementations and needs more work.

4. My proposal is to add a new attribute 'attributeConstraints' to the 
subschema subentry which associates additional constraints with a 
certain attribute type by OID crossref similar like DIT content rules do 
for structural object classes.

Possible constraints:

REGEX
Regular expression defining a valid syntax of attribute values

VALUES
Explicit set of possible attribute values. (The constraint itself could 
also be achieved by REGEX but it enables the client to provide a typical 
select list at the user interface.)

LDAPURI
LDAP URL specifying a set of possible attribute values as LDAP search 
results. If attrs is not specified the DNs of the found entries are the 
set of possible values.

OPTIONS
Set of possible tagging attribute options or option tag/range prefixes.

MAXNUMBER
max. count of multi-valued attribute values

MAXBYTELEN
maximum numbers of bytes

MAXCHARLEN
maximum lenght of a character-based string (depending on syntax)

Either one of REGEX, VALUES and LDAPURI SHALL be allowed, not 
combinations of these parameters.

Examples (lines partially wrapped in this message):

For constraining attribute type 'o' to a set of 'o' attribute
values of already existing company entries. (This might cause problems 
if only one subschema subentry is present for the whole DIT.)

attributeConstraints ( 2.5.4.10
   LDAPURI 
ldap://dir.example.com/ou=Companies,dc=example,dc=com?o?one?(objectClass=organization)
)

For attribute type 'manager' be chosen from DNs of existing entries:

attributeConstraints ( 0.9.2342.19200300.100.1.10
   LDAPURI 
ldap://dir.example.com/dc=example,dc=com??sub?(&(objectClass=inetOrgPerson)(title=Manager))
)

For attribute type 'jpegPhoto' of restricted size and to a single value 
(overrides multi-valued default):

attributeConstraints ( 0.9.2342.19200300.100.1.60
   MAXNUMBER 1
   MAXBYTELEN 4000
)

Restricting a (proprietary) attribute 'gender' to values specified in 
ISO standard 5801:

attributeConstraints ( 1.3.6.1.4.1.5427.1.389.4.7
   VALUES ( '0' $ '1' $ '2' $ '9' )
)

_______________________________________________
Ldapext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ldapext