[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
[ldapext] Additional constraints for attribute values in subschema
- To: LDAP Extensions list <ldapext@ietf.org>
- Subject: [ldapext] Additional constraints for attribute values in subschema
- From: Michael Ströder <michael@stroeder.com>
- Date: Wed, 23 Apr 2008 16:37:25 +0200
- Delivered-to: ldapext@core3.amsl.com
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9
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
Ldapext@ietf.org
https://www.ietf.org/mailman/listinfo/ldapext