Subject: Re: The SKiCal extensions

From: Eric Busboom <[email-masked]>
Date: Mon, 5 Feb 2001 20:38:02 -0800 (PST)

On Tue, 30 Jan 2001, Greg FitzPatrick wrote:

> It is our sincere hope that each of these will be accepted as an update to
> RFC2445.  If this happens then SKiCal and iCal will be identical!  Even in
> the event that this does not happen the comments and criticisms received
> will be of great benefit in preparing the SKiCal draft for its last call.

Greg, 

The model for sharing event information that you and your team have
created is very impressive! The SkiCal additions definitly make iCal
useful in a broader range of services, and will probably hasten its
adoption in a wide audience.

But, valuable are they are, I don't think these properties belong in
rfc2445, for two reasons: 

	1) They are oriented towards a specific application -- public
	events -- so they are more specific that the rest of iCalendar. 

	2) They are extensions of a type we will probably see in the
	future. Adding them the the RFC will cost us the opportunity to
	create a more general method for incorporating additions

The SkiCal properties are for a general set of public events, but they are
still more specialized that the rest of iCalendar. Every meeting will have
a UID and a DTSTART, but broad classes of meetings will never have a
THINKS or PRICE -- like any TODO, JOURNAL, and most group meetings. This
makes the SkiCal properties slightly non-cohesive, and suggest that they
should be in their own specification.

Note that you are proposing about 20 new properties, and the existing spec
has 65 or so -- SkiCal is a 30% addition. That is a substantial change. 

SkiCal is a great idea, but I don't think it will be the only improvement
on iCalendar. What happens when someone proposes extensions for project
management? or the construction industry? If we are going to make
iCalendar more useful to a specific application, we should take the time
to create an extension mechanism. 

Here is an idea for such a mechanism: 

	Property Name: EXTENSIONS

	Purpose: List extensions used in an object

	Value Type: TEXT

	Property Parameters: Non-standard property parameters
	can be specified on this property

	Conformance: The property can be specified in an iCalendar object.

	Description: This property lists all of the prefixes for extension
	properties that are included in the object. For instance, the
	SkiCal properties all begin with "SKI-", and if any of them appear
	in the object, it must also have an EXTENSIONS property with the value
	"SKI"

        BEGIN:VCALENDAR
        VERSION:2.0
       	EXTENSIONS:SKI
        PRODID:-//hacksw/handcal//NONSGML v1.0//EN
        BEGIN:VEVENT
        DTSTART:19970714T170000Z
        DTEND:19970715T035959Z
        SUMMARY:Bastille Day Party
        SKI-LANGUE: English
        END:VEVENT
        END:VCALENDAR

        extensions = "EXTENSIONS" extenparam ":" text *("," text)
                  CRLF
        extenparam = *(
                ; the following is optional,
                ; but MUST NOT occur more than once
                (";" xparam)
   		)

Then, we would also add REQUEST-STATUS values for "Success, ignored
extensions properties" and maybe "Failure, unsupported extensions
properties"

Then, all future extensions, beginning with SkiCal, can have their own
RFC. Implementors don't need to implement them all, and can accept or
reject them as a group. And, if another group wants propose new standard
extensions, there is a path to do it. 

I do want to see these properties incorporated into standard calendaring
and scheduling applictions, but I much perfer they they be kept together
as a unit and added to iCalendar as a group.  I think that some extension
mechanism would make iCalendar more robust while still permitting the
SkiCal additions. 

eric.

---

From: "Shannon J. Clark" <[email-masked]>
Date: Mon, 5 Feb 2001 23:43:09 -0600

This sounds like a good proposal but a few questions.

