[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Subject: Registration of text/calendar MIME property TRANSP
Bruce_Kahn@xxxxxxxx wrote:
>
> 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.
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.
>
> >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: Bruce_Kahn@xxxxxxxx
> Iris Associates Phone: 978.392.5335
> Westford, MA, USA 01886 FAX: and nothing but the FAX...
> Standard disclaimers apply, even where prohibited by law...