Subject: Fw: Correct handling of Recurrence-id

From: [email-masked]
Date: Wed, 11 Jun 2003 10:57:47 -0400

This never showed up in list so sending again.
_____________________
Note: new email address

[email-masked]
----- Forwarded by Robert Ransdell/Westford/IBM on 06/11/2003 10:54 AM 
-----

Robert Ransdell/Westford/IBM
06/04/2003 10:47 AM

To
[email-masked]
cc

Subject
Re: Fw: Correct handling of Recurrence-id

iTip section 3.2.5 CANCEL
"When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be 
incremented." IS A BUG.

There use to TWO methods CANCEL and REMOVE. The CANCEL meaning all 
attendees bumped the sequence.  The remove did not.  These to methods were 
combined into CANCEL.  The combined CANCEL method can not bump the 
sequence number.

 If I invite 5 people to a meeting ( John, Bob, Sally, Jane, George) with 
sequence 0.  I than decide I do not need Sally to come so I send a Cancel 
just to Sally with Sally as the Attendee line.   I can not bump sequence 
on the Cancel.  If I do,  I have just invalidated the responses from John, 
Bob, Jane and George.

_____________________
Note: new email address

[email-masked]

Doug Royer <[email-masked]> 
Sent by: [email-masked]
05/30/2003 04:53 PM
Please respond to
[email-masked]

To
"[email-masked]" <[email-masked]>
cc

Subject
Re: Fw: Correct handling of Recurrence-id

[email-masked] wrote:
> 
> The RNext notes uses iCalendar model  were RECURRENCE-ID's never change. 

>  This will not change unless there is a  VERY good argument to do so.

