Re: [ldapext] Additional constraints for attribute values in subschema

[Kurt Zeilenga <Kurt.Zeilenga@Isode.com>]

On Apr 23, 2008, at 7:37 AM, Michael Ströder wrote:

> 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.

Constraints upon the LDAP string encodings of values or constraints  
upon abstract values.

For the latter, I would think a mechanism to specify an ASN.1  
constraint upon the value would work reasonable well.  (Of course,  
implementation ease would depend on how ASN.1 aware your code is  
already.)

For the former, well, given multiple possible encodings per value, I  
don't think it will work well.  For instance, regex'ing works best  
only when the DSA has a canonical string representation of the value.

-- Kurt

>
>
> 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
> Ldapext@ietf.org
> https://www.ietf.org/mailman/listinfo/ldapext

_______________________________________________
Ldapext mailing list
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext