Network Working Group E. Candell
Request for Comments: 3773 Comverse
Category: Informational June 2004
Network Working Group E. Candell
Request for Comments: 3773 Comverse
Category: Informational June 2004
High-Level Requirements for Internet Voice Mail
对Internet语音邮件的高级别要求
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
摘要
This document describes the high-level requirements for Internet Voice Mail (IVM) and establishes a baseline of desired functionality against which proposed MIME profiles for Internet Voice Messaging can be judged. IVM is an extension of the Voice Profile for Internet Mail (VPIM) version 2 designed to support interoperability with desktop clients. Other goals for this version of VPIM include expanded interoperability with unified messaging systems, conformance to Internet standards, and backward compatibility with voice messaging systems currently running in a VPIM enabled environment. This document does not include goals that were met fully by VPIM version 2.
本文档描述了互联网语音邮件（IVM）的高级要求，并建立了所需功能的基线，据此可以判断互联网语音消息的拟议MIME配置文件。IVM是Internet邮件语音配置文件（VPIM）第2版的扩展，旨在支持与桌面客户端的互操作性。此版本VPIM的其他目标包括扩展与统一消息系统的互操作性、符合Internet标准以及与当前在支持VPIM的环境中运行的语音消息系统的向后兼容性。本文档不包括VPIM版本2完全实现的目标。
Until recently, voice mail and call answering services were implemented as stand-alone proprietary systems. Today, standards such as the Voice Profile for Internet Mail (VPIM) enable interoperability between such systems over the Internet. VPIM version 1 [VPIM1] was experimental and was a first attempt at a Voice Profile for Internet Mail, but is now classified as Historical. VPIM Version 2 [VPIM2] is an improvement on VPIM version 1 that was originally intended to provide interoperability between voice messaging systems only. It describes a messaging profile that standardizes the exchange of voice mail over an IP messaging network using SMTP [DRUMSMTP] and MIME [MIME1].
直到最近，语音邮件和电话应答服务还作为独立的专有系统实施。如今，互联网邮件语音配置文件（VPIM）等标准实现了互联网上此类系统之间的互操作性。VPIM版本1[VPIM1]是实验性的，是第一次尝试互联网邮件语音配置文件，但现在被归类为历史。VPIM版本2[VPIM2]是对VPIM版本1的改进，该版本最初仅用于提供语音消息系统之间的互操作性。它描述了一个消息传递配置文件，该配置文件使用SMTP[DrumMSTP]和MIME[MIME1]标准化IP消息传递网络上的语音邮件交换。
Because the number of desktop boxes is growing rapidly and will soon approach the number of desktop telephones, it is essential to consider the requirements of desktop email client applications
因为桌面盒的数量正在迅速增长，并且即将接近桌面电话的数量，所以必须考虑桌面电子邮件客户端应用程序的要求。
(including, but not limited to, MIME-compliant email clients). With the trend toward integration of voice mail and email through unified messaging (UM), it is now necessary to define a profile that supports the needs of desktop applications and unified messaging systems (including Internet Facsimile [EXFAX]). This profile is being referred to as Internet Voice Mail (IVM).
（包括但不限于MIME兼容的电子邮件客户端）。随着通过统一消息（UM）集成语音邮件和电子邮件的趋势，现在有必要定义一个支持桌面应用程序和统一消息系统（包括Internet传真[EXFAX]）需求的配置文件。此配置文件被称为Internet语音邮件（IVM）。
This document defines the goals for Internet Voice Mail. This standard will support the interchange of voice messages between voice mail systems, unified messaging systems, email servers, and desktop client applications. The desktop client application is of particular and important interest to IVM. This document will also expand the offerings of service providers by facilitating access to voice mail from a web client.
本文档定义了Internet语音邮件的目标。该标准将支持语音邮件系统、统一消息系统、电子邮件服务器和桌面客户端应用程序之间的语音消息交换。桌面客户端应用程序对IVM特别重要。本文档还将通过促进从web客户端访问语音邮件来扩展服务提供商的服务。
The following terms have specific meaning in this document:
以下术语在本文件中具有特定含义：
"service" An operational service offered by a service provider "application" A use of systems to perform a particular function "terminal" The endpoint of a communication application "goal" An objective of the standardization process
“服务”服务提供商提供的操作服务“应用”使用系统执行特定功能“终端”通信应用程序的端点“目标”标准化过程的目标
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
Enhanced interoperability is the primary goal of IVM. The profile MUST facilitate interoperability between voice mail systems, unified messaging systems, Internet email servers, and desktop client applications. Such interoperability MUST support systems which combine multiple media types in a single message, as well as legacy voice mail and email systems. It MUST allow the ability to accommodate varying capabilities of the voice mail, unified messaging, and email systems. Furthermore, IVM MUST be compatible with Internet Fax (extended mode) proposed standards and VPIM messages that contain fax body parts.
增强互操作性是IVM的主要目标。该配置文件必须促进语音邮件系统、统一消息系统、Internet电子邮件服务器和桌面客户端应用程序之间的互操作性。这种互操作性必须支持在一条消息中结合多种媒体类型的系统，以及传统的语音邮件和电子邮件系统。它必须能够适应语音邮件、统一消息和电子邮件系统的不同功能。此外，IVM必须与互联网传真（扩展模式）拟议标准和包含传真正文部分的VPIM消息兼容。
To have "interoperability" means that an IVM compliant sender attempting to send to a recipient will not fail because of incompatibility. IVM MUST support interoperability amongst the systems listed below:
具有“互操作性”意味着符合IVM的发送方尝试发送给接收方时不会因为不兼容而失败。IVM必须支持下列系统之间的互操作性：
- Desktop Email client applications - IVM-capable Voice Mail systems - IVM-capable unified messaging systems - Traditional email servers
- 桌面电子邮件客户端应用程序-支持IVM的语音邮件系统-支持IVM的统一消息系统-传统电子邮件服务器
IVM SHOULD also support interoperability with VPIM version 2 Voice Mail Systems.
IVM还应支持与VPIM版本2语音邮件系统的互操作性。
IVM MUST include new functionality to facilitate access to voice mail messages from desktop applications.
IVM必须包括新的功能，以方便从桌面应用程序访问语音邮件消息。
Overall interoperability requires interoperability for all message elements: body parts deemed essential for message validity MUST be preserved, essential information MUST be provided in a form that is accessible by the users, status codes [CODES] MUST be understood, and operations that are standard for each system SHOULD be supported.
总体互操作性要求所有消息元素具有互操作性：必须保留对消息有效性至关重要的正文部分，必须以用户可访问的形式提供基本信息，必须理解状态代码[代码]，并且应支持每个系统的标准操作。
Desktop email applications are typically text based. The abilities to listen to, reply to, forward, and generate voice mail messages from a traditional desktop environment are relatively new developments. To accommodate current use and future developments in this area, IVM MUST provide features to support access to voice mail messages from the desktop and other email-reading devices. Also, web access to voicemail SHOULD be supported from the desktop.
桌面电子邮件应用程序通常基于文本。从传统桌面环境中收听、回复、转发和生成语音邮件消息的能力是相对较新的发展。为了适应这一领域的当前使用和未来发展，IVM必须提供支持从桌面和其他电子邮件阅读设备访问语音邮件的功能。此外，还应支持从桌面访问语音邮件。
IVM SHOULD NOT require desktop email applications to possess a large amount of processing power, and a base level implementation MUST interoperate, even if it does not offer complex processing. In order to support interoperability, at least one mandatory codec MUST be defined. The mandatory codec(s) SHOULD be widely available on desktops. For interoperability with VPIM version 2 systems, IVM applications MAY also support the VPIM v2 mandatory codec, 32KADPCM [ADPCM and G726-32].
IVM不应该要求桌面电子邮件应用程序拥有大量的处理能力，并且即使它不提供复杂的处理，基本级别的实现也必须具有互操作性。为了支持互操作性，必须至少定义一个必需的编解码器。桌面上应广泛提供强制性编解码器。为了与VPIM版本2系统的互操作性，IVM应用程序还可以支持VPIM v2强制编解码器32KADPCM[ADPCM和G726-32]。
Any codecs included in the IVM specification SHOULD meet the following criteria:
IVM规范中包含的任何编解码器应满足以下标准：
- Availability on desktops: Codecs SHOULD be available on most platforms.
- 桌面上的可用性：编解码器应该在大多数平台上可用。
- Source code availability: Source code SHOULD be readily accessible.
- 源代码可用性：源代码应该易于访问。
- Decoding complexity: All codecs MUST be low complexity to decode.
- 解码复杂度：所有编解码器必须是低复杂度才能解码。
- Encoding complexity: Some of the codecs MUST be low complexity to encode.
- 编码复杂度：某些编解码器必须具有较低的编码复杂度。
- Bit rate: IVM SHOULD specify a codec with low bit rate for devices (i.e., wireless) that do not have much space/bandwidth.
- 比特率：IVM应该为没有太多空间/带宽的设备（如无线设备）指定低比特率的编解码器。
- Voice Over IP support: IVM SHOULD specify a codec that supports Voice over IP implementations.
- IP语音支持：IVM应指定支持IP语音实现的编解码器。
Voice Content MUST always be contained in an audio/basic content-type unless the originator is aware that the recipient can handle other content. To enable future support of other formats, IVM SHOULD provide identification of the codec used without requiring interpretation of an audio format. IVM MAY allow audio encodings and formats that are not identified in the IVM specification to support environments in which the sender is aware of the optimal encoding and format for the recipient.
语音内容必须始终包含在音频/基本内容类型中，除非发端人知道收件人可以处理其他内容。为了将来支持其他格式，IVM应提供所用编解码器的标识，而无需解释音频格式。IVM可允许IVM规范中未识别的音频编码和格式支持发送方知道接收方最佳编码和格式的环境。
To address performance and bandwidth issues, IVM MAY support streaming of IVM audio to the desktop. IVM MAY explicitly support formats other than raw audio to facilitate streaming.
为了解决性能和带宽问题，IVM可能支持将IVM音频流传输到桌面。IVM可能明确支持原始音频以外的格式，以促进流媒体传输。
Because most email readers are text/html based and because many devices are not capable of recording audio content, IVM MUST allow inclusion of text body parts in a voice message. IVM SHOULD NOT explicitly prohibit other media types as long as critical content is identified and minimal discard rules are specified.
由于大多数电子邮件阅读器都是基于文本/html的，而且许多设备无法录制音频内容，因此IVM必须允许在语音消息中包含文本正文部分。IVM不应明确禁止其他媒体类型，只要确定了关键内容并指定了最小的丢弃规则。
To support devices that have applications dedicated to specific media types or that are not capable of handling specific content, IVM SHOULD define a way to describe the content of the message, indicating how the content can be accessed.
为了支持具有专用于特定媒体类型的应用程序或无法处理特定内容的设备，IVM应定义一种描述消息内容的方法，指示如何访问内容。
Desktop implementation of IVM MUST support attachments of any media type.
IVM的桌面实现必须支持任何媒体类型的附件。
Voice messaging systems are generally implemented as special-purpose machines that interface to a telephone switch and provide call answering and voice messaging services. VPIM version 2 was designed to support interoperability between such systems and remains the best messaging profile for this purpose.
语音信息系统通常作为专用机器实现，与电话交换机连接，并提供电话应答和语音信息服务。VPIM版本2旨在支持此类系统之间的互操作性，并且仍然是用于此目的的最佳消息传递配置文件。
To support interoperability between IVM voice messaging systems and other compliant systems, IVM SHOULD have a minimum set of required features that will guarantee interoperability, and also provision for additional functionality that may be supported by more complex systems. IVM MUST define a mechanism for identifying essential content and status codes [CODES] indicating that a message could not be delivered due to capability differences.
为了支持IVM语音消息系统和其他兼容系统之间的互操作性，IVM应具有一组最低限度的必需功能，以保证互操作性，并提供可能由更复杂系统支持的附加功能。IVM必须定义一种机制，用于识别基本内容和状态代码[代码]，表明由于能力差异而无法传递消息。
NOTE: IVM SHOULD provide some level of interoperability with VPIM version 2 voice messaging systems. In order to support minimal interoperability between IVM and VPIM version 2, IVM systems MAY be able to receive the VPIM version 2 32KADPCM codec [ADPCM and G726- 32], and MUST gracefully handle the case where a legacy receiving system does not support the IVM codecs.
注意：IVM应提供与VPIM版本2语音消息系统的某种程度的互操作性。为了支持IVM和VPIM版本2之间的最小互操作性，IVM系统可能能够接收VPIM版本2 32KADPCM编解码器[ADPCM和G726-32]，并且必须优雅地处理传统接收系统不支持IVM编解码器的情况。
Unified messaging solutions typically leverage common store, directory, and transport layers to provide greater interoperability and accessibility to a variety of media content. They support creation of and access to voicemail, email, and fax messages from a single user interface.
统一消息解决方案通常利用公共存储层、目录层和传输层，为各种媒体内容提供更好的互操作性和可访问性。它们支持从单个用户界面创建和访问语音邮件、电子邮件和传真消息。
To accommodate the common functionality of unified messaging systems, IVM MUST support the inclusion of body parts containing different media types. It MUST also handle messages that contain VPIM messages as attachments to messages of another type (such as multipart/mixed), and VPIM messages that contain attachments of another type.
为了适应统一消息系统的通用功能，IVM必须支持包含不同媒体类型的身体部位。它还必须将包含VPIM消息的消息作为另一类型（如多部分/混合）消息的附件，以及包含另一类型附件的VPIM消息进行处理。
To provide interoperability with systems that cannot handle a particular content type, IVM MUST provide a mechanism for identifying critical content and MAY define media specific status codes and strings to handle non-delivery of these body parts.
为了提供与无法处理特定内容类型的系统的互操作性，IVM必须提供一种识别关键内容的机制，并且可以定义媒体特定的状态代码和字符串来处理这些身体部位的未交付。
Traditional email servers are those that support only textual media as inline content. IVM MUST interoperate consistently with the current Internet mail environment. If an IVM message arrives in users' mailboxes, IVM MUST provide a mechanism to interoperate with common user practices for mail messages: storing them in databases, retransmission, forwarding, creation of mail digests, and replying to messages using non-audio equipment.
传统的电子邮件服务器只支持文本媒体作为内联内容。IVM必须与当前的Internet邮件环境保持一致的互操作。如果IVM消息到达用户邮箱，IVM必须提供一种机制，以便与邮件消息的常见用户实践进行互操作：将它们存储在数据库中，重新传输、转发、创建邮件摘要，以及使用非音频设备回复消息。
It is the goal of IVM to conform as closely as possible to existing standards while meeting the other goals defined in this document.
IVM的目标是尽可能符合现有标准，同时满足本文件中定义的其他目标。
- Restrictions: The profile SHOULD impose as few restrictions as possible to existing Internet mail standards. In particular, it MUST support all elements of RFC 2822 [DRUMSIMF], except those that prevent the profile from meeting other IVM goals.
- 限制：配置文件应尽可能少地对现有的Internet邮件标准施加限制。特别是，它必须支持RFC2822[DRUMSIMF]的所有元素，除了那些阻止概要文件满足其他IVM目标的元素。
- Additions: The profile SHOULD make as few additions as possible to existing internet mail standards. It SHOULD adhere to existing desktop conventions in desktop-related areas such as file extensions. If it is necessary to define new MIME types or sub-types, the IVM work group SHOULD propose terms that are already standard or in common use in the desktop environment.
- 附加：配置文件应尽可能少地增加现有的internet邮件标准。在与桌面相关的领域，如文件扩展名，它应该遵守现有的桌面约定。如果需要定义新的MIME类型或子类型，IVM工作组应该提出已经是标准的或在桌面环境中常用的术语。
This profile SHOULD provide backward compatibility with VPIM version 2 to the extent that the functionality required to meet the goals of this profile is not compromised. Where backward compatibility is not possible, IVM SHOULD provide and define a minimal set of rules and status codes for handling non-delivery of IVM messages resulting from interoperability with VPIM version 2 systems and other legacy systems.
此配置文件应提供与VPIM版本2的向后兼容性，以确保满足此配置文件目标所需的功能不受损害。在不可能向后兼容的情况下，IVM应提供并定义一组最小的规则和状态代码，用于处理由于与VPIM版本2系统和其他遗留系统的互操作性而导致的IVM消息未送达。
IVM MUST be usable in an environment in which there exist legacy gateways that do not understand MIME. Core features and critical data MUST not be lost when messages pass through AMIS gateways [AMIS-A and AMIS-D]. IVM SHOULD allow interoperability with recipient devices and gateways that have limited buffering capabilities and cannot buffer all header information.
IVM必须在存在不理解MIME的遗留网关的环境中可用。当消息通过AMIS网关[AMIS-A和AMIS-D]时，不得丢失核心功能和关键数据。IVM应允许与缓冲能力有限且无法缓冲所有标头信息的接收方设备和网关进行互操作。
To facilitate security, IVM MUST support authenticated and/or encrypted voice messages. In addition, IVM MUST adhere to the security issues identified in VPIM v2 [VPIM2] and in the other RFCs referenced by this document, especially SMTP [DRUMSMTP], Internet Message Format [DRUMSIMF], and MIME [MIME1].
为了提高安全性，IVM必须支持经过身份验证和/或加密的语音消息。此外，IVM必须遵守VPIM v2[VPIM2]和本文档引用的其他RFC中确定的安全问题，特别是SMTP[DRUMSMTP]、互联网消息格式[DRUMSIMF]和MIME[MIME1]。
[ADPCM] Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32 kbit/s ADPCM: MIME Sub-type Registration", RFC 2422, September 1998.
[ADPCM]Vaudreuil，G.和G.Parsons，“收费质量语音-32 kbit/s ADPCM:MIME子类型注册”，RFC2421998年9月。
[AMIS-A] Audio Messaging Interchange Specifications (AMIS) - Analog Protocol Version 1, Issue 2, February 1992.
[AMIS-A]音频消息交换规范（AMIS）-模拟协议第1版，第2期，1992年2月。
[AMIS-D] Audio Messaging Interchange Specifications (AMIS) - Digital Protocol Version 1, Issue 3 August 1993.
[AMIS-D]音频消息交换规范（AMIS）-数字协议第1版，1993年8月3日发行。
[CODES] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 3463, January 2003.
[CODES]Vaudreuil，G.“增强邮件系统状态代码”，RFC 3463，2003年1月。
[DRUMSMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[Drusmtp]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[DRUMSIMF] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[DRUMSIMF]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[EXFAX] Masinter, L. and D. Wing, "Extended Facsimile Using Internet Mail", RFC 2532, March 1999.
[EXFAX]Masinter，L.和D.Wing，“使用互联网邮件的扩展传真”，RFC 25321999年3月。
[G726-32] CCITT Recommendation G.726 (1990), General Aspects of Digital Transmission Systems, Terminal Equipment - 40, 32,24,16 kbit/s Adaptive Differential Pulse Code Modulation (ADPCM).
[G726-32]CCITT建议G.726（1990），数字传输系统的一般方面，终端设备-40,32,24,16 kbit/s自适应差分脉冲编码调制（ADPCM）。
[MIME1] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME1]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[VPIM2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail, Version 2", RFC 2421, September 1998.
[VPIM2]Vaudreuil，G.和G.Parsons，“互联网邮件语音配置文件，第2版”，RFC 24211998年9月。
[VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 1911, February 1996.
[VPIM1]Vaudreuil，Greg，“互联网邮件语音档案”，RFC 19111996年2月。
[VPIM3] Silvestro, L. and R. Miles, "Goals for Voice Profile for Internet Mail, Version 3", Work in Progress, March 2000.
[VPIM3]Silvestro，L.和R.Miles，“互联网邮件语音档案的目标，第3版”，正在进行的工作，2000年3月。
This document is the final result of an evolving requirements document that started with VPIM v3 and evolved into an alternative specification for a different (i.e., end-to-end instead of server-to-server) application. The basis for this document was written by Laile Di Silvestro and Rod Miles [VPIM3].
本文档是一个不断发展的需求文档的最终结果，该文档从VPIM v3开始，并发展为不同（即，端到端而不是服务器到服务器）应用程序的替代规范。本文件的基础由Laile Di Silvestro和Rod Miles[VPIM3]编写。
The author gratefully acknowledges the authors of [VPIM3], and the input and feedback provided by the members of the EMA and IETF VPIM work groups.
作者衷心感谢[VPIM3]的作者，以及EMA和IETF VPIM工作组成员提供的意见和反馈。
Emily Candell Comverse 200 Quannapowitt Parkway Wakefield, MA 01803 Phone: +1-781-213-2324 EMail: emily.candell@comverse.com
Emily Candell Comverse 200 Quannapowitt Parkway Wakefield，马萨诸塞州01803电话：+1-781-213-2324电子邮件：Emily。candell@comverse.com
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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编辑功能的资金目前由互联网协会提供。