RFC 2969

Wide Area Directory Deployment - Experiences from TISDAG

📅 published October 2000, from ietf

RFC 2969 🎀

Wide Area Directory Deployment - Experiences from TISDAG ✨

Network Working Group 💖 Request for Comments: 2969

Authors: T. Eklof and L. Daigle 🫶

Category: Informational 📚 (so this one is info-only, not a standard 🙈)

Date: October 2000 🗓️

Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🌈

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 (C) The Internet Society (2000). All Rights Reserved.

Abstract 🦋

okay so the TISDAG (Technical Infrastructure for Swedish Directory Access Gateway) project gave us so much insight into what it's actually like to deploy a wide-scale directory service 😭 this doc is basically a catalogue of the experiences the team picked up while building the infrastructure for a national (i.e., multi-organizational) directory service, plus a pilot deployment running on off-the-shelf directory service products. it also covers how the project relates to other directory deployment projects, and throws out some proposals for future extensions (larger scale deployment, other application areas) 💅

these are the authors' own observations, based on work done and general project discussions. other project participants definitely have their own list of experiences, so we don't claim this is exhaustive! 🙈

Table of Contents

   1.0 Introduction ................................................  2
   1.1 Overview of the TISDAG project ..............................  2
   1.2 Organization of this document ...............................  3
   2.0 The TISDAG project itself ...................................  3
   2.1  TISDAG overview ............................................  3
   2.2 Some successes ..............................................  4
   2.3 Some surprises ..............................................  5
   2.3.1 LDAP objectclasses and the "o" attribute ..................  6
   2.3.1 The Tagged Index Object ...................................  6
   2.3.3  Handling Status Messages .................................  7
   2.3.4  Deployment with Commercial Software ......................  7
   2.4 Some observations ...........................................  7
   2.4.1 Participation of the WDSPs ................................  7
   2.4.2 Index Objects and Referral Index size .....................  8
   2.4.3 Index Object and Query Performance ........................  8
   2.5 Some evolutions .............................................  9
   3.0 Related Projects ............................................ 11
   3.1 The Norwegian Directory of Directories (NDD) ................ 11
   3.2 DESIRE Directory Services ................................... 11
   4.0 Some Directions for TISDAG Next Steps ....................... 12
   4.1 Security support ............................................ 12
   4.2 WDSPs attributes and schemas  ............................... 12
   5.0 Some conclusions ............................................ 13
   6.0 Security Considerations ..................................... 13
   7.0 Acknowledgements ............................................ 13
   8.0 Authors' Addresses .......................................... 13
   9.0 References .................................................. 14
   Appendix -- Specific Software Issues and Deployment Experiences.. 15
   Full Copyright Statement ........................................ 18

1.0 Introduction ✨

1.1 Overview of the TISDAG project 🌸

as described in more detail in [TISDAG], the original goal of TISDAG was to build the infrastructure for a national whitepages directory service 📖 to actually be useful, it had to deal with the real world: end-users' existing client software, and the needs of information providers ("Whitepages Directory Service Providers" -- WDSPs). the real world includes multiple protocols, so-called directory service access protocols, plus more general Internet application protocols like HTTP and SMTP 🧚

the project also got that WDSPs have many good reasons to be reluctant to hand over copies of their subscribers' personal data. respect 🫶

1.2 Organization of this document 🧚

this doc is split into 3 major sections 💜 the first one looks at specific lessons the authors learned through TISDAG, plus the implementation of one conformant system. next, we look at how the TISDAG work relates to other large-scale directory projects that are ongoing, so you can see how those efforts might interact. finally, there are some preliminary thoughts on applying the DAG system to other applications and deployment environments.

further suggestions for deploying networked DAG servers (meshes) are in [DAG-Mesh]. and more discussion about developing architectural principles is in a separate document, [DAG++] ✨

2.0 The TISDAG project itself 💅

2.1 TISDAG overview 🦋

the technical infrastructure for TISDAG (see [TISDAG] for the complete overview and technical specification) gives end-user client software connection points to run basic whitepages queries. there's a different connection point for each protocol end-users might want to use: WWW (http), e-mail (SMTP), Whois++, LDAPv2 and LDAPv3 🌈 for every client, a transaction happens within the bounds of that protocol's syntax and semantics.

but here's the catch 👀 TISDAG doesn't keep a replicated copy of all the whitepages info. instead it keeps an index over the data, which lets it redirect (referrals) clients to services likely to have matching responses. so the DAG system has to do a fair bit of background work to fulfill each query.

the first, and most important, step is querying the DAG Referral Index: a server holding index information, obtained through the Common Indexing Protocol (see [CIP1, CIP2, CIP3]) in the Tagged Index Object format (see [TIO]). this index has enough info to figure out which of the many participating WDSPs should be contacted to finish the query 🔥 whenever possible, these referrals get passed back to the querying client, so it can contact the relevant WDSPs directly. this means the DAG system does less work itself, and WDSPs get more visibility, which is an incentive to join the system 💖 protocols that natively support referrals include Whois++ and LDAPv3, although they may only be referred to servers using the same protocol.

not every protocol does referrals though! LDAPv2 doesn't, for example.

so, to handle referrals to servers using a protocol other than the calling client's own, there's a secondary step called "query chaining" 🔗 it chases those extra referrals inside the DAG system itself. for example, say an LDAPv2 client connects. a query goes to the Referral Index to figure out which WDSPs might have answers, and then resources inside the DAG system are used to pursue the query at those WDSPs' servers. the results from all these services get packaged into one single response set for the client that made the query 🎀

the architecture built to support the required functionality splits the system into separate components:

  • Client Access Points (CAPs): handle incoming queries from client software.
  • Referral Index (RI): maintains an index over the collected whitepages info, and provides referrals, based on actual data queries, to WDSPs that might have relevant info.
  • Service Access Points (SAPs): mediate access to WDSP whitepages servers to perform queries and retrieve results for the client's query.

there are several CAPs and SAPs in the system: at least one for every protocol supported for incoming queries and for WDSP servers, respectively 🧁

these components are designed to be implementable as separate programs, and they talk to each other through an internal protocol, the DAG/IP 💌 in practice, that means different components can live on different machines, for load-balancing and performance reasons. it also acts as a "common language" for the CAPs, SAPs and RI to express queries and receive results.

all of this is the planned or ideal behaviour of the system. once designed, a pilot phase kicked off to compare reality with expectations 👀 two independent implementations of the software were created, and a test deployment was set up within the Swedish University Network (SUNET). more detail on the project and where it's at can be found at http://tisdag.sunet.se/ 🌸

the rest of this section covers some conclusions drawn from turning the proposed architecture into reality, both the successes and the surprises 💅

2.2 Some successes 👑

implementing and piloting software that met the TISDAG technical specification did show some important wins for the approach 🏆

most notably, the system works pretty much as expected (see exceptions below) as transparent middleware for whitepages directory services. client software and WDSP servers were minimally affected. from the point of view of behaviour and configuration, the DAG system looked like a server to clients, and like a client to servers 🦋

operationally, the goal was to give end-users responses in reasonable response times (though definitely not "an addressbook replacement" 📱). the prototypes managed responses within 10 seconds, at least in the limited testbed configuration with 10 WDSP's providing directory service info. more observations on system performance come later on ⏳

the DAG system does show it's possible to build referral-level services at a national level. (the deployment hasn't proven conclusively yet that it can, in its current formulation, work as a transparent query-fulfillment proxy service, so that's still TBD 👀)

the implementation also showed that it's possible, in some sense, to do (semantic) protocol mapping with N+M complexity instead of NxM mappings 🧠 in other words, protocol translations only had to be defined for "N" allowable end-user query access protocols to/from the DAG/IP, and "M" supported WDSP server protocols. each of the N input components didn't have to individually map to the M output protocols. big brain energy 🧠✨

as a related point, the prototype had some wins mapping between schema representations across the different protocol paradigms. a big reason? the system's schemas were kept simple and focused on the minimal needs to support the base service requirements 🍓

