Internet DRAFT - draft-h350-directory-services

draft-h350-directory-services




Internet Draft                                               T. Johnson 
Document: draft-h350-directory-services-00.txt     U. of North Carolina 
Category: Informational                                        S. Okubo 
Expires: May 2004                                     Waseda University 
                                                               S.Campos 
                                                                  ITU-T 
                                                          November 2003 
                                                                        
    
                        H.350 Directory Services 
    
    
Status of this Memo 
    
   This document is an Internet-Draft and is NOT offered in accordance 
   with Section 10 of RFC2026, and the author does not provide the IETF 
   with any rights other than to publish as 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." 
    
   The list of current Internet-Drafts can be accessed at 
   http://www.ietf.org/1id-abstracts.html 
    
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 
    
Abstract 
    
   The International Telecommunications Union Standardization Sector 
   (ITU-T) has created the H.350 series of Recommendations that specify 
   directory services architectures in support of multimedia 
   conferencing protocols. The goal of the architecture is to 
   'directory enable' multimedia conferencing so that these services 
   can leverage existing identity management and enterprise 
   directories. A particular goal is to enable an enterprise or service 
   provider to maintain a canonical source of users and their 
   multimedia conferencing systems, so that multiple call servers from 
   multiple vendors, supporting multiple protocols, can all access the 
   same data store. 
    
   Because SIP is an IETF standard, the contents of H.350 and H.350.4 
   are made available via this document to the IETF community. 
    
 
 
 
Johnson            Informational - Expires May 2004           [Page 1] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
Table of Contents 
    
   H.350 Directory Services...........................................1 
   Status of this Memo................................................1 
   Abstract...........................................................1 
   Table of Contents..................................................2 
   1.   Scope........................................................2 
   2.   Terminology..................................................3 
   3.   Conventions used in this document............................4 
   4.   H.350........................................................4 
   4.1.   Scope.......................................................4 
   4.1.1.  Design Goals..............................................6 
   4.1.2.  Extending the Schema......................................7 
   4.2.   commURIObject Definition....................................9 
   4.2.1.  commURIObject............................................10 
   4.2.2.  commURI..................................................10 
   4.3.   CommObject Definition......................................10 
   4.3.1.  commObject...............................................11 
   4.3.2.  commUniqueId.............................................11 
   4.3.3.  commOwner................................................11 
   4.3.4.  commPrivate..............................................12 
   4.4.   CommObject LDIF Files......................................12 
   4.4.1.  LDIF for commURIObject...................................13 
   4.4.2.  LDIF for commObject......................................14 
   4.5.   H.350 Annex A Indexing Profile.............................16 
   5.   H.350.4.....................................................16 
   5.1.   Scope......................................................16 
   5.1.1.  Extending the schema.....................................17 
   5.2.   Object class definitions...................................17 
   5.2.1.  SIPIdentity..............................................17 
   5.2.2.  SIPIdentitySIPURI........................................18 
   5.2.3.  SIPIdentityRegistrarAddress..............................18 
   5.2.4.  SIPIdentityProxyAddress..................................19 
   5.2.5.  SIPIdentityAddress.......................................20 
   5.2.6.  SIPIdentityPassword......................................20 
   5.2.7.  SIPIdentityUserName......................................21 
   5.2.8.  SIPIdentityServiceLevel..................................21 
   5.3.   SIPIdentity LDIF Files.....................................22 
   5.4.   H.350.4 Annex A Indexing profile...........................25 
   6.   Acknowledgments.............................................25 
   7.   Normative References........................................26 
   8.   Informative References......................................26 
   9.   Security Considerations.....................................26 
   10.  Contact Information.........................................27 
    
1. Scope 
   The International Telecommunications Union Standardization Sector 
   (ITU-T) has created the H.350 series of Recommendations that specify 
   directory services architectures in support of multimedia 
   conferencing protocols. The goal of the architecture is to 
 
 
 
Johnson            Informational - Expires May 2004           [Page 2] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   'directory enable' multimedia conferencing so that these services 
   can leverage existing identity management and enterprise 
   directories. A particular goal is to enable an enterprise or service 
   provider to maintain a canonical source of users and their 
   multimedia conferencing systems, so that multiple call servers from 
   multiple vendors, supporting multiple protocols, can all access the 
   same data store. 
    
   H.350 architectures are not intended to change the operation of 
   multimedia conferencing protocols in any way. Rather, they are meant 
   to standardize the way the already defined protocol elements are 
   stored in a directory, so that they can be accessed in a 
   standardized manner. 
    
   In the H.350 series, Recommendation H.350 specifies the base 
   architecture and object classes, while subordinate Recommendations 
   specify elements that are specific to individual protocols. 
   Currently, the Recommendations include: 
    
   H.350  Directory Services Architecture for Multimedia Conferencing 
   H.350.1 - Directory Services Architecture for H.323 
   H.350.2 - Directory Services Architecture for H.235 
   H.350.3 - Directory Services Architecture for H.320 
   H.350.4 - Directory Services Architecture for SIP 
   H.350.5 - Directory Services Architecture for Non-Standard Protocols 
    
   Because SIP is an IETF standard, the contents of H.350 and H.350.4 
   are made available via this document to the IETF community. 
    
2. Terminology 
    
   The following terms are used throughout the document: 
    
   *  call server: a protocol-specific signalling engine that routes 
      video or voice calls on the network. In H.323 this entity is a 
      gatekeeper. In SIP, this entity is a SIP Proxy Server. Note that 
      not all signalling protocols use a call server. 
    
   *  endpoint: a logical device that provides video and/or voice media 
      encoding/decoding, and signalling functions. Examples include: 
    
      *  a group teleconferencing appliance that is located in a 
         conference room 
      *  an IP telephone.  
      *  a software program that takes video and voice from a camera 
         and microphone and encodes it and applies signalling using a 
         host computer. 
    
   *  enterprise directory: A canonical collection of information about 
      users in an organization. Typically this information is collected 
 
 
 
Johnson            Informational - Expires May 2004           [Page 3] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
      from a variety of organizational units to create a whole. For 
      example, Human Resources may provide name and address, 
      Telecommunications may provide the telephone number, Information 
      Technology may provide the email address, etc. For the purposes 
      of this architecture, it is assumed that an enterprise directory 
      is accessible via LDAP. 
    
   *  White Pages: An application that allows end users to look up the 
      address of another user. This may be web-based or use some other 
      user interface. 
 
3. Conventions used in this document 
    
   Conventions in this document conform to ITU-T guidelines. In this 
   Recommendation, the following conventions are used: 
    
   "Shall" indicates a mandatory requirement. 
    
   "Should" indicates a suggested but optional course of action. 
    
   "May" indicates an optional course of action rather than a 
   recommendation that something take place. 
    
   References to clauses, sub clauses, annexes and appendices refer to 
   those items within this Recommendation unless another specification 
   is explicitly listed. 
    
    
4. H.350  
    
   The normative text of H.350 is reproduced in this section. 
    
4.1. Scope 
    
   This Recommendation describes a directory services architecture for 
   multimedia conferencing using LDAP. Standardized directory services 
   can support 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 document 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 inter-relation 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 
 
 
 
Johnson            Informational - Expires May 2004           [Page 4] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   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 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 incorporate LDAP into their products, but 
   have been forced to do so without 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 
   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 SRV records for obtaining registration server 
   addresses. Therefore, 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 H.350 has as a feature 
   endpoint specific configuration, where it is desirable that each 
   endpoint has 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 H.323, 
   H.235, or H.320, as described in the H.350.x series of 
   Recommendations. Multiple H.350.x classes can be combined to 
   represent endpoints that support more than one protocol. For 
   example, endpoints that support H.323, H.235 and H.320 would include 
   H.350, H.350.1, H.350.2, and H.350.3 in their LDAP representations. 
   Further, each entry should contain commObject to serve as the 
   entry's structural object class. 
    
 
 
 
Johnson            Informational - Expires May 2004           [Page 5] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   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, 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 in the enterprise directory is the addition of the simple 
   object class commURI. CommObject data may be instantiated in the 
   same or in entirely separate directories, thus allowing flexibility 
   in implementation. 
    
4.1.1.  Design Goals 
    
   Large-scale deployments of IP video and voice services have 
   demonstrated the need for complementary directory services 
   middleware. Service administrators need call servers that are aware 
   of enterprise directories to avoid duplication of account management 
   processes. Users need 'white pages' to locate other users with whom 
   they wish to communicate. All of these processes should pull their 
   information from canonical data sources in order to reduce redundant 
   administrative processes and ensure information accuracy. The 
   following design criteria are established for this architecture. The 
   architecture will: 
    
   1)   enable endpoint information to be associated with people. 
   Alternately it enables endpoint information to be associated with 
   resources such as conference rooms or classrooms; 
    
   2)   enable online searchable "white pages" where dialling 
   information (e.g. endpoint addresses) can be found, along with other 
   "traditional" directory information about a user, such as name, 
   address, telephone, email, etc.; 
    
   3)   enable all endpoint information to be stored in a canonical 
   data source (the Directory), rather than local to the call server, 
   so that endpoints can be managed through manipulations of an 
   enterprise directory, rather than by direct entry into the call 
   server; 
    
   4)   support the creation of very large-scale distributed 
   directories. These include white pages "portals" that allow 
   searching for users across multiple institutional directories. In 
   this application, each enterprise directory registers itself with 
   (or is unknowingly discovered by) a directory of directories that is 
   capable of searching across multiple LDAP directories; 
    
   5)   be able to support multiple instances of endpoints per user or 
   resource; 
 
 
 
Johnson            Informational - Expires May 2004           [Page 6] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
    
   6)   represent endpoints that support more than one protocol, for 
   example, endpoints that are both H.320 and H.323; 
    
   7)   store enough information about endpoint configuration so that 
   correct configuration settings can be documented to end users on a 
   per-endpoint basis, as a support tool, or loaded automatically into 
   the endpoint; 
    
   8)   be extendable as necessary to allow implementation-specific 
   attributes to be included; 
    
   9)   be non-invasive to the enterprise directory, so that support 
        for multimedia conferencing can be added in a modular fashion 
        without significant changes to the enterprise directory. 
    
   The scope of this Recommendation does not include extensions of 
   functionality to protocols as defined within the protocols 
   themselves. It is not the intent of the Recommendation to add 
   features, but merely to represent existing protocol attributes. The 
   exception to this case is when functionality is implied by the 
   directory itself, such as the commPrivate attribute. 
    
4.1.2.  Extending the Schema 
    
   H.350 object classes may be extended as necessary for specific 
   implementations. For example, a class may be extended to support 
   billing reference codes. Extensions to the schema are not considered 
   as part of the Recommendation and do not signify compliance. 
    
   In some cases it may be necessary to extend the H.350 schemas in 
   order to represent more information than is supported by the 
   Recommendations. This may be important for developers that implement 
   proprietary endpoint functionality that needs to be represented by 
   attributes in the directory. It may also be important for enterprise 
   applications. For example 'modelNumber', and 'accountNumber' are 
   examples of attributes that are not defined in the Recommendation 
   but may be useful if implemented. Adding attributes to this 
   architecture must be done in a way that does not break compatibility 
   with this Recommendation. 
    
   A full discussion of schema design and extension is beyond the scope 
   of this Recommendation. See IETF RFC 2252 for details. Two basic 
   approaches to schema extension that do not break compatibility with 
   this Recommendation, are extension through subclass and extension 
   through the use of auxiliary classes. 
    
4.1.2.1.  Extension Through Subclass 
    
 
 
 
Johnson            Informational - Expires May 2004           [Page 7] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   It is possible to create a subclass of an existing predefined object 
   class in order to add new attributes to it. To create a subclass, a 
   new object class must be defined, that is a subclass of the existing 
   one, by indicating in the definition of the new class that the 
   existing class is its superior. Once the subclass is created, new 
   attributes can be defined within it. 
    
   The following example shows how the commObject class can be 
   subclassed in order to add an attribute to represent a billing 
   account and a billing manager. 
    
   objectclass ( BillingInfo-OID 
   NAME 'BillingInfo' 
   DESC 'Billing Reference Information' 
   SUP commObject STRUCTURAL 
   MAY ( BillingAccount $ BillingManager $ ) 
   ) 
    
   Note that BillingInfo-OID must be replaced by an actual OID. Also 
   note that, whenever a structural class is extended, its subclass 
   must also be structural. 
    
   The following sample entry shows the newly created attributes. This 
   example also uses ITU-T Rec. H.350.1 for h323Identity. 
    
   dn: commUniqueId=2000,ou=h323identity, dc=company, dc=com 
   objectclass: top 
   objectclass: commObject 
   objectclass: h323Identity 
   objectclass: BillingInfo 
   commUniqueId: 2000 
   BillingAccount: 0023456 
   BillingManager: John Smith 
    
   Note that this example and approach demonstrate extension of the 
   general commObject object class, and not any individual H.350.x 
   classes. If it is desired to extend an H.350.x auxiliary class, then 
   that should be accomplished through the definition of additional 
   auxiliary classes that support the desired attributes, as described 
   in section 4.1.2.2. 
    
