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:
<ObjectClassDescription> ::= "("
<oid> -- ObjectClass identifier
[ "NAME" <DirectoryStrings> ]
[ "DESC" <DirectoryString> ]
[ "OBSOLETE" ]
[ "SUP" <oids> ] -- ObjectClass[es] from which this
class is derived
[ "PARENT" <oids> ] -- Permissible parents of this
object class
[ ( "ABSTRACT" | "STRUCTURAL" | "AUXILIARY" ) ]
[ "MUST" <oids> ] -- AttributeTypes
[ "MAY" <oids> ] -- 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:
<string-UUID>","<major>"."<minor>.
( 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:
<ProtocolSequence>":"<NetworkAddress>"[]" or
<ProtocolSequence>":"<NetworkHostName>"[]"
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:
<string-UUID>","<major>"."<minor>.
( 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,
<URL:ftp://ds.internic.net/rfc/rfc1777.txt>
[2] M. Wahl, T. Howes, S. Kille, et al. "Lightweight Directory
Access Protocol (Version 3)",
INTERNET-DRAFT <draft-ietf-asid-ldapv3-protocol-04.txt>,
February 1997.
[3] M. Wahl, A. Coulbeck, T. Howes, S. Kille, 'Lightweight
Directory Access Protocol: Standard and Pilot Attribute
Definitions',
INTERNET DRAFT <draft-ietf-asid-ldapv3-attributes-03.txt>
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]
