Movatterモバイル変換

Network Working Group                                         G. ParsonsRequest for Comments: 4024                               Nortel NetworksCategory: Informational                                      J. Maruszak                                                               July 2005Voice Messaging Client BehaviourStatus 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).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.Table of Contents1.  Introduction..................................................22.  Conventions Used in This Document.............................23.  Message Icon..................................................33.1.  Proposed Mechanism......................................34.  Sender's Number Column........................................34.1.  Proposed Mechanism......................................45.  Message Size..................................................45.1.  Proposed Mechanism......................................46.  Media Viewer..................................................56.1.  Proposed Mechanism......................................67.  Mark Message as Read..........................................67.1.  Proposed Mechanism......................................68.  Security Considerations.......................................79.  Informative References........................................710. Acknowledgments...............................................8Parsons & Maruszak           Informational                      [Page 1]

RFC 4024            Voice Messaging Client Behaviour           July 20051.  Introduction   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.   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.   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).   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.2.  Conventions Used in This Document   In examples, "C:" and "S:" indicate lines sent by the client and   server respectively.   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 inRFC-2119 [4].Parsons & Maruszak           Informational                      [Page 2]

RFC 4024            Voice Messaging Client Behaviour           July 20053.  Message Icon   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.   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.3.1.  Proposed Mechanism   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].4.  Sender's Number Column   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.   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).Parsons & Maruszak           Informational                      [Page 3]

RFC 4024            Voice Messaging Client Behaviour           July 20054.1.  Proposed Mechanism   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., "-").5.  Message Size   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.   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].5.1.  Proposed Mechanisms   There are three suggested methods to relay this information, of them,   the first method is favored:5.1.1.  MIME Header Content-Duration as described inRFC 2424 [5]   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.   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.Parsons & Maruszak           Informational                      [Page 4]

RFC 4024            Voice Messaging Client Behaviour           July 20055.1.2.  Message length indicated as a parameter of an ExistingRFC 2045 [7] Content-Type Header Field   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.   Content-Type Header Field example:   Content-Type=audio/*; length=50   Content-Type=image/tiff; pages=35.1.3.  Message length indicated as part of an existingRFC 2822 [9]        Header Field   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)6.  Media Viewer   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).   Where there is more than one body part, obviously the appropriate   viewer should be used depending on which body part the user has   selected.Parsons & Maruszak           Informational                      [Page 5]

RFC 4024            Voice Messaging Client Behaviour           July 2005   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.6.1.  Proposed Mechanism   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].7.  Mark Message as Read   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 insection 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.7.1.  Proposed Mechanism   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.Parsons & Maruszak           Informational                      [Page 6]

RFC 4024            Voice Messaging Client Behaviour           July 20058.  Security Considerations   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.9.  Informative References   [1]  Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail -        version 2 (VPIMv2)",RFC 3801, June 2004.   [2]  Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message        Context for Internet Mail",RFC 3458, January 2003.   [3]  Parsons, G. and J. Maruszak, "Calling Line Identification for        Voice Mail Messages",RFC 3939, December 2004.   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement        Levels",BCP 14,RFC 2119, March 1997.   [5]  Vaudreuil, G. and G. Parsons, "Content Duration MIME Header        Definition",RFC 3803, June 2004.   [6]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",RFC 3501, March 2003.   [7]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail        Extensions (MIME) Part One: Format of Internet Message Bodies",RFC 2045, November 1996.   [8]  Burger, E., "Critical Content Multi-purpose Internet Mail        Extensions (MIME) Parameter",RFC 3459, January 2003.   [9]  Resnick, P., "Internet Message Format",RFC 2822, April 2001.   [10] Parsons, G.,"IMAP Voice Extensions", Work in Progress, June        1999.Parsons & Maruszak           Informational                      [Page 7]

RFC 4024            Voice Messaging Client Behaviour           July 200510.  Acknowledgments   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.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   Janusz Maruszak   Phone: +1-416-885-0221   EMail: jjmaruszak@sympatico.caParsons & Maruszak           Informational                      [Page 8]

RFC 4024            Voice Messaging Client Behaviour           July 2005Full Copyright Statement   Copyright (C) The Internet Society (2005).   This document is subject to the rights, licenses and restrictions   contained inBCP 78, and except as set forth therein, the authors   retain all their rights.   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 inBCP 78 andBCP 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 athttp://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.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Parsons & Maruszak           Informational                      [Page 9]