none
MIME Raw data in EAS Sync Response

    Question

  • Hello,

    There are several places in the EAS protocol where raw MIME data goes back and forth.

    In the SendMail request, the Mime element is defined as containing the raw MIME message as a byte array, which translates into opaque binary data in WBXML.

    This makes sense since MIME messages may contain bodyparts with a Content-Transfer-Encoding:8bit and a mix of various non ascii charsets in a single message.

    On the other hand, the Data element in Sync or  responses, which may also contain raw MIME messages if the Type is set to 4, is defined as a String. This seems to be in contradiction with what is being used in the SendMail command.

    Actually, the specification indicates that the Data content should be b64 encoded if the type is 3 (RTF) but it does not say anything about the MIME Type.

    In other words, what would a server return in the Data elements of a sync response with type 4 and the following 2 messages

    Subject: message1
    From: joe@example.com
    Content-Type: text/plain; charset=ISO-8859-1;format=flowed
    Content-Transfer-Encoding: 8bit
    
    <some 8 bit iso-9959-1 characters here>

    and

    Subject: message2
    From: jane@example.com
    Content-Type: text/plain; charset=UTF-8;format=flowed
    Content-Transfer-Encoding: 8bit
    
    <some nasty UTF-8 characters here>

    ?

    The WBXML lets you choose 1 charset but its scope is the whole document. And actually, a single MIME message may contain multiple body parts with different charset.

    Thanks,

    Arnaud Quillaud

    Friday, September 13, 2013 12:16 PM

Answers

