[Evolution-users] No bidirectional synchronization using CardDAV

[Milan Crha]

On Fri, 2023-09-08 at 22:21 +0200, Matthias Kuntze wrote:
> Info: The support team of Garmtech said that their CardDAV
> communication works with Thunderbird so that no action would be done
> at the server side.

	Hi,
that's quite unfortunate, because when the server always returns ctag
as `1`, despite the content of the address book changed, then it's
clearly the server's fault. They should not pretend that the address
book collections support the `ctag`, ideally they should reject the
`getctag` requests. The CardDAV code is smart enough to try the
`getctag` only once and if it fails, then it'll not do it again (until
the process or the backend is restarted).

Maybe Thunderbird does not use the `getctag` and just updates always
everything. It's a plain waste of resources, not only on the wire, but
also the server resources, when the `getctag` support is available.

The `getctag` extension was originally developer for the CalDAV
collections, but the servers, if they support this extension, usually
support it also for the CardDAV. That's the reason why it's used also
for the CardDAV, not only for the CalDAV, collections.

The CardDAV backend (neither the CalDAV backend) in the evolution-data-
server does not allow to disable the `getctag` check. It trusts the
server that when it returns the `ctag`, it is a valid `ctag` and that
the server does manage it appropriately.

Try to convince them that a functional `getctag` extension for the
CardDAV is a good thing to have. They should prefer lower load of their
servers. The quick fix is to reject the `getctag` requests by the server.
	Bye,
	Milan