One - would it be attached to every object? (i.e. would you need to add this
property to each vEvent, vToDo, vJournal etc inside of a vCalendar that has
the extension? I can think of many situations where individual events might
be added to a calendar from a different application - potentially one app
which understands the Extensions, and another that does not.

Two - Shouldn't we us a standard naming schema and reference for extensions
(i.e. what defines SKI as an extension? Ideally it should probably use
something akin to XML document definitions - if a given app doesn't
understand it potentially the reference for it could be obtain across the
network? This then also leads to the thought that extensions should probably
also have a version attached to them (i.e. what happens if SKI is changed?)

Three - What is the overall goal of adding many additional properties? Is it
for individual users of applications? or for the software packages
themselves? (i.e. is it for human organization or for electronic searches?)
Many of the proposed criteria seem to fit into a vision of events being
defined by a series of properties that can serve as restrictions for a
search (i.e. is the event in English? does it cost less than X?)

	Does this standard propose a simple way to handle cases where events do not
have the given extensions? Are all of the proposed properties optional? If
optional, how frequently will they be utilized? If not utilized do they
serve a useful purpose?

My company is writing an application where in the future I certainly see a
very useful role for many of the SKiCal proposals - however I am also
concerned about how to exchange information between SKiCal systems and more
general iCalendar systems - it seems that many of the SKiCal extensions (or
additions to iCalendar) will be useful for some types of events - and will
be used by certain types of users and under some situations, but for many
general situations most if not all of the new properties will go unused.

anyway, my immediate and quick response to Eric's suggestion - I think that
an extension type system is a potentially good idea but needs some
additional work.

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 Eric Busboom
Sent: Monday, February 05, 2001 10:38 PM
To: Greg FitzPatrick
Cc: [email-masked]; Pregen@Egenconsulting. Com; Bob Mahoney;
Patrik Fältström
Subject: Re: The SKiCal extensions

Greg,

	Value Type: TEXT

        BEGIN:VCALENDAR
        VERSION:2.0
       	EXTENSIONS:SKI

eric.

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Tue, 6 Feb 2001 10:51:24 +0100

Congratulations Eric! You just invented NAMESPACES :-)

... and no, that is not my only response,  but it is going to take a few
cups of coffee to put something together.

Greg

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Tue, 6 Feb 2001 14:44:37 +0100

Shannon wrote:

...Three - What is the overall goal of adding many additional properties? Is
it

Greg replies:

I like this question.  These are important points.

Why do we do this?  Why would we move certain types of information from the
all encompassing basket of DESCRIPTION to little nooks and crannies of their
own.  Face it, anything you can say as the value of an extra property, can
also be said in DESCRIPTION or briefly in SUMMARY.

You can always say

---ex. 1

DESCRIPTION: to attend this get-together non-members must pay 50 French
francs.
DESCRIPTION: to participate you must have a valid certificate in XTL999.
DESCRIPTION: The topic of the lecture will be Madonna.
DESCRIPTION: 99 good reasons for joining our club; Reason #1 Because we
care...    ... Reason #99 Because we dare.

---

or perhaps we should aggregate these since only one description can occur in
a calendar object.

---ex 2.

DESCRIPTION: to attend this get-together non-members must pay 50 French
francs. Y you must have a valid certificate in XTL999. The topic of the
lecture will be Madonna.  There are 99 good reasons for joining our club;
Reason #1 Because we care...    ... Reason #99 Because we dare.

---

Cutting this description up into specific nooks (properties) is called
SORTING and giving each item their own type-name is called LABELING.

There is only one reason to SORT and LABEL and that is to REUSE.  You will
not bother to sort anything you will never reuse (more than once that is -
"save it or trash it", is also a sort).

Traditional sorting is manual - you file some papers here and some there.
HERE  and THERE are usually little containers with LABELS on them.  But also
LAYOUT is sorting.  The way information is presented (sorted out) on a
screen or paper is crucial to our REUSE of that information.

If we find that a gathering of objects which we intend for REUSE share
significant commonalities we can create a DIRECTORY using salient
commonalities as sort keys.

All directories are SORTED.  But the level of sorting as well as the amount
of information included in a directory are dependent upon CIRCUMSTANCES.

These CIRCUSTANCES are:

 The availability of information.
 The physical restraints of the publishing media.
 The existence, extent and scope of the commonalties identified.

With these circumstances known, utilitarian calculus can then be used to
determine the optimal granularity of the SORT.

Benefit = (GAINS from USE)  minus (effort expended)

---

So far half-easy.  We know that almost all public resources are publicized
in one manner or another, that almost any publication notice makes use of
the WHAT, WHERE and WHEN commonalities, though not in standardized formats
and we believe that the Internet has removed many of the restraints of paper
based publishing which would render this discussion irrelevant.

But on the other hand we don't really know what "GAINS from USE" to expect.
We assume that if there was a directory in which identical commodities where
marked with their PRICE, users would use that information in making buying
decisions.
We assume that the same goes for the availability of parking and payment
methods, languages spoken, restrictions, recommendations and so on, but
since this sort of directory does not exist in more that a few isolated (and
somewhat experimental) instances, it may seem to many resource publishers
that the gains do not merit the effort.

But we are not resource publishers.  Nor are we tool makers.  We are
architects trying to create structures where resource publishers can
comfortably move in and where tools can work effectively.

I don't think this is a chicken-egg problem.  I think we must go first and
create infostructures.  These infostructures are based on possibilities but
also from  pragmatics learned in pre-automated usage.  We can not guarantee
that these possibilities will be realized, but without the structures where
are the possibilities?

Initially this just might lead to better "layout" on a humanly readable page
(that which Shannon refers to as human organization), but in the long run we
are building infostructures for Shannon's "electronic searches".

In the long run we expect that as extensive directories come into existence
the use-value of automated searches for criteria such as those described in
SKiCal will be significant.

Finally though, I will make  the same reservation here which I have made in
the Semantic Web efforts in which I participate;  Metadata is not the only
solution.  As the digitalized and networked contextual information base
grows, it will be increasingly possible to "discover" specific answers in
resource descriptions, even in the absence of specific tags.

We need to strike a balance.  At this moment, no one suggests eliminating
the specific properties of iCal in favor of one big blob of text and no one
suggests that every atomic grain of information needs its own markup tag.
The answer is somewhere in between but take care - this is a moving target!

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Tue, 6 Feb 2001 16:24:23 +0100

Eric

At the IETF in San Diego there where quite a few discussion within the
applications area as to how to utilize namespaces and schemas.  Personally
I have had email discussions with Graham Klyne on how to approach this
subject and  Patrik Fältström and I once talked about it at a lunch.

The cluster-modularity that the namespace-schema mechanism offers is
undeniable.

The problem so far seems to be coordination.  Coordination seems to be a big
problem.  Why couldn't (for example) the date-time and recurrence rules of
2445 be coordinated with the date-time and recurrence rules of XML-Schemas?

http://www.w3.org/TR/xmlschema-2/

Frank Dawson has some input on that perhaps?

I just don't know where we could find the force to accomplish something like
this.

Since the semantics of SKiCal will also be published as a schema using XML
syntax - it would be just wonderful if your Sword-of-Alexander suggestion
was to gain ground, but also a bit perilous for us if it was to lead to
diversion in the current discussions.

Hopefully the ongoing SKiCal submissions are serving to enlighten.  The
ensuing discussions certainly do so for me.  I don't think it is simply so
that the SKiCal submissions as a group fall outside the basic 2445
framework.  I think, for example, that the issue of dualism (the calendar
object as a pointer versus the calendar object as a sovereign entity) should
be resolved and many of the SKiCal properties address that problem.

I think that the RECOMMENDED, REQUIRED and PROHIBITED properties certainly
pertain to meetings as well as events.  Actually I think all the properties
and property parameters at least to some degree fall with in the business
meeting model.

On the other hand in conjecture with Shannon's mail, there is a valid point
as to  what extent automated discovery will be exercised on business
meetings! And consequently to what extent application designers wish to
offer this sort of extensibility.

I surely hope that others will speak up on this namespace issue and I only
wish there was a convenient method to cross post on this thread with the
other groups within which the issue is being considered.

Greg

---

From: George Babics <[email-masked]>
Date: Tue, 06 Feb 2001 15:46:07 -0500

> adoption in a wide audience.

  I agree.

> has 65 or so -- SkiCal is a 30% addition. That is a substantial change.

  Many people may want to add new properties and parameters to iCalendar.
They may be industry, domain or even country specific. If we add all
these extensions to iCalendar, it may grow to be hundreds of pages long.
(It is already about 150 pages in length.)

  Furthermore, most implementors will probably not implement all properties.
We will end up with people asking questions such as, does implementation A
support properties X, Y, and Z? Asking which extensions are supported
is much easier.

  Before adding new properties and parameters to iCalendar, we should
try to solve the general questions that have been posed in this group
recently. They include,

  Do we really need to worry about many people wanting to add new
properties and parameters? Perhaps only Skical and one or two other
sets of properties will need to be added.

  When does a new type of information need to go into a new property
instead of in the DESCRIPTION or SUMMARY? This may be difficult to
answer.

  What type of new properties should go into iCalendar? All? non-
domain specific ones? What is the purpose of iCalendar? A
repository of all properties? Basic properties? Fundamental
properties?

     If we add all of them we may have the problems described above.
   If we do not add them all, we may run into problems with interoperability?
   Product A supports extensions X, Y, Z and product B supports extensions
   X, V, W ...

     If we choose to have all extensions in extension rfcs, then we
   need to evaluate each proposed property. We need to ask if it is
   domain specific or fundamental. For some properties it may be a
   difficult question to answer. For instance, is SKUID domain specific?

     Furthermore, people writing extensions must make sure that things
   they add are not already in or consistent with other extensions. 
   What if extension A has a property that is very similar or identical
   to a property in extension B?

  How do other standards handle exceptions? (I believe Patrik mentioned
SNMP.) I am sure others have encountered similar problems.

  How easy it is to add extensions to iCalendar? Eric had an idea to
make it easily extensible. What mechanisms do other standards provide?

  If we do answer these questions, we should put the answers into
iCalendar. If we decide to use extensions, we can have a
section or appendix on how to create an extension to iCalendar.
 
> to create an extension mechanism.

  I agree. I am leaning towards a well defined extension mechanism for
iCalendar.

George

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Fri, 9 Feb 2001 14:24:53 +0100

There is a part of the SKiCal model that I would like to clarify before
presenting the actual properties and property parameters involved therein.

The motivating force behind this group or extensions comes from a series of
meetings held with customer service reps at Stockholm City's Information
office.  The meetings strived to reach a consensus on what "customers" were
mainly interested in knowing about "events".

The "events" were just about any thing the City had to offer to a resident
or a tourist.  This included typical tourist attractions, food and lodging,
municipal services, sporting events and not least convention facilities.

We soon found that many of the city's offerings were not what you would
typically call an event.  A museum, open most of the days of the year, is
not normally called an event.  So we began to use the term "resources"

We also had some trouble giving a name to the users of these resources.
They were not necessarily tourists or businessmen, but actually anybody who
was interested in spending time doing something.

We began to use the term "TimeSpenders" since we felt that was a fitting
semantic match.
This terms implies that there is a temporal aspect to our resources, which
differentiates them from traditional directory offerings.

From this TimeSpender perspective, it does not really matter if one is going
to go watch a football game or go get ones teeth pulled.  One is about to
"spend some time".

For a TimeSpender tourist visiting Stockholm for just one day, it really
would not matter if a particular exhibition was an "event", say Friday
between 19.00 and 21.00 or a persistent resource open all year.  They were
both equally viable time spending opportunities on the Friday our tourist
was visiting town.

Opening Times

As a participant to these meetings I wrote to the CALSCH list explaining the
need for something I called "Opening Times".  My point was that our 2445
recurrence rules were not really meant for describing Opening Times and I
hoped that others might see the value of such a property even in the
business meeting domain.

One might  benefit from knowing when a particular meeting hall was open,
beyond the actual hours described in the DTSTART DTEND.

One problem with such a property, is of course, that Calendars would quickly
fill up and overflow if we, for example, were to load them with the opening
times of all the restaurants and stores in our neighborhood.  We obviously
don't need to have that information in front of us all of the time, only
when desiring to access such a resource.

After some discussion with Bruce Kahn in San Diego, it seemed to both of us
that the ability to define opening (or operating, or accusable) times might
be better served though a set of property parameters.  And that is what we
have now done.

Now back to Stockholm working group and those most common TimeSpender
questions:

The WHOWS?

A list was made up of a dozen of most important aspects.  In no particular
order they were:

Parking, payment-methods, Alcohol served, smoking allowed, Age requirements,
need for reservations, requirements made upon the TimeSpender, Price,
Handicap facilities, pet restrictions, dress codes or dress recommendations,
the availability of transportation.

There were also some particular foreign language related items.

With this list in hand we asked ourselves for each item:

a)  Is this item important enough to warrant a visual and consistent place
holder(Something like a burning cigarette icon or a cocktail glass icon and
so forth) in brochures or webpage layouts?

