[Ietf-calsify] Re: What's wrong with more radical simplification?
Doug at Royer.com
Fri Feb 11 10:50:17 PST 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
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
Doug Royer | http://INET-Consulting.com
We Do Standards - You Need Standards
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 293 bytes
Desc: not available
Url : http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20050211/a6f468ed/Doug.vcf
More information about the Ietf-calsify