Subject: [Ietf-calsify] Comments on radical simplification and bumping the version

From: TimHare at comcast.net (Tim Hare)
Date: Fri Feb 11 16:56:58 2005

if:  The components and properties presented by a radically simple 
implementation are a subset of iCalendar, so current implementations 
_should_, if they are compliant, be able to accept these items.

and

if: Sending items to a radically simple implementation means that 
components and properties which are not part of the radically simplified 
set should not be sent, or should be sent only as an alterative representation

then: there needs to be a way for current implementations to know what 
they're exchanging items with so they can  send only the simple subset
or: they send two representations and recipients use what they can deal with

Since sending two representations is kind of expensive (but as Nathaniel 
pointed out, in this age of BitTorrent, who would notice?), a version n 
identification would seem to be the better solution. I don't agree with 
using VERSION: 3.0, however.  To me, it makes more sense for the radically 
simple versions to be VERSION: 1.5  - i.e. more than vCalendar and less 
than the current iCalendar.

Tim Hare
Interested Bystander, Non-Inc.

Tim Hare
Interested Bystander, Non-Inc.

---

From: Doug at Royer.com (Doug Royer)
Date: Fri Feb 11 17:04:03 2005

> using VERSION: 3.0, however.  To me, it makes more sense for the 
> radically simple versions to be VERSION: 1.5  - i.e. more than vCalendar 
> and less than the current iCalendar.
> 

The iCal VERSION property takes a range. So we could do:

	VERSION:2.0,2.1

	VERSION:2.0.3.0

	....

That could mean that the sender supports a newer version
and understands the old.
-- 

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

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Sat Feb 12 05:03:21 2005

> _should_, if they are compliant, be able to accept these items.

I got a question about the simplification. Some of the simplifications 
are not compatible with the current spec. (like the way timezones are 
supposed to be moved to an extension. Even with the extension you still 
must store the start time in utc)
On the other side, there is talk about seeing what current clients can 
do, and remove the rest from the spec.
But if the spec will not be compatible, why look at current client? Why 
not start from the start, and see what you would need to do good 
calendaring, instead of looking at the bugs in current clients.

Michiel

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Feb 12 12:24:18 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/20050212/1706468e/smime.bin

---

From: elias at cse.ucsc.edu (Elias Sinderson)
Date: Sat Feb 12 12:45:26 2005

Doug Royer wrote:

> [...] As far as I can tell the only noticable issue is infinate 
> recurring entries. So could we add a propertry or parameter that says, 
> "and
> there are more so when you run out - send a METHOD:REFRESH to get the 
> next year (or whatever) of them" ?

Given the following:
(a) infinitely recurring meetings aren't really infinite and
(b) people don't last forever anyway
FWIW, the weekly project meetings I've been involved with for the 
several years get shuffled about more than once per year to adjust to 
other scheduling constraints, and I believe this is fairly typical. The 
only things which don't really get shuffled about are things like 
holidays...

Would it be reasonable to deprecate infinitely recurring events and 
place an upperbound of, say, one year on recurring entries? This 
approach seems more reasonable than adding additional methods to the 
base spec, since no existing clients currently implement any methods 
that are added to the spec.

Cheers,
Elias

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Sat Feb 12 12:58:21 2005

Elias Sinderson wrote:
> place an upperbound of, say, one year on recurring entries? 

I think it isn't such a great idea, becasue one year is a magic number. 
Why one year, and not two years?

Michiel

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Sat Feb 12 13:01:42 2005

Doug Royer wrote:
> It is my belief that any iCal-Basic object can be understood by
> all current iCalendar implementations. If not, PLEASE point out
> why not.

Yes, it can. (except for the suggestion i've read to move timezone 
information to the rrule)
But a new client will still have to be able to read the 'old' ical type 
events. Because they can receive them. Users won't accept it if a new 
client will not be able to accept events from older clients.
So i think that removing things from the spec won't make writing new 
clients any easier.

Michiel

---

From: Doug at Royer.com (Doug Royer)
Date: Sat Feb 12 13:49:33 2005

> information to the rrule)

What move?

> So i think that removing things from the spec won't make writing new 

True in the short term, however over time the old formats will 
disappear. Just like most implementations no longer support
the XCS calendar format (pre-iCalendar/vCalendar) any more.

And as there is just as much chance that a new implementation will find
yet another way to correctly represent what the current implementations
correctly and differently represent.

Many years ago when SMTP was coming out, there was a rule that went
something like, "Be generous in what you accept, and  conservative in
what you generate". For the most part we can read each others
email. 20 years ago you could read it, but it sometimes had odd stuff
in it from pre-SMTP mailers (Like UUCP email addresses).

I agree with what you are saying. However the current status is not
quite working and yet MUCH closer than pre-iCalendar. I think (And
PLEASE point out where I am wrong) that for NON-scheduling that
iCal-Basic is close if not right on.

-- 

-------------- 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/20050212/7f0b8f54/Doug-0001.vcf

