MSDN > フォーラム ホーム > Using the Exchange Server Protocols > In ActiveSync, how is the XML for deleting a field meant to work for calendar exceptions when using protocol 12.1?
質問する質問する
 

回答済みIn ActiveSync, how is the XML for deleting a field meant to work for calendar exceptions when using protocol 12.1?

  • 2009年7月1日 13:43Jed Ecker ユーザーのメダルユーザーのメダルユーザーのメダルユーザーのメダルユーザーのメダル
     
    In this question I am specifically asking about the 12.1 protocol used by exchange 2007 rather than the 14.0 protocol that I believe is associated with exchange 2010.

    My company has an ActiveSync server product and we've recently ran into an issue with recurring events. When an exception to a recurring event is sent the Windows Mobile behavior is to only send fields that are different, so in this sense the exception seems to have "Ghosted" behavior for the fields already existing in the master. What this means is that when an exception is created on a WM device by deleting, for example, the location field, WM sends a tag as <Location></Location> or just <Location/> depending on how you convert the wbxml.

    What I am seeing in this case is that the iPhone and the Palm Pre both send no Location tag whenever the location field is deleted when sending an exception. The end result is that if either device creates an exception to a recurring event by completely deleting a field then the field that was completely deleted remains on the server. I've seen this directly against Exchange 2007 without the involvement of our server product.

    What I am asking here is for a confirmation that deleting a field in a calendar exception must be done for sending an empty XML tag. If this is the intended behavior for ActiveSync protocol we will attempt to contact these other companies to inform them of their bugs.

回答

  • 2009年8月3日 13:50Tom Jebo_DSCMSFT, モデレータユーザーのメダルユーザーのメダルユーザーのメダルユーザーのメダルユーザーのメダル
     回答済み

    Jed,

    I apologize for the delay in getting you a response on this. 

    You are correct, the iPhone & Pre probably have problems dealing with Exceptions.  Windows Mobile does this correctly.
     
    There is also indeed an issue with Exchange that is being addressed.  The issue has to do with Recurring Calendar Exceptions (as you've found) in that the server MUST be more explicit about the use of the empty tag to signal that the field has been deleted and is now empty, versus having its value be inherited from the series.  For example, today it's not possible for clients to differentiate whether an exception has no reminder or a reminder of 0min from the server's response. As you correctly pointed out, if the client is using the <Supported> tags and decides to "Ghost" some properties, then the client cannot ever edit the exception's ghosted properties which should inherit from the series.  (This would not change what the server sends to the client).

    Let me know if you have any other questions or need any clarification


    Regards, Tom Jebo Senior Support Escalation Engineer Microsoft DS Protocol Team

すべての返信

  • 2009年7月1日 13:48Hongwei Sun-MSFTMSFT, モデレータユーザーのメダルユーザーのメダルユーザーのメダルユーザーのメダルユーザーのメダル
     
    Hi, Jed,

       Thanks for your question.  One of our team memeber will work on it and get back to you soon.

    Thanks!
    Hongwei Sun -MSFT
  • 2009年7月13日 15:31Dominic Salemno MSFTMSFT, モデレータユーザーのメダルユーザーのメダルユーザーのメダルユーザーのメダルユーザーのメダル
     
    Jed,

    I am the engineer who has taken ownership of your case. I am currently investigating this issue and will have an answer for you shortly.

    Dominic Salemno
    Senior Support Escalation Engineer
  • 2009年8月3日 13:50Tom Jebo_DSCMSFT, モデレータユーザーのメダルユーザーのメダルユーザーのメダルユーザーのメダルユーザーのメダル
     回答済み

    Jed,

    I apologize for the delay in getting you a response on this. 

    You are correct, the iPhone & Pre probably have problems dealing with Exceptions.  Windows Mobile does this correctly.
     
    There is also indeed an issue with Exchange that is being addressed.  The issue has to do with Recurring Calendar Exceptions (as you've found) in that the server MUST be more explicit about the use of the empty tag to signal that the field has been deleted and is now empty, versus having its value be inherited from the series.  For example, today it's not possible for clients to differentiate whether an exception has no reminder or a reminder of 0min from the server's response. As you correctly pointed out, if the client is using the <Supported> tags and decides to "Ghost" some properties, then the client cannot ever edit the exception's ghosted properties which should inherit from the series.  (This would not change what the server sends to the client).

    Let me know if you have any other questions or need any clarification


    Regards, Tom Jebo Senior Support Escalation Engineer Microsoft DS Protocol Team
  • 2009年8月3日 14:21Jed Ecker ユーザーのメダルユーザーのメダルユーザーのメダルユーザーのメダルユーザーのメダル
     
    Thanks for your reply. We all get busy so don't feel too bad about taking a while. I'm just glad to know what the correct behavior is. Thanks again!