Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migrated to Confluence 5.3
Note
titleWork in progress

This site is in the process of being reviewed and updated.

Table of Contents
indent20px
typelist

Introduction

We want to store the schema into ADS as any other entries. We have to define the minimum set of ObjectClasses an AttributeTypes needed to be able to bootstrap the schema.

All the ObjectClass will depend on the MetaObjectClass element, which is hard wired in the server.
All the AttributeTypes will depend on the MetaAttributeType element, which is hard wired in the server.

Note

The new Syntaxes will use the OIDs  1.3.

Note

The new AttributesType will use the OIDs 1.3.6.1.4.1.18060.10.14.0.30.N
The new ObjectClasses MatchingRules will use the OIDs 1.3.6.1.4.1.18060.10.14.0.41.N
Here, the prefix The new AttributesType will use the OIDs 1.3.6.1.4.1.18060 is the one declared to IANA to represent the Apache Foundation and the next 1.1 values are used specifically for Apache Directory.

Syntaxes

We must define the minimum set of syntaxes.

Those are following the following grammar (from RFC 4512 ) :

Code Block

<SyntaxDescription> ::= 
    <LPAREN> <WSP>
         <numericoid>
         ( <SP> "DESC" <SP> <qdstring> )?
         <extensions> <WSP> 
    <RPAREN>

Only one is already defined: in http://www.rfc-archive.org/getrfc.php?rfc=4517

Code Block

3.3.3.  Boolean

   A value of the Boolean syntax is one of the Boolean values, true or
   false.  The LDAP-specific encoding of a value of this syntax is
   defined by the following ABNF:

      Boolean = "TRUE" / "FALSE"

   The LDAP definition for the Boolean syntax is:

      ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' )

   This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].

They are the new one described in the following table :

...

Desc

...

OID

...

Extensions

...

rules

...

NameOrOid

...

1.3.6.1.4.1.18060.1.1.0.1.1

...

-

...

Must be a valid Name or a valid OID

...

NamesOrOids

...

1.3.6.1.4.1.18060.1.1.0.1.2

...

-

...

Must be a list of valid Names or a valid OIDs

...

Type

.0.4.0.2.N
The new ObjectClasses will use the OIDs 1.3.6.1.4.1.18060.0.4.0.3.N
The new DITStructureRules will use the OIDs 1.3.6.1.4.1.18060.0.4.0.4.N
The new NameForms will use the OIDs 1.3.6.1.4.1.18060.0.4.0.5.N

We will use OIDs  1.3.6.1.4.1.18060.1.1.0.0.N for Meta objects.

Here, the prefix 1.3.6.1.4.1.18060 is the one declared to IANA to represent the Apache Foundation and the next 1.1 values are used specifically for Apache Directory.

Elements of the Meta-Schema

The MetaSchema will be presented in MetaSchema schema, but before, we must define some elements in this page.

Syntaxes

We must define the minimum set of syntaxes.

Those are following the following grammar (from RFC 4512 ) :

No Format

<SyntaxDescription> ::=
    <LPAREN> <WSP>
         <numericoid>
         ( <SP> "DESC" <SP> <qdstring> )?
         <extensions> <WSP>
    <RPAREN>

34 of them are defined in  RFC 4517. For instance, here the definition of Boolean syntax :

No Format

3.3.3.  Boolean

   A value of the Boolean syntax is one of the Boolean values, true or
   false.  The LDAP-specific encoding of a value of this syntax is
   defined by the following ABNF:

      Boolean = "TRUE" / "FALSE"

   The LDAP definition for the Boolean syntax is:

      ( 1.3.

...

6.1.4.1.

...

1466.

...

115.121.1.7 DESC 'Boolean' )

   This syntax corresponds to the BOOLEAN ASN.1 type from [ASN.1].

Here are the new one we need to implement the MetaSchema, described in the following table :

1.0.1.3

Desc

OID

Extensions

rules

objectClassType

-

Should be one of those 3 strings :

  • ABSTRACT
  • STRUCTURAL
  • AUXILIARY

Usage

1.3.6.1.4.1.18060.10.14.0.0.1 .4

-

Should be one of those 4 3 strings :

  • ABSTRACT
  • STRUCTURALuserApplications
  • directoryOperationAUXILIARY
  • distributedOperation
  • dSAOperation

MatchingRules

The Matching rules are deifned in RFC 4512 :

Code Block

<MatchingRuleDescription> ::= <LPAREN> <WSP>
         <numericoid> <MRParameters>
         <SP> "SYNTAX" <SP> <numericoid>
         <extensions> <WSP> <RPAREN>

