pregen@xxxxxxxxxxxxxxxxxx wrote:
If anyone thinks a topic still needs discussion, please say so on the list.
I have spent hours working on the draft cleaning up
the multiple identical statements and such. I am now
moving the property/component/value type definitions to the front of the spec - like iCalendar.
After the last post from Steve, I looked closer at the METHOD property in the objects and I still feel that we do not need to put METHOD in the objects. This
will keep METHOD 100% pure iTIP (yet we can still query
for objects by METHOD).
The only thing we really want to know is if the objects are 'BOOKED', 'UNPROCESSED', or marked 'DELETED'. And So I added (I can still remove it :-), STATE() to the query language.
SELECT * FROM VEVENT WHERE STATE() = 'BOOKED'
SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED'
SELECT * FROM VEVENT WHERE STATE() = 'DELETED'
The 'state' also does not need to be specified as belonging
to an object as it will NEVER go over the wire. As 100% of
all *iTIP* objects deposited are UNPROCESSED, 100% of all objects
modified to DELETE state (still working out the syntax for this).
are in the DELETED state. And 100% of all other objects are in effect BOOKED (including VCARs, {CS,VCALSTORE,VAGENDA} properties)
So you would CMD:CREATE any object. If it has a METHOD, then it MUST BE an iTIP object, so it is deposited and its 'state' is 'UNPROCESSED'.
If it does not have a METHOD in it, then its state is BOOKED.
And I am thing of adding a parameter to the DELETE command:
CMD:DELETE <- Remove the object from the store.
CMD;opt=markfor:DELETE <- Mark it as state DELETED.
I would think that a huge amount of the time using the STATE() method would get you what you want (You can still also use date constraints with it).
Also, If you query for METHOD = '<some iTIP method>', then the CS MUST get you the objects that were deposited into the CS with that method in their VCALENDAR object and CAP only needs to specify that the CS MUST remember their METHOD and not how the CS remembers.
This also slightly simplifies synchronization where pass one must be get pending iTIP requests (UNPROCESSED).
Comments?