File: rfc2967.txt

package info (click to toggle)
doc-rfc 20181229-2
links: PTS, VCS
area: non-free
in suites: buster
size: 570,944 kB
sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (5883 lines) | stat: -rw-r--r-- 209,845 bytes
parent folder | download | duplicates (6)






Network Working Group                                          L. Daigle
Request for Comments: 2967                      Thinking Cat Enterprises
Category: Informational                                       R. Hedberg
                                                               Catalogix
                                                            October 2000


                 TISDAG - Technical Infrastructure for
                   Swedish Directory Access Gateways

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   The strength of the TISDAG (Technical Infrastructure for Swedish
   Directory Access Gateways) project's DAG proposal is that it defines
   the necessary technical infrastructure to provide a single-access-
   point service for information on Swedish Internet users.  The
   resulting service will provide uniform access for all information --
   the same level of access to information (7x24 service), and the same
   information made available, irrespective of the service provider
   responsible for maintaining that information, their directory service
   protocols, or the end-user's client access protocol.

Table of Contents

   1.0 Introduction. . . . . . . . . . . . . . . . . . . . . . . . .  5
   1.1 Project Goal. . . . . . . . . . . . . . . . . . . . . . . . .  5
   1.2 Executive Summary of Technical Study Result . . . . . . . . .  5
   1.3 Document Overview . . . . . . . . . . . . . . . . . . . . . .  6
   1.4 Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  7
   2.0 Requirements. . . . . . . . . . . . . . . . . . . . . . . . .  7
   2.1 End-User Requirements . . . . . . . . . . . . . . . . . . . .  8
   2.2 WDSPs Requirements. . . . . . . . . . . . . . . . . . . . . .  8
   2.3 DAG-System Requirements . . . . . . . . . . . . . . . . . . .  9
   3.0 Functional Specification. . . . . . . . . . . . . . . . . . .  9
   3.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   3.2 The DAG Core. . . . . . . . . . . . . . . . . . . . . . . . . 10
   3.3 Client Interface. . . . . . . . . . . . . . . . . . . . . . . 11
   3.3.1 Acceptable User Input . . . . . . . . . . . . . . . . . . . 12



Daigle & Hedberg             Informational                      [Page 1]

RFC 2967                         TISDAG                     October 2000


      Supported Query Types. . . . . . . . . . . . . . . . . . . . . 12
      Matching Semantics . . . . . . . . . . . . . . . . . . . . . . 12
      Character Sets . . . . . . . . . . . . . . . . . . . . . . . . 13
   3.3.2 Data Output Spec. . . . . . . . . . . . . . . . . . . . . . 14
      Schema Definition. . . . . . . . . . . . . . . . . . . . . . . 14
      Referral Definition. . . . . . . . . . . . . . . . . . . . . . 14
      Error conditions . . . . . . . . . . . . . . . . . . . . . . . 14
   3.4 Directory Server Interface. . . . . . . . . . . . . . . . . . 14
   4.0 Architecture. . . . . . . . . . . . . . . . . . . . . . . . . 15
   4.1 Software Components . . . . . . . . . . . . . . . . . . . . . 15
   4.1.1 Internal Communications . . . . . . . . . . . . . . . . . . 15
   4.1.2 Referral Index. . . . . . . . . . . . . . . . . . . . . . . 15
   4.1.3 DAG-CAPs. . . . . . . . . . . . . . . . . . . . . . . . . . 15
   4.1.4 DAG-SAPs. . . . . . . . . . . . . . . . . . . . . . . . . . 17
   4.2 Important Architectural Notes . . . . . . . . . . . . . . . . 17
   4.2.1 2 Distinct Functions:  Referrals and Chaining . . . . . . . 17
   4.2.2 Limited Query and Response Semantics. . . . . . . . . . . . 17
   4.2.3 Visibility. . . . . . . . . . . . . . . . . . . . . . . . . 17
   4.2.4 Richness of Query semantics . . . . . . . . . . . . . . . . 18
   4.2.5 N+M Protocol Mappings . . . . . . . . . . . . . . . . . . . 18
   4.2.6 DAG-CAPs and DAG-SAPs are completely independent of each
      other. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   4.2.7 The Role of the DAG-CAP . . . . . . . . . . . . . . . . . . 18
   4.2.8 The Role of the DAG-SAP . . . . . . . . . . . . . . . . . . 19
   4.2.9 DAG/IP is internal. . . . . . . . . . . . . . . . . . . . . 19
   4.2.10 Expectations . . . . . . . . . . . . . . . . . . . . . . . 19
   4.2.11 Future Extensions. . . . . . . . . . . . . . . . . . . . . 19
   5.0 Software Specifications . . . . . . . . . . . . . . . . . . . 19
   5.1 Notational Convention . . . . . . . . . . . . . . . . . . . . 19
   5.2 DAG-CAP Basics. . . . . . . . . . . . . . . . . . . . . . . . 20
   5.2.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . 20
   5.2.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . 21
   5.2.3 Error handling. . . . . . . . . . . . . . . . . . . . . . . 21
   5.2.4 Pruning of results. . . . . . . . . . . . . . . . . . . . . 22
   5.3 DAG-SAP Basics. . . . . . . . . . . . . . . . . . . . . . . . 22
   5.3.1 Functionality . . . . . . . . . . . . . . . . . . . . . . . 22
   5.3.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . 23
   5.3.3 Error handling. . . . . . . . . . . . . . . . . . . . . . . 23
   5.3.4 Pruning of results. . . . . . . . . . . . . . . . . . . . . 23
   5.3.5 Constraint precedence . . . . . . . . . . . . . . . . . . . 23
   5.4 The Referral Index. . . . . . . . . . . . . . . . . . . . . . 24
   5.4.1 Architecture. . . . . . . . . . . . . . . . . . . . . . . . 24
   5.4.2 Interactions with WDSPs (CIP) . . . . . . . . . . . . . . . 24
   5.4.3 Index Object Format . . . . . . . . . . . . . . . . . . . . 24
   5.4.4 DAG-Internal I/O. . . . . . . . . . . . . . . . . . . . . . 24
   5.4.5 The Index Server. . . . . . . . . . . . . . . . . . . . . . 24
   5.4.6 Configuration . . . . . . . . . . . . . . . . . . . . . . . 25
   5.4.7 Security. . . . . . . . . . . . . . . . . . . . . . . . . . 25



Daigle & Hedberg             Informational                      [Page 2]

RFC 2967                         TISDAG                     October 2000


   5.5 Mail (SMTP) DAG-CAP . . . . . . . . . . . . . . . . . . . . . 25
   5.5.1 Mail DAG-CAP Input. . . . . . . . . . . . . . . . . . . . . 26
   5.5.2 Translation from Mail query to DAG/IP . . . . . . . . . . . 28
      Querying the Referral Index. . . . . . . . . . . . . . . . . . 28
      Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 29
   5.5.3 Chaining queries in Mail DAG-CAP. . . . . . . . . . . . . . 31
   5.5.4 Expression of results in Mail DAG-CAP . . . . . . . . . . . 31
   5.5.5 Expression of Errors in Mail DAG-CAP. . . . . . . . . . . . 31
   5.6 Web (HTTP) DAG-CAP. . . . . . . . . . . . . . . . . . . . . . 32
   5.6.1 Web DAG-CAP Input . . . . . . . . . . . . . . . . . . . . . 32
   5.6.2 Translation from Web query to DAG/IP. . . . . . . . . . . . 33
      Querying a DAG-SAP Directly. . . . . . . . . . . . . . . . . . 33
      Querying the Referral Index. . . . . . . . . . . . . . . . . . 33
      Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 35
   5.6.3 Chaining queries in Web DAG-CAP . . . . . . . . . . . . . . 36
   5.6.4 Expression of results in Web DAG-CAP. . . . . . . . . . . . 36
      text/html results. . . . . . . . . . . . . . . . . . . . . . . 36
      application/whoispp-response Results . . . . . . . . . . . . . 37
   5.6.5 Expression of Errors in Web DAG-CAP . . . . . . . . . . . . 37
      Standard Errors. . . . . . . . . . . . . . . . . . . . . . . . 38
   5.7 Whois++ DAG-CAP . . . . . . . . . . . . . . . . . . . . . . . 38
   5.7.1 Whois++ DAG-CAP Input . . . . . . . . . . . . . . . . . . . 38
   5.7.2 Translation from Whois++ query to DAG/IP. . . . . . . . . . 39
      Querying the Referral Index. . . . . . . . . . . . . . . . . . 39
      Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 39
   5.7.3 Chaining in Whois++ DAG-CAP . . . . . . . . . . . . . . . . 40
   5.7.4 Expression of results in Whois++. . . . . . . . . . . . . . 41
   5.7.5 Expression of Errors in Whois++ DAG-CAP . . . . . . . . . . 41
   5.8 LDAPv2 DAG-CAP. . . . . . . . . . . . . . . . . . . . . . . . 42
   5.8.1 LDAPv2 DAG-CAP Input. . . . . . . . . . . . . . . . . . . . 42
   5.8.2 Translation from LDAPv2 query to DAG/IP . . . . . . . . . . 44
      Querying the Referral Index. . . . . . . . . . . . . . . . . . 44
      Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 46
   5.8.3 Chaining queries in LDAPv2 DAG-CAP. . . . . . . . . . . . . 48
   5.8.4 Expression of results in LDAPv2 . . . . . . . . . . . . . . 48
   5.8.5 Expression of Errors in LDAPv2 DAG-CAP. . . . . . . . . . . 48
   5.9 LDAPv3 DAG-CAP. . . . . . . . . . . . . . . . . . . . . . . . 50
   5.9.1 LDAPv3 DAG-CAP Input. . . . . . . . . . . . . . . . . . . . 50
   5.9.2 Translation from LDAPv3 query to DAG/IP . . . . . . . . . . 51
      Querying the Referral Index. . . . . . . . . . . . . . . . . . 51
      Querying a DAG-SAP . . . . . . . . . . . . . . . . . . . . . . 54
   5.9.3 Chaining queries in LDAPv3 DAG-CAP. . . . . . . . . . . . . 55
   5.9.4 Expression of results in LDAPv3 . . . . . . . . . . . . . . 55
   5.9.5 Expression of Errors in LDAPv3 DAG-CAP. . . . . . . . . . . 56
   5.10 Whois++ DAG-SAP. . . . . . . . . . . . . . . . . . . . . . . 57
   5.10.1 Input. . . . . . . . . . . . . . . . . . . . . . . . . . . 57
   5.10.2 Translation from DAG/IP to Whois++ query . . . . . . . . . 58
   5.10.3 Translation of Whois++ results to DAG/IP . . . . . . . . . 58



Daigle & Hedberg             Informational                      [Page 3]

RFC 2967                         TISDAG                     October 2000


   5.11 LDAPv2 DAG-SAP . . . . . . . . . . . . . . . . . . . . . . . 59
   5.11.1 Input. . . . . . . . . . . . . . . . . . . . . . . . . . . 59
   5.11.2 Translation from DAG/IP to LDAPv2 query. . . . . . . . . . 59
   5.11.3 Translation of LDAPv2 results to DAG/IP. . . . . . . . . . 61
   5.12 LDAPv3 DAG-SAP . . . . . . . . . . . . . . . . . . . . . . . 62
   5.12.1 Input. . . . . . . . . . . . . . . . . . . . . . . . . . . 62
   5.12.2 Translation from DAG/IP to LDAPv3 query. . . . . . . . . . 62
   5.12.3 Translation of LDAPv3 results to DAG/IP. . . . . . . . . . 64
   5.13 Example Queries. . . . . . . . . . . . . . . . . . . . . . . 64
   5.13.1 A Whois++ Query. . . . . . . . . . . . . . . . . . . . . . 65
      What the Whois++ DAG-CAP Receives. . . . . . . . . . . . . . . 65
      What the Whois++ DAG-CAP sends to the Referral Index . . . . . 65
      What the Whois++ DAG-CAP Sends to an LDAP DAG-SAP. . . . . . . 65
   5.13.2 An LDAP Query. . . . . . . . . . . . . . . . . . . . . . . 66
      What the LDAP DAG-CAP Receives . . . . . . . . . . . . . . . . 66
   5.13.3 What the LDAP DAG-CAP sends to the Referral Index. . . . . 67
      What the LDAP DAG-CAP Sends to a Whois++ DAG-SAP . . . . . . . 67
      What the LDAP DAG-CAP Sends to an LDAP DAG-SAP . . . . . . . . 68
   6.0 Service Specifications. . . . . . . . . . . . . . . . . . . . 68
   6.1 Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 68
   6.2 WDSP Participation. . . . . . . . . . . . . . . . . . . . . . 69
   6.3 Load Distribution . . . . . . . . . . . . . . . . . . . . . . 69
   6.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 72
   7.0 Security. . . . . . . . . . . . . . . . . . . . . . . . . . . 73
   7.1 Information credibility . . . . . . . . . . . . . . . . . . . 73
   7.2 Unauthorized access . . . . . . . . . . . . . . . . . . . . . 73
   8.0 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 74
   Appendix A - DAG Schema Definitions . . . . . . . . . . . . . . . 75
   A.1 DAG Personal Information Schema (DAGPERSON Schema). . . . . . 76
   A.2 DAG Organizational Role Information Schema (DAGORGROLE
      Schema). . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
   Appendix B - Schema Mappings for Whois++ and LDAP . . . . . . . . 77
   B.1 LDAP and the DAG Schemas. . . . . . . . . . . . . . . . . . . 78
   B.2 Whois++ and the DAG Schemas . . . . . . . . . . . . . . . . . 81
   Appendix C - DAG-Internal Protocol (DAG/IP) . . . . . . . . . . . 82
   C.1 A word on the choice of DAG/IP. . . . . . . . . . . . . . . . 83
   C.2 DAG/IP Input and Output -- Overview . . . . . . . . . . . . . 83
   C.3 BNF for DAG/IP input and output . . . . . . . . . . . . . . . 83
   C.3.1 The DAG/IP Input Grammar. . . . . . . . . . . . . . . . . . 84
   C.3.2 The DAG/IP Response Grammar . . . . . . . . . . . . . . . . 87
   C.4 DAG/IP Response Messages. . . . . . . . . . . . . . . . . . . 89
   Appendix D - DAG/IP Response Messages Mapping . . . . . . . . . . 93
   Appendix E - DAG CIP Usage. . . . . . . . . . . . . . . . . . . . 95
   E.1 CIP Index Object. . . . . . . . . . . . . . . . . . . . . . . 95
   E.2 CIP Index Object Creation . . . . . . . . . . . . . . . . . . 97
   E.3 CIP Index Object Sharing. . . . . . . . . . . . . . . . . . . 98
   E.3.1 Registration of Servers . . . . . . . . . . . . . . . . . . 98
   E.3.2 Transmission of Objects . . . . . . . . . . . . . . . . . .100



Daigle & Hedberg             Informational                      [Page 4]

RFC 2967                         TISDAG                     October 2000


   Appendix F - Summary of Technical Survey Results. . . . . . . . .100
   Appendix G - Useful References. . . . . . . . . . . . . . . . . .102
   Bibliography. . . . . . . . . . . . . . . . . . . . . . . . . . .102
   Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . .104
   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . .105

List of Tables

   Table 3.1 DAG-supported queries . . . . . . . . . . . . . . . . .12
   Table 5.1 Allowable Whois++ Queries . . . . . . . . . . . . . . .38
   Table A.1 DAGPERSON schema attributes . . . . . . . . . . . . . .76
   Table A.2 DAGORGROLE schema attributes. . . . . . . . . . . . . .77
   Table B.1 Canonical DAGPERSON schema & LDAP inetorgPerson
      attributes . . . . . . . . . . . . . . . . . . . . . . . . . .79
   Table B.2 Reasonable Approximations for LDAP organizationalRole
      attributes . . . . . . . . . . . . . . . . . . . . . . . . . .79
   Table B.3 Canonical mappings for LDAP organizationalRole
      attributes . . . . . . . . . . . . . . . . . . . . . . . . . .81
   Table B.4 Canonical DAGPERSON schema & Whois++ USER attributes. .81
   Table B.5 Canonical mappings for Whois++ ORGROLE attributes . . .82
   Table C.1 List of system response codes . . . . . . . . . . . . .90
   Table D.1 LDAPv2/v3 resultcodes to DAG/IP response codes
      mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . .93
   Table D.2 Mapping from DAG/IP response codes to LDAPv2/v3
      resultcodes. . . . . . . . . . . . . . . . . . . . . . . . . .94
   Table D.3 Mapping between DAG/IP and Whois++ response codes . . .94
   Table F.1 Summary of TISDAG Survey Results: Queries . . . . . . 101
   Table F.2 Summary of TISDAG Survey Results: Operational
      Information. . . . . . . . . . . . . . . . . . . . . . . . . 101

1.0 Introduction

1.1 Project Goal

   The overarching goal of this project is to develop the necessary
   technical infrastructure to provide a single-access-point service for
   searching for whitepages information on Swedish Internet users.  The
   service must be uniform for all information -- the same level of
   access to information (7x24 service), and the same whitepages
   information made available, irrespective of the service provider
   responsible for maintaining that information.

1.2 Executive Summary of Technical Study Result

   The strength of the TISDAG project's DAG proposal is that it defines
   the necessary technical infrastructure to provide a single-access-
   point service for information on Swedish Internet users.  The
   resulting service will provide uniform access for all information --



Daigle & Hedberg             Informational                      [Page 5]

RFC 2967                         TISDAG                     October 2000


   the same level of access to information (7x24 service), and the same
   information made available, irrespective of the service provider
   responsible for maintaining that information, their directory service
   protocols, or the end-user's client access protocol.

   Instead of requiring centralized mirroring of complete information
   records from Swedish directory service providers, the DAG system uses
   a well-defined index object summary of that data, updated at the
   directory service provider's convenience.  When an end-user queries
   the DAG, the referral information is used (by the end-user's
   software, or by a module within the DAG, as appropriate) to complete
   the final query directly at the directory service provider's system.
   This ensures that the end-user gets the most up-to-date complete
   information, and promotes the directory service provider's main
   interest:  its service.  The architecture of the DAG itself is very
   modular; support for future protocols can be added in the operational
   system.

1.3 Document Overview

   This document is broken into 5 major sections:

   Requirements: As a service, the DAG system will have several
   different types of users.  In order to be successful, those users'
   needs (requirements) must be met.  This in turn defines certain
   constraints, or system requirements, that must be met.  This section
   aims to capture the baseline requirement assumptions to be addressed
   by the system, and thus lays the groundwork on which the rest of the
   proposed system is built.

   Functional Specification Overview: Working from the users'
   requirements, specific technologies and  functionality details are
   outlined to architect a system that will meet the stated
   requirements.  This includes a conceptual architecture for the
   system.  While the Requirements section outlines the needs the
   different users have for the eventual DAG system,  implementing and
   providing the eventual service will entail constraints or conditions
   that need to be met in order to be able to participate in the overall
   system.

   Architecture: Once the system has been defined conceptually, a
   proposed software architecture is specified to produce the desired
   functionality and meet the stated requirements.

   Software Specifications: This section provides the specifications for
   software components to meet the architecture described above.





Daigle & Hedberg             Informational                      [Page 6]

RFC 2967                         TISDAG                     October 2000


   Service Specifications: Once the software has been designed, the
   success of the DAG system will rest on its operational
   characteristics.  Details of service requirements are given in this
   section.

1.4 Terminology

   DAG-CAP: Client Access Point -- point of communication between
   client-access software and the DAG system.

   DAG-System: The Directory Access Gateway system resulting from the
   TISDAG  project.  A collection of infrastructural software and
   services for the purpose of providing unified access to Swedish
   whitepages information.

   DAG/IP: DAG-Internal Protocol -- communication protocol used between
   software components of the DAG.

   End-User: People performing White Pages searches and look-ups (via
   various forms of client software).

   DAG-SAP:  Service Access Point -- point of communication between the
   DAG and WDSP software.

   WDSP: Whitepages Directory Service Provider -- ISPs, companies, or
   other interested entities.

   Whitepages Information: Collected information coordinates for
   individual people.  This typically includes (but is not limited to) a
   person's name, and e-mail address.

