[Ietf-calsify] Re: Ietf-calsify Digest, Vol 38, Issue 10

[Ciny Joy]

Hi,
    So was their a conclusion on the SEQUENCE, DTSTAMP discussion? I am 
especially interested in knowing which fields should be used to 
determine the latest update received in iMIP. Also, is there a proposal 
to standardize when these fields should be modified?

Thanks,
Ciny

ietf-calsify-request at osafoundation.org wrote:
> Send Ietf-calsify mailing list submissions to
> 	ietf-calsify at osafoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
> or, via email, send a message with subject or body 'help' to
> 	ietf-calsify-request at osafoundation.org
>
> You can reach the person managing the list at
> 	ietf-calsify-owner at osafoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Ietf-calsify digest..."
>
>
> Today's Topics:
>
>    1. Re: Issue 86: iTIP: DECPRECATE SEQUENCE (Reinhold Kainhofer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 17 Sep 2007 21:55:26 +0200
> From: Reinhold Kainhofer <reinhold at kainhofer.com>
> Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
> To: ietf-calsify at osafoundation.org
> Message-ID: <200709172155.28657.reinhold at kainhofer.com>
> Content-Type: text/plain;  charset="ansi_x3.4-1968"
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Am Montag, 17. September 2007 schrieb Tim Hare:
>   
>> Third- from the definitions of these two in our current version of
>> RFC2445bis (-07?) it appears that DTSTAMP specifies the creation date of
>> the iCalendar object representation (not the create date of the object in
>> the calendar store, whatever representation that uses), but does NOT
>> indicate revisions. From my reading of it, DTSTAMP would only change for a
>> "revision" if said "revision" consisted of deleting and recreating the
>> iCalendar object. 
>>     
>
> Actually, this is not clear to me. According to the RFC, the DTSTAMP is the 
> date/time then that specific *iCalendar* object is created. If an application 
> uses some other storage format and creates the iCalendar objects for calendar 
> data exchange on the fly, shouldn't DTSTAMP be the date of that creation?
>
> The DATE-MODIFIED would be the date of the last change, the CREATED would be 
> the time of the initial creation of the event. And SEQUENCE needs to be 
> incremented whenever a change significant for schedulling happens.
>
>
> RFC 2445, section 4.8.7.2:
>    Purpose: The property indicates the date/time that the instance of
>    the iCalendar object was created.
>
> RFC 2445bis-07, section 3.8.7.2:
>    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.
>
> Hmm, that last added sentence seems like a significant behavior change in the 
> RFC. In particular, looking at the further description, I don't think it's 
> entirely correct:
>
> RFC 2445, section 4.8.7.2:
>    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.
>
> RFC 2445bis-07, section 3.8.7.2:
>       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.
>
> I read the old Purpose as DTSTAMP indicating when that iCalendar object was 
> created from the data in the calendar store, while the new one indicates that 
> it should be the time of the last modification.
> The first paragraph of the new Description (and the old description) also 
> indicates this, while the added paragraph in the new Description indicates 
> something different. Maybe this should be further clarified. If DTSTAMP 
> should really be the date of the last modification of the data in the 
> calendar store, why do we need it at all?
>
> 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/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFG7tuwTqjEwhXvPN0RAlm0AJ930xifJmWyss5SYLyPDBCYVuR0mgCeMwoT
> hTEwqIdhhNvLnFkGADqSyjo=
> =eXpA
> -----END PGP SIGNATURE-----
>
>
> ------------------------------
>
> _______________________________________________
> Ietf-calsify mailing list
> Ietf-calsify at osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/ietf-calsify
>
>
> End of Ietf-calsify Digest, Vol 38, Issue 10
> ********************************************
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/ietf-calsify/attachments/20070928/f37d8c2d/attachment.html