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

From: [email-masked]
Date: Wed, 19 May 2004 16:55:42 -0400

In trying to picture how the new TRANSPARENT-NOCONFLICT and 
OPAQUE-NOCONFLICT TRANSParency property values would function I ran into a 
bit of a quandry about how something would work given the new values.  In 
particular I see 2 scenarios where I see some potential problems with CU 
confusion or frustration.  So I thought Id ask the WG for some help in 
understanding/resolving it.

Sceneario 1: I am going on vacation and I want to block off that entire 
week from my calendar.  I also want to make sure I do not overbook myself 
for, say, Wednesday afternoon when my family and I have reservations to 
some special activity at a particular time (ie: "Island boat tour from 3 - 
5PM, no rainchecks or refunds").

For this case I would normally expect to create either an entry that spans 
all week and has TRANSP:OPAQUE so that my coworkers know Im out that week. 
 However, given the rules for TRANSPARENT-NOCONFLICT and 
OPAQUE-NOCONFLICT, I cannot later add that special Wednesday event to my 
calendar with either -NOCONFLICT value.  Trying to do so would result in 
my CUA being given a REQUEST-STATUS:6.2; response code.

So just how would I block off the entire vacation week and have that 
special event on my calendar?  Possible solutions include:

        A: Do not use an OPAQUE-NOCONFLICT property value for either 
entry.  This though could allow me to overbook myself for that special 
activity.

        B: Split the preexisting week long blocker into a "before special 
event" block and an "after special event" block.  While doable, it does 
introduce some other potential issues:

                1: If the special event gets rescheduled, the same process 
would need to be repeated.  Also, this would leave a non-OPAQUE slot in my 
availability that should not be there.
                2: If the special event is cancelled (ie: rained out) then 
I now have an available spot in my availability that should not be there.

Scenario 2: I want to go on vacation for 2 weeks and block out my time 
accordingly.  However I have a bi-weekly team meeting with a 
TRANSP:OPAQUE-NOCONFLICT so I cant just make a blocking entry that spans 
my entire vacation block.

So again Im not sure what the expected / correct set of actions would be 
for me to be able to block out my vacation time when I have a pre-existing 
OPAQUE-NOCONFLICT entry.  Just because Im on vacation does not mean I want 
to delete the team meeting from my calendar.  I may be the Organizer of it 
and as such clearly do not want to CANCEL it or delete it for everyone. 
Besides even if I make the VEVENT have a STATUS:CANCELLED, that does not 
mean the TRANSParency value is ignored since the entry still exists in my 
calendar.

One possible solution would be to locally change my copy of the VEVENT to 
be TRANSP:OPAQUE (not OPAQUE-NOCONFLICT) and then save the vacation entry. 
 This however would mean that my version is no longer in sync with the 
version the other ATTENDEEs have.  So if I were to delegate it to someone 
else, my CUA would have to know to restore the original OPAQUE-NOCONFLICT 
on the copy it sent to my designee.  Other bad sideffects of this solution 
is that if I were the Organizer then if I were to do any updates to it 
(before going on vacation) then the instance affected would also get a 
TRANSP:OPAQUE value which would allow others to overbook now and thats not 
what I would expect.

The (B) solution above could be equally applied here too but again there 
are undesirable side effects in doing this.

So can someone please explain how to solve these simple scenarios?  While 
I see and understand the uses for the new -NOCONFLICT values, Im having a 
hard time visualizing their practical use in some simple cases.

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

---

From: Doug Royer <[email-masked]>
Date: Thu, 20 May 2004 10:49:17 -0600

This was discussed on this list before. The solution is:

Make your new TRANSPARENT-OPAQUE object a series of recurring objects 
that span all
of the non-opaque time and insert them into your calendar.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards

---

From: [email-masked]
Date: Thu, 27 May 2004 18:28:30 -0400

> This was discussed on this list before. The solution is:

Thanks for your quick response.  However I do no recall us discussing 
actual scenarios like the 2 I posted, merely discussing usage examples for 
the proposed new -NOCONFLICT values (ie: "Making sure a conf. room is 
never overbooked."). 

So in the interest of fairness and accuracy I did a full text scan of the 
archives back to 1996 and I found just 27 messages (excluding this new 
thread) that have the word "NOCONFLICT" in them:

Date
Subject
10/19/99
Overlapped Bookings (David Madeo <[email-masked]>)
10/19/99
        Re: Overlapped Bookings (Doug Royer <[email-masked]>)
08/18/2000
Subject: Registration of text/calendar MIME property TRANSP (George Babics 
<[email-masked]>)
08/21/2000
        Re: Subject: Registration of text/calendar MIME property TRANSP 
([email-masked])
08/21/2000
                Re: Subject: Registration of text/calendar MIME property 
TRANSP (Doug Royer <[email-masked]>)
08/21/2000
                [Fwd: Returned mail: Host unknown (Name server: imc.or: 
host not found)] (Doug Royer <[email-masked]>)
08/22/2000
                        Re: Subject: Registration of text/calendar MIME 
property TRANSP ([email-masked])
08/22/2000
                                Re: Subject: Registration of text/calendar 
MIME property TRANSP (Doug Royer <[email-masked]>)
02/11/2002
                        Re: CAP: inconsistency in Overlapped Booking 
definition (Doug Royer <[email-masked]>)
01/08/2002
CAP (NO CONFLICT and ALLOW-CONFLICT) (Doug Royer <[email-masked]>)
06/14/2003
        CAP ABNF (Doug Royer <[email-masked]>)
02/23/2003
CAP REQUEST-STATUS - update and proposals (Doug Royer <[email-masked]>)
03/13/2003
        Re: CAP Last call??? ([email-masked])
04/01/2003
        Re: CAP & busytime? - CUA-BOT (Doug Royer <[email-masked]>)
04/02/2003
                Re: CAP & busytime? - CUA-BOT ("Preston Stephenson" 
<[email-masked]>)
04/02/2003
                                                Re: CAP & busytime? - 
CUA-BOT ([email-masked])
04/02/2003
                                                        Re: CAP & 
busytime? - CUA-BOT (Doug Royer <[email-masked]>)
04/03/2003
                                                                Re: CAP & 
busytime? - CUA-BOT ([email-masked])
04/02/2003
cap-10 sections 1-5 comments/questions (mostly boring) (Dan Winship 
<[email-masked]>)
07/22/2003
                        Re: Cap Free-Busy Request - vs QUERY? (Doug Royer 
<[email-masked]>)
07/23/2003
                                Re: Cap Free-Busy Request - vs QUERY? 
("Craig Johnson" <[email-masked]>)
07/22/2003
                Re: Cap Free-Busy Request - vs QUERY? ("Craig Johnson" 
<[email-masked]>)
07/22/2003
                        Re: Cap Free-Busy Request - vs QUERY? (Doug Royer 
<[email-masked]>)
10/02/2003
                                Re: When to publish -12 - VFREEBUSY 
("Craig Johnson" <[email-masked]>)
11/25/2003
                                Re: Clarification for Free/Busy (Doug 
Royer <[email-masked]>)
01/19/2004
CAP-12: 10.12.1 Searching for VFREEBUSY ([email-masked])
01/19/2004
        Re: CAP-12: 10.12.1 Searching for VFREEBUSY (Doug Royer 
<[email-masked]>)

None of them actually discuss scenarios like I asked about.  BTW: I 
noticed that Dougs postings from 19-Oct-1999 and 8-Jan-2002 had questions 
noone ever responded to also and we never resolved... 

As I sorted thru thse postings I also noticed that my recent comment about 
the ABNF comments on TRANSP were initially posted back in Aug-2000 so its 
not something that was just now discovered.

I did find that Doug responded with the same basic response in one of his 
1-Apr-2003 replys under the "CAP & busytime? - CUA-BOT" sub-threads. 
However that was just his response that one time, not an actual discussion 
by the WG on how to approach it..   Plust it was just 1 paragraph in a 
very active discussion thread, not really a WG discussion and agreement of 
the behaviour.

> of the non-opaque time and insert them into your calendar.

This suggestion has 2 points that still need to be addressed:

1: Not every implementation breaks entries like "Vacation" into repeating 
daily entries that span the entire week.  For example, both Notes and 
Outlook allow users to specify a single instance entry that blocks the 
entire time/set of dates.  As such, users have come to rely on this 
ability.  Even if it was changed under the covers to be multiple daily 
instances (something we are loath do consider given that what we both have 
currently works just fine), there is still...

2: My original "B" issue that comes from needing to reschedule or 
otherwise change the "exception" NOCONFLICT entry.  That was:

>         B: Split the preexisting week long blocker into a "before 
> special event" block and an "after special event" block.  While 
> doable, it does introduce some other potential issues: 
> 
>                 1: If the special event gets rescheduled, the same 
> process would need to be repeated.  Also, this would leave a non-
> OPAQUE slot in my availability that should not be there. 
>                 2: If the special event is cancelled (ie: rained 
> out) then I now have an available spot in my availability that 
> should not be there. 

For B.1, how is the CUA to know that it can (MUST actually) rework the 
TRANSP:OPAQUE halves before and after the new NOCONFLICT entry if the 
entry is reschedule?  To do so would require some extra metadata that we 
have never defined or discussed. 

Just how is a CUA to know that it needs to 'repair' the hole left by #B.2 
by either consolidating the "before" and "after" TRANSP:OPAQUE entries 
into a single "all day" instance (again)?  To do so requires that the CUA 
have some way of 'knowing' that the OPAQUE entries before and after are 
part of the same "vacation" and thus 'mergable' into a larger entry that 
takes all day.

BTW: if my TRANSP:OPAQUE-NOCONFLICT event has STATUS:CANCELLED then one 
could argue that it should no longer be OPAQUE-NOCONFLICT since its been 
cancelled (but its still on the calendar for legal/historical/personal 
reasons).

So far I am not convinced that what Doug suggested method is the 
sole/correct way to solve my scenarios or that it is even buildable with 
what we have currently in the RFCs or the CAP draft.  Dougs suggestion A) 
is not codified in CAP in any form and B) does not address all the issues 
inherent in that kind of design.