4.1.2.2.  Extension Through The Use Of Auxiliary Classes 
    
   It is possible to add attributes to an LDAP entry by defining an 
   auxiliary class containing the new attributes and applying those 
   attributes to instantiated values in the directory. The auxiliary 
   class will not be subclassed from any existing object class. Note 
   that it should have the special class top as its superior. The 
   following example creates the same billing account and billing 
 
 
 
Johnson            Informational - Expires May 2004           [Page 8] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   manager attributes as the previous example, but does so by defining 
   them in their own auxiliary class. 
    
   objectclass ( BillingInfo-OID 
   NAME 'BillingInfo' 
   DESC 'Billing Reference Information' 
   SUP top AUXILIARY 
   MAY ( BillingAccount $ BillingManager $ ) 
   ) 
    
   Note how the superior was changed from commObject to top and the 
   object class changed from being a structural to auxiliary. 
    
   It is recommended that all attributes in the auxiliary class be 
   optional rather than mandatory. In this way, the auxiliary object 
   class itself can be associated with an entry regardless of whether 
   any values for its attributes are present. 
    
   The following example shows a sample endpoint that utilizes the new 
   auxiliary class and attributes. This example also uses H.350.1 for 
   h323Identity. 
    
   dn: commUniqueId=2000,ou=h323identity, dc=company, dc=com 
   objectclass: top 
   objectclass: commObject 
   objectclass: BillingInfo 
   commUniqueId: 2000 
   BillingAccount: 0023456 
   BillingManager: John Smith 
    
4.1.2.3.  Object Identifiers 
    
   An attribute's Object Identifier (OID) is a unique numerical 
   identifier usually written as a sequence of integers separated by 
   dots. For example, the OID for the commUniqueId is 
   0.0.8.350.1.1.2.1.1. All attributes must have an OID. OIDs can be 
   obtained from anyone who has one and is willing to delegate a 
   portion of it as an arc, keeping a record of the arc to avoid 
   duplication. Further, the Internet Assigned Numbers Authority (IANA) 
   gives out OIDs to any organization that asks. 
 
4.2. commURIObject Definition 
    
   Auxiliary object class that contains the commURI attribute. This 
   attribute is added to a person or resource object to associate one 
   or more commObject instances with that object. Its values are LDAP 
   URIs that point to the associated commObjects, for example, to a 
   user's H.323 conferencing station and SIP IP phone. Note that 
   multiple instances of commURI need not point to the same commObject 
 
 
 
Johnson            Informational - Expires May 2004           [Page 9] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   directory. In fact, each commURI instance could point to an endpoint 
   managed by a different service provider. 
    
4.2.1.  commURIObject 
    
   OID: 0.0.8.350.1.1.1.2.1 
   objectclasses: (0.0.8.350.1.1.1.2.1 
   NAME 'commURIObject' 
   DESC 'object that contains the URI attribute type' 
   SUP top AUXILIARY 
   MAY ( commURI ) 
   ) 
    