2.3 Some surprises ✨

Over roughly a year, from the first "final" draft of the spec through building and first deploying the software, a few surprises popped up 🙈 They came in two flavours: ones that showed up once the theory met practice, and ones that only appeared when the system ran with commercial software clients and servers 💅

The Appendix has more detail on specific software issues, but some of the bigger problems from the implementation phase are described below 🫶

2.3.1 LDAP objectclasses and the "o" attribute 💜

It was a major shock, a few months into the project, that none of the "standard" LDAP person objectclasses included organization ("o") as an attribute 😭 The assumption seems to be that "o" will be part of the distinguished name for an entry, so there's little (if any) reason to list it separately. That makes it trickier to store information about people across multiple organizations (for example, at an ISP's directory server) and to use the organization name to refine queries. (Roland Hedberg caught this issue and flagged it to the authors of the "inetorgperson" objectclass document 🦋)

2.3.1 The Tagged Index Object 🎀

The Tagged Index Object ("TIO"), which carries indexes of WDSP information to the RI, is designed to have record (entry) tags. Those tags reduce the number of false positive referrals generated when a search runs in the RI ✨ One of the nice features of the first index object type, Whois++'s centroid (see [centroid]), was that the index object size didn't grow linearly with the size of the indexed data. At some point, the index object's growth slowed compared to the underlying data set. At first glance, the TIO seems to behave the same way. Lowkey, though, as the index grows, the TIO's compression factor may not reach the same efficiency as centroids 🙈

One reason is that the tagged lists can get quite long, depending on the order in which tags are assigned to the underlying data. The tagging as defined allows a compressed expression of tag "ranges", so 1-500 can be written instead of 1,2,3,[...]500. That means it might be worth exploring an optimal "sorting" of the underlying data before tags are applied, so the most common tokens get consecutive tags. That gives the most compressed tag lists 🧚 It isn't clear whether this can be done efficiently across the entire set of records, attributes, and tokens, but it's worth investigating to produce the most compressed TIO for transmission 💖

There's also a catch on the time side. To use the tags efficiently in the RI, it's almost necessary to "reinflate" the index object so joins can be done on the tag lists attached to matching tokens. The other option is to store the compressed tag list and accept an extra cost for comparing tag lists for matching tokens. That means list comparison operations happen outside the scope of a base database management system 😳 There was an unexpected tradeoff to make, and it's giving "pick your poison" 💀

2.3.3 Handling Status Messages 🌸

Mapping status messages from multiple sub-transactions into a single status communication for the end-user client software turned out to be a real challenge 😤 When a query is chained to multiple WDSPs (through the SAPs), it's pretty common for at least one WDSP server to return an error code or be unavailable. If one WDSP can't be reached out of several referrals, should the client software be given the impression that the query completed successfully, or not? Most client protocol error handling models aren't sophisticated enough to make that distinction clear 🙃

2.3.4 Deployment with Commercial Software 🛠️

When it was finally time to test the software with standard commercial client and server software, more surprises came to light. They were mostly about these products' expected worldview and some occasional implementation shortcuts 👀 Again, the Appendix has more detail, but the highlights were:

  • client software that could only handle a very small subset of a protocol's defined status message lexicon (for example, only 2 system messages were supported) 💀
  • client software that automatically appended extra terms to a user-specified query (for example, adding or email=<what the user typed in to the query>) 🙈

2.4 Some observations 🔍

2.4.1 Participation of the WDSPs 🦋

One thing that came to light is that the nature of the index object generated by the WDSPs has a big impact on performance. That's true both for integrating the index object into the Referral Index and for how efficiently queries get handled 📈 One proposal is to define more clearly how the WDSPs should generate the CIP index object, which is currently left to their discretion. Another is to alert individual WDSPs when their index objects are considered substandard 🫶

On another front, when referrals are chained to WDSP servers, some servers perform better than others, which affects the overall response time of the DAG system 🐢 From a service point of view, it should also be possible to suggest to WDSPs that are consistently slow (longer than some selected response time) that they're substandard 💅

