Subject: [Ietf-calsify] What's wrong with more radical simplification?

From: nsb at guppylake.com (Nathaniel Borenstein)
Date: Thu Feb 10 08:29:33 2005

Tim Hare said something in October that was so on target that I think 
it's worth reading again:

> Maybe it's serendipity, but I was pointed to an old post at 
> http://www.shirky.com/writings/evolve.html about evolvable systems as 
> it relates to the Web; and it kind of struck a chord about what we're 
> doing here.
>
> Let's get out an iCal-Basic that everyone can create easily from what 
> they've got now,  and everyone can read in with what they've got now. 
> Even if it means we're passing back-and-forth larger sets of data to 
> describe repeating appointments, even if it means certain appointments 
> that cross timezones or daylight-savings-time changes have problems.  
> The thing is, if we can get out something that works, we can then 
> evolve it to work better.  We have got to find the simplest common 
> denominator that works, call that iCal-Basic, and release it. That's 
> the four-footed fish crawling up on the shore... we'll get to mammals 
> later.

I believe this post goes to the heart of everything that is most broken 
about iCal, and that we must take it very seriously if we're to have 
any hope of fixing this mess.  I will therefore reiterate yet again my 
past observations about the potential for radical simplification, 
simply because no one has yet convinced me that what I advocate would 
be an *over* simplification.  I believe that we should grab for any 
simplification that won't demonstrably make the standard inadequate for 
its primary purposes, which I regard to be personal and interpersonal 
event scheduling.

I still believe that we can completely eliminate recurrence rules, and, 
given that elimination, we can radically reduce the importance and 
complexity of time zones as well.

First of all, let's consider carefully what will happen if we choose to 
go down the road, as many are proposing, of making RRULES an optional 
part of the specification.  In that world, the composer of an email 
invitation to a repeating meeting won't be able to know (for reasons 
touched on in my companion post, "Receiver Capability Description 
Considered Harmful") whether or not the recipient(s) will understand 
RRULES.  Thus, such a composer will inevitably end up sending repeating 
meeting invitations as multipart/alternatives, containing both a "set" 
and a "rule" description of the repeating meeting.  In that case, I 
would argue that the RRULES can be dispensed with entirely as 
redundant.

Eliminating RRULES implies, in turn, that we can use UTC for nearly 
everything, so that the only time zone translation that needs to be 
done is at the user level and involves the relatively straightforward 
translation between UTC and the user's own time zone.  Together, this 
pair of changes would be an enormous simplification of a protocol that 
I believe is choking under its own complexity.  Even the discussion on 
this list about how to simplify RRULES is, I fear, too complex for many 
potential implementors to understand, and thus will inevitably lead to 
"misinterpretations."  (I put the word in quotes because I believe that 
if there is any way to misinterpret a standard, it is the spec that is 
at fault, not the implementor.   Long experience has taught that if 
there is more than one way to interpret an RFC, it will be interpreted 
in more than one way by software that claims to be conformant.)

If, as I am claiming, it is *possible* to do everything without RRULES, 
and that RRULES are just a bandwith-and-space-saving-convenience for 
repeat meetings that have LOTS of repeats (and, of course, a truly 
vital feature for any imaginary meetings that continue infinitely, 
unlike their attendees), then we should try to build a complete version 
without RRULES first, and only try to add on the efficiency/convenience 
of RRULES later, if at all.  Worrying about the cost/efficiency of 
representing a recurring meeting, in a world full of BitTorrent and 
webcams, strikes me as rather myopic.  If we can live with base64, we 
can live with this.

I know that several of you are tired of hearing this argument from me.  
I encourage you to shut me up by convincing me that it is NOT possible 
to define a completely adequate version of iCal that doesn't have any 
recurrence rules.  But if it is possible, I think it is what we should 
do. -- Nathaniel

---

From: stpeter at jabber.org (Peter Saint-Andre)
Date: Thu Feb 10 09:53:04 2005

In article <[email-masked]>,

> complexity of time zones as well.

+1

"Simplify, simplify, simplify." -- Henry David Thoreau

/psa

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Thu Feb 10 16:03:36 2005

> complexity of time zones as well.

