1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc4102.txt b/doc/rfc/rfc4102.txt
new file mode 100644
index 0000000..b5880f1
--- /dev/null
+++ b/doc/rfc/rfc4102.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                           P. Jones
+Request for Comments: 4102                           Cisco Systems, Inc.
+Category: Standards Track                                      June 2005
+
+
+               Registration of the text/red MIME Sub-Type
+
+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 (2005).
+
+Abstract
+
+   This document defines the text/red MIME sub-type.  "Red" is short for
+   redundant.  The actual RTP packetization for this MIME type is
+   specified in RFC 2198.
+
+1.  Introduction
+
+   Text is an important component of any multimedia communication
+   system.  Like audio, the transport of text can benefit from the use
+   of redundancy in order to improve reliability and end-user
+   experience.
+
+   RFC 2198 [1] defines an RTP [2] payload format for redundant audio
+   data.  The format defined in that document is quite suitable for
+   providing redundancy for text, as well as audio.
+
+   RFC 4103 [8] specifies one usage of RFC 2198 and the text/red MIME
+   type for the transport of redundant text data.
+
+   This memo provides the MIME sub-type registration information for
+   text/red.  While this document focuses on the use of this MIME sub-
+   type in SDP [5], the application of this MIME sub-type is not
+   restricted to SDP.
+
+
+
+
+
+
+
+
+Jones                       Standards Track                     [Page 1]
+
+RFC 4102                 text/red MIME Sub-Type                June 2005
+
+
+2.  Conventions Used in This Document
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [3].
+
+3.  IANA Considerations
+
+   One new MIME sub-type has been registered by the IANA, as described
+   below:
+
+   MIME media type name: text
+
+   MIME subtype name: RED
+
+   Required parameters:
+      rate: the RTP clock rate of the payload carried within the RTP
+      packet.  Typically, this rate is 1000, but other rates MAY be
+      specified.  This parameter MUST be set equal to the clock rate of
+      the text payload format carried as the primary encoding.
+
+      pt: a comma-separated ordered list of RTP payload types
+      enumerating the primary, secondary, etc., in accordance with RFC
+      2198.  Because comma is a special character, the list MUST be a
+      quoted-string (enclosed in double quotes).  For static payload
+      types, each list element is simply the type number.  For dynamic
+      payload types, each list element is a mapping of the dynamic
+      payload type number to an embedded MIME content-type specification
+      for the payload format corresponding to the dynamic payload type.
+      The format of the mapping is:
+
+               dynamic-payload-type "=" content-type
+
+      If the content-type string includes a comma, then the content-
+      type string MUST be a quoted-string.  If the content-type string
+      does not include a comma, it MAY still be quoted.  Because it is
+      part of the list, which must itself be a quoted-string, the
+      quotation marks MUST be quoted with backslash quoting as specified
+      in RFC 2045 [4].  If the content-type string itself contains a
+      quoted-string, then the requirement for backslash quoting is
+      recursively applied.
+
+   Optional parameters: ptime, maxptime (these attributes are originally
+      defined in RFC 2327 [5] and RFC 3267 [6], respectively)
+
+   Restrictions on Usage:
+      This type is defined only for transfer via RTP.
+      It shall not be defined for a storage format.
+
+
+
+Jones                       Standards Track                     [Page 2]
+
+RFC 4102                 text/red MIME Sub-Type                June 2005
+
+
+   Encoding considerations:
+      See restrictions on Usage above; this section is included per
+      the requirements in RFC 3555 [7].
+
+   Security considerations: Refer to section 5 of RFC 4102.
+
+   Interoperability considerations: none
+
+   Published specification: RFC 2198
+
+   Applications which use this media type:
+      Text streaming and conferencing tools.
+
+   Additional information: none
+
+   Person & email address to contact for further information:
+      Paul E. Jones
+      E-mail: paulej@packetizer.com
+
+   Intended usage: COMMON
+
+   Author:
+      Paul E. Jones
+      paulej@packetizer.com
+
+   Change Controller:
+      AVT Working Group delegated from the IESG
+
+4.  Mapping to SDP Parameters
+
+   The information carried in the MIME media type specification has a
+   specific mapping to fields in the Session Description Protocol (SDP)
+   [5], which is commonly used to describe RTP sessions.  When SDP is
+   used to specify sessions employing the RFC 2198 in a text session,
+   the mapping is as follows:
+
+   -  The MIME type ("text") goes in SDP "m=" as the media name.
+
+   -  The value of the parameter "rate" goes in SDP "a=rtpmap".
+
+   -  The MIME subtype (RED) goes in SDP "a=rtpmap" as the encoding
+      name.
+
+   -  The parameters "ptime" and "maxptime" go in the SDP "a=ptime" and
+      "a=maxptime" attributes, respectively.
+
+
+
+
+
+
+Jones                       Standards Track                     [Page 3]
+
+RFC 4102                 text/red MIME Sub-Type                June 2005
+
+
+   -  The pt parameter is mapped to an a=fmtp attribute by eliminating
+      the parameter name (pt) and changing the commas to slashes.  For
+      example, 'pt="101,102"' maps to 'a=fmtp:99 101/102', where = '99'
+      is the payload type of the redundancy frames.  Note that the
+      single quote marks (') used in this example are not present in the
+      actual message encoding, but are present here only for
+      readability.  The level of redundancy is shown by the number of
+      elements in the payload type list.
+
+   Any dynamic payload type in the list MUST be represented by its
+   payload type number and not by its content-type.  The mapping of
+   payload types to the content-type is done using the normal SDP
+   procedures with "a=rtpmap".
+
+   An example of SDP is:
+
+        m=text 11000 RTP/AVP 98 100
+        a=rtpmap:98 t140/1000
+        a=rtpmap:100 red/1000
+        a=fmtp:100 98/98
+
+   For each redundancy payload type defined, the ordering of the primary
+   and redundancy encoding(s) is fixed.  If more than one combination of
+   primary and redundancy encoding(s) is desired, multiple redundancy
+   payload types needs to be defined.
+
+5.  Security Considerations
+
+   The security considerations listed in RFC 2198 apply.  Further, it
+   should be understood that text data, perhaps even more so than audio
+   data, is susceptible to unwanted modification that may lead to
+   undesired results.  To prevent modification of the primary,
+   secondary, or header information, payload integrity protection over
+   at least the complete RTP packet is RECOMMENDED, for example using
+   SRTP [9].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jones                       Standards Track                     [Page 4]
+
+RFC 4102                 text/red MIME Sub-Type                June 2005
+
+
+6.  Normative References
+
+   [1] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M.,
+       Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, "RTP Payload
+       for Redundant Audio Data", RFC 2198, September 1997.
+
+   [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
+       "RTP: A Transport Protocol for Real-Time Applications", STD 64,
+       RFC 3550, July 2003.
+
+   [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+       Levels", BCP 14, RFC 2119, March 1997.
+
+   [4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+       Extensions (MIME) Part One: Format of Internet Message Bodies",
+       RFC 2045, November 1996.
+
+   [5] Handley, M., Jackson, V., "SDP: Session Description Protocol",
+       RFC 2327, April 1998.
+
+   [6] Sjoberg, J., Westerlund, M., Lakaniemi, A., and Q. Xie, "Real-
+       Time Transport Protocol (RTP) Payload Format and File Storage
+       Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate
+       Wideband (AMR-WB) Audio Codecs", RFC 3267, June 2002.
+
+   [7] Casner, S. and P. Hoschka, "MIME Type Registration of RTP Payload
+       Formats", RFC 3555, July 2003.
+
+7.  Informative References
+
+   [8] Hellstrom, G. and P. Jones, "RTP Payload for Text Conversation",
+       RFC 4103, June 2005.
+
+   [9] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
+       Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
+       3711, March 2004.
+
+Author's Address
+
+   Paul E. Jones
+   Cisco Systems, Inc.
+   7025 Kit Creek Rd.
+   Research Triangle Park, NC 27709, USA
+
+   Phone: +1 919 392 6948
+   EMail: paulej@packetizer.com
+
+
+
+
+
+Jones                       Standards Track                     [Page 5]
+
+RFC 4102                 text/red MIME Sub-Type                June 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Jones                       Standards Track                     [Page 6]
+