Subject: Re: CAP: inconsistency in Overlapped Booking definition

From: George Babics <[email-masked]>
Date: Mon, 11 Feb 2002 17:38:04 -0500

I propose we change the definition to:

Overlapped Booking

         A policy which indicates whether or not OPAQUE entries can
         overlap one another in a calendar.

Or we remove the definition. It seems to refer to the ALLOW-CONFLICT
property in VAGENDA. Do we need the definition of two different terms
that mean the same thing?

The old definition was:

  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 the time span of any entry (VEVENT,
         VTODO, ...) in the calendar can overlap the time span of any
         other entry in the same calendar.  When applied to an
         individual entry, it indicates whether or not any other entry's
         time span can overlap that individual entry.

George

George Babics wrote:
> 
>   Yes it seems wrong. Anyone know of why we need or wanted Overlapped
> Booking policies for individual entries?
> 
>   If there are no objections, I'll fix the definition of
> Overlapped Booking.
> 
> George
> 
> John Stracke wrote:
> >
> >   In section 1.3, the definition of Overlapped Booking says it's a
> > policy that can be applied to a calendar or an individual entry.
> > However, the definition of Calendar Policy seems to indicate that
> > policies apply only to calendars; this is inconsistent.
> >
> > In any case, it seems like an Overlapped Booking policy for individual
> > entries would be redundant, since the same effect can be obtained by the
> > TRANSP property on VEVENTs.
> >
> > --
> > /=================================================================\
> > |John Stracke    | http://www.ecal.com |My opinions are my own.   |
> > |Chief Scientist |================================================|
> > |eCal Corp.      |Dave Barry for President! He'll Keep Dan Quayle.|
> > [email-masked] <mailto:[email-masked]>|(OK, it's old)                                  |
> > \=================================================================/

---

From: Doug Royer <[email-masked]>
Date: Mon, 11 Feb 2002 17:11:33 -0700

>          overlap one another in a calendar.

I am not sure what you are saying.

If you are saying there are two definitions and you want to
clean that up - GREAT. However the new text your are proposing
seems to drop some information.

If you are saying drop the component specific:

	TRANSP:TRANSPARENT-NOCONFLICT
and
	TRANSP:OPAQUE-NOCONFLICT

No - they were debated and added for a reason.

There were two needs:

(1) Setting a rule for the calendar which the components can not
    violate. Which allows the calendar to never allow overlapped
    bookings. This was ALLOW-CONFLICTS and I think it needs to stay.
    Otherwise it is difficult to have a resource calendar. If you
    are saying you want to change the name of the property - I have
    no problem with that.

(2) The other is when a specific component can not be overlapped with
    any other component but other components in the same calendar might
    allow overlapping between each other.

We need to keep both, that is we need to keep the
calendar level ALLOW-CONFLICTS and both of the new TRANSP
property values TRANSPARENT-NOCONFLICT and OPAQUE-NOCONFLICT
that are defined in CAP.

And the text definition for Overlapped Booking need to
describe both (1) and (2).

> that mean the same thing?

I am not sure what the 'other' term is? (1) ALLOW-CONFLICT
and (2) ???

See my comments to John's post below.

> > > In any case, it seems like an Overlapped Booking policy for
> > > individual entries would be redundant, since the same effect
> > > can be obtained by the TRANSP property on VEVENTs.

The definition for Overlapped booking in section 1.3 describes
both the TRANSP and calendar wide setting ALLOW-CONFLICTS.

I don't see the conflict you are describing.

5.2 Access Control and NOCONFLICT

   The TRANSP property can take on values (TRANSPARENT-NOCONFLICT,
   OPAQUE-NOCONFLICT) that prohibit other events from overlapping it.
   This setting overrides access.  The ALLOW-CONFLICT Calendar or
   component setting may also prevent overlap, returning an error code
   "6.3"

And as it is an 'or'; Then ALLOW-CONFLICT set to FALSE means
that the entire calendar is blocked from overlapped components
no matter what the component entry says.

A meeting room calendar for example would have ALLOW-CONFLICT
set to FALSE and no one could double book the same time.
This was preferred to forcing the CUA to guess why the bookings
failed with permission denied if they did not book a time slot.
Even if the CUA deposited an entry that said TRANSP:OPAQUE
and not TRANSP:OPAQUE-NOCONFLICT as pre-CAP CUA will do.

The reason for allowing single component overlap blocking:
There are times when you can't be two places at once (vacation
for example) and yet you may wish to have other times slots where
you have not yet decided which to attend (This boring meeting
or the other boring meeting).