Subject: [Ietf-calsify] Section 4.8.7.2 Date/Time Stamp: Purpose of DTSTAMP in the context of calendaring

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Wed Jul 4 22:01:45 2007

Here's the exact text change for this proposal.

Old text:

 > Purpose: The property indicates the date/time that the instance
 >    of the iCalendar object was created.

New text:

 > Purpose:  In the case of an iCalendar object that specifies a
 >    "METHOD" property, this property specifies the date and time that
 >    the instance of the iCalendar object was created.  In the case of
 >    an iCalendar object that doesn't specify a "METHOD" property, this
 >    property specifies the date and time that the information
 >    associated with the calendar component was last revised in the
 >    calendar store.

Old text:

 > This property is different than the "CREATED" and "LAST-MODIFIED"
 > properties. These two properties are used to specify when the
 > particular calendar data in the calendar store was created and last
 > modified. This is different than when the iCalendar object
 > representation of the calendar service information was created or
 > last modified.

New text:

 > In the case of an iCalendar object that specifies a "METHOD"
 > property, this property is different than the "CREATED" and "LAST-
 > MODIFIED" properties.  These two properties are used to specify
 > when the particular calendar data in the calendar store was
 > created and last modified.  This is different than when the
 > iCalendar object representation of the calendar service
 > information was created or last modified.
 >
 > In the case of an iCalendar object that doesn't specify a "METHOD"
 > property, this property is equivalent to the "LAST-MODIFIED"
 > property.

Cheers,
Bernard

Bernard Desruisseaux wrote:
> In section 4.8.7.2 Date/Time Stamp of RFC 2445 it says:
> 
>  > Purpose: The property indicates the date/time that the instance of
>  > the iCalendar object was created.
>  >
>  > [...]
>  >
>  > Description: The value MUST be specified in the UTC time format.
>  >
>  > This property is also useful to protocols such as [IMIP] that have
>  > inherent latency issues with the delivery of content. This property
>  > will assist in the proper sequencing of messages containing iCalendar
>  > objects.
>  >
>  > This property is different than the "CREATED" and "LAST-MODIFIED"
>  > properties. These two properties are used to specify when the
>  > particular calendar data in the calendar store was created and last
>  > modified. This is different than when the iCalendar object
>  > representation of the calendar service information was created or
>  > last modified.
> 
> As was discussed at the Calsify WG meeting in Prague, I believe we
> need to clarify the purpose of the "DTSTAMP" property.
> 
> I believe the current definition of the "DTSTAMP" property make
> sense in the context of scheduling, but not so for calendaring
> (i.e., calendar access).
> 
> According to the current definition, a CalDAV server that doesn't
> store the iCalendar representation of calendar resources should
> always return iCalendar objects with the "DTSTAMP" property set to
> the current time with the consequence that the ETag (see section
> 3.11 Entity Tags of RFC 2616) of all the calendar resources would
> change every second! Clearly, no serious CalDAV server implementation
> would do such a thing. Returning iCalendar objects with the "DTSTAMP"
> property set to the last modification time of the calendar resource
> would seem more appropriate.
> 
> One way to address this issue would be to make the "DTSTAMP" property
> optional in all calendar components in the iCalendar specifications,
> but to make it mandatory in all calendar components in the iTIP
> specification. Actually, it might have been the original intent.
> RFC 2445 was ambiguous on whether "DTSTAMP" is mandatory or optional.
> (see issues 37, 38, 39 and 40). iTIP, on the other hand, was clear
> that "DTSTAMP" is required in all calendar components.
> 
> In my opinion, we should not go back on the consensus made earlier
> by this WG to clarify that "DTSTAMP" is required in all calendar
> components. Some calendaring applications may actually find it useful
> to always have a "DTSTAMP" property in all calendar components.
> Remember that the "LAST-MODIFIED" property is optional in all calendar
> components.
> 
> In order to address this issue in a way that preserves backward
> compatibility with existing iCalendar applications, I propose to
> modify the definition of the "DTSTAMP" property to specify that in
> the context of calendaring (i.e., iCalendar object with no "METHOD"
> property) its value may be set to the date and time that the calendar
> component was last revised in the calendar store (i.e., same
> definition as LAST-MODIFIED), but that in the context of scheduling
> its value should be set to the date and time where the scheduling
> message (i.e., iCalendar object with a METHOD property) was created.
> 
> Cheers,
> Bernard
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

