Subject: [Ietf-calsify] rfc 2446 - Cancel and sequence number

From: Robert_Ransdell at notesdev.ibm.com (Robert Ransdell)
Date: Fri Mar 16 09:40:29 2007

This has been discussed before but worth bringing up again.

section 3.2.5 says that when you cancel a meeting you must bump the 
sequence number.   This works for a real cancel but when chair is just 
removing a single attendee.

When rfc 2446 was first being designed there was a method for removing a 
person and a different method for canceling the meeting.
When you remove a person you can not bump the sequence number, because 
doing so does not allow the chair to re-invite that person without 
rescheduling to all.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070316/1d179bcd/attachment.html

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Fri Mar 16 10:03:41 2007

Hi Robert,

> doing so does not allow the chair to re-invite that person without

I am not sure I understand why there is a problem with always bumping the 
sequence number for a CANCEL. The chair does not have to send out an update 
to everyone if they later decide to re-invite the cancelled attendee.

However, arguably the correct thing for the chair to do is:

1) Bump SEQUENCE
2) Send CANCEL to the attendee being removed
3) Send REQUEST to other attendees with the cancelled attendee no longer 
listed (this informs the other attendees that someone is no longer 
attending)

Then to re-invite:

1) Bump SEQUENCE
2) Send REQUEST to all attendees (including the re-invited one)

However, I suspect this all boils down to how you interpret the SEQUENCE 
behavior. I think that is one area where people have different views. For 
example, should the organizer always bump the sequence for every change to 
the event? Or should it only be bumped when it is something that will 
likely change other attendees participation status? In reality, who gets to 
decide the later? An attendee may choose to participate or not based on 
some criteria that the organizer may not be able to fathom.

As part of the iTIP revision process I want to pin down the semantics of 
SEQUENCE precisely. To that end I would like to ask existing implementer to 
describe their own interpretation.

-- 
Cyrus Daboo

---

From: Arnaud.Quillaud at Sun.COM (Arnaud Quillaud)
Date: Sat Mar 17 01:06:59 2007

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de 
> Cyrus Daboo
> Envoy? : vendredi 16 mars 2007 19:02
> ? : Robert Ransdell; [email-masked]
> Objet : Re: [Ietf-calsify] rfc 2446 - Cancel and sequence number
> 
> 
> Hi Robert,
> 
> > When rfc 2446 was first being designed there was a method 
> for removing 
> > a person and a different method for canceling the meeting. When you 
> > remove a person you can not bump the sequence number, 
> because doing so 
> > does not allow the chair to re-invite that person without 
> rescheduling 
> > to all.
> 
> describe their own interpretation

The rules for incrementing the SEQUENCE are still defined in the calsify draft at http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.8.7.4

Shouldn't those be removed from there (if it is not too late) ?

Arnaud Quillaud

PS: the current Sun Calendar Server is probably not a good example in terms of implementation as it bumps up the seq number for pretty much any change.

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

---

From: lear at cisco.com (Eliot Lear)
Date: Sat Mar 17 04:22:49 2007

Arnaud Quillaud wrote:
> Shouldn't those be removed from there (if it is not too late) 

This sounds right to me, and no it's not too late.  The one group of 
changes we said we would allow to RFC 2445bis would be those arising 
from changes to the other documents, and in particular iTIP.

> PS: the current Sun Calendar Server is probably not a good example in terms of implementation as it bumps up the seq number for pretty much any change.

Does it present a change to a user?  If so, that must be frustrating.

Eliot

---

From: Arnaud.Quillaud at Sun.COM (Arnaud Quillaud)
Date: Sat Mar 17 04:49:49 2007

> De : Eliot Lear [mailto:[email-masked]] 
> Envoy? : samedi 17 mars 2007 13:22
> ? : Arnaud Quillaud
> Cc : Cyrus Daboo; Robert Ransdell; [email-masked]
> Objet : Re: RE : [Ietf-calsify] rfc 2446 - Cancel and sequence number
> 
> 
> Arnaud Quillaud wrote:
> > The rules for incrementing the SEQUENCE are still defined in the 
> > calsify draft at 
> > 
> http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-06#section-3.
> > 8.7.4
> >
> > PS: the current Sun Calendar Server is probably not a good 
> example in 
> > terms of implementation as it bumps up the seq number for 
> pretty much any change.
> >   
> 

In most cases it does not.

Arnaud