Subject: [ietf-caldav] some more typos in caldav access examples
From: Arnaud Quillaud <[email-masked]>
To: [email-masked]
Date: Thu, 05 Feb 2009 17:07:04 +0100
List-Id: Discussions on Calendar Access protocol based on WebDAV <ietf-caldav.osafoundation.org>

Still looking at: 
http://caldav.calconnect.org/caldavfiles/files/draft-desruisseaux-rfc4791bis.changes.html#examples

The event abcd2 is missing the following exception (which is returned in 
the calendar-query report).

BEGIN:VEVENT
DTSTAMP:20060206T001121Z
DTSTART;TZID=US/Eastern:20060106T140000
DURATION:PT1H
RECURRENCE-ID;TZID=US/Eastern:20060106T120000
SUMMARY:Event #2 bis bis
UID:[email-masked]
END:VEVENT

The event abcd3 is missing

X-ABC-GUID:[email-masked]

which is returned in the calendar query reports.

Looking at 
http://caldav.calconnect.org/caldavfiles/files/draft-desruisseaux-rfc4791bis.changes.html#rfc.section.7.8.1
For the second event, the

PRODID

is returned when it should not.

Looking at 
http://caldav.calconnect.org/caldavfiles/files/draft-desruisseaux-rfc4791bis.changes.html#rfc.section.7.8.3

the getetag property is returned when it was not asked for in the request.

Arnaud Q

Date: Thu, 05 Feb 2009 16:25:48 +0100
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [ietf-caldav] invalid TODO in CalDAV examples

Hello,

Looking at 
http://caldav.calconnect.org/caldavfiles/files/draft-desruisseaux-rfc4791bis.changes.html#examples

There are 2 todos (abcd4.ics and abcd5.ics) with an alarm containing:

TRIGGER;RELATED=START:-PT10M

but those 2 todos only have a DUE date, making them invalid icalendar 
components.
The TRIGGER should be:

TRIGGER;RELATED=END:-PT10M

This affects the output of the example at: 
http://caldav.calconnect.org/caldavfiles/files/draft-desruisseaux-rfc4791bis.changes.html#rfc.section.7.8.9

It also affects 
http://caldav.calconnect.org/caldavfiles/files/draft-desruisseaux-rfc4791bis.changes.html#rfc.section.7.8.5 
. In that case the DUE property is expressed as a DATETIME with tz 
(although not timezone component is provided) instead of DATE.

Arnaud Q

From: Helge Hess <[email-masked]>
To: CalDAV DevList <[email-masked]>
Date: Thu, 5 Feb 2009 15:09:40 +0100
Subject: Re: [ietf-caldav] X- props in organizer's copy

On 05.02.2009, at 14:41, Arnaud Quillaud wrote:
> Actually, the same could be said about regular properties: An  
> organizer
> may want to add an attachment to his copy of a meeting but may not  
> want
> to send it to the attendees.

VALARM is another component which should not be transmitted?

Instead of an attribute on each property, a single property listing  
the 'personal' properties might be more efficient? Eg:

   SCHEDULE-NO-PROPAGATE:X-MYCLIENT-EVENT-COLOR,X-MYCLIENT-EVENT-ID

BTW: this issue not only applies to scheduling, but also to shared  
calendars. Eg if I save an event to a shared calendar, I might not  
want to save 'my' alarm. Instead the client might want to keep that  
locally.

Greets,
   Helge
-- 
http://zideone.com/

Date: Thu, 05 Feb 2009 14:41:44 +0100
From: Arnaud Quillaud <[email-masked]>
Sender: [email-masked]
To: [email-masked]
Subject: [ietf-caldav] X- props in organizer's copy

Hello,

CalDAV clients often use X- props to persist proprietary information 
(e.g. "X-MYCLIENT-EVENT-COLOR:red", or 
"X-MYCLIENT-MEETING-CHAT-URL:xyz:abc").
Using the new scheduling model, it is now the server's responsibility to 
propagate or not propagate those X- props to attendees: propagating an 
event color property would not be appropriate while propagating a 
meeting chat url would be. In the meantime, it is impossible for a 
server to be aware of all X- props (existing and yet to come) and take 
the apppropriate action.

Should we define a boolean parameter indicating whether the organizer's 
client wishes to propagate a particular property (or component) to the 
attendee ? The default would be true.

Example:
X-MYCLIENT-EVENT-COLOR;SCHEDULE-PROPAGATE=FALSE:red
X-MYCLIENT-MEETING-CHAT-URL;SCHEDULE-PROPAGATE=TRUE:xyz:abc

Actually, the same could be said about regular properties: An organizer 
may want to add an attachment to his copy of a meeting but may not want 
to send it to the attendees.

Arnaud Q