This Recommendation1 describes a directory services architecture for multimedia conferencing using lightweight directory access protocol (LDAP). Standardized directory services can support the association of persons with endpoints@ searchable white pages@ and clickable dialling. Directory services can also assist in the configuration of endpoints@ and user authentication based on authoritative data sources. This Recommendation describes a standardized LDAP schema to represent endpoints on the network and associate those endpoints with users. It discusses design and implementation considerations for the interrelation of video and voice-specific directories@ enterprise directories@ call servers and endpoints. The use of a common@ authoritative data source for call server@ endpoint@ user@ authentication and white pages information is an important aspect of large scale multimedia conferencing environments. Without a common data source@ service providers must create separate processes to manage each of these functions. By standardizing the LDAP schema used to represent the underlying data@ products from different system vendors can be deployed together to create an overall application environment. For example@ a white pages search engine developed by one provider could serve directory information to IP telephones produced by a second provider@ with signalling managed by a call server produced by yet a third provider. Each of these disparate systems can access the same underlying data source@ reducing or eliminating the need to coordinate the separate management of each system. A significant benefit to the user is that the management of this data can be incorporated into existing customer management tools@ allowing for quick and flexible scaling up of applications. Indeed@ many technology providers have already incorporated LDAP into their products@ but have been forced to do so without the benefit of a standardized schema. This Recommendation represents an effort to standardize those representations to improve interoperability and performance. While URLs are already standardized for several conferencing protocols@ their representation in a directory is not. This Recommendation supports a standardized way for URLs to be searched and located. This is a necessary step to support 'clickable dialling'. Management of endpoint configurations can be improved if the correct settings are stored by the service provider in a location that is accessible to both service provider and endpoint. LDAP provides a convenient storage location that can be accessed by both call server and endpoint; thus it is possible to use the directory to support the endpoint configuration@ which is important for simplified operation and supporting user mobility. Note that other technologies also support endpoint configuration@ notably the use of SNMP for complete configuration and DNS SRV resource records for obtaining registration server addresses. Therefore@ ITU-T H.350 should be viewed not as an authoritative endpoint configuration architecture@ but rather one tool that can assist with this task. Note that the use of ITU-T H.350 has as a feature endpoint specific configuration@ where it is desirable that each endpoint have a unique configuration. This architecture uses a generic object class@ called commObject@ to represent attributes common to any video or voice protocol. Auxiliary classes represent specific protocols@ such as ITU-T H.323@ ITU-T H.235.x@ or ITU-T H.320@ as described in the ITU-T H.350.x series of Recommendations. Multiple ITU-T H.350.x classes can be combined to represent endpoints that support more than one protocol. For example@ endpoints that support ITU-T H.323@ ITU-T H.235.x and ITU-T H.320 would include ITU-T H.350@ ITU-T H.350.1@ ITU-T H.350.2@ and ITU-T H.350.3 in their LDAP representations. Furthermore@ each entry should contain commObject to serve as the entry's structural object class. There are two basic components in the architecture. The commURI object is a class whose only purpose is to link a person or resource to a commObject. By placing a commURI 'pointer' in an individual's directory entry@ that individual becomes associated with the particular targeted commObject. Similarly@ each commObject contains a pointer@ called commOwner@ which points to the individual or resource that is associated with the commObject. In this way@ people or resources can be associated with endpoints. The only change required to the enterprise directory is the addition of the simple object class commURI. CommObject data may be instantiated in the same or an entirely separate directory@ thus allowing flexibility in implementation. 1 This Recommendation includes an electronic attachment containing schema configuration files for commURIObject and commObject.