Subject: Some questions raised in my recent review of RFC2445

From: "Shannon J. Clark" <[email-masked]>
Date: Wed, 14 Mar 2001 12:48:07 -0600

As part of my ongoing development efforts, I recently was rereading most of
the standards docs, in looking at RFC2445 (iCalendar) the following
questions came to mind.

One - there is an assumption, though not clearly documented, that most
events and interactions will be on a one event by one event basis. Indeed a
very common application (MS Outlook) appears to have a problem with complex
iCalendar objects containing multiple vEvents. It is frequently useful to
have the ability to deal with large sets of events (for example when
synchronizing between two systems or when importing one large calendar into
another). Is there an explicit requirement that "iCalendar" compliant
products handle MULTI-OBJECT iCalendar messages?

	i.e. Messages with both a vEvent and a vTodo? Or an iCalendar object with
multiple vEvents? What about multiple vCalendars?

Two – there is an assumption that most of the time there will only be ONE
event at a given time, and that overlaps are unforgivable. This implies that
all events take 100% of a person’s time, and this contributes to the stress
of using calendars, and decreases their utility for most people. Most time
related events are not all or nothing affairs, most of the time they are of
the form “the show is on now” or “the meeting is running for at least the
next 45 minutes” or the cafeteria closes at 2:00. Sure there are the cases
of events in two places at once - but in a world of virtual meetings and
frequent multi-tasking our tools should accommodate how we in fact work and
function.

Three – much value can be obtained by helping relate events to each other,
by doing this deadlines can be attached to the conference they are related
to etc. Yes there is a "related_to" property - but see my above question
about multi-object messages, with tools that require EACH object to be dealt
with as a seperate transaction and interaction - the utility of linking
events and other objects is greatly lessened.

