Share via

2.1.3.4.2.2 Content-Type, Content-Description, Content-Disposition Headers

  • Article

MIME writers SHOULD determine the primary value of the Content-Type header (2) for an attached file by using the following steps:

  1. Acquire the value of the PidTagAttachMimeTag property ([MS-OXCMSG] section 2.2.2.29). If this value is not available, MIME writers determine the value of the Content-Type header by mapping it from the file extension (which is determined from the attachment file name, as specified in section 2.1.3.4.2.1), or by examining the file content itself. A MIME writer MAY<82> only generate the value of the PidTagAttachMimeTag property ([MS-OXCMSG] section 2.2.2.29) on inbound MIME messages and not provide the property value for an outbound MIME message. As a last resort, the MIME writer uses the value "application/octet-stream".

  2. If the value acquired in the previous step does not match requirements for MIME content-type, as specified in [RFC2045], or if the value represents any multipart MIME content-type, or if the value matches one of the following values, MIME writers replace it with "application/octet-stream":

    • application/applefile

    • application/mac-binhex40

    • message/rfc822

The value acquired as a result is then used as the value of the Content-Type header. MIME writers SHOULD also generate the name parameter for this header, by using the attachment file name (determined as specified in section 2.1.3.4.2.1) as a value.

MIME writers SHOULD<83> generate a Content-Description header by using the value of the PidTagDisplayName property ([MS-OXCFOLD] section 2.2.2.2.2.5). If the property has no value, an empty header can be generated. If any of the conditions specified in [RFC2047] section 1 apply, the value of the Content-Description header (2) SHOULD be encoded as specified in that document. A MIME writer MAY<84> skip any encoding of the non-ASCII characters in the Content-Description header and use the value of an attachment's PidTagDisplayName property ([MS-OXCFOLD] section 2.2.2.2.2.5) with no further encoding.

The value for the Content-Disposition header SHOULD<85> be generated based on whether the attachment is inline or not, as specified in section 2.1.3.4.1. For inline attachments, the value is "inline", and for non-inline attachments, the value is "attachment". MIME writers SHOULD generate the following parameters for this header:

  • filename: the attachment file name determined as specified in 2.1.3.4.2.1 is used as a value.

  • size: the value of the PidTagAttachSize property ([MS-OXCMSG] section 2.2.2.5) SHOULD be used as a parameter value. The size parameter SHOULD<86> be generated only if this property value is available and greater than 0 (zero).

  • creation-date: the value of the PidTagCreationTime property ([MS-OXCMSG] section 2.2.2.3) SHOULD<87> be used as the parameter value; if the property value is not available, the current time SHOULD be used. In either case, the creation time SHOULD<88> be converted from UTC to a local time zone of the MIME writer's choice and formatted as specified in [RFC2822].

  • modification-date: the value of the PidTagLastModificationTime property ([MS-OXCMSG] section 2.2.2.2) SHOULD<89> be used as the parameter value; if the property value is not available, the current time SHOULD be used. In either case, the modification time SHOULD<90> be converted from UTC to a local time zone of the MIME writer's choice and formatted as specified in [RFC2822].

  • When a MIME skeleton is present as described in section 2.1.3.5.1, a MIME writer MAY<91> copy the entire original value of the Content-Disposition header to the message instead of generating individual parameter values as described in the preceding points.