<MRParameters> ::= 
    ( <SP> "NAME" <SP> <qdstrings> |
    <SP> "DESC" <SP> <qdstring> |
    <SP> "OBSOLETE" )+

Here are the new MatchingRules :

numericOid

1.3.6.1.4.1.18060.0.4.0.0.2

-

Must be a valid numeric OID

attributeTypeUsage

1.3.6.1.4.1.18060.0.4.0.0.3

-

Should be one of those 4 strings :

  • userApplications
  • directoryOperation
  • distributedOperation
  • dSAOperation

number

1.3.6.1.4.1.18060.0.4.0.0.4

-

Must be a number

oidLen

1.3.6.1.4.1.18060.0.4.0.0.5

-

Must be a valid numeric oid followed
by a length constraint

objectName

1.3

Name

OID

Desc

Obsolete

Syntax

Extensions

BooleanMatch

1.3.6.1.4.1.18060.10.14.0.20.1

Match a Boolean

no

Boolean

-

6

-

Must be a valid name a-zA-Z(a-zA-Z0-9-;)*

MatchingRules

The Matching rules are defined in RFC 4512 :

No Format

<MatchingRuleDescription> ::= <LPAREN> <WSP>
         <numericoid> <MRParameters>
         <SP> "SYNTAX" <SP> <numericoid>
         <extensions> <WSP> <RPAREN>

<MRParameters> ::=
    ( <SP> "NAME" <SP> <qdstrings> |
    <SP> "DESC" <SP> <qdstring> |
    <SP> "OBSOLETE" )+

Here are the new MatchingRules :

Name

OID

Desc

Obsolete

Syntax

Extensions

OidMatch

NameOrOidMatch

1.3.6.1.4.1.18060.1.1.0.2.2

Match a name or an OID

no

NameOrOid

-

NamesOrOidsMatch

1.3.6.1.4.1.18060.1.1.0.2.3

Match a list of names or OIDs

no

NamesOrOids

-

TypeMatch

1.3.6.1.4.1.18060.1.1.0.2.41

Match a type of ObjectClassan OID

no

OID Type

-

UsageMatch BooleanMatch

1.3.6.1.4.1.18060.1.1.0.2.52

Match an attributeType Usagea Boolean

no

Usage Boolean

-

ObjectClasses

The ObjectClass element is described in RFC 4512 :

NameOrOidMatch

1.3.6.1.4.1.18060.1.1.0.2.3

Match a name or an OID

no

NameOrOid

-

TypeMatch

1.3.6.1.4.1.18060.1.1.0.2.4

Match a type of ObjectClass

no

Type

-

UsageMatch

1.3.6.1.4.1.18060.1.1.0.2.5

Match an attributeType Usage

no

Usage

-

ObjectClasses

The ObjectClass element is described in RFC 4512 :

No Format

<ObjectClassDescription> 
Code Block

<ObjectClassDescription> ::=
          <LPAREN> <SP> <numericoid> <ocparameters> <extensions> <WSP> <RPAREN>

// Each parameters should not be seen more than once
<ocparameters>  ::=
    ( <SP> "NAME" <SP>    <LPAREN> <SP> <numericoid> <ocparameters> <extensions> <WSP> <RPAREN>

// Each parameters should not be seen more than once
<ocparameters>  ::=
    ( <SP> "NAME" <SP> <qdescrs>
    | <SP> "DESC" <SP> <qdstring>
    | <SP> "OBSOLETE"
    | <SP> "SUP" <SP> <oids>
    | <SP> ( "ABSTRACT" | "STRUCTURAL" | "AUXILIARY" )
    | <SP> "MUST" <SP> <oids>
    | <SP> "MAY" <SP> <oids> )+

Here we have some elements which are already in the schema :

Code Blocknoformat
attributetype ( 2.5.4.0
	NAME 'objectClass'
	DESC 'RFC2256: object classes of the entity'
	EQUALITY objectIdentifierMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.38
 )
Code Blocknoformat
attributetype ( 2.5.4.13
	NAME 'description'
	DESC 'RFC2256: descriptive information'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
 )
Code Blocknoformat
attributetype ( 2.5.4.41
	NAME 'name'
	DESC 'RFC2256: common supertype of name attributes'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768}
 )

...

Name

OID

Desc

Sup

Equality

Ordering

Substr

Syntax

SingleValue

Collective

NoUserModification

Usage

m-oid

obsolete

