Share via

2.2.3.4.2.2 Application/Applefile

  • Article

This section specifies MIME analysis for MIME parts with a Content-Type header value of "application/applefile" that are not subparts of a MIME part with a Content-Type header value of "multipart/appledouble".

The procedure of MIME header analysis for attachments with a MIME content-type of "application/applefile" is the same as for the procedure for ordinary file attachments specified in section 2.2.3.4.1, with one exception: MIME readers set the value of the PidTagAttachMimeTag property ([MS-OXCMSG] section 2.2.2.29) to "application/applefile".

Processing of MIME message content SHOULD include parsing the AppleSingle structure, as specified in [RFC1740]. MIME readers SHOULD use the data from this structure to fill the PidTagAttachDataBinary property ([MS-OXCMSG] section 2.2.2.7) and the PidNameAttachmentMacInfo property ([MS-OXCMSG] section 2.2.2.29) with appropriate structures, as specified in section 2.2.3.4.2.1 and [MacBin].

If MIME body data does not match the definition of the AppleSingle structure, MIME readers can choose to try to interpret the body of this MIME part as a MacBinary structure. If this succeeds, MIME readers SHOULD copy the resulting MacBinary structure to the value of the PidTagAttachDataBinary property, and the PidNameAttachmentMacInfo property SHOULD be filled with appropriate data from the MacBinary structure. The value of the PidNameAttachmentMacInfo property SHOULD be "application/applefile" data that contains only the header and resource fork sections. But if the MIME reader fails to parse the MIME body, the entire message SHOULD<171> be rejected as not MIME compliant.

If the AppleSingle or MacBinary structure contains a file name for this attachment, it SHOULD<172> be used only if no file name was found during analysis of the attachment's MIME headers.

The remainder of this section specifies how MIME readers SHOULD<173> map elements from AppleSingle format, which can have a Content-Type header value of "multipart/appledouble" or "application/applefile", to MacBinary data in the value of the PidTagAttachDataBinary property.

The general structure of AppleSingle format is specified in [RFC1740]. In short, this data structure contains a header part, followed by some number of entries. Each of these entries is identified by a number (AppleSingleEntryId, unsigned 32-bit integer), which defines the internal structure of its binary data. The value of each AppleSingleEntryId, along with the definition of the structure of each entry, is specified by [RFC1740]. Custom entries are also allowed in this format.

The MacBinary structure consists of the following five parts; each part is padded to a 128-byte boundary, and all parts except the header are optional:<174>

  1. Header

  2. Additional header data

  3. Actual file data (data fork)

  4. Resource fork

  5. Comment

The structure of the MacBinary header, with comments on usage of each field by MIME readers, is shown in the following table. All offsets and lengths are in bytes, and all integers use big-endian byte ordering.

Field offset

Field length

Description

0

1

Old version number, MUST be zero.

1

1

Length of file name, unsigned byte; MUST be less than 64.

2

63

File name, in ASCII; characters beyond the length specified in byte 1 MUST be ignored.<175>

65

4

File type data, normally expressed as four characters.

69

4

File creator data, normally expressed as four characters.

73

1

Finder flags, bits 15:8.

74

1

Pad, MUST be 0 (zero).

75

2

Icon vertical location, unsigned 16-bit integer.

77

2

Icon horizontal location, unsigned 16-bit integer.

79

2

File's folder ID.

81

1

File protected flag, low order bit.

82

1

Pad, MUST be 0.

83

4

Data fork length, signed 32-bit integer, zero if there is no data fork.

87

4

Resource fork length, signed 32-bit integer, zero if there is no resource fork.

91

4

File creation date, signed 32-bit integer representing a number of seconds since (or before, if negative) midnight, 01/01/2000, UTC.

95

4

File modification date, signed 32-bit integer representing a number of seconds since (or before, if negative) midnight, 01/01/2000, UTC.

99

2

Comment length, unsigned 16-bit integer, MUST be 0 (zero).

101

1

Finder flags, bits 7:0.

102

4

Signature. MIME reader SHOULD<176> set this value to "mBIN" (%x6D.42.49.4E).

106

1

