RFC 2970

Architecture for Integrated Directory Services - Result from TISDAG

📅 published October 2000, from ietf

🎀 RFC 2970: Architecture for Integrated Directory Services 🎀

Bestie, this one is a whole vibe. 💖 It's an Informational RFC from the Network Working Group, so it's not a standard, just a super smart write-up of what the team learned.

  • Authors: L. Daigle and T. Eklof 🫶
  • Category: Informational 📚
  • Date: October 2000 🗓️
  • Obsoletes / Updates: the header doesn't list any RFCs it obsoletes or updates 🦋

Title: Architecture for Integrated Directory Services - Result from TISDAG ✨

Status of This Memo 📝

Okay, babe, the official disclaimer: this memo gives info to the Internet community. It is not a standard of any kind 🙈. Distribution is unlimited, so share away 💅.

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

Abstract 🌸

So, a single, unified, global whitepages directory (think: a giant phonebook for people) is still just a dream 😭. But more and more people want widely-dispersed directory servers, meaning ones run by different organizations, to team up for big, large-scale services 🌍. Those range from national whitepages services all the way to multi-national indexes of WWW resources, and beyond 🧚.

Using what they learned from the TISDAG (Technical Infrastructure for Swedish Directory Access Gateways) ([TISDAG]) project, this doc lays out an approach for building the infrastructure that connects all those scattered servers into one service 🔥. The big twist? It doesn't force every server to use the same protocol and schema set. That would be so boring 🥱.

1. Introduction ✨

Okay so, the TISDAG project was all about giving people centralized access to distributed information, specifically whitepages info, on a national scale 🇸🇪. The full spec for the finished system is in [TISDAG], and [DAGEXP] shares the real-world experience of building something this big 💪. [DAG-Mesh] looks at the issues and possibilities of networking multiple DAG services 🕸️. Building on all of that, this document tries to describe some of the architectural foundations of the system, and suggests ways the approach could be generalized, as long as it stays within the bounds of applicability 🦋.

The proposed architecture slots a coordinated set of modules between the client access software and the participating servers 💖. The client talks to the service through one single entry point, and behind the scenes the other modules handle the app support 🫧. That could mean modules for query proxying, schema translation, lookups, referrals, security infrastructure, and so on 🎀.

Part of this architecture is an "internal protocol" (the "DAG/IP" in the TISDAG project) 🔐. This doc also lays out the requirements the team came up with for that protocol in the extended DAG 📋.

2.0 Some terminology 📖

Terms in this document match the ones in [ALVE] 💅. For our purposes, there are important distinctions and relationships between applications, services, servers and systems, and here's how they're defined 👑:

  • Application: this is meant in the general sense, as a solution to a particular set of user needs. It's not tied to a specific piece of software, like an "application program" 🌸.

An application covers the type(s) of information to be exchanged, the expected behavior, and so on 🧠. So a whitepages (search) application might take a name as input to a query engine, and return all the info linked to that name 📇. A specific security application, by contrast, might use that same name input to check access controls 🔑.

  • Service: an operational system that provides (controlled) access to meet a particular application's needs 💫.

You can change a service by reconfiguring its location, access controls, and so on 🔧. Changing the application means changing the service 🔄.

  • Server: a single component that offers access through a dedicated protocol, without caring which service (or services) it's supporting in a given setup. Usually it's programmed for one particular application 🖥️.
  • System: a set of components with established interconnections 🕸️.

So a service can be split across several servers 🍰. A collection of services (working on their own, or linked through specified agreements) acts as an implementation of an application 🎁. A system is made up of one or more servers and services 💜.

A "system architecture" identifies the specific software components, how they behave, the communication channels, and the messages needed to meet a particular service's needs 🧩. The TISDAG specification [TISDAG] has exactly that kind of description, defining a software system that meets the needs of a national whitepages directory service 🇸🇪. Here, we outline the general principles that lead to that specific system architecture, and talk about how those principles could be applied in other contexts 🌈.

Looking at the bigger picture, we present a "service architecture": a framework for assembling components into systems that meet the needs of a much wider range of services 🌍. This isn't about developing one or more new protocols for services. It's about looking at a useful framework of components that work together 🤝. The goal is to cut down the overall number of (specialized) protocols that need to be developed, by pulling out the very general concepts that all protocols have in common 🙌.