1.3.6.1.4.1.18060.10.14.0.32.1

The type is obsolete Object Identifier

-

OidMatch BooleanMatch

-

-

Boolean OID

yes

-

yes

dSAOperation

sup m-name

1.3.6.1.4.1.18060.10.14.0.32.2

The list of superior Object name

-

NamesOrOidsMatch caseIgnoreMatch

-

-

caseIgnoreSubstringsMatch

objectName {32768} NamesOrOids

no

-

yes

dSAOperation

must

m-description

1.3.6.1.4.1.18060.10.14.0.32.3

The list of mandatory AT object description

-

NamesOrOidsMatch caseIgnoreMatch

-

-

NamesOrOids

no

-

yes

dSAOperation

caseIgnoreSubstringsMatch

1.3.6.1.4.1.1466.115.121.1.15{1024}

yes

-

m-obsolete

may

1.3.6.1.4.1.18060.10.14.0.32.4

The list of authorized AT type is obsolete

-

NamesOrOidsMatch BooleanMatch

-

-

NamesOrOids Boolean

no yes

-

yes

dSAOperation

type m-supObjectClass

1.3.6.1.4.1.18060.10.14.0.32.5

The ObjectClass type list of superiors

-

TypeMatch NameOrOidMatch

-

-

Type NameOrOid

yes no

-

yes

dSAOperation

AttributeType

The AttributeType element is described in RFC 4512 :

m-must

1.3.6.1.4.1.18060.0.4.0.2.6

The list of mandatory ATs

-

NameOrOidMatch

-

-

NameOrOid

no

-

m-may

1.3.6.1.4.1.18060.0.4.0.2.7

The list of authorized ATs

-

NameOrOidMatch

-

-

NameOrOid

no

-

m-typeObjectClass

1.3.6.1.4.1.18060.0.4.0.2.8

The ObjectClass type

-

TypeObjectClassMatch

-

-

TypeObjectClass

yes

-

m-extensionObjectClass

1.3.6.1.4.1.18060.0.4.0.2.9

An objectclass
extension

-

caseIgnoreMatch

-

-

1.3.6.1.4.1.1466.115.121.1.15{32768}

no

-

AttributeType

The AttributeType element is described in RFC 4512 :

No Format

<AttributeTypeDescription> = <LPAREN> <WSP> <numericoid> <atparameters> <extensions> <WSP> <RPAREN>

// Each parameters should not be seen more than once
<atparameters>  ::=
    (<SP> "NAME" <SP> <qdescrs>
Code Block

<AttributeTypeDescription> = <LPAREN> <WSP> <numericoid> <atparameters> <extensions> <WSP> <RPAREN>

// Each parameters should not be seen more than once
<atparameters>  ::=
    (<SP> "NAME" <SP> <qdescrs>
    | <SP> "DESC" <SP> qdstring
    | <SP> "OBSOLETE"
    | <SP> "SUP" <SP> <oid>
    | <SP> "EQUALITY" <SP> <oid>
    | <SP> "ORDERING" <SP> <oid>
    | <SP> "SUBSTR" <SP> <oid>
    | <SP> "SYNTAX" <SP> <noidlen>
    | <SP> "SINGLE-VALUE"
    | <SP> "COLLECTIVEDESC" <SP> qdstring
    | <SP> "NO-USER-MODIFICATIONOBSOLETE"
    | <SP> "USAGESUP" <SP> <usage>)+

Here we have some elements which are already in the schema :

Code Block

attributetype ( 2.5.4.13
	NAME 'description'
	DESC 'RFC2256: descriptive information'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
 )
Code Block

attributetype ( 2.5.4.41
	NAME 'name'
	DESC 'RFC2256: common supertype of name attributes'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768}
 )

The other ones must be defined. Here is a table grouping all the missing elements :

...

Name

...

OID

...

Desc

...

Sup

...

Equality

...

Ordering

...

Substr

...

Syntax

...

SingleValue

...

Collective

...

NoUserModification

...

Usage

...

obsolete

...

1.3.6.1.4.1.18060.1.1.0.3.6

...

The type is obsolete

...

-

...

BooleanMatch

...

-

...

-

...

Boolean

...

yes

...

-

...

yes

...

dSAOperation

...

sup

...

1.3.6.1.4.1.18060.1.1.0.3.7

...

The list of superior

...

-

...

nameOrOidMatch

...

-

...

-

...

NameOrOid

...

yes

...

-

...

yes

...

dSAOperation

...

equality

<oid>
    | <SP> "EQUALITY" <SP> <oid>
    | <SP> "ORDERING" <SP> <oid>
    | <SP> "SUBSTR" <SP> <oid>
    | <SP> "SYNTAX" <SP> <noidlen>
    | <SP> "SINGLE-VALUE"
    | <SP> "COLLECTIVE"
    | <SP> "NO-USER-MODIFICATION"
    | <SP> "USAGE" <SP> <usage>)+

Here we have some elements which are already in the schema :

No Format

attributetype ( 2.5.4.13
	NAME 'description'
	DESC 'RFC2256: descriptive information'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
 )
No Format

attributetype ( 2.5.4.41
	NAME 'name'
	DESC 'RFC2256: common supertype of name attributes'
	EQUALITY caseIgnoreMatch
	SUBSTR caseIgnoreSubstringsMatch
	SYNTAX 1.3.6.1.4.1.1466.

...

115.

...

121.1.15{32768}
 )

The other ones must be defined. Here is a table grouping all the missing elements :

0.3.8

Name

OID

Desc

Sup

Equality

Ordering

Substr

Syntax

SingleValue

Collective

m-supAttributeType

Equality matching rule

-

nameOrOidMatch

-

-

NameOrOid

yes

-

yes

dSAOperation

ordering

1.3.6.1.4.1.18060.10.14.0.2.10

The list of superior

-

nameOrOidMatch

-

-

NameOrOid

yes

-

m-equality

1.3.9 .6.1.4.1.18060.0.4.0.2.11

Equality Ordering matching rule

-

nameOrOidMatch

-

-

NameOrOid

yes

-

m-ordering

yes

dSAOperation

substr

1.3.6.1.4.1.18060.1.1.0.3.10

Substring matching rule

-

nameOrOidMatch

-

-

NameOrOid

yes

-

yes

dSAOperation

.4.1.18060.0.4.0.2.12

Ordering matching rule

-

nameOrOidMatch

-

-

NameOrOid

yes

-

m-substr

1.3.6.1.4.1.18060.0.4.0.2.13

Substring matching rule

-

nameOrOidMatch

-

-

NameOrOid

yes

-

m-syntax

1.3.6.1.4.1.18060.0.4.0.2.14

The attribute syntax

-

nameOrOidMatch

-

-

NameOrOid

yes

-

m-singleValue

1.3.6.1.4.1.18060.0.4.0.2.15

The attribute is single valued

-

BooleanMatch

-

-

Boolean

yes

-

m-collective

1.3.6.1.4.1.18060.0.4.0.2.16

The attribute is collective

-

BooleanMatch

-

-

Boolean

yes

-

m-noUserModification

1.3.6.1.4.1.18060.0.4.0.2.17

The attribute is protected

-

BooleanMatch

-

-

Boolean

yes

-

m-usage

1.3.6.1.4.1.18060.0.4.0.2.18

Type of operation

-

UsageMatch

-

-

Usage

yes

-

m-extensionAttribyteType

1.3.6.1.4.1.18060.0.4.0.2.19

Extension for attributeType

-

caseIgnoreMatch

-

-

1.3.6.1.4.1.1466.115.121.1.15{32768}

no

-

Ordering is useless, so is Substr.

DITStructureRules

The DITStructureRule element is described in RFC 4512 :

No Format

<DITStructureRule> = <LPAREN> <WSP> <ruleid> <dsrparameters> <extensions> <WSP> <RPAREN>

// Each parameters should not be seen more than once
<dsrparameters>  ::=
    ( <SP> "NAME" <SP> <qdescrs>
    | <SP> "DESC" <SP> qdstring
    | <SP> "OBSOLETE"
    | <SP> "FORM" <SP> <oid>
    | <SP> "SUP" <SP> <ruleids>) +

The other ones must be defined. Here is a table grouping all the missing elements :

Name

OID

Desc

Sup

Equality

Ordering

Substr

Syntax

SingleValue

Collective

m-ruleId

1.3.6.1.4.1.18060.0.4.0.2.20

The rule ID

-

ruleIdMatch

-

-

RuleId

yes

-

m-form 

1.3.6.1.4.1.18060.0.4.0.2.21

The name form associated
with this DITStructure rule

-

oidMatch

-

-

RuleIds

yes

-

m-supDitStructureRule

1.3.6.1.4.1.18060.0.4.0.2.22

The list of superiors

-

ruleIdsMatch

-

-

Oid

no

-

m-extensionDITStructureRule

1.3.6.1.4.1.18060.0.4.0.2.23

Extensions for DITStructureRule

