Subject: Re: Subject: Registration of text/calendar MIME property TRANSP

From: [email-masked]
Date: Tue, 29 Aug 2000 16:43:34 -0400

George:
Not sure what the benefit is of allowing a conflict flag parameter on the 
ATTENDEE property. This seems to introduce a level of complexity that may 
be difficult to show interoperability for. I think you would agree that we 
need to nip-in-the-bud any extensions that will negatively impact IOP. 
I can see the scenarios for having a modal, CAP specific, calendar level 
property that says "check and notify me of any conflicts" on events that I 
create during this session. But I see only problems with a modal, calendar 
component level property that is suppose to restrict creation of 
conflicting components. If the property is set of TRUE and you create some 
properties that are overlapping and then you reset the property to FALSE, 
is the calendar system suppose to do anything about the existing 
overlapping events that would otherwise not be allowed with the FALSE 
value? If not, then I think that this property has limited utility.
Better to have a CAP property that merely is active for the session and 
will notify a CUA if they try to create an event that overlaps an existing 
event.
-- Frank

---

From: George Babics <[email-masked]>
Date: Wed, 30 Aug 2000 13:54:18 -0400

[email-masked] wrote:
> 
> George:
> 
> Not sure what the benefit is of allowing a conflict flag parameter on the ATTENDEE property. This seems to introduce a level of complexity that may be difficult to show interoperability for. I think you would agree that we need to nip-in-the-bud any extensions that will negatively impact IOP.

  I am not sure if it will introduce such a level of complexity. If it does,
we will have to examine gain VS interoperability cost.

> 
> I can see the scenarios for having a modal, CAP specific, calendar level property that says "check and notify me of any conflicts" on events that I create during this session. But I see only problems with a modal, calendar component level property that is suppose to restrict creation of conflicting components. If the property is set of TRUE and you create some properties that are overlapping and then you reset the property to FALSE, is the calendar system suppose to do anything about the existing overlapping events that would otherwise not be allowed with the FALSE value? If not, then I think that this property has limited utility.

  The calendar system can ignore any other component that conflicts with the 
component that now has CONFLICT set to FALSE. It will still have the utility to
prevent anyone from inviting the user to any new events during that time slot.

  It could be useful for a user who may often obtain many conflicts, and who,
for certain events, does not want any conflicts, and for other less important
events may allow conflicts (allowing the user to chose from the conflicting
meetings).
  
> 
> Better to have a CAP property that merely is active for the session and will notify a CUA if they try to create an event that overlaps an existing event.

  A user may want to prevent others from double booking him or her, or it
can be used by a resource, such as a room, to prevent double booking.

  However, if it does cause interoperability or implementation problems,
and we see a need for such functionality, we may need to restrict ourselves
to a property that simply checks and notifies the user of any conflicts
that he or she created.

> -- Frank

George