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

[Bernard Desruisseaux]

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