Multimedia Messaging Service (MMS) Media Format and Codecs ... · C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs 1 PREFACE 2 3 4 5 6 7 This document defines content types, media

3GPP2 C.S0045-A

Version 1.0

Date: 31 March 2006

Multimedia Messaging Service (MMS) Media Format and Codecs for cdma2000 Spread Spectrum Systems

COPYRIGHT

3GPP2 and its Organizational Partners claim copyright in this document and individual Organizational Partners may copyright and issue documents or standards publications in individual Organizational Partner’s name based on this document. Requests for reproduction of this document should be directed to the 3GPP2 Secretariat at [email protected]. Requests to reproduce individual Organizational Partner’s documents should be directed to that Organizational Partner. See www.3gpp2.org for more information.

1

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

PREFACE 1

2 3

4 5 6 7

This document defines content types, media formats and codecs for the non-real time Multimedia Messaging Service (MMS) per [1].

NOTE: cdma2000® is the trademark for the technical nomenclature for certain specifications and standards of the Organizational Partners (OPs) of 3GPP2. Geographically (and as of the date of publication), cdma2000® is a registered trademark of the Telecommunications Industry Association (TIA-USA) in the United States.

2 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

NOTES 1

2 3 4 5 6 7 8 9

10 11

12

13 14 15 16 17

18 19 20 21 22

23 24

25

1. The following verbal forms are used: “shall” and “shall not” identify requirements to be followed strictly to conform to the standard and from which no deviation is permitted. “Should” and “should not” indicate that one of several possibilities is recommended as particularly suitable, without mentioning or excluding others; that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited. “May” and “need not” indicate a course of action permissible within the limits of the standard. “Can” and “cannot” are used for statements of possibility and capability, whether material, physical, or causal.

2. Footnotes appear at various points in this specification to elaborate and to further clarify items discussed in the body of the specification.

3. Unless indicated otherwise, this document presents numbers in decimal form.

Binary numbers are distinguished in the text by the use of single quotation marks. In some tables, binary values may appear without single quotation marks if table notation clearly specifies that values are binary. The character ‘x’ is used to represent a bit of unspecified value. For example ‘xxx00010’ represents any 8-bit binary value such that the least significant five bits equal ‘00010’.

Hexadecimal numbers (base 16) are distinguished in the text by use of the form 0xh…h where h…h represents a string of hexadecimal digits. For example, 0x2fa1 represents a number whose binary value is ‘0010111110100001’ and whose decimal value is 12193. Note that the exact number of bits in the binary representation of a hexadecimal number strictly depends upon the implementation requirements for the variable being represented.

4. “Base station” refers to the functions performed on the fixed network, which are typically distributed among a cell, a sector of a cell, and a mobile communications switching center.

3 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

CONTENTS 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

NOTES..........................................................................................................................................................3

1 Introduction and Scope ........................................................................................................................6

2 References ...........................................................................................................................................7

3 Definitions and abbreviations .............................................................................................................10

3.1 Definitions ..................................................................................................................................10

3.2 Abbreviations .............................................................................................................................10

4 Media formats.....................................................................................................................................12

4.1 Text ............................................................................................................................................12

4.1.1 Text in SMIL ..........................................................................................................................13

4.1.2 Timed Text.............................................................................................................................13

4.2 Speech.......................................................................................................................................13

4.2.1 Narrow Band Speech ............................................................................................................13

4.2.2 Wide Band Speech................................................................................................................14

4.3 Audio..........................................................................................................................................14

4.4 Synthetic audio ..........................................................................................................................14

4.5 Still Image ..................................................................................................................................14

4.6 Bitmap graphics .........................................................................................................................15

4.7 Video..........................................................................................................................................15

4.8 Vector graphics..........................................................................................................................15

4.9 File Format for Dynamic Media..................................................................................................16

4.10 Media Synchronization and Presentation Format......................................................................16

A ANNEX A. MIME CONFORMANCE (Informative) .............................................................................18

A.1 Scope.........................................................................................................................................18

A.1.1 Applicability............................................................................................................................18

A.1.2 Purpose .................................................................................................................................18

A.1.3 Relation to SMIL....................................................................................................................19

A.2 MIME Type Rules ......................................................................................................................19

4 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

A.2.1 The text major type................................................................................................................20 1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

A.2.1.1 Receiving Text ..............................................................................................................20

A.2.1.2 Sending Text.................................................................................................................20

A.2.2 Non-text parts ........................................................................................................................20

A.2.2.1 Receiving non-text parts...............................................................................................20

A.2.2.2 Sending non-text parts..................................................................................................21

A.2.3 Content-disposition................................................................................................................21

A.2.3.1 Receiving content-disposition.......................................................................................21

A.2.3.2 Sending content-disposition .........................................................................................21

A.2.4 Multiparts ...............................................................................................................................21

A.2.4.1 Receiving multiparts .....................................................................................................21

A.2.4.2 Sending multiparts ........................................................................................................21

A.2.5 The “Message” Major Type ...................................................................................................22

A.2.5.1 Receiving Message Major Type ...................................................................................22

A.2.5.2 Sending Message Major Type......................................................................................22

5 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

1 Introduction and Scope 1

2 3 4 5

This document specifies the media types, formats and codecs for the MMS within the 3GPP2 system. The scope of the present document extends to codecs for speech, audio, video, still images, bitmap graphics, and other media in general, as well as scene description, multimedia integration and synchronization schemes.

6 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

2 References 1

2 3

4 5

6

7 8 9

10

11

12 13

14 15

16 17

18

19

20 21

22

23

24 25

26 27 28

The following documents contain provisions, which through reference in this text, constitute provisions of the present document.

• References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.

• For a specific reference, subsequent revisions do not apply.

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP2 document, a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1] 3GPP2 S.R0064: “Multimedia Messaging Service (MMS); Stage 1 Requirements".

[2] The Unicode Consortium: "The Unicode Standard", Version 4.0 (Reading, MA, Addison-Wesley, 2003. ISBN 0-321-18578-1), as amended by Unicode 4.0.1.

[3] ANSI INCITS 4-1986 (R2002): "Information Systems - Coded Character Sets - 7-Bit American National Standard Code for Information Interchange (7-Bit ASCII) ".

[4] ISO/IEC 8859-1:1998: "Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1".

[5] IETF RFC 2279: "UTF-8, a transformation format of ISO 10646".

[6] 3GPP TS 23.038: “Alphabets and language-specific information”.

[7] ITU-T Recommendation T.81 (09/92): "Information technology - Digital compression and coding of continuous-tone still images - Requirements and guidelines".

[8] "JPEG File Interchange Format", Version 1.02.

[9] ITU-T Recommendation H.263 (02/98): "Video coding for low bit rate communication".

[10] ISO/IEC 14496-2 (2004): "Information technology -- Coding of audio-visual objects -- Part 2: Visual".

[11] CompuServe Incorporated: "GIF Graphics Interchange Format: A Standard defining a mechanism for the storage and transmission of raster-based graphics information", Columbus, OH, USA, 1987.

7 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

1 2

3

4 5

6

[12] CompuServe Incorporated: "Graphics Interchange Format (Version 89a)", Columbus, OH, USA.

[13] IETF RFC 2083: "PNG (Portable Networks Graphics) Specification Version 1.0".

[14] ISO/IEC 14496-3: 2001: "Information technology -- Coding of audio-visual objects -- Part 3: Audio".

[15] W3C: "Scalable Vector Graphics (SVG) 1.2 Specification", http://www.w3.org/TR/SVGMobile12 . 7

8 [16] W3C: "Mobile SVG Profiles: SVG Tiny and SVG Basic", http://www.w3.org/TR/SVGMobile . 9

10

11 12

13 14

15 16

17

[17] IETF RFC 2046: "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types".

[18] MIDI Manufacturers Association: "Scalable Polyphony MIDI Specification, RP-34", Los Angeles, CA, 2002.

[19] MIDI Manufacturers Association: "Scalable Polyphony MIDI Device 5-to-24 Note Profile for 3GPP, RP-35", Los Angeles, CA, 2002.

[20] MIDI Manufacturers Association: "Standard MIDI Files 1.0", RP-001, "The Complete MIDI 1.0 Detailed Specification, Document Version 96.1", Los Angeles, CA, February 1996.

[21] 3GPP TS 26.071: "AMR speech CODEC; General description".

[22] 3GPP2 C.S0050: "File Formats for Multimedia Services for cdma2000 Spread Spectrum Systems".

18 19

20 21

22

23

24 25

26 27

28 29

[23] 3GPP2 C.S0020: "High Rate Speech Service Option 17 for Wideband Spread Spectrum Communication Systems".

[24] Void

[25] IETF RFC 3676: "The Text/Plain Format and DelSp Parameters".

[26] IETF RFC 2045: “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies”.

[27] IETF RFC 2048: “Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures”.

[28] IETF RFC 2183: “Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field”.

8 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

1 [29] 3GPP2 X.S0016-200 “MMS Stage 2 Functional Description”.

[30] ITU-T Recommendation H.264 (2003): “Advanced video coding for generic audiovisual services” | ISO/IEC 14496-10:2003: “Information Technology – Coding of audio-visual objects – Part 10: Advanced Video Coding”.

2 3 4

5

6

7 8

9 10

11

12

13 14

15

16

[31] ISO/IEC 14496-3:2001/Amd.1.2003, Bandwidth Extensions.

[32] ISO/IEC 14496-3:2001/Amd.1.2003/COR1:2004.

[33] 3GPP2 C.S0052: “Source-Controlled Variable-Rate Multimode Wideband Speech Codec (VMR-WB) Service Option 62 and 63 for Spread Spectrum Systems”.

[34] 3GPP TS 26.171: “Speech Codec speech processing functions; AMR Wideband Speech Codec; General Description”.

[35] Void

[36] 3GPP TS 26.245 “3GPP Timed Text”.

[37] 3GPP2 C.S0014: “Enhanced Variable Rate Codec, Speech Service Option 3 for Wideband Spread Spectrum Digital Systems”.

[38] IETF RFC 4281, "The Codecs Parameter for 'Bucket' Media Types".

[39] IETF RFC 4393: “MIME Type Registrations for 3GPP2 Multimedia files“.

9 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

3 Definitions and abbreviations 1

3.1 Definitions 2

3 4

5 6 7

8 9

10 11 12

13

14 15

16 17

18 19

20 21

22 23 24

25 26

For the purposes of the present document, the following terms and definitions apply for these media elements:

codec: a system component that encodes and decodes data (usually audio, video, etc.) from one representation to another, often with the goal of saving memory space or transmission bandwidth (compression).

continuous media: media with an inherent notion of time. In the present document speech, audio, synthetic audio, and video are examples of continuous media.

discrete media: media that itself does not contain an element of time. In the present document text and still image are examples of discrete media. Note that timed text and bit map graphics can be continuous media also, depending on the presentation aspects.

dynamic media: same as continuous media

file format: an unambiguous method for storing data on a memory device (usually non-volatile).

media synchronization and media presentation: description of the spatial layout and temporal behavior of a presentation; it can also contain hyperlinks.

multimedia: a combination of multiple media elements used in a service to enrich the user experience.

natural media: media that occur naturally. In the present document, speech, audio, video and still image are examples of natural media.

synthetic media: media that are synthesized from algorithms and/or semantic descriptions. In the present document, bit map graphics, vector graphics and synthetic audio are examples of synthetic media.

user agent: the module on the terminal that performs MMS specific operations on a user’s behalf.

3.2 Abbreviations 27

28 For the purposes of the present document, the abbreviations given in the following apply:

10 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

3G third generation

3G2 file format for 3GPP2 multimedia services

3GPP 3rd Generation Partnership Project

3GPP2 3rd Generation Partnership Project 2

AAC Advanced Audio Coding

AMR Adaptive Multi-Rate

GIF Graphics Interchange Format

GSM Global Mobile System

HE AAC High Efficiency Advanced Audio Coding

IETF Internet Engineering Task Force

IP Internet Protocol

ISO International Standards Organization

ITU-T International Telecommunications Union - Telecommunications

JFIF JPEG File Interchange Format

JPEG Joint Photographic Experts Group

MIDI Musical Instrument Digital Interface

MIME Multipurpose Internet Mail Extensions

MM Multimedia Message

