summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4539.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4539.txt')
-rw-r--r--doc/rfc/rfc4539.txt339
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc4539.txt b/doc/rfc/rfc4539.txt
new file mode 100644
index 0000000..8f2f849
--- /dev/null
+++ b/doc/rfc/rfc4539.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group T. Edwards
+Request for Comments: 4539 PBS
+Category: Informational May 2006
+
+
+ Media Type Registration for the
+ Society of Motion Picture and Television Engineers (SMPTE)
+ Material Exchange Format (MXF)
+
+Status of This Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document serves to register a media type for the Society of
+ Motion Picture and Television Engineers (SMPTE) Material Exchange
+ Format (MXF). MXF, defined by SMPTE 377M, is a standard wrapper
+ format developed for the interchange of audiovisual material,
+ including both 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Edwards Informational [Page 1]
+
+RFC 4539 Media Type Registration for MXF May 2006
+
+
+1. Introduction
+
+ The present document registers a media type for SMPTE Material
+ Exchange Format (MXF). MXF, defined by SMPTE 377M [SMPTE377M], is a
+ standard wrapper format developed for the interchange of audiovisual
+ material, including both audiovisual essence and rich metadata.
+
+ Essence is the raw video, audio, and data streams contained and
+ described by MXF. Metadata carried by MXF includes structural
+ metadata and descriptive metadata. Structural metadata relates to
+ the structure and capabilities of the MXF file and is generally
+ required for proper decoding. Some examples of structural metadata
+ are descriptions of essence types, information to help synchronize
+ playout of audio and video, and content length. Descriptive metadata
+ gives information about the program content in the file and is not
+ essential for decoding. Some examples of descriptive metadata are
+ program title, actors, and scene descriptions. The essence in MXF
+ files may itself carry data, such as vertical blanking interval data
+ used for carriage of Closed Captioning and other purposes.
+
+ MXF is an important tool in providing interoperation between
+ different video systems as well as digital cinema systems. MXF also
+ aids in the development of video production and distribution
+ workflows that are more efficient, multi-vendor, file based, and IT
+ oriented.
+
+ SMPTE currently has standards for the mapping of the following
+ 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, and A-Law
+ audio. The flexibility of the MXF generic container allows for the
+ possibility of mappings of additional essence types in the future.
+
+ The media type defined here is needed to correctly identify MXF files
+ when they are served over HTTP or other network connections, included
+ in multi-part documents, indexed by operating systems and digital
+ asset management systems, or used in other places where media types
+ are used.
+
+
+
+
+
+
+
+
+Edwards Informational [Page 2]
+
+RFC 4539 Media Type Registration for MXF May 2006
+
+
+2. Security Considerations
+
+ Security requirements for the application/mxf media type are
+ discussed in the IANA media type registration (Section 3.1).
+
+3. IANA Considerations
+
+ The 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)
+
+ 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 provides hints to the decoder regarding the
+ structure of the MXF file, which could include Operational Pattern,
+ essence types, descriptive metadata schemes, and other elements that
+ are identified by their SMPTE Universal Label.
+
+ SMPTE Universal Labels are Object Identifiers (OIDs), as specified by
+ [ASN1]. Thus, a URN of a SMPTE Universal Label can use the OID URN
+ namespace specified in [RFC3061], or any other future URN namespace
+ that is appropriate for SMPTE Universal Labels.
+
+ Note that, per [RFC2045], some characters (including the comma used
+ to separate multiple values) require that the entire parameter value
+ be enclosed in quotes.
+
+ Below is an example of use of the optional parameter. The two SMPTE
+ Universal Labels indicate that the MXF file uses the OP1a Operational
+ Pattern and contains IEC DV video at 25 Mbps, 525 lines, 59.94 fps
+ interlaced essence.
+
+
+
+
+
+Edwards Informational [Page 3]
+
+RFC 4539 Media Type Registration for MXF May 2006
+
+
+ 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"
+
+ 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
+
+
+
+Edwards Informational [Page 4]
+
+RFC 4539 Media Type Registration for MXF May 2006
+
+
+ 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
+
+
+
+
+
+Edwards Informational [Page 5]
+
+RFC 4539 Media Type Registration for MXF May 2006
+
+
+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).
+
+
+
+
+
+
+
+Edwards Informational [Page 6]
+