Subject: Re: CAP (booked) - latest interm draft

From: [email-masked]
Date: Wed, 9 Jan 2002 16:06:04 -0500

Doug wrote:
>> 1.3 Definitions
>>
>>   Booked
>>
>>     An entry in a calendar has one of two conceptual states.  It is
>>     scheduled or it is booked.  A scheduled entry has been st
>>     in the calendar store but has not been acted on by a calendar
>>     user (CU) or calendar user agent (CUA).  A scheduled entry
>>     contains a METHOD property set to an [iTIP] method.
>
>> ...  A booked entry is a component does not have a METHOD property.
>
>Should be:
>
>  A booked entry is a component with a METHOD set to to the METHOD
>  property value of 'CREATE'.

That does not jive w/Section 2.8 "Relationship of RFC 2446 (ITIP) to CAP"
either that expressly says:

   A scheduled component becomes a booked component when its METHOD
   property is removed. For example, a component whose METHOD is "REQUEST"
   is scheduled. The component becomes booked when the METHOD is set to
   "BOOKED".

It does not sound logical that the METHOD on a existing, booked entry would
be "CREATE" or "BOOKED".  It seems more logical that there is no METHOD on
it really.  Otherwise we run the risk of some future iCalendar extension
accidentally reusing a METHOD value that may incorrectly cause a CAP client
to treat the scheduled entry as booked when it is not.  That way ANY METHOD
value means its NOT booked and NO METHOD value means booked.  Simple and
wont potentially cause problems later w/misclassification.

In any case, there is a discrepancy between the defintion in 1.3 and the
text in 2.8 that needs to be resolved.

Bruce
===========================================================================
Bruce Kahn
INet: [email-masked]  (<=== NEW EMAIL ADDRESS IN EFFECT)
Messaging and Collaboration Development
and so on...

---

From: Doug Royer <[email-masked]>
Date: Thu, 10 Jan 2002 12:56:53 -0700

[email-masked] wrote:

I thought we had this conversation and agreed that other
than wanting to change it - there was no reason to change it
an we were going to keep it as 'CREATE' as specified before
the non-debate change?

And yes - if I missed that quote, it also needs to change
back.

> That does not jive w/Section 2.8 "Relationship of RFC 2446 (ITIP) to
> CAP" either that expressly says:
> 
>      property is removed. For example, a component whose METHOD is
>      "REQUEST" is scheduled. The component becomes booked when the
>      METHOD is set to "BOOKED".
> 
> It does not sound logical that the METHOD on a existing, booked entry
> would be "CREATE" or "BOOKED". It seems more logical that there is no
> METHOD on it really. Otherwise we run the risk of some future
> iCalendar extension accidentally reusing a METHOD value that may
> incorrectly cause a CAP client to treat the scheduled entry as booked
> when it is not. That way ANY METHOD value means its NOT booked and NO
> METHOD value means booked. Simple and wont potentially cause problems
> later w/misclassification.
> 
> In any case, there is a discrepancy between the defintion in 1.3 and
> the text in 2.8 that needs to be resolved.
> 
> Bruce