b) Is in important enough to serve as the key to an automated search?  For
example show me all the resources where I can take my dog?  Concerts that
are free to attend? Where children are admitted? and so on.

c) Will the resource Publishers go to the trouble of declaring this
particular item of information.

The answers to all three questions for most of the items were qualified.
The most common qualifier was "if we reach critical mass".  But it was
decided that if nothing was made compulsory eventually the market would
prove the need for each individual item.  So we decided to create
place-holders for all.

The first draft of SKiCal reflects this, but also a complicated set of
description mechanisms, which not even the authors really understood when
looking back on our own examples.

Therefore we decided on a softer simplified KISS approach.  We determined
that all these particulars (and many more)  were either;

1. an available resource, such as parking
2. a requirement, such as you must be at least 18
3. a recommendation, such as dress warmly or RTFM before coming
4. A restriction, such as NO SMOKING, or NO HAND GUNS

and that it would be sufficient to reduce the whole property list into
becoming the values of four properties, one of which was already part of
2445 - AVAILABLE

so the result would look something like this

REQUIRED: Drivers License
AVAILABLE: free IEEE 802.11 Wireless LAN
PROHIBITED: Flash photography

Now you as you can see we have made things a little harder for automated
searches, but the consensus is that the market when provided with the
opportunity will reach consensus on codes or terms to alleviate the problem.
For example a rather complicated schema for the suitability of seeing
particular movies is reduced to standardized codes such as PG13

