RFC 4024

Voice Messaging Client Behaviour

📅 published July 2005, from ietf

RFC 4024: Voice Messaging Client Behaviour 🎀

Okay bestie, let's get into RFC 4024 💖 It's an Informational doc from the Network Working Group, so it's sharing info with the Internet community rather than setting a standard. Written by G. Parsons (Nortel Networks) and J. Maruszak, and it's dated July 2005. Its header doesn't list anything it obsoletes or updates. ✨

Status of This Memo

This memo is here to share info with the Internet community 🦋 It is not an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2005).

Abstract

This doc spells out the expected behaviour of a client for the different parts 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

1. Introduction ✨

Internet messaging is turning into unified messaging, so "e-mail" doesn't just mean text anymore 📬 Today's "e-mail" is often multi-media, meaning it can have lots of non-text parts. Those parts can be attachments, or they can contain voice and/or fax.

Voice, fax, and text each have their own distinct characteristics that users just intuitively get 🧚 For example, each one needs a different media viewer: a text editor for text, an audio player for voice, and an image viewer for fax. Their message sizes are different too: kilobytes for text, seconds for voice, and pages for fax. So a message that has more than one of these types in its parts is called a mixed media message. 🫶

How the messaging client responds to these differences and acts on them is called "Client Behaviour" 👑 It depends on the concept of "Message-Context" [2] (formerly called primary content), which tells you whether the message is voice mail, fax, or text. The client can use this header to work out the right client behaviour for a given message.

Back in the day, a messaging "client" meant a visual interface (a GUI, or graphical user interface) on your computer 💻 But as messaging moves toward unified communications, the actual form of the client is expected to change. Today's email can be read on wireless devices with tiny screens, or even "viewed" over a telephone, meaning you listen to your email the way you'd listen to voice mail through a TUI (telset user interface) 📞

This document is meant to be general and cover all types of messaging clients, since the user's expectations of behaviour based on message type aren't expected to change. Some of the concepts below might lean more toward the common GUI client, though. 🌈

2. Conventions Used in This Document 🎀

In examples, C: and S: mark lines sent by the client and the 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]. 🔥

3. Message Icon 🦋

The go-to way to tell voice, fax, and text messages apart on a GUI client is a visual cue, aka an icon 🧡 A TUI client would use a similar voice prompt, called an "earcon" 🔈

Since a message can contain more than one media type, the icon should describe the primary message content, as defined by the "Message-Context" header. The obvious picks would be a telephone for voice, a fax machine for fax, and an envelope for text mail. The earcons are similarly obvious: short spoken prompts like "voice message" 🙈

It could go a step further, with the GUI icon changing to show the message has been read. Some email clients already do this, while others leave the icon alone and just bold unread messages in the list 💅 For example, a telephone with the receiver off-hook could show the voice message has been played. A fax machine with paper at the bottom instead of the top would show the fax has been viewed. And an open envelope shows a text message has been read. ✨

3.1. Proposed Mechanism

The icon depends on the primary message type, so the client should get that info from the "Message-Context " message header 🧚 This header is defined in [2].

4. Sender's Number Column 💜

Most email GUI clients today organize important message info into columns in the summary message list. TUIs often give even shorter summaries at the start of a session. Typical GUI columns include the message subject and the date the message was received. 📋

Another key piece of info is who the message came from. For voice or fax, the origin is usually a telephone or fax machine, and each one has its own telephone number. That number is crucial if the user wants to call back 📞 It should be shown accurately to the user, and it shouldn't be turned into an email address. 🍓

4.1. Proposed Mechanism

Rather than squishing the telephone number into an email address, a new Internet message header can hold the originating telephone number [3]. If the message is marked as voice or fax per [2], the client should pull out the number and show it to the user in its own column ✨ Since this header only holds the digits of the telephone number, the client is left to add any separating characters (e.g., "-") 🫶

5. Message Size 🌸

When attachments are large, or clients are small (like a PDA) or links are slow (like wireless), the client needs to see the length of the message in a useful format before opening it. ⏳

Message size is normally shown in kilobytes (kB) right now. That's fine for plain text, and while it hints at how well compression worked, kB isn't very helpful for knowing how big a voice or fax message is. Instead, the size should show the length of the message: the duration in seconds for a voice message, and the number of pages for a fax 🌈 The message might have multiple types, so the size shown should be for the primary content type, per [2]. 💖