3.0 TISDAG -- a first implementation, and some generalizations 🚀

The Swedish TISDAG project (covered in detail in [TISDAG], with some experiences reported in [DAGEXP]) was built to meet the requirements of one particular national directory service 🇸🇪. Building a component-based system that offers a directory service through a uniform interface (a client access point) taught the team a ton 🧠. It showed them how the system architecture could be extended, so that services with different base requirements can still get many of the same perks 🎀.

3.1 Deconstructing the TISDAG architecture 🔍

Looking back, the TISDAG system architecture can be described in terms of 3 key requirements and 4 basic design principles 💅:

  • R1. The service had to work with (several) existing client and server software for the white pages application 🤝.
  • R2. It had to be possible to extend the service to support new client and server protocols, if and when they became relevant 🌱.
  • R3. The service had to be easy to reconfigure, so it could handle more machines (load-sharing), and so on ⚖️.
  • D1. As a design principle, it was important to consider that queries and information templates (schema) beyond the originally defined set might eventually need to be supported 🔮.
  • D2. Since the architecture was already modular and built for extensibility, it made sense to remember that the same (or a similar) system could be applied to other, non-white pages, applications 🌟.
  • D3. The service has an "inside" and an "outside". This means telling apart the components that are accessible to the world at large from the ones open only to other components in the system 🚪.
  • D4. Internally, there's a single protocol framework for all communications. This makes service support functions easier (for example, security of transmission), keeps things distributable, and provides the base mechanism for allowing and checking the interoperability of components 🔐.

The resulting system architecture had modular component types that fill a small number of functional roles, all hooked together by a generic query-response language 🧩. The functional roles are:

  • CAPs ("client access points"): these are responsible for accepting and responding to incoming requests, through programmed and configured behavior 📥. They translate each incoming query into some set of DAG-internal actions (queries), then handle the responses, filtering and recombining them so the client's request gets fulfilled within the scope of the service 🎯.

In the TISDAG system, all CAPs handle whitepages queries, but they're told apart by the application protocol they receive queries in (for example, LDAPv2, LDAPv3, HTTP, and so on) 🌐. To the client software, the TISDAG system looks like a server of that particular protocol 🪞. In the more general case, CAPs could be configured to handle different aspects of a service (for example, authenticated versus non-authenticated access) 🔐. The TISDAG CAPs all had a simple control structure. The more general case would also have CAPs drawing on different subsets of DAG (internal) servers to handle different query types 🧠. (See the "Operator Service" example, in section 5.2 below.) 👀

  • SAPs ("service access points"): these are responsible for proxying DAG-internal queries to specified services 🚏. Other components in the system use them as resources 🧰. Through programmed and configured behavior, they translate queries in the internal protocol into actions against (usually external) servers 🔄. They take care of any necessary overhead or differences in interaction style, then convert the responses back into the internal protocol 🎁. In the TISDAG system, all SAPs handle whitepages queries, but they're told apart by the application protocol they use to reach remote services 🌍. More distinctions could come from the schema mappings (of the remote service) they handle, and from other service differentiators 🏷️.
  • Internal Servers: these respond to queries in the internal protocol and provide specific types of information 📦. In the TISDAG system, there's one internal server that provides referral information in response to queries 👉.

Notice that all of these components are defined by the functional roles they play in the system, not by the particular protocols they handle, or even by the aspect of the service they're meant to support ✨. So a client access point is in charge of handling client traffic, whether that's for searching, setting up security credentials, or any other task 💖.

3.2 Some generalizations ✨

okay so the big requirements and design principles from earlier? they're NOT only for a whitepages service 💅 they work for any app built on a query-response model, for services that have to support multiple protocols, and/or for services that need specialized behavior happening "behind the scenes" 🫶 in TISDAG, that last one was baked right in: the service first looks for referrals, then makes queries as needed. and for protocols that don't handle referrals natively? the TISDAG system proxies the queries for them 🔥

