Subject: Yokahama meeting

From: [email-masked]
Date: Wed, 22 May 2002 16:05:30 -0400

Based on the lack of responses to the list regarding Yokahama, Bob and I 
have decided to not hold a session for the CALSCH working group in 
Yokahama.  However, we can still continue to work on drafts on the list 
and can submit them - we just can not have any "in person" interim 
meetings.  So, keep those cards and letters coming.  bob and I are going 
to review the sparse activity to see if the ball is in our court to state 
items are "complete."  If anyone thinks a topic still needs discussion, 
please say so on the list.

thanks for your support.

---

From: Doug Royer <[email-masked]>
Date: Wed, 22 May 2002 15:52:03 -0600

[email-masked] wrote:
> 
>  If anyone thinks a topic still
> needs discussion, please say so on the list.

I have spent hours working on the draft cleaning up
the multiple identical statements and such. I am now
moving the property/component/value type definitions 
to the front of the spec - like iCalendar.

After the last post from Steve, I looked closer at the 
METHOD property in the objects and I still feel that 
we do not need to put METHOD in the objects. This
will keep METHOD 100% pure iTIP (yet we can still query
for objects by METHOD).

The only thing we really want to know is if the objects
are 'BOOKED', 'UNPROCESSED', or marked 'DELETED'. And
So I added (I can still remove it :-), STATE() to the query
language.

	SELECT * FROM VEVENT WHERE STATE() = 'BOOKED'

	SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED'

	SELECT * FROM VEVENT WHERE STATE() = 'DELETED'

The 'state' also does not need to be specified as belonging
to an object as it will NEVER go over the wire. As 100% of
all *iTIP* objects deposited are UNPROCESSED, 100% of all objects
modified to DELETE state (still working out the syntax for this).
are in the DELETED state. And 100% of all other objects are 
in effect BOOKED (including VCARs, {CS,VCALSTORE,VAGENDA} properties)

So you would CMD:CREATE any object.
  If it has a METHOD, then it MUST BE an iTIP object,
  so it is deposited and its 'state' is 'UNPROCESSED'.

  If it does not have a METHOD in it, then its state is BOOKED.

  And I am thing of adding a parameter to the DELETE command:

	CMD:DELETE		<- Remove the object from the store.

	CMD;opt=markfor:DELETE  <- Mark it as state DELETED.

I would think that a huge amount of the time using the STATE()
method would get you what you want (You can still also use date
constraints with it).

Also, If you query for METHOD = '<some iTIP method>', then
the CS MUST get you the objects that were deposited into
the CS with that method in their VCALENDAR object and CAP
only needs to specify that the CS MUST remember their METHOD
and not how the CS remembers.

This also slightly simplifies synchronization where pass one must be
get pending iTIP requests (UNPROCESSED).

Comments?

---

From: Gary Frederick <[email-masked]>
Date: Thu, 23 May 2002 06:15:57 -0500

Could you make a copy of the draft available Doug?

Gary

---

From: Doug Royer <[email-masked]>
Date: Thu, 23 May 2002 08:14:20 -0600

> Could you make a copy of the draft available Doug?

Yes, as soon as it is ready the other editors and I will
publish it.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 24 May 2002 15:03:17 -0400

Doug Royer wrote:
> to an object as it will NEVER go over the wire.

On the contrary, the state of a component should be sent on the
wire to the CUA, such that the CUA can easily find out the state
of components returned for an arbitrary search.  Otherwise, the
CUA will be forced to perform multiple search commands (i.e., one
for each state) when a single search could do.

What's wrong with Steve's proposition of specifying the state
explicitly in the component?

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

---

From: Bernard Desruisseaux <[email-masked]>
Date: Fri, 24 May 2002 15:03:18 -0400

>         CMD;opt=markfor:DELETE  <- Mark it as state DELETED.

We should be cautious about mixing the state of a component with
the fact that it has been mark for removal.  For instance, with
my email client, if I delete an "Unread" email message (i.e., add
the flag "Deleted" to it) and that I later undelete this message
(i.e., remove the flag "Deleted") the email message will still be
marked as "Unread".

The fact that a component has been mark for removal would be
better handled by a property which could easily be maintained
by CMD:MODIFY.  I don't see the need for a new command, nor an
option to an existing command.

I can think of many ways of implementing this in iCalendar.
Here's a few:

  1- Two properties:

       STATE:UNPROCESSED
       DELETED:TRUE

  2- One property with a parameter:

       STATE;DELETED=TRUE:UNPROCESSED

  3- One multi-value / multi-instance property:

       STATE:UNPROCESSED
       STATE:DELETED
     or
       STATE:UNPROCESSED,DELETED

Cheers,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Fri, 24 May 2002 13:46:37 -0600

> option to an existing command.

We have in the past decided that there would not be a way
to 'un-delete' so it is not the same comparison.

The only reason that the DELETE state exists is so that
the 2nd and up synchronization processes can tell if something
has already been done. Example the 1st synchronization tells
the CS that object A is marked for delete. The the 2nd and up
synchronization's will know to delete their copies of A.

Without a marked for delete, the 2nd and up synchronization will
'think' that their copies of A are new to the CS and re-create them
in the CS.

No new command has been proposed. CMD was the replacement
for the XML command headers.

There is NO property to use the MODIFY command with, we
removed the conception that METHOD was contained in the object.

> I can think of many ways of implementing this in iCalendar.

All three of your proposals define a new property - STATE.
There is no reason for a new property. A CUA marks an
object for delete, so that other CUAs (or the same one later)
will know a specific object has been considered.

And STATE() only has meaning with respect to one particular CS.
STATE() has NO meaning to any iTIP other object and STATE()
has no meaning between CUAs.

I have not proposed anything new. DELETE already existed
as did CMD (by chair proclamation that the XML command was out).
I did not add or modify the meaning of DELETE. Nor did I propose
any new properties. I simply am looking for a way for a CUA
to tell the CS; "delete this object, and remember you did so
that synchronization works later".

---

From: Bernard Desruisseaux <[email-masked]>
Date: Mon, 27 May 2002 10:53:31 -0400

> to 'un-delete' so it is not the same comparison.

The CAP Requirements document only deferred how to undelete
a calendar (Section 4.3.1).

> removed the conception that METHOD was contained in the object.

You did propose "to remove the conception that METHOD was
contained in the object."  But that has not been agreed on
the list yet.

> any new properties.

I don't understand why you think I'm against proposing
something new.  Adding an option to an existing command
is something new.  We need to propose something new.
Otherwise we wouldn't be having this debate about how
to solve the issue at hand.

> I simply am looking for a way for a CUA

I'm looking for the same thing.  Except that I don't want to force
CUA to perform multiple search commands when a single one could do.

With your proposal CUA will have to perform a search command to
get the 'BOOKED' components, another search command to get the
'UNPROCESSED' components and yet another one for the 'DELETED'
components.

By returning a property in iCalendar object to specify whether
they are DELETED or not CUA will be able to perform a single (1)
search command instead of three (3).

No need for a new option to an existing command, nor any new
function to the query language.  All that is required to solve
the issue is one new property that can be modified with CMD:MODIFY
and queried with CMD:SEARCH.

Cheers,
Bernard