2.0 Requirements

   There are 2 primary classes of users for the proposed Whitepages
   directory access gateway:

   - End-users
   - WDSPs

   As outlined below, needs of each of these user classes imposes a set
   of constraints on the design of the DAG system itself.  Some of the
   requirements shown below are assumed starting criteria for the DAG
   service; others have been derived from data collected in the
   Technical Survey or other expertise input.







Daigle & Hedberg             Informational                      [Page 7]

RFC 2967                         TISDAG                     October 2000


2.1 End-User Requirements

   The End-User is to be provided with a specific set of search types:

   Name
   Name + Organization
   Role + Organization
   Name + Locality
   Name + Organization + Locality
   Role + Organization + Locality

   The search results will, if available, include the following
   information for each "hit":

   - Full name
   - E-mail address
   - Role
   - Organization
   - Locality
   - Full address
   - Telephone numbers

   Access to the service must be available through reasonable and
   current protocols -- such that directory-service-aware software can
   make use of it seamlessly, and there are no reasonable technological
   impediments to making this service useful to all Swedish Internet
   users.

   Following on that, its responses are expected to be timely; a
   standard search should not take more time than the average access to
   a web-server.

2.2 WDSPs Requirements

   Given that the WDSPs that participate in this service are already in
   the business of providing a service of whitepages information, they
   have certain requirements that must be respected in order to make
   this a successful and useful service to all concerned.

   The DAG system must provide reasonable assurances of data integrity
   for WDSPs; the information the End-User sees should correspond
   directly to that provided by the WDSPs.  The DAG system should be
   non-preferential in providing whitepages information -- the service
   is to the End-User, and the source of whitepages information should
   not influence the search and information presentation processes.






Daigle & Hedberg             Informational                      [Page 8]

RFC 2967                         TISDAG                     October 2000


   The DAG system must be able to reflect information updates within a
   reasonable time after receipt from WDSPs; on the flip side, while the
   DAG system will function best with regular updates from WDSPs, the
   update and participation overhead for WDSPs should be held within
   reasonable bounds of what the WDSP should do to support regular
   access to its information.

   Furthermore, given that WDSPs provide directory service information
   with an eye to value-added service, wherever possible End-Users
   should be redirected to the WDSP responsible for individual directory
   service entries for final and further information.

2.3 DAG-System Requirements

   In order to address the requirements of End-Users and WDSPs, the DAG
   system itself has certain design constraints that must be taken into
   account.

   The system must be implementable/operational by Dec 31/98 -- which
   implies that it must be designed and constructed with already extant
   technologies.

   The System will have certain requirements for participation -- e.g.,
   7x24 WDSP availability.

   In terms of scaling, the system should be able to handle 8M records
   at the outset, with a view to handling larger information systems in
   the future.

   The system must also be capable of extension to other, related
   applications (e.g., serving security certificate information).

3.0 Functional Specification

   In the TISDAG pilotservice we have decided to apply some limitations
   as to what is specified for the DAG/IP.  These limitations are
   presented in this text in the following manner:

      TISDAG: This is a TISDAG comment

3.1 Overview

   The conceptual environment of the DAG system can be described in
   three major components:

   - client access software for end-users
   - the DAG system core
   - WDSP directory service software



Daigle & Hedberg             Informational                      [Page 9]

RFC 2967                         TISDAG                     October 2000


   This is illustrated in Figure 3.1

   The DAG (Directory Access Gateway) is the infrastructural core of the
   service; it maintains the necessary data and transformation
   facilities to permit the smooth connection of diverse directory
   service Client Software to the existing WDSPs' directory servers.
   The key challenges in designing this portion of the system are:

   Quantity of data -- the quantity of whitepages information that will
   be made available, and diversity of its sources (different WDSPs)
   introduce challenges in terms of finding a structure that will allow
   efficient searching, and facilitate the timeliness of updating the
   necessary information.

   Multiplicity of access protocols -- in order to support the use of
   existing whitepages-aware software with a minimum of perturbation,
   the DAG system will have to present a uniform face in several
   different access protocols, each with its own information search and
   representation paradigm.

   This specification will outline the following areas:

   - the functioning of the DAG core itself
   - the interface between the DAG core and End-Users' Directory Service
     Access software
   - the interface between the DAG core and Directory Services Servers

3.2 The DAG Core

   In order to reduce the quantity of data the DAG itself must maintain,
   and to keep the maintenance of the whitepages information as close as
   possible to the source of information (the WDSPs themselves), the DAG
   will only maintain index information and will use "query routing" to
   efficiently refer End-User queries to WDSPs for search refinement and
   retrieval of information.  Although originally developed for the
   Whois++ protocol, query routing is being pursued in a protocol-
   independent fashion in the IETF's FIND WG, so the choice of this
   approach does not limit the selection and support of whitepages
   access protocols.

   The DAG will look after pursuing queries for access protocols that do
   not support referral mechanisms.  In order to achieve the support of
   multiple access protocols and differing data paradigms, the DAG will
   be geared to specifically support a limited set of whitepages
   queries.






Daigle & Hedberg             Informational                     [Page 10]

RFC 2967                         TISDAG                     October 2000


                                          +---------+      @
                                 +      ->|         |     -+-
                                /|Protocol|         |      |
                               / |    /   +---------+     / \
                              /  | "B"
                             +   |  /
                             |   |<-
         +-------+           |   |
    O    |       |           |   |
   -+-   |       |<--------->|   |
    |    |       | Protocol  |   |
   / \   |       |  "A"      |   |<-
         +-------+           |   |Protocol
                             |   |   \
                             +   |   "A"  +---------+      @
                              \  |     \  |         |     -+-
                               \ |      ->|         |      |
                                \|        +---------+     / \
                                 +

                             The
   End      Client           DAG           Directory   Directory
   Users    Software         System        Server      Service
                             Core          Software    Providers

           Figure 3.1 The role of the DAG system

3.3 Client Interface

   The DAG will respond to End-User queries in

   - e-mail (SMTP)
   - WWW (HTTP)
   - LDAPv2
   - Whois++
   - LDAPv3

   The DAG will provide responses including the agreed-upon data.  For
   access protocols that can handle referrals, responses will be data
   and/or referrals in that query protocol.  These are Whois++ and
   LDAPv3.  N.B.: the LDAPv3 proposal defines a referral as a URL; no
   limitation is placed on the access protocol.  However it cannot be
   assumed that all clients will be able to handle all access protocols,
   so only referrals to LDAPv3 servers will be returned.







Daigle & Hedberg             Informational                     [Page 11]

RFC 2967                         TISDAG                     October 2000


3.3.1 Acceptable User Input

   User Input is defined in terms of

   - Searchable Attributes
   - Matching semantics
   - Character sets

   These, in conjunction with the DAG schema, defined in Appendix A,
   form the basis of the required query expression.  Individual queries
   are discussed in more detail in the Client Access Point (DAG-CAP)
   component descriptions for supported protocols.

   Supported Query Types

   The DAG system is designed to support fragment-matching queries on a
   limited set of data attributes -- "Name", "Organizational Role",
   "Organization", and "Locality".  The selected permissible query
   combinations of attributes are listed in Table 3.1.  From the table
   it can be seen that not all combinations of the three attributes are
   supported -- only those that are needed for the desired
   functionality.

   Symbol  Description
   ------- -----------
   N       Name
   NL      Name + Locality
   NO      Name + Organization
   NOL     Name + Organization + Locality
   RO      Role + Organization
   ROL     Role + Organization + Locality

   Table 3.1 DAG-supported queries

   The RO and ROL queries are separated from the rest as they are
   searches for "virtual" persons -- roles within an organization (e.g.,
   president, or customer service desk) for which one might want to find
   contact information.

   Matching Semantics

   As befits the individual client query protocols, more string matching
   expressions may be provided.  The basic semantics of the DAG expect
   the following to be available in all client access software (as
   relevant):






Daigle & Hedberg             Informational                     [Page 12]

RFC 2967                         TISDAG                     October 2000


   - Full word, exact match
   - Word substring match (E.g., "cat" would match "scatter")
   - Case-sensitive and case-insensitive matching

      TISDAG: LDAP/X.500, supports case-sensitivity as such but some of
      the most used attributes, such as the commonName attribute, are
      defined in the standard to be of the case-insensitive
      attributetypes.  The impact on the DAG system is that even if the
      index collected from a LDAP/X.500 server might have upper and
      lower case letters in the tokens, they can not be handled as such
      since that would be inferring meaning in something which is
      natively regarded as meaningless.  The conclusion of the above is
      that The Referral Index should be case-insensitive and case-
      sensitivity should be supported by the SAPs if the native access
      protocol supports it.

   Character Sets

   Wherever possible, the DAG System supports and promotes the use of
   Unicode Version 2.0 for character sets (see [21]) specifically the
   UTF-8 encoding (see Appendix A.2 of [21] or [20]) Accommodation is
   made, where necessary, to support the deployed base of existing
   software.

   Specifically:

   DAG/IP: All internal communications using the DAG/IP are carried out
   in UTF-8.

      TISDAG: not just UTF-8, but UTF-8 based on composed UNICODE
      version 2 character encodings.

   DAG-CAP input: Where specific access protocols permit selection of
   character sets, DAG-CAPs must support UTF-8.  They may additionally
   support other anticipated character set encodings.

   DAG-SAP communications with WDSPs:  Where specific access protocols
   permit selection of character sets, DAG-SAPs must support UTF-8 and
   use UTF-8 whenever the remote WDSP supports it.  They may
   additionally support other character set encodings.

   CIP Index Objects: The Index Objects supplied by the WDSPs to the DAG
   system shall contain data encoded in UTF-8.

      TISDAG: The same limitation as for DAG/IP, that is the basic data
      should be UTF-8 encoded composed UNICODE version 2 character
      encodings.




Daigle & Hedberg             Informational                     [Page 13]

RFC 2967                         TISDAG                     October 2000


3.3.2 Data Output Spec

   Schema Definition

   The schema used for the DAG service  is defined in Appendix A.  This
   is a very basic information schema, intended to carry the necessary
   information  for the DAG service, and not more.  Although generic
   "whitepages" schema definitions do exist the more sophisticated and
   detailed the information presentation, the more difficult it is to
   map the schema seamlessly across protocols of different paradigms.
   Thus, the "KISS" ("Keep it simple, sir") principle seems appropriate
   here.

   Individual DAG-CAPs define how they express this schema.

   Referral Definition

   For client access protocols that make use of the concept of
   referrals, DAG-CAP definitions will define the expression of
   referrals in those protocols.  The DAG/IP defines the expression of
   referrals (see Appendix  C).

   Error conditions

   Each DAG-CAP may provide more detailed error messages, but will
   define minimally the support for the following error conditions:

   - unrecognized query
   - too many hits

   Apart from these errors, the DAG-CAP may choose to refuse a query by
   redirecting the end-user to a different DAG-CAP of the same protocol.

3.4 Directory Server Interface

   The DAG will use the Common Indexing Protocol (CIP) server-server
   protocol to obtain updated index objects from WDSPs.  For query-
   routing purposes, WDSPs are expected to  provide Whois++, LDAPv2 or
   LDAPv3 interface to their data (although their preferred access may
   be something completely different).  N.B.:  In the responses from the
   technical survey, all respondents currently provide access to their
   service in one of these protocols.

   In order to provide a useful and uniform service, WDSPs are expected
   to provide 7x24 access to their whitepages information.  WDSPs are
   also expected to implement operations, administration, maintenance,
   and provisioning processes designed to minimize service down time for
   both planned and unplanned administration and maintenance activities.



Daigle & Hedberg             Informational                     [Page 14]

RFC 2967                         TISDAG                     October 2000


4.0 Architecture

4.1 Software Components

   The conceptual architecture of the DAG is represented in Figure 4.1.
   General architectural specifications are described below, followed by
   individual component specifications Sections 5.5 through 5.12.

4.1.1 Internal Communications

   Communications between components of the DAG  will be by TCP/IP
   connections, using the DAG-Internal Protocol (DAG/IP).  DAG/IP is
   used by DAG-CAPs to communicate with the Referral Index and DAG-SAPs.
   Thus, the DAG/IP defines

   - the DAG-CAPs' range of query ability in the Referral Index (to
     gather referrals in response to the end-user's requests)
   - the responses (and their formats) of the Referral Index to the
     DAG-CAP requests
   - the DAG-CAPs' range of query ability to the DAG-SAPs for pursuing
     referrals when the DAG-CAP needs to do chaining for the client
     access software
   - the responses (and their formats) of the DAG-SAPs to the DAG-CAPs.

   The detail of the planned DAG/IP is given in Appendix C.  The detail
   of the DAG-CAP--Referral Index and DAG-CAP--DAG-SAP interactions  is
   given in the definitions of individual DAG-CAPs and DAG-SAPs, below
   (Sections 5.5 through 5.12).

4.1.2 Referral Index

   The Referral Index is responsible for maintaining the index of WDSP
   information, and providing a list of reasonable referrals in response
   to DAG-CAP search requests.  These "referrals" provide pointers to
   identify WDSPs that may have information that matches the end-user's
   query.

4.1.3 DAG-CAPs

   Individual DAG-CAPs are responsible for providing a particular client
   access protocol interface to the DAG service.  DAG-CAPs receive end-
   user queries in a particular query access protocol, convert the
   request into a query for the Referral Index ( i.e., expressed in
   DAG/IP), and then convert the Referral Index's response into a form
   that is appropriate for the client access protocol.  This may mean
   passing back the referrals directly, calling on DAG-SAPs to do the
   work of translating the referral into results ("chaining"), or a
   combination of both.



Daigle & Hedberg             Informational                     [Page 15]

RFC 2967                         TISDAG                     October 2000


              +-------------------------------------+
              |+====+                               |
   HTTP   <-->+|    |<------+  (Full chaining)      |
              ||    |       |                       |
              |+====+       |                       |
              |             |                 +----+|
              |             |      Referral-->|    ||
              |             |      Result  <--|    |+<--> Whois++
              |             |                 +----+|
              |+====+       |                       |
   SMTP   <-->+|    |<------+  (Full chaining)      |
              ||    |       |                       |
              |+====+       |                       |
              |             |                 +----+|
              |             |      Referral-->|    ||
              |             |      Result  <--|    |+<--> LDAPv2
              |             |                 +----+|
              |+====+       |                       |
   Whois++<-->+|    |<------+  (Chain LDAPv2/3)     |
              ||    |       |                       |
              |+====+       |                       |
              |             |                 +----+|
              |             |      Referral-->|    ||
              |             |      Result  <--|    |+<--> LDAPv3
              |             |                 +----+|
              |+====+       |                       |
   LDAPv2 <-->+|    |<------+  (Full chaining)      |
              ||    |       |                       |
              |+====+       |                       |
              |             |                       |
              |+====+       |                       |
   LDAPv3 <-->+|    |<------+  (Chain Whois++)      |
              ||    |       |                       |
              |+====+       |                       |
              |             |                       |
              |             v                       |
              |   +-----------------------+         |
              |   |  Referral Index       |<---------------> Common
              |   |                       |         | Indexing Protocol
              |   +-----------------------+         | (CIP)
              +-------------------------------------+

            All internal communications are in DAG/IP.

            Figure 4.1 Conceptual Architecture of the DAG






Daigle & Hedberg             Informational                     [Page 16]

RFC 2967                         TISDAG                     October 2000


4.1.4 DAG-SAPs

   Individual DAG-SAPs are called upon (by DAG-CAPs) to take DAG-
   generated referrals and pursue them -- issuing the indicated query at
   the specified WDSP service.  Results from individual WDSPs are
   converted back into DAG/IP-specific format for the DAG-CAP that made
   the request.  Each DAG-SAP is responsible for handling referrals to
   WDSPs of a particular protocol (e.g., LDAPv2, Whois++, etc).

4.2 Important Architectural Notes

   This section notes some of the thinking that has driven the
   architectural and software design specification for the DAG system.
   This helps to provide the context in which to understand the software
   specifications that follow, and should give clues for the eventual
   extension of the DAG system.  This section also acts, in some ways,
   as an FAQ (Frequently Asked Questions) section, as the content is
   shaped by questions received during the tech spec development phase.
   It attempts to illuminate context that may not otherwise be apparent
   on a first reading of the software specifications.

4.2.1 2 Distinct Functions:  Referrals and Chaining

   At all times, it must be kept in mind that the primary function of
   the DAG system is to provide users with referrals to WDSP services
   that may have the information they seek.  Since it is the case that
   not all supported client protocols can handle referrals, the DAG
   system also provides a chaining service to pursue referrals that the
   user's client software cannot handle itself.  This chaining service
   does attempt to match the user's query against data from WDSPs, but
   this is to be seen as a secondary, or support function of the DAG
   system.  In the perfect future, all access protocols will be able to
   handle all referrals!

4.2.2 Limited Query and Response Semantics

   The DAG system does not attempt to be a chameleon, or the ultimate
   whitepages query service.  It focuses on providing referrals for
   information on the limited number of query types outlined in the
   functional specifications of the DAG service.  This makes the DAG
   system a good place to start a search, but refinements and detailed
   inquiries are beyond its scope.

4.2.3 Visibility

   Given the limited query syntax of the DAG system it will not always
   be possible to exactly match a query posed to a CAP into a query
   posed to a SAP.  This will have the effect that for instance a LDAPv2



Daigle & Hedberg             Informational                     [Page 17]

RFC 2967                         TISDAG                     October 2000


   client that issues a query to the DAG system which by the DAG system
   is chained to a LDAP server might not get the same results as if the
   client where directly connected to the server in question.

4.2.4 Richness of Query semantics

   Even the limited query syntax of the DAG system is capable of
   expressing queries that might NOT be possible to represent in the
   access protocols to the WDSPs.  In these cases the DAG-SAP either can
   refuse the query or try to emulate it.

4.2.5 N+M Protocol Mappings

   As part of the chaining service offered by the DAG system, a certain
   amount of mapping between protocols is required -- in theoretical
   terms, there  are "N" allowable end-user query access protocols, and
   "M" supported WDSP server protocols.  The architecture of the
   software is constructed to use a single internal protocol (the
   DAG/IP) and data schema, providing a common language between all
   components.  Without this, each input protocol module (DAG-CAP) would
   have to be constructed to be able to handle every WDSP protocol --
   NxM protocol mappings.  This would make the system complex, and
   difficult to expand to include new protocols in future.

4.2.6 DAG-CAPs and DAG-SAPs are completely independent of each other

   For the above reasons, the DAG-CAP and DAG-SAP modules are intended
   to be completely independent of each other.  A DAG-SAP responds to a
   query that is posed to it in the DAG/IP, without regard to the
   protocol of the DAG-CAP that passed the query.

4.2.7 The Role of the DAG-CAP

   Thus, the DAG-CAP is responsible for using the DAG/IP to obtain
   referral information and, where necessary, chained responses.  Where
   necessary, it performs adjustments to accommodate the differences in
   semantics between the DAG/IP and its native protocol.  This might
   involved doing post-filtering of the results returned by the DAG-SAPs
   since the query issued in DAG/IP to the DAG-SAP might be "broader"
   then the original query.

   Thus, the DAG-CAP "knows" only 2 protocols:  its native protocol, and
   the DAG/IP.








Daigle & Hedberg             Informational                     [Page 18]

RFC 2967                         TISDAG                     October 2000


4.2.8 The Role of the DAG-SAP

   Similarly, the DAG-SAP is responsible for responding to DAG/IP
   queries by contacting the designated WDSP server.  Where necessary,
   it performs adjustments to accommodate the differences in semantics
   between the DAG/IP and its native protocol.  These adjustments might
   mean that, as a consequence, the DAG-SAP will receive results that do
   not match the original query.  In such cases the DAG-SAP should
   attempt to do post-pruning in order to reduce the mismatch between
   the original query and the results returned.

   Thus, the DAG-SAP "knows" only 2 protocols:  its native protocol, and
   the DAG/IP.

4.2.9 DAG/IP is internal

   No module outside of the DAG system should be aware of the DAG/IP's
   construction.  End-users use the query protocols supported by DAG-
   CAPs; WDSPs are contacted using the query protocols supported in the
   DAG-SAPs.

