I think to get past such issues with providers like this, you first need to understand what it is and what it is not.<p>Forget the brochure, the ads and the nice tutorial, those are NOT CardDAV/SMTP/IMAP/... servers. What they are instead are ways to access their own proprietary special thing using standard protocols that your software and tools already supports, if you can't use the dedicated api.<p>It applies to pretty much every system for which Google has made their own thing, with their own api (contact api, mail api, ...), and then offer an alternate way to access their system by standard protocols.<p>And what this means is that the ruling system is the underlying one, the one which can be accessed in several ways, including that standard protocol. If their contact system discards the field "foobar" because it doesn't want it, then it doesn't matter if CardDAV says it should be kept.<p>Sure Google should totally make this clearer, and sure as an user I'm not a big fan, and yes I totally understand and agree with the "but as a result they break the standard, lose data and cause unexpected behavior and that's terrible", but from a purely engineering perspective it also makes total sense as to why those things happen this way, and is actually rather predictable.<p>You're feeding data to a special system that just so happens to have a CardDAV/SMTP/IMAP/... endpoint plugged on top of it. Of course that endpoint doesn't rule how the special system will behave.<p>And frankly any one who has had to build/support that kind of "api on top of an api" for some time has faced that sort of situation before.<p>In fact you don't need to go that far; I mean how many of your web applications take PUT or DELETE requests ? The HTTP protocol certainly says it should work and the http server you're using supports it. And let's not talk about all those sites that give a full page answer to a HEAD request.<p>PS: again, I am most definitely NOT saying I like that it works that way, I'm just saying ... "well no big surprise there".