I think removing rrules would be a real bad idea. Sure, handing out a 
list of  occurrences will show up the same way on a calendar. But you 
lost information. The app won't know anymore that it is an event that 
happens every monday. It just has a list of dates. It can't show the UI 
anymore, so the user can't change it to every tuesday. The data is gone.

Michiel

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Thu Feb 10 16:29:05 2005

On 10. Feb 2005, at 23:03 Uhr, Michiel van Leeuwen wrote:
>> I still believe that we can completely eliminate recurrence rules, 
>> and, given that elimination, we can radically reduce the importance 
>> and complexity of time zones as well.
> happens every monday. It just has a list of dates. It can't show the 
> UI anymore, so the user can't change it to every tuesday. The data is 
> gone.

If you have some standard you basically always loose information since 
you need to find a viable common denominator.

So what is your _solution_ to this? Pointing out the flaws is 
insufficient, its proven that rrules are not interoperable since 
everyone does rrules in a different way and no one does support them 
fully?!

For the _basic_ draft, IMHO timezones and rrules should be removed to 
have something which can be widely supported by everyone.
Of course they should be supported in some extension.

Greets,
   Helge
-- 
http://docs.opengroupware.org/Members/helge/
OpenGroupware.org

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Thu Feb 10 17:48:07 2005

Hi Helge,

--On February 11, 2005 1:27:34 AM +0100 Helge Hess 
<[email-masked]> wrote:

> insufficient, its proven that rrules are not interoperable since everyone
> does rrules in a different way and no one does support them fully?!

OK - so what exactly is wrong with RRULEs in and of themselves? My reading 
of the current interoperability state is that most products handle RRULE 
generation/expansion correctly. The real problem is not the RRULEs per se, 
but rather then exceptions to recurrences and how to manage rescheduling of 
such exceptions via iTIP. Exceptions and rescheduling will be a problem 
whether we have RRULEs or just RDATEs. It looks like that ought to be 
easier with RDATEs only, but I'm not sure its all that much easier.

-- 
Cyrus Daboo

---

From: TimHare at comcast.net (Tim Hare)
Date: Thu Feb 10 21:04:00 2005

In a particular UI implementation, you _can_ use recurrence rules supported 
by that product - all we are proposing is that they be _exchanged_ as a 
list of RDATES, or even more simply as a set of VEVENTS. The calendar store 
of the originator of the recurring-event item can store it in the compact 
manner with recurrence rules stored according to what it supports.  The 
calendar store(s) of the recipient(s) could, I suppose, use the UID on the 
VEVENTs to try to determine a recurrence rule according to its own methods 
(the simplest being to make it one item with a list of dates, 
probably).  But in either case, the user hasn't lost the ability to simply 
put in recurring items. The UI, in other words, is separate from the data.

Tim

At 05:03 PM 2/10/05, Michiel van Leeuwen wrote:
>I think removing rrules would be a real bad idea. Sure, handing out a list 
>of  occurrences will show up the same way on a calendar. But you lost 
>information. The app won't know anymore that it is an event that happens 
>every monday. It just has a list of dates. It can't show the UI anymore, 
>so the user can't change it to every tuesday. The data is gone.
>
>
>Michiel
>_______________________________________________
>Ietf-calsify mailing list
>[email-masked]
>http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

---

From: Robert_Ransdell at notesdev.ibm.com ([email-masked])
Date: Fri Feb 11 07:43:55 2005

that is my take on rrule intop as well.

Cyrus Daboo <[email-masked]> 
Sent by: [email-masked]
02/10/2005 08:47 PM

To
Helge Hess <[email-masked]>, [email-masked]
cc

Subject
Re: [Ietf-calsify] Re: What's wrong with more radical simplification?

Hi Helge,

> insufficient, its proven that rrules are not interoperable since 
everyone

but rather then exceptions to recurrences and how to manage rescheduling 
of 
such exceptions via iTIP. Exceptions and rescheduling will be a problem 
whether we have RRULEs or just RDATEs. It looks like that ought to be 
easier with RDATEs only, but I'm not sure its all that much easier.

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Fri Feb 11 08:34:08 2005

> you need to find a viable common denominator.
I think that is the wrong approach. Looking at bugs/problems in current 
implementations, and removing that from the spec. You need to define 
what you want to approach with the spec, and make sure you can reach that.
Not having recurrence rules just because some clients have problems with 
them isn't the right way imo.

