Subject: Re: Extensions To iCalendar [Was: Re: The SKiCal extensions]

From: [email-masked]
Date: Tue, 6 Feb 2001 23:31:49 +0000

George, your comments on creating a well-defined extension process for 
iCalendar is just what we need to do.  Any ideas, list?
___________________
Patricia Egen Consulting
www.egenconsulting.com
423-875-2652

---

From: "Shannon J. Clark" <[email-masked]>
Date: Tue, 6 Feb 2001 18:28:04 -0600

A few thoughts:

(I will use REQUIRED below not in the RFC 2445 context of required by all
implementations, but in the sense of "inherently required by the object
type")

There are REQUIRED properties that nearly all instances of objects of a
given type need - example a description (at least a short one), a date for a
vEvent. I would postulate that this is very SMALL list and could represent
the base set (probably smaller than even our current standard)

Then for each CONTEXT of iCalendar implementation and use there are other
properties that are more (and some that are less) useful. For example, in
the public event context of the SKiCal context the entire set of properties
about ATTENDEES, DELEGATES etc are fairly useless, and the simple property
of LOCATION may not be sufficient.

In reading over the current standards documents it is clear that a large
part of the problem set they are solving is business meeting scheduling
related - this is a large problem. I propose the following - we may want to
consider this as another set to apply to our well-defined extension process
should we develop one.

This would allow (and the current standard does this to a degree with the
large set of features that are "optional") for very efficient but basic
implementations for general sets of the calendaring and scheduling problem,
and more domain specific implementations for certain problem areas (such as
business meeting scheduling, commercial service scheduling (doctor's offices
for example), public event sharing, events not tied to time shares (such as
possible events not yet fixed in time), and other domains not yet defined or
publicly revealed.

So, one route we may want to take is when considering this extension process
look at the current standard as well as the proposed SKiCal and use these
two domains as the first two possible extensions:
  a..     Business meetings (much of the current standard)
  b..     Public Events (SKiCal)
It seems to me that there are problems that are very general (reoccurrence
rules, timezone issues) and problems that are very problem specific
(delegation and other attendee negotiations). Additionally there are "types"
of objects which are fairly general (deadlines - "vToDos; scheduled by some
time characteristic either date or time and date - vEvent) Other objects
have been added to accommodate requirements (vUsers, vQueries, vJournals) of
many applications.

There are also many problems that are interrelated but specific - many types
of events do not have a "Price" attached to them, for those that do
internationalization issues such as currency need to be dealt with.

We may want to formally recognize to some degree the difference between
these types of properties - with an extension context of some type we may
also be able to group and arrange properties in a way that is helpful BOTH
to computer programs and humans.

Hope this is helpful to everyone - I am trying to offer ideas and probing
questions.

Shannon

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

  -----Original Message-----
  From: [email-masked]
[mailto:[email-masked]]On Behalf Of
[email-masked]
  Sent: Tuesday, February 06, 2001 5:32 PM
  To: George Babics
  Cc: [email-masked]; [email-masked]
  Subject: Re: Extensions To iCalendar [Was: Re: The SKiCal extensions]

---

From: John Stracke <[email-masked]>
Date: Wed, 07 Feb 2001 10:47:47 -0500

"Shannon J. Clark" wrote:

(Side note: please don't post in HTML--especially not from
Outlook Express [or any other MS implementation], since it
generates illegal HTML that Netscape has trouble replying to.)

> There are REQUIRED properties that nearly all instances of
> objects of a given type need - example a description (at least
> a short one), a date for a vEvent.

A VEVENT that's intended for machine consumption (e.g., in
something like cron) might well not have a description.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |They prayed for their fates to be quick,     |
[email-masked]|painless, and, ideally, someone else's.      |
\==============================================================/

---

From: "Graham Gilmore" <[email-masked]>
Date: Wed, 7 Feb 2001 12:45:36 -0500

----- Original Message -----
From: "Shannon J. Clark" <[email-masked]>
Cc: <[email-masked]>
Sent: 06 February, 2001 19:28
Subject: RE: Extensions To iCalendar [Was: Re: The SKiCal extensions]

> A few thoughts:
>
> (I will use REQUIRED below not in the RFC 2445 context of required by
> all implementations, but in the sense of "inherently required by the
> object type")
>
> given type need - example a description (at least a short one), a date
> for a vEvent. I would postulate that this is very SMALL list and could
> represent the base set (probably smaller than even our current
standard)

    In spite of Shannon's disclaimer, I noted a contradiction in the RFC
on the topic of REQUIRED properties in the VEVENT.  I looked through the
issues list (http://www.softwarestudio.org/iCal/2445Issues.html), and I
didn't see it (though that doesn't mean it wasn't there :) :

     In section 4.6.1, describing the grammar for VEVENT components, the
DTSTART property is listed as optional (in fact, none of the properties
are required, according to the grammar).

     However, in section 4.8.2.4, the description of the DTSTART
property clearly states:

         Within the "VEVENT" calendar component, this property defines
         the start date and time for the event.  The property is
REQUIRED
         in "VEVENT" calendar components.

    Obviously, both sections can't be correct.  Which is it?  I don't
think it makes a lot of sense to publish a VEVENT without a start date,
but as I understand it for some iTIP methods (such as cancelling an
event) it isn't needed.

    Graham

---

From: Eric Busboom <[email-masked]>
Date: Thu, 8 Feb 2001 11:47:27 -0800 (PST)

On Wed, 7 Feb 2001, Graham Gilmore wrote:

> think it makes a lot of sense to publish a VEVENT without a start
> date, but as I understand it for some iTIP methods (such as cancelling
> an event) it isn't needed.

The broader question is: why do we have this kind of text in
RFC2445? Shouldn't the association between properties and components be
left solely to RFC2446?

Would there be any detriment to removing the ABNF for the components and
the "Conformance" sections for the Properties? It seems that both of these
sections are redundant with RFC2446.

As an implementer, I ignored both sections in RFC2445 and only used
RFC2446. 

eric.