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

From: [email-masked]
Date: Mon, 28 Aug 2000 14:28:58 -0400

George asked:
>   However, should the property be at the attendee level?
>[Snip]It can look something like:
>
>   ATTENDEE:CONFLICT=FALSE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal

This is probably too fine a level to put it at; allowing the Organizer to 
say that I may not double book the time but Doug or Frank can.  I would 
think that the value would be better suited as a property of the entry 
that applies equally to all:

BEGIN:VEVENT
CONLICTS:FALSE
ATTENDEE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal
...

  I would also suggest that the property convey the Organizers desire but 
is not required to be observed.  For example, I may decide that I would 
want CONFLICT:TRUE for this entry since I only tentatively accepted it. 
This is similar to the Organizer classifying the entry as TRANSP:OPAQUE 
but I change it to TRANSP:TRANSPARENT because Im tentatively going or 
because I do not want it to affect my busytime when others check.  The 
Organzier can convey intent or desire but cannot rule the Attendees world; 
at least not in this respect.

>The user may be able to
>change his or her default, i.e., have a calendar wide CONFLICT property.

CAP Editors: Please be sure that when CAP addresses this issue of both 
calendar level policy (ie: A room cannot be double booked but a user can 
be) and the entry level policy (ie: "You already have an entry for that 
time slot that precludes overbooking this time").  It should allow some 
flexibility in dealing with both as well as just resolving single cases. 

For example, if I have an event conflict but no calendar level policy then 
I would expect some reasonable behaviour (ie: "Do you want to A) 
Reschedule this entry, B) Reschedule that entry, C) Double book anyways 
or...") to be achievable w/o making the CUA jump thru tons of hoops (ie: 
First I must change the blocking entry to CONFLICT:TRUE then I have to 
resave the conflicting one and finally I change CONFLICT:FALSE on the 
blocker.  Ugh!!!)

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: George Babics <[email-masked]>
Date: Mon, 28 Aug 2000 15:30:09 -0400

[email-masked] wrote:
> This is probably too fine a level to put it at; allowing the Organizer to say that I may not double book the time but > Doug or Frank can.  I would think that the value would be better suited as a property of the entry that applies
> equally to all:

>   I would also suggest that the property convey the Organizers desire but is not required to be observed.  For 
> example, I may decide that I would want CONFLICT:TRUE for this entry since I only tentatively accepted it.  This is
> similar to the Organizer classifying the entry as TRANSP:OPAQUE but I change it to TRANSP:TRANSPARENT because Im
> tentatively going or because I do not want it to affect my busytime when others check.  The Organzier can convey
> intent or desire but cannot rule the Attendees world; at least not in this respect.

  I meant that it is the attendee that sets the value of CONFLICT like it
does for PARTSTAT. 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.

> CAP Editors: Please be sure that when CAP addresses this issue of both calendar level policy (ie: A room cannot be
> double booked but a user can be) and the entry level policy (ie: "You already have an entry for that time slot that
> precludes overbooking this time").  It should allow some flexibility in dealing with both as well as just resolving
> single cases.
> 
> For example, if I have an event conflict but no calendar level policy then I would expect some reasonable behaviour
> (ie: "Do you want to A) Reschedule this entry, B) Reschedule that entry, C) Double book anyways or...") to be
> achievable w/o making the CUA jump thru tons of hoops (ie: First I must change the blocking entry to CONFLICT:TRUE
> then I have to resave the conflicting one and finally I change CONFLICT:FALSE on the blocker.  Ugh!!!)
> 
> Bruce