Network Working Group G. Parsons
Request for Comments: 4024 Nortel Networks
Category: Informational J. Maruszak
July 2005
Network Working Group G. Parsons
Request for Comments: 4024 Nortel Networks
Category: Informational J. Maruszak
July 2005
Voice Messaging Client Behaviour
语音消息客户端行为
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
This document defines the expected behaviour of a client to various aspects of a Voice Profile for Internet Mail (VPIM) message or any voice and/or fax message.
本文档定义了客户端对Internet Mail（VPIM）消息或任何语音和/或传真消息的语音配置文件的各个方面的预期行为。
Table of Contents
目录
1. Introduction.................................................. 2
2. Conventions Used in This Document............................. 2
3. Message Icon.................................................. 3
3.1. Proposed Mechanism...................................... 3
4. Sender's Number Column........................................ 3
4.1. Proposed Mechanism...................................... 4
5. Message Size.................................................. 4
5.1. Proposed Mechanism...................................... 4
6. Media Viewer.................................................. 5
6.1. Proposed Mechanism...................................... 6
7. Mark Message as Read.......................................... 6
7.1. Proposed Mechanism...................................... 6
8. Security Considerations....................................... 7
9. Informative References........................................ 7
10. Acknowledgments............................................... 8
1. Introduction.................................................. 2
2. Conventions Used in This Document............................. 2
3. Message Icon.................................................. 3
3.1. Proposed Mechanism...................................... 3
4. Sender's Number Column........................................ 3
4.1. Proposed Mechanism...................................... 4
5. Message Size.................................................. 4
5.1. Proposed Mechanism...................................... 4
6. Media Viewer.................................................. 5
6.1. Proposed Mechanism...................................... 6
7. Mark Message as Read.......................................... 6
7.1. Proposed Mechanism...................................... 6
8. Security Considerations....................................... 7
9. Informative References........................................ 7
10. Acknowledgments............................................... 8
As Internet messaging evolves into unified messaging, the term "e-mail" no longer refers to text-only messages. Today's "e-mail" are often multi-media. That is, they can have numerous non-text parts. These parts can be attachments or can contain voice and/or fax.
随着Internet消息逐渐演变为统一消息，“电子邮件”一词不再指纯文本消息。今天的“电子邮件”通常是多媒体的。也就是说，它们可以有许多非文本部分。这些部分可以是附件，也可以包含语音和/或传真。
Each of voice, fax, and text have their own distinct characteristics, which are intuitive to the user. For example, each of these message types require a different media viewer (text editor for text, audio player for voice, and image viewer for fax), and the dimensions of message size are also different for all three (kilobytes for text, seconds for voice, and pages for fax). As a result, a message that includes more than one of these in its parts is termed a mixed media message.
语音、传真和文本中的每一种都有自己独特的特征，用户可以直观地看到这些特征。例如，每种消息类型都需要不同的媒体查看器（文本的文本编辑器、语音的音频播放器和传真的图像查看器），并且这三种类型的消息大小尺寸也不同（文本的千字节、语音的秒数和传真的页数）。因此，包含其中一个以上部分的消息称为混合媒体消息。
How the messaging client responds to, and acts on these differences is termed "Client Behaviour". This is dependent on the concept of "Message-Context" [2] (previously called primary content), which defines whether the message is a voice mail, fax, or text message. The client can utilize this header to determine the appropriate client behaviour for a particular message.
消息传递客户端如何响应这些差异并根据这些差异采取行动被称为“客户端行为”。这取决于“消息上下文”[2]（以前称为主要内容）的概念，它定义消息是语音邮件、传真还是文本消息。客户机可以利用此头来确定特定消息的适当客户机行为。
Traditionally, a messaging "client" referred to some sort of visual interface (or GUI - graphical user interface) that was presented on the users computer. However, as messaging evolves to unified communications the actual form of the messaging client is expected to change. Today's email can often be viewed on wireless devices with very limited screens or even "viewed" over a telephone (i.e., listening to email as you would listen to voice mail through a TUI - telset user interface).
传统上，消息传递“客户端”指的是在用户计算机上呈现的某种可视界面（或GUI图形用户界面）。然而，随着消息传递向统一通信的发展，消息传递客户端的实际形式预计将发生变化。今天的电子邮件通常可以在屏幕非常有限的无线设备上查看，甚至可以通过电话“查看”（即，像通过TUI-telset用户界面收听语音邮件一样收听电子邮件）。
The intent of this document is to be general and refer to all types of messaging clients, as the user's expectation of behaviour based on the type of message is not expected to change. However, some of the following concepts may tend towards the more common GUI client.
本文档的目的是一般性的，涉及所有类型的消息传递客户端，因为用户基于消息类型的行为预期不会改变。但是，以下一些概念可能倾向于更常见的GUI客户端。
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
在示例中，“C:”和“S:”分别表示客户端和服务器发送的行。
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 RFC-2119 [4].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC-2119[4]中所述进行解释。
The preferred method to distinguish between voice, fax, and text messages on a GUI client is with a visual cue, or icon. A similar voice prompt or "earcon" would be used for TUI clients.
在GUI客户端上区分语音、传真和文本消息的首选方法是使用可视提示或图标。TUI客户端将使用类似的语音提示或“earcon”。
As it is possible for the message to contain more than one media type, the icon should describe the primary message content, as defined by the "Message-Context" header. Obvious choices for the icon/message pairs would be a telephone for a voice message, a fax machine for a fax message, and an envelope for a text mail message. Similarly obvious for the earcons would be short spoken prompts like "voice message".
由于消息可能包含多个媒体类型，因此图标应描述“消息上下文”标题定义的主要消息内容。图标/消息对的明显选择是：电话用于语音消息，传真机用于传真消息，信封用于文本邮件消息。对于耳塞来说，类似“语音信息”这样的简短语音提示也是显而易见的。
This could be taken a step further, and have the GUI icon change to indicate that the message has been read as is currently done in some email clients (others do not change the icon but merely bold the message in the message list to indicate it is unread). For example, a telephone with the receiver off-hook could indicate that the voice message has been played. A fax machine with paper at the bottom, as opposed to the top, would show that the fax had been viewed. Finally, an open envelope indicates that a text message has been read.
这可以更进一步，更改GUI图标以指示消息已被读取，就像当前在某些电子邮件客户端中所做的那样（其他客户端不更改图标，而只是在消息列表中加粗以指示消息未被读取）。例如，如果一部电话的听筒没有挂机，则表明语音信息已经播放。一台底部有纸而不是顶部有纸的传真机会显示传真已被查看过。最后，打开的信封表示文本消息已被读取。
As the choice of icon is determined by the primary message type, the client should obtain this information from the "Message-Context " message header. This header is defined in [2].
由于图标的选择由主消息类型决定，因此客户端应从“消息上下文”消息头获取此信息。此标题在[2]中定义。
As is the case with most email GUI clients today, important message information is organized into columns when presented to the user in a the summary message list. TUIs often present even briefer summaries to the user at the beginning of the session. Typical columns in the GUI client include the message subject, and the date the message was received.
与当今大多数电子邮件GUI客户端一样，重要的消息信息在摘要消息列表中呈现给用户时会被组织成列。TUIs通常在会话开始时向用户呈现更简短的摘要。GUI客户端中的典型列包括消息主题和消息接收日期。
Another important piece of information for the user is the origin of the message. For a voice or fax message, the origin is typically a telephone or fax machine respectively, each of which has an associated telephone number. This telephone number is critical to the user if they wish to return the call. This should be presented accurately to the user (without making it an email address).
对于用户来说，另一个重要的信息是消息的来源。对于语音或传真消息，来源通常分别是电话或传真机，每台电话或传真机都有一个相关的电话号码。如果用户希望回电话，则此电话号码对用户至关重要。这应该准确地呈现给用户（不将其作为电子邮件地址）。
Instead of forcing the telephone number into an email address, a new Internet message header can be used to hold the originating telephone number [3]. If the message is indicated as being a voice or fax message per [2], the client should extract the number, and display it to the user in a separate column. As this header is defined to only hold the digits of the telephone number, it is left to the client to add any separating characters (e.g., "-").
可以使用新的Internet消息头来保存原始电话号码，而不是将电话号码强制输入电子邮件地址[3]。如果消息根据[2]指示为语音或传真消息，则客户端应提取号码，并在单独的列中向用户显示。由于此标头定义为仅保存电话号码的数字，因此客户端可以添加任何分隔字符（例如“-”）。
In the cases of large attachments, small clients (e.g., PDA) and slow links (e.g., wireless) there is also a need for the client to see the length of the message in a suitable format before opening it.
在大附件、小客户端（如PDA）和慢速链路（如无线）的情况下，客户端还需要在打开消息之前以适当的格式查看消息的长度。
Currently, message size is normally given in kilobytes (kB). This is sufficient for plain text messages, but while it may give a hint as to how good the compression algorithm is, kB is not very useful in knowing the size of a voice and/or fax message. Instead, the size should give an indication of the length of the message, i.e., the duration (in seconds) of a voice message, and the number of pages of a fax. Again, the message may contain multiple types, so the size displayed should be that of the primary content type, per [2].
目前，消息大小通常以kB为单位。这对于纯文本消息就足够了，但尽管它可能会提示压缩算法有多好，但kB在了解语音和/或传真消息的大小方面并不是很有用。相反，大小应该指示消息的长度，即语音消息的持续时间（以秒为单位）和传真的页数。同样，消息可能包含多种类型，因此根据[2]，显示的大小应为主要内容类型的大小。
There are three suggested methods to relay this information, of them, the first method is favored:
有三种建议的方法可以传递此信息，其中第一种方法更受欢迎：
For voice messages, the Content-Duration field of the main audio/* body part (as indicated by content-disposition per [1]) should be displayed as the length of the message. If there are several audio parts, an implementation may display the message size as an aggregate of the length of each.
对于语音消息，主音频/*正文部分的内容持续时间字段（由[1]中的内容处置指示）应显示为消息的长度。如果存在多个音频部分，则实现可能会将消息大小显示为每个音频部分长度的集合。
For fax messages a new MIME Header, Content-Page-Length, could be defined, similar to Content-Duration with the exception that number of pages would be specified, rather than number of seconds. (e.g., Content-Page-Length:3). This would be created at origination.
对于传真消息，可以定义一个新的MIME头，即Content Page Length，类似于Content Duration，只是需要指定页数，而不是秒数。（例如，内容页长度：3）。这将在发起时创建。
5.1.2. Message length indicated as a parameter of an Existing RFC 2045 [7] Content-Type Header Field
5.1.2. 作为现有RFC 2045[7]内容类型标头字段的参数指示的消息长度
This would be created at the source. This proposed method would allow the message length to be passed to the client by default in IMAP. Again the client would have to choose between the main voice message length or an aggregate message length for display.
这将在源代码处创建。此建议的方法允许在IMAP中默认情况下将消息长度传递给客户端。同样，客户端必须在显示的主要语音消息长度或聚合消息长度之间进行选择。
Content-Type Header Field example:
内容类型标题字段示例：
Content-Type=audio/*; length=50
Content-Type=image/tiff; pages=3
Content-Type=audio/*; length=50
Content-Type=image/tiff; pages=3
5.1.3. Message length indicated as part of an existing RFC 2822 [9] Header Field
5.1.3. 作为现有RFC 2822[9]头字段的一部分指示的消息长度
This field would be created at the source and may include message length information, but because it is part of the message headers, it could also be amended on reception (by a local process). This method would allow the message length to be passed to any client by default and not require any client modification. If used, this field would indicate the aggregate length of all attachments.
此字段将在源位置创建，可能包含消息长度信息，但由于它是消息头的一部分，因此也可以在接收时（通过本地进程）对其进行修改。默认情况下，此方法允许将消息长度传递给任何客户端，并且不需要任何客户端修改。如果使用，此字段将指示所有附件的总长度。
The advantage of this mechanism is that no new headers are required and it works with existing clients. The downside is that it overloads the subject field.
这种机制的优点是不需要新的头，它可以与现有的客户机一起工作。缺点是它会使主题字段过载。
Subject Header Field example:
主题标题字段示例：
Subject=Voice Message (0:04)
Subject=Fax Message (3p)
Subject=Voice Message (0:14) with Fax (1p)
Subject=Voice Message (0:04)
Subject=Fax Message (3p)
Subject=Voice Message (0:14) with Fax (1p)
When a message is initially opened, the client should, by default, open the proper media viewer to display the primary message content. That is, an audio player for voice messages, an image viewer for fax, and a text editor for text messages. Note that on a TUI, the viewer would render the media to sound (which would have varying effect depending on the media and available process).
最初打开邮件时，默认情况下，客户端应打开适当的媒体查看器以显示主要邮件内容。也就是说，语音消息的音频播放器、传真的图像查看器和文本消息的文本编辑器。请注意，在TUI上，查看器会将媒体渲染为声音（这将根据媒体和可用进程产生不同的效果）。
Where there is more than one body part, obviously the appropriate viewer should be used depending on which body part the user has selected.
如果有多个身体部位，显然应根据用户选择的身体部位使用适当的查看器。
In the case where several viewers are available for a single media type, the user should be prompted to select the desired viewer on the first occasion that the message type is encountered. That viewer should then become the default viewer for that media type. The user should have the ability to change the default viewer for a media type at any time.
如果一种媒体类型有多个查看器，则在第一次遇到消息类型时，应提示用户选择所需的查看器。然后，该查看器应成为该媒体类型的默认查看器。用户应能够随时更改媒体类型的默认查看器。
Note that it is possible that the media viewer may not be part of the client or local to the host of the client. For example, a user could select to play a voice message from a GUI and the message is played over a telephone (perhaps because the user has no desktop speakers). Additionally, a user listening to a unified messaging inbox over a TUI could chose to print a particular message to a nearby fax machine.
请注意，媒体查看器可能不是客户端的一部分，也可能不是客户端主机的本地。例如，用户可以选择播放来自GUI的语音消息，该消息通过电话播放（可能是因为用户没有桌面扬声器）。此外，通过TUI收听统一消息收件箱的用户可以选择将特定消息打印到附近的传真机。
As mentioned, the default viewer displayed to the user should be the appropriate one for the primary message type. The client is able to determine the primary message type from the "Message-Context" message header per [2].
如前所述，显示给用户的默认查看器应该是主消息类型的相应查看器。客户机能够根据[2]从“消息上下文”消息头确定主要消息类型。
Obviously, the user must be able to know which messages they have read, and which are unread. This feature would also control the message icon or earcon as mentioned in section 1.
显然，用户必须能够知道他们读过哪些消息，哪些消息是未读的。此功能还可以控制第1节中提到的信息图标或耳控。
With the proliferation of voice and fax messages, clients should only indicate that these messages are read when the primary body part has been read. For example, a voice message should not be indicated as read until the audio part has been played. The default is currently to mark a message read, when the first body part (typically text) is viewed.
随着语音和传真消息的激增，客户端应仅在已读取主体部分时指示已读取这些消息。例如，在播放音频部分之前，不应将语音消息指示为已读。当前默认设置是在查看第一个正文部分（通常为文本）时，将消息标记为已读。
Implementation of this feature on most clients is a local issue.
在大多数客户端上实现此功能是一个本地问题。
For example, in the case of IMAP4 [6], these clients should only set the \SEEN flag after the first attachment of the primary content type has been opened. That is, if the message context is voice message, the \SEEN flag would be set after the primary voice message (indicated by content-disposition [1] or content-criticality [8]) is opened.
例如，在IMAP4[6]的情况下，这些客户端只应在打开主内容类型的第一个附件后设置\SEEN标志。也就是说，如果消息上下文是语音消息，则在打开主语音消息（由内容处置[1]或内容关键性[8]指示）后将设置\SEEN标志。
The desirable client behaviours described here are intended to provide the user with a better client experience. However, supporting the proposed behaviours described in this document does not make a client immune from the risks of being a mail client. That is, the client is not responsible for the format of the message received, it only interprets. As a result, messages could be spoofed or masqueraded to look like a message they are not to elicit a desired client behaviour. This could be used to fool the end user, for example, into thinking a message was a voice message (because of the icon) when it was not.
此处描述的理想客户行为旨在为用户提供更好的客户体验。然而，支持本文件中描述的拟议行为并不能使客户免于成为邮件客户的风险。也就是说，客户机不负责接收到的消息的格式，它只负责解释。因此，消息可能会被欺骗或伪装成一条消息，它们不会引发所需的客户端行为。例如，这可以用来欺骗最终用户，使其认为某条消息是语音消息（因为图标），而实际上它不是。
[1] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[1] Vaudreuil，G.和G.Parsons，“互联网邮件语音配置文件-第2版（VPIMv2）”，RFC 3801，2004年6月。
[2] Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message Context for Internet Mail", RFC 3458, January 2003.
[2] Burger，E.，Candell，E.，Eliot，C.，和G.Klyne，“互联网邮件的消息上下文”，RFC 3458，2003年1月。
[3] Parsons, G. and J. Maruszak, "Calling Line Identification for Voice Mail Messages", RFC 3939, December 2004.
[3] Parsons，G.和J.Maruszak，“语音邮件的呼叫线路识别”，RFC 39392004年12月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Vaudreuil, G. and G. Parsons, "Content Duration MIME Header Definition", RFC 3803, June 2004.
[5] Vaudreuil，G.和G.Parsons，“内容持续时间MIME头定义”，RFC 3803，2004年6月。
[6] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[6] Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[7] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式”，RFC 20451996年11月。
[8] Burger, E., "Critical Content Multi-purpose Internet Mail Extensions (MIME) Parameter", RFC 3459, January 2003.
[8] Burger，E.“关键内容多用途互联网邮件扩展（MIME）参数”，RFC 3459，2003年1月。
[9] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[9] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[10] Parsons, G., "IMAP Voice Extensions", Work in Progress, June 1999.
[10] Parsons，G.，“IMAP语音扩展”，正在进行的工作，1999年6月。
This work was inspired by the discussion of "Proposed Mechanisms" for IMAP that were detailed in a since expired work in progress entitled "IMAP Voice Extensions" [10]. The authors would like to acknowledge all those who contributed to that document. In addition, Cheryl Kinden, Derrick Dunne, and Jason Collins assisted in the editing of previous revisions of this document.
这项工作的灵感来自于对IMAP“拟议机制”的讨论，该讨论在一份名为“IMAP语音扩展”的已过期的正在进行的工作中进行了详细说明[10]。提交人要感谢所有对该文件作出贡献的人。此外，Cheryl Kinden、Derrick Dunne和Jason Collins协助编辑了本文件之前的修订版。
Author's Addresses
作者地址
Glenn Parsons Nortel Networks P.O. Box 3511, Station C Ottawa, ON K1Y 4H7 Canada Phone: +1-613-763-7582 Fax: +1-613-967-5060 EMail: gparsons@nortel.com
加拿大渥太华C站Glenn Parsons Nortel Networks邮政信箱3511，电话：+1-613-763-7582传真：+1-613-967-5060电子邮件：gparsons@nortel.com
Janusz Maruszak Phone: +1-416-885-0221 EMail: jjmaruszak@sympatico.ca
Janusz Maruszak电话：+1-416-885-0221电子邮件：jjmaruszak@sympatico.ca
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。