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

From: Doug Royer <[email-masked]>
Date: Wed, 18 Aug 1999 08:13:08 -0700 (PDT)

> Date: Wed, 18 Aug 1999 02:00:55 -0400
> From: David Madeo <[email-masked]>
> 
> Doug Royer wrote:
> 
> >  W-23 CAP Calendar property to allow/disallow   U
> >       overlapped booking OPAQUE entries?
> >
> > There was a proposal to add a calendar property for this.
> > There was discussion, and I did not see any objections.
> >
> > Change this to a 'Y' ?
> 
> I think this is an extremely useful property, but I recall discussion
> that we might want this at the VEVENT level as well as at the calendar
> level.

Yep - I forgot that.

If there is no objection to this then next week I'll change
the status to 'Y' and take the email on this topic that has
been discussed and send out some proposed text.

-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: [email-masked]
Date: Wed, 18 Aug 1999 15:40:14 GMT

HHHmmmmmmm.

---

From: [email-masked]
Date: Wed, 18 Aug 1999 16:15:52 GMT

>that we might want this at the VEVENT level as well as at the calendar

Not sure what you mean by the VEVENT level. Specifying CONFLICTS as a
calendar property would assure that you can block overlapping VEVENTS.
However, it is very problematic to have this as a component property. This
seems to be something that is best addressed via CUA interaction; either
manually or through an agent. Or, you can address this requirement via a
combination of TRANSP:OPAQUE and PRIORITY:1..n properties. However, I am at
a loss as to how you would "enforce" the CONFLICTS:FALSE value that is in
one VEVENT when processing other VEVENTs that could have been emailed to
your calendar as iMIP messages.

-- Frank

---

From: Doug Royer <[email-masked]>
Date: Wed, 18 Aug 1999 09:44:30 -0700 (PDT)

> From: [email-masked]
> Date: Wed, 18 Aug 1999 16:15:52 GMT
> 

Having the property at the COMPONENT level would simply standardize
the way that a CS would enforce a VEVENT specific rule.

Frank - what you stated above TRANSP:OPAQUE and PRIORITY:1 does not
keep another TRANSP:OPAQUE and any PRIORITY from being inserted into
the calendar.  And there is no text that I recall in any of the RFCs
or drafts that implies that TRANSP:OPQAUE and PRIORITY:1 implies do
not double book this time.

I see that the WG has to make one of these decisions:

	1) No to calendar level property.
	   No to component level property.
		
	2) Yes to calendar level property.
	   No to component level property.
	
	3) No to calendar level property.
	   Yes to component level property.
	   
	4) Yes to calendar level property.
	   Yes to component level property.

If the WG goes for 2, 3, or 4, then we need to decide on any CAP text.

I propose we go with item 4 above.

-Doug

---

From: [email-masked]
Date: Wed, 18 Aug 1999 17:14:01 GMT

>been discussed and send out some proposed text.

NO, I object. We should be reviewing the proposed text prior to changing 
the status of this work item.
Per my previous note to Dave. I think there are real problems with making 
this a component property. I see the justification for this as a calendar 
property. BUT, we need the proposed text for the CONFLICTS boolean 
component property.

---

From: Doug Royer <[email-masked]>
Date: Wed, 18 Aug 1999 10:18:56 -0700 (PDT)

> Date: Wed, 18 Aug 1999 17:14:01 GMT
> 
> >> 

Okay - I was proposing that we first decide if this is something
we want to do, then if yes - we add an action item to the CAP
document to produce some text.

There seems to be consensus for a calendar property.
Does the WG agree?

There seems to be some dispute for a component property.

-Doug

---

From: [email-masked]
Date: Wed, 18 Aug 1999 17:32:41 GMT

Doug:
Having CONFLICTS as a component property just doesn't scale. If I have to 
search through all 3200 entries currently on my calendar to figure out if 
I can book a conflicting event, each time I get either an SCS "REQUEST" or 
a CCS "CREATE" CAP command we are doomed!
This should only be a calendar level property for performance and 
scalability reasons. 
You are entirely RIGHT! Using transparency and priority doesn't say you 
can't schedule conflicts. It does say what the CUA should do for UI 
display (for example) when it retrieves these from the CS. For example a 
PRIORITY:1 event conflicting with a PRIORITY:2 event might be displayed to 
show the conflict but different priorities.
There is also the issues of the practicality of making this a component 
property. For example, how can I have a DATE event for July 14th, Bastille 
Day if there is an event for 1-2PM on July 14th for an obligatory meeting 
with my manager? Naw, the interactions of this at the event level will add 
a level of complexity that we just haven't thought out.
If the calendar allows CONFLICTS:TRUE, then we should allow a CS to define 
them as such.
-- Frank

