idnits 2.17.1 draft-edwards-mime-mxf-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 276. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2006) is 6630 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'SMPTE377M' -- Possible downref: Non-RFC (?) normative reference: ref. 'SMPTE400M' -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Edwards 3 Internet-Draft PBS 4 Expires: September 4, 2006 March 3, 2006 6 Media Type Registration for SMPTE Material Exchange Format (MXF) 7 draft-edwards-mime-mxf-03 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 4, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document serves to register a media type for the SMPTE Material 41 Exchange Format (MXF). MXF, defined by SMPTE 377M, is a standard 42 wrapper format developed for the interchange of audiovisual material, 43 including both audiovisual essence and rich metadata. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Security Considerations . . . . . . . . . . . . . . . . . . . . 3 49 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 50 3.1. Media Type for SMPTE Material Exchange Format (MXF) . . . . 4 51 4. RFC Editor Considerations . . . . . . . . . . . . . . . . . . . 6 52 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 53 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 54 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 55 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 Intellectual Property and Copyright Statements . . . . . . . . . . 9 58 1. Introduction 60 The present document registers a media type for SMPTE Material 61 Exchange Format (MXF). MXF, defined by SMPTE 377M [SMPTE377M], is a 62 standard wrapper format developed for the interchange of audiovisual 63 material, including both audiovisual essence and rich metadata. 65 Essence is the raw video, audio, and data streams contained and 66 described by MXF. Metadata carried by MXF includes structural 67 metadata and descriptive metadata. Structural metadata relates to 68 the structure and capabilities of the MXF file, and is generally 69 required for proper decoding. Some examples of structural metadata 70 are descriptions of essence types, information to help synchronize 71 playout of audio and video, and content length. Descriptive metadata 72 gives information about the program content in the file, and is not 73 essential for decoding. Some examples of descriptive metadata are 74 program title, actors, and scene descriptions. The essence in MXF 75 files may itself carry data, such as vertical blanking interval data 76 used for carriage of Closed Captioning and other purposes. 78 MXF is an important tool in providing interoperation between 79 different video systems as well as digital cinema systems. MXF also 80 aids in the development of video production and distribution 81 workflows that are more efficient, multi-vendor, file-based, and IT- 82 oriented. 84 SMPTE currently has standards for the mapping of the following 85 essence types to the MXF generic container: MPEG (including MPEG-1 86 and MPEG-2 video streams, as well as MPEG audio), DV-DIF (Digital 87 Video Digital Interface Format for the DV family of related video 88 encodings), Uncompressed Pictures, SDTI-CP (Serial Digital Transport 89 Interface Content Package for delivering packetized audiovisual 90 content over the SDI interface), D-10 (a specialized video stream 91 incorporating MPEG-2 4:2:2P@ML), D-11 (a high-definition video 92 compression standard), AES3 audio, Broadcast Wave audio, and A-Law 93 audio. The flexibility of the MXF generic container allows for the 94 possibility of mappings of additional essence types in the future. 96 The media type defined here is needed to correctly identify MXF files 97 when they are served over HTTP or other network connections, included 98 in multi-part documents, indexed by operating systems and digital 99 asset management systems, or when used in other places where media 100 types are used. 102 2. Security Considerations 104 Security requirements for the application/mxf media type are 105 discussed in the IANA media type registration (Section 3.1). 107 3. IANA Considerations 109 The present document requests that IANA registers the media type 110 application/mxf as specified in Section 3.1. The registration uses 111 the template present in [RFC4288]. 113 3.1. Media Type for SMPTE Material Exchange Format (MXF) 115 To: ietf-types@iana.org 116 Subject: Registration of media type application/mxf 118 Type name: application 120 Subtype name: mxf 122 Required parameters: none 124 Optional parameters: ULs 126 The optional parameter ULs is a single Uniform Resource Name 127 (URN), or a comma-separated list of multiple URNs of SMPTE 128 Universal Labels (which are defined by SMPTE 400M [SMPTE400M]). 130 This optional parameter provides hints to the decoder regarding 131 the structure of the MXF file, which could include Operational 132 Pattern, essence types, descriptive metadata schemes, and other 133 elements that are identified by their SMPTE Universal Label. 135 SMPTE Universal Labels are Object Identifiers (OIDs) as specified 136 by [ASN1]. Thus a URN of a SMPTE Universal Label can use the OID 137 URN namespace specified in [RFC3061], or any other future URN 138 namespace that is appropriate for SMPTE Universal Labels. 140 Note that, per [RFC2045], some characters (including the comma 141 used to separate multiple values) require that the entire 142 parameter value be enclosed in quotes. 144 Below is an example of use of the optional parameter. The two 145 SMPTE Universal Labels indicate that the MXF file utilizes the 146 OP1a Operational Pattern and contains IEC DV video at 25 Mbps, 525 147 lines, 59.94 fps interlaced essence. 149 Content-Type: application/mxf; 150 ULs="urn:oid:1.3.52.4.1.1.1.13.1.2.1.1.1, 151 urn:oid:1.3.52.4.1.1.1.4.1.2.2.2.1.1" 153 Encoding considerations: binary 155 Security considerations: Application/mxf objects are not signed 156 but may be partially encrypted internally. External security 157 mechanisms must be employed to ensure content confidentiality. 158 MXF, through metadata extensions, may allow executable code to be 159 transferred in the file. It is suggested that no unauthenticated 160 executables decoded from an MXF file be executed. Some compressed 161 essence types carried in MXF may carry a risk that certain 162 pathological bitstreams could lead to potential denial-of-service 163 attacks against these essence decoders. 165 Interoperability considerations: MXF provides a standard wrapping 166 for a number of audio and video essence types according to a 167 number of different Operational Patterns (OP). Thus 168 interoperability depends upon the MXF file decoder having the 169 capability to match the features of the MXF file encoder. An 170 Application Specification (AS) can ensure that MXF encoders and 171 decoders can effectively interoperate. 173 Published specification: RFC XXXX, SMPTE 377M [SMPTE377M] 175 Applications which use this media type: MXF is a wrapper for many 176 types of audio and video essence types in use by many applications 177 in the broadcast and digital cinema industries. These include 178 non-linear editing systems, video servers, video camera systems, 179 digital asset management systems, and digital video distribution 180 systems. 182 Additional information: 184 Magic number(s): none 186 File extension(s): .mxf 188 Macintosh File Type Code(s): "mxf " 190 Person & email address to contact for further information: 192 Thomas Edwards 193 email: tedwards@pbs.org 194 Intended usage: COMMON 196 Restrictions on usage: none 198 Author/Change controller: 200 Thomas Edwards 201 email: tedwards@pbs.org 203 4. RFC Editor Considerations 205 The reference to RFC XXXX in the media type registration 206 (Section 3.1) should be replaced with the actual RFC number of this 207 document when it is issued. 209 Please remove this section before publication as RFC. 211 5. References 213 5.1. Normative References 215 [SMPTE377M] 216 Society of Motion Picture and Television Engineers, 217 "Material Exchange Format (MXF) File Format 218 Specification", SMPTE 377M-2004, . 220 [SMPTE400M] 221 Society of Motion Picture and Television Engineers, "SMPTE 222 Labels Structure", SMPTE 400M-2004, 223 . 225 5.2. Informative References 227 [ASN1] International Telephone and Telegraph Consultative 228 Committee, "Specification of Basic Encoding Rules for 229 Abstract Syntax Notation One (ASN.1)", 230 CCITT Recommendation X.209, January 1988. 232 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 233 Extensions (MIME) Part One: Format of Internet Message 234 Bodies", RFC 2045, November 1996. 236 [RFC3061] Mealling, M., "A URN Namespace of Object Identifiers", 237 RFC 3061, February 2001. 239 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 240 Registration Procedures", BCP 13, RFC 4288, December 2005. 242 Author's Address 244 Thomas G. Edwards 245 PBS 246 1320 Braddock Place 247 Alexandria, VA 22314 248 US 250 Phone: +1 703 739 5000 251 Email: tedwards@pbs.org 252 URI: http://www.pbs.org 254 Intellectual Property Statement 256 The IETF takes no position regarding the validity or scope of any 257 Intellectual Property Rights or other rights that might be claimed to 258 pertain to the implementation or use of the technology described in 259 this document or the extent to which any license under such rights 260 might or might not be available; nor does it represent that it has 261 made any independent effort to identify any such rights. Information 262 on the procedures with respect to rights in RFC documents can be 263 found in BCP 78 and BCP 79. 265 Copies of IPR disclosures made to the IETF Secretariat and any 266 assurances of licenses to be made available, or the result of an 267 attempt made to obtain a general license or permission for the use of 268 such proprietary rights by implementers or users of this 269 specification can be obtained from the IETF on-line IPR repository at 270 http://www.ietf.org/ipr. 272 The IETF invites any interested party to bring to its attention any 273 copyrights, patents or patent applications, or other proprietary 274 rights that may cover technology that may be required to implement 275 this standard. Please address the information to the IETF at 276 ietf-ipr@ietf.org. 278 Disclaimer of Validity 280 This document and the information contained herein are provided on an 281 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 282 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 283 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 284 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 285 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 286 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 288 Copyright Statement 290 Copyright (C) The Internet Society (2006). This document is subject 291 to the rights, licenses and restrictions contained in BCP 78, and 292 except as set forth therein, the authors retain all their rights. 294 Acknowledgment 296 Funding for the RFC Editor function is currently provided by the 297 Internet Society.