4.2.10 Expectations

   The expectation is that the DAG system, although defined as a single
   construct, will operate by running modules on several different,
   perhaps widely distributed (in terms of geography and ownership),
   computers.  For this reason, the DAG/IP specified in such a way that
   it will operate on inter-machine communications.

4.2.11 Future Extensions

   The DAG system architecture was constructed with a specific view to
   extensibility.  At any time, an individual component may be improved
   (e.g., the Mail DAG-CAP may be given a different query interface)
   without disrupting the system.

   Additionally, future versions of the DAG system may support other
   access protocols -- for end-users, and for WDSPs.

5.0 Software Specifications

5.1 Notational Convention

   It is always a challenge to accurately represent text protocol in a
   printed document; when is a new line a "newline", and when is it an
   effect of the text formatter?





Daigle & Hedberg             Informational                     [Page 19]

RFC 2967                         TISDAG                     October 2000


   In order to be adequately illustrated, this document includes many
   segments of protocol grammars, sample data, and sample input/output
   in a text protocol.  In order to distinguish newlines that are
   significant in a protocol, the symbol

   <NL>

   is used.  For example,

   This is an example of a very long line of input.  There is only one
   newline in it (at the end), in spite of the fact that this document
   shows it spanning several lines of text.<NL>

5.2 DAG-CAP Basics

5.2.1 Functionality

   Every DAG-CAP must support the full range of DAG queries, as defined
   in 3.3.1.

   Each DAG-CAP accepts queries in its native protocol.  Individual
   DAG-CAP definitions define the expected expression of the DAG queries
   in the native protocol.

   The DAG-CAP is then responsible for:

   - converting that expression into a query in the DAG/IP to obtain
     relevant referrals from the Referral Index.  This might mean that
     parts of the original query are disregarded (e.g., if the query
     included attributes not supported by the DAG application, or if the
     query algebra was not supported by the DAG application);
   - returning referrals in the client's native protocol, where
     possible;
   - expressing the client query to the necessary DAG-SAPs, given the
     limitations mentioned above, to chain those referrals not usefully
     expressible in the client's native protocol;
   - possibly doing post-filtering on the DAG-SAP results; and
   - converting the collected DAG-SAP results for expression in the
     client's native protocol (and schema, where applicable).

   Each DAG-CAP defines the nature of the interaction with the end-user
   (e.g., synchronous or asynchronous, etc).  Additionally, each DAG-CAP
   must be able to carry out the following, in order to permit load-
   limiting and load-balancing in the DAG system:

   - direct the client to a different DAG-CAP of the same type (for
     load-balancing)




Daigle & Hedberg             Informational                     [Page 20]

RFC 2967                         TISDAG                     October 2000


   - decline to return results because too many referrals were generated
     (to discourage data-mining).  Ideally, this should include the
     generation of a message to refine the query in order to produce a
     more manageable number of referrals/replies.

   DAG-CAPs must be capable of accepting and respecting DAG-SAP service
   referrals (for DAG-SAP load-sharing).

   In protocols that permit it, the DAG-CAP should indicate to the end-
   user which services were unavailable for chaining referrals (i.e., to
   indicate there were parts of the search that could not be completed,
   and information might be missing).

      TISDAG: Any CAP that receives commands other than queries, like
      help, answers those on its own.  A CAP should not pass any system
      command on to the RI.

5.2.2 Configuration

   It must be possible to change the expected address of the DAG-CAP by
   configuration of the software (i.e., host and port, e-mail address,
   etc).

   For DAG-CAPs that need to access DAG-SAPs for query chaining, for
   each type (protocol) of DAG-SAP that is needed, the DAG-CAP must be
   configurable in terms of:

   - at least one known DAG-SAP of every necessary protocol to contact
   - for each DAG-SAP, the host and port of the DAG-SAP software

   The DAG-CAPs must also be configurable in terms of a maximum number
   of referrals to handle for a user transaction (i.e., to prevent data
   mining, the DAG-CAP will refuse to reply if the query is too general
   and too many hits are generated at the Referral Index).

   The DAG-CAP must be configurable in terms of alternate DAG-CAPs of
   the same type to which the end-user software may be directed if this
   one is too busy.

5.2.3 Error handling

   Apart from error conditions arising from the operation of the DAG-CAP
   itself, DAG-CAPs are responsible for communicating error conditions
   occurring elsewhere in the system that affect the outcome of the
   user's query (e.g., in the DAG-RI, or in one or more DAG-SAPs).






Daigle & Hedberg             Informational                     [Page 21]

RFC 2967                         TISDAG                     October 2000


   If the DAG-CAP sends a query to the DAG-RI and receives an error
   message, it should attempt to match the the received DAG errorcode
   into its native access protocol's error codes.  The same action is
   appropriate when the DAG-CAP is "chaining" the query to one DAG-SAP.

   There are also occasions when the DAG-CAP may have to combine
   multiple errorcodes into a single expression to the user.  When the
   DAG-CAP is "chaining" the query through DAG-SAPs to one or more
   WDSPs, situations can arise when there is a mix of responsecodes from
   the DAG-SAPs.  If this happens, the DAG-CAP should try to forward
   information to the end-user software that is as specific as possible,
   for instance which of the WDSPs has not been able to fulfill the
   query and why.

   See Appendix D for more information concerning error condition
   message mappings.

5.2.4 Pruning of results

   Since there is no perfect match between the query syntaxes of the DAG
   system on one hand and the different access protocols that the DAG-
   CAPs and DAG-SAPs supports on the other, there will be situations
   where the results a DAG-CAP has to collect is "broader" then what
   would have been the case if there had been a perfect match.  This
   might have adverse effects on the system to the extent that
   administrative limits will "unnecessary" be exceeded on WDSPs or that
   the collected results exceeds the sizelimit of the DAG-CAP.

   Since the DAG-CAP is the only part of the DAG system that actually
   knows what the original query was, the DAG-CAP can prune the results
   received from the DAG-SAPs in such a way that the results presented
   to the client better matches the original question.

5.3 DAG-SAP Basics

5.3.1 Functionality

   Every DAG-SAP must support the full range of DAG queries, as defined
   in 3.3.1.  Results must be complete DAG schemas expressed in well-
   formed DAG/IP result formats (see Appendix C).  Each DAG-SAP accepts
   queries in DAG/IP and converts them to the native schema and protocol
   for which it is designed to proxy.

   The DAG-SAP is then responsible for

   - converting the query into the native schema and protocol of the
     WDSP to which the referral points.  (If the query is not
     representable in the native protocol, it must return an error



Daigle & Hedberg             Informational                     [Page 22]

RFC 2967                         TISDAG                     October 2000


     message.  If it is emulatable, the DAG-SAP can attempt emulate it
     by posing a related query to the WDSP and post-pruning the results
     received);
   - contacting that WDSP, using the host, port, and protocol
     information provided in the referral;
   - negotiating the query with the remote WDSP;
   - accepting results from the WDSP, possibly doing post-filtering on
     the result set; and
   - conveying the results back to the calling DAG-CAP using the DAG/IP
     and its schema.

   Note that this implicitly means that the DAG-SAP is responsible for
   chaining and pursuing any referrals it receives from WDSP services.
   The DAG-SAP returns only search results to the DAG-CAP that called
   it.

5.3.2 Configuration

   DAG-SAPs must be configurable to accept connections only from
   recognized DAG components.

   DAG-SAPs that have service limits must be configurable to redirect
   DAG-CAPs to alternate DAG-SAPs of the same type when necessary.

5.3.3 Error handling

   A DAG-SAP must translate error codes received from a WDSP server to
   DAG error codes according to Appendix D.

5.3.4 Pruning of results

   Since it might not be possible to exactly map a DAG query into a
   query in the access protocol supported by the a DAG-SAP, the DAG-SAP
   should try to translate it into a more general query (or if necessary
   into a set of queries).  If so, the DAG-SAP must then prune the
   result set received before furthering it to the DAG-CAP.

5.3.5 Constraint precedence

   Some constraints, search and case, can appear both as local and
   global constraints.  If this happens in a query then the local
   constraint specification overrides the global.  For a query like the
   following:

   fn=leslie;search=exact and org=think:search=substring

   the resulting search constraint for "fn=leslie" will be "exact" while
   it for "org=think" will be "substring".



Daigle & Hedberg             Informational                     [Page 23]

RFC 2967                         TISDAG                     October 2000


5.4 The Referral Index

5.4.1 Architecture

   The Referral Index contains (only) information necessary to deliver
   referrals to DAG-CAPs based on the query types supported by the DAG
   itself.  The Referral Index creates an index over these objects so
   that it can respond to DAG-CAP queries using the DAG/IP.  The
   information is drawn directly from interactions with participating
   WDSPs' software, using the Common Indexing Protocol (CIP).

5.4.2 Interactions with WDSPs (CIP)

   WDSPs that wish to participate in the DAG system must register
   themselves (see Section 5.4.6).  Once registered, the Referral Index
   will interact with the WDSPs using the Common Indexing Protocol as
   defined in [1], using the Index Object defined in Section 5.4.3.

5.4.3 Index Object Format

   The CIP index object type is based on the Tagged Index Object as
   defined in [12].  Appendix E details the expected content of the
   index objects as they are to be provided by the WDSPs.

      TISDAG: The tokens in the Tagged Index Object should be UTF-8
      encoded composed UNICODE version 2 character encoding.

5.4.4 DAG-Internal I/O

   The Referral Index interacts with the rest of the DAG internal
   modules (DAG-CAPs) by listening for queries and responding in the
   DAG/IP (defined in Appendix C).

5.4.5 The Index Server

   The Referral Index must index the necessary attributes of the CIP
   index object in order to respond to queries of the form described in
   Table 3.1.

   The semantics of the chosen CIP object (defined in Appendix E) are
   such that a referral to a WDSP server is sent back if (and only if)

   - the index object of the WDSP contains all the tokens of the query,
     in the attributes specified, according to the logic of the DAG/IP
     query, and
   - all of those tokens are found with a common tag.





Daigle & Hedberg             Informational                     [Page 24]

RFC 2967                         TISDAG                     October 2000


   This means that a query for the name "Fred Flintstone" (2 tokens)
   will yield a referral to a server that has a record for "Fred Amadeus
   Flintstone", but not to a WDSP with 2 differently tagged records, for
   "Fred Amadeus" and "Julie Flintstone".  Depending on the access
   protocol being used and the original end-user query, the referral to
   the WDSP with "Fred Amadeus Flintstone" may yield a successful
   result, or it may not.  But, it is known that the other WDSP would
   not have yielded successful searches.  That is, the referral approach
   may yield false-positive results, but will not miss appropriate
   WDSPs.

5.4.6 Configuration

   The Referral Index must provide the ability to register interested
   WDSPs, as outlined in Appendix E.

   The Referral Index must be able to configure the port for DAG/IP
   communications.  Also, it must be configurable to recognize only
   registered DAG-CAPs.

5.4.7 Security

   The Referral Index will accept queries only from recognized
   (registered) DAG-CAPs.  This will reduce "denial of service" attack
   types, but is also a reflection on the fact that the Referral Index
   uses the DAG/IP, (i.e., internal) protocol, which should not be
   exposed to non-DAG software.

   The Referral Index must be able to use authenticated communication to
   receive data from WDSPs (see Appendix E).

5.5 Mail (SMTP) DAG-CAP

   This is the default Mail DAG-CAP.  More sophisticated ones could
   certainly be written -- e.g., for pretty-printed output, or for
   handling different philosophies of case-matching.

   This DAG-CAP has been designed on the assumption that mail queries
   will be human-generated (i.e., using a mail program/text editor), as
   opposed to being queries formulated by software agents.  The input
   grammar should therefore be simple and liberal in acceptance of
   variations of whitespace formatting.









Daigle & Hedberg             Informational                     [Page 25]

RFC 2967                         TISDAG                     October 2000


5.5.1 Mail DAG-CAP Input

   Mail DAG-CAP input is expected to be a regular or MIME-encoded (see
   [9] and [10]) SMTP mail message, sent to an advertised mail address.
   The mail DAG-CAP parses the message and replies to it with a MIME-
   encoded message containing the results of the DAG search.

   One query is accepted per e-mail message -- text after a single valid
   query has been read is simply ignored.

   The body of the query message must follow the syntax defined below.
   Note that all input control terms ("type=", "name=" etc) are shown in
   lower case for convenience, but could be upper case or mixed case on
   input.

   mailquery       = [mnl] [controls] mnl terms mnl
   controls        = [msp] "searchtype" [msp] "=" [msp]
                        ( matchtype /
                          casetype /
                          matchtype msp casetype /
                          casetype msp matchtype /
                          <nothing> )
   matchtype       = "substring" / "exact"
                  ; default:  substring
   casetype        = "ignore" / "sensitive"
                  ; default:  ignore

   terms           = n / n-l / n-o / n-o-l / r-o / r-o-l

   n               = n-term
   n-l             = ( n-term l-term  / l-term n-term)
   n-o             = ( n-term o-term  / o-term n-term )
   n-o-l           = ( n-term o-term l-term /
                    n-term l-term o-term /
                    l-term n-term o-term /
                    l-term o-term n-term /
                    o-term l-term n-term /
                    o-term n-term l-term )
   r-o             = ( r-term o-term / o-term r-term )
   r-o-l           = ( r-term o-term l-term /
                    r-term l-term o-term /

                    l-term o-term r-term /
                    l-term r-term o-term /
                    o-term l-term r-term /
                    o-term r-term l-term )
   n-term          = [msp] "name" [msp] "=" [msp] string mnl
   o-term          = [msp] "org" [msp] "=" [msp] string mnl



Daigle & Hedberg             Informational                     [Page 26]

RFC 2967                         TISDAG                     October 2000


   l-term          = [msp] "loc" [msp] "=" [msp] string mnl
   r-term          = [msp] "role" [msp] "=" [msp] string mnl

   string          = <US-ASCII or quoted-printable encoded
                   ISO-8859-1 or UTF-8 except nl and sp>
   msp             = 1*(sp)
    sp              = " "
   mnl             = 1*(nl)

   nl              = <linebreak>

   The following are valid mail queries:

   Example 1:

   searchtype =   <NL>
   name = thinking cat<NL>

   Example 2:

   searchtype = exact ignore<NL>
   name=thinking cat<NL>

   Example 3:

   role=thinking cat<NL>
   org =space colonization<NL>

   Example 4:

   name=thinking cat <NL>
   <NL>
   <NL>
   My signature line follows here in the most annoying
   fashion <NL>

   Note that the following are not acceptable queries:

   Example 5:

   searchtype= exact substring <NL>
   name = thinking cat <NL>

   Example 6:

   name=thinking cat org= freedom fighters anonymous<NL>





Daigle & Hedberg             Informational                     [Page 27]

RFC 2967                         TISDAG                     October 2000


   In Example 5, two conflicting searchtypes are given.  In Example 6,
   no linebreak follows the n-term.

5.5.2 Translation from Mail query to DAG/IP

   Querying the Referral Index

   A key element of translating from the Mail DAG-CAP input into the
   DAG/IP query format is to "tokenize" the input terms into single
   token elements for the DAG/IP query.  For example,  the n-term

   name= thinking cat<NL>

   is tokenized into 2 n-tokens:

   thinking
   cat

   which are then mapped into the following in the DAG/IP query (dag-n-
   terms):

   FN=thinking and FN=cat<NL>

   The same is true for all r-terms, l-terms and o-terms.  The primary
   steps in translating the mail input into a DAG/IP query are:

   translate quoted-printable encoding, if necessary
   translate base64 encoding, if necessary
   tokenize the strings for each term
   construct the DAG/IP query from the resulting components, as
   described in more detail below

   DAG/IP constraints are constructed from the searchtype information in
   the query.

   dag-matchtype = "search=" <matchtype> /
                "search=substring"  ; if matchtype not
                                    ; specified

   dag-casetype  = "case=ignore"  /    ; if casetype not
                                    ; specified or
                                    ; casetype=ignore
                "case=consider"     ; if casetype=sensitive

   constraints   = ":" dag-matchtype ";" dag-casetype

   The terms for the DAG/IP query are constructed from the tokenized
   strings from the mail input.



Daigle & Hedberg             Informational                     [Page 28]

RFC 2967                         TISDAG                     October 2000


   dag-n-terms   = "FN=" n-token 0*( " and FN=" n-token)
   dag-o-terms   = "ORG=" o-token 0*( " and ORG=" o-token)
   dag-l-terms   = "LOC=" l-token 0*( " and LOC=" l-token)
   dag-r-terms   = "ROLE=" r-token 0*( " and ROLE=" r-token)

   This means that the relevant DAG/IP queries are formulated as one of
   two types:

   dagip-query   = ( ( ( n-query / nl-query / no-query /
                      nol-query ) [" and template=DAGPERSON"]":"
                   dag-matchtype ";" dag-casetype) /
                  ( ( ro-query / rol-query )
                    [" and template=DAGORGROLE"]":"
                    dag-matchtype ";" dag-casetype)  )

   n-query       = dag-n-terms
   nl-query      = dag-n-terms " and " dag-l-terms
   no-query      = dag-n-terms " and " dag-o-terms
   nol-query     = dag-n-terms " and " dag-o-terms " and "
                dag-l-terms
   ro-query      = dag-r-terms " and " dag-o-terms
   rol-query     = dag-r-terms " and " dag-o-terms " and "
                dag-l-terms

   The examples given earlier are then translated as follows.

   Example 1:

   FN=thinking and FN=cat:search=substring;case=ignore<NL>

   Example 2:

   FN=thinking and FN=cat:search=exact;case=ignore<NL>

   Example 3:

   ROLE=thinking and ROLE=cat and ORG=space and
   ORG=colonization:search=substring;case=ignore<NL>

   Querying a DAG-SAP

   In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP),
   the DAG/IP query must include information about the target WDSP
   server.  This information is drawn from the Referral Index SERVER-
   TO-ASK referral information, and is appended to the query as
   specified in Appendix C):





Daigle & Hedberg             Informational                     [Page 29]

RFC 2967                         TISDAG                     October 2000


   ":host=" quoted-hostname ";port=" number ";server-info="
   quoted-serverinfo ";charset=" charset

   where the response from the Referral Index included:

   "# SERVER-TO-ASK " serverhandle nl
   " Server-info: " serverinfo nl
   " Host-Name: " hostname nl
   " Host-Port: " number nl

   " Protocol: " prot nl
   " Source-URI: " source nl
   " Charset: " charset nl
   "# END" nl

   and the "quoted-hostname" and "quoted-serverinfo" are obtained from
   "hostname" and "serverinfo" respectively, by quoting the DAG/IP
   special characters.

   For example, the referral

   # SERVER-TO-ASK dagsystem01<NL>
    Server-info: o=thinkingcat, c=se<NL>
    Host-Name: thinkingcat.com<NL>
    Host-Port: 2839<NL>
    Protocol: ldapv2<NL>
    Source-URI: http://www.thinkcat.com
    Charset: T.61<NL>
    # END<NL>

   would yield the addition

   :host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
   c\=se;charset=T\.61

   in its query to an LDAPv2 DAG-SAP.

   (N.B.: See Appendix C for further definitions of the terms used in
   the SERVER-TO-ASK response).

   Note that it is the DAG-SAP's responsibility to extract these terms
   from the query and use them to identify the WDSP server to be
   contacted.  See the individual DAG-SAP definitions, below.








Daigle & Hedberg             Informational                     [Page 30]

RFC 2967                         TISDAG                     October 2000


5.5.3 Chaining queries in Mail DAG-CAP

   The Mail DAG-CAP has to chain all referrals -- to the Whois++ DAG-
   SAP, LDAPv2  DAG-SAP, or LDAPv3 DAG-SAP as appropriate for the
   referral.

