Re: [VCARDDAV] vCard format and lack of interoperability

Barry Leiba <> Sat, 17 November 2012 00:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B7E621F8897 for <>; Fri, 16 Nov 2012 16:59:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.932
X-Spam-Status: No, score=-102.932 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KJSb2IrZ7N6g for <>; Fri, 16 Nov 2012 16:59:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5771021F8874 for <>; Fri, 16 Nov 2012 16:59:48 -0800 (PST)
Received: by with SMTP id y2so2761840lbk.31 for <>; Fri, 16 Nov 2012 16:59:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=B0IX+wfFLP8zfmuf9mehH8uApqWx6Lpa4MHHPTc+NGU=; b=vy561jid2TPdmg7zSU2tfLoY2IhF7dBeGT2o3hZj3I8gBR0kEVFxPxUwBKaE+I6xnQ hNzBfE7i8D5tgOlR9LKwDmGSu6qXXBssLHgyYHOZUyXWu+yOKe1b69ZAkv01pdsTqEZl EueVeKuZtuxXHX3C5ypml3tKsaGlhM8JF703QjVxfilWU6iquc79RklqUVEukFNXnHSH nQVNtuADmRjkCAuPcuxioAmXniN4P01gBlQYtU5mmpyqkRVvhzs0VmnCgeubvsZZ7oRd gCYRJforI58Y4jklbJpxx/OMc+9W6abWYKrQ0O2bUsJC/+j5gzrRn3JIUFbMmT/05/Yq U2hQ==
MIME-Version: 1.0
Received: by with SMTP id gj1mr5767309lab.49.1353113987258; Fri, 16 Nov 2012 16:59:47 -0800 (PST)
Received: by with HTTP; Fri, 16 Nov 2012 16:59:47 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Fri, 16 Nov 2012 19:59:47 -0500
X-Google-Sender-Auth: wy09jlHvPyWISG-MqMGdBaHzRlI
Message-ID: <>
From: Barry Leiba <>
To: Alessandro Rossini <>
Content-Type: text/plain; charset="ISO-8859-1"
Cc: CardDAV <>
Subject: Re: [VCARDDAV] vCard format and lack of interoperability
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF vcarddav wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 17 Nov 2012 00:59:49 -0000

> I performed an empirical study of the interoperability of the vCard format:
> This study shows that common contact information is often represented by grouped
> properties and non-standard properties. These properties are not interoperable and
> make the import/export of vCard files as well as the synchronisation via CardDAV
> unreliable.

Your analysis appears to have a major flaw: you're looking at
implementations that do not (yet) support the 4.0 standard, and are
noting that they do not support the 4.0 standard... and you're saying
that the standard has problems because the implementations don't
support it (or aren't using it properly).  Your empirical study is not
of interoperability, but of deployment.

As you've noted (with your own construction of a 4.0 vCard), most of
what you need is representable interoperably in vCard 4.0.  It's just
that the specification is fairly new (and, yes, it has its problems;
we will likely need a revision of the spec (but not of the version
number) to clarify some things and fix some errors), and support for
it isn't out there yet.  We expect that it will be.

As you've also noted, social networking extensions need to be added.
We've tried several times to get work on that started, and there are a
few of us here who would love to try again.  But we've gotten no
interest from the social networking service providers.  Twitter and
Facebook have both declined to work on it, for example.  *No one*
involved with providing social networking services has come forward to
work on a specification and/or to express interest in implementing any
specification that might be written.  That's why nothing's there.

Finally, the system is extensible.  If there are things that are
missing that you think are important, and you have some real hope that
those things would be implemented if they were defined, then come help
us write a definition and publish it.  (But remember that there does
need to be some reasonable evidence that it'll be implemented in order
for it to be of much use.)