> everyone does rrules in a different way and no one does support them 

Fix the clients.
Or come up with something completly new, that new clients can implement 
correctly. But that will take even longer.

> Of course they should be supported in some extension.

imo extensions also are the wrong solution. If i want to publish my 
calendar, i can't use the extensions, because i don't know what other 
clients will read the file. So in reality, you can never use extensions. 
(can you imagine a client asking the user: what application is the 
recipient of this event using?)

Michiel

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Fri Feb 11 08:45:02 2005

Tim Hare wrote:
> In a particular UI implementation, you _can_ use recurrence rules 
> supported by that product - all we are proposing is that they be 
> _exchanged_ as a list of RDATES, or even more simply as a set of 
> VEVENTS.

So the recipient of the exchange can't change (or even look at) the 
recurrence information.

> The calendar store(s) of the 
> recipient(s) could, I suppose, use the UID on the VEVENTs to try to 
> determine a recurrence rule according to its own methods

That will give even more bugs. Trying to be smart based on a list of dates.

There is some other problem i tought of: It isn't uncommon for users to 
create a recurring event without an end time, because it is not known at 
the time of creating. So for the time being, it will recur forever. What 
should the application do when exchanging that event as a list of 
rdates? It must come up with an arbitrary end date. The recipient might 
think of that as the real date. Not only did you loose the original 
information, you added wrong new information.

Michiel

---

From: Libby.Miller at bristol.ac.uk (Libby Miller)
Date: Fri Feb 11 08:53:56 2005

On Fri, 11 Feb 2005, Michiel van Leeuwen wrote:

>> list of RDATES, or even more simply as a set of VEVENTS.
>
>> The calendar store(s) of the recipient(s) could, I suppose, use the UID on 
>> the VEVENTs to try to determine a recurrence rule according to its own 
>> methods
>
> create a recurring event without an end time, because it is not known at the 
> time of creating. So for the time being, it will recur forever. What should 
> the application do when exchanging that event as a list of rdates? It must 
> come up with an arbitrary end date. The recipient might think of that as the 
> real date. Not only did you loose the original information, you added wrong 
> new information.

which applications export data as rrules? and is it mostly timezone 
information? It looks from our smallish dataset[1] that evolution does 
export them. Does anyone have any bigger/better sets of example outputs?

cheers,

Libby

[1] http://www.w3.org/2002/12/cal/test/

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Fri Feb 11 09:04:19 2005

On Feb 11, 2005, at 17:33, Michiel van Leeuwen wrote:
> Helge Hess wrote:
>> If you have some standard you basically always loose information 
>> since you need to find a viable common denominator.
> I think that is the wrong approach.

Its not an approach at all, its just a statement/fact. Most 
clients/servers use iCalendar for interoperability, not for their 
implementation (and can therefore only expose iCal features, not their 
full functionality).

This is a bit different for most OpenSource clients, which also use 
iCalendar for storing the information.

> Fix the clients.
> Or come up with something completly new, that new clients can 
> implement correctly. But that will take even longer.

You have the assumption that fixing the clients is an easy and viable 
task. I had the impression that currently rrules can represent every 
recurrence model which was supported by the initial protocol creators. 
This in turn makes it very complex and forces everyone to implement all 
the rrules of the others (and in practice nobody does that which makes 
rrules not interoperable).

But people suggested that I might be wrong on how compliant current 
clients are. Do Outlook, Kontact, Evolution, Mozilla, iCal.app really 
support 100% of the currently specified iCalendar rrules? I would be 
surprised, but pleased to hear some actual investigation on that.

> clients will read the file.

Thats a rather weird statement. Why can't you use the extensions? If 
the "other" client supports them, he will have additional information, 
if not, he will fall back to the base spec.

Greets,
   Helge

---

From: daboo at isamet.com (Cyrus Daboo)
Date: Fri Feb 11 09:06:05 2005

Hi Michiel,

--On February 11, 2005 5:44:52 PM +0100 Michiel van Leeuwen <[email-masked]> 
wrote:

> should the application do when exchanging that event as a list of rdates?
> It must come up with an arbitrary end date. The recipient might think of
> that as the real date. Not only did you loose the original information,
> you added wrong new information.
>

