none
Is there a default MIMESupport value? RRS feed

  • Question

  • Hi,

     

    I am reading through the documentation on the MIMESupport flag in ActiveSync version 12.1, but do not see mention of what default behavior to have when this optional value is not present.  We have a client that is sending 2 BodyPreference elements with different Type elements during a Sync with no MIMESupport flag and want to be sure we are not limited by a default value to the MIMESupported flag.  If there is no default value, should HTML or MIME be given preference when both are specified?

    References: MS-ASCMD - Section 2.2.3.94.3 - Revision 10.0

    MS-ASAIRS - Section 2.2.2.2 - Revision 10.0

     

    Sample client XML:

    <?xml version="1.0"?><!DOCTYPE AirSync PUBLIC "-//AIRSYNC//DTD AirSync//EN"
    "http://www.microsoft.com/"><Sync><Collections><Collection><SyncKey>6</SyncKey><CollectionId>InboxFolder</CollectionId><DeletesAsMoves/><GetChanges/><WindowSize>50</WindowSize><Options><Conflict>0</Conflict><FilterType>2</FilterType><Base.BodyPreference><Base.Type>2</Base.Type><Base.TruncationSize>20480</Base.TruncationSize></Base.BodyPreference><Base.BodyPreference><Base.Type>4</Base.Type></Base.BodyPreference></Options></Collection></Collections></Sync>

    Tuesday, October 11, 2011 1:31 PM

Answers

  • Hi cnogee,

    The default Exchange Server behavior if the MIMESupport element is not included is to treat it as being set to 0, "Never send MIME data".  If the MIMESupport element is missing, the expected behavior is that the BodyPreference element with Type = 4 is ignored, and you should get back HTML.

    The purpose of BodyPreference is not to request a specific body type.  Its purpose is to tell the server, "if you send me this type of body, use these settings".  The use of the MIMESupport tag tells the server that you happen to support and accept MIME.  That does not necessarily mean that you will get it (the server may return HTML instead).

    Exchange Server handles multiple BodyPreference elements by finding the one that matches the body type it plans on returning.  If MIMESupport is not present, it should not return a MIME body at all.

    Regards,
    Mark Miller
    Escalation Engineer
    US-CSS DSC PROTOCOL TEAM

    Monday, November 14, 2011 2:44 PM

