Subject: iCalendar Extensions Proposal

From: Eric Busboom <[email-masked]>
Date: Tue, 13 Feb 2001 11:21:59 -0800 (PST)

Most of the contributors to the recent thread about how ( and if ) to
permit extensions to iCalendar have supported the idea of some formal
extension mechanism. 

Additionally, several people noted that it is not necessary to declare
what extensions a component uses, as with an EXTENSIONS
property. Implementations are required to ignore properties that they
don't understand, and they can scan a component to discover extension
properties. 

I still want to have some way to group extension properties so that an
implementation can report in REQUESTS-STATUS that it has ignored an entire
set of properties. There is a big difference between "I don't support
ATTACH properties" and "I don't support any of the XXX extension
properties." One indicates a feature is unsupported and the other
indicates that an entire set of applications is not supported. 

So, it is probably sufficient to declare in iCalendar that all IANA
registered properties and parameters to be used in iCalendar components
that are not defined in iCalendar must include some prefix. The "EXT-"
prefix seems like a good choice, with a recommendation that it be followed
with another application-specific prefix as per the "X-" properties
recommendation. Thus, "EXT-SKI-"

So, how about the following changes?

eric.

----------------------------------------------------------------------------------------

Addition to 4.1, Content Lines:

     ext-name = "EXT-" [extension-id "-"] 1*(ALPHA / DIGIT / "-")
     ; Reserved for names registered in other RFCs

Change to 4.8.8.1, Non-Standard properties. 

  [ Change use of "extension property" to "experimental property" ]

Additional section, 4.8.8.2, Extension Properties

   Property Name: Any property name with an "EXT-" prefix

   Purpose: This class of property provides a framework for defining
   standard extension  properties.

   Value Type: Defined in property registration

   Property Parameters: Defined in property registration

   Conformance: Defined in property registration

   Description: 

   Extension properties are specified
   by property and/or property parameter names that have the
   prefix text of "EXT-" (the four character sequence: LATIN CAPITAL
   LETTERS E,X,T followed by the HYPEN-MINUS character). It is recommended
   that the prefix be followed by another prefix to identify the
   type of extension. This will facilitate readability of the
   extensions and minimize possible collision of names between different
   application. User agents that support this content type are expected to
   be able to parse the extension properties and property parameters but
   can ignore them.

   Extension properties must be registered with the IANA in an RFC.

   Format Definition: Defined in property registration.

   Example: The following might be an extension for an
   audio-clip form of subject property:

   EXT-ABC-MMSUBJ;EXT-ABC-MMSUBJTYPE=wave:http://load.noise.org/mysubj.wav

Addition to iTIP: 

  Add a REQUEST-STATUS value that indicates that a set of extension
  properties is unsupported and has been ignored

---

From: John Stracke <[email-masked]>
Date: Tue, 13 Feb 2001 15:18:21 -0500

> indicates that an entire set of applications is not supported.

I don't see that at all.  To me, there is no more need to group in REQUEST-STATUS than in
the initial message.  If you send me a message that uses 3 properties from an extension I
don't understand, and I say "I don't support these properties", you have the same
information about my handling of the message as if I said "I don't support this
extension".  The latter might allow your CUA to believe that it can predict my reaction to
other properties in the same extension; but I don't think that's so.  For example, I might
have a new CUA; or my CUA might have support for some other the properties from that
extension.

In addition, trying to group properties like this is risky for the long term.  Today, Fred
and Barney might define their own extension sets, EXT-FRED- and EXT-BARNEY-; maybe Fred's
includes EXT-FRED-TOXINS (the list of toxins present at an event), while Barney's includes
EXT-BARNEY-ALLERGENS.  Next week, Wilma decides she wants to work up an extension for all
the known environmental hazards at the event; she has to pick between (a) renaming TOXINS
and ALLERGENS to be EXT-WILMA-{TOXINS,ALLERGENS}, so that they match the rest of the
properties; or (b) not being able to use the extension syntax to describe her extension.
Since (a) breaks compatibility, she pretty much has to do (b).  In other words, any
grouping system is going to break down eventually.

I think the fundamental reason this happens is that the groups aren't *real*; they have no
effect on the meaning of the properties, so there's no natural way to divide them up; their
borders are indefinite.  In other contexts where this comes up, we solve it by permitting
something to be sorted into two groups (or by aliasing, which comes to the same thing).
For example, an event may fit into multiple categories (consider dinner theatre), so the
CATEGORIES property is multivalued.  In the case of group properties into extensions,
though, this isn't really feasible.

(Side note: if we had an extension prefix, it should not be "EXT-", because it sounds too
much like "X-".  :-)

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |There are footprints on the moon. No feet, just|
[email-masked]|footprints.                                    |
\================================================================/

