One document matched: draft-gellens-mime-bucket-01.txt
Differences from draft-gellens-mime-bucket-00.txt
Internet Draft R. Gellens
Document: draft-gellens-mime-bucket-01.txt Qualcomm
Expires: April 2005 October 2004
The Codecs Parameter for "Bucket" Media Types
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed
and any of which I become aware will be disclosed, in accordance
with RFC 3668 (BCP 79).
By submitting this Internet-Draft, I accept the provisions of
Section 3 of RFC 3667 (BCP 78).
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt The list of
Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
Several MIME type/subtype combinations exist which can contain
different media formats. A receiving agent thus needs to examine
the details of such media content to determine if the specific
elements can be rendered given an available set of codecs.
Especially when the end system has limited resources, or the
connection to the end system has limited bandwidth, it would be
helpful to know from the Content-Type alone if the content can be
rendered.
Gellens [Page 1] Expires April 2005
Internet Draft The Codecs Parameter October 2004
This document adds a new parameter, "codecs", to various
type/subtype combinations to allow for unambiguous specification of
the codecs required to support the media formats contained within.
By labelling content with the specific codecs required to render the
contained media, receiving systems can determine if the codecs are
supported by the end system, and if not, can take appropriate action
(such as rejecting the content, sending notification of the
situation, transcoding the content to a supported type, fetching and
installing the required codecs, etc.)
Gellens [Page 2] Expires April 2005
Internet Draft The Codecs Parameter October 2004
Table of Contents
1. Conventions Used in this Document . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
3. The Codecs Parameter . . . . . . . . . . . . . . . . . . . . 5
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Additional Media Feature Details . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8
10. Informative References . . . . . . . . . . . . . . . . . . 9
11. Author's Address . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property Statement . . . . . . . . . . . . . . . 9
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 10
Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Conventions Used in this Document
The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD
NOT", and "MAY" in this document are to be interpreted as described
in "Key words for use in RFCs to Indicate Requirement Levels"
[KEYWORDS].
2. Introduction
One of the original motivations for MIME is the ability to identify
the specific media type of a message part. However, due to various
factors, it is not always possible from looking at the MIME type and
subtype to know which specific media formats are contained in the
body part, or which codecs are required in order to display the
content.
There are several media type/subtypes (either currently registered
or deployed with registration pending) which may contain codecs
chosen from a set. It is currently necessary to examine each media
element in order to determine the codecs required to render the
content. For example, video/3gpp may contain any of the video
formats H.263, H.263+, H.264, MPEG-4 SPL0, and/or any of the audio
formats AMR, AMR-WB, or AAC, as specified in [3GPP-Formats].
Gellens [Page 3] Expires April 2005
Internet Draft The Codecs Parameter October 2004
In some cases, the specific codecs can be determined by examining
the header information of the media content. While this isn't as
bad as examining the entire content, it still requires specialized
knowledge of each format and is resource consumptive.
This ambiguity can be a problem for various clients and servers. It
presents a significant burden to Multimedia Messaging (MMS) servers,
which must examine the media sent in each message in order to
determine which codecs are required to render the content. Only
then can it determine if the content requires transcoding or
specialized handling prior to being transmitted to the handset.
Additionally, it presents a challenge to smart clients on devices
with constrained memory, processing power, or transmission bandwidth
(such as cellular telephones and PDAs). Such clients often need to
determine in advance if they are currently capable of rendering the
content contained in an MMS or email message.
Specifically,
o audio/3gpp can contain AMR or AAC contents as specified in
[3GPP-Formats].
o audio/3gpp2 can contain AMR, AAC, 13K (as per [13k]), EVRC, or
SMV, as specified in [3GPP2-Formats] (video/3gpp2 MIME
registration pending).
o video/3gpp can contain H.263, H.263+, H.264, MPEG-4 SPL0, and/or
AMR, AMR-WB, or AAC, as specified in [3GPP-Formats].
o video/3gpp2 can contain H.263, H.263+, H.264, MPEG-4 SPL0,
and/or AMR, AAC, 13K (as per [13k]), EVRC, or SMV, as specified
in [3GPP2-Formats] (video/3gpp2 MIME registration pending).
Note that there are additional media types which are ambiguous, but
are outside the scope of this document, including:
o video/mp4V-ES and video/mpeg4-generic which can contain anything
allowed by the MPEG-4 specification, or any audio codec
registered with the MP4 registration authority [MP4-Reg].
o video/quicktime which can contain anything for which there is a
QuickTime codec component; since QuickTime is extensible, this
is not limited to the codecs that are or have been shipped by
Apple Computer.
With each "bucket" type, a receiving agent only knows that it has a
container format. It doesn't even know whether content labelled
video/3GPP or video/3GPP2 contains video; it might be audio only,
audio and video, or video only.
Gellens [Page 4] Expires April 2005
Internet Draft The Codecs Parameter October 2004
A solution which permits a receiving agent to determine the specific
codecs required to render media content would help provide efficient
and scalable servers, especially for Multimedia Messaging (MMS), and
aid the growth of multimedia services in wireless networks.
3. The Codecs Parameter
This document adds a parameter to allow unambiguous specification of
the codecs required to render the content in a media element. This
parameter is optional in all current types to which it is added.
Future types which contain ambiguity are strongly encouraged to
include this parameter, as mandatory if possible, as optional
otherwise.
Media types:
audio/3gpp,
audio/3gpp2*,
video/3gpp,
video/3gpp2*,
*registration pending
Parameter name:
Codecs
Parameter value:
A single value, or a comma-separated list of values (which must
be enclosed in quotes to comply with MIME rules) which
identifies the codec(s) required to render the content in the
body part.
Each value consists of one or more dot-separated elements. The
name space for the first element is determined by the MIME type.
The name space for each subsequent element is determined by the
preceding element.
Examples of Generic Syntax:
a.bb.c.d
"a.bb, c.dd"
Initial name space: This document only defines values for files
in the ISO File Format family. Other file formats may also
define codec naming.
Gellens [Page 5] Expires April 2005
Internet Draft The Codecs Parameter October 2004
For the ISO File format, the first element is a sample
description entry four-character code as registered by the MP4
Registration Authority [MP4-Reg]. The values are
case-sensitive. For the name 'mp4a', indicating some kind of
MPEG-4 audio, the second element is the hexadecimal
representation of the MP4 Registration Authority
ObjectTypeIndication (OTI) [MP4-Reg] (e.g., the element "0x20").
Syntax:
codecs = "Codecs" *SP "=" *SP value
value = id / DQUOTE *SP id *(*SP "," *SP id) *SP DQUOTE
id = id-ISO / id-gen
id-gen = element *( "." element )
id-ISO = cpid [ "." oti ]
cpid = 4 (idchar / idchar-spec)
oti = "0x" 2HEXDIG
element = 1*(idchar / idchar-spec)
idchar = <any (US-ASCII) CHAR except SPACE, CTLs,
"$", or tspecials>
idchar-spec = "$" 2DIGIT
tspecials = "(" / ")" / "<" / ">" / "@" /
"," / ";" / ":" / "\" / <">
"/" / "[" / "]" / "?" / "="
Note that in some cases, the four-character ID registered in
[MP4-Reg] may still be ambiguous, even when using the OTI. For
example, all mpeg-4 audio codecs are under 'mp4a', including HVXC,
CELP, GA (which can be AAC, twinVQ, or BSAC), SA, TTSI, HILN (see
MP4A). However, since audio/3gpp2, video/3gpp2, audio/3gpp, and
video/3gpp restrict the allowable ISO code points, there is no
ambiguity in these four cases.
Gellens [Page 6] Expires April 2005
Internet Draft The Codecs Parameter October 2004
When the Codecs parameter is used, it MUST contain all codecs
required to render all content present in the body part. The Codecs
parameter MUST NOT contain any codecs which are not present in the
body part.
4. Examples
Content-Type: Video/3GPP2; Codecs="sevc, s263"
(EVRC audio plus H.263 video)
Content-Type: Audio/3gp; Codecs=samr
(AMR audio)
Content-Type: video/3gpp; Codecs="s263, samr"
(H.263 video plus AMR audio)
Content-Type: audio/3gpp2; Codecs=mp4a.0xE1
(13k audio)
Content-Type: video/3gpp2; Codecs="mp4v.0x20, mp4a.0xE1"
(Visual ISO/IEC 14496-2 [MP4V] plus 13K voice)
Note: 0x20 OTI value says "Includes associated Amendment(s) and
Corrigendum(a). The actual object types are defined in ISO/IEC
14496-2 and are conveyed in the DecoderSpecificInfo as specified
in ISO/IEC 14496-2, Annex K."
5. Additional Media Feature Details
For the same reasons that the Codecs parameter is useful, it is
sometimes helpful to provide additional details for a media
element (e.g., the number of X and Y pixels, the color depth,
etc.). These details are sometimes called "media features" and
sometimes "media characteristics".
When such additional features are included, the
[Content-Features] header provides a handy way to do so.
6. IANA Considerations
The hard-working IANA staff is kindly requested to add "Codecs"
as an optional parameter to the media types listed in Section
3, with a reference to this document
Gellens [Page 7] Expires April 2005
Internet Draft The Codecs Parameter October 2004
7. Security Considerations
The codecs parameter itself does not alter the security
considerations of any of the media types for which it is
available. Each audio and video media type has its own set of
security considerations which continue to apply, regardless of
the use of the codecs parameter.
An incorrect codecs parameter might cause media content to be
received by a device which is not capable of rendering it, or
might cause media content to not be sent to a device which is
capable of receiving it. An incorrect codecs parameter is
therefore capable of some types of denial of service attacks.
However, this is most likely to arise by accident, as an
attacker capable of altering media data in transit could cause
more harm by altering the media format itself, or even the
content type header, rather than just the codecs parameter of
the content type header.
8. Acknowledgements
David Singer and Harinath Garudadri provided significant help,
which is very much appreciated.
9. Normative References
[ABNF] Crocker, Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium,
Demon Internet Ltd., November 1997.
[Content-Features] Kline, G., "Indicating Media Features for
MIME Content", RFC 2912, September 2000.
[MIME-Types] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996.
[Media-Features] Holtman, K., A. Mutz and T. Hardie, "Media
Feature Tag Registration Procedure", RFC 2506, BCP 31, March
1999.
Gellens [Page 8] Expires April 2005
Internet Draft The Codecs Parameter October 2004
[MP4-reg] MP4REG, The MPEG-4 Registration Authority,
<url://www.mp4ra.org>
10. Informative References
[13k] Gellens, R and H. Garudadri, "The QCP File Format and
Media Types for Speech Data", RFC 3625, September 2003.
[AMR] Sjoberg, J., M. Westerlund, A. Lakaniemi, 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.
[3GPP-Codecs] TS 26.234, Third Generation Partnership Project
(3GPP), "Transparent end-to-end streaming service; Protocols and
codecs", URL:
<http://www.3gpp.org/ftp/Specs/html-info/26234.htm>
[3GPP-Formats] TS 26.244, Third Generation Partnership Project
(3GPP), "Transparent end-to-end streaming service; 3GPP file
format (3GP)", URL:
<http://www.3gpp.org/ftp/Specs/html-info/26244.htm>
[3GPP2-Formats] Third Generation Partnership Project 2, "3GPP2
File Formats for Multimedia Service", URL:
<http://www.3gpp2.org/Public_html/specs/C.S0050-0_v1.0_121503.pdf>
[MP4A] ISO/IEC 14496-3:2001, "Information Technology--Coding of
Audio/Visual Object--Part 3: Audio".
[MP4V] ISO/IEC 14496-2:2001, "Information Technology--Coding of
Audio/Visual Object--Part 2: Video".
11. Author's Address
Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121
USA
randy@qualcomm.com
Gellens [Page 9] Expires April 2005
Internet Draft The Codecs Parameter October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any intellectual property 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; neither does
it represent that it has made any effort to identify any such
rights. Information on the IETF's procedures with respect to
rights in standards-track and standards-related documentation
can be found in BCP-11. Copies of claims of rights made
available for publication 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 implementors or users of this specification can be
obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights which may cover technology that may be
required to practice this standard. Please address the
information to the IETF Executive Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004).
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.
Disclaimer
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.
Gellens [Page 10] Expires April 2005
| PAFTECH AB 2003-2026 | 2026-04-24 07:41:08 |