Incompatible RECURRENCE-ID not catched during validation (RFC5545 3.8.4.4)?

[pbiering]

(copy from skarim#197 - by accident chosen the wrong repo)

Hi,

original issue reported to Radicale: Kozea/Radicale#1966

ICS validator catches the problematic item, but vobject let it pass during PUT.

In the referenced item following occurs:

...
BEGIN:VEVENT
UID:4a409fc4-ec4d-472f-a013-e49a0ddf0eda
RECURRENCE-ID;VALUE=DATE:20251118
DTSTART;TZID=Europe/Paris:20251118T100000
...

BEGIN:VEVENT
UID:4a409fc4-ec4d-472f-a013-e49a0ddf0eda
RECURRENCE-ID;TZID=Europe/Paris:20251118T100000
DTSTART;TZID=Europe/Paris:20251124T100000
...

The first one is violating http://icalendar.org/iCalendar-RFC-5545/3-8-4-4-recurrence-id.html

Shouldn't this not be catched by vobject to avoid, that vobject-using software has to implement a post-vobject check for such issue.

Regards,
Peter

[da4089]

Looking at the events in the supplied file, I'm a bit confused what it's trying to do.

The first VEVENT creates the recurrence set, annually, 3rd Tuesday of November, for three years. And sets the time to 10:00am until 11:00am in the Paris timezone.

The second VEVENT has the same UID, so it's in the same sequence. The RECURRENCE-ID is a DATE (not a DATE-TIME), and that seems to be an error: it must specify the element of the recurrence set that it is overriding, since the first VEVENT uses a DATE-TIME for its DTSTART, this RECURRENCE-ID must use a DATE-TIME too. That appears to be an error from Thunderbird, assuming all the MOZ stuff comes from there.

The third VEVENT has the same UID, so it's also in the same sequence. Its RECURRENCE-ID matches the DTSTART of the first VEVENT: it is meant to replace the first element of the sequence, and it moves the time to 6 days later, and changes it to be two hours long (not one).

So it looks like something is pretty broken with whatever created this recurrence set.

Then the question is what should vObject do about that. The main issue is that overrides of a recurrence are recorded as distinct VEVENTs in a VCALENDAR. Validation will require a view across the entire calendar, not just one event, and matching up overrides with their base RRULE VEVENT (using the UID), and checking the RECURRENCE-ID has both a matching value type AND a value that matches one of the recurrences from the RRULE, the RDATEs, and not an EXDATE.

This seems like quite a bit of work. I don't recall any other validation in vObject that has this much scope.