doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc3009.txt b/doc/rfc/rfc3009.txt
new file mode 100644
index 0000000..bf7c982
--- /dev/null
+++ b/doc/rfc/rfc3009.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                       J. Rosenberg
+Request for Comments: 3009                                   dynamicsoft
+Category: Standards Track                                 H. Schulzrinne
+                                                             Columbia U.
+                                                           November 2000
+
+
+                  Registration of parityfec MIME types
+
+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 Internet Society (2000).  All Rights Reserved.
+
+Abstract
+
+   The RTP (Real-time Transport Protocol) payload format for generic
+   forward error correction allows RTP participants to improve loss
+   resiliency through the use of traditional parity-based channel codes.
+   This payload format requires four new MIME types, audio/parityfec,
+   video/parityfec, text/parityfec and application/parityfec.  This
+   document serves as the MIME type registration for those formats.
+
+1 Introduction
+
+   The RTP payload format for generic forward error correction [1]
+   allows RTP participants to improve loss resiliency through the use of
+   traditional parity-based channel codes.  This payload format requires
+   four new MIME types, audio/parityfec, video/parityfec,
+   text/paritfyfec and application/parityfec.  RFC 2048 [2] defines
+   procedures for registration of new MIME types within the IETF tree.
+   Furthermore, the Audio/Video Transport working group has defined
+   additional procedures that must be followed when registering RTP
+   payload formats [3].  This document serves as the MIME type
+   registration for those formats based on those procedures.
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 1]
+
+RFC 3009                        FEC MIME                   November 2000
+
+
+2 Registration of audio/parityfec
+
+       To: ietf-types@iana.org
+
+       Subject: Registration of MIME media type audio/parityfec
+
+       MIME media type name: audio
+
+       MIME subtype name: parityfec
+
+       Required parameters: none
+
+            Note that [3] mandates that RTP payload formats without a
+            defined rate must define a rate parameter as part of their
+            MIME registration.  The payload format for generic forward
+            error correction [1] does not specify a rate parameter.
+            However, the rate for FEC data is equal to the rate of the
+            media data it protects.
+
+       Optional parameters: none
+
+            Typical optional parameters [3], such as the number of
+            channels, and the duration of audio per packet, do not
+            apply to FEC data.  The number of channels is effectively
+            the same as the media data it protects; the same is true
+            for the duration of audio per packet.
+
+       Encoding considerations: This format is only defined for
+            transport within the Real Time Transport protocol (RTP)
+            [4,5].  Its transport within RTP is fully specified with RFC
+            2733 [1].
+
+       Security considerations: the same security considerations
+            apply to these mime registrations as to the payloads for
+            for them, as detailed in RFC 2733.
+
+       Interoperability considerations: none
+
+       Published specification: This MIME type is described fully
+            within RFC 2733 [1].
+
+       Applications which use this media type: Audio and video
+            streaming tools which seek to improve resiliency to loss by
+            sending additional data with the media stream.
+
+       Additional information: none
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 2]
+
+RFC 3009                        FEC MIME                   November 2000
+
+
+       Person & email address to contact for further information:
+
+            Jonathan Rosenberg
+            dynamicsoft
+            72 Eagle Rock Avenue
+            First Floor
+            East Hanover, NJ 07936
+            email: jdrosen@dynamicsoft.com
+                   jdrosen@alum.mit.edu
+
+       Intended usage: COMMON
+
+       Author/Change controller: This registration is part of the IETF
+            registration tree.
+
+       RTP and SDP Issues: Usage of this format within RTP and the
+            Session Description Protocol (SDP) [6] are fully specified
+            within RFC 2733 [1].
+
+3 Registration of video/parityfec
+
+       To: ietf-types@iana.org
+
+       Subject: Registration of MIME media type video/parityfec
+
+       MIME media type name: video
+
+       MIME subtype name: parityfec
+
+       Required parameters: none
+
+            Note that [3] mandates that RTP payload formats without a
+            defined rate must define a rate parameter as part of their
+            MIME registration.  The payload format for generic forward
+            error correction [1] does not specify a rate parameter.
+            However, the rate for FEC data is equal to the rate of the
+            media data it protects.
+
+       Optional parameters: none
+
+            Typical optional parameters [3], such as the number of
+            channels, and the duration of audio per packet, do not
+            apply to FEC data.  The number of channels is effectively
+            the same as the media data it protects; the same is true
+            for the duration of video per packet.
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 3]
+
+RFC 3009                        FEC MIME                   November 2000
+
+
+       Encoding considerations: This format is only defined for
+            transport within the Real Time Transport protocol (RTP)
+            [4,5].  Its transport within RTP is fully specified with RFC
+            2733 [1].
+
+       Security considerations: the same security considerations
+            apply to these MIME registrations as to the payloads for
+            for them, as detailed in RFC 2733.
+
+       Interoperability considerations: none
+
+       Published specification: This MIME type is described fully
+            within RFC 2733 [1].
+
+       Applications which use this media type: Audio and video
+            streaming tools which seek to improve resiliency to loss by
+            sending additional data with the media stream.
+
+       Additional information: none
+
+       Person & email address to contact for further information:
+
+            Jonathan Rosenberg
+            dynamicsoft
+            72 Eagle Rock Avenue
+            First Floor
+            East Hanover, NJ 07936
+            email: jdrosen@dynamicsoft.com
+                   jdrosen@alum.mit.edu
+
+       Intended usage: COMMON
+
+       Author/Change controller: This registration is part of the IETF
+            registration tree.
+
+       RTP and SDP Issues: Usage of this format within RTP and the
+            Session Description Protocol (SDP) [6] are fully specified
+            within RFC 2733 [1].
+
+4 Registration of text/parityfec
+
+       To: ietf-types@iana.org
+
+       Subject: Registration of MIME media type text/parityfec
+
+       MIME media type name: text
+
+       MIME subtype name: parityfec
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 4]
+
+RFC 3009                        FEC MIME                   November 2000
+
+
+       Required parameters: none
+
+            Note that [3] mandates that RTP payload formats without a
+            defined rate must define a rate parameter as part of their
+            MIME registration.  The payload format for generic forward
+            error correction [1] does not specify a rate parameter.
+            However, the rate for FEC data is equal to the rate of the
+            media data it protects.
+
+       Optional parameters: none
+
+            Typical optional parameters [3], such as the number of
+            channels, and the duration of audio per packet, do not
+            apply to FEC data.  The number of channels is effectively
+            the same as the media data it protects; the same is true
+            for the duration of text per packet.
+
+       Encoding considerations: This format is only defined for
+            transport within the Real Time Transport protocol (RTP)
+            [4,5].  Its transport within RTP is fully specified with RFC
+            2733 [1].
+
+       Security considerations: the same security considerations
+            apply to these MIME registrations as to the payloads for
+            for them, as detailed in RFC 2733.
+
+       Interoperability considerations: none
+
+       Published specification: This MIME type is described fully
+            within RFC 2733 [1].
+
+       Applications which use this media type: Audio, video and text
+            streaming tools which seek to improve resiliency to loss by
+            sending additional data with the media stream.
+
+       Additional information: none
+
+       Person & email address to contact for further information:
+
+            Jonathan Rosenberg
+            dynamicsoft
+            72 Eagle Rock Avenue
+            First Floor
+            East Hanover, NJ 07936
+            email: jdrosen@dynamicsoft.com
+                   jdrosen@alum.mit.edu
+
+       Intended usage: COMMON
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 5]
+
+RFC 3009                        FEC MIME                   November 2000
+
+
+       Author/Change controller: This registration is part of the IETF
+            registration tree.
+
+       RTP and SDP Issues: Usage of this format within RTP and the
+            Session Description Protocol (SDP) [6] are fully specified
+            within RFC 2733 [1].
+
+5 Registration of application/parityfec
+
+        To: ietf-types@iana.org
+
+        Subject: Registration of MIME media type application/parityfec
+
+        MIME media type name: application
+
+        MIME subtype name: parityfec
+
+        Required parameters: none
+
+             Note that [3] mandates that RTP payload formats without a
+             defined rate must define a rate parameter as part of their
+             MIME registration.  The payload format for generic forward
+             error correction [1] does not specify a rate parameter.
+             However, the rate for FEC data is equal to the rate of the
+             media data it protects.
+
+        Optional parameters: none
+
+             Typical optional parameters [3], such as the number of
+             channels, and the duration of audio per packet, do not
+             apply to FEC data.  The number of channels is effectively
+             the same as the media data it protects; the same is true
+             for the duration of application data per packet.
+
+        Encoding considerations: This format is only defined for
+             transport within the Real Time Transport protocol (RTP)
+             [4,5].  Its transport within RTP is fully specified with RFC
+             2733 [1].
+
+       Security considerations: the same security considerations
+            apply to these MIME registrations as to the payloads for
+            for them, as detailed in RFC 2733.
+
+        Interoperability considerations: none
+
+        Published specification: This MIME type is described fully
+             within RFC 2733 [1].
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 6]
+
+RFC 3009                        FEC MIME                   November 2000
+
+
+        Applications which use this media type: Audio, video and
+             application streaming tools which seek to improve
+             resiliency to loss by sending additional data with the
+             media stream.
+
+        Additional information: none
+
+        Person & email address to contact for further information:
+
+             Jonathan Rosenberg
+             dynamicsoft
+             72 Eagle Rock Avenue
+             First Floor
+             East Hanover, NJ 07936
+             email: jdrosen@dynamicsoft.com
+                    jdrosen@alum.mit.edu
+
+        Intended usage: COMMON
+
+        Author/Change controller: This registration is part of the IETF
+             registration tree.
+
+        RTP and SDP Issues: Usage of this format within RTP and the
+             Session Description Protocol (SDP) [6] are fully specified
+             within RFC 2733 [1].
+
+6 Security Considerations
+
+   This MIME registration does not introduce any additional security
+   considerations.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 7]
+
+RFC 3009                        FEC MIME                   November 2000
+
+
+7 Authors' Addresses
+
+   Jonathan Rosenberg
+   dynamicsoft
+   72 Eagle Rock Avenue
+   First Floor
+   East Hanover, NJ 07936
+
+   EMail: jdrosen@dynamicsoft.com
+
+
+   Henning Schulzrinne
+   Columbia University
+   M/S 0401
+   1214 Amsterdam Ave.
+   New York, NY 10027-7003
+
+   EMail: schulzrinne@cs.columbia.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 8]
+
+RFC 3009                        FEC MIME                   November 2000
+
+
+8 Bibliography
+
+   [1] Rosenberg, J. and H. Schulzrinne, "An RTP Payload Format for
+       Generic Forward Error Correction", RFC 2733, December 1999.
+
+   [2] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail
+       Extensions (MIME) Part Four: Registration Procedures", RFC 2048,
+       November 1996.
+
+   [3] Casner, S. and P. Hoschka, "MIME type registration of RTP payload
+       formats", Work in Progress.
+
+   [4] Schulzrinne, H., Casner, S., Frederick, R.  and V. Jacobson,
+       "RTP: a transport protocol for real-time applications", RFC 1889,
+       January 1996.
+
+   [5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
+       a transport protocol for real-time applications", Work in
+       Progress.
+
+   [6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
+       RFC 2327, April 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                     [Page 9]
+
+RFC 3009                        FEC MIME                   November 2000
+
+
+9  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2000).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rosenberg & Schulzrinne     Standards Track                    [Page 10]
+