Internet DRAFT - draft-hedberg-alvestrand-ndd
draft-hedberg-alvestrand-ndd
HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 00:20:06 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 21 May 1999 10:53:00 GMT
ETag: "2e9afa-ce62-37453b0c"
Accept-Ranges: bytes
Content-Length: 52834
Connection: close
Content-Type: text/plain
Internet-Draft Roland Hedberg
Category: Informational Catalogix
Expires: November 21, 1999 Harald Alvestrand
Maxware AS
May 1999
Technical Specification
The Norwegian Directory of Directories (NDD)
draft-hedberg-alvestrand-ndd-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 21, 1999.
Abstract
This specification describs what we belive to be the necessary
infrastructure to provide a national directory server infrastructure
in Norway for publicly accessible directory servers.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Hedberg & Alvestrand [Page 1]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
Table of Contents
1 - INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 PROJECT GOAL. . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 DOCUMENT OVERVIEW . . . . . . . . . . . . . . . . . . . . . . 3
1.3 TERMINOLOGY . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 - REQUIREMENTS. . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 OVERVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 END-USERS . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1 What is searchable. . . . . . . . . . . . . . . . . . . . . 5
2.2.2 How is it searchable. . . . . . . . . . . . . . . . . . . . 5
2.2.3 How fast the system will respond. . . . . . . . . . . . . . 6
2.3 WDSPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Security concerns . . . . . . . . . . . . . . . . . . . . . . 6
3 - ARCHITECTURE. . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 OVERVIEW. . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 END-USER SOFTWARE . . . . . . . . . . . . . . . . . . . . . . 7
3.3 THE PROTOCOL CONVERTERS . . . . . . . . . . . . . . . . . . . 8
3.4 THE RIO SERVER. . . . . . . . . . . . . . . . . . . . . . . . 8
3.5 CONNECTED DIRECTORY SERVERS . . . . . . . . . . . . . . . . . 8
4 - SCHEMA. . . . . . . . . . . . . . . . . . . . . . . . . . . .10
4.1 RIO SERVER SCHEMA . . . . . . . . . . . . . . . . . . . . . .10
4.1.1 DIT Structure . . . . . . . . . . . . . . . . . . . . . . .10
4.1.2 Attributes. . . . . . . . . . . . . . . . . . . . . . . . .10
4.1.3 Object classes. . . . . . . . . . . . . . . . . . . . . . .11
4.2 CONNECTED SERVERS SCHEMA. . . . . . . . . . . . . . . . . . .11
4.2.1 DIT structure . . . . . . . . . . . . . . . . . . . . . . .11
4.2.2 Attributes. . . . . . . . . . . . . . . . . . . . . . . . .11
4.2.3 Objectclasses . . . . . . . . . . . . . . . . . . . . . . .12
5 - REFERRAL INDEX AND ORGANIZATION SERVER. . . . . . . . . . . .12
5.1 INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . . . .12
5.2 FUNCTIONALITY . . . . . . . . . . . . . . . . . . . . . . . .13
5.2.1 use of the ref attribute. . . . . . . . . . . . . . . . . .13
5.2.2 Format of the nssref attribute. . . . . . . . . . . . . . .14
5.2.3 Examples. . . . . . . . . . . . . . . . . . . . . . . . . .14
5.2.3.1 Example 1 - single level search below c=NO. . . . . . . .14
5.2.3.2 Example 2 - subtree search with organization as base. . .15
5.3 DATA IMPORT . . . . . . . . . . . . . . . . . . . . . . . . .16
5.3.1 Broennoeysund registry. . . . . . . . . . . . . . . . . . .16
5.3.2 domain registry (NORID) . . . . . . . . . . . . . . . . . .16
6 - PROTOCOL CONVERTER. . . . . . . . . . . . . . . . . . . . . .17
6.1 INTRODUCTION. . . . . . . . . . . . . . . . . . . . . . . . .17
6.2 WWW INTERFACE . . . . . . . . . . . . . . . . . . . . . . . .17
6.3 CLIENTSIDE PROTOCOL CONVERSION (CPC). . . . . . . . . . . . .18
6.3.1 Character set handling. . . . . . . . . . . . . . . . . . .18
6.3.2 Referral handling . . . . . . . . . . . . . . . . . . . . .18
6.3.2 Query translation . . . . . . . . . . . . . . . . . . . . .18
6.3.3 Result gathering. . . . . . . . . . . . . . . . . . . . . .19
6.3.4 Result code handling. . . . . . . . . . . . . . . . . . . .19
6.4 SERVERSIDE PROTOCOL CONVERSION (SPC). . . . . . . . . . . . .19
Hedberg & Alvestrand [Page 2]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
7 - CONNECTED DIRECTORY SERVERS. . . . . . . . . . . . . . . . .20
7.1 NAMESPACE REGISTRATION. . . . . . . . . . . . . . . . . . . .20
7.2 THE REFERRAL. . . . . . . . . . . . . . . . . . . . . . . . .21
7.3 DIRECTORY SERVERS SUPPORTING THE LDAP ACCESS PROTOCOL . . . .21
7.4 DIRECTORY SERVERS NOT SUPPORTING LDAP AS A ACCESS PROTOCOL. .22
9 - ACKNOWLEDGEMENT. . . . . . . . . . . . . . . . . . . . . . .22
9 - REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . .22
10 - AUTHORS' ADDRESS . . . . . . . . . . . . . . . . . . . . . .23
APPENDIX A - ATTRIBUTE MAPPING. . . . . . . . . . . . . . . . . .24
APPENDIX B - USED OBJECTCLASSES AND ATTRIBUTES. . . . . . . . . .24
1 - Introduction
1.1 Project Goal
The goal of this project is to develop the necessary infrastructure
to provide a national directory server infrastructure in Norway for
publicly accessible directory servers. One part of this
infrastructure is a registration infrastructure by which norwegian
companies can register unique Distinguished Names to use in their
directories. The other part, the technical infrastructure, should be
organized so that a Internet user only has to know about one access
point to be able to access all the information provided by the
connected directory services. The service should also provide a
uniform view of the information so that the user should not need to
know which directory service she is accessing.
The service will natively support LDAPv3 [2] as access protocol
and will through the use of a protocol converters support LDAPv2[1].
A WWW interface will also be provided.
The service should as a minimum make available information about
organization names, organization numbers and organization contact
addresses, such as is available from the Broennoeysund registry.This
is to serve as a basis for providing pointers to directory services
that contain information about the organization or persons within
that organization.This infrastructure should also provide a plattform
on which other types of service can be built.
1.2 Document Overview
This document is broken into 4 major sections:
Schema: If the service is going to be perceived as "one" service, the
different parts have to adhere to a couple of basic rules regarding
the schema.
Referral Index and Organization Server: This is the critical function
of the system, a central repository of organization information and
pointers to directory servers that holds such information.
Hedberg & Alvestrand [Page 3]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
Protocol Converter: For those running access clients, that does not
use LDAPv3 [2] as access protocol, this function is necessary to get
the expected functionality out of the system. Likewise if directory
servers, that do not support LDAPv3, want to connect to the system
an intermediate translator will be necessary.
Connected Directory Servers: If the system is going to be
able to support seamless access to all the information contained
therein, the connected systems has to obey certain rules.
Note: the parts refer to one another, in such a way that the text
should be read from the beginning until the end. The sections are
not selfcontained.
1.3 Terminology
End-User: People performing White Pages searches and look-ups (via
various forms of client software).
WDSP: Whitepages Directory Service Provider -- ISPs, companies, or
other interested entities.
Whitepages Information: Collected information coordinates for
individual people. This typically includes ( but is not limited to)
a person's name, telephone number and e-mail address.
RIO server: Referral Index and Organizational Information server,
more about this in section 4
Protocol Converter: A function that handles differences among access
protocols.
Serverside Protocol converter (SPC): A function that makes a
non-LDAPv3 server appear as a LDAPv3 server.
Clientside Protocol converter (CPC): A function that allows clients
to use other access protocols than LDAPv3 against the service.
NORID: The Norwegian domain name registry
Broennoeysund: The official organization maintaining, among others,
the registry of organizations for Norway.
Hedberg & Alvestrand [Page 4]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
2 - Requirements
2.1 Overview
We believe that the acceptance of such a system as the one presented
in this specification is very much dependent of whether the system
lives up to the expectations of its users. We also believe we can
group the users in two different classes, one being the providers
(WDSPs) and the other the consumers (end users). Each group having
quite different expectations, and those expectations imply
restrictions on the system as a whole.
2.2 End-users
It is probably fair to define the expectations of a end-user like this;
A end-user wants to know
- what she can search for and
- how, and
- how fast she can get it.
The answers that will cause most usage of the system will be "complete
information where information is available","easily using standard
tools" and "very quickly".
Based on this definition and the basic goal of this system we can
restate the requirements of the system to be;
2.2.1 What is searchable
A end-user should be able to search for Norwegian organizations and
people/functions/roles within these organizations. The following
query types will therefore be supported:
Organization
Organization + name
Organization + function/role
The system will not place any restrictions on which attributes people
may search for. The minimum set of searchable attributes are,
for organizations, those that are imported from the Broennoeysund and
the NORID registries (see Appendix A) and for persons/functions/roles
only commonName.
2.2.2 How is it searchable
The supported client access protocols will at onset only be
LDAPv3/v2. For those not having a LDAPv2/v3 client handy there will
also be a WWW page from which they can query the system.
Hedberg & Alvestrand [Page 5]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
Regarding LDAP, no limitations are placed on what types of filters
that can be used.
The recommended method, when searching for a person or a
function/role is:
1. Do a single level search for an organization name under C=NO, with
"objectclass=organization"
2. If one or more organizations with directory references are found,
do one subtree search for each of these organizations for the person
or role sought, with "objectclass=person" or
"objectclass=organizationalRole" respectively.
If clients can not do this sequence of queries, they will have to go
through the Client Protocol Converter (CPC).
2.2.3 How fast the system will respond
When serving typical queries, the system should be scalable to handle
50 queries/second and 1.000.000 queries/day. A typical query ( I want
to find the email address for Harald Alvestrand working at Maxw...
something) should be answered within 15 seconds, 24 hours a day, 7
days a week.
In the initial phase, it is unrealistic to expect 100% uptime, but the
design of the system should be such that there does not have to be any
planned downtime of the service as a whole.
2.3 WDSPs
All WDSPs should be treated equally and fair. It is up to each
organization to choose which WDSP that will be allowed to publish
their information through this system. The requirement that the
service places on the WDSP servers is that they are accessible either
through LDAPv2 or LDAPv3, and supports the schema described here.
All WDSPs partaking in this service have to keep their directory
server working well within the boundaries of the system as a whole. A
connected directory server must therefore answer queries, with
filters expressing any of the queries defined in section 2.2, within
10 seconds, 24 hour a day, 7 days a week. (The same note about
availablity applies here, too).
2.4 Security concerns
Since all information handled by this service is public and it is
defined as a read-only system, no authentication of the users of the
system is necessary.
Hedberg & Alvestrand [Page 6]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
3 - Architecture
3.1 Overview
The system consists of four distinct parts ;
- The end-user software
- The protocol converters
- The RIO server
- The connected directory servers
Part one and four are mostly outside the scope of this specification,
but the specification of two and three are bounded by their
functionality. So it is necessary to incorporate them into this
description.
Fig 1. describes schematically the relation among the different
parts.
The SPC and the RIO server will function according to the LDAPv3 [2]
specification. Neither of them are required to support any of the
extensions standardized by the IETF.
3.2 End-user software
Unfortunately most LDAP v2/v3 clients in use today are very much
geared toward use with a single organizations LDAP directory. This
preconception is made obvious by the lack of possibility of adding
a organization specifier in the default search field.
Therefore specifying the queries that this system wants to support
does not come natural to most interfaces and in one of the client
interfaces it is impossible to produce.
Even if a organization can be specified, a search can not be made
stepwise, that is first finding the right organization and then
finding the person. The CPC of this system will try to limit the
impact of this imperfection in the clients.
LDAPv3, that support referrals does not have to connect to the client
protocol converter (CPC) but can instead connect directly to the RIO
server. Even though a LDAPv3 client can be connected to and properly
function together with a LDAPv2 server connected to the system, this
behavior is not something we support since LDAPv2 server normally do
not use the character set that a LDAPv3 client is expecting (UTF-8
encoded Unicode 2.0) . The RIO server will therefore never return a
referral that points directly to a connected LDAPv2 server but
instead will return a referral that points to the server protocol
converter (SPC), which then can handle the character set conversion.
LDAPv2, that according to the specification [1] does not support
either referrals or UTF-8 as a character set will always have to
connect to the CPC and should not connect directly to the RIO
server.
Hedberg & Alvestrand [Page 7]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
The following client software will be considered for the first
version of the service:
- Internet Explorer 4.1 and 5.0
- Netscape Navigator 4,5
- Eudora 4.1
- ON-Mail
- Lotus Notes 4.5
- Microsoft Outlook 98
Each of these may be configured to point at a specific CPC.
3.3 The Protocol converters
Protocol converters are there to hide differences in the access
protocol methods; such as how queries are expressed, character set
usage and referral handling.
The protocol converters will translate between UTF-8 encoded Unicode
2.0 and other predefined character set (presently T.61 and Latin-
1/ISO 8859-1) when necessary.
Depending on the query produced by the end-users client software it
might sometimes be necessary to issue several queries to the RIO
server to fulfill one request.
The protocol converters will never return a referral.
3.4 The RIO server
The RIO server will contain the organization information imported
from the Broennoeysund and the NORID registries, supplemented
with referrals to other directory servers. Today the number of
registered organizations amounts to approximately 1.000.000
organizations.
It will act as a LDAPv3 server and will return referral when deemed
necessary according to the specification in 5.2 .
When a organization wants to publish more information about
themselves, then what is maintained in the Broennoeysund registry, it
may do so by publishing the information as one or more directory
entries in a publicly accessible directory server/servers. And then
supply the NDD service with one or more URLs, defining which server
and baseobject to use for searches, to be incorporated into the RIO
server's database.
In no other case is information from the connected directory servers
stored in the RIO server.
3.5 Connected directory servers
The design of this system is built on the assumption that any
connected directory server has to at least appear to be a LDAP
server. This behavior can be accomplished either by the organization
running the service or by the SPC if sufficient interest in such a
translator is expressed.
Hedberg & Alvestrand [Page 8]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
A organization is allowed to publish LDAP URLs to the service
specifying one or more LDAPv3 servers together with one or more
LDAPv2 servers. The LDAPv2 URL will then be translated into a SPC URL
before stored in the RIO server
+--------------+ +------------+
| |<----------------------------> | RIO server |
|LDAPv3 client |<--- LDAPv3 ---- +------------+
| |<------------ \
+--------------+ \ \ +--------------------+
\ -----------> | WDSP LDAPv3 server |
\ +--------------------+
v
+-----+ +--------------------+
| SPC |<-LDAPv2-> | WDSP LDAPv2 server |
+-----+ +--------------------+
+--------------+ +-----+ +------------+
|LDAPv2 client |<- LDAPv2 ->| CPC |<--LDAPv3-> | RIO server |
+--------------+ +-----+ +------------+
^ ^
| \ +--------------------+
LDAPv3| ----LDAPv3-> | WDSP LDAPv3 server |
| +--------------------+
v
+-----+ +--------------------+
| SPC |<--LDAPv2-> | WDSP LDAPv2 server |
+-----+ +--------------------+
Fig 1.
WDSP = Whitepages Directory Service Provider
CPC = Client Protocol Converter
SPC = Server Protocol Converter
Hedberg & Alvestrand [Page 9]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
4 - Schema
If the service is going to be able to present a uniform fa‡ade to the
users a schema covering not only the RIO server but also limiting the
choice of schema for the connected Directory servers has to be
defined. We do not want to place excessive constraints on the
connected Directory servers but do want to define a small number of
restrictions, which has to be followed, to make the whole appear as
one service.
4.1 RIO server schema
The basis for the chosen schema is what kind of information that is
stored in the Broennoeysund and the NORID registry. Since no two
entries in the Broennoeysund registry can have the same "Organisasjons
nummer" (organization identifier), while all other information are
non-unique, this attributes value is an excellent choice for Relative
Distinguished Name [6].
The possible extension of the imported information by a referral link
to a publicly accessible external directory server have also
influenced the choice of attributes.
4.1.1 DIT Structure
The base object of the DIT will be c=NO.
The RDN of the different organization entries will be based on the
"organisasjons nummer" by using the attribute organizationID. The
organization having the "organisasjons nummer" 123456 will therefore
have the Distinguished Name "organizationID=123456,c=NO" in the RIO
server.
4.1.2 Attributes
The necessary attributes required to be able to store the information
supplied by the Broennoeysund and the NORID registry as well as the
referral link are;
organizationName,o
telephoneNumber
facsimileTelephoneNumber
postalAddress
postalCode
locality,l
associatedDomain
organizationID
organizationType
nssref (see section 5.2)
Which attribute that corresponds to which field in the registries
databases are given in Appendix A.
Hedberg & Alvestrand [Page 10]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
4.1.3 Object classes
The set of attributes defined in 4.1.2 can be covered by the use of
the following object classes:
organization (X.500/RFC 2256)
domainRelatedObject (RFC 1274)
kfOrg (defined in this specification)
4.2 Connected Servers Schema
4.2.1 DIT structure
We do not place any restrictions on the depth on the tree, neither do
we place any restriction on where in a local DIT the entry point of a
referral is placed. For example if the base given in the referral
is:
dc=maxware, dc=no ,
o=maxware as, dc=maxware,dc=no ,
o=maxware, c=no
or
o=maxware, l=trondheim, c=no
is irrelevant to this service as long as the name of the entry point
is globally unique.
We do expect that subtree searches for people and functions/roles can
be made below the entry point defined in the referral stored in the
RIO server or in the SPC, and that the entry pointed to by the
referral uses the objectclass "organization" along with any other
objectclass deemed necessary by the organization responsible for the
server.
4.2.2 Attributes
Since this service is defined as a White pages service we chiefly want
three different kinds of entries to be present in a connected
Directory server;
The organization entry, which must be the entry point. This entry
must contain at least the information present in the Broennoeysund
registry. Therefore additions to the information are allowed
deletions are not.
Person entries, must contain commonName, surName and should at least
contain one of telephoneNumber and mail.
Hedberg & Alvestrand [Page 11]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
Role entries, must contain the attribute commonName and should at
least contain one of telephoneNumber, roleOccupant and mail.
For all types of entries other information might be present and
readable but that is up to the organization and the WDSP to decide.
4.2.3 Objectclasses
For the three different types of entries mentioned in section 4.2.2
the following objectclasses must be present:
type objectclass
------------ ------------
organization organization
person person
role organizationalRole
The reason for mandating these object classes are that they are
usefull in searches.
These object classes are not sufficient when it comes to allowing
the use of the above mentioned attributes. We therefore expect the
connected services to complement these with other objectclass which
contains the missing attributes. The reason for choosing these are
that they are well known, sufficient for supporting the expected
types of searches and already in use in some common LDAP clients.
There is no reason for the NDD to mandate which object classes to
use to allow these attributes. Other work in the Katalogforum will
result in recommendations on this topic.
5 - Referral Index and organization server
5.1 Introduction
The Referral Index and Organization (RIO) server are vital for
getting this service bootstrapped. It provides a means by which
information about Norwegian organizations can be publicized as well
as a solution for how these organization can in a uniform way publish
more information about themself.
The proposed evolution of the NDD system is the following; at the
start the RIO server will only contain information about
organizations, collected from the Broennoeysund and the Norwegian
domainname registries (NORID). After some time directory servers
containing more information about one or more organizations in the
RIO server will be connected to the service by having the original
information extended by a referral link to the appropriate directory
server.
Hedberg & Alvestrand [Page 12]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
The RIO server must be able to act as a LDAPv3 server, it might
also support other access protocols but that is outside of this
specification.
5.2 Functionality
This section describes one possible implementation of the "single
level returns information, subtree search returns a referral"
behavior. It is not the only possible solution.
The concept of having referral information stored in a LDAPv3
directory such as the RIO server is borrowed from [11], but the
functionality we want to have is a bit different. The following
section describe our view on how referrals will be used in this
service.
This desired functionality will possibly be part of a further
revision to [11].
5.2.1 use of the ref attribute
For normal operation, the nssref attribute causes the generation of
referrals.
If an entry containing the nssref attribute is either in the scope of
a one level search below c=NO or a base level search, then the
information contained in each such entry except for the nssref
attribute is returned.
If the entry named in a request contains the nssref attribute, the
search defined is not a base level search and the entry is not the
root DSE, the server returns an LDAPResult with the resultCode field
set to "referral" and the referral field set to contain the value(s)
of the nssref attribute.
In the context of the RIO server, a subtree search under c=no (the
only possible case where an nssref attribute can be encountered
during a search) will return a UnwillingToPerform error, so how to
handle this case is not handled here.
The manageDsaIT control as provided in [11] is there to allow clients
to see the nssref attribute instead of having a referral generated.
Except when the manageDsaIT control (documented in section 7 of [11])
is present in the operation request, the nssref attribute is not
visible to clients, except when its value is returned in referrals or
continuation references.
When the manageDsaIT control is present in a request, the server will
treat an entry containing the nssref attribute as an ordinary entry,
and the nssref attribute as an ordinary attribute, and the server
will not return referrals or continuation references corresponding to
nssref attributes.
Hedberg & Alvestrand [Page 13]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
5.2.2 Format of the nssref attribute
The referral is a LDAP URL.
This LDAP URL comes in two versions, one which directly points at the
connected directory server (which then has to be a LDAPv3 complaint
server) and the other which is a indirect pointer using the SPC. The
later has a special baseobject defined, which the SPC then uses as a
key into its database to translate into one or more URLs pointing to
the directory server holding the actual information.
An example of the indirect LDAP URL would be :
ldap://spc.katalogforum.no/dsi=1.752.834.880.172
Using this sort of indirection allows us to keep one database, with
the SPC, where all the information about non-LDAPv3 directory servers
is kept.
5.2.3 Examples
5.2.3.1 Example 1 - single level search below c=NO
Assume that the RIO server contains, the following information in
LDIF [12] format:
dn: organizationID=830495622,c=NO
objectclass: top
objectclass: organization
objectclass: kfOrg
o: Max Matsenter AS
organizationType: AS
postalAddress: Granden
postalCode: 6930
l: SVELGEN
telephoneNumber: +47 57 79 32 08
dn: organizationID=834880172,c=NO
objectclass: top
objectclass: organization
objectclass: kfOrg
objectclass: referral
o: Maxibaatene AS
organizationType: AS
postalAddress: Ryenstubben 7
postalCode: 0679
l: OSLO
telephoneNumber: +47 22 19 70 19
nssref: ldap://spc.katalogforum.no/dsi=1.752.834.880.172
Hedberg & Alvestrand [Page 14]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
dn: organizationID=979523408,c=NO
objectclass: top
objectclass: organization
objectclass: kfOrg
objectclass: referral
objectclass: domainRelatedObject
o: EDB MAXWARE AS
organizationType: AS
postalAddress: Pirsenteret
postalCode: 7005
l: TRONDHEIM
telephoneNumber: +47 73 54 57 00
facsimileTelephoneNumber: +47 73 54 57 50
nssref: ldap://ldap.maxware.no/o=maxware,c=NO
associatedDomain: maxware.no
A search, with base object c=NO and filter "(o=*MAX*)", for the
attributes "locality" and "organization",
will then return the resultset:
SearchResultEntry {
organizationID=830495622,c=NO {
organization { Max Matsenter AS }
locality { SVELGEN }
}
organizationID=834880172,c=NO {
organization { Maxibaatene AS }
locality { OSLO }
}
organizationID=979523408,c=NO {
organization { EDB MAXWARE A/S }
locality { TRONDHEIM }
}
}
SearchResultDone "success"
5.2.3.2 Example 2 - subtree search with organization as base
Given the information in section 5.2.3.1, a subtree search with the
baseobject "organizationID=979523408,c=NO" issued to the RIO server
will return:
SearchResultDone "referral" {
ldap://ldap.maxware.no/o=maxware,c=NO
}
Hedberg & Alvestrand [Page 15]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
5.3 Data import
The information in the RIO server will be updated once a day based on
the changes in the registries information and if new directory
servers are connected or old disconnected.
5.3.1 Broennoeysund registry
Most of the import is straight forward one-to-one mapping from fields
in the Broennoeysund registry into attributes in the RIO server (see
Appendix A) . Two attribute must even so be handled in a special
manner:
postalAddress, which according to X.520 [7] is limited to 6 X 30
characters. In the registry the addresses are simple strings with
length varying from 0 - >100 characters. The long strings should, if
possible by a automatic process, be split into no more than 6 parts,
neither of which shall exceed 30 characters. If such a process is not
possible to accomplish then the string should be truncated to fit
into one 30 characters string.
telephoneNumber and facsimileTelephoneNumber should be stored in the
RIO server as international telephone numbers and in a consistent
format. The proposed format is:
+47 11 22 33 44
Or put into words; a "+" character followed by the country code,
followed by the phonenumber with the digits divided into pairs, each
pair separated from the others or the country code by a space
character.
It is worth noting that there is nothing preventing a organization
for having more than one "organisasjons nummer", this might come as a
result of one company having acquired another or a organization
changing type ("organisasjonsform").
Note also that "Postnr" and "Poststed" may also need to be
incorporated into postalAddress.
5.3.2 domain registry (NORID)
The information from the NORID registry is matched against the
information from the Broennoeysund registry by the use of the
"organisasjons nummer". Presently the only information imported from
this registry is the domain name.
Hedberg & Alvestrand [Page 16]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
6 - Protocol converter
6.1 Introduction
The RIO server will natively only support LDAPv3. This decision
implies that users using any other access protocol must use a
protocol converter to be able to query the RIO server. For the moment
we only envision support for one other access protocols, LDAPv2. In
the future other access protocols might be added.
It is assumed that a client accessing the service through the
protocol converter can not handle LDAPv3 referrals. If therefore the
result returned by the RIO server contains LDAPv3 referrals the
protocol converter MUST follow these referrals and collect the
results gained from them before returning the result set to the
client.
6.2 WWW interface
As a part of the CPC a WWW interface will be provided, this interface
will allow users to query the system by specifying a set of search
criteria's.
The searches that has to be supported are the one listed in 2.2
namely ;
- Searches for organizations by way of specifying information that is
connected to that organization, be it the name of the organization,
its telephone number or some other information present in the
Broennoeysund registry.
- Searches for people, functions/roles within organizations by giving
the organization name and information connected to the person or
function/role.
The interface should support a step-wise mode for searching the
information, such that a end-user could start by finding the relevant
organization(s) and then use that set as a base for further searches.
Hedberg & Alvestrand [Page 17]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
6.3 Clientside Protocol Conversion (CPC)
6.3.1 Character set handling
Apart from not being able to handle referrals the other mayor
drawback of LDAPv2 is the problematic characterset handling.
In LDAPv2 the characterset was never defined but left to be defined
by X.500, what LDAPv2 provided was a 8-bit clean transport mechanism.
This omission/feature has led to the use of several different
charactersets together with LDAPv2 services and furthermore the
production of LDAPv2 clients with predefined expectations on which
characterset to send to the server and what to expect in return.
Since LDAPv3 uses UTF-8 encoded Unicode the protocol converter will
have to translate between the characterset used by the LDAPv2 client
and UTF-8, before furthering the query to the RIO server and also
vice versa before passing back the result from the RIO server.
Using LDAPv2, clients and servers has no way of informing each other
which characterset to use therefore this service will provide one or
more instance of the LDAPv2 protocol converters, on different ports,
each one using one specific characterset.
6.3.2 Referral handling
If the CPC receives more than one referral from the RIO server, it
should try them in sequence until it can elicit a response from one
of them. When doing this probing it must start with the referrals
that are pointing directly at a LDAPv3 server and leave the referrals
pointing to the SPC until all direct referrals has be tried.
6.3.2 Query translation
The LDAP clients that allows you to specify both a person name and a
organization name in a query usually ends up producing a search
filter that looks like this:
"(&(cn=harald alvestrand)(o=*maxware*))"
or possibly
"(&(cn=*harald*)(cn=*alvestrand*)(o=*maxware*))"
Given the schema we have defined for this service this query can not
be answered directly by the service, we therefore propose that the
CPC should handle this kind of filters in a special way.
step 1: use the organization specification part of the filter as a
filter in a query to the RIO server, in this case "(o=*maxware*)"
would be sent as filter to the RIO server.
Hedberg & Alvestrand [Page 18]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
step2: Issue new queries to the RIO server, one per received entry
from step 1, using the received DNs as the base DNs and as filter
the original filter without the organization specification part. For
the above mentioned filters the filters used in step 2 would be
"(cn=harald alvestrand)" and "(&(cn=*harald*)(cn=*alvestrand*))"
respectively.
step3: In case the organization entry contains a nssref attribute,
this attribute's values will then be return as one or more referrals
in a searchResultDone. These referrals should then be followed using
the same filter as in step 2 but with the new server and base as
specified in the referral.
6.3.3 Result gathering
The CPC should gather all results , that is follow all referrals
necessary to follow, before returning any information to the client.
No sorting of the complete results set will be done. The
distinguished names (DNs) of the return entries should be the DNs
that the entries have in there local environment.
OBS! At least one LDAP clients allows the user to 'click' on the
entries returned, with the intent that further information about the
entry then should be fetched. This "feature" only works if the DNs
returned from the connected servers are globally unique. Something we
therefore demand from them while at the same time we are proposing a
mechanism and organization for registring globally unique DNs in
Norway.
6.3.4 Result code handling
Since the CPC might have to gather information from several servers
it might get into the situation, when it has collected all the
results, that it has one or more entries to return but also one or
more resultcodes representing reasons why it could not get all the
entries it should have. Since it can not return more then one
resultcode to the client, it must in these cases return the
resultcode "other" together with a errorMessage specifying which
servers returned which errors.
6.4 Serverside protocol conversion (SPC)
The SPC will handle all referral to connected directory servers that
does not use LDAPv3 as access protocol, and its function is the to
make it appear as if the connecting LDAPv3 client is talking to a
LDAPv3 server.
Hedberg & Alvestrand [Page 19]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
If the connected directory server is a LDAPv2 server this clearly
involves character set translation on the query issued by the client
from UTF-8 into whatever character set the server is using and the
reverse on any information returned by the server.
Whether it is necessary to edit the attribute set or the attribute
values of queries or responses is something one has to investigate
when the system is operational; in the first version, we will try to
avoid this.
If the connected directory server is only supporting a non-LDAP
access protocol, more problems has to be dealt with, this list
includes;
* query syntax translation
* attribute translation
* possible string centric to token centric conversion
* the necessity for result pruning caused by imperfect filter mapping
* resultcode translation
* character set translation
The initial version of this service is not supporting any non-LDAP
access protocols.
7 - Connected Directory Servers
7.1 Namespace registration
The Norwegian Directory of Directories will serve as naming authority
and repository for the C=NO namespace. The following namespaces will
be managed:
- UID=<number>, C=NO: All Norwegian registered organizations will
have one of these by virtue of being registered in Broennoeysund.
- O=name, C=NO: Any Norwegian organization may request to have such a
DN assigned to them. The "name" must be either the registered name of
the organization as described in the Broennoeysund registry, a well
known abbreviation thereof, or another well-known identifier for the
company.
These rules, governing name registration, are intended to be similar
to the rules governing Norwegian domain names for companies.
Registration is achieved by means of a Webform or a form sent in by
e-mail, and may be subject to a reasonable handling charge.
Hedberg & Alvestrand [Page 20]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
The information submitted MUST include:
- The organization's organization number
- The name applied for
- Contact details for a contact person within the company
This information will be made public once the request is granted.
Where there is no directory registered, information about assignments
will be kept as O= attribute values in the relevant organization
entry.
7.2 The referral
It is permissible for a organization to supply this service with a
set of referral URLs pointing to different servers. From the service
point of view all of these URLs are deemed equal both when it comes
to performance and content.
A log over the performance of connected directories when they are
queried through the CPC or the SPC will be kept, and if any server
is consistently unavailable or only returns errors, it will be
removed from the service if the organization and/or the WDSP
involved has not fixed the problem within a reasonable amount of
time.
7.3 Directory servers supporting the LDAP access protocol
The following are acceptable naming schemes for use in directories
linked into the RIO service:
- 1*[dc=<name>,]dc=<TLD> where the domain name belongs to the company
registering (note: there may be more than 2 levels of DC components
below the Top Level Domain)
- UID=<number>, C=no, with a valid Broennoeysund register number
- O=<name>, C=no, with a registered organization name
- O=<name>, C=<country>, where <name> is registered in <country>
according to applicable rules in that country
- O=<name>, where <name> is registered according to ITU's X.666 rules
Any organization wanting to make additional public information
available about the organization must provide the service with at
least one LDAP URL pointing to a entry in a local DIT, this entry
should among other contain the objectclass organization. And must
contain at least the information present in the RIO server, as
supplied by the Broennoeysund registry.
Hedberg & Alvestrand [Page 21]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
Furthermore;
- How the DIT is organized below or above the entry point is not a
concern of this service.
- Subtree searches for people and functions/roles below the entry
point must be permitted.
- The commonName and surName attributes of the person and
functions/roles entries must be accessible/searchable.
- A globally unique DN must be returned together with the entry.
7.4 Directory servers not supporting LDAP as a access protocol
Are presently not supported.
The decision on whether or not to include such services will be made
according to a cost-benefit analysis when the question arises.
8 - Acknowledgement
Work on this specification was supported by the Norwegian Directory
Forum as part of their plan to facilitate the cooperation between
Internet publishers of public contact information within Norway.
9 - References
[1] Yeong, W., Howes, T., and S. Kille, "Lightweight Directory Access
Protocol", RFC 1777, March 1995
[2] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access
Protocol (v3)", RFC 2251, December 1997.
[3] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
2252, December 1997.
[4] Howes, T., "A String Representation of LDAP Search Filters", RFC
2254, December 1997.
[5] Berners-Lee, T., Fielding, R., and Frystyk, H., "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996
[6] ITU-T Rec. X.500, "The Directory: Overview of Concepts, Models
and Service", 1993.
[7] "The Directory: Selected Attribute Types". ITU-T Recommendation
X.520, 1993.
Hedberg & Alvestrand [Page 22]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
[8] Wahl, M., "A Summary of the X.500(96) User Schema for use with
LDAPv3" , RFC 2256, December 1997
[9] Kille, S., Wahl, M., Grimstad, A., Huber, R., Sataluri, S. "Using
Domains in LDAP/X.500 Distinguished Names", RFC 2247, January 1998
[10] Barker, P. and Kille, S., "The COSINE and Internet X.500
Schema", RFC 1274, November 1991
[11] Howes, T. and Wahl, M., "Referrals and Knowledge References in
LDAP Directories", draft-ietf-ldapext-referral-00.txt, March 1998
[12] Good, G., "The LDAP Data Interchange Format (LDIF) - Technical
Specification", draft-good-ldap-ldif-02.txt, February 1999
[13] Hedberg, R., "LDAPv2 client Vs the Index Mesh", draft-ietf-find-
cip-ldapv2-02.txt, November 1998
10 - Authors' Address
Roland Hedberg
Catalogix
Dalsveien 53
N-0775 Oslo
Norway
Phone: +47 23 08 29 96
EMail: Roland.Hedberg@catalogix.ac.se
Harald Tveit Alvestrand
Maxware
Pirsenteret
N-7005 Trondheim
Norway
Phone: +47 73 54 57 97
EMail: Harald@alvestrand.no
Hedberg & Alvestrand [Page 23]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
APPENDIX A - Attribute mapping
RIO server Registry Defined in
Bronnoysund(B)/
NORID (N)
--------------- ---------------- ----------
organizationID Orgnr. (B) This document
postalAddress Adresse (B) RFC2256 [8]
organization,o Navn (B) RFC2256 [8]
telephoneNumber Telefon (B) RFC2256 [8]
facsimileTelephoneNumber Telefaks (B) RFC2256 [8]
locality Poststed (B) RFC2256 [8]
postalCode Postnr (B) RFC2256 [8]
organizationType organisasjonsform (B) This document
associatedDomain domainname (N) RFC1274 [10]
nssref This document
Appendix B - Used Objectclasses and attributes
RFC2256 [8]
( 2.5.6.4 NAME 'organization' SUP top STRUCTURAL MUST o
MAY ( userPassword $ searchGuide $ seeAlso $ businessCategory $
x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationaliSDNNumber $
facsimileTelephoneNumber $
street $ postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ st $ l $ description ) )
( 2.5.6.8 NAME 'organizationalRole' SUP top STRUCTURAL MUST cn
MAY ( x121Address $ registeredAddress $ destinationIndicator $
preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $
telephoneNumber $ internationaliSDNNumber $
facsimileTelephoneNumber $
seeAlso $ roleOccupant $ preferredDeliveryMethod $ street $
postOfficeBox $ postalCode $ postalAddress $
physicalDeliveryOfficeName $ ou $ st $ l $ description ) )
( 2.5.6.6 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
RFC 1274 [10]
( 0.9.2342.19200300.100.4.17 NAME 'domainRelatedObject' SUP top
STRUCTURAL MUST associatedDomain )
Hedberg & Alvestrand [Page 24]
INTERNET-DRAFT The Norwegian Directory of Directories (NDD) 21 May 1999
draft-ietf-ldapext-referral-00.txt [11]
( 2.16.840.1.113730.3.1.34 NAME 'ref' DESC 'URL reference'
EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
USAGE distributedOperation )
( 2.16.840.1.113730.3.2.6 NAME 'referral' SUP top STRUCTURAL
MAY ( ref $ * ) )
draft-ietf-find-cip-ldapv2-02.txt [13]
( 1.2.752.17.1.21 NAME 'dSI' EQUALITY caseIgnoreIA5Match
SYNTAX IA5String )
Norsk Katalogforum
( T.B.D.1.1 NAME 'organizationType' DESC 'Organization Type'
EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) )
( T.B.D.1.2 NAME 'organizationID' DESC 'Organization Identifier'
EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) )
( T.B.D.1.3 NAME 'nssref' DESC 'URL reference'
EQUALITY caseExactIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
USAGE distributedOperation )
( T.B.D.2.1 NAME 'kfOrg' SUP top AUXILLIARY
MAY ( organizationType $ organizationID ) )