---

From: Eric Busboom <[email-masked]>
Date: Wed, 14 Feb 2001 09:39:26 -0800 (PST)

On Tue, 13 Feb 2001, John Stracke wrote:

> the initial message.  

> borders are indefinite.  

The groups are not real in your example, but they ought to be real in
actual extensions. Our first example of an extension is a very cohesive
group -- public events and activities. In that case, SKI means something
very specific. An application that can't do "SKI" is unable to work with
public events and activities, which is a stronger assertion than "I'm
going to ignore LANGUE"

The "natural way" to group new properties is by the type of application
that they properties implmement. We should not have new extensions for
"bob's properties" but rather for groups of properties that serve a
specific purpose, like project management, or doctor's appointments, or
public events. 

Sure, if we permit random, non-cohesive extensions, then the group prefix
will be meaningless; the assumption of the prefix is that all extensions,
as a group, have a definite purpose, and the group prefix is the tag for
that purpose.  

eric.

---

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

A very similar issue arises from various attempts to create reusable
software components (in fact nearly the exact same issue exists with Java
namespace issues, how to organize components into a logical manner)

Java points to a few possible solutions.

One - Company or application specific components, which may be reusable
within the context of that company's suite of applications - but are not
intended for generalized reusability are placed within a naming schema that
includes the company name (com.mycompany.*) - in our context this is akin to
properties of the form X-MYCOMPANY-* where my applications use the
properties, but I don't expect interoperability based around these
properties.

