1. The client seems to give up in the middle of synchronisation session.
Synchronisation session is not terminated successfully, because client fails to send a new request (containing at least some status commands) after server has sent its data enclosed in a sync command as a response to client's sync command. The client gives a message that synchronization was interrupted and states that there was a problem in communication. There seems to be nothing wrong with server's response, however. This doesn't happen in all situations. However when it happens, the problem is reproducible. In other words, if new synchronisation is initiated again with the same data in both client ja server databases, the problem will reappear. A direct Internet connection is used, so there is neither WAP gateway nor any proxy in between. In attached files there is the data exchanged between client and server both in a successful and an unsuccessful case. The only difference between the two cases is that the unsuccessful case has one more calendar event in the server database.
2. The client does't send recurrency information during sync.
The client fails to send the RRULE vCalendar/vEvent property for recurring events, eventhough both the client and server states in their device info that they are capable of handling RRULE. This problem can be verified from files successful_slowsync_raw and successful_slowsync_xml. The only calendar event sent from client to server is a recurring event and set to occur every week. However that information is lost during the synchronisation because client doesn't send RRULE.