MMS Multimedia Messaging Service

MPEG Motion Picture Expert Group

OMA Open Mobile Alliance

RFC Request For Comment

RTP Realtime Transport Protocol

SMIL Synchronized Multimedia Integration Language

SP-MIDI Scalable Polyphony MIDI

SVG Scalable Vector Graphics

UTF-8 Unicode Transformation Format (the 8-bit form)

VMR-WB Variable Rate Multimode Wide Band

11 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

4 Media formats 1

2 3 4 5 6

7 8 9

10 11

12 13 14 15 16 17

18 19 20 21 22 23 24 25

26 27

Multiple media elements shall be combined into a composite single MM using MIME multipart format as defined in [17]. The media type of a single MM element shall be identified by its appropriate MIME type, whereas the media format shall be indicated by its appropriate MIME subtype. For creating an MM with the media elements described in [22], the MIME subtypes specified in [22] shall be used.

In order to guarantee minimum support and compatibility between multimedia messaging capable terminals, an MMS User Agent supporting specific media types shall comply with the following selection of media formats. Unrecognized subtypes of MIME types image, video, audio and application shall be treated as “application/octet-stream”; that is, the MMS User Agent shall treat unrecognized subtypes as attachments.

When an MM is composed of a “.3g2” file [22], the MIME type shall be indicated as specified in [39]. For the video/3gpp2 and audio/3gpp2 MIME types, the optional "Codecs" parameter as specified in [38] should be included. When the "Codecs" parameter is used, it shall contain all codecs indicated by the content present in the body part. The "Codecs" parameter shall not include any codecs which are not indicated by any media elements in the body part.

Note that support for media type narrowband speech is mandatory when present in the MM. By including the codec in the "Codecs" parameter, appropriate handling of this media type can be ensured. 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: Transcoding of messages in the network prior to delivery is described in [29], Section 7.1.3, “Retrieval of a Multimedia Message in the recipient MMSE”.

4.1 Text 28

29

30 31 32

33 34

The MMS User Agent shall support the media type “text” as follows:

• Shall use any character encoding (charset) that contains a subset of the logical characters in Unicode [2](e.g. US-ASCII [3], ISO-8859-1 [4], UTF-8 [5], GSM 7-bit default alphabet [6], Shift_JIS, etc.);

• Shall treat any unrecognized subtypes of "text" as subtype "plain" as long as the MMS Terminal MIME implementation knows how to handle the charset;

12 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

1 2

3

• Shall treat any other unrecognized subtypes of “text” and unrecognized charsets as "application/octet-stream".

An MMS User Agent should support "text/plain; format=flowed", as specified in [25].

4.1.1 Text in SMIL 4

5 6

7 8

9 10

The MMS terminal should support media type “Text in SMIL” which is intended to enable formatted text in a SMIL presentation. If text in SMIL is supported, the MMS terminal :

• Shall support a SMIL plus XHTML profile contained in 3GPP2 SMIL language profile [22] presentation and may ignore any unsupported XHTML modules in a SMIL document.

• Shall support rendering of a SMIL presentation where text is referenced with the SMIL 2.0 “text” element together with the SMIL 2.0 “src” attribute.

4.1.2 Timed Text 11

12 13

14

The MMS terminal should support the media type “Timed Text”. If timed text is supported the MMS terminal:

• Shall support 3GPP Timed Text [36].

4.2 Speech 15

16 There are two types of speech defined for MMS – NarrowBand (NB) and WideBand (WB).

4.2.1 Narrow Band Speech 17

18

19

20

21

22

23

The MMS terminal shall support the media type “NarrowBand speech”.

The MMS terminal shall support:

• EVRC [37];

and shall support one or both of the following speech codecs:

• 3GPP2 13K [23];

• AMR [21].

13 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

4.2.2 Wide Band Speech 1

2 3

4

5

The MMS terminal should support the media type “WideBand Speech”. If the MMS terminal supports WideBand Speech then it shall support:

VMR-WB [33] and shall use mode3 at 12.65 Kbps.

Note: VMR-WB mode 3 is interoperable with AMR-WB at 12.65 Kbps [34].

4.3 Audio 6

7 8

9

10

