doc: Add RFC documents

1 files changed, 1011 insertions, 0 deletions

diff --git a/doc/rfc/rfc2970.txt b/doc/rfc/rfc2970.txt
new file mode 100644
index 0000000..b5b62e7
--- /dev/null
+++ b/doc/rfc/rfc2970.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+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.
+
+Abstract
+
+   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
+     program").
+
+     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
+     system that will meet the needs of a national whitepages directory
+     service.  Here, we outline some of the general principles which
+     lead to that specific system architecture and discuss ways in which
+     the principles can be applied in other contexts.
+
+     Looking at this bigger picture, we present a "service
+     architecture", or a framework for assembling components into
+     systems that meet the needs of a wider variety of services.  This
+     is not a question of developing one or more new protocols for
+     services, but rather to examine a useful framework of
+     interoperating components.  The goal is to reduce the overall
+     number of (specialized) protocols that are developed requiring
+     incorporation of some very general concepts that are common to all
+     protocols.
+
+3.0  TISDAG -- a first implementation, and some generalizations
+
+   The Swedish TISDAG project (described in detail in [TISDAG], with
+   some experiences reported in [DAGEXP]) was designed to fulfill the
+   requirements of a particular national directory service.   The
+   experience of developing component-based system for providing a
+   directory service through a uniform interface (client access point)
+   provided valuable insight into the possibilities of extending the
+   system architecture so that services with different base requirements
+   can benefit from many of the same advantages.
+
+3.1 Deconstructing the TISDAG architecture
+
+   In retrospect, we can describe the TISDAG system architecture in
+   terms of 3 key requirements and 4 basic design principles:
+
+      R1. The service had to function with (several) existing client and
+          server software for the white pages application.
+
+      R2. It had to be possible to extend the service to accommodate new
+          client and server protocols if and when they became relevant.
+
+      R3. The service had to be easily reconfigurable -- to accommodate
+          more machines (load-sharing), etc.
+
+      D1. As a design principle, it was important to consider the
+          possibility that queries and information templates (schema)
+          other than the originally-defined set might eventually be
+          supported.
+
+
+
+Daigle & Eklof               Informational                      [Page 3]
+
+RFC 2970       Architecture for IDS - Result from TISDAG    October 2000
+
+
+      D2. As the architecture was already modular and geared towards
+          extensibility, it seemed important to keep in mind that the
+          same (or a similar) system could be applied to other (non-
+          white pages) applications.
+
+      D3. There is an "inside" and an "outside" to the service --
+          distinguishing between components that are accessible to the
+          world at large and those that are open only to other
+          components of the system.
+
+      D4. Internally, there is a single protocol framework for all
+          communications -- this facilitates service support functions
+          (e.g., security of transmission), ensures distributability,
+          and provides the base mechanism for allowing/ascertaining
+          interoperability of components.
+
+   The resulting system architecture featured modular component (types)
+   to fulfill a small number of functional roles, interconnected by a
+   generic query-response language.  The functional roles were defined
+   as:
+
+      CAPs -- "client access points" -- responsible for accepting and
+      responding to incoming requests through programmed and configured
+      behavior -- to translate the incoming query into some set of DAG-
+      internal actions (queries) and dealing with the responses,
+      filtering and recombining them in such a way as to fulfill the
+      client request within the scope of the service.  In the TISDAG
+      system, all CAPs are responsible for handling whitepages queries,
+      but the CAPs are distinguished by the application protocol in
+      which they will receive queries (e.g., LDAPv2, LDAPv3, HTTP, etc).
+      To the client software, the TISDAG system appears as a server of
+      that particular protocol.  In the more general case, CAPs may be
+      configured to handle different aspects of a service (e.g.,
+      authenticated vs.  non-authenticated access).  While the TISDAG
+      CAPs all had a simple control structure, the more general case
+      would also see CAPs drawing on different subsets of DAG (internal)
+      servers in order to handle different query types.  (See the
+      "Operator Service" example, in section 5.2 below).
+
+      SAPs -- "service access points" -- responsible for proxying DAG-
+      internal queries to specified services.  These are resources drawn
+      upon by other components within the system.  Through programmed
+      and configured behavior, they translate queries in the internal
+      protocol into actions against (typically external) servers, taking
+      care of any necessary overhead or differences in interaction
+      style, and converting the responses back into the internal
+      protocol.  In the TISDAG system, all SAPs are responsible for
+      handling whitepages queries, but they are distinguished by the
+
+
+
+Daigle & Eklof               Informational                      [Page 4]
+
+RFC 2970       Architecture for IDS - Result from TISDAG    October 2000
+
+
+      application protocol in which they will access remote services.
+      Further distinctions could be made based on the (remote service's)
+      schema mappings they handle, and other service differentiators.
+
+      Internal Servers respond to queries in the internal protocol and
+      provide specific types of information.  In the TISDAG system,
+      there is one internal server which provides referral information
+      in response to queries.
+
+   Note that all these components are defined by the functional roles
+   they play in the system, not the particular protocols they handle, or
+   even the aspect of the service they are meant to support.  That is, a
+   client access point is responsible for handling client traffic,
+   whether its for searching, establishing security credentials, or some
+   other task.
+
+3.2 Some generalizations
+
+   The Requirements and Design principles outlined above are not
+   particular to a national whitepages service.  They are equally
+   applicable in any application based on a query-response model, in
+   services where multiple protocols need to be supported, and/or when
+   the service requires specialized behavior "behind the scenes".  In
+   the TISDAG project, this last was inherent in the way the service
+   first looks for referrals, then makes queries as appropriate.  For
+   protocols that don't handle the referral concept natively, the TISDAG
+   system proxies the queries.
+
+   Because of its particular application to query-response situations,
+   the term "Directory Access Gateway", or "DAG" still fits as a label
+   for this type of system architecture.
+
+   Internet applications are evolving, and require more sophisticated
+   features (e.g., security mechanisms, accounting mechanisms,
+   integration of historical session data).  Continuing to develop a
+   dedicated protocol per application type results in encumbered and
+   unwieldy protocols, as each must implement coverage of all of these
+   common aspects.  But creating a single multi-application protocol
+   seems unlikely at best.  The implicit proposal here is that, rather
+   than overloading protocols to support multiple aspects of a service,
+   those aspects can be managed by breaking the service into multiple
+   supporting components to carry out the specialized tasks of
+   authentication, etc.
+
+
+
+
+
+
+
+
+Daigle & Eklof               Informational                      [Page 5]
+
+RFC 2970       Architecture for IDS - Result from TISDAG    October 2000
+
+
+3.3 A Word on DAG/IP
+
+   In the TISDAG project, the choice was made to use a single "internal
+   protocol" (DAG/IP).  The particular protocol used is not relevant to
+   the architecture, but the principle is important.  By selecting a
+   single query-response transaction protocol, the needs of the
+   particular application could be mapped onto it in terms of queries
+   and data particular to the application.  This makes the internal
+   communications more flexible for configuration to other environments
+   (services, applications).
+
+   It is common today to select an existing, widely deployed protocol
+   for transferring commands and data between client and server -- e.g.,
+   HTTP.  However, apart from any issues of the appropriateness (or
+   inappropriateness) of extending HTTP to this use, the work would have
+   remained to define all the transaction types and data types over that
+   protocol -- the specification of the interaction semantics and
+   syntax.
+
+3.4 Perceived benefits
+
+   Apart from the potential to divide and conquer service aspects, as
+   described above, this approach has many perceived benefits:
+
+      - For multi-protocol environments, it requires on the order of
+        N+M inter-protocol mappings, not NxM.
+      - distribution of development
+      - distribution of operation
+      - eventual possibilities of hooking together different
+        systems (of different backgrounds)
+      - separation of
+              - architectural principles
+              - implementation to a specific application
+              - configuration for a given service
+
+   It is not the goal to say that a standardized system architecture can
+   be made so that single components can be built for all possible
+   applications.  However, this approach in general permits the
+   decoupling of access protocols from specific applications, and
+   facilitates the integration of necessary infrastructure independently
+   of access protocol (e.g., referrals, security, lookup services,
+   distribution etc).
+
+
+
+
+
+
+
+
+
+Daigle & Eklof               Informational                      [Page 6]
+
+RFC 2970       Architecture for IDS - Result from TISDAG    October 2000
+
+
+4.0 Proposed service architecture
+
+   Pictorially, the DAG architecture is as follows:
+
+         +-------------------------------------------+
+     "a" |         |                +--------+       |
+   <----->  CAP a  |                | SAP A  |       |
+         |         |                |        |       |
+         |---------+                +-+------+---+   |
+         |                            |(Internal)|   |
+         |           "DAG/IP"         | Server i |   |
+         |                            +----------+   |
+         |                                           |
+         |                                           |
+         |                          +--------+       | "B"
+         |                          | SAP B  <-------------->
+         |                          |        |       |
+         |                          +--------+       |
+         |                                           |
+         +-------------------------------------------+
+
+   Note that the bounding box is conceptual -- all components may or may
+   not reside on one server, or a set of servers governed by the
+   provider of the service.
+
+   As we saw in the TISDAG project, the provider of this DAG-based
+   service may be only loosely affiliated with the remote services that
+   are used (Whitepages Directory Service Providers (WDSPs) in this
+   case).
+
+4.1 Using the architecture
+
+   Building a service on this architecture requires:
+
+   Service implementation:
+      1. definition of the overall application to be supported by the
+         system -- whitepages, web resource indexing, medical
+         information
+      2. requirements
+      3. expected behavior
+
+   System architecture:
+      1. nature of deployment -- distributed, security requirements,
+         etc.
+      2. identification of necessary CAPs -- in terms of access
+         protocols to be supported, different service levels to be
+         provided (e.g., secure and unsecure connections)
+
+
+
+
+Daigle & Eklof               Informational                      [Page 7]
+
+RFC 2970       Architecture for IDS - Result from TISDAG    October 2000
+
+
+      3. identification of necessary services -- e.g., proxying to
+         remote information search services, lookup services, "AAA[A]"
+         (Authentication, Authorization, Accounting, [and Access])
+         servers, etc
+      4. definition of the transaction process for the service:  insofar
+         as the CAPs represent the service to client software, CAP
+         modules manage the necessary transactions with other service
+         modules
+
+   Data architecture:
+
+      1. selection of schemas to be used (in each protocol)
+      2. definition of schema and protocol mappings -- into and out of
+         some DAG/IP representation
+
+5.0  Illustrations
+
+5.1 Existing TISDAG Project
+
+   Consider the TISDAG project in the light of the above definitions.
+
+   Service implementation:
+      1. A national-scale subset of Whitepages lookups, with specific
+         query types supported: only certain schema attributes were
+         permitted in queries, and the expected behavior was limited in
+         scope.
+      2. Requirements: the service had to support multiple query
+         protocols (from clients and for servers), and be capable of
+         searching the entire space of data without centralizing the
+         storage of records.
+      3. Given a query of accepted type, provide referrals to whitepages
+         servers that might have information to fulfill the query; if
+         necessary, proxy the referrals (chain) to retrieve the
+         information for the client.
+
+   System architecture:
+      1. distributable components
+      2. publicly accessible CAPs in HTTP, SMTP, Whois++, LDAPv2, and
+         LDAPv3
+      3. referral proxies to Whois++, LDAPv2 and LDAPv3 WDSPs, as well
+         as a referral query service
+      4. the basic transaction process, uniform across all CAPs, is:
+              - query the RI for relevant referrals
+              - where necessary, chain referrals through SAPs of
+                appropriate protocol return, in the native protocol, all
+                remaining referrals and data
+
+
+
+
+
+Daigle & Eklof               Informational                      [Page 8]
+
+RFC 2970       Architecture for IDS - Result from TISDAG    October 2000
+
+
+   Data architecture:  see the spec.
+
+   In the TISDAG project, the above diagram could be mapped as follows:
+
+      CAP a           LDAPv2 CAP
+      SAP A           the Referral Index (RI) interface
+      Server i        the Referral Index (RI)
+      SAP B           LDAPv3 SAP
+
+   Note that, in the TISDAG project specification, the designation SAP
+   referred exclusively to proxy components designed to deal with
+   external servers.  The Referral Index was considered an entity in its
+   own right.  However, generalizing the concepts of the TISDAG
+   experience lead to the proposal of regarding all DAG/IP-supporting
+   service components as SAPs, each designed to carry out a particular
+   type of service functionality, and whether the server is managed
+   internally to the DAG system or not is immaterial.
+
+5.2 Operator service
+
+   Consider the case of "number portability" -- wherein it is necessary
+   to determine the current service provider of a specific phone number.
+   The basic assumption is that phone numbers are assigned to be
+   globally unique, but are not in any way tied to a specific service
+   provider.  Therefore, it is necessary to determine the current
+   service provider for the given number before being able to retrieve
+   current information.  For the sake of our illustration, let us assume
+   that the management of numbers is two-tiered -- suppose the system
+   stores (internally) the mapping between these random digit strings
+   and the country in which each was originally activated, but relies on
+   external (country-specific) services to manage the updated
+   information about which service provider currently manages a given
+   number.  Then, the service data need only be updated when new numbers
+   are assigned, or national services change their access points.
+
+   We can look at a grossly-simplified version of the problem as an
+   illustration of some of the concepts proposed in this service
+   architecture.  We couple it with the "name search" facet of the
+   TISDAG example, to underscore that a single service ("operator") may
+   in fact be supported by several disjunct underlying activities.
+
+   Service implementation:
+      1. Retrieving service information for a particular (unstructured)
+         phone number digit sequence, or searching for numbers
+         associated with a particular name (or fragment thereof).
+      2. Requirements:  support IP-telephony through HTTP-based
+         requests, wireless device requests through WAP [WAP].
+
+
+
+
+Daigle & Eklof               Informational                      [Page 9]
+
+RFC 2970       Architecture for IDS - Result from TISDAG    October 2000
+
+
+      3. Expected behavior:  given a name (fragment), return a list of
+         names and numbers to match the fragment; given a phone number,
+         return appropriately-structured information re. the current
+         service mapping for that number.
+
+   System architecture:
+      1. Publicly accessible through CAPs; components widely
+         distributed.
+      2. Need one CAP for HTTP, one for WAP.
+      3. Support services include:  an internal service for lookup of
+         number strings (to identify nation of origin of the number), a
+         proxy to access national services for registration of numbers
+         and service providers, and a proxy for remote service provider
+         for retrieval of detailed information regarding numbers.  For
+         the name searching, we also need a referral index over the
+         names, and a proxy to whatever remote servers are managing the
+         whitepages directories.
+      4. Now, 2 different types of transaction are possible:  search for
+         name, or look-up a number.  In the name search case, the CAP
+         receives a name or name fragment, looks it up in the internal
+         referral index, and finds associated numbers through external
+         whitepages services (WDSPs).  To look-up a number, the CAP
+         first uses the internal look-up service to determine the
+         country of origin of the number, and then uses a SAP to access
+         that nation's number-service provider directory, and finally
+         uses a different SAP to access the current service provider to
+         determine the information required to make the call.
+
+   Data architecture:
+        [Out of scope for the purposes of this illustration]
+
+        Note that some elements of the system architecture are
+        deliberately vague.  Per the requirements, no structure is
+        expected in the number string, and therefore the lookup server
+        must maintain an index of number-to-country mappings and relies
+        on an external number-to-service mapping service (in each
+        country).  However, were there any structure to the numbers, the
+        lookup server could make use of that structure in the indexing,
+        or in distribution of the index itself.  This would have no
+        effect on the CAPs, which have no inherent reliance on how the
+        lookup server performs its task.
+
+
+
+
+
+
+
+
+
+
+Daigle & Eklof               Informational                     [Page 10]
+
+RFC 2970       Architecture for IDS - Result from TISDAG    October 2000
+
+
+        Pictorially, the example can be rendered as follows:
+
+         +-------------------------------------------+
+     "a" |         |                +--------+       |
+   <----->  CAP a  |                | SAP A  |       |
+         |         |                |        |       |
+         |---------+                +-+------+---+   |
+         |                            |(Internal)|   |
+         |           "DAG/IP"         | Server i |   |
+         |                            +----------+   |
+         |                                           |
+         |                          +--------+       | "B"
+         |                          | SAP B  <-------------->
+         |                          |        |       |
+         |                          +--------+       |
+         |                                           |
+         |                          +--------+       | "C"
+         |---------+                | SAP C  <-------------->
+     "b" |         |                |        |       |
+   <----->  CAP b  |                +--------+       |
+         |         |                                 |
+         |---------+                +--------+       |
+         |                          | SAP D  |       |
+         |                          |        |       |
+         |                          +-+------+---+   |
+         |                            |(Internal)|   |
+         |                            | Server j |   |
+         |                            +----------+   |
+         |                                           |
+         |                          +--------+       | "E"
+         |                          | SAP E  <-------------->
+         |                          |        |       |
+         |                          +--------+       |
+         +-------------------------------------------+
+
+   where
+
+      CAP a           HTTP CAP
+      CAP b           WAP CAP
+      SAP A           the number-nation lookup interface
+      Server i        number-nation lookup server (what country)
+      SAP B           nation-service lookup SAP (what service provider)
+      SAP C           service-number information lookup SAP (current
+                      service details)
+      SAP D           referral index interface
+      Server j        referral index service
+      SAP E           proxy for chaining queries to remote WDSPs
+
+
+
+
+Daigle & Eklof               Informational                     [Page 11]
+
+RFC 2970       Architecture for IDS - Result from TISDAG    October 2000
+
+
+5.3 Medical application
+
+   The service architecture is useful for applications outside the scope
+   of "telecoms".  In another hypothetical illustration, consider the
+   case of medical information -- records about patients that may be
+   created and stored at a variety of institutions which they visit.  It
+   is not unusual to need to access all information concerning a
+   patient, whether or not the person can recollect (or communicate)
+   conditions that were treated, procedures that were performed, or
+   medical institutions visited.  The data may include everything from
+   prescriptions, to X-rays and other images, to incident reports and
+   other elements of medical history, etc.  Typically, the information
+   is stored where it is collected (or by an agency authorized by that
+   institution) -- not in a central repository.  Any service that looks
+   to provide complete answers to queries must deal with these
+   realities, and clearly must function with a strong security model.
+
+   Service implementation:
+      1. Retrieving all medical information for a particular person.
+      2. Requirements:  must retrieve, or at least locate, all
+         available information, regardless of its storage location;
+         cannot require central repository of information; must
+         implement authorization and access controls.  Must
+         support a proprietary protocol for secure connections
+         within hospitals, wireless access for personnel in
+         emergency vehicles (not considered secure access).
+      3. Expected behavior:  given a patient's national ID, and
+         authorized access by medical personnel in secure locations,
+         determine what kinds of records are available, and where;
+         given a request for a specific type of record, retrieve
+         the record.  Given a patient's national ID, and authorized
+         access from a wireless device, provide information re.
+         any known medical flags (e.g., medicine allergies,
+         conditions, etc).
+
+   System architecture:
+      1. Only 2 CAP types are needed, but instances of these will
+         be established at major medical institutions.
+      2. Need one CAP to support the proprietary protocol, one
+         to support wireless access.
+      3. Support services include:  an internal server to support
+         security authentication and access control determination;
+         an internal server to act as referral index for finding
+         information pertinent to a particular patient, and one
+         or more proxies for accessing remote data storage servers.
+      4. The basic transaction requires that the first step be
+         to authenticate the end-user and determine access privileges.
+         In the case of wireless access, this last will not involve
+
+
+
+Daigle & Eklof               Informational                     [Page 12]
+
+RFC 2970       Architecture for IDS - Result from TISDAG    October 2000
+
+
+         a specific lookup, but rather will be set to allow the
+         user to see the list of publicized medical conditions.
+         Depending on the query type, the next step will be to
+         contact the referral index to determine what records
+         exist, and then track down information at the remote sources.
+
+   Data architecture:
+           [Out of scope for the purposes of this illustration]
+
+   Pictorially, the example can be rendered as follows:
+
+         +-------------------------------------------+
+     "a" |         |                +--------+       |
+   <----->  CAP a  |                | SAP A  |       |
+         |         |                |        |       |
+         |---------+                +-+------+---+   |
+         |                            |(Internal)|   |
+         |           "DAG/IP"         | Server i |   |
+         |                            +----------+   |
+         |                                           |
+         |                                           |
+         |                          +--------+       | "B"
+         |---------+                | SAP B  <-------------->
+     "b" |         |                |        |       |
+   <----->  CAP b  |                +--------+       |
+         |         |                                 |
+         |---------+                +--------+       |
+         |                          | SAP C  |       |
+         |                          |        |       |
+         |                          +-+------+---+   |
+         |                            |(Internal)|   |
+         |                            | Server j |   |
+         |                            +----------+   |
+         +-------------------------------------------+
+
+   where
+
+      CAP a           CAP for proprietary protocol, secure clients
+      CAP b           WAP CAP, for roaming access
+      SAP A           authentication and ACL lookup interface
+      Server i        authentication and ACL lookup server
+      SAP B           remote service SAP -- probably LDAPv3
+      SAP C           Referral Index interface
+      Server j        Referral Index
+
+
+
+
+
+
+
+Daigle & Eklof               Informational                     [Page 13]
+
+RFC 2970       Architecture for IDS - Result from TISDAG    October 2000
+
+
+6. Requirements for the future DAG/IP
+
+   The role of the DAG/IP is less as a query protocol, and more as a
+   framework or structure for carrying basic query-response transactions
+   of different (configurable) types.
+
+   Whatever the syntax or grammar, the basic requirements for the DAG/IP
+   include that it be:
+
+      - lightweight; CAPs, SAPs should be able to be quite small
+      - flexible enough to carry queries of different paradigms, results
+        of different types
+      - able to support authentication, authorization, accounting and
+        audit mechanisms -- not necessarily native to the protocol
+      - able to support encryption and end-to-end security within the
+        DAG system
+      - sophisticated enough to allow negotiation of  capabilities --
+        querying & identifying application type supported (e.g.,
+        whitepages vs. service location vs. URN resolution), query types
+        supported, results types supported
+
+      This also means:
+
+   Better support for query-passing/other query semantics (need to
+   balance that against the fact that you don't want DAG-CAPs/SAPs to
+   have to know a multiplicity of semantic possibilities.
+
+   Security infrastructure -- ability to establish security credentials,
+   maintain a secure transaction, and propagate the security information
+   forward in the transaction (don't want to reinvent the wheel, just
+   want to be able to use it!).
+
+   Ability to do lookups, instead of searches -- might mean connecting
+   to different services than the RI and/or presenting things in a
+   slightly different light -- e.g., lookup <blat> in the <foo> space,
+   as opposed to search for all things concerning <blat>.
+
+   Ability to access other services -- e.g., Norwegian Directory of
+   Directories [NDD] -- beyond just for specific characteristics of the
+   service (e.g., security).
+
+   In short, the model that seems to stand out from these requirements
+   one of a protocol framework that looks after establishing secure and
+   authenticated (authorized, accountable, auditable...) connections,
+   with transaction negotiation facilities.  Within that framework, it
+   must be possible to identify transaction types, provide suitable
+   input information (negotiation?) for those transactions, and accept
+   transaction result objects back.
+
+
+
+Daigle & Eklof               Informational                     [Page 14]
+
+RFC 2970       Architecture for IDS - Result from TISDAG    October 2000
+
+
+7. Revisiting TISDAG -- for the future
+
+   In the light of the above proposals, we can revisit the way the
+   TISDAG CAPs would be defined.
+
+   The whitepages-application service known as TISDAG could have SAPs
+   that supported 2 types of query, and 2 types of result sets:
+
+           query types:
+                   . token-based
+                   . phrase-based
+
+           result types:
+                   . result data
+                   . referrals
+
+   The Whois++ CAP would be configured to contact LDAPv2 and LDAPv3 SAPs
+   because they are identified as providing that kind of service (i.e.,
+   if referral protocol == LDAPv2 connect to a particular service).  The
+   query paradigm will be phrase-oriented -- NOT because the Whois++ CAP
+   understands LDAP, but because that is one of the defined query types.
+
+8. Applicability Limitations
+
+   As it stands, this type of service architecture is limited to query-
+   response type transactions.  This does account for a broad range of
+   applications and services, although it would be interesting to
+   consider broadening the concept to make it applicable to tunneling
+   other protocols (e.g., to connect a call through a SAP, in the number
+   portability example above).
+
+9. Security Considerations
+
+   This document takes a high-level perspective on service architecture,
+   and as such it neither introduces nor addresses security concerns at
+   an implementation level.
+
+   A distributed service built following this approach must address
+   issues of authentication of users, authorization for access to
+   material/components of the system, and encryption of links between
+   them, as befits the nature of the information and service provided.
+
+
+
+
+
+
+
+
+
+
+Daigle & Eklof               Informational                     [Page 15]
+
+RFC 2970       Architecture for IDS - Result from TISDAG    October 2000
+
+
+10. Acknowledgements
+
+   In discussing this perspective on the evolution of DAG/IP, it seemed
+   to us that the requirements for DAG/IP are falling into line with the
+   proposed text-based directory access protocol that has variously been
+   discussed.  Whether it survives in a recognizable form or not :-)
+   some of the above has been drawn from discussions of that protocol
+   with Michael Mealling and Patrik Faltstrom.
+
+   The work described in this document was carried out as part of an on-
+   going project of Ericsson.  For further information regarding that
+   project, contact:
+
+      Bjorn Larsson
+      bjorn.x.larsson@era.ericsson.se
+
+11. Authors' Addresses
+
+   Leslie L. Daigle
+   Thinking Cat Enterprises
+
+   EMail:  leslie@thinkingcat.com
+
+
+   Thommy Eklof
+   Hotsip AB
+
+   EMail: thommy.eklof@hotsip.com
+
+12. References
+
+   Request For Comments (RFC) and Internet Draft documents are available
+   from numerous mirror sites.
+
+   [ALVE]     Alvestrand, H., "Definitions for Talking about
+              Directories", Work in Progress.
+
+   [TISDAG]   Daigle, L. and R. Hedberg "Technical Infrastructure for
+              Swedish Directory Access Gateways (TISDAG)", RFC 2967,
+              October 2000.
+
+   [DAGEXP]   Eklof, T. and L. Daigle, "Wide Area Directory Deployment
+              Experiences", RFC 2969, September 2000.
+
+   [DAG-Mesh] Daigle, L. and T. Eklof, "Networking Multiple DAG servers:
+              Meshes", RFC 2968, September 2000.
+
+
+
+
+
+Daigle & Eklof               Informational                     [Page 16]
+
+RFC 2970       Architecture for IDS - Result from TISDAG    October 2000
+
+
+   [NDD]      Hedberg, R. and H. Alvestrand, "Technical Specification,
+              The Norwegian Directory of Directories (NDD)", Work in
+              Progress.
+
+   [WAP]      The Wireless Application Protocol, http://www.wapforum.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daigle & Eklof               Informational                     [Page 17]
+
+RFC 2970       Architecture for IDS - Result from TISDAG    October 2000
+
+
+13.  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 & Eklof               Informational                     [Page 18]
+