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? David Madeo wrote: &gt; &gt; Hi, &gt; &gt; I haven't seen any discussion of Overlapped bookings in a while, so I &gt; read through all the email, collected all the ideas and wrote some &gt; text. Hope you find this &gt; useful. &gt; &gt; Thanks, dmadeo &gt; &gt; [ PS Bruce mentioned the possibility of removing the component &gt; property and instead expanding the values for TRANSP. So instead of &gt; just having TRANSP:OPAQUE and TRANSP:TRANS, you could have (and I'm &gt; paraphrasing), TRANSP:TRANS, TRANSP:TRANS-NOCONFLICT, TRANSP:OPAQUE, &gt; and TRANSP:OPAQUE-NOCONFLICT. If the calendar property is set to &gt; CONFLICTS:FALSE, then the two OPAQUE (and TRANS) entries are treated &gt; identically, but still defined differently. Since the calendar &gt; property may be changed back, the component properties do not lose &gt; their settings. This makes as much sense to me as a specific &gt; component entry for CONFLICTS. Comments welcome] &gt; &gt; ---------------------------------------- &gt; &gt; W-23 CAP Calendar property to allow/disallow Y &gt; booking overlapped or conflicting OPAQUE entries? &gt; &gt; 1.3 definitions &gt; &gt; Overlapped Booking &gt; &gt; A policy which indicates whether or not OPAQUE events can overlap one &gt; another. &gt; When the policy is applied to a calendar it indicates whether or &gt;