Subject: Re: W-23 CAP Calendar property .. overlapped booking

From: Doug Royer <[email-masked]>
Date: Wed, 25 Aug 1999 11:14:05 -0700 (PDT)

> Date: Tue, 24 Aug 1999 13:48:21 -0400
> From: David Madeo <[email-masked]>
> 
> [email-masked] wrote:
> 
> > Suppose your CS doesn't support enforcement of CONFLICTS property? There
> > are a number of calendar systems that don't. I would suggest that CONFLICTS
> > enforcement is another CS CAPABILITIES enumeration.
> > -- Frank
> 
> A given CS can fail to support conflicts in one of two ways.  Either they
> allow conflicts with no way to prevent them, or they disallow conflicts with
> no way to allow them.  Neither is a good solution from the user point of view.
> 
> It occurs to me that "CONFLICTS" will be a per user setting, similar to
> attendance status anyway.  For example:  I send an invite to everyone on this
> list to a weekly conference call (not a bad idea!), and specify "no conflicts
> allowed".  Frank is interested in knowing it takes place but has no intention
> of calling in ever so he allows conflicts.  Doug on the other hand will
> religiously call in, even if he's on vacation so conflicts are not allowed.
> Alex decides that he's stopped caring about this and deletes the item.
> 
> Each of us will have different settings.  You might argue that it's out of
> band then and shouldn't be in CAP, but I disagree.  Any calendar client
> should be able to change the "CONFLICTS" setting of an appt.  Servers should
> be required to honor the setting.

I see it as a calendar setting, not a user setting.  So the owner of
the calendar can set it at both the calendar level and the component
level.

Two people can not book the same car at the same time - no matter what
the user wants.  So a CS implementation may force no conflicts.

A company calendar may list all department events.  So the company
event calendar MUST allow conflicts.  (The conference room calendar
would allow no conflicts).  So a CS implementation may force conflicts
allowed.

The same with a component. I really want to go to this thing. Allow
no conflicts.

I am never going to that thing even if the ORGANIZER sets no
conflicts, yet I need to know that it is happening.  So allow
conflicts all of the time for that component.

Proposal:

  Perhaps one user can REQUEST another does not allow conflicts by
  including it in the REQUEST component.  However calendar users subject
  to access control can change any property/paramater.

I think that addresses both issues. As David pointed out, the
component ORGANIZER might strongly suggest no conflicts. So they
can include it in a component. However the calendar ~owners~ know
best for their calendars.

-Doug
-------------------------------------------------------------------
[email-masked]		http://playground.sun.com/~dougr
Pager:				[email-masked]
801 W. El Camino #131		Work:   (650)786-7599
Mountain View, CA 94040		Ham Radio: N6AAW, Aviation: PP-ASEL

---

From: David Madeo <[email-masked]>
Date: Wed, 25 Aug 1999 17:23:26 -0400

> the calendar can set it at both the calendar level and the component

Agreed, I mispoke when I said user.

>   to access control can change any property/paramater.

I like Bruce's idea about TRANSP.  I think the idea is coming together and the
wording will soon follow.

> best for their calendars.

Exactly.

dmadeo