Coming here from duplicate bug report #14945 I notice that both 
patches offered here might not consider the '__tags' (aka CardDAV 
categories) attribute/property correctly .

According to this
https://github.com/horde/turba/blob/master/lib/Driver.php#L1221
it seems that '__tags' should not be set to null before calling save() .

I see the dilemma with unwanted deletion of certain contact attributes 
via CardDAV. But from my point of view there are more users managing 
their contacts data through a client than via web frontend.
Maybe it is easier to offer a settings option for disallowing deletion 
through carddav ...

The proposed patch in comment #3 has got a big downside, as it will 
always delete values from all fields that cannot be set via CardDAV. 
For example, if you were to change a contact's first name via CardDAV 
with the patch from comment #3 applied, changing the name would 
inadvertently delete the values stored in the "Assistent's phone 
number" field (assistPhone), or carPhone, or may others. This would 
cause trouble on a shared calendar where one user uses Turba's web 
interface only and another uses CardDAV, at the very least. Like Jan 
pointed out, this could only work if all fields from Turba were 
exposed via CardDAV.

While allowing all fields to be exported and re-set via CardDAV is 
another story altogether, there is something that can be done with 
little effort: Keep values of non-CardDAV-exported fields unchanged 
(like is now) but allow other fields to be deleted.

So for the time being, I created a patch where only those fields can 
be deleted via CardDAV that are currently seen when using CardDAV. 
While this does not address the problem that CardDAV clients may be 
dropping attributes unknown to them and those attributes in turn 
disappear in Turba, it does, however, hinder CardDAV users from 
unwillingly deleting values they have never seen. The fact of not 
being able to delete _any_ value is a big problem on our site, as 
people cannot remove any outdated information from a contact via 
CardDAV as of now.

Of course, this proposed patch has a downside, too: Users might still 
be expecting to be able to see and alter information via CardDAV in 
any field they see via the web interface, and even with this patch, 
they still see only some of this information. If they "clean out" a 
contact via CardDAV, there might be more stuff remaining than they 
think.

Reading a bit more, it looks indeed as the exchanged vCard object 
represents the complete contacts object. (The same applies for 
iCalendar and events of course). That means that importing a vCard 
object should only use the available properties and delete any other 
properties from the server.

I still don't feel comfortable with that, because:
1) we would have to make sure to export *all* properties completely so 
that clients at least have a chance to not lose data when sending 
updates back to the server
2) I would expect that some clients simply won't re-export some 
unsupported properties leading to data loss when sending updates back

The same is of course true for Turba as the CardDAV server. We drop 
unsupported properties too. To fix this, we would have to store the 
complete vCard/iCalendar objects for every import. 
https://oxpedia.org/wiki/index.php?title=AppSuite:VCardMapping has 
some good algorithms as how to proceed with such an attempt.

TL;DR: this requires massive changes and restructuring in how Turba, 
Kronolith, and Nag work.

Unfortunately there is no safe way to delete individual attributes. 
There is no distinction whether a client intended to delete an 
attribute, or simply doesn't support it. Theoretically, a client (and 
a server too FWIW), should keep all attributes it doesn't understand 
unaltered. But I'm not sure if this is really the case in practice. 
Horde for example does *not* keep arbitrary attributes, as a server.

The logic seems sound to me, but assigning to Jan to look at 
eventually, since I'm not sure if there is ever a case where CardDav 
would send only changed attributes and not the entire object.

Proposed patch.
I don't know if this is the right way to clear attributes in contact 
in Horde, I don't found the right function to use, but this patch 
works for me. Tested with last SoGo.

After 2 years, I see this is still a problem, at least with SoGo connector.
Any insight into this issue?

Testing SOGo for thunderbird (CardDav client) I realized that if you 
try to delete a contact's attribute in Horde, you can't.

Example, if you have a contact with:
object_firstname: foo
object_homephone: 5551111
object_workphone: 5552222

And we delete the workphone.

SOGo connector sends a PUT without the workphone (deleted), like this:
BEGIN:VCARD
VERSION:3.0
PRODID:-//Inverse inc.//SOGo Connector 1.0//EN
UID:20130730134707.8L8VpqSPT9rDS3Bqcglzyg1@xxxxxxxxx
N:;foo
FN:foo
TEL;TYPE=home:5551111
X-MOZILLA-HTML:FALSE
END:VCARD

Horde ignores the missing workphone and does not delete it in the database.

Modifications to any attribute, including workphone works fine, but 
you can't delete any attribute (identity property types).

I think the code relevant for this is in turba/lib/Application.php 
line 791, where values are set in the contacts, but only for the ones 
passed in the PUT vcard:
===
foreach ($contact as $attribute => $value) {
     if ($attribute != '__key') {
         $existing_contact->setValue($attribute, $value);
     }
===

Question, is this behaviour intentional?
I suppose you could delete an attribute value setting the field blank:
TEL;TYPE=work:

But I am not really sure this should be the right method, if you PUT a 
full contact I think it should be all replaced.