Movatterモバイル変換

Network Working Group                                         T. EdwardsRequest for Comments: 4539                                           PBSCategory: Informational                                         May 2006Media Type Registration for theSociety 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 Contents1. Introduction ....................................................22. Security Considerations .........................................33. IANA Considerations .............................................33.1. Media Type for SMPTE Material Exchange Format (MXF) ........34. References ......................................................54.1. Normative References .......................................54.2. Informative References .....................................5Edwards                      Informational                      [Page 1]

RFC 4539            Media Type Registration for MXF             May 20061.  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 20062.  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   inSection 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: noneEdwards                      Informational                      [Page 4]

RFC 4539            Media Type Registration for MXF             May 2006   Author/Change controller:   Thomas Edwards   email: tedwards@pbs.org4.  References4.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.orgEdwards                      Informational                      [Page 5]

RFC 4539            Media Type Registration for MXF             May 2006Full Copyright Statement   Copyright (C) The Internet Society (2006).   This document is subject to the rights, licenses and restrictions   contained inBCP 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 inBCP 78 andBCP 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 athttp://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]