Subject: Questions about the proposed standards...

From: Ian Woollard <[email-masked]>
Date: Wed, 23 Jun 1999 19:23:09 +0100

I'm still trying to get my head around the specs...

Should REQUEST and REPLY object be stored in the database?
It seems to me that they should be stored in the database
until they have been married up and then they can be
deleted, but it didn't seem to be explicitly mentioned
anywhere... either they aren't or I've missed it.

Another question: is there a need for SEQUENCES for each
calendar database (I know that there are SEQUENCES for
objects in the database- but I'm talking about a master
SEQUENCE)?

(I also have visions of each database keeping track of the
SEQUENCE of the other databases they reference but I think
that isn't in the specs anywhere- but I think that that
would be a good idea.)

Its just that a SEQUENCE can be useful to see whether the
database has changed or not with little work, and it can
also discover if a database has been rolled back due to
failures of the host. Ids can be uniquely tagged to avoid
problems with Id reuse after deletion... and there might
be a way to get rid of tombstones too using SEQUENCE.

-- 
-Ian        ([email-masked])

2 Secrets to success: 1. Don't tell everyone what you know.

---

From: Frank_Dawson/CAM/[email-masked]
Date: Wed, 23 Jun 1999 14:54:45 -0400

Which specs? iTIP/iMIP RFCs or CAP drafts?

---

From: Frank_Dawson/CAM/[email-masked]
Date: Wed, 23 Jun 1999 15:02:21 -0400

About SEQUENCE questions...
- SEQUENCE is a component property, not a CS or calendar property.

- Its purpose is to allow sequencing of iTIP messages received out of sequence.
It is used along with UID, RECURRENCE-ID, and lastly, DTSTAMP.

- Your suggestion seems to be a part of a larger vision for calendar
synchronization requirements. This is outside the scope of current CAP work.

Hope this helps.

-- Frank