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

Bernard Desruisseaux bernard.desruisseaux at oracle.com
Wed Jul 4 21:59:59 PDT 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
> Ietf-calsify at osafoundation.org
> 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


More information about the Ietf-calsify mailing list