summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2970.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2970.txt')
-rw-r--r--doc/rfc/rfc2970.txt1011
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]
+