Mobile phone Development Combat 97--MMS Introduction 4

MMS Editing and encapsulation

Edit

MMS creation Mode

· Registration: In this mode, the MMS client device should only be limited to creating and submitting MMS messages based on the content of the core mm contents domain.
· Warning: In this mode, the MMS client device should instruct the user to create and submit MMS messages that are limited to creating and submitting content based on the core mm contents domain.
· No limit: In this mode, MMS client should allow users to add any content to the MMS

Packaging

MMS Package (encapsulation)--mime

In order to be able to send multimedia messages via wireless technology, all parts of it must be packaged into a single piece of information. The method used is based on the MIME standard, which is currently used by most Internet e-mail communications. This also ensures that MMS and e-mail are compatible.

Encoding and values in the MMS header file

Content-type: The MMS header file contains a Content-type parameter that describes the MIME type of the MMS message.

The Content-type used are:

Application/vnd.wap.multipart.related This MIME type should be used when a SMIL presentation is included in a multimedia message. It is recommended that you include a "start" parameter in the MMS header file. It specifies the Content-id of the SMIL presentation. If you include the "start" parameter, you must also include the "type" parameter of Application/smil in the header file. If you omit "start" and subsequent "type" parameters, the SMIL presentation must be the first part of the body of the MMS message. Note: Write the "Start" and "type" parameter values without the quotation marks.

Application/vnd.wap.multipart.mixed This MIME type should be used when a SMIL presentation is not included in the body of the MMS message.

Application/vnd.wap.multipart.alternative This MIME type indicates that the multi-part contains an alternate content type. The phone will select the most supported MIME type. If more than one of the alternative types is supported, the last one is selected.

Some MMS header files are defined as "Encoded-string-value". The character set IANA mibenum values in these header files should be encoded as integer values (short integers or long integers). The character set Us-ascii (IANA Mibenum 3) should always be accepted. If you do not specify a character set (simple text-string encoding), then the character set is Us-ascii (the low part of ISO 8859-1). If the text string cannot be represented as US-ASCII, the character set should be encoded as UTF-8 (IANA Mibenum 106), which has a unique byte order.

In the MMS header file, the supported characters should be at least the characters in ISO 8859-1. Header files that are defined as text-string (Content-location, Message-id, and so on) should contain only us-ascii characters (the low portion of ISO 8859-1).

Encoding in the body of a multimedia message

Content-type: This is a "content type" description for a section of the MMS message body.

Application/smil; Charset= "Us-ascii" – this is the part of the SMIL presentation Content-type

Content-type example of the image/jpeg– image section.

The Content-type example of the text/plain– text section. The WSP multi-segment encoding should be used. The content type in the WSP multi-segment header file should be encoded with the WSP binary value whenever possible. If the WSP binary value is not available, the text encoding should be used.

content-location-This is the only reference for each part of the information. This format is useful for referencing. By using relative URL references, other parts of the information can refer to another content-location.

For example,

Content-id-This is the only Content-id for each part of the message. By using the "CID:" Reference, the presentation section can refer to another content-id. For example, , where "<xyzxyz>" is the Content-id of a section of the same piece of information (note that the parentheses are removed in the reference string). The Content-id does not have to be globally unique, and it does not require a valid address definition.

A Content-id or content-location can contain up to 100 characters. The character encoding for the WSP multi-segment header file (Content-id, content-location, and so on) should be US-ASCII (the low part of ISO 8859-1) because the character set in the partial header file

Code, there is no WSP-specific definition.

MMS MIME Type

Application/vnd.wap.mms-message

Application/vnd.wap.multipart-mixed

Application/vnd.wap.multipart-alternative

application/vnd.wap.multipart-related

Depending on the MMS encapsulation Protocol version 1.x and the MMS conformance specification, the WSP multi-segment header file and the content type's assignment number, which is encoded using version 1.3 and lower, should be used.