Some of the original WHOWs fell outside of this model and they are

PRICE - because you don't prohibit or require a "price" and to recommend a
"price" would be confusing

HANDICAP FACILITIES - because we have been waiting for our partners in this
area to supply us with a particular mechanism more advanced than merely
saying AVAILABLE: Wheel Chair ramp

BOOKINGS - because we are looking for an address as an answer
so that one could publish a combination like:

REQUIRED: Advanced bookings
BOOKINGS: www.tickettron.com

PAYMENT-METHOD - because this also fell outside the model.

So there you have the WHOW properties and the motivation behind them.  We
will follow the standard procedure and present them for inclusion one for
one - but the use-argument is basically the same for all.

In a separate mail I will explain the OpeningTimes parameters (TERM, OPTIME,
OPRULES), that our common to all the WHOWS.

Greg

---

From: John Stracke <[email-masked]>
Date: Fri, 09 Feb 2001 11:28:41 -0500

> becoming the values of four properties, one of which was already part of

<searches> There is no AVAILABLE property in 2445.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |I will not buy this .signature, it is scratched.|
[email-masked]|                                                |
\=================================================================/

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Sun, 11 Feb 2001 18:38:35 +0100

whoops - I meant RESOURCES

thanks for the correction

-----Ursprungligt meddelande-----
Från: [email-masked]
[mailto:[email-masked]]För John Stracke
Skickat: den 9 februari 2001 17:29
Till: [email-masked]
Ämne: Re: The SKiCal extensions - argument for HOW