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

From: camerost at exchange.microsoft.com (Cameron Stillion)
Date: Tue Aug 17 12:27:47 2004

Comments on 1.2:
I don't have a problem specifically with allowing seconds optionally to
the start or end times of appointments.  I think it will be VERY rarely
used, and I question its real value in actual applications that real
humans run on real computers to do real time and schedule management. I
do, however, think that recurrences byseconds are not meaningful in the
space we are targeting.  

This all comes back to the charge of this working group.  I think the
space we are trying to solve is the personal time management space, not
the micro-organism life span space, or the stellar cartography motion of
siderial time space.  Frankly, there are time-based applications and
systems out there that will not use this standard.  And I'm ok with
that. Frankly, I wouldn't expect these systems to use a standard schema
in the first place.  They have specialized scientific purposes that will
be optimized and specially designed for their own use.  I'm hoping to
get most of us to agree on the space that we are targeting.

If we can get a lot of bang for the buck without cluttering the standard
(like including seconds for those of you who want to use it) then I
suppose we should make room for it.  But be cautious - the slope is
slippery.

Comments on 1.3:
Any non-gregorian calendar would need to specify a completely different
schema for recurrences, and potentially even date specification.  I
think it is highly unlikely the schemas we build now for gregorian
calendars will be generally applicable to other calendar types.
Therefore, I think they should be defined by other standards.  As a
suggestion, a mechanism for other calendar types would be supported by
the notion of:  BEGIN:X-HANGUL-EVENT  or BEGIN:X-LUNAR-EVENT

If there is sufficient interest in making such schemas more standard, by
all means we should define a new document which details how such things
work.

Comments on 2:
The question in my mind is whether supporting such complex recurrences
is actually meaningful? Not whether we can support complex equations by
duplicating UIDs... though that does seem like a fascinating workaround.
The formal proof, then, is "show what purpose requires their existence".

Comments on 5:
Yes, compatibility will be broken with some.  I guess what I'm trying to
say here is - let's make it somewhat inclusive, but not overly so.
We're not going to make everyone happy, but if we make the pain points
mostly on the uncharted edges, we're likely to face less problems.  For
example: depracating recurrence rules completely would be a far more
destructive change than I think would survive. So many iCals use them
already. Instead, let's just depracate the things about them that no one
uses.

Gracias,
cam

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Elias
Sinderson
Sent: Monday, August 16, 2004 9:52 PM
To: [email-masked]
Subject: Re: [Ietf-calsify] Recommendations for stripping down iCal to
amanageable 'standard'

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.
>
> 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?

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.

>> 3) Simplify exceptions
>> I propose that exceptions be exclusively one-off events, never 
>> recurrences themselves. [...]
>
> Yes.

Agreed.

>> 4)  Remove useless properties
>
> 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
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify