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

[Steven Legg <steven.legg@eb2bcom.com>]

Hi Michael,

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

Another problem is that the underlying ASN.1 type for attributeTypes,
i.e., AttributeTypeDescription, is controlled by the X.500 working group.
If the LDAP-specific encoding is extended but the X.500 definition isn't,
then there is no way to transport the additional parameters in the X.500
protocols (unless they can be expressed as an ASN.1 constraint).

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

Approach 4 is the way I would tackle it.

> 
> Possible constraints:
> 
> REGEX
> Regular expression defining a valid syntax of attribute values

Kurt has already made the point the REGEX works better at the level
of ASN.1 abstract values (as opposed to the particular encoding of
the value), and it so happens that ASN.1 has a PATTERN constraint
for applying a regular expression to a character string. It can also
apply constraints to specific components of complex syntaxes, which
would make it easier to target the right part of a structured value.

A limited subset of ASN.1 constraint notation would be sufficient
to cover the REGEX, VALUES and MAXCHARLEN cases, and would provide
an obvious upgrade path for the future.

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

The size of a value transferred in protocol depends of the encoding rules
used and even on options used within a set of rules. An LDAP-specific
encoding of a value will usually be a different length to its BER encoding
or GSER encoding. A specification would have to be very clear about how
the length is calculated. Perhaps it's not worth the trouble.

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

It don't see any great problem in allowing parameters to at least be combined
by union. A set of values is a union after all.

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

I'd much rather see the LDAP-specific encoding of any new LDAP syntax defined
to be the GSER encoding with respect to a specified ASN.1 type. It's easier to
support for those of us with GSER decoders, and makes no real difference to
those who hand craft their parsers. I imagine the GSER encoding of an
attributeConstraints value would look something like this:

     { type o, ldapURI "ldap://dir.example.com/ou=Companies,dc=example,dc=com?o?one?
     (objectClass=organization)" }

Regards,
Steven

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