Subject: [Ietf-calsify] Recommendations for stripping down iCal to a manageable 'standard'

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Mon Aug 16 17:35:18 2004

I think it's about time to get this party started...

The following is a list of my personal recommendations for altering iCal
as it exists today in order to limit the scope of implementation and
bring it to a level that is suitable for widespread implementation:

0) New Name

Let's not put new wine in old bottles.  I recommend we call this the
"eCal" standard, short for "electronic calendar".  I like this better
than sCal or qCal, mostly because it expresses a similarity to eMail,
and I believe one of our stated goals (at least verbally) is to bring
calendaring out of obscurity and into the ubiquity of electronic mail.  

1) Clarify Purpose

I think it is critical to our success that we make it very clear what
the purpose of such a calendaring standard is.  My proposal is that our
mission here is to define a method and way to schematize Calendar data
for personal and/or group scheduling.  We want to be able to represent
electronically the kinds of data people store in planners, organizers,
wall calendars, and other types of time management and organizational
tools.

1.1) Limit Schema Support

As a non-goal, I suggest that our purpose is NOT to define a schema for
all types of PIM data -  specifically, journal items, task items, etc.
Other data types like those mentioned should be specified in OTHER
standards.  This means removing VJOURNAL and VTODO from this document.

1.2) Limit Data Support

I further recommend that it is NOT our goal to define a time/date schema
that is necessarily universally applicable.  Non-calendaring
applications may require more granular or more broad time-based
calculation, but these are beyond the scope of this work.  More
specifically, this standard will not necessarily support managing
time-based or scheduling information in the sub-minute or multi-century
scope.

1.3) eCal Scale

It has also been recommended that the standard be limited to "Gregorian"
calendar support.  I suggest that other types of calendars will require
different schemas and should therefore be handled in different
standards... IF they are desirable in the future.  This standard should
deal exclusively in Gregorian dates, in my opinion.

2) Simplify recurrences

Nathaniel suggested in San Diego a rather severe approach which included
doing away completely with recurrence rules.  While I applaud his
ability to think outside the box, I believe that the problem is not
necessarily the existence of recurrences that causes a problem, but the
ability to specify recurrences that don't make sense or that are beyond
the scope of the problem.

I recommend that we remove the recurrence BY*'s that are not applicable
to PIM data.  I think those are: BYHOUR, BYMINUTE, and BYSECOND.

I also recommend that we disallow multiple BY*'s in one FREQ.

2.1) Better examples

I believe that the example in the spec of "every Sunday in January at
8:30:00 AM and 9:30:00 AM, every other year" is heinously contrived and
should be expunged. I do, however, think that we should show examples of
commonly used recurrences that span the bulk of the valid recurrence
equations.  Perhaps this belongs in a different doc... Do we need a
"calendaring profiles" informational RFC that tells application
programmers how to implement standard types, and perhaps even provides
regular expressions for implementing reasonable parsers?  I've always
thought that format specifications should require actual regular
expression code that shreds it. 

3) Simplify exceptions

Exceptions are an important principle in calendaring, but they can be
problematic if they are not handled cleanly.  One of the reasons why
exceptions are so difficult in the current proposed standard is that
exceptions can be specified as recurrences themselves.  Therefore
exceptions inherit all the problems of recurrences squared.

I propose that exceptions be exclusively one-off events, never
recurrences themselves.  I believe this simplifies exceptions to a point
that allows them to be implemented in a rational way.  I think this also
makes recurrences much more palatable (see item 2 above) while not
killing them off completely.

4)  Remove useless properties

For example:

GEO = Geographic Position (?)
Does anyone use this? Does anyone think they will ever specify the lat
and long of their next team meeting?  I don't understand the purpose of
this, since we have such great time zone support?  What could a client
ever reasonably do with this information?

5) Compatibility

Fortunately or Unfortunately, there exist lots of iCals out there in the
world wide web thingy - while we may not like the way they do things, it
would be very naughty of us to declare everything they do as
non-standard.  I think we should be somewhat cautious about our removals
at least to the degree that we do not severely cripple the large
existing data that is stored on sites such as eventsherpa and icalshare.
This will also help our ultimate goal which is (in this small scope) to
bring this draft to standard.

Why don't we start with this as a means for discussion.

Let it begin...

cameron stillion
<[email-masked]>

---

From: Doug at Royer.com (Doug Royer)
Date: Mon Aug 16 18:17:01 2004

And it iTIP simplification in scope?

>time-based or scheduling information in the sub-minute or multi-century
I do not follow the above item. Are you saying do always with 
YYYYMMDDTHHMMSS
in iCal?

I do not see how SS adds too much. How about for compatibility we just 
say that SS
is optional and if not supplied equals zero?

>deal exclusively in Gregorian dates, in my opinion.
Yes!

>2) Simplify recurrences
Remove multiple BY's in one rule - yes.

In iTIP all same SEQ/UID items are the same object. Complex recurrences
can be represented the same now by providing multiple objects each with
simple recurrences and all with the same UID. No need for those complex
recurrence rules.

