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=, 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=,]dc= 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=, C=no, with a valid Broennoeysund register number - O=, C=no, with a registered organization name - O=, C=, where is registered in according to applicable rules in that country - O=, where 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 ) )