schema.sdf 18.7 KB
Newer Older
1
2
3
4
5
6
# $OpenLDAP$
# Copyright 1999-2000, The OpenLDAP Foundation, All Rights Reserved.
# COPYING RESTRICTIONS APPLY, see COPYRIGHT.

H1: Schema Specification

Kurt Zeilenga's avatar
Kurt Zeilenga committed
7
This chapter describes how to extend the user schema used by {{slapd}}(8).
8
The first section, {{SECT:Distributed Schema Files}} details optional
9
10
11
12
13
14
15
16
17
schema definitions provided in the distribution and where to obtain
other definitions.
The second section, {{SECT:Extending Schema}}, details how to define
new schema items.
!if 0
The third section, {{SECT:Transferring Schema}} details how you can
export schema definitions from an LDAPv3 server and transform it
to {{slapd.conf}}(5) format.
!endif
18
19
20
21
22
23
24
25
26

H2: Distributed Schema Files

OpenLDAP is distributed with a set of schema specifications for
your use.  Each set is defined in a file suitable for inclusion
(using the {{EX:include}} directive) in your {{slapd.conf}}(5)
file.  These schema files are normally installed in the
{{F:/usr/local/etc/openldap/schema}} directory.

27
!block table; colaligns="LR"; coltags="F,N"; align=Center; \
28
	title="Table 6.1: Provided Schema Specifications"
29
30
31
32
33
34
35
File			Description
core.schema		OpenLDAP {{core}} (required)
cosine.schema		Cosine and Internet X.500 (useful)
inetorgperson.schema	InetOrgPerson (useful)
misc.schema		Assorted (experimental)
nis.schema		Network Information Services (FYI)
openldap.schema		OpenLDAP Project (experimental)
36
37
38
!endblock

To use any of these schema files, you only need to include the
39
desired file in the global definitions portion of your
40
41
42
43
44
45
46
47
48
49
50
51
52
{{slapd.conf}}(5) file.  For example:

>	# include schema
>	include /usr/local/etc/openldap/schema/core.schema
>	include /usr/local/etc/openldap/schema/cosine.schema
>	include /usr/local/etc/openldap/schema/inetorgperson.schema

