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

From: Cyrus Daboo <[email-masked]>
Date: Tue, 01 Jun 2010 10:07:24 -0400

Hi Simon,

--On May 31, 2010 4:24:32 PM -0400 Simon Perreault 
<[email-masked]> 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.
etc.

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

-- 
Cyrus Daboo