extensions for subschema (was: Additional constraints for attribute values in subschema)

HI!

While this ietf-ldapext thread was back in 2008 it's IMO still something worth
to think about. How about discussing this in a BoF session at LDAPcon 2011 in
October?

Yes, I was too busy to write that up for a submission...

Ciao, Michael.

Steven Legg wrote:
> 
> 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' )
>> )