Note that you almost always have to truncate an unbounded recurrence when 
doing iTIP because you cannot do conflict resolution for an unbounded 
recurrence. Indeed iTIP specifies a request-status code that CUAs can use 
in a REPLY to indicate that a recurring event was scheduled, but only over 
a finite set of recurrences (i.e. unbounded set is truncated for scheduling 
purposes).

Its worth noting two different scenarios for unbounded recurrences:

1) Those that specify a date only - not time (i.e. all day events such as 
anniversaries, holidays etc). These are usually not a problem for iTIP 
because in general you are probably not worried about conflicts (e.g. it 
doesn't matter that my birthday falls on a national holiday or the day of 
the company outing etc).

2) Those that include a time. These are the ones that present real 
difficulties because of the need to do detailed conflict resolution.

One option we may want to consider is to only allow unbounded recurrences 
for date-only items. Recurring events with times then have to be bounded, 
using either UNTIL or COUNT in an RRULE or a set of RDATEs.

I think this is reasonable because as a real world observation, I believe 
that timed recurring events really are bounded in some fashion.

-- 
Cyrus Daboo

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Fri Feb 11 09:08:01 2005

> export them. Does anyone have any bigger/better sets of example outputs?

I thought all applications exported data as RRULEs. Are there any 
existing applications that don't?

-- 
Free replacement for Exchange and Outlook (Contacts and Calendar)
http://www.ScheduleWorld.com/
WAP: http://www.ScheduleWorld.com/sw/WAPToday?id=4000&tz=EST
WebDAV: http://www.ScheduleWorld.com/sw/webDAVDir/4000.ics
VFREEBUSY: http://www.ScheduleWorld.com/sw/freebusy/4000.ifb

---

From: mark at ScheduleWorld.com (Mark Swanson)
Date: Fri Feb 11 09:17:07 2005

> surprised, but pleased to hear some actual investigation on that.

Well, ScheduleWorld 100% implements RRULEs. The GUI doesn't reflect this 
because then folks could create RRULEs that wouldn't interoperate with a 
few other products. I have done a fair bit of RRULE interop testing over 
the years and some products have always been quite good and others have 
become good only recently. My current impression is that RRULEs are 
fairly well supported - even by lesser known products like phpICalendar.

Cheers.

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Feb 11 09:26:32 2005

> anymore, so the user can't change it to every tuesday. The data is gone.

I can only second that. In particular, rfc 2445 is also meant as the format 
e.g. for drag'n'dropping of events from one application to another. If you 
expand the recurrence rule before dragging, the second application will not 
get that information.
Currently, it's possible to take an event from KOrganizer / Kontact, drag it 
to evolution and the event will be exactly the same as it was in KOrganizer.

I think iCalendar should be a format that allows to exchange all available 
information without any data loss.

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 / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050211/1ae51e2f/attachment.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Feb 11 09:28:22 2005

> if not, he will fall back to the base spec.

Yes, exactly. And that is the problem here.
If you move recurrence information to the extension and you use a recurrence, 
any client which does not understand that recurrence extension will just show 
the very first occurrence but none of the other occurrences. 

So, to be sure that the receiving client really shows all occurrences one 
can't use the recurrence extension at all. Doesn't make too much sense, does 
it?

Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050211/f3bf02ad/attachment-0001.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Feb 11 09:30:42 2005

> >> since you need to find a viable common denominator.

I would argue to the contrary. What I like so much about iCalendar is that it 
defines a way to do almost anything you might ever want to do. So when you 
implement a new feature in your calendar application, most of the time, 
iCalendar already gives you a format how to store this feature in an 
iCalendar object (for drag'n'drop, invitations, even storing). So you don't 
have to cook your own soup, but instead can use a standard which other 
clients (that implement a similar feature) can also understand.

I think it basically boils down to the two views of standards:
1) A standard should describe what every application MUST implement. If an 
application wants to do something more, it's on its own. ("lowest common 
denominator")
2) A standard gives a suggestion how an application might implement any (even 
very exotic) feature. No application will ever implement full support for 
every little detail of such a standard, but if it implements one feature, it 
can be sure that any other application that implements a similar feature will 
be able to reuse the data.

