I think we should clarify some aspects of the response when multiple
changes to the same resource have occurred:
1) for a given resource, only one sync-response is returned, regardless
of how many state changes (e.g. created --> modified --> deleted -->
recreated) it has gone through. The status reflects the latest state of
the resource at the time of the query (but see 2)).
2) if a resource has been created, then modified since the last sync,
the server MUST return '201 Created'.
3) if a resource has been deleted then recreated since the last sync,
the server MUST return '201 Created' (cf open issue No 6).
Of course, the above points reflect my interpretation of the spec. I may
be wrong, but that would be just another justification for clarifying
the desired behavior.
Finally, there is a race condition where some resources are
created/modified/deleted and a report issued at the exact same time.
Depending on how the sync token is implemented on the server side, it
might be hard to avoid having those resource being returned twice (in 2
Hence, I think it is worth mentioning that:
"Under some rare circumstances, the server may return the same
sync-response (i.e. refering to the same resource and with the same
status) in response to 2 consecutive sync-collection report requests.
The client can easily detect such duplicate by asking for the getetag
property and comparing it with a previously stored value."