RFC 4539

RFC 4539 at a glance 🎀 Okay bestie, this one is a registration doc, not a protocol spec. It's titled Media Type Registration for the Society of Motion Picture and Television Engineers (SMPTE) Material Exchange Format (MXF), written by Thomas G. Edwards of PBS, dated May 2006. It's Informational 💅, so it's giving "here's some info, no standard being created here." The original doesn't say it obsoletes or updates anything, so I'm not going to make that up 🙈

---

Status of This Memo ✨

This memo is just info for the Internet community. It isn't an Internet standard of any kind, and it can be shared freely with no limits 🦋

Copyright Notice 💜

Copyright (C) The Internet Society (2006).

Abstract 🌸

This doc registers a media type for the SMPTE Material Exchange Format (MXF). MXF is defined by SMPTE 377M, and it's a standard wrapper format for passing audiovisual material around. It can carry both the audiovisual essence and rich metadata 🎬

Table of Contents 🧚

1. Introduction ....................................................2
2. Security Considerations .........................................3
3. IANA Considerations .............................................3
   3.1. Media Type for SMPTE Material Exchange Format (MXF) ........3
4. References ......................................................5
   4.1. Normative References .......................................5
   4.2. Informative References .....................................5

1. Introduction 💖

So this doc registers a media type for SMPTE MXF. MXF is defined by SMPTE 377M [SMPTE377M], and it's a standard wrapper format for interchanging audiovisual material, covering both audiovisual essence and rich metadata 🎞️

Essence is the raw video, audio, and data streams that MXF contains and describes. Metadata in MXF comes in two flavours, structural and descriptive ✨

• Structural metadata is about the structure and capabilities of the MXF file, and it's generally required for proper decoding. Examples are descriptions of essence types, info to help line up audio and video playout, and content length.
• Descriptive metadata tells you about the program content in the file, and it's not essential for decoding. Examples are program title, actors, and scene descriptions.

The essence can carry data too, like vertical blanking interval data used for Closed Captioning and other purposes 📺

MXF is a big deal for interoperation between different video systems and digital cinema systems 🍿 It also helps make video production and distribution workflows more efficient, multi-vendor, file based, and IT oriented, which is so iconic 😭

SMPTE currently has standards for mapping these essence types to the MXF generic container:

• MPEG (including MPEG-1 and MPEG-2 video streams, as well as MPEG audio)
• DV-DIF (Digital Video Digital Interface Format for the DV family of related video encodings)
• Uncompressed Pictures
• SDTI-CP (Serial Digital Transport Interface Content Package for delivering packetized audiovisual content over the SDI interface)
• D-10 (a specialized video stream incorporating MPEG-2 4:2:2P@ML)
• D-11 (a high-definition video compression standard)
• AES3 audio
• Broadcast Wave audio
• A-Law audio

The MXF generic container is flexible, so mappings of additional essence types could show up in the future 🌈

The media type defined here is needed to correctly identify MXF files when they're served over HTTP or other network connections. It's also needed when they're included in multi-part documents, indexed by operating systems and digital asset management systems, or used anywhere else media types are used 🫶

2. Security Considerations 🔥

Security requirements for the application/mxf media type are discussed in the IANA media type registration (Section 3.1). Go check that section, it's the main event 👑

3. IANA Considerations 🦋

IANA has registered the media type application/mxf as specified in Section 3.1. The registration uses the template present in [RFC4288] ✨

3.1. Media Type for SMPTE Material Exchange Format (MXF) 💅

Here's the registration template, copied exactly as written:

To: ietf-types@iana.org
Subject: Registration of media type application/mxf

Type name: application

Subtype name: mxf

Required parameters: none

Optional parameters: ULs

The optional parameter ULs is a single Uniform Resource Name (URN), or a comma-separated list of multiple URNs of SMPTE Universal Labels (which are defined by SMPTE 400M [SMPTE400M]) 🧚

This optional parameter gives hints to the decoder about the structure of the MXF file. That could include the Operational Pattern, essence types, descriptive metadata schemes, and other elements identified by their SMPTE Universal Label 🎀

SMPTE Universal Labels are Object Identifiers (OIDs), as specified by [ASN1]. So a URN of a SMPTE Universal Label can use the OID URN namespace specified in [RFC3061], or any other future URN namespace that fits SMPTE Universal Labels 🌸

Heads up: per [RFC2045], some characters (including the comma used to separate multiple values) mean the entire parameter value has to be enclosed in quotes. Don't skip the quotes!

Here's an example. The two SMPTE Universal Labels say the MXF file uses the OP1a Operational Pattern and contains IEC DV video at 25 Mbps, 525 lines, 59.94 fps interlaced essence 🎬

   Content-Type:  application/mxf;
      ULs="urn:oid:1.3.52.4.1.1.1.13.1.2.1.1.1,
      urn:oid:1.3.52.4.1.1.1.4.1.2.2.2.1.1"

The rest of the template, verbatim:

Encoding considerations: binary

Security considerations: Application/mxf objects are not signed but
may be partially encrypted internally.  External security mechanisms
must be employed to ensure content confidentiality.  MXF, through
metadata extensions, may allow executable code to be transferred in
the file.  It is suggested that no unauthenticated executables
decoded from an MXF file be executed.  Some compressed essence types
carried in MXF may carry a risk that certain pathological bitstreams
could lead to potential denial-of-service attacks against these
essence decoders.

Interoperability considerations: MXF provides a standard wrapping for
a number of audio and video essence types according to a number of
different Operational Patterns (OP).  Thus, interoperability depends
upon whether the MXF file decoder has the capability to match the
features of the MXF file encoder.  An Application Specification (AS)
can ensure that MXF encoders and decoders can interoperate
effectively.

Published specification: RFC 4539, SMPTE 377M [SMPTE377M]

Applications that use this media type: MXF is a wrapper for many
types of audio and video essence types in use by many applications in
the broadcast and digital cinema industries.  These include
non-linear editing systems, video servers, video camera systems,
digital asset management systems, and digital video distribution
systems.

Additional information:

   Magic number(s): none

   File extension(s): .mxf

   Macintosh File Type Code(s): "mxf "

Person & email address to contact for further information:
Thomas Edwards
email: tedwards@pbs.org

Intended usage: COMMON

Restrictions on usage: none
Author/Change controller:

Thomas Edwards
email: tedwards@pbs.org

4. References 📚

4.1. Normative References ✨

• [SMPTE377M] Society of Motion Picture and Television Engineers, "Material Exchange Format (MXF) File Format Specification", SMPTE 377M-2004, <http://www.smpte.org>.
• [SMPTE400M] Society of Motion Picture and Television Engineers, "SMPTE Labels Structure", SMPTE 400M-2004, <http://www.smpte.org>.

4.2. Informative References 🌈

• [ASN1] International Telephone and Telegraph Consultative Committee, "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)", CCITT Recommendation X.209, January 1988.
• [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
• [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", RFC 3061, February 2001.
• [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

Author's Address 💌

Thomas G. Edwards
PBS
6453 Stephenson Way
Alexandria, VA  22312
US

Phone: +1 703 739 5000
EMail: tedwards@pbs.org
URI:   http://www.pbs.org

Full Copyright Statement 🎀

Copyright (C) The Internet Society (2006).

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 provided by the IETF Administrative Support Activity (IASA).