it seems most people here think that a standard is just for those parts that 
every application must implement (i.e. every detail of a standard needs to be 
supported by an application). 
However, what I like so much about iCalendar is that it gives you a 
standardized way for lots of advanced features. 

> recurrence model which was supported by the initial protocol creators.

I think it was meant to be able to describe every possible combination one 
might ever need. Anything else wouldn't make sense, because again it would 
lead to fragmentation, since one would need to invent a new solution if an 
application has needs that are not covered by a limited standard. And then 
one can be sure that interoperaility between two applications that both 
support such an advanced feature will never work.

> support 100% of the currently specified iCalendar rrules? 

No, at least korganizer / kontact doesn't. AFAICR, BYSETPOS is not correctly 
handled. The GUI of korganizer or kontact might not suggest it, but our 
libkcal library does in fact support almost the whole specification.

Cheers,
Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050211/7bc4c12b/attachment.bin

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Fri Feb 11 09:36:09 2005

On Feb 11, 2005, at 18:16, Mark Swanson wrote:
> Well, ScheduleWorld 100% implements RRULEs. The GUI doesn't reflect 
> this because then folks could create RRULEs that wouldn't interoperate 
> with a few other products.

Isn't that a contradiction? What good is an rrule if you can't display 
it? Of course I believe you that you can parse the iCalendar structure 
of the rrule, but what good is the data if the user can't view/edit it?

Unless I'm missing something, not reflecting the rrule in the GUI is 
exactly the same like not supporting it. And reflecting _all_ the 
specified rrules in iCalendar should be quite difficult (if not 
impossible if you still want to have good usability ;-).

> My current impression is that RRULEs are fairly well supported - even 
> by lesser known products like phpICalendar.

My impression is that a lot of clients use a similiar subset of the 
specified rrules and that this subset works pretty well. But it might 
be wrong.

Also most of the newer clients are specifically build around iCalendar 
which obviously improves on that too.
(eg comparing interoperability between Sunbird and Kontact should be 
done, but isn't particulary interesting since both use some derivate of 
iCalendar. One would need to compare interoperability between eg 
Outlook and Sunbird or Notes and Kontact).

Greets,
   Helge

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Feb 11 09:36:18 2005

On Friday 11 February 2005 17:53, Libby Miller wrote:
> export them. 

KOrganizer and Kontact use rrule for recurring events and recurring to-dos. 

Cheers,
Reinhold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050211/e91303e2/attachment.bin

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Fri Feb 11 09:39:39 2005

> the very first occurrence but none of the other occurrences.

Why is that? The client will show a sequence of connected events, it 
just doesn't know the algorithm the sequence was built with.

> can't use the recurrence extension at all. Doesn't make too much 

No, but it isn't the way you describe it.

The events are still connected, the idea was not to remove the 
connection between the events but to remove the pretty complex rrule 
language. The latter would have the additional advantage that we could 
also drop timezones for the basic spec (another huge complication).
But all this was already discussed some month ago?

Greets,
   Helge

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Fri Feb 11 10:02:51 2005

Cyrus Daboo wrote:
> Note that you almost always have to truncate an unbounded recurrence 
> when doing iTIP because you cannot do conflict resolution for an 
> unbounded recurrence.

Should a (sane) limitation in one application of ical restrict ical 
itself? There are other ways a ical can be published and/or shared. Not 
all of them need conflict resolution. If i just publish calendar 
somewhere, i'm not doing iTIP.

> I think this is reasonable because as a real world observation, I 
> believe that timed recurring events really are bounded in some fashion.
> 
In practice they do, but you don't always know the end when creating the 
event. Forcing the user to come up with an arbitrary enddate should be 
avoided imo.

Michiel

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Feb 11 10:08:42 2005

Skipped content of type multipart/mixed-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4696 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050211/f82a91a6/smime-0001.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Feb 11 10:15:41 2005

> just doesn't know the algorithm the sequence was built with.

So the basic standard would require you to always send the whole list of 
rdates, even if you then use a rrule with the extended standard?
What if you want to use an rrule plus an additional recurrence on a different 
date? Like a meeting each monday, but once it will happen on wednesday.

