From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4024.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc4024.txt (limited to 'doc/rfc/rfc4024.txt') 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] + -- cgit v1.2.3