Re: CAP-12-e: TRANSP and -NOCONFLICT changes

Doug replied on 05/27/2004 07:10:11 PM:
> This is NOT a CAP issue, this is an 2445 issue as 2445/2446 objects have 

> the exact same
> problem with OPAQUE objects that must be blocked around on pre-CAP 
> implementations.

<CAVEAT> This entire first bit has become a digression from the questions 
but I think that some clarification is in order. </CAVEAT>

Actually it is NOT an issue with the RFCs because they only desribed the 
data model (RFC 2445) and the workflow model (RFC 2446).  For CAP, we 
enhanced/extended TRANSP to include new properties and a slightly 
different usage.  RFC 2445 defined TRANSP simply as:

4.8.2.7 Time Transparency

   Property Name: TRANSP

   Purpose: This property defines whether an event is transparent or not
   to busy time searches.

Note that TRANSP was strictly for transparency on busy time searches and 
nothing more.  However for CAP we have added new values and 
extended/changed the meaning.  With CAP, we are dealing with more than 
just the data and workflow model, we have a client / server model so CAP 
is the first place the concept of overbookings was addressed:

   Overlapped Booking -  A policy which indicates whether or not
      components with a "TRANSP" property not set to
      "TRANSPARENT-NOCONFLICT" or "OPAQUE-NOCONFLICT" value can overlap
      one another.

This implicitly make TRANSP no longer simply for telling "whether an event 
is transparent or not to busy time searches", it clearly adds new meaning 
to TRANSP because it now affects the client / server usage (and hence my 
questions/confusion).  The change is not implicit, its clearly explicit 
with text like:

   TRANSP -  This is a modification the [iCAL] "TRANSP" property and it
      allows more values. The new values are related to conflict
      control. (Section 8.37)

In Section 8.37 I see:

   Purpose: This property defines whether an component is transparent or
   not to busy time searches. This is a modification to [iCAL] "TRANSP"
   property in that it adds some values.

This clearly states that TRANSP is still only defined to indicate "whether 
an component is transparent or not to busy time searches"; there is no 
mention of being used for "conflict control" as the 1st paragraph stated. 
If you read the ABNF comments, you will see that this is just an oversight 
in our new "Purpose" text.

> The fact that some (or all?) implementations do not have a  button 
> performing this
> new user friendly feature does not make CAP broken.

If there is no clear way for simple features to be built in a consistant 
manner then interoperabilitiy between different CAP CUAs and CSs will be 
impossible to achieve.  One CUA will do things one way and if the actions 
are not correctly interperable by another CUA then I claim it is that CAP 
is broken (or at least highly ambiguous).  After all, the ambiguity is 
being introduced by CAP changing TRANSP.

It is not just a simple matter of some GUI button to make things work. The 
problem is that there is _nothing_ in CAP that even remotely describes how 
to deal with issues that arise like in the scenarios I gave.  Even if you 
simplify my scenarios down to 1 day cases ("Im taking next Tuesday off for 
an extra long weekend.") there is still nothing I can find in CAP or in WG 
archives as to how to fully deal with the relatively simple examples. 

If I put a VEVENT with TRANSP:OPAQUE on my calendar for Tuesday then 
everyone can easily see Im not available Tuesday.  I now want to put a 
Cirque du Soleil performance on my calendar with TRANSP:OPAQUE-NOCONFLICT 
so that I dont accidentally overschedule myself.   My CUA can see that I 
have a single VEVENT with TRANSP:OPAQUE on it and so it can see Im busy 
all day Tuesday.  According to the text in CAP, my CUA cannot save the 
VEVENT for the Cirque performance because doing so would be prevented by 
the CS since the new VEVENT has TRANSP:OPAQUE-NOCONFLICT and I have a 
TRANSP:OPAQUE VEVENT already on my calendar.

A simple way to work around this is to have the CUA find the VEVENT with 
TRANSP:OPAQUE and split it into 2 separate VEVENTs, each with 
TRANSP:OPAQUE and that will fill the time on Tuesday before and after the 
Cirque VEVENT.  However I have question how the CUA knows that its proper 
to do this splitting.  You would NOT split "Bastile Day" into 2 sub-day 
VEVENTs would you? 

So what what would allow the CUA to know that Tuesday _is_ splitable?  A 
GUI button is too simple a means because that is indiscriminate and would 
allow your CUA to split "Bastile Day" (or "Memorial Day") into 2 sub-day 
VEVENTs.  If I took the example another step forward, adding another 
OPAQUE-NOCONFLICT VEVENT for a pre-show meal would further split the 
TRANSP:OPAQUE VEVENT down into even more fragments.

There is also the case of dealing with rescheduling the OPAQUE-NOCONFLICT 
VEVENT to a larger or smaller time slot (ie: I factored in too much drive 
time).  Is the CUA expected to repatch the split VEVENT TRANSP:OPAQUE  to 
once again abut the changed OPAQUE-NOCONFLICT entry.  If it does not then 
by shortening the OPAQUE-NOCONFLICT VEVENT I now have a schedulable gap on 
my Tuesday schedule and thats not good.  If it is supposed to repatch, 
what information is it to use to tell it "If this VEVENT is rescheduled, 
dont forget to go update these other VEVENTs so that busytime accurately 
reflects my availabiltiy"?  You can build this with proprietary extensions 
or flags but thats not what we want in CAP is it?

If anyone has the answers to these or can point me to the text in CAP-13 
that Im missing, please post them as I think they are important for 
everyone to understand.

<ALTERNATIVE IDEA>
One way to avoid going down some "divide and repatch" rat hole is to have 
some means for the CUA to tell the CS "Yes I know Bruce is busy at this 
time but he really wants to put this TRANSP:OPAQUE-NOCONFLICT VEVENT on 
the calendar anyway so go ahead and do it."  That is, some means for the 
CUA to convey to the CS my "Yes, go ahead and book this NOCONFLICT entry 
even if there is a conflicting TRANSP:OPAQUE entry" GUI button selection. 
This new mechanism could not be used to overbook other NOCONFLICT entries, 
merely those with TRANSP:OPAQUE. 

I think this would both make it unambiguous how my scenarios would work 
and would still allow us to have NOCONFLICT control where needed.  (Yes 
this would mean a change to CAP as it stands now but it would also mean 
that we clear up much of the ambiguity related to cases like those I 
gave...)   This would also have the benefit of not cluttering up the 
calendar with a bunch of 'sub-day' fragments and the like; its a simple 
and direct means for the CUA to convey the CU's intentions while still 
respecting conflict settings.  After all, NOCONFLICT is new to CAP so 
having a simple and unambiguous means of handling these kinds of scenarios 
would be good for us all.
</ALTERNATIVE IDEA>

>                                                      It makes it a CUA 
> implementation
> feature that can be coded into CUAs with or without CAP using existing 
> 2445 and 2446
> objects (METHOD:ADD).

I dont quite follow Doug here but I dont think its relevant to the 
discussion since TRANSP:OPAQUE-NOCONFLICT is new witn CAP.

> This new feature request (skip over opaque objects and block out a range 

> of time) was
> never in the CAP requirements document and is a new feature request.

This is NOT a new feature request.  Its been part of CAP since at least 
1999 and Im trying to analyze how it will actually work in common 
scenarios.  For some cases its pretty straight forward (ie: reserving a 
conf. room) but not for the ones I listed (ie: managing my personal 
calendar).  Thats why Im asking for clarification and suggesting an 
alternative idea.

Bruce
===========================================================================
Bruce Kahn                                INet: 
[email protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear.