Subject: Re: [VCARDDAV] CardDAV + xCard in query response

From: Simon Perreault <[email-masked]>
Date: Mon, 13 Jun 2011 14:49:45 -0400

On 2011-05-27 19:57, Arnaud Quillaud wrote:
> http://tools.ietf.org/html/draft-ietf-vcarddav-carddav-10#section-10.4 ,
> the address-data corresponding to a REPORT response is defined as:
> 
>        <!ELEMENT address-data (#PCDATA)>
>        <!-- PCDATA value: address data -->
> 
> (and the same section contains two paragraph explaining how to deal with
> CDATA).
> 
> If I understand this definition correctly, this more or less prevents
> the use of xCard as the returned format.

Well, no matter what the schema says, the text itself prevents xCard
from being used. If I understand correctly, CardDAV specifies vCard 3,
mentions that v4 is compatible, and that's it. I guess we'll need a new
1-page RFC to specify xCard inside CardDAV...

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 13 Jun 2011 15:11:07 -0400

Hi Simon,

> 1-page RFC to specify xCard inside CardDAV...

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

-- 
Cyrus Daboo

---

From: Arnaud Quillaud <[email-masked]>
Date: Tue, 14 Jun 2011 19:21:40 +0200

On Mon, Jun 13, 2011 at 9:11 PM, Cyrus Daboo <[email-masked]> wrote:

> Hi Simon,
>
>
> --On June 13, 2011 2:49:45 PM -0400 Simon Perreault <
> [email-masked]> wrote:
>

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 ?

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

Arnaud Quillaud

>
> --
> Cyrus Daboo
>
>
> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 20 Jun 2011 12:20:30 -0400

Hi Arnaud,

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

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 20 Jun 2011 13:35:43 -0400

On 2011-06-20 12:20, Cyrus Daboo wrote:
> 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[].

If we end up doing that, I, for one, would consider it a huge failure.

Simon

---

From: Mike Douglass <[email-masked]>
Date: Mon, 20 Jun 2011 14:12:18 -0400

I had taken the approach that what is contained within the calendar-data 
element is the XML representation of an event, i.e

<calendar-data>
<icalendar>
...
</icalendar>
</calendar-data>

This is more in line with other protocols and allows the entire response 
to be parsed as a whole.

It does raise the issue of whether there is a resource body (there isn't 
in my case) and what representation it takes - is it an XML database 
manufacturing icalendar or an icalendar system manufacturing XML - or 
some other approach manufacturing both.

In essence I don't have a resource body to reproduce exactly...

On 06/20/2011 01:35 PM, Simon Perreault wrote:
>> resource body, including the<?xml ...>  element at the start. I think

-- 

Mike Douglass                           [email-masked]
Senior Systems Programmer
Communication&  Collaboration Technologies      518 276 6780(voice) 2809
(fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180

---

From: Cyrus Daboo <[email-masked]>
Date: Mon, 20 Jun 2011 14:27:10 -0400

Hi Mike,

> In essence I don't have a resource body to reproduce exactly...

I think what goes in address-data and calendar-data must match what would 
be returned in the body of a GET response on the corresponding URI. At 
least that was the original intent, but maybe for XML we have to change 
that.

-- 
Cyrus Daboo

---

From: Mike Douglass <[email-masked]>
Date: Mon, 20 Jun 2011 14:53:31 -0400

Ok - I see where that comes from - I think we do need to change.

On 06/20/2011 02:27 PM, Cyrus Daboo wrote:
> I think what goes in address-data and calendar-data must match what 
> would be returned in the body of a GET response on the corresponding 
> URI. At least that was the original intent, but maybe for XML we have 
> to change that.
>

--