This episode explains what the ideas are, and defers the technical
detail to later articles. This introduction explains how global
directories can benefit you, your family and your company. In short, a
global directory is a way of retrieving contact information from others,
using standard technology, so you can employ tools that download and
update contact information without any input from you.
This episode explains what the ideas are, and defers the technical detail to later articles. This introduction explains how global directories can benefit you, your family and your company. In short, a global directory is a way of retrieving contact information from others, using standard technology, so you can employ tools that download and update contact information without any input from you.
Usage Examples and Introduction
Imagine receiving a phone call from someone you never met. They may use a modern Internet-based mechanism, like sip:email@example.com or they may use an old-fashioned phone number, like +12345. In both cases, you would be able to locate a directory server that spills information about the caller, even before you answer the call. Imagine what that would mean to your pizza delivery service. Imagine how that would help you to send a document to the person you are talking to. Imagine how that would help you to find that person's chat address, an Internet bypass for their phone number, their map location and much more that they care to share publicly. And if you enjoy your privacy, imagine how the directory could help you to that person's key material to encipher your phone call and email attachments.
It gets even prettier when you contact the remote directory through a hub of your own. Your hub could help you to attach personal notes to that particular caller. For example, the pizza they ordered last time. Or an internal contact reference code code. Or whether the caller is an idiot ;-) Your hub might even dig up letters or bills that you have sent to the caller. And if you enjoy your privacy, it could even store the Short Authentication String used during the previous ZRTP-enciphered call.
Interestingly, the technology to do this already exists, and it is commonly used because it is rock-solid. Chances are that your mobile devices can use it with a simple app already -- an LDAP client is available for most desktops and smaller platforms. The technology is just not usually installed by default, because most people don't ask for it -- they simply don't realise how much more the Internet has to offer than web and email. Below, I will explain what directories do, how they form a global directory, and I will say a few general things about technology. I will also explain how this helps you to get more control over your online presence.
The later parts of this series will focus on technology in-depth. In this article, the focus will be on explaining the concepts and only give a broad overview of how it actually works.
The idea of a global directory is that everybody who wants to publish information, does so under their own domain. Then, if someone wants to find your information, they approach your directory service and download it. Pretty similar to websites, except that the information in a directory is highly structured to contain, among other things, contact information. Everyone can see information that you published, so they never need to enter it themselves. When your contact information changes, it can be updated by all those who track for updates. These are the predictable benefits from structuring directory information -- it becomes subject to automation! Compare that to sending all your contacts an email that you have moved or changed your mobile phone number!
The magic that makes such directory services work together as a global directory is that individually entered bits of information are glued together. If we leave it to commerce, this is done by creating one "central" site into which everyone enters their information. Given enough traction for such a site this does actually work, but this model has grave privacy implications, especially when it is offered as a free service so that the provider needs to cover their expenses indirectly. It is much better if every party hosts their own (directory) services and conform to a standard way of publishing them.
LDAP is a standard protocol for providig a directory service under one's domain, and there is a standard method for glueing these together, through particular announcements in the DNS. If your domain name is orvelte.nep, you will add a "DNS service record" under the standard name _ldap._tcp.orvelte.nep in your domain's DNS data, and suddenly your directory has gone public.
The other part of the deal is finding the lead to your domain and its directory service. The common practice with many Internet protocols is to identify users in a format like firstname.lastname@example.org, can be translated to a directory location like uid=bakker,dc=orvelte,dc=nep -- meaning, user bakker under domain orvelte which falls under top-level domain nep. This is what is called a "Distinguished Name" or DN in LDAP-lingo; a unique location for finding information about a person. Since the domain name orvelte.nep is included as dc=orvelte,dc=nep it is possible to lookup the "DNS service record" for the directory and ask there for uid=bakker,dc=orvelte,dc=nep. The response would be a list of properties known about this user, such as there phone number, street address, email address, website, map location and whatever else they might care to share.
All this could be done by a clever-enough LDAP client. In practice however, not all clients are that clever, which is why we will introduce the idea of having your own outgoing hub servicing your LDAP queries by approaching the global directory. This hub can also perform other functions, such as caching and storing notes locally, and perhaps extra descriptions for people that are not yet part of the global directory. There is no magic here, only a stack of practical solutions.
One remark about phone numbers -- these are not normally part of the Internet, but through ENUM they can be turned into domain names. You can simply acquire ENUM access for your phone number and add the aforementioned "DNS Service Records" under those zones.
Note how you are in full control of your information -- you decide what you publish, and since you do so under your own domain name you can retract it at any time. There is no service, free or paid, to subscribe to other than what you need to get LDAP service going.
Technologies: Web, DNS, LDAP
There are several ways of getting to contact information. LDAP clearly is the best option, but it is good to explain why it is better than the obvious alternative technologies -- DNS and the web.
DNS is the system that translates domain names (like rickywiki.vanrein.org) into IP addresses, and that contains references to specific services such as for email and chat. When dealing with identities that look like email@example.com, it usually deals with the orvelte.nep part -- the user identity bakker is not commonly shown in DNS. This is pleasant, because DNS is a public infrastructure without any access filtering. You probably don't want to give spammers an easy way to browse through the World's contact information and find yours. This is one reason why DNS is unfit for directories. Another is that it was quite simply not designed for that purpose; even simply downloading a photograph over DNS stretches the system well beyond its design assumptions. DNS is perfect for pointing to a directory service under a domain, but not for providing the actual data.
The web is the other possible technology that would be a mistake for a global directory. The web is very suitable as a mechanism to present human-readable information and even documents, but its automation on a global scale seems to be very difficult. Although efforts to this end are being made, there are many problems that remain unanswered, and that introduce new ones of their own -- like who to show what and how. Another problem with web technology is that it is relatively inefficient because it needs to take so many alternative approaches into account at once.
There is a modest protocol by the name of LDAP, which was designed as a directory service with all the facilities for a global directory purposefully built in. Purpose-built solutions are almost always better than generic ones like DNS and web, and LDAP certainly demonstrates this point. It is a reasonably light-weight protocol for retrieving information from a remote site, it has proper access control built in, it comes with a plethora of standardised attributes for contact information and, perhaps most importantly, it is flexible about the kind of information you care to store in it. LDAP is the only reasonable choice for a global directory.
There are many implementations of LDAP; you might know it as IBM Tivoli, Microsoft Active Directory, Lotus Notes or Novell eDirectory. Large companies tend to use one of these products as an internal directory, as well as to manage systems and users within the organisation. The upcoming articles in this series will not focus on these products but on OpenLDAP; not because it is thought to be a better product, but simply because this is an open source implementation, freely available to anyone.
LDAP has many, many integrations with all sorts of software, ranging from desktop applications to technical processes such as mail servers. It is mature, used widely and it is very, very potent. An interesting recent development is the integration of directory data with AJAX web environments, using JSON representations of directory objects, so that the information stored in a directory can be presented in a form fit for human consumption. JSON is a very good match with the LDAP object model, because this object data is structured yet flexible, like JSON; in many applications the integration can make more sense than the integration with an SQL database. An added value of LDAP is of course that it is a protocol and not just a data store that can only be used internally. Note however, that there are also types of application that work better with SQL than with LDAP.
Getting started with LDAP
Accessing an LDAP service is not much different from accessing another server; you login to a hostname as a user and some form of credential (like a password). The one thing that LDAP generally adds, is an entry point (base DN, like dc=orvelte,dc=nep) in the directory where you want to start searching. This extra detail is required because you are in fact accessing a node on the global directory that may host other parts of the global directory as well. There generally is a way of using LDAP as a visitor, in which case you are only shown those parts that are configured as public information.
Later articles will detail how you can setup an LDAP server under your own domain. When you have done this, you should be able to attach to it from your desktops and mobile devices. Until then, you could connect to a few local directories that are publicly available:
- On Linux, you could try Luma. Also note that Evolution has LDAP-support integrated.
- On Mac OS X, both the Contacts and Mail applications can query LDAP; neither will upload information to LDAP, but LDAPManager will.
- On Windows, //please let us know what tools you use
- If you prefer to install it on a web server, you should have a look at web2ldap .
- On Android phones, you could use ???, which integrates with your contact list.``
- On iPhone and other iOS platforms, you could use ???, which integrates with your contact list.
- Visit the WikiPedia page List of LDAP software .
- ??? -- please tell us about the tools that you like best for your platform!
Note that this is not the global directory at work; it merely shows a number of local nodes that you can explicitly connect to. The global directory will make these connections automatically, once you connect to your own proxy LDAP server.