In D5226#66984, @machniak wrote:

Maybe setting it to an empty string would work, but we're ignoring such values on our side (AXMLEntry::appendXML()), so we'd have to change how we handle empty strings. Maybe it was a problem for the original Syncroton authors implementation, but I think this change should be safe for us. So, I'd propose to try this first.

I don't think we should create contacts with an empty name, because it will be just as confusing.

Then I wonder whether there are other possibilities. Setting firstName does not look great. For example, would setting nickName work? Also, I think we should check if contact has name property (the Display Name) set and use it. Finally, if we use such special value, we might want to ignore it when a modified contact is sent back by the client.

I think we don't have to make it too complicated. A vCard should always have the FN property set (https://datatracker.ietf.org/doc/html/rfc6350#section-3.3), so this is really just a workaround for otherwise invalid vcards (altough I'm not entirely sure where the mapping form vcard to the structure happens, so I could be mistaken), and it works well enough (the name is rendered in both roundcube and outlook). We should probably also prevent that you can create contacts without an FN in the first place, but since we don't really have full control over clients this workaround may still make sense. I guess I can try 'nickName' too, but I'm not sure it makes a difference.
I wouldn't handle the special value anywhere, I don't think it's worth the extra complexity (and somebody might just want to name a contact with the magic value).

The motivation for the workaround is that Plesk is apparently running into this every now and then, and it just seems like a dangerous footgun that breaks the synchronization completely.

FN property is required, but can be empty.