Things like 
RRULE:FREQ=WEEKLY;BYDAY=MO;COUNT=120
RDATE;VALUE=DATE:20050101,20050120,20050216
would then become invalid iCalendar syntax...
Currently, the RRULE defines several dates, and the RDATE defines additional 
dates. If I understand you correctly, the RDATE list would now be the list of 
all recurrences. And if the gui supports recurrence rules, you'd manually 
need to check each of the dates in the RDATE if it is an additional exception 
to the RRULE...

> language. 

Yes, but if you use an rrule, you would only have one vevent with the rrule, 
not the whole chain of vevents.

BTW, I think it's an either or. Either we don't allow any recurrence rules at 
all (which in my eyes would completely remove interoperability, since almost 
all GUIs have settings for recurrence rule), or we need the whole complex 
(but complete) RRULE language.

Reinhold

Reinhold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050211/7b58a117/attachment.bin

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Fri Feb 11 10:28:26 2005

> be able to reuse the data.

I think this is painted rather black and white which is not how it 
needs to be. As mentioned there can be extensions and things like 
rrules and timezones certainly make a lot of sense.

But to have interoperability (aka a _standard_) you MUST agree on 
certain blocks of functionality. I can't see how a standard can work 
otherwise.

Your example of "if it implements one feature, it can be sure that any 
other application that implements a similar feature will be able to 
reuse the data" is obviously wrong, because this other application will 
not understand some other obscure feature you are using in the same 
iCalendar entity.

> supported by an application).

Well, I would say thats the core definition of the word "standard" and 
not the "thinking" of the people here ;-)

> standardized way for lots of advanced features.

Si, iCalendar currently seems to be more like a framework to choose 
implementation suggestions from, less an actual standard (which someone 
is really compliant with). I thought the goal of calsify was to fix 
exactly this situation.

Greets,
   Helge

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Feb 11 10:31:53 2005

> of the rrule, but what good is the data if the user can't view/edit it?

All instances of that event will be correctly displayed. Unless you edit that 
event, you don't loose any data.

Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050211/81b1bdd7/attachment-0001.bin

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Fri Feb 11 10:42:00 2005

On 11. Feb 2005, at 19:14 Uhr, Reinhold Kainhofer wrote:
> If I understand you correctly, the RDATE list would now be the list of
> all recurrences.

All instances of a recurrence, yes.

> And if the gui supports recurrence rules, you'd manually

No. Why is the rrule still require if you have all individual instances 
anyway? Its required to support the editor panel in the calendering 
client. If it supports the rrule, it can show proper UI for changing 
the cycle.
Also if a server or client gets an event with the rrule and supports 
the rrule, it only needs to store one event (but would still need to 
transmit the full set when interacting).

> not the whole chain of vevents.

Yes, it certainly has some advantages (eg it requires small 
transactions). But it also has major disadvantages which where already 
pointed out.

> (but complete) RRULE language.

The choice to be made is whether rrules are supported in the basic 
draft or not. If you do, you also need to provide full timezone 
support, so the draft will get quite complex (not significant gain to 
what we have now).
Of course you could (and probably should) still restrict the rrule 
language if the choice goes for the latter.

Greets,
   Helge

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Feb 11 10:57:23 2005

> client. If it supports the rrule, it can show proper UI for changing

Yes, but the problem is that the list of RDATEs is not only the result from 
the RRULE, but it might also contain additional dates, which are already in 
the "old" RDATE list according to rfc2445. 

E.g. if a file contains:
DTSTART:20050109T070000Z
RRULE:FREQ=WEEKLY;BYDAY=SU;COUNT=2
RDATE;VALUE=DATE:20050109,20050116,20050216

Then the recurrence rule is every sunday, but the rdate list also contains an 
additional occurrence on Feb 16. So one in the GUI one has to check each of 
the dates in RDATE if it was generated by the RRULE, or if it is an 
additional occurrence. Such additional occurrences would need to be edited 
differently (like exception dates).

Reinhold

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050211/6d6c7fd5/attachment.bin

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Fri Feb 11 11:09:25 2005

On 11. Feb 2005, at 19:57 Uhr, Reinhold Kainhofer wrote:
> additional occurrence on Feb 16.

If this is a real world problem (say: more than one, non-MS 
implementation actively uses this construct), we obviously need some 
solution to this (eg a seperate field for one or the other).

