Architecture for Integrated Directory Services - Result from TISDAG
RFC 2970

Document Type RFC - Informational (October 2000; No errata)
Was draft-daigle-arch-ids (individual)
Authors Thommy Eklof , Leslie Daigle 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 2970 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          L. Daigle
Request for Comments: 2970                                      T. Eklof
Category: Informational                                     October 2000

  Architecture for Integrated Directory Services - Result from TISDAG

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.


   A single, unified, global whitepages directory service remains
   elusive.  Nonetheless, there is increasing call for participation of
   widely-dispersed directory servers (i.e., across multiple
   organizations) in large-scale directory services.  These services
   range from national whitepages services, to multi-national indexes of
   WWW resources, and beyond.  Drawing from experiences with the TISDAG
   (Technical Infrastructure for Swedish Directory Access Gateways)
   ([TISDAG]) project, this document outlines an approach to providing
   the necessary infrastructure for integrating such widely-scattered
   servers into a single service, rather than attempting to mandate a
   single protocol and schema set for all participating servers to use.

1. Introduction

   The TISDAG project addressed the issue of providing centralized
   access to distributed information for whitepages information on a
   national scale.  The specification of the eventual system is
   presented in [TISDAG], and [DAGEXP] outlines some of the practical
   experience already gained in implementing a system of this scale and
   nature.  [DAG-Mesh] considers the issues and possibilities of
   networking multiple DAG services.  Following on from those, this
   document attempts to describe some of the architectural underpinnings
   of the system, and propose directions in which the approach can be
   generalized, within the bounds of applicability.

Daigle & Eklof               Informational                      [Page 1]
RFC 2970       Architecture for IDS - Result from TISDAG    October 2000

   The proposed architecture inserts a coordinated set of modules
   between the client access software and participating servers.  While
   the client software interacts with the service at a single entry
   point, the remaining modules are called upon (behind the scenes) to
   provide the necessary application support.  This may come in the form
   of modules that provide query proxying, schema translation, lookups,
   referrals, security infrastructure, etc.

   Part of this architecture is an "internal protocol" -- called the
   "DAG/IP" in the TISDAG project.  This document also outlines the
   perceived requirements for this protocol in the extended DAG.

2.0 Some terminology

   Terms used in this document are compliant with those set out in
   [ALVE]. For the purposes of this document, important distinctions and
   relationships are defined between applications, services, servers and
   systems.  These are defined as follows:

   Application:  this is meant in the general sense, as a solution to a
     particular (set of) user need(s).  That is, the definition is not
     tied to a particular piece of software (as in "application

     The definition of an application includes the type(s) of
     information to be exchanged, expected behavior, etc.  Thus, a
     whitepages (search) application may expect to receive a name as
     input to a query engine, and will return all information associated
     with the name.  By contrast, a specific security application might
     use the same input name to verify access controls.

   Service:  an operational system providing (controlled) access to
     fulfill a particular application's needs.

     One service may be changed by configuring location, access
     controls, etc.  Changing application means changing the service.

   Server:  a single component offering access through a dedicated
     protocol, without regard to a specific service (or services) it may
     be supporting in a given configuration. Typically programmed for a
     particular application.

   System:  a set of components with established interconnections.

     Thus, a service can be split between several servers.  A collection
     of services (independently, or interrelated through specified
     agreements) act as an implementation of an application.  A system
     is composed of one or more servers and services.

Daigle & Eklof               Informational                      [Page 2]
RFC 2970       Architecture for IDS - Result from TISDAG    October 2000

     A "system architecture" identifies specific software components,
     their behavior, communication channels and messages needed to
     fulfill a particular service's needs.  The TISDAG specification
     [TISDAG] includes just such a description, defining a software
Show full document text