idnits 2.17.1 draft-ietf-avt-fecmime-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 10, 2000) is 8812 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 332 looks like a reference -- Missing reference section? '2' on line 336 looks like a reference -- Missing reference section? '3' on line 341 looks like a reference -- Missing reference section? '4' on line 345 looks like a reference -- Missing reference section? '5' on line 349 looks like a reference -- Missing reference section? '6' on line 353 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force AVT WG 3 Internet Draft J.Rosenberg,H.Schulzrinne 4 draft-ietf-avt-fecmime-01.txt dynamicsoft,Columbia U. 5 March 10, 2000 6 Expires: September, 2000 8 Registration of parityfec MIME types 10 STATUS OF THIS MEMO 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference 23 material or to cite them other than as work in progress. 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 The RTP payload format for generic forward error correction allows 34 RTP participants to improve loss resiliency through the use of 35 traditional parity based channel codes. This payload format requires 36 four new MIME types, audio/parityfec, video/parityfec, text/parityfec 37 and application/parityfec. This document serves as the MIME type 38 registration for those formats. 40 1 Introduction 42 The RTP payload format for generic forward error correction [1] 43 allows RTP participants to improve loss resiliency through the use of 44 traditional parity based channel codes. This payload format requires 45 four new MIME types, audio/parityfec, video/parityfec, 46 text/paritfyfec and application/parityfec. RFC 2048 [2] defines 47 procedures for registration of new MIME types within the IETF tree. 48 Furthermore, the Audio/Video Transport working group has defined 49 additional procedures that must be followed when registering RTP 50 payload formats [3]. This document serves as the MIME type 51 registration for those formats based on those procedures. 53 2 Registration of audio/parityfec 55 To: ietf-types@iana.org 57 Subject: Registration of MIME media type audio/parityfec 59 MIME media type name: audio 61 MIME subtype name: parityfec 63 Required parameters: none 65 Note that [3] mandates that RTP payload formats without a 66 defined rate must define a rate parameter as part of their 67 MIME registration. The payload format for generic forward 68 error correction [1] does not specify a rate parameter. 69 However, the rate for FEC data is equal to the rate of the 70 media data it protects. 72 Optional parameters: none 74 Typical optional parameters [3], such as the number of 75 channels, and the duration of audio per packet, do not 76 apply to FEC data. The number of channels is effectively 77 the same as the media data it protects; the same is true 78 for the duration of audio per packet. 80 Encoding considerations: This format is only defined for 81 transport within the Real Time Transport protocol (RTP) 82 [4,5]. Its transport within RTP is fully specified with RFC 83 2733 [1]. 85 Security considerations: none 87 Interoperability considerations: none 89 Published specification: This MIME typed is described fully 90 within RFC 2733 [1]. 92 Applications which use this media type: Audio and video 93 streaming tools which seek to improve resiliency to loss by 94 sending additional data with the media stream. 96 Additional information: none 98 Person & email address to contact for further information: 100 Jonathan Rosenberg 101 dynamicsoft 102 200 Executive Drive 103 Suite 120 104 West Orange, NJ 07046 105 email: jdrosen@dynamicsoft.com 106 jdrosen@alum.mit.edu 108 Intended usage: COMMON 110 Author/Change controller: This registration is part of the IETF 111 registration tree. 113 RTP and SDP Issues: Usage of this format within RTP and the 114 Session Description Protocol (SDP) [6] are fully specified 115 within RFC 2733 [1]. 117 3 Registration of video/parityfec 119 To: ietf-types@iana.org 121 Subject: Registration of MIME media type video/parityfec 123 MIME media type name: video 125 MIME subtype name: parityfec 127 Required parameters: none 128 Note that [3] mandates that RTP payload formats without a 129 defined rate must define a rate parameter as part of their 130 MIME registration. The payload format for generic forward 131 error correction [1] does not specify a rate parameter. 132 However, the rate for FEC data is equal to the rate of the 133 media data it protects. 135 Optional parameters: none 137 Typical optional parameters [3], such as the number of 138 channels, and the duration of audio per packet, do not 139 apply to FEC data. The number of channels is effectively 140 the same as the media data it protects; the same is true 141 for the duration of video per packet. 143 Encoding considerations: This format is only defined for 144 transport within the Real Time Transport protocol (RTP) 145 [4,5]. Its transport within RTP is fully specified with RFC 146 2733 [1]. 148 Security considerations: none 150 Interoperability considerations: none 152 Published specification: This MIME typed is described fully 153 within RFC 2733 [1]. 155 Applications which use this media type: Audio and video 156 streaming tools which seek to improve resiliency to loss by 157 sending additional data with the media stream. 159 Additional information: none 161 Person & email address to contact for further information: 163 Jonathan Rosenberg 164 dynamicsoft 165 200 Executive Drive 166 Suite 120 167 West Orange, NJ 07046 168 email: jdrosen@dynamicsoft.com 169 jdrosen@alum.mit.edu 171 Intended usage: COMMON 173 Author/Change controller: This registration is part of the IETF 174 registration tree. 176 RTP and SDP Issues: Usage of this format within RTP and the 177 Session Description Protocol (SDP) [6] are fully specified 178 within RFC 2733 [1]. 180 4 Registration of text/parityfec 182 To: ietf-types@iana.org 184 Subject: Registration of MIME media type text/parityfec 186 MIME media type name: text 188 MIME subtype name: parityfec 190 Required parameters: none 192 Note that [3] mandates that RTP payload formats without a 193 defined rate must define a rate parameter as part of their 194 MIME registration. The payload format for generic forward 195 error correction [1] does not specify a rate parameter. 196 However, the rate for FEC data is equal to the rate of the 197 media data it protects. 199 Optional parameters: none 201 Typical optional parameters [3], such as the number of 202 channels, and the duration of audio per packet, do not 203 apply to FEC data. The number of channels is effectively 204 the same as the media data it protects; the same is true 205 for the duration of text per packet. 207 Encoding considerations: This format is only defined for 208 transport within the Real Time Transport protocol (RTP) 209 [4,5]. Its transport within RTP is fully specified with RFC 210 2733 [1]. 212 Security considerations: none 214 Interoperability considerations: none 216 Published specification: This MIME typed is described fully 217 within RFC 2733 [1]. 219 Applications which use this media type: Audio, video and text 220 streaming tools which seek to improve resiliency to loss by 221 sending additional data with the media stream. 223 Additional information: none 225 Person & email address to contact for further information: 227 Jonathan Rosenberg 228 dynamicsoft 229 200 Executive Drive 230 Suite 120 231 West Orange, NJ 07046 232 email: jdrosen@dynamicsoft.com 233 jdrosen@alum.mit.edu 235 Intended usage: COMMON 237 Author/Change controller: This registration is part of the IETF 238 registration tree. 240 RTP and SDP Issues: Usage of this format within RTP and the 241 Session Description Protocol (SDP) [6] are fully specified 242 within RFC 2733 [1]. 244 5 Registration of application/parityfec 246 To: ietf-types@iana.org 248 Subject: Registration of MIME media type application/parityfec 250 MIME media type name: application 252 MIME subtype name: parityfec 254 Required parameters: none 256 Note that [3] mandates that RTP payload formats without a 257 defined rate must define a rate parameter as part of their 258 MIME registration. The payload format for generic forward 259 error correction [1] does not specify a rate parameter. 260 However, the rate for FEC data is equal to the rate of the 261 media data it protects. 263 Optional parameters: none 265 Typical optional parameters [3], such as the number of 266 channels, and the duration of audio per packet, do not 267 apply to FEC data. The number of channels is effectively 268 the same as the media data it protects; the same is true 269 for the duration of application data per packet. 271 Encoding considerations: This format is only defined for 272 transport within the Real Time Transport protocol (RTP) 273 [4,5]. Its transport within RTP is fully specified with RFC 274 2733 [1]. 276 Security considerations: none 278 Interoperability considerations: none 280 Published specification: This MIME typed is described fully 281 within RFC 2733 [1]. 283 Applications which use this media type: Audio, video and 284 application streaming tools which seek to improve 285 resiliency to loss by sending additional data with the 286 media stream. 288 Additional information: none 290 Person & email address to contact for further information: 292 Jonathan Rosenberg 293 dynamicsoft 294 200 Executive Drive 295 Suite 120 296 West Orange, NJ 07046 297 email: jdrosen@dynamicsoft.com 298 jdrosen@alum.mit.edu 300 Intended usage: COMMON 302 Author/Change controller: This registration is part of the IETF 303 registration tree. 305 RTP and SDP Issues: Usage of this format within RTP and the 306 Session Description Protocol (SDP) [6] are fully specified 307 within RFC 2733 [1]. 309 6 Security Considerations 311 This MIME registration does not introduce any addititional security 312 considerations. 314 7 Author's Addresses 316 Jonathan Rosenberg 317 dynamicsoft 318 200 Executive Drive 319 Suite 120 320 West Orange, NJ 07052 321 email: jdrosen@dynamicsoft.com 323 Henning Schulzrinne 324 Columbia University 325 M/S 0401 326 1214 Amsterdam Ave. 327 New York, NY 10027-7003 328 email: schulzrinne@cs.columbia.edu 330 8 Bibliography 332 [1] J. Rosenberg and H. Schulzrinne, "An RTP payload format for 333 generic forward error correction," Request for Comments (Proposed 334 Standard) 2733, Internet Engineering Task Force, Dec. 1999. 336 [2] N. Freed, J. Klensin, and J. Postel, "Multipurpose internet mail 337 extensions (MIME) part four: Registration procedures," Request for 338 Comments (Best Current Practice) 2048, Internet Engineering Task 339 Force, Nov. 1996. 341 [3] S. Casner and P. Hoschka, "MIME type registration of RTP payload 342 formats," Internet Draft, Internet Engineering Task Force, July 1999. 343 Work in progress. 345 [4] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a 346 transport protocol for real-time applications," Request for Comments 347 (Proposed Standard) 1889, Internet Engineering Task Force, Jan. 1996. 349 [5] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a 350 transport protocol for real-time applications," Internet Draft, 351 Internet Engineering Task Force, July 1999. Work in progress. 353 [6] M. Handley and V. Jacobson, "SDP: session description protocol," 354 Request for Comments (Proposed Standard) 2327, Internet Engineering 355 Task Force, Apr. 1998.