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 ) )