summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4024.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4024.txt')
-rw-r--r--doc/rfc/rfc4024.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc4024.txt b/doc/rfc/rfc4024.txt
new file mode 100644
index 0000000..ea93db0
--- /dev/null
+++ b/doc/rfc/rfc4024.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+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).
+
+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 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
+
+
+
+
+
+
+
+
+
+
+Parsons & Maruszak Informational [Page 1]
+
+RFC 4024 Voice Messaging Client Behaviour July 2005
+
+
+1. 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 in RFC-2119 [4].
+
+
+
+
+
+Parsons & Maruszak Informational [Page 2]
+
+RFC 4024 Voice Messaging Client Behaviour July 2005
+
+
+3. 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 2005
+
+
+4.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 in RFC 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 2005
+
+
+5.1.2. Message length indicated as a parameter of an Existing
+ RFC 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=3
+
+5.1.3. Message length indicated as part of an existing RFC 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 in section 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 2005
+
+
+8. 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 2005
+
+
+10. 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.ca
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Parsons & Maruszak Informational [Page 8]
+
+RFC 4024 Voice Messaging Client Behaviour July 2005
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (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.
+
+ 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.
+
+ 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.
+
+ 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]
+