[Ietf-calsify] Section 220.127.116.11 Date/Time Stamp: Purpose of DTSTAMP
in the context of calendaring
bernard.desruisseaux at oracle.com
Thu Jul 5 13:51:26 PDT 2007
Cyrus Daboo wrote:
> Hi Bernard,
> --On July 5, 2007 12:59:59 AM -0400 Bernard Desruisseaux
> <bernard.desruisseaux at oracle.com> wrote:
>> 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.
> 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
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.
> 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?
More information about the Ietf-calsify