Subject: The SKiCal extensions

From: [email-masked]
Date: Tue, 30 Jan 2001 16:16:39 -0600

Greg:

Is there any reason that you don't want to just submit these extensions as a
separate "events based" extensions draft?

By adding these to the iCalendar draft, the implication is that they must be
implemented by 2 or more independent implementations to allow iCalendar to
progress from proposed to draft. Right?

A major implementation of iCalendar is PIM based applications. I wonder how
many of them will implement these extensions?

-- Frank

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Wed, 31 Jan 2001 10:52:04 +0100

Frank wrote:

Greg:  Well this two pronged approach is the method we worked out with Pat
Egan and Patrik Fältström.  The entire set of SKiCal extensions exists of
course as a draft and will be submitted as such.

http://www.ietf.org/internet-drafts/draft-many-ical-ski-03.txt

By doing things in this way, we give the community a chance to weigh the
merits of each individual proposal separately.  I am convinced that to keep
iCalendar living and vital, internationally in tune, and ready for new
application domains, these proposals are worth including.  Hopefully the
group will decide if it is better to concentrate these to SKiCal or
incorporate them in the next version of 2445.

Furthermore the SKiCal concept has been a fellow traveler on this list for
over two years and the form it now takes has been influenced heavily by the
discussion in the CALSCH WG.  Not least you yourself have made valuable
contributions.  I am very happy for these proposals to get a final review.

On each proposal there will be two questions.

1. Does this make a significant addition to iCal and therefore we add it to
2445?
2. Is SKiCal developing in the right direction and are these proposals well
thought out and syntaxed correctly and expediently for use in the
usage-domain that SKiCal addresses.

Frank:

Greg:

Good point.  What does implementation imply?  I suppose that it means that
an application must have a response for ALL the grammar of RFC2445.  Does
this mean that general escape loops for "unknown" properties i.e..
properties and parameters that do not have a corresponding function in an
application can be just bypassed with out breaking the parse?  Or does it
mean that an application must individually consider each property and
parameter, saying "I know these - I expected they might pop up, but I don't
deal with them.

Or does it mean that a specific that procedure must be implemented for every
individual property and parameter in the RFC?

I don't know the answer to this.  I hope Patrik will help out here.

Frank:

Greg:

Of course I do not know this, but it does not seem unreasonable to think
that PIMs in the hands of private individuals would be even more apt to want
this additional functionality than office workers who should be primarily
concentrating on there companies business events and meetings.

As things stands there are quite a few independent applications which use
SKiCal even if they are concentrated to Europe.  Our problem is that
application developers are building their tools based on the original SKiCal
draft, which needless to say has no RFC status.  This is an unfortunate
situation that we wish to alleviate ASAP.

---

From: John Stracke <[email-masked]>
Date: Wed, 31 Jan 2001 10:06:27 -0500

Greg FitzPatrick wrote:

> Good point.  What does implementation imply? [...] Does

I wouldn't think so.  That would not be an implementation of the SKiCal
extensions; that would be an implementation of iCalendar.  It would not reflect
any experience with the extensions, which is the whole point of the
implementation requirement for Draft Standard: to make sure that the community
has experience with the protocol and has uncovered its problems.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |If God had not given us duct tape, it would have|
[email-masked]|been necessary to invent it.                    |
\=================================================================/

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Wed, 31 Jan 2001 21:51:24 +0100

What you say makes sense.  I see now that I was only giving examples of
applications which would not incorporate SKiCal properties at all.
Obviously I think that the properties will be used, just not all of them and
not all at the same time either.

In any case the criteria of independent implementations presents no
hindrance to us.

> parameter, saying "I know these - I expected they might pop up, but I
don't

John Stracke wrote:

I wouldn't think so.  That would not be an implementation of the SKiCal
extensions; that would be an implementation of iCalendar.  It would not
reflect
any experience with the extensions, which is the whole point of the
implementation requirement for Draft Standard: to make sure that the
community
has experience with the protocol and has uncovered its problems.

---

From: George Babics <[email-masked]>
Date: Wed, 31 Jan 2001 17:20:35 -0500

> incorporate them in the next version of 2445.

  Should we be putting domain specific properties and parameters into
iCalendar? Should they be in separate drafts or rfcs and labeled as 
domain specific extensions to iCalendar? We can have an "events based",
a "military based", and other extensions. I am sure some others will
eventually want their own extensions.

  In other words, should iCalendar contain basic calendaring
and scheduling properties, or should it contain all that every domain
needs? If we allow domain specific information in iCal, then we must
resubmit it as a new rfc every time a new set of specific properties
are needed.
  
   We can look at how other standards deal with similar
issues. Do they change the standard or have extensions?
Furthermore, how likely is it that many others will want to
add extensions to iCalendar?

   Some of the properties needed by skical may still need to go
into iCal, because they may be very basic and useful to all. Such
a property can be "LANGUE", and perhaps others. On the other hand, 
"PROMO" seems to be very domain specific.

George

---

From: "Shannon J. Clark" <[email-masked]>
Date: Wed, 31 Jan 2001 17:34:11 -0600

I thought that one of the purposes of the X- properties were to allow for
properties specific to one application. Why shouldn't this still be used for
extensions to iCalendar such as SKiCal? (X-SKI- is what is currently used by
the SKiCal draft)

In general though many standards tend to get rather large and cluttered
(HTML for ex.) it seems to me that simpler the base standard is kept, the
fewer interoperability and implementation issues there will be, a long,
complex, and overly lengthy standard full of highly specialized properties
and special cases will tend to require more complex, lengthy, and hard to
maintain application code - which runs counter to the purpose of making a
generally available standard which allows for easy interoperability and
communication.

Just my 2 cents.

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 George Babics
Sent: Wednesday, January 31, 2001 4:21 PM
To: Greg FitzPatrick
Cc: [email-masked]; [email-masked]; Patrik Fältström
Subject: Re: SV: The SKiCal extensions

George

---

From: Pär Lannerö <[email-masked]>
Date: Thu, 01 Feb 2001 00:59:28 +0100

> eventually want their own extensions.

I think that George Babics questions are very clearly formulated and
very relevant. 

The SKICal effort was initiated partly because of needs within the
tourism sector, but we have tried to include only extensions which we
believe have a _very_ wide use, such as LANGUE, REQUIRED, PRICE,
HANDICAP-FACILITIES.

These aren't really "tourism based". Or if they are, I would say
ATTENDEE is "office based". 

The "X-VND-" prefix mechanism is somewhat useful for domain-specific
extensions, but as soon as there are many people wanting to communicate
unambiguously one important piece of information there is a need for
standards documents. 

(Reason: The same prefix very easily could be used by several different
vendors each having a different semantic intention with their
extension.)

An alternative to standards documents could be something "stronger" than
the "X-VND-" mechanism. (For example, one new property which connects a
certain X-VND-prefix within a component with a URI, just like in XML
namespaces.)

imho /Pär