2.4.2 Index Objects and Referral Index size 📏

As described in more detail in [complex], many factors can influence how fast index objects grow as more data is indexed 🧠 That work dealt specifically with tokenized data for Whois++ centroids, and it isn't immediately generalizable to every form of the Tagged Index Object. However, the TIO structure used for the TISDAG project is similar enough to a centroid that the same "order of magnitude" and growth characteristics are applicable ✨

Here's what affects the size of the data ("number of entries"):

  • Number of generated tokens 🔢 The number of tokens generated from the directory data depends on what gets tokenized. If the data is tokenized on names and addresses (so, not unique data like phone numbers), a rough estimate is that number_of_tokens = 0.2 * number_of_data_records. Growth is linear across the span from a few thousand to at least 1.2 million records. It should then level off, since the sets of names and addresses are finite, but the current tests haven't shown a break point yet 👀

If the data is tokenized on something unique, like phone numbers, a rough estimate is that number_of_tokens = number_of_data_records. It's possible to tokenize in different ways, though. For example, you could divide phone numbers into parts, which would result in fewer tokens 🧩

  • Number of directories 📁 Since tokens are generated individually for each directory, the data size depends on how many directories there are. 10 directories with 100.000 records will generate the same number of tokens as one directory with 1.000.000 records 🤯

2.4.3 Index Object and Query Performance 🚀

Here's what affects performance ("queries/second"):

  • Type of query (exact, substring, etc.) 🔍 A 'substring' query is slower than an 'exact' query because of:
    1. somewhat slower look-up in the internal DAG database than an exact query
    2. mostly, a larger amount of data is fetched from the internal DAG database because of more hits, which generates more index processing
    3. substring queries are sent to the directory servers, which also results in more hits and more data fetched. The directory servers may also be more or less effective at handling substring queries 💅
  • Number of search attributes 🏷️ A query with one or a few attributes will most of the time result in many hits, which means a lot of data, both internally in DAG and from the directory servers. On the other hand, a query with many attributes will result in a somewhat slower look-up in the internal DAG database ✨
  • Number of directories 📚 A larger number of directories may result in many referrals, but it depends on the query. A simple query will generate a lot of referrals, which means a lot of data from the directories has to be fetched. It will also result in a somewhat slower look-up in the internal DAG database 🙃
  • Number of chained referrals 🔗 Queries that aren't chained are faster, since the result data doesn't have to be sent through the DAG system. Chained queries to several directories can be processed in parallel in the SAPs, but all the data has to be processed in the CAP before it's sent to the client 🏃‍♀️
  • Response time in the directory servers ⏱️ The response time from the directory servers is, of course, critical. The total response time for DAG is never faster than the slowest directory server involved 😭
  • Number of tokens (size of Tagged Index Objects) 🧚 The number of tokens has little impact on look-up time in the internal DAG database 💜

2.5 Some evolutions ✨

okay so the TISDAG project has been "alive" for just over two years now 🎂 and bestie, it has glowed up SO much in that time. There were changes out in the wider world (user and service provider expectations, related software getting deployed, all that) and changes in how the project itself understood its goals 💅

The biggest plot twist is that the project started out wanting to be a national referral service, but it slowly turned into more of a transparent protocol proxy service 🦋 Now it tries to fulfill client queries as completely as it can, while staying inside the client protocol's semantics. Why did this happen? Probably a few reasons 🤔 Existing client and server software expects a narrower range of behaviour than their protocol specs actually describe. Also, once the technology was there for some proxying, going all the way felt totally within reach. Iconic decision honestly 👑

From the point of view of building a national whitepages service, this is a really positive glow-up 🌸 BUT it put some strain on the original system architecture, so some adjustments have been proposed (more detail below) 🫶 What's less clear is how this will affect the flexibility of the architecture. Like, can it handle other applications, or different protocols and protocol paradigms? The original plan was super simple: "find things that sort of match the input query and let the client itself decide if the match is close enough" 🧚 As requirements get more sophisticated, the simplicity gets hit, and the system might get a bit more brittle 😬 (Some proposals for avoiding this are outlined in [DAG++], which goes back to the underlying principles and suggests steps forward at that level 📚)

Inside the TISDAG project, this evolution led to the following technical adjustments:

  • The latest version of the technical specification makes a distinction (in the internal protocol grammar) between queries aimed at the Referral Index and queries passed to SAPs to fulfill a query 🎀 This keeps the query-routing queries simple, while allowing more sophistication in expressing a query that fulfills the client's original semantic expression ✨
  • The extra constraints in the SAP query language still aren't enough for the internal protocol to express really sophisticated queries 🥲 The DAG/IP was originally only meant for query-routing queries, so it expects all queries to be token-based, whereas LDAP queries are phrase-oriented. This means SAPs have to do a lot of "post-pruning" of WDSP result sets to match the DAG/IP query sent by a CAP for query fulfillment 💀 And CAPs then have to do more post-pruning to match the DAG/IP results (from the SAPs) to the original query semantics 😭

The real strength of the TISDAG project is that it separated the technical framework needed to support the service from the configuration needed to support a particular application or service 💜 That includes query and schema mapping, configuration for protocols, and so on. Future improvements should focus on evolving that framework, while keeping that separation from the specific applications, services, and protocols that might use it 🫶

The TISDAG project is not alone in trying to solve the problems of providing coordinated access to resources managed by multiple, disparate services 🧩

3.1 The Norwegian Directory of Directories (NDD) 🇳🇴

