Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2967

TISDAG - Technical Infrastructure for Swedish Directory Access Gateways

Pages: 105
Informational
Part 5 of 5 – Pages 93 to 105
First   Prev   None

Top   ToC   RFC2967 - Page 93   prevText

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
Top   ToC   RFC2967 - 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
                                              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
Top   ToC   RFC2967 - 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" TIMESTAMP = 1*DIGIT NAMECHAR = DIGIT | UPPER | LOWER | "-" | ";" | "."
Top   ToC   RFC2967 - 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
   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.
Top   ToC   RFC2967 - 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   ToC   RFC2967 - 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
   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]):
Top   ToC   RFC2967 - 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
     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.
Top   ToC   RFC2967 - 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 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.
Top   ToC   RFC2967 - 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,
                                                      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
Top   ToC   RFC2967 - 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, 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.
Top   ToC   RFC2967 - 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   ToC   RFC2967 - Page 104

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
Top   ToC   RFC2967 - 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
   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.