In ActiveSync, how is the XML for deleting a field meant to work for calendar exceptions when using protocol 12.1?
- 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.
답변
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- 답변으로 표시됨Tom Jebo_DSCMSFT, 중재자2009년 8월 3일 월요일 오후 1:51
모든 응답
- 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 - 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 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- 답변으로 표시됨Tom Jebo_DSCMSFT, 중재자2009년 8월 3일 월요일 오후 1:51
- 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!