Greets,
   Helge

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Fri Feb 11 12:12:41 2005

Helge Hess wrote:
> Thats a rather weird statement. Why can't you use the extensions? If the 
> "other" client supports them, he will have additional information, if 
> not, he will fall back to the base spec.

Let's assume that timezones move to an extension. The client i use 
supports them. So, the start time of en event is defined with a 
timezone. I publish the calendar. (upload the whole ics file). Someone 
else reads it using a client that doesn't support timezones. How can he 
fall back? he has to ignore the timezone information, because he doesn't 
understand it. He can either use the time in the wrong timezone, or 
ignore the time completely. Both is wrong.
So, if i want my calendar to be readable by other clients, i can't use 
timezones.
The same story would hold for other extensions.

Michiel

---

From: helge.hess at opengroupware.org (Helge Hess)
Date: Fri Feb 11 12:29:03 2005

On 11. Feb 2005, at 21:12 Uhr, Michiel van Leeuwen wrote:
> timezone.

No, the start time would still be defined in UTC, the timezone would be 
added as a hint (actually a required one for the rrules extension).

> I publish the calendar. (upload the whole ics file). Someone else 
> reads it using a client that doesn't support timezones. How can he 
> fall back?

See above, the times will always be in UTC, the timezone is additional 
information. So its a non-issue.

> he has to ignore the timezone information, because he doesn't 
> understand it.

Yes, and it won't hurt since the time value is always in UTC, there is 
no reason to do it otherwise. We only transport timezone information to
a) add information for editors/viewers
b) to allow for rrules

You seem to miss the reasons when and why timezones are required in the 
protocol/format? I'm somewhat surprised about that, since exactly this 
was discussed only some weeks ago including some details on how this 
could be done format-wise.

> He can either use the time in the wrong timezone, or ignore the time 
> completely. Both is wrong.

Yes, because your assumptions is wrong. To be up/downwards compatible 
timevalues would always be in UTC.

> The same story would hold for other extensions.

Of course extensions must be properly done to be compatible, but so far 
both discussed items can be easily done as extensions while still 
providing downwards compatibility AND provide the same functionality 
like before.

BTW: we do not talk about timezone awareness in the client, this has to 
be available in any case. This is only about including timezone 
information in the protocol entity which is only required for 
recurrences and to one kind of allday appointments (as far as I can 
see).

Greets,
   Helge

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Feb 11 12:50:24 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050211/ebcd1ade/smime.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Feb 11 13:00:24 2005

> The same story would hold for other extensions.

Not with the ideas as proposed. The idea was to send out the data
expanded (into multiple components or RDATEs - in UTC) and
optionally also send the extension object unexpanded (w/ timezone info).

For PUBLISH and most scheduling the expanded objects work just fine
as they have to work with RDATEs right now anyway.

Only when you want the recipient to understand the GUI user had clicked
on weekly (or whatever) do you need to send out the recurrence rules.

If you wish to synchronize entire objects including the ORGANIZERS
intent, then you do care about the recurrence rules. If you doing
scheduling with others - you just care if they can attend the
instance times.

In most cases, I do not visually check the recurrence rules in
the GUI or ICS file, I just look at when it places dates in
my calendar, or what any accompanying descriptive text sent
in an associated MIME object says about the meeting.

If a weekly meeting notice were sent out for one years
worth of time and it had 10 exception dates in it. How many
of you look at the GUI recurrence panel to see it? Many of
the GUI's out there can not display such objects even when
they can add them correctly to your calendar.

-- 

Doug Royer                     | http://INET-Consulting.com
-------------------------------|-----------------------------

               We Do Standards - You Need Standards

-------------- next part --------------
A non-text attachment was scrubbed...
Name: Doug.vcf
Type: text/x-vcard
Size: 293 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050211/ed8992ef/Doug.vcf

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Fri Feb 11 15:05:54 2005

> optionally also send the extension object unexpanded (w/ timezone info).
Ok, i was more thinking about extensions in general. The two proposed 
extensions indeed have a fallback. Also, i was more thinking about the 
current usage of timezones in dtstart.

So for every extension there must be a fallback.

> on weekly (or whatever) do you need to send out the recurrence rules.

