directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Adding extensions to schema element : how do we store them in the meta-schema ?
Date Mon, 18 Oct 2010 12:03:31 GMT
  Hi guys,

I'm a little annoyed atm trying to get the schema element extensions 
handled by the server. Let me explain what is my problem :

- all the schema elements (AT, OC, MR, S, ...) can have some extensions, 
as explicited by RFC 4512.
- a schema element may have more than one element
- an extension has a key and at least one value (but may have many)
- we store the schema elements as LDIF
- we also allow the server to parse those schema elements when provided 
as specified by the RFC
- when parsing them, the extensions are correctly stored into the 
corresponding Java instances, as manipulated by the schemaManager

So the problem is how do we express those extensions in a LDIF format? 
Currently, we don't...

Let me give you some example. The following OC (using the RFC syntax) is 
correctly parsed :

objectclass ( NAME 'person' DESC 'RFC2256: a person' SUP top 
STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ 
seeAlso $ description ) X-extension 'test' X-otherExtension ( 'test1' 
'test2' ) )

The 2 extensions are stored into  Map<String, List<String>> into the 
corresponding instance of

The corresponding LDIF file for this instance would be :
version: 1
version: 1
dn: m-oid=,ou=objectClasses,cn=core,ou=schema
objectclass: metaObjectClass
objectclass: metaTop
objectclass: top
m-name: person
m-description: RFC2256: a person
m-supobjectclass: top
m-typeobjectclass: STRUCTURAL
m-must: cn
m-must: sn
m-may: userPassword
m-may: telephoneNumber
m-may: seeAlso
m-may: description

but I have no idea on how to express the extensions...

Should it be something like :
m-extension: X-extension 'test'
m-extension: X-otherExtension ( 'test1' 'test2' )

if so, that means we will have to parse those extensions when reading 
them. Not convenient.

Another proposal would be to use AT's options :
m-extension;X-extension: test
m-extension;X-otherExtension: test1
m-extension;X-otherExtension: test2

which is probably better, but as we don't currently support AT's option, 
this is not possible.

So, what about starting to think about how to handle AT's options right 
now, assuming it's a part of the spec, that we need it to handle 
languages, and it's also mandatory for binary attributes 
(certificate;bianry, for instance) ?

Emmanuel L├ęcharny

View raw message