Subject: Overlapped Bookings

From: David Madeo <[email-masked]>
Date: Tue, 19 Oct 1999 14:16:29 -0400

Hi,

I haven't seen any discussion of Overlapped bookings in a while, so I
read through all the email, collected all the ideas and wrote some
text.  Hope you find this
useful.  

Thanks, dmadeo

[ PS Bruce mentioned the possibility of removing the component
property and instead expanding the values for TRANSP.  So instead of
just having TRANSP:OPAQUE and TRANSP:TRANS, you could have (and I'm
paraphrasing), TRANSP:TRANS, TRANSP:TRANS-NOCONFLICT, TRANSP:OPAQUE,
and TRANSP:OPAQUE-NOCONFLICT.  If the calendar property is set to
CONFLICTS:FALSE, then the two OPAQUE (and TRANS) entries are treated
identically, but still defined differently.  Since the calendar
property may be changed back, the component properties do not lose
their settings.  This makes as much sense to me as a specific
component entry for CONFLICTS.  Comments welcome]

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

W-23 CAP Calendar property to allow/disallow                 Y
     booking overlapped or conflicting OPAQUE entries?

1.3 definitions

Overlapped Booking

A policy which indicates whether or not OPAQUE events can overlap one
another.  
When the policy is applied to a calendar it indicates whether or
not any OPAQUE events in the calendar can overlap. When applied to an
individual event, it indicates whether or not it can be overlapped by
any
other OPAQUE event.

2.8 extensions to iCalendar (I'm not sure how this is different than
section 12)

CONFLICTS   A component level property which controls whether overlapped
booking is allowed with this particular component.  This component
property can be changed at any time, regardless of the Calendar
property setting.  Only if the Calendar and the component properties
are set to CONFLICTS:TRUE, will opaque components be allowed to be
overlapped.  The default setting is CONFLICTS:TRUE

6.2 Access Control and CONFLICTS discrepancies

Even if access control allows a CUA to store an event, the CONFLICTS
Calendar or component setting may prevent it, returning an error code
"6.3"

7.2.1.1.1
Result: 6.3  Conflicts not allowed

9.1
(in the VCALENDAR, VEVENT, VTODO, and VJOURNAL sections add the
following)

CONFLICTS

12.2

CONFLICTS N Whether overlapped booking is allowed in this
Calendar. Only if both the Calendar and the component have
CONFLICTS:TRUE will the CS allow another overlapping OPAQUE component to
be scheduled.  If the Calendar CONFLICTS property is changed,
previously scheduled conflicting components are left alone.  Only if
one of the conflicting components is rescheduled to a new time, will
the Calendar setting apply.  The default setting is CONFLICTS:TRUE

dmadeo

---

From: Doug Royer <[email-masked]>
Date: Tue, 19 Oct 1999 13:04:45 -0700

As I have heard others say over the last few emails/months:

	TRANSP is the way to go.

Questions:

	1) At the calendar level, should TRANS-NOCONFLICT or TRANS-CONFLICT
	   be the only ones allowed?

	2) Should TRANSP: be allowed as a STORE property? As a default?
	   overrideable?