File name script identifier. MIME reader SHOULD set to 0 (zero).

107

1

Extended finder flags, MIME reader SHOULD set to 0 (zero).

108

12

Zero fill.

120

2

Secondary header length, MUST be 0 (zero).

122

1

MacBinary version number. MUST be set to 130 (0x82), indicating MacBinary III, when the MIME reader creates the MacBinary structure.

123

1

Minimum MacBinary version supported by this structure. MUST be set to 129 (0x81), indicating MacBinary II, when the MIME reader creates the MacBinary structure.

124

2

CRC of the previous 124 bytes. MIME readers SHOULD calculate this value by applying a CRC algorithm on the first 124 bytes of the header. The CRC algorithm used by MacBinary is the CCITT algorithm, which uses the polynomial 0x1021. For more information on CRC-CCITT, see [X25] section 2.2.7.4. ([X25] refers to the CRC algorithm as a "frame check sequence".)

Bytes 126:127

2

Zero fill.

When processing AppleSingle data, MIME readers MUST map AppleSingle fields to MacBinary fields as specified in the following table.

AppleSingleEntryId and type

MacBinary field

Comment

1, Data fork

Bytes 83:86 – length;

MacBinary data fork part

This mapping SHOULD only be used by MIME readers in MIME analysis of a standalone "application/applefile"; as specified in [RFC1740]), the data fork SHOULD be in a separate MIME part in "multipart/appledouble" case.

2, Resource fork

Bytes 87:90 – length;

MacBinary resource fork part

None.

3, ASCII string

Byte 1 – length,

Bytes 2:64 – ASCII string value (only length bytes used)

File name. Note that MacBinary limits this string to 63 bytes. Excess bytes MUST be truncated.

8, ASFileDates structure, create

Bytes 91:94

File creation date, MIME readers SHOULD map it for AppleSingle to MacBinary conversion.

8, ASFileDates structure, modify

Bytes 95:98

File modification date, MIME readers SHOULD map it for AppleSingle to MacBinary conversion.

8, ASFileDates structure,

access

None

MIME writers SHOULD set to 0 (zero) on conversion to AppleSingle.

8, ASFileDates structure,

backup

None

MIME writers SHOULD set to 0 (zero) on conversion to AppleSingle.

9, ASFinderInfo structure,

ioFlFndrInfo.fdType

Bytes 65:68

File type information.

9, ASFinderInfo structure,

ioFlFndrInfo.fdCreator

Bytes 69:72

File creator information.

9, ASFinderInfo structure,

ioFlFndrInfo.fdFlags

Byte 73 – bits 15:8

Byte 101 – bits 7:0

File finder flags word. MIME readers SHOULD map this element for AppleSingle to MacBinary conversion.

9, ASFinderInfo structure

ioFlFndrInfo.fdLocation.v

Bytes 75:76<177>

Icon vertical location. MIME readers SHOULD map this element for AppleSingle to MacBinary conversion.

9, ASFinderInfo structure,

ioFlFndrInfo.fdLocation.h

Bytes 77:78<178>

Icon horizontal location. MIME readers SHOULD map this element for AppleSingle to MacBinary conversion.

9, ASFinderInfo structure,

ioFlFndrInfo.fdFldr

Bytes 79:80

File folder ID. MIME readers SHOULD map this element for AppleSingle to MacBinary conversion.

9, ASFinderInfo structure,

ioFlXFndrInfo

None

MIME writers SHOULD fill with zeros on conversion to AppleSingle.

10, ASMacInfo structure,

filler

None

MIME writers SHOULD fill with zeros on conversion to AppleSingle.

10, ASMacInfo structure,

ioFlAttrib, bit 1

Byte 81, low order bit

Protected flag. MIME readers SHOULD map this element for AppleSingle to MacBinary conversion.<179>

Conversion from a full AppleSingle structure, found in a standalone "application/applefile" MIME element that is not a child of a MIME part whose MIME content-type is "multipart/appledouble", to a reduced AppleSingle structure that SHOULD be used as a child of "multipart/appledouble", is done simply by removing the entry with AppleSingleEntryId equal to 1 (the data fork) and adjusting the AppleSingle header accordingly.