Information about http://www.openldap.org/pub/umich/ldap.pdf
CITI Technical Report 958 …
Tags: access method, authentication framework, client library, data representation, defi, directory access protocol, directory ldap, directory service, func, functional model, information model, information technology integration, ldap clients, ldap server, lightweight directory access protocol, namespace, osi directory, protocol elements, timothy a howes, umich edu,Pages: 11
Language: english
Created: Sat Dec 13 23:00:08 2003
Display cached document
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
CITI Technical Report 958
The Lightweight Directory Access Protocol:
X.500 Lite
Timothy A. Howes
tim@umich.edu
ABSTRACT
This paper describes the Lightweight Directory Access Protocol (LDAP), which provides
low-overhead access to the X.500 directory. LDAP includes a subset of full X.500 func-
tionality. It runs directly over TCP and uses a simplified data representation for many
protocol elements. These simplifications make LDAP clients smaller, faster, and easier to
implement than full X.500 clients. Our freely available implementation of the protocol is
also described. It includes an LDAP server and a client library that makes writing LDAP
programs much easier.
July 27, 1995
Center for Information Technology Integration
University of Michigan
519 West William Street
Ann Arbor, MI 48103-4943
The Lightweight Directory
Access Protocol: X.500 Lite
Timothy A. Howes
July 27, 1995
1. Introduction emulating some operations with others.
LDAP uses simple string encodings for most
X.500, the OSI directory standard [1], defines attributes. The result is a low-overhead
a comprehensive directory service, includ- access method for the X.500 directory, suit-
ing an information model, a namespace, a able for use on virtually any platform.
functional model, and an authentication
framework. X.500 also defines the Directory Section 2 of this paper gives a quick intro-
Access Protocol (DAP) used by clients to duction to X.500. Section 3 gives an
access the directory. DAP is a full OSI proto- overview of LDAP, describing the simplifi-
col that contains extensive functionality, cations it makes to X.500. Section 4 summa-
much of which is not used by most applica- rizes the key advantages of the LDAP
tions. protocol. Section 5 briefly describes our
implementation of LDAP, including our
DAP is significantly more complicated than server and client library. Section 6 compares
the more prevalent TCP/IP stack implemen- the performance of DAP and LDAP. Finally,
tations and requires more code and comput- Section 7 describes some work we are doing
ing horsepower to run. The size and that builds on LDAP.
complexity of DAP make it difficult to run
on smaller machines such as the PC and
Macintosh where TCP/IP functionality often 2. Overview of X.500
comes bundled with the machine. When the
DAP stack implementations are used, they X.500 is the OSI directory service. X.500
typically require an involved customization defines the following components:
process, which has limited the acceptance of
· An information model--determines the
X.500.
form and character of information in the
directory.
The Lightweight Directory Access Protocol
(LDAP) was designed to remove some of · A namespace--allows the information to
the burden of X.500 access from directory be referenced and organized.
clients, making the directory available to a · A functional model--determines what
wider variety of machines and applications. operations can be performed on the infor-
Building on similar ideas in the DAS [7] and mation.
DIXIE [4] protocols, LDAP runs directly
over TCP/IP or other reliable transport. As · An authentication framework--allows
we shall see, it simplifies many X.500 opera- information in the directory to be secured.
tions, leaving out little-used features and
Center for Information Technology Integration 1
Howes
· A distributed operation model--deter- authenticate. In the first category, the read
mines how data is distributed and how operation retrieves the attributes of an entry
operations are carried out. whose name is known. The list operation
The information model is centered around enumerates the children of a given entry.
entries, which are composed of attributes. The search operation selects entries from a
Each attribute has a type and one or more defined area of the tree based on some selec-
values. The type determines the attribute's tion criteria known as a search filter. For
syntax, which defines what kind of informa- each matching entry, a requested set of attri-
tion is allowed in the values. butes (with or without values) is returned.
The searched entries can span a single entry,
Which attributes are required and allowed an entry's children, or an entire subtree.
in an entry are controlled by a special Alias entries can be followed automatically
objectClass attribute in every entry. The val- during a search, even if they cross server
ues of this attribute identify the type of boundaries.
entry (e.g., person, organization, etc.). The
type of entry determines which attributes In the second category, X.500 defines four
are required, and which are optional. For operations for modifying the directory. The
example, the object class person requires the modify operation is used to change existing
surname and commonName attributes, but entries. It allows attributes and values to be
description, seeAlso, and others are optional. added and deleted. The add and delete oper-
ations are used to insert and remove entries
Entries are arranged in a tree structure and from the directory. The modify RDN opera-
divided among servers in a geographical tion is used to change the name of an entry.
and organizational distribution. Entries are
named according to their position in this The final category defines a bind operation,
hierarchy by a distinguished name (DN). allowing a client to initiate a session and
Each component of the DN is called a rela- prove its identity to the directory. Several
tive distinguished name (RDN). Alias authentication methods are supported, from
entries, which point to other entries, are simple clear-text password to public key-
allowed, circumventing the hierarchy. Fig- based authentication. The unbind operation
ure 1 depicts the relationship between is used to terminate a directory session. An
entries, attributes, and values and shows abandon operation is also defined, allowing
how entries are arranged into a tree. an operation in progress to be canceled.
Each X.500 operation and result can be
signed to ensure its integrity. Signing is done
using the originating client's or server's
public key. The signed request or result is
carried end-to-end in the protocol, allowing
alias object
entry entry integrity to be checked at every step. This
Attr Attr ... guards against connection hijacking or mod-
ification by intermediate servers. Service con-
Type Value Value ... trols can be specified that determine
information such as how an operation will
Figure 1. X.500 information model. The X.500 model be carried out, whether aliases should be
is centered around entries composed of dereferenced, the maximum number of
attributes that have a type and one or more
values. Entries are organized in a tree struc- entries to return, and the maximum amount
ture. Alias entries can be used to build non- of time to spend on an operation.
hierarchical relationships.
Functionally, X.500 defines operations in In X.500, the directory is distributed among
three areas: search and read, modify, and many servers (called DSAs for Directory
Center for Information Technology Integration 2
The Lightweight Directory Access Protocol: X.500 Lite
System Agent). No matter which server a The time and size limit service controls are
client connects to, it sees the same view of included directly in the search request.
the directory. If a server is unable to answer (They are not included with the other opera-
a client's request, it can either chain the tions.) The searchAliases search control and
request to another server, or refer the client dereferenceAliases service control are com-
to the server. bined in a single derefAliases parameter in
the LDAP search. The ASN.1 [11] definition
of the LDAP search request is shown in Fig-
3. Overview of LDAP ure 3.
SearchRequest ::= [APPLICATION 3] SEQUENCE {
LDAP assumes the same information model baseObject LDAPDN,
and namespace as X.500. It is also client- scope ENUMERATED {
baseObject (0),
server based, with one important difference: singleLevel (1),
there are no referrals returned in LDAP. An wholeSubtree (2)
},
LDAP server must return only results or derefAliasesENUMERATED {
errors to a client. If referrals are involved, neverDerefAliases (0),
derefInSearching (1),
the LDAP server is responsible for chasing derefFindingBaseObj (2),
them down. This model is depicted in Fig- alwaysDerefAliases (3)
},
ure 2, though the intermediate server shown sizeLimit INTEGER (0 .. MaxInt),
is not required (i.e., an implementation timeLimit INTEGER (0 .. MaxInt),
attrsOnly BOOLEAN,
could choose to have its DSA speak "native" filter Filter,
LDAP). attributes SEQUENCE OF AttributeType
}
Filter ::= CHOICE {
X.500 and [0] SET OF Filter,
DSA or [1] SET OF Filter,
not [2] Filter,
t
equalityMatch [3] AttributeValueAssertion,
es
al
qu
rr
substrings [4] SubstringFilter,
fe
re
greaterOrEqual [5] AttributeValueAssertion,
re
lessOrEqual [6] AttributeValueAssertion,
LDAP LDAP chain present [7] AttributeType,
Client Server approxMatch [8] AttributeValueAssertion
}
re
Figure 3. ASN.1 for the LDAP search operation. The
re
su
LDAP search operation offers similar func-
qu
lt
es
tionality to DAP search. It combines search
t
parameters and service controls and simpli-
X.500 fies the filter encoding.
DSA
The LDAPDN and AttributeType components
of the search are encoded as simple charac-
Figure 2. Relationship between LDAP and X.500.
The LDAP client-server model includes an ter strings using the formats defined in RFC
LDAP server translating LDAP requests into 1779 [5] and RFC 1778 [2], respectively,
X.500 requests, chasing X.500 referrals, and
returning results to the client. rather than the highly structured encoding
used by X.500. Similarly, the value in an
The LDAP functional model is a subset of AttributeValueAssertion is encoded as a prim-
the X.500 model. LDAP supports the follow- itive OCTETSTRING, not a more structured
ing operations: search, add, delete, modify, ASN.1 type. The structure is reflected in the
modify RDN, bind, unbind, and abandon. syntax of the encoded string, not in the
The search operation is similar to its DAP encoding itself.
counterpart. A base object and scope are
specified, determining which portion of the The results of an LDAP search are sent back
tree to search. A filter specifies the entries to the client one at a time, in separate search-
within the scope to select. The LDAP search Entry packets. This sequence of entries is ter-
filter offers the same functionality as the one minated by a final searchResult packet that
in DAP but is encoded in a simpler form. contains the result of the search (e.g., suc-
Center for Information Technology Integration 3
Howes
cess, a size or time limit was exceeded, etc.). The LDAP bind operation supports a subset
Having a final terminator packet allows cli- of X.500 bind functionality. It allows only
ents and servers to stream results more eas- simple authentication, consisting of a clear-
ily, handling one entry at a time. This is text password, and Kerberos version 4
especially useful in memory-constrained authentication [6], which translates into an
environments where holding the collection X.500 external authentication method. The
of all entries from a large search is not possi- LDAP bind operation includes a choice of
ble. credentials, allowing for future expansion of
available authentication methods.
The X.500 list and read operations are not
included in LDAP. Instead, they are emu- The DAP unbind, abandon, modify RDN,
lated with the LDAP search operation. Read add and delete operations are virtually
is emulated by a base object search of the identical to their DAP counterparts.
entry to read, with a filter testing for the
existence of the objectClass attribute. Every
entry is required to have an object class and 4. Key Advantages
must match this filter. List is emulated by a
one level search of the entry to list, also with LDAP has four key advantages over DAP.
a filter testing for the existence of the object- First, it runs directly over TCP (or other reli-
Class attribute. If the ability to distinguish able transport, in theory), eliminating much
alias children from other children (a feature of the connection set-up and packet-han-
provided by X.500 list) is desired, the object- dling overhead of the OSI session and pre-
Class attribute can be retrieved and exam- sentation layers required by DAP. In
ined for a value of alias. addition, the near universal availability of
TCP/IP implementations means that LDAP
The LDAP modify operation also differs can run on most systems "out of the box."
slightly from its DAP counterpart. In DAP,
four kinds of changes can be made: entire Second, LDAP simplifies the X.500 func-
attributes can be added or deleted; individ- tional model in two ways. It leaves out the
ual values can be added or deleted. These read and list operations, emulating them via
capabilities require a client to read an entry the search operation. It also leaves out some
before attempting a modify (e.g., when add- of the more esoteric and less-often-used ser-
ing a value, to discover whether an add vice controls and security features of full
attribute or add value is required). X.500 (e.g., the ability to sign operations).
This simplifies LDAP implementations.
In LDAP, we simplified the semantics of
modify by supporting three operations: add Third, though X.500 and LDAP both
values; delete values; and replace values. If a describe and encode protocol elements
request is made to add values to an attribute using ASN.1 and BER [12], LDAP uses
that does not exist in the entry, the attribute string encodings for distinguished names
is created automatically. If a request is made and data elements. X.500 uses a complex
to delete the last value of an attribute, the and highly-structured encoding even for
entire attribute is deleted. An attribute can simple data elements; LDAP data elements
also be deleted by specifying a delete values are string types. This encoding is a big win
operation without specifying any values. for distinguished names, which have con-
Finally, the replace values construct is used to siderable structure leading to encoding/
make an attribute contain the given values decoding complexity and size. LDAP rele-
after the modify. The LDAP server takes gates the knowledge of a value's syntax to
care of translating the replace request into the application program rather than lower-
the necessary sequence of modify, add, and level protocol routines.
delete operations required by X.500.
Center for Information Technology Integration 4
The Lightweight Directory Access Protocol: X.500 Lite
Finally, LDAP frees clients from the burden Key to the success of our LDAP implemen-
of chasing referrals. The LDAP server is tation has been libldap, the LDAP client
responsible for chasing down any referrals library. The libldap library gives program-
returned by X.500, returning either results or mers a simple yet powerful C Language API
errors to the client. Clients assume a single for accessing the X.500 directory through
connection model in which X.500 appears as LDAP. The library is self-contained, includ-
a single logical directory. ing the necessary ASN.1/BER routines for
producing and reading LDAP protocol ele-
ments. It contains routines to begin and end
5. Implementation sessions with the directory, perform searches
and other operations, and parse and display
In setting out to implement LDAP we had the results obtained from the directory. Fig-
three goals in mind: ure 4 is a C code fragment showing a simple
use of libldap. It illustrates the synchronous
· provide a freely available reference interface provided by libldap. Asynchronous
implementation of the protocol; routines are also provided.
· enable the development of LDAP clients
#include
on a wide variety of platforms; and LDAP *ld;
LDAPMessage *e, *r;
· solve the problem of providing access to char *a, *dn;
our campus X.500 directory. /* open a connection and authenticate */
if ((ld = ldap_open("hostname", LDAP_PORT))
In addition, we have found our implementa- == NULL)
fail();
tion has been incorporated into a number of if (ldap_simple_bind_s(ld, NULL, NULL) !=
vendor offerings, increasing the availability LDAP_SUCCESS)
fail();
of LDAP products. /* search for entries, return all attrs */
if (ldap_search_s(ld, "c=US", LDAP_SCOPE_ONELEVEL,
"o=*michigan*", NULL, 0, &r) != LDAP_SUCCESS)
Our LDAP implementation has three main fail();
components: a server, a client library, and /* step through each entry returned */
for (e = ldap_first_entry(ld, r); e != NULL;
various clients. Our LDAP server, ldapd, is e = ldap_next_entry(ld, e)) {
based on the popular ISO Development /* get and print the entry name */
dn = ldap_getdn(ld, e);
Environment (ISODE) package. We use the printf("entry: %s\n", dn);
ISODE OSI stack implementation and DAP free(dn);
/* step through each attribute */
client library to access X.500. The ldapd for (a = ldap_first_attribute(ld, e);
server supports connections to multiple a != NULL;
a = ldap_next_attribute(ld, e, a)) {
X.500 servers, providing efficient handling printf("attr: %s\n", a);
of referrals. /* get and print vals */
v = ldap_get_values(ld, e, a);
for (i = 0; v[i] != NULL; i++) {
The ldapd server can be run as a UNIX printf("val: %s\n", v[i]);
stand-alone daemon or from inetd, the UNIX }
ldap_value_free(v);
Internet protocol daemon. It accepts connec- }
tions from LDAP clients, forking off a copy }
Figure 4. Sample libldap code. This code fragment
of itself to handle each connection. It also searches for and retrieves entries from the
supports connectionless LDAP (CLDAP) directory. The entries are then stepped
through and each value of each attribute is
[10], a version of LDAP that runs over UDP printed. If the attribute names retrieved are
or other connectionless transport. CLDAP is known, ldap_get_values() can be called
with the names directly.
useful in applications where speed is para-
mount, the information desired is small, and In addition to the basic operations shown in
the connection setup overhead of LDAP is Figure 4, libldap contains routines to assist
too large. LDAP application developers in a variety of
ways. There are display template routines
which provide a standardized way of dis-
Center for Information Technology Integration 5
Howes
playing entries. The display format is gov- used for all query measurements, providing
erned by a configuration file that tells which a baseline for comparison.
attributes to display for entries of a particu-
lar object class and how to display them. By Table 1 shows the performance of a range of
using these routines, no code changes are typical DAP and LDAP queries. The tests
necessary for an application to change how were conducted on a dedicated machine
entries are displayed, add a new attribute to running the DAP and LDAP clients, the
the display, etc. LDAP server, and the DSA. As can be seen
in the table, the delay introduced by LDAP
Also provided are routines to assist in the is minimal. This delay could be eliminated
construction of search filters. Often, differ- altogether by a native DSA implementation,
ent filters need to be constructed based on eliminating the intermediate encoding,
user input. For example, in a simple look-up decoding, and protocol translation.
application if a user types in a number, one
might want to perform a search for entries Table 1. Comparison of DAP and LDAP query times.
with a phone number (home, work, fax, or Searches were performed using the same
pager) matching all or part of the number. If DSA, with a "hot" cache of entries. Times
an alphabetic string is input, a search by are in milliseconds.
name is more appropriate. If an exact match
Query DAP LDAP
search yields no results, a less restrictive
approximate search might be tried. The get Unauthenticated bind 30 68
filter routines automate the process of creat- Authenticated bind 34 56
ing these filters. The filters produced are Simple search (one entry) 32 41
specified in a configuration file via regular Simple search (50 entries) 293 353
expressions that are matched against user
input. Table 2 shows the size of the queries and
results given in Table 1. It shows that LDAP
Many LDAP client applications have been queries are substantially smaller than equiv-
developed by us and others on the Internet. alent DAP queries. The savings are due pri-
Some of the more interesting applications marily to the simplified DN and value
include maX.500, waX.500 and xax500, GUI encodings. Query sizes are also reduced by
clients for the Macintosh, MS Windows, and the absence of service controls in every
X Windows, respectively; go500gw, a gopher operation.
to X.500 gateway; web500gw, a World Wide
Web to X.500 gateway; and mail500 and Table 2. Comparison of DAP and LDAP query sizes.
fax500, RFC 822-based X.500-capable mail- LDAP queries are significantly smaller
ers. Work is ongoing on other applications than their DAP counterparts. Query sizes
as well. are in bytes.
Query DAP LDAP
6. Performance Unauthenticated bind 192 14
Authenticated bind 409 138
The performance of LDAP is satisfactory for Simple search request 237 105
most applications. In this section, we com- Single search result 547 355
pare the performance of DAP and LDAP in
four areas: response time to queries; the size Tables 3 and 4 show the time to decode and
of queries; PDU encoding speed; and the encode a range of typical DAP and LDAP
size and complexity of client-side imple- PDUs. They show that LDAP has a modest
mentations. For these comparisons, we used performance advantage for simple PDUs
our LDAP implementation and the ISODE and a substantial advantage for complex
DAP implementation. The same DSA was PDUs, especially those containing many dis-
Center for Information Technology Integration 6
The Lightweight Directory Access Protocol: X.500 Lite
tinguished names where the LDAP string Table 5. Comparison of DAP and LDAP implemen-
representation is a big win. tation complexity. The DE client, which can
be built using either DAP or LDAP, is used
Table 3. Comparison of DAP and LDAP decoding to compare implementation size. Semi-
times. LDAP protocol elements are easier colon count, which approximates the num-
to decode, especially for complex PDUs. ber of statements, and "if" statement count,
The complex PDU contained an attribute which approximates the number of code
with over 600 DNs. About half of the DAP paths are another measure of complexity.
decoding time was spent in a duplicate The comparison was between ISODE-8.0
check, to ensure that an attribute has only and our LDAP implementation.
one of each value.
Metric DAP LDAP
PDU Complexity DAP LDAP
Total size (DE) 1,484,568 334,552
Simple 550 110 Text 958,464 221,184
Medium 7,925 714 Data 385,024 73,728
Complex 38,393 2,702 BSS 141,080 39,640
Semicolon count 46,746 1,989
Table 4. Comparison of DAP and LDAP encoding If count 9369 568
times. LDAP protocol elements are
encoded more efficiently, especially for
complex PDUs.
7. Future Work
PDU Complexity DAP LDAP
LDAP has succeeded in making X.500 more
Simple 24 6 accessible and is largely responsible for a
Medium 1,084 324 substantial increase in X.500 client develop-
Complex 2656 989 ment. Despite this success, X.500 deploy-
ment on the Internet remains disappointing.
Finally, we compare implementation size One reason for this is the heavyweight
and code complexity). Such a comparison is nature of X.500 servers; to take advantage of
anecdotal at best, given the wide range of the proliferation of LDAP clients to access
programmer skills and goals used in pro- local data, a site must first bring up a full
ducing the implementations. However, X.500 service. To address this problem we
some conclusions favorable to LDAP can be are developing a stand-alone LDAP server
drawn from the overwhelming advantage it called slapd. Slapd exports the same LDAP
has in this area, as shown in Table 5. functionality described above but is back-
ended by its own local database, not by
The Directory Enquiries client was chosen X.500.
for the size comparison. It can be compiled
to use either DAP or LDAP for X.500 com- To prevent stand-alone LDAP servers from
munication. The code complexity of the being isolated from the rest of the X.500
ISODE DAP and our LDAP client libraries world, we have made a compatible exten-
were also compared. We used two complex- sion to LDAP that allows the return of refer-
ity measures. The first, a count of the num- rals to the client. This adds some complexity
ber of semi-colons, approximates the on the client side to follow the referrals, but
number of statements. The second, a count in return we gain simplicity in the server.
of the number of "if" statements, approxi-
mates the number of code paths. In comput- The 1993 version of the X.500 standard
ing both of these metrics, an effort was includes many features missing from 1988
made to include only those portions of code X.500, on which LDAP is based. Among the
required to access X.500. new features are access control, replication,
schema management, and various DAP
Center for Information Technology Integration 7
Howes
extensions. A new version of LDAP is under 9. Acknowledgements
development by the Internet Engineering
Task Force that will incorporate some of This material is based upon work supported
these features, as well as address some secu- by the National Science Foundation under
rity concerns with the present version of Grant No. NCR-9416667. LDAP was devel-
LDAP, such as its lack of strong authentica- oped in collaboration with Steve Kille,
tion and integrity insurance capability. Wengyik Yeong, and Colin Robbins, along
with help from members of the Internet
The DAP extensions include the ability to Engineering Task Force. My colleague Mark
retrieve search results a "page" at a time, C. Smith deserves much of the credit for the
specify a byte limit on the size of an LDAP implementation described in this
attribute to return, treat the attributes of a paper. Many thanks also to Peter Honey-
DN as part of the entry during a search, and man for his ever-valuable review.
more. The security features being consid-
ered include strong (public key-based)
authentication, and signing of operations.
References
Finally, with the growing popularity of the
World Wide Web, we see interesting and 1. "The Directory: Overview of Concepts, Mod-
exciting possibilities for merging the two els and Service," CCITT Recommendation
X.500, 1988.
technologies. Work has already begun on
defining a URL format for LDAP [3], and a 2. T. Howes, S. Kille, W. Yeong, and C. Rob-
URL-valued attribute for X.500 [8]. bins, "The String Representation of Standard
Attribute Syntaxes," RFC 1778, March 1995.
3. T. Howes and M. Smith, "An LDAP URL
8. Summary Format," Internet Draft draft-ietf-asid-dap-
format-00.txt, March 1995.
The Lightweight Directory Access Protocol
4. T. Howes, M. Smith and B. Beecher. "DIXIE
provides a low-overhead method of access- Protocol Specification," RFC 1249, August
ing the X.500 directory. It runs directly over 1991.
TCP, and makes several simplifications to
full X.500 DAP, leaving out many of the 5. S. Kille, "A String Representation of Distin-
lesser-used features. LDAP uses primitive guished Names," RFC 1779, March 1995.
string encodings for most data elements, 6. S.P. Miller, B.C. Neuman, J.I. Schiller, and
making it more efficient and easier to imple- J.H. Saltzer, "Kerberos Authentication and
ment than DAP. We have developed a freely Authorization System," MIT Project Athena
available reference implementation of LDAP Documentation Section E.2.1, December
which has been ported to several platforms, 1987.
including UNIX, VMS, PC, and Macintosh. 7. M. Rose, "Directory Assistance Service,"
Our intermediate-server-based implementa- RFC 1202, February 1991.
tion introduces little delay over full DAP,
produces smaller protocol exchanges, and 8. M. Smith, "Definition of an X.500 Attribute
results in smaller and less complex clients. Type and Object Class to Hold Uniform
Resource Identifiers (URIs)," Internet Draft
Our implementation is freely available:
draft-ietf-asid-x500-url-01.txt, March 1995.
ftp://terminator.rs.itd.umich.edu/ldap/
ldap.tar.Z 9. W. Yeong, T. Howes, and S. Kille, "Light-
weight Directory Access Protocol," RFC
There is also an LDAP discussion list join- 1777, March 1995.
able by sending email to:
10. A. Young, "Connectionless Lightweight
ldap-request@umich.edu
Directory Access Protocol," Internet Draft
draft-ietf-osids-cldap-02.txt, April 1995.
Center for Information Technology Integration 8
The Lightweight Directory Access Protocol: X.500 Lite
11. Specification of Abstract Syntax Notation
One (ASN.1), CCITT Recommendation
X.208, 1988.
12. Specification of Basic Encoding Rules for
Abstract Syntax Notation One (ASN.1),
CCITT Recommendation X.209, 1988.
Author Information
Tim Howes is a Senior Systems Research
Programmer for the University of Michi-
gan's Information Technology Division. He
received a B.S.E. in Aerospace Engineering,
a M.S.E. in Computer Engineering from
U-M, and is completing a Ph.D. in Com-
puter Science. He is currently project direc-
tor and principal investigator for the NSF-
sponsored WINX project, and in charge of
directory service development and deploy-
ment at U-M. He is the primary architect
and implementor of the U-M LDAP direc-
tory package, the DIXIE system, the GDA
X.500 DSA, and a major developer of the
QUIPU X.500 implementation. He is author
or co-author of several papers and RFCs,
including RFC 1777 and RFC 1778 defining
the LDAP protocol. He is chair of the IETF
Access, Searching, and Indexing of Directo-
ries working group, and an active member
of the ACM and IEEE.
Center for Information Technology Integration 9