5.5.4 Expression of results in Mail DAG-CAP

   The results message is sent to the "Reply-To:"  address of the
   originating mail, if available (see [4] for appropriate
   interpretation of mail originator headers).  The original query is
   repeated, along with the message-id.  The remainder of the body of
   the mail message is the concatenation of responses from the DAG-SAP
   calls, each result having the WDSP's SOURCE URI (from the referral)
   appended to it, and the system messages also having been removed.

   At the end of the message, the WDSP servers that failed to respond
   (i.e., the DAG-SAP handling the referral returned the "% 403
   Information Unavailable" message) are listed with their server-info.

5.5.5 Expression of Errors in Mail DAG-CAP

   If the mail DAG-CAP receives a message that is not parsable using the
   query grammar described above, it returns an explanatory message to
   the query mail's reply address saying that the query could not be
   interpreted, and giving a description of valid queries.

   If the number of referrals sent by the Referral Index is greater than
   the pre-determined maximum (for detecting data-mining efforts, or
   otherwise refusing over-general queries, such as "FN=svensson"), the
   mail DAG-CAP will send an explanatory message to the query mail's
   reply address describing the "over-generalized query" problem,
   suggesting the user resubmit a more precise query, and describing the
   list of valid query types.

   If the mail DAG-CAP receives several different result codes from the
   DAG-SAPs it should represent those in an appropriate manner in the
   response message.

   A mail DAG-CAP may redirect a connection to another mail DAG-CAP for
   reasons of load-balancing.  This is done simply by forwarding the
   mail query to the address of the alternate mail DAG-CAP.









Daigle & Hedberg             Informational                     [Page 31]

RFC 2967                         TISDAG                     October 2000


5.6 Web (HTTP) DAG-CAP

5.6.1 Web DAG-CAP Input

   The web DAG-CAP provides its interface via standard HTTP protocol.
   The general expectation is that the web DAG-CAP will provide a form
   page with radio buttons to select "substring or exact match" and
   "consider case or ignore case".  Other information (about name, role,
   organization, locality) is solicited as free-form text.

   The DAG-CAP receives queries via an HTTP "post" method (the outcome
   of the form action for the page described above, or generated
   elsewhere).  The rest of this section describes the variables that
   are to be expressed in that post.  The actual layout of the page and
   most user interface issues are left to the discretion of the builder.
   Note that the Web DAG-CAP may be called upon to provide responses in
   different content encoding, and must therefore address the "Accept-
   Encoding:" request header in the HTTP connection.

   Although the Web protocol, HTTP, is not itself capable of handling
   referrals, through the use of two extra variables this client is
   given the option of requesting referral information and then pursuing
   individual referrals through the Web DAG-CAP itself, as a proxy for
   those referrals.  This is handled through the extra "control
   variables" to request referrals only, and to indicate when the
   transaction is a continuation of a previous query to pursue a
   referral.

   There has been call to have a "machine-readable" version of the
   search output.  As HTML is geared towards visual layout, user agents
   that intend to do something with the results other than present them
   in an HTML browser have few cues to use to extract the relevant
   information from the HTML page.  Also, "minor" visual changes,
   accomplished with extensive HTML updates, can disrupt user agents
   that were built to blindly parse the original HTML.  Therefore,
   provision has been made to return "raw" format results.  These are
   requested by specifying "Accept-Content: application/whoispp-
   response"  in the request header of the HTTP message to the HTTP
   DAG-CAP.












Daigle & Hedberg             Informational                     [Page 32]

RFC 2967                         TISDAG                     October 2000


   The variables that are expected are:

   transaction     = "new" / "chain"  ; default is "new". This
                   ; should not be user-settable.  It is used
                   ; in constructed URLs
   resulttype      = "all" / "referrals" ; default is "all"
   matchtype       = "substring" / "exact"
   casetype        = "case ignore" / "case sensitive"
   n-term          = string
   o-term          = string
   l-term          = string
   r-term          = string
   host-term       = string
   port-term       = string
   servinfo-term   = string
   prot-term       = string ; the protocol of the referral
   string          = <UNICODE-2-0-UTF-8> / <UNICODE-1-1-UTF-8> /
                  <ISO-8859-1>

5.6.2 Translation from Web query to DAG/IP

   Querying a DAG-SAP Directly

   If the transaction variable is "chain", the information in the POST
   is used to pursue a particular referral, not do a search of the
   Referral Index.  The appropriate DAG-SAP (deduced from the prot-term)
   is contacted and issued the query directly.

   Results from this type of query are always full results (i.e., not
   referrals).

   Querying the Referral Index

   A key element of translating from the Web DAG-CAP input into the
   DAG/IP query format is to "tokenize" the input terms into single
   token elements for the DAG/IP query.  For example,  the n-term

   name= thinking cat

   is tokenized into 2 n-tokens:

   thinking
   cat

   which are then mapped into the following in the DAG/IP query (dag-n-
   terms):

   FN=thinking and FN=cat



Daigle & Hedberg             Informational                     [Page 33]

RFC 2967                         TISDAG                     October 2000


   The same is true for the r-term, l-term and o-term.

   The primary steps in translating the HTTP input into a DAG/IP query
   are:

   translate encodings, if necessary
   tokenize the strings for each term
   construct the DAG/IP query from the resulting components, as
   described in more detail below

   DAG/IP constraints are constructed from the searchtype information in
   the query.

   dag-matchtype = "search=" <matchtype> /
                "search=substring"     ; if matchtype not
                                       ; specified

   dag-casetype  = "case=ignore"  /       ; if casetype not
                                       ; specified or
                                       ; casetype="case ignore"
                "case=consider"        ; if casetype=
                                       ; "case sensitive"

   constraints   = ":" dag-matchtype ";" dag-casetype

   The terms for the DAG/IP query are constructed from the tokenized
   strings from the HTTP post input.

   dag-n-terms   = "FN=" n-token 0*( " and FN=" n-token)
   dag-o-terms   = "ORG=" o-token 0*( " and ORG=" o-token)
   dag-l-terms   = "LOC=" l-token 0*( " and LOC=" l-token)
   dag-r-terms   = "ROLE=" r-token 0*( " and ROLE=" r-token)

   This means that the relevant DAG/IP queries are formulated as one of
   two types:

   dagip-query   = ( ( ( n-query / nl-query / no-query / nol-query )
                      [" and template=DAGPERSON"]":" dag-matchtype
                      ";" dag-casetype) /
                  ( ( ro-query / rol-query )
                      [" and template=DAGORGROLE"]":" dag-matchtype
                      ";" dag-casetype)  )

   n-query       = dag-n-terms







Daigle & Hedberg             Informational                     [Page 34]

RFC 2967                         TISDAG                     October 2000


   nl-query      = dag-n-terms " and " dag-l-terms
   no-query      = dag-n-terms " and " dag-o-terms
   nol-query     = dag-n-terms " and " dag-o-terms " and "
                dag-l-terms
   ro-query      = dag-r-terms " and " dag-o-terms
   rol-query     = dag-r-terms " and " dag-o-terms " and "
                dag-l-terms

   Querying a DAG-SAP

   In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP),
   the DAG/IP query must include information about the target WDSP
   server.  This information is drawn from the Referral Index SERVER-
   TO-ASK referral information, and is appended to the query as
   specified in Appendix C:

   ":host=" quoted-hostname ";port=" number ";server-info="
   quoted-serverinfo ";charset=" charset

   where the response from the Referral Index included:

   "# SERVER-TO-ASK " serverhandle <NL>
   " Server-info: " serverinfo <NL>
   " Host-Name: " hostname <NL>
   " Host-Port: " number <NL>
   " Protocol: " prot <NL>
   " Source-URI: " source <NL>
   " Charset: " charset <NL>
   "# END" <NL>

   and the "quoted-hostname" and "quoted-serverinfo" are obtained from
   "hostname" and "serverinfo" respectively, by quoting the DAG/IP
   special characters.

   For example, the referral

   # SERVER-TO-ASK dagsystem01<NL>
    Server-info: o=thinkingcat, c=se<NL>
    Host-Name: thinkingcat.com<NL>
    Host-Port: 2839<NL>
    Protocol: ldapv2<NL>
    Source-URI: http://www.thinkingcat.com
    Charset: T.61<NL>
   # END<NL>

   would yield the addition





Daigle & Hedberg             Informational                     [Page 35]

RFC 2967                         TISDAG                     October 2000


   :host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
   c\=se;charset=T\.61

   in its query to an LDAPv2 DAG-SAP

   (N.B.: See Appendix C for further definitions of the terms used in
   the SERVER-TO-ASK response).

   Note that it is the DAG-SAP's responsibility to extract these terms
   from the query and use them to identify the WDSP server to be
   contacted.  See the individual DAG-SAP definitions, below.

5.6.3 Chaining queries in Web DAG-CAP

   If the resulttype was "all", all of the referrals received from the
   Referral Index are chained using the appropriate DAG-SAPs.  If only
   referrals were requested, the Referral Index results are returned.

5.6.4 Expression of results in Web DAG-CAP

   text/html results

   The default response encoding is text/html.  If the resulttype was
   "all",  the content of the chaining responses from the DAG-SAPs,
   without the system messages, is collated into a single page response,
   one result entry per demarcated line ( e.g., bullet item).  The FN or
   ROLE value should be presented first and clearly.  The SOURCE URI for
   each WDSP referral should be presented as an HREF for each of the
   WDSPs results.

   At the end of the message, the WDSP servers that failed to respond
   (i.e., the DAG-SAP handling the referral returned the "% 403
   Information Unavailable" message) are listed with their server-info.

   If, however, the resulttype was "referrals", the results from the
   Referral Index are returned as HREF URLs to the Web DAG-CAP itself,
   with the necessary information to carry out the query (including the
   "HOST=", etc, for the referral).

   For example, if the original query:

   n-term="thinking cat"
   resulttype="referrals"

   drew the following referral from the Referral Index:

   # SERVER-TO-ASK DAG-Serverhandle<NL>
    Server-Info: c=se, o=tce<NL>



Daigle & Hedberg             Informational                     [Page 36]

RFC 2967                         TISDAG                     October 2000


    Host-Name: answers.tce.com<NL>
    Host-Port: 1111<NL>

    Protocol: ldapv3<NL>
    Source-URI: http://some.service.se/
    Charset: UTF-8<NL>
   # END<NL>

   the response would be an HTML page with an HREF HTTP "POST" URL to
   the Web DAG-CAP with the following variables set:

   n-term="thinking cat"
   transaction="chain"
   servinfo-term="c=se, o=tce"
   host-term="answers.tce.com"
   port-term="1111"
   prot-term="ldapv3"

   The Source-URI should be established in the response as its own HREF
   URI.

   application/whoispp-response Results

   If Accept-Encoding: " HTTP request header had the value
   "application/whoispp-response", the content of the HTTP response will
   be constructed in the same syntax and attribute mapping as for the
   Whois++ DAG-CAP.

   If the resulttype was "all", all the referrals will have been chained
   by the Web DAG-CAP, and the response will include only full data
   records.

   If the resulttype was "referrals", then all referrals are passed
   directly back in a single response, in correct Whois++ referral
   format (conveniently, this is how they are formulated in the DAG/IP).
   Note that this will include referrals to LDAP-based services as well
   as Whois++ servers.

5.6.5 Expression of Errors in Web DAG-CAP

   A Web DAG-CAP may redirect a connection to another web DAG-CAP for
   reasons of load-balancing.  This is done simply by using an HTTP
   redirect.








Daigle & Hedberg             Informational                     [Page 37]

RFC 2967                         TISDAG                     October 2000


   Standard Errors

   If the web DAG-CAP receives a message that is not parsable using the
   query grammar described above, it sends an explanatory HTML page
   saying that the query could not be interpreted, and giving a
   description of valid queries.

   If the number of referrals sent by the Referral Index is greater than
   the pre-determined maximum (for detecting data-mining efforts, or
   otherwise refusing over-general queries, such as "FN=svensson"), the
   web DAG-CAP will send a page with an explanatory message describing
   the "over-generalized query" problem, suggesting the user resubmit a
   more precise query, and describing the list of valid query types.

   If the web DAG-CAP receives more than one result code from the DAG-
   SAPs, it must represent them all in a appropriate manner in the
   response.

   application/whoispp-response Errors

   An invalid query is responded to with a simple text response with the
   error: "% 500 Syntax Error".

   If too many referrals are generated from the Referral Index, the
   simple text response will have the message "% 503 Query too general".

5.7 Whois++ DAG-CAP

      TISDAG: The system commands polled-for/-by should elicit the empty
      set as a return value until we better understand the implications
      of doing otherwise.

5.7.1 Whois++ DAG-CAP Input

   Input to the Whois++ DAG-CAP follows the Whois++ standard ([6]).
   Minimally, the Whois++ DAG-CAP must support the following queries:

   Query Type     Expression in Whois++
   -----------    ------------------------------------
   N              One or more "name=" and
                  template=USER

   NL             One or more "name=" and
                  One or more "address-locality=" and template=USER

   NO             One or more "name=" and
                  one or more "organization-name=" and template=USER




Daigle & Hedberg             Informational                     [Page 38]

RFC 2967                         TISDAG                     October 2000


   NOL            One or more "name=" and
                  one or more  "organization-name=" and
                  one or more  "address-locality=" and template=USER

   RO             One or more "org-role=" and
                  one or more "organization-name=" and template=ORGROLE

   ROL            One or more "org-role=" and
                  one or more "organization-name=" and
                  one or more "address-locality=" and template=ORGROLE

      Table 5.1 Allowable Whois++ Queries

   The following constraints must be supported for queries:

   "search=" (substring / exact)
   "case=" (ignore / consider)

   If no constraints are defined in a query the default is exact and
   ignore.  For example,

   FN=foo and loc=kista and fn=bar<NL>

   is a perfectly valid Whois++ NL query for "Foo Bar" in "Kista".

5.7.2 Translation from Whois++ query to DAG/IP

   Querying the Referral Index

   The Whois++ DAG-CAP formulates a DAG/IP query by forwarding the
   search terms received (as defined in Table 5.1).

   For example, the above query would be expressed as:

   FN=foo and LOC=kista and FN=bar and template=DAGPERSON<NL>

   Querying a DAG-SAP

   In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP),
   the DAG/IP query must include information about the target WDSP
   server.  This information is drawn from the Referral Index SERVER-
   TO-ASK referral information, and is appended to the query as
   specified in appendix C:

   ":host=" quoted-hostname ";port=" number ";server-info="
   quoted-serverinfo ";charset=" charset





Daigle & Hedberg             Informational                     [Page 39]

RFC 2967                         TISDAG                     October 2000


   where the response from the Referral Index included:

   "# SERVER-TO-ASK " serverhandle<NL>
   " Server-info: " serverinfo<NL>
   " Host-Name: " hostname<NL>
   " Host-Port: " number<NL>
   " Protocol: " prot<NL>
   " Source-URI: " source<NL>
   " Charset: " charset<NL>
   "# END"<NL>

   and the "quoted-hostname" and "quoted-serverinfo" are obtained from
   "hostname" and "serverinfo" respectively, by quoting the DAG/IP
   special characters.

   For example, the referral

   # SERVER-TO-ASK dagsystem01<NL>
    Server-info: o=thinkingcat, c=se<NL>
    Host-Name: thinkingcat.com<NL>
    Host-Port: 2839<NL>
    Protocol: ldapv2<NL>
    Source-URI: http://www.thinkingcat.com/
    Charset: T.61<NL>
   # END<NL>

   would yield the addition

   :host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
   c\=se;charset=T\.61

   in its query to an LDAPv2 DAG-SAP.

   (N.B.: See Appendix C for further definitions of the terms used in
   the SERVER-TO-ASK response).

   Note that it is the DAG-SAP's responsibility to extract these terms
   from the query and use them to identify the WDSP server to be
   contacted.  See the individual DAG-SAP definitions, below.

5.7.3 Chaining in Whois++ DAG-CAP

   The Whois++ DAG-CAP relies on DAG-SAPs to chain any non-Whois++
   referrals (currently, the LDAPv2 and LDAPv3 DAG-SAPs).







Daigle & Hedberg             Informational                     [Page 40]

RFC 2967                         TISDAG                     October 2000


5.7.4 Expression of results in Whois++

   Results are expressed in Whois++ by collating the DAG/IP results
   received from DAG-SAPs (using the FULL response), and using the
   template and attribute mappings defined in Appendix B. For each
   result from a given referral, the SOURCE attribute is added, with the
   value of the SOURCE-URI from the referral.

   Any referrals to other Whois++ servers provided by the Referral Index
   are sent directly to the Whois++ client as follows:

   server-to-ask   =   "# SERVER-TO-ASK " DAG-Serverhandle<NL>
                    " Server-Handle: " SERVER-INFO<NL>
                    " Host-Name: " HOST<NL>
                    " Host-Port: " PORT<NL>
                    " Protocol: " PROTOCOL<NL>
                    "# END"<NL>

   where SERVER-INFO, HOST, PORT, PROTOCOL are drawn from the referral
   provided in the DAG/IP, and the SOURCE-URI information is lost.

5.7.5 Expression of Errors in Whois++ DAG-CAP

   As appropriate, the Whois++ DAG-CAP will express operational errors
   following the Whois++ standard.  There are 4 particular error
   conditions of the DAG system that the DAG-CAP will handle as
   described below.

   When the Whois++ DAG-CAP receives a query that it cannot reply to
   within the (data) constraints of the DAG, it sends an error message
   and closes the connection.  The error message includes

   % 502 Search expression too complicated<NL>

   If the number of referrals sent by the Referral Index is greater than
   the pre-determined maximum (for detecting data-mining efforts, or
   otherwise refusing over-general queries, such as "FN=svensson"), the
   Whois++ DAG-CAP will send an error message and close the connection.
   The error message includes

   % 503 Query too general<NL>

   (N.B.: this is different from the "Too many hits" reply, which does
   send partial results.)







Daigle & Hedberg             Informational                     [Page 41]

RFC 2967                         TISDAG                     October 2000


   A Whois++ DAG-CAP may redirect a connection to another Whois++ DAG-
   CAP for reasons of load-balancing.  This is expressed to the end-user
   client software using the SERVER-TO-ASK response with appropriate
   information to reach the designated alternate DAG-CAP.

   If a Whois++ DAG-CAP receives several different response codes from
   DAG-SAPs it should try to represent them all in the response to the
   end-user client.

   The proposed mapping between DAG/IP response codes and Whois++
   response codes are given in Appendix D.

5.8 LDAPv2 DAG-CAP

5.8.1 LDAPv2 DAG-CAP Input

   Input to the LDAPv2 DAG-CAP follows the LDAPv2 standard ([19]).
   Minimally, the LDAPv2 DAG-CAP must support the following queries
   (adapted from the ASN.1 grammar of the standard):

   BindRequest ::=
         [APPLICATION 0] SEQUENCE {
                     version   INTEGER (1 .. 127),
                     name      LDAPDN,
                     authentication CHOICE {
                           simple        [0] OCTET STRING,
                           krbv42LDAP    [1] OCTET STRING,
                           krbv42DSA     [2] OCTET STRING
                      }

         }

   BindResponse ::= [APPLICATION 1] LDAPResult

   SearchRequest ::=
    [APPLICATION 3] SEQUENCE {
        baseObject    "dc=se",
        scope         wholeSubtree          (2),
        derefAliases  ENUMERATED {
                     neverDerefAliases     (0),
                     derefInSearching      (1),
                     derefFindingBaseObj   (2),
                     derefAlways           (3)
        },
        sizeLimit     INTEGER (0 .. maxInt),
        timeLimit     INTEGER (0 .. maxInt),
        attrsOnly     BOOLEAN,
        filter        Filter,



Daigle & Hedberg             Informational                     [Page 42]

RFC 2967                         TISDAG                     October 2000


        attributes    SEQUENCE OF AttributeType
   }

   Filter ::=
    CHOICE {
        and                [0] SET OF Filter,
        or                 [1] SET OF Filter,
        not                [2] Filter,
        equalityMatch      [3] AttributeValueAssertion,
        substrings         [4] SubstringFilter
    }

   SubstringFilter ::=
    SEQUENCE {
        type               AttributeType,
        SEQUENCE OF CHOICE {
            initial        [0] LDAPString,
            any            [1] LDAPString,
            final          [2] LDAPString
        }
    }

   Queries against attributes in the prescribed LDAP standard schema
   (see Appendix B) are accepted.

   N.B., this is a minimal set of supported queries, to achieve the
   basic DAG-defined queries.  An LDAP DAG-CAP may choose to support
   more complex queries than this, if it undertakes to do the
   translation from the DAG/IP to the LDAPv2 client in a way that
   responds to the semantics of those queries.

      TISDAG:  Since LDAPv2 didn't specify any characterset but relied
      on X.500 to do so, in practice several different charactersets are
      in use in Sweden today.  That the LDAPv2 CAP has no way of knowing
      which characterset that are in use by a connecting client is a
      problem that the TISDAG project can not solve.

      Users of the DAG system will have to configure their specific
      client according to information on the TISDAG web page.  That page
      provides very specific information (including port number) that
      can be given to LDAPv2 users.  The LDAP DAG-CAP listening on the
      default port (389) will be the LDAPv3 one.