All replies

  • Hi Arnaud,

    Thanks for your questions.

    Someone from our team will get in touch with you shortly.

    Regards,


    SEBASTIAN CANEVARI - MSFT Escalation Engineer Protocol Documentation Team

    Friday, September 13, 2013 4:48 PM
  • Hi Arnaud, I am the engineer who will be working with you on this issue. I am currently researching the problem and will provide you with an update soon. Thank you for your patience.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Friday, September 13, 2013 7:24 PM
    Owner
  • Hello Josh,

    Any update on this ?

    Thursday, September 19, 2013 6:29 PM
  • Hi Arnaud, I am still looking into this issue. I hope to have more information for you soon. Your patience is greatly appreciated.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Monday, September 23, 2013 4:31 PM
    Owner
  • Hi Arnaud, the specifics about how various character encodings are handled is contained in the WAP Binary XML Content Format 1.2 specification. This is not a Microsoft Open Specification document and can be found on the W3C site here: http://www.w3.org/TR/wbxml/. I believe that the following 2 sections address your question and provide examples.

    Character Encoding
    http://www.w3.org/TR/wbxml/#_Toc443384896


    Encoding Examples
    http://www.w3.org/TR/wbxml/#_Toc443384925


    Please let me know if that helps you.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Tuesday, October 01, 2013 2:19 PM
    Owner
  • It does not answer my question unfortunately. I already mentioned in my initial question that WBXML lets you set the charset of the response.

    My point is that the WBXML charset can be specified only at the document level. But if a client is fetching multiple messages back, each message may contain a different character encoding. For example, a client may fetch 2 messages in a single Sync Request, one containing ISO-8859-1 8bit encoding, and another one containing Shift-JIS 8 bit encoding. In that case, if you set the WBXML charset to ISO-8859-1, the second message (containing Shift-JIS) will appear as garbled, and vice versa.

    Wednesday, October 02, 2013 4:14 PM
  • Hi Arnaud, looking back at your initial post. Can you ask your question as it relates to the protocol documentation and reference the sections that you believe are relevant? I tried to understand the scenario you described, but wasn't able to …

    According to MS-ASCMD section 2.2.3.39, the DATA element applies to the following commands:

    • ItemOperations
    • ResolveRecipients
    • Search

    Also, per MS-ASCMD section 2.2.3.170, the TYPE element applies to the following commands:

    • Autodiscover
    • FolderCreate
    • FolderSync
    • ResolveRecipients

    Finally, the MIME element (section 2.2.3.99) applies to:

    • SendMail
    • SmartForward
    • SmartReply.

    Since there does not appear to be any overlap between the 3 different elements that you are asking about I don't understand the scenario that you described.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team



    Thursday, October 03, 2013 4:02 PM
    Owner
  • I was talking about the Sync Response. In that context, there is a data element, and it is defined in MS-ASAIRS 2.2.10.1.

    And to give you a precise example, here is a sample exchange,  where a client does a fetch of 2 MIME messages, one in ISO-8859-1 and 8 bit transfer encoding, and another one with a Shift-JIS and 8 bit transfer encoding.

    Request:
    
    <airsync:Sync xmlns:airsync="AirSync:">
    <airsync:Collections>
    <airsync:Collection>
    <airsync:SyncKey>86400;1371162972;218485841232295;189;232</airsync:SyncKey>
    <airsync:CollectionId>xxx</airsync:CollectionId>
    <airsync:GetChanges>0</airsync:GetChanges>
    <airsync:Options>
    <airsync:FilterType>1</airsync:FilterType>
    <airsync:MIMESupport>2</airsync:MIMESupport>
    <airsyncbase:BodyPreference xmlns:airsyncbase="AirSyncBase:">
    <airsyncbase:Type>4</airsyncbase:Type>
    <airsyncbase:TruncationSize>32768</airsyncbase:TruncationSize>
    </airsyncbase:BodyPreference>
    </airsync:Options>
    <airsync:Commands>
    <airsync:Fetch>
    <airsync:ServerId>229</airsync:ServerId>
    </airsync:Fetch>
    <airsync:Fetch>
    <airsync:ServerId>230</airsync:ServerId>
    </airsync:Fetch>
    </airsync:Commands>
    </airsync:Collection>
    </airsync:Collections>
    </airsync:Sync>
    
    Response:
    
    <airsync:Sync xmlns:airsync="AirSync:">
    <airsync:Collections>
    <airsync:Collection>
    <airsync:SyncKey>86400;1371162972;218485841232295;189;232</airsync:SyncKey>
    <airsync:CollectionId>0;INBOX</airsync:CollectionId>
    <airsync:Status>1</airsync:Status>
    <airsync:Responses>
    <airsync:Fetch>
    <airsync:ServerId>229</airsync:ServerId>
    <airsync:Status>1</airsync:Status>
    <airsync:ApplicationData>
    <airsyncbase:Body xmlns:airsyncbase="AirSyncBase:">
    <airsyncbase:Type>4</airsyncbase:Type>
    <airsyncbase:Data>
    Date: Thu, 03 Oct 2013 15:36:10 +0200
    From: john &lt;john@example.com&gt;
    MIME-version: 1.0
    To: Joe &lt;joe@example.com&gt;
    Subject: trips
    Content-type: text/plain; charset=ISO-8859-1 format=flowed
    Content-transfer-encoding: 8bit
    
    Some ISO-8859-1 8bit data here
    </airsyncbase:Data>
    </airsyncbase:Body>
    <email:ContentClass xmlns:email="Email:">urn:content-classes:message</email:ContentClass>
    ...
    </airsync:ApplicationData>
    </airsync:Fetch>
    <airsync:Fetch>
    <airsync:ServerId>230</airsync:ServerId>
    <airsync:Status>1</airsync:Status>
    <airsync:ApplicationData>
    <airsyncbase:Body xmlns:airsyncbase="AirSyncBase:">
    <airsyncbase:Type>4</airsyncbase:Type>
    <airsyncbase:Data>
    Date: Thu, 03 Oct 2013 15:36:10 +0200
    From: john &lt;john@example.com&gt;
    MIME-version: 1.0
    To: Joe &lt;joe@example.com&gt;
    Subject: trips
    Content-type: text/plain; charset=Shift-JIS format=flowed
    Content-transfer-encoding: 8bit
    
    Some Shift-JIS 8bit data here
    </airsyncbase:Data>
    </airsyncbase:Body>
    <email:ContentClass xmlns:email="Email:">urn:content-classes:message</email:ContentClass>
    ...
    </airsync:ApplicationData>
    </airsync:Fetch>
    </airsync:Responses>
    </airsync:Collection>
    </airsync:Collections>
    </airsync:Sync>

    Friday, October 04, 2013 8:09 AM
  • Hi Arnaud, am I correct in assuming that you have an actual trace of the Sync request/response from your previous post? Can you share that with me? You can e-mail it to dochelp(at)microsoft(dot)com to my attention.

    Also, is the issue that the Data portion of the e-mail that is using the Shift-JIS encoding not correct? Does it appear to be more of a problem with the implementation of the protocol by the server that the client is talking to? If yes, what is the server type and version that you are receiving the response from?


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Friday, October 11, 2013 4:23 PM
    Owner
  • No, the issue is a generic protocol issue that has nothing to do with a particular implementation:

    You can not have an XML document using multiple charsets in their raw format (which is the case here since 8bit transfer encoding is used) as simple element values (strings) in different places of the document.

    Given how unlikely a change of the protocol is, I think your documentation should specify that 8bit content-transfer-encoding in MIME message is not supported, at least in the Data element of the Sync Response.

    Monday, October 14, 2013 11:57 AM
  • Hi Arnaud, thank you for providing clarification. I will share this information with the documentation team who will consider it for future addition to the documentation.


    Josh Curry (jcurry) | Escalation Engineer | Open Specifications Support Team

    Wednesday, October 16, 2013 8:51 PM
    Owner