Subject: [Fwd: Returned mail: Host unknown (Name server: imc.or: host not found)]

From: Doug Royer <[email-masked]>
Date: Mon, 21 Aug 2000 19:30:25 -0700

> Another thought...
> 
> I can understand the requirement to allow a CUA to interact with a CS to
> negotiate the desire to avoid overlapping events. Maybe this should be a
> modally set calendar property?

There was a large discussion on this WG list about
NOCONFLICT. The original proposal was that both the
Calendar and components needed a NOCONFLICT - I think
it was Bruce's idea, and Frank you used to think it
was a good idea :-)

>    Subject: Re: W-23 CAP Calendar property .. overlapped booking 
>    From: [email-masked] 
>    Date: Fri, 27 Aug 1999 19:05:35 GMT 
>
>> If the calendar property is set CONFLICTS:FALSE, then new or
>> updated events which conflict should generate an error. Previously
>> entered events which conflict should not cause an error unless/until
>> one of them is updated. Why would I have a conflict if I try to
>> update an event with CONFLICT:TRUE that was created prior to the
>> calendar property CONFLICTS:FALSE being set?
>
> BUT...I think that Bruce Kahn's comments about adding another enumeration
> to TRANSP for OPAQUE-NO-CONFLICTS sounds good too.
> 
> -- Frank

Subject: Re: Subject: Registration of text/calendar MIME property TRANSP
From: Doug Royer <[email-masked]>
To: [email-masked]
Date: Mon, 21 Aug 2000 19:28:32 -0700

> Another thought...
> 
> I can understand the requirement to allow a CUA to interact with a CS to
> negotiate the desire to avoid overlapping events. Maybe this should be a
> modally set calendar property?

There was a large discussion on this WG list about
NOCONFLICT. The original proposal was that both the
Calendar and components needed a NOCONFLICT - I think
it was Bruce's idea, and Frank you used to think it
was a good idea :-)

>    Subject: Re: W-23 CAP Calendar property .. overlapped booking 
>    From: [email-masked] 
>    Date: Fri, 27 Aug 1999 19:05:35 GMT 
>
>> If the calendar property is set CONFLICTS:FALSE, then new or
>> updated events which conflict should generate an error. Previously
>> entered events which conflict should not cause an error unless/until
>> one of them is updated. Why would I have a conflict if I try to
>> update an event with CONFLICT:TRUE that was created prior to the
>> calendar property CONFLICTS:FALSE being set?
>
> BUT...I think that Bruce Kahn's comments about adding another enumeration
> to TRANSP for OPAQUE-NO-CONFLICTS sounds good too.
> 
> -- Frank