Apple's Newest iCal Not Subscribing to Mozilla Calendars Correctly

Brett O'Connor

unread,

Oct 9, 2003, 4:32:46 PM10/9/03

to

Hi Calendar group,

It seems that the newest version of Apple's iCal (1.5.1 - released
yesterday) does not process Mozilla-published calendars correctly. :(

From what I can determine, it now takes the END:VCALENDAR lines in the
.ics files that Mozilla Calendar publishes literally. When you
subscribe to a Mozilla-published calendar, iCal now only makes a local
copy of the first event ever added to the calendar, and does not process
any events past that. Mozilla calendar puts an END:VCALENDAR after
every event in the .xml. iCal only puts END:VCALENDAR at the end of the
calendar file.

Thanks,

Brett O'Connor

Scot McSweeney-Roberts

unread,

Oct 10, 2003, 7:12:35 AM10/10/03

to

I noticed that iCal and MozCal had such different 'styles' when I was
writing a script to merge iCalendar files. I decided to see which was
correct by looking at the RFC for the iCalendar format (RFC 2445) and
acording to section 4.4

The Calendaring and Scheduling Core Object is a collection of
calendaring and scheduling information. Typically, this information
will consist of a single iCalendar object. However, multiple
iCalendar objects can be sequentially grouped together.

So both styles are correct, though iCal's is more typical. I'd log a bug
with Apple - as it's iCal not conforming to the RFC, not MozCal
outputting nonstandard files. As soon as I upgrade my copy of iCal and
test it I'll send Apple some feedback (not that have any great hope
they'll do anything about, but it's worth a shot).

Scot

Libby Miller

unread,

Oct 10, 2003, 7:23:57 AM10/10/03

to

Yeah, both are correct. Apple have actually been quite good at repairing
another problem with respect to RFC 2445, so it is worth asking. I've
forwarded the message to Olivier Gutknecht at apple in case he hasn't
seen it.

cheers

Libby

> _______________________________________________
> mozilla-calendar mailing list
> mozilla-...@mozilla.org
> http://mail.mozilla.org/listinfo/mozilla-calendar
>
>

Chris Carlin

unread,

Oct 10, 2003, 8:02:42 AM10/10/03

to

> From what I can determine, it now takes the END:VCALENDAR lines in the
> .ics files that Mozilla Calendar publishes literally. When you
> subscribe to a Mozilla-published calendar, iCal now only makes a local
> copy of the first event ever added to the calendar, and does not process
> any events past that. Mozilla calendar puts an END:VCALENDAR after
> every event in the .xml. iCal only puts END:VCALENDAR at the end of the
> calendar file.

Yeah, kOrganizer used to have this problem.
I understand that the ruling was that they were wrong and it is now
fixed (perhaps only in the CVS version, though).

I don't know, I guess email Apple and complain? :)

~Chris

Brett O'Connor

unread,

Oct 10, 2003, 1:10:21 PM10/10/03

to

Cool. Thanks for the info.

I've contacted Apple also. Hopefully they will fix it. I just figured
I would try here also as you all are much more responsive, to say the
least. :)

As always, thanks for all your hard work.

Brett O'Connnor

Olivier Gutknecht

unread,

Oct 16, 2003, 1:27:50 PM10/16/03

to

Hi,

First, as Scot said, both styles can be considered as syntaxically
valid. The problem with the one vcalendar/one vevent is that it could
lead to some annoying semantics fuzziness or wasted bandwidth:
- if the events in the calendar have timezone information, the vtimezone
block must be present in the vcalendar block. vtimezone blocks can be
quite big and duplicating the very same vtimezone block in -all-
vcalendar blocks for all the events.
- the 'calendar on the web' idea is not something that was explicitely
stated in the various icalendar rfc, but it can be assumed it's a way of
expressing a publication (a la RFC 2446, see RFC 2447 example in section
4.4) for a calendar. The RFC says that multiple vcalendar blocks are ok,
but it is also ok to have different METHOD properties in each calendar
block. What should be the correct behavior for a calendaring agent when
the source data is a PUBLISH, a REQUEST, an UPDATE, another PUBLISH and
a CANCEL ? This is probably more the intended usage of multiple
vcalendar blocks in the RFC (see RFC 2447, example in section 4.5).
There is a comment in bug 129660 about same-uid constraint in iTIP, but
it is only for REQUEST-like methods.
- In the context of a all-publish, what is the exact meaning of multiple
vcalendar blocks ? mozilla interprets that as an aggregation of events,
but it would be equally correct to assume it's an aggregation of
calendars, each with one (or more) event and a request to add multiple
calendars to the user calendaring agent in one shot.

Ol.

Scot McSweeney-Roberts

unread,

Oct 17, 2003, 6:26:08 AM10/17/03

to

Olivier Gutknecht wrote:

> - In the context of a all-publish, what is the exact meaning of multiple
> vcalendar blocks ? mozilla interprets that as an aggregation of events,
> but it would be equally correct to assume it's an aggregation of
> calendars, each with one (or more) event and a request to add multiple
> calendars to the user calendaring agent in one shot.

I've been thinking about that - if I were writing a calendar app with no
knowledge of how mozilla works, I would assume that mulitple calendars
in a file is exactly that, multiple calendars and not a single calendar
the way mozilla interprets them.

I suppose that while the iCal files mozillas produces are technically
valid, they are a bit weird.

Scot