idnits 2.17.1 draft-ietf-avt-text-red-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.5 on line 246. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 271. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 6 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (May 2004) is 7257 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) == Unused Reference: '6' is defined on line 210, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2327 (ref. '5') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 3555 (ref. '6') (Obsoleted by RFC 4855, RFC 4856) -- Obsolete informational reference (is this intentional?): RFC 2793 (ref. '7') (Obsoleted by RFC 4103) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 3 Internet Draft P. Jones 4 Cisco Systems, Inc. 5 Expires: October 2004 May 2004 7 Registration of the text/red MIME Sub-Type 9 Status of this Memo 11 By submitting this Internet-Draft, I (we) certify that any applicable 12 patent or other IPR claims of which I am (we are) aware have been 13 disclosed and any of which I (we) become aware will be disclosed, in 14 accordance with RFC 3668 (BCP 79). 16 By submitting this Internet-Draft, I (we) accept the provisions of 17 Section 3 of RFC 3667 (BCP 78). 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This document is a submission of the IETF AVT WG. Comments should be 35 directed to the AVT WG mailing list, avt@ietf.org. 37 Abstract 39 This document defines the text/red MIME sub-type. The actual RTP 40 packetization for this MIME type is specified in RFC 2198. 42 [Note to RFC Editor: All references to RFC XXXX are to be replaced by 43 references to the RFC number of this memo when published.] 45 1. Introduction 47 =0C 48 Text is an important component of any multimedia communication 49 system. Like audio, the transport of text can benefit from the use 50 of redundancy in order to improve reliability and end-user 51 experience. 53 RFC 2198 [1] defines an RTP [2] payload format for redundant audio 54 data. The format defined in that document is quite suitable for 55 providing redundancy for text, as well as audio. 57 RFC 2793 [7] specifies one usage of RFC 2198 and the text/red MIME 58 type for the transport of redundant text data. 60 This memo provides the MIME sub-type registration information for 61 text/red. While this document focuses on the use of this MIME sub- 62 type in SDP [5], the application of this MIME sub-type is not 63 restricted to SDP. 65 2. Conventions used in this document 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [3]. 71 3. IANA Considerations 73 One new MIME sub-type is to be registered, as described below: 75 MIME media type name: text 77 MIME subtype name: RED 79 Required parameters: 80 rate: the RTP clock rate of the payload carried within the RTP 81 packet. Typically, this rate is 1000, but other rates MAY be 82 specified. This parameter MUST be set equal to the clock rate 83 of the text payload format carried as the primary encoding. 85 pt: a comma-separated ordered list of RTP payload types 86 enumerating the primary, secondary, etc., in accordance with 87 RFC 2198. Because comma is a special character, the list MUST 88 be a quoted-string (enclosed in double quotes). For static 89 payload types, each list element is simply the type number. 90 For dynamic payload types, each list element is a mapping of 91 the dynamic payload type number to an embedded MIME content- 92 type specification for the payload format corresponding to the 93 dynamic payload type. The format of the mapping is: 95 dynamic-payload-type "=3D" content-type 97 =0C 99 If the content-type string includes a comma, then the content- 100 type string MUST be a quoted-string. If the content-type 101 string does not include a comma, it MAY still be quoted. Since 102 it is part of the list which must itself be a quoted-string, 103 that means the quotation marks MUST be quoted with backslash 104 quoting as specified in RFC 2045 [4]. If the content-type 105 string itself contains a quoted-string, then the requirement 106 for backslash quoting is recursively applied. 108 Optional parameters: ptime, maxptime 110 Encoding considerations: 111 This type is only defined for transfer via RTP. 113 Security considerations: Refer to section 5 of RFC XXXX. 115 Interoperability considerations: none 117 Published specification: RFC 2198 119 Applications which use this media type: 120 Text streaming and conferencing tools. 122 Additional information: none 124 Person & email address to contact for further information: 125 Paul E. Jones 126 E-mail: paulej@packetizer.com 128 Intended usage: COMMON 130 Author / Change controller: 131 Paul E. Jones | IETF avt WG 132 paulej@packetizer.com | 134 4. Mapping to SDP Parameters 136 The information carried in the MIME media type specification has a 137 specific mapping to fields in the Session Description Protocol (SDP) 138 [5], which is commonly used to describe RTP sessions. When SDP is 139 used to specify sessions employing the RFC 2198 in a text session, 140 the mapping is as follows: 142 - The MIME type ("text") goes in SDP "m=3D" as the media name. 144 - The value of the parameter "rate" goes in SDP "a=3Drtpmap". 146 - The MIME subtype (RED) goes in SDP "a=3Drtpmap" 147 as the encoding name. 149 =0C 151 - The parameters "ptime" and "maxptime" go in the SDP "a=3Dptime" 152 and "a=3Dmaxptime" attributes, respectively. 154 - The pt parameter is mapped to an a=3Dfmtp attribute by eliminating 155 the parameter name (pt) and changing the commas to slashes. For 156 example, 'pt=3D"101,102"' maps to 'a=3Dfmtp:99 101/102', where = 157 '99' is 158 the payload type of the redundancy frames. Note that the single 159 quote marks (') used in this example is not present in the 160 actual message encoding, but is present here only for readability. 161 The level of redundancy is shown by the number of elements in the 162 payload type list. 164 Any dynamic payload type in the list MUST be represented by its 165 payload type number and not by its content-type. The mapping of 166 payload types to the content-type is done using the normal SDP 167 procedures with "a=3Drtpmap". 169 An example of SDP is: 171 m=3Dtext 11000 RTP/AVP 98 100 172 a=3Drtpmap:98 t140/1000 173 a=3Drtpmap:100 red/1000 174 a=3Dfmtp:100 98/98 176 For each redundancy payload type defined, the ordering of the primary 177 and redundancy encoding(s) is fixed. If more than one combination of 178 primary and redundancy encoding(s) is desired, multiple redundancy 179 payload types needs to be defined. 181 5. Security Considerations 183 The security considerations listed in RFC 2198 apply. Further, it 184 should be understood that text data, perhaps even more so than audio 185 data, is susceptible to unwanted modification that may lead to 186 undesired results. To prevent modification of the primary, secondary 187 or header information, payload integrity protection over at least the 188 complete RTP packet is RECOMMENDED, for example using SRTP [8]. 190 6. Normative References 192 [1] Perkins, C., et al., "RTP Payload for Redundant Audio Data", RFC 193 2198, September 1997. 195 [2] Schulzrinne, et al., "RTP: A Transport Protocol for Real-Time 196 Applications", RFC 3550, July 2003. 198 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 199 Levels", RFC 2119, March 1997. 201 =0C 203 [4] Freed, N., Borenstein, N., "Multipurpose Internet Mail 204 Extensions (MIME) Part One: Format of Internet Message Bodies", 205 RFC 2045, November 1996. 207 [5] Handley, M., Jackson, V., "SDP: Session Description Protocol", 208 RFC 2327, April 1998. 210 [6] Casner, S., Hoschka, P., "MIME Type Registration of RTP Payload 211 Formats", RFC 3555, July 2003. 213 7. Informative References 215 [7] Hellstrom, G., "RTP Payload for Text Conversation", RFC 2793, 216 May 2000. 218 [8] Baugher, et al., "The Secure Real-time Transport Protocol", RFC 219 3711, March 2004. 221 8. Author's Address 223 Paul E. Jones 224 Cisco Systems, Inc. 225 7025 Kit Creek Rd. 226 Research Triangle Park, NC 27709, USA 227 Phone: +1 919 392 6948 228 Email: paulej@packetizer.com 230 9. Full Copyright Statement 232 Copyright (C) The Internet Society (2004). 234 This document is subject to the rights, licenses and restrictions 235 contained in BCP 78, and except as set forth therein, the authors 236 retain all their rights. 238 Disclaimer 240 This document and the information contained herein are provided on an 241 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 242 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 243 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 244 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 245 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 246 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 248 Intellectual Property 250 =0C 251 The IETF takes no position regarding the validity or scope of any 252 Intellectual Property Rights or other rights that might be claimed to 253 pertain to the implementation or use of the technology described in 254 this document or the extent to which any license under such rights 255 might or might not be available; nor does it represent that it has 256 made any independent effort to identify any such rights. Information 257 on the procedures with respect to rights in RFC documents can be 258 found in BCP 78 and BCP 79. 260 Copies of IPR disclosures made to the IETF Secretariat and any 261 assurances of licenses to be made available, or the result of an 262 attempt made to obtain a general license or permission for the use of 263 such proprietary rights by implementers or users of this 264 specification can be obtained from the IETF on-line IPR repository at 265 http://www.ietf.org/ipr. 267 The IETF invites any interested party to bring to its attention any 268 copyrights, patents or patent applications, or other proprietary 269 rights that may cover technology that may be required to implement 270 this standard. Please address the information to the IETF at ietf- 271 ipr@ietf.org. 273 Acknowledgement 275 Funding for the RFC Editor function is currently provided by the 276 Internet Society. 278 =0C