The MMS terminal should support the media type “audio”. If the media type “audio” is supported the MMS terminal:

• Should support MPEG-4 AAC Profile Level 2 [14], [31], [32];

• Should support MPEG-4 HE AAC Profile Level 3 [14], [31], [32].

4.4 Synthetic audio 11

12 13

14 15 16 17 18

19

The MMS terminal should support the media type “synthetic audio”. If the media type “synthetic audio” is supported the MMS terminal:

• Should support the Scalable Polyphony MIDI (SP-MIDI) content format defined in Scalable Polyphony MIDI Specification [18] and the device requirements defined in Scalable Polyphony MIDI Device 5-to-24 [19] (note Profile for 3GPP [19] SP-MIDI content is delivered in the structure specified in Standard MIDI Files 1.0 [20], either in format 0 or format 1);

• Should support general MIDI Level 1 with a minimum of 24 voices[20].

4.5 Still Image 20

21

22

23

24 25

The MMS terminal shall support the media type “still image” as follows:

• Shall support ISO/IEC JPEG [7] and JFIF [8].

• The support for ISO/IEC JPEG shall only apply to the following two modes:

• Shall support baseline DCT, non-differential, Huffman coding, as defined in table B.1, symbol 'SOF0' in [7];

14 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

1 2

• May support progressive DCT, non-differential, Huffman coding, as defined in table B.1, symbol 'SOF2' [7].

4.6 Bitmap graphics 3

4 5

6

7

8

The MMS terminal should support the media type “bitmap graphics”. If the media type “bitmap graphics” is supported the MMS terminal:

• Should support GIF87a [11];

• Should support GIF89a, [12];

• Should support PNG, [13].

4.7 Video 9

10 11

12

13

14

15

16

17 18

19

The MMS terminal should support the media type “video”. If the media type “video” is supported the MMS terminal:

• Shall support decoding of ITU-T Recommendation H.263 [9] profile 0 level 45;

• Shall support decoding of at least one of the following:

• MPEG-4 Visual Simple Profile Level 0b [10];

• H.264 Baseline Profile [30] Level 1b with constraint_set1_flag=1;

• Should support decoding of H.263 [9] Profile 3 Level 45;

• Video encoding is not specified. However, if the capabilities of the receiving terminal are not known, ITU-T Recommendation H.263 [9] profile 0 level 10 should be used.

Note that H.263 [9] profile 0 is contained in MPEG-4 Visual as the short header format.

4.8 Vector graphics 20

21 22

23

The MMS terminal should support the media type “vector graphics”. If the media type “2D vector graphics” is supported the MMS terminal:

• Shall support the “Tiny” profile for Scalable Vector Graphics (SVG-Tiny 1.2) [15] [16];

15 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

1 • Should support the "Basic" profile for Scalable Vector Graphics (SVG-BASIC) [15] [16].

4.9 File Format for Dynamic Media 2

3

4

5

6 7

8 9

10 11

12

13

14 15 16

17 18

19 20

21

The file format(s) for dynamic media supported by 3GPP2 MMS are specified in [22].

Support for specific file types are defined as follows.

• The “.3g2” file format shall be supported.

• For the “.3g2” file format, sample entries for mandatory codecs (as specified in this document) shall be supported.

• When 3GPP2 13K vocoder content is received in the MM as a .3g2 file, the MMS user agent shall support decoding of both MP4AudioSampleEntry and QCELPSampleEntry.

• When an MMS user agent creates an MM with 3GPP2 13K vocoder content and the MM is composed as a .3g2 file, the 13K vocoder content:

• Should be stored as MP4AudioSampleEntry, with OTI value of 0xE1;

• May be stored as QCELPSampleEntry.

• When any media is stored in the “.3g2” file format all other media types contained in the MMS message that have a sample entry defined in .3g2 file format shall also be stored in the “.3g2” file format.

• No file formats with a valid MIME type shall be prohibited unless specified in this document.

• MMS files should follow the guidelines recommended in Annex B section B.2 of [22] regarding file usage. MMS files of less than 30 seconds should not be fragmented.

Note: Some legacy MMS terminals may not support file fragmentation.

4.10 Media Synchronization and Presentation Format 22