All replies

  • Hi,

    Thank you for your question.  One of our engineers will follow up soon.

    Thanks,

    Edgar

    Tuesday, October 11, 2011 3:51 PM
    Moderator
  • Hi cnogee,

    I am investigating this issue and will follow up soon with an answer.

    Regards,
    Mark Miller
    Escalation Engineer
    US-CSS DSC PROTOCOL TEAM

    Wednesday, October 19, 2011 3:35 PM
  • Hi,

     

    Was wondering if you have any updates?

    Friday, October 21, 2011 1:23 PM
  • Hi cnogee,

     

    If I correctly understand your question, there is no “default” value for the MIMESupport element since it is Optional.  Refer to the schema for section 2.2.3.94.3 MIMESupport (Sync) Request, section 2.2.2.19.1 Request:

     

    <xs:element minOccurs="0" name="MIMESupport">

            <xs:simpleType>

                   <xs:restriction base="xs:unsignedByte">

                           <xs:minInclusive value="0" />

                           <xs:maxInclusive value="2" />

                   </xs:restriction>

            </xs:simpleType>

    </xs:element>

     

    Section 2.2.27  BodyPreference Request, “MUST NOT contain more than one BodyPreference element for each allowable value of the Type element.“  And, “The contents of the airsync:Options, itemoperations:Options, or search:Options element specify preferences for all of the content that the user is interested in searching, synchronizing, or retrieving.”

     

    And, per 2.2.2.22.4 Type (BodyPreference) “A command request or response MUST have a maximum of one Type element per BodyPreference element.”

     

    From section 2.2.2.19.1 Request:

     

    <xs:element minOccurs="0" maxOccurs="2" name="Options">

      <xs:element ref="airsyncbase:BodyPreference" minOccurs="0" maxOccurs="unbounded" />

     

    Per section 2.2.3.107.5 Options (Sync), “Because synchronization options are specified on a collection, the client can specify a unique airsyncbase:BodyPreference element value for each collection that it is being synchronized.”

     

    Therefore, what your client is sending appears to be invalid per protocol specification:

     

    <?xml version="1.0"?><!DOCTYPE AirSync PUBLIC "-//AIRSYNC//DTD AirSync//EN""http://www.microsoft.com/">

    <Sync>

    <Collections>

    <Collection>

    <SyncKey>6</SyncKey>

    <CollectionId>InboxFolder</CollectionId>

    <DeletesAsMoves/>

    <GetChanges/>

    <WindowSize>50</WindowSize>

    <Options>

    <Conflict>0</Conflict>

    <FilterType>2</FilterType>

    <Base.BodyPreference>

    <Base.Type>2</Base.Type>

    <Base.TruncationSize>20480</Base.TruncationSize>

    </Base.BodyPreference>

    <Base.BodyPreference>

    <Base.Type>4</Base.Type>

    </Base.BodyPreference>

    </Options>

    </Collection>

    </Collections>

    </Sync>

    Regards,
    Mark Miller
    Escalation Engineer
    US-CSS DSC PROTOCOL TEAM

    Friday, October 21, 2011 9:08 PM
  • Thank you for answering our question about MIMESupport.  We do believe from Section 2.2.27  BodyPreference you cited you are allowed to have more than 1 Body Preference element per Collection as long as the Type is different for each Body Preference.  You can also cite in Section 2.2.2.19.1 Request that the maxOccurs of BodyPreference are “unbounded”. In addition to this, we have network traces of WindowsMobile devices that show them requesting multiple body preferences. Given that the request appears valid, what is the correct server behavior when more than one BodyPreference is given, one BodyPreference with a Type of 4 the other a Type of 2, and there is no MIMESupport tag?

    Wednesday, October 26, 2011 1:45 PM
  • Any response to our new question?

    what is the correct server behavior when more than one BodyPreference is given, one BodyPreference with a Type of 4 the other a Type of 2, and there is no MIMESupport tag?

    Can the server decide which BodyPreference to use or is there still some rule on which to use?

    Thursday, November 3, 2011 3:56 PM
  • Hi cnogee,

    I'm investigating this and will follow up asap.

    Regards,
    Mark Miller
    Escalation Engineer
    US-CSS DSC PROTOCOL TEAM

    Thursday, November 3, 2011 4:12 PM
  • Was checking how a response was coming?
    Wednesday, November 9, 2011 3:53 PM
  • Hi cnogee,

    Thank you for your patience.  I am discussing this with our product group and will have an answer asap.  I see your point regarding the ambiguity and it is not made clear in the documentation, so we may also follow up with a change future documentation.

    Regards,
    Mark Miller
    Escalation Engineer
    US-CSS DSC PROTOCOL TEAM

    Thursday, November 10, 2011 6:53 PM
  • Hi cnogee,

    The default Exchange Server behavior if the MIMESupport element is not included is to treat it as being set to 0, "Never send MIME data".  If the MIMESupport element is missing, the expected behavior is that the BodyPreference element with Type = 4 is ignored, and you should get back HTML.

    The purpose of BodyPreference is not to request a specific body type.  Its purpose is to tell the server, "if you send me this type of body, use these settings".  The use of the MIMESupport tag tells the server that you happen to support and accept MIME.  That does not necessarily mean that you will get it (the server may return HTML instead).

    Exchange Server handles multiple BodyPreference elements by finding the one that matches the body type it plans on returning.  If MIMESupport is not present, it should not return a MIME body at all.

    Regards,
    Mark Miller
    Escalation Engineer
    US-CSS DSC PROTOCOL TEAM

    Monday, November 14, 2011 2:44 PM