Share via

2.2.3.4.2.1 Multipart/Appledouble

  • Article

A MIME element with a Content-Type header value of "multipart/appledouble", as specified in [RFC1740], has two child MIME elements. The "header part" has a Content-Type header value of "application/applefile"; the "data part" can have any MIME content-type except "application/applefile" or another multipart MIME content-type.

As a MIME reader copies data from a "multipart/appledouble" MIME entity to an Attachment object, it analyzes the three parts in the following sequence:

  1. The header part (typically the first child of "multipart/appledouble").

  2. The data part (typically the second child of "multipart/appledouble").

  3. The "multipart/appledouble" envelope itself.

Property values that are set as a result of MIME header analysis of a particular MIME part, as specified in section 2.2.3.4.1, overwrite property values that are set as a result of previous MIME part analysis.

The procedure of header analysis for any part of a "multipart/appledouble" MIME part is similar to the procedure for ordinary file attachments specified in section 2.2.3.4.1, with the following additions:

MIME readers set the value of the PidTagAttachMimeTag property ([MS-OXCMSG] section 2.2.2.29) to "multipart/appledouble".

MIME readers set the value of the PidTagAttachEncoding property to the following byte sequence (in hexadecimal): "%x2A.86.48.86.F7.14.03.0B.01".

MIME readers copy the value of the Content-Type header on the data part to the value of the PidNameAttachmentMacContentType property ([MS-OXCMSG] section 2.2.2.29).<167>

MIME readers SHOULD copy the entire MIME body of the header part to the value of the Attachment object's PidNameAttachmentMacInfo property ([MS-OXCMSG] section 2.2.2.29).<168> MIME readers SHOULD also parse this data and the MIME body from the data part to form a MacBinary structure, as specified in [RFC1740]. The resulting MacBinary structure SHOULD then be written to the Attachment object's PidTagAttachDataBinary property ([MS-OXCMSG] section 2.2.2.7).

MIME readers copy file creator and file type information taken from the MacBinary representation of the attachment to the value of the PidTagAttachAdditionalInformation property ([MS-OXCMSG] section 2.2.2.21), with special formatting as follows; the file creator and type fields are both unsigned 32-bit integers in big-endian format:

  • A single byte, value "0x3A" (colon character).

  • The file creator, encoded by the rule that follows.

  • A single byte, value "0x3A" (colon character).

  • The file type, encoded by the rule that follows.

  • A single byte, value "0x00".

Encoding is done from the highest-order byte to the lowest-order byte, by using the following scheme:

  • Single bytes with values for "\" (%x5C), ":" (%x3A), and ";" (%x3B) are replaced with two-byte sequences: "\\" (%x5C.5C), "\:" (%x5C.3A), and "\;" (%x5C.3B) respectively.

  • Single bytes with values less than 32, greater than 251, or equal to 127 are encoded by a backslash (%x5C), followed by the byte value in octal, padded with zeroes to 3 digits. So, for example, a "0x01" byte is encoded as "\001", and "0xFF" is encoded as "\377".

If parsing of the header part fails, MIME readers SHOULD<169> reject the entire message as not MIME compliant.

If the AppleSingle structure from the header part contains a file name for this attachment, it SHOULD<170> be used as the file name only if no file name was found during processing of the MIME headers.