-- 
Bernard Desruisseaux | Senior Manager, Software Development | 514.905.8696
Oracle Server Technologies
600 Blvd. de Maisonneuve W., Suite 1900 | Montreal, Quebec H3A 3J2
Bernard Desruisseaux | Chef senior du d?veloppement logiciel | 514.905.8696
Oracle Technologies serveurs
600, boul. de Maisonneuve Ouest, bureau 1900 | Montr?al (Qu?bec) H3A 3J2

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Thu Jul 5 06:24:40 2007

Hi Bernard,

>  >    associated with the calendar component was last revised in the

Well "calendar store" is not defined anywhere. Plus if I happen to use 
iCalendar format as the native format in my calendar store this would not 
hold true - i.e. DTSTAMP would not change when the calendar data changed.

I am also a little unsure of what "created" means in the METHOD case. For 
instance, in at least one implementation I have done I create the iTIP 
message for an event by copying that event. Are you saying that when that 
happens a new DTSTAMP must be used? If so, I think the term "generated" 
might be better than "created". Or we should be much more explicit. In fact 
perhaps iTIP should state that every new iTIP message, be it a PUBLISH, 
REQUEST, REPLY etc MUST have a new DTSTAMP generated for it. If we go down 
that route then maybe 2445 needs to say nothing about DTSTAMP + METHOD.

-- 
Cyrus Daboo

---

From: TimHare at comcast.net (Tim Hare)
Date: Thu Jul 5 07:15:21 2007

Sorry I can't make Jabber sessions, but here is an alternative text idea
regarding DTSTAMP.

New text:

 > Purpose:  This property is used to determine the correct version of an
iCalendar
 > object to use, when presented with two different versions of the same
object. For
 > example, two iTIP REQUESTs to change meeting time for the same meeting
arrive,
 > or two different files with METHOD:PUBLISH are found describing the same
events. 
 > The object with the later DTSTAMP identifies the most recent copy and
MUST be used. 

With this new text, I would leave the old text about CREATED and
LAST-MODIFIED alone.

Tim Hare
Interested Bystander, Non-Inc.

---

From: bernard.desruisseaux at oracle.com (Bernard Desruisseaux)
Date: Thu Jul 5 13:53:51 2007

Cyrus Daboo wrote:
> Well "calendar store" is not defined anywhere.

I'm simply using the same terminology that is used in RFC 2445
when describing the "LAST-MODIFIED" property.

> Plus if I happen to use 
> iCalendar format as the native format in my calendar store this would 
> not hold true - i.e. DTSTAMP would not change when the calendar data 
> changed.

Whoever changes the iCalendar object should change the value of the
DTSTAMP property.  If a calendar user agent modifies an iCalendar
object in its local calendar store it should update the value of
DTSTAMP.  When a CalDAV client modifies an iCalendar object and
uploads it to a CalDAV server it should update the value of the
DTSTAMP property before uploading it to the server. Whether iCalendar
is used as the native format in your calendar store does not matter.

> 
> I am also a little unsure of what "created" means in the METHOD case.

Again, I simply used the same terminology that is used in RFC 2445.

> For instance, in at least one implementation I have done I create the 
> iTIP message for an event by copying that event. Are you saying that 
> when that happens a new DTSTAMP must be used?

My understanding is that DTSTAMP should be set to the time when a
iTIP messages is created/generated/rendered.

> If so, I think the term 
> "generated" might be better than "created".

I agree.  We should update the description of LAST-MODIFIED as well.

> Or we should be much more 
> explicit. In fact perhaps iTIP should state that every new iTIP message, 
> be it a PUBLISH, REQUEST, REPLY etc MUST have a new DTSTAMP generated 
> for it.

Ok.

> If we go down that route then maybe 2445 needs to say nothing 
> about DTSTAMP + METHOD.

But then how would DTSTAMP differ from LAST-MODIFIED in RFC2445?

Cheers,
Bernard