because it's so tied to query-response situations, the name "Directory Access Gateway", or "DAG", still fits as a label for this kind of system architecture 🦋

internet apps keep evolving and need fancier features, like security mechanisms, accounting mechanisms, and integration of historical session data 💀 if you keep building a dedicated protocol for every app type, you end up with encumbered, unwieldy protocols, because each one has to cover all of these common aspects again and again 😭 but a single multi-application protocol? honestly that seems unlikely at best 🙈 so the implicit idea here is: instead of overloading protocols to support every aspect of a service, you break the service into multiple supporting components that handle the specialized jobs, like authentication and so on 🌈

3.3 A Word on DAG/IP 🎀

in TISDAG, they chose a single "internal protocol" called DAG/IP 🧚 the particular protocol isn't what matters for the architecture, but the principle totally does 💜 by picking a single query-response transaction protocol, the needs of a particular application can be mapped onto it in terms of queries and the data specific to that application. this makes the internal communications way more flexible to configure for other environments and services 🍓

it's super common today to grab an existing, widely deployed protocol for moving commands and data between client and server, like HTTP 🌸 but even setting aside whether extending HTTP to this use is appropriate (or not appropriate, lol), you'd still have to define all the transaction types and data types over that protocol. so the work of specifying the interaction semantics and syntax doesn't go away 😤

3.4 Perceived benefits 🌟

aside from the potential to divide and conquer service aspects (see above!), this approach has a bunch of perceived benefits 👑

- For multi-protocol environments, it requires on the order of
  N+M inter-protocol mappings, not NxM.

Wait, let me put that in a nice list for you, bestie 💖

  • 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's NOT the goal to claim that a standardized system architecture can be made so that single components can be built for all possible applications 🙅‍♀️ what this approach does do is permit the decoupling of access protocols from specific applications, and it makes it easier to integrate the necessary infrastructure independently of the access protocol (things like referrals, security, lookup services, distribution, etc.) 🦄

4.0 Proposed service architecture 🏰

here's what the DAG architecture looks like, pictorially 📸

      +-------------------------------------------+
  "a" |         |                +--------+       |
<----->  CAP a  |                | SAP A  |       |
      |         |                |        |       |
      |---------+                +-+------+---+   |
      |                            |(Internal)|   |
      |           "DAG/IP"         | Server i |   |
      |                            +----------+   |
      |                                           |
      |                                           |
      |                          +--------+       | "B"
      |                          | SAP B  <-------------->
      |                          |        |       |
      |                          +--------+       |
      |                                           |
      +-------------------------------------------+

quick note: that bounding box is conceptual 🫧 all the components may or may not live on one server, or on a set of servers run by the provider of the service. totally up to them ✨

and as we saw in the TISDAG project, the provider of this DAG-based service may be only loosely affiliated with the remote services it uses (Whitepages Directory Service Providers, aka WDSPs, in that case) 🤝

4.1 Using the architecture 🧩

building a service on this architecture requires the following, bestie 📝

Service implementation:

  1. definition of the overall application to be supported by the system, like whitepages, web resource indexing, or 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 the access protocols to be supported and the different service levels to be provided (e.g., secure and unsecure connections) 🔐
  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, the CAP modules manage the necessary transactions with the 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 🌷

let's look at the TISDAG project through the lens of all those definitions, shall we? 🔍

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 an 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 🪄

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

one thing to note: 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 TISDAG experience led 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? totally immaterial 💅✨

5.2 Operator service 📞

Okay so picture number portability 📱, where you keep your phone number even when you switch providers. Phone numbers are globally unique, but they are NOT tied to any specific service provider in any way. That means before you can grab any info, you have to figure out who is currently running the number. 🕵️‍♀️ Here's the setup: the system stores (internally) the mapping between these random digit strings and the country each one was originally activated in, but it relies on external, country-specific services to keep the updated info on which provider manages a given number. So the service data only needs updating when new numbers get assigned or when national services change their access points. 💅

Let's look at a grossly-simplified version of the problem to see some of the concepts in this service architecture in action. 🧚 We're pairing it with the "name search" facet of the TISDAG example, to show that a single service ("operator") MAY in fact be supported by several disjunct underlying activities. It's giving teamwork 🫶

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].
  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, 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, so 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). BUT, if there were 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. 🦋

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