Daigle & Hedberg             Informational                     [Page 43]

RFC 2967                         TISDAG                     October 2000


5.8.2 Translation from LDAPv2 query to DAG/IP

   Querying the Referral Index

   The essential stratagem for mapping LDAP queries into DAG/IP Referral
   Index queries is to tokenize the string-oriented LDAP
   AttributeValueAssertions or SubstringFilters and construct an
   appropriate DAG/IP token-oriented query in the DAG/IP.  This will
   generalize the LDAP query and yield false-positive referrals, but
   should not miss any appropriate referrals.

   There are 3 particular cases to be considered:

   equalityMatch queries
   substring queries
   combination equalityMatch and substring queries

      TISDAG: If the LDAP filter contains a cn-term and no objectclass
      specification it is unclear if the search is for a person or a
      role.  When this happens the DAG query should cover all bases and
      map the query into a query for both people and roles.

   EqualityMatch queries can be handled by simply tokenizing the
   AttributeValueAssertions, making one DAG/IP query term per token
   (using the appropriate DAGSchema attribute) and carrying out an
   exact match in the DAG/IP.

   Consider the following example, represented in the ASCII
   expression of LDAP Filters as described in [13]):

   (& (cn=Foo Bar)(objectclass=inetOrgPerson))

   This query can be represented in the DAG/IP as

   FN="Foo" and FN="Bar":search=exact<NL>

   N.B.
   The search is set up to be "case=ignore" (the DAG/IP's default)
   because the relevant LDAP schema attributes are all derivatives
   of the "name" attribute element, which is defined to have a case
   insensitive match.

   If no objectclass were defined the query in DAG/IP would have
   been

   (FN="Foo" and FN="bar") or (ROLE="Foo" and ROLE="bar"):search=exact





Daigle & Hedberg             Informational                     [Page 44]

RFC 2967                         TISDAG                     October 2000


   inetOrgPerson is used as the objectclass in this and the following
   examples, although person or organizationalPerson could also have
   been used.

   This query will yield false-positive referrals; the original
   LDAP query should only match against records for which the "cn"
   attribute is exactly the phrase "Foo Bar", whereas the DAG/IP
   query will yield referrals any WDSP containing records that
   include the two tokens "foo" and "bar" in any order.

   For example, this DAG/IP query will yield referrals to WDSPs
   with records including:

   cn: Bar Foo
   cn: Le Bar Foo
   cn: Foo Bar AB

   LDAP substring queries must also be tokenized in order to construct a
   DAG/IP query.  The additional point to bear in mind is that LDAP
   substring expressions are directed at phrases, which obscure
   potential token boundaries.  Consequently, all points between
   substring components must be considered as potential token
   boundaries.

   Thus, the LDAP query

   (& (cn=black) (o=c*t) (objectclass=inetOrgPerson))

   could be expressed as a  DAG/IP query with 3 tokens, in a substring
   search:

   FN=black and ORG=c and ORG=t:search=substring<NL>

   This query will yield false-positive results as the tokenized query
   does not preserve the order of appearance in the LDAP substring, and
   it doesn't preserve phrase-boundaries.  That is,

   ORG=c and ORG=t:search=substring

   will match

   tabacco

   which is not a match by the LDAP query semantics.

   Combined EqualityMatch and Substring queries need special attention.
   When an LDAP query includes both EqualityMatch components and
   substring filter components, the DAG/IP query to the Referral Index



Daigle & Hedberg             Informational                     [Page 45]

RFC 2967                         TISDAG                     October 2000


   can be constructed by following the same mechanisms of tokenization,
   but the whole search will become a substring search, as the DAG/IP
   defines only search types across the entire query for Referral Index
   queries.

   Thus,

   (& (cn=Foo Bar) (o=c*t) (objectclass=inetOrgPerson))

   can be expressed as

   FN=Foo and FN=Bar and ORG=c and ORG=t:search=substring<NL>

   Alternatively, the LDAP DAG-CAP could conduct two separate queries
   and take the intersection (the logical "AND") of the two sets of
   referrals returned by the Referral Index.

   Note that DAG/IP can accept phrases for searches -- the query

   FN=Foo\ bar<NL>  (note the escaped space)

   is perfectly valid.  However, it would match only those things which
   have been tokenized in a way that preserves the space, which is the
   empty set in the case of the data stored here.

   Querying a DAG-SAP

   It is never invalid to use the same substantive query to a DAG-SAP as
   was used to obtain referral information from the Referral Index.
   However, the over-generalization of these queries may yield excessive
   numbers of results, and will necessitate some pruning of results in
   order to match the returned results against the semantics of the
   original LDAP query.  It is the LDAP DAG-CAP that is responsible for
   this pruning, as it is the recipient of the original query, and
   responsible for responding to its semantics.

   In concrete terms, when making the DAG/IP query which is to be sent
   to a  DAG-SAP the above mentioned queries are still valid queries,
   but an alternative finer-grained query is also possible, namely:

   FN=foo and FN=bar and ORG=c;search=lstring and ORG=t;search=tstring

   Particularly in the case of the LDAPv2 DAG-CAP, however, there will
   be cause to use LDAP(v2/v3) DAG-SAPs.  Since these DAG-SAPs also deal
   in phrase-oriented data, a less-over-generalized query can be passed
   to them:

   FN=Foo\ Bar:search=exact<NL>



Daigle & Hedberg             Informational                     [Page 46]

RFC 2967                         TISDAG                     October 2000


   In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP),
   the DAG/IP query must include information about the target WDSP
   server.  This information is drawn from the Referral Index SERVER-
   TO-ASK referral information, and is appended to the query as
   specified in Appendix C:

   ":host=" quoted-hostname ";port=" number ";server-info="
   quoted-serverinfo ";charset=" charset

   where the response from the Referral Index included:

   "# SERVER-TO-ASK " serverhandle<NL>
   " Server-info: " serverinfo<NL>
   " Host-Name: " hostname<NL>
   " Host-Port: " number<NL>
   " Protocol: " prot<NL>
   " Source-URI: " source<NL>
   " Charset: " charset<NL>
   "# END<NL>

   and the "quoted-hostname" and "quoted-serverinfo" are obtained from
   "hostname" and "serverinfo" respectively, by quoting the DAG/IP
   special characters.

   For example, the referral

   # SERVER-TO-ASK dagsystem01<NL>
    Server-info: o=thinkingcat, c=se<NL>
    Host-Name: thinkingcat.com<NL>
    Host-Port: 2839<NL>
    Protocol: ldapv2<NL>
    Source-URI: http://www.thinkingcat.com <NL>
    Charset: T.61<NL>
   # END<NL>

   would yield the addition

   :host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
   c\=se;charset=T\.61

   in its query to an LDAPv2 DAG-SAP.

   (N.B.: See Appendix C for further definitions of the terms used in
   the SERVER-TO-ASK response).

   Note that it is the DAG-SAP's responsibility to extract these terms
   from the query and use them to identify the WDSP server to be
   contacted.  See the individual DAG-SAP definitions, below.



Daigle & Hedberg             Informational                     [Page 47]

RFC 2967                         TISDAG                     October 2000


5.8.3 Chaining queries in LDAPv2 DAG-CAP

   The LDAPv2 DAG-CAP relies on DAG-SAPs to resolve every referral.

5.8.4 Expression of results in LDAPv2

   As described above, results from DAG-SAPs will have to be post-
   processed in cases where the original query was generalized for
   expression in DAG/IP.

   Acceptable results are expressed in the LDAP search response:

   SearchResponse ::=
    CHOICE {
         entry       [APPLICATION 4] SEQUENCE {
                  objectName   LDAPDN,
                  attributes   SEQUENCE OF SEQUENCE
                           {
                                    AttributeType,
                                    SET OF AttributeValue
                           }
                  },
         resultCode  [APPLICATION 5] LDAPResult
    }

   where

   LDAPDN = DN / "cn=" (FN/ROLE) [",o="ORG] ",dc=se"
   attributes = <all attributes mapped from DAG schema, and
                  "objectClass = inetOrgPerson",
                  "objectClass = top",
                  "objectClass = person" or
                  "objectClass = organizationalRole", as
                  appropriate, and "labeledURI = <SOURCE-URI>"
                  for each result from a given referral>

   (Where DN,FN,ORG and ROLE are the values from the DAG schema).

   I.e., where available, the entry's true DN is used; otherwise (e.g.,
   for data coming from Whois++ servers), a reasonable facsimile is
   constructed.

5.8.5 Expression of Errors in LDAPv2 DAG-CAP

   As appropriate, the LDAPv2 DAG-CAP will express system responses
   following the LDAPv2 standard.





Daigle & Hedberg             Informational                     [Page 48]

RFC 2967                         TISDAG                     October 2000


   Appendix D gives the proposed mapping between DAG/IP response codes
   and LDAPv2 resultcodes.

   There are 4 particular error conditions of the DAG system that the
   DAG-CAP will handle as described below.

   When the LDAPv2 DAG-CAP receives a query that it cannot reply to
   within the (data) constraints of the DAG queries, it sends an error
   message and closes the connection.  The error message includes the
   LDAPv2 resultCode:

   noSuchAttribute        (for incorrect schema attributes)
   inappropriateMatching  (when a match type other than those
                           supported is used, e.g. approxMatch)
   unwillingToPerform     (when the query is not one of the
                           defined types)

   If the number of referrals sent by the Referral Index is greater than
   the pre-determined maximum (for detecting data-mining efforts, or
   otherwise refusing over-general queries, such as "FN=svensson"), the
   LDAPv2 DAG-CAP will send an error message.  The error message
   includes one of the following resultCodes:

   sizeLimitExceeded
   timeLimitExceeded

   An LDAPv2 DAG-CAP may redirect a connection to another LDAPv2 DAG-CAP
   for reasons of load-balancing.  This is expressed to the end-user
   client software using the "umich referral" convention to direct the
   client software to an alternate DAG-CAP by passing the URL in an
   error message.

   Since a LDAPv2 DAG-CAP only can send one resultcode back to a client;
   If a LDAPv2 DAG-CAP receives several different result codes from the
   DAG-SAPs it will have to construct a resultmessage that to some
   extent represents the combination of those.  It is proposed that in
   these cases the following actions are taken:

   - All the response codes are collected
   - Each response code are translated into the corresponding LDAPv2
     resultcode.
   - A resultcode is chosen to represent the collected response on the
     following grounds:
       If  "success" is the only resultcode represented after these
       steps the return that result code.
       If apart from "success" there is one other resultcode represented
       return that other resultcode.




Daigle & Hedberg             Informational                     [Page 49]

RFC 2967                         TISDAG                     October 2000


       If apart from "success" there are two or more resultcodes
       represented return the resultcode "other".

5.9 LDAPv3 DAG-CAP

5.9.1 LDAPv3 DAG-CAP Input

   Input to the LDAPv3 DAG-CAP follows the LDAPv3 definition (currently
   defined in [17]).  Minimally, the LDAPv3 DAG-CAP must support the
   following queries (adapted from the ASN.1 grammar of the standard):

   BindRequest ::= [APPLICATION 0] SEQUENCE {

                version                 INTEGER (1 .. 127),
                name                    LDAPDN,
                authentication          AuthenticationChoice }

        AuthenticationChoice ::= CHOICE {
                simple                  [0] OCTET STRING,
                                         -- 1 and 2 reserved
                sasl                    [3] SaslCredentials }

        SaslCredentials ::= SEQUENCE {
                mechanism               LDAPString,
                credentials             OCTET STRING OPTIONAL }

   BindResponse ::= [APPLICATION 1] SEQUENCE {
             COMPONENTS OF LDAPResult,
             serverSaslCreds    [7] OCTET STRING OPTIONAL }

   SearchRequest ::= [APPLICATION 3] SEQUENCE {
        baseObject      c=se,
        scope           wholeSubtree            (2) },
        derefAliases    ENUMERATED {
                neverDerefAliases       (0),
                derefInSearching        (1),
                derefFindingBaseObj     (2),
                derefAlways             (3) },
         sizeLimit       INTEGER (0 .. maxInt),
        timeLimit       INTEGER (0 .. maxInt),
        typesOnly       BOOLEAN,
        filter          Filter,
        attributes      AttributeDescriptionList }








Daigle & Hedberg             Informational                     [Page 50]

RFC 2967                         TISDAG                     October 2000


   Filter ::= CHOICE {
        and             [0] SET OF Filter,
        or              [1] SET OF Filter,
        not             [2] Filter,
        equalityMatch   [3] AttributeValueAssertion,
        substrings      [4] SubstringFilter }

   SubstringFilter ::= SEQUENCE {
        type            AttributeDescription,
        -- at least one must be present
        substrings    initial [0] LDAPString,
        substrings    any     [1] LDAPString,
        substrings    final   [2] LDAPString}

   Queries against attributes in the proscribed LDAP standard schema
   (see Appendix B) are accepted.

   N.B., this is a minimal set of supported queries, to achieve the
   basic DAG-defined queries.  An LDAP DAG-CAP may choose to support
   more complex queries than this, if it undertakes to do the
   translation from the DAG/IP to the LDAPv3 client in a way that
   responds to the semantics of those queries.

5.9.2 Translation from LDAPv3 query to DAG/IP

   Querying the Referral Index

   The essential stratagem for mapping LDAP queries into DAG/IP Referral
   Index queries is to tokenize the string-oriented LDAP
   AttributeValueAssertions or SubstringFilters and construct an
   appropriate DAG/IP token-oriented query in the DAGschema.  This will
   generalize the LDAP query and yield false-positive referrals, but
   should not miss any appropriate referrals.

   There are 3 particular cases to be considered:

   equalityMatch queries
   substring queries
   combination equalityMatch and substring queries

      TISDAG: If the LDAP filter contains a cn-term and no objectclass
      specification it is unclear if the search is for a person or a
      role.  When this happens the DAG query should cover all bases and
      map the query into a query for both people and roles.







Daigle & Hedberg             Informational                     [Page 51]

RFC 2967                         TISDAG                     October 2000


   EqualityMatch queries can be handled by simply tokenizing the
   AttributeValueAssertions, making one DAG/IP query term per token
   (using the appropriate DAGSchema attribute) and carrying out an exact
   match in the DAG/IP.

   Consider the following example, represented in the ASCII expression
   of LDAP Filters as described in [13]):

   (& (cn=Foo Bar)(objectclass=person))

   This query can be represented in the DAG/IP as

   FN="Foo" and FN="Bar":search=exact<NL>

   N.B.
   The search is set up to be "case=ignore" (the DAG/IP's default)
   because the relevant LDAP schema attributes are all derivatives of
   the "name" attribute element, which is defined to have a case
   insensitive match.

   If no objectclass where defined the query in DAG/IP would have been

   (FN="Foo" and FN="bar") or ( ROLE="Foo" and ROLE="bar"):search=exact

   Although person is used as objectclass in this and the following
   examples, inetOrgPerson or organizationalPerson could also have been
   used.

   This query will yield false-positive referrals; the original LDAP
   query should only match against records for which the "cn" attribute
   is exactly the phrase "Foo Bar", whereas the DAG/IP query will yield
   referrals any WDSP containing records that include the two tokens
   "foo" and "bar" in any order.

   For example, this DAG/IP query will yield referrals to WDSPs with
   records including:

   cn: Bar Foo
   cn: Le Bar Foo
   cn: Foo Bar AB

   LDAP substring queries must also be tokenized in order to construct a
   DAG/IP query.  The additional point to bear in mind is that LDAP
   substring expressions are directed at phrases, which obscure
   potential token boundaries.  Consequently, all points between
   substring components must be considered as potential token
   boundaries.




Daigle & Hedberg             Informational                     [Page 52]

RFC 2967                         TISDAG                     October 2000


   Thus, the LDAP query

   (& (cn=black) o=c*t) (objectclass=person))

   should be expressed as a DAG/IP query with 3 tokens, in a substring
   search:

   FN=black and ORG=c and ORG=t:search=substring<NL>

   This query will yield false-positive results as the tokenized query
   does not preserve the order of appearance in the LDAP substring, and
   it doesn't preserve phrase-boundaries.  That is,

   ORG=c and ORG=t:search=substring

   will match

   tabacco

   which is not a match by the LDAP query semantics.

   Combined EqualityMatch and Substring queries need special attention.
   When an LDAP query includes both EqualityMatch components and
   substring filter components, the DAG/IP query to the Referral Index
   can be constructed by following the same mechanisms of tokenization,
   but the whole search will become a substring search, as the DAG/IP
   defines search types across the entire query.

   Thus,

   (& (cn=Foo Bar) (o=c*t) (objectclass=person))

   can be expressed as

   FN=Foo and FN=Bar and ORG=c and ORG=t:search=substring<NL>

   Alternatively, the LDAP DAG-CAP could conduct two separate queries
   and take the intersection (the logical "AND") of the two sets of
   referrals returned by the Referral Index.

   Note that DAG/IP can accept phrases for searches -- the query

   FN=Foo\ bar<NL>   (note the escaped space)

   is perfectly valid.  However, it would match only those things which
   have been tokenized in a way that preserves the space, which is the
   empty set in the case of the data stored here.




Daigle & Hedberg             Informational                     [Page 53]

RFC 2967                         TISDAG                     October 2000


   Querying a DAG-SAP

   It is never invalid to use the same substantive query to a DAG-SAP as
   was used to obtain referral information from the Referral Index.
   However, the over-generalization of these queries may yield excessive
   numbers of results, and will necessitate some pruning of results in
   order to match the returned results against the semantics of the
   original LDAP query.  It is the LDAP DAG-CAP that is responsible for
   this pruning, as it is the recipient of the original query, and
   responsible for responding to its semantics.

   In concrete terms, when making the DAG/IP query which is to be sent
   to a  DAG-SAP the above mentioned queries are still valid queries,
   but an alternative finer-grained query is also possible, namely:

   FN=foo and FN=bar and ORG=c;search=lstring and ORG=t;search=tstring

   In querying a DAG-SAP (irrespective of the protocol of that DAG-SAP),
   the DAG/IP query must include information about the target WDSP
   server.  This information is drawn from the Referral Index SERVER-
   TO-ASK referral information, and is appended to the query as
   specified in Appendix C):

   "host=" quoted-hostname ";port=" number ";server-info="
   quoted-serverinfo ";charset=" charset

   where the response from the Referral Index included:
   "# SERVER-TO-ASK " serverhandle <NL>
   " Server-info: " serverinfo<NL>
   " Host-Name: " hostname<NL>
   " Host-Port: " number<NL>
   " Protocol: " prot<NL>
   " Source-URI: " source<NL>
   " Charset: " charset<NL>
   "# END"<NL>

   and the "quoted-hostname" and "quoted-serverinfo" are obtained from
   "hostname" and "serverinfo" respectively, by quoting the DAG/IP
   special characters.

   For example, the referral

   # SERVER-TO-ASK dagsystem01<NL>
    Server-info: o=thinkingcat, c=se<NL>
    Host-Name: thinkingcat.com<NL>
    Host-Port: 2839<NL>
    Protocol: ldapv2<NL>
    Source-URI:http://www-thinkingcat.se/



Daigle & Hedberg             Informational                     [Page 54]

