Re: [VCARDDAV] Last call comment: please add version parameter to Mime type

Cyrus Daboo <> Tue, 01 June 2010 14:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1E4C528C133 for <>; Tue, 1 Jun 2010 07:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2qIHkvrWsr+i for <>; Tue, 1 Jun 2010 07:07:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CB5E828C14A for <>; Tue, 1 Jun 2010 07:07:48 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 622AB16BB8E78; Tue, 1 Jun 2010 10:07:29 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7BftYbbzxzLG; Tue, 1 Jun 2010 10:07:28 -0400 (EDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id 8CC4C16BB8E6D; Tue, 1 Jun 2010 10:07:27 -0400 (EDT)
Date: Tue, 01 Jun 2010 10:07:24 -0400
From: Cyrus Daboo <>
To: Simon Perreault <>,
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="2443"
Subject: Re: [VCARDDAV] Last call comment: please add version parameter to Mime type
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF vcarddav wg mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 01 Jun 2010 14:07:52 -0000

Hi Simon,

--On May 31, 2010 4:24:32 PM -0400 Simon Perreault 
<> wrote:

>> Could we please add a "version" parameter to the text/vcard MIME
>> Content type? That would greatly help when trying to do content
>> negotiation in CardDAV. E.g. A server supporting both 3.0 and 4.0
>> vcard formats could allow clients to use the http Accept header to
>> request a particular version be returned by the server. This will
>> greatly aid in transitioning clients from 3.0 to 4.0.
> RFC2425 and 2426 specified text/directory while we specify text/vcard.
> Isn't this sufficient for content negotiation?

Actually in CardDAV we deliberately (after some list discussion) decided to 
require text/vcard for 3.0 vcards as well as 4.0. Given that we do need a 
way for the client to indicate its preferred version for data sent to it by 
a server that supports both 3.0 and 4.0. The HTTP Accept header is the 
proper way to do that, but we need the version indicated as part of that. 
Now it is possible to define arbitrary "tags" for Accept so we could simply 
invent our own version indicators, but it seems silly to do that if we can 
simply add the version parameter to the MIME type.

> As for future versions, I've heard that the world is moving toward XML...
> ;)

Yeah, so that raises a point about the XML spec: it does not define a MIME 
type for vcard-in-xml. The iCalendar-in-xml spec defines 
application/calendar+xml. I suggest we go with application/vcard+xml. You 
can probably quickly copy the template from the iCalendar-in-xml spec.

Once we have that MIME type for the XML representation, then content 
negotiation in CardDAV is trivial (given that the XML representation is 
only valid for 4.0).

>> That said it
>> would also be useful to have some recommendations on how to convert
>> between 3.0 and 4.0 formats.
> We created Appendix A exists exactly for this purpose. Could you be a bit
> more specific?

Appendix A is fine, but I was thinking about something with a lot more 
detail (and I am not suggesting that be part of our draft or even a new 
one). e.g. specific instructions on converting 3.0 -> 4.0:

1. Change the VERSION property from 3.0 to 4.0.
2. Change any TEL property values to URIs.
3. Remove CONTEXT and CHARSET parameters.
4. Remove MAILER property.

I'll probably end up putting together instructions like that when I code 
the converter for our server.

Cyrus Daboo