3:40 a.m.
Hello Thomas!
I noticed that a monthly recurrence RRULE gets lost on the server.
Here's what's being sent:
BEGIN:VCALENDAR
VERSION:1.0
TZ:+00:00
DAYLIGHT:FALSE
BEGIN:VEVENT
LAST-MODIFIED:20110112T155221Z
DCREATED:20110112T155221Z
UID:20060416T203656Z-4272-727-1-241@gollum
SEQUENCE:3
CLASS:PUBLIC
TRANSP:0
SUMMARY:recurrence weekly, limited
DESCRIPTION:recurrs four times due its end date
DTSTART:20060406T170000Z
RRULE:W1 TH 20060427T170000Z
DTEND:20060406T173000Z
END:VEVENT
END:VCALENDAR
This comes back:
BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
SUMMARY:recurrence monthly\, 6th day\, limited
DESCRIPTION:recurrs three times on the 6th of each month
DTSTART:20060406T173000Z
DTEND:20060406T180000Z
CLASS:PUBLIC
DTSTAMP:20110112T154809Z
LAST-MODIFIED:20110112T154809Z
END:VEVENT
END:VCALENDAR
I know that Memotoo normally converts recurring events into local,
floating time, but even that is not happening here. Looks like the
parser cannot map the RRULE and therefore drops it before importing the
event into the server.
The Synthesis engine sends vCalendar 1.0 here because the server tells
it that this is the preferred format:
<Rx-Pref>
<CTType>text/x-vcalendar</CTType>
<VerCT>1.0</VerCT>
</Rx-Pref>
<Rx>
<CTType>text/calendar</CTType>
<VerCT>2.0</VerCT>
</Rx>
<Tx-Pref>
<CTType>text/x-vcalendar</CTType>
<VerCT>1.0</VerCT>
</Tx-Pref>
<Tx>
<CTType>text/calendar</CTType>
<VerCT>2.0</VerCT>
</Tx>
Can this be changed so that text/calendar is preferred when talking to
SyncEvolution?
We can force this on the client side (type = calendar:text/calendar!),
but this is just a workaround and users with existing configurations
would have to change this manually.
iCalendar 2.0 is the right way to go forward, although in this monthly
recurrence case it doesn't help:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.17//EN
BEGIN:VEVENT
LAST-MODIFIED:20110112T161053Z
DTSTAMP:20110112T161100Z
CLASS:PUBLIC
SUMMARY:recurrence monthly\, 6th day\, limited
DESCRIPTION:recurrs three times on the 6th of each month
DTSTART:20060406T173000Z
RRULE:FREQ=MONTHLY;INTERVAL=1;UNTIL=20060606T173000Z
DTEND:20060406T180000Z
END:VEVENT
END:VCALENDAR
Also doesn't work.
The CtCap for iCalendar 2.0 also seem to be incomplete. UID and
RECURRENCE-ID are not mentioned, nor are some others. Can you check
this?
In this case, the UID isn't sent by the Synthesis engine, in contrast to
the X- extensions for vCard. This puzzles me a bit, I need to check
that.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
7:03 p.m.
Hi Patrick
Ok I have add UID and RECCURENCE-ID in the CtCap.
Ok now the "Rx-Pref" and "Tx-Pref" are "text/calendar 2.0"
for Evolution.
I have no problem with the rules ... Each time I add one in Evolution,
the rule is added to Memotoo.
Are you sure ?
Thomas
Le 12/01/2011 17:40, Patrick Ohly a écrit :
Hello Thomas!
I noticed that a monthly recurrence RRULE gets lost on the server.
Here's what's being sent:
BEGIN:VCALENDAR
VERSION:1.0
TZ:+00:00
DAYLIGHT:FALSE
BEGIN:VEVENT
LAST-MODIFIED:20110112T155221Z
DCREATED:20110112T155221Z
UID:20060416T203656Z-4272-727-1-241@gollum
SEQUENCE:3
CLASS:PUBLIC
TRANSP:0
SUMMARY:recurrence weekly, limited
DESCRIPTION:recurrs four times due its end date
DTSTART:20060406T170000Z
RRULE:W1 TH 20060427T170000Z
DTEND:20060406T173000Z
END:VEVENT
END:VCALENDAR
This comes back:
BEGIN:VCALENDAR
VERSION:2.0
BEGIN:VEVENT
SUMMARY:recurrence monthly\, 6th day\, limited
DESCRIPTION:recurrs three times on the 6th of each month
DTSTART:20060406T173000Z
DTEND:20060406T180000Z
CLASS:PUBLIC
DTSTAMP:20110112T154809Z
LAST-MODIFIED:20110112T154809Z
END:VEVENT
END:VCALENDAR
I know that Memotoo normally converts recurring events into local,
floating time, but even that is not happening here. Looks like the
parser cannot map the RRULE and therefore drops it before importing the
event into the server.
The Synthesis engine sends vCalendar 1.0 here because the server tells
it that this is the preferred format:
<Rx-Pref>
<CTType>text/x-vcalendar</CTType>
<VerCT>1.0</VerCT>
</Rx-Pref>
<Rx>
<CTType>text/calendar</CTType>
<VerCT>2.0</VerCT>
</Rx>
<Tx-Pref>
<CTType>text/x-vcalendar</CTType>
<VerCT>1.0</VerCT>
</Tx-Pref>
<Tx>
<CTType>text/calendar</CTType>
<VerCT>2.0</VerCT>
</Tx>
Can this be changed so that text/calendar is preferred when talking to
SyncEvolution?
We can force this on the client side (type = calendar:text/calendar!),
but this is just a workaround and users with existing configurations
would have to change this manually.
iCalendar 2.0 is the right way to go forward, although in this monthly
recurrence case it doesn't help:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Synthesis AG//NONSGML SyncML Engine V3.4.0.17//EN
BEGIN:VEVENT
LAST-MODIFIED:20110112T161053Z
DTSTAMP:20110112T161100Z
CLASS:PUBLIC
SUMMARY:recurrence monthly\, 6th day\, limited
DESCRIPTION:recurrs three times on the 6th of each month
DTSTART:20060406T173000Z
RRULE:FREQ=MONTHLY;INTERVAL=1;UNTIL=20060606T173000Z
DTEND:20060406T180000Z
END:VEVENT
END:VCALENDAR
Also doesn't work.
The CtCap for iCalendar 2.0 also seem to be incomplete. UID and
RECURRENCE-ID are not mentioned, nor are some others. Can you check
this?
In this case, the UID isn't sent by the Synthesis engine, in contrast to
the X- extensions for vCard. This puzzles me a bit, I need to check
that.
1:40 a.m.
On Mi, 2011-01-19 at 08:03 +0000, Thomas Pequet wrote:
Hi Patrick
Ok I have add UID and RECCURENCE-ID in the CtCap.
Ok now the "Rx-Pref" and "Tx-Pref" are "text/calendar 2.0"
for Evolution.
I have no problem with the rules ... Each time I add one in Evolution,
the rule is added to Memotoo.
Are you sure ?
I can no longer reproduce it either. I see that UTC time in my normal
test cases is converted to local, floating time, but that is expected
given that MemoToo does not store time zone information.
After adapting my MemoToo test cases for that I was down to one
difference. It seems that when you added RECURRENCE-ID support, you did
it like that:
* add EXDATE to recurring VEVENT
* leave RECURRENCE-ID in the exception VEVENT
* *but* UID is not preserved (replaced with something that looks
like a sequential number, which is not necessarily globally
unique)
As a result, after syncing to a second client, the "remove whole
meeting" functionality does not work on that client. It is also not
possible to handle meeting updates received via email (ITIP), because
the UID specified in the email does not match the synchronized calendar.
Adding the EXDATE is probably a good idea for dumb clients, but wouldn't
be necessary when sticking to iCalendar 2.0. Is there a chance to keep
the UID as it is?
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
8:31 p.m.
Sorry Patrick, I have tried to find a solution to keep the UID with the
second client but I have not found it ...
Thomas
Le 19/01/2011 15:40, Patrick Ohly a écrit :
On Mi, 2011-01-19 at 08:03 +0000, Thomas Pequet wrote:
> Hi Patrick
>
> Ok I have add UID and RECCURENCE-ID in the CtCap.
>
> Ok now the "Rx-Pref" and "Tx-Pref" are "text/calendar
2.0" for Evolution.
>
> I have no problem with the rules ... Each time I add one in Evolution,
> the rule is added to Memotoo.
> Are you sure ?
I can no longer reproduce it either. I see that UTC time in my normal
test cases is converted to local, floating time, but that is expected
given that MemoToo does not store time zone information.
After adapting my MemoToo test cases for that I was down to one
difference. It seems that when you added RECURRENCE-ID support, you did
it like that:
* add EXDATE to recurring VEVENT
* leave RECURRENCE-ID in the exception VEVENT
* *but* UID is not preserved (replaced with something that looks
like a sequential number, which is not necessarily globally
unique)
As a result, after syncing to a second client, the "remove whole
meeting" functionality does not work on that client. It is also not
possible to handle meeting updates received via email (ITIP), because
the UID specified in the email does not match the synchronized calendar.
Adding the EXDATE is probably a good idea for dumb clients, but wouldn't
be necessary when sticking to iCalendar 2.0. Is there a chance to keep
the UID as it is?
4255
days inactive
4267
days old
syncevolution@synevolution.org
3 comments
2 participants
participants (2)
-
Patrick Ohly -
Thomas Pequet