Subject: Section 4.8.7.4 Sequence Number [Re: [Ietf-calsify] Re: Ietf-calsify Digest, Vol 38, Issue 10]

From: Bernard Desruisseaux <[email-masked]>
Date: Wed, 14 Nov 2007 00:04:38 -0500

Do we want to remove the text in section 4.8.7.4 Sequence Number of
RFC 2445 that specifies when the sequence number MUST be incremented
as Cyrus was "tempted to suggest"?

Cheers,
Bernard

Cyrus Daboo wrote:
> Hi Ciny,
> 
> --On September 28, 2007 11:46:53 AM -0700 Ciny Joy <[email-masked]> 
> wrote:
> 
>>     So was their a conclusion on the SEQUENCE, DTSTAMP discussion? I am
>> especially interested in knowing which fields should be used to determine
>> the latest update received in iMIP. Also, is there a proposal to
>> standardize when these fields should be modified?
> 
> I am crafting a response to all the discussion that took place on this 
> recently.
> 
> My conclusions are the following:
> 
> 1) We do need SEQUENCE to properly allow an organizer to match up 
> responses from attendees with the latest revisions sent out by the 
> organizer.
> 
> 2) Clarify that SEQUENCE is not meant to be any kind of indicator to the 
> client that a response is needed. RSVP=TRUE must be used instead.
> 
> 3) Clarify that clients must determine for themselves what constitutes a 
> significant change to an event that would cause a new accept/decline 
> prompt to be presented to a user. Clients may treat a change in SEQUENCE 
> number as always causing a prompt, but should not rely solely on a 
> change of SEQUENCE number.
> 
> 4) Clarify under what circumstances SEQUENCE should change. There is 
> currently some text on that in 2445bis, but I am tempted to suggest that 
> really belongs in 2446bis in a single section dealing with SEQUENCE 
> issues. The text here would list some properties for which changes MUST 
> result in a sequence change, and others that MAY result in a change 
> depending on the exact nature of the property change. I don't think we 
> can go further than that.
> 
> I am working on putting together some text on this so that we can seek 
> consensus on these points.
> 

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