10.2.1 Canonical Form

The MIME specification requires that every simple content type define a standard format, called the canonical form. The MIME specification recommends that data be converted to canonical form before the data is encoded or inserted into a message. The specification describes the canonical form of a few media types and outlines a process for registering new types. The Internet Assigned Numbers Authority publishes a list of assigned media types and maintains a repository of the data format descriptions for those types.

For text, the canonical form uses a carriage return (ASCII 13) followed by a line feed (ASCII 10) to indicate a line break. Typically, an application converts text to canonical form before including the text in a message.

For most other content types, the canonical form is identical to the normal format of the file. A good working strategy is to always convert text to canonical form and to assume that other data does not require conversion. We use this strategy in this manual. Be aware, though, that some file formats might have a canonical form different than the normal format of the data.

There is no canonical form for multipart content types. Instead, each part contained in a multipart body must be in canonical form.

10.2.2 Multipart Bodies

A MIME part body may contain nested MIME parts. In this case, each nested part contains its own set of headers and its own part body. The top-level part has the media type multipart.

The MIME specification defines four multipart subtypes. The MIME package also supports an additional multipart subtype, the multipart/related content type described in RFC 2387. All multipart types require that the header value contain a boundary parameter. The value of the boundary parameter delimits the parts of the message. For example, the message snippet below contains two parts delimited by __the_boundary__:

Content-Type: multipart/mixed; boundary="__the_boundary__" --__the_boundary__ This is the first part, in plain text. --__the_boundary__ Content-Type: text/plain; charset=us-ascii This is the second part, also in plain text but with a Content-Type header. --__the_boundary__--

Since the MIME format uses the value of the boundary parameter to tell where parts begin and end, it's important that the value does not occur in the content of any message part. This restriction includes parts which are themselves multiparts. In other words, if a message contains more than one multipart, each multipart in the message must use a different boundary. Otherwise, a recipient has no way to reconstruct the message accurately.

---

An RWMimeMultipart must not contain itself, either directly or indirectly. A part that contains itself cannot be represented as a string.

---

Table 2: MIME multipart subtypes

A Content-Type of multipart/mixed is typically used for email attachments, and is therefore the most common multipart type. A default-constructed R-WMimeMultipartType object represents a multipart/mixed header value.