RFC 2967
TISDAG - Technical Infrastructure for Swedish Directory Access Gateways
Pages: 105
Informational
Informational
Part 5 of 5 – Pages 93 to 105
Appendix D - DAG/IP Response Messages Mapping
LDAPv2/v3 DAG/IP --------------------------------------- --------------------- success (0) v2&v3 200 Command Ok operationsError (1) v2&v3 505 Operations error protocolError (2) v2&v3 505 Operations error timeLimitExceeded (3) v2&v3 404 Timeout sizeLimitExceeded (4) v2&v3 110 To many hits compareFalse (5) v2&v3 200 OK compareTrue (6) v2&v3 200 OK authMethodNotSupported (7) v2&v3 505 Operations error strongAuthRequired (8) v2&v3 505 Operations error referral (10) v3 200 OK adminLimitExceeded (11) v3 110 Too many hits unavailableCriticalExtension (12) v3 505 Operations error confidentialityRequired (13) v3 505 Operations error saslBindInProgress (14) v3 N.A. noSuchAttribute (16) v2&v3 200 OK undefinedAttributeType (17) v2&v3 500 Syntax error inappropriateMatching (18) v2&v3 500 Syntax error constraintViolation (19) v2&v3 111 Requested constraint not supported attributeOrValueExists (20) v2&v3 200 OK invalidAttributeSyntax (21) v2&v3 500 Syntax error noSuchObject (32) v2&v3 200 OK aliasProblem (33) v2&v3 505 Operations error invalidDNSyntax (34) v2&v3 500 Syntax error isLeaf (35) v2 N.A. aliasDereferencingProblem (36) v2&v3 505 Operations error inappropriateAuthentication (48) v2&v3 500 Syntax error invalidCredentials (49) v2&v3 403 Information Unavailable insufficientAccessRights (50) v2&v3 403 Information Unavailable busy (51) v2&v3 403 Information Unavailable unavailable (52) v2&v3 401 Service not available unwillingToPerform (53) v2&v3 505 Operations error loopDetect (54) v2&v3 505 Operations error namingViolation (64) v2&v3 N.A. objectClassViolation (65) v2&v3 N.A. notAllowedOnNonLeaf (66) v2&v3 N.A. notAllowedOnRDN (67) v2&v3 N.A. entryAlreadyExists (68) v2&v3 N.A. objectClassModsProhibited (69) v2&v3 N.A. affectsMultipleDSAs (71) v3 N.A. other (80) v2&v3 403 Information Unavailable Table D.1 LDAPv2/v3 resultcodes to DAG/IP response codes mapping
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
DAG/IP Whois++
-------------------------------------- -----------------------------
110 Too Many hits 110 Too Many hits
111 Requested constraint not supported 111 Requested constraint not
supported
112 Requested constraint not fullfilled 112 Requested constraint not
fullfilled
200 Command Ok 200 Command Ok
201 Command Completed successfully 201 Command Completed
successfully
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
complicated
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
Appendix E - DAG CIP Usage
E.1 CIP Index Object
The CIP object used by the DAG system is based on the Tagged Index Object as defined in [12]. The grammar, adapted from that Work in Progress, for the specific object used by the DAG is as follows: index-object = 0*(io-part SEP) io-part io-part = header SEP schema-spec SEP index-info header = version-spec SEP update-type SEP this-update SEP last-update context-size version-spec = "version:" *SPACE "x-tagged-index-1" update-type = "updatetype:" *SPACE ( "total" | ( "incremental" [*SPACE "tagbased"|"uniqueIDbased" ]) this-update = "thisupdate:" *SPACE TIMESTAMP last-update = [ "lastupdate:" *SPACE TIMESTAMP SEP] context-size = [ "contextsize:" *SPACE 1*DIGIT SEP] schema-spec = "BEGIN IO-Schema" SEP 1*(schema-line SEP) "END IO-Schema" schema-line = attribute-name ":" token-type token-type = "TOKEN" index-info = full-index | incremental-index full-index = "BEGIN Index-Info" SEP 1*(index-block SEP) "END Index-Info" incremental-index = 1*(add-block | delete-block | update-block) add-block = "BEGIN Add Block" SEP 1*(index-block SEP) "END Add Block" delete-block = "BEGIN Delete Block" SEP 1*(index-block SEP) "END Delete Block" update-block = "BEGIN Update Block" SEP 0*(old-index-block SEP) 1*(new-index-block SEP) "END Update Block" old-index-block = "BEGIN Old" SEP 1*(index-block SEP) "END Old" new-index-block = "BEGIN New" SEP 1*(index-block SEP) "END New" index-block = first-line 0*(SEP cont-line) first-line = attr-name ":" *SPACE taglist "/" attr-value cont-line = "-" taglist "/" attr-value taglist = tag 0*("," tag) | "*" tag = 1*DIGIT ["-" 1*DIGIT] attr-value = 1*(UTF8) attr-name = dag-searchattr / "objectclass" dag-searchattr = "FN" / "LOC" / "ROLE" / "ORG" TIMESTAMP = 1*DIGIT NAMECHAR = DIGIT | UPPER | LOWER | "-" | ";" | "."
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
[14]) 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
efficiency.
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 ([12]). 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, Record #1: FN: Foo Bar ORG: The Snack Bar Record #2: 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
reconstruction.
This would yield the index object:
version: x-tagged-index-1
update-type: total
this-update: 855938804
last-update:
context-size:
BEGIN IO-Schema
objectclass: TOKEN
FN: TOKEN
ORG: TOKEN
END IO-Schema
BEGIN Index-Info
objectclass: */dagperson
FN: 1/Foo
-1,2/Bar
-2/Smith
ORG: 1/The
-1,2/Snack
-1/Bar
-2/Shack
End Index-Info
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,
[12]):
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
service.
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
DSIs.
consistencybase: How consistency of the index is maintained over
incremental updates:
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 [7]). 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 [2]
and [3]).
Appendix F - Summary of Technical Survey Results
As part of the TISDAG project, a technical survey was carried out --
announced on the tisdag@swip.net 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,
HTTP,Gopher PH,HTTP,Gopher
3 N,NL,NOL Except ROLE LDAPv2,DAP,HTTP LDAPv2,LDAPv3,DAP,
HTTP
4 N,NO,NL,NOL Except ROLE Whois++,HTTP LDAPv3,Whois++,
HTTP,E-mail
5 N,NO,NL,NOL Except ROLE LDAPv2,Whois LDAPv2,LDAPv3,
Whois++,HTTP Whois,Whois++,PH,
Finger,HTTP
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
UTF-8 UNICODE
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 this project. 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.Bibliography
[1] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol", RFC 2651, August 1999. [2] Allen, J. and M. Mealing, "MIME Object Definitions for the Common Indexing Protocol (CIP)", RFC 2652, August 1999. [3] Allen, J. and P. Leach, "CIP Transport Protocols", RFC 2653, August 1999. [4] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. [5] Crocker, D., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [6] Deutsch, P., Schoultz, R., Falstrom, P. and C. Weider, "Architecture of the WHOIS++ Service", RFC 1835, July 1995. [7] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996. [8] Patrik Faltstrom, Martin Hamilton, Leslie L. Daigle, "WHOIS++ templates", Work in Progress. [9] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Interent Message Bodies", RFC 2045, November 1996. [10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[11] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical Specification", RFC 2849, June 2000. [12] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A Tagged Index Object for use in the Common Indexing Protocol", RFC 2654, August 1999. [13] Howes, R., "A String Representation of LDAP Search Filters", RFC 1960, June 1996. [14] Paul Panotzki, "Complexity of the Common Indexing Protocol: Predicting Search Times in Index Server Meshes", Master's Thesis, KTH, September 1996. [15] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982. [16] Smith, M., "Definition of the inetOrgPerson Object Class", RFC 2798, April 2000. [17] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [18] Wahl, M., "A summary of the X.500(96) User Schema for use with LDAPv3", RFC 2256, December 1997. [19] Yeong, W., Howes, T. and S. Kille, "Lightweight Directory Access Protocol", RFC 1777, March 1995. [20] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [21] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996.
Authors' Addresses
Leslie L. Daigle Thinking Cat Enterprises EMail: leslie@thinkingcat.com Roland Hedberg Catalogix Jegerveien 25 0777 Oslo Norway Phone: +47 23 08 29 96 EMail: Roland@catalogix.se
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 English. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.