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 © 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.

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

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.

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

       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

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].

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.

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

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.

9 Full Copyright Statement

Copyright © 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.