DAG/IP LDAP v2/v3
110 Too many hits sizeLimitExceeded (4)
111 Requested constraint not supported constraintViolation (19)
112 Requested constraint not fullfilled constraintViolation (19)
200 Command Ok Success (0)
201 Command Completed successfully N.A.
203 Bye N.A.
204 Overgeneralized N.A.
220 Service Ready N.A.
226 Transaction complete N.A.
401 Service not available unavailable (52)
402 Search expression too complicated unwillingToPerform (53)
403 Information Unavailable busy (51)
404 Time out timeLimitExceeded (3)
405 Operations error operationsError (1)
500 Syntax error protocolError (2)
502 Search expression too complicated unwillingToPerform (53)
503 Query to general unwillingToPerform (53)
505 Operations error operationsError (1)
600 <token> N.A.
601 <token> N.A.
601 DEF N.A.
601 ANY N.A.
Table D.2 Mapping from DAG/IP response codes to LDAPv2/v3 resultcodes
110 Too Many hits 110 Too Many hits
111 Requested constraint not supported 111 Requested constraint not
112 Requested constraint not fullfilled 112 Requested constraint not
200 Command Ok 200 Command Ok
201 Command Completed successfully 201 Command Completed
401 Service not available 401 Service not available
403 Information Unavailable 403 Information not available
404 Timeout 404 Timeout
405 Operations error 405 Operations error
500 Syntax error 500 Syntax error
502 Search expression too complicated 502 Search expression too
503 Query to general 506 Query to general
505 Operations error 505 Operations error
Table D.3 Mapping between DAG/IP and Whois++ response codes
SPACE = <ASCII space, %x20>;
SEP = (CR LF) | LF
CR = <ASCII CR, carriage return, %x0D>;
LF = <ASCII LF, line feed, %x0A>;
DIGIT = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
UPPER = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
"I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
"Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
"Y" | "Z"
LOWER = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
"i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
"q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
"y" | "z"
US-ASCII-SAFE = %x01-09 / %x0B-0C / %x0E-7F
;; US-ASCII except CR, LF, NUL
UTF8 = US-ASCII-SAFE / UTF8-1 / UTF8-2 / UTF8-3
/ UTF8-4 / UTF8-5
UTF8-CONT = %x80-BF
UTF8-1 = %xC0-DF UTF8-CONT
UTF8-2 = %xE0-EF 2UTF8-CONT
UTF8-3 = %xF0-F7 3UTF8-CONT
UTF8-4 = %xF8-FB 4UTF8-CONT
UTF8-5 = %xFC-FD 5UTF8-CONT
N.B.: The only tokenization type permitted is "TOKEN". While the
Tagged Index Object memo permits the use of "FULL" (i.e., the entire
value of the attribute is preserved as a single token), that has the
danger of yielding a unique token for every record. Studies in the
growth of centroid sizes as a function of number of records (see
) demonstrate that such unique tokens (e.g., phone numbers) are
to be avoided. While storing tag information requires some number of
extra bytes of storage per token index entry, using unique tokens
causes the number of token entries in the index to continue to grow
linearly with the number of records, thereby affecting search
Note also that tags are to be applied to the data on a per entry
level. Thus, if two index lines in the same index object contain the
same tag, then it is always the case that those two lines refer back
to the same "record" in the directory. In LDAP terminology, the two
lines would refer back to the same directory object.
Additionally if two index lines in the same index object contain
different tags, then it is always the case that those two lines refer
back to different records in the directory.
The attribute "objectclass" is used to denote the record/object types
in the data summarized in this index object.
Values for the objectclass attribute should be restricted to:
dagperson or dagrole, the two DAG schema object types.
E.2 CIP Index Object Creation
WDSPs are expected to create index objects following the general
principles outlined in the Whois++ protocol documentation (creation
of centroids) and the Tagged Index Object documentation ().
Following the syntax described above, the index object contains token
information for each attribute in the DAGSchema:
- a list of all the unique tokens (strings delimited by the specified
characters) that appear in the WDSP database for the attribute
- for each token in that list, which records the token appears in
So, for example,
FN: Foo Bar
ORG: The Snack Bar
FN: Bar Smith
ORG: Snack Shack
yields (conceptually) the following information for the attribute FN:
Foo (1), Bar (1,2), Smith (2)
and the following information for the attribute ORG:
The (1), Snack (1, 2), Bar (1), Shack (2)
Note that the record numbers here are used simply as tags or virtual
record identifiers to indicate when 2 tokens appear in the same
record. The record identifiers are not used for any part of any
query to the WDSP.
There is some discussion as to whether the use of the same record tag
for all attributes makes it too easy to "decompile" the index object;
i.e., reconstruct a WDSPs data based on re-ordering the tokens
associated with each attribute and tag number. However, we are
dealing only with the search attributes here, which is a minimal
subset of the quantity of data held by the WDSP. The conclusion is
then that the improved efficiency given by using the same tag numbers
across attributes outweighs the (remote) possibility of information
This would yield the index object:
TISDAG: Within the project it has been decided to base consistency
between updates on consistent tags. This means that if the
update-type is "incremental" the specifier must be "tagbased".
E.3 CIP Index Object Sharing
E.3.1 Registration of Servers
It is beyond the scope of this document to define how WDSP servers
shall be registered with the DAG Referral Index. Such a procedure
must be defined, and the following information established for each
WDSP dataset (adapted from the Tagged Index Object specification,
dsi: An OID which uniquely identifies the subtree and scope of the
dataset for which the index object is created.
base-uri: One or more URI's which will form the base of any referrals
created based upon the index object that is governed by this
agreement. For example, for LDAP the base-uri would specify (among
other items): the LDAP host, the base object to which this index
object refers (e.g., c=SE), and the scope of the index object
(e.g., single container).
supplier: The hostname and listening port number of the supplier
server, as well as any alternative servers holding that same naming
contexts, in case the supplier is unavailable.
source-uri: The URI of the WDSP's preferred source of directory
service information. This might be, for instance, an HTTP-based
consumeraddr: This is a URI of the "mailto:" form, with the RFC 822
email address of the consumer server.
updateinterval: The maximum duration in seconds between occurrences
of the supplier server generating an update. If the consumer
server has not received an update from the supplier server after
waiting this long since the previous update, it is likely that the
index information is now out of date. A typical value for a server
with frequent updates would be 604800 seconds, or every week.
attributeNamespace: Every set of index servers that together wants to
support a specific usage of indices, has to agree on which
attributenames to use in the index objects. The participating
directory servers also has to agree on the mapping from local
attributenames to the attributenames used in the index. Since one
specific index server might be involved in several such sets, it
has to have some way to connect a update to the proper set of
indexes. One possible solution to this would be to use different
consistencybase: How consistency of the index is maintained over
complete - every change or delete concerning one object has to
contain all tokens connected to that object. This method must be
supported by any server who wants to comply with this standard
tagbased - starting at a full update every incremental update
referring back to this full updated has to maintain state-
information regarding tags, such that a object within the
original database is assigned the same tagnumber every time.
This method is optional.
uniqueID - every object in the Dataset has to have a unique value
for a specific attribute in the index. A example of such a
attribute could be the distinguishedName attribute. This method
is also optional.
securityoption: Whether and how the supplier server should sign and
encrypt the update before sending it to the consumer server.
Options for this version of the DAG service are "none": the update
is sent in plaintext "PGP/MIME": the update is digitally signed and
encrypted using PGP (see ). PGP/MIME is recommended.
security credentials: The long-term cryptographic credentials used
for key exchange and authentication of the consumer and supplier
servers, if a security option was selected. For "PGP/MIME", this
will be the trusted public keys of both servers.
E.3.2 Transmission of Objects
CIP Index Objects are sent to the DAG Referral Index by MIME-encoded
SMTP, following the Common Indexing Protocol specification (see 
Appendix F - Summary of Technical Survey Results
As part of the TISDAG project, a technical survey was carried out --
announced on the email@example.com mailing list, all Swedish WDSPs (and
potential WDSPs) were encouraged to fill out and submit the WWW-based
survey form (see http://tisdag.sunet.se/tisdag-survey.html).
The survey was carried out in May, 1997. Response was not as good as
had been hoped -- in the end, 5 WDSPs participated. We had hoped for
more responses than this, in order to have a concrete sense of
directory service providers' current and planned status. However,
informal "hallway" conversations with a few people at
Interoperabilitet'97 in Sollentuna suggest that, while people see the
TISDAG project as an important and timely step, they don't
necessarily have an immediate understanding of how it will impact
them, and what they can/should contribute. So, the results can be
seen as informational, though not a definitive statement of the whole
directory service picture in Sweden.
Interesting things to note from these results include the fact that,
although there were only 5 respondents, these are clearly significant
players -- 4 expect to have more than 100 000 records to contribute
by 12 months from now. There were no real surprises in terms of the
supported protocols or search types.
Table E.1 summarizes information from the survey concerning types of
queries currently supported by WDSPs, and planned for the next 12
months. Note that, at the time of the survey, the requirement of
searching by ROLE had not been proposed, so the survey did not
specifically ask if WDSPs supported both the DAGPERSON schema
protocol-equivalents (i.e., USER template in Whois++ and
inetorgperson objectclass in LDAP). In the table, the column
"Complete info?" describes whether or not the WDSP currently returns
at least as much information as is required for a DAG reply.
Resp Search Types Complete info? Access Protocols Access Protocols
(now) (12 months)
---- ------------ -------------- ---------------- ----------------
1 NOL Except ROLE Whois++ Whois++
2 N,NO,NL,NOL Except ROLE LDAPv2,DAP,PH, LDAPv2,LDAPv3,DAP,
3 N,NL,NOL Except ROLE LDAPv2,DAP,HTTP LDAPv2,LDAPv3,DAP,
4 N,NO,NL,NOL Except ROLE Whois++,HTTP LDAPv3,Whois++,
5 N,NO,NL,NOL Except ROLE LDAPv2,Whois LDAPv2,LDAPv3,
Table F.1 Summary of TISDAG Survey Results: Queries
Resp # of Records (now) # of Records (12 months) Character Sets
----- ------------------ ------------------------ --------------
1 94 280 120 000 - 130 000 ISO-8859-1
2 88 000 100 000 ISO-8859-1
3 N/A 100 000 T.61 (Telex)
4 150 000 250 000 ISO-8859-1
5 4 300 10 000 ISO-8859-1
Table F.2 Summary of TISDAG Survey Results: Operational Information
Appendix G - Useful References
N.B.: The following is a collection of Internet standards documents
(RFCs) and Internet-Drafts from which the material in this report was
drawn. Internet-Drafts are works-in-progress, and are not meant to
be cited. Where they are used in this document, references are to
the text contained in the Internet-Draft; i.e., they are not meant to
imply standards, so much as useful starting points for the work of
Electronic copies of the version of the Internet-Drafts documents
that were used in preparing this report are available from the
project web page, http://tisdag.sunet.se.
 Allen, J. and M. Mealling, "The Architecture of the Common
Indexing Protocol", RFC 2651, August 1999.
 Allen, J. and M. Mealing, "MIME Object Definitions for the
Common Indexing Protocol (CIP)", RFC 2652, August 1999.
 Allen, J. and P. Leach, "CIP Transport Protocols", RFC 2653,
 Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
 Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
RFC 2234, November 1997.
 Deutsch, P., Schoultz, R., Falstrom, P. and C. Weider,
"Architecture of the WHOIS++ Service", RFC 1835, July 1995.
 Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC
2015, October 1996.
 Patrik Faltstrom, Martin Hamilton, Leslie L. Daigle, "WHOIS++
templates", Work in Progress.
 Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Interent Message Bodies",
RFC 2045, November 1996.
 Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
 Good, G., "The LDAP Data Interchange Format (LDIF) - Technical
Specification", RFC 2849, June 2000.
 Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A Tagged
Index Object for use in the Common Indexing Protocol", RFC 2654,
 Howes, R., "A String Representation of LDAP Search Filters", RFC
1960, June 1996.
 Paul Panotzki, "Complexity of the Common Indexing Protocol:
Predicting Search Times in Index Server Meshes", Master's
Thesis, KTH, September 1996.
 Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
 Smith, M., "Definition of the inetOrgPerson Object Class", RFC
2798, April 2000.
 Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
 Wahl, M., "A summary of the X.500(96) User Schema for use with
LDAPv3", RFC 2256, December 1997.
 Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995.
 Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
 The Unicode Consortium, "The Unicode Standard -- Version 2.0",
Full Copyright Statement
Copyright (C) The Internet Society (2000). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the