---

From: pregen at egenconsulting.com ([email-masked])
Date: Sun Feb 13 09:17:03 2005

Michael, I think you have hit on a key issue here.  Interestingly enough, 
there was never a "requirements" document established to use as a guide 
for the three RFCs (2445, 2446, 2447).  One was created for CAP but not 
for these three.  The reason for this, I believe, was because there was 
already a base of document established prior to these RFCs.  The original 
CALSCH charter quoted the following documents for use as input to these 
drafts:

* Distributed Scheduling Protocol (CHRONOS) IETF Working Group 
* ISO/IEC SC18 Distributed Office Application for Calendaring, Scheduling 
and Appointments 
* MHS Alliance Calendaring and Scheduling Interoperability Protocol (CSIP) 

* X.400 API Association (XAPIA) Calendaring and Scheduling API (CSA) and 
Calendaring and Scheduling Interoperabilty Specification (CSIS) 
* X/Open Consortium Calendaring and Scheduling (XCS) Implementor's 
Specification 
* Versit vCalendar format 

I figure if people want to go find these original documents, they can try. 
 I have yet to find a full copy of the XAPIA document, which, I believe, 
is a pretty good start for a stab at requirements.

I don't know if you all will find this helpful, but in the past, I have 
held several surveys with organizations to monitor what people wanted in a 
calendar application.  This may help steer people towards some components 
that should be in a standard.  It won't help with the nitty gritty and 
details of how to describe events, timezones, and such, but it does show 
the kinds of things people want to see in a calendaring app.  Please be 
aware that this document needs to be updated to include what users want in 
today's webcentric environment. 

http://www.egenconsulting.com/calreqs.htm
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

Michiel van Leeuwen <[email-masked]> 
Sent by: [email-masked]
02/12/2005 08:03 AM

To
[email-masked]
cc

Subject
[Ietf-calsify] Re: Comments on radical simplification and bumping the 
version

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

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Sun Feb 13 13:51:05 2005

>> information to the rrule)
I though i have seen a suggestion to put the timezone information on the 
rrule instead of the starttime. But that is not my main point.

>> But a new client will still have to be able to read the 'old' ical 
>> type events. 
> 
> disappear.

I'm afraid that short term can be pretty long. For example, look at the 
web. It is full of 'old' documents, full of quirks etc.

> what you generate". 

What I think we need is a list of what you can safely generate. This 
would be some recommendation. "if you want to do publishing, you can use 
this subset. if you do scheduling, you can do this (possibly other) 
subset. if you do generate something that isn't on the list, you are not 
violation the spec, but might have problems with interop".
This list would be based on the current clients. If you don't care about 
other clients, you can use everything from ical.
The current list would pretty much look like ical-basic. In the future, 
it might be expanded. If the majorty of used clients would someday 
safely understand rrules, the list can be updated. But the real spec 
won't change!

Michiel

---

From: Doug at Royer.com (Doug Royer)
Date: Sun Feb 13 14:33:41 2005

> rrule instead of the starttime. But that is not my main point.

No. No move at all. For recurrence rules things are the same.

I am just suggestion that for bound recurrences, it might not be
necessary to convey anything except RDATEs. So everything can
be in UTC. So I think we need to make a rule:

	For bound recurrences - use UTC and RDATEs
	and never use RRULE or EXRULE.

The above works for published, scheduled, and data-exchange of
bound recurrences. I think that covers a huge percentage
of calendar entries.

And I am suggesting that unbound recurrences might not ever
need to be used. Just pick some upper bound and let
people look. So everything can be in UTC. I do not think
that we need to define the upper limit, that will be application
dependent.

People do not really want time zones, they just want it to work.
And they want to tell their GUI that it is at 2pm in FOO time zone.
They do not care if the GUI converts it to UTC before distributing
a bound recurrence.

Unbound recurrences - that is 'I think', the only real issue left.
And if we really need them, lets reduce RRULE to what is used
and needed. (SECONDLY, MINUTELY - are they used ?)

>> True in the short term, however over time the old formats will disappear.
> 
> 

I think that is what I have been proposing.

> safely understand rrules, the list can be updated. But the real spec 

Yes, I think we agree.

For some reason vendors seem reluctant to describe the recurrence rules
they generate. You can play with their GUI and determine if they
support weekly or what ever. Is what you can not tell from their GUI
is how they make up RDATE, EXDATE, RRULE, and EXRULE.

For example:

	Some never generate EXRULE (do any?) they just generate EXDATEs.

	Some never generate RRULE's, they use RDATE and bound them to
	an upper limit.

	Some never really update their RRULE, they just add RDATEs
	and EXDATEs.

So, the trick with scheduling is going to be to find that acceptable
list of how to generate recurrence rules. So far the large vendors
are not talking. So we have to reverse engineer (not accurate), or
look at their features, propose something, and see if they scream :-)

-- 

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

---

