Subject: Subject: Registration of text/calendar MIME property TRANSP

From: [email-masked]
Date: Mon, 21 Aug 2000 21:01:59 -0400

George:
An interesting suggested change to the TRANSP property in iCalendar. 
However, I have some concerns with the suggested proposal.
TRANSP semantics in RFC 2445 are specific to whether a VEVENT calendar 
component creates a busy time interval or not. It has current no semantics 
that indicate whether overlapping or "conflicting" VEVENT intervals can be 
generated. That is, the semantics for TRANSP are singular and orthogonal 
to any other semantics.
Your proposal would create a "side effect" by overloading the TRANSParency 
property with semantics for specifying whether overlapping events might 
also be allowed on an event. Creating side effects is not considered to be 
a good engineering practice. It certainly creates implementation 
complexity.
In past CAP discussions about this idea, it was noted by some that testing 
for an overlap state is difficult to test for as the calendar data base 
grows in size and is also inefficient in such large databases, leading to 
performance considerations. There are other problems too.
There is also the scenario where overlap already exists between two 
existing events (e.g., event "A" and "B"). Now if a proposed event "C" 
that specifies an event interval happens to overlap the event intervals 
for events "A" and "B", how is a request for "no overlap" to be enforced? 
Is the event creation to fail? Or is the event to be created but with a 
non-fatal exception that an overlap already exists? Or is it okay for an 
implementation to take an "implementation dependent" approach to "overlap 
enforcement"? These questions need to be answered prior to addressing this 
proposal.
This raises the additional concern whether this extension would ever be 
widely implemented. If not, why are we proposing it for iCalendar? The 
proposed standard can't progress to draft standard until we see widespread 
implementation of the complete set of iCalendar features.
Earlier, I had remembered CAP conversations about creating a new property 
(e.g., NOCONFLICTS) that would be specified on an event that wanted to 
prevent such overlapping events. What happened to this design approach. 
Whether an individual VEVENT creates busy time should remain an 
independent property from whether overlapping or "conflicting" VEVENT 
calendar components are allowed within a given time interval. 
Don't others see the problems with this proposal, as it current is 
written, too?
-- Frank