summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6597.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6597.txt')
-rw-r--r--doc/rfc/rfc6597.txt731
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc6597.txt b/doc/rfc/rfc6597.txt
new file mode 100644
index 0000000..5686d21
--- /dev/null
+++ b/doc/rfc/rfc6597.txt
@@ -0,0 +1,731 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) J. Downs, Ed.
+Request for Comments: 6597 PAR Government Systems Corp.
+Category: Standards Track J. Arbeiter, Ed.
+ISSN: 2070-1721 April 2012
+
+
+ RTP Payload Format for
+ Society of Motion Picture and Television Engineers (SMPTE)
+ ST 336 Encoded Data
+
+Abstract
+
+ This document specifies the payload format for packetization of KLV
+ (Key-Length-Value) Encoded Data, as defined by the Society of Motion
+ Picture and Television Engineers (SMPTE) in SMPTE ST 336, into the
+ Real-time Transport Protocol (RTP).
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 5741.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc6597.
+
+Copyright Notice
+
+ Copyright (c) 2012 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+Downs & Arbeiter Standards Track [Page 1]
+
+RFC 6597 RTP Format for SMPTE ST 336 Data April 2012
+
+
+Table of Contents
+
+ 1. Introduction ....................................................2
+ 2. Conventions, Definitions, and Acronyms ..........................3
+ 3. Media Format Background .........................................3
+ 4. Payload Format ..................................................4
+ 4.1. RTP Header Usage ...........................................5
+ 4.2. Payload Data ...............................................5
+ 4.2.1. The KLVunit .........................................5
+ 4.2.2. KLVunit Mapping to RTP Packet Payload ...............6
+ 4.3. Implementation Considerations ..............................6
+ 4.3.1. Loss of Data ........................................6
+ 4.3.1.1. Damaged KLVunits ...........................7
+ 4.3.1.2. Treatment of Damaged KLVunits ..............9
+ 5. Congestion Control ..............................................9
+ 6. Payload Format Parameters .......................................9
+ 6.1. Media Type Definition ......................................9
+ 6.2. Mapping to SDP ............................................10
+ 6.2.1. Offer/Answer Model and Declarative Considerations ..10
+ 7. IANA Considerations ............................................11
+ 8. Security Considerations ........................................11
+ 9. References .....................................................12
+ 9.1. Normative References ......................................12
+ 9.2. Informative References ....................................12
+
+1. Introduction
+
+ This document specifies the payload format for packetization of KLV
+ (Key-Length-Value) Encoded Data, as defined by the Society of Motion
+ Picture and Television Engineers (SMPTE) in [SMPTE-ST336], into the
+ Real-time Transport Protocol (RTP) [RFC3550].
+
+ The payload format is defined in such a way that arbitrary KLV data
+ can be carried. No restrictions are placed on which KLV data keys
+ can be used.
+
+ A brief description of SMPTE ST 336, "Data Encoding Protocol Using
+ Key-Length-Value", is given. The payload format itself, including
+ use of the RTP header fields, is specified in Section 4. The media
+ type and IANA considerations are also described. This document
+ concludes with security considerations relevant to this payload
+ format.
+
+
+
+
+
+
+
+
+
+Downs & Arbeiter Standards Track [Page 2]
+
+RFC 6597 RTP Format for SMPTE ST 336 Data April 2012
+
+
+2. Conventions, Definitions, and Acronyms
+
+ The term "Universal Label Key" is used in this document to refer to a
+ fixed-length, 16-byte SMPTE-administered Universal Label (see
+ [SMPTE-ST298]) that is used as an identifying key in a KLV item.
+
+ The term "KLV item" is used in this document to refer to one single
+ Universal Label Key, length, and value triplet encoded as described
+ in [SMPTE-ST336].
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+3. Media Format Background
+
+ [SMPTE-ST336], "Data Encoding Protocol Using Key-Length-Value",
+ defines a byte-level data encoding protocol for representing data
+ items and data groups. This encoding protocol definition is
+ independent of the application or transportation method used.
+
+ SMPTE ST 336 data encoding can be applied to a wide variety of binary
+ data. This encoding has been used to provide diverse and rich
+ metadata sets that describe or enhance associated video
+ presentations. Use of SMPTE ST 336 encoded metadata in conjunction
+ with video has enabled improvements in multimedia presentations,
+ content management and distribution, archival and retrieval, and
+ production workflow.
+
+ The SMPTE ST 336 standard defines a KLV triplet as a data interchange
+ protocol for data items or data groups where the Key identifies the
+ data, the Length specifies the length of the data, and the Value is
+ the data itself. The KLV protocol provides a common interchange
+ point for all compliant applications irrespective of the method of
+ implementation or transport.
+
+ The Key of a KLV triplet (a Universal Label Key) is coded using a
+ fixed-length 16-byte SMPTE-administered Universal Label.
+ [SMPTE-ST298] further details the structure of 16-byte SMPTE-
+ administered Universal Labels. Universal Label Keys are maintained
+ in registries published by SMPTE (see, for example, [SMPTE-ST335] and
+ [SMPTE-RP210]).
+
+
+
+
+
+
+
+
+
+Downs & Arbeiter Standards Track [Page 3]
+
+RFC 6597 RTP Format for SMPTE ST 336 Data April 2012
+
+
+ The standard also provides methods for combining associated KLV
+ triplets in data sets where the set of KLV triplets is itself coded
+ with the KLV data coding protocol. Such sets can be coded in either
+ full form (Universal Sets) or one of four increasingly bit-efficient
+ forms (Global Sets, Local Sets, Variable Length Packs, and Defined
+ Length Packs). The standard provides a definition of each of these
+ data constructs.
+
+ Additionally, the standard defines the use of KLV coding to provide a
+ means to carry information that is registered with a non-SMPTE
+ external agency.
+
+4. Payload Format
+
+ The main goal of the payload format design for SMPTE ST 336 data is
+ to provide carriage of SMPTE ST 336 data over RTP in a simple, yet
+ robust manner. All forms of SMPTE ST 336 data can be carried by the
+ payload format. The payload format maintains simplicity by using
+ only the standard RTP headers and not defining any payload headers.
+
+ SMPTE ST 336 KLV data is broken into KLVunits. A KLVunit is simply a
+ logical grouping of otherwise unframed KLV data, grouped based on
+ source data timing (see Section 4.2.1). Each KLVunit is then placed
+ into one or more RTP packet payloads. The RTP header marker bit is
+ used to assist receivers in locating the boundaries of KLVunits.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Downs & Arbeiter Standards Track [Page 4]
+
+RFC 6597 RTP Format for SMPTE ST 336 Data April 2012
+
+
+4.1. RTP Header Usage
+
+ This payload format uses the RTP packet header fields as described in
+ the table below:
+
+ +-----------+-------------------------------------------------------+
+ | Field | Usage |
+ +-----------+-------------------------------------------------------+
+ | Timestamp | The RTP Timestamp encodes the instant along a |
+ | | presentation timeline that the entire KLVunit encoded |
+ | | in the packet payload is to be presented. When one |
+ | | KLVunit is placed in multiple RTP packets, the RTP |
+ | | timestamp of all packets comprising that KLVunit MUST |
+ | | be the same. The timestamp clock frequency is |
+ | | defined as a parameter to the payload format |
+ | | (Section 6). |
+ | | |
+ | M-bit | The RTP header marker bit (M) is used to demarcate |
+ | | KLVunits. Senders MUST set the marker bit to '1' for |
+ | | any RTP packet that contains the final byte of a |
+ | | KLVunit. For all other packets, senders MUST set the |
+ | | RTP header marker bit to '0'. This allows receivers |
+ | | to pass a KLVunit for parsing/decoding immediately |
+ | | upon receipt of the last RTP packet comprising the |
+ | | KLVunit. Without this, a receiver would need to wait |
+ | | for the next RTP packet with a different timestamp to |
+ | | arrive, thus signaling the end of one KLVunit and the |
+ | | start of another. |
+ +-----------+-------------------------------------------------------+
+
+ The remaining RTP header fields are used as specified in [RFC3550].
+
+4.2. Payload Data
+
+4.2.1. The KLVunit
+
+ A KLVunit is a logical collection of all KLV items that are to be
+ presented at a specific time. A KLVunit is comprised of one or more
+ KLV items. Compound items (sets, packs) are allowed as per
+ [SMPTE-ST336], but the contents of a compound item MUST NOT be split
+ across two KLVunits. Multiple KLV items in a KLVunit occur one after
+ another with no padding or stuffing between items.
+
+
+
+
+
+
+
+
+
+Downs & Arbeiter Standards Track [Page 5]
+
+RFC 6597 RTP Format for SMPTE ST 336 Data April 2012
+
+
+4.2.2. KLVunit Mapping to RTP Packet Payload
+
+ An RTP packet payload SHALL contain one, and only one, KLVunit or a
+ fragment thereof. KLVunits small enough to fit into a single RTP
+ packet (RTP packet size is up to the implementation but should
+ consider underlying transport/network factors such as MTU
+ limitations) are placed directly into the payload of the RTP packet,
+ with the first byte of the KLVunit (which is the first byte of a KLV
+ Universal Label Key) being the first byte of the RTP packet payload.
+
+ KLVunits too large to fit into a single RTP packet payload MAY span
+ multiple RTP packet payloads. When this is done, the KLVunit data
+ MUST be sent in sequential byte order, such that when all RTP packets
+ comprising the KLVunit are arranged in sequence number order,
+ concatenating the payload data together exactly reproduces the
+ original KLVunit.
+
+ Additionally, when a KLVunit is fragmented across multiple RTP
+ packets, all RTP packets transporting the fragments of a KLVunit MUST
+ have the same timestamp.
+
+ KLVunits are bounded with changes in RTP packet timestamps. The
+ marker (M) bit in the RTP packet headers marks the last RTP packet
+ comprising a KLVunit (see Section 4.1).
+
+4.3. Implementation Considerations
+
+4.3.1. Loss of Data
+
+ RTP is generally deployed in network environments where packet loss
+ might occur. RTP header fields enable detection of lost packets, as
+ described in [RFC3550]. When transmitting payload data described by
+ this payload format, packet loss can cause the loss of whole KLVunits
+ or portions thereof.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Downs & Arbeiter Standards Track [Page 6]
+
+RFC 6597 RTP Format for SMPTE ST 336 Data April 2012
+
+
+4.3.1.1. Damaged KLVunits
+
+ A damaged KLVunit is any KLVunit that was carried in one or more RTP
+ packets that have been lost. When a lost packet is detected (through
+ use of the sequence number header field), the receiver
+
+ o MUST consider the KLVunit partially received before a lost packet
+ as damaged. This damaged KLVunit includes all packets prior to
+ the lost one (in sequence number order) back to, but not
+ including, the most recent packet in which the M-bit in the RTP
+ header was set to '1'.
+
+ o MUST consider the first KLVunit received after a lost packet as
+ damaged. This damaged KLVunit includes the first packet after the
+ lost one (in sequence number order) and, if the first packet has
+ its M-bit in the RTP header set to '0', all subsequent packets up
+ to and including the next one with the M-bit in the RTP header set
+ to '1'.
+
+ The above applies, regardless of the M-bit value in the RTP header of
+ the lost packet itself. This enables very basic receivers to look
+ solely at the M-bit to determine the outer boundaries of damaged
+ KLVunits. For example, when a packet with the M-bit set to '1' is
+ lost, the KLVunit that the lost packet would have terminated is
+ considered damaged, as is the KLVunit comprised of packets received
+ subsequent to the lost packet (up to and including the next received
+ packet with the M-bit set to '1').
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Downs & Arbeiter Standards Track [Page 7]
+
+RFC 6597 RTP Format for SMPTE ST 336 Data April 2012
+
+
+ The example below illustrates how a receiver would handle a lost
+ packet in another possible packet sequence:
+
+ +---------+-------------+ +--------------+
+ | RTP Hdr | Data | | |
+ +---------+-------------+ +--------------+
+ .... | ts = 30 | KLV KLV ... | | | >---+
+ | M = 1 | | | | |
+ | seq = 5 | ... KLV KLV | | | |
+ +---------+-------------+ +--------------+ |
+ Last RTP pkt for time 30 Lost RTP Pkt |
+ (seq = 6) |
+ |
+ +--------------------------------------------------------+
+ |
+ | +---------+-------------+ +---------+-------------+
+ | | RTP Hdr | Data | | RTP Hdr | Data |
+ | +---------+-------------+ +---------+-------------+
+ +--> | ts = 45 | KLV KLV ... | | ts = 45 | ... KLV ... | >---+
+ | M = 0 | | | M = 1 | | |
+ | seq = 7 | ... KLV ... | | seq = 8 | ... KLV KLV | |
+ +---------+-------------+ +---------+-------------+ |
+ RTP pkt for time 45 Last RTP pkt for time 45 |
+ KLVunit carried in these two packets is "damaged" |
+ |
+ +----------------------------------------------------------------+
+ |
+ | +---------+-------------+
+ | | RTP Hdr | Data |
+ | +---------+-------------+
+ +--> | ts = 55 | KLV KLV ... | ....
+ | M = 1 | |
+ | seq = 9 | ... KLV ... |
+ +---------+-------------+
+ Last and only RTP pkt
+ for time 55
+
+ In this example, the packets with sequence numbers 7 and 8 contain
+ portions of a KLVunit with a timestamp of 45. This KLVunit is
+ considered "damaged" due to the missing RTP packet with sequence
+ number 6, which might have been part of this KLVunit. The KLVunit
+ for timestamp 30 (ended in packet with sequence number 5) is
+ unaffected by the missing packet. The KLVunit for timestamp 55,
+ carried in the packet with sequence number 9, is also unaffected by
+ the missing packet and is considered complete and intact.
+
+
+
+
+
+
+Downs & Arbeiter Standards Track [Page 8]
+
+RFC 6597 RTP Format for SMPTE ST 336 Data April 2012
+
+
+4.3.1.2. Treatment of Damaged KLVunits
+
+ SMPTE ST 336 KLV data streams are built in such a way that it is
+ possible to partially recover from errors or missing data in a
+ stream. Exact specifics of how damaged KLVunits are handled are left
+ to each implementation, as different implementations can have
+ differing capabilities and robustness in their downstream KLV payload
+ processing. Because some implementations can be particularly limited
+ in their capacity to handle damaged KLVunits, receivers MAY drop
+ damaged KLVunits entirely.
+
+5. Congestion Control
+
+ The general congestion control considerations for transporting RTP
+ data apply; see RTP [RFC3550] and any applicable RTP profile, like
+ AVP [RFC3551].
+
+ Further, SMPTE ST 336 data can be encoded in different schemes that
+ reduce the overhead associated with individual data items within the
+ overall stream. SMPTE ST 336 grouping constructs, such as local sets
+ and data packs, provide a mechanism to reduce bandwidth requirements.
+
+6. Payload Format Parameters
+
+ This RTP payload format is identified using the application/smpte336m
+ media type, which is registered in accordance with [RFC4855], and
+ using the template of [RFC4288].
+
+6.1. Media Type Definition
+
+ Type name: application
+
+ Subtype name: smpte336m
+
+ Required parameters:
+
+ rate: RTP timestamp clock rate. Typically chosen based on
+ sampling rate of metadata being transmitted, but other rates
+ can be specified.
+
+ Optional parameters: None
+
+ Encoding considerations: This media type is framed and binary; see
+ Section 4.8 of [RFC4288].
+
+ Security considerations: See Section 8 of RFC 6597.
+
+
+
+
+
+Downs & Arbeiter Standards Track [Page 9]
+
+RFC 6597 RTP Format for SMPTE ST 336 Data April 2012
+
+
+ Interoperability considerations: Data items in smpte336m can be very
+ diverse. Receivers might only be capable of interpreting a subset
+ of the possible data items; unrecognized items are skipped.
+ Agreement on data items to be used out of band, via application
+ profile or similar, is typical.
+
+ Published specification: RFC 6597
+
+ Applications that use this media type: Streaming of metadata
+ associated with simultaneously streamed video and transmission of
+ [SMPTE-ST336]-based media formats (e.g., Material Exchange Format
+ (MXF) [SMPTE-ST377]).
+
+ Additional Information: none
+
+ Person & email address to contact for further information: J. Downs
+ <jeff_downs@partech.com>; IETF Payload Working Group
+ <payload@ietf.org>
+
+ Intended usage: COMMON
+
+ Restrictions on usage: This media type depends on RTP framing, and
+ hence is only defined for transfer via RTP ([RFC3550]). Transport
+ within other framing protocols is not defined at this time.
+
+ Author:
+
+ J. Downs <jeff_downs@partech.com>
+
+ J. Arbeiter <jimsgti@gmail.com>
+
+ Change controller: IETF Payload working group delegated from the
+ IESG.
+
+6.2. Mapping to SDP
+
+ The mapping of the above defined payload format media type and its
+ parameters SHALL be done according to Section 3 of [RFC4855].
+
+6.2.1. Offer/Answer Model and Declarative Considerations
+
+ This payload format has no configuration or optional format
+ parameters. Thus, when offering SMPTE ST 336 Encoded Data over RTP
+ using the Session Description Protocol (SDP) in an Offer/Answer model
+ [RFC3264] or in a declarative manner (e.g., SDP in the Real-Time
+ Streaming Protocol (RTSP) [RFC2326] or the Session Announcement
+ Protocol (SAP) [RFC2974]), there are no specific considerations.
+
+
+
+
+Downs & Arbeiter Standards Track [Page 10]
+
+RFC 6597 RTP Format for SMPTE ST 336 Data April 2012
+
+
+7. IANA Considerations
+
+ IANA has registered application/smpte336m as specified in
+ Section 6.1. The media type has been added to the IANA registry for
+ "RTP Payload Format media types"
+ (http://www.iana.org/assignments/rtp-parameters).
+
+8. Security Considerations
+
+ RTP packets using the payload format defined in this specification
+ are subject to the security considerations discussed in the RTP
+ specification [RFC3550], and in any applicable RTP profile. The main
+ security considerations for the RTP packet carrying the RTP payload
+ format defined within this memo are confidentiality, integrity, and
+ source authenticity. Confidentiality is achieved by encryption of
+ the RTP payload. Integrity of the RTP packets is achieved through a
+ suitable cryptographic integrity protection mechanism. Cryptographic
+ systems may also allow the authentication of the source of the
+ payload. A suitable security mechanism for this RTP payload format
+ should provide confidentiality, integrity protection, and at least
+ source authentication capable of determining whether or not an RTP
+ packet is from a member of the RTP session.
+
+ Note that the appropriate mechanism to provide security to RTP and
+ payloads following this memo may vary. It is dependent on the
+ application, the transport, and the signaling protocol employed.
+ Therefore, a single mechanism is not sufficient, although if suitable
+ the usage of the Secure Real-time Transport Protocol (SRTP) [RFC3711]
+ is recommended. Other mechanisms that may be used are IPsec
+ [RFC4301] and Transport Layer Security (TLS) [RFC5246] (RTP over
+ TCP), but other alternatives may exist as well.
+
+ This RTP payload format presents the possibility for significant
+ non-uniformity in the receiver-side computational complexity during
+ processing of SMPTE ST 336 payload data. Because the length of SMPTE
+ ST 336 encoded data items is essentially unbounded, receivers must
+ take care when allocating resources used in processing. It is easy
+ to construct pathological data that would cause a naive decoder to
+ allocate large amounts of resources, resulting in denial-of-service
+ threats. Receivers SHOULD place limits on resource allocation that
+ are within the bounds set forth by any application profile in use.
+
+ This RTP payload format does not contain any inherently active
+ content. However, individual SMPTE ST 336 KLV items could be defined
+ to convey active content in a particular application. Therefore,
+ receivers capable of decoding and interpreting such data items should
+ use appropriate caution and security practices. In particular,
+ accepting active content from streams that lack authenticity or
+
+
+
+Downs & Arbeiter Standards Track [Page 11]
+
+RFC 6597 RTP Format for SMPTE ST 336 Data April 2012
+
+
+ integrity protection mechanisms places a receiver at risk of attacks
+ using spoofed packets. Receivers not capable of decoding such data
+ items are not at risk; unknown data items are skipped over and
+ discarded according to SMPTE ST 336 processing rules.
+
+9. References
+
+9.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
+ Jacobson, "RTP: A Transport Protocol for Real-Time
+ Applications", STD 64, RFC 3550, July 2003.
+
+ [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio
+ and Video Conferences with Minimal Control", STD 65,
+ RFC 3551, July 2003.
+
+ [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications
+ and Registration Procedures", BCP 13, RFC 4288,
+ December 2005.
+
+ [RFC4855] Casner, S., "Media Type Registration of RTP Payload
+ Formats", RFC 4855, February 2007.
+
+9.2. Informative References
+
+ [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
+ Streaming Protocol (RTSP)", RFC 2326, April 1998.
+
+ [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
+ Announcement Protocol", RFC 2974, October 2000.
+
+ [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer
+ Model with Session Description Protocol (SDP)",
+ RFC 3264, June 2002.
+
+ [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
+ K. Norrman, "The Secure Real-time Transport Protocol
+ (SRTP)", RFC 3711, March 2004.
+
+ [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
+ Internet Protocol", RFC 4301, December 2005.
+
+
+
+
+
+
+Downs & Arbeiter Standards Track [Page 12]
+
+RFC 6597 RTP Format for SMPTE ST 336 Data April 2012
+
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer
+ Security (TLS) Protocol Version 1.2", RFC 5246,
+ August 2008.
+
+ [SMPTE-RP210] Society of Motion Picture and Television Engineers,
+ "SMPTE RP 210v12:2010 Data Element Dictionary", 2010,
+ <http://www.smpte-ra.org/mdd/>.
+
+ [SMPTE-ST298] Society of Motion Picture and Television Engineers,
+ "SMPTE ST 298:2009 Universal Labels for Unique
+ Identification of Digital Data", 2009,
+ <http://www.smpte.org>.
+
+ [SMPTE-ST335] Society of Motion Picture and Television Engineers,
+ "SMPTE ST 335:2012 Metadata Element Dictionary
+ Structure", 2012, <http://www.smpte.org>.
+
+ [SMPTE-ST336] Society of Motion Picture and Television Engineers,
+ "SMPTE ST 336:2007 Data Encoding Protocol Using Key-
+ Length-Value", 2007, <http://www.smpte.org>.
+
+ [SMPTE-ST377] Society of Motion Picture and Television Engineers,
+ "SMPTE ST 377-1:2011 Material Exchange Format (MXF) -
+ File Format Specification", 2011,
+ <http://www.smpte.org>.
+
+Authors' Addresses
+
+ J. Downs (editor)
+ PAR Government Systems Corp.
+ US
+
+ EMail: jeff_downs@partech.com
+
+
+ J. Arbeiter (editor)
+ US
+
+ EMail: jimsgti@gmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+Downs & Arbeiter Standards Track [Page 13]
+