[Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being optional(in the grammar)

[Reinhold Kainhofer]

Am Freitag, 8. September 2006 02:52 schrieb John W Noerenberg II:
> At 7:31 PM -0400 9/7/06, Tim Hare wrote:
> >RFC2445 has this to say about DTSTAMP, and about its use  vs.
> >CREATED and DATE-MODIFIED
>
> I know what the RFC says. :-)  My point is the definitions (despite
> the RFC's claim to the contrary) are indistinguishable.  In practice
> both CREATED and DTSTAMP invariably have the same value.  

Sorry, but that's not true. If I created an event yesterdayday, sent out an 
invitation and today get some confirmations back, the event will have 
CREATED:20060908....
DATE-MODIFIED:20060909...
(Explanation: The event was created yesterday in the storage (which might 
either be a flat file, a groupware server or something else), and it was 
modified today, which does not create a new event.)

If you now tomorrow publish that event to some other group of people or so 
(i.e. send a mail with METHOD:PUBLISH), the calendar that you send out will 
have the above CREATED and DATE-MODIFIED (provided that you didn't modify it 
meanwhile in the calendar store), but as that particular invitation will be 
created tomorrow, it will have
DTSTAMP:20060910...


So, these three settings are in deed different. The CREATED will never change 
once the event is by the organizer, the DATE-MODIFIED is only changed when 
you modify the event, and the DTSTAMP is the time when you create that 
particular invitation or export from the calendar server.

Cheers,
Reinhold


-- 
------------------------------------------------------------------
Reinhold Kainhofer, Vienna University of Technology, Austria
email: reinhold at kainhofer.com, http://reinhold.kainhofer.com/
 * Financial and Actuarial Mathematics, TU Wien, http://www.fam.tuwien.ac.at/
 * K Desktop Environment, http://www.kde.org, KOrganizer maintainer
 * Chorvereinigung "Jung-Wien", http://www.jung-wien.at/