Subject: Re: Subject: Registration of text/calendar MIME property TRANSP

From: [email-masked]
Date: Tue, 22 Aug 2000 11:48:14 -0400

Doug noted:
>There was a large discussion on this WG list about
NOCONFLICT.

Actually it was about CONFLICTS:TRUE/FALSE (All under the Subject "W-23 
CAP Calendar property .. overlapped booking" starting 17-Aug-1999).

>The original proposal was that both the
>Calendar and components needed a NOCONFLICT - I think
>it was Bruce's idea,

Actually I wrote:
>>Which brings up another point (I think you were saying).  That if the
>>property exists in a component, then it would only apply to
>>TRANSP:OPAQUE components.
>
>This would argue in favor of not making 2 properties that need to be 
checked but rather changing TRANSP: 
>to be n-stated (ie: TRANS, OPAQUE, OPAQUE-NOCONFLICTS).  Are you suggesting this or am I just 
>ahead of the thought process on this?? 
>
>I think having 2 properties that control each other (ie: 
>
><PSEUDOCODE> 
>IFF TRANSP:TRANS 
>        ignore CONFLICTS: 
>ELSE IFF CONFLICTS:TRUE 
>                RETURN("OK") 
>        ELSE 
>                RETURN("BUZZ OFF") 
></PSEUDOCODE> 
>
>is just ugly.  This was one motivation for collapsing required, optional, 
etc down and including into ROLE= 
>on ATTENDEEs.  However if we do this, it couldn't be a property of the 
Calendar (ie: outside a vEvent) since 
>we do not have TRANSP: on calendars... 
>
>Then again, if TRANSP and CONFLICTS were exclusive of each other I could 
use TRANSP: TRANS and >
>CONFLICTS:FALSE to leave holes in my busytime and still block them from 
being booked by others.  A 
>novel ideal some folks would enjoy playing with Im sure. 
>
> Hmm, choices, choices... 

I didnt propose it actually, I was just thinking out loud to further 
progress the discussion.  The talk of a separate CS policy that enforces 
CONFLICTS happened later in that same thread.  Given that CAP is 
interested in having CONFLICTS:TRUE / FALSE as a policy, it makes more 
sense to NOT overload TRANSP and make a separate new property called 
CONFLICTS.  That way it can be both on the entry (ie: inside the vEvent) 
or on the calendar as CS policy.

It seems nonsensicial to have a CS policy of "TRANSP:OPAQUE-NOCONFLICT" 
since the policy is really "Do I allow CONFLICTs or not??"; it has 
_nothing_ to do with transparency or opaqueness of the calendar itself.

In addition, a side effect of a new property could be that it is defined 
to be CONFLICT: TRUE if it is not there.  This would allow a phasing in of 
CUAs that grok CONFLICT when parsing data they get over iTIP (NOT over CAP 
itself) while allowing CAP savy CUAs to do the right thing.  Changing 
TRANSP to new non-RFC 2445 values would mean that existing CUAs would not 
properly grok the TRANSPARENT/OPAQUEness of the entry as well as the 
NOCONFLICT intent.

Yes, there are some niggling 'what about...' cases that would need to be 
resolved by defining a new CONFLICTS property (ie: Dealing with 
preexisting CONFLICTS:FALSE entries that conflict) but they can be 
resolved by a clear, well thought thru proposal...

This is not waffling on my part; just mulling over the needs vs 
implications arguments again.  Someone nudge me back with a compelling 
argument why TRANSP must get toasted instead of making a new CONFLICTS 
property...

Hmm, originally I also talked about letting the Organzier 'request' the 
priority of the entry via TRANSP instead of CONFLICT but that the 
recipient did not have to obey it.  Does it make more sense for _that_ 
case to n-state TRANSP or can it be done via a combination of 
TRANSP/CONFLICT (ala the pseudo code above)??

Also looking back over the original thread, I do not see a clear concensus 
to some of the issues (esp. CS enforcment vs CUA enforcment in some 
cases).  Perhaps there has been some new cycles spent on this out of 
bounds to fix this...

Bruce
PS: In researching this thread I found that Doug was actually on the other 
side then (Dated 08/25/99 10:57:08 AM MST, same Subject thread in response to Andre):
> They both sound like the same amount of work to me, and having 
> CONFLICTS at the component level increases flexibility a _lot_,
> so we need it.

Me too.
===========================================================================
Bruce Kahn                                INet: [email-masked]
Iris Associates                          Phone: 978.392.5335
Westford, MA, USA 01886                    FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Tue, 22 Aug 2000 09:10:43 -0700

[email-masked] wrote:
>.

I have always agreed they needed to be separate.
I just bowed to what I thought would make it work and
keep both sides happy

> Also looking back over the original thread, I do not see a clear
> concensus to some of the issues (esp. CS enforcment vs CUA enforcment in
> some cases).  Perhaps there has been some new cycles spent on this out of
> bounds to fix this...

Group Do we do 2 separate properties?

-Doug

---

From: George Babics <[email-masked]>
Date: Mon, 28 Aug 2000 12:32:27 -0400

Doug Royer wrote:

[snip]
 
> Group Do we do 2 separate properties?

   At our last CAP editors meeting we agreed that we support
two separate properties. 

   However, should the property be at the attendee level?
This would be to allow an attendee to specify whether
someone can double book the attendee at the same time slot
the event occurs. It can look something like:

   ATTENDEE:CONFLICT=FALSE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal

   The default can be true (allow conflicts). The user may be able to
change his or her default, i.e., have a calendar wide CONFLICT property.

   Or perhaps it should go into VCARs, i.e., allow or disallow UPNs to double
book a user.

  Comments?

George

---

From: John Stracke <[email-masked]>
Date: Tue, 29 Aug 2000 10:06:33 -0400

>    ATTENDEE:CONFLICT=FALSE;PARTSTAT=ACCEPTED:cap://cal.foo.com/relcal

I would prefer not to see TRANSP bound to CAP; I think it will be useful even
for those who don't support CAP.

--
/================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.  |
|Chief Scientist |===============================================|
|eCal Corp.      |Don't anthropomorphize computers. We don't like|
[email-masked]|it.                                            |
\================================================================/