Subject: question on 'LAST-MODIFIED' property

From: Harrie Hazewinkel <[email-masked]>
Date: Mon, 19 Jul 2004 14:38:28 +0200

HI all,

I have an implementation kind of question regarding the LAST-MODIFIED
property. I am curious of thoughts for this property whether it
is usefull to maintain in CAP clients (or intermediate-servers that
act as clients).

In our implementation of a CAP server we have added at the server side
the LAST-MODIFIED property. The approach is; adding or updating this 
property at the moment the component is inserted or updated in the
calendar store. My problem is that the CAP client invoking the
respective  action in the server will never know the value of the
property unless the client is does invoke a SEARCH command for the
specific UID/component.
The CAP client can do a reasonable guess of the time only when the 
system clock of the server and client are in sync. Not knowing the value
of the LAST-MODIFIED makes it difficult for a CAP client that would only 
like to retrieve updates made since the last synchronization (it does 
not really know the LAST-MODIFIED value) and having been off-line
(think along the lines of IMAP usage).

Therefore, I was thinking that it could be useful to have a 
LAST-MODIFIED property in the VREPLY also. If I look at examples in
page 103/104 the UID is included.
Maybe there are other apporaches I have missed so far, but always
invoking a SEARCH command for a specific time and then in the client
chekcing whether there was an update is also not attractive. In 
perticular in clients with limited resources.

Any ideas,

Harrie

---

From: [email-masked]
Date: Mon, 19 Jul 2004 21:34:19 -0400

First - I do not believe the intent of CAP is for true "synchronization" in 
the PDA/IntelliSync/SyncML sense. That would be more in the vein of the 
SyncML projects I believe.

Secondly, see 4.8.7.2 (DTSTAMP) in RFC2445 - I belive that this DTSTAMP, in 
conjunction perhaps with UID and/or SEQ, could be used to determine the 
update time of things on the other end.. It would be up to the client to 
maintain DTSTAMP in any local database containing iCalendar 
objects;  remember, however that storing calendar objects makes you a CS 
(Calendar Store) in addition to a CUA  and you might want/need to act 
accordingly.

Tim Hare
Interested Bystander, Non-Inc.

At 08:38 AM 7/19/04, you wrote:

>The CAP client can do a reasonable guess of the time only when the system 
>clock of the server and client are in sync. Not knowing the value
>like to retrieve updates made since the last synchronization (it does not 
>really know the LAST-MODIFIED value) and having been off-line
>Therefore, I was thinking that it could be useful to have a LAST-MODIFIED 
>property in the VREPLY also. If I look at examples in
>chekcing whether there was an update is also not attractive. In perticular 
>in clients with limited resources.
>
>
>Any ideas,
>
>Harrie

Tim Hare
Interested Bystander, Non-Inc.

---

From: Doug Royer <[email-masked]>
Date: Mon, 19 Jul 2004 20:35:12 -0600

Harrie Hazewinkel wrote:

> is useful to maintain in CAP clients (or intermediate-servers that
> act as clients).

Yes, LAST-MODIFIED was part of the synchronization discussion that took
part in the requirements for CAP.

What ever CUA is going to sync with the CS will need that property in order
to tell if which possibly modified object was the last edit of that object.

SEQUENCE and DTSTAMP tell you the last that was sent by the ORGANIZER.
However those will not tell you which has the correct copy of any added 
local
attributes (VALARM components as an example).

If the CS does not change anything as seen by the CUA, then LAST-MODIFIED is
not relevant.  If the UID, SEQUENCE, and DTSTAMP are the same
in the CUA and CS, yet the LAST-MODIFIED in the CS is newer, then it means
that another CUA updated the object (such as adding local vlarrms, or 
removing them, or ...)
and the copy in the CS should be used as the latest copy for 
synchronization.

http://www.calsch.org/ietf/archives/draft-ietf-calsch-capreq-04.txt

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   | Fax:    (866)594-8574
                               | Cell:   (208)520-4044

              We Do Standards - You Need Standards