So if SEQUENCE:1 changes 100% of all instances.
Then SEQUENCE:2 trying to cancel one of the new (SEQUENCE:1 instances.

You can't becaues you would have no idea what was being canceled
if the RECURRENCE-ID refer to the SEQUENCE:0 instances.

-- 

  Doug Royer                     |   http://INET-Consulting.com
  -------------------------------|-----------------------------
  [email-masked]                 | Office: (208)612-INET
  http://Royer.com/People/Doug   |    Fax: (866)594-8574
                                 |   Cell: (208)520-4044

                 We Do Standards - You Need Standards

---

From: Doug Royer <[email-masked]>
Date: Wed, 11 Jun 2003 14:05:09 -0600

[email-masked] wrote:

> attendees bumped the sequence.  The remove did not.  These to methods 
> were combined into CANCEL.  The combined CANCEL method can not bump the 
> sequence number.
> 
>  If I invite 5 people to a meeting ( John, Bob, Sally, Jane, George) 
> with sequence 0.  I than decide I do not need Sally to come so I send a 
> Cancel just to Sally with Sally as the Attendee line.   I can not bump 
> sequence on the Cancel.  If I do,  I have just invalidated the responses 
> from John, Bob, Jane and George.

When you say "I can not bump sequence on the Cancel", you really mean
'You do not want to bump the sequence on the cancel'.

If you send a CANCEL to a select set of ATTENDEEs then their
CUA may say 'what is this' (say their CUA crashed), so they
then send a REFRESH for UID XX. What do you send them? The old object
that is canceled? A copy of the CANCEL - for which they will then
send you a REFRESH again because they do not have a copy. That is
why the SEQUENCE MUST be bumped. Else you have to keep a copy or
be able to re-construct and remember they ATTENDEEs a,b, and c only
get a CANCEL when talking about UID 123,2188,1083,...

If however you BUMP the SEQUENCE each time, then you do not
have to remember anything. The latest copy is always the
correct copy.

If you CANCEL the VEVENT, you MUST bump the SEQUENCE so that
it then becomes the latest copy of the object and everyone
knows if they do a REFRESH, that they get the CANCEL and not
the old object.

The argument that you have to re-send REQUESTs to everyone
has been debated on this list and the answer is YES.

Option 1: There is no requirement that each ATTENDEE see the
entire ATTENDEE list. That is each ATTENDEE can be sent
a unique copy of the VEVENT, with only their ATTENDEE
in the object. With this model you may then send that
one ATTENDEE a CANCEL, there is NO problem with bumping
the SEQUENCE number as the copy is unique to ATTENDEE.
So it is not a BUG.

Option 2: All or some (2 or more) of the ATTENDEEs may get objects
that contain all or some (1 or more) of the other ATTENDEEs.
In this case you MUST send each ATTENDEE in that list a new
CANCEL object with a bumped SEQUENCE so they are all in sync.
So not a bug.

This was discussed on this CALSCH WG list and both iCal and iTIP
were planned and released so that both models would work.
The SEQUENCE number MUST BE bumped with a CANCEL.

--

---

From: [email-masked]
Date: Thu, 12 Jun 2003 12:04:29 -0400

That's bogus.

NO NO NO.
If I bump the sequence number for a givent RECUR-ID or a non repeating 
meeting. Than all responses prior to this SEQUENCE are invalid.  The 
attendees must send a new accept/decline.  However when you send a CANCEL 
to an individual, the other attendees are not sent any a reschedule.  Thus 
they do not repsond.

Refer to my original example.  When I send a CANCEL to a select subset of 
the invitees, I am REMOVING them as attendees.  I send the UNID and in the 
case of a repeating meeting the RECUR-ID (The initial date of this 
individual repeat item) and the current sequence number.

The way the CANCEL is suppose to work is that if the SEQUENCE number of 
the CANCEL is greater than the invitees current sequence number than the 
item is canceled.  The invitee removes it from his/her calendar.
If the sequence number of the CANCEL is equal to the invitees current 
sequence number and the DTSTAMP is also greaterthan the item is canceled. 
The invitee removes it from his/her calendar.

If the sequence number is less than the invitee would either ignore it as 
stale data or send back a Refresh request with the UNID and the RECUR-ID 
(initial date of this individual repeat item).  The only way that a CANCEL 
would have a sequence number less that the sequence of the invitee, is 
when the invitee had been removed and than re-invited.  The chair would 
send back the current data which would be the re-invite.

_____________________
Note: new email address

Doug Royer <[email-masked]> 
Sent by: [email-masked]
06/11/2003 04:05 PM
Please respond to
[email-masked]

To

Subject

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 12 Jun 2003 11:24:05 -0600

[email-masked] wrote:
> meeting. Than all responses prior to this SEQUENCE are invalid.

YES - and they MUST re-reply. That is what this WG had decided
in the iTIP debates. It is NOT optional.

Make you CUA smart and notice that nothing changed that the
user cared about and auto-reply.

>  The 
> attendees must send a new accept/decline.  However when you send a 
> CANCEL to an individual, the other attendees are not sent any a 
> reschedule.  Thus they do not repsond.

Not always true, in some cases *ALL* ATTENDEEs see object with
*ALL* other ATTENDEEs. So you model will break in that case
as their copy of the object IS obsolete.

> Refer to my original example.  When I send a CANCEL to a select subset 
> of the invitees, I am REMOVING them as attendees.  I send the UNID and 
> in the case of a repeating meeting the RECUR-ID (The initial date of 
> this individual repeat item) and the current sequence number.

That is not per-spec.

> item is canceled.  The invitee removes it from his/her calendar.

Yes.

> sequence number and the DTSTAMP is also greaterthan the item is 
> canceled.  The invitee removes it from his/her calendar.

No that is not what iTIP says (minus its typo):

4.2.10 Removing Attendees

      ...

    The original meeting includes "A", "B", "C", and "D". The example
    below shows the "CANCEL" that "A" sends to "B". Note that in the
    example below the "STATUS" property is omitted. This is used when the
    meeting itself is cancelled and not when the intent is to remove an
    "Attendee" from the Event.

Except it has a typo, it should read:

    ...This is used when the
    meeting itself is not cancelled and when the intent is to remove an
    "Attendee" from the Event.

So your original post did not CANCEL the event, it simply
removed an ATTENDEE.

To CANCEL the entire EVENT, bump the SEQUENCE.

--

---

From: [email-masked]
Date: Thu, 12 Jun 2003 13:45:44 -0400

There is no mention in the iTip of sending the cancel request of 1 invitee 
to the entire set of attendees.
_____________________
Note: new email address

06/12/2003 01:24 PM
Please respond to
[email-masked]

To

Subject
Re: CANCEL and SEQUENCE usage

That is not per-spec.

Yes.

      ...

    ...This is used when the

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 12 Jun 2003 12:55:43 -0600

[email-masked] wrote:
> 
> There is no mention in the iTip of sending the cancel request of 1 
> invitee to the entire set of attendees.

I did not mean to say that, I meant:

     ATTENDEE        0+     MUST include all "Attendees" being removed
                            the event. MUST include all "Attendees" if
                            the entire event is cancelled.

So there is a way to remove one or more ATTENDEEs (a CANCEL for just
those ATTENDEEs).

There is a way to CANCEL one or more instances, or the entire object
for all ATTENDEEs.

And you are allowed to send the entire object to each individual
attendees, or to all ATTENDEEs.

Bumping SEQUENCE is valid during CANCEL and was what was agreed
be the protocol.

--

---

From: [email-masked]
Date: Thu, 12 Jun 2003 15:17:03 -0400

You are STILL missing the point.
As the Chair I have a current sequence number.  All the accepts/declines 
are based on that sequence number.  If I have an accept but it is from a 
previous sequence number than the state of that attendee is WAITING FOR 
RESPONSE.
Now I (under your rules ) bump the sequence number and send a Cancel to 
invitee A.  No other invitees are sent any kind of message.
Now Notes sequence number is 1 lager than all existing accepts/declines.
Thus all invitees are now in  WAITING FOR RESPONSE state.
_____________________
Note: new email address

06/12/2003 02:55 PM

To
[email-masked]
cc

Subject

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 12 Jun 2003 14:43:04 -0600

> previous sequence number than the state of that attendee is WAITING FOR 

You are waiting them to REPLY/SEQENCE:<new> - YES.

> Thus all invitees are now in  WAITING FOR RESPONSE state.

The ORGANIZER-CUA does not need to send a REQUEST for every
change. It has to bump the SEQUENCE number for CANCEL.

However you could optimize your code knowing that the ONLY thing
that you did was remove ATTENDEEs, and bump the SEQUENCE in the
ORGANIZER copy as specified, not send a new REQUEST, update the status
as if the ATTENDEE's already replied as before. If/When that object
changes in a way that otherwise updates the SEQUENCE and modifies
data in the object that the application deems needed, then
send them REQUEST/SEQUENCE:<say what they have + 2> and they
would never care, they would just REPLY never needing to know
or caring why they missed SEQUENCE<what they have + 1>.
As the specs mandate that higher  SEQUENCESs obsolete
lower SEQUENCE numbers for the same UID they would
have to throw away the old data anyway.

The SEQUENCE is updated under specific rules by '1'.
However the ORGANIZER-CUA does not need to send them
unless needed. The ATTENDEE-CUA already has to be coded
to process objects out of order and with missing SEQUENCES.
And as iTIP (or iCAL?) specifies that a newer SEQUENCE
obsoletes all older with the same UID, then the ATTENDEE-CUA
would have no problem processing SEQUENCE:<what they have + one-or-more>

-AND-

You *could* in your CUA notice if you happened to get one that
looks like SEQUENCE:<more-than-yours> and the only difference is missing
ATTENDEEs, have your CUA auto-REPLY without ATTENDEE-CU intervention.

One of the reasons for this being mandated is to allow for flexible
scheduling needs based on the application. In some usages  - The ATTENDEE
may really need the other ATTENDEE lists, in many (most?) an ATTENDEE
may never care. By forcing the above iTIP/iCAL model - both needs can
be satisfied.

--

---

From: [email-masked]
Date: Thu, 12 Jun 2003 18:14:48 -0400

So you are creating either thrashing or causing complexity in Chair side 
coding to handle something that is not a problem if you do not bump the 
sequence number on a CANCEL.
_____________________
Note: new email address

06/12/2003 04:43 PM

To

Subject

-AND-

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 12 Jun 2003 17:02:39 -0600

> sequence number on a CANCEL.

I am not adding any complexity, you are trying to ignore the fact
that it IS in the spec.

---

From: [email-masked]
Date: Thu, 12 Jun 2003 19:29:31 -0400

Its a BUG  created when they merged the Remove and Cancel METHODS
_____________________
Note: new email address

06/12/2003 07:02 PM

To

Subject

---

From: Doug Royer <[email-masked]>
Date: Thu, 12 Jun 2003 17:54:10 -0600

> Its a BUG  created when they merged the Remove and Cancel METHODS

Looking through the archive I can only find a 'CAP' REMOVE METHOD
that was taken out of CAP, not an iTIP or iCAL properly.
Not the same thing.

And even if I missed it, that is how the WG bought off iTIP.
And that method does work.

--

---

From: [email-masked]
Date: Fri, 13 Jun 2003 12:56:20 -0400

Lets assume your method of bumping the sequence on CANCEL sending to just 
the intended invitees and internally bumping all accepts/decline notices.
What about the ones you have not received yet.
If you had a large meeting and several people were removed over time the 
sequence would be bumped several times.
Now one of the invitees gets back from vacation and accepts the meeting. 
You now receive and accept with sequence vastly different than your 
current.

The only way to compensate for this is for chair now to keep track of 
current sequence and effective sequence not counting bumps from cancels.

THAT'S STUPID since there IS NO PROBLEM IF YOU DON'T BUMP SEQUENCE ON 
CANCEL
_____________________
Note: new email address

06/12/2003 07:54 PM

To

Subject

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 13 Jun 2003 11:39:48 -0600

[email-masked] wrote:
> 
> Lets assume your method of bumping the sequence on CANCEL sending to 
> just the intended invitees and internally bumping all accepts/decline 
> notices.

> What about the ones you have not received yet.

Do them smartly.

>  You now receive and accept with sequence vastly different than your 

Do them smartly.

> current sequence and effective sequence not counting bumps from cancels.

No - Do them smartly.

> THAT'S STUPID since there IS NO PROBLEM IF YOU DON'T BUMP SEQUENCE ON 

You can debate how you want it to go in the future. However no
matter how stupid you think it is, that is the way it is. And it works.

--

---

From: [email-masked]
Date: Fri, 13 Jun 2003 14:00:24 -0400

!!!!!!!IT DOES NOT WORK!!!!!!!!!   --- THIS HAS BEEN POINTED OUT SEVERAL 
TIMES IN THE PAST IN 1999 FORWARD.
_____________________
Note: new email address

06/13/2003 01:39 PM

To

Subject

Do them smartly.

Do them smartly.

No - Do them smartly.

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 13 Jun 2003 13:02:52 -0600

> TIMES IN THE PAST IN 1999 FORWARD.

It works just fine in my implementation.
It works just fine interoperating with other vendors.

If you mean that you do not want to send out new REQUESTS, okay.
Or if you mean you do not like to keep track of things rather
then send the new REQUESTS, okay.

But it works just fine and it is how it is documented.

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 13 Jun 2003 13:13:38 -0600

> TIMES IN THE PAST IN 1999 FORWARD.

In addition, there is NO case where bumping the sequence
number and sending or re-sending an object breaks iTIP.

--

---

From: [email-masked]
Date: Fri, 13 Jun 2003 16:07:29 -0400

In all cases where the sequence is bumped, ALL invitees must be notified 
of a RESCHEDULE.  They must re-accept/decline.  All existing responses 
become invalid.   Overhead is way too high for sending an un-invite to one 
person.
_____________________
Note: new email address

06/13/2003 03:13 PM

To

Subject

--

---

From: Doug Royer <[email-masked]>
Date: Fri, 13 Jun 2003 15:00:58 -0600

[email-masked] wrote:
> become invalid.   Overhead is way too high for sending an un-invite to 
> one person.

We finally agree - it works, you simply don't like it.

--

---

From: [email-masked]
Date: Mon, 16 Jun 2003 11:22:38 -0400

NO.   It does not work.   I tried Outlook, that wrote exactly to the spec. 
 They are FUBAR'd and you can not re-invite someone that you have removed.

NOTES does not currently;   Nor will it ever code to this BUG in the spec 
and bump the sequence on a CANCEL and thus break workflow.
_____________________
Note: new email address

06/13/2003 05:00 PM

To

Subject

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 16 Jun 2003 09:56:47 -0600

[email-masked] wrote:
> 
> NO.   It does not work.   I tried Outlook, that wrote exactly to the 
> spec.  They are FUBAR'd and you can not re-invite someone that you have 
> removed.

I am not sure what you are saying is invalid. Are you saying
that if you bump the SEQUENCE and re-issues REQUESTS, the Outlook
clients says NO? My tests show that it works. So I do not understand
what you are saying fails.

> NOTES does not currently;   Nor will it ever code to this BUG in the 
> spec and bump the sequence on a CANCEL and thus break workflow.

So you are saying that if I ever bump the SEQUENCE number for other
reasons that NOTES can never do a CANCEL? Or are you saying that
if you ever CANCEL someone that you can never bump the SEQUENCE?
Or are you saying that if you need to CANCEL and do something
else that you feel needs to bump the sequence, that NOTES
can not handle that? Or are you saying that you are going
to make sure that NOTES  is not conferment with iCal/iTIP?

--

---

From: [email-masked]
Date: Mon, 16 Jun 2003 14:07:35 -0400

No I'm saying as Chair I will not bump the sequence number on a cancel 
(uninvite to an individual); just like I would not bump the sequence 
number if I was inviting an additional invitee.  The only time I bump the 
sequence number is on a reschedule. This makes the invite of an additional 
invitee consistent.  I can re-invite the person who I accidentally 
uninvited without issuing a Reschedule to all the attendees forcing them 
to re-accept/decline.

_____________________
Note: new email address

06/16/2003 11:56 AM

To

Subject

--