Four – in interoperability I can foresee issues with the “folding” technique
to handle long lines – has this been a part of the testing procedures? That
is, as part of the upcoming interop testing are there explicit cases to
"stress" various tool's handling of this folding efforts? - it seems to me
that the reliance on whitespace has potential to be error prone especially
in interop between platforms (say the simple case of messages passing
between Mac users and Windows users - perhaps with a unix system thrown into
the mix somewhere.

More as I continue to delve into the docs.

Shannon

Shannon J. Clark
CEO - JigZaw, Inc
1.800.4.JIGZAW (454.4929)
[email-masked]
www.jigzaw.com

---

From: John Stracke <[email-masked]>
Date: Wed, 14 Mar 2001 14:28:03 -0500

"Shannon J. Clark" wrote:

> events and interactions will be on a one event by one event basis.

Where do you see this, please?

> Two - there is an assumption that most of the time there will only be ONE
> event at a given time, and that overlaps are unforgivable.

Very few users can manage to be in more than one place at the same time.  (Those
hypothetical users who can don't need a calendar as much, because they don't have to
worry about conflicts.  ;-)

Anyway, 4.8.2.7 (TRANSP) contradicts you.

> Three - much value can be obtained by helping relate events to each other,
> to etc.

But then we need to define the various possible semantics of this sort of
attachment.  This might be valuable eventually, but it was not needed for the
initial goals.

> Four - in interoperability I can foresee issues with the ?folding? technique
> to handle long lines

I suppose.  But, really, folding is easy to implement, and easy to test.  Semantic
problems are harder.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |This space intentionally not left blank.     |
[email-masked]|                                             |
\==============================================================/

---

From: Alan Davies <[email-masked]>
Date: Wed, 14 Mar 2001 14:34:57 -0500

>iCalendar objects containing multiple vEvents.

Outlook is not the benchmark of how the Standard should be implemented,
just one vendor's implementation of a subset.

>Two  there is an assumption that most of the time there will only be ONE

Where is this assumption about overlapping made?

>events and other objects is greatly lessened.

Again, Outlook is not the only implementation.

>Four  in interoperability I can foresee issues with the “folding” technique
>to handle long lines

It seems simple enough to understand and code, and the RFC is quite
specific about the character set used- it shouldn't be difficult to
support this on each platform.

--Alan

---

From: "Shannon J. Clark" <[email-masked]>
Date: Wed, 14 Mar 2001 14:12:36 -0600

This is my point - there is an assumption on the part of the standards doc,
and many implementers that the majority of events will be of the sort that
cannot overlap. (I am aware of the TRANSP)

My software is close to 100% focused on information that does NOT by default
cause conflicts - mostly notifications of possible events, but NOT
invitations to them, rather indications on your calendar that there are
multiple things occurring at the same time. In my general usage of my
calendars overlapping events are more often than not what I have on my
calendar - I am mostly concerned with what my options are - not with
deciding exactly which I will be attending (these are mostly of the category
of public type events).

The assumption is seen in the examples and documentation in the first few
sections - I'll review the docs again and send the exact locations later
this week.

I was NOT considering related events as attachments to over events - I have
been considering them as LINKS to other events - is this not a correct
interpretation of the related to property?

Shannon

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of John Stracke
Sent: Wednesday, March 14, 2001 1:28 PM
To: [email-masked]
Subject: Re: Some questions raised in my recent review of RFC2445

> event at a given time, and that overlaps are unforgivable.

Very few users can manage to be in more than one place at the same time.
(Those
hypothetical users who can don't need a calendar as much, because they don't
have to
worry about conflicts.  ;-)

But then we need to define the various possible semantics of this sort of
attachment.  This might be valuable eventually, but it was not needed for
the
initial goals.

> Four - in interoperability I can foresee issues with the ?folding?
technique

I suppose.  But, really, folding is easy to implement, and easy to test.
Semantic
problems are harder.

---

From: "Shannon J. Clark" <[email-masked]>
Date: Wed, 14 Mar 2001 14:24:20 -0600

Alan,

I am well aware that Outlook is not the benchmark, I cite it as a very
commonly deployed and used application where clearly the interpretation of
the standard was not clear. From an interop point of view - and thus from
the perspective of moving the standard forward - it is important that we
have a common understanding of WHAT the standard is for - if there are
questions from major vendors overall adoption and use of a standard will
suffer.

As such, this appears to me to indicate that there are some assumptions that
are not clearly documented within the standards - are or are not
multi-object iCalendar files to be expected? Are all methods of using the
various standards focused on ONE EVENT at a time OR is there is significant
place within the standards efforts for actions that involve MULTIPLE
iCalendar objects at a time?

For example - importing a calendar (which I thought was major role for the
iCalendar standard to play - to allow a complex calendar to be imported and
exported between two iCalendar compliant software applications)

Or a action that involved multiple RELATED objects (a vEvent and related
vToDo for example)?

What about actions involving multiple object that are NOT related? (Three
different performances of a play?)

IF they are defined by a reoccurrence rule - clearly the standards fully
apply and expect this situation, I'm asking if they are also apply to
non-reoccurring entries.

Re the folding - I agree that it is clearly spelled out and fairly easy to
implement - I was just suggesting that when we test interop we don't forget
to test these seemingly "simple" portions of the code - not too infrequently
the areas we "assume" we got right can contain hidden "gotchas" shouldn't be
to hard to set up some test scenarios that exercise this aspect of our
various applications.

Shannon

-----Original Message-----
From: Alan Davies [mailto:[email-masked]]
Sent: Wednesday, March 14, 2001 1:35 PM
To: Shannon J. Clark
Cc: [email-masked]
Subject: Re: Some questions raised in my recent review of RFC2445

--Alan

---

From: John Stracke <[email-masked]>
Date: Wed, 14 Mar 2001 15:58:21 -0500

"Shannon J. Clark" wrote:

> multi-object iCalendar files to be expected?

4.6 says:

     In addition, a complex iCalendar object is possible that is used to
     capture a complete snapshot of the contents of a calendar (e.g.,
     composite of many different calendar components).

What do you consider unclear?

> Or a action that involved multiple RELATED objects (a vEvent and related

If you want related events, write an I-D defining them.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Misanthropology: the study of why people are so|
[email-masked]|stupid.                                        |
\================================================================/

---

From: Alan Davies <[email-masked]>
Date: Wed, 14 Mar 2001 16:29:05 -0500

> questions from major vendors overall adoption and use of a standard will

That's your interpretation of their interpretation of the standard.

As you've seen from testing Outlook, it is clear that Microsoft
has implemented a subset of the standards. I don't know their reasons for
this, but at least it's better than nothing- it doesn't mean that there's
a problem with the standard though. You're right that it's important to
understand what we're all implementing, that's one goal of CalConnect.

 > iCalendar objects at a time?

An "iCalendar object" is a different concept from an "event", so your
second question doesn't make sense. RFC2445 states that an iCalendar
object can contain "one or more" components, some of which could be
events:

4.6 Calendar Components

    The body of the iCalendar object consists of a sequence of calendar
    properties and one or more calendar components. The calendar
    properties are attributes that apply to the calendar as a whole. The
    calendar components are collections of properties that express a
    particular calendar semantic. For example, the calendar component can
    specify an event, a to-do, a journal entry, time zone information, or
    free/busy time information, or an alarm.

    [....]

... a complex iCalendar object is possible that is used to
    capture a complete snapshot of the contents of a calendar (e.g.,
    composite of many different calendar components).

 > to hard to set up some test scenarios that exercise this aspect of our

Yes, all details should be tested- I took your previous comment to imply
that folding was a problem with the standard.

--Alan

---

From: "David L. Nicol" <[email-masked]>
Date: Thu, 15 Mar 2001 00:33:43 +0000

John Stracke wrote:
> have to worry about conflicts.  ;-)

Calendars contain entries for multiple activites, for instance
all the rooms in a building hold classes which overlap; a general calendar
needs to support applications besides one person's appointments!

---

From: John Stracke <[email-masked]>
Date: Thu, 15 Mar 2001 10:15:14 -0500

> needs to support applications besides one person's appointments!

And they do.  But, as I said before, personal appointments are the best understood
(and most challenging) part of the problem space, so that's what people were thinking
about when they wrote 2445, and it probably reflects that attitude.

|eCal Corp.      |This is the .sig that says... Ni!            |

---

From: "Graham Gilmore" <[email-masked]>
Date: Thu, 15 Mar 2001 12:25:02 -0500

----- Original Message -----
From: "Shannon J. Clark" <[email-masked]>
To: <[email-masked]>
Sent: 14 March, 2001 15:12
Subject: RE: Some questions raised in my recent review of RFC2445

> deciding exactly which I will be attending (these are mostly of the
category

    The assumption that you mention is probably present - its validity
is, apparently, arguable (e.g. your comments :).  However, the
TRANSParency of an event is used for calculating responses to FREEBUSY
requests.  It doesn't require calendaring software to prevent users from
having multiple OPAQUE events in their calendar (or even confirming
their attendance at said events) occurring at the same time.  In any
case, as you know it is possible to specify events that don't cause
conflicts via the TRANSP property, so I can't really see why the
aforementioned assumption would cause any problems (if you have any
specific examples, please clarify!).  Are you suggesting the default
value for TRANSP (being OPAQUE) be changed, or perhaps removed?

    Graham