[Ietf-calsify] Why no empty calendar?

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

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

---