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

From: Cyrus Daboo <[email-masked]>
Date: Tue, 08 Jul 2008 16:43:36 -0400

Hi,
(Whilst I realize it is too late for changes to 2445bis now, I think it is 
still worth raising issues and using the issue tracker to log problems that 
could be considered in a future revision - assuming Eliot does not mind 
leaving the tracker up).

Currently both 2445 and 2445bis make it impossible to have an empty 
VCALENDAR object. i.e. a VCALENDAR with only properties - no components. 
The relevant ABNF is:

        icalbody   = calprops component

        component  = 1*(eventc / todoc / journalc / freebusyc /
                     timezonec / iana-comp / x-comp)

The workaround is to send a single VTIMEZONE object or a bogus X- component 
(perhaps BEGIN:X-2445-IS-SILLY), or a bogus "regular" component. But that 
seems a little silly. It should be perfectly possible for me to publish an 
empty calendar.

Proposal: relax the restriction that a VCALENDAR object has to contain "one 
or more" components, to instead allow "zero or more" components, and adjust 
ABNF and text accordingly.

-- 
Cyrus Daboo

_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: "Tim Hare" <[email-masked]>
Date: Tue, 8 Jul 2008 16:53:42 -0400

What's the use case for publishing an empty calendar?

Why would I want to open that file, assuming I found it using some sort of
calendar search? 

If this _were_ allowed in some future revision, then I would vote that a UA
MUST warn that the file is empty when opened. No one wants to open an .ics
file (say for example the schedule for the Irish National Hurling
Championships) to add something to their calendar, get nothing added, and
not be informed.  It's already sometimes onerous when a UA opens a calendar
file _with_ data but doesn't position you to, or tell you about, the first
item added - you then end up hunting through calendar entries to make sure
what you thought would happened did in fact happen.

Tim Hare
Interested Bystander, Non-Inc.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Cyrus Daboo
Sent: Tuesday, July 08, 2008 4:44 PM
To: [email-masked]
Subject: [Ietf-calsify] Why no empty calendar?

Hi,

--
Cyrus Daboo

---

From: Helge Hess <[email-masked]>
Date: Tue, 8 Jul 2008 23:09:54 +0200

+1, makes sense to me.

> Why would I want to open that file, assuming I found it using some  

You do not 'open' the 'file', you subscribe it. While it may not  
contain events now, it might contain some in the future.

Using the transport layer for this (eg HTTP 404) is not that good. The  
calendar actually exists and is valid, its just empty at a specific  
point in time.
The only other option might be to return an empty resource (content- 
length: 0). But then the calendar component itself might have  
interesting meta data.

Thanks,
   Helge

PS: I'm pretty sure that most iCal tools already work that way ...
-- 
Helge Hess
http://helgehess.eu/

---

From: "Tim Hare" <[email-masked]>
Date: Tue, 8 Jul 2008 17:18:09 -0400

OK I understand the use case now; so my only statement will be that any UA
which processes the file (please note, you do not have to subscribe to it,
it's perfectly OK to reference an .ics file via an anchor tag and href
attribute, with a file association which causes it to be opened by a
particular desktop program) MUST warn that it is empty.

Tim Hare

-----Original Message-----
From: Helge Hess [mailto:[email-masked]] 
Sent: Tuesday, July 08, 2008 5:10 PM
To: Tim Hare
Cc: 'Cyrus Daboo'; [email-masked]
Subject: Re: [Ietf-calsify] Why no empty calendar?

+1, makes sense to me.

On 08.07.2008, at 22:53, Tim Hare wrote:
> Why would I want to open that file, assuming I found it using some 
> sort of calendar search?

You do not 'open' the 'file', you subscribe it. While it may not contain
events now, it might contain some in the future.

Using the transport layer for this (eg HTTP 404) is not that good. The
calendar actually exists and is valid, its just empty at a specific point in
time.
The only other option might be to return an empty resource (content-
length: 0). But then the calendar component itself might have interesting
meta data.

Thanks,
   Helge

---

From: Reinhold Kainhofer <[email-masked]>
Date: Tue, 8 Jul 2008 23:57:10 +0200

> particular desktop program) MUST warn that it is empty.

I don't think that should really be a MUST. If I add a remote calendar file 
(i.e. a URL that will be regularly polled) to my personal organizer, I simply 
want its events to be displayed in my UA. I don't want to be bothered 
with "WARNING: The calendar blahblah does not contain any events!" messages 
whenever the application polls the calendar.

Of course, there are situations where a warning makes sense, but in other 
situations it is simply annoying to the user.

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: "Tim Hare" <[email-masked]>
Date: Tue, 8 Jul 2008 21:12:36 -0400

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?

Tim Hare

-----Original Message-----
From: Reinhold Kainhofer [mailto:[email-masked]] 
Sent: Tuesday, July 08, 2008 5:57 PM
To: [email-masked]
Cc: Tim Hare; 'Helge Hess'
Subject: Re: [Ietf-calsify] Why no empty calendar?

Am Dienstag, 8. Juli 2008 schrieb Tim Hare:
> OK I understand the use case now; so my only statement will be that 
> any UA which processes the file (please note, you do not have to 
> subscribe to it, it's perfectly OK to reference an .ics file via an 
> anchor tag and href attribute, with a file association which causes it 
> to be opened by a particular desktop program) MUST warn that it is empty.

I don't think that should really be a MUST. If I add a remote calendar file
(i.e. a URL that will be regularly polled) to my personal organizer, I
simply want its events to be displayed in my UA. I don't want to be bothered
with "WARNING: The calendar blahblah does not contain any events!" messages
whenever the application polls the calendar.

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)

iD8DBQFIc+K5TqjEwhXvPN0RAhFTAKDZaVjsizUUSKKoklxUIb7KuHOubwCgoooA
u0LAc/Z9pbOhNnBffRrsxNo=
=epvS

---

From: Lisa Dusseault <[email-masked]>
Date: Mon, 14 Jul 2008 15:55:00 -0700

> ways other than mail, CalDAV, or subscriptions?

+1.  Actually I think the subscription case needs to be fleshed out too.

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".

X.1. Components

All iCalendar components can be mixed in the same file.  VTIMEZONE  
components SHOULD be included in the same file where the timezone  
definitions are used.

X.1.1 VTODOs

Many, but not all clients, can handle importing VTODOs along with  
VEVENTS.  When the user maintains several different calendars for  
different contexts, the VTODOs are usually associated with the same  
contexts as the VEVENTs: (e.g. "home tasks" and "work tasks").  Thus,  
it's very convenient to export VTODOs in the same file as VEVENTS.    
However, there are still some calendar agents that don't handle tasks,  
and users might find their tasks disappearing or even confusing the  
importing piece of software.   It might be a useful feature to allow  
users the choice of including VTODOs in export files or leaving them  
out.

VTODOs can be recurring items, can have due dates and alarms. This  
should be supported, otherwise the user must be warned if information  
is being lost in import.

X.1.2 VJOURNALs

VJOURNAL components are even less consistently handled.   They are  
used in some time-management software to allow users to enter quick  
notes, that might turn into tasks or events or may simply be archived  
as plain notes.   However, when a user agent has no ability to display  
notes as separate components from calendar events, the user at least  
needs to be made aware that some types of components are not being  
preserved in the import.

Not all properties are routinely supported on VJOURNAL items.   
CONTACT, ORGANIZER, RECURRING, SEQUENCE  properties are not. ,.. what  
else?  Alarms... perhaps attachments should be recommended here, and  
most other things advised against.

X.2. Alarms

choice to clear all alarms when importing
default choice when exporting should be to include
how to convert to local context
how the ATTACH property points to a local file

importing client MUST be able to handle multiple alarms on the same  
parent component

X.3.  Attachments

How does this work anyway?  Is CID URL really used?  Where are the  
content parts stored, that are referenced?

X.4.  Other considerationsw

The FREEBUSY properties on an iCalendar object should be preserved in  
this way...

The METHOD property should not appear

The PRODID property can be dropped/changed on import, but should be  
saved on export for debugging information.

CATEGORIES are generally treated as keywords, either folksonomies or  
specific categories in some enterprise systems.  In either case,  
categories are not usually given top-level UI treatment -- instead,  
separate calendars (separate iCalendar files) are more commonly used  
as the model.

COMMENT properties are not common.  User agents may fold this into  
description during import.

How are invitations handled?  How can a user see, when they import an  
event into a new piece of software, that this was received as an  
invitation and from whom and when?

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

Y.  Security Considerations (to add to security considerations already  
there)

Respecting CLASS:private and confidential

---