4.2.2.  commURI 
    
   OID: 0.0.8.350.1.1.1.1.1 
   attributetypes:( 0.0.8.350.1.1.1.1.1 
   NAME 'commURI' 
   DESC 'Labeled URI format to point to the distinguished name of the 
   commUniqueId' 
   EQUALITY caseExactMatch 
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 
   Application utility class 
        Standard 
   Number of values 
        multi 
   Definition 
        Labelled URI containing an LDAP URL identifying the directory 
   containing the referenced commObject instance. The search filter 
   specified by this LDAP URL shall specify an equality search of the 
   commUniqueId attribute of the commObject class. 
   Permissible values (if controlled) 
   Notes 
        Used to find the endpoint of the user in question. The label 
   field may be used to represent the function of the endpoint, such as 
   'home IP phone' or 'desktop video' for user interface display 
   purposes. 
        Note that the label portion of the field may contain spaces as 
   in the example below showing 'desktop video'. 
   Semantics 
   Example applications for which this attribute would be useful 
   Example (LDIF fragment) 
   commURI: 
   ldap://directory.acme.com/dc=acme,dc=com??sub?(commUniqueId=bob) 
   desktop video 
    
4.3. CommObject Definition  
    
   Abstraction of video or voice over IP device. The commObject class 
   permits an endpoint (H.323 endpoint or SIP user agent or other 
 
 
 
Johnson            Informational - Expires May 2004          [Page 10] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   protocol endpoint) and all their aliases to be represented by a 
   single entry in a directory. Note that every directory entry should 
   contain commObject as the entry's structural object class. That 
   entry may also contain H.350.x auxiliary classes. 
    
4.3.1.  commObject 
    
   OID: 0.0.8.350.1.1.2.2.1 
   objectclasses: (0.0.8.350.1.1.2.2.1 
   NAME 'commObject' 
   DESC 'object that contains the Communication attributes' 
   SUP top STRUCTURAL 
   MUST commUniqueId 
   MAY ( commOwner $ commPrivate ) 
   ) 
    
4.3.2.  commUniqueId 
    
   OID: 0.0.8.350.1.1.2.1.1 
   attributetypes: (0.0.8.350.1.1.2.1.1 
   NAME 'commUniqueId' 
   DESC 'To hold the endpoints unique Id' 
   EQUALITY caseIgnoreIA5Match 
   SUBSTR caseIgnoreIA5SubstringsMatch 
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 
   Application utility class 
        standard 
   Number of values 
        multi 
   Definition 
        The endpoint's unique ID. 
   Permissible values (if controlled) 
   Notes 
        This is the RDN of this object. In practice, there will always 
   be one and only one commUniqueId for every endpoint. This attribute 
   uniquely identifies an endpoint in the commObject directory. It must 
   be unique within that directory, but need not be unique globally. 
   This attribute has no relationship to the enterprise directory. 
   Semantics 
   Example applications for which this attribute would be useful 
   Example (LDIF fragment) 
   commUniqueId: bob 
    
4.3.3.  commOwner 
    
   OID: 0.0.8.350.1.1.2.1.2 
   attributetypes: 0.0.8.350.1.1.2.1.2 
   NAME 'commOwner' 
   DESC 'Labeled URI to point back to the original owner' 
   EQUALITY caseExactMatch 
 
 
 
Johnson            Informational - Expires May 2004          [Page 11] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 
   Application utility class 
        Standard 
   Number of values 
        multi 
   Definition 
        Labelled URI format to point back to the person or resource 
   object associated with this entry. 
   Permissible values (if controlled) 
   Notes 
        Used as a reverse entry finder of the owner(s). This attribute 
   may point to groups. Note that this URI can point to a cn, but in 
   applications where it is desired to bind authentication information 
   across both the commObject and enterprise directories, it may be 
   desirable that commOwner points to a dn rather than a cn, thus 
   uniquely identifying the owner of the commObject. 
   Semantics 
   Example applications for which this attribute would be useful 
   Example (LDIF fragment) 
   commOwner: 
   ldap://directory.acme.com/dc=acme,dc=com??sub?(cn=bob%20smith) 
   commOwner: uid=bob,ou=people,dc=acme,dc=com 
    
4.3.4.  commPrivate 
    
   OID: 0.0.8.350.1.1.2.1.3 
   attributetypes: (0.0.8.350.1.1.2.1.3 
   NAME 'commPrivate' 
   DESC 'To decide whether the entry is visible to world or not' 
    SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 
   Application utility class 
        Standard 
   Number of values 
        multi 
   Definition 
        To be used by the user and indicate privacy options for an 
   endpoint,  i.e. unlisted number. 
   Permissible values (if controlled) 
   Notes 
        This attribute is defined as Boolean. Future version of this 
   Recommendation may develop a controlled vocabulary for this 
   attribute to accommodate multiple types of privacy. 
   Semantics 
   Example applications for which this attribute would be useful 
   Example (LDIF fragment) 
   commPrivate: true 
    
4.4. CommObject LDIF Files  
    
 
 
 
Johnson            Informational - Expires May 2004          [Page 12] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   This section contains a schema configuration file for commURIObject 
   and commObject that can be used to configure an LDAP server to 
   support these classes. 
    
4.4.1.  LDIF for commURIObject 
    
   # Communication Object Schema 
   # 
   # Schema for Representing Communication Objects in an LDAP Directory 
   #  
   # Abstract 
   #  
   # This document defines the schema for representing Communication  
   # objects in an LDAP directory [LDAPv3].  It defines schema elements 
   # to represent a communication object URI [commURIObject].  
   #  
   # 
   # 
   #                     .1 = Communication related work  
   #                     .1.1 = commURIObject 
   #                     .1.1.1 = attributes 
   #                     .1.1.2 = objectclass 
   #                     .1.1.3 = syntax 
   # 
   # Attribute Type Definitions 
   #  
   #    The following attribute types are defined in this document: 
   #  
   #        commURI 
   dn: cn=schema  
   changetype: modify  
   # 
   # if you need to change the definition of an attribute,  
   #            then first delete and re-add in one step 
   # 
   # if this is the first time you are adding the commObject 
   # objectclass using this LDIF file, then you should comment 
   # out the delete attributetypes modification since this will 
   # fail. Alternatively, if your ldapmodify has a switch to continue 
   # on errors, then just use that switch -- if you're careful 
   # 
   delete: attributetypes 
   attributetypes: (0.0.8.350.1.1.1.1.1 NAME 'commURI' )  
   - 
   # 
   # re-add the attributes -- in case there is a change of definition 
   # 
   #  
   add: attributetypes  
   attributetypes: (0.0.8.350.1.1.1.1.1  
 
 
 
Johnson            Informational - Expires May 2004          [Page 13] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
        NAME 'commURI'  
        DESC 'Labeled URI format to point to the distinguished name of 
   the commUniqueId'  
        EQUALITY caseExactMatch  
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )  
   - 
   # Object Class Definitions 
   #  
   #    The following object classes are defined in this document: 
   #  
   #        commURIObject 
   #  
   # commURIObject 
   #  
   #    This auxiliary object class represents a URI attribute type 
   #     
   # 
   delete: objectclasses 
   objectclasses: (0.0.8.350.1.1.1.2.1 NAME 'commURIObject' )  
   - 
   add: objectclasses  
   objectclasses: (0.0.8.350.1.1.1.2.1  
        NAME 'commURIObject'  
        DESC 'object that contains the URI attribute type'  
        SUP top AUXILIARY  
        MAY ( commURI )  
           )  
   - 
   # 
   # end of LDIF 
   # 
    
4.4.2.  LDIF for commObject 
    
   # Communication Object Schema 
   # 
   # Schema for Representing Communication Objects in an LDAP Directory 
   #  
   # Abstract 
   #  
   # This document defines the schema for representing Communication  
   # objects in an LDAP directory [LDAPv3].  It defines schema elements 
   # to represent a communication object [commObject]. 
   #  
   # 
   #                     .1 = Communication related work  
   #                     .1.2 = commObject 
   #                     .1.2.1 = attributes 
   #                     .1.2.2 = objectclass 
   #                     .1.2.3 = syntax 
 
 
 
Johnson            Informational - Expires May 2004          [Page 14] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   # 
   # 
   # Attribute Type Definitions 
   #  
   #    The following attribute types are defined in this document: 
   #  
   #        commUniqueId 
   #        commOwner 
   #        commPrivate 
   dn: cn=schema  
   changetype: modify  
   # 
   # if you need to change the definition of an attribute,  
   #            then first delete and re-add in one step 
   # 
   # if this is the first time you are adding the commObject 
   # objectclass using this LDIF file, then you should comment 
   # out the delete attributetypes modification since this will 
   # fail. Alternatively, if your ldapmodify has a switch to continue 
   # on errors, then just use that switch -- if you're careful 
   # 
   delete: attributetypes 
   attributetypes: (0.0.8.350.1.1.2.1.1 NAME 'commUniqueId' )  
   attributetypes: (0.0.8.350.1.1.2.1.2 NAME 'commOwner' )  
   attributetypes: (0.0.8.350.1.1.2.1.3 NAME 'commPrivate' )  
   - 
   # 
   # re-add the attributes -- in case there is a change of definition 
   # 
   #  
   add: attributetypes  
   attributetypes: (0.0.8.350.1.1.2.1.1  
        NAME 'commUniqueId'  
        DESC 'To hold the endpoints unique Id'  
        EQUALITY caseIgnoreIA5Match  
        SUBSTR caseIgnoreIA5SubstringsMatch  
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )  
   attributetypes: (0.0.8.350.1.1.2.1.2  
        NAME 'commOwner'  
        DESC 'Labeled URI to point back to the original owner'  
        EQUALITY caseExactMatch  
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )  
   attributetypes: (0.0.8.350.1.1.2.1.3  
        NAME 'commPrivate'  
        DESC 'To decide whether the entry is visible to world or not'  
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )  
   - 
   # Object Class Definitions 
   #  
   #    The following object classes are defined in this document: 
 
 
 
Johnson            Informational - Expires May 2004          [Page 15] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   #  
   #        commObject 
   #  
   # commObject 
   #      
   # 
   delete: objectclasses 
   objectclasses: (0.0.8.350.1.1.2.2.1 NAME 'commObject' )  
   - 
   add: objectclasses  
   objectclasses: (0.0.8.350.1.1.2.2.1  
        NAME 'commObject'  
        DESC 'object that contains the Communication attributes'  
        SUP top STRUCTURAL  
        MUST commUniqueId  
        MAY ( commOwner $ commPrivate )  
        )  
   - 
   # 
   # end of LDIF 
   # 
    
4.5. H.350 Annex A Indexing Profile 
    
   Indexing of attributes is an implementation-specific activity and 
   depends upon the desired application. Non-indexed attributes can 
   result in search times sufficiently long to render some applications 
   unusable. Notably, user and alias lookup should be fast. The Annex A 
   Indexing Profile describes an indexing configuration for commObject 
   directories that will be optimized for use in directory of 
   directories applications. Use of this profile is optional. 
    
   commURI: no recommendation 
    
   commUniqueId: equality 
    
   commOwner: presence 
    
   commPrivate: presence 
    
5. H.350.4 
    
   The normative text of H.350 is reproduced in this section. 
 
5.1. Scope 
    
   This Recommendation describes an LDAP directory services 
   architecture for multimedia conferencing using SIP. In particular, 
   it defines an LDAP schema to represent SIP User Agents (UAs) on the 
   network and associate those endpoints with users. 
 
 
 
Johnson            Informational - Expires May 2004          [Page 16] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
    
   This Recommendation is intended to supplement the CommObject 
   directory architecture as discussed in ITU-T Rec. H.350, and not 
   intended to be used as a stand-alone architecture. The 
   implementation of this LDAP schema, together with the use of the 
   H.350 CommObject architecture, facilitates the integration of SIP 
   User Agents and conferencing devices into existing Enterprise 
   Directories, thus allowing the user to perform white page lookups 
   and access clickable dialling supported by SIP devices. The primary 
   reasons for implementing this schema include those listed in ITU-T 
   Rec. H.350 (the CommObject class definition) as they apply 
   specifically to the use of SIP UAs, and to facilitate vendors making 
   SIP services more readily available to their users. 
    
   The scope of this Recommendation includes recommendations for the 
   architecture to integrate endpoint information for endpoints using 
   SIP into existing enterprise directories and white pages. 
    
   The scope of this Recommendation does not include normative methods 
   for the use of the LDAP directory itself or the data it contains. 
   The purpose of the schema is not to represent all possible data 
   elements in the SIP protocol, but rather to represent the minimal 
   set required to accomplish the design goals enumerated in ITU-T Rec. 
   H.350. 
    
   Note that SIP provides well-defined methods for discovering 
   registrar addresses and locating users on the network. Some of the 
   attributes defined here are intended for more trivial or manual 
   implementations and may not be needed for all applications. For 
   example, SIPIdentityRegistrarAddress and SIPIdentityAddress may not 
   be needed for many applications, but are included here for 
   completeness. Thus, SIPIdentitySIPURI is the primary attribute of 
   interest that will be served out, especially for white page 
   directory applications. 
    
5.1.1.  Extending the schema 
    
   The SIPIdentity classes may be extended as necessary for specific 
   implementations. See the base of ITU-T Rec. H.350 for a discussion 
   on schema extension. 
    
5.2. Object class definitions 
    
   The SIPIdentity object class represents SIP User Agents (UAs). It is 
   an auxiliary class and is derived from the commObject class, which 
   is defined in the ITU-T Rec. H.350. 
    
5.2.1.  SIPIdentity 
    
   OID: 0.0.8.350.1.1.6.2.1 
 
 
 
Johnson            Informational - Expires May 2004          [Page 17] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   objectclasses: (0.0.8.350.1.1.6.2.1 
   NAME 'SIPIdentity' 
   DESC 'SIPIdentity object' 
   SUP top AUXILIARY 
   MAY ( SIPIdentitySIPURI $ SIPIdentityRegistrarAddress $ 
      SIPIdentityProxyAddress $ SIPIdentityUserName $ 
      SIPIdentityPassword $ SIPIdentityServiceLevel $ 
      userSMIMECertificate ) 
   ) 
    
5.2.2.  SIPIdentitySIPURI 
    
   OID: 0.0.8.350.1.1.6.1.1 
   attributetypes: (0.0.8.350.1.1.6.1.1 
   NAME 'SIPIdentitySIPURI' 
   DESC 'Universal Resource Indicator of the SIP UA' 
   EQUALITY caseExactMatch 
   SUBSTR caseExactSubstringsMatch 
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 
   Application utility class 
        standard 
   Number of values 
        multi 
   Definition 
        Uniform Resource Identifier that identifies a communication 
   resource in SIP. Usually contains a user name and a host name and is 
   often similar in format to an email address. 
   Permissible values (if controlled) 
   Notes 
        This URI may institute SIP or SIPS (secure). In the event that 
   SIPS is instituted, the URI must reflect that it is using SIPS as 
   opposed to SIP. See Examples below. 
   Semantics 
   Example applications for which this attribute would be useful 
        Online representation of most current listing of a user's 
   SIP(S) UA. 
   Example  
   SIPIdentitySIPURI: sip:alice@foo.com          // SIP example 
   SIPIdentitySIPURI: sip:alice@152.2.158.212    // SIP example 
   SIPIdentitySIPURI: sips:bob@birmingham.edu    // SIPS example 
    
5.2.3.  SIPIdentityRegistrarAddress 
    
   OID: 0.0.8.350.1.1.6.1.2 
   attributetypes: (0.0.8.350.1.1.6.1.2 
   NAME 'SIPIdentityRegistrarAddress' 
   DESC 'specifies the location of the registrar'  
   EQUALITY caseIgnoreIA5Match 
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 
   Application utility class 
 
 
 
Johnson            Informational - Expires May 2004          [Page 18] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
        Standard 
   Number of values 
        multi 
   Definition 
        Address for the domain to which the server that handles 
   REGISTER requests and forwarding to the location server for a 
   particular domain belongs. 
   Permissible values (if controlled) 
   Notes 
        Note that RFC 3261 states that user agents can discover their 
   registrar address by configuration, using the address-of-record, or 
   by multicast. The first scenario, by configuration, is noted as out 
   of scope for RC 3261. This attribute may be used for the first 
   scenario. It can be accomplished manually, (e.g. a web page that 
   displays a user's correct registrar address) or automatically with 
   an H.350.4 aware user agent. 
   Semantics 
   Example applications for which this attribute would be useful 
        white pages, a web page that displays a user's correct 
   configuration information. 
   Example (LDIF fragment) 
   SIPIdentityRegistrarAddress: 152.2.15.22     //IP address example 
   SIPIdentityRegistrarAddress: sipregistrar.unc.edu  //FQDN example 
    
5.2.4.  SIPIdentityProxyAddress 
    
   OID: 0.0.8.350.1.1.6.1.3 
   attributetypes: (0.0.8.350.1.1.6.1.3 
   NAME 'SIPIdentityProxyAddress' 
   DESC 'Specifies the location of the SIP Proxy' 
   EQUALITY caseIgnoreIA5Match 
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 
   Application utility class 
        Standard 
   Number of values 
        multi 
   Definition 
        Address which specifies the domain location of SIP proxy within 
   a domain. RFC 3261 defines the role of the SIP proxy. 
   Permissible values (if controlled) 
   Notes  
        SIP User Agents are not REQUIRED to use a proxy, but will in 
   many cases. 
   Semantics 
   Example applications for which this attribute would be useful 
        white pages, a web page that displays a user's correct 
   configuration information. 
   Example (LDIF fragment) 
   SIPIdentityProxyAddress: 172.2.13.234     //IP address example 
   SIPIdentityProxyAddress: sipproxy.unc.edu  //FQDN example 
 
 
 
Johnson            Informational - Expires May 2004          [Page 19] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
    
5.2.5.  SIPIdentityAddress  
    
   OID: 0.0.8.350.1.1.6.1.4 
   attributetypes: (0.0.8.350.1.1.6.1.4 
   NAME 'SIPIdentityAddress' 
   DESC 'IP address or FQDN of the UA' 
   EQUALITY caseIgnoreIA5Match 
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 
   Application utility class 
        standard 
   Number of values 
        multi 
   Definition 
        Specifies the IP address or fully qualified domain name of the 
   UA. 
   Permissible values (if controlled) 
   Notes 
        This attribute may be useful for applications in which UA to UA 
   communication is direct, not involving a proxy or registrar. 
   Example applications for which this attribute would be useful 
        A web page that displays a user's proper user agent 
   configuration information. 
   Example (LDIF fragment) 
   SIPIdentityAddress: 152.2.121.36       // IP address example 
   SIPIdentityAddress: ipPhone.foo.org    // FQDN example 
    
5.2.6.  SIPIdentityPassword 
    
   OID: 0.0.8.350.1.1.6.1.5 
   attributetypes: (0.0.8.350.1.1.6.1.5 
   NAME 'SIPIdentityPassword' 
   DESC 'The user agent SIP password ' 
   EQUALITY octetStringMatch 
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) 
   Application utility class 
        Standard 
   Number of values 
        multi 
   Definition 
        The SIP user agent's password, used for the HTTP digest 
   authentication scheme as defined in RFC 2617. 
   Permissible values (if controlled) 
   Notes 
        Because RFC 2069, which was made obsolete by RFC 2617, was used 
   as the basis for HTTP Digest in RFC 2543, any SIP servers supporting 
   RFC 2617 must ensure backward compatibility with RFC 2069. 
        This SIPIdentityUserName, together with SIPIdentityPassword, 
   are reserved for the purpose of use with Digest Access 
 
 
 
Johnson            Informational - Expires May 2004          [Page 20] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   Authentication, and not intended for use with Basic Authentication 
   methods. 
        LDAP provides one method to store user passwords for reference. 
   If passwords are stored in LDAP it makes the LDAP server a 
   particularly valuable target for attack. Implementors are encouraged 
   to exercise caution and implement appropriate security procedures 
   such as encryption, access control, and transport layer security for 
   access to this attribute. 
   Semantics 
   Example applications for which this attribute would be useful 
   Example (LDIF fragment) 
   SIPIdentityPassword: 36zxJmCIB18dM0FVAj 
    
5.2.7.  SIPIdentityUserName 
    
   OID: 0.0.8.350.1.1.6.1.6 
   attributetypes: (0.0.8.350.1.1.6.1.6 
   NAME 'SIPIdentityUserName' 
   DESC 'The user agent user name.' 
   EQUALITY caseIgnoreMatch 
   SUBSTR caseIgnoreSubstringsMatch 
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 
   Application utility class 
        Standard 
   Number of values 
        multi 
   Definition 
        The SIP user agent's user name, used for the HTTP digest 
   authentication scheme as defined in RFC 2617. 
   Permissible values (if controlled) 
   Notes 
        Because RFC 2069, which was made obsolete by RFC 2617, was used 
   as the basis for HTTP Digest Authentication in RFC 2543, any SIP 
   servers supporting HTTP Digest Authentication as defined in RFC 2617 
   must ensure backward compatibility with RFC 2069. 
        This SIPIdentityUserName, together with SIPIdentityPassword, 
   are reserved for the purpose of use with Digest Access 
   Authentication, and not intended for use with Basic Authentication 
   methods. 
        Note that in many cases the user name will be parsed from the 
   user@proxy.domain portion of the SIP URI. In that case it may not be 
   necessary to populate this attribute. 
   Semantics 
   Example applications for which this attribute would be useful 
   Example (LDIF fragment) 
   SIPIdentityUserName: nelkhour 
    
5.2.8.  SIPIdentityServiceLevel 
    
   OID: 0.0.8.350.1.1.6.1.7 
 
 
 
Johnson            Informational - Expires May 2004          [Page 21] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   attributetypes: (0.0.8.350.1.1.6.1.7  
   NAME 'SIPIdentityServiceLevel'  
   DESC 'To define services that a user can belong to.'  
   EQUALITY caseIgnoreIA5Match 
   SUBSTR caseIgnoreIA5SubstringsMatch 
   SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) 
   Application utility class 
        Standard 
   Number of values 
        multi 
   Definition 
        This describes the level of services a user can belong to.  
   Permissible values (if controlled) 
   Notes 
        This attribute does not represent a data element found in SIP. 
   SIP itself does not support distinctions in service levels. Instead, 
   this attribute provides a mechanism for the storage of service level 
   information directly in LDAP. This mapping allows service providers 
   to adapt to an existing LDAP directory without changing the values 
   of the SIPIdentityServiceLevel instances in the directory. 
   Semantics 
   Example applications for which this attribute would be useful 
   Example (LDIF fragment) 
   SIPIdentityServiceLevel: premium 
    
5.3. SIPIdentity LDIF Files 
    
   This clause contains a schema configuration file for SIPIdentity 
   that can be used to configure an LDAP server to support this class. 
    
   # SIPIdentity Object Schema 
   # 
   # Schema for representing SIPIdentity Object in an LDAP Directory 
   #  
   # Abstract 
   #  
   # This Recommendation defines the schema for representing 
   SIPIdentity  
   # object in an LDAP directory [LDAPv3].  It defines schema elements 
   # to represent an SIPIdentity object [SIPIdentity]. 
   #  
   #                     .1 = Communication related work 
   #                     .1.6 = SIPIdentity 
   #                     .1.6.1 = attributes 
   #                     .1.6.2 = objectclass 
   #                     .1.6.3 = syntax 
   # 
   # 
   # 
   # Attribute Type Definitions 
 
 
 
Johnson            Informational - Expires May 2004          [Page 22] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   #  
   #    The following attribute types are defined in this 
   Recommendation: 
   #  
   #     SIPIdentitySIPURI 
   #     SIPIdentityRegistrarAddress 
   #     SIPIdentityProxyAddress 
   #     SIPIdentityAddress 
   #     SIPIdentityPassword 
   #     SIPIdentityUserName 
   #     SIPIdentityServiceLevel 
   dn: cn=schema  
   changetype: modify  
   # 
   # if you need to change the definition of an attribute,  
   #            then first delete and re-add in one step 
   # 
   # if this is the first time you are adding the SIPIdentity 
   # objectclass using this LDIF file, then you should comment 
   # out the delete attributetypes modification since this will 
   # fail. Alternatively, if your ldapmodify has a switch to continue 
   # on errors, then just use that switch -- if you are careful 
   # 
   delete: attributetypes 
   attributetypes: (0.0.8.350.1.1.6.1.1 NAME 'SIPIdentitySIPURI' )  
   attributetypes: (0.0.8.350.1.1.6.1.2 NAME 
   'SIPIdentityRegistrarAddress' )  
   attributetypes: (0.0.8.350.1.1.6.1.3 NAME 'SIPIdentityProxyAddress' 
   )  
   attributetypes: (0.0.8.350.1.1.6.1.4 NAME 'SIPIdentityAddress' )  
   attributetypes: (0.0.8.350.1.1.6.1.5 NAME 'SIPIdentityPassword' )  
   attributetypes: (0.0.8.350.1.1.6.1.6 NAME 'SIPIdentityUserName' )  
   attributetypes: (0.0.8.350.1.1.6.1.7 NAME 'SIPIdentityServiceLevel' 
   )  
   - 
   # 
   # re-add the attributes -- in case there is a change of definition 
   # 
   #  
   add: attributetypes  
   attributetypes: (0.0.8.350.1.1.6.1.1  
        NAME 'SIPIdentitySIPURI'  
        DESC 'Universal Resource Indicator of the SIP UA'  
        EQUALITY caseExactMatch  
        SUBSTR caseExactSubstringsMatch  
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )  
   attributetypes: (0.0.8.350.1.1.6.1.2  
        NAME 'SIPIdentityRegistrarAddress'  
        DESC 'specifies the location of the registrar'  
        EQUALITY caseIgnoreIA5Match  
 
 
 
Johnson            Informational - Expires May 2004          [Page 23] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )  
   attributetypes: (0.0.8.350.1.1.6.1.3  
        NAME 'SIPIdentityProxyAddress'  
        DESC 'Specifies the location of the SIP Proxy'  
        EQUALITY caseIgnoreIA5Match  
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )  
   attributetypes: (0.0.8.350.1.1.6.1.4  
        NAME 'SIPIdentityAddress'  
        DESC 'IP address of the UA'  
        EQUALITY caseIgnoreIA5Match  
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )  
   attributetypes: (0.0.8.350.1.1.6.1.5  
        NAME 'SIPIdentityPassword'  
        DESC 'The user agent SIP password '  
        EQUALITY octetStringMatch  
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )  
   attributetypes: (0.0.8.350.1.1.6.1.6  
        NAME 'SIPIdentityUserName'  
        DESC 'The user agent user name.'  
        EQUALITY caseIgnoreMatch  
        SUBSTR caseIgnoreSubstringsMatch  
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )  
   attributetypes: (0.0.8.350.1.1.6.1.7  
        NAME 'SIPIdentityServiceLevel'  
        DESC 'To define services that a user can belong to.'  
        EQUALITY caseIgnoreIA5Match  
        SUBSTR caseIgnoreIA5SubstringsMatch  
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )  
   - 
   # Object Class Definitions 
   #  
   #    The following object class is defined in this Recommendation: 
   #  
   #        SIPIdentity 
   #  
   # SIPIdentity 
   #   
   # 
   delete: objectclasses 
   objectclasses: (0.0.8.350.1.1.6.2.1 NAME 'SIPIdentity' )  
   - 
   add: objectclasses  
   objectclasses: (0.0.8.350.1.1.6.2.1  
        NAME 'SIPIdentity'  
        DESC 'SIPIdentity object'  
        SUP top AUXILIARY  
        MAY ( SIPIdentitySIPURI $ SIPIdentityRegistrarAddress $  
             SIPIdentityProxyAddress $ SIPIdentityAddress $  
             SIPIdentityPassword $ SIPIdentityUserName $  
             SIPIdentityServiceLevel $ userSMIMECertificate )  
 
 
 
Johnson            Informational - Expires May 2004          [Page 24] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
        )  
   - 
   # 
   # end of LDIF 
   # 
    
5.4. H.350.4 Annex A Indexing profile 
    
   Indexing of attributes is an implementation-specific activity and 
   depends upon the desired application. Non-indexed attributes can 
   result in search times sufficiently long to render some applications 
   unusable. Notably, user and alias lookup should be fast. The Annex A 
   Indexing Profile describes an indexing configuration for SIPIdentity 
   directories that will be optimized for use in directory of 
   directories applications. Use of this profile is optional. 
    
   SIPIdentitySIPURI: equality  
    
   SIPIdentityRegistrarAddress: no recommendation 
    
   SIPIdentityProxyAddress: no recommendation 
    
   SIPIdentityAddress: equality 
    
   SIPIdentityUserName: equality 
    
   SIPIdentityPassword: no recommendation 
    
   SIPIdentityServiceLevel: equality 
    
6. Acknowledgments 
    
   We are grateful to numerous colleagues for reaching across multiple 
   boundaries of standards bodies, research networks, academia and 
   private industry in order to produce an architecture that works 
   toward integrating multimedia conferencing deployments. In 
   particular, standards from both IETF and ITU-T were drawn from 
   extensively, and the architecture is meant to serve all communities. 
    
   This work developed out of the Video Conferencing Middleware 
   (VidMid-VC) working group, a joint effort of Internet2 
   (www.internet2.edu) and the Video Development Initiative 
   (www.vide.net). The architecture was developed in response to 
   deployment challenges discovered in the ViDeNet 
   (https//:videnet.unc.edu) academic test bed providing video and 
   voice over IP infrastructure across research networks 
   internationally. 
    
   This work was supported in part by a grant from the United States 
   National Science Foundation contract number ANI-0222710. 
 
 
 
Johnson            Informational - Expires May 2004          [Page 25] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
 
7. Normative References 
    
   [1]  Hodges, J., Morgan, R., "Lightweight Directory Access Protocol 
        (v3): Technical Specification," RFC 3377, September 2002. 
    
   [2]  ITU-T Recommendation H.350, " Directory services architecture 
        for multimedia conferencing," 2003. 
    
   [3]  ITU-T Recommendation H.350.4, " Directory services architecture 
        for SIP," 2003. 
    
   [4]  Franks, J., Hallam-Baker P., Hostetler, J., Lawrence, S., 
        Leach, P., Luotonen, A., Stewart, L., "HTTP Authentication: 
        Basic and Digest Access Authentication," RFC 2617, June 1999. 
    
   [5]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 
        Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: 
        Session Initiation Protocol," RFC 3261, June 2002. 
    
   [6]  Rosenberg, J., Schulzrinne, H., "Session Initiation Protocol 
        (SIP): Locating SIP Servers," RFC 3263, June 2002. 
    
8. Informative References 
    
   [7]  Hodges, J., Morgan, R., "Lightweight Directory Access Protocol 
        (v3): Technical Specification," RFC 3377, September 2002. 
    
   [8]  ITU-T Recommendation H.350.1, " Directory services architecture 
        for H.323," 2003. 
    
   [9]  ITU-T Recommendation H.350.2, " Directory services architecture 
        for H.235," 2003. 
    
   [10] ITU-T Recommendation H.350.3, " Directory services architecture 
        for H.320," 2003. 
    
   [11] ITU-T Recommendation H.350.5, " Directory services architecture 
        for Non-Standard Protocols," 2003. 
    
   [12] Howes T. and Smith, M., "Understanding And Deploying LDAP 
        Directory Services," New Riders Publishing, ISBN: 1578700701, 
        1999. 
    
   [13] Howes T. and Smith, M., " LDAP Programming Directory-Enabled 
        Applications with Lightweight Directory Access Protocol," New 
        Riders Publishing, ISBN: 1578700000, 1997. 
 
9. Security Considerations 
    
 
 
 
Johnson            Informational - Expires May 2004          [Page 26] 
                                     
     Internet Draft  H.350 Directory Services        November 2003 
 
 
   H.350 does not alter the security architectures of any particular 
   protocol. However, it does offer a standardized place to store 
   authentication credentials where appropriate. It should be noted 
   that both H.323 and SIP support shared secret authentication (H.235 
   Annex D and HTTP Digest, respectively). These approaches require 
   that the call server have access to the password. Thus, if the call 
   server or H.350 directory is compromised, passwords also may become 
   compromised. These weaknesses may be due to weaknesses in the 
   systems (H.350 directory or call servers) and their operation rather 
   than in H.350 per se.
    
   It is strongly encouraged that call servers and an H.350 directory 
   mutually authenticate each other before sharing information. 
   Further, it is strongly encouraged that communications between H.350 
   directories and call servers or endpoints happen over secure 
   communication channels such as SSL or TLS. 
    
   Finally, access control lists on LDAP servers are a matter of policy 
   and are not a part of the standard. System administrators are 
   advised to use common sense when setting access control on H.350 
   attributes. For example, password attributes should only be 
   accessible by the authenticated user, while address attributes might 
   be publicly available. 
    
10.     Contact Information 
    
   Tyler Johnson 
   Editor, H.350 
   University of North Carolina  
   Chapel Hill, NC 27599 
   Tel: +1.919.843.7004 
   Email: Tyler_Johnson@unc.edu 
    
   Sakae Okubo 
   Rapporteur for Q.4/16, ITU-T SG16 
   Waseda University 
   YRP Ichibankan, 3-4 Hikarinooka 
   Yokosuka-shi, 239-0847 Japan 
   Tel: +81 46 847 5406 
   e-mail: sokubo@waseda.jp 
    
   Simo Ferraz de Campos Neto 
   Counsellor, ITU-T SG 16 
   International Telecommunication Union 
   Place des Nations 
   Geneva CH1211 - Switzerland 
   Tel:    +41-22-730-6805 
   E-mail: simao.campos@itu.int 
 
 
 
Johnson            Informational - Expires May 2004          [Page 27]