Closed Bug 303663 Opened 16 years ago Closed 13 years ago
should ICS calendar always bumps DTSTAMP on all events when writing?
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.
My reading of RFC 2445 section 18.104.22.168 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?
Status: NEW → ASSIGNED
(In reply to comment #1) > My reading of RFC 2445 section 22.214.171.124 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 126.96.36.199 "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. )
This might be related to bug 301140. Maybe even a dup (although that bug doesn't talk about dtstamp)
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.
Assignee: dmose → nobody
Status: ASSIGNED → NEW
Summary: ICS calendar always bumps DTSTAMP and LASTMODIFIED on all events when writing → should ICS calendar always bumps DTSTAMP on all events when writing?
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 !!!
(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.
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"! ??
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.
Does RFC2445bis clarify this at all?
@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.
(In reply to comment #9) > Does RFC2445bis clarify this at all? 188.8.131.52. Sequence Number <http://tools.ietf.org/rfcmarkup?doc=draft-ietf-calsify-rfc2445bis-07#section-184.108.40.206> 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.
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)." ??
(In reply to comment #9) > Does RFC2445bis clarify this at all? Yes. See: http://tools.ietf.org/html/draft-ietf-calsify-rfc2445bis-08#section-220.127.116.11 > 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".
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.
Fixed with bug 457203. LAST-MODIFIED/DTSTAMP is only bumped on actually modified items.
Assignee: nobody → daniel.boelzle
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
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".
Target Milestone: 1.0 → 1.0b1
You need to log in before you can comment on or make changes to this bug.