23 24

An MMS User Agent shall support at least one of the media synchronization and presentation mechanisms described in [22] for rendering messages with multiple media elements. Specifically, the synchronization and presentation for messages with multiple media elements shall be one of:

25 26

27 • 3GPP2 SMIL, as described in [22];

16 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

1

2 3 4

5

• Compact Multimedia Format CMF as described in [22].

An MMS User Agent may include a synchronization and presentation mechanism in messages it generates. If such an element is included, it shall use one of the above mechanisms as described in [22].

17 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

A ANNEX A. MIME CONFORMANCE (Informative)

18 3GPP2

1

A.1 Scope 2

3 4 5 6

7 8

9 10 11

The bulk of this annex is simply reiterating basic MIME processing rules from the IETF MIME RFC documents. They are merely collected and simply stated here. None of the rules are changed. If this text conflicts with any of the MIME documents, this annex should be considered incorrect and the MIME documents correct.

These rules apply in MMS regardless of whether the syntax and encoding are IETF MIME or WAP WSP or other.

The rules given here do not impose any syntax or encoding which is different from the IETF MIME RFCs and their syntax, or the WAP/OMA WSP syntax and encoding of MIME structure.

A.1.1 Applicability 12

13 14 15 16

17 18 19 20

21 22 23

24 25

The rules described here are the most basic rules for sending and receiving MMS messages. These rules underlie, apply to and are imposed upon all other content in MMS. They underlie SMIL structured messages. They underlie messages regardless of the codec, character set, or text format.

The rules described here apply specifically to the sending and receiving of MMS messages by the handset on the MM1 interface. In the rules section below, the rules for receiving describe what the handset client must be able to receive. The rules for sending describe what the handset client should send.

These rules work with the WSP encoding of MIME structures as described in the WSP standard. The rules also apply if another syntax or encoding is used. For example, if IMAP is used to transfer message parts one at a time, the rules still apply.

This section describes some content formats for simple text messages and attachments because these are fundamental defaults for handling unknown content.

A.1.2 Purpose 26

27 28 29

30 31 32

33 34

These rules establish the basic framework for structuring MMS messages. They address the fundamental text type, the unknown attachment type, the “multipart” type for structuring and the “message” type. The purposes for establishing these rules are as follows.

First, these rules guarantee interoperability. If different MMS clients deviate from or implement these rules differently there will be interoperability problems between MMS clients and servers and between MMS clients.

To give a specific example, there is no explicit requirement in another document that a handset be able to process a simple text/plain message. There is also no prohibition against

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

1 2

3 4 5 6

7 8 9

10

11 12 13 14 15 16

17 18 19 20 21 22 23 24

25 26 27 28 29

sending such a message. Thus two conforming implementations could fail to interoperate on a simple level.

These rules are the same as the rules for Internet email and thus following them provides increased interoperability with the Internet in general. This interoperability is important in the short term when there are fewer MMS handsets as it will give the user of MMS handsets many more users to exchange messages with.

Second, these rules are important to facilitate upgrading to more advanced content as MMS progresses. They allow for graceful handling of content types that are not understood or handled by the client. These rules are the same ones that allow progression to more advanced content in Internet email.

To some degree defaulting rules that facilitate handling of unknown content types are less important in MMS than in Internet email because the MMSC may transform content to suit the handset’s capabilities. The server can transform any newly invented content types into older types (at some loss). However, for the server to do this effectively and minimize loss in transformation there must be some basic, clearly defined defaults that the server can count on.

A good example of the use of these defaulting rules is the use of the types text/x-vcard and text/x-vcal. Both of these types represent data that could be processed better and more automatically if it is recognized as contact and calendar information. For example the contents can be automatically inserted into the contacts database or the calendar. However since they are registered as text subtypes, the text defaulting rule applies. Users with handsets that don’t support the contact or calendar information are shown the plain text contact or calendar information and have the opportunity to enter it into their contact database or calendar manually.

In these examples, the user with a handset that can process vcard and vcal automatically gets the benefit of the new format. The user without the ability to automatically process still gets the information even though it is in a more primitive format. Without the text defaulting rules, users whose handsets do not recognize these types would likely be unable to view the information at all.