RFC 2967                         TISDAG                     October 2000


    Charset: T.61<NL>
   # END<NL>

   would yield the addition

   :host=thinkingcat\.com;port=2839;server-info=o\=thinkingcat\,\
   c\=se;charset=T\.61

   in its query to an LDAPv2 DAG-SAP.

   (N.B.: See Appendix C for further definitions of the terms used in
   the SERVER-TO-ASK response).

   Note that it is the DAG-SAP's responsibility to extract these terms
   from the query and use them to identify the WDSP server to be
   contacted.  See the individual DAG-SAP definitions, below.

5.9.3 Chaining queries in LDAPv3 DAG-CAP

   The LDAPv3 DAG-CAP relies on DAG-SAPs to resolve all referrals except
   those to LDAPv3 servers (i.e., Whois++ referrals, currently).

5.9.4 Expression of results in LDAPv3

   As described above, results from DAG-SAPs will have to be post-
   processed in cases where the original query was generalized for
   expression in DAG/IP.  Acceptable results are expressed in LDAPv3
   messages containing search result entries (see the standard for more
   detail):

   SearchResultEntry ::= [APPLICATION 4] SEQUENCE {
        objectName      LDAPDN,
        attributes      PartialAttributeList }

   PartialAttributeList ::= SEQUENCE OF SEQUENCE {
        type    AttributeDescription,
        vals    SET OF AttributeValue }

   SearchResultReference ::= [APPLICATION 19] SEQUENCE OF LDAPURL
   -- at least one LDAPURL element must be present

   SearchResultDone ::= [APPLICATION 5] LDAPResult

   where

   LDAPDN = DN / "cn=" (FN/ROLE) [",o=" ORG] ",dc=se"





Daigle & Hedberg             Informational                     [Page 55]

RFC 2967                         TISDAG                     October 2000


   attributes = <all attributes mapped from the DAG schema, and
                  "objectClass = inetOrgPerson",
                  "objectClass = person",
                  "objectClass = top" or
                  "objectClass = organizationalRole", as
                  appropriate, and "labeledURI = <SOURCE-URI>"
                  for each result from a given referral>
   LDAPResult = success

   (Where DN, FN, ROLE, and ORG are the values from the DAG schema).

   I.e., where available, the entry's true DN is used; otherwise (e.g.,
   for data coming from Whois++ servers), a reasonable facsimile is
   constructed.

   Referral URLs are constructed from the DAG/IP's SERVER-TO-ASK
   information as follows:

   refurl = "ldap://" HOST [":" PORT] "/" (SERVER-INFO / "dc=se")

   The intention is that WDSPs using LDAPv3 servers will provide an
   appropriate LDAPDN for their server in the SERVER-INFO.  Clients are
   then expected to repeat their query at the server designated by this
   URL (i.e., the refURL does not include the query).

5.9.5 Expression of Errors in LDAPv3 DAG-CAP

   As appropriate, the LDAPv3 DAG-CAP will express operational errors
   following the LDAPv3 standard.  There are 4 particular error
   conditions of the DAG system that the DAG-CAP will handle as
   described below.

   When the LDAPv3 DAG-CAP receives a query that it cannot reply to
   within the (data) constraints of the DAG queries, it sends an error
   message and closes the connection.  The error message includes the
   LDAPv3 resultCode

   noSuchAttribute        (for incorrect schema attributes chosen)
   inappropriateMatching  (when a match type other than those
   supported is used e.g., approxMatch)
   unwillingToPerform     (when the query is not one of the defined
   types)

   If the number of referrals sent by the Referral Index is greater than
   the pre-determined maximum (for detecting data-mining efforts, or
   otherwise refusing over-general queries, such as "FN=svensson"), the
   LDAPv3 DAG-CAP will send an error message.  The error message
   includes the following resultCode:



Daigle & Hedberg             Informational                     [Page 56]

RFC 2967                         TISDAG                     October 2000


   adminLimitExceeded

   An LDAPv3 DAG-CAP may redirect a connection to another LDAPv3 DAG-CAP
   for reasons of load-balancing.  In this case, the LDAPv3 DAG-CAP
   sends a result message including only

   SearchResultReference ::= [APPLICATION 19]  AltURL

   SearchResultDone ::= referral

   where

   AltURL = "ldap://" <althostport> ":" <altbase>

   Since a LDAPv3 DAG-CAP only can send one resultcode back to a client;
   If a LDAPv3 DAG-CAP receives several different result codes from the
   DAG-SAPs it will have to construct a resultmessage that to some
   extent represents the combination of those.  It is proposed that in
   these cases the following actions are taken:

   - All the response codes are collected
   - Each response code are translated into the corresponding LDAPv3
     resultcode.
   - A resultcode is chosen to represent the collected response on the
     following grounds:
       If "success" is the only resultcode represented after these steps
       the return that result code.
       If apart from "success" there is one other resultcode represented
       return that other resultcode.
       If apart from "success" there are two or more resultcodes
       represented return the resultcode "other".

5.10 Whois++ DAG-SAP

5.10.1 Input

   The Whois++ DAG-SAP expects valid DAG/IP communications.  Queries
   must include referral information (see below) and search terms that
   conform to the DAG-allowed query types (e.g., not searches for
   organization alone, etc).

   The referral information is added to the end of the DAG-SAP query, as
   defined in the DAG-CAP definition sections:

   ":host=" quoted-hostname ";port=" number ";server-info="
   quoted-serverinfo ";charset=" charset





Daigle & Hedberg             Informational                     [Page 57]

RFC 2967                         TISDAG                     October 2000


5.10.2 Translation from DAG/IP to Whois++ query

   The HOST and PORT information are used to make a TCP/IP-based
   connection to the remote (presumed) Whois++ server.  The query
   expressed to the remote Whois++ server is the remainder of the DAG/IP
   query the Whois++ DAG-SAP received, with the following template ID
   translations:

   template=DAGPERSON becomes template=USER

   and

   template=DAGROLE becomes template=ORGROLE

   Additional mappings for attributes are defined in Appendix B.

   Note that the search types used in the DAG/IP are not all required by
   the Whois++ syntax.  Therefore, some Whois++ WDSPs may be using
   servers that do not support searches other than "exact" and "lstring"
   (the search types required by the Whois++ protocol standard).  The
   Whois++ DAG-CAP may

   - send the DAG/IP query as constructed (e.g., with
     "search=substring"), and pass back the "% 502 Search expression too
     complicated" from the WDSP's server,
     - translate the DAG/IP query into a construct using only these
     search types (which will yield incomplete results, as not all
     queries are expressible with those search types),
     - attempt to ascertain what search types are  supported by the
     remote server and reformulate using them (e.g., regular
     expressions).  This would work, but would entail an excessively
     complicated Whois++ DAG-SAP, and might not yield any better results
     if the remote server doesn't support any optional search types.

5.10.3 Translation of Whois++ results to DAG/IP

   Any referrals that the remote WDSP server returns are pursued,
   following the usual Whois++ (client) fashion, by the Whois++ DAG-SAP.

   If it is not possible to establish a Whois++ session with the remote
   server, or if the session is interrupted, before results are
   received, the DAG-SAP will itself return no results and an error
   message, including

   % 403 Information Unavailable<NL>






Daigle & Hedberg             Informational                     [Page 58]

RFC 2967                         TISDAG                     October 2000


   If the remote server issues any other Whois++ error message and does
   not yield any results, the remote server's error message will be
   included in the DAG-SAP's own error message; no results will be
   returned.

   If results are successfully received from the remote server, they
   will be expressed using the  DAG/IP -- essentially passing through
   all FULL response information received from the remote server, mapped
   into the DAGSchema using the mappings defined in Appendix A.

5.11 LDAPv2 DAG-SAP

5.11.1 Input

   The LDAPv2 DAG-SAP expects valid DAG/IP communications.  Queries must
   include referral information (see below) and search terms that
   conform to the DAG-allowed query types (e.g., not searches for
   organization alone, etc).

   The referral information is added to the end of the DAG-SAP query, as
   defined in the DAG-CAP definition sections (as additional terms in
   the DAG/IP query):

   ":host=" quoted-hostname ";port=" number ";server-info="
   quoted-serverinfo ";charset=" charset

5.11.2 Translation from DAG/IP to LDAPv2 query

   The HOST and PORT information are used to make a TCP/IP-based
   connection to the remote (presumed) LDAPv2 server.  The DAG-SAP will
   establish a connection with the remote server, following standard
   LDAPv2 message exchanges.

   The search request itself will be constructed from the DAG/IP query
   (without the HOST, SERVER-INFO and PORT terms) as follows:

   SearchRequest ::=
    [APPLICATION 3] SEQUENCE {
        baseObject    LDAPDN,  -- from the DAG/IP query
        scope         baseObject            (0) },
        derefAliases  ENUMERATED {
                              neverDerefAliases     (0),
                              derefInSearching      (1),
                              derefFindingBaseObj   (2),
                              derefAlways           (3)

                         },
        sizeLimit     INTEGER (0 .. maxInt),



Daigle & Hedberg             Informational                     [Page 59]

RFC 2967                         TISDAG                     October 2000


        timeLimit     INTEGER (0 .. maxInt),
        attrsOnly     FALSE
        filter        Filter,
        attributes    SEQUENCE OF AttributeType
                           -- all DAGschema attributes
                              equivalents in  the defined
                              standard LDAP schema
   }

   Filter ::=
    CHOICE {
        and                [0] SET OF Filter,
        or                 [1] SET OF Filter,
        not                [2] Filter,
        substrings         [4] SubstringFilter,
    }

   SubstringFilter
    SEQUENCE {
        type               AttributeType,

        SEQUENCE OF CHOICE {
        substrings    initial [0] LDAPString,
        substrings    any     [1] LDAPString,
        substrings    final   [2] LDAPString}
    }

   where and, or and not filters are constructed to preserve the logic
   of the DAG/IP query.

   For the purposes of matching token-based DAG/IP queries to reasonable
   LDAP queries, all searches should be passed to the LDAP WDSP as
   substring searches.  The WDSP results must then be pruned to respect
   token boundaries, where necessary.

   So, for example,  the DAG/IP query

   FN=Foo\ Bar and ORG=Thinking\ Cat:search=substring<NL>

   would be sent to the designated LDAP WDSP as

   (& (fn=*Foo Bar*) (o=*Thinking Cat*) (objectclass=person))

   Interestingly, the query

   FN=Foo\ Bar and ORG=Thinking\ Cat:search=exact<NL>

   would also be sent to the designated LDAP WDSP as



Daigle & Hedberg             Informational                     [Page 60]

RFC 2967                         TISDAG                     October 2000


   (& (fn=*Foo Bar*) (o=*Thinking Cat*) (objectclass=person))

   but the WDSPs returned results would have to be pruned to remove any
   results that had non-tokenizing characters on either side of "Foo
   Bar" and "Thinking Cat".

   The final consideration for mapping DAG/IP queries into LDAP queries
   is the issue of character case.  In LDAP, individual attribute
   syntaxes define the consideration of case.  All of the attributes
   used here are case-insensitive in their definitions.  Therefore, all
   LDAP WDSP queries are inherently case-insensitive; if the DAG/IP
   query calls for a case-sensitive match, the LDAP DAG-SAP will have to
   do pruning of the results from the DAG-SAP.

5.11.3 Translation of LDAPv2 results to DAG/IP

   If it is not possible to establish an LDAPv2 session with the remote
   server, or if the session is interrupted before results are received,
   or if the remote server issues any kind of error message and produces
   no result, the DAG-SAP will itself return no results and an error
   message, including

   % 403 Information Unavailable<NL>

   If results are successfully received from the remote server, the
   attributes and values that are provided for each result message will
   be incorporated into the DAG/IP result, according to the schema
   mappings laid out in Appendix B.

   One particular adjustment must be done to accommodate differences
   between LDAP and the DAG/IP.  The attributes on which searches are
   keyed ("cn", "l", and "o" in the LDAP schemas) are all defined as
   being case-insensitive for equality matching.  Thus, if the DAG/IP
   query includes the constraint "case=consider", the results from the
   remote server must be post-processed to remove any wrong-cased ones.

      TISDAG: The serverhandle and localhandle in the DAG/IP response
      should be constructed as follows:

   serverhandle is: <hostname-without-periods><port> (because
       server DN's are not enforceably unique).  E.g., a
       services.bunyip.com server on 7778 would
       become servicesbunyipcom7778.
     localhandle is:  the RDN (relative distinguished name), with
       spaces replaced by "_".  E.g., cn=leslie_daigle






Daigle & Hedberg             Informational                     [Page 61]

RFC 2967                         TISDAG                     October 2000


5.12 LDAPv3 DAG-SAP

5.12.1 Input

   The LDAPv3 DAG-SAP expects valid DAG/IP communications.  Queries must
   include referral information (see below) and search terms that
   conform to the DAG-allowed query types (e.g., not searches for
   organization alone, etc).

   The referral information is added to the end of the DAG-SAP query, as
   defined in the DAG-CAP definition sections:

   ":host=" quoted-hostname ";port=" number ";server-info="
   quoted-serverinfo ";charset=" charset

5.12.2 Translation from DAG/IP to LDAPv3 query

   The HOST and PORT information are used to make a TCP/IP-based
   connection to the remote (presumed) LDAPv3 server.  The DAG-SAP will
   establish a connection with the remote server, following standard
   LDAPv3 message exchanges.

   The search request itself will be constructed from the DAG/IP query
   (without the HOST, SERVER-INFO and PORT terms) as follows:

   SearchRequest ::=
    [APPLICATION 3] SEQUENCE {
        baseObject    LDAPDN,  -- from the DAG/IP query
        scope         baseObject            (0) },
        derefAliases  ENUMERATED {
                                neverDerefAliases     (0),
                                derefInSearching      (1),
                                derefFindingBaseObj   (2),
                                derefAlways           (3)
                              },
        sizeLimit     INTEGER (0 .. maxInt),
        timeLimit     INTEGER (0 .. maxInt),
        attrsOnly     FALSE
        filter        Filter,
        attributes    SEQUENCE OF AttributeType
                      -- all DAGschema attributes equivalents in
                         the defined standard LDAP schema
   }

   Filter ::=
    CHOICE {
        and                [0] SET OF Filter,
        or                 [1] SET OF Filter,



Daigle & Hedberg             Informational                     [Page 62]

RFC 2967                         TISDAG                     October 2000


        not                [2] Filter,
        substrings         [4] SubstringFilter,
    }

   SubstringFilter
    SEQUENCE {
        type               AttributeType,
        SEQUENCE OF CHOICE {
        substrings    initial [0] LDAPString,
        substrings    any     [1] LDAPString,
        substrings    final   [2] LDAPString}
    }

   where and, or and not filters are constructed to preserve the logic
   of the DAG/IP query.

   For the purposes of matching token-based DAG/IP queries to reasonable
   LDAP queries, all searches should be passed to the LDAP WDSP as
   substring searches.  The WDSP results must then be pruned to respect
   token boundaries, where necessary.

   So, for example,  the DAG/IP query

   FN=Foo\ Bar and ORG=Thinking\ Cat:search=substring<NL>

   would be sent to the designated LDAP WDSP as

   (&(fn=*Foo Bar*)(o=*Thinking Cat*)(objectClass=person))

   Interestingly, the query

   FN=Foo\ Bar and ORG=Thinking\ Cat:search=exact<NL>

   would also be sent to the designated LDAP WDSP as

   (&(fn=*Foo Bar*)(o=*Thinking Cat*)(objectClass=person))

   but the WDSP's returned results would have to be pruned to remove any
   results that had non-tokenizing characters on either side of "Foo
   Bar" and "Thinking Cat".

   The final consideration for mapping DAG/IP queries into LDAP queries
   is the issue of character case.  In LDAP, individual attribute
   syntaxes define the consideration of case.  All of the attributes
   used here are case-insensitive in their definitions.  Therefore, all
   LDAP WDSP queries are inherently case-insensitive; if the DAG/IP
   query calls for a case-sensitive match, the LDAP DAG-SAP will have to
   do pruning of the results from the DAG-SAP.



Daigle & Hedberg             Informational                     [Page 63]

RFC 2967                         TISDAG                     October 2000


