< draft-ietf-avt-rfc3555bis-04.txt   draft-ietf-avt-rfc3555bis-05.txt >
Internet Engineering Task Force Audio/Video Transport Working Group Internet Engineering Task Force Audio/Video Transport Working Group
Internet-Draft S. Casner Internet-Draft S. Casner
draft-ietf-avt-rfc3555bis-04.txt Packet Design draft-ietf-avt-rfc3555bis-05.txt Packet Design
Obsoletes: RFC 3555 (if approved) April 17, 2006 Obsoletes: RFC 3555 (if approved) October 15, 2006
Expires: October 17, 2006 Expires: April 15, 2007
Media Type Registration of RTP Payload Formats Media Type Registration of RTP Payload Formats
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware will been or will be disclosed, and any of which he or she becomes aware will
be disclosed, in accordance with Section 6 of BCP 79. be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 26, 2006. This Internet-Draft will expire on April 15, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies the procedure to register RTP payload This document specifies the procedure to register RTP payload
formats as audio, video or other media subtype names. This is formats as audio, video or other media subtype names. This is
useful in a text-based format description or control protocol to useful in a text-based format description or control protocol to
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction .................................................. 3 1. Introduction .................................................. 3
1.2. Terminology .............................................. 3 1.2. Terminology .............................................. 3
2. Procedure For Registering Media Types for RTP Payload Types ... 3 2. Procedure For Registering Media Types for RTP Payload Types ... 3
2.1. Example Media Type Registration ........................... 5 2.1. Example Media Type Registration ........................... 5
2.2. Restrictions on Sharing a Subtype Name ................... 6 2.2. Restrictions on Sharing a Subtype Name ................... 6
3. Mapping to SDP Parameters ..................................... 7 3. Mapping to SDP Parameters ..................................... 7
4. Changes from RFC 3555 ......................................... 8 4. Changes from RFC 3555 ......................................... 8
5. Security Considerations ....................................... 8 5. Security Considerations ....................................... 8
6. IANA Considerations ........................................... 9 6. IANA Considerations ........................................... 10
7. References .................................................... 9 7. References .................................................... 10
8. Author's Address .............................................. 10 8. Author's Address .............................................. 11
9. Intellectual Property Statement ............................... 10 9. Intellectual Property Statement ............................... 11
10. Disclaimer of Validity ........................................ 10 10. Disclaimer of Validity ........................................ 12
11. Copyright Statement ........................................... 11 11. Copyright Statement ........................................... 12
1. Introduction 1. Introduction
RFC 4288 [1] defines media type specification and registration RFC 4288 [1] defines media type specification and registration
procedures that use the Internet Assigned Numbers Authority (IANA) as a procedures that use the Internet Assigned Numbers Authority (IANA) as a
central registry. That document covers general requirements independent central registry. That document covers general requirements independent
of particular application environments and transport modes. This of particular application environments and transport modes. This
document defines the specific requirements for registration of media document defines the specific requirements for registration of media
types for use with the Real-time Transport Protocol (RTP), RFC 3550 [2], types for use with the Real-time Transport Protocol (RTP), RFC 3550 [2],
to identify RTP payload formats. to identify RTP payload formats.
skipping to change at page 8, line 42 skipping to change at page 8, line 42
specified under restrictions on usage. This document also specifies the specified under restrictions on usage. This document also specifies the
conditions under which new optional parameters may be added to a conditions under which new optional parameters may be added to a
previously defined RTP media type and adds a new Section 2.2 to clarify previously defined RTP media type and adds a new Section 2.2 to clarify
the requirements for sharing a media type among RTP and non-RTP transfer the requirements for sharing a media type among RTP and non-RTP transfer
methods. methods.
RFC 3555 included media type registrations for the RTP payload formats RFC 3555 included media type registrations for the RTP payload formats
defined in the RTP Profile for Audio and Video Conferences, RFC 3551 defined in the RTP Profile for Audio and Video Conferences, RFC 3551
[4]. Those media type registrations have been removed from this [4]. Those media type registrations have been removed from this
document. Some of them have been assembled into a separate companion document. Some of them have been assembled into a separate companion
RFC XXXX [7], leaving out those that have been, or are intended to be, RFC XXXX [8], leaving out those that have been, or are intended to be,
registered in revisions of their own payload format specification RFCs. registered in revisions of their own payload format specification RFCs.
Philipp Hoschka is a co-author of RFC 3555; his contributions to the Philipp Hoschka is a co-author of RFC 3555; his contributions to the
foundation of this document are appreciated. foundation of this document are appreciated.
5. Security Considerations 5. Security Considerations
The media type registration procedure specified in this memo does not The media type registration procedure specified in this memo does not
impose any security considerations on its own. Registrations conforming impose any security considerations on its own. Registrations conforming
to this procedure also do not themselves impose security risks, but each to this procedure also do not themselves impose security risks.
is required to state any security considerations specific to use of the However, use of the media type being registered could very well impose
media type being registered. security risks:
Several audio and video encodings are perfect for hiding data using o Any media type that contains "active content" imposes the risk of
steganography. malicious side-effects unless execution of that content is
adequately constrained.
The RTP specification, RFC 3550, provides security considerations for o Several audio and video encodings are perfect for hiding data
the transport of audio and video data over RTP, including the use of using steganography.
encryption where confidentiality is required.
o The RTP specification, RFC 3550, provides security considerations
for the transport of audio and video data over RTP, including the
use of encryption where confidentiality is required.
Therefore, each media type registration is required to state any
security considerations that apply to the use of that type. The
remainder of this section is copied from RFC 4288 [1], which specifies
media type registration procedures in general.
An analysis of security issues MUST be done for all types registered in
the standards tree. A similar analysis for media types registered in
the vendor or personal trees is encouraged but not required. However,
regardless of what security analysis has or has not been done, all
descriptions of security issues MUST be as accurate as possible
regardless of registration tree. In particular, a statement that there
are "no security issues associated with this type" MUST NOT be confused
with "the security issues associates with this type have not been
assessed".
There is absolutely no requirement that media types registered in any
tree be secure or completely free from risks. Nevertheless, all known
security risks MUST be identified in the registration of a media type,
again regardless of registration tree.
The security considerations section of all registrations is subject to
continuing evaluation and modification, and in particular MAY be
extended by use of the "comments on media types" mechanism described in
RFC 4288 Section 6.
Some of the issues that should be looked at in a security analysis of a
media type are:
o Complex media types may include provisions for directives that
institute actions on a recipient's files or other resources. In
many cases provision is made for originators to specify arbitrary
actions in an unrestricted fashion that may then have devastating
effects. See the registration of the application/postscript
media type in RFC 2046 [7] for an example of such directives and
how they should be described in a media type registration.
o All registrations MUST state whether or not they employ such
"active content", and if they do, they MUST state what steps have
been taken to protect users of the media type from harm.
o Complex media types may include provisions for directives that
institute actions that, while not directly harmful to the
recipient, may result in disclosure of information that either
facilitates a subsequent attack or else violates a recipient's
privacy in some way. Again, the registration of the
application/postscript media type illustrates how such directives
can be handled.
o A media type that employs compression may provide an opportunity
for sending a small amount of data that, when received and
evaluated, expands enormously to consume all of the recipient's
resources. All media types SHOULD state whether or not they
employ compression, and if they do they should discuss what steps
need to be taken to avoid such attacks.
o A media type might be targeted for applications that require some
sort of security assurance but not provide the necessary security
mechanisms themselves. For example, a media type could be
defined for storage of confidential medical information that in
turn requires an external confidentiality service, or which is
designed for use only within a secure environment.
6. IANA Considerations 6. IANA Considerations
The purpose of this document is to specify the requirements and The purpose of this document is to specify the requirements and
procedures for registering RTP payload formats in the IANA media type procedures for registering RTP payload formats in the IANA media type
registry. No registrations are defined here, so no IANA actions are registry. No registrations are defined here, so no IANA actions are
required for this document. required for this document.
7. References 7. References
skipping to change at page 10, line 5 skipping to change at page 11, line 19
[5] Handley, M., V. Jacobson and C. Perkins, "SDP: Session Description [5] Handley, M., V. Jacobson and C. Perkins, "SDP: Session Description
Protocol", draft-ietf-mmusic-sdp-new-26.txt, January 2006. Protocol", draft-ietf-mmusic-sdp-new-26.txt, January 2006.
(Approved for publication as Proposed Standard to obsolete (Approved for publication as Proposed Standard to obsolete
RFC 2327, so this reference should be to the RFC when published RFC 2327, so this reference should be to the RFC when published
and that number inserted where RFC YYYY appears in this document) and that number inserted where RFC YYYY appears in this document)
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies", RFC 2045, (MIME) Part One: Format of Internet Message Bodies", RFC 2045,
November 1996. November 1996.
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions
(MIME) Part Two: Media Types", RFC 2046, November 1996.
7.2. Informative References 7.2. Informative References
[7] Casner, S., "Media Type Registration of Payload Formats in the [8] Casner, S., "Media Type Registration of Payload Formats in the
RTP Profile for Audio and Video Conferences", RTP Profile for Audio and Video Conferences",
draft-ietf-avt-rfc3555bis-part2-00.txt, February, 2006. draft-ietf-avt-rfc3555bis-part2-00.txt, February, 2006.
(Companion to this document, referenced herein as RFC XXXX). (Companion to this document, referenced herein as RFC XXXX).
8. Author's Address 8. Author's Address
Stephen L. Casner Stephen L. Casner
Packet Design Packet Design
3400 Hillview Avenue, Building 3 3400 Hillview Avenue, Building 3
Palo Alto, CA 94304 Palo Alto, CA 94304
 End of changes. 9 change blocks. 
20 lines changed or deleted 89 lines changed or added

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