>killing them off completely.
Yes.

>4)  Remove useless properties
Deprecate - GEO - yes. The were added when GPS's were new and
everyone thought it would be a great addition.

>bring this draft to standard.
Some of the ideas in CAP should also be transferred over.
NAME, DESCRIPTION, and LOCALE of the calendar just to name a few.

When you look at the large number of free calendar .ICS files, they all seem
to have several vendor extensions in common that they all add. Such as
their version of the time zone of the calendar.  CAL-ID , CAL-URL.

Just to start a thread.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

-------------- 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/20040816/9ce3d31c/smime.bin

---

From: elias at cse.ucsc.edu (Elias Sinderson)
Date: Mon Aug 16 21:53:47 2004

Doug Royer wrote:

> Cameron Stillion wrote:
>
>> 1.2) Limit Data Support
>> I further recommend that it is NOT our goal to define a time/date 
>> schema that is necessarily universally applicable [...] this standard 
>> will not necessarily support managing time-based or scheduling 
>> information in the sub-minute or multi-century scope.
>
> YYYYMMDDTHHMMSS in iCal?
> say that SS is optional and if not supplied equals zero?

SS must at least be optional as there are many applications which 
require sub-minute scheduling. (Scheduling satellite communications 
windows is a primary example of this.) Developing a standard that leaves 
out the concerns of aerospace and defense applications is, IMHO, an 
illformed mission to embark upon. It is honestly no more difficult to 
handle SS than it is to handle MM and, as I said, should at least be 
optional (SHOULD) if not outright required (MUST).

>> 1.3) eCal Scale
>> It has also been recommended that the standard be limited to 
>> "Gregorian" calendar support.  I suggest that other types of 
>> calendars will require different schemas and should therefore be 
>> handled in different standards... IF they are desirable in the 
>> future.  This standard should deal exclusively in Gregorian dates, in 
>> my opinion.
>
> Yes!

A reasonable simplifying assumption that will cover most cases. However, 
I would like to advance the notion that the specification should provide 
a mechanism for defining other calendars in terms of standard units, 
e.g. by specifying a multiplier to 'stretch' / 'compress' seconds, or 
redefine the number of days in a 'year'. In the absence of such 
definitions, the Gregorian calendar should obviously be the standard 
default that is used. Again, prime examples include NASA mission 
scheduling requirements as well as other non-Gregorian, Earth-based 
calendars, which 'begin' prior to year '0'. To simplify client and 
server development, support for non-gregorian systems should be 
optional, but specifying the mechanism for this would be a benefit in 
that people wouldn't go off and define ad hoc and incompatible methods.

>> 2) Simplify recurrences
>
> Remove multiple BY's in one rule - yes. In iTIP all same SEQ/UID items 
> are the same object. Complex recurrences
> can be represented the same now by providing multiple objects each 
> with simple recurrences and all with the same UID. [...]

I would provisionally agree, although I would like to see a formal proof 
that one can achieve the same recurrences using the simplified approach.

>> recurrences themselves. [...]
>
> Yes.

Agreed.

> Deprecate - GEO - yes. The were added when GPS's were new and everyone 
> thought it would be a great addition.

Agreed.

>> 5) Compatibility
>> Fortunately or Unfortunately, there exist lots of iCals out there in 
>> the  world wide web thingy - while we may not like the way they do 
>> things, it would be very naughty of us to declare everything they do 
>> as non-standard.  I think we should be somewhat cautious about our 
>> removals at least to the degree that we do not severely cripple the 
>> large existing data that is stored on sites such as eventsherpa and 
>> icalshare. This will also help our ultimate goal which is (in this 
>> small scope) to bring this draft to standard.  
>
I have mixed feeling regarding this. In general, I agree with you in 
principle, it seems clear that it is folly to try and import everything 
into this standard. Hence, it is also clear that some existing things 
will be broken (i.e. non-compliant). So, while commendable, I feel that 
we can only regard other non-standard calendaring schemes as just that. 
Yes, we should make an attempt to include what they have gotten right 
but let's not lose the path ourselves simply to save a few lost sheep.  :-)

Regards,
Elias

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Aug 17 10:24:57 2004

Elias Sinderson wrote:

>>> future.  This standard should deal exclusively in Gregorian dates, 
>>> in my opinion.
>>
>
> A reasonable simplifying assumption that will cover most cases. 
> However, I would like to advance the notion that the specification 
> should provide a mechanism for defining other calendars in terms of 
> standard units, e.g. by specifying a multiplier to 'stretch' / 
> 'compress' seconds, or redefine the number of days in a 'year'. In the 
> absence of such definitions, the Gregorian calendar should obviously 
> be the standard default that is used. Again, prime examples include 
> NASA mission scheduling requirements as well as other non-Gregorian, 
> Earth-based calendars, which 'begin' prior to year '0'. To simplify 
> client and server development, support for non-gregorian systems 
> should be optional, but specifying the mechanism for this would be a 
> benefit in that people wouldn't go off and define ad hoc and 
> incompatible methods. 

