On Sat, 2011-01-22 at 14:18 -0500, Adam Tauno Williams wrote: > On Sat, 2011-01-22 at 10:57 -0600, Kirk Wolff wrote: > > Hello, > > I've been digging through calendar's webdav backend > The calendar is CalDAV [it uses REPORT methods]; a descendant of WebDAV. > > code and found that > > there's special handling of calendar items (components) that have > > the same UID. Under what circumstances would two calendar items > > have both the same UID and href? > I suppose this could happen in the case of editing a recurrence [I don't > specifically know how evolution internally handles recurrences; but I > work on a CalDAV server and ... man, are recurring events in iCal/CalDAV > stupid and a pain].
RFC4791 4.1. Calendar Object Resources Calendar object resources contained in calendar collections MUST NOT contain more than one type of calendar component (e.g., VEVENT, VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE components, which MUST be specified for each unique TZID parameter value specified in the iCalendar object. For instance, a calendar object resource can contain one VEVENT component and one VTIMEZONE component, but it cannot contain one VEVENT component and one VTODO component. Instead, the VEVENT and VTODO components would have to be stored in separate calendar object resources in the same collection. Calendar object resources contained in calendar collections MUST NOT specify the iCalendar METHOD property. The UID property value of the calendar components contained in a calendar object resource MUST be unique in the scope of the calendar collection in which they are stored. Calendar components in a calendar collection that have different UID property values MUST be stored in separate calendar object resources. Calendar components with the same UID property value, in a given calendar collection, MUST be contained in the same calendar object resource. This ensures that all components in a recurrence "set" are contained in the same calendar object resource. It is possible for a calendar object resource to just contain components that represent "overridden" instances (ones that modify the behavior of a regular instance, and thus include a RECURRENCE-ID property) without also including the "master" recurring component (the one that defines the recurrence "set" and does not contain any RECURRENCE-ID property). For example, given the following iCalendar object: BEGIN:VCALENDAR PRODID:-//Example Corp.//CalDAV Client//EN VERSION:2.0 BEGIN:VEVENT UID:1...@example.com SUMMARY:One-off Meeting DTSTAMP:20041210T183904Z DTSTART:20041207T120000Z DTEND:20041207T130000Z END:VEVENT BEGIN:VEVENT UID:2...@example.com SUMMARY:Weekly Meeting DTSTAMP:20041210T183838Z DTSTART:20041206T120000Z DTEND:20041206T130000Z RRULE:FREQ=WEEKLY END:VEVENT BEGIN:VEVENT UID:2...@example.com SUMMARY:Weekly Meeting RECURRENCE-ID:20041213T120000Z DTSTAMP:20041210T183838Z DTSTART:20041213T130000Z DTEND:20041213T140000Z END:VEVENT END:VCALENDAR The VEVENT component with the UID value "1...@example.com" would be stored in its own calendar object resource. The two VEVENT components with the UID value "2...@example.com", which represent a recurring event where one recurrence instance has been overridden, would be stored in the same calendar object resource. _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers