Subject: MODIFY restriction table...

From: Doug Royer <[email-masked]>
Date: Wed, 14 Nov 2001 16:54:28 -0700

(I included some cut-paste text from CAP) I think they MUST BE
changed per my comments.

This would be removed.

          . . . METHOD           1         <<placeholder. it may move
                                                to meta-info>>

These would be '0 or 1' or '0+', if they are not being changed
with the MODIFY method - they MUST NOT be included (EXCEPT
UID which CAN NOT BE CHANGED and ALARMID - which CAN NOT BE CHANGED).

            . . . OWNER            1+
             . . . RELCALID         1
            . . . QUERYNAME        1
             . . . QUERY            1
             . . . SUMMARY          1        Can be null
            . . . DTSTAMP          1
             . . . DTSTART          1

             . . . ORGANIZER        1
           . . . . ACTION         1
 
             . . . . TRIGGER        1
            . . . METHOD           1        <<placeholder. it may move
                                             to meta-info>>
             . . . ORGANIZER        1
             . . . PRIORITY         1
            . . . . . TZOFFSET     1
             . . . . . TZOFFSETFROM 1
             . . . . . TZOFFSETTO   1
        . . . TZID             1

These MUST BE '1' and CAN NOT BE CHANGED by the MODIFY command.

          . . . UID             1

If ANY VALARM is being modified - MUST BE '1' and CAN NOT BE
CHANGED by the MODIFY command.

          . . . . ALARMID        0 or 1   MUST be 1 if multiple
                                             VALARMs are present in same
                                             component.

---

From: Doug Royer <[email-masked]>
Date: Thu, 15 Nov 2001 14:25:46 -0700

An error in my post...

>           . . . METHOD           1         <<placeholder. it may move

This CAN NOT be removed (I forgot).

In CAP, there is a METHOD per stored component, where:

	CREATED 	= booked
	<iTIP methods>	= iTIP status
	DELETE		= Marked as deleted 

(1) So, MODIFY MAY have a METHOD ('0 or 1') per component. And the
    The value can be <any iTIP METHOD>, CREATE, or DELETE

(2) And CREATE MUST have a METHOD ('1') per component.
    The value can be <any iTIP METHOD> or CREATE.

(3) And DELETE MAY have a METHOD ('0 or 1') but it would be useless.

-Doug

---

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 21 Nov 2001 15:14:41 -0500

>         DELETE          = Marked as deleted

I'm not sure how you could marked components as deleted,
given that after METHOD:DELETE components no longer exist.

> (3) And DELETE MAY have a METHOD ('0 or 1') but it would be useless.

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: Wed, 21 Nov 2001 14:39:22 -0700

> given that after METHOD:DELETE components no longer exist.

Not true - exactly.
With iTIP there is no DELETE - only CANCEL. So the argument was
that CAP needed to be able to mark things as DELETE, so the CUA + CU
could later determine if it was to be removed from the CS.

The 'command' METHOD:MODIFY could mark a component as 'METHOD:DELETE'.
Don't confuse that with a 'command' METHOD:DELETE that removes
the named targets.

Why you need to mark *components* METHOD:DELETE:

	With iMIP/iTIP, you can get data out of order. So, if the
	ORGANIZER sends a METHOD:REQUEST SEQUENCE:0, then later a 
	METHOD:REQUEST SEQUENCE:1 then later a METHOD:CANCEL SEQUENCE:1 .

	But in iMIP you get METHOD:REQUEST SEQUENCE:0 then you get 
	METHOD:CANCEL, and later you get the METHOD:REQUEST SEQUENCE:1.

If you do not METHOD:MODIFY the METHOD:CREATE SEQUENCE:0 component
as METHOD:DELETE (instead you deleted the component), then when you
get the out of order METHOD:REQUEST SEQUENCE:1, you would create
a new entry in you CS --- ERROR!

I might not have the argument exactly right, but there are times
when you can get the iTIP data out of order and you could create
zombie events in your calendar.

If however you marked the component as METHOD:DELETE and you saved
the METHOD:CANCEL (for how long?), then when you later got the
old METHOD:REQUEST, your CS/CUA would know that it was received
out of order and clean up the mess.

OR the CUA could send a METHOD:REFRESH SEQUENCE:1 when it got the
CANCEL with the newer SEQUENCE number. But still you have to
mark the data in the CS somehow while you wait for the reply - the
talk was to mark such components as marked for delete - they contain
METHOD:DELETE. When the CUA got the 'no such UID (or whatever)' 
error from the ORGANIZER, then it could remove the component.

For single instances this looks easy. When a specific instance
is CANCEL'ed - then you have to keep things some how until 
the CUA can determine what happened.