tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 2967


TISDAG - Technical Infrastructure for Swedish Directory Access Gateways

Part 5 of 5, p. 93 to 105
Prev RFC Part


prevText      Top      Up      ToC       Page 93 
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

Top      Up      ToC       Page 94 
 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
 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

Top      Up      ToC       Page 95 
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"
   NAMECHAR     = DIGIT | UPPER | LOWER | "-" | ";" | "."

Top      Up      ToC       Page 96 
   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

   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.

Top      Up      ToC       Page 97 
   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.

Top      Up      ToC       Page 98 
   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:

   version: x-tagged-index-1
   update-type: total
   this-update: 855938804

   BEGIN IO-Schema
   objectclass: TOKEN

   END IO-Schema
   BEGIN Index-Info
   objectclass: */dagperson
   FN: 1/Foo
   ORG: 1/The
   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,

Top      Up      ToC       Page 99 
   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
     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.

Top      Up      ToC       Page 100 
     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 mailing list, all Swedish WDSPs (and
   potential WDSPs) were encouraged to fill out and submit the WWW-based
   survey form (see

   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.

Top      Up      ToC       Page 101 
   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,

4     N,NO,NL,NOL   Except ROLE     Whois++,HTTP      LDAPv3,Whois++,

5     N,NO,NL,NOL   Except ROLE     LDAPv2,Whois      LDAPv2,LDAPv3,
                                    Whois++,HTTP      Whois,Whois++,PH,

      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

Top      Up      ToC       Page 102 
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,


   [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

Top      Up      ToC       Page 103 
   [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.

Top      Up      ToC       Page 104 
Authors' Addresses

   Leslie L. Daigle
   Thinking Cat Enterprises


   Roland Hedberg
   Jegerveien 25
   0777 Oslo

   Phone: +47 23 08 29 96

Top      Up      ToC       Page 105 
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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.