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

From: jwn2 at qualcomm.com (John W Noerenberg II)
Date: Thu Sep 7 16:07:49 2006

At 1:28 PM -0700 6/12/06, Jeffrey Harris wrote:
>Given that the RFC was confused, I'd like to put in a vote in favor of
>choosing optional for DTSTAMP, not MUST.  Lots of iCalendar in the wild
>doesn't have a DTSTAMP, and I don't see a compelling reason for
>requiring it (although I'd be happy to be informed of compelling reasons).

Heck, I'd love to see DTSTAMP's use deprecated.  I don't buy there's 
sufficient difference between CREATED and DTSTAMP to necessitate two 
different attributes.
-- 

john noerenberg
   ----------------------------------------------------------------------
   It is treason to sacrifice love of truth, intellectual honesty,
   loyalty to the laws and methods of the mind, to any other interests,
   including those of one's country.
   -- Herman Hesse, The Glass Bead Game, 1943
   ----------------------------------------------------------------------

---

From: Robert_Ransdell at notesdev.ibm.com (Robert Ransdell)
Date: Thu Sep 7 16:18:39 2006

you will break backward compatibility if you remove DTSTAMP.  Its 
equivalent to Posted Date.

John W Noerenberg II <[email-masked]> 
Sent by: [email-masked]
09/07/2006 07:08 PM

To
Jeffrey Harris <[email-masked]>
cc
CALSIFY Mailinglist <[email-masked]>
Subject
Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being    optional 
(in the grammar)

john noerenberg
   ----------------------------------------------------------------------
   It is treason to sacrifice love of truth, intellectual honesty,
   loyalty to the laws and methods of the mind, to any other interests,
   including those of one's country.
   -- Herman Hesse, The Glass Bead Game, 1943
   ----------------------------------------------------------------------
_______________________________________________
Ietf-calsify mailing list
[email-masked]
http://lists.osafoundation.org/mailman/listinfo/ietf-calsify

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060907/2e21ab28/attachment.htm

---

From: TimHare at comcast.net (Tim Hare)
Date: Thu Sep 7 16:33:56 2006

RFC2445 has this to say about DTSTAMP, and about its use  vs. CREATED and
DATE-MODIFIED
 
-------------------------------------------------------- snip
--------------------------------------------------------------------
Conformance: This property MUST be included in the "VEVENT", "VTODO",

   "VJOURNAL" or "VFREEBUSY" calendar components.

   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.
-------------------------------------------------------- snip
--------------------------------------------------------------------
 
Also I seem to remember that DTSTAMP is used in iMIP and iTIP to determine
the winner in a multiple-updates-received-not-necessarily-in-order scenario.
I don't think it can be deprecated without understanding its use in those
areas.
 
Tim Hare
Interested Bystander, Non-Inc.

  _____  

From: [email-masked]
[mailto:[email-masked]] On Behalf Of Robert Ransdell
Sent: Thursday, September 07, 2006 7:18 PM
To: John W Noerenberg II
Cc: CALSIFY Mailinglist; [email-masked]
Subject: Re: [Ietf-calsify] Error in RFC 2445 regarding DTSTAMP being
optional(in the grammar)

you will break backward compatibility if you remove DTSTAMP.  Its equivalent
to Posted Date. 

09/07/2006 07:08 PM 

To

cc

Subject

john noerenberg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060907/7b81a24b/attachment.htm

---

From: jwn2 at qualcomm.com (John W Noerenberg II)
Date: Thu Sep 7 17:52:45 2006

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.  It's 
pointless redundancy.  One or the other should go.

If DTSTAMP is needed for backward compatibility then keep that 
instead and deprecate CREATED.

---

From: reinhold at kainhofer.com (Reinhold Kainhofer)
Date: Fri Sep 8 03:25:46 2006

Am Freitag, 8. September 2006 02:52 schrieb John W Noerenberg II:
> 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: [email-masked], 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/

---

From: jwn2 at qualcomm.com (John W Noerenberg II)
Date: Mon Sep 11 12:27:46 2006

>particular invitation or export from the calendar server.

I'll grant it's possible for DTSTAMP and CREATED to differ.  I've 
just never seen it. :-)
The essential question I'm asking, are both attributes necessary?  I 
can see an argument for DTSTAMP (despite the way I began this 
thread), as it's useful for determining the order in which changes to 
an event should be applied.  However, no other attribute depends on 
CREATED.  In the interest of simplifying the protocol, 4.8.7.1 should 
be eliminated (and references to it, of course).  However I'd be 
happy if the text in 4.8.7.1 where changed from:

    Conformance: The property can be specified once in "VEVENT", "VTODO"
    or "VJOURNAL" calendar components.

to

Conformance: The property MAY be specified once in "VEVENT", "VTODO"
or "VJOURNAL" calendar components.  Absence of this parameter MUST 
NOT cause a CUA or CS (Calendar Service) to reject the calendar 
component specification.

That would make it clear the parameter is optional.
-- 

john noerenberg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20060911/34282fbc/attachment.htm