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

From: [email-masked]
Date: Mon, 21 Aug 2000 21:11:51 -0400

(I may have ruined the discussion thread by posting my previous concern 
with this proposal with a prefix of "Re:" in the subject line. My 
apologies!)
George:
Another thought...
I can understand the requirement to allow a CUA to interact with a CS to 
negotiate the desire to avoid overlapping events. Maybe this should be a 
modally set calendar property?
-- Frank

---

From: [email-masked]
Date: Tue, 22 Aug 2000 13:17:28 -0400

Doug:
In either case, let's make sure that the change request has a clear 
definition of the exception cases and how they are handled.
BTW, separating this out from TRANSP would be my preference.
-- Frank

---

From: [email-masked]
Date: Tue, 22 Aug 2000 13:38:00 -0400

Bruce:
>Hmm, originally I also talked about letting the Organzier 'request' the 
priority of the entry via TRANSP instead of CONFLICT >but that the 
recipient did not have to obey it.  Does it make more sense for _that_ 
case to n-state TRANSP or can it be done >via a combination of 
TRANSP/CONFLICT (ala the pseudo code above)?? 

Actually, having a n-state TRANSP is what we had in vCalendar. You may 
remember that we had an integer value on TRANSP. We had a value of zero 
mean that the entry will block time and be factored into a busy time 
search. A value of one meant that the event was truly transparent and 
would not block time. A value other than that was implementation 
dependent. The original design ideas were that other values would act 
similar to the "layering" in CAD drawings. Busy but reschedulable (a value 
of 2). Busy but schedulable with overlapping events(a value of 3), busy 
and no conflicts (a value of 4). But we got rid of integer values in 
iCalendar...
In any case, the discussion seems to be going towards a disjoint property 
for CONFLICTS. Back to where we were back some time ago on the list.

>Also looking back over the original thread, I do not see a clear 
concensus to some of the issues (esp. CS enforcment vs >CUA enforcment in 
some cases).  Perhaps there has been some new cycles spent on this out of 
bounds to fix this... 

Yep. No consensus. Which is why I guess this gets brought up again ;-)

---

From: [email-masked]
Date: Thu, 31 Aug 2000 11:31:16 -0400

George wrote:
>That is, the attendee, and not the Organizer, who decides
>whether one may double book that attendee at that time. The Organizer can 
still
>give a suggestion of whether double booking be allowed or not.

This would argue more for a separate property rather than a parameter on 
an ATTENDEE since it applies to the entry in the Attendees calendar rather 
than being a property of the person itself.  Kind of like TRANSP...

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...