From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3009.txt | 563 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 563 insertions(+) create mode 100644 doc/rfc/rfc3009.txt (limited to 'doc/rfc/rfc3009.txt') 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] + -- cgit v1.2.3