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

[Doug Royer <doug@xxxxxxxxxxxxxx>]

> 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: Frank_Dawson@xxxxxxxxx 
>    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

Reporting-MTA: dns; home.royer.com
Received-From-MTA: DNS; home.royer.com
Arrival-Date: Mon, 21 Aug 2000 19:28:34 -0700 (PDT)

Final-Recipient: RFC822; ietf-calendar@imc.or
Action: failed
Status: 5.1.2
Remote-MTA: DNS; imc.or
Last-Attempt-Date: Mon, 21 Aug 2000 19:28:35 -0700 (PDT)

--- Begin Message ---

• To: ietf-calendar@xxxxxx
• Subject: Re: Subject: Registration of text/calendar MIME property TRANSP
• From: Doug Royer <doug@xxxxxxxxxxxxxx>
• Date: Mon, 21 Aug 2000 19:28:32 -0700
• References: <>
• Reply-to: ietf-calendar@xxxxxx
• Sender: doug

> 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: Frank_Dawson@xxxxxxxxx 
>    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

--- End Message ---