Share via

2.1.3.3.1 Client Actions

  • Article

To create a plain text message body in MIME format, clients SHOULD set the value of the PidTagBody property ([MS-OXCMSG] section 2.2.1.58.1). Additionally, clients SHOULD set the value of the PidTagInternetCodepage property ([MS-OXCMSG] section 2.2.1.58.6) to a code page that corresponds to the character set that the client wants to appear in the MIME message. If the client does not set the PidTagInternetCodepage property for a plain text message body, the server SHOULD default this property to "ISO-8859-15", but MAY<61> default this property to "ISO-8859-1". Clients SHOULD NOT create inline Attachment objects when the best body format of the Message object is plain text.

To create an HTML message body in MIME format, clients SHOULD set the value of the PidTagHtml property ([MS-OXCMSG] section 2.2.1.58.9) to the HTML message text. When this property is set, clients MUST set the value of the PidTagInternetCodepage property ([MS-OXCMSG] section 2.2.1.58.6) to the code page of the HTML message text. Note that the PidTagHtml property is a PtypBinary property ([MS-OXCDATA] section 2.11.1), not a PtypString property. Clients can, instead, set the value of the PidTagRtfCompressed property ([MS-OXPROPS] section 2.942) to the body text in compressed RTF format, depending on the MIME writer that is used to convert this text to HTML format. Clients MUST NOT create HTML message text using Unicode characters (UTF-16LE scheme), and the value of the PidTagInternetCodepage property MUST NOT be set to "1200". The UTF-32 form and the UTF-16GE scheme are also not acceptable for this purpose; UTF-7 (code page 65000) and the UTF-8 form (code page 65001) are acceptable.

To create a multipart/related message body in MIME format with HTML body text and inline images, clients SHOULD set the value of the PidTagHtml property to the HTML message text. When this property is set, the value of the PidTagInternetCodepage property is set to the code page of the HTML message text. Clients supply a value for either the PidTagAttachContentId property ([MS-OXCMSG] section 2.2.2.29) or the PidTagAttachContentLocation property ([MS-OXCMSG] section 2.2.2.29) on related file attachments such as images; the PidTagAttachContentId property SHOULD be chosen for this purpose. Depending on the choice of attachment property, inline image links in the HTML body MUST use one of the following:

  1. The "cid:" Uniform Resource Identifier (URI) scheme and a unique content identifier that matches the value of the PidTagAttachContentId property on the corresponding Attachment object.

  2. A copy of the value of the PidTagAttachContentLocation property on the corresponding Attachment object.

Instead of setting the value of the PidTagHtml property, clients can set the value of the PidTagRtfCompressed property and include Object Linking and Embedding (OLE) attachments, depending on the server, to convert the RTF text to HTML and the static renderings of the OLE attachments to image attachments. For details, see section 2.1.3.3.7.

For plain text messages, clients SHOULD write the value of the PidTagBody property in Unicode characters and SHOULD set the value of the PidTagInternetCodepage property to the code page that matches the sender's preferred character set. When generating a MIME element for the plain text body, MIME writers map this code page to a character set name, convert the Unicode text into that character set, and write that character set name to the value of the character set parameter of the Content-Type header. The plain text MIME element generated for a TNEF message SHOULD be treated in the same way.

For HTML messages, clients SHOULD write the value of the PidTagHtml property by using text in the sender's preferred character set. Clients set the value of the PidTagInternetCodepage property to the code page that corresponds to the preferred character set. Clients MUST NOT use UTF-16 form (code page 1200) as the preferred character set. If the HTML document contains a content-type meta tag, its charset parameter value SHOULD match the preferred character set.

When generating a MIME element or elements for an HTML message body, MIME writers map the value of the PidTagInternetCodepage property to a character set name, write the MIME element body in that character set, and write that character set name as the value of the Content-Type header's charset parameter, as specified in section 5.1 of [RFC2045]. If the HTML document contains a content-type meta tag, its charset parameter value SHOULD match the Content-Type header's character set parameter value.

For RTF messages, clients SHOULD write the value of the PidTagRtfCompressed property by using text in the sender's preferred character set. Clients SHOULD set the value of the PidTagInternetCodepage property to the code page that corresponds to the preferred character set. The preferred character set MUST NOT be the UTF-16 form (code page 1200). MIME writers MUST NOT rely on the value of the PidTagInternetCodepage property but treat it as a preference; MIME writers SHOULD instead rely on the value of one or more \ansicpg control words in the RTF stream (2), as described in [MSFT-RTF], to determine the actual body code page.

When generating a MIME element or elements for an RTF message body, MIME writers SHOULD convert the RTF text to plain text or HTML. MIME writers MAY<62> instead generate a TNEF attachment that contains the RTF body. MIME writers also SHOULD map the body code page to a character set name, SHOULD write the MIME element body in that character set, and SHOULD write that character set name as the value of the Content-Type header's charset parameter.

Even if a Message object has no body, clients SHOULD set the value of the PidTagInternetCodepage property to indicate a preferred character set for header text, to be used in encoding as specified in [RFC2047].

When generating headers for a MIME entity, it can be necessary to encode the characters as specified in [RFC2047]. MIME writers SHOULD use the same character set for all headers and the message body. MIME writers MAY<63> re-encode the message body with the same character set as the MIME message headers. MIME writers MAY<64> preserve the character set of the original MIME message body. If a different character set is supplied for different body types, MIME writers MAY<65> identify the body format that can generate the others and apply its character set to all body formats. Attachments that are themselves messages are independent and can have a different character set.