ASID Working Group S. Judd INTERNET-DRAFT Microsoft Corporation S. Thatte Microsoft Corporation P. Leach Microsoft Corporation W. Hopkins Hewlett-Packard Corporation Expires August 28, 1997 February 28, 1997 Lightweight Directory Access Protocol: Schema for Storing RPC Entries in a Directory Service < draft-ietf-asid-ldap-rpcschema-00.txt > 1. Status of this Memo This document is an Internet-Draft. 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." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 2. Abstract The Lightweight Directory Access Protocol [1][2] defines a standard protocol for accessing diverse directory services. One common use of a directory service is the location of application services, among which are RPC services. This document defines a set of object classes and attributes for storing metadata and binding information for RPC services that are DCE-compliant or closely follow the DCE model, in directories that support LDAP. Internet Draft Schema for Storing RPC Entries 28-Feb-1997 3. Table of Contents 1. Status of this Memo....................................1 2. Abstract...............................................1 3. Table of Contents......................................2 4. Overview...............................................2 5. Objects and Attributes.................................3 5.1. Notation...............................................4 5.2. Object Naming..........................................4 5.3. Object Definitions.....................................4 5.4. Attribute Definitions..................................6 6. Usage Model............................................9 6.1. DCE Relative Names.....................................10 7. Authors' Addresses.....................................10 8. Bibliography...........................................11 4. Overview This document defines a schema that conforms closely to the DCE conceptual model for RPC entries. This schema allows an RPC Name Service Interface (NSI) implementation to use LDAP to store RPC entries, and to use LDAP queries to implement the RPC Name Service Interface (NSI) lookup APIs. Note on terminology: in this document the terms "property" and "attribute" are used interchangeably. The requirement is to support three kinds of RPC Name Service Entries: @ Server Entries: server entries support the retrieval of a set of string bindings for any combination of Entry Name, Interface ID and version, Object ID, Transfer Syntax, and transfer syntax version @ Group Entries: a set of RPC entries identified by an Entry name @ Profile Entries: a profile establishes a priority-based search order through a set of entries. This is essentially a "list of sets" with the outer list ordered by priority and each inner set being a set of entries at the current priority DCE RPC defines the concept of a "mixed entry" in which a single entry serves multiple purposes - for example, entries that serve as both Group and Server entries. Mixed entries are not supported by this schema. This seldom-used DCE RPC feature leads to unnecessary complexity for both implementers and users of the RPC Name Service Interface. To meet these requirements the schema defines seven object classes: @ container @ rpcEntry @ rpcGroup Judd, Thatte, Leach, Hopkins [Page 2] Internet Draft Schema for Storing RPC Entries 28-Feb-1997 @ rpcServer @ rpcServerElement @ rpcProfile @ rpcProfileElement and 9 attributes: @ rpcNsObjectID @ rpcNsGroup @ rpcNsPriority @ rpcNsProfileEntry @ rpcNsInterrfaceId @ rpcNsAnnotation @ rpcNsCodeset @ rpcNsBindings @ rpcNsTransferSyntax Taken together these object classes and attributes implement the DCE-RPC concept of an "Entry". The rpcEntry object class is an abstract class from which all other RPC objects derive, so that they may be easily located in a search. An rpcGroup, rpcServer, or rpcProfile object forms the "root" of an entry. The type of entry is determined by the object class. Note that the types are mutually exclusive; an entry cannot serve multiple purposes. Separating the entry types into distinct object classes simplifies the task of the NSI provider in determining how to handle a given entry. Table 1: RPC Entry Types Entry Type Object Class(es) --------------------------------------------------------------- Group rpcGroup, holds a set of references to other RPC- Entry objects Profile rpcProfile, a container holding a set of rpcProfileEntry objects, each holding a list of references to entries with a given priority. Server rpcServer, a container holding a set of rpcServerElement objects, each holding the identification of one or more interfaces (and/or objects) offered by a given server --------------------------------------------------------------- 5. Objects and Attributes The 'top', 'country', 'locality', 'organization' and 'organizationalUnit' object classes are included in the "LDAPv3 Standard and Pilot Attribute Definitions", a work in progress [2]. Judd, Thatte, Leach, Hopkins [Page 3] Internet Draft Schema for Storing RPC Entries 28-Feb-1997 5.1. Notation The notation used in this document is the same as that used in [2], with the following difference: the referenced notation does not allow the expression of both permissible parentage and class inheritance. The BNF in [2] for defining object classes is therefore extended as follows: ::= "(" -- ObjectClass identifier [ "NAME" ] [ "DESC" ] [ "OBSOLETE" ] [ "SUP" ] -- ObjectClass[es] from which this class is derived [ "PARENT" ] -- Permissible parents of this object class [ ( "ABSTRACT" | "STRUCTURAL" | "AUXILIARY" ) ] [ "MUST" ] -- AttributeTypes [ "MAY" ] -- AttributeTypes ")" 5.2. Object Naming All objects have 'cn' (Common-name) as their naming attribute; this attribute provides the RDN for the object. 'cn' is included in [2] and defined in [4]. 5.3. Object Definitions 5.3.1. Container The Container object is a general purpose container for use in building containment hierarchies, and is not specific to RPC. (1.2.840.113556.1.3.23 NAME 'container' SUP top PARENT (country $organization $ organizationalUnit $ locality $ container) ) 5.3.2. RPC Entry The RPC Entry is an abstract class from which all other RPC classes are derived. Judd, Thatte, Leach, Hopkins [Page 4] Internet Draft Schema for Storing RPC Entries 28-Feb-1997 ( 1.2.840.113556.1.5.27 NAME 'rpcEntry' SUP top ABSTRACT MUST cn ) 5.3.3. RPC Group The rpcGroup object defines an RPC Group. The cn is the RDN component of the entry name provided by the user in the NSI API call that creates the group. The rpcNsObjectID attribute contains string UUIDs of objects added to the group entry by applications. These Object IDs are not used by the NSI provider during lookup operations. ( 1.2.840.113556.1.5.80 NAME 'rpcGroup' SUP rpcEntry PARENT (country $organization $ organizationalUnit $ locality $ container) STRUCTURAL MUST rpsNsGroup MAY rpcNsObjectID ) 5.3.4. RPC Profile RPC Profile entries are implemented by two object classes. The rpcProfile object class is a container. It is used to gather profile elements into a single profile instance. The cn is the RDN component of the entry name provided by the user in the NSI API call that creates the profile. ( 1.2.840.113556.1.5.82 NAME 'rpcProfile' SUP rpcEntry PARENT (country $ organization $ organizationalUnit $ locality $ container) STRUCTURAL ) The rpcProfileElement object describes a single element in the profile. The entire profile is retrieved with a single-level LDAP search rooted at the parent rpcProfile container. The cn is a string UUID generated by the NSI provider when the rpcProfileElement instance is created. ( 1.2.840.113556.1.5.26 NAME 'rpcProfileElement' SUP rpcEntry Judd, Thatte, Leach, Hopkins [Page 5] Internet Draft Schema for Storing RPC Entries 28-Feb-1997 PARENT rpcProfile STRUCTURAL MUST ( rpcNsPriority $ rpcNsProfileEntry $ rpcNsInterfaceId ) MAY rpcNsAnnotation ) 5.3.5. RPC Server RPC Server entries are implemented by two object classes. The rpcServer object class is a container. It is used to gather rpcServerElement entries into a single server instance. The CN is the RDN component of the entry name provided by the user in the NSI API call that creates the server entry. ( 1.2.840.113556.1.5.81 NAME 'rpcServer' SUP rpcEntry PARENT (country $ organization $ organizationalUnit $ locality $ container) STRUCTURAL MAY ( rpcNsObjectID $ rpcNsCodeSet ) ) The rpcServerElement object describes a single interface in the server entry. The entire Server entry is retrieved with a single-level LDAP search rooted at the parent rpcServer container. The properties of the rpcServerElement object allow for efficient searching using straightforward LDAP query expressions. The CN is a string UUID generated by the NSI provider when the rpcServerElement instance is created. ( 1.2.840.113556.1.5.73 NAME 'rpcServerElement' SUP rpcEntry PARENT rpcServer STRUCTURAL MUST ( rpcNsInterfaceID $ rpcNsBindings $ rpcNsTransferSyntax ) ) 5.4. Attribute Definitions RPC Name Service implementations search on a well-known set of properties.Implementations of this schema are advised to index the following properties for performance reasons: - rpcNsObjectID - rpcNsInterfaceID Judd, Thatte, Leach, Hopkins [Page 6] Internet Draft Schema for Storing RPC Entries 28-Feb-1997 5.4.1. rpcNsObjectID A set of string UUIDs for objects (in the DCE RPC sense of objects). ( 1.2.840.113556.1.4.312 NAME 'rpcNsObjectID' EQUALITY caseIgnoreListMatch SYNTAX directoryString USAGE userApplications ) 5.4.2. rpcNsGroup A set of DN's for RPC entries that are members of a given RPC group. ( 1.2.840.113556.1.4.114 NAME 'rpcNsGroup' EQUALITY distinguishedNameMatch SUBSTRING distinguishedNameMatch SYNTAX DN USAGE userApplications ) 5.4.3. rpcNsPriority An integer value indicating the priority of a given RPC profile element. ( 1.2.840.113556.1.4.117 NAME 'rpcNsPriority' EQUALITY integerMatch SYNTAX INTEGER USAGE userApplications ) 5.4.4. rpcNsProfileEntry The DN of a single RPC entry that is a member of a given RPC profile. ( 1.2.840.113556.1.4.118 NAME 'rpcNsGroup' EQUALITY distinguishedNameMatch SUBSTRING distinguishedNameMatch SYNTAX DN SINGLE-VALUE USAGE userApplications ) Judd, Thatte, Leach, Hopkins [Page 7] Internet Draft Schema for Storing RPC Entries 28-Feb-1997 5.4.5. rpcNsInterfaceId A string composed of the UUID for an interface exported by an RPC server, and the interface major and minor version numbers in the form: ","".". ( 1.2.840.113556.1.4.115 NAME 'rpcNsInterfaceID' EQUALITY caseIgnoreMatch SYNTAX directoryString SINGLE-VALUE USAGE userApplications ) 5.4.6. rpcNsAnnotation A string describing a given RPC Profile element. ( 1.2.840.113556.1.4.366 NAME 'rpcNsAnnotation' EQUALITY caseIgnoreMatch SUBSTRING caseIgnoreMatch SYNTAX directoryString SINGLE-VALUE USAGE userApplications ) 5.4.7. rpcNsCodeSet A set of strings identifying the character sets supported by a given RPC server. ( 1.2.840.113556.1.4.367 NAME 'rpcNsCodeset' EQUALITY caseIgnoreListMatch SYNTAX directoryString USAGE userApplications ) 5.4.8. rpcNsBindings A set of binding strings for a given interface and transfer syntax, in the form: ":""[]" or ":""[]" Judd, Thatte, Leach, Hopkins [Page 8] Internet Draft Schema for Storing RPC Entries 28-Feb-1997 ( 1.2.840.113556.1.4.113 NAME 'rpcNsBindings' EQUALITY caseIgnoreMatch SYNTAX directoryString USAGE userApplications ) 5.4.9. rpcNsTransferSyntax A set of strings composed of the string UUID for a transfer syntax supported by an RPC server, and the transfer syntax major and minor version numbers in the form: ","".". ( 1.2.840.113556.1.4.314 NAME 'rpcNsTransferSyntax' EQUALITY caseIgnoreListMatch SYNTAX directoryString USAGE userApplications ) 6. Usage Model Instantiating an rpcGroup, rpcProfile, or RPCServer object and any necessary child objects (e.g. rpcServerElement or rpcProfileElement) can create any RPC entry type. Searching is simplified because there is a well-known set of object classes and attributes for each entry type. A group entry contains the rpcNsGroup property listing the entries in the group. Each group is a single object and can be retrieved in a single operation. An rpcGroup object may have rpcNsObjectID present - the list of object ID's, if present, are explicitly stored and retrieved by applications and are not used by the NSI provider in locating rpcNsGroup objects. A profile entry consists of an rpcProfile container with one or more rpcProfileEntry objects as children, one for each priority level defined. The complete profile is retrieved in a single operation by performing a single-level LDAP search for objects of class rpcProfileElement rooted at the rpcProfile entry. A server entry consists of an rpcServer container with one or more rpcServerElement objects as children. The complete entry is retrieved in a single operation by performing a single-level LDAP search for objects of class rpcServerElement rooted at the rpcProfile entry. The NSI provider creates a new rpcServerElement entry when the interface and transfer syntax provided by the caller do not match an existing rpcServerElement in the named server entry. If a matching rpcServerElement exists, the NSI provider updates it with the string bindings provided by the caller. Judd, Thatte, Leach, Hopkins [Page 9] Internet Draft Schema for Storing RPC Entries 28-Feb-1997 This schema allows many discrete rpcServerElement objects to be stored in a given entry. This avoids a number of problems in trying to store multiple interfaces with their versions and transfer syntaxes in a single entry while providing convenient access and searching via LDAP. Indexing the Interface ID and Object UUID's reduces the performance cost for retrieving multiple objects. 6.1. DCE Relative Names DCE RPC allows names presented to the RPC Name Service Interface to be absolute or relative. An absolute name contains the full DN of the entry in question. A relative name is relative to the DCE Cell where the name is stored. The full DN is the DN of the cell with the relative name appended. When using an LDAP directory to store RPC entries as defined by this schema, the implementation of relative names is implementation dependent, but should be consistent. A suggested approach is the creation of a container at the root of the namespace (e.g. directly below the first instantiated object, such as Organization or organizationalUnit) called RpcServices, which forms the root for 'cell-relative' names. 7. Authors' Addresses Steven G. Judd Microsoft Corporation 1 Microsoft Way Redmond, WA. 98053 USA e-mail: stevenju@microsoft.com Paul Leach Microsoft Corporation 1 Microsoft Way Redmond, WA. 98053 USA e-mail: paulle@microsoft.com Satish Thatte Microsoft Corporation 1 Microsoft Way Redmond, WA. 98053 USA e-mail: satisht@microsoft.com Judd, Thatte, Leach, Hopkins [Page 10] Internet Draft Schema for Storing RPC Entries 28-Feb-1997 William S. Hopkins Hewlett-Packard Corporation 300 Apollo Drive Chelmsford, MA. 01824 e-mail: hopkins@apollo.hp.com 8. Bibliography [1] W. Yeong, T. Howes, S. Kille, 'Lightweight Directory Access Protocol', RFC 1777, March 1995, [2] M. Wahl, T. Howes, S. Kille, et al. "Lightweight Directory Access Protocol (Version 3)", INTERNET-DRAFT , February 1997. [3] M. Wahl, A. Coulbeck, T. Howes, S. Kille, 'Lightweight Directory Access Protocol: Standard and Pilot Attribute Definitions', INTERNET DRAFT October 1996 [4] The Directory: Selected Attribute Types. ITU-T Recommendation X.520, 1993. [5] The Directory: Selected Object Classes. ITU-T Recommendation X.521, 1993. Judd, Thatte, Leach, Hopkins [Page 11]