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

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Thu Feb 10 11:12:38 2005

Saint Peter,

With all due respect, I believe we can too.  But who will remove this
functionality from their parsers? Who will degrade their iCal generators
to begin unrolling recurrences?  I don't see it happening for this
generation.  

A new standard that includes less maybe - just like a new standard that
includes more (as some have suggested we pursue) - would be a viable
alternative to newcomers, assuming it provided 'enough' functionality
for their purpose.  

"For every problem, there is a solution that is simple, neat, and
wrong."
H. L. Mencken

/cds

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Peter
Saint-Andre
Sent: Thursday, February 10, 2005 9:37 AM
To: [email-masked]
Subject: [Ietf-calsify] Re: What's wrong with more radical
simplification?

In article <[email-masked]>,
 Nathaniel Borenstein <[email-masked]> 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.

+1

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

/psa

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

---

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Fri Feb 11 01:24:11 2005

What you are suggesting is that representing a simple example like "once
a week every Wednesday" would be a list of individual vevents (perhaps
with exceptions) and that the recipient somehow reverse engineer that
collection into the original rule? This is more than separating the data
from the UI, it's obscuring it completely.  This puts a very heavy
burden on clients who don't want to represent recurrences like a huge
list of events.  This would limit the UI vendor fairly severely, it
seems.

cameron

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Tim Hare
Sent: Thursday.10.February.2005 21.02
To: Michiel van Leeuwen; [email-masked]
Subject: Re: [Ietf-calsify] Re: What's wrong with more radical
simplification?

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:
>Nathaniel Borenstein 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

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Feb 11 10:50:33 2005

PUBLISH vs Scheduling vs Data Exchange.

    And the so called infinitely recurring appointment is an excuse
    we use when we really do not know the end date. No meeting
    lasts forever. At some point no one will care about our
    birthday.

For PUBLISH calendars:

    Most of the time you do not care. If it is a PUBLISH then there
    is no scheduling anyway. (And most implementations put their
    calendars on URL's without a METHOD property any way - so there
    really can not be scheduling).

    As for reverse engineering the RDATEs back into recurrence
    rules. For PUBLISH calendars I do not think that I do go to the
    recurrence tab and look at the recurrence rule. I just
    look at my screen and notice that it is every Tuesday at noon.
    And visually notice the exceptions.

    And a large percentage of implementations do not do scheduling,
    they just post or email non-iTIP calendars to some URL.

    If I post my personal calendar a year in advance, is that
    not sufficient as it really will be updated anyway? Two years?
    Why will RDATE's not be sufficient?

For Scheduled calendars:

    Again, is not one or two years sufficient? If not - why?

    Cameron is right, the first thing we do when scheduling
    is compare the instance times, not the recurrence rules.

    If I get a scheduling request that just happens to be
    every Tuesday at noon, I can simply look at the screen
    and notice the times. Later if an important customer
    wants to meet on a Tuesday at noon. Do I care about
    the recurrence rules? No, I look and my screen, notice
    that my standard Tuesday noon meeting is in the way
    and I say yes to the customer anyway. And I let
    the GUI sort it out.

For Data Exchange:

    This is when we need to be able to transfer the information
    about the intent of the ORGANIZER. This is when recurrence
    rules matter.

-- 

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/a6f468ed/Doug.vcf