5.12.3 Translation of LDAPv3 results to DAG/IP

   Any referrals that the remote WDSP server returns are pursued,
   following the usual LDAPv3 (client) fashion, by the LDAPv3 DAG-SAP.

   If it is not possible to establish an LDAPv3 session with the remote
   server, or if the session is interrupted before results are received,
   or if the remote server issues any kind of error message and produces
   no result, the DAG-SAP will itself return no results and an error
   message, including

   % 403 Information Unavailable<NL>

   If results are successfully received from the remote server, the
   attributes and values that are provided for each result message will
   be incorporated into the DAG/IP result, which will be expressed using
   the DAG/IP and schema mappings as outlined in Appendix A.

   One particular adjustment must be done to accommodate differences
   between LDAP and the DAG/IP.  The attributes on which searches are
   keyed ("cn", "l", and "o" in the LDAP schemas) are all defined as
   being case-insensitive for equality matching.  Thus, if the DAG/IP
   query includes the constraint "case=consider", the results from the
   remote server must be post-processed to remove any wrong-cased ones.

      TISDAG: The serverhandle and localhandle in the DAG/IP response
      should be constructed as follows:

      - serverhandle is: <hostname-without-periods><port> (because
        server DN's are not enforceably unique).  E.g., a
        services.bunyip.com server on 7778 would become
        servicesbunyipcom7778.
      - localhandle is:  the RDN (relative distinguished name), with
        spaces replaced by "_".  E.g., cn=leslie_daigle

5.13 Example Queries

   The following sample end-user queries illustrate some of the more
   delicate steps of query/schema semantics translations in the DAG
   system.

   N.B.:  the data presented in these examples is often senseless,
   provided only to serve as illustrations of matching on word-ordering,
   case sensitivity, etc.







Daigle & Hedberg             Informational                     [Page 64]

RFC 2967                         TISDAG                     October 2000


5.13.1 A Whois++ Query

   What the Whois++ DAG-CAP Receives

   In this example, the Whois++ DAG-CAP receives the following query:

   name=thinking and name=cat:search=exact;case=consider<NL>

   The expected answer can be described as:

   Any USER templates that contain the tokens "thinking" and "cat" in a
   name attribute.

   For example:

   Different records:

   name: the thinking cat
   name: sublime cat thinking

   or a single record with 2 or more name attributes

   name: thinking felines
   name: erudite cat

   but not

   name: Thinking Cat Enterprises

   This last record would not match because the query called for case
   sensitivity, and the case of the name attribute's value does not
   match the query.

   What the Whois++ DAG-CAP sends to the Referral Index

   After schema translation, this is sent to the Referral Index as:

   fn=thinking and fn=cat:search=exact<NL>

   What the Whois++ DAG-CAP Sends to an LDAP DAG-SAP

   Note that the Whois++ DAG-CAP will never interact with a Whois++
   DAG-SAP as the Whois++ referrals returned by the Referral Index are
   passed directly back to the Whois++ client.

   The Whois++ DAG-CAP should send the same substantive query to the
   DAG-SAP as it sent to the Referral Index, except that it can include
   the case sensitivity constraint:



Daigle & Hedberg             Informational                     [Page 65]

RFC 2967                         TISDAG                     October 2000


   fn=thinking and fn=cat:search=exact;case=consider<NL>

   which will be translated by the DAG-SAP into an LDAP query of the
   form:

   (&(cn=*thinking*)(cn=*cat*)(objectclass=inetOrgPerson))

   which will match a record with:

   cn: Thinking
   cn: Cat

   (i.e., 2 different cn attributes, with the 2 values; LDAP defines
   case sensitivity matching by the schema attribute definition).

   or a record with:

   cn: I wish I had a thinking dog and a singing cat

   The first record should be pruned by the LDAP DAG-SAP, in order to
   respect the semantics of the DAG/IP query.

5.13.2 An LDAP Query

   What the LDAP DAG-CAP Receives

   In this example, the LDAP  DAG-CAP receives the following query
   (using RFC1960 notation):

   (& (cn=th*c*t) (o=green groceries) (objectClass=person))

   What the LDAP user is looking for, with this query, is all records
   within the "green groceries" organization that have a cn attribute
   starting with "th", ending with "t", and having a "c" somewhere in
   the middle.

   cn values that would match this include:

   cn: thinkingcat
   cn: Thinking Cat
   cn: The Black Cat
   cn: Thick Mat









Daigle & Hedberg             Informational                     [Page 66]

RFC 2967                         TISDAG                     October 2000


5.13.3 What the LDAP DAG-CAP sends to the Referral Index

   The LDAP DAG-CAP must formulate a token-based query to the Referral
   Index that will not inadvertently exclude records that would match.
   The first challenge lies in the fact that the "*" characters in the
   LDAP string-based query can cover token-boundaries.

   A suitable query to the Referral Index would be:

   FN=th AND FN=C AND FN=T AND ORG=green AND
   ORG=groceries:search=substring<NL>

   This will generate some false positive referrals, directing the query
   to WDSPs containing records with the following attribute values (the
   match letters are in capitals for ease of identification):

   cn: wiTH three blaCk poTs

   o: peaGREEN and cyan GROCERIES
   o: GROCERIES are GREENer than electronics

   Alternative approaches include breaking the original query into
   several queries to the referral index in such a way that the DAG-CAP
   can use only those referrals that appear in all the Referral Index
   responses.  However, this is

   overkill -- the purpose of the Referral Index is to give direction on
     where there may be more information

   difficult to code into the DAG-CAP in a general way -- it has to
     identify, by LDAP query type, when and how to do so

   likely to generate Referral Index queries that are complex and time-
   consuming to process.

   What the LDAP DAG-CAP Sends to a Whois++ DAG-SAP

   The LDAP DAG-CAP may send the same query to a Whois++ DAG-SAP as it
   sent to the Referral Index.  False positives here mean results that
   are not expected as a match by the LDAP client.  The LDAP DAG-CAP
   should prune these results from the information returned by the
   Whois++ DAG-SAP.

   Or it might rewrite the query into:

   FN=th;search=lstring AND FN=C;search=substring AND
   FN=T;search=tstring AND ORG=green AND ORG=groceries:case=ignore<NL>




Daigle & Hedberg             Informational                     [Page 67]

RFC 2967                         TISDAG                     October 2000


   What the LDAP DAG-CAP Sends to an LDAP DAG-SAP

   As an architectural principle, it is never wrong to send the same
   query to a DAG-SAP as was formulated for the Referral Index.  It is
   also noteworthy to keep in memory that all DAG-SAPs are handled equal
   by all DAG-CAPs therefore a LDAP DAG-CAP will not need to send a
   different query to a LDAP DAG-SAP then it would to any other DAG-SAP.

   So in this case the LDAP DAP-CAP could either send the same query to
   the LDAP DAG-SAP as it sent to the Referral Index or it could send
   the augmented version that is allowed to be use with the DAG-SAPs,
   namely:

   FN=th;search=lstring AND FN=C;search=substring AND
   FN=T;search=tstring AND ORG=green\ groceries:case=ignore<NL>

   Note that this will be translated, by the LDAP DAG-SAP, into a query
   of the form

   (&(cn=*th*)(cn=*c*)(cn=*t*)(o=*green groceries*)
   (objectClass=person))

   which is still more general than the original query.

   Note the translation from "FN=th;search=lstring" into "cn=*th*".
   This is necessary, as the DAG/IP lstring constraint is based on
   tokens, whereas "cn=th*" refers to the beginning of the attribute's
   value (phrase, not token).  The DAG-SAP should therefore prune out
   any results that include things like "oTHer plaCes for visiTors" in
   order to match the semantics of the DAG/IP query it received.

   The DAG-CAP should then prune those results to match the semantics of
   the original LDAP query.

6.0 Service Specifications

6.1 Overview

   To satisfy the requirements laid out for the TISDAG project, the
   software built for the DAG system must be able to meet the following
   service specifications:

   - primary designated DAG-CAPs of all types (but not necessarily
     secondary ones set up for load-balancing) must be available to
     provide service or redirect queries on a 7x24 basis.






Daigle & Hedberg             Informational                     [Page 68]

RFC 2967                         TISDAG                     October 2000


   - in general, responses to queries should be available in under 10
     seconds; very generalized queries (i.e., when the user truly cannot
     specify enough information to focus the search) can be deferred to
     take much longer (having results is more important than having a
     quick answer)
   - the data provided from each WDSP should be updated in the DAG at
     least once every 7 days

6.2 WDSP Participation

   WDSPs who wish to participate in the DAG system do so by providing
   DAG-compatible access to their service, where DAG-compatible means:

   - access in (exactly) one of LDAPv2, LDAPv3, or Whois++
     - 7x24 service for responding to referrals generated in the DAG
     core (minimally) weekly updates of the index object describing the
     information their service indexes
     - use of USER and ROLE templates for Whois++ servers
     - use of inetorgperson and organizationalrole objectclasses for
     LDAP servers

   To participate, WDSPs must register each DAG-compliant server with
   the DAG system, providing details for each data set that it covers:

   - the host, port and protocol of the server
     - an identifier for the dataset
     - a URL for the service of preference for accessing the data
     (preferred source)
     - protocol-specific information
     - administrative contact information
     - CIP object exchange information

   Note that any WDSP wishing to make data available through the DAG
   system but unable to support these requirements may provide
   information through an agreement with a third-party which does meet
   these requirements.  Thus, data can be replicated between cooperating
   WDSPs.  The DAG referral index does not claim ownership of personal
   information; it directs queries to services that do, by whatever
   agreements with whichever relevant parties.  Note that, in this case,
   the SOURCE-URI may direct end-users to the WDSP's existing services,
   not the service of the third party.

6.3 Load Distribution

   It is anticipated that the DAG system will be quite popular, and
   measures must be available to distribute the load of answering
   queries.




Daigle & Hedberg             Informational                     [Page 69]

RFC 2967                         TISDAG                     October 2000


   The DAG system is presented as a conceptual whole, made up of several
   component parts -- DAG-CAPs, DAG-SAPs and the Referral Index.  Each
   of these component parts must be replicable, and service must be
   shared between replicas.

   It may be interesting to consider allowing large-scale service
   providers (large companies, ISPs)  the ability to mirror the Referral
   Index or provide alternate DAG-CAPs/DAG-SAPs for their
   personnel/customers.  Policies and possibilities for doing that are
   beyond the scope of this report; however, the software architecture
   has been designed to support such activity.

   Figure 6.1 shows that individual components of the DAG system may
   each run on non-co-located server hardware, connected by TCP/IP
   networks.  These components can be replicated as needed.




































Daigle & Hedberg             Informational                     [Page 70]

RFC 2967                         TISDAG                     October 2000


   +====+
   |    |  DAG-CAP (Client Access Point)
   |    |
   +====+
   +----+
   |    |  DAG-SAP (Service Access Point)
   |    |
   +----+
              +====+
   HTTP   <-->|    |
              |    |                +----+
              +====+                |    |<--> Whois++
                                    |    |
                 +====+             +----+
      SMTP   <-->|    |
                 |    |          +----+
                 +====+          |    |<--> LDAPv2
                                 |    |
                    +====+       +----+
         Whois++<-->|    |
                    |    |
                    +====+             +----+
                                       |    |<--> LDAPv3
                                       |    |
                                       +----+
                                       |    |<--> LDAPv3
                                       |    |
                                       +----+
                                       |    |<--> LDAPv3
                                       |    |
                 +====+                +----+
      LDAPv2 <-->|    |
                 |    |
                 +====+
              +====+
   LDAPv3 <-->|    |
              |    |
              +====+
               +------------------------+
               | Referral Index         |<--> Common Indexing Protocol
               |                        |     (CIP)
               +------------------------+
         +------------------------+
         | Referral Index         |
         |                        |
         +------------------------+

   Figure 6.1 Distributable nature of DAG components



Daigle & Hedberg             Informational                     [Page 71]

RFC 2967                         TISDAG                     October 2000


   Thus, the software built to this specification must be configurable
   to permit the following actions:

   - DAG-CAP software must be able to handle or redistribute the primary
     load.  Depending on the DAG-CAP software, this may be handled by
     having multiple processes attending to incoming queries, or the
     DAG-CAP at the primary address for the protocol may be nothing more
     than a reflector that redirects incoming queries to the address of
     the least-loaded server at the moment.
   - This is particularly necessary in synchronous connection protocols,
     such as Whois++ and LDAP, where the goal is to minimize the amount
     of time a requesting client is connected to the well-advertised
     address port.
   - DAG-CAP software must be able to direct referrals to different
     DAG-SAPs of the same protocol type.
   - DAG-CAP software must be able to detect overly general queries
     (i.e., have some metric to decide that the number of referrals
     generated by the Referral Index is too great).
   - DAG-SAPs must be able to redirect DAG-CAP queries at their
     discretion, or just refuse service because of loading (therefore
     DAG-CAPs must also be able to find other DAG-SAPs)

6.4 Extensibility

   The DAG system has been designed to allow for extensibility in
   certain key areas:

   It is possible to add new DAG-CAPs and DAG-SAPs transparently.
   Beyond replicating the software of existing DAG-CAPs, new
   implementations for particular protocols (e.g., building a more
   elaborate mail-based query system), or implementations for altogether
   different protocols (e.g., PH) can be added by adhering to the basic
   principles of DAG-CAPs and DAG-SAPs defined in the software
   specification.  The new DAG-CAP is responsible for the translation of
   queries into DAG/IP (post-processing results, if necessary) and
   results in the new protocol.  No other part of the DAG system is
   affected.

   More functionality may be added to the DAG system service (e.g.,
   adding security certificate references to the schema of returned
   information) by updating the DAG schema.

   Depending on how the load on the service goes, it may be interesting
   to consider reducing the number of queries that are chained for
   protocols that inherently can handle the concept of pursuing
   referrals.  Specifically, LDAPv3 and Whois++ both handle referrals,
   but the current system calls for chaining LDAPv3 (and LDAPv2)
   referrals for the Whois++ DAG-CAP, and vice versa.  Alternatively,



Daigle & Hedberg             Informational                     [Page 72]

RFC 2967                         TISDAG                     October 2000


   "virtual" DAG-CAPs could be established for each participating WDSP
   for each protocol the WDSP doesn't support, and referrals to those
   DAG-CAPs could be given to the calling client.  For example, a
   Whois++ client would be given a Whois++ referral to the virtual
   Whois++ DAG-CAP for a WDSP that supports only LDAP.  The importance
   of having one virtual DAG-CAP per WDSP is that the point of
   connection is the only way to distinguish which WDSP the Whois++
   client thought it was connecting to.

7.0 Security

7.1 Information credibility

   Security, in the context of "read-only" directory services, is
   primarily concerned with maintaining data integrity as it passes from
   an originating server to the end-user making an inquiry.  That is,
   some server(s) hold correct user information, and a client accessing
   a directory service should be certain that whichever servers that the
   information has to pass through before reaching the client, it
   receives a true representation of the original information.

   The DAG system as such MUST be completely invisible as the mediator
   of the information from the WDSPs to the querying directory access
   client.  The only possible modifications that can appear is
   translations from one characterset into another.  Hopefully, this
   does not alter the meaning of the information.

7.2 Unauthorized access

   In keeping with the public nature of the proposed TISDAG service, the
   DAG system does not provide any access control system beyond
   components' configuration to accept connections from recognized other
   components.  For more detailed access control, it is up to the
   connected WDSPs to apply the access control.

   Since the DAG system only supports searching and retrieving
   information, no updates can occur through the DAG client access
   points.

   Security in updates (CIP index objects) is provided by encryption and
   signature of objects from registered WDSPs.










Daigle & Hedberg             Informational                     [Page 73]

RFC 2967                         TISDAG                     October 2000


8.0 Acknowledgments

   This work came from ideas originally put forward by Patrik Faltstrom.
   The TISDAG project was supported by the Swedish KK Foundation.

   Thanks to especially to Jens Lundstrom, Thommy Eklof, Bjorn Larsson
   and Sandro Mazzucato for their comments on draft versions of this
   document.











































Daigle & Hedberg             Informational                     [Page 74]

RFC 2967                         TISDAG                     October 2000


Appendix A - DAG Schema Definitions

   The DAG makes use of 2 information schemas -- the DAGPERSON schema
   for information about specific people, and the DAGORGROLE schema for
   organizational roles that may or may not be job positions occupied by
   people at any given time (e.g., an organization's president, customer
   service desk, etc).

   This appendix defines the schemas in terms of the attributes used
   within the DAG/IP.  Mappings to the standard LDAP and Whois++ object
   classes and templates (respectively) are described in Appendix B.

   Because the role of the DAG schemas is to act as an intermediary
   between information provided in different access protocols, with
   different underlying schema paradigms, the attributes in the schema
   are identified as being required or optional.  The required
   attributes are so designated because they are involved in the DAG
   search types and/or the minimal returned response.  They have defined
   mappings in the selected access protocols.  The optional attributes
   have proposed mappings in those protocols.

   It is important to note that the DAG/IP is constructed to carry any
   alternative attribute information that may be provided by a given
   WDSP; individual DAG-SAPs and DAG-CAPs may choose to pass along,
   interpret, or ignore any attributes not defined in this appendix.

   Additionally, note that the order of attributes in the DAG/IP is
   significant, which means that it is possible to use one attribute to
   carry the information describing the type of subsequent ones (e.g.,
   see the "ADR-TYPE" attribute below).

   Finally, attributes may be repeated.  For example, this schema
   structure can carry  multiple phone numbers of different types for
   one person.

















Daigle & Hedberg             Informational                     [Page 75]

RFC 2967                         TISDAG                     October 2000


A.1 DAG Personal Information Schema (DAGPERSON Schema)

   Attribute    Designation   Specific Description
   ---------    -----------   -------------------------------------
   FN           Required      Free-text representation of full name
   EMAIL        Required      Internet e-mail address
   LOC          Required      Locality -- geographic region
   ORG          Required      Person's organization
   ADR-TYPE     Optional      Type of address that follows
                              ("org", "home", "org-postal",
                              "home-postal", "unqualified")
   ADR          Optional      Full address
   ADR-STREET   Optional      Street address component
   ADR-ROOM     Optional      Suite or room number component
   ADR-CITY     Optional      City name
   ADR-STATE    Optional      Region of address
   ADR-COUNTRY  Optional      Country
   ADR-CODE     Optional      Postal code component
   TEL-TYPE     Optional      Type of telephone number (
                              "work",  "home", "mobile",
                              "fax" ,"pager", "unqualified")
                              in the following attribute
   TEL          Optional      A phone number for the person
   SOURCE       Optional      The WDSP's preferred  access to
                              their service -- a URL
   DN           Optional      Entry's "distinguished name"
                              (for LDAP)

      Table A.1 DAGPERSON schema attributes






















Daigle & Hedberg             Informational                     [Page 76]

RFC 2967                         TISDAG                     October 2000


A.2 DAG Organizational Role Information Schema (DAGORGROLE Schema)

   Attribute   Designation     Specific Description
   ---------   -----------     ---------------------
   ROLE        Required        Name of organizational role
   EMAIL       Required        E-mail address associated with role
   ORG         Required        Name of organization
   LOC         Required        Locality -- geographic region
   TEL-TYPE    Optional        Type of telephone number
                               in the TEL attribute immediately
                               following("org" or "fax")
   TEL         Optional        Phone number

   FN          Optional        Full name of current role occupant
   SOURCE      Optional        The WDSP's preferred  access to their
                                service -- a URL
   DN          Optional        Entry's "distinguished name" (for LDAP)

   Table A.2 DAGORGROLE schema attributes

Appendix B - Schema Mappings for Whois++ and LDAP

   The DAG/IP makes use of two specific schemas, as defined above.
   However, schemas particular to access protocols need to be handled in
   order to appropriately address incoming user queries, and chaining
   queries to WDSPs.  The recognized standard schemas are:

   - the USER template for Whois++ ([8])
   - the ORGROLE template for Whois++ ([8])
   - the inetOrgperson objectclass for LDAP ([16])
   - the organizationalrole objectclass for LDAP ([18])

   The DAG/IP schemas were developed based on the information that the
   TISDAG project requirements wish to return in results, in conjunction
   with information about standard schemas used in the basic WDSP access
   protocols (LDAPv2/v3 and Whois++).  However, particularly in the case
   of address information, the schemas used for those protocols allow
   for considerable scope of information representation.  In practice,
   this means that different WDSPs may choose to use different sub-parts
   of the schema, or even implement local customizations.

   Therefore, Appendix A outlines a very basic schema that can carry all
   the necessary information.  The basic DAG-CAPs and DAG-SAPs are
   designed to work to that information structure.  This appendix
   outlines the expected behaviour for DAG-SAPs mapping into the DAG/IP
   schema, and DAG-CAPs extracting information to pass along to client
   software after a chaining operation has returned results.




Daigle & Hedberg             Informational                     [Page 77]

RFC 2967                         TISDAG                     October 2000


B.1 LDAP and the DAG Schemas

   The only time information is carried in the DAG schemas is when a
   DAG-SAP is returning information (obtained from  WDSPs' servers) to a
   DAG-CAP using the DAG/IP.  The "canonical" mappings between standard
   LDAP object classes (inetorgPerson, defined in [16] and
   organizationalRole, defined in [18] and the DAGPERSON schema and
   DAGORGROLE schema are defined such that information passed from an
   LDAP DAG-SAP to an LDAP DAG-CAP (e.g., in the case of an LDAPv3 DAG-
   SAP returning information chained for an LDAPv2 DAG-CAP) will be
   mapped into the same attributes as it was extracted.

   However, the representation of some attributes (such as address) is
   truly widely varied between protocol paradigms.  The goal with the
   "reasonable approximation" mappings that are provided is to give
   DAG-CAPs a basic mechanism for communicating information drawn from
   non-LDAP DAG-SAP sources.  The mappings may not be perfect, but they
   will convey the information to the end-user in some LDAP-
   understandable fashion, which is the goal of this project's effort.

   The canonical mappings for the LDAP inetorgPerson object class and
   the DAGPERSON schema are given in Table B.1.  A few reasonable
   approximation mappings follow in Table B.2.  Beyond that, DAG-SAPs
   may pass along any additional attributes in the DAG/IP, and DAG-CAPs
   may elect to forward or interpret any that are recognizable (e.g.,
   the sn ("surname") attribute is not listed here, but a DAG-SAP might
   return that in the DAG/IP, and a DAG-CAP, recognizing the string
   representation, could elect to include it in its LDAP response to the
   client).

   DAGPERSON Attribute     LDAP inetorgPerson attribute
   -------------------     ----------------------------
   FN                      cn
   EMAIL                   mail
   LOC                     l
   ORG                     o

   ADR-TYPE=org
   ADR-STREET              street
   ADR-ROOM                roomNumber
   ADR-STATE               st
   ADR-COUNTRY             c

   ADR-TYPE=org-postal
   ADR                     postalAddress
   ADR-ROOM                postOfficeBox
   ADR-CODE                postalCode




Daigle & Hedberg             Informational                     [Page 78]

RFC 2967                         TISDAG                     October 2000


   ADR-TYPE=home-postal
   ADR                     homePostalAddress

   TEL-TYPE=work
   TEL                     telephoneNumber

   TEL-TYPE=home
   TEL                     homePhone

   TEL-TYPE=fax
   TEL                     facsimileTelephoneNumber

   TEL-TYPE=mobile
   TEL                     mobile

   TEL-TYPE=pager
   TEL                     pager

   DN                      dn
   SOURCE                  labeledURI

   Table B.1 Canonical DAGPERSON schema & LDAP inetorgPerson attributes

   DAGROLE Attribute        LDAP organizationalRole attribute
   -----------------------  ---------------------------------
   ADR-TYPE=unqualified
   ADR                      street
   ADR-STREET               street
   ADR-ROOM                 room
   ADR-STATE                st
   ADR-COUNTRY              c

   TEL-TYPE=unqualified
   TEL                      telephoneNumber

   Table B.2 Reasonable Approximations for LDAP organizationalRole
   attributes














Daigle & Hedberg             Informational                     [Page 79]

RFC 2967                         TISDAG                     October 2000


   For example, consider the following LDAP record information, in LDIF
   [11] format:

   dn: cn=Barbara Jensen, ou=Product Development, o=Ace Industry,
   c=US
   objectclass: top
   objectclass: person
   objectclass: organizationalPerson
   objectclass: inetorgperson
   cn: Barbara Jensen
   cn: Barbara J Jensen
   cn: Babs Jensen
   sn: Jensen
   uid: bjensen
   telephonenumber: +1 408 5551212
   description:  A big sailing fan

   This would validly be carried in the DAGPERSON schema as follows:

   DN: cn=Barbara Jensen, ou=Product Development, o=Ace Industry,
   c=US
   FN: Barbara Jensen
   FN: Barbara J Jensen
   FN: Babs Jensen
   SN: Jensen
   TEL-TYPE: work
   TEL:  +1 408 5551212

   The canonical mappings for the LDAP organizationalRole object class
   and the DAGORGROLE schema are given in Table B.3 .Beyond that, DAG-
   SAPs may elect to send along any attributes, and DAG-CAPs may
   interpret any that are recognizable.  N.B., the organizationalRole
   class does not include provision for inclusion of an e-mail address.
   This mapping rather blithely assumes the availability of the mail
   attribute as defined for inetorgPerson.
















Daigle & Hedberg             Informational                     [Page 80]

RFC 2967                         TISDAG                     October 2000


   DAGORGROLE Attribute   LDAP organizationalRole attribute
   --------------------   ---------------------------------
   ROLE                   cn
   EMAIL                  mail
   ORG                    o
   LOC                    l

   TEL-TYPE=org
   TEL                    telephoneNumber

   TEL-TYPE=fax
   TEL                    facsimileNumber

   FN                     roleOccupant
   DN                     dn
   SOURCE                 labeledURI

   Table B.3 Canonical mappings for LDAP organizationalRole attributes

B.2 Whois++ and the DAG Schemas

   The "canonical" mappings between standard Whois++ templates as
   defined in [8] and the DAGPERSON schema and DAGORGROLE schema are
   defined in Tables B.4 and B.5.  Beyond that, DAG-SAPs may pass along
   any additional attributes in the DAG/IP, and DAG-CAPs may elect to
   forward or interpret any that are recognizable.

   DAGPERSON Attribute   Whois++ USER template attribute
   -------------------   -------------------------------
   FN                    name
   EMAIL                 email
   LOC                   address-locality
   ORG                   organization-name

   ADR-TYPE=unqualified
   ADR                   address

   ADR-TYPE=org
   ADR                   organization-address
   ADR-STREET            organization-address-street
   ADR-ROOM              organization-address-room
   ADR-CITY              organization-address-city
   ADR-STATE             organization-address-state
   ADR-COUNTRY           organization-address-country
   ADR-CODE              organization-address-zip-code






Daigle & Hedberg             Informational                     [Page 81]

RFC 2967                         TISDAG                     October 2000


   ADR-TYPE=home         address-type=home
   ADR                   address
   ADR-STREET            address-street
   ADR-ROOM              address-room
   ADR-CITY              address-city
   ADR-STATE             address-state
   ADR-COUNTRY           address-country
   ADR-CODE              address-zip-code

   TEL-TYPE=work         phone-type=work
   TEL                   phone

   TEL-TYPE=home         phone-type=home
   TEL                   phone

   TEL-TYPE=fax
   TEL                   fax

   TEL-TYPE=mobile
   TEL                   cellular

   TEL-TYPE=pager
   TEL                   pager

   Table B.4 Canonical DAGPERSON schema & Whois++ USER attributes

   DAGORGROLE Attribute       Whois++ ORGROLE attribute
   --------------------       -------------------------
   ROLE                       org-role
   EMAIL                      email
   ORG                        organization-name
   LOC                        organization-address-locality
   FN                         name

   TEL-TYPE=org
   TEL                        phone

   TEL-TYPE=fax
   TEL                        fax

   Table B.5 Canonical mappings for Whois++ ORGROLE attributes

Appendix C - DAG-Internal Protocol (DAG/IP)

   The DAG-Internal Protocol (DAG/IP) is currently defined as a
   derivative of the query-interaction protocol of Whois++ as laid out
   in RFC1835 ([6]).




Daigle & Hedberg             Informational                     [Page 82]

RFC 2967                         TISDAG                     October 2000


C.1 A word on the choice of DAG/IP

   The use of the DAG/IP is strictly internal to the DAG system.  In
   that regard, it is possible make use of any query language, or define
   a new one.

   The Whois++ protocol was selected as the basis of the DAG/IP for
   several reasons:

   - it has the power and flexibility to convey all necessary queries
   - it is a simple, text-based protocol; clients need not implement the
     full functionality of the protocol in order to carry out minimal
     queries
   - the power of the full-fledge directory service query protocol will
     give DAG-CAP writers the ability to express more sophisticated
     queries if desired (e.g., to produce more intricate "intelligent"
     matching of spellings, common character substitutions, etc).
   - the text-based, delimited attribute results expression facilitates
     optional inclusion of  extra data supplied by WDSPs -- DAG-CAPs can
     easily ignore any unknown information and continue to interpret the
     rest of the result information.

   Also, the use of an existing protocol leverages the experience and
   time of the creators of the protocol -- hammering out such elusive
   and yet necessary details as handling line-endings, quoting special
   characters, etc.

   There is a freely-available test suite of tools for testing servers'
   Whois++ protocol conformance (for the Referral Index, and for DAG-
   SAPs).  Send mail to digger-info@bunyip.com for further information.

C.2 DAG/IP Input and Output -- Overview

   Input interactions in DAG/IP are as defined in RFC1835, "Architecture
   of the WHOIS++ service" ([6]), sections 2.2 and 2.3.  Section C.3 of
   this document adapts the grammar used in more recent descriptions of
   the Whois++ protocol to illustrate the syntax of the DAG/IP.

   DAG/IP output will be a subset of what is defined in RFC1835, section
   2.4, except that referral responses ("SERVER-TO-ASK") contain more
   information.

C.3 BNF for DAG/IP input and output

   The following sections are adapted from the Whois++ grammar.  For
   discussion of the semantic intent of the query protocol, and other
   matters, see Whois++ RFC 1835 [6].




Daigle & Hedberg             Informational                     [Page 83]

RFC 2967                         TISDAG                     October 2000


C.3.1 The DAG/IP Input Grammar

   The following grammar, which uses the Augmented BNF (ABNF) notation
   as defined in [5], defines the set of acceptable DAG/IP input.

   N.B.:  As outlined in the ABNF definition, rule names and string
   literals are in the US-ASCII character set, and are case-insensitive.
   Also,  when a character is written explicitly in the grammar, as for
   example ";", it represents the byte value of that character in all of
   the allowed character sets in their encodings used in this protocol.
   Specifically in UNICODE, ";" means the character U+003B, which when
   encoding the character in UTF-8 will generate the byte value 0x3B
   which is then used in the DAG/IP protocol.

   dagip-command   = ( system-command [":" "hold"]
                 / ri-query
                 / sap-query ) nl

   ri-query        =   ri-terms [":" globalcnstrnts]

   sap-query       =   sap-terms [":" [sapcnstrnts][ ":" wdspinfo]]

   system-command =   "constraints"
                   / "describe"
                   / "commands"
                   / "polled-by"
                   / "polled-for"
                   / "version"
                   / "list"
                   / "show" [1*sp datastring]
                   / "help" [1*sp datastring]
                   / "<NL>" [string]

   ri-terms       =   ri-and-expr *(1*sp "or" 1*sp ri-and-expr)

   ri-and-expr    =   ri-basic-expr *(1*sp "and" 1*sp ri-basic-
   expr)

   ri-basic-expr  =   ["not" 1*sp] ri-term / ( "(" ri-terms ")" )

   ri-term        =   generalterm / specificterm / combinedterm

   sap-terms       =   sap-and-expr *(1*sp "or" 1*sp sap-and-expr)

   sap-and-expr    =   sap-basic-expr *(1*sp "and" 1*sp
                       sap-basic-expr)

   sap-basic-expr  =   ["not" 1*sp] sap-term / ( "(" sap-terms ")" )



Daigle & Hedberg             Informational                     [Page 84]

RFC 2967                         TISDAG                     October 2000


   sap-term        =   ( generalterm / specificterm / combinedterm)
                       localcnstrnts

   generalterm     =   datastring

      TISDAG: Since the DAG system only supports certain attribute
      combinations in its queries, (Table 3.1).  The use of generalterm
      may lead to unexpected behaviour and is therefore deprecated.
      CAPs should therefore not use it even if it is in the protocol.

   specificterm    =   specificname "=" datastring

   specificname    =   "handle" / "value"

   combinedterm    =   attributename "=" datastring

   sapcnstrnts     =   sapcnstrnt *(";" sapcnstrnt)

   sapcnstrnt      =   localcnstrnt / globalcnstrnt

   localcnstrnts   =   [";search=" sap-searchvalue] [";case="
                       sap-casevalue]

   localcnstrnt    =   "search=" sap-searchvalue / "case="
                       sap-casevalue

      ;N.B.:  in the case where local and global constraints
      ;       conflict, local constraints take precedence
      ;       and overrides the global constraint

   sap-searchvalue =   "tstring" / searchvalue

   sap-casevalue   =   "consider" / "ignore"

   globalcnstrnts  =   globalcnstrnt *(";" globalcnstrnt)

   globalcnstrnt   =   "search" "=" searchvalue
                    / opt-globalcnst

   opt-globalcnst  =   "hold"
                    / "case" "=" casevalue
                    / "maxfull" "=" 1*digit
                    / "maxhits" "=" 1*digit
                    / "language" "=" language
                    / "incharset" "=" characterset
                    / "ignore" "=" attributename
                    / "include" "=" attributename




Daigle & Hedberg             Informational                     [Page 85]

RFC 2967                         TISDAG                     October 2000


   ; N.B.: If an attribute is named both with the "include" and "ignore"
   ; constraints, the attribute is to be included in the result, but the
   ; system message must be "% 112 Requested constraint not fulfilled".

   language        = <The language code defined in RFC1766>

   characterset    =   "UNICODE-2-0-UTF-8"

   searchvalue     =   "exact" / "substring" / "lstring"

   casevalue       =   "ignore" / "consider"

   wdspinfo        =   attrValAss *( ";" attrValAss )

   attrValAss      =   attributename "=" datastring

      TISDAG: Within the boundaries of the TISDAG project it has been
      decided that the only permitted attributes for wdspinfo are
      "host","port","server-info" and "charset".  Regarding "charset"
      the values for this attribute are defined to be one of "UTF-8",
      "ISO8859-1","T\.61" or "US-ASCII".

   datastring      =   1*data-elt

   attributename   =   1*(<%d32-126 except specialbyte>)
                         ; omit 127, which is DEL

   data-elt        =   "\" specialbyte / normalbyte

   normalbyte      =   <%d32-255, except specialbyte>

   specialbyte     =   " " / tab / "=" / "," / ":" / ";" / "\" /
                    "*" / "." / "(" / ")" / "[" / "]" / "^" /
                    "$" / "!" / "<NL>"

   number          =   1*digit

   digit           =   "0" / "1" / "2" / "3" / "4" /
                    "5" / "6" / "7" / "8" / "9"

   tab             =   %d09
   sp              =   %d32                ; space
   nl              =   %d13 %d10           ; CR LF








Daigle & Hedberg             Informational                     [Page 86]

RFC 2967                         TISDAG                     October 2000


   NOTE: Spaces (sp) that are significant to a query must be escaped.
   The following characters, when significant to the query, may  be
   preceded and/or followed by a single space:
     : ; , ( ) = !

C.3.2 The DAG/IP Response Grammar

   The following grammar, which uses the Augmented BNF (ABNF) notation
   as defined in RFC2234 (see [5]),

   N.B.:  As outlined in the ABNF definition, rule names and string
   literals are in the US-ASCII character set, and are case-insensitive.
   Also,  when a character is written explicitely in the grammar, as for
   example ";", it represents the byte value of that character in all of
   the allowed character sets in their encodings used in this protocol.
   Specifically in UNICODE, ";" means the character U+003B which when
   encoding the character in UTF-8 will generate the byte value 0x3B
   which is then used in the DAG/IP protocol.

   server-resp     =   goodmessage mnl output mnl endmessage
                    / badmessage nl endmessageclose

   output          =   0*(full-record / server-to-ask)

   full-record     =   "# FULL " template " " serverhandle " "
                          localhandle system-nl
                    1*fulldata
                     "# END" system-nl

      TISDAG: serverhandle is:

      - Whois++, whatever the server-handle on the record returned by
        the WDSP.
      - LDAP, <hostname-without-periods><port> (because server DN's are
        not enforceably unique).  E.g., a services.bunyip.com server on
        7778 would become servicesbunyipcom7778.

      localhandle is:
      - Whois++:  the localhandle on the record returned by the WDSP
      - LDAP, it is the RDN (relative  distinguished name), with spaces
        replaced by "_".  E.g., cn=leslie_daigle

   server-to-ask   =   "# SERVER-TO-ASK " serverhandle system-nl
                    server-to-askdata
                    "# END" system-nl

   fulldata        =   " " attributename ": " attributevalue
   system-nl



Daigle & Hedberg             Informational                     [Page 87]

RFC 2967                         TISDAG                     October 2000


   server-to-ask-data = " Server-Info: " serverinfo system-nl
                     " Host-Name: " hostname system-nl
                     " Host-Port: " number system-nl
                     " Protocol: " prot system-nl
                     " Source-URI: " source system-nl
                     " Charset: " characterset system-nl

   attributename   =   r-string

   attributevalue  =   longstring

   template        =   <%d32-%d255 except specialbyte>

   serverhandle    =   <%d32-%d255 except specialbyte>

   localhandle     =   <%d32-%d255 except specialbyte>

   serverinfo      =   string

   hostname        =   string

   prot            =   string ; currently one of "ldapv2"
                           ; "ldapv3" "whois++"

   characterset    =   "UTF-8" / "T.61" / "ISO8859-1" / "US-ASCII"

   source          =   string

   longstring      =   string 0*( nl ( "+" / "-" ) string )

   string          =   0*(%d32-255)

   r-string        =   0*(<%d32-126 except specialbyte>)
                        ; omit 127 which is DEL

   specialbyte     =   ":" / " "

   mnl             =   1*system-nl

   system-nl       =   nl [ 1*(message nl) ]

   nl              =   %d13 %d10    ; CR and LF

   message         =   [1*( messagestart "-" string nl)]
                    messagestart " " string nl

   messagestart    =   "% " digit digit digit




Daigle & Hedberg             Informational                     [Page 88]

RFC 2967                         TISDAG                     October 2000


   goodmessage     =   [1*( goodmessagestart "-" string nl)]
                    goodmessagestart " " string nl

   goodmessagestart=   "% 200"

   badmessage      =   [1*( badmessagestart "-" string nl)]
                    badmessagestart " " string nl

   badmessagestart =   "% 5" digit digit

   endmessage      =   endmessageclose / endmessagecont

   endmessageclose =   [endmessagestart " " string nl]
                    byemessage

   endmessagecont  =   endmessagestart " " string nl

   endmessagestart =   "% 226"

   byemessage      =   byemessagestart " " string nl

   byemessagestart =   "% 203"

   number          =   1*( digit )

   digit           =   "0" / "1" / "2" / "3" / "4" / "5" / "6" /
                    "7" / "8" / "9"

C.4 DAG/IP Response Messages

   The following list and discussion of response codes is derived from
   the Whois++ protocol definition, RFC1835 ([6]).

   A system message begins with a '%', followed by a space and a three
   digit number, a space, and an optional text message.  The line
   message must be no more than 81 bytes long, including the terminating
   CR LF pair.  There is no limit to the number of system messages that
   may be generated.

   A multiline system message have a hyphen instead of a space in column
   6, immediately after the numeric response code in all lines, except
   the last one, where the space is used.

   Example 1

   % 200 Command okay

   Example 2



Daigle & Hedberg             Informational                     [Page 89]

RFC 2967                         TISDAG                     October 2000


   % 220-Welcome to
   % 220-the Whois++ server
   % 220 at ACME inc.

   The client is not expected to parse the text part of the response
   message except when receiving reply 600 or 601, in which case the
   text part is in the former case the name of a character set that will
   be used by the server in the rest of the response, and in the latter
   case when it specifies what language the attribute value is in.  The
   valid values for characters sets is specified in the "characterset"
   list in the BNF listing in Appendix C.

   The theory of reply codes is described in Appendix E in STD 10,
   RFC821 ([15]).

   System response code           Description

   ----------------------------   ------------------------------
   110 Too many hits              The number of matches exceeded
                                  the value specified by the
                                  maxhits constraint.  Server
                                  will still reply with as many
                                  records as "maxhits" allows.

   111 Requested constraint not   One or more constraints in query
       supported                  is not implemented, but the
                                  search is still done.

   112 Requested constraint not   One or more constraints in query
       fulfilled                  has unacceptable value and was
                                  therefore not used, but the
                                  search is still done.

   200 Command Ok                 Command accepted and executed.
                                  The client must wait for a
                                  transaction end system message.

   201 Command Completed          Command accepted and executed.
       successfully

   203 Bye                        Server is closing connection










Daigle & Hedberg             Informational                     [Page 90]

RFC 2967                         TISDAG                     October 2000


   204 Overgeneralized            The server could not exactly
                                  match the DAG query into its
                                  native access protocol.  The
                                  resulting native query was
                                  "looser".

   220 Service Ready              Greeting message.  Server is
                                  accepting commands.

   226 Transaction complete       End of data.  All responses to
                                  query are sent.

   401 Service not available

   402 Search expression
       too complicated

   403 Information Unavailable    When a remote service is not
                                  (currently) available.

   404 Time out

   500 Syntax error

   502 Search expression too      This message is sent when the
       complicated                server is not able to resolve a
                                  query (i.e. when a client sent a
                                  regular expression that is too
                                  deeply nested).

   503 Query to general           This is like the "too many hits"
                                  situation, but the server does
                                  not send along any results.  This
                                  message is used to deflect data
                                  mining.

   505 Operations error           Permanent operations error

   600 <token>                    Subsequent attribute values are
                                  encoded in the character set
                                  specified by <token>.

   601 <token>                    Subsequent attribute values are
                                  in the language specified by
                                  <token>.






Daigle & Hedberg             Informational                     [Page 91]

RFC 2967                         TISDAG                     October 2000


   601 DEF                        Subsequent attribute values are
                                  default values, i.e. they should
                                  be used for all languages not
                                  specified by "601 <token>" since
                                  last "601 ANY" message.

   601 ANY                        Subsequent attribute values are
                                  for all languages.

   Table C.1 List of system response codes









































Daigle & Hedberg             Informational                     [Page 92]

RFC 2967                         TISDAG                     October 2000


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



Daigle & Hedberg             Informational                     [Page 93]

RFC 2967                         TISDAG                     October 2000


 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



Daigle & Hedberg             Informational                     [Page 94]

RFC 2967                         TISDAG                     October 2000


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 | "-" | ";" | "."



Daigle & Hedberg             Informational                     [Page 95]

RFC 2967                         TISDAG                     October 2000


   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.





Daigle & Hedberg             Informational                     [Page 96]

RFC 2967                         TISDAG                     October 2000


   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.







Daigle & Hedberg             Informational                     [Page 97]

RFC 2967                         TISDAG                     October 2000


   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]):



Daigle & Hedberg             Informational                     [Page 98]

RFC 2967                         TISDAG                     October 2000


   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.



Daigle & Hedberg             Informational                     [Page 99]

RFC 2967                         TISDAG                     October 2000


     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.





Daigle & Hedberg             Informational                    [Page 100]

RFC 2967                         TISDAG                     October 2000


   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











Daigle & Hedberg             Informational                    [Page 101]

RFC 2967                         TISDAG                     October 2000


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.




Daigle & Hedberg             Informational                    [Page 102]

RFC 2967                         TISDAG                     October 2000


   [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.

















Daigle & Hedberg             Informational                    [Page 103]

RFC 2967                         TISDAG                     October 2000


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



































Daigle & Hedberg             Informational                    [Page 104]

RFC 2967                         TISDAG                     October 2000


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.



















Daigle & Hedberg             Informational                    [Page 105]