MimeContent vs Mime Content

Recently, I helped a customer with an issue where they were wondering if it was essential to set the ToRecipients, CcRecipients, and BccRecipients if they were setting the same values in the MimeContent property when doing a CreateItem call in Exchange Web Services. While trying to test out the scenarios, I thought “maybe it depends on the order of the elements in your <t:Message>. I soon realized that the order of the properties in the <t:Message> node seemed to matter. As it turns out, MessageType inherits from ItemType and MimeContent is defined on the ItemType where the recipient properties are defined on the MessageType and both of these are xs:sequence types. This means that their elements must appear in a specific order. Any deviation from the prescribed sequence results in a schema validation error returned from EWS. That meant that the MimeContent property itself always had to appear before the recipient properties since MimeContent is the first element described in the ItemType.

Here’s the schema for the ItemType and you can see that MimeContent is first.

<!-- Core contents of an item. -->
<xs:complexType name="ItemType">
    <xs:element name="MimeContent" type="t:MimeContentType" minOccurs="0" />
    <xs:element name="ItemId" type="t:ItemIdType" minOccurs="0" />
    <xs:element name="ParentFolderId" type="t:FolderIdType" minOccurs="0"/>
    <xs:element name="ItemClass" type="t:ItemClassType" minOccurs="0" />
    <xs:element name="Subject" type="xs:string" minOccurs="0" />
    <xs:element name="Sensitivity" type="t:SensitivityChoicesType" minOccurs="0" />
    <xs:element name="Body" type="t:BodyType" minOccurs="0" />
    <xs:element name="Attachments" type="t:NonEmptyArrayOfAttachmentsType" minOccurs="0" />
    <xs:element name="DateTimeReceived" type="xs:dateTime" minOccurs="0" />
    <xs:element name="Size" type="xs:int" minOccurs="0" />
    <xs:element name="Categories" type="t:ArrayOfStringsType" minOccurs="0" />
    <xs:element name="Importance" type="t:ImportanceChoicesType" minOccurs="0" />
    <xs:element name="InReplyTo" type="xs:string" minOccurs="0" />
    <xs:element name="IsSubmitted" type="xs:boolean" minOccurs="0" />
    <xs:element name="IsDraft" type="xs:boolean" minOccurs="0" />
    <xs:element name="IsFromMe" type="xs:boolean" minOccurs="0" />
    <xs:element name="IsResend" type="xs:boolean" minOccurs="0" />
    <xs:element name="IsUnmodified" type="xs:boolean" minOccurs="0" />
    <xs:element name="InternetMessageHeaders" type="t:NonEmptyArrayOfInternetHeadersType" minOccurs="0" />
    <xs:element name="DateTimeSent" type="xs:dateTime" minOccurs="0" />
    <xs:element name="DateTimeCreated" type="xs:dateTime" minOccurs="0" />
    <xs:element name="ResponseObjects" type="t:NonEmptyArrayOfResponseObjectsType" minOccurs="0" />
    <xs:element name="ReminderDueBy" type="xs:dateTime" minOccurs="0" />
    <xs:element name="ReminderIsSet" type="xs:boolean" minOccurs="0" />
    <xs:element name="ReminderMinutesBeforeStart" type="t:ReminderMinutesBeforeStartType" minOccurs="0" />
    <xs:element name="DisplayCc" type="xs:string" minOccurs="0" />
    <xs:element name="DisplayTo" type="xs:string" minOccurs="0" />
    <xs:element name="HasAttachments" type="xs:boolean" minOccurs="0"/>
    <xs:element name="ExtendedProperty" type="t:ExtendedPropertyType" minOccurs="0" maxOccurs="unbounded" />
    <xs:element name="Culture" type="xs:language" minOccurs="0"/>
    <xs:element name="EffectiveRights" type="t:EffectiveRightsType" minOccurs="0" />
    <xs:element name="LastModifiedName" type="xs:string" minOccurs="0" />
    <xs:element name="LastModifiedTime" type="xs:dateTime" minOccurs="0" />

That’s followed by the MessageType schema that is an extension of ItemType. This is where the recipient properties appear.

<!-- - - - - - - - - - - - - - - - - - - -->
<!--   Message type: derived from item   -->
<!-- - - - - - - - - - - - - - - - - - - -->
<xs:complexType name="MessageType">
    <xs:extension base="t:ItemType">
        <xs:element name="Sender" minOccurs="0" type="t:SingleRecipientType" />
        <xs:element name="ToRecipients" type="t:ArrayOfRecipientsType" minOccurs="0" />
        <xs:element name="CcRecipients" type="t:ArrayOfRecipientsType" minOccurs="0" />
        <xs:element name="BccRecipients" type="t:ArrayOfRecipientsType" minOccurs="0" />
        <xs:element name="IsReadReceiptRequested" type="xs:boolean" minOccurs="0" />
        <xs:element name="IsDeliveryReceiptRequested" type="xs:boolean" minOccurs="0" />
        <xs:element name="ConversationIndex" type="xs:base64Binary" minOccurs="0" />
        <xs:element name="ConversationTopic" type="xs:string" minOccurs="0" />
        <xs:element name="From" type="t:SingleRecipientType" minOccurs="0" />
        <xs:element name="InternetMessageId" type="xs:string" minOccurs="0" />
        <xs:element name="IsRead" type="xs:boolean" minOccurs="0" />
        <xs:element name="IsResponseRequested" type="xs:boolean" minOccurs="0" />
        <xs:element name="References" type="xs:string" minOccurs="0" />
        <xs:element name="ReplyTo" type="t:ArrayOfRecipientsType" minOccurs="0" />
        <xs:element name="ReceivedBy" type="t:SingleRecipientType" minOccurs="0" />
        <xs:element name="ReceivedRepresenting" type="t:SingleRecipientType" minOccurs="0" />

If you think about how the server will process this XML SOAP request, it will get the MimeContent first and then the first-class properties after that. So the server will build out its entire MIME message based on the content of the MimeContent property and then override those values with the first-class properties that follow. The same holds true for other properties like Body, Subject, etc.

After I figured all this out, I found this already clearly explained in Inside Microsoft Exchange Server 2007 Web Services explaining this same phenomenon when attempting to set the subject:

Well, during a CreateItem call, properties are processed on a first-come, first-served basis.  You first create an empty message, set the contents from the MIME, and then set the explicit subject. This really isn’t a problem in practice although it has some interesting implications. The schema mandates a specific ordering of elements within item instances. In other words, trying to put the subject before the MimeContent property results in a schema validation error. Therefore, which property overwrites which is dictated by the ordering as defined in the schema. (page 176)

They later go on to say the only time you’ll have a conflict is when you try to also set the same properties using the extended properties, so avoid doing that. There’s no need to set both the first-class property and it’s equivalent extended property.