Subject: [Ietf-calsify] iTIP: persisting SEQUENCE number

From: cyrus at daboo.name (Cyrus Daboo)
Date: Mon Oct 1 14:21:29 2007

Hi folks,
In trying to come up with some clarifying text for the SEQUENCE property I 
ran into the following situation:

1) Create a recurring meeting, Monday-Friday for five instances only.
2) Invite an attendee: this will send a REQUEST with SEQUENCE:0.
3) Override the Wednesday meeting by moving forward an hour. This will send 
a REQUEST for that instance only with SEQUENCE:1.
4) Delete the Thursday instance. This will send a CANCEL for that instance 
only.

Question: what should the SEQUENCE number be for the CANCEL?

There are two possibilities depending on how you read things:

1) SEQUENCE:1 - this is one more than SEQUENCE:0 which was the last 
sequence number used for the instance being cancelled.
2) SEQUENCE:2 - this is one more than the largest SEQUENCE sent in prior 
messages.

The problem with this ambiguity is that two clients could interpret this 
differently, so that one sends out SEQUENCE:1 as per the first 
interpretation, but the second is expecting SEQUENCE:2 as per the second 
interpretation, so it discards the message as being out of date.

My feeling is that when the ORGANIZER has to increment the SEQUENCE number 
they MUST use a value that is higher than the largest SEQUENCE previously 
sent for the entire recurrence set.

Does that make sense? If not, why not?

-- 
Cyrus Daboo

---

From: Robert_Ransdell at notesdev.ibm.com (Robert Ransdell)
Date: Mon Oct 1 14:50:21 2007

Skipped content of type multipart/alternative

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Mon Oct 1 20:43:01 2007

Hi Robert,

--On October 1, 2007 5:49:11 PM -0400 Robert Ransdell 
<[email-masked]> wrote:

> This has been a discussion in the past.

OK, I have reviewed the discussion on this. Some comments (taking your 
comments out of order):

> Previous recommendation was to not bump sequence number on CANCEL.

I disagree this was the recommendation. In fact 2446 is very explicit in 
section 2.1.4 that SEQUENCE must be bumped on CANCEL (or ADD). The previous 
debates subsequent to publication of 2446 reached no consensus on whether 
this was a bug or not.

My take on this is the following: it is vitally import that a cancel be 
correctly processed if messages are received out of order. Thus bumping the 
SEQUENCE number on CANCEL makes sense to avoid losing the cancel action if 
received out of order. I don't believe that relying on DTSTAMP to 
differentiate out of order messages in this situation is a good idea.

> The iTip says you have to bump
> by 2.  However that leads to a problem.  The CANCEL function and the
> remove attendee function where combined.  The problem arises if you need
> to re-invite someone you have removed.   If the chair bumped the sequence
> number on the chair side to match the sequence sent to the removed
> invitee, they would have to send out new invitees to all attendees. Bad
> idea.  However if the chair only bumps the sequence number on the
> iCalendar CANCEL sent to the removed attendee, then they now have a
> problem if there was a mistake and they have to re-invite them.

I disagree that there is any problem in this.

Again, my feeling on this is as follows: iTIP makes it clear that the 
ORGANIZER'S CUA has to persist on a per-ATTENDEE basis, the 
SEQUENCE/DTSTAMP values (section 2.1.5). What is important is that the CUA 
track what the next expected SEQUENCE/DTSTAMP reply for any one attendee is 
going to be.

So, if the organizer sends out SEQUENCE:0 to two attendees A & B, then 
sends a CANCEL for one instance to B and bumps SEQUENCE to 1, then if A 
replies to that instance only with SEQUENCE:0 the organizer knows that that 
is a valid reply even though the SEQUENCE on the instance is 1. The 
"expected" sequence for the attendee A is still 0.

Re-invite is not a problem. Send a REQUEST to B with SEQUENCE:2. Again this 
does not affect A in anyway as A's state is being persisted.

Next: lets say you need to change the time of that instance, so a request 
goes out with SEQUENCE:3. Now the organizer will be expecting a SEQUENCE:3 
reply from both A & B.

So I think provided CUAs persist SEQUENCE/DTSTAMP for the next expected 
reply on a per-attendee basis this all works and does not require excessive 
message updates to be sent etc.

Does that make sense? Did I miss something in my analysis?

-- 
Cyrus Daboo

---

From: Arnaud.Quillaud at Sun.COM (Arnaud Quillaud)
Date: Tue Oct 2 07:02:07 2007

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de 
> Cyrus Daboo
> Envoy? : mardi 2 octobre 2007 05:42
> ? : Robert Ransdell
> Cc : Calsify; [email-masked]
> Objet : Re: [Ietf-calsify] iTIP: persisting SEQUENCE number
> 
> 
> Hi Robert,
> 
> > invitee, they would have to send out new invitees to all attendees. 
> > Bad idea.  However if the chair only bumps the sequence 
> number on the 

In the case of a CalDAV based CUA, how is the client supposed to persist this per ATTENDEE SEQUENCE information on the server (e.g. in the case where the organizer is using 2 cal clients) ? 
If CalDAV scheduling is used, the CUA may try to guess the right SEQUENCE by looking at the outbox history but that is not guaranteed to work as servers are not required to keep the outbox history.

Arnaud Q

> _______________________________________________
> Ietf-calsify mailing list
> [email-masked] 
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Wed Oct 3 10:45:36 2007

Hi Arnaud,

Arnaud Quillaud wrote:
> Cyrus Daboo wrote:
> In the case of a CalDAV based CUA, how is the client supposed to persist
> this per ATTENDEE SEQUENCE information on the server (e.g. in the case
> where the organizer is using 2 cal clients) ? If CalDAV scheduling is
> used, the CUA may try to guess the right SEQUENCE by looking at the
> outbox history but that is not guaranteed to work as servers are not
> required to keep the outbox history.

Currently, the CalDAV calendar-schedule draft only defines two new
iCalendar parameters RECEIVED-SEQUENCE and RECEIVED-DTSTAMP to
"persist" the value of the SEQUENCE and DTSTAMP properties that was
specified in the most recent reply received from a given Attendee.
Example:

   ATTENDEE;CN="Cyrus Daboo";PARTSTAT=ACCEPTED;RECEIVED-SEQUENCE=2;
    RECEIVED-DTSTAMP=20070214T123456Z:mailto:[email-masked]

The purpose of these parameters is only to allow the handling of
scheduling messages that arrive in an unexpected order (i.e., not
at all what you are asking for)

We are still debating whether there is a need for the Organizer to
"persist" on a per Attendee basis the last SEQUENCE number sent to
the Attendee.

I believe we need to answer the following questions:

1- Is there a use case where the Organizer bumps the SEQUENCE
    number but doesn't send an update to any Attendee?

2- Is there a use case where the Organizer bumps the SEQUENCE
    number and only sends an update to some Attendees?

    [ The case of an Organizer adding new Attendees and only
      sending an update to those new Attendees would be an
      example *if* the Organizer (his CUA really) also bump
      the SEQUENCE number.  According to iCalendar (though
      it should be "according to iTIP") the Organizer is not
      required to bump the SEQUENCE number here. If the
      SEQUENCE number is bumped, I would say that all the
      Attendees should receive an update... ]

3- Is there a use case where the Organizer would consider
    an Attendee reply that specifies a SEQUENCE number less
    than the current SEQUENCE number?

Cheers,
Bernard