Classnotes | LDAP01 | RecentChanges | Preferences Showing revision 2 As we have seen the basic format for a given line in an LDIF file is defined by attributes and values separated by colons:
attribute: value
We have also seen that LDIFs allow for multivalued attributes using commas:
attribute: value1,value2,value3
So what possible attributes are there? The answer to this is "many", and the attribute definitions vary from purpose to purpose. Completely examining all possible attributes is beyond the scope of this course. However, over the next several days you will gain an understanding of attribute definitions and schema files (next section) such that you will be able to find the attributes for yourself.
So, in this section, we will simply be examining some of the more universal attributes as well as delving into their usage and syntax.
Attribute Syntax
An attribute type's definition lays the groundwork for the answers to questions like, "What type of values can be stored in this attribute?", "Can these two values be compared?", and, if so, "How should the comparison take place?"
Let's take a look at the telephoneNumber entry we just saw as an example. Suppose you search the directory for the person who ones the phone number 885-9162. This may seem easy when you first think about it, however RFC 2252 explains that a telephone number can contain characters other than digits (0-9) and a hyphen (-). By this definition, a telephone number can include:
a-z
A-Z
0-9
Various punctuation characters such as commas, periods, parentheses, hyphens, colons, question marks and spaces
Thus, 885.9162 or 885 9162 are correct matches for the search we've requested. Then, what about the area code, or extensions?
The solution to dilemas such as these are that attribute type definitions include matching rules that tell the LDAP server how to make comparisons. Taking a look at RFC 2256 for the entry for telephoneNumber (also on page 17 of the book) we find:
We can see that the attribute has two associated matching rules (specified by EQUALITY and SUBSTR). The telephoneNumberMatch rule is used for equality comparisons (this is both whitespace- and case-insenstive). Then, the telephoneNumberSubstringsMatch rule is used for partial telephone number matches.
Finally, the SYNTAX keyword specifies the object identifier (OID) of the encoding rules used for storing and transmitting values of the attribute type. The number enclosed by curly braces ({}) specifies the minimum recommended maximum length of the attribute's value that a server should support.
On Object Identifiers (OID)
An OID is a string of dotted numbers that uniquely identifies items such as attributes, syntaxes, object classes, etc (all of which we will see soon). OID assignments must be unique worldwide, so if you have a need to extend a given schema element, then you should not haphazardly create a new OID. Instead, you should go to http://www.iana.org/cgi-bin/enterprise.pl and request a private enterprise number. The form is short and normally takes one to two weeks to be processed. Once you have your own enterprise number, you can create your own OIDs without fear of them conflicting with existing OIDs. RFC 3383 describes some best practices for registering new LDAP values with IANA.
We will not be creating our own OIDs in this class, but there may be a time when you (or someone in your organization) may need to. So keep this in mind.
