Subject: RE: The SKiCal extensions

From: [email-masked]
Date: Tue, 6 Feb 2001 16:23:14 -0600

Eric:

Good suggestion.

I would like to take your extensions suggestion a step further. As iCalendar
gains acceptance, there are bound to be many proposals broad "sets" of
property extensions, such as the SKiCal work. As such, we need to be
prepared to enable interoperability between different iCalendar
implementations for different sets of these extensions. Your proposal would
facilitate this.

What we also would benefit from knowing what base iCalendar property sets
are included. Adding registration of tags for the base version of iCalendar
would be helpful too. For example:

EXTENSIONS:RFC2445-BASIC,RFC2445-VEVENT,RFC2445-VTIMEZONE,SKICAL

Additionally, would it be helpful to remoniker this property to recognize
that you are exchanging the needed capabilities for parsing and processing
the received iCalendar object? Maybe call it CAPABILITIES, instead of
EXTENSIONS?

-- Frank

---

From: "Shannon J. Clark" <[email-masked]>
Date: Tue, 6 Feb 2001 17:14:46 -0600

Frank,

You bring up an good point which bears clarification.

Will this feature be used as part of an exchange of information BETWEEN
calendaring systems (perhaps should be considered as part of CAP?) - which
already has a Capabilities property I think.

Or should it be a characteristic of EACH individual object within an
iCalendar system?

I certainly think there is a valuable role for interactions between systems
to include a progamatic method of identify expectations of those systems
(i.e. similar to an HTML version registration of a given page to take a
commonly used but rarely looked at example) - especially if the systems
involved will be changing/expanding on a frequently basis, programs need to
know what features they understand. Ideally in some cases there should be
mechanism to expand a program's features without requiring a new program
version to be written - i.e. if you can parse XML pages - you may be able to
handle a "new" Document definition type by getting the standard from a
documented location.

To use an example that people have probably experienced, the ability of
browsers to with some accuracy "get" new plugins - not always perfectly
implemented, but a greatly valuable application.

From am implementer's perspective however it is critical to know where
extended capabilities will be referenced, and where they will be used. If
they are attached to individual objects - which can be exchanged between
systems, then perhaps they need to also be attached to the objects (though
alternatively they could be attached to the communication - if all methods
of communication could be handled)

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
[email-masked]
Sent: Tuesday, February 06, 2001 4:23 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: The SKiCal extensions

Eric:

Good suggestion.

-- Frank

---

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

"Shannon J. Clark" wrote:

> Ideally in some cases there should be

Not really; all the DTD can give you is the syntax.  To extend the semantics
you would have to...

> browsers to with some accuracy "get" new plugins

...download code.  This is amazingly insecure, and not something that the IETF
can really standardize anyway, since the code you'd need would be highly
implementation-specific.

I suppose, if we had an extension mechanism, your implementor could provide a
repository of plugins; when you saw an extension you didn't understand, you'd
go check the repository.  It would necessarily be a proprietary system, though.

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |Reality is what refuses to go away when I stop|
[email-masked]|believing in it.                              |
\===============================================================/