Described in [NDD], the Norwegian Directory of Directories project also aims to provide the infrastructure needed for a national directory service 🏗️ It assumes LDAP (v2 or v3) accessibility of WDSP information (provided by the WDSP itself, or through other arrangements). It tackles some of the trickier issues of hooking together LDAP servers that are already running into one coherent network: a uniform distinguished naming scheme and content-based referrals 🔗 It also deals with the practical reality of being compatible with different versions of LDAP clients, like v2 (which doesn't support referrals) and v3 (which does) 🙈

At the heart of the system is the "Referral Index and Organizational information" (RIO) server 📇 It provides a searchable catalogue over Norwegian organizations. This helps you find whitepages servers for individual organizations, as long as the query includes which organization(s) you're interested in 🔍

This work is complementary to the TISDAG work, since it offers a more focused service for integrating LDAP directory servers 🤝 Still, you need to know the organization a person belongs to before searching for their e-mail address. That might be fine for finding mail addresses tied to someone's work organization, but it's less likely to work for finding a personal e-mail address 😩 In an age where ISPs are everywhere, a priori knowledge of a user's ISP identification is unlikely, bestie 💀

3.2 DESIRE Directory Services 🇪🇺

The EC funded project DESIRE II (http://www.desire.org) is building a distributed European indexing system for information on Research and Education 🎓 The Directory Services work done by DANTE and SURFnet proposes an architecture applied to a server mesh structure, to create a wide-area directory service infrastructure 🕸️

This service is meant to support whitepages information with LDAP servers at WDSPs, and also Web-search meshes at various places using Whois++ for information about resources and for routing queries to other index-based services 🦋

Like the TISDAG project, the DESIRE directory services project wants to act as a focal point for queries, so client software can access the right resources from a wide range of disparate services 💖

There are architectural differences between the approach used in the TISDAG project and the DESIRE directory service project 🧐 But many of the driving needs are the same, and both chose the approach of content-based indexing and referrals ✨

4.0 Some Directions for TISDAG Next Steps 🚀

The fun thing about technology is that there are always more tweaks and changes you can make 🤓 However, a service should evolve in response to specific customer needs! There are several ways the TISDAG service itself could advance. Some are outlined below as possibilities perceived at this time, rather than specific recommendations for the underlying technology changes that would be needed to get there 🧠 A related topic, networking DAG servers (meshes), is discussed in [DAG-Mesh] 🕸️

4.1 Security support 🔐

There's a real need for security considerations when using a wide-scaled directory system in application areas other than the public whitepages application of the TISDAG project 😳 It's an open question whether the directory service is distributed across the Internet, or whether it functions entirely within an internal, closed network 🏠

4.2 WDSPs attributes and schemas 📋

Today the DAG system uses 2 information schemas: the DAGPERSON schema for information about specific people, and the DAGORGROLE schema for organizational roles 🧑‍💼 The technical specification includes a definition of the schema, along with an understood mapping to (and from) some standard schemas used in the supported protocols 🔄 Still, to include new WDSPs that may not have all the attributes in a schema, or that may use different schemas and query attributes, it should be possible to create and use new customized or standardized schemas, and to do schema mapping if it's necessary 🛠️ It might also be possible to constrain queries to desired query attributes, templates, or object classes 🎯

In practice, this means different WDSPs may choose to use different subparts of one defined schema, or even implement local customizations 💅

5.0 Some conclusions 💭

Fewer people hold out hope for a unified global directory service based on standardized protocols these days 🥹 Still, it's interesting to see more projects building infrastructure that allows unified access to what is otherwise an unforgivingly diverse and dislocated set of information servers 🌍 What can't be dictated (in standardized protocols and schemas) may still be accommodated through service infrastructure ✨ The right approach seems to be building better and better frameworks to support these diversified services, without making the framework architecture depend on specific technologies 🦋

6.0 Security Considerations 🚨

⚠️ Heads up: this one is serious. The TISDAG project has so far focused on serving only publicly sharable information. As noted in Section 4.1, any future work will have to provide additional facilities for authentication, authorization, encryption, and otherwise handling sensitive data in an open environment. Do NOT skip this part, bestie 😭🔒

7.0 Acknowledgements 🫶

This document outlines the perspectives and opinions of the authors, based on experience as well as many fruitful and enlightening discussions with others: Roland Hedberg, Torbjorn Granat, Patrik Granholm, Rikard Wessblad and Sandro Mazzucato 💜

The work described in this document was carried out as part of an ongoing project of Ericsson 🏢 For more information about that project, contact:

Bjorn Larsson bjorn.x.larsson@era.ericsson.se

8.0 Authors' Addresses 📮

Thommy Eklof Hotsip AB

EMail: thommy.eklof@hotsip.com

Leslie L. Daigle Thinking Cat Enterprises

EMail: leslie@thinkingcat.com

9.0 References 📚

Request For Comments (RFC) and Internet Draft documents are available from numerous mirror sites 🪞

  • [CIP1] Allen, J. and M. Mealling, "The Architecture of the Common Indexing Protocol (CIP)", RFC 2651, August 1999.
  • [CIP2] Allen, J. and M. Mealling, "MIME Object Definitions for the Common Indexing Protocol (CIP)", RFC 2652, August 1999.
  • [CIP3] Allen, J., Leach, P. and R. Hedberg, "CIP Transport Protocols", RFC 2653, August 1999.
  • [DAG++] Daigle, L. and T. Eklof, "An Architecture for Integrated Directory Services", RFC 2970, October 2000.
  • [DAG-Mesh] Daigle, L. and T. Eklof, "Networking Multiple DAG servers: Meshes", RFC 2968, October 2000.
  • [TISDAG] Daigle, L. and R. Hedberg "Technical Infrastructure for Swedish Directory Access Gateways (TISDAG)," RFC 2967, October 2000.
  • [centroid] Deutsch, P., Schoultz, R., Faltstrom, P. and C. Weider, "Architecture of the WHOIS++ service", RFC 1835, August 1995.
  • [NDD] Hedberg, R. and H. Alvestrand, "Technical Specification, The Norwegian Directory of Directories (NDD)", Work in Progress.
  • [TIO] Hedberg, R., Greenblatt, B., Moats, R. and M. Wahl, "A Tagged Index Object for use in the Common Indexing Protocol", RFC 2654, August 1999.
  • [complex] P. Panotzki, "Complexity of the Common Indexing Protocol: Predicting Search Times in Index Server Meshes", Master's Thesis, KTH, September 1996.
  • [WAP] The Wireless Application Protocol, http://www.wapforum.org

Appendix -- Specific Software Issues and Deployment Experiences ✨

okay so this section is basically a bunch of real-life tea from people who actually built and deployed this stuff 🫖💅 these are anecdotes, not a full official review of client software, but they show the kinds of problems your implementation team is likely to run into. bestie, read these before you ship 🙈

Character encoding 🔤

one client's addressbook sends iso-8859 encoding when it queries a directory server (it depends on the font config in the browser), but the directory server answers in Unicode (UTF-8) 😭 so the LDAP CAP has to be able to handle different character set encodings for the request and the response. chaotic, I know 💀

Referrals 🔀

apparently there's only one commercial addressbook that supports LDAPv3, and everything else is still on LDAPv2 🙃 the LDAPv3 client that got tested doesn't handle referrals properly. when the server's result contains response code 10 (the one reserved for referrals), the client just can't cope 💔 from what they saw, neither the client nor the end-user had any way to decide whether, or which, referrals to follow up on. nobody actually knows how LDAP clients handle a mix of referrals and results, but the vibe is that it doesn't work 🥲

Objectclasses in LDAP 🧾

the LDAP clients don't put any objectclass in their query to the DAG-system 👀 so the DAG-system can't see any difference between inetOrgPerson and organisationalRole when the cn attribute is holding both a name and a role. honestly not the biggest deal, but it has some iykyk side effects 🙈 most directory user interfaces (the ones in browsers and mail programs) say they only support person-related queries, but in practice a user can use the interface to send a query that targets a role entry anyway 🫣

Query with attribute Organisation 🏢

you can send a query with the organisation attribute, but it returns zero hits 😩 the reason is that organisation isn't included in the inetOrgPerson objectclass. Roland Hedberg has proposed a change for the latest release of the objectclass definition document 🙌

to narrow the search down to a range of organization names (attribute values), there are three possible approaches, each with its own pros and cons ⚖️

  1. Recommend the use of the locality attribute. the catch is that a more standard definition would be needed, because locality is currently used for everything from organization to county to map coordinates 🗺️
  2. Recommend or require that the attribute organisation should be inherited in objectclass inetOrgPerson.
  3. Build the LDAP DAG-SAP to submit 2 query to the WDSP. the second query is the same as the first, but with only cn filters, and it's only sent if the entire query including o results in no hits. (basically, back off from the organization filtering if it doesn't seem to be supported 🫠)

Configuration ⚙️

there's no way to see which character set an LDAP client wants to use 😤 so far the project's recommendation has been to define a unique port for each character set. that means end-users have to do extra configuration in their client software, and the port number-charset mapping has to be properly advertised in the service 📢

DN 🪪

when a user wants more info about someone they found in a preliminary search, the LDAP client uses the entry's DN together with the host and port to reach the DAG system 💅 the problem is that this makes the client send a non-compliant query to the DAG system, since DNs aren't part of any of the defined queries for the service. and it just doesn't do what it's supposed to, which is get to the user's entry. big yikes 😭

Response Codes 🚦

the LDAPv3 client that was used doesn't support more than 2 response codes: "success" and "size limit exceeded" 💀 every other response code gets translated into "size limit exceeded", even though no results come back. so if the error really was that the size limit was exceeded, the results up to that limit get shown. but if it was some other response code getting mapped to that one, no results show up at all 🫥

Sending and loading CIP Index Objects 📇

at least one server quotes the CIP-object incorrectly for the Swedish characters A-Ring, A-Umlaut and O-Umlaut 🇸🇪 sending quoted printable CIP-objects with PINE mail software does work though ✨

Source - Labeled URI 🔗

the original plan for the labeled-URI attribute was to use it to return a pointer to the WDSP that provided the user's information 🧭 but the standard use of the labeled-URI attribute (which may actually be filled in by data returned from a WDSP) is to hold the URI for more private related homepages 🏡

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. 🎀

📦 where this page comes from