A.1.3 Relation to SMIL 30

31 32 33

The rules described here fully support the multipart/related formatting of SMIL content. Multipart/related encoding of SMIL is a specific content type carried in MMS, and thus is beyond the scope of this document.

A.2 MIME Type Rules 34

35 36 37 38

39 40

A basic operating principle for MIME is that a handset should be liberal in what it can receive, and conservative in what it sends. Adhering to this principle greatly enhances interoperability. Thus this section describes what should be sent distinctly with what should be accepted when receiving.

19 3GPP2

Another fundamental rule is that unknown content should never be completely ignored. Its presence should be indicated to the user. This is based on the principle that it is proper to

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

1 2 3 4

inform the user if some content arrived that could not be displayed so the user can take appropriate action. This action might be requesting the sender to resend it in a different form, or perhaps purchasing a new handset that can display the content. These rules are elaborated in the following sections.

A.2.1 The text major type 5

A.2.1.1 Receiving Text 6

7 8

9 10 11 12

The handset must be able to display message parts of type “text/plain”. Note that “text/plain; format=flowed” (as specified in [25]) can be especially beneficial on handsets.

The type “text/html” should be recognized and displayed in some manner, even if it is just stripping the HTML formatting. This is because there are very large amounts of HTML content in the world and some might end up on a handset. If it does, treating it as “text/plain” will generally be unacceptable for the end user.

A.2.1.2 Sending Text 13

14 15 16

When sending messages that consist solely of text, they should be a single “text/plain” part without any additional structure. (e.g., SMIL is not required). Generating “text/plain; format=flowed” [25] is recommended.

A.2.2 Non-text parts 17

18 19

This section addresses message parts that are not for the purpose of structuring and not text. For example, these include image, video, audio and application parts.

A.2.2.1 Receiving non-text parts 20

21 22 23

24 25 26

27 28

29 30

The handset should accept and be able to ignore any parts that it cannot display or process. It should not reject the message or fail to display those parts of the message that it can display.

The handset should display the presence and relative details about parts even if it cannot fully display the part. For example it may display the content type, and if available the filename and size.

The handset should allow parts that cannot be displayed to be saved as attachments if the handset can save any parts as attachments.

The handset should allow parts that cannot be displayed to be forwarded, if the handset supports message forwarding.

20 3GPP2

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

A.2.2.2 Sending non-text parts

21 3GPP2

1

2 Nothing is imposed when sending non-text parts

A.2.3 Content-disposition 3

4 5 6

The “Content-Disposition” header can be added to any MIME entity to indicate whether it is an attachment or it is to be displayed inline. It can also carry a file name. It especially applies to “text”, “image”, “video” and “audio” types.

A.2.3.1 Receiving content-disposition 7

8 9

10 11

If a part is marked as “inline” it should be displayed fully as part of the message after any inline parts preceding it and before any inline parts following it.

If a part is marked as “attachment”, an icon, text or other indication of its presence should be displayed with the message.

A.2.3.2 Sending content-disposition 12

13 14 15

If a part of a message was composed in such a way that it should be presented with other parts of the message as the message is viewed it should have a “Content-Disposition” header with the value “inline”.

A.2.4 Multiparts 16

A.2.4.1 Receiving multiparts 17

18

19

20

21 22 23

The handset should support receiving the “mixed” sub-type of “multipart”.

The handset should support receiving and processing nested multipart MIME entities.

Then handset should treat sub-types of multipart that are not recognized as multipart/mixed.

“Multipart/related” entities of types that are not understood should be treated as “multipart/mixed”. The “multipart/related” type as used with SMIL and HTML is addressed elsewhere.

A.2.4.2 Sending multiparts 24

25 No requirements for sending multiparts are imposed.

C.S0045-A v1.0 3GPP2 MMS Media Format and Codecs

22 3GPP2

A.2.5 The “Message” Major Type 1

A.2.5.1 Receiving Message Major Type 2

3

4 5

The handset should support the receipt and display of the type “message/rfc822”.

Any message sub-types that are not supported should be treated as “application/octet-stream”.

A.2.5.2 Sending Message Major Type 6

7 No requirements for sending major type message entities are imposed.