Yeah, and that is important imho. First because of the infinite 
recurring events. (Yes, i know they will end one day, but you don't know 
that end date. i'm still not happy with forcing the user to come up with 
some value, or to add a magic number)
Second, for data exchange. I'm thinking about the way sunbird handles 
sharing a calendar here. You don't want to lose the recurrence 
information the next time you open the file.
Also, in real-life i'm thinking as an appointment as something 
recurring, not as a list of dates. removing that information requires 
the client to show a nice visual list to make it possible for the user 
to see the relation (every monday). If i know it is every monday at 10, 
I just need to check my weekly schedule to see if it fits for me. 
Without the information, i need to check every week. (this can be 
automated of course, but that depends on the user putting everything on 
his calendar. Again forcing the user to do something to make the spec a 
bit less complex)

Michiel

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Feb 11 15:23:23 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050211/6b84b946/smime.bin

---

From: pregen at egenconsulting.com ([email-masked])
Date: Fri Feb 11 15:24:49 2005

Helge, I think it's a pretty safe bet that the vendors you stated in your 
note do not 100% support the rrules  icalendar specs - I'd be surprised if 
they did 50%.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

Helge Hess <[email-masked]> 
Sent by: [email-masked]
02/11/2005 12:04 PM

To
[email-masked]
cc

Subject

Greets,
   Helge

---

From: TimHare at comcast.net (Tim Hare)
Date: Fri Feb 11 17:27:59 2005

Wow - I do seem to have a penchant for stirring up discussion!

I admit, here, that I probably went too far with the simplification idea. I 
still really want to see UTC as the common exchange time format, but I can 
see the point of retaining some RRULE idea.

Some of the ideas / discussion in response bring out an important (to me) 
point:

Calsify / iCal-Basic is about finding that least common denominator point 
that everyone can agree to implement so that users do not have to worry 
about their publishing or scheduling of events being accepted. As an 
individual user, I want calendaring to be just as simple as e-mail is now - 
there must be a set of functions that I can reasonably expect to be there 
in any calendaring tool I use. I don't want to stop and think about it, I 
just want to create the event/meeting/whatever and click 'OK'

Do we have any way to determine what this common set of functions is right 
now? Do the Interop reports from Calconnect give us enough information (yet)?

Tim Hare
Interested Bystander, Non-Inc.

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Sat Feb 12 01:35:03 2005

Am Samstag, 12. Februar 2005 00:23 schrieb Doug Royer:
> > ... I'm thinking about the way sunbird handles
> People and applications use ICS files as their cal store,
> however iCalendar was not designed as a file store. Trying to
> make it do both is part of the problem. You end up with
> everything everyone needs.

You already need everything everyone needs for simple data exchange like 
drag'n'drop!  And iCalendar was designed for exactly these kinds of thing (at 
least that's how I understand the intro).

Reinhold

-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, 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 / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050212/745f149b/attachment.bin

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Sat Feb 12 01:39:52 2005

> individual user, I want calendaring to be just as simple as e-mail is now -

Hehe, you chose the wrong example here. Do you know how complex the 
specification for email is (in particular the mime spec and all the various 
encodings possible)? iCalendar is trivial compared to those specs... 

Just because something appears simple to the user, doesn't mean that the 
specification behind it is simple. Most times I think it's just the 
opposite... 
Reinhold
-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna, 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 / KPilot maintainer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050212/3187e1ca/attachment.bin

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Feb 12 12:14:37 2005

Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050212/bac35c25/smime.bin

---

From: pregen at egenconsulting.com ([email-masked])
Date: Sun Feb 13 08:41:25 2005

Ditto to your thoughts Tim (from another end-user).  As for the lowest 
subset, that's what the Min-IOP technical committee is working on in the 
consortium.  I actually owe them a document that "sort of" shows what has 
worked over the last several interops.  It's a start - but not complete.
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

Tim Hare <[email-masked]> 
Sent by: [email-masked]
02/11/2005 08:26 PM

To

Subject

I admit, here, that I probably went too far with the simplification idea. 
I 
still really want to see UTC as the common exchange time format, but I can 

individual user, I want calendaring to be just as simple as e-mail is now 
- 

now? Do the Interop reports from Calconnect give us enough information 
(yet)?

Tim Hare