doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc4855.txt b/doc/rfc/rfc4855.txt
new file mode 100644
index 0000000..67a3be7
--- /dev/null
+++ b/doc/rfc/rfc4855.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Network Working Group                                          S. Casner
+Request for Comments: 4855                                 Packet Design
+Obsoletes: 3555                                            February 2007
+Category: Standards Track
+
+
+             Media Type Registration of RTP Payload Formats
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The IETF Trust (2007).
+
+Abstract
+
+   This document specifies the procedure to register RTP payload formats
+   as audio, video, or other media subtype names.  This is useful in a
+   text-based format description or control protocol to identify the
+   type of an RTP transmission.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Terminology ................................................2
+   2. Procedure For Registering Media Types for RTP Payload Types .....2
+      2.1. Example Media Type Registration ............................4
+      2.2. Restrictions on Sharing a Subtype Name .....................5
+   3. Mapping to SDP Parameters .......................................6
+   4. Changes from RFC 3555 ...........................................7
+   5. Security Considerations .........................................8
+   6. IANA Considerations .............................................9
+   7. References .....................................................10
+      7.1. Normative References ......................................10
+      7.2. Informative References ....................................10
+
+
+
+
+
+
+
+
+
+
+Casner                      Standards Track                     [Page 1]
+
+RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007
+
+
+1.  Introduction
+
+   RFC 4288 [1] defines media type specification and registration
+   procedures that use the Internet Assigned Numbers Authority (IANA) as
+   a central registry.  That document covers general requirements
+   independent of particular application environments and transport
+   modes.  This document defines the specific requirements for
+   registration of media types for use with the Real-time Transport
+   Protocol (RTP), RFC 3550 [2], to identify RTP payload formats.
+
+1.1.  Terminology
+
+   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 RFC 2119 [3] and
+   indicate requirement levels for implementations compliant with this
+   specification.
+
+2.  Procedure For Registering Media Types for RTP Payload Types
+
+   Registering an RTP payload type as a media type follows the same
+   procedures as described in RFC 4288 [1] and uses the registration
+   template shown in Section 10 of that RFC.  To specify how the
+   particular payload format is transported over RTP, some additional
+   information is required in the following sections of that template:
+
+     Required parameters:
+          If the payload format does not have a fixed RTP timestamp
+          clock rate, then a "rate" parameter is required to specify the
+          RTP timestamp clock rate.  A particular payload format may
+          have additional required parameters.
+
+     Optional parameters:
+          Most audio payload formats can have an optional "channels"
+          parameter to specify the number of audio channels included in
+          the transmission.  The default channel order is as specified
+          in RFC 3551 [4].  Any payload format, but most likely audio
+          formats, may also include the optional parameters "ptime" to
+          specify the recommended length of time in milliseconds
+          represented by the media in a packet, and/or "maxptime" to
+          specify the maximum amount of media that can be encapsulated
+          in each packet, expressed as time in milliseconds.  The
+          "ptime" and "maxptime" parameters are defined in the Session
+          Description Protocol (SDP) [5].
+
+          A particular payload format may have additional optional
+          parameters.  As allowed in Section 4.3 of [1], new parameters
+          MAY be added to RTP media types that have been previously
+
+
+
+Casner                      Standards Track                     [Page 2]
+
+RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007
+
+
+          defined, but the new parameters MUST NOT change existing
+          functionality and it MUST be possible for existing
+          implementations to ignore the additional parameters without
+          impairing operation.
+
+     Encoding considerations:
+          Most RTP payload formats include binary or framed data as
+          described in Section 4.8 of [1].  The appropriate encoding
+          considerations MUST be noted.
+
+     Published specification:
+          A description of the media encoding and a specification of the
+          payload format must be provided, usually by reference to an
+          RTP payload format specification RFC.  That RFC may be
+          separate, or the media type registration may be incorporated
+          into the payload format specification RFC.  The payload format
+          specification MUST include the RTP timestamp clock rate (or
+          multiple rates for audio encodings with multiple sampling
+          rates).
+
+          A reference to a further description of the data compression
+          format itself should be provided, if available.
+
+     Restrictions on usage:
+          The fact that the media type is defined for transfer via RTP
+          MUST be noted, in particular, if the transfer depends on RTP
+          framing and hence the media type is only defined for transfer
+          via RTP.
+
+   Depending on whether or not the type has already been registered for
+   transfer with a non-RTP protocol (e.g., MIME mail or http), several
+   different cases can occur:
+
+      a) Not yet registered as a media type
+
+         A new registration should be constructed using the media type
+         registration template.  The registration may specify transfer
+         via other means in addition to RTP if that is feasible and
+         desired.  The appropriate encoding considerations must be
+         specified, and the restrictions on usage must specify whether
+         the type is only defined for transfer via RTP or via other
+         modes as well.
+
+         Optional parameters may be defined as needed, and it must be
+         clearly stated to which mode(s) of transfer the parameters
+         apply.
+
+
+
+
+
+Casner                      Standards Track                     [Page 3]
+
+RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007
+
+
+      b) Media type exists for a non-RTP protocol
+
+         The restrictions on usage of the existing type should be
+         changed, if present, or added, if not, to indicate that the
+         type can also be transferred via RTP.
+
+         RTP-specific parameters may be added, and it must be clearly
+         stated that these are only to be used when the media type is
+         transmitted via RTP transport.
+
+      c) Update an existing media type for RTP to be used for a non-RTP
+         protocol
+
+         The restrictions on usage of the existing type should be
+         changed to indicate that the type can also be transferred via a
+         non-RTP protocol (e.g., SMTP, HTTP).
+
+         Non-RTP-specific parameters can be added, and it must be
+         clearly stated that these are only to be used when the media
+         type is transmitted via a non-RTP transport.
+
+2.1.  Example Media Type Registration
+
+   The following sample registration of a fake media type audio/example
+   provides examples for some of the required text.  References to RFC
+   nnnn would be replaced by references to the RFC that contains the
+   payload format specification and the media type registration.
+
+     Type name: audio
+
+     Subtype name: example
+
+     Required parameters:
+          rate: RTP timestamp clock rate, which is equal to the sampling
+          rate.  The typical rate is 8000; other rates may be specified.
+
+     Optional parameters:
+          channels: number of interleaved audio streams, either 1 for
+          mono or 2 for stereo, and defaults to 1 if omitted.
+          Interleaving takes place between on a frame-by-frame basis,
+          with the left channel followed by the right channel.
+
+          ptime: recommended length of time in milliseconds represented
+          by the media in a packet (see RFC 4566).
+
+          maxptime: maximum amount of media that can be encapsulated in
+          each packet, expressed as time in milliseconds (see RFC 4566).
+
+
+
+
+Casner                      Standards Track                     [Page 4]
+
+RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007
+
+
+     Encoding considerations:
+          This media type is framed binary data (see RFC 4288, Section
+          4.8).
+
+     Security considerations: See Section n of RFC nnnn
+
+     Interoperability considerations:
+          Some receivers may only be capable of receiving single-channel
+          audio.
+
+     Published specification: RFC nnnn
+
+     Applications that use this media type:
+          Audio and video streaming and conferencing tools.
+
+     Additional information: none
+
+     Person & email address to contact for further information:
+          Fred Audio <fred@example.com>
+
+     Intended usage: COMMON
+
+     Restrictions on usage:
+          This media type depends on RTP framing, and hence is only
+          defined for transfer via RTP (RFC 3550).  Transfer within
+          other framing protocols is not defined at this time.
+
+     Author:
+          Fred Audio
+
+     Change controller:
+          IETF Audio/Video Transport working group delegated from the
+          IESG.
+
+2.2.  Restrictions on Sharing a Subtype Name
+
+   The same media subtype name MUST NOT be shared for RTP and non-RTP
+   (file-based) transfer methods unless the data format is the same for
+   both methods.  The data format is considered to be the same if the
+   file format is equivalent to a concatenated sequence of payloads from
+   RTP packets not including the RTP header or any RTP payload-format
+   header.
+
+   The file format MAY include a magic number or other header at the
+   start of the file that is not included when the data is transferred
+   via RTP.
+
+
+
+
+
+Casner                      Standards Track                     [Page 5]
+
+RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007
+
+
+   A second requirement for sharing a media subtype name is that the
+   sets of required parameters must be the same for both methods.
+
+   For cases where the data format or required parameters cannot be the
+   same for RTP and non-RTP transfer methods, the data formats MUST be
+   registered as separate types.  It is RECOMMENDED that the subtype
+   names be related, such as by using a common root plus a suffix.  For
+   those cases where a suffix is applied in the subtype name for the RTP
+   transfer method, the suffix "+rtp" is suggested.
+
+3.  Mapping to SDP Parameters
+
+   The representation of a media type is specified in the syntax of the
+   Content-Type header field in RFC 2045 [6] as follows:
+
+        type "/" subtype  *(";" parameter)
+
+   Parameters may be required for a particular type or subtype or they
+   may be optional.  For media types that represent RTP payload formats,
+   the parameters "rate", "channels", "ptime", and "maxptime" have
+   general definitions (given above) that may apply across types and
+   subtypes.  The format for a parameter is specified in RFC 2045 as
+
+        attribute "=" value
+
+   where attribute is the parameter name and the permissible values are
+   specified for each parameter.  RFC 2045 specifies that a value MUST
+   be present and that the value MUST be a quoted string if it contains
+   any of the special characters listed in that RFC.
+
+   The information carried in the media type string has a specific
+   mapping to fields in the Session Description Protocol (SDP) [5],
+   which is commonly used to describe RTP sessions.  The mapping is as
+   follows:
+
+      o  The media type (e.g., audio) goes in SDP "m=" as the media
+         name.
+
+      o  The media subtype (payload format) goes in SDP "a=rtpmap" as
+         the encoding name.
+
+      o  The general (possibly optional) parameters "rate" and
+         "channels" also go in "a=rtpmap" as clock rate and encoding
+         parameters, respectively.
+
+      o  The general (and optional) parameters "ptime" and "maxptime" go
+         in the SDP "a=ptime" and "a=maxptime" attributes, respectively.
+
+
+
+
+Casner                      Standards Track                     [Page 6]
+
+RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007
+
+
+      o  Any payload-format-specific parameters go in the SDP "a=fmtp"
+         attribute.  The set of allowed parameters is defined by the RFC
+         that specifies the payload format and MUST NOT be extended by
+         the media type registration without a corresponding revision of
+         the payload format specification.  The format and syntax of
+         these parameters may also be defined by the payload format
+         specification, but it is suggested that the parameters be
+         copied directly from the media type string as a semicolon
+         separated list of parameter=value pairs.  For payload formats
+         that specify some other syntax for the fmtp parameters, the
+         registration of that payload format as a media type must
+         specify what the parameters are in MIME format and how to map
+         them to the "a=fmtp" attribute.
+
+   An example mapping is as follows:
+
+         audio/L16; rate=48000; channels=2; ptime=5; emphasis=50-15
+
+         m=audio 49170 RTP/AVP 97
+         a=rtpmap:97 L16/48000/2
+         a=fmtp:97 emphasis=50-15
+         a=ptime:5
+
+   Note that the payload format (encoding) names defined in the RTP
+   Profile [4] are commonly shown in upper case.  Media subtype names
+   are commonly shown in lower case.  These names are case-insensitive
+   in both places.  Similarly, parameter names are case-insensitive both
+   in media type strings and in the default mapping to the SDP a=fmtp
+   attribute.
+
+4.  Changes from RFC 3555
+
+   This document updates RFC 3555 to conform to the revised media type
+   registration procedures in RFC 4288 [1].  Whereas RFC 3555 required
+   the encoding considerations to specify transfer via RTP, that is now
+   specified under restrictions on usage.  This document also specifies
+   the 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 the requirements for sharing a media type among RTP and non-
+   RTP transfer methods.
+
+   RFC 3555 included media type registrations for the RTP payload
+   formats defined in the RTP Profile for Audio and Video Conferences,
+   RFC 3551 [4].  Those media type registrations have been removed from
+   this document.  Some of them have been assembled into a separate
+   companion RFC 4856 [8], leaving out those that have been, or are
+   intended to be, registered in revisions of their own payload format
+   specification RFCs.
+
+
+
+Casner                      Standards Track                     [Page 7]
+
+RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007
+
+
+   Philipp Hoschka is a co-author of RFC 3555; his contributions to the
+   foundation of this document are appreciated.
+
+5.  Security Considerations
+
+   The media type registration procedure specified in this memo does not
+   impose any security considerations on its own.  Also, registrations
+   conforming to this procedure do not themselves impose security risks.
+   However, use of the media type being registered could very well
+   impose security risks:
+
+      o  Any media type that contains "active content" imposes the risk
+         of malicious side-effects unless execution of that content is
+         adequately constrained.
+
+      o  Several audio and video encodings are perfect for hiding data
+         using steganography.
+
+      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 associated 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.
+
+
+
+
+Casner                      Standards Track                     [Page 8]
+
+RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007
+
+
+   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 is designed for use only within a secure
+         environment.
+
+6.  IANA Considerations
+
+   The purpose of this document is to specify the requirements and
+   procedures for registering RTP payload formats in the IANA media type
+   registry.  No registrations are defined here.
+
+
+
+
+
+
+Casner                      Standards Track                     [Page 9]
+
+RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007
+
+
+7.  References
+
+7.1.  Normative References
+
+   [1] Freed, N. and J. Klensin, "Media Type Specifications and
+       Registration Procedures", BCP 13, RFC 4288, December, 2005.
+
+   [2] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
+       A Transport Protocol for Real-Time Applications", RFC 3550, July
+       2003.
+
+   [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+   [4] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
+       Conferences with Minimal Control", RFC 3551, July 2003.
+
+   [5] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
+       Description Protocol", RFC 4566, July 2006.
+
+   [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+       Extensions (MIME) Part One: Format of Internet Message Bodies",
+       RFC 2045, 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
+
+   [8] Casner, S., "Media Type Registration of Payload Formats in the
+       RTP Profile for Audio and Video Conferences", RFC 4856, February
+       2007.
+
+Author's Address
+
+   Stephen L. Casner
+   Packet Design
+   3400 Hillview Avenue, Building 3
+   Palo Alto, CA 94304
+   United States
+
+   Phone: +1 650 739-1843
+   EMail: casner@acm.org
+
+
+
+
+
+
+
+Casner                      Standards Track                    [Page 10]
+
+RFC 4855         Media Type Reg. of RTP Payload Formats    February 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 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, THE IETF TRUST 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 in BCP 78 and BCP 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 at
+   http://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 currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Casner                      Standards Track                    [Page 11]
+