none
Synchronising a change in the ConversationId property via ActiveSync RRS feed

  • Question

  • We are working in implementing ActiveSync 14 in our own server.

    So far we have been unable to convince any ActiveSync client (iOS Mail.app, Outlook iOS) to change the ConversationId property for an email item once the item has arrived on the client (mail item X is synced with conversation id Y and later on the server re-computes the conversation id to Z).

    At this point we are wondering if it's at all possible for a mail item's ConversationId property to be changed through the normal sync mechanism (the one that is used when syncing the read/unread or flagged state). The spec says the client must be prevented from changing the ConversationId but it doesn't say that the server should or should not change it (MS-ASEMAIL 2.2.2.21).

    Is the ConversationId attribute considered immutable in ActiveSync?

    Friday, May 3, 2019 12:18 PM

All replies

  • CristianDr,

    Thank you for your question.  An engineer will contact you soon.


    Bryan S. Burgin Senior Escalation Engineer Microsoft Protocol Open Specifications Team

    Friday, May 3, 2019 6:28 PM
    Moderator
  • Hi Cristian,

    Thanks for the question about the ConversationId attribute in Sync responses. Since we may need to have you share some traces and/or other data to help us investigate this question, would you mind sending email to dochelp at microsoft dot com, referencing the URL for this thread and my name?

    Are you saying that the iOS clients (Mail and Outlook) are not respecting the new values for ConversationId after re-Sync'ing an item from your server? This sounds like a scenario that shouldn't happen. Let me know if this logic makes sense to you: 

    1. new email item is received and stored on the server as unique item id aaa.

    2. based on subject and other information, ConversationId xxx is computed and added to unique item id aaa's properties.

    3. client syncs item aaa and sees ConversationId xxx.

    4. a reply is sent, changing for example the subject. Server stores this new unique item, with id bbb. Then the server computes a new ConversationId yyy based on the subject change and adds it to bbb's properties.

    5. client now syncs *all* items from server. 

    Result:

    Email item aaa should still have ConversationId xxx.

    Email item bbb should have ConversationId yyy.

    There doesn't seem to be a scenario where email item aaa will return anything but xxx in subsequent Sync responses. 

    Please correct me if I've misunderstood your scenario. 

    Best regards,
    Tom Jebo
    Sr Escalation Engineer
    Microsoft Open Specifications

    Friday, May 3, 2019 10:18 PM
    Moderator
  • Hello Tom and thank you for your answer

    I will send traces by email in a couple of days.

    As to the scenario that poses problems for us you said:
    "There doesn't seem to be a scenario where email item aaa will return anything but xxx in subsequent Sync responses."

    That's exactly where our problem lies.
    In our server implementation item "aaa" initially has no ConversationId.
    Later on the ConversationId gets computed. We can't control _when_ the ActiveSync client syncs so if it syncs "aaa" without ConversationId later on it should update the value to "xxx" if that is reported by the server as part of a Change set. This does not seem to happen.

    We have lots of existing mail data without ConversationId (previous version that has no support for conversations) and we planned to do an asynchronous calculation of ConversationIds to prevent an offline migration.
    This would mean that, at least while the server is computing stuff, ConversationIds are initially not reported and updated later on.

    If the ConversationId is immutable (once item "aaa" has ConversationId "xxx" this ConversationId can never be updated to something else) we have to find some sort of workaround.

    Thanks again and best regards,
    Cristian Draghici
    Axigen Messaging

    • Edited by CristianDr Saturday, May 4, 2019 2:47 PM
    Saturday, May 4, 2019 3:18 AM