RFC 2424

Content Duration MIME Header Definition

📅 published September 1998, from ietf

RFC 2424: Content Duration MIME Header Definition ✨

okay bestie, this one's a Standards Track spec from September 1998 🍓 Its authors are G. Vaudreuil (Lucent Technologies) and G. Parsons (Northern Telecom), and it's part of the Network Working Group. The title block doesn't list anything it obsoletes or updates, so it's standing alone 💅

Status of this Memo

This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🦋 For the standardization state and status of this protocol, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸

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

Overview

This doc describes the MIME header Content-Duration, which is meant for any timed media content (typically audio/* or video/*) 🎀

1. Abstract ✨

Same vibe as the overview: this is the MIME header Content-Duration, built for any time varying media content (typically audio/* or video/*) 🎬 The length of time is written in seconds, with no units indicator ⏱️

2. Content-Duration Header Field 🌈

Time varying media, like a spoken voice message or a video clip, has an inherent duration ⏳ Lots of audio and video encodings can include their duration as header info, or let you work it out from the byte length of the data 🤓 Still, it can be handy to show the duration in a MIME header, so you can read it without dealing with the actual content 🫶

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] 📖

2.1 Syntax 💖

The Content-Duration field's value is one number, giving the duration of the content in seconds. Formally:

duration := "Content-Duration" ":" 1*10DIGIT

Practically speaking (though it's highly unlikely in MIME media 🙈), the upper bound on the numerical value of the duration is (2^^31 - 1), which is 2147483647 🔢

2.2 Semantics 🔥

This field is the duration of the time varying media it's attached to ⏲️ The duration is written in seconds with no units tag. The time value should be exact, but you can't know the exact duration without opening the content and playing it 😭 If you need an exact value, go with the playing method. This mechanism is just a way for the sender to put a duration in the header, so it's easy to access ✨

There are a bunch of ways to show this duration to the recipient (like in the inbox headers, or when an audio attachment is opened). What the receiving side actually does with this field is a local implementation issue 💅

2.3 Example 🧚

In this example, the content duration is 33 seconds:

    Content-Duration: 33

3. VPIM Usage 🎀

The Content-Duration header field for the audio/32KADPCM sub-type is a super useful part of the VPIM specification [VPIM2] 👑 All VPIM Messages MUST contain this sub-type to carry the audio of a voice message 🔥 It can also be handy in some cases (say, viewing on a simple MIME or non-MIME desktop) to have the voice message's duration available without opening the audio content 🌸

4. Security Considerations 💀

Okay, read this one carefully, it's serious. ⚠️

This definition introduces the option of explicitly identifying the time duration of an audio/* or video/* content outside of the binary data that forms the content. In some environments (though probably not most of them), identifying the actual time duration in a header field may be a security issue, so it should not be noted. Relying on the time in this header field cannot be trusted for determining the exact size of the data 🚨 The exact length of the data must be determined by examining the data itself 🔐

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. 🌷
  • [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. 🔑

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 implementation 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. 🦋

📦 where this page comes from