Those can be separate drafts.

>>> 2) Simplify recurrences
>>
>>
>> Remove multiple BY's in one rule - yes. In iTIP all same SEQ/UID 
>> items are the same object. Complex recurrences
> I would provisionally agree, although I would like to see a formal 
> proof that one can achieve the same recurrences using the simplified 
> approach.

In the simplest form, each of the multiple objects has exactly one 
date/time and
no RRULE.  Now add simplified RRULEs. I can not think of any set of entries
that can not be represented.

>>> 4)  Remove useless properties 
Also 'RELATED-TO' is value is vendor specific and unusable as documented.

The purpose of iCal is to allow for the transfer of information between 
vendors.
A property that is specifically unspecified is not useful.

-- 

-------------- 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/20040817/cf53422a/smime.bin

---

From: Chris_Stoner at notesdev.ibm.com ([email-masked])
Date: Tue Aug 17 11:31:19 2004

> optional (SHOULD) if not outright required (MUST).

I agree.  I'd like to see consideration of Seconds as at least optional.
We might have a good example of this being necessary where the application
is not message-based, but instead builds a queue.  Given that, in order to
use DTSTAMP appropriately, they might need seconds in the time/date.

> >> future.  This standard should deal exclusively in Gregorian dates, in

Why was this put into the standard in the first place?  Does anyone
remember?

Will respond to the Recurrence part separately.....
-Chris Stoner

---

From: Chris_Stoner at notesdev.ibm.com ([email-masked])
Date: Tue Aug 17 11:31:25 2004

> calendaring out of obscurity and into the ubiquity of electronic mail.

Is there any worth to keeping "iCal"?  Some companies have adopted iCal as
a standard even if it's not in Draft state yet, and we might do well to
build off of that branding so to speak?

> standards.  This means removing VJOURNAL and VTODO from this document.

Journal at least should go.  I agree with that.  To Do's, well, I'm
hesitant to agree that they should go.  What are To Dos?  They tend to act
like just a special meeting type, so maybe they do fit in here.  In
Berkley, we discussed another option - why not have To Dos as a "should"
but require that if the vendor does not support To Dos, to respond with
that to the sender.

> deal exclusively in Gregorian dates, in my opinion.

Should this just be removed then?  Or have the vendor specify a default of
"Gregorian", giving the option of extending it in the future?

> I also recommend that we disallow multiple BY*'s in one FREQ.

I disagree.  I think Rules should go.  Why not take out the complexity of
recurrences and have the standard dictate that the vendor must send a list
of dates, and optionally send a recurrence rule (for UI purposes or maybe
for handheld devices)?  This way the recipient does not have to infer what
the rule meant, but can simply put the sent dates on the calendar.

I really think this is worthwhile to consider if you take it step further -
to reschedules.  This is where each vendor does their own thing
(currently).  That's ok, so long as we're all sending the same basic data,
but we're not.  If we sent the exact dates that we want rescheduled, and
the exact dates that we want rescheduled to, we'd solve alot of basic
rescheduling interop problems.

And this path allows the vendor to be as complex as they would like.  Some
offer very complex repeat rules, while a new vendor to the iCal space may
want to offer a much smaller subset of the recurrence feature.  Both should
still send the same iCal and interoperate if they both send a list of
time/dates instead of rules and exceptions.

> ever reasonably do with this information?

I agree.  Don't think this is being used...

> bring this draft to standard.

That's a good point.  I think though, if we each take the position that
we'll probably all have to modify our implementation in order to fit what
we come up with as the iCal (or eCal or whatever) standard, then maybe it's
ok to make drastic changes to the standard.  We'll all likely have work to
do from this....
-CS

---

From: Doug at Royer.com (Doug Royer)
Date: Tue Aug 17 11:53:47 2004

>the rule meant, but can simply put the sent dates on the calendar.
Standing staff meeting every Monday at 2pm. The argument for not being able
to have unbounded instances is the problem. What limit? How many means 
forever?
Or do we add a new unbound property or parameter. Then we are back to some
version of rrule.

Currently multiple RRULE properties are allowed per object. I think that
needs to go at a minimum.

>rescheduling interop problems.
Yes. TOSS all of the iTIP complexity. Simply send replacement objects. 
That's one
method of updating objects that works for all vendors already. Keep the 
same UID
and update the SEQ values, send new objects. Simplifies all of that mess.

-- 

-------------- 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/20040817/c410acdb/smime-0001.bin

---

From: Chris_Stoner at notesdev.ibm.com ([email-masked])
Date: Tue Aug 17 13:28:45 2004

> needs to go at a minimum.

Yes - infinitely recurring meetings would no longer be supported. There
would simply be no way to express that in a list of time/dates, unless, as
you said, we fell back to sending a rule as well.

What about just getting rid of infinite recurrences?

> and update the SEQ values, send new objects. Simplifies all of that mess.

Right - and think of this: the vendor can still have multiple Rules,
exceptions, etc. in their UI, but what they send has to be the
consolidation of all of that in a list of time/dates...
-CS