-

caseIgnoreMatch

-

-

1.3.6.1.4.1.1466.115.121.1.15{32768}

no

-

NameForms

The NameForm element is described in RFC 4512 :

No Format

<NameForm> = <LPAREN> <WSP> <numericOid> <nfParameters> <extensions> <WSP> <RPAREN>

// Each parameters should not be seen more than once
<nfParameters>  ::=
    ( <SP> "NAME" <SP> <qdescrs>
    | <SP> "DESC" <SP> qdstring
    | <SP> "OBSOLETE"
    | <SP> "OC" <SP> <oid>
    | <SP> "MUST" <SP> <oids>
    | <SP> "MAY" <SP> <oids> ) +

The other ones must be defined. Here is a table grouping all the missing elements :

Name

OID

Desc

Sup

Equality

Ordering

Substr

Syntax

SingleValue

Collective

m-oc

1.3.6.1.4.1.18060.0.4.0.2.24

The structural ObjectClass

-

numericOidMatch

-

-

Oid

yes

-

m-extensionNameForm

1.3.6.1.4.1.18060.0.4.0.2.25

Extensions for NameForm

-

caseIgnoreMatch

-

-

1.3.6.1.4.1.1466.115.121.1.15{32768}

no

-

DITContentRules

The DITContentRule element is described in RFC 4512 :

No Format

<DITContentRule> = <LPAREN> <WSP> <numericOid> <dcrParameters> <extensions> <WSP> <RPAREN>

// Each parameters should not be seen more than once
<dcrParameters>  ::=
    ( <SP> "NAME" <SP> <qdescrs>
    | <SP> "DESC" <SP> qdstring
    | <SP> "OBSOLETE"
    | <SP> "AUX" <SP> <oids>
    | <SP> "MUST" <SP> <oids>
    | <SP> "MAY" <SP> <oids>
    | <SP> "NOT" <SP> <oids> ) +

The other ones must be defined. Here is a table grouping all the missing elements :

Name

OID

Desc

Sup

Equality

Ordering

Substr

Syntax

SingleValue

Collective

m-aux

1.3.6.1.4.1.18060.0.4.0.2.26

List of auxiliary ObjectClasses

-

numericOidMatch

-

-

Oids

no

-

m-not

1.3.6.1.4.1.18060.0.4.0.2.27

List of precluded attribute types

-

numericOidMatch

-

-

Oids

no

-

m-extensionDITContentRule

1.3.6.1.4.1.18060.0.4.0.2.28

Extensions for DITContentRule

-

caseIgnoreMatch

-

-

1.3.6.1.4.1.1466.115.121.1.15{32768}

no

-

MatchingRuleUses

The MatchingRuleUse element is described in RFC 4512 :

No Format

<MatchingRuleUse> = <LPAREN> <WSP> <numericOid> <mruParameters> <extensions> <WSP> <RPAREN>

// Each parameters should not be seen more than once
<mruParameters>  ::=
    ( <SP> "NAME" <SP> <qdescrs>
    | <SP> "DESC" <SP> qdstring
    | <SP> "OBSOLETE"
    | <SP> "APPLIES" <SP> <oids> ) +

The other ones must be defined. Here is a table grouping all the missing elements :

Name

OID

Desc

Sup

Equality

Ordering

Substr

Syntax

SingleValue

Collective

m-applies syntax

1.3.6.1.4.1.18060.10.14.0.32.11 29

List of attribute types the matching rule applies to The attribute syntax

-

numericOidMatch nameOrOidMatch

-

-

NameOrOid Oids

yes no

-

yes

dSAOperation

m-extensionMatchingRuleUse single-value

1.3.6.1.4.1.18060.10.14.0.32.12 30

Extensions for DITContentRule The attribute is single valued

-

BooleanMatch

- caseIgnoreMatch

-

Boolean

yes

-

yes

dSAOperation


- collective

1.3.6.1.4.1.1466.18060115.1.1.0.3.13

The attribute is collective

-

BooleanMatch

-

-

Boolean

yes

-

yes

dSAOperation

no-user-modification

1.3.6.1.4.1.18060.1.1.0.3.14

The attribute is protected

-

BooleanMatch

-

-

Boolean

yes

-

yes

dSAOperation

usage

1.3.6.1.4.1.18060.1.1.0.3.15

Type of operation

-

UsageMatch

-

-

Usage

yes

-

yes

dSAOperation

...

121.1.15{32768}

no

-

Description of currently existing schemas

All the current schemas objects are described with the new syntax in those pages :