From: mvl at exedo.nl (Michiel van Leeuwen)
Date: Sun Feb 13 15:02:19 2005

> No. No move at all. For recurrence rules things are the same.

I expressed myself poorly. I remember someone making the suggestion to 
move. I think it wasn't accepted. The fact that it isn't backward 
compatible would be a very good reason to not accept it.

>> would be some recommendation. "if you want to do publishing, you can 
>> use this subset. if you do scheduling, you can do this (possibly 
>> other) subset. if you do generate something that isn't on the list, 
>> you are not violation the spec, but might have problems with interop".
> 

The proposal was a new spec, which is the old spec with some thing 
removed. What i am suggesting is to keep the old spec, but create a 
best-practices document. That would include what not to use, and how to 
do certain things (for every use-case of iCalendar). (expand a recurring 
event into rdates, don't use exrule etc)

If some client decides to generate exrule anyway, it isn't violating the 
spec. It is just not a good showing nice behaviour.

Michiel

---

From: ellmann at wisc.edu (Curt Ellmann)
Date: Mon Feb 14 08:03:43 2005

I agree that one year is too short-- what is the problem with infinitely
recurring events?  There are plenty of examples of events that are
infinitely recurring-- holidays, anniversaries, and other celebrations.

-curt.

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Michiel van
Leeuwen
Sent: Saturday, February 12, 2005 2:58 PM
To: [email-masked]
Subject: [Ietf-calsify] Re: Comments on radical simplification and bumping
the version

Michiel

---

From: elias at cse.ucsc.edu (Elias Sinderson)
Date: Mon Feb 14 08:44:17 2005

>infinitely recurring-- holidays, anniversaries, and other celebrations.
I only suggested one year as a matter of conjecture - the limit could be 
five years, or ten, for that matter, as long as there is a limit which 
allows a /finite/ expansion of recurring events. Note that this was in 
response to Doug Royers observation that "the only noticable issue is 
infinate recurring entries." I will also note that the cannonical 
examples provided for infinitely recurring events have been all-day 
events, which do not suffer from the timezone issues that have been 
identified. As per Dougs' suggestion, the inclusion of a property which 
indicates that a METHOD:REFRESH should be done in the future seems like 
a good idea; simply a way to say 'and so on' or 'sync again later'. I 
cannot think of a situation where a client would need to get the 
infinity of recurrences in a single sync and not be able to sync again 
in the future. Further, regarding the question of the duration placed as 
an upper bound, allowing any given implementation to set its' own upper 
bound on recurrences rather than having it rigidly declared in the 
specification would make it possible for devices with limited profiles 
to play along as well.

It may be useful to step back from this issue for a minute and try to 
identify use cases that require scheduling of recurring events (or any 
event), e.g., five years out. Neither Hotels nor airlines will allow one 
to place reservations that far in advance. The most difficult restaraunt 
to dine at in California (French Laundry) only takes reservations 
several months (4?) out. Business meetings are never arranged in this 
matter, and it only seems a matter of convenience to say that this 
meeting will recur infinitely rather than specify an end date several 
years away. As I mentioned before, even so called 'infinitely recurring' 
weekly project meetings are (semi)regularly rescheduled to accomodate 
attendees constraints and other recurring meetings that are scheduled. 
If anyone can provide a use case which requires an infinitely recurring 
event which is not an all day affair (such as holidays, birthdays, 
anniversaries, etc.), please provide it. Extra credit will be given if 
it isn't some freaky and contrived edge case, but occurs frequently 
enough that it would be an honest inconvenience to a user to schedule 
seperate events.

Deprecating infinitely recurring events and placing a sensible upper 
bound as suggested would allow recurring events to be represented as 
either a RRULE or as a finite sequence of events, and would sidestep the 
issues related to timezones that have been raised previously on the 
list. It would seem that the benefits of this simplification greatly 
outweigh the downside of rescheduling a meeting every couple years (if 
it lasts that long) or similar. Further, if RRULEs become an optional 
part of the specification, as has been suggested before, this approach 
would allow interoperability where one system implements RRULEs and the 
other doesn't, as there won't be a problem in an infinite expansion of 
events.

Cheers,
Elias

---

From: lennox at cs.columbia.edu (Jonathan Lennox)
Date: Mon Feb 14 09:16:31 2005

On Monday, February 14 2005, "Elias Sinderson" wrote to "[email-masked]" saying:

> allows a /finite/ expansion of recurring events.

One only semi-tongue-in-cheek suggestion would be "no events past POSIX
time_t 0x7fffffff" (Tue Jan 19 03:14:07 2038 UTC), as such events would I
imagine cause interoperability problems anyway.

> Note that this was in 
> identified.

Note that the Call Processing Language (RFC 3880) normatively cites
iCalendar's RRULE specification, and the usage there has need for rules like
"working hours", e.g. "9 am - 5 pm Monday - Friday".  Any CPL revision would
want to cite a future full RRULE spec, though, not iCal-basic.

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu