Selecting Consistent Data Formats31to the directory entry. Attempting to add an attribute to an entry that is neither required nor allowedaccording to the entry's object class definition causes the Directory Server to return an object classviolation message.For example, if an entry is defined to use the organizationalPerson object class, then thecommon name (cn) and surname (sn) attributes are required for the entry. That is, values for theseattributes must be set when the entry is created. In addition, there is a long list of attributes thatcan optionally be used on the entry, including descriptive attributes like telephoneNumber, uid,streetAddress, and userPassword.3.5.2. Selecting Consistent Data FormatsLDAP schema allows any data to be placed on any attribute value. However, it is important to storedata consistently in the directory tree by selecting a format appropriate for the LDAP client applicationsand directory users.With the LDAP protocol and Directory Server, data must be represented in the data formats specifiedin RFC 2252. For example, the correct LDAP format for telephone numbers is defined in two ITU-Trecommendations 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. Forexample, 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 asfollows:postalAddress: 1206 Directory Drive$Pleasant View, MN$34200Attributes can require strings, binary input, integers, and other formats. The allowed format is set in theschema definition for the attribute.3.5.3. Maintaining Consistency in Replicated SchemaWhen 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 consistencyin replicated schema allows replication to continue smoothly. Consider the following points formaintaining 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 causesreplication 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 thesupplier replica but has a different syntax from the attribute on the supplier, replication will fail.3.6. Other Schema ResourcesSee the following links for more information about standard LDAPv3 schema:
