draft-ietf-payload-rtp-klv-03.txt   draft-ietf-payload-rtp-klv-04.txt 
Payload Working Group J. Downs, Ed. Payload Working Group J. Downs, Ed.
Internet-Draft PAR Government Systems Corp. Internet-Draft PAR Government Systems Corp.
Intended status: Standards Track J. Arbeiter, Ed. Intended status: Standards Track J. Arbeiter, Ed.
Expires: August 4, 2012 February 1, 2012 Expires: September 2, 2012 March 1, 2012
RTP Payload Format for SMPTE 336M Encoded Data RTP Payload Format for SMPTE 336M Encoded Data
draft-ietf-payload-rtp-klv-03 draft-ietf-payload-rtp-klv-04
Abstract Abstract
This document specifies the payload format for packetization of KLV This document specifies the payload format for packetization of KLV
(Key-Length-Value) Encoded Data, as defined by the Society of Motion (Key-Length-Value) Encoded Data, as defined by the Society of Motion
Picture and Television Engineers (SMPTE) in SMPTE 336M, into the Picture and Television Engineers (SMPTE) in SMPTE 336M, into the
Real-time Transport Protocol (RTP). Real-time Transport Protocol (RTP).
Status of this Memo Status of this Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 4, 2012. This Internet-Draft will expire on September 2, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3
3. Media Format Background . . . . . . . . . . . . . . . . . . . 3 3. Media Format Background . . . . . . . . . . . . . . . . . . . 3
4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 4 4.1. RTP Header Usage . . . . . . . . . . . . . . . . . . . . . 4
4.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Payload Data . . . . . . . . . . . . . . . . . . . . . . . 5
4.2.1. The KLVunit . . . . . . . . . . . . . . . . . . . . . 5 4.2.1. The KLVunit . . . . . . . . . . . . . . . . . . . . . 5
4.2.2. KLVunit Mapping to RTP Packet Payload . . . . . . . . 5 4.2.2. KLVunit Mapping to RTP Packet Payload . . . . . . . . 5
4.3. Implementation Considerations . . . . . . . . . . . . . . 6 4.3. Implementation Considerations . . . . . . . . . . . . . . 6
4.3.1. Loss of Data . . . . . . . . . . . . . . . . . . . . . 6 4.3.1. Loss of Data . . . . . . . . . . . . . . . . . . . . . 6
4.3.1.1. Damaged KLVunits . . . . . . . . . . . . . . . . . 6 4.3.1.1. Damaged KLVunits . . . . . . . . . . . . . . . . . 6
4.3.1.2. Treatment of Damaged KLVunits . . . . . . . . . . 7 4.3.1.2. Treatment of Damaged KLVunits . . . . . . . . . . 8
5. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 8 5. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 8
6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 8 6. Payload Format Parameters . . . . . . . . . . . . . . . . . . 8
6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 8 6.1. Media Type Definition . . . . . . . . . . . . . . . . . . 8
6.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Mapping to SDP . . . . . . . . . . . . . . . . . . . . . . 9
6.2.1. Offer/Answer Model and Declarative Considerations . . 9 6.2.1. Offer/Answer Model and Declarative Considerations . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . . 11
skipping to change at page 3, line 24 skipping to change at page 3, line 24
can be used. can be used.
A brief description of SMPTE 336M, KLV Encoded Data, is given. The A brief description of SMPTE 336M, KLV Encoded Data, is given. The
payload format itself, including use of the RTP header fields, is payload format itself, including use of the RTP header fields, is
specified in Section 4. The media type and IANA considerations are specified in Section 4. The media type and IANA considerations are
also described. This document concludes with security considerations also described. This document concludes with security considerations
relevant to this payload format. relevant to this payload format.
2. Conventions, Definitions and Acronyms 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
[SMPTE298M]) 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 The term "KLV item" is used in this document to refer to one single
universal key, length, and value triplet, or one single SMPTE Universal Label Key, length, and value triplet encoded as described
Universal Label, encoded as described in [SMPTE336M]. in [SMPTE336M].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Media Format Background 3. Media Format Background
[SMPTE336M], Data Encoding Protocol Using Key-Length-Value, defines a [SMPTE336M], Data Encoding Protocol Using Key-Length-Value, defines a
byte-level data encoding protocol for representing data items and byte-level data encoding protocol for representing data items and
data groups. This encoding protocol definition is independent of the data groups. This encoding protocol definition is independent of the
skipping to change at page 4, line 7 skipping to change at page 4, line 12
content management and distribution, archival and retrieval, and content management and distribution, archival and retrieval, and
production workflow. production workflow.
The SMPTE 336M standard defines a Key-Length-Value (KLV) triplet as a The SMPTE 336M standard defines a Key-Length-Value (KLV) triplet as a
data interchange protocol for data items or data groups where the Key data interchange protocol for data items or data groups where the Key
identifies the data, the Length specifies the length of the data and identifies the data, the Length specifies the length of the data and
the Value is the data itself. The KLV protocol provides a common the Value is the data itself. The KLV protocol provides a common
interchange point for all compliant applications irrespective of the interchange point for all compliant applications irrespective of the
method of implementation or transport. 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. [SMPTE298M]
further details the structure of 16-byte SMPTE-administered Universal
Labels. Universal Label Keys are maintained in registries published
by SMPTE (see, for example, [SMPTE335M] and [SMPTERP210]).
The standard also provides methods for combining associated KLV The standard also provides methods for combining associated KLV
triplets in data sets where the set of KLV triplets is itself coded triplets in data sets where the set of KLV triplets is itself coded
with KLV data coding protocol. Such sets can be coded in either full with KLV data coding protocol. Such sets can be coded in either full
form (Universal Sets) or in one of four increasingly bit-efficient form (Universal Sets) or in one of four increasingly bit-efficient
forms (Global Sets, Local Sets, Variable Length Packs and Defined forms (Global Sets, Local Sets, Variable Length Packs and Defined
Length Packs). The standard provides a definition of each of these Length Packs). The standard provides a definition of each of these
data constructs. data constructs.
The standard also describes implications of KLV coding including the Additionally, the standard defines the use of KLV coding to provide a
use of a SMPTE Universal Label (UL) as a value within a KLV coding means to carry information that is registered with a non-SMPTE
triplet or whose meaning is entirely conveyed by the SMPTE UL itself. external agency.
The two kinds of usage for such standalone SMPTE ULs are a) as a
value in a KLV construct and b) as a Key that has no Length and no
Value.
The standard also defines the use of KLV coding to provide a means to
carry information that is registered with a non-SMPTE external
agency.
The encoding byte range (length of the payload) can accommodate
unusually large volumes of data. Consequently, a specific
application of KLV encoding might require only a limited operating
data range and those details shall be defined in a relevant
application document.
4. Payload Format 4. Payload Format
The main goal of the payload format design for SMPTE 336M data is to The main goal of the payload format design for SMPTE 336M data is to
provide carriage of SMPTE 336M data over RTP in a simple, yet robust provide carriage of SMPTE 336M data over RTP in a simple, yet robust
manner. All forms of SMPTE 336M data can be carried by the payload manner. All forms of SMPTE 336M data can be carried by the payload
format. The payload format maintains simplicity by using only the format. The payload format maintains simplicity by using only the
standard RTP headers and not defining any payload headers. standard RTP headers and not defining any payload headers.
SMPTE 336M KLV data is broken into KLVunits. A KLVunit is simply a SMPTE 336M KLV data is broken into KLVunits. A KLVunit is simply a
skipping to change at page 5, line 13 skipping to change at page 5, line 13
the table below: the table below:
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Field | Usage | | Field | Usage |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Timestamp | The RTP Timestamp encodes the instant along a | | Timestamp | The RTP Timestamp encodes the instant along a |
| | presentation timeline that the entire KLVunit encoded | | | presentation timeline that the entire KLVunit encoded |
| | in the packet payload is to be presented. When one | | | in the packet payload is to be presented. When one |
| | KLVunit is placed in multiple RTP packets, the RTP | | | KLVunit is placed in multiple RTP packets, the RTP |
| | timestamp of all packets comprising that KLVunit MUST | | | timestamp of all packets comprising that KLVunit MUST |
| | be the same. The timestamp clock frequency SHALL be | | | be the same. The timestamp clock frequency is defined |
| | defined as a parameter to the payload format | | | as a parameter to the payload format (Section 6). |
| | (Section 6). | | M-bit | The RTP header marker bit (M) is used to demarcate |
| M-bit | The RTP header marker bit (M) SHALL be set to '1' for | | | KLVunits. Senders MUST set the marker bit to '1' for |
| | any RTP packet which contains the final byte of a | | | any RTP packet which contains the final byte of a |
| | KLVunit. For all other packets, the RTP header marker | | | KLVunit. For all other packets, senders MUST set the |
| | bit SHALL be set to '0'. This allows receivers to | | | RTP header marker bit to '0'. This allows receivers |
| | pass a KLVunit for parsing/decoding immediately upon | | | to pass a KLVunit for parsing/decoding immediately |
| | receipt of the last RTP packet comprising the | | | upon receipt of the last RTP packet comprising the |
| | KLVunit. Without this, a receiver would need to wait | | | KLVunit. Without this, a receiver would need to wait |
| | for the next RTP packet with a different timestamp to | | | for the next RTP packet with a different timestamp to |
| | arrive, thus signaling the end of one KLVunit and the | | | arrive, thus signaling the end of one KLVunit and the |
| | start of another. | | | start of another. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
The remaining RTP header fields are used as specified in [RFC3550]. The remaining RTP header fields are used as specified in [RFC3550].
4.2. Payload Data 4.2. Payload Data
skipping to change at page 5, line 48 skipping to change at page 5, line 48
across two KLVunits. Multiple KLV items in a KLVunit occur one after across two KLVunits. Multiple KLV items in a KLVunit occur one after
another with no padding or stuffing between items. another with no padding or stuffing between items.
4.2.2. KLVunit Mapping to RTP Packet Payload 4.2.2. KLVunit Mapping to RTP Packet Payload
An RTP packet payload SHALL contain one, and only one, KLVunit or a An RTP packet payload SHALL contain one, and only one, KLVunit or a
fragment thereof. KLVunits small enough to fit into a single RTP fragment thereof. KLVunits small enough to fit into a single RTP
packet (RTP packet size is up to implementation but should consider packet (RTP packet size is up to implementation but should consider
underlying transport/network factors such as MTU limitations) are underlying transport/network factors such as MTU limitations) are
placed directly into the payload of the RTP packet, with the first 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 key) byte of the KLVunit (which is the first byte of a KLV Universal Label
being the first byte of the RTP packet payload. Key) being the first byte of the RTP packet payload.
KLVunits too large to fit into a single RTP packet payload MAY span KLVunits too large to fit into a single RTP packet payload MAY span
multiple RTP packet payloads. When this is done, the KLVunit data multiple RTP packet payloads. When this is done, the KLVunit data
MUST be sent in sequential byte order, such that when all RTP packets MUST be sent in sequential byte order, such that when all RTP packets
comprising the KLVunit are arranged in sequence number order, comprising the KLVunit are arranged in sequence number order,
concatenating the payload data together exactly reproduces the concatenating the payload data together exactly reproduces the
original KLVunit. original KLVunit.
Additionally, when a KLVunit is fragmented across multiple RTP Additionally, when a KLVunit is fragmented across multiple RTP
packets, all RTP packets transporting the fragments a KLVunit MUST packets, all RTP packets transporting the fragments of a KLVunit MUST
have the same timestamp. have the same timestamp.
KLVunits are bounded with changes in RTP packet timestamps. The KLVunits are bounded with changes in RTP packet timestamps. The
marker (M) bit in the RTP packet headers marks the last RTP packet marker (M) bit in the RTP packet headers marks the last RTP packet
comprising a KLVunit (see Section 4.1). A receiver MUST consider a comprising a KLVunit (see Section 4.1).
KLVunit to be completed when it receives either a packet with M=1 or
a packet with a new timestamp. In the former case, the packet
payload is included in the completed KLVunit; in the latter case, it
is not.
4.3. Implementation Considerations 4.3. Implementation Considerations
4.3.1. Loss of Data 4.3.1. Loss of Data
RTP is generally deployed in network environments where packet loss RTP is generally deployed in network environments where packet loss
might occur. RTP header fields enable detection of lost packets, as might occur. RTP header fields enable detection of lost packets, as
described in [RFC3550]. When transmitting payload data described by described in [RFC3550]. When transmitting payload data described by
this payload format, packet loss can cause the loss of whole KLVunits this payload format, packet loss can cause the loss of whole KLVunits
or portions thereof. or portions thereof.
4.3.1.1. Damaged KLVunits 4.3.1.1. Damaged KLVunits
A damaged KLVunit is any KLVunit that was carried in one or more RTP 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 packets that have been lost. When a lost packet is detected (through
use of the sequence number header field), the receiver: use of the sequence number header field), the receiver:
o MUST consider any KLVunit presently being received as damaged. o MUST consider the KLVunit partially received before a lost packet
The damaged KLVunit includes all packets prior to the lost one (in as damaged. This damaged KLVunit includes all packets prior to
sequence number order) back to, but not including, the most recent the lost one (in sequence number order) back to, but not
packet in which the M bit in the RTP header was set to '1'. including, the most recent packet in which the M-bit in the RTP
header was set to '1'.
o MUST consider all subsequent packets (in sequence number order) up o MUST consider the first KLVunit received after a lost packet as
to and including the next one with the M-bit in the RTP header set damaged. This damaged KLVunit includes the first packet after the
to '1' as part of a damaged KLVunit. lost one (in sequence number order) and, if the first packet has
its M-bit in the RTP header is 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 M-bit set to '1').
The example below illustrates how a receiver would handle a lost The example below illustrates how a receiver would handle a lost
packet in one possible packet sequence: packet in another possible packet sequence:
+---------+-------------+ +--------------+ +---------+-------------+ +--------------+
| RTP Hdr | Data | | | | RTP Hdr | Data | | |
+---------+-------------+ +--------------+ +---------+-------------+ +--------------+
.... | ts = 30 | KLV KLV ... | | | >---+ .... | ts = 30 | KLV KLV ... | | | >---+
| M = 1 | | | | | | M = 1 | | | | |
| seq = 5 | ... KLV KLV | | | | | seq = 5 | ... KLV KLV | | | |
+---------+-------------+ +--------------+ | +---------+-------------+ +--------------+ |
Last RTP pkt for time 30 Lost RTP Pkt | Last RTP pkt for time 30 Lost RTP Pkt |
(seq = 6) | (seq = 6) |
skipping to change at page 9, line 44 skipping to change at page 10, line 4
6.2. Mapping to SDP 6.2. Mapping to SDP
The mapping of the above defined payload format media type and its The mapping of the above defined payload format media type and its
parameters SHALL be done according to Section 3 of [RFC4855]. parameters SHALL be done according to Section 3 of [RFC4855].
6.2.1. Offer/Answer Model and Declarative Considerations 6.2.1. Offer/Answer Model and Declarative Considerations
This payload format has no configuration or optional format This payload format has no configuration or optional format
parameters. Thus, when offering SMPTE 336M Encoded Data over RTP parameters. Thus, when offering SMPTE 336M Encoded Data over RTP
using SDP in an Offer/Answer model [RFC3264] or in a declarative using Session Description Protocol (SDP) in an Offer/Answer model
manner (e.g., SDP in the Real-time Streaming Protocol (RTSP) [RFC3264] or in a declarative manner (e.g., SDP in the Real-time
[RFC2326] or the Session Announcement Protocol (SAP) [RFC2974]), Streaming Protocol (RTSP) [RFC2326] or the Session Announcement
there are no specific considerations. Protocol (SAP) [RFC2974]), there are no specific considerations.
7. IANA Considerations 7. IANA Considerations
This memo requests that IANA registers application/smpte336m as This memo requests that IANA registers application/smpte336m as
specified in Section 6.1. The media type is also requested to be specified in Section 6.1. The media type is also requested to be
added to the IANA registry for "RTP Payload Format MIME types" added to the IANA registry for "RTP Payload Format MIME types"
(http://www.iana.org/assignments/rtp-parameters). (http://www.iana.org/assignments/rtp-parameters).
8. Security Considerations 8. Security Considerations
RTP packets using the payload format defined in this specification RTP packets using the payload format defined in this specification
are subject to the security considerations discussed in the RTP are subject to the security considerations discussed in the RTP
specification [RFC3550], and in any applicable RTP profile. The main specification [RFC3550], and in any applicable RTP profile. The main
security considerations for the RTP packet carrying the RTP payload security considerations for the RTP packet carrying the RTP payload
format defined within this memo are confidentiality, integrity and format defined within this memo are confidentiality, integrity and
source authenticity. Confidentiality is achieved by encryption of source authenticity. Confidentiality is achieved by encryption of
the RTP payload. Integrity of the RTP packets through suitable the RTP payload. Integrity of the RTP packets through suitable
cryptographic integrity protection mechanism. Cryptographic system cryptographic integrity protection mechanism. Cryptographic systems
may also allow the authentication of the source of the payload. A may also allow the authentication of the source of the payload. A
suitable security mechanism for this RTP payload format should suitable security mechanism for this RTP payload format should
provide confidentiality, integrity protection and at least source provide confidentiality, integrity protection and at least source
authentication capable of determining if an RTP packet is from a authentication capable of determining if an RTP packet is from a
member of the RTP session or not. member of the RTP session or not.
Note that the appropriate mechanism to provide security to RTP and Note that the appropriate mechanism to provide security to RTP and
payloads following this memo may vary. It is dependent on the payloads following this memo may vary. It is dependent on the
application, the transport, and the signalling protocol employed. application, the transport, and the signaling protocol employed.
Therefore a single mechanism is not sufficient, although if suitable Therefore a single mechanism is not sufficient, although if suitable
the usage of SRTP [RFC3711] is recommended. Other mechanism that may the usage of SRTP [RFC3711] is recommended. Other mechanisms that
be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but may be used are IPsec [RFC4301] and TLS [RFC5246] (RTP over TCP), but
also other alternatives may exist. also other alternatives may exist.
This RTP payload format presents the possibility for significant non- This RTP payload format presents the possibility for significant non-
uniformity in the receiver-side computational complexity during uniformity in the receiver-side computational complexity during
processing of SMPTE 336M payload data. Because the length of SMPTE processing of SMPTE 336M payload data. Because the length of SMPTE
336M encoded data items is essentially unbounded, receivers must take 336M encoded data items is essentially unbounded, receivers must take
care when allocating resources used in processing. It is trivial to care when allocating resources used in processing. It is trivial to
construct pathological data that would cause a naive decoder to construct pathological data that would cause a naive decoder to
allocate large amounts of resources, resulting in denial-of-service allocate large amounts of resources, resulting in denial-of-service
threats. Receivers SHOULD place limits on resource allocation that threats. Receivers SHOULD place limits on resource allocation that
are within the bounds set forth by any application profile in use. are within the bounds set forth by any application profile in use.
This RTP payload format does not contain any inheritly active This RTP payload format does not contain any inherently active
content. However, individual SMPTE 336M KLV items could be defined content. However, individual SMPTE 336M KLV items could be defined
to convey active content in a particular application. Therefore, to convey active content in a particular application. Therefore,
receivers capable of decoding and interpreting such data items should receivers capable of decoding and interpreting such data items should
use appropriate caution and security practices. In particular, use appropriate caution and security practices. In particular,
accepting active content from streams that lack authenticity or accepting active content from streams that lack authenticity or
integrity proteciton mechanisms places a receiver at risk to attacks integrity protection mechanisms places a receiver at risk of attacks
using spoofed packets. Receivers not capable of decoding such data using spoofed packets. Receivers not capable of decoding such data
items are not at risk; unknown data items are skipped over and items are not at risk; unknown data items are skipped over and
discarded according to SMPTE 336M processing rules. discarded according to SMPTE 336M processing rules.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 11, line 30 skipping to change at page 11, line 37
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551, Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003. July 2003.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005. Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Formats", RFC 4855, February 2007. Formats", RFC 4855, February 2007.
[SMPTE336M]
Society of Motion Picture and Television Engineers,
"SMPTE336M-2007: Data Encoding Protocol Using Key-Length-
Value", 2007, <http://www.smpte.org>.
9.2. Informative References 9.2. Informative References
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time [RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC 2326, April 1998. Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
skipping to change at page 12, line 11 skipping to change at page 12, line 11
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[SMPTE377M] [SMPTE298M]
Society of Motion Picture and Television Engineers, "ANSI/
SMPTE 298M-1997: Universal Labels for Unique
Identification of Digital Data", 1997,
<http://www.smpte.org>.
[SMPTE335M]
Society of Motion Picture and Television Engineers, "SMPTE
335M-2001: Metadata Dictionary Structure", 2001,
<http://www.smpte.org>.
[SMPTE336M]
Society of Motion Picture and Television Engineers, Society of Motion Picture and Television Engineers,
"SMPTE377M-2004: Material Exchange Format (MXF) File "SMPTE336M-2007: Data Encoding Protocol Using Key-Length-
Format Specification", 2004, <http://www.smpte.org>. Value", 2007, <http://www.smpte.org>.
[SMPTE377M]
Society of Motion Picture and Television Engineers, "SMPTE
377M-2004: Material Exchange Format (MXF) File Format
Specification", 2004, <http://www.smpte.org>.
[SMPTERP210]
Society of Motion Picture and Television Engineers, "SMPTE
RP 210v12: Metadata Dictionary Registry of Metadata
Element Descriptions", 2010, <http://www.smpte.org>.
Authors' Addresses Authors' Addresses
J. Downs (editor) J. Downs (editor)
PAR Government Systems Corp. PAR Government Systems Corp.
US US
Phone: Phone:
Email: jeff_downs@partech.com Email: jeff_downs@partech.com
J. Arbeiter (editor) J. Arbeiter (editor)
US US
Phone: Phone:
Email: jimsgti@gmail.com Email: jimsgti@gmail.com
 End of changes. 26 change blocks. 
65 lines changed or deleted 86 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/