---

From: [email-masked]
Date: Wed, 25 Aug 1999 10:07:17 -0400

Doug wrote:
>Which brings up another point (I think you were saying).  That if the
>property exists in a component, then it would only apply to
>TRANSP:OPAQUE components.

This would argue in favor of not making 2 properties that need to be 
checked but rather changing TRANSP: to be n-stated (ie: TRANS, OPAQUE, 
OPAQUE-NOCONFLICTS).  Are you suggesting this or am I just ahead of the 
thought process on this??

I think having 2 properties that control each other (ie:

<PSEUDOCODE>
IFF TRANSP:TRANS
        ignore CONFLICTS: 
ELSE IFF CONFLICTS:TRUE 
                RETURN("OK") 
        ELSE
                RETURN("BUZZ OFF")
</PSEUDOCODE>

is just ugly.  This was one motivation for collapsing required, optional, 
etc down and including into ROLE= on ATTENDEEs.  However if we do this, it 
couldn't be a property of the Calendar (ie: outside a vEvent) since we do 
not have TRANSP: on calendars... 

Then again, if TRANSP and CONFLICTS were exclusive of each other I could 
use TRANSP: TRANS and CONFLICTS:FALSE to leave holes in my busytime and 
still block them from being booked by others.  A novel ideal some folks 
would enjoy playing with Im sure.

 Hmm, choices, choices...

Bruce
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: [email-masked]
Date: Wed, 25 Aug 1999 10:18:26 -0400

Dave replied:
>Any calendar client should be
>able to change the "CONFLICTS" setting of an appt.  Servers should be 
required
>to honor the setting.

To a point, yes.  However if CONFLICTS is a policy setting on a resources 
calendar then perhaps noone should be allowed to override the setting nor 
should the Organizers setting take effect.  You may say "Conflicts OK" 
when reserving a resource but then what happens if someone else does the 
exact same thing?  You wind up w/2 meetings in the same room!!  Not good 
(unless you are higher on the food chain).

  Also, if I have an appt that I mark as CONFLICTS:FALSE and then I want 
to add something to my calendar that would conflict, should I not be able 
to do so if I tell the CS "Yes, I really really want to add this 
conflicting entry".  For example, my boss sends out 6 months of team 
meeting notices w/CONFLICTS:FALSE on them and I accept them.  I then try 
to plan my vacation for a week in that time frame and I enter a 5 day 
event that conflicts w/the prior request.  Shouldnt I be able to say "Yes 
CS, I know it conflicts but I want it to." or "Yes CS, I know it conflicts 
but do it anyways"??  As long as my calendars policy allows for conflicts 
(or has no knowledge of conflicts as previously noted) then I should be 
able to do it.

  Making me DECLINE my attendance it not always acceptable.  If Im in IETF 
Los Angelos then I can easilly attend via teleconference (and Ive done 
that.)

Semi-bottom line:
  The CS should enforce policy settings but its unclear how lower level 
settings (ie: on particular entries) should be handled to cover all bases.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Wed, 25 Aug 1999 10:58:23 -0700 (PDT)

> Date: Tue, 24 Aug 1999 16:59:02 GMT
> 
> 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.

Yes - for both calendar level and component level.

-Doug

---

From: Doug Royer <[email-masked]>
Date: Wed, 25 Aug 1999 10:57:08 -0700 (PDT)

> Date: Tue, 24 Aug 1999 12:03:46 -0400
> From: Alexander Taler <[email-masked]>
> 
> Doug Royer wrote:
> > 
> > > Date: Wed, 18 Aug 1999 17:32:41 GMT
> > >
> > > Doug:
> > I can certainty make it scale :-)  On other words IF it were a standard
> > - don't do it that way and you will not have a performance or
> > salability problem :-)
> > 
> > Example:  In your implementation have a look-aside persistent cache
> > for each calendar of the VFREEBUSY time.  Make it a 3 state mask;
> > BUSY, BUSY-NO-DUPS, FREE. If someone schedules time and that
> > time is not BUSY-NO-DUPS - nothing to look up.
> 
> ...
>
> They both sound like the same amount of work to me, and having 
> CONFLICTS at the component level increases flexibility a _lot_,
> so we need it.

Me too.
 
