Network Working Group G. Vaudreuil
Request for Comments: 3801 Lucent Technologies
Obsoletes: 2421 G. Parsons
Category: Standards Track Nortel Networks
June 2004
Network Working Group G. Vaudreuil
Request for Comments: 3801 Lucent Technologies
Obsoletes: 2421 G. Parsons
Category: Standards Track Nortel Networks
June 2004
Voice Profile for Internet Mail - version 2 (VPIMv2)
Internet邮件语音配置文件-第2版（VPIMv2）
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. The profile is referred to as the Voice Profile for Internet Mail (VPIM) in this document. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems.
本文档规定了在语音处理服务器平台之间使用的Internet多媒体消息协议的受限配置文件。此配置文件在本文档中称为Internet邮件语音配置文件（VPIM）。这些平台在历史上一直是专用计算机，通常没有与传统的支持Internet电子邮件的计算机相关的相同设施。因此，VPIM还根据需要指定其他功能。该配置文件旨在规定允许一致性系统之间互通的最小通用特征集。
This document obsoletes RFC 2421 and describes version 2 of the profile with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in Appendix F. Appendix A summarizes the protocol profiles of this version of VPIM.
本文件淘汰了RFC 2421，并更精确地描述了配置文件的第2版。本次修订未对方案进行任何更改。RFC 2421的变更列表见附录F。附录A总结了该版本VPIM的协议概要。
Table of Contents
目录
1. Introduction...................................................3
1.1. Voice Messaging System Limitations.......................3
1.2. Design Goals.............................................4
1.3. Applicability for VPIM...................................5
2. Requirements Language..........................................5
3. Protocol Restrictions..........................................6
4. Voice Message Interchange Format...............................6
4.1. VPIM Message Addressing Formats..........................7
4.2. Message Header Fields....................................9
4.3. MIME Audio Content Descriptions.........................17
4.4. Voice Message Content Types.............................19
4.5. Other MIME Contents.....................................23
4.6. Delivery Status Notification (DSN)......................25
4.7. Message Disposition Notification (MDN)..................26
4.8. Forwarded Messages......................................26
4.9. Reply Messages..........................................27
5. Message Transport Protocol....................................27
5.1. Base SMTP Protocol......................................28
5.2. SMTP Service Extensions.................................28
5.3. ESMTP - SMTP Downgrading................................30
6. Directory Address Resolution..................................30
7. Management Protocols..........................................30
7.1. Network Management......................................31
8. Conformance Requirements......................................31
9. Security Considerations.......................................32
9.1. General Directive.......................................32
9.2. Threats and Problems....................................32
9.3. Security Techniques.....................................33
10. Normative References..........................................33
11. Acknowledgments...............................................36
12. Appendix A - VPIM Requirements Summary........................37
13. Appendix B - Example Voice Messages...........................43
14. Appendix C - Example Error Voice Processing Error Codes.......49
15. Appendix D - Example Voice Processing Disposition Types.......50
16. Appendix E - IANA Registrations...............................50
16.1. Voice Content-Disposition Parameter Definition.........51
16.2. Multipart/Voice-Message MIME Media Type Definition.....51
17. Appendix F - Change History: RFC 2421 (VPIM V2) To This Doc...53
18. Authors' Addresses............................................54
19. Full Copyright Statement......................................55
1. Introduction...................................................3
1.1. Voice Messaging System Limitations.......................3
1.2. Design Goals.............................................4
1.3. Applicability for VPIM...................................5
2. Requirements Language..........................................5
3. Protocol Restrictions..........................................6
4. Voice Message Interchange Format...............................6
4.1. VPIM Message Addressing Formats..........................7
4.2. Message Header Fields....................................9
4.3. MIME Audio Content Descriptions.........................17
4.4. Voice Message Content Types.............................19
4.5. Other MIME Contents.....................................23
4.6. Delivery Status Notification (DSN)......................25
4.7. Message Disposition Notification (MDN)..................26
4.8. Forwarded Messages......................................26
4.9. Reply Messages..........................................27
5. Message Transport Protocol....................................27
5.1. Base SMTP Protocol......................................28
5.2. SMTP Service Extensions.................................28
5.3. ESMTP - SMTP Downgrading................................30
6. Directory Address Resolution..................................30
7. Management Protocols..........................................30
7.1. Network Management......................................31
8. Conformance Requirements......................................31
9. Security Considerations.......................................32
9.1. General Directive.......................................32
9.2. Threats and Problems....................................32
9.3. Security Techniques.....................................33
10. Normative References..........................................33
11. Acknowledgments...............................................36
12. Appendix A - VPIM Requirements Summary........................37
13. Appendix B - Example Voice Messages...........................43
14. Appendix C - Example Error Voice Processing Error Codes.......49
15. Appendix D - Example Voice Processing Disposition Types.......50
16. Appendix E - IANA Registrations...............................50
16.1. Voice Content-Disposition Parameter Definition.........51
16.2. Multipart/Voice-Message MIME Media Type Definition.....51
17. Appendix F - Change History: RFC 2421 (VPIM V2) To This Doc...53
18. Authors' Addresses............................................54
19. Full Copyright Statement......................................55
MIME is the Internet multipurpose, multimedia-messaging standard. This document explicitly recognizes its capabilities and provides a mechanism for the exchange of various messaging technologies, primarily voice and facsimile.
MIME是Internet多用途的多媒体消息标准。本文件明确承认了其功能，并为各种消息传递技术（主要是语音和传真）的交换提供了一种机制。
Voice messaging evolved as telephone answering service into a full send, receive, and forward messaging paradigm with unique message features, semantics and usage patterns. Voice messaging was introduced on special purpose computers that interface to a telephone switch and provide call answering and voice messaging services. Traditionally, messages sent from one voice messaging system to another were transported using analog networking protocols based on DTMF signaling and analog voice playback. As the demand for networking increases, there was a need for a standard high-quality digital protocol to connect these machines. VPIM has successfully demonstrated its usefulness as this new standard. VPIM is widely implemented and is seeing deployment in customer networks. This document clarifies ambiguities found in the earlier specification and is consistent with implementation practice. The profile is referred to as Voice Profile for Internet Mail (VPIM) in this document.
语音消息作为电话应答服务发展成为一种完整的发送、接收和转发消息模式，具有独特的消息功能、语义和使用模式。语音信息是在特殊用途的计算机上引入的，这些计算机与电话交换机连接，提供电话应答和语音信息服务。传统上，从一个语音消息系统发送到另一个语音消息系统的消息是使用基于DTMF信令和模拟语音回放的模拟网络协议传输的。随着网络需求的增加，需要一个标准的高质量数字协议来连接这些机器。VPIM已经成功地证明了它作为这一新标准的实用性。VPIM被广泛实施，并在客户网络中部署。本文件澄清了早期规范中存在的歧义，并与实施实践保持一致。此配置文件在本文档中称为Internet邮件语音配置文件（VPIM）。
This document specifies a restricted profile of the Internet multimedia messaging protocols for use between voice processing server platforms. These platforms have historically been special-purpose computers and often do not have the same facilities normally associated with a traditional Internet Email-capable computer. As a result, VPIM also specifies additional functionality, as it is needed. This profile is intended to specify the minimum common set of features to allow interworking between conforming systems.
本文档规定了在语音处理服务器平台之间使用的Internet多媒体消息协议的受限配置文件。这些平台在历史上一直是专用计算机，通常没有与传统的支持Internet电子邮件的计算机相关的相同设施。因此，VPIM还根据需要指定其他功能。该配置文件旨在规定允许一致性系统之间互通的最小通用特征集。
This document obsoletes RFC 2421 and describes VPIM version 2 of with greater precision. No protocol changes were made in this revision. A list of changes from RFC 2421 are noted in Appendix F. Appendix A summarizes the protocol profiles of this version of VPIM.
本文档淘汰了RFC 2421，并更精确地描述了的VPIM版本2。本次修订未对方案进行任何更改。RFC 2421的变更列表见附录F。附录A总结了该版本VPIM的协议概要。
The following are typical limitations of voice messaging platforms that were considered in creating this baseline profile.
以下是创建此基线配置文件时考虑的语音消息平台的典型限制。
1) Text messages are not normally received and often cannot be easily displayed or viewed. They can often be processed only via text-to-speech or text-to-fax features not currently present in many of these machines.
1) 文本消息通常不会被接收，并且通常无法轻松显示或查看。它们通常只能通过文本到语音或文本到传真功能进行处理，而这些功能目前在这些机器中并不存在。
2) Voice mail machines usually act as an integrated Message Transfer Agent, Message Store and User Agent. There is typically no relaying of messages. RFC822 header fields may have limited use in the context of the limited messaging features currently deployed.
2) 语音邮件机通常充当集成的消息传输代理、消息存储和用户代理。通常没有消息中继。RFC822头字段在当前部署的有限消息功能上下文中的使用可能有限。
3) Voice mail message stores are generally not capable of preserving the full semantics of an Internet message. As such, use of a voice mail machine for gatewaying is not supported. In particular, storage of recipient lists, "Received:" lines, and "Message-ID:" may be limited.
3) 语音邮件消息存储通常无法保留Internet消息的完整语义。因此，不支持使用语音邮件机进行网关连接。特别是，收件人列表“已接收：”行和“消息ID:”的存储可能会受到限制。
4) Internet-style distribution/exploder mailing lists are not typically supported. Voice mail machines often implement only local alias lists, with error-to-sender and reply-to-sender behavior. Reply-all capabilities using a Cc list are not generally available.
4) 通常不支持Internet样式的分发/爆炸邮件列表。语音邮件机器通常只实现本地别名列表，并具有错误发送和回复发送行为。使用Cc列表回复所有功能通常不可用。
5) Error reports must be machine-parsable so that helpful responses can be voiced to users whose only access mechanism is a telephone.
5) 错误报告必须是机器可解析的，以便能够向只有电话访问机制的用户发出有用的响应。
6) The voice mail systems generally limit address entry to 16 or fewer numeric characters, and normally do not support alphanumeric mailbox names. Alpha characters are not generally used for mailbox identification, as they cannot be easily entered from a telephone terminal.
6) 语音邮件系统通常将地址输入限制为16个或更少的数字字符，并且通常不支持字母数字邮箱名称。字母字符通常不用于邮箱识别，因为它们无法从电话终端轻松输入。
It should be noted that newer systems are based natively on SMTP/MIME and do not suffer these limitations. In particular, some systems may support media other than voice and fax.
应该注意的是，较新的系统本机基于SMTP/MIME，不受这些限制。特别是，某些系统可能支持语音和传真以外的媒体。
It is a goal of this profile to make as few restrictions and additions to the existing Internet mail protocols as possible while satisfying the requirements for interoperability with current generation voice messaging systems. This goal is motivated by the desire to increase the accessibility to digital messaging by enabling the use of proven existing networking software for rapid development.
本概要文件的目标是尽可能减少对现有Internet邮件协议的限制和添加，同时满足与当前一代语音消息系统的互操作性要求。这一目标的动机是希望通过使用经过验证的现有网络软件进行快速开发，从而提高数字信息的可访问性。
This specification is intended for use on a TCP/IP network; however, it is possible to use the SMTP protocol suite over other transport protocols. The necessary protocol parameters for such use are outside the scope of this document.
本规范适用于TCP/IP网络；但是，可以在其他传输协议上使用SMTP协议套件。此类使用的必要协议参数不在本文件范围内。
This profile is intended to be robust enough to be used in an environment, such as the global Internet, with installed-base gateways that do not understand MIME. Full functionality, such as reliable error messages and binary transport, will require careful selection of gateways (e.g., via MX records) to be used as VPIM forwarding agents. Nothing in this document precludes use of general-purpose MIME email packages to read and compose VPIM messages. While no special configuration is required to receive VPIM conforming messages, some may be required to originate conforming structures.
此配置文件旨在足够健壮，以便在安装了不理解MIME的基本网关的环境（如全球互联网）中使用。完整的功能，如可靠的错误消息和二进制传输，需要仔细选择用作VPIM转发代理的网关（例如，通过MX记录）。本文档中的任何内容都不排除使用通用MIME电子邮件包来读取和撰写VPIM消息。虽然接收符合VPIM的消息不需要特殊配置，但可能需要一些配置来创建符合VPIM的结构。
It is expected that a system administrator who can perform TCP/IP network configuration will manage a VPIM messaging system. When using facsimile or multiple voice encodings, it is suggested that the system administrator maintain a list of the capabilities of the networked mail machines to reduce the sending of undeliverable messages due to lack of feature support. Configuration, implementation and management of these directory-listing capabilities are local matters.
可以执行TCP/IP网络配置的系统管理员将管理VPIM消息传递系统。当使用传真或多种语音编码时，建议系统管理员维护联网邮件机的功能列表，以减少由于缺乏功能支持而无法发送的邮件。这些目录列表功能的配置、实现和管理是本地事务。
VPIM is intended for the exchange of voice messages between traditional voice messaging systems and for systems that need to interoperate with such systems. VPIM is intended connect voice-messaging systems into special-purpose voice messaging networks. VPIM may also be used between message store servers and VPIM-aware clients such as web servers, TUI, and GUI clients. VPIM is not intended or optimized for downloading to, or sending from commercial email clients.
VPIM用于在传统语音消息系统之间以及需要与此类系统互操作的系统之间交换语音消息。VPIM旨在将语音信息系统连接到专用语音信息网络。VPIM还可以在消息存储服务器和支持VPIM的客户端（如web服务器、TUI和GUI客户端）之间使用。VPIM不适用于下载或从商业电子邮件客户端发送。
Internet Voice Messaging, the subject of a separate standards initiative, is intended to enable general-purpose email clients to send and receive voice content through general-purpose message stores in an interoperable way. IVM may also be a suitable format for downloading voice messages from a VPIM server to a commercial email client. It may also be a suitable format for submission of a voice message from a general-purpose client into a VPIM system.
Internet语音消息是一项独立标准倡议的主题，旨在使通用电子邮件客户端能够以互操作的方式通过通用消息存储发送和接收语音内容。IVM也可以是将语音消息从VPIM服务器下载到商业电子邮件客户端的合适格式。它也可以是将语音消息从通用客户端提交到VPIM系统的合适格式。
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 [REQ].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[REQ]中的说明进行解释。
This protocol does not limit the number of recipients per message. Where possible, server implementations should not restrict the number of recipients in a single message. It is recognized that no implementation supports unlimited recipients, and that the number of supported recipients may be quite low.
此协议不限制每条邮件的收件人数量。在可能的情况下，服务器实现不应限制单个消息中的收件人数量。人们认识到，没有任何实现支持无限的收件人，而且受支持的收件人数量可能非常少。
This protocol does not limit the maximum message length. Implementers should understand that some machines will be unable to accept excessively long messages. A mechanism is defined in [SIZE] to declare the maximum message size supported.
此协议不限制最大消息长度。实现者应该理解，有些机器将无法接受过长的消息。[SIZE]中定义了一种机制来声明支持的最大消息大小。
The following sections describe the restrictions and additions to Internet mail protocols that are required to be conforming with this VPIM v2 profile. Though various SMTP, ESMTP and MIME features are described here, the implementer is referred to the relevant RFCs for complete details. The table in Appendix A summarizes the protocol details of this profile.
以下各节描述了符合此VPIM v2配置文件所需的互联网邮件协议的限制和补充。虽然这里描述了各种SMTP、ESMTP和MIME特性，但实现者可以参考相关RFC以获得完整的详细信息。附录A中的表格总结了该概要文件的协议细节。
The voice message interchange format is a profile of the Internet Mail Protocol Suite. Any Internet Mail message containing the format defined in this section is referred to as a VPIM Message in this document. As a result, this document assumes an understanding of the Internet Mail specifications. Specifically, VPIM references components from the message format standard for Internet messages [RFC822], the Multipurpose Internet Message Extensions [MIME1-5], the X.400 gateway specification [X.400], and the delivery status and message disposition notifications [REPORT][DSN][DRPT][STATUS][MDN].
语音消息交换格式是Internet邮件协议套件的一种配置文件。任何包含本节定义格式的Internet邮件在本文档中称为VPIM邮件。因此，本文档假定您了解Internet邮件规范。具体而言，VPIM引用了互联网消息的消息格式标准[RFC822]、多用途互联网消息扩展[MIME1-5]、X.400网关规范[X.400]以及传递状态和消息处置通知[REPORT][DSN][DRPT][status][MDN]中的组件。
MIME, introduced in [MIME1], is a general-purpose message body format that is extensible to carry a wide range of body parts. It provides for encoding binary data so that it can be transported over the 7-bit text-oriented SMTP protocol. This transport encoding (denoted by the "Content-Transfer-Encoding:" MIME field) is in addition to the audio encoding required to generate a binary object.
MIME是在[MIME1]中引入的一种通用消息正文格式，可扩展以承载广泛的正文部分。它提供二进制数据编码，以便通过7位面向文本的SMTP协议传输。此传输编码（由“Content Transfer encoding:”MIME字段表示）是生成二进制对象所需音频编码的补充。
MIME defines two transport-encoding mechanisms to transform binary data into a 7-bit representation, one designed for text-like data ("Quoted-Printable"), and one for arbitrary binary data ("Base64"). While Base64 is dramatically more efficient for audio data, either will work. Where binary transport is available, no transport encoding is needed, and the data can be labeled as "Binary".
MIME定义了两种传输编码机制，用于将二进制数据转换为7位表示形式，一种用于类文本数据（“引用的可打印”），另一种用于任意二进制数据（“Base64”）。虽然Base64对音频数据的效率显著提高，但两者都可以。在二进制传输可用的情况下，不需要传输编码，数据可以标记为“二进制”。
VPIM addresses SHALL use the RFC 822 format based on the Domain Name System. This naming system has two components: the local part, used for username or mailbox identification; and the host part, used for global machine identification.
VPIM地址应使用基于域名系统的RFC 822格式。此命名系统有两个组件：本地部分，用于用户名或邮箱标识；主机部分，用于全局机器识别。
The local part of the address shall be a US-ASCII string uniquely identifying a mailbox on a destination system. For voice messaging, the local part SHALL be a printable string containing the mailbox ID of the originator or recipient. While alpha characters and long mailbox identifiers MAY be permitted, short numeric local parts SHOULD be used as most voice mail networks rely on numeric mailbox identifiers to retain compatibility with the limited 10-digit telephone keypad. As a result, some voice messaging systems may only be able to handle a numeric local part. The reception of alphanumeric local parts on these systems may result in the address being mapped to some locally unique (but confusing to the recipient) number or, in the worst case the address could be deleted making the message unreplyable. Additionally, it may be difficult to create messages on these systems with an alphanumeric local part without complex key sequences or some form of directory lookup (see 6). The use of the Domain Name System should be transparent to the user. It is the responsibility of the voice mail machine to lookup the fully-qualified domain name (FQDN) based on the address entered by the user (see 6).
地址的本地部分应为唯一标识目标系统上邮箱的US-ASCII字符串。对于语音信息，本地部分应为可打印字符串，包含发端人或收件人的邮箱ID。虽然允许使用字母字符和长邮箱标识符，但应使用短数字本地部分，因为大多数语音邮件网络依赖数字邮箱标识符来保持与有限的10位电话键盘的兼容性。因此，某些语音消息系统可能只能处理数字本地部分。在这些系统上接收字母数字的本地部分可能会导致地址被映射到某些本地唯一（但收件人会感到困惑）的号码，或者，在最坏的情况下，地址可能会被删除，从而使邮件无法发送。此外，在这些系统上，如果没有复杂的键序列或某种形式的目录查找，可能很难使用字母数字本地部分创建消息（请参见6）。域名系统的使用应当对用户透明。语音邮件机负责根据用户输入的地址查找完全限定的域名（FQDN）（参见6）。
In the absence of a global directory, specification of the local part is expected to conform to international or private telephone numbering plans. It is likely that private numbering plans will prevail and these are left for local definition. However, it is RECOMMENDED that public telephone numbers be noted according to the international numbering plan described in [E.164]. The indication that the local part is a public telephone number is given by a preceding "+" (the "+" would not be entered from a telephone keypad, it is added by the system as a flag). Since the primary information in the numeric scheme is contained by the digits, other character separators (e.g., "-") may be ignored (i.e., to allow parsing of the numeric local mailbox) or may be used to recognize distinct portions of the telephone number (e.g., country code). The specification of the local part of a VPIM address can be split into the four groups described below:
在没有全球目录的情况下，本地部分的规格应符合国际或私人电话编号计划。可能会以私人编号计划为准，这些计划留待当地定义。但是，建议根据[E.164]中所述的国际编号计划注明公共电话号码。本地部分是公共电话号码的指示由前面的“+”给出（“不会从电话键盘输入“+”，它由系统添加为标志）。由于数字方案中的主要信息包含在数字中，因此可以忽略其他字符分隔符（例如“-”），以允许对数字本地邮箱进行解析，或可用于识别电话号码的不同部分（例如，国家代码）。VPIM地址的本地部分的规范可分为以下四组：
1) mailbox number - for use as a private numbering plan (any number of digits) - e.g., 2722@lucent.com
1) 邮箱号码-用作专用编号计划（任意位数）-例如。，2722@lucent.com
2) mailbox number+extension
- for use as a private numbering plan with extensions
any number of digits, use of "+" as separator
- e.g., 2722+111@Lucent.com
2) mailbox number+extension
- for use as a private numbering plan with extensions
any number of digits, use of "+" as separator
- e.g., 2722+111@Lucent.com
3) +international number - for international telephone numbers conforming to E.164 maximum of 15 digits - e.g., +16137637582@vm.nortel.ca
3) +国际号码-适用于符合E.164的国际电话号码，最多15位-例如+16137637582@vm.nortel.ca
4) +international number+extension
- for international telephone numbers conforming to E.164
maximum of 15 digits, with an extension (e.g., behind a
PBX) that has a maximum of 15 digits.
- e.g., +17035245550+230@ema.org
4) +international number+extension
- for international telephone numbers conforming to E.164
maximum of 15 digits, with an extension (e.g., behind a
PBX) that has a maximum of 15 digits.
- e.g., +17035245550+230@ema.org
Note that this address format is designed to be compatible with current usage within the voice messaging industry. It is not compatible with the addressing formats of RFCs 2303-2304. It is expected that as telephony services become more widespread on the Internet, these addressing formats will converge.
请注意，此地址格式旨在与语音信息行业的当前使用情况兼容。它与RFCs 2303-2304的寻址格式不兼容。预计随着电话服务在互联网上越来越普及，这些寻址格式将趋同。
Special addresses to represent the sender are provided for compatibility with the conventions of Internet mail. These addresses do not use numeric local addresses, both to conform to current Internet practice and to avoid conflict with existing numeric addressing plans. Two special addresses are RESERVED for use as follows:
为了与Internet邮件的约定兼容，提供了代表发件人的特殊地址。这些地址不使用数字本地地址，既符合当前的互联网实践，又避免与现有的数字寻址计划冲突。保留两个特殊地址供使用，如下所示：
postmaster@domain
postmaster@domain
By convention, a special mailbox named "postmaster" MUST exist on all systems. This address is used for diagnostics and should be checked regularly by the system manager. This mailbox is particularly likely to receive text messages, which is not normal on a voice-processing platform. The specific handling of these messages is an individual implementation choice.
按照惯例，所有系统上都必须存在一个名为“postmaster”的特殊邮箱。此地址用于诊断，应由系统管理员定期检查。此邮箱特别可能接收文本消息，这在语音处理平台上是不正常的。这些消息的具体处理是一个单独的实现选择。
non-mail-user@domain
非邮件-user@domain
If a reply to a message is not possible, such as a telephone-answering message, then the special address "non-mail-user" SHOULD be used as the originator's address. Any text name such as "Telephone Answering", or the telephone number if it is available, is permitted. This special address is used as a token to indicate an unreachable originator. A conforming implementation MUST NOT permit a reply to an
如果无法回复邮件，例如电话应答邮件，则应使用特殊地址“非邮件用户”作为发起者的地址。允许使用任何文本名称，如“电话应答”或电话号码（如果有）。此特殊地址用作令牌，表示无法访问的发起者。一致性实施不得允许对
address from "non-mail-user". For compatibility with the installed base of mail user agents, implementations MUST reject the message when a message addressed to "non-mail-user" is received. The status code for such NDN's is 5.1.1 "Mailbox does not exist".
来自“非邮件用户”的地址。为了与邮件用户代理的已安装基础兼容，当接收到地址为“非邮件用户”的邮件时，实现必须拒绝该邮件。此类NDN的状态代码为5.1.1“邮箱不存在”。
Example:
例子：
From: Telephone Answering <non-mail-user@mycompany.com>
From: Telephone Answering <non-mail-user@mycompany.com>
There are many ways to handle distribution list (DL) expansions and none are 'standard'. A VPIM implementation MAY support DLs. Using a simple alias is a behavior closest to what many voice mail systems do today and what is to be used with VPIM messages. A couple of important features that need special care when DLs are used are:
有很多方法可以处理通讯组列表（DL）扩展，但没有一种是“标准”的。VPIM实现可能支持DLs。使用简单的别名是一种最接近当今许多语音邮件系统的行为，也最接近VPIM消息的使用方式。使用DLs时需要特别注意的两个重要功能是：
Reply to the originator - (Address in the RFC822 "Reply-To:" or "From" field) Errors to the submitter - (Address in the MAIL FROM field of the ESMTP exchange or the "Return-Path:" RFC822 field)
回复发起人-（RFC822“回复至：”或“发件人”字段中的地址）提交人错误-（ESMTP交换的“邮件发件人”字段中的地址或“返回路径：”RFC822字段）
Some proprietary voice messaging protocols include only the recipient of the particular copy in the envelope and include no "header fields" except date and per-message features. Most voice messaging systems do not provide for "Header Information" in their messaging queues and only include delivery information. As a result, recipient information MAY be in either the "To:" or "Cc:" header fields. If all recipients cannot be presented then the recipient header fields SHOULD be omitted to indicate that an accurate list of recipients (e.g., for use with a reply-all capability) is not known.
一些专有语音消息协议仅包括信封中特定副本的收件人，不包括除日期和每条消息功能以外的“标题字段”。大多数语音消息传递系统在其消息传递队列中不提供“标题信息”，只包含传递信息。因此，收件人信息可能位于“收件人：”或“抄送：”标题字段中。如果无法显示所有收件人，则应省略收件人标题字段，以表明收件人的准确列表（例如，用于回复所有功能）未知。
Internet messages contain a header information block. This header block contains information required to identify the sender, the list of recipients, the message send time, and other information intended for user presentation. Except for specialized gateway and mailing list cases, header fields do not indicate delivery options for the transport of messages.
Internet消息包含标题信息块。此标题块包含标识发件人、收件人列表、邮件发送时间所需的信息，以及用于用户演示的其他信息。除专用网关和邮件列表情况外，标题字段不表示邮件传输的传递选项。
Distribution list processors are noted for modifying or adding to the header fields of messages that pass through them. VPIM systems MUST be able to accept and ignore header fields that are not defined here.
通讯组列表处理程序以修改或添加通过它们的消息的标题字段而著称。VPIM系统必须能够接受和忽略此处未定义的标题字段。
The following header lines are permitted for use with VPIM messages:
以下标题行允许与VPIM消息一起使用：
SEND RULES
发送规则
The originator's fully qualified domain address (a mailbox address followed by the fully qualified domain name) MUST be present. Systems conforming with this profile SHOULD provide the text personal name of the voice message originator in a quoted phrase, if the name is available. Text names of corporate or positional mailboxes MAY be provided as a simple string. From: [RFC822]
发端人的完全限定域名（邮箱地址后跟完全限定域名）必须存在。符合此配置文件的系统应在引用的短语中提供语音消息发起人的个人姓名（如果名称可用）。公司邮箱或位置邮箱的文本名称可以作为简单字符串提供。发件人：[RFC822]
Example:
例子：
From: "Joe S. User" <12145551212@mycompany.com>
From: "Joe S. User" <12145551212@mycompany.com>
From: Technical Support <611@serviceprovider.com>
From: Technical Support <611@serviceprovider.com>
From: Non-mail-user@myserver.mycompany.com
发件人：非邮件-user@myserver.mycompany.com
Voice mail machines may not be able to support separate attributes for the "From:" header fields and the SMTP MAIL FROM, VPIM-conforming systems SHOULD set these values to the same address. Use of addresses different than those present in the "From:" header field address may result in unanticipated behavior.
语音邮件机器可能无法支持“发件人：”标题字段的单独属性，SMTP邮件发件人，符合VPIM的系统应将这些值设置为相同的地址。使用不同于“发件人：”标题字段地址的地址可能会导致意外行为。
RECEIVE RULES
接受规则
The user listed in the "From:" field MUST be presented in the voice message envelope of the voice messaging system as the originator of the message, though the exact presentation is an implementation decision (e.g., the mailbox ID or the text name MAY be presented). The "From:" address SHOULD be used for replies (see 4.9).
“发件人：”字段中列出的用户必须作为消息的发起人出现在语音消息系统的语音消息信封中，尽管确切的显示方式是一项实施决策（例如，可以显示邮箱ID或文本名称）。“发件人：”地址应用于回复（见4.9）。
The "To:" field contains the recipient's fully-qualified domain address.
“收件人：”字段包含收件人的完全限定域地址。
Example:
例子：
To: +12145551213@mycompany.com
To: +12145551213@mycompany.com
SEND RULES
发送规则
There MAY be one or more "To:" fields in any message. Systems SHOULD provide a list of recipients only if all recipients are available.
任何消息中都可能有一个或多个“收件人：”字段。只有当所有收件人都可用时，系统才应提供收件人列表。
Systems, such as gateways from protocols or legacy platforms that do not indicate the complete list of recipients, MAY provide a "To:" line. Because these systems cannot accurately enumerate all recipients in the "To:" headers, recipients SHOULD NOT be enumerated.
系统，例如来自协议或遗留平台的网关，如果未指明完整的收件人列表，则可能会提供“收件人：”行。由于这些系统无法准确枚举“收件人：”标题中的所有收件人，因此不应枚举收件人。
RECEIVE RULES
接受规则
Systems conforming to this profile MAY discard the addresses in the "To:" fields if they are unable to store the information. This would, of course, make a reply-to-all capability impossible. If present, the addresses in the "To:" field MAY be used for a reply message to all recipients.
符合此配置文件的系统如果无法存储信息，可能会丢弃“收件人：”字段中的地址。当然，这将使对所有能力的回答变得不可能。如果存在，“收件人：”字段中的地址可用于向所有收件人发送回复邮件。
The "Cc:" field contains additional recipients' fully qualified domain addresses. Many voice mail systems maintain only sufficient envelope information for message delivery and are not capable of storing or providing a complete list of additional recipients.
“Cc:”字段包含其他收件人的完全限定域地址。许多语音邮件系统仅保留足够的信封信息用于邮件传递，无法存储或提供其他收件人的完整列表。
SEND RULES
发送规则
Conforming implementations MAY send "Cc:" lists if all recipients are known at the time of origination. If not, systems SHOULD omit the "Cc:" fields to indicate that the full list of recipients is unknown or otherwise unavailable. The list of disclosed recipients MUST NOT include undisclosed recipients (i.e., those sent via a blind copy).
如果发起时已知所有收件人，则一致性实施可发送“抄送：”列表。否则，系统应省略“Cc:”字段，以指示收件人的完整列表未知或不可用。披露的收件人列表不得包括未披露的收件人（即通过盲拷贝发送的收件人）。
Example:
例子：
Cc: +12145551213@mycompany.com
Cc: +12145551213@mycompany.com
RECEIVE RULES
接受规则
Systems conforming to this profile MAY add all the addresses in the "Cc:" field to the "To:" field, others MAY discard the addresses in the "Cc:" fields. If a list of "Cc:" addresses is present, these addresses MAY be used for a reply message to all recipients.
符合此配置文件的系统可以将“Cc:”字段中的所有地址添加到“to:”字段中，其他系统可以丢弃“Cc:”字段中的地址。如果存在“抄送：”地址列表，则这些地址可用于向所有收件人发送回复消息。
The "Date:" field contains the date and time the message was sent by the originator.
“日期：”字段包含发端人发送邮件的日期和时间。
SEND RULES
发送规则
The sending system MUST report the time the message was sent. The time zone MUST be present and SHOULD be represented in a four-digit
发送系统必须报告消息的发送时间。时区必须存在，并且应以四位数字表示
time zone offset, such as -0500 for North American Eastern Standard Time. This MAY be supplemented by a time zone name in parentheses, e.g., "-0700 (PDT)".
时区偏移，例如北美东部标准时间为-0500。这可以用括号中的时区名称来补充，例如“-0700（PDT）”。
Example:
例子：
Date: Wed, 28 Jul 96 10:08:49 -0800 (PST)
Date: Wed, 28 Jul 96 10:08:49 -0800 (PST)
If the VPIM sender is relaying a message from a system that does not provide a time stamp, the time of arrival at the gateway system SHOULD be used as the date.
如果VPIM发送方正在中继来自未提供时间戳的系统的消息，则到达网关系统的时间应作为日期。
RECEIVE RULES
接受规则
Conforming implementations SHOULD be able to convert [RFC822] date and time stamps into local time
一致性实现应能够将[RFC822]日期和时间戳转换为本地时间
The "Sender:" field contains the actual address of the originator if an agent on behalf of the author indicated in the "From:" field sends the message.
“发件人：”字段包含发端人的实际地址，如果代理代表“发件人：”字段中指定的作者发送消息。
SEND RULES
发送规则
This header field MAY be sent by VPIM-conforming systems.
此标题字段可由符合VPIM的系统发送。
RECEIVE RULES
接受规则
If the address in the "Sender:" field cannot be preserved in the recipient's message queues or in the next-hop protocol from a gateway, the field MAY be silently discarded.
如果“发件人：”字段中的地址无法保留在收件人的消息队列或网关的下一跳协议中，则该字段可能会被悄悄丢弃。
The "Return-path:" field is added by the final delivering SMTP server. If present, it contains the address from the MAIL FROM parameter of the ESMTP exchange (see [RFC822]). Any error messages resulting from the delivery failure MUST be sent to this address. Note that if the "Return-path:" is null ("<>") (e.g., a call answer message would have no return path) delivery status notifications MUST NOT be sent.
“返回路径：”字段由最终的SMTP服务器添加。如果存在，它包含来自ESMTP交换的MAIL from参数的地址（请参见[RFC822]）。由于传递失败而导致的任何错误消息都必须发送到此地址。请注意，如果“返回路径：”为空（“<>”）（例如，呼叫应答消息将没有返回路径），则不得发送传递状态通知。
SEND RULES
发送规则
The originating system MUST NOT add this header.
发起系统不得添加此标头。
RECEIVE RULES
接受规则
If the receiving system is incapable of storing the return path (or MAIL FROM) to be used for subsequent delivery errors (i.e., it is a gateway to a legacy system or protocol), the receiving system must otherwise ensure that further delivery errors don't happen. Systems that do not support the return path MUST ensure that at the time the message is acknowledged (i.e., when a DSN would be sent), the message is delivered to the recipient's ultimate mailbox. Non-Delivery notifications SHOULD NOT be sent after that final delivery.
如果接收系统无法存储用于后续传递错误的返回路径（或邮件来源）（即，它是传统系统或协议的网关），则接收系统必须确保不会发生进一步的传递错误。不支持返回路径的系统必须确保在确认邮件时（即发送DSN时），将邮件发送到收件人的最终邮箱。未送达通知不应在最终送达后发送。
The "Message-Id:" field contains a globally unique per-message identifier.
“消息Id:”字段包含每个消息的全局唯一标识符。
SEND RULES
发送规则
A globally unique message-id MUST be generated for each message sent from a VPIM-conforming implementation.
必须为符合VPIM的实现发送的每条消息生成一个全局唯一的消息id。
Example:
例子：
Message-Id: <12345678@mycompany.com>
Message-Id: <12345678@mycompany.com>
RECEIVE RULES
接受规则
When provided in the original message, it MUST be used when sending a MDN. This identifier MAY be used for tracking and auditing. From [RFC822]
当原始消息中提供时，在发送MDN时必须使用它。此标识符可用于跟踪和审核。来自[RFC822]
If present, the "Reply-To:" header provides a preferred address to which reply messages should be sent (see 4.9). Typically, voice mail systems can only support one originator of a message so it is likely that this field will be ignored by the receiving system. From: [RFC822]
如果存在，“回复至：”标题提供了回复消息应发送到的首选地址（见4.9）。通常，语音邮件系统只能支持一条消息的一个发起人，因此接收系统可能会忽略此字段。发件人：[RFC822]
SEND RULES
发送规则
A conforming system SHOULD NOT send a "Reply-To:" header.
一致性系统不应发送“回复：”标题。
RECEIVE RULES
接受规则
If a "Reply-To:" field is present, a reply-to-sender message MAY be sent to the address specified (that is, in lieu of the address in the "From:" field). If the receiving system (e.g., multi-protocol
如果存在“回复至：”字段，则可将回复至发件人消息发送至指定的地址（即代替“发件人：”字段中的地址）。如果接收系统（例如，多协议
gateway) only supports one address for the originator, then the address in the "From:" field MUST be used and the "Reply-To:" field MAY be silently discarded.
网关）仅支持发起者的一个地址，则必须使用“发件人：”字段中的地址，并且“回复收件人：”字段可能会被自动丢弃。
The "Received:" field contains trace information added to the beginning of a RFC822 message by MTAs. This is the only field that may be added by an MTA. Information in this header is useful for debugging when using an US-ASCII message reader or a header-parsing tool. From: [RFC822]
“Received:”字段包含MTA添加到RFC822邮件开头的跟踪信息。这是MTA可以添加的唯一字段。当使用US-ASCII消息读取器或标头解析工具时，此标头中的信息对于调试非常有用。发件人：[RFC822]
SEND RULES
发送规则
A VPIM-conforming system MUST add a "Received:" field. When acting as a gateway, information about the system from which the message was received SHOULD be included.
符合VPIM的系统必须添加“接收：”字段。当充当网关时，应包括有关接收消息的系统的信息。
RECEIVE RULES
接受规则
A VPIM-conforming system MUST NOT remove any "Received:" fields when relaying messages to other MTAs or gateways. These header fields MAY be ignored or deleted when the message is received at the final destination.
当将消息中继到其他MTA或网关时，符合VPIM的系统不得删除任何“已接收：”字段。当在最终目的地收到消息时，这些标题字段可能会被忽略或删除。
The "MIME-Version:" field MUST be present to indicate that the message conforms to [MIME1-5]. Systems conforming with this specification SHOULD include a comment with the words "(Voice 2.0)". [VPIM1] defines an earlier version of this profile and uses the token (Voice 1.0). Example:
“MIME版本：”字段必须存在，以表明消息符合[MIME1-5]。符合本规范的系统应包括一条注释，注释中应注明“（语音2.0）”。[VPIM1]定义此配置文件的早期版本并使用令牌（语音1.0）。例子：
MIME-Version: 1.0 (Voice 2.0)
MIME版本：1.0（语音2.0）
This identifier is intended for information only and SHOULD NOT be used to semantically identify the message as being a VPIM message. Instead, the presence of the multipart/voice-message content type defined in section 18.2 SHOULD be used if identification is necessary.
此标识符仅供参考，不应用于从语义上将消息标识为VPIM消息。相反，如果需要识别，则应使用第18.2节中定义的多部分/语音消息内容类型。
The "Content-Type:" header MUST be present to declare the type of content enclosed in the message. The typical top-level content in a VPIM Message SHOULD be Multipart/Voice-Message. The allowable contents are detailed starting in section 4.4 of this document. From: [MIME2]
“Content Type:”标头必须存在，以声明消息中包含的内容类型。VPIM消息中典型的顶级内容应该是多部分/语音消息。允许的内容从本文件第4.4节开始详细说明。发件人：[MIME2]
Because Internet mail was initially specified to carry only 7-bit US-ASCII text, it may be necessary to encode voice and fax data into a representation suitable for that environment. The "Content-Transfer-Encoding:" header describes this transformation if it is needed.
由于最初指定Internet邮件仅携带7位US-ASCII文本，因此可能需要将语音和传真数据编码为适合该环境的表示形式。“Content Transfer Encoding:”标题描述了此转换（如果需要）。
SEND RULES
发送规则
An implementation in conformance with this profile SHOULD send audio and/or facsimile data in "Binary" form when binary message transport is available (see section 5). When binary transport is not available, implementations MUST encode the audio and/or facsimile data as "Base64".
当二进制消息传输可用时，符合此配置文件的实现应以“二进制”形式发送音频和/或传真数据（见第5节）。当二进制传输不可用时，实现必须将音频和/或传真数据编码为“Base64”。
RECEIVE RULES
接受规则
Conforming implementations MUST recognize and decode the standard encodings, "Binary" (when binary support is available), "7bit, "8bit", "Base64" and "Quoted-Printable" per [MIME1]. The detection and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be supported in order to meet MIME requirements and to preserve interoperability with the fullest range of possible devices.
一致性实现必须根据[MIME1]识别和解码标准编码、“二进制”（当二进制支持可用时）、“7bit”、“8bit”、“Base64”和“引用的可打印文件”。检测和解码“引用的可打印文件”、“7bit”和“8bit”“必须支持，以满足MIME要求，并保持与尽可能多的设备的互操作性。
The "Sensitivity:" field, if present, indicates the requested privacy level. If no privacy is requested, this field is omitted. The header definition is as follows:
“敏感度：”字段（如果存在）表示请求的隐私级别。如果未请求隐私，则忽略此字段。标题定义如下：
Sensitivity := "Sensitivity" ":" Sensitivity-value
Sensitivity := "Sensitivity" ":" Sensitivity-value
Sensitivity-value := "Personal" / "Private" / "Company-Confidential"
Sensitivity-value := "Personal" / "Private" / "Company-Confidential"
SEND RULES
发送规则
A VPIM-conforming implementation MAY include this header to indicate the sensitivity of a message. If a user marks a message "Private", a conforming implementation MUST send only the "Private" sensitivity level. There are no VPIM-specific semantics defined for the values "Personal" or "Company-Confidential". A conforming implementation SHOULD NOT send the values "Personal" or "Company-Confidential". If the message is of "Normal" sensitivity, this field SHOULD be omitted. From: [X.400]
符合VPIM的实现可包括该报头以指示消息的敏感性。如果用户将消息标记为“Private”，则一致性实现必须只发送“Private”敏感级别。没有为“个人”或“公司机密”值定义特定于VPIM的语义。一致性实施不应发送“个人”或“公司机密”的价值观。如果信息具有“正常”灵敏度，则应忽略此字段。发件人：[X.400]
RECEIVE RULES
接受规则
If a "Sensitivity:" field with a value of "Private" is present in the message, a conforming system MUST prohibit the recipient from forwarding this message to any other user. A conforming system, however, SHOULD allow the responder to reply to a sensitive message, but SHOULD NOT include the original message content. The responder MAY set the sensitivity of the reply message.
如果消息中存在值为“Private”的“Sensitivity:”字段，则一致性系统必须禁止收件人将此消息转发给任何其他用户。然而，一致性系统应允许响应者回复敏感消息，但不应包括原始消息内容。响应者可以设置回复消息的灵敏度。
A receiving system MAY ignore sensitivity values of "Personal" and "Company Confidential".
接收系统可能忽略“个人”和“公司机密”的敏感值。
If the receiving system does not support privacy and the sensitivity is "Private", a negative delivery status notification MUST be sent to the originator with the appropriate status code (5.6.0) "Other or undefined protocol status" indicating that privacy could not be assured. The message contents SHOULD be returned to the sender to allow for a voice context with the notification. A non-delivery notification to a private message SHOULD NOT be tagged private since it will be sent to the originator. From: [X.400]
如果接收系统不支持隐私，且敏感度为“隐私”，则必须向发端人发送负面交付状态通知，并附上相应的状态代码（5.6.0）“其他或未定义的协议状态”，表明无法确保隐私。应将消息内容返回给发送者，以允许通知的语音上下文。私人邮件的未送达通知不应标记为私人，因为它将被发送给发端人。发件人：[X.400]
A message with no privacy explicitly noted (i.e., no header) or with "Normal" sensitivity has no special treatment.
没有明确注明隐私（即，没有标题）或敏感度“正常”的消息没有特殊处理。
Indicates the requested importance to be given by the receiving system. If no special importance is requested, this header MAY be omitted and the value of the absent header assumed to be "normal". From: [X.400]
指示接收系统要给出的请求重要性。如果未要求特殊重要性，则可省略此标头，并假定缺失标头的值为“正常”。发件人：[X.400]
Importance := "Importance" ":" importance-value
Importance := "Importance" ":" importance-value
Importance-value := "low" / "normal" / "high"
Importance-value := "low" / "normal" / "high"
SEND RULES
发送规则
Conforming implementations MAY include this header to indicate the importance of a message.
一致性实现可包括该报头以指示消息的重要性。
RECEIVE RULES
接受规则
If the receiving system does not support "Importance:", the attribute MAY be silently dropped.
如果接收系统不支持“重要性：”，则该属性可能会自动删除。
The "Subject:" field is often provided by email systems but is not widely supported on voice mail platforms. From: [RFC822]
“主题：”字段通常由电子邮件系统提供，但语音邮件平台并不广泛支持。发件人：[RFC822]
SEND RULES
发送规则
For compatibility with text-based mailbox interfaces, a text subject field SHOULD be generated by a conforming implementation. It is RECOMMENDED that voice-messaging systems that do not support any text user interfaces (e.g., access only by a telephone) insert a generic subject header of "VPIM Message" or "Voice Message" for the benefit of GUI-enabled recipients.
为了与基于文本的邮箱接口兼容，应通过一致性实现生成文本主题字段。建议不支持任何文本用户界面（例如，仅通过电话访问）的语音消息系统插入“VPIM消息”或“语音消息”的通用主题标题，以方便启用GUI的收件人。
RECEIVE RULES
接受规则
It is anticipated that many voice-only systems will be incapable of storing the subject line. The subject MAY be discarded by a receiving system.
预计许多纯语音系统将无法存储主题行。接收系统可以丢弃对象。
This field MAY be present to facilitate the text identification of these body parts in simple email readers. Any values may be used.
此字段可能用于帮助在简单电子邮件阅读器中识别这些身体部位的文本。可以使用任何值。
Example:
例子：
Content-Description: Big Telco Voice Message
内容描述：大电信语音信息
SEND RULES
发送规则
This field MAY be added to a voice body part to offer a freeform description of the voice content. It is useful to incorporate the values for Content-Disposition with additional descriptions. For example, this can be used to indicate product name or transcoding records.
此字段可以添加到语音主体部分，以提供语音内容的自由形式描述。将内容处置的值与其他描述合并在一起非常有用。例如，这可用于指示产品名称或转码记录。
RECEIVE RULES
接受规则
This field MAY be displayed to the recipient. However, since it is only informative it MAY be ignored.
此字段可能会显示给收件人。但是，由于它只是提供信息，因此可能会被忽略。
This field MUST be present to allow the parsable identification of
body parts within a VPIM voice message. This is especially useful
if, as is typical, more than one Audio/* body occurs within a single
level (e.g., Multipart/Voice-Message). Since a VPIM voice message is
intended to be automatically played in the order in which the audio
contents occur, the audio contents MUST always be of disposition
inline. However, it is still useful to include a filename value, so
this SHOULD be present if this information is available. From:
[DISP]
This field MUST be present to allow the parsable identification of
body parts within a VPIM voice message. This is especially useful
if, as is typical, more than one Audio/* body occurs within a single
level (e.g., Multipart/Voice-Message). Since a VPIM voice message is
intended to be automatically played in the order in which the audio
contents occur, the audio contents MUST always be of disposition
inline. However, it is still useful to include a filename value, so
this SHOULD be present if this information is available. From:
[DISP]
SEND RULES
发送规则
In order to distinguish between the various types of audio contents in a VPIM voice message a new disposition parameter "voice" is defined with IANA (see section 18.1) with the parameter values below to be used as appropriate:
为了区分VPIM语音信息中的各种类型的音频内容，使用IANA定义了一个新的配置参数“voice”（参见第18.1节），并根据需要使用以下参数值：
Audio-Type := "voice" "=" Audio-type-value
Audio-Type := "voice" "=" Audio-type-value
Audio-type-value := "Voice-Message" / "Voice-Message-Notification" /
"Originator-Spoken-Name" /"Recipient-Spoken-Name" /"Spoken-Subject"
Audio-type-value := "Voice-Message" / "Voice-Message-Notification" /
"Originator-Spoken-Name" /"Recipient-Spoken-Name" /"Spoken-Subject"
Voice-Message - the primary voice message, Voice-Message-Notification - a spoken delivery notification or spoken disposition notification, Originator-Spoken-Name - the spoken name of the originator, Recipient-Spoken-Name - the spoken name of the recipient(s) if available to the originator Spoken-Subject- the spoken subject of the message, typically spoken by the originator
语音信息-主要语音信息，语音信息通知-口头交付通知或口头处置通知，发起者口头姓名-发起者的口头姓名，收件人口头姓名-收件人的口头姓名（如果发起者口头主体可用）-信息的口头主体，通常由发起者说
Note that there SHOULD only be one instance of each of these types of audio contents per message level. Additional instances of a given type (i.e., parameter value) MAY occur within an attached forwarded or reply voice message. If there are multiple recipients for a given message, recipient-spoken-name MUST NOT be used.
请注意，对于每种类型的音频内容，每个消息级别应该只有一个实例。附加的转发或回复语音消息中可能会出现给定类型（即参数值）的其他实例。如果给定邮件有多个收件人，则不得使用收件人的口头姓名。
RECEIVE RULES
接受规则
Implementations SHOULD use this header. However, those that do not understand the "voice" parameter (or the "Content-Disposition:" header) can safely ignore it, and will present the audio body parts in order (but will not be able to distinguish between them). If more than one instance of the "voice" parameter type value is encountered at one level (e.g., multiple 'Voice-Message' tagged contents) then they SHOULD be presented together.
实现应该使用这个头。但是，那些不理解“voice”参数（或“Content Disposition:”标题）的人可以安全地忽略它，并按顺序显示音频主体部分（但无法区分它们）。如果在一个级别遇到多个“voice”参数类型值实例（例如，多个“voice Message”标记内容），则应将它们一起显示。
The "Content-Duration:" header provides an indication of the audio length in seconds of the segment.
“Content Duration:”标题以秒为单位指示该段的音频长度。
Example:
例子：
Content-Duration: 33
内容持续时间：33
SEND RULES
发送规则
This field MAY be present to allow the specification of the length of the audio body part in seconds.
此字段可用于以秒为单位指定音频主体部分的长度。
RECEIVE RULES
接受规则
The use of this field on reception is a local implementation issue. From: [DUR]
在接收时使用此字段是本地实施问题。发件人：[DUR]
4.3.4. Content-Language:
4.3.4. 内容语言：
This field MAY be present to allow the specification of the spoken language of the audio body part. The encoding is defined in [LANG].
该字段可用于指定音频身体部位的口语。编码在[LANG]中定义。
Example for UK English:
英国英语示例：
Content-Language: en-UK
内容语言：英语
SEND RULES
发送规则
A sending system MAY add this field to indicate the language of the voice. The determination of this (e.g., automated or user-selected) is a local implementation issue.
发送系统可以添加此字段以指示语音的语言。确定这一点（例如，自动或用户选择）是本地实施问题。
RECEIVE RULES
接受规则
The use of this field on reception is a local implementation issue. It MAY be used as a hint to the recipient (e.g., end-user or an automated translation process) as to the language of the voice message.
在接收时使用此字段是本地实施问题。它可以用作提示接收者（例如，最终用户或自动翻译过程）语音消息的语言。
The content types described in this section are identified for use within the Multipart/Voice-Message content. This content is referred to as a "VPIM message" in this document and is the fundamental part of a "VPIM message".
本节中描述的内容类型可在多部分/语音消息内容中使用。此内容在本文档中称为“VPIM消息”，是“VPIM消息”的基本部分。
Only the contents profiled can be sent within a VPIM voice message construct (i.e., the Multipart/Voice-Message content type) to form a simple or a more complex structure (several examples are given in Appendix B). The presence of other contents within a VPIM voice message is not permitted. In the absence of a bilateral agreement, conforming implementations MUST NOT create a message containing prohibited contents. In the spirit of liberal acceptance, a conforming implementation MAY accept and render prohibited content. Systems unable to accept or render prohibited contents MAY discard the prohibited contents as necessary to deliver the acceptable content. When multiple contents are present within the Multipart/Voice-Message, they SHOULD be presented to the user in the order that they appear in the message.
在VPIM语音消息构造（即多部分/语音消息内容类型）中，只能发送所分析的内容，以形成简单或更复杂的结构（附录B中给出了几个示例）。VPIM语音消息中不允许存在其他内容。在没有双边协议的情况下，一致性实施不得创建包含禁止内容的消息。本着自由接受的精神，一致性实现可以接受并呈现禁止的内容。无法接受或呈现禁止内容的系统可根据需要丢弃禁止内容，以交付可接受的内容。当多部分/语音消息中存在多个内容时，应按照它们在消息中出现的顺序向用户显示这些内容。
Some deployed implementations based on a common interpretation of the original VPIM v2 specification reject messages with prohibited content rather than discard the unsupported contents. For interoperability with these systems, it is especially important that prohibited contents not be sent within a Multipart/Voice-Message.
一些基于原始VPIM v2规范的通用解释的部署实现拒绝包含禁止内容的消息，而不是丢弃不支持的内容。对于与这些系统的互操作性，禁止在多部分/语音消息中发送禁止的内容尤为重要。
This MIME multipart structure provides a mechanism for packaging a voice message into one container that is tagged as VPIM v2 conforming. The sub-type is identical in semantics and syntax to multipart/mixed, as defined in [MIME2]. As such, it may be safely interpreted as a multipart/mixed by systems that do not understand the sub-type (only the identification as a voice message would be lost).
此MIME多部分结构提供了一种机制，用于将语音消息打包到标记为VPIM v2的容器中。子类型在语义和语法上与multipart/mixed相同，如[MIME2]中所定义。因此，不理解子类型的系统可以安全地将其解释为多部分/混合（只有作为语音消息的标识才会丢失）。
In addition to the MIME required boundary parameter, a version parameter is also required for this sub-type. This is to distinguish this refinement of the sub-type from the previous definition in [VPIM1]. The value of the version parameter is "2.0" if the content conforms to the requirements of this specification. Should there be further revisions of this content type, there MUST be backwards compatibility (i.e., systems implementing version n can read version 2, and systems implementing version 2 can read version 2 contents within a version n).
除了MIME必需的边界参数外，此子类型还需要版本参数。这是为了将子类型的细化与[VPIM1]中先前的定义区分开来。如果内容符合本规范的要求，则版本参数的值为“2.0”。如果此内容类型有进一步的修订，则必须具有向后兼容性（即，实现版本n的系统可以读取版本2，而实现版本2的系统可以读取版本n中的版本2内容）。
SEND RULES
发送规则
The Multipart/Voice-Message content-type MUST only contain the profiled media and content types specified in this section (i.e., Audio/*, Image/*, and Message/RFC822). The most common will be: spoken name, spoken subject, the message itself, and an attached fax. Forwarded messages are created by simply using the Message/RFC822 construct.
多部分/语音消息内容类型必须仅包含本节中指定的分析媒体和内容类型（即音频/*、图像/*和消息/RFC822）。最常见的是：口头姓名、口头主题、邮件本身和附带的传真。转发的消息只需使用Message/RFC822构造即可创建。
Conformant implementations MUST use Multipart/Voice-Message in a VPIM message. In most cases, this Multipart/Voice-Message Content-Type will be the top level but may be included within a Message/RFC822 if the message is forwarded or within a multipart/mixed when more than one message is being forwarded.
一致性实现必须在VPIM消息中使用多部分/语音消息。在大多数情况下，此多部分/语音消息内容类型为顶层，但如果消息被转发，则可包含在消息/RFC822中，或者当转发多个消息时，可包含在多部分/混合中。
RECEIVE RULES
接受规则
Conformant implementations MUST recognize the Multipart/Voice-Message content (whether it is a top-level content or contained in a Multipart/Mixed) and MUST be able to separate the contents (e.g., spoken name or spoken subject).
一致性实现必须识别多部分/语音消息内容（无论是顶级内容还是包含在多部分/混合中），并且必须能够分离内容（例如，语音名称或语音主题）。
The semantic of Multipart/Voice-Message (defined in section 18.2) is identical to Multipart/Mixed and may be interpreted as that by systems that do not recognize this content-type.
多部分/语音消息（定义见第18.2节）的语义与多部分/混合消息相同，可被不识别此内容类型的系统解释为语义。
SEND RULES
发送规则
MIME requires support of the Message/RFC822 message encapsulation body part. This body part SHOULD be used within a Multipart/Voice-Message to forward complete messages (see 4.8) or to reply with original content (see 4.9). From: [MIME2]
MIME需要消息/RFC822消息封装体部分的支持。此正文部分应在多部分/语音消息中使用，以转发完整消息（见4.8）或以原始内容回复（见4.9）。发件人：[MIME2]
RECEIVE RULES
接受规则
The receiving system MUST accept this format and SHOULD treat this attachment as a forwarded message. The receiving system MAY flatten the forwarding structure (i.e., remove this construct to leave multiple voice contents or even concatenate the voice contents to fit in a recipient's mailbox), if necessary.
接收系统必须接受此格式，并应将此附件视为转发的邮件。如有必要，接收系统可展平转发结构（即，移除此结构以保留多个语音内容，甚至连接语音内容以适合接收者的邮箱）。
SEND RULES
发送规则
An implementation conforming to this profile MUST send Audio/32KADPCM by default for voice [ADPCM]. This encoding is a moderately-compressed encoding with a data rate of 32 kbits/second using moderate processing resources. Typically, this body contains several minutes of message content; however, if used for spoken name or subject the content is expected to be considerably shorter (i.e., about 5 and 10 seconds respectively).
默认情况下，符合此配置文件的实现必须为语音[ADPCM]发送音频/32KADPCM。此编码是一种适度压缩编码，使用适度的处理资源，数据速率为32 kbits/s。通常，此正文包含几分钟的消息内容；然而，如果用于口头名称或主题，则内容预计将相当短（即，分别约5秒和10秒）。
RECEIVE RULES
接受规则
Receivers MUST be able to accept and decode Audio/32KADPCM. If an implementation can only handle one voice body, then multiple voice bodies (if present) SHOULD be concatenated, and MUST NOT be discarded. If concatenated, the contents SHOULD be in the same order they appeared in the multipart.
接收机必须能够接收和解码音频/32KADPCM。如果一个实现只能处理一个语音体，那么应该连接多个语音体（如果存在），并且不能丢弃。如果连接，则内容应与它们在多部分中出现的顺序相同。
A common image encoding for facsimile, known as TIFF-F, is a derivative of the Tag Image File Format (TIFF) and is described in several documents. For the purposes of VPIM, the F Profile of TIFF for Facsimile (TIFF-F) is defined in [TIFF-F], and the Image/TIFF MIME content-type is defined in [TIFFREG]. While there are several formats of TIFF, only TIFF-F is profiled for use within Multipart/Voice-Message. Further, since the TIFF-F file format is used in a store-and-forward mode with VPIM, the image MUST be encoded so that there is only one image strip per facsimile page.
传真的通用图像编码，称为TIFF-F，是标签图像文件格式（TIFF）的衍生版本，在多个文档中进行了描述。就VPIM而言，传真用TIFF（TIFF-F）的F配置文件在[TIFF-F]中定义，图像/TIFF MIME内容类型在[TIFFREG]中定义。虽然TIFF有多种格式，但只有TIFF-F可在多部分/语音消息中使用。此外，由于TIFF-F文件格式在VPIM的存储转发模式下使用，因此必须对图像进行编码，以便每个传真页只有一个图像条。
SEND RULES
发送规则
All VPIM implementations that support facsimile MUST generate TIFF-F compatible facsimile contents in the Image/TIFF subtype using the application=faxbw encoding by default. If the VPIM message is a voice- annotated fax, the implementation SHOULD send this fax content in Multipart/Voice-Message. If the message is a simple fax, an implementation MAY send it without using the Multipart/Voice-Message to be more compatible with fax-only (RFC 2305) implementations.
默认情况下，所有支持传真的VPIM实现必须使用application=faxbw编码在Image/TIFF子类型中生成与TIFF-F兼容的传真内容。如果VPIM消息是带语音注释的传真，则实现应以多部分/语音消息的形式发送此传真内容。如果消息是简单传真，则实现可以在不使用多部分/语音消息的情况下发送消息，以便与仅传真（RFC 2305）实现更兼容。
While any valid MIME body header MAY be used (e.g., Content-Disposition to indicate the filename), none are specified to have special semantics for VPIM and MAY be ignored. Note that the content-type parameter application=faxbw MUST be included in outbound messages.
虽然可以使用任何有效的MIME正文头（例如，用于指示文件名的内容配置），但没有一个被指定为具有VPIM的特殊语义，可以忽略。请注意，出站消息中必须包含内容类型参数application=faxbw。
RECEIVE RULES
接受规则
Not all VPIM systems support fax, but all SHOULD accept it within the multipart/voice-message. Within a Multipart/Voice-Message, a receiving system that cannot render fax content SHOULD accept the voice content of a VPIM message and discard the fax content. Outside a Multipart/Voice-Message, a recipient system MAY reject (with appropriate NDN) the entire message if it cannot store or is not capable of rendering a message with fax attachments. VPIM conforming systems MAY support fax outside of (or without) the Multipart/Voice-Message.
并非所有VPIM系统都支持传真，但都应在多部分/语音消息中接受传真。在多部分/语音消息中，无法呈现传真内容的接收系统应接受VPIM消息的语音内容并丢弃传真内容。在多部分/语音邮件之外，如果收件人系统无法存储或无法呈现带有传真附件的邮件，则可能会拒绝（使用适当的NDN）整个邮件。VPIM兼容系统可支持在多部分/语音消息之外（或没有）进行传真。
Some deployed implementations based on a common interpretation of the original VPIM V2 specification reject messages with fax content within the Multipart/Voice-Message rather than discard the unsupported contents. These systems will return the message to the sender with an NDN indicating lack of support for fax.
一些基于原始VPIM V2规范的通用解释的部署实现拒绝在多部分/语音消息中包含传真内容的消息，而不是丢弃不支持的内容。这些系统会将消息返回给发件人，并带有NDN，表示不支持传真。
The following MIME contents (with the exception of multipart/mixed in section 4.5.1) MAY be included within a multipart/voice message. Other contents MUST NOT be included. Their handling is a local implementation issue. Multipart/mixed is included to promote interoperability with a wider range of systems and also to allow the creation of more complex multimedia messages (with a VPIM message as one part).
多部分/语音消息中可能包含以下MIME内容（第4.5.1节中的多部分/混合内容除外）。不得包含其他内容。它们的处理是当地的执行问题。包括多部分/混合，以促进与更广泛系统的互操作性，并允许创建更复杂的彩信（其中包括VPIM消息）。
This common MIME content-type allows the enclosing of several body parts in a single message.
这种常见的MIME内容类型允许在单个消息中包含多个正文部分。
SEND RULES
发送规则
A VPIM voice message (i.e., multipart/voice-message) MAY be included within a message with a Multipart/Mixed top-level content type. Typically, this would only be used when mixing non-voice and non-fax contents with a voice message.
VPIM语音消息（即，多部分/语音消息）可以包括在具有多部分/混合顶级内容类型的消息中。通常，这仅在将非语音和非传真内容与语音消息混合时使用。
RECEIVE RULES
接受规则
Such a message is not itself a VPIM message and the handling of such a construct is outside the scope of the VPIM profile. However, an the spirit of liberal acceptance, a conforming implementation MUST accept and render a VPIM voice message contained in a Multipart/Mixed.
此类消息本身不是VPIM消息，并且此类构造的处理不在VPIM配置文件的范围内。然而，出于自由接受的精神，一致性实现必须接受并呈现包含在多部分/混合协议中的VPIM语音消息。
SEND RULES
发送规则
This content was profiled in the original specification of VPIM v2 as a means of transporting contact information from the sender to the recipient. This usage did not find widespread adoption and is no longer a feature of VPIM V2. Conforming implementations SHOULD NOT send the Text/Directory content type.
VPIM v2的原始规范中对该内容进行了分析，将其作为将联系人信息从发送者传输到接收者的一种方式。这种用法没有被广泛采用，并且不再是VPIM V2的一项功能。一致性实现不应发送文本/目录内容类型。
RECEIVE RULES
接受规则
For compatibility with an earlier specification of VPIM v2, the Text/Directory content type MUST be accepted by a conforming implementation, but need not be stored, processed, or rendered to the recipient.
为了与VPIM v2的早期规范兼容，文本/目录内容类型必须由一致性实现接受，但无需存储、处理或呈现给收件人。
Use of any other encoding except the required codecs reduces interoperability in the absence of explicit knowledge about the capabilities of the recipient. A conforming implementation SHOULD NOT use any other encoding unless a unique identifier is registered with the IANA prior to use (see [MIME4]). The voice encodings SHOULD be registered as subtypes of Audio. The fax encodings SHOULD be registered as subtypes of Image.
除了所需的编解码器之外，使用任何其他编码都会在不明确了解接收方能力的情况下降低互操作性。一致性实施不应使用任何其他编码，除非在使用前向IANA注册了唯一标识符（见[MIME4]）。语音编码应注册为音频的子类型。传真编码应注册为图像的子类型。
SEND RULES
发送规则
Proprietary voice encoding formats or other standard formats SHOULD NOT be sent under this profile unless the sender has a reasonable expectation that the recipient will accept the encoding. In practice, this requires explicit per-destination configuration information maintained either in a directory, personal address book, or gateway configuration tables.
专有语音编码格式或其他标准格式不应在此配置文件下发送，除非发件人合理预期收件人将接受编码。实际上，这需要在目录、个人通讯簿或网关配置表中维护每个目标的显式配置信息。
RECEIVE RULES
接受规则
Systems MAY accept other Audio/* or Image/* content types if they can
decode them. Systems which receive Audio/* or Image/* content types
which they are unable to deposit or unable to render MUST return the
message (and SHOULD include the original content) to the originator
with an NDN indicating media not supported.
Systems MAY accept other Audio/* or Image/* content types if they can
decode them. Systems which receive Audio/* or Image/* content types
which they are unable to deposit or unable to render MUST return the
message (and SHOULD include the original content) to the originator
with an NDN indicating media not supported.
MIME requires support of the basic Text/Plain content type (with the US-ASCII character set). This content type has limited applicability within the voice-messaging environment. However, because VPIM is a MIME profile, MIME requirements SHOULD be met.
MIME需要支持基本文本/普通内容类型（使用US-ASCII字符集）。此内容类型在语音消息环境中的适用性有限。但是，由于VPIM是一个MIME配置文件，因此应该满足MIME要求。
SEND RULES
发送规则
Conforming VPIM implementations SHOULD NOT send the Text/Plain content-type. Implementations MAY send the Text/Plain content-type outside the Multipart/Voice-Message.
一致性VPIM实现不应发送文本/普通内容类型。实现可以在多部分/语音消息之外发送文本/普通内容类型。
RECEIVE RULES
接受规则
Within a Multipart/Voice-Message, the Text/Plain content-type MAY be dropped from the message, if necessary, to deliver the audio/fax components. The recipient SHOULD NOT reject the entire message if the text component cannot be accepted or rendered.
在多部分/语音消息中，如有必要，可从消息中删除文本/普通内容类型，以传送音频/传真组件。如果无法接受或呈现文本组件，则收件人不应拒绝整个邮件。
Outside a Multipart/Voice-Message, conforming implementations MUST accept Text/Plain; however, specific handling is left as an implementation decision. From: [MIME2]
在多部分/语音消息之外，一致性实现必须接受文本/纯文本；但是，具体的处理由实现决策决定。发件人：[MIME2]
Some deployed implementations based on a common interpretation of the original VPIM V2 specification reject messages with any text content rather than discard the unsupported contents. These systems will return the message to the sender with an NDN indicating lack of support for text.
一些基于原始VPIM V2规范的通用解释部署的实现拒绝包含任何文本内容的消息，而不是丢弃不支持的内容。这些系统会将消息返回给发件人，并带有NDN，表示不支持文本。
A DSN is a notification of delivery (positive DSN), non-delivery (negative DSN), or temporary delivery delay (delayed DSN). The top-level content-type of a DSN is Multipart/Report, which is defined in [REPORT]. The content-type which distinguishes DSN's from other types of notifications is Message/Delivery-Status, which is defined in [DSN].
DSN是传递（正DSN）、未传递（负DSN）或临时传递延迟（延迟DSN）的通知。DSN的顶级内容类型是Multipart/Report，在[Report]中定义。将DSN与其他通知类型区分开来的内容类型是[DSN]中定义的消息/传递状态。
SEND RULES
发送规则
A VPIM-compliant implementation MUST be able to send DSN's that conform to [REPORT] and [DSN]. Unless requested otherwise, a non-delivery DSN MUST be sent when any form of non-delivery of a message occurs.
符合VPIM的实施必须能够发送符合[REPORT]和[DSN]的DSN。除非另有要求，否则发生任何形式的邮件未送达时，必须发送未送达DSN。
A VPIM-compliant implementation SHOULD provide a spoken delivery status in the "human-readable" body part of the DSN, but MAY provide a textual status.
VPIM兼容的实现应在DSN的“人类可读”主体部分中提供语音传递状态，但也可以提供文本状态。
RECEIVE RULES
接受规则
A VPIM-compliant implementation MUST be able to receive DSN's that conform to [REPORT] and [DSN].
符合VPIM的实施必须能够接收符合[REPORT]和[DSN]的DSN。
A VPIM-compliant implementation MUST be able to receive a DSN whose "human-readable" body part contains a spoken delivery status phrase or a textual description. Though subsequent use of the phrase or text is a local implementation issue, the intent of the DSN MUST be presented to the end user.
符合VPIM的实现必须能够接收DSN，其“人类可读”的主体部分包含口头交付状态短语或文本描述。尽管短语或文本的后续使用是本地实现问题，但必须向最终用户展示DSN的意图。
An MDN is a notification indicating what happens to a message after it is deposited in the recipient's mailbox. An MDN can be positive (message was read/played/rendered/etc.) or negative (message was deleted before recipient could see it, etc.). The top-level content-type of a MDN is Multipart/Report, which is defined in [REPORT]. The content-type which distinguishes MDN's from other types of notifications is Message/Disposition-Notification, which is defined in [MDN].
MDN是一种通知，指示邮件存放到收件人邮箱后发生的情况。MDN可以是肯定的（消息被读取/播放/呈现/等等），也可以是否定的（消息在收件人看到之前被删除，等等）。MDN的顶级内容类型是Multipart/Report，在[Report]中定义。将MDN与其他类型的通知区分开来的内容类型是消息/处置通知，它在[MDN]中定义。
SEND RULES
发送规则
A VPIM-compliant implementation SHOULD support the ability to request MDNs. This is done via the use of the "Disposition-Notification-To:" header field as defined in [MDN].
符合VPIM的实现应支持请求MDN的能力。这是通过使用[MDN]中定义的“处置通知收件人：”标题字段完成的。
A VPIM-compliant implementation SHOULD support the ability to send MDNs, but these MDNs MUST conform to [REPORT] and [MDN].
符合VPIM的实现应支持发送MDN的能力，但这些MDN必须符合[REPORT]和[MDN]。
When sending an MDN, a VPIM-compliant implementation SHOULD provide a spoken message disposition in the "human-readable" body part of the MDN, but MAY provide a textual status.
发送MDN时，符合VPIM的实现应在MDN的“人类可读”正文部分中提供语音消息处理，但可以提供文本状态。
RECEIVE RULES
接受规则
A VPIM-compliant implementation SHOULD respond to an MDN request with an MDN response.
符合VPIM的实现应使用MDN响应响应MDN请求。
A VPIM-compliant implementation MUST be able to receive MDNs that conform to [REPORT] and [MDN], if it is capable of requesting MDNs. If a VPIM-compliant implementation is capable of receiving MDNs, it MUST be able to receive a MDN whose "human-readable" body part contains a spoken message disposition phrase or a textual disposition description. Though subsequent use of the phrase or text is a local implementation issue, the intent of the MDN MUST be presented to the end user.
符合VPIM的实现必须能够接收符合[REPORT]和[MDN]的MDN，前提是它能够请求MDN。如果符合VPIM的实现能够接收MDN，则它必须能够接收其“人类可读”主体部分包含语音消息处置短语或文本处置描述的MDN。尽管短语或文本的后续使用是本地实现问题，但必须向最终用户展示MDN的意图。
VPIM v2 explicitly supports the forwarding of voice and fax content with voice or fax annotation. However, only the two constructs described below are acceptable in a VPIM message. Since only the first (i.e., Message/RFC822) can be recognized as a forwarded message (or even multiple forwarded messages), it is RECOMMENDED that this construct be used whenever possible.
VPIM v2明确支持通过语音或传真批注转发语音和传真内容。但是，在VPIM消息中，只有下面描述的两种构造是可接受的。由于只有第一个（即消息/RFC822）可以被识别为转发消息（甚至多个转发消息），因此建议尽可能使用此构造。
Forwarded VPIM messages SHOULD be sent as a Multipart/Voice-Message
with the entire original message enclosed in a Message/RFC822
content-type and the annotation as a separate Audio/* or Image/* body
part. If the RFC822 header fields are not available for the
forwarded content, simulated header fields with available information
SHOULD be constructed to indicate the original sending timestamp, and
the original sender as indicated in the "From:" field. Note that at
least one of "From:", "Subject:", or "Date:" MUST be present. As
well, the Message/RFC822 content MUST include at least the "MIME-
Version:", and "Content-Type:" header fields. From: [MIME2]
Forwarded VPIM messages SHOULD be sent as a Multipart/Voice-Message
with the entire original message enclosed in a Message/RFC822
content-type and the annotation as a separate Audio/* or Image/* body
part. If the RFC822 header fields are not available for the
forwarded content, simulated header fields with available information
SHOULD be constructed to indicate the original sending timestamp, and
the original sender as indicated in the "From:" field. Note that at
least one of "From:", "Subject:", or "Date:" MUST be present. As
well, the Message/RFC822 content MUST include at least the "MIME-
Version:", and "Content-Type:" header fields. From: [MIME2]
In the event that forwarding information is lost, the entire audio
content MAY be sent as a single Audio/* segment without including any
forwarding semantics. An example of this loss is an AMIS message
being forwarded through an AMIS-to-VPIM gateway.
In the event that forwarding information is lost, the entire audio
content MAY be sent as a single Audio/* segment without including any
forwarding semantics. An example of this loss is an AMIS message
being forwarded through an AMIS-to-VPIM gateway.
VPIM v2 explicitly supports replying to received messages.
VPIM v2明确支持回复收到的消息。
Support of multiple originator header fields in a reply message is often not possible on voice messaging systems, so it may be necessary to choose only one when gatewaying a VPIM message to another voice message system. However, implementers should note that this may make it impossible to send DSN's, MDN's, and replies to their proper destinations.
语音消息系统通常不支持回复消息中的多个发起者报头字段，因此在将VPIM消息网关化到另一个语音消息系统时，可能需要只选择一个。但是，实现者应该注意，这可能导致无法将DSN、MDN和回复发送到其正确的目的地。
In some cases, replying to a message is not possible, such as with a message created by telephone answering (i.e., classic voice mail). In this case, the From field SHOULD contain the special address non-mail-user@domain (see 4.1.2). The recipient's VPIM system SHOULD NOT offer the option to reply to this kind of message (unless an outcalling feature is offered - which is out of scope for VPIM).
在某些情况下，无法回复消息，例如通过电话应答创建的消息（即经典语音邮件）。在这种情况下，“发件人”字段应包含非邮件的特殊地址-user@domain（见4.1.2）。收件人的VPIM系统不应提供回复此类邮件的选项（除非提供了呼出功能-这超出了VPIM的范围）。
Messages are transported between voice mail machines using the Internet Extended Simple Mail Transfer Protocol (ESMTP). All information required for proper delivery of the message is included in the ESMTP dialog. This information, including the sender and recipient addresses, is commonly referred to as the message "envelope". This information is equivalent to the message control block in many analog voice messaging protocols.
消息使用Internet扩展简单邮件传输协议（ESMTP）在语音邮件机之间传输。正确传递消息所需的所有信息都包含在ESMTP对话框中。此信息，包括发件人和收件人地址，通常称为邮件“信封”。此信息相当于许多模拟语音消息协议中的消息控制块。
ESMTP is a general-purpose messaging protocol, designed both to send mail and to allow terminal console messaging. Simple Mail Transport Protocol (SMTP) was originally created for the exchange of US-ASCII 7-bit text messages. Binary and 8-bit text messages have
ESMTP是一种通用消息传递协议，设计用于发送邮件和允许终端控制台消息传递。简单邮件传输协议（SMTP）最初是为交换US-ASCII 7位文本消息而创建的。二进制和8位文本消息具有
traditionally been transported by encoding the messages into a 7-bit text-like form. [ESMTP] formalized an extension mechanism for SMTP, and subsequent RFCs have defined 8-bit text networking, command streaming, binary networking, and extensions to permit the declaration of message size for the efficient transmission of large messages such as multi-minute voice mail.
传统上是通过将消息编码成7位文本形式来传输的。[ESMTP]正式定义了SMTP的扩展机制，随后的RFC定义了8位文本网络、命令流、二进制网络和扩展，以允许声明消息大小，以便高效传输大型消息，如多分钟语音邮件。
The following sections list ESMTP commands, keywords, and parameters that are required and those that are optional for conformance to this profile.
以下各节列出了符合此配置文件所需的ESMTP命令、关键字和参数，以及可选的ESMTP命令、关键字和参数。
A conforming system MUST implement all mandatory SMTP and ESMTP commands. Any defined optional command or parameter MAY be supported.
一致性系统必须执行所有强制性SMTP和ESMTP命令。可以支持任何定义的可选命令或参数。
VPIM utilizes a number of SMTP Service Extensions to provide full-featured voice messaging service. The following extensions are profiled for use with VPIM:
VPIM利用许多SMTP服务扩展来提供功能齐全的语音消息服务。为与VPIM一起使用，对以下扩展进行了分析：
The DSN extension defines a mechanism which allows an SMTP client to specify (a) DSN's should be generated under certain conditions, (b) whether such DSN's should return the contents of the message, and (c) additional information, to be returned with a DSN, that allows the sender to identify both the recipient(s) for which the DSN was issued, and the transaction in which the original message was sent.
DSN扩展定义了一种机制，允许SMTP客户端指定（a）在某些条件下应生成DSN，（b）此类DSN是否应返回邮件内容，以及（c）随DSN返回的附加信息，该机制允许发送方识别为其发出DSN的收件人，以及发送原始消息的事务。
The DSN extension MUST be supported by VPIM conforming implementations.
DSN扩展必须由符合VPIM的实现支持。
In addition, beyond the requirements of [DRPT], conforming implementations MUST support NOTIFY parameter on the RCPT command to allow indication of when the originator requests a notification. The RET parameter SHOULD be supported to return the original message with the notification. Parameters ORCPT and ENVID MAY also be supported. From: [DRPT]
此外，除了[DRPT]的要求外，一致性实现必须支持RCPT命令上的NOTIFY参数，以允许指示发起者何时请求通知。应支持RET参数返回带有通知的原始消息。也可以支持参数ORCPT和ENVID。发件人：[DRPT]
The SIZE extension defines a mechanism whereby an SMTP client and server may interact to give the server an opportunity to decline to accept a message (perhaps temporarily) based on the client's estimate of the message size. From: [SIZE]
大小扩展定义了一种机制，SMTP客户端和服务器可以通过这种机制进行交互，从而使服务器有机会根据客户端对邮件大小的估计拒绝接受邮件（可能是暂时的）。发件人：[尺码]
The SIZE extension MUST be supported by VPIM-compliant implementations.
符合VPIM的实施必须支持大小扩展。
The ENHANCEDSTATUSCODES extension defines a mechanism whereby an SMTP server augments its responses with the enhanced mail system status codes defined in [CODES]. These codes can then be used to provide more informative explanations of error conditions. From: [STATUS]
ENHANCEDSTATUSCODES扩展定义了一种机制，SMTP服务器通过[codes]中定义的增强邮件系统状态代码来增强其响应。然后，可以使用这些代码对错误条件提供更详细的解释。发件人：[状态]
The ENHANCEDSTATUSCODES extension SHOULD be supported by VPIM-compliant implementations.
符合VPIM的实现应支持ENHANCEDSTATUSCODES扩展。
The PIPELINING extension defines a mechanism whereby an SMTP server can indicate the extent of its ability to accept multiple commands in a single TCP send operation. Using a single TCP send operation for multiple commands can improve SMTP performance significantly. From [PIPE]
管道扩展定义了一种机制，通过该机制，SMTP服务器可以指示其在单个TCP发送操作中接受多个命令的能力范围。对多个命令使用单个TCP发送操作可以显著提高SMTP性能。来自[管道]
The PIPELINING extension SHOULD be supported by VPIM-compliant implementations.
管道扩展应该由符合VPIM的实现支持。
The CHUNKING extension defines a mechanism that enables an SMTP client and server to negotiate the use of the message data transfer command "BDAT" (in alternative to the DATA command) for efficiently sending large MIME messages. From: [BINARY]
分块扩展定义了一种机制，使SMTP客户端和服务器能够协商使用消息数据传输命令“BDAT”（替代数据命令）来高效地发送大型MIME消息。发件人：[二进制]
The CHUNKING extension MAY be supported by VPIM-compliant implementations.
符合VPIM的实现可能支持分块扩展。
The BINARYMIME extension defines a mechanism that enables an SMTP client and server to negotiate the transfer of unencoded binary message data utilizing the BDAT command. From: [BINARY]
BINARYMIME扩展定义了一种机制，使SMTP客户端和服务器能够利用BDAT命令协商未编码二进制消息数据的传输。发件人：[二进制]
The BINARYMIME extension MAY be supported by VPIM-compliant implementations. Note that [BINARY] specifies that if BINARYMIME is to be supported, then CHUNKING has to be supported by definition.
符合VPIM的实现可能支持BINARYMIME扩展。注意，[BINARY]指定如果要支持BINARYMIME，则必须通过定义支持分块。
The SMTP extensions suggested or required for conformance to VPIM fall into two categories. The first category includes features that increase the efficiency of the transport system such as SIZE, BINARYMIME, and PIPELINING. In the event of a downgrade to a less-functional transport system, these features can be dropped with no functional change to the sender or recipient.
建议或要求符合VPIM的SMTP扩展分为两类。第一类包括提高传输系统效率的功能，如大小、二进制MIME和管道。在降级到功能较差的传输系统的情况下，可以在不改变发送方或接收方功能的情况下删除这些功能。
The second category of features is transport extensions in support of new functions. DSN and ENHANCEDSTATUSCODES provide essential improvements in the handling of delivery status notifications to bring email to the level of reliability expected of Voice Mail. To ensure a consistent level of service across an intranet or the global Internet, it is essential that VPIM-conforming ESMTP support the DSN extension at all hops between a VPIM originating system and the recipient system. In the situation where a "downgrade" is unavoidable a relay hop may be forced (by the next hop) to forward a VPIM message without the ESMTP request for delivery status notification. It is RECOMMENDED that the downgrading system should continue to attempt to deliver the message, but MUST send an appropriate delivery status notification to the originator, e.g., the message left an ESMTP host and was sent relayed to a non-DSN-aware destination, and this may be the last DSN received.
第二类功能是支持新功能的传输扩展。DSN和ENHANCEDSTATUSCODES在传递状态通知的处理方面提供了必要的改进，使电子邮件达到语音邮件预期的可靠性水平。为了确保跨intranet或全球Internet的一致服务级别，符合VPIM的ESMTP必须在VPIM发起系统和接收方系统之间的所有跃点支持DSN扩展。在“降级”不可避免的情况下，中继跳可能会（由下一跳）被强制转发VPIM消息，而无需ESMTP发送状态通知请求。建议降级系统应继续尝试传递消息，但必须向发端人发送适当的传递状态通知，例如，消息离开ESMTP主机并被中继发送到不支持DSN的目的地，这可能是最后一次接收到DSN。
It is the responsibility of a VPIM system to provide the fully-qualified domain name (FQDN) of the recipient based on the address entered by the user (if the entered address is not already a FQDN). This would typically be an issue on systems that offer only a telephone user interface. The mapping of the dialed target number to a routable FQDN address, allowing delivery to the destination system, can be accomplished through implementation-specific means.
VPIM系统负责根据用户输入的地址（如果输入的地址还不是FQDN）提供收件人的完全限定域名（FQDN）。对于只提供电话用户界面的系统来说，这通常是一个问题。拨号目标号码到可路由FQDN地址的映射，允许传送到目标系统，可以通过特定于实现的方式完成。
To facilitate a local cache, an implementation may wish to populate local directories with the first and last names, as well as the senders' spoken name information extracted from received messages. Addresses or names parsed from the header fields of VPIM messages MAY be used to populate directories.
为了便于本地缓存，实现可能希望使用从接收到的消息中提取的名字和姓氏以及发送者的语音姓名信息填充本地目录。从VPIM消息头字段解析的地址或名称可用于填充目录。
The Internet protocols provide a mechanism for the management of messaging systems, from the management of the physical network through the management of the message queues. SNMP SHOULD be supported on a VPIM-conforming machine.
Internet协议为消息传递系统的管理提供了一种机制，从物理网络的管理到消息队列的管理。应在符合VPIM的计算机上支持SNMP。
The digital interface to the VM and the TCP/IP protocols MAY be managed. MIB II MAY be implemented to provide basic statistics and reporting of TCP and IP protocol performance [MIB II].
可以管理到VM和TCP/IP协议的数字接口。MIB II可用于提供TCP和IP协议性能的基本统计和报告[MIB II]。
VPIM is a messaging application that will be supported in several environments and be supported on differing devices. These environments include traditional voice processing systems, desktop voice messaging systems, store-and-forward relays, and protocol translation gateways.
VPIM是一种消息传递应用程序，将在多个环境中受支持，并在不同的设备上受支持。这些环境包括传统的语音处理系统、桌面语音消息系统、存储转发中继和协议转换网关。
In order to accommodate all environments, this document defines two areas of conformance: transport and content.
为了适应所有环境，本文档定义了两个一致性领域：传输和内容。
Transport-conformant systems will pass VPIM messages in a store-and-forward manner with assured delivery notifications and without the loss of information. It is expected that most store-and-forward Internet mail-based messaging systems will be VPIM transport-conformant.
符合传输要求的系统将以存储转发的方式传递VPIM消息，并确保发送通知，且不会丢失信息。预计大多数基于存储和转发Internet邮件的消息传递系统将符合VPIM传输。
Content-conformant systems will generate and interpret VPIM messages. Conformance in the generation of VPIM messages indicates that the restrictions of this profile are honored. Only contents specified in this profile or extensions agreed to by bilateral agreement may be sent. Conformance in the interpretation of VPIM messages indicates that all VPIM content types and constructs can be received; that all mandatory VPIM content types can be decoded and presented to the recipient in an appropriate manner; and that any unrenderable contents result in the appropriate notification.
符合内容的系统将生成和解释VPIM消息。生成VPIM消息的一致性表明遵守此配置文件的限制。只能发送本简介中规定的内容或经双边协议同意的扩展内容。VPIM消息解释的一致性表明可以接收所有VPIM内容类型和结构；所有强制性VPIM内容类型都可以以适当的方式解码并呈现给收件人；任何不可交代的内容将导致适当的通知。
A summary of the conformance requirements is contained in Appendix A.
合规性要求的摘要包含在附录A中。
VPIM end systems are expected to be both transport- and content-conformant. Voice messaging systems and protocol conversion gateways are considered end systems.
VPIM终端系统应同时兼容传输和内容。语音消息系统和协议转换网关被视为终端系统。
Relay systems are expected to be transport-conformant in order to receive and send conforming messages. However, they must also create VPIM-conforming delivery status notifications in the event of delivery problems.
中继系统应符合传输要求，以便接收和发送符合要求的信息。但是，如果出现交付问题，他们还必须创建符合VPIM的交付状态通知。
Desktop Email clients that support VPIM are expected to be content-conformant. Desktop email clients use various protocols and API's for exchanging messages with the local message store and message transport system. While these clients may benefit from VPIM
支持VPIM的桌面电子邮件客户端应与内容一致。桌面电子邮件客户端使用各种协议和API与本地消息存储和消息传输系统交换消息。而这些客户端可能会从VPIM中受益
transport capabilities, specific client-server requirements are out-of-scope for this document.
传输功能、特定的客户端服务器要求不在本文档的范围内。
This document is a profile of existing Internet mail protocols. To maintain interoperability with Internet mail, any security to be provided should be part of the Internet security infrastructure, rather than a new mechanism or some other mechanism outside of the Internet infrastructure.
本文档是现有Internet邮件协议的概要。为了保持与Internet邮件的互操作性，所提供的任何安全性都应该是Internet安全基础设施的一部分，而不是Internet基础设施之外的新机制或其他机制。
Both Internet mail and voice messaging have their own set of threats and countermeasures. As such, this specification does not create any security issues not already existing in the profiled Internet mail and voice mail protocols themselves. This section attends only to the set of additional threats that ensue from integrating the two services.
互联网邮件和语音信息都有自己的威胁和对策。因此，本规范不会产生任何已分析的Internet邮件和语音邮件协议本身不存在的安全问题。本节仅讨论集成这两个服务所带来的一系列附加威胁。
The actual sender of the voice message might not be the same as that specified in the "Sender:" or "From:" message header fields or the MAIL FROM address from the SMTP envelope. In a tightly constrained environment, sufficient physical and software controls may be able to ensure prevention of this problem. In addition, the recognition of the sender's voice may provide confidence of the sender's identity irrespective of that specified in "Sender:" or "From:". It should be recognized that SMTP implementations do not provide inherent authentication of the senders of messages, nor are sites under obligation to provide such authentication.
语音邮件的实际发件人可能与“发件人：”或“发件人：”邮件标题字段中指定的发件人或SMTP信封中的邮件发件人地址不同。在严格约束的环境中，充分的物理和软件控制可能能够确保防止此问题。此外，无论“发件人：”或“发件人：”中的规定如何，对发件人声音的识别可能会提供对发件人身份的信心。应该认识到，SMTP实现不提供邮件发件人的固有身份验证，站点也没有义务提供此类身份验证。
Assigning an Internet mail address to a voice mailbox opens the possibility of receiving unsolicited messages (either text or voice mail). Traditionally, voice mail systems operated in closed environments and were not susceptible to unknown senders. Voice mail users have a higher expectation of mailbox privacy and may consider such messages as a security breach. Many Internet mail systems are choosing to block all messages from unknown sources in an attempt to curb this problem.
将Internet邮件地址分配给语音邮箱可以接收未经请求的邮件（文本邮件或语音邮件）。传统上，语音邮件系统在封闭的环境中运行，不易受到未知发件人的影响。语音邮件用户对邮箱隐私有更高的期望，并且可以将这些消息视为安全漏洞。许多互联网邮件系统都选择阻止来自未知来源的所有邮件，以试图遏制这一问题。
Users of voice messaging systems have an expectation of a level of message privacy that is higher than the level provided by Internet mail without security enhancements. This expectation of privacy by users SHOULD be preserved as much as possible.
语音消息系统的用户期望的消息隐私级别高于未经安全增强的Internet邮件所提供的级别。应尽可能保留用户对隐私的这种期望。
Sufficient physical and software control may be acceptable in constrained environments. Further, the profile specified in this document does not in any way preclude the use of any Internet object or channel security protocol to encrypt, authenticate, or non-repudiate the messages.
在受限环境中，可以接受充分的物理和软件控制。此外，本文档中指定的配置文件不以任何方式排除使用任何Internet对象或通道安全协议来加密、验证或不可否认消息。
[8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E. and D. Crocker, "SMTP Service Extension for 8bit-MIMEtransport", RFC 1652, July 1994.
[8BIT]Klensin，J.，Freed，N.，Rose，M.，Stefferud，E.和D.Crocker，“8BIT MIMEtransport的SMTP服务扩展”，RFC 16521994年7月。
[ADPCM] 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.
[ADPCM]Vaudreuil，G.和G.Parsons，“收费质量语音-32 kbit/s自适应差分脉冲编码调制（ADPCM）MIME子类型注册”，RFC 3802，2004年6月。
[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版，第3期，1993年8月。
[BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[BINARY]Vaudreuil，G.，“用于传输大型和二进制MIME消息的SMTP服务扩展”，RFC 3030，2000年12月。
[CODES] Vaudreuil, G. "Enhanced Mail System Status Codes", RFC 1893, January 1996.
[代码]Vaudreuil，G.“增强邮件系统状态代码”，RFC 1893，1996年1月。
[MIMEDIR] Dawson, F., Howes, T. and M. Smith, "A MIME Content-Type for Directory Information", RFC 2425, September 1998.
[MIMEDIR]Dawson，F.，Howes，T.和M.Smith，“目录信息的MIME内容类型”，RFC 24251998年9月。
[DISP] Troost, R. and S. Dorner, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header", RFC 2183, August 1997.
[DISP]Troost，R.和S.Dorner，“在互联网消息中传达呈现信息：内容处置标题”，RFC 2183，1997年8月。
[DNS1] Mockapetris, P., "Domain names - implementation and specification", RFC 1035, November 1987.
[DNS1]Mockapetris，P.，“域名-实现和规范”，RFC1035，1987年11月。
[DNS2] Mockapetris, P., "Domain names - concepts and facilities", RFC 1034, November 1987.
[DNS2]Mockapetris，P.，“域名-概念和设施”，RFC 1034，1987年11月。
[DRPT] Moore, K., "Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)", RFC 3461, January 2003.
[DRPT]Moore，K.，“用于传递状态通知（DSN）的简单邮件传输协议（SMTP）服务扩展”，RFC 34612003年1月。
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[DUR] Parsons, G. and G. Vaudreuil, "Content Duration MIME Header Definition", RFC 3803, June 2004.
[DUR]Parsons，G.和G.Vaudreuil，“内容持续时间MIME头定义”，RFC 3803，2004年6月。
[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时代的编号计划。
[ESMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[ESMTP]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[G726] 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]CCITT建议G.726（1990），数字传输系统的一般方面，终端设备-40,32,24,16 kbit/s自适应差分脉冲编码调制（ADPCM）。
[HOSTREQ] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[HOSTREQ]Braden，R.，“互联网主机的要求——应用和支持”，STD 3，RFC 1123，1989年10月。
[LANG] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[LANG]Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，2001年1月。
[MDN] Hansen, T., Ed. and G. Vaudreuil, Ed., "Message Disposition Notification", RFC 3798, May 2004.
[MDN]Hansen，T.，Ed.和G.Vaudreuil，Ed.，“消息处置通知”，RFC 3798，2004年5月。
[MIB II] Rose, M., "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", RFC 1213, March 1991.
[MIB II]Rose，M.，“基于TCP/IP的互联网网络管理的管理信息库：MIB-II”，RFC 1213，1991年3月。
[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月。
[MIME2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types ", RFC 2046, November 1996.
[MIME2]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[MIME3] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, November 1996.
[MIME3]Moore，K.，“多用途互联网邮件扩展（MIME）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[MIME4] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
[MIME4]Freed，N.，Klensin，J.和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，RFC 20481996年11月。
[MIME5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples ", RFC 2049, November 1996.
[MIME5]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[PIPE] Freed, N.and A. Cargille, "SMTP Service Extension for Command Pipelining" STD 60, RFC 2920, September 2000.
[PIPE]Freed，N.和A.Cargille，“用于命令管道的SMTP服务扩展”STD 60，RFC 2920，2000年9月。
[REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 3462, January 2003.
[报告]Vaudreuil，G.“邮件系统管理消息报告的多部分/报告内容类型”，RFC 3462，2003年1月。
[REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[REQ]Bradner，S.，“在RFC中用于指示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
[RFC822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[SIZE] Klensin, J., Freed, N. and K. Moore, "SMTP Service Extensions for Message Size Declaration" STD 10, RFC 1870, November 1995.
[SIZE]Klensin，J.，Freed，N.和K.Moore，“邮件大小声明的SMTP服务扩展”STD 10，RFC 1870，1995年11月。
[STATUS] Freed, N., "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996.
[STATUS]Freed，N.，“用于返回增强错误代码的SMTP服务扩展”，RFC 2034，1996年10月。
[TIFF-F] Parsons, G. and J. Rafferty, "Tag Image File Format: Application F", RFC 2306, March 1998.
[TIFF-F]Parsons，G.和J.Rafferty，“标签图像文件格式：应用程序F”，RFC 2306，1998年3月。
[TIFFREG] Parsons, G., Rafferty, J. and S. Zilles, "Tag Image File Format: image/tiff - MIME sub-type registration", RFC 2302, March 1998.
[TIFFREG]Parsons，G.，Rafferty，J.和S.Zilles，“标签图像文件格式：图像/tiff-MIME子类型注册”，RFC 2302，1998年3月。
[V-MSG] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME Sub-type Registration", RFC 2423, September 1998.
[V-MSG]Vaudreuil，G.和G.Parsons，“VPIM语音消息MIME子类型注册”，RFC 24231998年9月。
[VCARD] Dawson, F. and T. Howes, "vCard MIME Directory Profile" RFC 2426, September 1998.
[VCARD]Dawson，F.和T.Howes，“VCARD MIME目录配置文件”RFC24261998年9月。
[VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911, February 1996.
[VPIM1]Vaudreuil，G.，“互联网邮件的语音模式”，RFC 19111996年2月。
[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月。
[X.400] CCITT/ISO, "CCITT Recommendations X.400/ ISO/IEC 10021-1, Message Handling: System and Service Overview", December 1988.
[X.400]CCITT/ISO，“CCITT建议X.400/ISO/IEC 10021-1，消息处理：系统和服务概述”，1988年12月。
The authors would like to offer a special thanks to the Electronic Messaging Association (EMA), especially the members of the Voice Messaging Committee, and the IETF VPIM Work Group, for their support of the VPIM specification and the efforts they have made to ensure its success.
作者要特别感谢电子信息协会（EMA），特别是语音信息委员会和IETF VPIM工作组的成员，感谢他们对VPIM规范的支持以及为确保其成功所做的努力。
The following table summarizes the profile of VPIM version 2 detailed in this document. Since in many cases it is not possible to simplify the qualifications for supporting each feature this appendix is informative. The reader is recommended to read the complete explanation of each feature in the referenced section. The text in the previous sections shall be deemed authoritative if any item in this table is ambiguous.
下表总结了本文档中详细介绍的VPIM版本2的配置文件。由于在许多情况下，不可能简化支持每个功能的资格，因此本附录提供了信息。建议读者阅读参考章节中每个功能的完整说明。如果本表中的任何项目不明确，则前几节中的文本应视为权威。
The conformance table is separated into various columns:
一致性表分为不同的列：
Feature - name of protocol feature (note that the indenting indicates a hierarchy of conformance, i.e., the conformance of a lower feature is only relevant if there is conformance to the higher feature)
Feature—协议功能的名称（注意，缩进表示一致性的层次结构，即，只有在与较高功能一致时，较低功能的一致性才相关）
Section - reference section in main text of this document
章节-本文件正文中的参考章节
Area - conformance area to which each feature applies: C - content T - transport
区域-每个功能适用的一致性区域：C-内容T-传输
Status - whether the feature is mandatory, optional, or prohibited. The key words used in this table are to be interpreted as described in [REQ], though the following list gives a quick overview of the different degrees of feature conformance:
状态-功能是强制的、可选的还是禁止的。本表中使用的关键词应按照[REQ]中所述进行解释，尽管以下列表简要概述了不同程度的功能一致性：
Must - mandatory Should - required in the absence of a compelling need to omit. May - optional Should not - prohibited in the absence of a compelling need. Must not - prohibited
必须-强制性-应-在没有迫切需要省略的情况下要求。在没有迫切需要的情况下，可以-可选-不应该-禁止。不得-禁止
Footnote - special comment about conformance for a particular feature
脚注-关于特定特征一致性的特别注释
VPIM version 2 Conformance
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
| | | | | | | |
Message Addressing Formats: | | | | | | | |
Use DNS host names |4.1 |C|x| | | | |
Use only numbers in mailbox IDs |4.1.1 |C| |x| | | |
Numbers in mailbox IDs follow E.164 |4.1.1 |C| |x| | | |
Use alpha-numeric mailbox IDs |4.1.1 |C| | |x| | |
Support of postmaster@domain |4.1.2 |C|x| | | | |
Support of non-mail-user@domain |4.1.2 |C| |x| | | |
Support of distribution lists |4.1.3 |C| | |x| | |
| | | | | | | |
Message Header Fields: | | | | | | | |
Sending outbound messages | | | | | | | |
From |4.2.1 |C|x| | | | |
Addition of text name |4.2.1 |C| |x| | | |
Same value as MAIL FROM |4.2.1 |C| |x| | | |
To |4.2.2 |C| |x| | | |1
cc |4.2.3 |C| | |x| | |1
Date |4.2.4 |C|x| | | | |
Sender |4.2.5 |C| | |x| | |
Return-Path |4.2.6 |C| | | | |x|
Message-ID |4.2.7 |C|x| | | | |
Reply-To |4.2.8 |C| | | |x| |
Received |4.2.9 |C|x| | | | |
MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | |
Content-Type |4.2.11 |C|x| | | | |
Content-Transfer-Encoding |4.2.12 |C|x| | | | |
Sensitivity |4.2.13 |C| | |x| | |
Importance |4.2.14 |C| | |x| | |
Subject |4.2.15 |C| |x| | | |
Disposition-notification-to |4.7 |C| |x| | | |
Other Headers |4.2 |C| | |x| | |
| | | | | | | |
VPIM version 2 Conformance
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
| | | | | | | |
Message Addressing Formats: | | | | | | | |
Use DNS host names |4.1 |C|x| | | | |
Use only numbers in mailbox IDs |4.1.1 |C| |x| | | |
Numbers in mailbox IDs follow E.164 |4.1.1 |C| |x| | | |
Use alpha-numeric mailbox IDs |4.1.1 |C| | |x| | |
Support of postmaster@domain |4.1.2 |C|x| | | | |
Support of non-mail-user@domain |4.1.2 |C| |x| | | |
Support of distribution lists |4.1.3 |C| | |x| | |
| | | | | | | |
Message Header Fields: | | | | | | | |
Sending outbound messages | | | | | | | |
From |4.2.1 |C|x| | | | |
Addition of text name |4.2.1 |C| |x| | | |
Same value as MAIL FROM |4.2.1 |C| |x| | | |
To |4.2.2 |C| |x| | | |1
cc |4.2.3 |C| | |x| | |1
Date |4.2.4 |C|x| | | | |
Sender |4.2.5 |C| | |x| | |
Return-Path |4.2.6 |C| | | | |x|
Message-ID |4.2.7 |C|x| | | | |
Reply-To |4.2.8 |C| | | |x| |
Received |4.2.9 |C|x| | | | |
MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | |
Content-Type |4.2.11 |C|x| | | | |
Content-Transfer-Encoding |4.2.12 |C|x| | | | |
Sensitivity |4.2.13 |C| | |x| | |
Importance |4.2.14 |C| | |x| | |
Subject |4.2.15 |C| |x| | | |
Disposition-notification-to |4.7 |C| |x| | | |
Other Headers |4.2 |C| | |x| | |
| | | | | | | |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
Receiving inbound messages | | | | | | | |
From |4.2.1 |C|x| | | | |
Present text personal name |4.2.1 |C| | |x| | |
To |4.2.2 |C|x| | | | |
cc |4.2.3 |C| | |x| | |
Date |4.2.4 |C|x| | | | |
Conversion of Date to local time |4.2.4 |C| |x| | | |
Sender |4.2.5 |C| | |x| | |
Return-Path |4.2.6 |C| |x| | | |
Message-ID |4.2.7 |C| | |x| | |
MDN requested |4.2.7 |C|x| | | | |
Reply-To |4.2.8 |C| | |x| | |
Received |4.2.9 |C| | |x| | |
MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | |
Content Type |4.2.11 |C|x| | | | |
Content-Transfer-Encoding |4.2.12 |C|x| | | | |
Sensitivity |4.2.13 |C|x| | | | |2
Importance |4.2.14 |C| | |x| | |
Subject |4.2.15 |C| | |x| | |
Disposition-notification-to |4.7 |C| |x| | | |
Other Headers |4.2 |C|x| | | | |3
| | | | | | | |
Message Content Encoding: | | | | | | | |
Sending outbound audio/fax contents | | | | | | | |
7BIT |4.2.12 |C| | | | |x|
8BIT |4.2.12 |C| | | | |x|
Quoted Printable |4.2.12 |C| | | | |x|
Base64 |4.2.12 |C|x| | | | |4
Binary |4.2.12 |C| |x| | | |5
Receiving inbound message contents | | | | | | | |
7BIT |4.2.12 |C|x| | | | |
8BIT |4.2.12 |C|x| | | | |
Quoted Printable |4.2.12 |C|x| | | | |
Base64 |4.2.12 |C|x| | | | |
Binary |4.2.12 |C|x| | | | |5
| | | | | | | |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
Receiving inbound messages | | | | | | | |
From |4.2.1 |C|x| | | | |
Present text personal name |4.2.1 |C| | |x| | |
To |4.2.2 |C|x| | | | |
cc |4.2.3 |C| | |x| | |
Date |4.2.4 |C|x| | | | |
Conversion of Date to local time |4.2.4 |C| |x| | | |
Sender |4.2.5 |C| | |x| | |
Return-Path |4.2.6 |C| |x| | | |
Message-ID |4.2.7 |C| | |x| | |
MDN requested |4.2.7 |C|x| | | | |
Reply-To |4.2.8 |C| | |x| | |
Received |4.2.9 |C| | |x| | |
MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | |
Content Type |4.2.11 |C|x| | | | |
Content-Transfer-Encoding |4.2.12 |C|x| | | | |
Sensitivity |4.2.13 |C|x| | | | |2
Importance |4.2.14 |C| | |x| | |
Subject |4.2.15 |C| | |x| | |
Disposition-notification-to |4.7 |C| |x| | | |
Other Headers |4.2 |C|x| | | | |3
| | | | | | | |
Message Content Encoding: | | | | | | | |
Sending outbound audio/fax contents | | | | | | | |
7BIT |4.2.12 |C| | | | |x|
8BIT |4.2.12 |C| | | | |x|
Quoted Printable |4.2.12 |C| | | | |x|
Base64 |4.2.12 |C|x| | | | |4
Binary |4.2.12 |C| |x| | | |5
Receiving inbound message contents | | | | | | | |
7BIT |4.2.12 |C|x| | | | |
8BIT |4.2.12 |C|x| | | | |
Quoted Printable |4.2.12 |C|x| | | | |
Base64 |4.2.12 |C|x| | | | |
Binary |4.2.12 |C|x| | | | |5
| | | | | | | |
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
Message Content Types: | | | | | | | |
Sending outbound messages | | | | | | | |
Multipart/Voice-Message |4.4.1 |C|x| | | | |
Message/RFC822 |4.4.2 |C| |x| | | |
Audio/32KADPCM |4.4.3 |C|x| | | | |
Content-Description |4.3.1 |C| | |x| | |
Content-Disposition |4.3.2 |C|x| | | | |
Content-Duration |4.3.3 |C| | |x| | |
Content-Language |4.3.4 |C| | |x| | |
Image/TIFF; application=faxbw |4.4.4 |C|x| | | | |7
Text/Directory |4.5.2 |C| | | |x| |9
Text/plain |4.5.4 |C| | | |x| |
Audio/* or Image/* (other encodings) |4.5.3 |C| | | |x| |
Other contents |4.5 |C| | | | |x|
Multipart/Mixed |4.5.1 |C| | |x| | |
Text/plain |4.5.4 |C| | |x| | |
Multipart/Report |4.6, 4.7 |C|x| | | | |
human-readable part is voice |4.6, 4.7 |C| |x| | | |
human-readable part is text |4.6, 4.7 |C| | |x| | |
Message/Delivery-Status |4.6 |C|x| | | | |
Message/Disposition-Notification |4.7 |C| |x| | | |
Other contents |4.5 |C| | | |x| |6
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
Message Content Types: | | | | | | | |
Sending outbound messages | | | | | | | |
Multipart/Voice-Message |4.4.1 |C|x| | | | |
Message/RFC822 |4.4.2 |C| |x| | | |
Audio/32KADPCM |4.4.3 |C|x| | | | |
Content-Description |4.3.1 |C| | |x| | |
Content-Disposition |4.3.2 |C|x| | | | |
Content-Duration |4.3.3 |C| | |x| | |
Content-Language |4.3.4 |C| | |x| | |
Image/TIFF; application=faxbw |4.4.4 |C|x| | | | |7
Text/Directory |4.5.2 |C| | | |x| |9
Text/plain |4.5.4 |C| | | |x| |
Audio/* or Image/* (other encodings) |4.5.3 |C| | | |x| |
Other contents |4.5 |C| | | | |x|
Multipart/Mixed |4.5.1 |C| | |x| | |
Text/plain |4.5.4 |C| | |x| | |
Multipart/Report |4.6, 4.7 |C|x| | | | |
human-readable part is voice |4.6, 4.7 |C| |x| | | |
human-readable part is text |4.6, 4.7 |C| | |x| | |
Message/Delivery-Status |4.6 |C|x| | | | |
Message/Disposition-Notification |4.7 |C| |x| | | |
Other contents |4.5 |C| | | |x| |6
Receiving in inbound messages | | | | | | | |
Multipart/Voice-Message |4.4.1 |C|x| | | | |
Message/RFC822 |4.4.2 |C|x| | | | |
Audio/32KADPCM |4.4.3 |C|x| | | | |
Content-Description |4.3.1 |C| | |x| | |
Content-Disposition |4.3.2 |C| |x| | | |
Content-Duration |4.3.3 |C| | |x| | |
Content-Language |4.3.4 |C| | |x| | |
Image/TIFF; application=faxbw |4.4.4 |C| |x| | | |8
Text/Directory |4.5.2 |C|x| | | | |9
Text/plain |4.5.4 |C| | |x| | |
Audio/* or Image/* (other encodings) |4.5.3 |C| | |x| | |
Other contents |4.5 |C| | |x| | |
Multipart/Mixed |4.5.1 |C| | |x| | |
Receiving in inbound messages | | | | | | | |
Multipart/Voice-Message |4.4.1 |C|x| | | | |
Message/RFC822 |4.4.2 |C|x| | | | |
Audio/32KADPCM |4.4.3 |C|x| | | | |
Content-Description |4.3.1 |C| | |x| | |
Content-Disposition |4.3.2 |C| |x| | | |
Content-Duration |4.3.3 |C| | |x| | |
Content-Language |4.3.4 |C| | |x| | |
Image/TIFF; application=faxbw |4.4.4 |C| |x| | | |8
Text/Directory |4.5.2 |C|x| | | | |9
Text/plain |4.5.4 |C| | |x| | |
Audio/* or Image/* (other encodings) |4.5.3 |C| | |x| | |
Other contents |4.5 |C| | |x| | |
Multipart/Mixed |4.5.1 |C| | |x| | |
| | | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
------------------------------------------|-----------|-|-|-|-|-|-|-
| | | | | | | |
Text/plain |4.5.4 |C|x| | | | |
Multipart/Report |4.6, 4.7 |C|x| | | | |
human-readable part is voice |4.6, 4.7 |C|x| | | | |
human-readable part is text |4.6, 4.7 |C|x| | | | |
Message/Delivery-Status |4.6 |C|x| | | | |
Message/Disposition-Notification |4.7 |C| |x| | | |
Other contents |4.5 |C| | |x| | |6
| | | | | | | |
Forwarded Messages | | | | | | | |
use Message/RFC822 construct |4.8 |C| |x| | | |
simulate headers if none available |4.8 |C| |x| | | |
| | | | | | | |
Reply Messages |4.9 |C|x| | | | |
send to Reply-To, else From address |4.2.8 |C| | |x| | |
send to non-mail-user |4.9 |C| | | |x| |
| | | | | | | |
Notifications | | | | | | | |
use Multipart/Report format |4.6, 4.7 |C|x| | | | |
always send error on non-delivery |4.6 |C|x| | | | |
send error messages to return-path |4.2.6 |C|x| | | | |
| | | | | | | |
Message Transport Protocol: | | | | | | | |
Base ESMTP Commands | | | | | | | |
HELO |5.1 |T|x| | | | |
MAIL FROM |5.1 |T|x| | | | |
RCPT TO |5.1 |T|x| | | | |
DATA |5.1 |T|x| | | | |
TURN |5.1 |T| | | | |x|
QUIT |5.1 |T|x| | | | |
RSET |5.1 |T|x| | | | |
VRFY |5.1 |T| | |x| | |
EHLO |5.1 |T|x| | | | |
BDAT |5.1 |T| | |x| | |5
| | | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
------------------------------------------|-----------|-|-|-|-|-|-|-
| | | | | | | |
Text/plain |4.5.4 |C|x| | | | |
Multipart/Report |4.6, 4.7 |C|x| | | | |
human-readable part is voice |4.6, 4.7 |C|x| | | | |
human-readable part is text |4.6, 4.7 |C|x| | | | |
Message/Delivery-Status |4.6 |C|x| | | | |
Message/Disposition-Notification |4.7 |C| |x| | | |
Other contents |4.5 |C| | |x| | |6
| | | | | | | |
Forwarded Messages | | | | | | | |
use Message/RFC822 construct |4.8 |C| |x| | | |
simulate headers if none available |4.8 |C| |x| | | |
| | | | | | | |
Reply Messages |4.9 |C|x| | | | |
send to Reply-To, else From address |4.2.8 |C| | |x| | |
send to non-mail-user |4.9 |C| | | |x| |
| | | | | | | |
Notifications | | | | | | | |
use Multipart/Report format |4.6, 4.7 |C|x| | | | |
always send error on non-delivery |4.6 |C|x| | | | |
send error messages to return-path |4.2.6 |C|x| | | | |
| | | | | | | |
Message Transport Protocol: | | | | | | | |
Base ESMTP Commands | | | | | | | |
HELO |5.1 |T|x| | | | |
MAIL FROM |5.1 |T|x| | | | |
RCPT TO |5.1 |T|x| | | | |
DATA |5.1 |T|x| | | | |
TURN |5.1 |T| | | | |x|
QUIT |5.1 |T|x| | | | |
RSET |5.1 |T|x| | | | |
VRFY |5.1 |T| | |x| | |
EHLO |5.1 |T|x| | | | |
BDAT |5.1 |T| | |x| | |5
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
| | | | | | | |
ESMTP Keywords & Parameters | | | | | | | |
DSN |5.2.1 |T|x| | | | |
NOTIFY |5.2.1 |T|x| | | | |
RET |5.2.1 |T| |x| | | |
ENVID |5.2.1 |T| | |x| | |
ORCPT |5.2.1 |T| | |x| | |
SIZE |5.2.2 |T|x| | | | |
ENHANCEDSTATUSCODES |5.2.3 |T| |x| | | |
PIPELINING |5.2.4 |T| |x| | | |
CHUNKING |5.2.5 |T| | |x| | |
BINARYMIME |5.2.6 |T| | |x| | |
| | | | | | | |
ESMTP-SMTP Downgrading | | | | | | | |
send delivery report upon downgrade |5.3 |T|x| | | | |
| | | | | | | |
Directory Address Resolution | | | | | | | |
provide facility to resolve addresses |6 |C| |x| | | |
use headers to populate local directory |6 |C| | |x| | |
| | | | | | | |
Management Protocols: | | | | | | | |
Network management |7.1 |T| | |x| | |
-------------------------------------------|----------|-|-|-|-|-|-|-
| | | | |S| |
| | | | | |H| |F
| | | | | |O|M|o
| | | |S| |U|U|o
| | | |H| |L|S|t
| |A|M|O| |D|T|n
| |R|U|U|M| | |o
| |E|S|L|A|N|N|t
| |A|T|D|Y|O|O|t
FEATURE |SECTION | | | | |T|T|e
-------------------------------------------|----------|-|-|-|-|-|-|-
| | | | | | | |
ESMTP Keywords & Parameters | | | | | | | |
DSN |5.2.1 |T|x| | | | |
NOTIFY |5.2.1 |T|x| | | | |
RET |5.2.1 |T| |x| | | |
ENVID |5.2.1 |T| | |x| | |
ORCPT |5.2.1 |T| | |x| | |
SIZE |5.2.2 |T|x| | | | |
ENHANCEDSTATUSCODES |5.2.3 |T| |x| | | |
PIPELINING |5.2.4 |T| |x| | | |
CHUNKING |5.2.5 |T| | |x| | |
BINARYMIME |5.2.6 |T| | |x| | |
| | | | | | | |
ESMTP-SMTP Downgrading | | | | | | | |
send delivery report upon downgrade |5.3 |T|x| | | | |
| | | | | | | |
Directory Address Resolution | | | | | | | |
provide facility to resolve addresses |6 |C| |x| | | |
use headers to populate local directory |6 |C| | |x| | |
| | | | | | | |
Management Protocols: | | | | | | | |
Network management |7.1 |T| | |x| | |
-------------------------------------------|----------|-|-|-|-|-|-|-
Footnotes:
脚注：
1. SHOULD leave blank if all recipients are not known or resolvable. 2. If a sensitive message is received by a system that does not support sensitivity, then it MUST be returned to the originator with an appropriate error notification. Also, a received sensitive message MUST NOT be forwarded to anyone. 3. If the additional header fields are not understood they MAY be ignored. 4. When binary transport is not available. 5. When binary transport is available.
1. 如果所有收件人都未知或无法解决，则应留空。2.如果不支持敏感度的系统接收到敏感消息，则必须将其返回给发起人，并发出相应的错误通知。此外，收到的敏感信息不得转发给任何人。3.如果未理解其他标题字段，则可能会忽略这些字段。4.当二进制传输不可用时。5.当二进制传输可用时。
6. Other un-profiled contents MUST only be sent by bilateral agreement. 7. If fax is supported. 8. If the fax content cannot be presented it MAY be dropped. 9. Handling of a vCard in text/directory is no longer defined.
6. 其他非概要内容只能通过双边协议发送。7.如果支持传真。8.如果无法显示传真内容，则可能会将其删除。9不再定义文本/目录中vCard的处理。
The following message is a full-featured message addressed to two recipients. The message includes the sender's spoken name, spoken subject and a short speech segment. The message is marked as important and private.
以下消息是一条功能齐全的消息，发送给两位收件人。该消息包括发送者的口头姓名、口头主题和简短的语音片段。该消息被标记为重要和私有。
To: +19725551212@vm1.mycompany.com
To: +16135551234@VM1.mycompany.com
From: "Parsons, Glenn" <12145551234@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: 123456789@VM2.mycompany.com
Sensitivity: Private
Importance: High
To: +19725551212@vm1.mycompany.com
To: +16135551234@VM1.mycompany.com
From: "Parsons, Glenn" <12145551234@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: 123456789@VM2.mycompany.com
Sensitivity: Private
Importance: High
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part1@VM2-4321
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part1@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Name data) fgdhgddlkgpokpeowrit09==
GLSLFDSLSERTIFLKTPFPGKTPORTPKTPFGTPOITPDADASSDADSDASD（这是base-64语音名称数据的示例）FGDHGDDLKGPOOKPEOWRIT09==
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Spoken-Subject
Content-Language: en-US
Content-ID: part2@VM2-4321
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Spoken-Subject
Content-Language: en-US
Content-ID: part2@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Subject data) fgdhgddlkgpokpeowrit09==
GLSLFDSLSERTIFLKTFPGKTPORTPKTPFGTPOITPDADASSDADSDASD（这是base-64口语主题数据的一个示例）FGDHGDDLKGPOOKPEOWRIT09==
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Description: Brand X Voice Message
Content-Disposition: inline; voice=Voice-Message; filename=msg1.726
Content-Duration: 25
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Description: Brand X Voice Message
Content-Disposition: inline; voice=Voice-Message; filename=msg1.726
Content-Duration: 25
iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq
(This is a sample of the base64 message data) zb8tFdLTQt1PXj
u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9==
iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq
(This is a sample of the base64 message data) zb8tFdLTQt1PXj
u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9==
--MessageBoundary- - - -
--MessageBoundary- - - -
The following message is a forwarded single segment voice. Both the forwarded message and the forwarding message contain the senders spoken names.
以下消息是转发的单段语音。转发消息和转发消息都包含发件人的语音名称。
To: +12145551212@vm1.mycompany.com
From: "Vaudreuil, Greg" <+19725552345@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: ABCD-123456789@VM2.mycompany.com
To: +12145551212@vm1.mycompany.com
From: "Vaudreuil, Greg" <+19725552345@VM2.mycompany.com>
Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
MIME-Version: 1.0 (Voice 2.0)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: ABCD-123456789@VM2.mycompany.com
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part3@VM2-4321
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part3@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Name data) fgdhgd dlkgpokpeowrit09==
GLSLFDSLSERTIFLKTFPGTPGKTPORTPKTPFGTPOITPDADASSDASD（这是base-64语音名称数据的示例）fgdhgd DLKGPOOKPEOWRIT09==
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Description: Forwarded Message Annotation
Content-Disposition: inline; voice=Voice-Message
Content-Transfer-Encoding: Base64
--MessageBoundary
Content-type: Audio/32KADPCM
Content-Description: Forwarded Message Annotation
Content-Disposition: inline; voice=Voice-Message
Content-Transfer-Encoding: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is the voiced introductory remarks encoded in base64) jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW dlkgpokpeowrit09==
GLSLFDSLSERTIFLKTFPGKTPORTPKTPFGTPOITPDADASSDASD（这是以base64编码的有声介绍性评论）jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW DLKGPOPKPEOWRIT09==
--MessageBoundary Content-type: Message/RFC822 Content-Transfer-Encoding: 7bit
--MessageBoundary内容类型：Message/RFC822内容传输编码：7bit
To: +19725552345@VM2.mycompany.com
From: "Parsons, Glenn, W." <+16135551234@VM1.mycompany.com>
Date: Mon, 26 Aug 93 8:23:10 -0500 (EST)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary2"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Voice 2.0)
To: +19725552345@VM2.mycompany.com
From: "Parsons, Glenn, W." <+16135551234@VM1.mycompany.com>
Date: Mon, 26 Aug 93 8:23:10 -0500 (EST)
Content-type: Multipart/Voice-Message; Version=2.0;
Boundary="MessageBoundary2"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0 (Voice 2.0)
--MessageBoundary2
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part6@VM2-4321
--MessageBoundary2
Content-type: Audio/32KADPCM
Content-Transfer-Encoding: Base64
Content-Disposition: inline; voice=Originator-Spoken-Name
Content-Language: en-US
Content-ID: part6@VM2-4321
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is a sample of the base-64 Spoken Name data) fgdhgd dlkgpokpeowrit09==
GLSLFDSLSERTIFLKTFPGTPGKTPORTPKTPFGTPOITPDADASSDASD（这是base-64语音名称数据的示例）fgdhgd DLKGPOOKPEOWRIT09==
--MessageBoundary2
Content-type: Audio/32KADPCM
Content-Disposition: inline; voice=Voice-Message
Content-Transfer-Encoding: Base64
--MessageBoundary2
Content-type: Audio/32KADPCM
Content-Disposition: inline; voice=Voice-Message
Content-Transfer-Encoding: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd (This is the original message audio data) fgwersdfmniwrjj jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW dlkgpokpeowrit09==
GLSLFDSLSERTIFLKTFPGKTPORTPKTPFGTPOITPDADASSDADSDASD（这是原始消息音频数据）FGWERSDFMNIWRJJRGOIJ3O45ITJ09FIUVDKJGWLAKGQ93IJKPOKFPGOKQ90GQ5TKJPOKFGW dlkgpokpeowrit09==
--MessageBoundary2--
--消息边界2--
--MessageBoundary--
--消息边界--
The following example is for a DSN sent to the sender of a message by a VPIM gateway at VM1.company.com for a mailbox which does not exist.
以下示例适用于VM1.company.com上的VPIM网关为不存在的邮箱发送给邮件发件人的DSN。
Date: Thu, 7 Jul 1994 17:16:05 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@vm.company.com>
Message-ID: <199407072116.RAA14128@vm1.company.com>
Subject: Returned voice message
To: 2175552345@VM2.mycompany.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="RAA14128.773615765/VM1.COMPANY.COM"
Date: Thu, 7 Jul 1994 17:16:05 -0400
From: Mail Delivery Subsystem <MAILER-DAEMON@vm.company.com>
Message-ID: <199407072116.RAA14128@vm1.company.com>
Subject: Returned voice message
To: 2175552345@VM2.mycompany.com
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
boundary="RAA14128.773615765/VM1.COMPANY.COM"
--RAA14128.773615765/VM1.COMPANY.COM
Content-type: Audio/32KADPCM
Content-Description: Spoken Delivery Status Notification
Content-Disposition: inline; voice= Voice-Message-Notification
Content-Transfer-Encoding: Base64
--RAA14128.773615765/VM1.COMPANY.COM
Content-type: Audio/32KADPCM
Content-Description: Spoken Delivery Status Notification
Content-Disposition: inline; voice= Voice-Message-Notification
Content-Transfer-Encoding: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd (This is a voiced description of the error in base64) jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW dlkgpokpeowrit09==
GLSLFDSLSERTIFLKTFPGKTPORTPKTPFGTPOITPDADFFSSSDADSDASSD（这是base64中错误的语音描述）jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW DLKGPOOKPEWRIT09==
--RAA14128.773615765/VM1.COMPANY.COM Content-type: Message/Delivery-Status
--RAA14128.773615765/VM1.COMPANY.COM内容类型：消息/传递状态
Reporting-MTA: dns; vm1.company.com
报告MTA:dns；vm1.company.com
Original-Recipient: rfc822; 2145551234@VM1.mycompany.com
Final-Recipient: rfc822; 2145551234@VM1.mycompany.com
Action: failed
Status: 5.1.1 (User does not exist)
Diagnostic-Code: smtp; 550 Mailbox not found
Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
Original-Recipient: rfc822; 2145551234@VM1.mycompany.com
Final-Recipient: rfc822; 2145551234@VM1.mycompany.com
Action: failed
Status: 5.1.1 (User does not exist)
Diagnostic-Code: smtp; 550 Mailbox not found
Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
--RAA14128.773615765/VM1.COMPANY.COM content-type: Message/RFC822
--RAA14128.773615765/VM1.COMPANY.COM内容类型：Message/RFC822
[original VPIM message goes here]
[此处显示原始VPIM消息]
--RAA14128.773615765/VM1.COMPANY.COM--
--RAA14128.773615765/VM1.COMPANY.COM--
The following example is for an MDN sent to the original sender for a message that has been played. This delivered VPIM message was received by a corporate gateway and relayed to a unified mailbox.
以下示例适用于已播放的消息发送给原始发件人的MDN。此已传递的VPIM消息由公司网关接收并转发到统一邮箱。
Date: Thu, 7 Jul 1994 17:16:05 -0400
From: "Greg Vaudreuil" <22722@vm.company.com>
Message-ID: <199407072116.RAA14128@exchange.company.com>
Subject: Voice message played
To: 2175552345@VM2.mycompany.com
MIME-Version: 1.0
Content-Type: multipart/report;
Report-type=disposition-notification;
Boundary="RAA14128.773615765/EXCHANGE.COMPANY.COM"
Date: Thu, 7 Jul 1994 17:16:05 -0400
From: "Greg Vaudreuil" <22722@vm.company.com>
Message-ID: <199407072116.RAA14128@exchange.company.com>
Subject: Voice message played
To: 2175552345@VM2.mycompany.com
MIME-Version: 1.0
Content-Type: multipart/report;
Report-type=disposition-notification;
Boundary="RAA14128.773615765/EXCHANGE.COMPANY.COM"
--RAA14128.773615765/EXCHANGE.COMPANY.COM
Content-type: Audio/32KADPCM
Content-Description: Spoken Disposition Notification
Content-Disposition: inline; voice= Voice-Message-Notification
Content-Transfer-Encoding: Base64
--RAA14128.773615765/EXCHANGE.COMPANY.COM
Content-type: Audio/32KADPCM
Content-Description: Spoken Disposition Notification
Content-Disposition: inline; voice= Voice-Message-Notification
Content-Transfer-Encoding: Base64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd (Voiced description of the disposition action in base64) jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW dlkgpokpeowrit09==
GLSLFDSLSERTIFLKTFPGKT端口RPKTPFGTPOITPDADFFSSSDADSDASSD（base64中处置行动的语音描述）jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW DLKGPOPOKPEO09==
--RAA14128.773615765/EXCHANGE.COMPANY.COM Content-type: Message/Disposition-Notification
--RAA14128.773615765/EXCHANGE.COMPANY.COM内容类型：消息/处置通知
Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)
报告UA:gregs-laptop.dallas.company.com（Unified FooMail 3.0）
Original-Recipient: rfc822;22722@vm.company.com
Final-Recipient: rfc822;Greg.Vaudreuil@foomail.company.com
Original-Message-ID: <199509192301.12345@vm2.mycompany.com>
Disposition: manual-action/MDN-sent-automatically; displayed
Original-Recipient: rfc822;22722@vm.company.com
Final-Recipient: rfc822;Greg.Vaudreuil@foomail.company.com
Original-Message-ID: <199509192301.12345@vm2.mycompany.com>
Disposition: manual-action/MDN-sent-automatically; displayed
--RAA14128.773615765/EXCHANGE.COMPANY.COM Content-type: Message/RFC822
--RAA14128.773615765/EXCHANGE.COMPANY.COM内容类型：Message/RFC822
[original VPIM message goes here]
[此处显示原始VPIM消息]
--RAA14128.773615765/EXCHANGE.COMPANY.COM--
--RAA14128.773615765/EXCHANGE.COMPANY.COM--
The following common voice processing errors and their corresponding status codes are given as examples. The text after the error codes is intended only for reference to describe the error code. Implementations should provide implementation-specific informative comments after the error code rather than the text below.
下面给出了以下常见的语音处理错误及其相应的状态代码作为示例。错误代码后的文本仅用于描述错误代码的参考。实现应该在错误代码之后提供特定于实现的信息性注释，而不是下面的文本。
Error condition RFC 1893 Error codes
----------------------------- --------------------------------
Error condition RFC 1893 Error codes
----------------------------- --------------------------------
Analog delivery failed 4.4.1 Persistent connection error because remote system is busy - busy
模拟传输失败4.4.1由于远程系统忙，导致持续连接错误-忙
Analog delivery failed 4.4.1 Persistent protocol error because remote system is - no answer from host ring-no-answer
模拟传输失败4.4.1永久协议错误，因为远程系统为-主机无应答无应答
Remote system did not answer 5.5.5 Permanent protocol error AMIS-Analog handshake ("D" in - wrong version response to "C" at connect time)
远程系统未回答5.5.5永久性协议错误AMIS模拟握手（“D”在-连接时对“C”的错误版本响应）
Mailbox does not exist 5.1.1 Permanent mailbox error - does not exist
邮箱不存在5.1.1永久邮箱错误-不存在
Mailbox full or over quota 4.2.2 Persistent mailbox error - full
邮箱已满或超过配额4.2.2永久邮箱错误-已满
Disk full 4.3.1 Persistent system error - full
磁盘已满4.3.1永久性系统错误-已满
Command out of sequence 5.5.1 Permanent protocol error - invalid command
命令顺序错误5.5.1永久协议错误-命令无效
Frame Error 5.5.2 Permanent protocol error - syntax error
帧错误5.5.2永久协议错误-语法错误
Mailbox does not support FAX 5.6.1 Permanent media error - not supported
邮箱不支持传真5.6.1永久介质错误-不支持
Mailbox does not support TEXT 5.6.1 Permanent media error - not supported
邮箱不支持文本5.6.1永久性媒体错误-不支持
Sender is not authorized 5.7.1 Permanent security error - sender not authorized
发件人未授权5.7.1永久性安全错误-发件人未授权
Message marked private, but 5.3.3 Permanent system error system is not private capable - not feature capable
消息标记为专用，但5.3.3永久系统错误系统不支持专用-不支持功能
The following common voice processing disposition conditions and their corresponding MDN Disposition (which contains the disposition mode, type and modifier, if applicable) are given as examples. Implementers should refer to [MDN] for a full description of the format of message disposition notifications.
下面给出了常见的语音处理配置条件及其相应的MDN配置（包含配置模式、类型和修改器，如果适用）作为示例。实现者应参考[MDN]了解消息处置通知格式的完整描述。
Notification event MDN Disposition mode, type & modifier
------------------------------ ------------------------------------
Notification event MDN Disposition mode, type & modifier
------------------------------ ------------------------------------
Message played by recipient, manual-action/MDN-sent-automatically; receipt automatically returned displayed
收件人播放的消息，手动操作/MDN自动发送；显示自动返回的收据
Message deleted from mailbox manual-action/MDN-sent-automatically; by user without listening deleted
自动发送从邮箱手动操作删除的邮件/MDN；按用户删除而不侦听
Message cleared when mailbox manual-action/MDN-sent-automatically; deleted by admin deleted/mailbox-terminated
邮箱手动操作/MDN自动发送时清除消息；已被管理员删除/邮箱已终止
Message automatically deleted automatic-action/ when older than administrator MDN-sent-automatically; deleted/ set threshold expired
消息自动删除自动操作/早于管理员时自动发送MDN；已删除/设置阈值已过期
Message processed, however manual-action/MDN-sent-automatically;
audio encoding unknown - processed/error
unable to play to user Error: unknown audio encoding
Message processed, however manual-action/MDN-sent-automatically;
audio encoding unknown - processed/error
unable to play to user Error: unknown audio encoding
There are no changes to the registration per [DISP] of the voice content disposition parameter defined in the earlier VPIM V2 document, RFC 2421. There are no changes to the registration per [MIME4] of the Multipart/voice-message content type defines in the earlier VPIM v2 document, RFC 2423.
在先前的VPIM V2文档RFC 2421中定义的语音内容配置参数的每[DISP]注册没有更改。根据[MIME4]对先前VPIM v2文档RFC 2423中定义的多部分/语音消息内容类型的注册没有任何更改。
Both are presented here for information.
这两个都是在这里提供的信息。
To: IANA@IANA.ORG
致：IANA@IANA.ORG
Subject: Registration of new Content-Disposition parameter
主题：注册新内容处置参数
Content-Disposition parameter name: voice
内容配置参数名称：语音
Allowable values for this parameter:
此参数的允许值：
Voice-Message - the primary voice message, Voice-Message-Notification - a spoken delivery notification or spoken disposition notification, Originator-Spoken-Name - the spoken name of the originator, Recipient-Spoken-Name - the spoken name of the recipient if available to the originator and present if there is ONLY one recipient, Spoken-Subject- the spoken subject of the message, typically spoken by the originator
语音信息-主要语音信息，语音信息通知-口头送达通知或口头处置通知，发起者口头姓名-发起者的口头姓名，收件人口头姓名-收件人的口头姓名（如果发起者可用），如果只有一个收件人，则提供，口语主语-信息的口语主语，通常由发起者说
Description:
说明：
In order to distinguish between the various types of audio contents in a VPIM voice message a new disposition parameter "voice" is defined with the preceding values to be used as appropriate. Note that there SHOULD only be one instance of each of these types of audio contents per message level. Additional instances of a given type (i.e., parameter value) may occur within an attached forwarded voice message.
为了区分VPIM语音消息中的各种类型的音频内容，定义了一个新的配置参数“voice”，并根据需要使用前面的值。请注意，对于每种类型的音频内容，每个消息级别应该只有一个实例。附加的转发语音消息中可能会出现给定类型（即参数值）的其他实例。
To: ietf-types@iana.org Subject: Registration of MIME media type Multipart/voice-message
致：ietf-types@iana.org主题：注册MIME媒体类型多部分/语音消息
MIME media type name: multipart
MIME媒体类型名称：多部分
MIME subtype name: voice-message
MIME子类型名称：语音消息
Required parameters: boundary, version
所需参数：边界、版本
The use of boundary is defined in [MIME2]
[MIME2]中定义了边界的使用
The version parameter that contains the value "2.0" if enclosed content conforms to [VPIM2R2]. The absence of this parameter indicates conformance to the previous version defined in RFC 1911 [VPIM1].
如果所附内容符合[VPIM2R2]，则包含值“2.0”的版本参数。缺少此参数表示符合RFC 1911[VPIM1]中定义的先前版本。
Optional parameters: none
可选参数：无
Encoding considerations: 7bit, 8bit or Binary
编码注意事项：7位、8位或二进制
Security considerations:
安全考虑：
This definition identifies the content as being a voice message. In some environments (though likely not the majority), the loss of the anonymity of the content may be a security issue.
此定义将内容标识为语音消息。在某些环境中（虽然可能不是大多数），内容的匿名性丢失可能是一个安全问题。
Interoperability considerations:
互操作性注意事项：
Systems developed to conform with [VPIM1] may not conform to this registration. Specifically, the required version will likely be absent, in this case the recipient system should still be able to accept the message and will be able to handle the content. The VPIM v1 positional identification, however, would likely be lost.
为符合[VPIM1]而开发的系统可能不符合本注册。具体来说，可能缺少所需的版本，在这种情况下，收件人系统应该仍然能够接受消息并能够处理内容。然而，VPIM v1位置标识可能会丢失。
Published specification: This document
已发布规范：本文件
Applications that use this media type:
使用此媒体类型的应用程序：
Primarily voice messaging
主要是语音信息
Additional information:
其他信息：
Magic number(s): none
File extension(s): .VPM
Macintosh File Type Code(s): VPIM
Magic number(s): none
File extension(s): .VPM
Macintosh File Type Code(s): VPIM
Person & email address to contact for further information:
联系人和电子邮件地址，以获取更多信息：
Glenn W. Parsons gparsons@nortelnetworks.com
格伦·W·帕森斯gparsons@nortelnetworks.com
Gregory M. Vaudreuil gregv@ieee.org
格雷戈里·M·沃德鲁伊gregv@ieee.org
Intended usage: COMMON
预期用途：普通
Author/Change controller:
作者/变更控制员：
Glenn W. Parsons & Gregory M. Vaudreuil
格伦·W·帕森斯和格雷戈里·M·沃德鲁伊
The updated profile in this document is based on the implementation and operational deployment experience of several vendors. The changes are categorized as general, content, transport and conformance. They are summarized below:
本文档中的更新配置文件基于多家供应商的实施和运营部署经验。变更分为一般变更、内容变更、传输变更和一致性变更。总结如下：
1. General
1. 全体的
- Various and substantial editorial updates to improve readability.
- 各种实质性的编辑更新，以提高可读性。
- Separated send rules from receive rules to aid clarity.
- 将发送规则与接收规则分开以帮助清晰。
- Clarified the behavior upon reception of unrecognized content types expected with the interworking between voice and unified messaging systems. (E.g., Unsupported non-audio contents should be discarded to deliver the audio message.)
- 阐明了语音和统一消息系统之间互通时接收到无法识别的内容类型时的行为。（例如，应丢弃不受支持的非音频内容以传递音频消息。）
- Reworked the sensitivity requirements to align them with X.400. Eliminated dependencies upon the MIXER documents.
- 修改了灵敏度要求，使其与X.400一致。消除了对混合器文档的依赖。
- Reorganized the content-type descriptions for clarity
- 为清晰起见，重新组织了内容类型描述
2. Content
2. 所容纳之物
- Changed handling of received lines by a gateway to SHOULD NOT delete in a gateway. In gateways to systems such as AMIS, it is not possible to preserve this information. It is intended that such systems be able to claim conformance.
- 将网关对接收线路的处理更改为不应在网关中删除。在AMIS等系统的网关中，不可能保存此信息。旨在使此类系统能够声明符合性。
- Eliminated the vCard as a supported VPIM V2 content type.
- 将vCard作为受支持的VPIM V2内容类型删除。
- Merged in text from RFC 2423 (Multipart/voice-message)
- 合并在RFC 2423的文本中（多部分/语音消息）
3. Transport
3. 运输
- None
- 没有一个
4. Conformance
4. 一致性
- Aligned the table of Appendix A to the requirements in the text.
- 将附录A中的表格与正文中的要求对齐。
Gregory M. Vaudreuil Lucent Technologies 7291 Williamson Rd Dallas, TX 75214 United States
Gregory M.Vaudreuil-Lucent Technologies美国德克萨斯州达拉斯威廉森路7291号，邮编75214
EMail: gregv@ieee.org
EMail: gregv@ieee.org
Glenn W. Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada
加拿大K1Y 4H7渥太华C站Glenn W.Parsons Nortel Networks邮政信箱3511
Phone: +1-613-763-7582
Fax: +1-613-763-2697
EMail: GParsons@NortelNetworks.com
Phone: +1-613-763-7582
Fax: +1-613-763-2697
EMail: GParsons@NortelNetworks.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编辑功能的资金目前由互联网协会提供。