GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc4102

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:
  1. The MIME type ("text") goes in SDP "m=" as the media name.
  1. The value of the parameter "rate" goes in SDP "a=rtpmap".
  1. The MIME subtype (RED) goes in SDP "a=rtpmap" as the encoding

name.

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

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

/data/webs/external/dokuwiki/data/pages/rfc/rfc4102.txt · Last modified: 2005/06/03 23:57 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki