One document matched: draft-gellens-mime-bucket-bis-00.txt
Network Working Group R. Gellens
Internet-Draft QUALCOMM Incorporated
Obsoletes: 4281 (if approved) D. Singer
Intended status: Standards Track Apple Inc.
Expires: June 26, 2011 P. Frojdh
Ericsson Research
December 23, 2010
The Codecs and Profiles Parameters for "Bucket" Media Types
draft-gellens-mime-bucket-bis-00.txt
Abstract
Several MIME type/subtype combinations exist that 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.
This document specifies two parameters, "codecs" and "profiles",
which are used with various MIME types or type/subtype combinations
to allow for unambiguous specification of the codecs and/or profiles
employed by the media formats contained within.
By labeling content with the specific codecs indicated 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, further inspection to determine if it
will be sufficient to support a subset of the indicated codecs, etc.)
Similarly, the profiles can provide an overall indication, to the
receiver, of the specifications with which the content complies. The
receiver may be able to work out the extent to which it can handle
and render the content by examining to see which of the declared
profiles it supports, and what they mean.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
Gellens, et al. Expires June 26, 2011 [Page 1]
Internet-Draft MIME profiles December 2010
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.
This Internet-Draft will expire on June 26, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Gellens, et al. Expires June 26, 2011 [Page 2]
Internet-Draft MIME profiles December 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions Used in This Document . . . . . . . . . . . . . . 6
3. The Codecs Parameter . . . . . . . . . . . . . . . . . . . . . 7
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Generic Syntax . . . . . . . . . . . . . . . . . . . . . . 8
3.3. ISO File Format Name Space . . . . . . . . . . . . . . . . 9
3.4. ISO Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
3.5. Use in Additional Media Types . . . . . . . . . . . . . . 11
3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.7. Additional Media Feature Details . . . . . . . . . . . . . 12
4. The Profiles Parameter . . . . . . . . . . . . . . . . . . . . 13
4.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Formal Declaration . . . . . . . . . . . . . . . . . . . . 13
4.3. Profiles Parameter Definition . . . . . . . . . . . . . . 14
4.4. Profiles for ISO Base Media File Format and QuickTime
files . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.5. Profiles Parameter BNF Definition . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6. Registration . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Gellens, et al. Expires June 26, 2011 [Page 3]
Internet-Draft MIME profiles December 2010
1. 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 indicated in order to render the
content.
There are several media type/subtypes (either currently registered or
deployed with registration pending) that contain codecs chosen from a
set. In the absence of the parameters described here, it is
necessary to examine each media element in order to determine the
codecs or other features required to render the content. For
example, video/3gpp may contain any of the video formats H.263
Profile 0, H.263 Profile 3, H.264, MPEG-4 Simple Profile, and/or any
of the audio formats Adaptive Multi Rate (AMR), Adaptive Multi Rate -
WideBand (AMR-WB), Extended AMR-WB, Advanced Audio Coding (AAC), or
Enhanced aacPlus, as specified in [3GPP-Formats].
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 such a server 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.
Ambiguity:
o audio/3gpp can contain AMR, AAC, AMR-WB, Extended AMR-WB, or
Enhanced aacPlus contents as specified in [3GPP-Formats].
o audio/3gpp2 can contain AMR, AAC, 13K (as per [13k]), Enhanced
Variable Rate Codec (EVRC), Selectable Mode Vocoder (SMV), or
VMR-WB, as specified in [3GPP2-Formats].
Gellens, et al. Expires June 26, 2011 [Page 4]
Internet-Draft MIME profiles December 2010
o video/3gpp can contain H.263 Profile 0, H.263 Profile 3, H.264,
MPEG-4 Simple Profile, and/or AMR, AMR-WB, Extended AMR-WB, AAC,
or Enhanced aacPlus, as specified in [3GPP-Formats].
o video/3gpp2 can contain H.263 Profile 0, H.263 Profile 3, H.264,
MPEG-4 Simple Profile, and/or AMR, AAC, 13K (as per [RFC3625]),
EVRC, SMV, or VMR-WB, as specified in [3GPP2-Formats].
Note that there are additional media types that are ambiguous, but
are outside the scope of this document, including:
o video/mpeg4-generic, which can contain anything allowed by the
MPEG-4 specification, or any codec registered with the MP4
registration authority [MP4RA];
With each "bucket" type, a receiving agent only knows that it has a
container format. It doesn't even know whether content labeled
video/3gpp or video/3gpp2 contains video; it might be audio only,
audio and video, or video only.
A solution that permits a receiving agent to determine the specific
codecs or profiles 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.
Gellens, et al. Expires June 26, 2011 [Page 5]
Internet-Draft MIME profiles December 2010
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 "Key words for use in
RFCs to Indicate Requirement Levels" [RFC2119] .
The syntax in this document uses the BNF rules specified in [RFC2045]
and [RFC2231].
Gellens, et al. Expires June 26, 2011 [Page 6]
Internet-Draft MIME profiles December 2010
3. The Codecs Parameter
3.1. Introduction
This section adds a parameter to allow unambiguous specification of
all codecs indicated to render the content in the MIME part. This
parameter is optional in all current types to which it is added.
Future types that contain ambiguity are strongly encouraged to
include this parameter.
This parameter applies to:
1. Files in the family based on the ISO Base Media File Format
[ISO14496-12].
2. The QuickTime file format, owned by Apple Inc.
This includes the media types:
1. audio/3gpp, video/3gpp
2. audio/3gpp2, video/3gpp2
3. audio/mp4, video/mp4
4. video/quicktime
Parameter name: Codecs
Parameter value: A single value, or a comma-separated list of values
identifying the codec(s) indicated 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.
Note that, per [RFC2045], some characters (including the comma used
to separate multiple values) require that the entire parameter value
be enclosed in quotes.
An element MAY include an octet that must be encoded in order to
comply with [RFC2045]. In this case, [RFC2231] is used: an asterisk
("*") is placed at the end of the parameter name (becoming "codecs*"
instead of "codecs"), the parameter value usually starts with two
single quote ("'") characters (indicating that neither character set
nor language is specified), and each octet that requires encoding is
Gellens, et al. Expires June 26, 2011 [Page 7]
Internet-Draft MIME profiles December 2010
represented as a percent sign ("%") followed by two hexadecimal
digits. Note that, when the [RFC2231] form is used, the percent
sign, asterisk, and single quote characters have special meaning and
so must themselves be encoded.
Examples of Generic Syntax:
codecs=a.bb.ccc.d
codecs="a.bb.ccc.d, e.fff"
codecs*=''fo%2e
codecs*="''%25%20xz, gork"
When the Codecs parameter is used, it MUST contain all codecs
indicated by the content present in the body part. The Codecs
parameter MUST NOT include any codecs that are not indicated by any
media elements in the body part.
In some cases, not all indicated codecs are absolutely required in
order to render the content. Therefore, when a receiver does not
support all listed codecs, special handling MAY be required. For
example, the media element(s) MAY need to be examined in order to
determine if an unsupported codec is actually required (e.g., there
may be alternative tracks (such as English and Spanish audio), there
may be timed text that can be dropped, etc.)
NOTE: Although the parameter value MUST be complete and accurate in
'breadth' (that is, it MUST report all four-character codes used in
all tracks for ISO-family files, for example) systems MUST NOT rely
on it being complete in 'depth'. If the hierarchical rules for a
given code (e.g., 'qvxy') were written after a server was
implemented, for example, that server will not know what elements to
place after 'qvxy'.
If a receiver encounters a body part whose Codecs parameter contains
codecs that are not indicated by any media elements, then the
receiver SHOULD process the body part by discarding the information
in the Codecs parameter.
If a receiver encounters a body part whose Codecs parameter does not
contain all codecs indicated by the media elements, then the receiver
MAY process the body part by discarding the information in the Codecs
parameter.
3.2. Generic Syntax
The Codecs parameter takes either of two forms. The first form is
used when the value does not contain any octets that require
encoding. The second form uses [RFC2231] to allow arbitrary octets
Gellens, et al. Expires June 26, 2011 [Page 8]
Internet-Draft MIME profiles December 2010
to be encoded. With either form, quotes allow for commas and other
characters in <tspecials> (quotes MAY be used even when not
required).
This BNF uses the rules specified in [RFC2045] and [RFC2231] .
Implementations MUST NOT add CFWS between the tokens except after
",". TOKEN is defined in [RFC2045], and <ext-octet> and <attribute-
char> are defined in [RFC2231].
codecs := cod-simple / cod-fancy
cod-simple := "codecs" "=" unencodedv
unencodedv := id-simple / simp-list
simp-list := DQUOTE id-simple *( "," id-simple ) DQUOTE
id-simple := element
; "." reserved as hierarchy delimiter
element := 1*octet-sim
octet-sim := <any TOKEN character>
; Within a Codecs parameter value, "." is reserved
; as a hierarchy delimiter
cod-fancy := "codecs*" ":=" encodedv
encodedv := fancy-sing / fancy-list
fancy-sing := [charset] "'" [language] "'" id-encoded
; Parsers MAY ignore <language>
; Parsers MAY support only US-ASCII and UTF-8
fancy-list := DQUOTE [charset] "'" [language] "'" id-list DQUOTE
; Parsers MAY ignore <language>
; Parsers MAY support only US-ASCII and UTF-8
id-list := id-encoded *( "," id-encoded )
id-encoded := encoded-elm *( "." encoded-elm )
; "." reserved as hierarchy delimiter
encoded-elm := 1*octet-fancy
octet-fancy := ext-octet / attribute-char
DQUOTE := %x22 ; " (double quote)
Initial name space: This document only defines values for files in
the ISO Base Media File Format, and QuickTime, families. Other file
formats may also define codec naming.
3.3. ISO File Format Name Space
For the ISO Base Media File Format, and the QuickTime movie file
format, the first element of a Codecs parameter value is a sample
description entry four-character code as registered by the MP4
Registration Authority [MP4RA]. Values are case sensitive.
Gellens, et al. Expires June 26, 2011 [Page 9]
Internet-Draft MIME profiles December 2010
Note that there are potentially multiple tracks in a file, each
potentially carrying multiple sample entries (some but not all uses
of the ISO File Format restrict the number of sample entries in a
track to one).
When the first element of a value is 'mp4a' (indicating some kind of
MPEG-4 audio) or 'mp4v' (indicating some kind of MPEG-4 part-2
video), the second element is the hexadecimal representation of the
MP4 Registration Authority ObjectTypeIndication (OTI), as specified
in [MP4RA] and [MP41] (including amendments). Note that [MP4RA] uses
a leading "0x" with these values, which is omitted here and hence
implied.
One of the OTI values for 'mp4a' is 40 (identifying MPEG-4 audio).
For this value, the third element identifies the audio
ObjectTypeIndication (OTI) as defined in [MP4A] (including
amendments), expressed as a decimal number.
For example, AAC low complexity has the value 2, so a complete string
for AAC-LC would be "mp4a.40.2".
One of the OTI values for 'mp4v' is 20 (identifying MPEG-4 part-2
video). For this value, the third element identifies the video
ProfileLevelIndication as defined in [MP4V] (including amendments),
expressed as a decimal number.
For example, MPEG-4 Visual Simple Profile Level 0 has the value 9, so
a complete string for MPEG-4 Visual Simple Profile Level 0 would be
"mp4v.20.9".
When the first element of a value is code indicating a codec from the
Advanced Video Coding specification [AVC], such as 'avc1' -
indicating AVC (h.264) video - or a code indicating Scalable Video
Coding (SVC) or Multiview Video Coding (MVC), the second element is
the hexadecimal representation of the following three bytes in the
sequence parameter set NAL unit specified in [AVC]:
(1) profile_idc,
(2) a byte composed of the values of constraint_set0_flag,
constraint_set1_flag, constraint_set2_flag,
constraint_set3_flag, and reserved_zero_4bits in bit-
significance order, starting from the most significant bit, and
(3) level_idc.
Note that reserved_zero_4bits is required to be equal to 0 in [AVC],
but other values for it may be specified in the future by ITU-T or
Gellens, et al. Expires June 26, 2011 [Page 10]
Internet-Draft MIME profiles December 2010
ISO/IEC.
This is as previously defined in the 3GPP File Format specification
3GPP TS 26.244 [3GPP-Formats], section A.2.2.
3.4. ISO Syntax
id-simple :=/ id-iso
id-encoded :=/ id-iso
id-iso := iso-gen / iso-mpega / iso-mpegv
iso-gen := cpid *( element / encoded-elm )
; <element> used with <codecs-simple>
; <encoded-elm> used with <codecs-fancy>
;
; Note that the BNF permits "." within <element>
; and <encoded-elm> but "." is reserved as the
; hierarchy delimiter
iso-mpega := mp4a "." oti [ "." aud-oti ]
iso-mpegv := mp4v "." oti [ "." vid-pli ]
iso-avc := avc1 [ "." avcoti ]
cpid := 4(octet-simple / octet-fancy)
; <octet-simple> used with <codecs-simple>
; <octet-fancy> used with <codecs-fancy>
mp4a := %x6d.70.34.61 ; 'mp4a'
oti := 2(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; leading "0x" omitted
avcoti := 6(DIGIT / "A" / "B" / "C" / "D" / "E" / "F")
; leading "0x" omitted
aud-oti := 1*DIGIT
mp4v := %x6d.70.34.76 ; 'mp4v'
vid-pli := 1*DIGIT
3.5. Use in Additional Media Types
This parameter MAY be specified for use with additional MIME media
types.
For ISO file formats where the name space as defined here is
sufficient, all that needs to be done is to update the media type
registration to specify the Codecs parameter with a reference to this
document. For existing media types, it is generally advisable for
the parameter to be optional; for new media types, the parameter MAY
be optional or required, as appropriate.
For ISO file formats where the name space as defined here needs to be
expanded, a new document MAY update this one by specifying the
additional detail.
Gellens, et al. Expires June 26, 2011 [Page 11]
Internet-Draft MIME profiles December 2010
For non-ISO formats, a new document MAY update this one by specifying
the name space for the media type(s).
3.6. Examples
Content-Type: video/3gpp2; codecs="sevc, s263"
(EVRC audio plus H.263 video)
Content-Type: audio/3gpp; codecs=samr
(AMR audio)
Content-Type: video/3gpp; codecs="s263, samr"
(H.263 video plus AMR audio)
Content-Type: audio/3gpp2; codecs=mp4a.E1
(13k audio)
Content-Type: video/3gpp2; codecs="mp4v.20.9, mp4a.E1"
(MPEG-4 Visual Simple Profile Level 0 plus 13K voice)
Note: OTI value 20 ("0x20" in [MP4RA]) says "Includes associated
Amendment(s) and Corrigendum(a). The actual object types are defined
in [MP4V] and are conveyed in the DecoderSpecificInfo as specified in
[MP4V], Annex K." (references adjusted).
3.7. Additional Media Feature Details
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" or "media
characteristics".
When such additional features are included, the content-features
[RFC2912] header provides a handy way to do so.
Gellens, et al. Expires June 26, 2011 [Page 12]
Internet-Draft MIME profiles December 2010
4. The Profiles Parameter
4.1. Introduction
Just as some codecs have a variety of profiles (subsets of their
functionality within which a bitstream can be coded), so also some
media files can be profiled, and be associated with one or more
profile identifiers of the profiles to which they conform. These
profiles can indicate features of the file format itself, which
codecs may be present, the profiles of those codecs, and so on. It
can be advantageous to a receiving system to know the overall file
profile(s) of a file; indeed, under these circumstances it may not be
necessary to know the codecs themselves if they are implied by the
profile.
4.2. Formal Declaration
This section adds a parameter to allow unambiguous specification of
the profiles to which a file claims conformance. This parameter is
optional in all current types to which it is added.
This parameter applies to:
1. Files in the family based on the ISO Base Media File Format
[ISO14496-12].
2. The QuickTime file format, owned by Apple Inc.
This includes the media types:
1. audio/3gpp, video/3gpp
2. audio/3gpp2, video/3gpp2
3. audio/mp4, video/mp4
4. video/quicktime
Parameter name: Profiles
Parameter value: A single value, or a comma-separated list of values
identifying the profiles(s) to which the file claims conformance.
Each value consists of one or more dot-separated elements. The name
space is determined by the MIME type.
Note that, per [RFC2045], some characters (including the comma used
to separate multiple values) require that the entire parameter value
Gellens, et al. Expires June 26, 2011 [Page 13]
Internet-Draft MIME profiles December 2010
be enclosed in quotes.
An element MAY include an octet that must be encoded in order to
comply with [RFC2045]. In this case, [RFC2231] is used: an asterisk
("*") is placed at the end of the parameter name (becoming "codecs*"
instead of "codecs"), the parameter value usually starts with two
single quote ("'") characters (indicating that neither character set
nor language is specified), and each octet that requires encoding is
represented as a percent sign ("%") followed by two hexadecimal
digits. Note that, when the [RFC2231] form is used, the percent
sign, asterisk, and single quote characters have special meaning and
so must themselves be encoded.
Examples of Generic Syntax:
profiles="isom,mp41,qvXt"
profiles*="''%25%20xz, gork"
4.3. Profiles Parameter Definition
The 'profiles' parameter is an optional parameter that indicates one
or more profiles to which the file claims conformance. Like the
'codecs' parameter described above, it may occur as either 'profiles'
or 'profiles*', with the same encoding rules. The value is, as for
the codecs parameter, a comma-separated list of profile identifiers.
Each profile may be followed by a period character and an associated
level identifier, if desired. The profiles parameter values are
therefore at most two level (a.b).
4.4. Profiles for ISO Base Media File Format and QuickTime files
For any file format based on the ISO Base Media File Format ISO/IEC
14496-12 [ISO14496-12] and QuickTime movie files, the profiles
parameter MUST list exactly the major brand, followed by the
compatible-brands, as listed in the filetype box ('ftyp'). The
major-brand MUST be first, and MAY be removed from the compatible-
brands list. (The file format requires that it be repeated in the
compatible brands, but this is requirement is relaxed here for
compactness.) There are no levels indicated in the filetype box, and
hence each value is a simple profile identifier without a period or
level indicator.
Note that brand codes are registered at the MP4 Registration
Authority [MP4RA].
An example might be profiles="mp41,isom,qvXt", indicating that MPEG-4
version 1 is the major brand and preferred use, that the file is
Gellens, et al. Expires June 26, 2011 [Page 14]
Internet-Draft MIME profiles December 2010
compatible with the version of the base file format identified by
'isom', and that it is also compatible with the specification/profile
'qvXt' (whatever that may be).
4.5. Profiles Parameter BNF Definition
profil := pro-simple / pro-fancy
pro-simple := "profiles" "=" unencodedv
; Within a Codecs parameter value, "." is reserved
; as a hierarchy delimiter
pro-fancy := "profiles*" ":=" encodedv
Gellens, et al. Expires June 26, 2011 [Page 15]
Internet-Draft MIME profiles December 2010
5. IANA Considerations
The IANA has added "codecs" and "profiles" as optional parameters to
the media types as listed in Sections 3 and 4, with a reference to
this document.
Gellens, et al. Expires June 26, 2011 [Page 16]
Internet-Draft MIME profiles December 2010
6. Registration
The MPEG4 Registration Authority can be consulted for the most up-to-
date registration of sub-parameters for the codecs type, for specific
codecs.
Gellens, et al. Expires June 26, 2011 [Page 17]
Internet-Draft MIME profiles December 2010
7. Security Considerations
The Codecs parameter itself does not alter the security
considerations of any of the media types with which it is used. Each
audio and video media type has its own set of security considerations
that 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 that is not capable of rendering it, or might
cause media content to not be sent to a device that 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.
Gellens, et al. Expires June 26, 2011 [Page 18]
Internet-Draft MIME profiles December 2010
8. Acknowledgements
Harinath Garudadri provided a great deal of help, which is very much
appreciated. Mary Barnes and Bruce Lilly provided detailed and
helpful comments. Reviews and comments by Sam Hartman, Russ Housley,
and Bert Wijnen were much appreciated. Chris Newman carefully
reviewed and improved the BNF.
Gellens, et al. Expires June 26, 2011 [Page 19]
Internet-Draft MIME profiles December 2010
9. References
9.1. Normative References
[3GPP-Formats]
3rd Generation Partnership Project, "Technical
Specification Group Services and System Aspects;
Transparent end-to-end packet switched streaming service
(PSS); 3GPP file format (3GP)", 3GPP TS 26.244.
[AVC] "Advanced video coding for generic audiovisual services",
ITU-T Recommendation H.264, ISO/IEC 14496-10:2009.
[ISO14496-12]
"Information technology -- Coding of audio-visual objects
-- Part 12: ISO base media file format", ISO/
IEC 14496-12:2008.
[MP4RA] "MP4REG, The MPEG-4 Registration Authority",
<http://www.mp4ra.org>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions:
Character Sets, Languages, and Continuations", RFC 2231,
November 1997.
[RFC2912] Klyne, G., "Indicating Media Features for MIME Content",
RFC 2912, September 2000.
9.2. Informative References
[3GPP2-Formats]
Third Generation Partnership Project 2, "3GPP2 File
Formats for Multimedia Service", <http://www.3gpp2.org/
Public_html/specs/C.S0050-0_v1.0_121503.pdf>.
[MP41] "Information technology--Coding of audio-visual objects--
Part 1: Systems", ISO/IEC 14496-1:2010.
[MP4A] "Information technology--Coding of audio-visual
objects--3: Audio", ISO/IEC 14496-3:2009.
Gellens, et al. Expires June 26, 2011 [Page 20]
Internet-Draft MIME profiles December 2010
[MP4V] "Information technology--Coding of audio-visual objects--
Part 2: Visual", ISO/IEC 14496-2:2004.
[RFC3625] Gellens, R. and H. Garudadri, "The QCP File Format and
Media Types for Speech Data", RFC 3625, September 2003.
Gellens, et al. Expires June 26, 2011 [Page 21]
Internet-Draft MIME profiles December 2010
Authors' Addresses
Randall Gellens
QUALCOMM Incorporated
5775 Morehouse Drive
San Diego, CA 92121
US
Email: randy@qualcomm.com
David Singer
Apple Inc.
1 Infinite Loop
Cupertino, CA 95014
US
Phone: +1 408 996 1010
Email: singer@apple.com
Per Frojdh
Ericsson Research
Multimedia Technologies SE-164
Stockholm 80
Sweden
Phone: +46 8 7190000
Email: Per.Frojdh@ericsson.com
Gellens, et al. Expires June 26, 2011 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-24 07:42:22 |