Two - Where you DO expect interoperability - use a general path and name
based NOT on company or application but on FUNCTIONALITY. The issue here is
that the SAME function can easily be named differently by two different
developers OR the same name used to represent different concepts (in our
case this would imply the NON X-* properties, and the issues between LANGUE
and LANGUAGE point to clear example of similar words used for different
contexts.

The further issue becomes where there are dependencies BETWEEN components -
i.e. in our context a property that by itself is not useful, but grouped
with other properties becomes functional (i.e. a start time without an end
time).

In looking at the proposed new properties I think we should address some
fundamental questions:

Are the new properties INTERDEPENDENT - that is, do they require that either
ALL or NONE of them are used - if so a naming schema that implies this
dependency could be a very useful and good thing - encouraging correct
usage.

Do the new properties supercede existing properties?

Do the new properties imply that existing properties won't be used/change in
their usage (see our ongoing discussion about how much detail to have in the
Summary or Description properties.)?

hope these spark useful discussion,

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: Wednesday, February 14, 2001 11:39 AM
To: John Stracke
Cc: [email-masked]
Subject: Re: iCalendar Extensions Proposal

eric.

---

From: John Stracke <[email-masked]>
Date: Wed, 14 Feb 2001 13:39:40 -0500

> public events and activities, which is a stronger assertion than "I'm

Actually, that's a good example of what I'm saying: EVENT-LANGUAGE (formerly LANGUE) could be an
important property for business meetings in some parts of the world.

> "bob's properties"

Groan.  I called them "Fred's properties" because it was an easy way to name them.  Let's recast
the example:

Let's say the hypothetical organization California Event Hosters (CEH) decides they need an
extension to provide information required by CA law.  Today, that would probably have to include
a list of known carcinogens (under Prop 65, I think it is); in the future, there might be
others--say, whether the company organizing the event offers same-sex benefits.  So they define
an extension set that includes, among others, CEH-CARCINOGENS.

Now the National Allergists' Group (NAG) wants to create an extension describing what sort of
allergens people might encounter at an event (particularly important for outdoor concerts,
say).  They do a lot of work, and create a good data model for things like the specific
allergens, the concentrations to expect, whether they're different depending on the weather; and
they define them all with the prefix NAG-.

Now along comes the National Environmentally Correct Events Alliances (NECEA), which wants to
create a comprehensive set of properties for describing all the environmental concerns one might
encounter at a particular event.  This would include carcinogens, allergens, and other toxins
actually at the event; but it might also include information on whether the company organizing
the event does anything environmentally unsound.  They put in a lot of work doing data modeling
for various toxins and the various categories of "environmentally unsound"; but they want to
reuse the NAG-* properties and CEH-CARCINOGENS--no sense creating two different data models.

Now suppose that the NECEA extensions take off and become much more widely implemented than the
original CEH or NAG extensions.  Suppose, in turn, that CEH contains many properties that don't
make sense outside of California; the only one that gets widely used is CEH-CARCINOGENS.  Why
should anybody that supports NECEA have to advertise "I support CEH, but not
CEH-SAME-SEX-BENEFITS, CEH-FOO, CEH-BAR,..."? They're more likely to say simply, "I support
CEH", and take their chances when someone sends them an iCalendar containing CEH-BAR.  (Think
it's unlikely? Check your browser's Accept: header; it almost certainly contains */*, "I can
accept anything".)

Oh, and then there's versioning.  What happens when California passes Proposition 1024 and
starts requiring more information, so CEH wants to define a new property? Do they have to put it
in a new extension? Obviously they'd rather just put it into the CEH- extension; but, without
versioning, this would lead to confusion over what "CEH-" contains.

In short, the borders of extension sets will almost certainly become fuzzy over time; and a
capabilities mechanism based on extension sets depends on the borders being crisp.

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |Know your limits, then destroy 'em.          |
[email-masked]|                                             |
\==============================================================/

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Thu, 15 Feb 2001 13:45:28 +0100

Well John as much as I appreciate the effort you put into these examples,
and enjoy your use of absurdity to put your point across, it seems that you
are missing something essential.

As I see the concept, there must be a leeway in our design that recognize
the use-values and use-frequencies of any property or parameter - the push
and pull of the market.

As I have written earlier, any sort of information that can be expressed in
words, can be inserted into the text-value fields of iCal as it stands.
Other media-types can be attached.  So the information you exemplify can be
expressed and digested by those concerned in the contents therein.

Yet some classes of information, feasibly unknown to us at this time, might
reach use-value and corresponding use-frequencies  meriting their climb on
the ladder of visibility.

Step one is layout visibility - special icons, bold fonts, animated gifs and
so on.

Step two would be machine visibility for inclusion or exclusion in automated
queries.

That is why we have chosen the path we took in our WHOW properties.

We could have decided on

WARM-CLOTHES:required

or

REQUIRED:warm clothes

We chose the later since it is doubtful that people will make large scale
queries about events where the wearing of warm clothes is required, but that
people might well want to have a place-holder for all the eventual
requirements of an event.

Now of course there is still this option...

DESCRIPTION: bla, bla, and we require you to dress warmly, bla, bla, bla.

...which may or may not suffice, depending on the value-scale of the
information contained.  For example we do not relegate DTSTART to becoming a
value of the DESCRIPTION property.

By the use of...

REQUIRED:warm clothes

... we expect that if dress-codes where ever to reach (improbable though it
may be) a use-value, use-frequency
that merited it, then the how-to-dress value of REQUIRED would become itself
a constrained value-set - a standardized enumeration or list.

There is of course one more option - that already used in 2445 for
recurrence; Creating a whole new set of rules for a property value.  This
probably happened since the flatness of mime-directory made the use of
properties and parameters to accomplish the task unwieldy.

One advantage to this method is that the whole shebang of recurrence rules
could be updated, in a stroke, by pointing to alternative rule structures,
with out altering any other existing property or parameter of 2445.  EX.

RECURRENCE; according-to="Frank":bla, bla, bla
RECURRENCE; according-to="Hoyle":bla, bla, bla

BTW, What Erik is suggesting, the clustering of extensions by use or domain
is the accepted practice through out the KR world.  That is what schemas are
all about.

I think it is constructive to see which SKiCal properties seem homogeneous
to the business meeting domain as is, you suggest EVENT-LANGUAGE for one,
and then examine the remainders as homogeneous to the TIMESPENDER domain.

Of course my conviction is that in the future users will want both.

Greg

John Stracke answering Eric:

> public events and activities, which is a stronger assertion than "I'm

Actually, that's a good example of what I'm saying: EVENT-LANGUAGE (formerly
LANGUE) could be an
important property for business meetings in some parts of the world.

> that they properties implmement. We should not have new extensions for

Groan.  I called them "Fred's properties" because it was an easy way to name
them.  Let's recast
the example:

Let's say the hypothetical organization California Event Hosters (CEH)
decides they need an
extension to provide information required by CA law.  Today, that would
probably have to include
a list of known carcinogens (under Prop 65, I think it is); in the future,
there might be
others--say, whether the company organizing the event offers same-sex
benefits.  So they define
an extension set that includes, among others, CEH-CARCINOGENS.

Now the National Allergists' Group (NAG) wants to create an extension
describing what sort of
allergens people might encounter at an event (particularly important for
outdoor concerts,
say).  They do a lot of work, and create a good data model for things like
the specific
allergens, the concentrations to expect, whether they're different depending
on the weather; and
they define them all with the prefix NAG-.

Now along comes the National Environmentally Correct Events Alliances
(NECEA), which wants to
create a comprehensive set of properties for describing all the
environmental concerns one might
encounter at a particular event.  This would include carcinogens, allergens,
and other toxins
actually at the event; but it might also include information on whether the
company organizing
the event does anything environmentally unsound.  They put in a lot of work
doing data modeling
for various toxins and the various categories of "environmentally unsound";
but they want to
reuse the NAG-* properties and CEH-CARCINOGENS--no sense creating two
different data models.

Now suppose that the NECEA extensions take off and become much more widely
implemented than the
original CEH or NAG extensions.  Suppose, in turn, that CEH contains many
properties that don't
make sense outside of California; the only one that gets widely used is
CEH-CARCINOGENS.  Why
should anybody that supports NECEA have to advertise "I support CEH, but not
CEH-SAME-SEX-BENEFITS, CEH-FOO, CEH-BAR,..."? They're more likely to say
simply, "I support
CEH", and take their chances when someone sends them an iCalendar containing
CEH-BAR.  (Think
it's unlikely? Check your browser's Accept: header; it almost certainly
contains */*, "I can
accept anything".)

Oh, and then there's versioning.  What happens when California passes
Proposition 1024 and
starts requiring more information, so CEH wants to define a new property? Do
they have to put it
in a new extension? Obviously they'd rather just put it into the CEH-
extension; but, without
versioning, this would lead to confusion over what "CEH-" contains.

In short, the borders of extension sets will almost certainly become fuzzy
over time; and a
capabilities mechanism based on extension sets depends on the borders being
crisp.

---

From: "Greg FitzPatrick" <[email-masked]>
Date: Thu, 15 Feb 2001 14:00:57 +0100

Good thought from Shannon:

Greg: yes we are not alone!

Greg:  X-Microsoft :-)

