LDAP.com
Enabling Identity Interoperability™

 

Home

Specifications

Schema

Commentary

Mark Wahl

Web Design by
Kristen Lanum

Evolution of schema formats

• X.500(1988)

  The 1988 publication of X.500 was the first attempt at forming a standard definition for white pages attributes and object classes, using a format similar to that of X.400.

  This example from RFC 1274 illustrates an attribute and an object class definition:

       manager ATTRIBUTE
           WITH ATTRIBUTE-SYNTAX
               distinguishedNameSyntax
       ::= {pilotAttributeType 10}
  
       pilotObject OBJECT-CLASS
           SUBCLASS OF top
           MAY CONTAIN {
               info, photo, manager, uniqueIdentifier,
               lastModifiedTime, lastModifiedBy,
               dITRedirect, audio}
       ::= {pilotObjectClass 3}
  

• X.500(1993)

  The next release of X.500 switched to a different ASN.1 representation format, as shown in X.520(2001) and X.521(2001):

       streetAddress ATTRIBUTE ::= {
         WITH SYNTAX               DirectoryString {ub-street-address}
         EQUALITY MATCHING RULE    caseIgnoreMatch
         SUBSTRINGS MATCHING RULE  caseIgnoreSubstringsMatch
         ID                        id-at-streetAddress
       }
  
       device OBJECT-CLASS ::= {
         SUBCLASS OF   {top}
         MUST CONTAIN  {commonName}
         MAY CONTAIN
           {description | localityName | organizationName | organizationalUnitName |
             owner | seeAlso | serialNumber}
         ID            id-oc-device
       }
  
       orgPersonNameForm NAME-FORM ::= {
         NAMES            organizationalPerson
         WITH ATTRIBUTES  {commonName}
         AND OPTIONALLY   {organizationalUnitName}
         ID               id-nf-orgPersonNameForm
       }
  

• U-M LDAP

  The University of Michigan LDAPv2 server SLAPD stored its schema in a configuration file, which used a simple string representation of attribute and object class definitions:

      attribute fax tel
  
      objectclass myperson
       requires cn, sn, objectclass
       allows mail, phone, fax
  

• LDAPv3

  For LDAP version 3 clients and servers, RFC 2252 defines a one-line string representation for schema elements, derived from that of X.500(1993). Typically this schema is represented in files using LDIF, and a MIME profile for transferring these schemas in email was also published in RFC 2927 but not widely adopted.

       attributeTypes: ( 2.5.4.9 NAME 'street' EQUALITY caseIgnoreMatch
        SUBSTR caseIgnoreSubstringsMatch
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{128} )
  
       objectClasses: ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn )
        MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
  

• DSML

  The Directory Service Markup Language Version 1 experimented with a XML encoding of the LDAP schema:

  
  <dsml:attribute-type id="mail">
    <dsml:name>mail</dsml:name>
    <dsml:object-identifier>0.9.2342.19200300.100.1.3</dsml:object-identifier>
    <dsml:syntax bound="256">0.9.2342.19200300.100.3.5</dsml:syntax>
  
  </dsml:attribute-type>
  
  <dsml:class
      id="person"
      superior="#top"
      type="structural">
    <dsml:name>person</dsml:name>
    <dsml:object-identifier>2.5.6.6</object-indentifier>
    <dsml:attribute ref="#sn" required="true"/>
    <dsml:attribute ref="#cn" required="true"/>
    <dsml:attribute ref="#userPassword" required="false"/>
    <dsml:attribute ref="#telephoneNumber" required="false"/>
    <dsml:attribute ref="#seeAlso" required="false"/>
    <dsml:attribute ref="#description" required="false"/>
  
  </dsml:class>
  

• DTD

  Many protocols have a fixed set of attribute definitions permissible, and so can map the attributes into elements of an XML document type definition.

  For example vCard defines its attributes as FN, N, NICKNAME, PHOTO, BDAY, ADR, LABEL, TEL, EMAIL, MAILER, TZ, GEO, TITLE, ROLE, LOGO, AGENT, ORG, CATEGORIES, NOTE, PRODID, REV, SORT-STRING, SOUND, URL, UID, VERSION, CLASS, KEY, and the Jabber XML representation of vCard defines the content as:

      <!ELEMENT vCard (
        (VERSION, FN, N),
        (NICKNAME?, PHOTO?, BDAY?, ADR?, LABEL?, TEL?, EMAIL?, JABBERID?, MAILER?, 
         TZ?, GEO?, TITLE?, ROLE?, LOGO?,AGENT?, ORG?, CATEGORIES?, NOTE?, PRODID?, 
         REV?, SORT-STRING?, SOUND?, UID?, URL?, CLASS?, KEY?, DESC? )*)>
  

• RDF

  Other modelling formats can be used to encode directory schemas, however at this time there is not yet a generic representation. Instead, each schema is encoded independently, as in the vCard representation in RDF, the Dublin Core representation in RDF, or FOAF:

      <foaf:Person>
        <foaf:name>Dan Brickley</foaf:name>
        <foaf:mbox_sha1sum>241021fb0e6289f92815fc210f9e9137262c252e</foaf:mbox_sha1sum>
        <foaf:homepage rdf:resource="http://rdfweb.org/people/danbri/" />
        <foaf:img rdf:resource="http://rdfweb.org/people/danbri/mugshot/danbri-small.jpeg" />
      </foaf:Person>
  

Continued at schema ontologies.