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

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

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.

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

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
===========================================================================
Bruce Kahn                                INet: 
[email protected]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...