RFC relevance of following

As per Relevance of the word following, we have this rfc below:

Network Working Group L.
Request for Comments: 2967 Thinking Cat
Category: Informational R.

October 2000

TISDAG - Technical Infrastructure
Swedish Directory Access

Status of this

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

Copyright

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

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

Table of

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
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 (
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

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
attributes . . . . . . . . . . . . . . . . . . . . . . . . . .79
Table B.2 Reasonable Approximations for LDAP
attributes . . . . . . . . . . . . . . . . . . . . . . . . . .79
Table B.3 Canonical mappings for LDAP
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
mapping. . . . . . . . . . . . . . . . . . . . . . . . . . . .93
Table D.2 Mapping from DAG/IP response codes to LDAPv2/v
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:
Information. . . . . . . . . . . . . . . . . . . . . . . . . 101

1.0

1.1 Project

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

1.2 Executive Summary of Technical Study

The strength of the TISDAG project's DAG proposal is that it
the necessary technical infrastructure to provide a single-access
point service for information on Swedish Internet users.
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
information made available, irrespective of the service
responsible for maintaining that information, their directory
protocols, or the end-user's client access protocol

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

1.3 Document

This document is broken into 5 major sections

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

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

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

Software Specifications: This section provides the specifications
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,
success of the DAG system will rest on its
characteristics. Details of service requirements are given in
section

1.4

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

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

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

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

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

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

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

2.0

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

- End-
-

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

Daigle & Hedberg Informational [Page 7]

RFC 2967 TISDAG October 2000

2.1 End-User

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

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

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

- Full
- E-mail
-
-
-
- Full
- Telephone

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

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

2.2 WDSPs

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

The DAG system must provide reasonable assurances of data
for WDSPs; the information the End-User sees should
directly to that provided by the WDSPs. The DAG system should
non-preferential in providing whitepages information -- the
is to the End-User, and the source of whitepages information
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
reasonable time after receipt from WDSPs; on the flip side, while
DAG system will function best with regular updates from WDSPs,
update and participation overhead for WDSPs should be held
reasonable bounds of what the WDSP should do to support
access to its information

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

2.3 DAG-System

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

The system must be implementable/operational by Dec 31/98 --
implies that it must be designed and constructed with already
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
at the outset, with a view to handling larger information systems
the future

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

3.0 Functional

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

TISDAG: This is a TISDAG

3.1

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

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

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
service; it maintains the necessary data and
facilities to permit the smooth connection of diverse
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
be made available, and diversity of its sources (different WDSPs
introduce challenges in terms of finding a structure that will
efficient searching, and facilitate the timeliness of updating
necessary information

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

This specification will outline the following areas

- the functioning of the DAG core
- the interface between the DAG core and End-Users' Directory
Access
- the interface between the DAG core and Directory Services

3.2 The DAG

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

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

Daigle & Hedberg Informational [Page 10]

RFC 2967 TISDAG October 2000

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

End Client DAG Directory
Users Software System Server
Core Software

Figure 3.1 The role of the DAG

3.3 Client

The DAG will respond to End-User queries

- e-mail (SMTP
- WWW (HTTP
- LDAPv
- Whois++
- LDAPv

The DAG will provide responses including the agreed-upon data.
access protocols that can handle referrals, responses will be
and/or referrals in that query protocol. These are Whois++
LDAPv3. N.B.: the LDAPv3 proposal defines a referral as a URL;
limitation is placed on the access protocol. However it cannot
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

User Input is defined in terms

- Searchable
- Matching
- Character

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

Supported Query

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

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

Table 3.1 DAG-supported

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

Matching

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

Daigle & Hedberg Informational [Page 12]

RFC 2967 TISDAG October 2000

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

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

Character

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

Specifically

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

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

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

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

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

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

Daigle & Hedberg Informational [Page 13]

RFC 2967 TISDAG October 2000

3.3.2 Data Output

Schema

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

Individual DAG-CAPs define how they express this schema

Referral

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

Error

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

- unrecognized
- too many

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

3.4 Directory Server

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

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

Daigle & Hedberg Informational [Page 14]

RFC 2967 TISDAG October 2000

4.0

4.1 Software

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

4.1.1 Internal

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

- the DAG-CAPs' range of query ability in the Referral Index (
gather referrals in response to the end-user's requests
- the responses (and their formats) of the Referral Index to
DAG-CAP
- the DAG-CAPs' range of query ability to the DAG-SAPs for
referrals when the DAG-CAP needs to do chaining for the
access
- 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
of the DAG-CAP--Referral Index and DAG-CAP--DAG-SAP interactions
given in the definitions of individual DAG-CAPs and DAG-SAPs,
(Sections 5.5 through 5.12).

4.1.2 Referral

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

4.1.3 DAG-

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

Daigle & Hedberg Informational [Page 15]

RFC 2967 TISDAG October 2000

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

All internal communications are in DAG/IP

Figure 4.1 Conceptual Architecture of the

Daigle & Hedberg Informational [Page 16]

RFC 2967 TISDAG October 2000

4.1.4 DAG-

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

4.2 Important Architectural

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

4.2.1 2 Distinct Functions: Referrals and

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

4.2.2 Limited Query and Response

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

4.2.3

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

Daigle & Hedberg Informational [Page 17]

RFC 2967 TISDAG October 2000

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

4.2.4 Richness of Query

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

4.2.5 N+M Protocol

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

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

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

4.2.7 The Role of the DAG-

Thus, the DAG-CAP is responsible for using the DAG/IP to
referral information and, where necessary, chained responses.
necessary, it performs adjustments to accommodate the differences
semantics between the DAG/IP and its native protocol. This
involved doing post-filtering of the results returned by the DAG-
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,
the DAG/IP

Daigle & Hedberg Informational [Page 18]

RFC 2967 TISDAG October 2000

4.2.8 The Role of the DAG-

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

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

4.2.9 DAG/IP is

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

4.2.10

The expectation is that the DAG system, although defined as a
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
it will operate on inter-machine communications

4.2.11 Future

The DAG system architecture was constructed with a specific view
extensibility. At any time, an individual component may be
(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
access protocols -- for end-users, and for WDSPs

5.0 Software

5.1 Notational

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

Daigle & Hedberg Informational [Page 19]

RFC 2967 TISDAG October 2000

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

is used. For example

This is an example of a very long line of input. There is only
newline in it (at the end), in spite of the fact that this
shows it spanning several lines of text.
5.2 DAG-CAP

5.2.1

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

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

The DAG-CAP is then responsible for

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

Each DAG-CAP defines the nature of the interaction with the end-
(e.g., synchronous or asynchronous, etc). Additionally, each DAG-
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 (
load-balancing

Daigle & Hedberg Informational [Page 20]

RFC 2967 TISDAG October 2000

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

DAG-CAPs must be capable of accepting and respecting DAG-SAP
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.,
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,
help, answers those on its own. A CAP should not pass any
command on to the RI

5.2.2

It must be possible to change the expected address of the DAG-CAP
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,
each type (protocol) of DAG-SAP that is needed, the DAG-CAP must
configurable in terms of

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

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

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

5.2.3 Error

Apart from error conditions arising from the operation of the DAG-
itself, DAG-CAPs are responsible for communicating error
occurring elsewhere in the system that affect the outcome of
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
message, it should attempt to match the the received DAG
into its native access protocol's error codes. The same action
appropriate when the DAG-CAP is "chaining" the query to one DAG-SAP

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

See Appendix D for more information concerning error
message mappings

5.2.4 Pruning of

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

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

5.3 DAG-SAP

5.3.1

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

The DAG-SAP is then responsible

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

Daigle & Hedberg Informational [Page 22]

RFC 2967 TISDAG October 2000

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

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

5.3.2

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

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

5.3.3 Error

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

5.3.4 Pruning of

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

5.3.5 Constraint

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

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

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

Daigle & Hedberg Informational [Page 23]

RFC 2967 TISDAG October 2000

5.4 The Referral

5.4.1

The Referral Index contains (only) information necessary to
referrals to DAG-CAPs based on the query types supported by the
itself. The Referral Index creates an index over these objects
that it can respond to DAG-CAP queries using the DAG/IP.
information is drawn directly from interactions with
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
themselves (see Section 5.4.6). Once registered, the Referral
will interact with the WDSPs using the Common Indexing Protocol
defined in [1], using the Index Object defined in Section 5.4.3.

5.4.3 Index Object

The CIP index object type is based on the Tagged Index Object
defined in [12]. Appendix E details the expected content of
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/

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

5.4.5 The Index

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

The semantics of the chosen CIP object (defined in Appendix E)
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/
query,
- 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
Flintstone", but not to a WDSP with 2 differently tagged records,
"Fred Amadeus" and "Julie Flintstone". Depending on the
protocol being used and the original end-user query, the referral
the WDSP with "Fred Amadeus Flintstone" may yield a
result, or it may not. But, it is known that the other WDSP
not have yielded successful searches. That is, the referral
may yield false-positive results, but will not miss
WDSPs

5.4.6

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

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

5.4.7

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

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

5.5 Mail (SMTP) DAG-

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

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

Daigle & Hedberg Informational [Page 25]

RFC 2967 TISDAG October 2000

5.5.1 Mail DAG-CAP

Mail DAG-CAP input is expected to be a regular or MIME-encoded (
[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
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
lower case for convenience, but could be upper case or mixed case
input

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

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

n = n-
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
o-term = [msp] "org" [msp] "=" [msp] string

Daigle & Hedberg Informational [Page 26]

RFC 2967 TISDAG October 2000

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

string = printable
ISO-8859-1 or UTF-8 except nl and sp
msp = 1*(sp
sp = " "
mnl = 1*(nl

nl =
The following are valid mail queries

Example 1:

searchtype = name = thinking cat
Example 2:

searchtype = exact ignore name=thinking cat
Example 3:

role=thinking cat org =space colonization
Example 4:

name=thinking cat My signature line follows here in the most
fashion
Note that the following are not acceptable queries

Example 5:

searchtype= exact substring name = thinking cat
Example 6:

name=thinking cat org= freedom fighters anonymous

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/

Querying the Referral

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

name= thinking cat
is tokenized into 2 n-tokens

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

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

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

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

dag-matchtype = "search=" /
"search=substring" ; if matchtype
;

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

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

The terms for the DAG/IP query are constructed from the
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
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-
nl-query = dag-n-terms " and " dag-l-
no-query = dag-n-terms " and " dag-o-
nol-query = dag-n-terms " and " dag-o-terms " and "
dag-l-
ro-query = dag-r-terms " and " dag-o-
rol-query = dag-r-terms " and " dag-o-terms " and "
dag-l-

The examples given earlier are then translated as follows

Example 1:

FN=thinking and FN=cat:search=substring;case=ignore
Example 2:

FN=thinking and FN=cat:search=exact;case=ignore
Example 3:

ROLE=thinking and ROLE=cat and ORG=space
ORG=colonization:search=substring;case=ignore
Querying a DAG-

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

Daigle & Hedberg Informational [Page 29]

RFC 2967 TISDAG October 2000

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

where the response from the Referral Index included

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

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

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

For example, the

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

: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
the SERVER-TO-ASK response).

Note that it is the DAG-SAP's responsibility to extract these
from the query and use them to identify the WDSP server to
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-

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

5.5.4 Expression of results in Mail DAG-

The results message is sent to the "Reply-To:" address of
originating mail, if available (see [4] for
interpretation of mail originator headers). The original query
repeated, along with the message-id. The remainder of the body
the mail message is the concatenation of responses from the DAG-
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
(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-

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

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

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

A mail DAG-CAP may redirect a connection to another mail DAG-CAP
reasons of load-balancing. This is done simply by forwarding
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-

5.6.1 Web DAG-CAP

The web DAG-CAP provides its interface via standard HTTP protocol
The general expectation is that the web DAG-CAP will provide a
page with radio buttons to select "substring or exact match"
"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
of the form action for the page described above, or
elsewhere). The rest of this section describes the variables
are to be expressed in that post. The actual layout of the page
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
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
referrals, through the use of two extra variables this client
given the option of requesting referral information and then
individual referrals through the Web DAG-CAP itself, as a proxy
those referrals. This is handled through the extra "
variables" to request referrals only, and to indicate when
transaction is a continuation of a previous query to pursue
referral

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

Daigle & Hedberg Informational [Page 32]

RFC 2967 TISDAG October 2000

The variables that are expected are

transaction = "new" / "chain" ; default is "new".
; should not be user-settable. It is
; in constructed
resulttype = "all" / "referrals" ; default is "all
matchtype = "substring" / "exact
casetype = "case ignore" / "case sensitive
n-term =
o-term =
l-term =
r-term =
host-term =
port-term =
servinfo-term =
prot-term = string ; the protocol of the
string = / /

5.6.2 Translation from Web query to DAG/

Querying a DAG-SAP

If the transaction variable is "chain", the information in the
is used to pursue a particular referral, not do a search of
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.,
referrals).

Querying the Referral

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

name= thinking

is tokenized into 2 n-tokens

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

FN=thinking and FN=

Daigle & Hedberg