> And, what I hope is a clarification:
> 
> Who polices the CONFLICTS property?  I presume that the CS does.
> Does it mean an error code which I receive in response to a 
> CREATE, which indicates that a conflict was found?

It would have to in some way.

We need to think if this opens a security hole. If a person
does not have permission to get your VFREEBUSY, but does have
permission to invite you via REQUEST, we need to make sure
the result code is closer to 'no' than 'busy'.

-Doug

---

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

> From: [email-masked]
> Date: Wed, 25 Aug 1999 10:07:17 -0400
> 
> Doug wrote:

I had not thought of that.

> is just ugly.

Yep ugly.

> ...  However if we do this, it 

Sure it could - the default TRANSP for the calendar? :-)

> would enjoy playing with Im sure.

That would solve an issue that Frank discussed.  It was something
like; I need 15 minutes before, and 15 minutes at the end of a meeting
in order to walk to/from the meeting.  The time need to be blocked
and is not part of the meeting (VEVENT).

-Doug

---

From: Doug Royer <[email-masked]>
Date: Fri, 27 Aug 1999 12:18:42 -0700 (PDT)

> Date: Fri, 27 Aug 1999 16:37:31 GMT
>
> >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.
> 
> Doug: This implies that the event that you are not going to has 
> TRANSP:TRANSPARENT set on it. If you don't want to go, then you won't have 
> it block time. CONFLICTS:FALSE will only prevent conflicting events that 
> have TRANSP:OPAQUE.

Yep. That how I see it :-)

> But I do agree now (looks like we all can be convinced of one thing or 
> another!) that CONFLICTS property ought to be also allowed on a component.
> However, what is the impact if the calendar has a calendar property 
> CONFLICTS:FALSE and the component has a component property CONFLICTS:TRUE? 
> Can you specify this? You may say NO! But what is the component property 
> is set prior to the calendar property being set? See some of the 
> complexity in enforcing this?

I don't see why it can't be an implementation detail.

One implementation can have it as a rule (Only one person
can book a single car). All attempts to set it to the other
way in a component can be permission denied as if you did
not have the VCAR to do that - hard coded into the CS.

Another implementation can have it be the default by allowing
the component to have an entry that conflicts with the
calendar default. And the component is that last word for
conflicts - hard coded into the CS.

It is just a property. Users simply have or do not not have
permission to change it.

I can't think of any case where a calendar would mandate that
all components MUST allow conflicts. But if someone did, then
that implementation could simply allow it.

-Doug

---

From: [email-masked]
Date: Tue, 31 Aug 1999 21:27:55 GMT

David Madeo wrote:

>Two appts (both with CONFLICT:TRUE) created which conflict while calendar
>property is set to CONFLICTS:TRUE.    Calendar property is changed to
>CONFLICTS:FALSE.  Two events are still in conflict, but that's ok.
>
>If I update one of the appts, it should generate a conflict error asking 
the
>user to pick a different time.  If I had updated the time to a new time 
which
>was in also in conflict,  the CS would not allow it.  It shouldn't allow
>updates (even for things we previously allowed) to conflict either.

If all I am doing is correcting a mis-spelling in the SUMMARY property, I 
certainly don't think that I should have to pick a new time. My event has 
a CREATED date/time that was before the calendar CONFLICTS property was 
changed from TRUE to FALSE. 
This whole scenario leads me to believe that conflict resolution for 
overlapping meetings should be something that the CUA detects and 
addresses, not the CS. 
I TOTALLY disagree with your proposal for preventing me from making any 
such changes. I am not certain that the discussion, to this point, has 
adequately followed through on understanding the impact of this line of 
reasoning to the CUA and CS, as well as the impact to foreign CUAs that 
have either sent iTIP or used CAP CREATE commands.
-- Frank

---

From: [email-masked]
Date: Tue, 31 Aug 1999 21:54:28 GMT

>I don't see why it can't be an implementation detail.
How about "interoperability". If this is an implementation detail, then 
were do we get the guarantee that it will have the same behavior on two 
different CSs that receive the same CAP command?

>not have the VCAR to do that - hard coded into the CS.
This sounds like we are building in non-interoperable options.

>It is just a property. Users simply have or do not not have
Then this would be come yet another VCAR policy? Will this be 
interoperable amongst at least two different implementations? If not, then 
this is not a feature we want to codify.

>that implementation could simply allow it.
Some calendar systems just allow conflicting appointments/meetings. This 
would present itself as not supporting the CONFLICTS:FALSE. Or would the 
CS return an error if the CUA tried to set this on this event?
-- Frank