Can anyone help clarify this ambiguity/confusion for me?

Bruce
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Thu, 27 May 2004 17:10:11 -0600

[email-masked] wrote:

> 1: Not every implementation breaks entries like "Vacation" into 
> repeating daily entries that span the entire week.  For example, both 
> Notes and Outlook allow users to specify a single instance entry that 
> blocks the entire time/set of dates.  As such, users have come to rely 
> on this ability.  Even if it was changed under the covers to be 
> multiple daily instances (something we are loath do consider given 
> that what we both have currently works just fine), there is still... 

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.

The fact that some (or all?) implementations do not have a  button 
performing this
new user friendly feature does not make CAP broken. 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).

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.

Sounds like a good add-on draft idea.

--

---

From: [email-masked]
Date: Fri, 28 May 2004 15:52:19 -0400

> problem with OPAQUE objects that must be blocked around on pre-CAP 

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

> 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 

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

> 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

---

From: Doug Royer <[email-masked]>
Date: Fri, 28 May 2004 15:34:58 -0600

[email-masked] wrote:

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

It is true that CAP adds to the OPAQUE object types in 2445. It however 
cap does not introduce OPAQUE
objects as a new concept and even if CAP did not add new OPAQUE object 
types, the problem still exists
in existing 2445/2446 objects.

Again, not a CAP issue.

--