Subject: [Ietf-calsify] summary of issues discussed in the jabber session

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Thu Dec 14 06:36:27 2006

Am Donnerstag, 14. Dezember 2006 14:54 schrieben Sie:
> Excuse me for asking a perhaps-too-obvious question, but have you
> deprecated X- things in recurrences? If not, can Kalarm et al devise a
> scheme which uses X-properties to provide what is needed?

No, because then we don't have interoperatobility with any other application. 
If some other application already supports a similar feature, the two 
applications would not be able to exchange that data, unless both use the 
same, well-defined scheme. This scheme of course would need to be published, 
preferrable in an RFC, so we can as well include it in RFC 2445 instead of 
artificially creating the need for yet-another standards-extension.

And most important: It should not matter which application generated a given 
recurrence. So proprietary X-... extensions are a bad thing.

I'm currently not working together with the KAlarm or the KTimeTracker 
developers at all. They simply generate iCalendar, and my application is able 
to understand iCalendar, so these two applications automagically work 
together without doing any special cases for KAlarm support in KOrganizer or 
Evolution or Apple iCal. 

> I'm concerned that trying to retain too many of the possibilities in the
> current iCalendar moves us away from the goal of the WG which is to produce
> something simpler that promotes interoperability among implementations.
> Retaining interoperability within components of one software suite, while
> not a bad goal, doesn't advance the state of calendaring in the way that
> the WG was chartered to do.

I always saw iCalendar as a specification that defines a superset of basically 
everything that any calendar application ever wanted to do. Hardly anybody 
would implement every aspect, but if an application wanted to implement, say, 
minutely recurrences, there is a well-defined and interoperable way to do 
this. While it's not guaranteed that any application will understand every 
detail (How many applications do not implement the LANG param? Or how many 
applications do not implement recurring alarms?), at least those applications 
that support a given feature can exchange data without having to invent 
something new. And they have a defined way to interpret the exchanged data 
consistently.
That last point was not really there in rfc 2445 because of some 
inconsistencies and misunderstandings in the RFC. And fixing that is the most 
important aspect for me.

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/