Note that "text/x-vcard" is the correct mime type for vcard data. Maybe addressbook server expects text/vcard, which is erroneous but could probably be worked-around.

Something that could easily be added to solve this: http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-10#section-6.2.2

Note the example and the author of the spec...

Sorry I am not so familiar with web server/ carddav configuration. I don't know where to put the additional information in. So any hint which file to change would help a lot

Here the official answer from apple bugs:

02-Nov-2010 01:07:
Engineering has determined that this issue behaves as intended based on the following information:

The CardDAV spec requires use of the text/vcard MIME type being registered by the vCard 4.0 spec update (even when clients use vCard v3). It is the responsibility of CardDAV client to get that right. So this is a bug in the SoGo extension. The reasoning behind this is that x- subtype was never standardized and we want to promote use of a standard subtype in this new CardDAV standard.

Hope this helps ... So is there any workaround for me ?

Hi Tigono,

Regarding the Apple bug, you could answer them that their mime type has not been registered with the IANA (http://www.iana.org/assignments/media-types/text/) and that until it's done, they cannot pretend DAV clients to be "right" or "wrong" on that matter. I think they should at least be tolerant to the current practice of using "text/x-vcard" which is a de-factor standard (as compared to "formal") used by SOGo Connector and many other programs.
Besides, VCARD 4 and CardDAV may be drafts, but they are certainly not RFC.

Back to your original concern: yes we will add code that detects the supported mime types from addresbook servers and handle this properly. If not today, it will be in the next two weeks.

Cheers,

That's good news. Give me a hint when it is done. Then I can help testing it :-)

P.S: Regarding Apple I put the following answer to the bug report:

In my opinion its an apple bug, because:

There is no IANA registered MIME-type for v-card and until this is done apple cannot pretend DAV clients to be right or wrong! Furthermore VCARD4 and carddav are actually drafts (so where is the actual standard)! So a lot of clients using x-vcard ...

No response from Apple ...

Is there something concerning this bug where I could help? Weekend would be fine for me for testing a nightly build :-)

Deadlock for my problem because: The 2 weeks are over and apple send the following information yesterday:

Engineering has determined that this issue behaves as intended based on the following information:

Apple doesn't pretend DAV clients are wrong. The CalDAV specification says so, and we are implementing a CardDAV server, so we follow that specification. CardDAV clients—including Sogo, that might not be compliant—must do so also.

It's true that CardDAV is a draft, but that's how all IETF specifications work. In this case, it's already been approved for publication, and will not change prior to publication. If you have issues with the IETF process, the IETF is the proper place to raise those issues. IANA registration will follow, per the standards process.

We consider this issue closed. If you have any questions or concern regarding this issue, please update your report directly (http://bugreport.apple.com).

Thank you for taking the time to notify us of this issue.

also discussed here:
http://discussions.apple.com/thread.jspa?threadID=2628613

after some "lame hacking" (I am not a coder myself) I was able to make it work at least when one person uses ONLY Thunderbird or ONLY Address Book.app. I use Custom4 parameter in Thunderbird's Address Book for workaround. Only thing is that Thunderbird is not able to correctly discover that contact changed when you update it through Address Book.app but when you recreate remote Address Book in Thunderbird everything is ok. Here are additional changes that I made to SOGO_connector:

--- sync.addressbook.groupdav.js 2011-02-20 16:13:20.000000000 +0100
+++ sync.addressbook.groupdav.js.new 2011-02-20 16:13:42.000000000 +0100
@@ -981,7 +981,7 @@
// dump("upload new/updated card: " + cardURL + "\n");
this.remainingUploads++;
let request = new sogoWebDAV(cardURL, this, data);

• request.put(vcard, "text/x-vcard; charset=utf-8");
• request.put(vcard, "text/vcard; charset=utf-8");
  }
  else {
  dump("new vcard could not be generated for update\n");

--- vcards.utils.js 2011-02-20 16:13:14.000000000 +0100
+++ vcards.utils.js.new 2011-02-21 19:53:28.000000000 +0100
@@ -600,15 +600,22 @@
let vCard = ("BEGIN:VCARD\r\n"

• "VERSION:3.0\r\n"

• "PRODID:-//Inverse inc.//SOGo Connector 1.0//EN\r\n");

  • let uid = card.getProperty("CardUID", "");
  • let uid = card.getProperty("Custom4", "");
    if (!uid.length) {
    uid = card.getProperty("groupDavKey", "");
  • card.setProperty("Custom4", uid);
    card.setProperty("CardUID", uid);
    }
    if (!uid.length) {
    uid = new UUID();
  • card.setProperty("CardUID", uid);
  • card.setProperty("Custom4", uid);
  • card.setProperty("CardUID", uid);
  • }
  • let uid_dynamic = card.getProperty("CardUID", "");
  • if (!uid_dynamic.length) {
  • uid_dynamic = new UUID();
    }

  • vCard += foldedLine("X-ABUID:" + uid_dynamic + "\:ABPerson") + "\r\n";
    vCard += foldedLine("UID:" + uid) + "\r\n";

    let lastName = card.getProperty("LastName", "");
    @@ -693,7 +700,7 @@
    let value = ((preferMailFormat == 2)
    ? "TRUE"
    : "FALSE");

  • vCard += "X-MOZILLA-HTML:" + value + "\r\n";

  • // vCard += "X-MOZILLA-HTML:" + value + "\r\n";
    }

    let primaryEmail = card.getProperty("PrimaryEmail", "");
    @@ -732,7 +739,7 @@

    • "-" + escapedForCard(birthMonth)
    • "-" + escapedForCard(birthDay)) + "\r\n";

