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

[Doug Royer]

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