Subject: New: 6.3 Scheduling Commands

From: Doug Royer <[email-masked]>
Date: Sun, 17 Feb 2002 17:43:16 -0700

6.3 Scheduling Commands

 Scheduling (or iTIP) objects are stored with the "create"
 command and manipulated and fetched just like any other
 iCalendar object.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 19 Feb 2002 11:07:26 -0500

>  command and manipulated and fetched just like any other

Here's some technical reasons for why it is not a good idea
to remove the <schedule> command.

    +--------------------+
    |        CAP         |
    +-------+------------+
    | iTIP  |            |
    +-------+            |
    |                    |
    |     iCalendar      |
    +--------------------+

As shown in the diagram above, CAP depends on both iTIP and
iCalendar.  On the other hand, iTIP does not depend on CAP.
Yes, I know, CAP defines new value types, properties and
components using iCalendar 2.0, but by itself this has no
consequence on iTIP [RFC 2446].

Since CAP is built on top of iTIP and not the other way
around, it is our responsability to make sure that CAP
will handle changes done to iTIP, whether it be the use
of new value types, properties and components, or simply
new values for existent properties (e.g., new values for
the METHOD property).

People working on the next version of iTIP should not have to
care on how CAP was defined (i.e., "can we add a METHOD:CREATE
in iTIP?  No, because METHOD:CREATE already means something in
CAP, and CS wouldn't be able to differentiate the CAP
METHOD:CREATE from the iTIP METHOD:CREATE).

Enforcing that all iTIP objects be submitted by a separate
command (i.e., <schedule>) is a simple and effective way
of making sure that CAP will handle future version of iTIP
as painlessly as possible.

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Tue, 19 Feb 2002 11:20:51 -0700

> ...

The protocol has NOTHING to do  with how you store objects.

> new values for existent properties (e.g., new values for

And did you have any example that shows we are breaking that?
I did on the list describe how it does not matter.

> METHOD:CREATE from the iTIP METHOD:CREATE).

Good - Why in the world would anyone invent an iTIP METHOD:CREATE
that was not the same as CAP MATHOD:CREATE? Lets stop that now.

> as painlessly as possible.

No, it is simply allowing iTIP METHOD:CREATE to mean something
different that CAP METHOD:CREATE - not something we should ever
want to happen.