303663 - should ICS calendar always bumps DTSTAMP on all events when writing?

Status: RESOLVED FIXED

(Calendar :: Internal Components, defect)

Description

[Dan Mosedale (:dmosedale, :dmose)]

When updating a WebDAV calendar by deleting an event, the DTSTAMP and
LAST-MODIFIED properties on every event in the file get set to the time that the
file was written.

Comment 1

[Dan Mosedale (:dmosedale, :dmose)]

My reading of RFC 2445 section 4.8.7.2 would seem to suggest DTSTAMP _should_ in
fact be bumped every time the ICS file is reserialized.  This seems kinda gross,
and 0.2 certainly didn't behave that way.  Any opinions on what we should do here?

Comment 2

[gekacheka]

(In reply to comment #1)
> My reading of RFC 2445 section 4.8.7.2 would seem to suggest DTSTAMP
> _should_ in fact be bumped every time the ICS file is reserialized.
> This seems kinda gross, and 0.2 certainly didn't behave that way.
> Any opinions on what we should do here?

I agree with your reading.  It sounds like DTSTAMP should be based on
the current time when the data is serialized, but each event's
LAST-MODIFIED field should change only if the event's data was
modified (added/changed/removed property).

I don't see any harm in following this, and it would be redundant for
them to always be the same.  For exporting, publishing, or attaching
ics file text, it sounds to me like the DTSTAMP is probably not important.

(DTSTAMP might be separate from LAST-MODIFIED so DTSTAMP serves as
 the Date: field for iTIP messages.  In that case, it serves as a way
 of distinguishing between the LAST-MODIFIED time when a meeting
 proposal was composed and stored, and the DTSTAMP time when each
 message about it is sent.

 This distinction might be important to humans.  The iTIP RFC doesn't
 give an example where this is important to the protocol.  iTIP
 RFC2446 sec 2.1.5 "Message Sequencing" says if there are multiple
 messages that match on UID and SEQUENCE, then the one with the later
 DTSTAMP overrides.  iCalendar RFC2445 sec 4.8.7.4 "Sequence Numbers"
 says the sequence number is only required to change when the changed
 data invalidates the previous version, for example changing the start
 time of a proposed meeting.

 Reading between the lines, I guess this applies to a scenario like the
 following: 

   An organizer sends a meeting proposal, and then later corrects some
   misspelled names, or includes more detailed location, and resends
   it.  The organizer's calendar user agent could resend the update
   with the same sequence number but a later DTSTAMP.  The DTSTAMP
   indicates the second came after the first, so the receiving
   calendar user agents know the second spelling and location should
   override the first [in case they arrive out of order].  Since the
   sequence number is the same, the updated proposal doesn't
   invalidate replies to the first, so receiving calendar user agents
   don't have to ask the user to accept/decline meeting again if they
   already replied to the first.

 ...but in this scenario the LAST-MODIFIED date would appear be just as
 good for disambiguating.  

 On the other hand, when a potential attendee replies, the reply
 messages have the UID and SEQUENCE number of the request, and the
 attendee doesn't modify the proposed event so it isn't appropriate to
 modify the LAST-MODIFIED date, so another field is needed to date the
 reply messages and distinguish them in case an attendee reconsiders
 and resends a different reply.  It looks like a separate DTSTAMP 
 is needed to distinguish the latest of multiple replies.  
)

Comment 3

[Michiel van Leeuwen (email: mvl+moz@)]

This might be related to bug 301140. Maybe even a dup (although that bug doesn't
talk about dtstamp)

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Yeah, that code change fixed the symptom I was talking about here.  I'm gonna
leave this bug open, though, as I'm not sure what behavior is really the most
desirable.

Comment 5

[Günter]

FMPOV DTSTAMP of a REQUEST is set the moment the ORGANIZER creates the event.
With specific situations he can modify the event, but modifying an event the SEQUENCE and the DTSTAMP has to be modified.
AND the calendar app HAS to send that modified event as an newer REQUEST with updated SEQUENCE and DTSTAMP to ALL ATTENDEES.

The ATTENDEE will use the REQUEST with the SEQUENCE number and the DTSTAMP (the ORGANIZER has send), add/update his calander.
His app has to send an REPLY with the same SEQUENCE number and the 'current' DTSTAMP. 

So your (ORGANIZER) REQUEST has to have ALWAYS the 'oldest' DTSTAMP value! 

If a REPLY is received with an older DTSTAMP than the stored at the ORGANIZER, it should NOT be processed, 
that's because it seems the REPLY is an answer to an event which was changed by the ORGANIZER.

If you -- the ORGANIZER -- didn't changed the event, the DTSTAMP should NOT have changed! 
If it's modified by just restarting TB/LG we have a BIG PROBLEM / BUG here, I think!

Hope there are others checking this!
For me it's a SHOWSTOPPED for LG !!!

Comment 6

[Daniel Boelzle [:dbo]]

(In reply to comment #5)
I think it's a bit different for received REPLY messages, Günter. Reading <http://rfc.net/rfc2446.html#s2.1.5>, especially the last paragraph, a calendar client needs to store the last received sequence and stamp of each attendee's REPLY message with the organizer's component. The rules about e.g. ignoring an REPLY message (if SEQUENCE matches, DTSTAMP is tie-breaker) need to be scoped to each individual attendee, not the organizer component's SEQUENCE/DTSTAMP. This particularly makes sense for local changes of the attendee's copy of the event (e.g. setting alarms, making notes), because calendar clients don't have to treat an attendee's copy special w.r.t. DTSTAMP.
(I will add that data as proposed in <http://tools.ietf.org/html/draft-desruisseaux-caldav-sched-04#section-7> in bug 457203.)

Thus I think it ought to be OK bumping DTSTAMP, but I am asking myself why we do that on every serialization:
<http://mxr.mozilla.org/comm-central/source/calendar/base/src/calItemBase.js#829>. Reading calIItemBase::icalString twice would serialize different ics, even though no modification has taken place. I think this is a bug, or at least bad API behaviour.

Comment 7

[Günter]

Hi Daniel,
OK, I was not aware of the "RECEIVED-SEQUENCE". So with the stored event at ORG'calendar you can add that while updating the event. 

But I'm still struggling with the "Thus I think it ought to be OK bumping DTSTAMP" as long as the DTSTAMP of the event itself is altered, or better to say: there is no change to the event. Isn't the DTSTAMP for an event together with the SEQUENCE has to be altered IF the ORG does some changes with that event? And for that an update of the event has to be send to all ATTENDEEs? 
"Bumping" up for any other reason is --IMO -- an bug, not only "at least bad API behaviour"!
??

Comment 8

[Daniel Boelzle [:dbo]]

I think it's odd, too. But I don't think it's a bug w.r.t. message sequencing.
My reading of the RFC regarding REQUEST messages: If the organizer bumps DTSTAMP (on minor changes) or SEQUENCE (on major changes, strongly should re-REQUEST), she SHOULD send out new messages, but it's not mandatory.

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

Does RFC2445bis clarify this at all?

Comment 10

[Günter]

@Dan ... please clarify your question/posting. Do you say the RFC2445bis has an 'undisputed' definition? I would second that. 
Reading the different RFC244* papers it's clear to me DTSTAMP is used by the ORG and ATT, respectively. It's a 'stamp' with the Z-time an action for the EVENT/TODO/FREEBUSY .. was made and it has to be send to the 'other' parties/ATTENDEEs or party/ORGANIZER. For that -- if UID and SEQUENCE don't help -- DTSTAMP acts as the tie-breaker. But how to use that if a 'system-bump' (which isn't related to the invitation process) has changed that value? We see the effect reported in the newsgroup: an ATT sends a REPLY and his DTSTAMP will be older that the bump DTSTAMP of the ORGANIZER if he logon/logoff after he received that REPLY without updating his event with the ATT's REPLY.
@Daniel #8
The RECEIVED-DTSTAMP will not help here AFAI understand. This can be used to trace the ATT's infos, but with checking against the ORGANIZER's currently stored DTSTAMP .. how do you see that helps? If you bump that 'ORG'-DTSTAMP (for what ever reason, if it's not event driven) you have a situation where the CUA can't act in a right manner.

Comment 11

[Daniel Boelzle [:dbo]]

(In reply to comment #9)
> Does RFC2445bis clarify this at all?

3.8.7.4.  Sequence Number <http://tools.ietf.org/rfcmarkup?doc=draft-ietf-calsify-rfc2445bis-07#section-3.8.7.4> states

""Organizer" includes this property in an iCalendar object that it sends to an "Attendee" to specify the current version of the calendar component."

Sending the message might fail, thus leaving attendees on older revisions. IMO that's the reason why <http://rfc.net/rfc2446.html#s2.1.4> states

"The value of the "SEQUENCE" property contained in a response from an "Attendee" may not always match the "Organizer's" revision. Implementations may choose to have the CUA indicate to the CU that the response is to an entry that has been revised and allow the CU to decide whether or not to accept the response."

(In reply to comment #10)
> The RECEIVED-DTSTAMP will not help here AFAI understand. This can be used to
> trace the ATT's infos, but with checking against the ORGANIZER's currently
> stored DTSTAMP .. how do you see that helps? If you bump that 'ORG'-DTSTAMP
> (for what ever reason, if it's not event driven) you have a situation where the
> CUA can't act in a right manner.

I think that's the cause why we should not check against the organizer component's DTSTAMP, but may only check against its SEQUENCE (whether a reply matches the general revision). However I wonder why we need to track a separate RECEIVED-SEQUENCE for each attendee then.

Comment 12

[Günter]

Just to get it right:
Lightning is going NOT going to use the "tie-breaker" as defined in the RFCs?!!

Is that said with:
"I think that's the cause why we should not check against the organizer
component's DTSTAMP, but may only check against its SEQUENCE (whether a reply
matches the general revision)."

??

Comment 13

[Bernard Desruisseaux]

(In reply to comment #9)
> Does RFC2445bis clarify this at all?

Yes.  See:

http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#section-3.8.7.2

> In the case of an iCalendar object that doesn't specify a "METHOD"
> property, this property is equivalent to the "LAST-MODIFIED"
> property.

So the answer to the question:

Should ICS calendar always bumps DTSTAMP on all events when writing?

is "No".

Comment 14

[Bernard Desruisseaux]

In section 2.1.5 of iTIP it specifies:
(http://tools.ietf.org/html/rfc2446#section-2.1.5)

  Furthermore, for each "ATTENDEE" property of a component CUAs must
  persist the "SEQUENCE" and "DTSTAMP" property values associated with
  the "Attendee's" response.

How a CUA is supposed to persist this information is left as an implementation detail.

If one happens to use multiple CUAs (e.g., Mozilla Lightning at work and Apple iCal at home) each accessing the same calendar service (e.g., the same CalDAV server) it then becomes important for these CUAs to share the persisted information.

iMIP clients should agree on a common way of persisting this information in iCalendar format. As Daniel pointed out, draft -04 of CalDAV Scheduling specified the parameters RECEIVED-DTSTAMP and RECEIVED-SEQUENCE for that purpose. With the new scheduling approach specified in draft -05 these parameters are no longer needed by CalDAV clients that always rely on the server to perform scheduling operations, as such these parameters have been removed in draft -05 since they became out of scope for this specific document.

That being said, I still believe these parameters should be defined in a separate document.

Comment 15

[Daniel Boelzle [:dbo]]

I fixed this issue with changes on bug 457203.

Comment 16

[Daniel Boelzle [:dbo]]

Fixed with bug 457203. LAST-MODIFIED/DTSTAMP is only bumped on actually modified items.

Comment 17

[Philipp Kewisch [:Fallen][📱📆]]

These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".