Network Working Group T. Johnson
Request for Comments: 3944 U. of North Carolina
Category: Informational S. Okubo
Waseda University
S. Campos
ITU-T
December 2004
Network Working Group T. Johnson
Request for Comments: 3944 U. of North Carolina
Category: Informational S. Okubo
Waseda University
S. Campos
ITU-T
December 2004
H.350 Directory Services
H.350目录服务
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
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.
国际电信联盟标准化部门（ITU-T）制定了H.350系列建议，其中规定了支持多媒体会议协议的目录服务体系结构。该体系结构的目标是“启用目录”多媒体会议，以便这些服务可以利用现有的身份管理和企业目录。一个特定的目标是使企业或服务提供商能够维护用户及其多媒体会议系统的规范来源，以便来自多个供应商的支持多种协议的多个呼叫服务器都可以访问相同的数据存储。
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. This document contains the entire normative text of ITU-T Recommendations H.350 and H.350.4 in sections 4 and 5, respectively. The remaining sections are included only in this document, not in the ITU-T version.
由于SIP是IETF标准，H.350和H.350.4的内容可通过本文件提供给IETF社区。本文件分别包含第4节和第5节中ITU-T建议H.350和H.350.4的完整规范性文本。其余章节仅包含在本文件中，不包含在ITU-T版本中。
Table of Contents
目录
1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
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. . . . . . . . . . . . . . . . 10
4.2.1. commURIObject. . . . . . . . . . . . . . . . . . 10
4.2.2. commURI. . . . . . . . . . . . . . . . . . . . . 10
4.3. CommObject Definition . . . . . . . . . . . . . . . . . 11
4.3.1. commObject . . . . . . . . . . . . . . . . . . . 11
4.3.2. commUniqueId . . . . . . . . . . . . . . . . . . 11
4.3.3. commOwner. . . . . . . . . . . . . . . . . . . . 12
4.3.4. commPrivate. . . . . . . . . . . . . . . . . . . 13
4.4. CommObject LDIF Files . . . . . . . . . . . . . . . . . 13
4.4.1. LDIF for commURIObject . . . . . . . . . . . . . 13
4.4.2. LDIF for commObject. . . . . . . . . . . . . . . 15
4.5. H.350 Annex A Indexing Profile. . . . . . . . . . . . . 17
5. H.350.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.1. Extending the schema . . . . . . . . . . . . . . 18
5.2. Object class definitions. . . . . . . . . . . . . . . . 18
5.2.1. SIPIdentity. . . . . . . . . . . . . . . . . . . 18
5.2.2. SIPIdentitySIPURI. . . . . . . . . . . . . . . . 19
5.2.3. SIPIdentityRegistrarAddress. . . . . . . . . . . 19
5.2.4. SIPIdentityProxyAddress. . . . . . . . . . . . . 20
5.2.5. SIPIdentityAddress . . . . . . . . . . . . . . . 21
5.2.6. SIPIdentityPassword. . . . . . . . . . . . . . . 21
5.2.7. SIPIdentityUserName. . . . . . . . . . . . . . . 22
5.2.8. SIPIdentityServiceLevel. . . . . . . . . . . . . 23
5.3. SIPIdentity LDIF Files. . . . . . . . . . . . . . . . . 23
5.4. H.350.4 Annex A Indexing profile. . . . . . . . . . . . 26
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References. . . . . . . . . . . . . . . . . . 28
8.2. Informative References. . . . . . . . . . . . . . . . . 28
9. Relationship to Other Specifications. . . . . . . . . . . . . 29
10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 30
1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
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. . . . . . . . . . . . . . . . 10
4.2.1. commURIObject. . . . . . . . . . . . . . . . . . 10
4.2.2. commURI. . . . . . . . . . . . . . . . . . . . . 10
4.3. CommObject Definition . . . . . . . . . . . . . . . . . 11
4.3.1. commObject . . . . . . . . . . . . . . . . . . . 11
4.3.2. commUniqueId . . . . . . . . . . . . . . . . . . 11
4.3.3. commOwner. . . . . . . . . . . . . . . . . . . . 12
4.3.4. commPrivate. . . . . . . . . . . . . . . . . . . 13
4.4. CommObject LDIF Files . . . . . . . . . . . . . . . . . 13
4.4.1. LDIF for commURIObject . . . . . . . . . . . . . 13
4.4.2. LDIF for commObject. . . . . . . . . . . . . . . 15
4.5. H.350 Annex A Indexing Profile. . . . . . . . . . . . . 17
5. H.350.4 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1.1. Extending the schema . . . . . . . . . . . . . . 18
5.2. Object class definitions. . . . . . . . . . . . . . . . 18
5.2.1. SIPIdentity. . . . . . . . . . . . . . . . . . . 18
5.2.2. SIPIdentitySIPURI. . . . . . . . . . . . . . . . 19
5.2.3. SIPIdentityRegistrarAddress. . . . . . . . . . . 19
5.2.4. SIPIdentityProxyAddress. . . . . . . . . . . . . 20
5.2.5. SIPIdentityAddress . . . . . . . . . . . . . . . 21
5.2.6. SIPIdentityPassword. . . . . . . . . . . . . . . 21
5.2.7. SIPIdentityUserName. . . . . . . . . . . . . . . 22
5.2.8. SIPIdentityServiceLevel. . . . . . . . . . . . . 23
5.3. SIPIdentity LDIF Files. . . . . . . . . . . . . . . . . 23
5.4. H.350.4 Annex A Indexing profile. . . . . . . . . . . . 26
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
7. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8. References. . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Normative References. . . . . . . . . . . . . . . . . . 28
8.2. Informative References. . . . . . . . . . . . . . . . . 28
9. Relationship to Other Specifications. . . . . . . . . . . . . 29
10. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 29
Full Copyright Statement. . . . . . . . . . . . . . . . . . . 30
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.
国际电信联盟标准化部门（ITU-T）制定了H.350系列建议，其中规定了支持多媒体会议协议的目录服务体系结构。该体系结构的目标是“启用目录”多媒体会议，以便这些服务可以利用现有的身份管理和企业目录。一个特定的目标是使企业或服务提供商能够维护用户及其多媒体会议系统的规范来源，以便来自多个供应商的支持多种协议的多个呼叫服务器都可以访问相同的数据存储。
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.
H.350体系结构无意以任何方式改变多媒体会议协议的操作。相反，它们旨在标准化已定义的协议元素在目录中的存储方式，以便能够以标准化的方式访问它们。
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系列中，建议H.350指定了基本体系结构和对象类，而次级建议指定了特定于各个协议的元素。目前，建议包括：
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
H.350-多媒体会议的目录服务架构H.350.1-H.323 H.350.2的目录服务架构-H.235 H.350.3的目录服务架构-H.320 H.350.4的目录服务架构-SIP H.350.5的目录服务架构-非标准协议的目录服务架构
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.
由于SIP是IETF标准，H.350和H.350.4的内容可通过本文件提供给IETF社区。
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.
* 呼叫服务器：特定于协议的信令引擎，在网络上路由视频或语音呼叫。在H.323中，这个实体是一个网守。在SIP中，该实体是SIP代理服务器。请注意，并非所有信令协议都使用呼叫服务器。
* 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.
* IP电话。
* 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 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.
* 企业目录：组织中用户信息的规范集合。通常，从各种组织单位收集这些信息，以创建一个整体。例如，人力资源部门可以提供姓名和地址，电信部门可以提供电话号码，信息技术部门可以提供电子邮件地址等。就本架构而言，假设企业目录可以通过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.
* 白页：允许最终用户查找其他用户地址的应用程序。这可以是基于web的，也可以使用其他用户界面。
Conventions in this document conform to ITU-T guidelines. In this Recommendation, the following conventions are used:
本文件中的约定符合ITU-T指南。在本建议中，使用了以下约定：
"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.
除非明确列出其他规范，否则条款、子条款、附件和附录均指本建议中的项目。
The normative text of H.350 is reproduced in this section.
本节转载了H.350的规范性文本。
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
本建议描述了使用LDAP的多媒体会议目录服务体系结构。标准化的目录服务可以支持人员与端点的关联、可搜索的白页和可点击的拨号。目录服务还可以帮助
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.
端点的配置，以及基于权威数据源的用户身份验证。本文档描述了一个标准化的LDAP模式，用于表示网络上的端点并将这些端点与用户关联。它讨论了视频和语音特定目录、企业目录、呼叫服务器和端点之间相互关系的设计和实现注意事项。
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 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.
为呼叫服务器、端点、用户、身份验证和白页信息使用通用、权威的数据源是大规模多媒体会议环境的一个重要方面。如果没有公共数据源，服务提供商必须创建单独的流程来管理这些功能。通过标准化用于表示底层数据的LDAP模式，可以将来自不同系统供应商的产品部署在一起，以创建一个整体应用程序环境。例如，一家提供商开发的白页搜索引擎可以向第二家提供商生产的IP电话提供目录信息，信令由第三家提供商生产的呼叫服务器管理。这些完全不同的系统中的每一个都可以访问相同的底层数据源，从而减少或消除了协调每个系统的单独管理的需要。用户的一个显著好处是，可以将此数据的管理纳入现有的客户管理工具中，从而允许快速灵活地扩展应用程序。事实上，许多技术提供商已经将LDAP合并到他们的产品中，但在没有标准化模式的情况下被迫这样做。本建议旨在标准化这些表示，以提高互操作性和性能。
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'.
虽然URL已经针对几种会议协议进行了标准化，但它们在目录中的表示形式却不是这样。本建议支持对URL进行搜索和定位的标准化方法。这是支持“可点击拨号”的必要步骤。
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
如果服务提供商将正确的设置存储在服务提供商和端点都可以访问的位置，则可以改进端点配置的管理。LDAP提供了一个方便的存储位置，呼叫服务器和端点都可以访问该位置；因此，可以使用目录来支持端点配置，这对于简化操作和支持用户移动性非常重要。请注意，其他技术也支持端点配置，特别是使用SNMP进行完整配置，使用SRV记录获取注册服务器地址。因此，H.350不应被视为权威的端点配置体系结构，而应被视为可以
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.
协助完成这项任务。请注意，H.350的使用具有特定于特征端点的配置，其中每个端点具有唯一的配置是可取的。
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.
该体系结构使用一个称为commObject的通用对象类来表示任何视频或语音协议的公共属性。辅助类表示特定的协议，如H.350.x系列建议中所述的H.323、H.235或H.320。可以组合多个H.350.x类来表示支持多个协议的端点。例如，支持H.323、H.235和H.320的端点将在其LDAP表示中包括H.350、H.350.1、H.350.2和H.350.3。此外，每个条目都应该包含commObject，作为条目的结构对象类。
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.
体系结构中有两个基本组件。commURI对象是一个类，其唯一用途是将个人或资源链接到commObject。通过在个人的目录条目中放置commURI“指针”，该个人将与特定的目标commObject相关联。类似地，commObject包含一个名为commOwner的指针，该指针指向与commObject关联的个人或资源。通过这种方式，人员或资源可以与端点相关联。企业目录中唯一需要的更改是添加简单对象类commURI。CommObject数据可以在相同或完全不同的目录中实例化，从而允许实现的灵活性。
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:
IP视频和语音服务的大规模部署表明，需要补充目录服务中间件。服务管理员需要知道企业目录的呼叫服务器，以避免重复帐户管理过程。用户需要“白页”来定位他们希望与之通信的其他用户。所有这些过程都应该从规范的数据源中提取信息，以减少冗余的管理过程并确保信息的准确性。为该架构建立了以下设计标准。该架构将：
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;
1) 允许端点信息与人关联。或者，它使端点信息能够与会议室或教室等资源相关联；
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.;
2) 启用可在线搜索的“白页”，其中可以找到拨号信息（如端点地址），以及关于用户的其他“传统”目录信息，如姓名、地址、电话、电子邮件等。；
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;
3) 允许将所有端点信息存储在规范数据源（目录）中，而不是呼叫服务器本地，以便可以通过企业目录的操作而不是直接进入呼叫服务器来管理端点；
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;
4) 支持创建非常大规模的分布式目录。其中包括允许跨多个机构目录搜索用户的白页“门户”。在这个应用程序中，每个企业目录都注册到一个目录目录中（或在不知不觉中被发现），该目录能够跨多个LDAP目录进行搜索；
5) be able to support multiple instances of endpoints per user or resource;
5) 能够支持每个用户或资源的多个端点实例；
6) represent endpoints that support more than one protocol, for example, endpoints that are both H.320 and H.323;
6) 表示支持多个协议的端点，例如，同时为H.320和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;
7) 存储有关端点配置的足够信息，以便可以在每个端点的基础上向最终用户记录正确的配置设置，作为支持工具，或自动加载到端点中；
8) be extendible as necessary to allow implementation-specific attributes to be included;
8) 可根据需要进行扩展，以允许包含特定于实现的属性；
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.
9) 对企业目录不具有侵入性，因此可以以模块化方式添加对多媒体会议的支持，而无需对企业目录进行重大更改。
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.
本建议的范围不包括对协议本身中定义的协议的功能扩展。本建议的目的不是添加特性，而只是表示现有的协议属性。这种情况的例外情况是目录本身隐含了功能，例如commPrivate属性。
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.
H.350对象类可根据具体实现的需要进行扩展。例如，可以扩展一个类以支持计费参考代码。对模式的扩展不被视为建议的一部分，也不表示符合性。
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.
在某些情况下，可能需要扩展H.350模式，以表示比建议支持的更多的信息。这对于实现专有端点功能的开发人员来说可能很重要，这些功能需要由目录中的属性表示。它对于企业应用程序也很重要。例如，“modelNumber”和“accountNumber”是建议中未定义但在实施时可能有用的属性示例。向该体系结构添加属性的方式必须不破坏与本建议的兼容性。
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.
对模式设计和扩展的全面讨论超出了本建议的范围。详见IETF RFC 2252。模式扩展的两种基本方法不会破坏与本建议的兼容性，即通过子类进行扩展和通过使用辅助类进行扩展。
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.
下面的示例显示了如何对commObject类进行子类化，以便添加一个表示账单帐户和账单管理器的属性。
objectclass ( BillingInfo-OID NAME 'BillingInfo' DESC 'Billing Reference Information' SUP commObject STRUCTURAL MAY ( BillingAccount $ BillingManager $ ) )
对象类（BillingInfo OID名称“BillingInfo”描述“计费参考信息”辅助通信对象结构可能（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.
请注意，BillingInfo OID必须由实际OID替换。还要注意的是，每当一个结构类被扩展时，它的子类也必须是结构类。
The following sample entry shows the newly created attributes. This example also uses ITU-T Rec. H.350.1 for h323Identity.
下面的示例条目显示了新创建的属性。本示例还使用ITU-T Rec.H.350.1进行h323Identity。
dn: commUniqueId=2000,ou=h323identity, dc=company, dc=com
objectclass: top
objectclass: commObject
objectclass: 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
对象类：BillingInfo通讯ID: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.
请注意，此示例和方法演示了通用commObject对象类的扩展，而不是任何单独的H.350.x类。如果需要扩展H.350.x辅助类，则应通过定义支持所需属性的附加辅助类来实现，如第4.1.2.2节所述。
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 manager attributes as the previous example, but does so by defining them in their own auxiliary class.
通过定义包含新属性的辅助类并将这些属性应用于目录中的实例化值，可以向LDAP条目添加属性。辅助类不会从任何现有对象类中派生。请注意，它应该具有特殊类top作为其上级。下面的示例创建与前面的示例相同的billing account和billing manager属性，但通过在其自己的辅助类中定义它们来实现。
objectclass ( BillingInfo-OID NAME 'BillingInfo' DESC 'Billing Reference Information' SUP top AUXILIARY MAY ( BillingAccount $ BillingManager $ ) )
对象类（BillingInfo OID名称“BillingInfo”描述“计费参考信息”辅助顶级辅助可能（BillingAccount$BillingManager$））
Note how the superior was changed from commObject to top and the object class changed from being a structural to auxiliary.
注意上级是如何从commObject变为top的，对象类是如何从结构类变为辅助类的。
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.
下面的示例显示了一个使用新辅助类和属性的示例端点。此示例还使用H.350.1表示h323Identity。
dn: commUniqueId=2000,ou=h323identity, dc=company, dc=com
objectclass: top
objectclass: commObject
objectclass: BillingInfo
dn: commUniqueId=2000,ou=h323identity, dc=company, dc=com
objectclass: top
objectclass: commObject
objectclass: BillingInfo
commUniqueId: 2000 BillingAccount: 0023456 BillingManager: John Smith
通讯录：2000账单账户：0023456账单经理：约翰·史密斯
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.
属性的对象标识符（OID）是一个唯一的数字标识符，通常以点分隔的整数序列形式写入。例如，通讯ID的OID为0.0.8.350.1.1.2.1.1。所有属性都必须具有OID。OID可以从任何有OID并且愿意将其一部分委托给arc的人处获得，并保留arc记录以避免重复。此外，互联网分配号码管理局（IANA）向任何提出请求的组织发放OID。
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 directory. In fact, each commURI instance could point to an endpoint managed by a different service provider.
包含commURI属性的辅助对象类。将此属性添加到person或resource对象中，以将一个或多个commObject实例与该对象关联。它的值是LDAP URI，这些URI指向相关的通信对象，例如用户的H.323会议站和SIP IP电话。请注意，commURI的多个实例不需要指向同一个commObject目录。事实上，每个commURI实例都可以指向由不同服务提供商管理的端点。
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 ) )
OID:0.0.8.350.1.1.1.1.2.1对象类：（0.0.8.350.1.1.1.2.1名称'commURIObject'DESC'对象，包含URI属性类型'SUP-top-associative-MAY（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
OID:0.0.8.350.1.1.1.1 AttributeType:（0.0.8.350.1.1.1.1.1名称'commURI'DESC'标记URI格式，指向commUniqueId的可分辨名称'EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15）应用工具类标准
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
包含LDAP URL的多定义标记URI的值数，该URL标识包含引用的commObject实例的目录。此LDAP URL指定的搜索筛选器应指定commObject类的commUniqueId属性的相等搜索。允许值（如果受控）用于查找相关用户端点的注释。标签字段可用于表示端点的功能，例如用于用户界面显示的“家庭IP电话”或“桌面视频”。请注意，字段的标签部分可能包含空格，如下面显示“桌面视频”的示例所示。语义此属性对其有用的示例应用程序示例（LDIF片段）commURI：ldap://directory.acme.com/dc=acme，dc=com×sub？（commUniqueId=bob）桌面视频
Abstraction of video or voice over IP device. The commObject class permits an endpoint (H.323 endpoint or SIP user agent or other 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.
通过IP设备提取视频或语音。commObject类允许一个端点（H.323端点或SIP用户代理或其他协议端点）及其所有别名由目录中的单个条目表示。请注意，每个目录条目都应该包含commObject作为条目的结构对象类。该条目还可能包含H.350.x辅助类。
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 ) )
OID:0.0.8.350.1.1.2.2.1对象类：（0.0.8.350.1.1.2.2.1名称“commObject”DESC“object”，包含通信属性“SUP top STRUCTURAL MUST commUniqueId MAY”（commOwner$commPrivate））
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'
OID:0.0.8.350.1.1.2.1.1 AttributeType:（0.0.8.350.1.1.2.1.1名称'commUniqueId'DESC'保存端点唯一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
相等caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch语法1.3.6.1.4.1.1466.115.121.1.26）应用程序实用程序类标准值数多定义端点的唯一ID。允许值（如果受控）注意这是此对象的RDN。实际上，对于每个端点，始终只有一个commUniqueId。此属性唯一标识commObject目录中的端点。它在该目录中必须是唯一的，但不必全局唯一。此属性与企业目录没有关系。语义示例应用程序，该属性对其非常有用示例（LDIF片段）commUniqueId:bob
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 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)
OID:0.0.8.350.1.1.2.2 AttributeType:0.0.8.350.1.1.2.1.2名称'commOwner'DESC'标记URI以指向原始所有者的相等caseExactMatch语法1.3.6.1.4.1.1466.115.121.1.15）应用程序实用程序类标准值数多定义标记URI格式以指向与之关联的人员或资源对象这个条目。允许值（如果受控）注释，用作所有者的反向输入查找器。此属性可能指向组。请注意，此URI可以指向cn，但在需要跨commObject和enterprise目录绑定身份验证信息的应用程序中，可能需要commOwner指向dn而不是cn，从而唯一标识commObject的所有者。语义示例应用程序，该属性将是有用的示例（LDIF片段）
commOwner:
ldap://directory.acme.com/dc=acme,dc=com??sub?(cn=bob%20smith)
commOwner: uid=bob,ou=people,dc=acme,dc=com
commOwner:
ldap://directory.acme.com/dc=acme,dc=com??sub?(cn=bob%20smith)
commOwner: uid=bob,ou=people,dc=acme,dc=com
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
OID:0.0.8.350.1.1.2.1.3 AttributeType:（0.0.8.350.1.1.2.1.3命名“commPrivate”DESC以确定条目是否对世界可见“语法1.3.6.1.4.1.1466.115.121.1.26）应用程序实用程序类用户要使用的标准值数多定义，并指示端点的隐私选项，即未列出的数字。允许值（如果受控）注意：此属性定义为布尔值。本建议的未来版本可能会为此属性开发一个受控词汇表，以适应多种类型的隐私。语义此属性对其有用的示例应用程序示例（LDIF片段）commPrivate:true
This section contains a schema configuration file for commURIObject and commObject that can be used to configure an LDAP server to support these classes.
本节包含commURIObject和commObject的架构配置文件，可用于配置LDAP服务器以支持这些类。
# 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]. # # #
#通信对象模式###在LDAP目录中表示通信对象的模式###抽象###本文档定义了在LDAP目录[LDAPv3]中表示通信对象的模式。它定义模式元素#来表示通信对象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
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
#
# .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
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 #
#删除：objectclasses objectclasses:（0.0.8.350.1.1.1.2.1名称“commURIObject”）-添加：objectclasses objectclasses:（0.0.8.350.1.1.1.2.1名称“commURIObject”DESC“object”，其中包含URI属性类型“SUP top AUXILIARY MAY（commURI））-##结束LDIF#
# 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
#
#
# 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
# 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
#
#
# 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: # # 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'
##如果这是您第一次使用此LDIF文件添加commObject#objectclass，则应注释#删除AttributeType修改，因为这将#失败。或者，如果您的ldapmodify有一个开关可以在出现错误时继续，那么只要使用该开关——如果您小心的话——删除：attributetypes attributetypes:（0.0.8.350.1.1.2.1.1名称“commUniqueId”）attributetypes:（0.0.8.350.1.1.2.1名称“commOwner”）attributetypes:（0.0.8.350.1.1.2.1.3名称“commPrivate”）-###重新添加属性--如果定义发生变化###添加：AttributeType AttributeType:（0.0.8.350.1.1.2.1.1名称'commUniqueId'DESC'保存端点唯一Id'相等caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch语法1.3.6.1.4.1.1466.115.121.1.26）attributeType：（0.0.8.350.1.1.2.2 NAME'commOwner'DESC'标记URI，指向原始所有者的相等caseExactMatch语法1.3.6.1.4.1.1466.115.121.1.15）attributeType:（0.0.8.350.1.1.2.1.3 NAME'commPrivate'DESC'决定条目是否对世界可见'SYNTAX 1.3.6.1.4.1.1466.115.121.1.26）-#对象类定义###本文档中定义了以下对象类：##commObject###commObject##删除：objectclasses对象类：（0.0.8.350.1.1.2.2名称“commObject”）-添加：objectclasses对象类：（0.0.8.350.1.1.2.2名称“commObject”
DESC 'object that contains the Communication attributes' SUP top STRUCTURAL MUST commUniqueId MAY ( commOwner $ commPrivate ) ) - # # end of LDIF #
DESC“包含通信属性的对象”SUP top STRUCTURAL MUST commUniqueId MAY（commOwner$commPrivate））-##LDIF结尾#
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.
属性索引是特定于实现的活动，取决于所需的应用程序。非索引属性可能导致搜索时间过长，导致某些应用程序无法使用。值得注意的是，用户和别名查找应该很快。附录A索引配置文件描述了commObject目录的索引配置，该配置将针对目录目录应用程序进行优化。此配置文件的使用是可选的。
commURI: no recommendation
commURI：没有建议
commUniqueId: equality
公报：平等
commOwner: presence
业主：在场
commPrivate: presence
私人通讯：存在
The normative text of H.350 is reproduced in this section.
本节转载了H.350的规范性文本。
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.
本建议描述了用于使用SIP的多媒体会议的LDAP目录服务体系结构。特别是，它定义了一个LDAP模式来表示网络上的SIP用户代理（UAs），并将这些端点与用户关联。
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
本建议旨在补充ITU-T Rec.H.350中讨论的CommObject目录体系结构，而不是用作独立体系结构。此LDAP模式的实现，以及H.350 CommObject体系结构的使用，有助于将SIP用户代理和会议设备集成到现有企业目录中，从而允许用户执行白页查找和访问SIP设备支持的可点击拨号。实施此模式的主要原因包括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.
Rec.H.350（CommObject类定义），因为它们特别适用于SIP UAs的使用，并帮助供应商使SIP服务更容易为其用户提供。
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.
本建议的范围包括针对使用SIP将端点信息集成到现有企业目录和白页中的体系结构的建议。
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.
本建议的范围不包括使用LDAP目录本身或其包含的数据的规范方法。模式的目的不是表示SIP协议中所有可能的数据元素，而是表示实现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.
请注意，SIP提供了定义良好的方法，用于在网络上发现注册器地址和定位用户。这里定义的一些属性用于更简单或手动的实现，可能并非所有应用程序都需要。例如，许多应用程序可能不需要SIPidentityRegistradAddress和SIPIdentityAddress，但为了完整性，此处将其包括在内。因此，SIPidentitySpuri是将要提供的主要属性，特别是对于白页目录应用程序。
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.
SIPIdentity类可以根据具体实现的需要进行扩展。有关模式扩展的讨论，请参阅ITU-T Rec.H.350的基础。
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.
SIPIdentity对象类表示SIP用户代理（UAs）。它是一个辅助类，从ITU-T Rec.H.350中定义的commObject类派生而来。
OID: 0.0.8.350.1.1.6.2.1 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 ) )
OID:0.0.8.350.1.1.6.2.1对象类：（0.0.8.350.1.1.6.2.1名称“SIPIdentity”描述“SIPIdentity对象”辅助顶级辅助可能（SIPIdentity ySpuri$SIPIdentity注册地址$SIPIdentity代理地址$SIPIdentity代理名称$SIPIdentity代理$SIPIdentity代理$SIPIdentity服务级别$userSMIMECertificate））
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
OID:0.0.8.350.1.1.6.1.1属性类型：（0.0.8.350.1.1.6.1.1名称“SIPIdentitySpuri”描述SIP UA的通用资源指示器“EQUALITY caseExactMatch SUBSTR CaseExactSubstrings匹配语法1.3.6.1.4.1.1466.115.121.1.15）应用程序实用程序类标准值个数多定义统一资源标识符，用于标识SIP中的通信资源。通常包含用户名和主机名，格式通常与电子邮件地址相似。允许值（如果受控）注释此URI可能会建立SIP或SIPS（安全）。在建立SIPS的情况下，URI必须反映它使用的是SIPS而不是SIP。见下面的例子。语义示例应用程序，对于这些应用程序，此属性将是用户SIP UA最新列表的有用在线表示。示例SIPIdentitySpuri:sip：alice@foo.com//SIP示例SIPIdentitySpuri:SIP:alice@152.2.158.212//SIP示例SIPIdentitySpuri:sips:bob@birmingham.edu//SIPS示例
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 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)
OID:0.0.8.350.1.1.6.1.2 AttributeType:（0.0.8.350.1.1.6.1.2名称'SIPIdentityRegistrarAddress'DESC'指定注册器'EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26'的位置）Application utility类处理特定域的注册请求并转发到位置服务器的服务器所属域的标准值数多定义地址。允许值（如果受控）
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 RFC 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
注意，RFC3261声明用户代理可以通过配置、使用记录地址或多播来发现其注册器地址。根据配置，第一个场景被认为超出了RFC 3261的范围。此属性可用于第一个场景。可以手动完成（例如，显示用户正确注册地址的网页），也可以使用具有H.350.4意识的用户代理自动完成。语义示例应用程序，该属性对于这些应用程序是有用的白页，一个显示用户正确配置信息的网页。示例（LDIF片段）SIPIdentityRegistrarAddress:152.2.15.22//IP地址示例SIPIdentityRegistrarAddress:sipregistrar.unc.edu//FQDN示例
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
OID:0.0.8.350.1.1.6.1.3 AttributeType:（0.0.8.350.1.1.6.1.3名称'SIPIdentityProxyAddress'DESC'指定SIP代理的位置'EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26）Application utility类标准值数多定义地址，用于指定域内SIP代理的域位置。RFC 3261定义SIP代理的角色。允许值（如果受控）Notes SIP用户代理不需要使用代理，但在许多情况下会使用。语义示例应用程序，该属性对于这些应用程序是有用的白页，一个显示用户正确配置信息的网页。示例（LDIF片段）SIPIdentityProxyAddress:172.2.13.234//IP地址示例SIPIdentityProxyAddress:sipproxy.unc.edu//FQDN示例
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
OID:0.0.8.350.1.1.6.1.4 AttributeType:（0.0.8.350.1.1.6.1.4名称'SIPIdentityAddress'DESC'UA的IP地址或FQDN'EQUALITY caseIgnoreIA5Match语法1.3.6.1.4.1.1466.115.121.1.26）应用工具类标准值数多定义指定UA的IP地址或完全限定域名。允许值（如果受控）注意：此属性对于UA-to-UA通信是直接的，不涉及代理或注册的应用程序可能有用。此属性对于显示用户正确的用户代理配置信息的网页非常有用的示例应用程序。示例（LDIF片段）SIPIdentityAddress:152.2.121.36//IP地址示例SIPIdentityAddress:ipPhone.foo.org//FQDN示例
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
OID:0.0.8.350.1.1.6.1.5 AttributeType:（0.0.8.350.1.1.6.1.5名称'SIPIdentityPassword'DESC'用户代理SIP密码'EQUALITY octetStringMatch语法1.3.6.1.4.1.1466.115.121.1.40）应用工具类标准值数多定义SIP用户代理密码，用于RFC 2617中定义的HTTP摘要身份验证方案。允许值（如果受控）注释：由于RFC 2617已淘汰的RFC 2069用作RFC 2543中HTTP摘要的基础，因此任何支持RFC 2617的SIP服务器必须确保与RFC 2069向后兼容。此SIPIdentityUserName与SIPIdentityPassword一起保留用于摘要访问
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
身份验证，不用于基本身份验证方法。LDAP提供了一种存储用户密码以供参考的方法。如果密码存储在LDAP中，则会使LDAP服务器成为特别有价值的攻击目标。鼓励实施者谨慎行事，并实施适当的安全程序，如加密、访问控制和传输层安全，以访问此属性。此属性对其有用的语义示例应用程序示例（LDIF片段）SIPIdentityPassword:36zxJmCIB18dM0FVAj
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
OID:0.0.8.350.1.1.6.6 AttributeType:（0.0.8.350.1.1.6.1.6名称'SIPIdentityUserName'DESC'用户代理用户名。'EQUALITY caseIgnoreMatch SUBSTR caseIgnoreMatch caseIgnoreSubstringsMatch语法1.3.6.1.1.1466.115.121.1.15）应用工具类标准值数多定义SIP用户代理的用户名，用于RFC 2617中定义的HTTP摘要身份验证方案。允许值（如果受控）注释：由于RFC 2617已淘汰的RFC 2069用作RFC 2543中HTTP摘要身份验证的基础，任何支持RFC 2617中定义的HTTP摘要身份验证的SIP服务器必须确保与RFC 2069向后兼容。此SIPIdentityUserName与SIPIdentityPassword一起保留用于摘要访问身份验证，而不是用于基本身份验证方法。请注意，在许多情况下，用户名将从user@proxy.domainSIPURI的一部分。在这种情况下，可能不需要填充此属性。语义此属性对其有用的示例应用程序示例（LDIF片段）SIPIdentityUserName:nelkhour
OID: 0.0.8.350.1.1.6.1.7 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
OID:0.0.8.350.1.1.6.1.7 AttributeType:（0.0.8.350.1.1.6.1.7名称“SIPIdentityService Level”DESC，用于定义用户可以属于的服务。“相等CaseIgnoreA5Match SUBSTR CaseIgnoreA5SubstringsMatch语法1.3.6.1.4.1.1466.115.121.1.26）应用程序实用程序类标准值数多定义这描述了用户可以属于的服务级别。允许值（如果受控）注意：此属性不表示在SIP中找到的数据元素。SIP本身不支持区分服务级别。相反，该属性提供了一种直接在LDAP中存储服务级别信息的机制。此映射允许服务提供商适应现有LDAP目录，而无需更改目录中SIPIdentityServiceLevel实例的值。语义此属性对其有用的示例应用程序示例（LDIF片段）SIPIdentityServiceLevel:premium
This clause contains a schema configuration file for SIPIdentity that can be used to configure an LDAP server to support this class.
此子句包含SIPIdentity的架构配置文件，可用于配置LDAP服务器以支持此类。
# 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
# 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 # # 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 )
#.1.6.3=语法#########属性类型定义##本建议中定义了以下属性类型：##SIPidentityspuri#SIPidentityRegistradAddress#SIPIdentityProxyAddress#SIPIdentityAddress#SIPIdentityPassword#SIPIdentityPassword#SIPIdentityUserName#IDEntityServiceLevel:cn=schema变更类型#如果需要修改#更改属性的定义，然后一步删除并重新添加###如果这是您第一次使用此LDIF文件添加SIPIdentity#objectclass，则应注释#删除AttributeType修改，因为这将#失败。或者，如果您的ldapmodify有一个开关可以在出现错误时继续，则只需使用该开关即可--如果您小心的话#删除：AttributeType AttributeType:（0.0.8.350.1.1.6.1.1名称“SipIdentityPuri”）AttributeType:（0.0.8.350.1.6.1.2名称“SipIdentityRegistradAddress”）AttributeType:（0.0.8.350.1.1.6.1.3名称“SIPIdentityProxyAddress”）AttributeType:（0.0.8.350.1.1.6.1.4名称“SIPIdentityAddress”）AttributeType:（0.0.8.350.1.1.6.1.5名称“SIPIdentityPassword”）AttributeType:（0.0.8.350.1.6.6名称“SIPIdentityUserName”）AttributeType:（0.8.350.1.1.6.1.7名称“SIPIdentityServiceLevel”）-###重新添加属性--如果定义发生更改##添加：AttributeType AttributeType:（0.0.8.350.1.1.6.1.1名称“SIPUA”的“EQUALITY caseExactMatch SUBSTR caseExactSubstringsMatch语法1.3.6.1.4.1.1466.115.121.1.15”的“SIPIdentitySpuri”通用资源指示器）
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 ) 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'
AttributeType：（0.0.8.350.1.1.6.1.2 NAME'SIPIdentityRegistrarAddress'DESC'指定注册器的平等案例IgnoreA5Match语法1.3.6.1.4.1.1466.115.121.1.26）AttributeType：（0.0.8.350.1.1.6.1.3 NAME'SIPIdentityProxyAddress'DESC'指定SIP代理'EQUALITY CaseIgnoreA5Match语法1.3.6.1.4.1.1466.115.121.1.26）AttributeType:（0.8.350.1.1.6.1.4 NAME'SIPIdentityAddress'DESC'UA'EQUALITY CaseIgnoreA5Match语法1.3.6.1.4.1.1.1.1466.115.121.1.26）AttributeType:（0.0.8.350.1.1.6.1.5名称'SIPIdentityPassword'DESC'用户代理SIP密码'EQUALITY octetStringMatch语法1.3.6.1.4.1466.115.121.1.40）属性类型：（0.0.8.350.1.1.6.6名称'SIPIdentityUserName'DESC'用户代理用户名。'EQUALITY caseIgnoreMatch SUBSTR caseIgnoreMatch语法1.3.6.1.4.1.1.1466.115.121.1.15）AttributeType:（0.0.8.350.1.1.6.1.7名称“SIPIdentityServiceLevel”DESC，用于定义用户可以属于的服务。“相等CaseIgnoreA5Match SUBSTR CaseIgnoreA5SubstringsMatch语法1.3.6.1.1.1466.115.121.1.26）-#对象类定义###本建议中定义了以下对象类：##SIPIdentity##SIPIdentity##删除：对象类对象类：（0.0.8.350.1.1.6.2.1名称“SIPIdentity”）-添加：对象类对象类：（0.0.8.350.1.1.6.2.1名称“SIPIdentity”
DESC 'SIPIdentity object' SUP top AUXILIARY MAY ( SIPIdentitySIPURI $ SIPIdentityRegistrarAddress $ SIPIdentityProxyAddress $ SIPIdentityAddress $ SIPIdentityPassword $ SIPIdentityUserName $ SIPIdentityServiceLevel $ userSMIMECertificate ) ) - # # end of LDIF #
描述“SIPIdentity对象”辅助顶部辅助可能（SIPIdentitySpuri$SIPIdentityRegistradAddress$SIPIdentityProxyAddress$SIPIdentityAddress$SIPIdentityPassword$SIPIdentityUserName$SIPIdentityServiceLevel$userSMIMECertificate））-##LDIF结束#
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.
属性索引是特定于实现的活动，取决于所需的应用程序。非索引属性可能导致搜索时间过长，导致某些应用程序无法使用。值得注意的是，用户和别名查找应该很快。附录A索引配置文件描述了SIPIdentity目录的索引配置，该配置将针对目录应用程序中的使用进行优化。此配置文件的使用是可选的。
SIPIdentitySIPURI: equality
SipIdentitySpuri：平等
SIPIdentityRegistrarAddress: no recommendation
SIPIdentity注册地址：无建议
SIPIdentityProxyAddress: no recommendation
SIPidentityProxy地址：无建议
SIPIdentityAddress: equality
SIPIdentityAddress：平等
SIPIdentityUserName: equality
SIPIdentityUserName:相等
SIPIdentityPassword: no recommendation
SIPIdentityPassword：没有建议
SIPIdentityServiceLevel: equality
SIPidentityService级别：相等
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.
我们感谢众多同事跨越标准机构、研究网络、学术界和私营行业的多个边界，以创建一个致力于集成多媒体会议部署的体系结构。特别是，IETF和ITU-T的标准均广泛采用，该体系结构旨在服务于所有社区。
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.
这项工作由视频会议中间件（VidMid VC）工作组开发，该工作组是Internet2（www.Internet2.edu）和视频开发计划（www.vide.net）的共同努力。该体系结构的开发是为了应对ViDeNet（https/：ViDeNet.unc.edu）学术测试平台中发现的部署挑战，该测试平台提供跨国际研究网络的IP视频和语音基础设施。
This work was supported in part by a grant from the United States National Science Foundation contract number ANI-0222710.
这项工作部分由美国国家科学基金会合同编号ANI-0221710资助。
This section is not present in the ITU-T standard, but gives information for the IETF community. Its content has the consensus of the ITU-T Study Group 16.
本节不在ITU-T标准中，但为IETF社区提供了信息。其内容得到了ITU-T研究小组16的一致同意。
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.
H.350不会改变任何特定协议的安全架构。但是，它确实提供了一个标准化的位置来存储适当的身份验证凭据。应该注意的是，H.323和SIP都支持共享秘密认证（分别是H.235附录D和HTTP摘要）。这些方法要求呼叫服务器能够访问密码。因此，如果呼叫服务器或H.350目录受损，密码也可能受损。这些弱点可能是由于系统（H.350目录或呼叫服务器）及其运行方面的弱点，而不是H.350本身的弱点造成的。
The userSMIMECertificate attribute is defined in RFC 2798 (section 2.8) as a part of inetOrgPerson. The SIP user agent's X.509 certificate can be stored in this attribute. When the certificate is present, it can be employed with S/MIME to provide authentication, integrity, and confidentiality as specified in RFC 3261 [5].
RFC 2798（第2.8节）将userSMIMECertificate属性定义为inetOrgPerson的一部分。SIP用户代理的X.509证书可以存储在此属性中。当证书存在时，它可以与S/MIME一起使用，以提供RFC 3261[5]中规定的身份验证、完整性和机密性。
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.
强烈建议呼叫服务器和H.350目录在共享信息之前相互验证。此外，强烈建议H.350目录与呼叫服务器或端点之间的通信通过SSL或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.
最后，LDAP服务器上的访问控制列表是一个策略问题，不是标准的一部分。建议系统管理员在设置H.350属性的访问控制时使用常识。例如，密码属性只能由经过身份验证的用户访问，而地址属性可能是公开的。
[1] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[1] Hodges，J.和R.Morgan，“轻量级目录访问协议（v3）：技术规范”，RFC3372002年9月。
[2] ITU-T Recommendation H.350, "Directory services architecture for multimedia conferencing", 2003.
[2] ITU-T建议H.350，“多媒体会议的目录服务体系结构”，2003年。
[3] ITU-T Recommendation H.350.4, "Directory services architecture for SIP", 2003.
[3] ITU-T建议H.350.4，“SIP目录服务体系结构”，2003年。
[4] Franks, J., Hallam-Baker P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[4] Franks，J.，Hallam Baker P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[5] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC3263，2002年6月。
[7] Smith, M., "Definition of the inetOrgPerson LDAP Object Class", RFC 2798, April 2000.
[7] Smith，M.，“inetOrgPerson LDAP对象类的定义”，RFC 2798，2000年4月。
[8] ITU-T Recommendation H.350.1, "Directory services architecture for H.323", 2003.
[8] ITU-T建议H.350.1，“H.323目录服务体系结构”，2003年。
[9] ITU-T Recommendation H.350.2, "Directory services architecture for H.235", 2003.
[9] ITU-T建议H.350.2，“H.235目录服务体系结构”，2003年。
[10] ITU-T Recommendation H.350.3, "Directory services architecture for H.320", 2003.
[10] ITU-T建议H.350.3，“H.320目录服务体系结构”，2003年。
[11] ITU-T Recommendation H.350.5, "Directory services architecture for Non-Standard Protocols", 2003.
[11] ITU-T建议H.350.5，“非标准协议的目录服务体系结构”，2003年。
[12] ITU-T Recommendation H.350.6, "Directory services architecture for Call Forwarding and Preferences", 2004.
[12] ITU-T建议H.350.6，“呼叫转移和首选项的目录服务体系结构”，2004年。
[13] Howes T. and M. Smith, "Understanding And Deploying LDAP Directory Services", New Riders Publishing, ISBN: 1578700701, 1999.
[13] Howes T.和M.Smith，“理解和部署LDAP目录服务”，《新骑手出版》，ISBN:15787007011999。
[14] Howes T. and M. Smith, "LDAP Programming Directory-Enabled Applications with Lightweight Directory Access Protocol", New Riders Publishing, ISBN: 1578700000, 1997.
[14] Howes T.和M.Smith，“具有轻量级目录访问协议的LDAP编程目录支持应用程序”，《新骑手》出版，ISBN:15787000001997。
This specification is an RFC publication of an ITU-T publication [4], without textual changes within the standard itself (Section 4). The present section appears in the RFC publication only. In order for this specification to be implemented properly, a number of standards pertaining to LDAP [1], [7], H.350 [2],[3], and SIP [4], [5], [6], [7], need to be implemented in whole or in part by the implementor.
本规范是ITU-T出版物[4]的RFC出版物，在标准本身（第4节）内没有文本更改。本节仅出现在RFC出版物中。为了正确实施本规范，实施者需要全部或部分实施与LDAP[1]、[7]、H.350[2]、[3]和SIP[4]、[5]、[6]、[7]相关的许多标准。
For some background information on the ITU and IETF directory service protocols, reading [8], [9], [10], [11], and [12] is valuable, and [13] and [14] are recommended books.
关于ITU和IETF目录服务协议的一些背景信息，阅读[8]、[9]、[10]、[11]和[12]是有价值的，而[13]和[14]是推荐书籍。
Tyler Johnson Editor, H.350 University of North Carolina Chapel Hill, NC 27599
泰勒·约翰逊编辑，H.350北卡罗来那大学教堂山，NC 27599
Phone: +1.919.843.7004
EMail: Tyler_Johnson@unc.edu
Phone: +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
Sakae Okubo问题4/16报告员，ITU-T SG16早稻田大学YRP Ichibankan，3-4 Hikarinooka Yokosuka shi，239-0847日本
Phone: +81 46 847 5406
EMail: sokubo@waseda.jp
Phone: +81 46 847 5406
EMail: sokubo@waseda.jp
Simao Ferraz de Campos Neto Counsellor, ITU-T SG 16 International Telecommunication Union Place des Nations Geneva CH1211 - Switzerland
Simao Ferraz de Campos Neto参赞，ITU-T SG 16国际电信联盟日内瓦国际广场CH1211-瑞士
Phone: +41-22-730-6805
EMail: simao.campos@itu.int
Phone: +41-22-730-6805
EMail: simao.campos@itu.int
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关ISOC文件中权利的ISOC程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。