Subject: Change management properties

From: Federico Mena Quintero <[email-masked]>
Date: Wed, 5 Jul 2000 18:49:13 -0400

Hello,

Please forgive me if this question is a rehash of previous issues
discussed on this list, but I just recently joined and have only read
part of the archives.

I am a bit unclear on the purpose of the CREATED, DTSTAMP, and
LAST-MODIFIED properties in calendar components.  As I understand it,
DTSTAMP is a CUA-side timestamp of when the component was last
modified (or created for the first time).  When the component is wired
over to the calendar store, then the CREATED and/or LAST-MODIFIED
properties are set by the calendar store itself.

Is this correct?  If so, am I correct in assuming that clients have no
business in modifying the CREATED AND LAST-MODIFIED properties of
calendar components?  As I understand it, clients should just frob the
DTSTAMP property every time they make a change to a component.

RFC 2445 also says that when the organizer makes changes to a number
of properties, the CUA should increment the value of the SEQUENCE
property; these properties are enumerated in the spec.  However, it
also says that

	In addition, changes made by the "Organizer" to other
	properties can also force the sequence number to be
	incremented.  The "Organizer" CUA MUST increment the sequence
	number when ever [SIC] it makes changes to properties in the
	calendar component that the "Organizer" deems will jeopardize
	the validity of the participation status of the "Attendees".
	For example, changing the location of a meeting from one
	locale to another distant locale could effectively impact the
	participation status of the "Attendees".

So from a CUA user interface perspective, when should the sequence
number change?  Should it change if the old and new values for the
LOCATION property are different?

It strikes me as funny that the specification says "MUST" when it is
the organizer who has to think something may happen... :-)

  Federico

---

From: [email-masked] (Steve Mansour)
Date: Wed, 05 Jul 2000 22:36:51 -0700

> DTSTAMP property every time they make a change to a component.

hmm... my understanding was that DTSTAMP marks the time when an iCalendar
object was assembled and sent over the wire. For example, when an iTIP
message was built and sent.  So, I could send an iTIP REPLY to accept an
invitation, then a few minutes later send another reply that declines the
invitation. The UID, RECURRENCE-ID, and SEQUENCE number for both messages
would be the same. But the DTSTAMP of the decline would be later than the
accept.

CREATED and LAST-MODIFIED times seemed more like properties that would be
set by the calendar store.

> the organizer who has to think something may happen... :-)

Agreed.  I remember we debated this for a long time. However, there was no
clear-cut right or wrong way to do this. You mentioned the LOCATION
property above. Even with this property, it is not always clear what to
do.  If I move the LOCATION of a meeting from its initial location to a
room across the hall, it could be argued that no SEQUENCE change is
needed. However, if the location moves from San Jose CA, to London,
England then it's a pretty significant move and attendees need to be
aware.

We needed somebody to make a call on a case-by-case basis. So, we finally
settled on leaving it up to the Organizer.

-Steve

---

From: Doug Royer <[email-masked]>
Date: Thu, 06 Jul 2000 12:53:49 -0700

> properties are set by the calendar store itself.

DTSTAMP is when the instance of the object is created for transport.
CREATED is when the persistent object was originally created.
LAST-MODIFIED is the time stamp when the persistent object was last
modified.

(VEVET UID:one, CREATED on Jan 1 2000, LAST-MODIFIED Feb 1 2000,
 was transported on DTSTAMP at Mar 1 2000)

It would not matter who (CUA or store) created, modified, or transported
the object.

> calendar components?

Modifying CREATED - correct.

A CUA might create an object, the the CUA would set CREATED and the
store would not change it.

If the client (CUA) modifies the object - then it would update
the LAST-MODIFIED.

>  As I understand it, clients should just frob the

Every time they make an object.

Not if the object is just forwarded, (Joe - here is the VEVENT, pass it
along to the mailing list), then it would not need to update the DTSTAMP.

If however the client was translating the object from a foreign format
into what looked the the original VCALENDAR object, then I would say
the DTSTAMP would need to be updated.

DTSTAMP is simply a way to find out when the on the wire copy of
the object was created - maybe for de-duping. Maybe for sorting
before being presented to the CU.

> LOCATION property are different?

Only if it is a significant change, then you MUST bump the SEQUENCE number.
Where: significant := ORGANIZERs whim.

In some cases, moving the LOCATION from room 3 to room 4 is no big deal.
In others the ATTENDEEs might be upset if they did not know.

I think it would be better to always bump it then to never bump it.
And it would be best to ask the ORGANIZER when they make the change
if it is significant.

> the organizer who has to think something may happen... :-)

Some organizers are funny :-)

-Doug

---

From: Federico Mena Quintero <[email-masked]>
Date: Thu, 6 Jul 2000 18:07:05 -0400

> set by the calendar store.

OK, so I did get this right :-)

> settled on leaving it up to the Organizer.

The problem is how to do this programatically.  I don't think having
an "Increase sequence number" button in the GUI is very friendly to
the user.  I also don't want to prompt the user every time with, "you
seem to have changed the location of this appointment; is this a
change that could affect which attendees can be at the meeting?"

So I'm considering simply doing a dumb strcmp() of the location field
and increasing the sequence number if the new one is different from
the old one.  Of course it should be increased as well if the other
properties mentioned in RFC 2445 get changed.

Is this reasonable?

  Federico

---

From: [email-masked] (Steve Mansour)
Date: Thu, 06 Jul 2000 22:27:12 -0700

> change that could affect which attendees can be at the meeting?"

Agreed.

> properties mentioned in RFC 2445 get changed.

Sounds reasonable. Your users will let you know :-)

-Steve