Re: [VCARDDAV] CardDAV + xCard in query response

Cyrus Daboo <> Mon, 20 June 2011 16:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66A8D1F0C63 for <>; Mon, 20 Jun 2011 09:20:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Pgm0v66bjq7W for <>; Mon, 20 Jun 2011 09:20:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ECB931F0C5A for <>; Mon, 20 Jun 2011 09:20:36 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 472BBF9B6D4; Mon, 20 Jun 2011 12:20:36 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ErGFHG0VULuL; Mon, 20 Jun 2011 12:20:35 -0400 (EDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id 4AD76F9B6C9; Mon, 20 Jun 2011 12:20:33 -0400 (EDT)
Date: Mon, 20 Jun 2011 12:20:30 -0400
From: Cyrus Daboo <>
To: Arnaud Quillaud <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <>
X-Mailer: Mulberry/4.1.0a1 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; size="1952"
Subject: Re: [VCARDDAV] CardDAV + xCard in query response
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: Mon, 20 Jun 2011 16:20:40 -0000

Hi Arnaud,

--On June 14, 2011 7:21:40 PM +0200 Arnaud Quillaud <> 

> Actually the server can advertise support for xCard via the
> CARDDAV:supported-address-data property at which point it is in theory OK
> for the client to send that. Obviously the schema for the address-data
> element would need to be tweaked to allow "embedded" XML, and maybe we
> have a one page spec to do that (actually perhaps two pages as we should
> deal with this for CalDAV too).
> So, in other words, it is too late to integrate this change into the
> CardDAV spec itself (?...). I can give this one pager a try but is it OK
> to mix CardDAV and CalDAV ?

At this point I would rather not be making changes to CardDAV - its been 
stuck in the queue for over a year now, but now that the vcard specs are 
done it is really close to publication. I don't want to do anything that 
might delay that. So at this point I would prefer a separate spec that 
covers both CalDAV and CardDAV in an appropriate fashion.

That said, I worry that "embedding" xCard and xCal inside the address-data 
and calendar-data elements is going to be problematic. In particular the 
content needs to reproduce exactly what would be in the resource body, 
including the <?xml ...> element at the start. I think that pretty much 
requires always places xcard/xCal data inside CDATA[].

> The only other ambiguity in the spec that I faced while implementing
> CardDAV + xCard is the fact that the address-data requires a content-type
> and a version number (e.g.
> <C:address-data type='text/vcard' version='4.0'/>
> ) when xCard has no version number per say (versioning is provided
> through XML namespaces).

I think it is still OK to require the version attribute even for xCard. It 
may still be the case that a server only wants to support one version of 
the xCard schema and not another one (not that we have more than one right 

Cyrus Daboo