• for (let i = 1; i < 5; i++) {
• for (let i = 1; i < 4; i++) {
  let custom = card.getProperty("Custom" + i, "");
  if (custom.length)
  vCard += foldedLine("CUSTOM" + i + ":"

Thanks for the tip. My configuration is now the following:

• Thunderbird 3.1.9
• SoGo Connector Nightly Build 3.105pre3 from today
• Apple Addressbook Server on a Mac Mini Server

I changed only the "x-vcard" entry in line 984 into vcard (file: sync.addressbook.groupdav.js) and after that a lot of things are working.
Also between my carddav account on my iphone and thunderbird.

In principal the update mechanism is working in both directions. E.g. updating is working with the company field and telephone numbers defined on my iphone.

But there are fields that where not updated whatever I do. But the reason is that the iphone stores it in another way and sogo connector does not map it in a way that thunderbird can understand. Here an example:

Using the iphone to define an address with some fields the vcf-file on the server has the following form:
BEGIN:VCARD
VERSION:3.0
N:Dumm;Diedel;;;
FN:Dumm Diedel
ORG:Doesel;
EMAIL;type=INTERNET;type=HOME;type=pref:dede@ffff.com
TEL;type=CELL;type=pref:+49 163 777 4444
item1.ADR;type=HOME;type=pref:;;Trochfeld 4;Halle;;36277;Deutschland
item1.X-ABADR:de
NOTE:Ftetgg Dfgh
URL;type=WORK;type=pref:www.spiegel.de
UID:25B2905F-CE74-4100-AF85-43796D057F97
X-MOZILLA-HTML:FALSE
END:VCARD

After importing this into thunderbirds normal address book and writing it back to a vcf file it has the following form:
BEGIN:VCARD
VERSION:3.0
N;CHARSET=UTF-8:Dumm;Diedel
FN;CHARSET=UTF-8:Dumm Diedel
ORG;CHARSET=UTF-8:Doesel;
ADR;TYPE=HOME,POSTAL;CHARSET=UTF-8:;;Trochfeld 4;Halle;;36277;Deutschland
TEL;TYPE=CELL,VOICE:+49 163 777 4444
EMAIL;TYPE=PREF,INTERNET:dede@ffff.com
URL;TYPE=WORK:www.spiegel.de
NOTE;CHARSET=UTF-8:Ftetgg Dfgh
END:VCARD

So there is a difference (what says the standard? I am not familiar enough with the standard). After dragging it to the carddav addressbook everything is working well, because of the "right, thunderbird conform" format.

So first: SoGo Connector is great work, but how can this be handled?

Fixed. Code will be available in the next nightlies.

The only change concerns the mimetype. I see no use for the other patch above, but feel free to open another bug report if this really poses a problem (with a proper description then).