Additional files may be available.  Please consult the OpenLDAP
FAQ ({{URL:http://www.openldap.org/faq/}}).

Note: You should not modify any of the schema items defined
in provided files.

Kurt Zeilenga's avatar
Kurt Zeilenga committed
53

54
55
H2: Extending Schema

Kurt Zeilenga's avatar
Kurt Zeilenga committed
56
Schema used by {{slapd}}(8) may be extended to support additional
Kurt Zeilenga's avatar
Kurt Zeilenga committed
57
58
59
60
61
62
syntaxes, matching rules, attribute types, and object classes.  This
chapter details how to add user application attribute types and
object classes using the syntaxes and matching rules already supported
by slapd.  slapd can also be extended to support additional syntaxes,
matching rules and system schema, but this requires some programming
and hence is not discussed here.
63

64
There are five steps to defining new schema:
65
^	obtain Object Identifer
66
+	choose a name prefix
67
68
69
70
+	create local schema file
+	define custom attribute types (if necessary)
+	define custom object classes

Kurt Zeilenga's avatar
Kurt Zeilenga committed
71

72
H3: Object Identifiers
73
74

Each schema element is identified by a globally unique
Kurt Zeilenga's avatar
Kurt Zeilenga committed
75
{{TERM[expand]OID}} (OID).  OIDs are also used to identify
76
77
other objects.
They are commonly found in protocols described by {{TERM:ASN.1}}.  In
78
particular, they are heavily used by the {{TERM[expand]SNMP}} (SNMP).
Kurt Zeilenga's avatar
Kurt Zeilenga committed
79
As OIDs are hierarchical, your organization
80
81
82
83
can obtain one OID and branch it as needed.  For example,
if your organization were assigned OID {{EX:1.1}}, you could branch
the tree as follows:

84
!block table; colaligns="LR"; coltags="EX,N"; align=Center; \
85
	title="Table 6.2: Example OID hierarchy"
86
87
88
89
90
91
92
93
OID		Assignment
1.1		Organization's OID
1.1.1		SNMP Elements
1.1.2		LDAP Elements
1.1.2.1		AttributeTypes
1.1.2.1.1	myAttribute
1.1.2.2		ObjectClasses
1.1.2.2.1	myObjectClass
94
95
96
97
98
99
!endblock

You are, of course, free to design a hierarchy suitable to your
organizational needs under your organization's OID.  No matter
what hierarchy you choose, you should maintain a registry of
assignments you make.  This can be a simple flat file or a
100
101
something more sophisticated such as the {{OpenLDAP OID Registry}}
({{URL:http://www.openldap.org/faq/index.cgi?file=197}}).
102
103
104
105
106
107
108

For more information about Object Identifers (and a listing
service) see {{URL:http://www.alvestrand.no/harald/objectid/}}.

.{{Under no circumstances should you use a fictious OID!}} 

To obtain a fully registered OID at {{no cost}}, apply for
109
an OID under {{ORG[expand]IANA}} (IANA) maintained
110
111
{{Private Enterprise}} arch.  Any private enterprise (organization)
may request an OID to be assigned under this arch.  Just fill
Kurt Zeilenga's avatar
Kurt Zeilenga committed
112
out the {{ORG:IANA}} form at {{URL: http://www.iana.org/cgi-bin/enterprise.pl}}
113
114
115
116
117
118
119
120
121
and your official OID will be sent to you usually within a few days.
Your base OID will be something like {{EX:1.3.6.1.4.1.X}} were {{EX:X}}
is an integer.

Note: Don't let the "MIB/SNMP" statement on the IANA page confuse you.
OIDs obtained using this form may be used for any purpose including
identifying LDAP schema elements.


122
H3: Name Prefix
123

124
In addition to assigning a unique object identifier to each schema
125
element, you should provide a least one textual name for each
Kurt Zeilenga's avatar
Kurt Zeilenga committed
126
element.  The name should be both descriptive and not likely
127
128
129
130
131
132
133
134
135
136
to clash with names of other schema elements.  In particular,
any name you choose should not clash with present or future
Standard Track names.

To reduce (but not eliminate) the potential for name clashes,
the convention is to prefix names of non-Standard Track with
a few letters to localize the changes to your organization.
The smaller the organization, the longer your prefix should
be.

Howard Chu's avatar
Howard Chu committed
137
In the examples below, we have chosen a short prefix '{{EX:my}}'
Kurt Zeilenga's avatar
Kurt Zeilenga committed
138
139
140
141
142
(to save space).  Such a short prefix would only be suitable for
a very large, global organization.  For a small, local organization,
we recommend something like '{{EX:deFirm}}' (German company) or
'{{EX:comExample}}' (elements associated with organization associated
with {{EX:example.com}}).
143
144


145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
H3: Local schema file

The {{EX:objectclass}} and {{EX:attributeTypes}} configuration file
directives can be used to define schema rules on entries in the
directory.  It is customary to create a file to contain definitions
of your custom schema items.  We recommend you create a file
{{F:local.schema}} in {{F:/usr/local/etc/openldap/schema/local.schema}}
and then include this file in your {{slapd.conf}}(5) file immediately
after other schema {{EX:include}} directives.

>	# include schema
>	include /usr/local/etc/openldap/schema/core.schema
>	include /usr/local/etc/openldap/schema/cosine.schema
>	include /usr/local/etc/openldap/schema/inetorgperson.schema
>	# include local schema
>	include /usr/local/etc/openldap/schema/local.schema


163
H3: Attribute Type Specification
164

165
166
167
168
The {{attributetype}} directive is used to define a new attribute
type.  The directive uses the same Attribute Type Description
(as defined in {{REF:RFC2252}}) used by the attributeTypes
attribute found in the subschema subentry, e.g.:
169
170
171

E:	attributetype <{{REF:RFC2252}} Attribute Type Description>

172
173
174
175
176
177
178
179
180
181
182
183
184
where Attribute Type Description is defined by the following
{{TERM:BNF}}:

>      AttributeTypeDescription = "(" whsp
>            numericoid whsp              ; AttributeType identifier
>          [ "NAME" qdescrs ]             ; name used in AttributeType
>          [ "DESC" qdstring ]            ; description
>          [ "OBSOLETE" whsp ]
>          [ "SUP" woid ]                 ; derived from this other
>                                         ; AttributeType
>          [ "EQUALITY" woid              ; Matching Rule name
>          [ "ORDERING" woid              ; Matching Rule name
>          [ "SUBSTR" woid ]              ; Matching Rule name
Kurt Zeilenga's avatar
Kurt Zeilenga committed
185
>          [ "SYNTAX" whsp noidlen whsp ] ; Syntax OID
186
187
188
189
190
191
192
193
194
195
196
197
198
199
>          [ "SINGLE-VALUE" whsp ]        ; default multi-valued
>          [ "COLLECTIVE" whsp ]          ; default not collective
>          [ "NO-USER-MODIFICATION" whsp ]; default user modifiable
>          [ "USAGE" whsp AttributeUsage ]; default userApplications
>          whsp ")"
>
>      AttributeUsage =
>          "userApplications"     /
>          "directoryOperation"   /
>          "distributedOperation" / ; DSA-shared
>          "dSAOperation"          ; DSA-specific, value depends on server
>

where whsp is a space ('{{EX: }}'), numericoid is a globally unique
Kurt Zeilenga's avatar
Kurt Zeilenga committed
200
OID in dotted-decimal form (e.g. {{EX:1.1.0}}), qdescrs is one or
Kurt Zeilenga's avatar
Kurt Zeilenga committed
201
202
more names, woid is either the name or OID optionally followed
length specifier (e.g {{EX:{10}}}).
203
204
205
206

For example, the attribute types {{EX:name}} and {{EX:cn}} are defined
in {{F:core.schema}} as:

Kurt Zeilenga's avatar
Kurt Zeilenga committed
207
>	attributeType ( 2.5.4.41 NAME 'name'
Kurt Zeilenga's avatar
Kurt Zeilenga committed
208
>		DESC 'name(s) associated with the object'
209
210
211
>		EQUALITY caseIgnoreMatch
>		SUBSTR caseIgnoreSubstringsMatch
>		SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )
Kurt Zeilenga's avatar
Kurt Zeilenga committed
212
213
214
215
216
217
218
219
220
221
222
>	attributeType ( 2.5.4.3 NAME ( 'cn' $ 'commonName' )
>		DESC 'common name(s) assciated with the object'
>		SUP name )

Notice that each defines the attribute's OID, provides a short name,
and a brief description.  Each name is an alias for the OID.
{{slapd}}(8) returns the first listed name when returning results.

The first attribute, {{EX:name}}, holds values of {{EX:directoryString}}
(UTF-8 encoded Unicode) syntax.  The syntax are specified by OID
(1.3.6.1.4.1.1466.115.121.1.15 identifies the directoryString
Kurt Zeilenga's avatar
Kurt Zeilenga committed
223
syntax).  A length recommendation of 32768 is specified.  Servers
Kurt Zeilenga's avatar
Kurt Zeilenga committed
224
225
226
227
228
229
should support values of this length, but may support longer values
The field does NOT specify a size constraint, so is ignored on
servers (such as slapd) which don't impose such size limits.  In
addition, the equality and substring matching uses case ignore
rules.  Below are tables listing commonly used syntax and
matching rules (OpenLDAP supports these and many more).
230

231
!block table; align=Center; coltags="EX,EX,N"; \
Kurt Zeilenga's avatar
Kurt Zeilenga committed
232
	title="Table 6.3: Commonly Used Syntaxes"
Kurt Zeilenga's avatar
Kurt Zeilenga committed
233
234
Name			OID				Description
boolean			1.3.6.1.4.1.1466.115.121.1.7	boolean value
235
distinguishedName	1.3.6.1.4.1.1466.115.121.1.12	DN
Kurt Zeilenga's avatar
Kurt Zeilenga committed
236
237
238
239
240
241
242
243
directoryString		1.3.6.1.4.1.1466.115.121.1.15	UTF-8 string
IA5String		1.3.6.1.4.1.1466.115.121.1.26	ASCII string
Integer			1.3.6.1.4.1.1466.115.121.1.27	integer
Name and Optional UID	1.3.6.1.4.1.1466.115.121.1.34	DN plus UID
Numeric String		1.3.6.1.4.1.1466.115.121.1.36	numeric string
OID			1.3.6.1.4.1.1466.115.121.1.38	object identifier
Octet String		1.3.6.1.4.1.1466.115.121.1.40	arbitary octets
Printable String	1.3.6.1.4.1.1466.115.121.1.44	printable string
244
245
!endblock

Kurt Zeilenga's avatar
Kurt Zeilenga committed
246
> 
Kurt Zeilenga's avatar
Kurt Zeilenga committed
247

248
!block table; align=Center; coltags="EX,N"; \
Kurt Zeilenga's avatar
Kurt Zeilenga committed
249
	title="Table 6.4: Commonly Used Matching Rules"
Kurt Zeilenga's avatar
Kurt Zeilenga committed
250
251
Name				Type		Description
booleanMatch			equality	boolean
Kurt Zeilenga's avatar
Kurt Zeilenga committed
252
octetStringMatch		equality	octet string
Kurt Zeilenga's avatar
Kurt Zeilenga committed
253
254
objectIdentiferMatch		equality	OID
distinguishedNameMatch		equality	DN
Kurt Zeilenga's avatar
Kurt Zeilenga committed
255
uniqueMemberMatch		equality	Name with optional UID
Kurt Zeilenga's avatar
Kurt Zeilenga committed
256
257
258
259
260
261
262
263
264
265
numericStringMatch		equality	numerical
numericStringOrderingMatch	ordering	numerical
numericStringSubstringsMatch	substrings	numerical
caseIgnoreMatch			equality	case insensitive, space insensitive
caseIgnoreOrderingMatch		ordering	case insensitive, space insensitive
caseIgnoreSubstringsMatch	substrings	case insensitive, space insensitive
caseExactMatch			equality	case sensitive, space insensitive
caseExactOrderingMatch		ordering	case sensitive, space insensitive
caseExactSubstringsMatch	substrings	case sensitive, space insensitive
caseIgnoreIA5Match		equality	case insensitive, space insensitive
Kurt Zeilenga's avatar
Kurt Zeilenga committed
266
267
caseIgnoreIA5OrderingMatch	ordering	case insensitive, space insensitive
caseIgnoreIA5SubstringsMatch	substrings	case insensitive, space insensitive
Kurt Zeilenga's avatar
Kurt Zeilenga committed
268
caseExactIA5Match		equality	case sensitive, space insensitive
Kurt Zeilenga's avatar
Kurt Zeilenga committed
269
270
caseExactIA5OrderingMatch	ordering	case sensitive, space insensitive
caseExactIA5SubstringsMatch	substrings	case sensitive, space insensitive
271
272
!endblock

273
The second attribute, {{EX:cn}}, is a subtype of {{EX:name}} hence
274
it inherits the syntax, matching rules, and usage of {{EX:name}}.
275
276
{{EX:commonName}} is an alternative name.

Kurt Zeilenga's avatar
Kurt Zeilenga committed
277
278
Neither attribute is restricted to a single value.  Both are meant
for usage by user applications.  Neither is obsolete nor collective.
279
280
281
282
283
284
285

The following subsections provide a couple of examples.


H4: myUniqueName

Many organizations maintain a single unique name for each user.
286
287
Though one could use {{EX:displayName}} ({{REF:RFC2798}}), this
attribute is really meant to be controlled by the user, not the
288
289
290
291
292
293
294
295
296
297
298
organization.  We could just copy the definition of {{EX:displayName}}
from {{F:inetorgperson.schema}} and replace the OID, name, and
description, e.g:

>	attributetype ( 1.1.2.1.1 NAME 'myUniqueName'
>		DESC 'unique name with my organization' 
>		EQUALITY caseIgnoreMatch
>		SUBSTR caseIgnoreSubstringsMatch
>		SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>		SINGLE-VALUE )

299
However, if we want this name to be included in
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
{{EX:name}} assertions [e.g. {{EX:(name=*Jane*)}}], the attribute
could alternatively be defined as a subtype of {{EX:name}}, e.g.:

>	attributetype ( 1.1.2.1.1 NAME 'myUniqueName'
>		DESC 'unique name with my organization' 
>		SUP name )


H4: myPhoto

Many organizations maintain a photo of each each user.  A
{{EX:myPhoto}} attribute type could be defined to hold a photo.
Of course, one could use just use {{EX:jpegPhoto}} ({{REF:RFC2798}})
(or a subtype) to hold the photo.  However, you can only do
this if the photo is in {{JPEG File Interchange Format}}.
Alternatively, an attribute type which uses the {{Octet String}}
syntax can be defined, e.g.:

>	attributetype ( 1.1.2.1.2 NAME 'myPhoto'
>		DESC 'a photo (application defined format)' 
>		SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
>		SINGLE-VALUE )

Kurt Zeilenga's avatar
Kurt Zeilenga committed
323
324
325
In this case, the syntax doesn't specify the format of the photo.
It's assumed (maybe incorrectly) that all applications accessing
this attribute agree on the handling of values.
326

327
328
If you wanted to support multiple photo formats, you could define
a separate attribute type for each format, prefix the photo
329
330
331
with some typing information, or describe the value using
{{TERM:ASN.1}} and use the {{EX:;binary}} transfer option.

Kurt Zeilenga's avatar
Kurt Zeilenga committed
332
Another alternative is for the attribute to hold a {{TERM:URI}}
333
pointing to the photo.  You can model such an attribute after
Kurt Zeilenga's avatar
Kurt Zeilenga committed
334
335
336
337
338
339
{{EX:labeledURI}} ({{REF:RFC2079}}) or simply create a subtype,
e.g.:

>	attributetype ( 1.1.2.1.3 NAME 'myPhotoURI'
>		DESC 'URI and optional label referring to a photo' 
>		SUP labeledURI )
340
341
342
343
344
345
346
347


H3: Object Class Specification

The {{objectclasses}} directive is used to define a new object
class.  The directive uses the same Object Class Description
(as defined in {{REF:RFC2252}}) used by the objectClasses
attribute found in the subschema subentry, e.g.:
348
349
350

E:	objectclass <{{REF:RFC2252}} Object Class Description>

351
352
where Object Class Description is defined by the following
{{TERM:BNF}}:
353

354
355
356
357
358
359
360
361
362
363
364
365
366
>	ObjectClassDescription = "(" whsp
>		numericoid whsp      ; ObjectClass identifier
>		[ "NAME" qdescrs ]
>		[ "DESC" qdstring ]
>		[ "OBSOLETE" whsp ]
>		[ "SUP" oids ]       ; Superior ObjectClasses
>		[ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ]
>			; default structural
>		[ "MUST" oids ]      ; AttributeTypes
>		[ "MAY" oids ]       ; AttributeTypes
>		whsp ")"

where whsp is a space ('{{EX: }}'), numericoid is a globally unique
Kurt Zeilenga's avatar
Kurt Zeilenga committed
367
OID in numeric form (e.g. {{EX:1.1.0}}), qdescrs is one or more
368
names, and oids is one or more names and/or OIDs.
369
370


371
372
H4: myPhotoObject

Kurt Zeilenga's avatar
Kurt Zeilenga committed
373
To define an {{auxiliary}} object class which allows
374
375
376
377
378
379
380
381
382
383
myPhoto to be added to any existing entry.

>	objectclass ( 1.1.2.2.1 NAME 'myPhotoObject'
>		DESC 'mixin myPhoto'
>		AUXILIARY
>		MAY myPhoto )


H4: myPerson

Kurt Zeilenga's avatar
Kurt Zeilenga committed
384
If your organization would like have a private {{structural}}
385
386
object class to instantiate users, you can subclass one of
the existing person classes, such as {{EX:inetOrgPerson}}
Kurt Zeilenga's avatar
Kurt Zeilenga committed
387
({{REF:RFC2798}}), and add any additional attributes which
388
389
390
391
392
you desire.

>	objectclass ( 1.1.2.2.2 NAME 'myPerson'
>		DESC 'my person'
>		SUP inetOrgPerson
Kurt Zeilenga's avatar
Kurt Zeilenga committed
393
394
>		MUST ( myUniqueName $ givenName )
>		MAY myPhoto )
395

396
397
The object class inherits the required/allowed attribute
types of {{EX:inetOrgPerson}} but requires {{EX:myUniqueName}}
Kurt Zeilenga's avatar
Kurt Zeilenga committed
398
and {{EX:givenName}} and allows {{EX:myPhoto}}.
399
400
401
402
403
404
405
406
407
408
409

!if 0
H2: Transferring Schema

Since the {{slapd.conf}}(5) schema directives use {{REF:RFC2252}}
format values, you can extract schema elements published by
any LDAPv3 server and easily construct directives for use with
{{slapd}}(8).

LDAPv3 servers publish schema elements in special {{subschema}}
entries (or subentries).  {{slapd}}(8) publishes a single subschema
410
entry normally named {{EX:cn=Subschema}}.  In a server which
411
412
supports a single subschema subentry, the DN of the subschema
subenty can usually be found by examining the value of the
413
{{EX:subschemaSubentry}} attribute type in the {{root DSE}}.
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
Other servers may publish multiple subschema entries.  These
can be located by examining the {{EX:subschemaSubentry}} attribute
contained in the entry at the root of each administrative context.

To obtain the schema from a subschema subentry, you can use
ldapsearch(1) as follows (replace the search base as needed):

>	ldapsearch -LLL -x -b "cn=Subschema" -s base "(objectclass=subschema)" attributeTypes objectClasses

This will return {{TERM:LDIF}} output containing many type/value
pairs.  The following is an abbreviated example:

>	dn: cn=Subschema
>	attributeTypes: ( 1.1.2.1.1 NAME 'myUniqueName' DESC 'unique name wi
>	 th my organization' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubst
>	 ringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE )
>	attributeTypes: ( 1.1.2.1.2 NAME 'myPhoto' DESC 'a photo (applicatio
>	 n defined format)' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
>	objectClasses: ( 1.1.2.2.2 NAME 'myPerson' DESC 'my person' SUP inet
Kurt Zeilenga's avatar
Kurt Zeilenga committed
433
>	 OrgPerson MUST ( myUniqueName $ givenName ) MAY myPhoto )
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458

Capture the output of the search in a file and then edit the file:

+ to contain only desired type/value pairs
^ join LDIF continuation lines
^ replace attribute type with directive name
(e.g. {{EX:s/attributeTypes:/attributeType/}} and
{{EX:s/objectClasses:/objectClass/}}).
^ continue long directives over multiple lines

For the three type/value pairs in our example, the edit should
result in a file with contains of:

>	attributetype ( 1.1.2.1.1 NAME 'myUniqueName'
>		DESC 'unique name with my organization' 
>		EQUALITY caseIgnoreMatch
>		SUBSTR caseIgnoreSubstringsMatch
>		SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
>		SINGLE-VALUE )
>	attributeType ( 1.1.2.1.2 NAME 'myPhoto'
>		DESC 'a photo (application defined format)'
>		SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
>	objectClass ( 1.1.2.2.2 NAME 'myPerson'
>		DESC 'my person'
>		SUP inetOrgPerson
Kurt Zeilenga's avatar
Kurt Zeilenga committed
459
460
>		MUST ( myUniqueName $ givenName )
>		MAY myPhoto )
461
462

Save in an appropriately named file (e.g. {{F:my.schema}}).
Kurt Zeilenga's avatar
Kurt Zeilenga committed
463
You may now include this file in your {{slapd.conf}}(5) file.
464
!endif
Kurt Zeilenga's avatar
Kurt Zeilenga committed
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492


H3: OID Macros

To ease the management and use of OIDs, {{slapd}}(8) supports
{{Object Identifier}} macros.  The {{EX:objectIdentifier}} is used
to equate a macro (name) with a OID.  The OID may possibly be derived
from a previously defined OID macro.   The {{slapd.conf(5)}} syntax
is:

E:	objectIdentifier <name> { <oid> | <name>[:<suffix>] }

The following demonstrates definition of a set of OID macros
and their use in defining schema elements:

>	objectIdentifier myOID	1.1
>	objectIdentifier mySNMP	myOrgOID:1
>	objectIdentifier myLDAP	myOrgOID:2
>	objectIdentifier myAttributeType	myOrgLDAP:1
>	objectIdentifier myObjectClass	myOrgLDAP:2
>	attributetype ( myAttributeType:3 NAME 'myPhotoURI'
>		DESC 'URI and optional label referring to a photo' 
>		SUP labeledURI )
>	objectclass ( myObjectClass:1 NAME 'myPhotoObject'
>		DESC 'mixin myPhoto'
>		AUXILIARY
>		MAY myPhoto )