]> git.sur5r.net Git - openldap/blobdiff - doc/guide/admin/schema.sdf
Add link to SDF tools at CPAN.
[openldap] / doc / guide / admin / schema.sdf
index 711bd99f172648a2b00f1a4f8038079df7a892e3..f0e1dd3bd200c923dbca0684cae6f040b68cdbdb 100644 (file)
@@ -4,7 +4,7 @@
 
 H1: Schema Specification
 
-This chapter describes how to extend the schema used by {{slapd}}(8).
+This chapter describes how to extend the user schema used by {{slapd}}(8).
 The first section, {{SECT:Distributed Schema Files}} details optional
 schema definitions provided in the distribution and where to obtain
 other definitions.
@@ -31,7 +31,6 @@ core.schema           OpenLDAP {{core}} (required)
 cosine.schema          Cosine and Internet X.500 (useful)
 inetorgperson.schema   InetOrgPerson (useful)
 misc.schema            Assorted (experimental)
-nadf.schema            North American Directory Forum (FYI)
 nis.schema             Network Information Services (FYI)
 openldap.schema                OpenLDAP Project (experimental)
 !endblock
@@ -51,15 +50,16 @@ FAQ ({{URL:http://www.openldap.org/faq/}}).
 Note: You should not modify any of the schema items defined
 in provided files.
 
+
 H2: Extending Schema
 
 Schema used by {{slapd}}(8) may be extended to support additional
-syntaxes, matching rules, attribute types, and object classes.
-This chapter details how to add attribute types and object classes
-using the syntaxes and matching rules already supported by slapd.
-slapd can also be extended to support additional syntaxes
-and matching rules, but this requires some programming and hence
-is not discussed here.
+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.
 
 There are five steps to defining new schema:
 ^      obtain Object Identifer
@@ -68,6 +68,7 @@ There are five steps to defining new schema:
 +      define custom attribute types (if necessary)
 +      define custom object classes
 
+
 H3: Object Identifiers
 
 Each schema element is identified by a globally unique
@@ -95,22 +96,22 @@ OID         Assignment
 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
+assignments you make.  This can be a simple flat file or
 something more sophisticated such as the {{OpenLDAP OID Registry}}
 ({{URL:http://www.openldap.org/faq/index.cgi?file=197}}).
 
 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!}} 
+.{{Under no circumstances should you use a fictitious OID!}} 
 
 To obtain a fully registered OID at {{no cost}}, apply for
-an OID under {{ORG[expand]IANA}} (IANA) maintained
+an OID under the {{ORG[expand]IANA}} (IANA) maintained
 {{Private Enterprise}} arch.  Any private enterprise (organization)
 may request an OID to be assigned under this arch.  Just fill
 out the {{ORG:IANA}} form at {{URL: http://www.iana.org/cgi-bin/enterprise.pl}}
 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}}
+Your base OID will be something like {{EX:1.3.6.1.4.1.X}} where {{EX:X}}
 is an integer.
 
 Note: Don't let the "MIB/SNMP" statement on the IANA page confuse you.
@@ -133,7 +134,7 @@ a few letters to localize the changes to your organization.
 The smaller the organization, the longer your prefix should
 be.
 
-In the examples below, we have choosen a short prefix '{{EX:my}}'
+In the examples below, we have chosen a short prefix '{{EX:my}}'
 (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
@@ -196,9 +197,9 @@ where Attribute Type Description is defined by the following
 >
 
 where whsp is a space ('{{EX: }}'), numericoid is a globally unique
-OID in dotted-decimal form (e.g. {{EX:1.2.3}}), qdescrs is one or
+OID in dotted-decimal form (e.g. {{EX:1.1.0}}), qdescrs is one or
 more names, woid is either the name or OID optionally followed
-length specifier (e.g {{EX:{10}}}).
+by a length specifier (e.g {{EX:{10}}}).
 
 For example, the attribute types {{EX:name}} and {{EX:cn}} are defined
 in {{F:core.schema}} as:
@@ -217,9 +218,9 @@ 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
+(UTF-8 encoded Unicode) syntax.  The syntax is specified by OID
 (1.3.6.1.4.1.1466.115.121.1.15 identifies the directoryString
-syntax).  An length recommendation of 32768 is specified.  Servers
+syntax).  A length recommendation of 32768 is specified.  Servers
 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
@@ -230,7 +231,6 @@ matching rules (OpenLDAP supports these and many more).
 !block table; align=Center; coltags="EX,EX,N"; \
        title="Table 6.3: Commonly Used Syntaxes"
 Name                   OID                             Description
-binary                 1.3.6.1.4.1.1466.115.121.1.5    BER/DER data
 boolean                        1.3.6.1.4.1.1466.115.121.1.7    boolean value
 distinguishedName      1.3.6.1.4.1.1466.115.121.1.12   DN
 directoryString                1.3.6.1.4.1.1466.115.121.1.15   UTF-8 string
@@ -249,9 +249,10 @@ Printable String   1.3.6.1.4.1.1466.115.121.1.44   printable string
        title="Table 6.4: Commonly Used Matching Rules"
 Name                           Type            Description
 booleanMatch                   equality        boolean
+octetStringMatch               equality        octet string
 objectIdentiferMatch           equality        OID
 distinguishedNameMatch         equality        DN
-uniqueMemberMatch              equality        DN with optional UID
+uniqueMemberMatch              equality        Name with optional UID
 numericStringMatch             equality        numerical
 numericStringOrderingMatch     ordering        numerical
 numericStringSubstringsMatch   substrings      numerical
@@ -319,9 +320,9 @@ syntax can be defined, e.g.:
 >              SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
 >              SINGLE-VALUE )
 
-As noted in the description, LDAP has no knowledge of the
-format of the photo.  It's assumed that all applications
-accessing this attribute agree on the handling of values.
+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.
 
 If you wanted to support multiple photo formats, you could define
 a separate attribute type for each format, prefix the photo
@@ -330,7 +331,12 @@ with some typing information, or describe the value using
 
 Another alternative is for the attribute to hold a {{TERM:URI}}
 pointing to the photo.  You can model such an attribute after
-{{EX:labeledURI}} ({{REF:RFC2079}}).
+{{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 )
 
 
 H3: Object Class Specification
@@ -358,7 +364,7 @@ where Object Class Description is defined by the following
 >              whsp ")"
 
 where whsp is a space ('{{EX: }}'), numericoid is a globally unique
-OID in numeric form (e.g. {{EX:1.2.3}}), qdescrs is one or more
+OID in numeric form (e.g. {{EX:1.1.0}}), qdescrs is one or more
 names, and oids is one or more names and/or OIDs.
 
 
@@ -384,8 +390,8 @@ you desire.
 >      objectclass ( 1.1.2.2.2 NAME 'myPerson'
 >              DESC 'my person'
 >              SUP inetOrgPerson
->              MUST ( 'myUniqueName' $ 'givenName' )
->              MAY 'myPhoto' )
+>              MUST ( myUniqueName $ givenName )
+>              MAY myPhoto )
 
 The object class inherits the required/allowed attribute
 types of {{EX:inetOrgPerson}} but requires {{EX:myUniqueName}}
@@ -424,7 +430,7 @@ pairs.  The following is an abbreviated example:
 >      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
->       OrgPerson MUST ( 'myUniqueName' $ 'givenName' ) MAY 'myPhoto' )
+>       OrgPerson MUST ( myUniqueName $ givenName ) MAY myPhoto )
 
 Capture the output of the search in a file and then edit the file:
 
@@ -450,9 +456,37 @@ result in a file with contains of:
 >      objectClass ( 1.1.2.2.2 NAME 'myPerson'
 >              DESC 'my person'
 >              SUP inetOrgPerson
->              MUST ( 'myUniqueName' $ 'givenName' )
->              MAY 'myPhoto' )
+>              MUST ( myUniqueName $ givenName )
+>              MAY myPhoto )
 
 Save in an appropriately named file (e.g. {{F:my.schema}}).
-You may now include this file in your {{slapd.conf}}(8) file.
+You may now include this file in your {{slapd.conf}}(5) file.
 !endif
+
+
+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 myOID:1
+>      objectIdentifier myLDAP myOID:2
+>      objectIdentifier myAttributeType        myLDAP:1
+>      objectIdentifier myObjectClass  myLDAP: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 )
+