Re: [VCARDDAV] CardDAV + xCard in query response

[Cyrus Daboo <[e-mail]>]

Hi Arnaud,

--On June 14, 2011 7:21:40 PM +0200 Arnaud Quillaud <[e-mail]> 
wrote:

> 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 
now).

-- 
Cyrus Daboo