idnits 2.17.1 draft-jones-avt-text-red-00.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: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. 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 (November 2003) is 7467 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: '2' is defined on line 130, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2793 (ref. '1') (Obsoleted by RFC 4103) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 AVT Working Group 2 Internet Draft P. Jones 3 Cisco Systems, Inc. 4 Expires: May 2004 November 2003 6 Registration of the text/red MIME Sub-Type 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document defines the text/red MIME sub-type. The packetization 31 and usage of this MIME type, which is intended for use within SDP, is 32 specified within RFC 2198 and RFC 2793, respectively. 34 1. Introduction 36 Text is an important component of any multimedia communication 37 system. Like audio, the transport of text can benefit from the use 38 of redundancy in order to improve reliability and end-user 39 experience. 41 RFC 2198 defines a payload format for audio data. The format defined 42 in that document is quite suitable for providing redundancy for text, 43 as well as audio. 45 RFC 2793 [1] specifies the use of RFC 2198 for the transport of 46 redundant text data. 48 Registration of the text/red MIME Sub-Type November 2003 50 This memo provides the MIME sub-type registration information. 52 2. Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in RFC 2119 [4]. 58 3. IANA Considerations 60 One new MIME sub-type is to be registered, as described below: 62 MIME media type name: text 64 MIME subtype name: RED 66 Required parameters: 67 pt: a comma-separated list of RTP payload types. Because 68 comma is a special character, the list must be a quoted-string 69 (enclosed in double quotes). For static payload types, each 70 list element is simply the type number. For dynamic payload 71 types, each list element is a mapping of the dynamic payload 72 type number to an embedded MIME content-type specification for 73 the payload format corresponding to the dynamic payload type. 74 The format of the mapping is: 76 dynamic-payload-type "=" content-type 78 If the content-type string includes a comma, then the 79 content-type string MUST be a quoted-string. If the content- 80 type string does not include a comma, it MAY still be quoted. 81 Since it is part of the list which must itself be a quoted- 82 string, that means the quotation marks MUST be quoted with 83 backslash quoting as specified in RFC 2045 [5]. If the content- 84 type string itself contains a quoted-string, then the 85 requirement for backslash quoting is recursively applied. To 86 specify the text/RED payload format in SDP, the pt parameter 87 is mapped to an a=fmtp attribute by eliminating the parameter 88 name (pt) and changing the commas to slashes. For example, 89 'pt="101,102"' maps to 'a=fmtp:99 101/102'. 91 Optional parameters: ptime, maxptime 93 Encoding considerations: 94 This type is only defined for transfer via RTP [3]. 96 Security considerations: Refer to section 4. 98 Interoperability considerations: none 99 Registration of the text/red MIME Sub-Type November 2003 101 Published specification: RFC 2198 103 Applications which use this media type: 104 Text streaming and conferencing tools. 106 Additional information: none 108 Person & email address to contact for further information: 109 Paul E. Jones 110 E-mail: paulej@packetizer.com 112 Intended usage: COMMON 114 Author / Change controller: 115 Paul E. Jones | IETF avt WG 116 paulej@packetizer.com | 118 4. Security Considerations 120 The security considerations listed in RFC 2198 apply. Further, it 121 should be understood that text data, perhaps even more so than audio 122 data, is susceptible to unwanted modification that may lead to 123 undesired results. 125 5. Normative References 127 [1] Hellstrom, G., "RTP Payload for Text Conversation�, RFC 2793, 128 May 2000. 130 [2] Perkins, C., et al., "RTP Payload for Redundant Audio Data", RFC 131 2198, September 1997. 133 [3] Schulzrinne, et al., "RTP: A Transport Protocol for Real-Time 134 Applications", RFC 3550, July 2003. 136 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 137 Levels", RFC 2119, March 1997. 139 [5] Freed, N., Borenstein, N., "Multipurpose Internet Mail 140 Extensions (MIME) Part One: Format of Internet Message Bodies", 141 RFC 2045, November 1996. 143 6. Author's Address 145 Paul E. Jones 146 Cisco Systems, Inc. 147 7025 Kit Creek Rd. 148 Research Triangle Park, NC 27709 149 Registration of the text/red MIME Sub-Type November 2003 151 Phone: +1 919 392 6948 152 Email: paulej@packetizer.com 154 7. Intellectual Property Right Considerations 156 The IETF takes no position regarding the validity or scope of any 157 intellectual property or other rights that might be claimed to 158 pertain to the implementation or use of the technology described in 159 this document or the extent to which any license under such rights 160 might or might not be available; neither does it represent that it 161 has made any effort to identify any such rights. Information on the 162 IETF's procedures with respect to rights in standards-track and 163 standards-related documentation can be found in BCP-11. Copies of 164 claims of rights made available for publication and any assurances of 165 licenses to be made available, or the result of an attempt made to 166 obtain a general license or permission for the use of such 167 proprietary rights by implementors or users of this specification can 168 be obtained from the IETF Secretariat. 170 The IETF invites any interested party to bring to its attention any 171 copyrights, patents or patent applications, or other proprietary 172 rights which may cover technology that may be required to practice 173 this standard. Please address the information to the IETF Executive 174 Director. 176 8. Full Copyright Statement 178 Copyright (C) The Internet Society (2003). All Rights Reserved. 180 This document and translations of it may be copied and furnished to 181 others, and derivative works that comment on or otherwise explain it 182 or assist in its implementation may be prepared, copied, published 183 and distributed, in whole or in part, without restriction of any 184 kind, provided that the above copyright notice and this paragraph are 185 included on all such copies and derivative works. However, this 186 document itself may not be modified in any way, such as by removing 187 the copyright notice or references to the Internet Society or other 188 Internet organizations, except as needed for the purpose of 189 developing Internet standards in which case the procedures for 190 copyrights defined in the Internet Standards process must be 191 followed, or as required to translate it into languages other than 192 English. 194 The limited permissions granted above are perpetual and will not be 195 revoked by the Internet Society or its successors or assigns. 197 This document and the information contained herein is provided on an 198 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 199 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 200 Registration of the text/red MIME Sub-Type November 2003 202 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 203 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 204 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 206 Acknowledgement 208 Funding for the RFC Editor function is currently provided by the 209 Internet Society.