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

[Bruce_Kahn@xxxxxxxxxxxxxxxx]

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: Bruce_Kahn@xxxxxxxxxxxxxxxx
Messaging & Collaboration            
    Phone: 978.399.6496
IBM Software Group                
        FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear.