Subject: Re: [Ietf-calsify] Why no empty calendar?

From: Reinhold Kainhofer <[email-masked]>
Date: Mon, 8 Sep 2008 01:44:33 +0200

Am Dienstag, 15. Juli 2008 schrieb Lisa Dusseault:
> On Jul 8, 2008, at 6:12 PM, Tim Hare wrote:
> > When you're discussing polling, you're in the realm of Atom or RSS and
> > subscriptions, where eliminating the error message is "natural" - my
> > RSS
> > reader doesn't tell me when the feed has not been updated. If,
> > however we
> > allow VCALENDARs to be empty, a UA which imports a calendar through
> > mechanisms other than a subscription definitely needs to warn the
> > user.
> >
> > I'll have to think more deeply on this; perhaps there needs to be an
> > iTIP- /
> > iMIP- document to describe behaviors when iCalendar objects are
> > consumed in
> > ways other than mail, CalDAV, or subscriptions?
>
> +1.  Actually I think the subscription case needs to be fleshed out too.

Thinking of this a bit more: I really think that an empty calendar should be 
allowed. In particular take the case of e.g. a sports team publishing their 
upcoming competitions (or a choir/band/orchestra publishing their upcoming 
concerts, or another organization their upcoming public events) as an .ics 
file on a web page. If they have no upcoming competitions, they cannot simply 
publish an empty .ics file, but have to change their homepage to remove the 
link to the then-non-existing .ics file. 

Shouldn't that be made easier to allow an empty calendar, so that these cases 
can be handled without much hassle? An empty calendar would be placed on the 
homepage and a CUA or any other application able to handle .ics files might 
(but doesn't have to) display a warning.

Cheers,
Reinhold
- -- 
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Reinhold Kainhofer <[email-masked]>
Date: Fri, 12 Sep 2008 14:31:06 +0200

Am Dienstag, 15. Juli 2008 schrieb Lisa Dusseault:
> I drafted some text a little while back, that might have been a 2445
> appendix, but could instead get used in a separate doc.  This starts
> out as drafty text but then turns into somewhat of an outline.
>
> Lisa
>
> ----
>
> X.  Importing and exporting iCalendar Data
>
> The iCalendar specification is commonly used as the basis for
> exporting calendar files that can be imported into different software
> when users need to move their calendars around. This document
> describes that practice.  It is intended to be descriptive rather than
> normative.
>
> The file type and extension are as specified in RFC2445bis.
>
> When a user has several calendars for different categories or contexts
> (such as "home", "work" and "local events"), user agents most commonly
> export these as separate files rather than using categories within one
> big file.  This works well with user agents that import each ICS file
> as a new calendar.  Another common practice is to name the export file
> after the calendar, e.g. "work.ics".
[...]
> The METHOD property should not appear

I completely agree with this. In particular, MS Outlook refuses to import an 
iCalendar file unless it contains METHOD:PUBLISH. This however has the 
drawback that no ATTENDEEs are allowed on any component, which runs counter 
the idea of full data im-/export.

Maybe we should explicitly hint at such situations?

> How often is RELATED-TO really used and what for?  Can a user agent
> drop this on import?

In KOrganizer we use RELATED-TO to build a tree structure for to-dos (i.e. a 
to-do can have sub-todo, which are RELATED-TO the parent to-do). In many 
cases the summary of a sub-to-do only makes sense in the context of the 
parent to-do.

The other situtation where we use RELATED-TO is connected to the fact that 
likbcal does not support multiple components with the same UID. So, when one 
wants to modify one specific recurrence instance we don't use RECURRENCE-ID, 
but add that date as an EXDATE and a new event with a new UID is generated 
for the exception. However, to preserve at least some indication where that 
event came from, we set RELATED-TO to the original UID (although we don't use 
that setting anywhere).

Of course, that's just a workaround for some missing functionality, but that's 
the best we could think of without having to reimplement/restructure large 
parts of our code (which relies on the fact that the UID uniquely determines 
one event).

Cheers,
Reinhold

- --

---

From: "Tim Hare" <[email-masked]>
Date: Fri, 12 Sep 2008 18:27:53 -0400

I believe, but haven't tested yet, that an iCalendar object could have only
timezone components, which would be an effective empty calendar.

A CUA  would still need to notify the user when handling such an object.

On the other issue posted under this topic where it was mentioned that
Outlook will not allow a METHOD:PUBLISH object to contain ATTENDEES,  I
think that may be non-compliant behavior and I'd rather see the CUA fixed,
but I can see a use case for METHOD:ARCHIVE (or some such name) which would
mean "iCalendar stream created verbatim as an intended backup"..

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: Reinhold Kainhofer [mailto:[email-masked]] 
Sent: Sunday, September 07, 2008 7:45 PM
To: Lisa Dusseault
Cc: Tim Hare; [email-masked]
Subject: Re: [Ietf-calsify] Why no empty calendar?

Am Dienstag, 15. Juli 2008 schrieb Lisa Dusseault:
> > When you're discussing polling, you're in the realm of Atom or RSS 
> > and subscriptions, where eliminating the error message is "natural" 
> > - my RSS reader doesn't tell me when the feed has not been updated. 
> > If, however we allow VCALENDARs to be empty, a UA which imports a 
> > calendar through mechanisms other than a subscription definitely 
> > needs to warn the user.
> >
> > consumed in ways other than mail, CalDAV, or subscriptions?
>

Thinking of this a bit more: I really think that an empty calendar should be
allowed. In particular take the case of e.g. a sports team publishing their
upcoming competitions (or a choir/band/orchestra publishing their upcoming
concerts, or another organization their upcoming public events) as an .ics
file on a web page. If they have no upcoming competitions, they cannot
simply publish an empty .ics file, but have to change their homepage to
remove the link to the then-non-existing .ics file. 

Shouldn't that be made easier to allow an empty calendar, so that these
cases can be handled without much hassle? An empty calendar would be placed
on the homepage and a CUA or any other application able to handle .ics files
might (but doesn't have to) display a warning.

Cheers,
Reinhold
- --
- ------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: [email-masked], http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien,
http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/ -----BEGIN PGP
SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIxGdkTqjEwhXvPN0RAhlFAJ4qPYOBNyl0dp56I5ZhaENBz2cCWwCeKuld
LcQ47lciN6sYlytA9/BIVGM=
=q6bn