Calendaring isn't something with which I'm very familiar so
I might be somewhat off base here, and I see that the draft
has been returned to the WG based on other reviews, so I'll
limit this to what seem like the most obvious security
things to address while doing further work on the spec.

- The handling of the 'Sync-token' seems underspecified, 
from a security perspective. I expected to see some
guidance as to uniqueness, randomness or unguessability so
that clients couldn't easily probe for things based on
guesses. 

- I don't understand why the 'Sync-token' needs to be a URI,
nor what processing might happen if e.g. an https URL were
used. (Might some proxies try to de-reference such URIs to 
reduce tracking or to try scan for badness?) I think it'd
be necessary to understand that to understand any security
or privacy issues that might arise.
  
- The security and privacy considerations text here seem
insufficient, overly generic and vague. RFC3986 also doesn't
seem like the best reference for (modern) URI security
considerations. Other than implying that a secure transport
is needed, (without really saying so), RFC5545 says that
privacy considerations are described elsewhere so referring
to that in section 9 also doesn't seem useful.