RFC 2423

RFC 2423: VPIM Voice Message MIME Sub-type Registration ✨

okay bestie, let's get into it 🎀 this one is RFC 2423, a Standards Track doc from September 1998 📅 It's in the Network Working Group, and it was written by G. Vaudreuil (Lucent Technologies) and G. Parsons (Northern Telecom) 👑 It obsoletes RFC 1911 🫶 and it's all about registering a new MIME sub-type for voice messages 🦋

---

Status of This Memo 📜

this one is an Internet standards track protocol for the Internet community, and it's asking everyone to share discussion and suggestions for improvements 💬 for the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 🔍 and distribution of this memo is unlimited 🌈

Copyright Notice ©️

Copyright (C) The Internet Society (1998). All Rights Reserved. 💜

Overview 🧚

this doc registers the MIME sub-type multipart/voice-message for the Voice Profile for Internet Mail (VPIM) 🎀 the full usage details live in the VPIM v2 specification, so that's your go-to for the deep dive 💅

1. Abstract ✨

same energy as the overview, just a bit more formal 💖 we're registering multipart/voice-message for VPIM, the full usage is in the VPIM v2 specification [VPIM2], and this doc revises the earlier sub-type registration from RFC 1911 [VPIM1] 🦋

2. VPIM Scope 🌸

okay so VPIM is a restricted profile of the Internet multimedia messaging protocols, made for voice processing platforms 🎙️ these platforms have historically been special-purpose computers, and they often don't have the same facilities you'd find on a regular Internet Email-capable computer 💀 so VPIM adds extra functionality where it's needed 🔥 the goal is the minimum common set of features that lets compliant systems talk to each other, so they can interwork 🫶

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 [REQ]. 👑

3. Voice Message Interchange 📨

3.1. multipart/voice-message 🎧

the multipart/voice-message sub-type is defined to hold specific media contents that get swapped in messages between voice messaging systems described in [VPIM2] 💖 basically it's a simple wrapper that clearly says "all of this is parts of one single voice message" 🎀 it has the same semantics and syntax as multipart/mixed from [MIME2], so systems that don't understand the sub-type can just treat it as a multipart/mixed 🦋 the only thing they lose is knowing it's a voice message, which is honestly a fair trade 💅

you can also add an explanatory preamble (like "VPIM voice message attached") for people reading with pre-MIME software 🌈 MIME-compliant software will just ignore that preamble, so everyone's happy ✨

on top of the MIME-required boundary parameter, this sub-type also needs a version parameter 🔥 that's how you tell this version apart from the earlier one in [VPIM1] 🫶 the value is 2.0 if the content follows [VPIM2] 💜 and if there are future revisions, there MUST be backwards compatibility (i.e. systems implementing version n can read version 2, and systems implementing version 2 can read version 2 contents within a version n) 🙈 the default when the parameter is missing is 1, meaning the content follows [VPIM1] 🍓

[VPIM2] says only specific media types that make sense for voice messaging are valid next-level' contents when version=2.0 💅 those are audio/, image/, message/rfc822andapplication/directory` 🎀 the multipart can package as many of these as needed 🌸

3.2. VPIM v2 Usage 💬

the multipart/voice-message sub-type is a primary component of the VPIM specification [VPIM2] 👑 All VPIM Messages MUST contain this sub-type to identify the wrapping of a voice message 🔥 the wrapper can hold anything from one single audio/32KADPCM content to a complex set of related and nested contents 🦋

usually, if there's more than one audio segment, the first is the spoken name of the originator, the second is the spoken subject, and the third is the voice message itself 🎙️ but this order MUST NOT be assumed in any case 🙈 also, the order the contents appear SHOULD be the order they're presented to the user 💖

the spoken name segment, if available, shall contain the name of the message sender in the voice of the sender, and it must not exceed 12 seconds 🎧

the spoken subject segment, if available, shall contain the subject of the message sender in the voice of the sender, and it must not exceed 20 seconds ⏱️

the directory information part, if present, contains info specific to the originator of the voice message 📇

for the details on proper usage, check the VPIM v2 Specification 🔍

4. IANA Registration 📝

here's the registration template, verbatim so it can go straight to IANA 💅

To: ietf-types@iana.org
Subject: Registration of MIME media type
          multipart/voice-message

MIME media type name: multipart

MIME subtype name: voice-message

Required parameters: boundary, version

   The use of boundary is defined in [MIME2]

   The version parameter that contains the value "2.0" if
   enclosed content conforms to [VPIM2].  The absence of this
   parameter indicates conformance to the previous version
   defined in RFC 1911 [VPIM1].

Optional parameters: none

Encoding considerations: 7bit, 8bit or Binary

Security considerations:

   This definition identifies the content as being a voice
   message.  In some environments (though likely not the
   majority), the loss of the anonymity of the content may be a
   security issue.

Interoperability considerations:

   Systems developed to conform with [VPIM1] may not conform to
   this registration.  Specifically, the required version will
   likely be absent, in this case the recipient system should
   still be able to accept the message and will be able to
   handle the content.  The VPIM v1 positional identification,
   however, would likely be lost.

Published specification:
    This document
    [VPIM2]

Applications which use this media type:

  Primarily voice messaging

Additional information:

  Magic number(s): ?
  File extension(s): .VPM
  Macintosh File Type Code(s): VPIM

Person & email address to contact for further information:

  Glenn W. Parsons
  Glenn.Parsons@Nortel.ca

  Gregory M. Vaudreuil
  Greg.Vaudreuil@Octel.Com

Intended usage: COMMON

Author/Change controller:

  Glenn W. Parsons & Gregory M. Vaudreuil

5. Authors' Addresses 📮

Glenn W. Parsons
Northern Telecom
P.O. Box 3511, Station C
Ottawa, ON  K1Y 4H7
Canada

Phone: +1-613-763-7582
Fax: +1-613-763-4461
EMail: Glenn.Parsons@Nortel.ca


Gregory M. Vaudreuil
Lucent Technologies
17080 Dallas Parkway
Dallas, TX  75248-1905
United States

Phone/Fax: +1-972-733-2722
EMail: GregV@Lucent.Com

6. References 📚

• [MIME2] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types ", RFC 2046, November 1996.
• [MIME4] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
• [VPIM1] Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911, February 1996.
• [VPIM2] Vaudreuil, G., and G. Parsons, "Voice Profile for Internet Mail - version 2", RFC 2421, September 1998.
• [REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

7. Full Copyright Statement ⭐

Copyright (C) The Internet Society (1998). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. 💖