RFC 3938

Video-Message Message-Context

📅 published October 2004, from ietf

RFC 3938: Video-Message Message-Context 🎬✨

  • Title: Video-Message Message-Context
  • Author: T. Hansen, AT&T Laboratories
  • Stream: Network Working Group
  • Category: Standards Track
  • Date: October 2004
  • Updates: RFC 3458

Status of this Memo 📋

okay bestie, this part is the official fine print. It says this is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💖. For the current standardization state and status, check the current edition of the "Internet Official Protocol Standards" (STD 1). And distribution of this memo is unlimited 🌸.

Copyright (C) The Internet Society (2004). That's the legal bit, no notes 🫶.

Abstract 🦋

so the Message-Context header from RFC 3458 tells you the vibe of a message, like whether it's a fax-message or a voice-message 📠🎤. This spec adds one new context value to that header: "video-message" 🎥✨.

A receiving user agent (UA) can use this info as a hint for presenting the message nicely. It's a hint, not a command 💅.

1. Introduction 🧚

email can carry tons of different kinds of messages, and the user interacts with each kind differently 🌈. As RFC 3458 [1] explains, the "message context" of a message tells the reader how they're expected to interact with it, like which icon to show 👑.

RFC 3458 already registers these message contexts: "voice-message", "fax-message", "pager-message", "multimedia-message", "text-message", and "none" 🍓.

2. Video Message 🎀

okay so one kind of email is basically a message that's mostly a video stream 📹💜. Services that send video email include the ones hooked up to cell phones that capture video, and video email services that use webcams on a PC 💻🌸.

These messages come in two flavors, and both can properly be called video messages:

  1. ones that embed the video stream inside the message as a body part, and
  2. ones whose video stream lives on a third party's video server 🌍.

The thing is, none of the existing message contexts properly identify these video messages 😭. So this spec adds one more value to the Message-Context header: video-message 🎥💖.

3. IANA Considerations 📚

3.1. Message-Context 🏷️

As RFC 3458 [1] lays out, this document registers "video-message" in the "Internet Message Context Types" repository 🫶. Here's the registration, verbatim:

Message-Context class name:
   video-message

Summary of the message class:
   Indicates a message whose primary content is a video mail message.
   The primary content is video data.  The context is usually a
   message recorded on a video camera, or a message whose primary
   purpose is to contain an external reference to a message recorded
   on a video camera.

Person & email address to contact for further information:
   Tony Hansen, tony+msgctxt@maillennium.att.com.

4. Security Considerations 🔐

ngl this one is short, but it matters 💀. The header is only meant to indicate message context. It's just a hint, and it doesn't require any behavior from a message user agent. Periodt 🙈.

5. Normative References 📖

Here's the one normative reference, verbatim:

[1]  Burger, E., Candell, E., Eliot, C., and G. Klyne, "Message
     Context for Internet Mail", RFC 3458, January 2003.

6. Author's Address 💌

Tony Hansen is the author, at AT&T Laboratories. Here's the contact info, verbatim:

Tony Hansen
AT&T Laboratories
200 Laurel Ave.
Middletown, NJ  07748
USA

EMail: tony+msgctxt@maillennium.att.com

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions in BCP 78. Except as set out there, the authors keep all their rights 🦋.

The document and the info in it are provided on an "AS IS" basis. The contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all disclaim every warranty, express or implied. That includes, but isn't limited to, any warranty that using the info won't infringe any rights, and any implied warranty of merchantability or fitness for a particular purpose. Yikes, legal stuff, but it's important 😭.

Intellectual Property 🧠

The IETF doesn't take a position on whether any Intellectual Property Rights or other rights claimed for the technology in this document are valid or in scope. It also doesn't say whether licenses under those rights are available, and it hasn't independently checked for such rights 🙈. The IETF's procedures on rights in IETF Documents are in BCP 78 and BCP 79 📜.

Copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses, and the results of attempts to get a general license for implementers or users are available from the IETF's online IPR repository at http://www.ietf.org/ipr 💖.

The IETF invites anyone to tell it about 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