5.1. Proposed Mechanisms

There are three suggested ways to pass this info along. The first method is the favored one 👑

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 shown as the message length 🎧 If there are several audio parts, an implementation may show the message size as the total length of all of them.

For fax, a new MIME header called Content-Page-Length could be defined. It's like Content-Duration, except it gives the number of pages instead of seconds, like Content-Page-Length:3. It would be created at origination. 📄

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 method would let the message length get passed to the client by default in IMAP 💌 Again, the client would have to pick between the main voice message length or the total 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 info. Since it's part of the message headers, it could also be changed on reception by a local process 🔁 This method would let the message length get passed to any client by default, with no client changes needed. If it's used, this field would show the total length of all attachments.

The upside is that no new headers are needed 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 first opened, the client should, by default, open the right media viewer to show the primary message content. So that's an audio player for voice messages, an image viewer for fax, and a text editor for text messages. On a TUI, the viewer would render the media as sound, and how that sounds depends on the media and what's available for processing 🔊

If there's more than one body part, the right viewer should be used based on the body part the user picked 🦋

When several viewers are available for one media type, the user should be asked to pick the viewer they want the first time that message type shows up. That viewer should then become the default for that media type. The user should be able to change the default viewer for a media type at any time 👑

The media viewer might not be part of the client or live on the client's host, which is kinda wild 🌍 For example, a user could pick to play a voice message from a GUI and have it play over a telephone, maybe because they don't have desktop speakers. And a user listening to a unified messaging inbox over a TUI could choose to print a message on a nearby fax machine 🖨️

6.1. Proposed Mechanism

As mentioned, the default viewer shown to the user should be the right one for the primary message type. The client can work out the primary message type from the "Message-Context" message header per [2] 💅

7. Mark Message as Read ✨

Okay so, obviously the user has to be able to tell which messages they've read and which ones are still unread 👀. This feature also controls the message icon or earcon we talked about in section 1 🎧.

With voice and fax messages everywhere now, clients should only mark these as read once the main body part has been read 🎙️. For example, a voice message shouldn't show as read until the audio part has actually been played. Right now the default is to mark a message as read when the first body part (usually the text) gets viewed, and that's not it for voice messages 💀.

7.1. Proposed Mechanism 🦋

Honestly, doing this on most clients is a local thing 💅.

Take IMAP4 [6] as an example. Clients should only set the \SEEN flag after the first attachment of the primary content type has been opened 📬. So if the message context is a voice message, the \SEEN flag gets set once the primary voice message (identified by content-disposition [1] or content-criticality [8]) is opened 🎀.

8. Security Considerations 🔐

The client behaviours described here are meant to give the user a better experience 🌸. BUT, and this is a big but 😭, following the behaviours in this document does not make a client immune to the risks that come with being a mail client. The client isn't responsible for the format of the message it gets. It just interprets it 🙈.

That means messages can be spoofed or disguised to look like a message they aren't, just to trigger a behaviour the attacker wants from the client 🚨. This could be used to trick the end user into thinking a message is a voice message (because of the icon) when it actually isn't 💀📞. Not cute, bestie. Be careful out there 🫶.

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. 🧚

10. Acknowledgments 🫶

This work was inspired by the chat about "Proposed Mechanisms" for IMAP in a work in progress called "IMAP Voice Extensions" [10], which has since expired 🥹. The authors want to thank everyone who contributed to that document 💜. Also, big love to Cheryl Kinden, Derrick Dunne, and Jason Collins for helping edit earlier revisions of this one 👑.

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

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 doesn't take a position on whether any Intellectual Property Rights or other rights claimed to cover the technology in this document are valid or in scope, or whether a license under those rights might be available. It also doesn't say it has made any independent effort to find such rights. Info on how rights work for RFC documents is in BCP 78 and BCP 79 📖.

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses that will be made available, or the result of an attempt to get a general license or permission to use these proprietary rights for implementers or users of this spec can be found in the IETF's online IPR repository at http://www.ietf.org/ipr 🔍.

The IETF invites anyone to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society ✨.

📦 where this page comes from