MIME messages

A MIME message consists of both data and metadata. MIME metadata consists of HTTP-style headers and MIME boundary delimiters.

MIME headers

Each header is a colon-separated name-value pair on a line. The ASCII sequence <CR><LF> terminates the line. A sequence of these headers, called a header block, is terminated by a blank line: <CR><LF><CR><LF>. Any headers that are in this HTTP style can appear in a MIME document. Some common MIME headers are described in MIME standard header fields.

Content-Type

The only header that must be present is the Content-Type header. This header specifies the type of the data in the message. If the Content-Type value starts with multipart, the message is a multipart MIME message. For multipart messages the Content-Type header must also include a boundary attribute that gives the text that is used to delimit the message parts. Each MIME part has its own Content-Type field that specifies the type of the data in the part. This can also be multipart, which allows multipart messages to be nested. MIME parts with any other Content-Type values are handled as BLOB data.

If a MIME document is sent over HTTP, the Content-Type header appears in the HTTP header block rather than in the MIME message body. For this reason, the integration node manages the value of the Content-Type header as the ContentType property in the Properties folder of the logical tree. This allows the MIME parser to obtain the Content-Type value for a MIME document that is received over HTTP. If you need to either create a new MIME tree or modify the value of the Content-Type, set the Content-Type value using the ContentType property in the MIME domain. If you set the Content-Type value directly in the MIME tree or HTTP tree, this value might be ignored or used inconsistently. The following ESQL is an example of how to set the integration node ContentType property:

SET OutputRoot.Properties.ContentType = 'text/plain';

Parsing

The MIME domain does not enforce the full MIME specification. Therefore, you can work with messages that might not be valid in other applications. For example, the MIME parser does not insist on a MIME-Version header. The MIME parser imposes the following constraints:

The MIME headers must be properly formatted:
- Each header is a colon-separated name-value pair, on a line of its own, terminated by the ASCII sequence <CR><LF>.
- The header line must use 7-bit ASCII.
- Semicolons are used to separate parameters:
```
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml
```
- A header might contain a comment in parentheses, for example:
```
MIME-Version: 1.0 (Generated by XYZ)
```
A line that starts with white space is treated as a continuation of the previous line. Therefore, a long header can be split across more than one line.
If two or more headers in a header block have the same name, their values are concatenated into a comma-separated list.
A top-level MIME Content-Type header must be available. The header is not case-sensitive. If the transport is HTTP, any Content-Type value in the HTTP header is used as the top-level Content-Type. If the transport is not HTTP, the Content-Type must appear in the initial header block of the MIME message.
The Content-Type value is a media type followed by the / character and a subtype. Examples of this are text/xml and multipart/related. The parser does not validate subtypes. The Content-Type value can be followed by one or more parameters that are separated by semicolons.
If the media type of a message is multipart, a boundary attribute must provide the text that is used to delimit the separate MIME parts.
Each individual MIME part can have its own Content-Type header. The part header can have a media type of multipart, so that multipart messages can be nested. In this case, a valid boundary attribute must be provided, and its value must be different from any that has been previously defined in the message. MIME parts that have any other Content-Type value are handled as BLOB data.
MIME multipart boundary delimiters are represented in 7-bit ASCII. The boundary delimiter consists of a line starting with a hyphen pair, followed by a boundary string. This sequence must not occur within the MIME message at any point other than as a boundary. A MIME end-delimiter is a hyphen pair, followed by the MIME boundary string, followed by a further hyphen pair. All delimiter lines must end in the ASCII sequence <CR><LF>. An example of a delimited message is:
```
--MIME_boundary
message data
--MIME_boundary
message data
--MIME_boundary--
```
where MIME_boundary is the boundary delimiter string, and message data represents message data.
The MIME media type message is not supported and results in an error at run time.
Any preamble data (text between the initial MIME header block and the first boundary delimiter) or epilogue data (text after the final boundary delimiter) is stored in the logical tree as a value-only element. Preamble data and epilogue data can appear only as the first and last children, respectively, of a Parts node.
The MIME parser does not support on-demand parsing and ignores the Parse Timing property. The parser does not validate MIME messages against a message model, and ignores the IBM® App Connect Enterprise Toolkit Validate property.

Special cases of multipart MIME

The MIME parser is intended primarily for use with multipart MIME messages. However, the parser also handles some special cases:

Multipart MIME with just one part. The logical tree for the MIME part saves the Content-Type and other information as usual, but the Data element for the attachment is empty.
Single-part MIME. For single-part MIME, the logical tree has no Parts child. The last child of the MIME tree is the Data element. The Data element is the parent of the BLOB that contains the message data.
MIME parts with no content.

Secure MIME (S/MIME)

S/MIME is a standard for sending secure email messages. S/MIME has an outer level Content-Type of multipart/signed with parameters protocol and micalg that define the algorithms that are used to encrypt the message. One or more MIME parts can have encoded content. These parts have Content-Type values such as application/pkcs7-signature and a Content-Transfer-Encoding of base64. The MIME domain does not attempt to interpret or verify whether the message is signed.