Network Working Group G. Vaudreuil
Request for Comments: 4237 Lucent Technologies
Category: Standards Track October 2005
Network Working Group G. Vaudreuil
Request for Comments: 4237 Lucent Technologies
Category: Standards Track October 2005
Voice Messaging Directory Service
语音通讯目录服务
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document provides details of the Voice Profile for Internet Mail (VPIM) directory service. The service provides the email address of the recipient that is given a telephone number. It optionally provides the spoken name of the recipient and the media capabilities of the recipient.
本文档提供了Internet Mail（VPIM）目录服务语音配置文件的详细信息。该服务提供收件人的电子邮件地址，并提供电话号码。它可以选择提供收件人的口头姓名和收件人的媒体功能。
The VPIM directory Schema provides essential additional attributes to recreate the voice mail user experience using standardized directories. This user experience provides, at the time of addressing, basic assurances that the message will be delivered as intended. This document combines two earlier documents, one from Anne Brown and one from Greg Vaudreuil, that define a voice messaging schema into a single working group submission.
VPIM目录模式提供了重要的附加属性，可以使用标准化目录重新创建语音邮件用户体验。在寻址时，这种用户体验提供了消息将按预期交付的基本保证。本文档结合了两个早期文档，一个来自Anne Brown，另一个来自Greg Vaudreuil，它们将语音消息传递模式定义为单个工作组提交。
Table of Contents
目录
1. Scope ...........................................................2
1.1. Design Goals ...............................................2
1.2. Performance Constraints ....................................2
1.3. Scaling Constraints ........................................3
1.4. Reliability Constraints ....................................3
2. The VPIMUser Directory Schema ...................................3
2.1. vPIMTelephoneNumber ........................................4
2.2. vPIMRfc822Mailbox ..........................................4
2.3. vPIMSpokenName .............................................4
2.4. vPIMTextName ...............................................5
2.5. vPIMSupportedAudioMediaTypes ...............................5
2.6. vPIMSupportedMessageContext ................................5
2.7. vPIMExtendedAbsenceStatus ..................................6
2.8. vPIMSupportedUABehaviors ...................................6
2.9. vPIMMaxMessageSize .........................................7
2.10. vPIMSubMailboxes ..........................................8
3. Security Considerations .........................................8
4. IANA Considerations .............................................9
4.1. Object Identifiers .........................................9
4.2. Object Identifier Descriptors ..............................9
5. References .....................................................10
5.1. Normative References ......................................10
5.2. Informative References ....................................10
1. Scope ...........................................................2
1.1. Design Goals ...............................................2
1.2. Performance Constraints ....................................2
1.3. Scaling Constraints ........................................3
1.4. Reliability Constraints ....................................3
2. The VPIMUser Directory Schema ...................................3
2.1. vPIMTelephoneNumber ........................................4
2.2. vPIMRfc822Mailbox ..........................................4
2.3. vPIMSpokenName .............................................4
2.4. vPIMTextName ...............................................5
2.5. vPIMSupportedAudioMediaTypes ...............................5
2.6. vPIMSupportedMessageContext ................................5
2.7. vPIMExtendedAbsenceStatus ..................................6
2.8. vPIMSupportedUABehaviors ...................................6
2.9. vPIMMaxMessageSize .........................................7
2.10. vPIMSubMailboxes ..........................................8
3. Security Considerations .........................................8
4. IANA Considerations .............................................9
4.1. Object Identifiers .........................................9
4.2. Object Identifier Descriptors ..............................9
5. References .....................................................10
5.1. Normative References ......................................10
5.2. Informative References ....................................10
The VPIM directory Schema (VPIMDIR) is accessed from outside the enterprise or service provider domain using the recipient's telephone number.
VPIM目录模式（VPIMDIR）是使用收件人的电话号码从企业或服务提供商域外部访问的。
Once the identity of the VPIM directory server is known, the email address, capabilities, and spoken name confirmation information can be retrieved. This query is expected to use LDAP [LDAP], a connection-oriented protocol. The protocol transaction includes multiple packet round-trips to execute the query and retrieval and is considered to be the highest latency element of the messaging service. Further, retrieval of the confirmation information may require the return of a spoken name segment of up to 20kbytes (5 seconds at 4kbytes/second). Over a sufficiently engineered Internet connection, a 1250 ms response time is believed to be achievable over the Internet at large.
一旦知道VPIM目录服务器的身份，就可以检索电子邮件地址、功能和语音姓名确认信息。此查询应使用LDAP[LDAP]，一种面向连接的协议。协议事务包括执行查询和检索的多个数据包往返，被认为是消息传递服务的最高延迟元素。此外，检索确认信息可能需要返回高达20kbytes（4kbytes/s时为5秒）的语音名称段。在经过充分设计的互联网连接上，一般认为可以在互联网上实现1250毫秒的响应时间。
A service provider's namespace is expected to include entries for tens of millions of subscribers in a flat namespace based on the VPIM inter-domain address form: telephone_number@domain_name. A large corporation may have a hundred-thousand entries, while a large service provider may have tens of millions of entries in a single domain. It is expected that there will be a single public address validation service for a given service provider's network. It is believed that existing directory technology, including horizontal scalability through replication, will provide sufficient transaction throughput within the required latency requirements to address this need. The only fundamental, new requirement this application imposes on directory servers, beyond similar existing services, is the ability to return the recipient's spoken name. Preliminary investigation suggests that storage and retrieval of a spoken name will not add appreciable latency; however, it will add to the need for storage capacity.
服务提供商的名称空间预计将在一个基于VPIM域间地址形式（电话）的平面名称空间中包含数千万订阅者的条目_number@domain_name. 一个大公司可能有十万个条目，而一个大型服务提供商在一个域中可能有数千万个条目。预计给定服务提供商的网络将有一个单一的公共广播验证服务。人们相信，现有的目录技术，包括通过复制实现的水平可伸缩性，将在所需的延迟要求内提供足够的事务吞吐量，以满足这一需求。除了类似的现有服务外，该应用程序对目录服务器提出的唯一基本的新要求是能够返回收件人的口头姓名。初步调查表明，储存和检索一个口头姓名不会增加明显的延迟；然而，这将增加对存储容量的需求。
DNS provides well-documented redundancy and load-balancing capabilities for the VPIMDIR. However, the latency requirements to the end-user may not permit client-side fail-over to a secondary server and may require the directory server to be implemented as a high-availability service.
DNS为VPIMDIR提供了完善的冗余和负载平衡功能。但是，对最终用户的延迟要求可能不允许客户端故障转移到辅助服务器，并且可能需要将目录服务器实现为高可用性服务。
(IANA-ASSIGNED-OID.1 NAME 'vPIMUser' SUP 'top' AUXILIARY MUST ( vPIMRfc822Mailbox $ vPIMTelephoneNumber ) MAY ( vPIMSpokenName $ vPIMSupportedUABehaviors $ vPIMSupportedAudioMediaTypes $ vPIMSupportedMessageContext $ vPIMTextName $ vPIMExtendedAbsenceStatus $ vPIMMaxMessageSize $ vPIMSubMailboxes ) )
（IANA-ASSIGNED-OID.1名称“vPIMUser”SUP“top”辅助必须（VPIMRFC822邮箱$vPIMTelephoneNumber）可以（vPIMSpokenName$VPIMSupportedAbeAbehaviors$vPIMSupportedAudioMediaTypes$vPIMSupportedMessageContext$vPIMTextName$VPIMextendedAbsenStatus$vPIMMaxMessageSize$VPIMSubMailbox））
When present, the vPIMUser object contains information useful for verifying that the dialed telephone number corresponds to the intended recipient. This object also provides capability information and mailbox status information useful for guiding composition by the sender and for setting delivery expectations at sending time.
存在时，vPIMUser对象包含用于验证所拨电话号码是否对应于预期收件人的有用信息。此对象还提供功能信息和邮箱状态信息，这些信息对于指导发件人的合成以及设置发送时的传递期望非常有用。
The attribute vPIMTelephoneNumber is the full E.164 form of the telephone number [E164], including any sub-addressing portion. The normal search will be for this attribute.
属性vPIMTelephoneNumber是电话号码[E164]的完整E.164形式，包括任何子寻址部分。正常搜索将针对此属性。
(IANA-ASSIGNED-OID.2.1 NAME 'vPIMTelephoneNumber' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44{20} )
（IANA-ASSIGNED-OID.2.1名称“vPIMTelephoneNumber”相等caseIgnoreMatch语法1.3.6.1.4.1.1466.115.121.1.44{20}）
Example: A North American telephone number with the sub address of 12 would be represented as "+12145551212+12".
示例：子地址为12的北美电话号码将表示为“+12145551212+12”。
Note that vPIMTelephoneNumber is, by default, a multi-valued attribute. But if an entry has multiple values for this attribute, those values MUST be distinct from each other in the telephone number portion. It is expected that each submailbox of a single telephone number will have its own vPIMUser entry.
请注意，vPIMTelephoneNumber在默认情况下是一个多值属性。但是，如果一个条目对此属性具有多个值，则这些值在电话号码部分中必须彼此不同。预计单个电话号码的每个子邮箱都有自己的vPIMUser条目。
The vPIMTelephoneNumber differs from telephoneNumber in [LDAP] in its support for sub-addressing information and its use as a voice messaging address. In most cases, these values will be the same.
vPIMTelephoneNumber与[LDAP]中的telephoneNumber的不同之处在于它支持子寻址信息，并将其用作语音消息地址。在大多数情况下，这些值是相同的。
The telephone number is stored with no parenthesis, spaces, dots, or hyphens. The leading '+' and the '+' delineating the submailbox are required markup.
电话号码存储时不带括号、空格、点或连字符。描述子邮箱的前导“+”和“+”是必需的标记。
The attribute vPIMRfc822Mailbox stores the inter-domain SMTP address of the voice mailbox associated with a given telephone number. It is defined as a distinct attribute to distinguish it from the rfc822Mailbox attribute that may be used for other purposes. Although it would be preferable to define vPIMRfc822Mailbox as a subtype of rfc822Mailbox, it is defined here as an entirely new attribute because some directory implementations do not support sub-typing.
属性vPIMRfc822Mailbox存储与给定电话号码关联的语音邮箱的域间SMTP地址。它被定义为一个独特的属性，以区别于可能用于其他目的的rfc822Mailbox属性。尽管最好将vPIMRfc822Mailbox定义为rfc822Mailbox的子类型，但此处将其定义为一个全新的属性，因为某些目录实现不支持子类型。
(IANA-ASSIGNED-OID.2.2 NAME 'vPIMRfc822Mailbox' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )
（IANA-ASSIGNED-OID.2.2名称“vPIMRfc822Mailbox”相等caseIgnoreA5Match语法1.3.6.1.4.1.1466.115.121.1.26{256}）
The vPIMSpokenName attribute is an octet string and MUST be encoded in 32 kbit/s ADPCM exactly, as defined by [32KADPCM]. vPIMSpokenName shall contain the spoken name of the user in the voice of the user. The length of the spoken name segment MUST NOT exceed five seconds.
vPIMSpokenName属性是一个八位字节字符串，必须按照[32KADPCM]的定义以32kbit/s ADPCM的格式准确编码。vPIMSpokenName应包含用户语音中的用户语音名称。语音姓名段的长度不得超过5秒。
Private or additional encoding types are outside the scope of this version.
专用或其他编码类型不在此版本的范围内。
(IANA-ASSIGNED-OID.2.3 NAME 'vPIMSpokenName' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{20000} SINGLE-VALUE )
（IANA-ASSIGNED-OID.2.3名称“vPIMSpokenName”相等八位字符串匹配语法1.3.6.1.4.1.1466.115.121.1.40{20000}单值）
The text name is designed to be consistent with the unstructured text name databases used for calling name delivery service of caller ID.
文本名称设计为与用于调用呼叫者ID的名称传递服务的非结构化文本名称数据库一致。
(IANA-ASSIGNED-OID.2.4 NAME 'vPIMTextName' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{20} SINGLE-VALUE )
（IANA-ASSIGNED-OID.2.4名称“vPIMTextName”相等caseIgnoreMatch语法1.3.6.1.4.1.1466.115.121.1.15{20}单值）
The vPIMSupportedAudioMediaTypes attribute indicates the type(s) of audio encodings that can be received at the address specified in vPIMRfc822Mailbox.
vPIMSupportedAudioMediaTypes属性表示可以在vPIMRfc822Mailbox中指定的地址接收的音频编码类型。
(IANA-ASSIGNED-OID.2.5 NAME 'vPIMSupportedAudioMediaTypes' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（IANA-ASSIGNED-OID.2.5名称“vPIMSupportedAudioMediaTypes”相等大小写IA5Match语法1.3.6.1.4.1.1466.115.121.1.26）
This is a multi-value attribute. The allowable values for this attribute are the MIME audio subtypes registered with IANA. Non-standard and private encoding types must be indicated by prepending the new type name with either "X-" or "x-".
这是一个多值属性。此属性的允许值是向IANA注册的MIME音频子类型。非标准和专用编码类型必须通过在新类型名称前面加上“X-”或“X-”来表示。
Because ADPCM is a required format, the audio32kadpcm value must be listed if this attribute is present.
由于ADPCM是必需的格式，因此如果存在此属性，则必须列出audio32kadpcm值。
The message context provides guidance to the sender about the message contexts the recipient is likely to accept. Message context provides less precise information about a given recipient's capabilities than a list of media types. However, given the growing role of media-conversion gateways, the context indicator provides more useful guidance to a sender in a "unified messaging" environment.
消息上下文为发件人提供有关收件人可能接受的消息上下文的指导。与媒体类型列表相比，消息上下文提供的有关给定收件人功能的信息不太精确。然而，考虑到媒体转换网关的作用越来越大，上下文指示符为“统一消息”环境中的发送者提供了更有用的指导。
(IANA-ASSIGNED-OID.2.6 NAME 'vPIMSupportedMessageContext' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（IANA-ASSIGNED-OID.2.6名称“vPIMSupportedMessageContext”相等caseIgnoreA5Match语法1.3.6.1.4.1.1466.115.121.1.26）
This is a multi-value attribute. The set of valid message context values is defined in [CONTEXT].
这是一个多值属性。有效消息上下文值集在[上下文]中定义。
It is common to have an attribute that indicates to the subscriber whether the recipient is accepting messages during his absence. This feature -- called "extended absence" -- provides an advisory message at sending time. It is similar in concept to "vacation notices" common for textual email, but has its own cultural and operational nuances.
通常会有一个属性向订阅者指示收件人是否在他不在时接受邮件。此功能称为“延长缺勤”，在发送时提供一条建议消息。它在概念上类似于文本电子邮件中常见的“假期通知”，但有其自身的文化和操作上的细微差别。
(IANA-ASSIGNED-OID.2.7 NAME 'vPIMExtendedAbsenceStatus' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
（IANA-ASSIGNED-OID.2.7名称“VPIMEXTENDEDASENCESTATUS”相等caseIgnoreA5Match语法1.3.6.1.4.1.1466.115.121.1.26单值）
The three values defined are:
定义的三个值是：
"Off", "On", "MsgBlocked"
“关闭”、“打开”、“MsgBlocked”
"Off" indicates that the recipient either does not support extended absence or has not set such an indicator. "Off" is the default condition if this attribute is not returned.
“关闭”表示收件人不支持长期缺勤或未设置此类指标。如果不返回此属性，“Off”是默认条件。
"On" indicates that the recipient has set an extended absence indicator, but the mailbox is still accepting messages for review at an unspecified future time.
“开”表示收件人已设置了延长缺勤指示器，但邮箱仍在接受邮件，以便在未指定的将来时间进行审阅。
"MsgBlocked" indicates that the recipient has set an extended absence indicator and the mailbox is currently configured to reject incoming messages. Messages SHOULD NOT be sent to the recipient if this value is returned in the vPIMExtendedAbsenceStatus attribute.
“MsgBlocked”表示收件人已设置延长缺勤指示器，邮箱当前配置为拒绝传入邮件。如果VPIMEXTENDEDASENCESTATUS属性中返回此值，则不应将邮件发送给收件人。
Internet mail does not provide facilities for the sender to know whether the recipient supports a number of optional features that can be requested or indicated in the RFC822 headers. This attribute provides a list of the attributes, considered optional by VPIM and other vendor-specific attributes, that may be supported by the recipient. If this attribute is not supported, only those attributes
Internet mail不提供便利，让发件人知道收件人是否支持RFC822标题中可以请求或指示的许多可选功能。此属性提供了一个属性列表，VPIM认为这些属性是可选的，收件人可能支持其他特定于供应商的属性。如果不支持此属性，则仅支持这些属性
listed as mandatory in VPIM are assumed to be supported. Undisclosed behaviors may be indicated in the RFC822 message; however, there is no assurance by the receiving system of their support.
在VPIM中列为必填项的被认为是受支持的。RFC822消息中可能指示未公开的行为；然而，接收系统无法保证他们的支持。
(IANA-ASSIGNED-OID.2.8 NAME 'vPIMSupportedUABehaviors' EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )
（IANA-ASSIGNED-OID.2.8名称“VPIMSupportedAbeAbehaviors”相等案例IGNOREIA5Match语法1.3.6.1.4.1.1466.115.121.1.26）
The following behaviors are defined:
定义了以下行为：
MessageDispositionNotification MessageSensitivity MessageImportance
MessageDispositionNotification MessageSensitivity message重要性
The presence of the MessageDispositionNotification value indicates that the recipient will send an MDN in response to an MDN request.
MessageDispositionNotification值表示收件人将发送MDN以响应MDN请求。
MessageSensitivity indicates that the recipient fully supports the sensitivity indication as defined in VPIM [VPIMV2].
MessageSensitivity表示收件人完全支持VPIM[VPIMV2]中定义的敏感度指示。
MessageImportance indicates that the recipient fully supports the importance indication as defined in VPIM [VPIMV2].
MessageImportance表示收件人完全支持VPIM[VPIMV2]中定义的重要性指示。
These may be further extended without standardization to include proprietary user interface functional extensions. These proprietary extension values must be prefixed with an "X-" or "x-".
这些可以在没有标准化的情况下进一步扩展，以包括专有用户界面功能扩展。这些专有扩展值必须以“X-”或“X-”作为前缀。
At the time of composition, the message can be checked for acceptable length using the maximum message size attribute. Maximum message size is an attribute usually configured by policy of the receiving system, typically in units of minutes. While ESMTP provides a mechanism to determine if a message is too long in bytes, it is an unreliable guide for the composer when multiple encodings, multiple media, or variable bit-rate encodings are supported.
在合成时，可以使用“最大消息大小”属性检查消息的可接受长度。最大消息大小是通常由接收系统的策略配置的属性，通常以分钟为单位。虽然ESMTP提供了一种确定消息是否过长（字节）的机制，但当支持多种编码、多种媒体或可变比特率编码时，它对编写器来说是一个不可靠的指南。
(IANA-ASSIGNED-OID.2.9 NAME 'vPIMMaxMessageSize' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
（IANA-ASSIGNED-OID.2.9名称“vPIMMaxMessageSize”相等整数匹配语法1.3.6.1.4.1.1466.115.121.1.27单值）
The attribute indicates the maximum message length in seconds that the receiving mailbox may receive.
该属性指示接收邮箱可能接收的最大邮件长度（以秒为单位）。
This attribute indicates the presence of sub-mailboxes for the queried telephone number. This information may be used to provide a post-dial sub-addressing menu to the sender.
此属性表示查询的电话号码存在子邮箱。此信息可用于向发件人提供拨号后子寻址菜单。
(IANA-ASSIGNED-OID.2.10 NAME 'vPIMSubMailboxes' EQUALITY numericStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.36{4} )
（IANA-ASSIGNED-OID.2.10名称“VPIMSubMailbox”相等数字字符串匹配语法1.3.6.1.4.1.1466.115.121.1.36{4}）
The allowable values include a list of sub-mailbox numbers with a numeric range of 1-9999. The user interface may use this information to prompt the sender to select a sub-mailbox. Spoken names associated with each sub-mailbox may be individually retrieved by subsequent queries to the recipient's VPIMDIR service.
允许值包括数字范围为1-9999的子邮箱号码列表。用户界面可以使用此信息提示发件人选择子邮箱。与每个子邮箱关联的语音名称可以通过对收件人的VPIMDIR服务的后续查询单独检索。
The following are known security issues.
以下是已知的安全问题。
1) Service provider customer information is very sensitive, especially in this time of local phone competition. Service providers require maximum flexibility to protect this data. Because of the dense nature of telephone number assignments, this data is subject to "go fish" queries via repeated LDAP queries to determine a complete list of current or active messaging subscribers. To reduce the value of this retrieved data, service providers may limit disclosure of data that is useful for telemarketing, such as the textual name, and may disclose only information useful to the sender, such as the recipient's spoken name, a data element that is much harder to auto-process.
1) 服务提供商的客户信息非常敏感，尤其是在这个本地电话竞争的时代。服务提供商需要最大的灵活性来保护这些数据。由于电话号码分配的密集性，这些数据会通过重复的LDAP查询进行“钓鱼”查询，以确定当前或活动消息传递订阅者的完整列表。为了降低检索到的数据的价值，服务提供商可能会限制对电话营销有用的数据的披露，例如文本名称，并且可能只披露对发送者有用的信息，例如接收者的口头名称，这是一个更难自动处理的数据元素。
2) In many countries, there are privacy laws or regulations that prohibit disclosure of certain kinds of descriptive information (e.g., text names). Hence, server implementors are encouraged to support DIT structural rules and name forms [LDAPMODELS] as these provide a mechanism for administrators to select appropriate naming attributes for entries. Administrators are encouraged to use these mechanisms, access controls, and other administrative controls, which may be available to restrict use of attributes containing sensitive information when naming entries.
2) 在许多国家，有隐私法律或法规禁止披露某些类型的描述性信息（例如，文本名称）。因此，鼓励服务器实现人员支持DIT结构规则和名称表单[LDAPMODELS]，因为它们为管理员提供了为条目选择适当命名属性的机制。鼓励管理员使用这些机制、访问控制和其他管理控制，这些控制可用于在命名条目时限制使用包含敏感信息的属性。
3) The LDAP directory service needs to be secured properly for this intended use. [LDAPAUTH] describes a number of considerations that apply in this use. In particular, this service provides unauthenticated, public access to directory data, and as such, it is vulnerable to attacks that redirect the query to a rogue server and offer malicious data.
3) LDAP目录服务需要为此预期用途进行适当的安全保护。[LDAPAUTH]描述了在此使用中应用的一些注意事项。特别是，此服务提供对目录数据的未经验证的公共访问，因此，它容易受到将查询重定向到恶意服务器并提供恶意数据的攻击。
Reference RFC 3383 "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)" [LDAPREG].
参考RFC 3383“轻量级目录访问协议（LDAP）的互联网分配号码管理局（IANA）注意事项”[LDAPREG]。
IANA has registered an LDAP Object Identifier for use in this technical specification, according to the following template:
IANA已根据以下模板注册了LDAP对象标识符以用于本技术规范：
Subject: Request for LDAP OID Registration
主题：请求LDAP OID注册
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Greg Vaudreuil (gregv@ieee.org)
格雷格·沃德鲁伊(gregv@ieee.org)
Specification: RFC 4237
规格：RFC4237
Author/Change Controller: IESG
作者/变更控制员：IESG
Comments:
评论：
The assigned OID will be used as a base for identifying a number of schema elements defined in this document.
分配的OID将用作标识本文档中定义的多个架构元素的基础。
IANA has registered the LDAP Descriptors used in this technical specification, as detailed in the following template:
IANA已注册了本技术规范中使用的LDAP描述符，详见以下模板：
Subject: Request for LDAP Descriptor Registration Update
主题：请求LDAP描述符注册更新
Descriptor (vPIM): see comment
描述符（vPIM）：请参阅注释
Object Identifier: see comment
对象标识符：请参阅注释
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
GregV@ieee.org
GregV@ieee.org
Usage: see comment
用法：参见注释
Specification: RFC 4237
规格：RFC4237
Author/Change Controller: IESG
作者/变更控制员：IESG
Comments:
评论：
The following descriptors have been added:
已添加以下描述符：
NAME Type OID
-------------- ---- ------------
vPIMUser O IANA-ASSIGNED-OID.1.1
vPIMRfc822Mailbox A IANA-ASSIGNED-OID.2.1
vPIMTelephoneNumber A IANA-ASSIGNED-OID.2.2
vPIMSpokenName A IANA-ASSIGNED-OID.2.3
vPIMSupportedUABehaviors A IANA-ASSIGNED-OID.2.4
vPIMSupportedAudioMediaTypes A IANA-ASSIGNED-OID.2.5
vPIMSupportedMessageContext A IANA-ASSIGNED-OID.2.6
vPIMTextName A IANA-ASSIGNED-OID.2.7
vPIMExtendedAbsenceStatus A IANA-ASSIGNED-OID.2.8
vPIMMaxMessageSize A IANA-ASSIGNED-OID.2.9
vPIMSubMailboxes A IANA-ASSIGNED-OID.2.10
NAME Type OID
-------------- ---- ------------
vPIMUser O IANA-ASSIGNED-OID.1.1
vPIMRfc822Mailbox A IANA-ASSIGNED-OID.2.1
vPIMTelephoneNumber A IANA-ASSIGNED-OID.2.2
vPIMSpokenName A IANA-ASSIGNED-OID.2.3
vPIMSupportedUABehaviors A IANA-ASSIGNED-OID.2.4
vPIMSupportedAudioMediaTypes A IANA-ASSIGNED-OID.2.5
vPIMSupportedMessageContext A IANA-ASSIGNED-OID.2.6
vPIMTextName A IANA-ASSIGNED-OID.2.7
vPIMExtendedAbsenceStatus A IANA-ASSIGNED-OID.2.8
vPIMMaxMessageSize A IANA-ASSIGNED-OID.2.9
vPIMSubMailboxes A IANA-ASSIGNED-OID.2.10
Where Type A is Attribute and Type O is ObjectClass
其中，类型A是属性，类型O是对象类
[LDAP] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002.
[LDAP]Hodges，J.和R.Morgan，“轻量级目录访问协议（v3）：技术规范”，RFC3372002年9月。
[32KADPCM] Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM) MIME Sub-type Registration", RFC 3802, June 2004.
[32KADPCM]Vaudreuil，G.和G.Parsons，“收费质量语音-32 kbit/s自适应差分脉冲编码调制（ADPCM）MIME子类型注册”，RFC 3802，2004年6月。
[CONTEXT] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.
[背景]Burger，E.，Candell，E.，Eliot，C.，和G.Klyne，“互联网邮件的信息背景”，RFC 3458，2003年1月。
[E164] CCITT Recommendation E.164 (1991), Telephone Network and ISDN Operation, Numbering, Routing and Mobile Service - Numbering Plan for the ISDN Era.
[E164]CCITT建议E.164（1991），电话网络和ISDN操作，编号，路由和移动服务-ISDN时代的编号计划。
[VPIMV2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIMV2]Vaudreuil，G.和G.Parsons，“互联网邮件语音配置文件-第2版（VPIMV2）”，RFC 38012004年6月。
[LDAPREG] Zeilenga, K., "Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)", BCP 64, RFC 3383, September 2002.
[LDAPREG]Zeilenga，K.，“轻量级目录访问协议（LDAP）的互联网分配号码管理局（IANA）注意事项”，BCP 64，RFC 3383，2002年9月。
[LDAPAUTH] Wahl, M., Alvestrand, H., Hodges, J., and R. Morgan, "Authentication Methods for LDAP", RFC 2829, May 2000.
[LDAPAUTH]Wahl，M.，Alvestrand，H.，Hodges，J.，和R.Morgan，“LDAP的身份验证方法”，RFC 28292000年5月。
[LDAPMODELS] Zeilenga, K., "LDAP: Directory Information Models" Work in Progress, February 2005.
[LDAPMODELS]Zeilenga，K.，“LDAP:目录信息模型”正在进行中，2005年2月。
Acknowledgements
致谢
This directory schema builds upon the earlier work of Carl Malamud and Marshall Rose in their TPC.INT remote printing experiment and the work lead by Anne Brown as part of the EMA voice messaging committee's directory effort. Anne Brown has provided important leadership and was a co-author of the original version of this document.
此目录模式基于Carl Malamud和Marshall Rose在其TPC.INT远程打印实验中的早期工作以及Anne Brown领导的工作，作为EMA语音消息委员会目录工作的一部分。安妮·布朗（Anne Brown）发挥了重要的领导作用，是本文件原始版本的共同作者。
Bernhard Elliot, working with the TMIA, has provided most of the organizational impetus to get this project moving, which was a substantial task given the sometimes slow and bureaucratic nature of the voice mail industry and regulatory environment.
Bernhard Elliot与TMIA合作，提供了推动该项目进展的大部分组织动力，鉴于语音邮件行业和监管环境有时缓慢且官僚，这是一项重大任务。
Thanks to Dave Dudley and the Messaging Alliance (TMA) for their early work in pioneering a shared directory service for voice messaging and their continuing efforts to apply that work to this effort.
感谢Dave Dudley和消息传递联盟（TMA）在开创语音消息传递共享目录服务方面的早期工作，以及他们将这项工作应用于这项工作的持续努力。
Greg White and Jeff Bouis, both of Lucent Technologies, provided invaluable assistance in reviewing and sanity checking. Countless errors and inconsistencies were corrected with their diligent review.
朗讯科技公司的格雷格·怀特（Greg White）和杰夫·布伊斯（Jeff Bouis）在审查和健全性检查方面提供了宝贵的帮助。无数的错误和不一致通过他们的认真审查得到纠正。
As chairman of the VPIM working group, Glenn Parsons has provided essential support over the many years this document has been in development.
作为VPIM工作组主席，Glenn Parsons多年来一直为本文件的编制提供重要支持。
Author's Address
作者地址
Please send comments on this document to the VPIM working group mailing list <vpim@ietf.org>.
请将对本文件的意见发送至VPIM工作组邮件列表<vpim@ietf.org>.
Gregory M. Vaudreuil Lucent Technologies 9489 Bartgis Ct Frederick, MD 21702
格雷戈里·沃德鲁伊·朗讯科技9489马里兰州弗雷德里克巴特吉斯Ct 21702
EMail: GregV@ieee.org
EMail: GregV@ieee.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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 procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见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编辑功能的资金目前由互联网协会提供。