5.3 Medical application 🏥

The service architecture is useful for stuff way outside of "telecoms", bestie! 💜 Here's another hypothetical: medical information. Think records about patients that get created and stored at a variety of institutions they visit. It's super common to need ALL the info about a patient, even if they can't remember (or communicate) what conditions got treated, what procedures were done, or which medical institutions they visited. 😭 The data can be everything from prescriptions, to X-rays and other images, to incident reports and other bits of medical history, etc. Usually the info is stored where it was 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 it 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 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

Okay the vibes are immaculate and the architecture is even more iconic 👑

6. Requirements for the future DAG/IP ✨

okay so the DAG/IP is less of a query protocol and more of a framework 💅 It's the structure that carries basic query-response transactions of all kinds of (configurable) types. Think of it as the stage, not the show 🎀

No matter what the syntax or grammar ends up being, the basic requirements say the DAG/IP should be:

  • lightweight; CAPs, SAPs should be able to be quite small 🌸
  • flexible enough to carry queries of different paradigms, and results of different types 🦋
  • able to support authentication, authorization, accounting and audit mechanisms, even if those aren't native to the protocol itself 🔐
  • able to support encryption and end-to-end security within the DAG system 🫶
  • sophisticated enough to negotiate capabilities: querying and identifying the application type supported (e.g., whitepages vs. service location vs. URN resolution), the query types supported, and the results types supported 👑

This also means:

Better support for query-passing and other query semantics. ngl this has to be balanced against the fact that DAG-CAPs/SAPs really shouldn't have to know a whole multiplicity of semantic possibilities 🙈

Security infrastructure. We need the ability to establish security credentials, keep a secure transaction going, and propagate the security information forward through the transaction. Don't want to reinvent the wheel, just want to be able to use it! 🛞✨

The ability to do lookups instead of searches. This might mean connecting to different services than the RI, and/or presenting things in a slightly different light. Like, lookup <blat> in the <foo> space, as opposed to search for all things concerning <blat> 🔍💖

The ability to access other services, like the Norwegian Directory of Directories [NDD], beyond just the specific characteristics of the service (e.g., security). 🧚

In short, the model that stands out from all of this is a protocol framework that looks after establishing secure and authenticated (authorized, accountable, auditable...) connections, with transaction negotiation facilities. Inside that framework it has to be possible to identify transaction types, provide suitable input information (negotiation?) for those transactions, and accept transaction result objects back. main character energy, fr 👑

7. Revisiting TISDAG -- for the future 🦋

okay now that we've got those proposals on the table, we can revisit how 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

So the Whois++ CAP would be configured to contact LDAPv2 and LDAPv3 SAPs, because those 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. And I need you to hear this part: it's NOT because the Whois++ CAP understands LDAP 🙅‍♀️ It's because phrase-based is one of the defined query types ✨

8. Applicability Limitations 🙈

real talk, this type of service architecture is limited to query-response type transactions. That said, it covers a broad range of applications and services, which is honestly still iconic 💅 It would be interesting to consider broadening the concept so it could tunnel other protocols too (e.g., connecting a call through a SAP, like in the number portability example above) 📞🧚

9. Security Considerations 💀

ok this one is serious, bestie. This document takes a high-level perspective on service architecture, so it neither introduces nor addresses security concerns at an implementation level. That's a them problem and a you problem 🫠

A distributed service built following this approach must address issues of authentication of users, authorization for access to material and components of the system, and encryption of links between them, as befits the nature of the information and service provided. Like, please protect your stuff 🔐😭

10. Acknowledgements 🫶

In discussing this take on how DAG/IP is evolving, it seemed to us that the requirements for DAG/IP were falling into line with the proposed text-based directory access protocol that people have been kicking around. Whether it survives in a recognizable form or not :-) some of the above was drawn from discussions of that protocol with Michael Mealling and Patrik Faltstrom. Big thank yous to them 💖

The work described in this document was carried out as part of an on-going project of Ericsson. For further information about 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. Go dig 🔍

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

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. thank you for keeping the lights on 💜

📦 where this page comes from