Other Schema Resources - Red Hat DIRECTORY SERVER 8.1 - DEPLOYMENT Deployment Manual

to the directory entry. Attempting to add an attribute to an entry that is neither required nor allowed
according to the entry's object class definition causes the Directory Server to return an object class
violation message.
For example, if an entry is defined to use the organizationalPerson object class, then the
common name (cn) and surname (sn) attributes are required for the entry. That is, values for these
attributes must be set when the entry is created. In addition, there is a long list of attributes that
can optionally be used on the entry, including descriptive attributes like telephoneNumber, uid,
streetAddress, and userPassword.
3.5.2. Selecting Consistent Data Formats
LDAP schema allows any data to be placed on any attribute value. However, it is important to store
data consistently in the directory tree by selecting a format appropriate for the LDAP client applications
and directory users.
With the LDAP protocol and Directory Server, data must be represented in the data formats specified
in RFC 2252. For example, the correct LDAP format for telephone numbers is defined in two ITU-T
recommendations documents:
• ITU-T Recommendation E.123. Notation for national and international telephone numbers.
• ITU-T Recommendation E.163. Numbering plan for the international telephone services. For
example, a US phone number is formatted as +1 555 222 1717.
As another example, the postalAddress attribute expects an attribute value in the form of a multi-
line string that uses dollar signs ($) as line delimiters. A properly formatted directory entry appears as
follows:
postalAddress: 1206 Directory Drive$Pleasant View, MN$34200
Attributes can require strings, binary input, integers, and other formats. The allowed format is set in the
schema definition for the attribute.
3.5.3. Maintaining Consistency in Replicated Schema
When the directory schema is edited, the changes are recorded in the changelog. During replication,
the changelog is scanned for changes, and any changes are replicated. Maintaining consistency
in replicated schema allows replication to continue smoothly. Consider the following points for
maintaining consistent schema in a replicated environment:
• Do not modify the schema on a read-only replica.
Modifying the schema on a read-only replica introduces an inconsistency in the schema and causes
replication to fail.
• Do not create two attributes with the same name that use different syntaxes.
If an attribute is created in a read-write replica that has the same name as an attribute on the
supplier replica but has a different syntax from the attribute on the supplier, replication will fail.

3.6. Other Schema Resources

See the following links for more information about standard LDAPv3 schema:
Selecting Consistent Data Formats
31