[Ietf-calsify] Why no empty calendar?
lisa at osafoundation.org
Mon Jul 14 15:55:00 PDT 2008
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
> 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
> 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.
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.
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
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".
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.
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
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.
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.
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
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
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
Respecting CLASS:private and confidential
More information about the Ietf-calsify