---

Greg:  Well there is domain-specific usage such as in dentistry and road
construction and there is functional usage such as in drilling.  So I guess
domain-specific makes more sense than functionally-specific
---

Greg:  This defining principle seems a bit fuzzy.  I have a hard time
finding ALL or NOTHING relationships in any iCal or SKiCal properties.

---

Greg: yes. good criteria

Greg:  Agreed, in SKiCal some properties were created simply to avoid
"bending" existing iCal properties.

Shannon

Shannon J. Clark
CEO - JigZaw, Inc

-----Original Message-----

eric.

---

From: John Stracke <[email-masked]>
Date: Thu, 15 Feb 2001 10:38:04 -0500

> Java points to a few possible solutions.

Note that Java does not attempt to bundle a set of classes into an "extension";
classes are named into heirarchical packages, but each class stands
alone--there's no way to say "I have extension sun.foo", and have that imply
that you have sun.foo.bar and sun.foo.baz.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |Just because we are out to get you does not mean|
[email-masked]|you are not paranoid.                           |
\=================================================================/

---

From: George Babics <[email-masked]>
Date: Thu, 15 Feb 2001 10:39:53 -0500

> namespace issues, how to organize components into a logical manner)

  This analogy brings up the question: what if people want to
create extensions of extensions? For instance, an extension to
Skical that only deals with music concerts.

> Summary or Description properties.)?

  If we do have some extension mechanism, we should perhaps consider
having some guidelines or rules for those adding extensions?

---

From: John Stracke <[email-masked]>
Date: Tue, 20 Feb 2001 09:13:42 -0500

Greg FitzPatrick wrote:

> and enjoy your use of absurdity to put your point across

I was not trying to be absurd.  These are perfectly reasonable examples.

> expressed and digested by those concerned in the contents therein.

<boggle> So can all the information in your own proposals (e.g.,
EVENT-LANGUAGE); in both cases, putting them into specific fields lets them be
processed automatically.  The allergens example would permit someone to
configure their CUA to know what they're allergic to, and warn them when an
event is not safe for them.

> with out altering any other existing property or parameter of 2445.

False.  That would break interop, because nobody would understand your
"according-to" parameter.

> is the accepted practice through out the KR world.

Doesn't mean it's correct in our case.  You're talking about documents, I'm
talking about a protocol.  An iCalendar object is not (just?) a document; it's
a protocol message, and it has much stricter interop requirements than a
document.

--
/===============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own. |
|Chief Scientist |==============================================|
|eCal Corp.      |"Dinner Special: Turkey $2.35; Chicken or Beef|
[email-masked]|$2.25; Children $2.00."                       |
\===============================================================/

---

From: Eric Busboom <[email-masked]>
Date: Wed, 21 Feb 2001 14:39:54 -0800 (PST)

> Skical that only deals with music concerts.

Either update the SkiCal RFC or make a new RFC. Flexibility is nice, but
it should only go so far, and in this case that is one level of
extension. 

> having some guidelines or rules for those adding extensions?

I don't think we need this either, since the cost of creating a new
specification, getting it through the IETF, and convincing other vendors
to implement the specification is high enough to weed out really dumb
extensions. 

Besides, the extension is not part of iCalendar, so boneheaded extensions
will not dilute core iCalendar functionality any more than boneheaded X
properties would.

eric.