Subject: [Ietf-calsify] Modifications without masters

From: jeffrey at osafoundation.org (Jeffrey Harris)
Date: Mon Oct 1 14:39:39 2007

Hi Folks,

Is there anything in RFC2445bis that forbids a modification without an
associated master in an iCalendar stream?

That is, should it be legal to have a stream like:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:Foo
METHOD:PUBLISH
BEGIN:VEVENT
UID:[email-masked]
RECURRENCE-ID:20060311T200000
DTSTART:20060311T200000
END:VEVENT
END:VCALENDAR

without an associated master recurring event?  Google Calendar's
exported iCalendar frequently has such modifications without masters.

Sincerely,
Jeffrey

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Mon Oct 1 14:54:40 2007

Hi Jeffrey,

> exported iCalendar frequently has such modifications without masters.

You certainly need to be able to do that for METHOD:REQUEST - i.e. you 
invite an attendee to one instance of a recurring meeting only.

iTIP does say that updates using PUBLISH are allowed, so I think the above 
is OK. However, was the event you quoted above exactly what they sent? If 
so why isn't there a DTEND or SUMMARY (I'm assuming that the event is 
supposed to represent some finite amount of time). What actually changed? 
The R-ID and DTSTART are the same...

-- 
Cyrus Daboo

---

From: jeffrey at osafoundation.org (Jeffrey Harris)
Date: Mon Oct 1 15:02:30 2007

Hi Cyrus,

> iTIP does say that updates using PUBLISH are allowed, so I think the
> above is OK. However, was the event you quoted above exactly what they
> sent? If so why isn't there a DTEND or SUMMARY (I'm assuming that the
> event is supposed to represent some finite amount of time). What
> actually changed? The R-ID and DTSTART are the same...

Sorry, I elided several lines for brevity.  When I've gotten events like
this from Google, they've typically had a matching DTSTART and
RECURRENCE-ID, it's a complete event, but there are no other VEVENT's
with a matching UID.

I'm guessing in Google's case this is just a bug, not the intention, but
I suppose calendar agents should accept events like this and treat them
like a normal event until we get a matching master.

Sincerely,
Jeffrey