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

From: Ciny.Joy at Sun.COM (Ciny Joy)
Date: Fri Sep 28 11:47:57 2007

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

[email-masked] wrote:
> Send Ietf-calsify mailing list submissions to
> 	[email-masked]
>
> 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
> 	[email-masked]
>
> You can reach the person managing the list at
> 	[email-masked]
>
> 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 <[email-masked]>
> Subject: Re: [Ietf-calsify] Issue 86: iTIP: DECPRECATE SEQUENCE
> To: [email-masked]
> Message-ID: <[email-masked]>
> 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: [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/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFG7tuwTqjEwhXvPN0RAlm0AJ930xifJmWyss5SYLyPDBCYVuR0mgCeMwoT
> hTEwqIdhhNvLnFkGADqSyjo=
> =eXpA
> -----END PGP SIGNATURE-----
>
>
> ------------------------------
>
> _______________________________________________
> Ietf-calsify mailing list
> [email-masked]
> 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

---

From: cyrus at daboo.name (Cyrus Daboo)
Date: Fri Sep 28 12:04:58 2007

Hi Ciny,

--On September 28, 2007 11:46:53 AM -0700 Ciny Joy <[email-masked]> wrote:

> 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?

I am crafting a response to all the discussion that took place on this 
recently.

My conclusions are the following:

1) We do need SEQUENCE to properly allow an organizer to match up responses 
from attendees with the latest revisions sent out by the organizer.

2) Clarify that SEQUENCE is not meant to be any kind of indicator to the 
client that a response is needed. RSVP=TRUE must be used instead.

3) Clarify that clients must determine for themselves what constitutes a 
significant change to an event that would cause a new accept/decline prompt 
to be presented to a user. Clients may treat a change in SEQUENCE number as 
always causing a prompt, but should not rely solely on a change of SEQUENCE 
number.

4) Clarify under what circumstances SEQUENCE should change. There is 
currently some text on that in 2445bis, but I am tempted to suggest that 
really belongs in 2446bis in a single section dealing with SEQUENCE issues. 
The text here would list some properties for which changes MUST result in a 
sequence change, and others that MAY result in a change depending on the 
exact nature of the property change. I don't think we can go further than 
that.

I am working on putting together some text on this so that we can seek 
consensus on these points.

-- 
Cyrus Daboo