Subject: Re: Fwd: Re: Synchronization [Was: Re: CAP: Last CallByMarchIETF: Need Volunteers!]

From: Mark Paterson <[email-masked]>
Date: Fri, 01 Feb 2002 13:51:09 -0500

At 10:51 AM 1/31/2002 -0700, you wrote:

Mark Paterson wrote:

> At 02:57 PM 1/18/2002 -0700, Doug Royer wrote:

> ...

> > Use SEQUENCE. Only the ORGANIZER can update the SEQUENCE
number.

> ....

> Sorry for taking so long to get back on this thread. My day job got
in

> the way :-)

> I didn't quite get what you meant about older data appearing
newer

> then newer data at first but I suppose some CS implementations
where

> all messages ever sent are kept I suppose this is possible but
all

> this means is that when we do a query for changes a sync CUA needs
to

> be careful to filter out those objects whose SEQUENCE appears
older

> then the SEQUENCE which the sync CUA last remembers. It
doesn't

> resolve my questions. A sync CUA is still not going to fetch each
and

> every object it knows about to check the latest SEQUENCE to
determine

> changes. This would be way too heavy on the CS.

I did not mean to imply that. I meant that LAST-MODIFIED only

tells you that it has been modified. It does not mean that

it is more-valid data simply because it has a newer time
stamp.

Sorry. I misunderstood you. You made it sound as if SEQUENCE was the
solution to all our problems.

> Let's try pulling back on
reigns and refocus on my original questions.

> My claim was that in order for CAP to live up to the Sync
requirements

> listed in the CAP Requirements a Sync CUA must be able to get
the

> answers to the following 3 questions:

> 1) Within the given date range what entries are new?

> 2) Within the given date range what entries have changed?

> 3) Within the given date range what entries have been deleted?

> Having followed the CAP-QL thread its perhaps time I took a crack
at

> building my own queries. I've made a few simplifying assumptions.
I've

> just worried about events, I've used DTSTART to determine if
something

> is in range and rather then figuring out what attributes to
retrieve

> I've just put "*". So here we go:

> BEGIN:VQUERY

> EXPAND:TRUE

> QUERY:SELECT * FROM VEVENT WHERE

> DTSTART < upper_range

> AND DTSTART > lower range

> AND DTSTAMP > last_time_asked

> END:VQUERY

(replace DTSTAMP with LAST-MODIFIED and I think it is right,

I incorrectly used DTSTAMP when I should have said
LAST-MODIFIED.

DTSTAMP is the time the iCalendar object was created for
transport

and is ALWAYS updated [per iTIP?] just before transporting
the

object.)

Yes, LAST-MODIFIED. Sorry you mentioned DTSTAMP in an earlier replied and
I switched over with out even really realizing I'd done so.

> If the Sync CUA then filters
out any objects whose SEQUENCE seems to

> indicate that it is actually older then what the Sync CUA last
knew

> about (as per Doug's suggestion) then the results that remain
should

> be all the changes within the range.

Yes, and by also filtering out from the returned set any

with the same UID and older SEQUENCE numbers in the return set.

As in if there were 5 updates between your sync times, you may
get:

UID:1, and 5 objects, with SEQUENCE numbers 1 2 3 4
5

Where only '5' would be the newest and 1, 2, 3, 4 are discarded

using iTIP rules.

For the issue of sync I'll just say yes. If a CS is implemented in this
fashion then yes this is what I meant. The Sync CUA should filter out
everything out but the latest and greatest.

With respect to CAP-QL however perhaps a separate thread could be started
since if I were a CUA developer I don't necessarily want to get every
sequence and have to filter out the old stuff (seems like a lot of
unnecessary byte count).

If am retrieving event data to populate say a week view then I think I'd
go:

BEGIN:VQUERY

EXPAND:TRUE

QUERY:SELECT * FROM VEVENT WHERE

DTSTART < end of the week

DTSTART > beginning of the week

END:VQUERY

This should get me all the booked and unbooked events for the week. As a
CUA I shouldn't have to filter through the SEQUENCE for each event I get
back. If so how do I change the query to just get the latest. I checked
in draft 06 and the VQUERY examples do not hint that this is the case
(then again they don't hint that it isn't) and nothing within the current
CAP-QL threads has addressed this as far as I know.

Anyhow this does not effect whether CAP is OK with respect to sync so for
now let's say they get filtered.

> By enumerating through
the

> results a Sync CUA can determine everything that is new by the
objects

> whose UID it doesn't recognize, ...

Yes.

> ... everything that has changed by the

> objects whose UID it does recognize, ..

No - changes would have the same UID for the same objects

and has a newer SEQUENCE number.

That's what I said. Why are you disagreeing with me? I think we agree.
The UIDs are the same so the sync CUA recognizes them and therefore knows
they aren't new, hence they should be handled as objects which have had
changes to them.

> .. and finally everything that
has

> been deleted from the objects within the changed list who now
are

> marked with METHOD:DELETE (as long as CUAs are forced to use
this

> method to delete objects).

iCalendar objects are marked for delete with METHOD:MODIFY.

They are deleted from the CS by <delete/>.

Yes I know. To quote you from later in this message "objects are
marked for delete by using METHOD:MODIFY and changing the object in the
store to METHOD:DELETE" which is all I meant.

Anyhow I think if it weren't for those annoying recurring entities we are
both in agreement that my query (with LAST_MODIFIED) covers things for
sync.

We need to agree on the issues with respect to recurring entries
next.

> What about instances of a recurring object?

> The EXPAND:TRUE line in the query should ensure that all new
and

> changed instances get returned. Correct?

Yes and all existing and unchanged instances.

This could be but I'm not sure this is actually specified anywhere within
the CAP-QL text. Should I get the master event and its UID along with all
its baby instances expanded out with their own RECURRENCE-ID or should I
just get the instances falling within the range I've queried
over?

Also, do I really need to put EXPAND:TRUE? I put it there since I thought
it was needed to get anything back since if it weren't expanded then
their would be no DTSTART values falling with the range but I suppose you
could also say that with EXPAND:FALSE that you'd still get back recurring
entries that have changed with recurrence sets that would cause an
instance to fall within your query range with the difference being in the
results you get back you just have the master event with its UID and
recurrence set unexpanded (no babies hanging on :-) ).

Perhaps some text to make the answers to these questions clearer is
needed. I'll let those of you contributing to the CAP-QL threads work it
out :-).

As far as sync goes I think in the case of both questions either answer
gives a Sync CUA a way to get new and changed instances of a recurring
entry within a range.

> The problem is still deleted
instances. I don't think EXPAND:TRUE will

> make sure that the Sync CUA gets returned instances marked with
METHOD

> DELETE within the range. If it does then we're covered but I
somehow

> don't think that's the way it is (comments from the CAP-QL
gang?).

The instances of objects with a RECURRENCE-ID do not exists anyway.

They are an expansion of an existing object that is expanded and

for booked objects only. The ORGANIZER never sends a METHOD:REQUEST

object that contains a RECURRENCE-ID.

Of course not. I was speaking figuratively. That's why it's not
covered.

And don't forget about
METHOD:CANCEL sent by the ORGANIZER,

which can cancel entire objects or specific instances.

Quoting you from a past reply "And we need to add text about
METHOD:DELETE and how that is the way to mark something as deleted."
and I agree with you.

So, if the EXPAND:FALSE object is
marked METHOD:DELETE, then ALL

of the instances are deleted and that object will NEVER have

a RECURRENCE-ID property (because EXPAND is FALSE).

When you say "the EXPAND:FALSE object" do just mean the VEVENT
with its UID, recurence set, etc.. or do actually mean that it is
considered marked as EXPAND:FALSE and then after someone does a VQUERY
with EXPAND:TRUE it will get expanded, all the instances will get
expanded out (with RECURRENCE-IDs being assigned) and then from then on
it is a VEVENT marked EXPAND:TRUE?

I can see the logic to that but I never realized that this was the
implication of querying with EXPAND:TRUE. Perhaps some explanatory text
within the CAP-QL text is needed.

If this is what you mean then this should be OK for sync. If a VEVENT
hasn't yet been expanded then it hasn't been sync'd to your PDA, Phone,
whatever yet so the fact that it now doesn't exist is fine. The other end
never new about them. I'll try that one more time. If a Sync CUA uses
EXPAND:TRUE in its queries (like I've done above) then EXPAND:FALSE
objects (to use your term) couldn't yet have been sent to the device (or
whatever you are synching with) so the fact that they now won't be is
fine.

The problem is still the instances that did result from EXPAND:TRUE that
are now gone.

iTIP allows for updates to
instances of objects. When that happens

there can be multiple objects created:

'One' new
object with an updated SEQUENCE

'More than
one' object each with the SAME UID and SEQUENCE.

And each
object specifying one or more instances.

(see ADD
in iTIP) - and all booked.

And if an object is METHOD:CANCEL, then its containing

DTSTART, DTEND/DURATION, RRULE, EXRULE, RDATE, and EXDATE
properties

specific instances that have been canceled, for the same

SEQUENCE number and UID objects. (see iTIP).

> Instead another query such as this is needed I think:

> BEGIN:VQUERY

> EXPAND:TRUE

> QUERY:SELECT * FROM VEVENT WHERE

> EXDATE < upper_range

> AND EXDATE > lower range

> AND DTSTAMP > last_time_asked

> END:VQUERY

> This would give a Sync CUA any newly changed recurring objects
with

> exceptions within the range, I think?

No, an object can be modified and instances can be removed by

changing the RRULE and never adding a EXDATE. Or by adding

a RDATE, or by adding or altering a EXRULE, or by DTSTART,

or RECURRANCE-ID, ...

Yes I know. That's what my next paragraph says. That's my point. Once a
recurring entry gets sync'd from then on if an instance is deleted using
any method other then adding an EXDATE I can't think of a way to make
query that ensures that the Sync CUA gets informed about the deleted
instances which it previously sync'd.

> It will only work however
if

> CUAs always add an EXDATE when an instance from a pre-existing

> recurrence set is deleted. If they just redo the recurrence
set

> completely then it becomes impossible.

Not impossible. Your first query (with LAST-MODIFIED) will

get all of the objects in that time range. Then the CUA

must compare using SEQUENCE and merging any multiple objects

with the same UID (originally created with ADD), then

it knows the state of the 'UID' object.

My first query doesn't get me all the objects in the time range, it get's
me all the entries within the time range which have changed. There is a
big difference. Anything the Sync CUA doesn't get, it assumes hasn't
changed. There is no way of knowing that the reason it didn't get a
recurring entry that used to have instances within this range is because
it is gone. It just thinks it hasn't changed.

When I say that it is impossible I should perhaps say it is not possible
in the way that the Sync CUA really needs.

A Sync CUA could take all the recurring entries it has sync'd in the
past, figure out which ones aught to cause an instance to fall within the
range being queried for and then do a query to get them from the CS
individually to check but this would be a lot of extra calls to the CS
and depending on your Sync model perhaps not even possible.

If you are building a Palm conduit or an Active Sync plug-in you can
access the devices database so you could do this despite how ugly it
seems but in the case of SyncML however I don't think you'd really be
allowed to. In a SyncML scenario the SyncML client on the device
authenticates against a Sync Server and reports its changes since the
last time it initiated a sync. The Sync Server then asks the backend data
store (the CAP CS in our world) for its changes since the last time a
sync was done, it compares the two lists and sends each back instructions
on what to change so that the two of them are good to go. The Sync Server
does not have knowledge of the database on the device. In theory the
SyncML protocol does have a search and get command so I guess the sync
server could go back to the sync client and ask for the entries (but I've
yet to see a SyncML client which implements these commands) but this
flies in the face of the entire SyncML model. I'm sure the gang at the
SyncML initiative would be horrified by my mere suggestion of this. The
poor owner of the wireless device is paying by the second on a 2G network
and by the packet on a 2.5G or 3G network so the extra trips back to the
device will not be appreciated.

> If my logic holds true (and
that remains to be seen. I need the

> expertise of the CAP-QL contributors) then text for the
following

> should be added:

> 1. CUAs must use METHOD:DELETE to mark something as
deleted.

Entire objects are marked for delete by using METHOD:MODIFY

and changing the object in the store to METHOD:DELETE.

It is NOT used when CANCELing instances of an object.

Hence the need for the text as suggested by you in a past
response.

> 2. CUAs must use EXDATE to
mark an instance within an existing

> Recurrence set as deleted rather than redefining the recurrence
set.

No. That is not practical.

I admit it is rather restrictive but I can't think of any other way in
which a Sync CUA could put together a set of queries and ensure that it
gets told about deleted instances of recurring entries that it has
previously sync'd.

I'd love it if someone else could suggest a query that'll do it. Anyone?
It's the only sticking point keeping us from closing this issue as far as
I can tell and I want it closed. This is far too much work. I have to go
do the stuff I was supposed to do today now. I don't know how you guys do
it :-).

> If we can do this and people
agree that my logic makes sense then I

> think we can mark off the synchronization requirements for CAP
as

> covered.

Not yet :-)

We're getting closer I think :-)

--

Mark Paterson

Director, Client R&D

Steltor

mailto:[email-masked]

http://www.steltor.com

---

From: Doug Royer <[email-masked]>
Date: Fri, 01 Feb 2002 14:39:13 -0700

Mark Paterson wrote:
 
> With respect to CAP-QL however perhaps a separate thread could be
> started since if I were a CUA developer I don't necessarily want to
> get every sequence and have to filter out the old stuff (seems like a
> lot of unnecessary byte count).
> 
> If am retrieving event data to populate say a week view then I think
> I'd go:
> 
> BEGIN:VQUERY
> EXPAND:TRUE
> This should get me all the booked and unbooked events for the week. As
> a CUA I shouldn't have to filter through the SEQUENCE for each event I
> get back. If so how do I change the query to just get the latest. I
> checked in draft 06 and the VQUERY examples do not hint that this is
> the case (then again they don't hint that it isn't) and nothing within
> the current CAP-QL threads has addressed this as far as I know.
> 
> Anyhow this does not effect whether CAP is OK with respect to sync so
> for now let's say they get filtered.

No - it gets everything you ask for in the VQUERY. 
If YOUR same CUA put the data there and did not do the filtering
before depositing it in the CS, then you get it back.
[PLUS I am going to reply to this in a separate post to explain more]

If ANOTHER CUA (or CUA-bot) put it there, then your CUA
needs to decide what to do with data - not the CS.

A CS should not do anything more that store and get iCalendar objects.
(You could have a CUA compiled into your CS that did smart things
 for you, but *that* or *those* features are still in a CUA).

> > > By enumerating through the
> That's what I said. Why are you disagreeing with me?

Okay - I must have misunderstood you.

> I think we agree.
> The UIDs are the same so the sync CUA recognizes them and therefore
> knows they aren't new, hence they should be handled as objects which
> have had changes to them.

Yes.

> We need to agree on the issues with respect to recurring entries next.
> 
> > >
> > > The EXPAND:TRUE line in the query should ensure that all new and
> This could be but I'm not sure this is actually specified anywhere
> within the CAP-QL text. Should I get the master event and its UID
> along with all its baby instances expanded out with their own
> RECURRENCE-ID or should I just get the instances falling within the
> range I've queried over?

You will get multiple objects. Each with the same UID, each
with a RECURRENCE-ID. The 'master' object will not be returned
as it is what was expanded.

If EXPAND=TRUE, then you will get only the ones that have
RECURRENCE-ID in the specified range - I think it is part
of the (#3) proposal I sent out. If not, I'll add it to
(#4) I am sending and checking in tonight.

> Also, do I really need to put EXPAND:TRUE? I put it there since I
> thought it was needed to get anything back since if it weren't
> expanded then their would be no DTSTART values falling with the range
> but I suppose you could also say that with EXPAND:FALSE that you'd
> still get back recurring entries that have changed with recurrence
> sets that would cause an instance to fall within your query range with
> the difference being in the results you get back you just have the
> master event with its UID and recurrence set unexpanded (no babies
> hanging on :-) ).

If EXPAND:FALSE then the 'master' object(s) are returned
and they are not expanded into multiple 'baby' instances.

If EXPAND:TRUE, then you do not get the 'master' object.
You get multiple instances, each with the same UID and 
a unique RECURRANCE-ID (and other properties may be different
between instances).

> > > The problem is still deleted instances. I don't think EXPAND:TRUE

> > So, if the EXPAND:FALSE object is marked METHOD:DELETE, then ALL
> When you say "the EXPAND:FALSE object" do just mean the VEVENT with
> its UID, recurence set, etc.. or do actually mean that it is
> expanded out (with RECURRENCE-IDs being assigned) and then from then
> on it is a VEVENT marked EXPAND:TRUE?

I meant that the VQUERY was done with EXPAND:FALSE, and you
get back an object marked METHOD:DELETE, then all of its instances
are also METHOD:DELETE.

If you were to VQUERY that same object with EXPAND=TRUE, you
will get X number of objects, each with METHOD:DELETE and
their RECURRANCE-ID.

> implication of querying with EXPAND:TRUE. Perhaps some explanatory
> text within the CAP-QL text is needed.

yes.

> hasn't yet been expanded then it hasn't been sync'd to your PDA,
> Phone, whatever yet so the fact that it now doesn't exist is fine. The
> other end never new about them. I'll try that one more time. If a Sync
> CUA uses EXPAND:TRUE in its queries (like I've done above) then
> EXPAND:FALSE objects (to use your term) couldn't yet have been sent to
> the device (or whatever you are synching with) so the fact that they
> now won't be is fine.

The 'EXPAND' parameter is not stored in the CS.
EXPAND is simply the way for the CUA to tell the CS that
it wants the CS to expand the 'master' object into
instances, or that it wants THE 'master' object(s).

> Yes I know. That's what my next paragraph says. That's my point. Once
> a recurring entry gets sync'd from then on if an instance is deleted
> using any method other then adding an EXDATE I can't think of a way to
> make query that ensures that the Sync CUA gets informed about the
> deleted instances which it previously sync'd.

The LAST-MODIFIED in the object will be updated. Or there
will be new objects with the same UID that have a newer LAST-MODIFIED
than your sync time. So the a VQUERY where LAST-MODIFED will return
them if they fall in the time range specified in the VQUERY.

> > > It will only work however if
> > > recurrence set is deleted. If they just redo the recurrence set
> My first query doesn't get me all the objects in the time range, it
> get's me all the entries within the time range which have changed.

Yes. All the objects in the time range you specified with
the given restrictions.

(a) If you replace DTSTART with RECURRANCE-ID and set EXPAND:TRUE
    you will get all instances that fall in the time range (modified
    or not).

(b) If you replace DTSART with LAST-MODIFIED, and EXPAND:TRUE,
    you will get ALL instances of any expanded 'master' object
    where the 'master' object has been modified within your time range.
    This *is* what you want because if the 'master' object is changed,
    it may effect all of its instances.

(c) If you make the QUERY:

	EXPAND:TRUE
	QUERY:SELECT * FROM VEVENT WHERE LAST-MODIFIED > ...last-sync

    You will get ALL instances that have been modified since your
    last sync time.

> There is a big difference. Anything the Sync CUA doesn't get, it
> assumes hasn't changed. There is no way of knowing that the reason it
> didn't get a recurring entry that used to have instances within this
> range is because it is gone. It just thinks it hasn't changed.

The CUA has the object, it gets the new objects with the updated
LAST-MODIFIED time, the difference between the two is the difference.

> When I say that it is impossible I should perhaps say it is not
> possible in the way that the Sync CUA really needs.

You have the old objects, you have the updated objects.
What else do you need?

> past, figure out which ones aught to cause an instance to fall within
> the range being queried for and then do a query to get them from the
> CS individually to check but this would be a lot of extra calls to the
> CS and depending on your Sync model perhaps not even possible.

Or as they will all have the SAME UID's as the original object,
just do one VQUERY for that (or  those) UID's and set EXPAND=TRUE.
The result will be the new object instances.

If you perform a VQUERY looking for LAST-MODIFIED after a specified
time, from the result set:

  - Delete from the CUA any that you have that did not come back.
  - Add any that the CUA does not have.
  - Update any where the data in the instance has changed.

> last time it initiated a sync. The Sync Server then asks the backend
> data store (the CAP CS in our world) for its changes since the last
> time a sync was done, it compares the two lists and sends each back
> instructions on what to change so that the two of them are good to go.

Sounds like a good proposal for an add on later draft to CAP.
It could be a predefined VQUERY, GET-WHAT-CHANGED with a 
parameter containing a date-time.

> The Sync Server does not have knowledge of the database on the device.
> In theory the SyncML protocol does have a search and get command so I
> guess the sync server could go back to the sync client and ask for the
> entries (but I've yet to see a SyncML client which implements these
> commands) but this flies in the face of the entire SyncML model. I'm
> sure the gang at the SyncML initiative would be horrified by my mere
> suggestion of this. The poor owner of the wireless device is paying by
> the second on a 2G network and by the packet on a 2.5G or 3G network
> so the extra trips back to the device will not be appreciated.

I think it can be done in one single VQUERY.

        EXPAND:TRUE
	QUERY:SELECT * FROM VEVENT
         WHERE LAST-MODIFIED >  ...last-sync-time...

OR if the CUA knows how to expand the objects - just VQUERY
with EXPAND:FALSE and get the fewer objects - and expand
the instances in the CUA code.

> > > 2. CUAs must use EXDATE to mark an instance within an existing
> which a Sync CUA could put together a set of queries and ensure that
> it gets told about deleted instances of recurring entries that it has
> previously sync'd.

I think I covered that above in this reply - do you agree?

> I'd love it if someone else could suggest a query that'll do it.
> Anyone? It's the only sticking point keeping us from closing this
> issue as far as I can tell and I want it closed. This is far too much
> work. I have to go do the stuff I was supposed to do today now. I
> don't know how you guys do it :-).

The LAST-MODIFIED in the 'master' object would have been updated,
so when your VQUERY is performed (with or without EXPAND=TRUE) the
result set will include those objects or instances that have changed
after the time specified. This will include METHOD:DELETE objects.

	It would include any:

	instances that have changed (updated LAST-MODIFIED)

	new objects (new/unknown UID, new LAST-MODIFED)

	object marked for delete (METHOD:DELETE, updated LAST-MODIFIED)

For iTIP objects, the same VQUERY will have returned in the result set:

	new instances (METHOD:ADD, new LAST-MODIFED)

	canceled objects (METHOD:CANCEL - new LAST-MODIFIED)

	canceled instances (METHOD:CANCEL with a RECURRANCE-ID property
			    and a new LAST-MODIFIED)

	updated objects (METHOD:REQUEST with new SEQUENCE,
		         updated LAST-MODIFIED)

	declined counter proposals (METHOD:DECLINE-COUNTER, 
                                    new LAST-MODIFIED)
	
And if your are the ORGANIZER it would also return any:

	counter proposals (METHOD:COUNTER, new LAST-MODIFIED)

Is anything missing?

---

From: Doug Royer <[email-masked]>
Date: Fri, 01 Feb 2002 14:57:43 -0700

Mark Paterson wrote:

> For the issue of sync I'll just say yes. If a CS is implemented in
> this fashion then yes this is what I meant. The Sync CUA should filter
> out everything out but the latest and greatest.

[broken out from separate and related thread]

Think of this from the iTIP perspective.

For an object where you are the ORGANIZER. You could
send and get in this order:

	send REQUEST , SEQUENCE 0
	you sync

	get REPLY, SEQUENCE 0, ATTENDEE A1
	get REPLY, SEQUENCE 0, ATTENDEE A2

	you sync.

	get COUNTER, SEQUENCE 0, ATTENDEE A3
	get REPLY, SEQUENCE 0, ATTENDEE A4

	you sync and accept the COUNTER
	send REQUEST, SEQUENCE 1

	get COUNTER SEQUENCE 0, ATTENDEE A5
	get REPLY, SEQUENCE 1, ATTENDEE A1
	get REPLY, SEQUENCE 1, ATTENDEE A3

	you sync.

As you can see, you have to keep the old SEQUENCE number
objects until the CUA has determined that all of the ATTENDEES
have performed a REPLY or COUNTER. If the CS were to delete all
SEQUENCE 0 objects, your CUA would not know which ATTENDEE is
participating as their PARTSTAT is only in their REPLY and what
SEQUENCE item they think they said YES or NO to.

And you would not know to send a DECLINE-COUNTER (or a
new REQUEST and updated SEQUENCE) in responce to ATTENDEE A5's
COUNTER object.

I am sure there are other reasons to keep old SEQUENCE
items until processed by a CUA.

These are NOT CAP issues, they are iTIP issues. And we should
not add this and other scenarios like this to CAP.

---

From: Mark Paterson <[email-masked]>
Date: Mon, 04 Feb 2002 10:53:18 -0500

At 02:39 PM 2/1/2002 -0700, you wrote:

I think it can be done in one
single VQUERY.

EXPAND:TRUE

QUERY:SELECT
* FROM VEVENT

WHERE LAST-MODIFIED
>  ...last-sync-time...

Yes this would do it but the difference between your query and mine is
that mine had a time range. Your query will give back everything that has
changed on the CS within the users agenda and not just those within a
specific time range. The Sync CUA may not care about new meetings that
have been booked 3 years out. The requirement for CAP reads as
follows...

"CAP MUST allow synchronization, meaning at a minimum that the CUA
is able to find and retrieve new, modified or deleted entries for a given
time period. The CUA MUST be able to find out which entries have been
added, modified or deleted since it last synchronized, in order to
operate in disconnected mode. This requirement may be satisfied using the
query requirements already defined."

The five words of importance "for a given time
period".

How does a Sync CUA find out about deleted instances of a recurring entry
that used to fall within a given time period but which have been deleted
since the last time a sync was performed without getting ALL the changes
on the CS and then doing its own time range filtering?

Perhaps something like this (once again I am simplifying things by just
using DTSTART and just worrying about VEVENTS)...

WHERE LAST-MODIFIED >  ...last-sync-time

AND DTSTART > bottom of time range

AND DTSTART < top of time range

AND RRULE="" (I'm trying to say not recurring. What's the
proper way of doing this is?)

followed by...

EXPAND:TRUE (or FALSE if the Sync CUA wants. It's not really CAP's
concern)

WHERE LAST-MODIFIED >  ...last-sync-time

AND RRULE=* (I'm trying to say recurring. What's the proper way of doing
this is?)

These two queries will give the Sync CUA all new, changed and deleted
non-recurring entries within a users calendar within a given time period
and will give the Sync CUA ALL new, changed, and deleted recurring
entries within a users calendar. This means that the Sync CUA may get
back more recurring entries then it actually needs but this would seem to
be a reasonable compromise. Statistically users would tend to have less
recurring entries in their calendar I think and they tend to change less
often then non-recurring entries so hopefully the extra overhead of the
Sync CUA getting recurring entries not actually within the given time
period would be kept to a minimum.

I suspect Sync solution implementors should be OK with this compromise as
well. Sync'ing recurring entries is difficult and a lot of solutions just
don't do it properly. Those that do just deal with them as one object
with their recurrence set and don't worry about expansion or if they do
sync them all every time since keeping track of what instances have been
sync'd in a range is just too confusing. So I don't think the compromise
I am proposing should really harm their implementations (lurkers on the
list thinking about implementing a sync solution against a CAP compliant
CS in the future may want to speak up now if you disagree).

If we can agree that this is sufficient then the following 2 things needs
to be done to put this issue to rest.

1) We still need some text within the CAP spec explaining that CAP CUAs
should delete things use METHOD MODIFY (as suggested by Doug in a
previous reply and seconded by me).

2) Either the CAP sync requirements should be updated  to reflect
what we can actually support or perhaps a section within the CAP Spec
could be added to explain how well it lives up to the requirments. As the
CAP Requirements document is an official document going back and changing
it would probably be a pain so my vote is for a small informational
section within the CAP spec.

--

Mark Paterson

Director, Client R&D

Steltor

mailto:[email-masked]

http://www.steltor.com

---

From: Doug Royer <[email-masked]>
Date: Mon, 04 Feb 2002 11:28:04 -0700

Mark Paterson wrote:
> that mine had a time range. Your query will give back everything that
> has changed on the CS within the users agenda and not just those
> within a specific time range. The Sync CUA may not care about new
> meetings that have been booked 3 years out. The requirement for CAP
> reads as follows...
>
> "CAP MUST allow synchronization, meaning at a minimum that the CUA is
> able to find and retrieve new, modified or deleted entries for a given
> operate in disconnected mode. This requirement may be satisfied using
> the query requirements already defined."

It was my belief that text meant that it needed to know about
changes since a time. What good is it to 1/2 sync? That is if
you only get 'changes' from yesterday and ignore changes
from two days ago? Here is why you don't want that:

	Jan. 1	you sync and everything is up to date.
	Jan. 10  your CS gets METHOD:CANCEL for objects in Feb.
	Feb. 1   you sync with a time range of Feb. 1- Feb. 28.

     You now missed the METHOD:CANCEL for the VEVENTS in Feb.
     and the results you get back are exactly what you asked for
     and bogus.

> The five words of importance "for a given time period".
> 
> How does a Sync CUA find out about deleted instances of a recurring
> entry that used to fall within a given time period but which have been
> deleted since the last time a sync was performed without getting ALL
> the changes on the CS and then doing its own time range filtering?

You don't mean 'deleted' you mean METHOD:CANCEL, and those
would show up with the above query I provided.

You can't 'delete' an instance, you can only METHOD:CANCEL
an instance. You can only delete an object, not instances
that only exist when the CS expands an object.

> Perhaps something like this (once again I am simplifying things by
> just using DTSTART and just worrying about VEVENTS)...
> 
> AND RRULE="" (I'm trying to say not recurring. What's the proper way
> of doing this is?)

"AND RRULE IS NULL" I think is what you are saying. But I don't
think that is what you want - see below.

> AND RRULE=* (I'm trying to say recurring. What's the proper way of
> doing this is?)

"RRULE IS NOT NULL" - Not what you really want.

Your above query would return instances of VEVENTs with an RRULE
(but not a RDATE, EXDATE, or EXRULE), within the given time range
that have changed since last-sync-time. Only instances in that
time range would be returned - and only if they changed after
last-sync-time.

This below would get all instances (with or without RRULE's) that
have changed since your last sync within a time range:

  BEGIN:VQUERY

  EXPAND:TRUE

  QUERY:SELECT * FROM VEVENT
   WHERE LAST-MODIFIED > ..last-sync-time AND METHOD != 'CREATE'

  QUERY:SELECT * FROM VEVENT
   WHERE DTSART > bottom of time range
   AND DTSTART < top of time range
   AND METHOD = 'CREATE'

  END:VQUERY

Above, the CS would EXPAND 'original' VEVENTs into instances,
and only return the ones that fall within the provided time range.
AND it would return any modified objects that might effect
the results. So you would now see the METHOD:CANCEL done
in January that effected the February objects.

ONLY a CUA combines objects, the CS does not, so the CS could
not 'know' that the January 10th object effected the February
objects in order to return them in the query.

A problem with your examples, is that they ignored RDATE,
EXDATE, and EXRULE. The CUA would have then had to calculate
those exceptions and additions from the result set.

> non-recurring entries within a users calendar within a given time
> period and will give the Sync CUA ALL new, changed, and deleted
> recurring entries within a users calendar. This means that the Sync
> CUA may get back more recurring entries then it actually needs but
> this would seem to be a reasonable compromise. Statistically users
> would tend to have less recurring entries in their calendar I think
> and they tend to change less often then non-recurring entries so
> hopefully the extra overhead of the Sync CUA getting recurring entries
> not actually within the given time period would be kept to a minimum.

Your query would have missed instances with a RDATE, and had
excessive instances that did not exists because of ignored
EXDATE and EXRULE. And because you specified a time range
in the same query based on DTSTART, you would missed any CANCEL
for objects or instances of those objects.

> I suspect Sync solution implementors should be OK with this compromise
> as well. Sync'ing recurring entries is difficult and a lot of
> solutions just don't do it properly. Those that do just deal with them
> as one object with their recurrence set and don't worry about
> expansion or if they do sync them all every time since keeping track
> of what instances have been sync'd in a range is just too confusing.
> So I don't think the compromise I am proposing should really harm
> their implementations (lurkers on the list thinking about implementing
> a sync solution against a CAP compliant CS in the future may want to
> speak up now if you disagree).
> 
> If we can agree that this is sufficient then the following 2 things
> needs to be done to put this issue to rest.
> 
> 1) We still need some text within the CAP spec explaining that CAP
> CUAs should delete things use METHOD MODIFY (as suggested by Doug in a

	(1) Mark them for delete with <modify>

	(2) Delete them with <delete>

	(3) Cancel entire object with METHOD:CANCEL
            and RECURRANCE-ID IS NULL

	(4) Cancel instances of object with METHOD:CANCEL
	    and RECURRANCE-ID IS NOT NULL.

With (3) and (4) currently being defiend by iTIP.

> 2) Either the CAP sync requirements should be updated  to reflect what
> we can actually support or perhaps a section within the CAP Spec could
> be added to explain how well it lives up to the requirments. As the
> CAP Requirements document is an official document going back and
> changing it would probably be a pain so my vote is for a small
> informational section within the CAP spec.

I agree we need more text in CAP. As part of the editors conference
call last week - I (I think it was me) agreed to write a proposal.

FYI - anyone is also allowed to propose text.

---

From: Mark Paterson <[email-masked]>
Date: Mon, 04 Feb 2002 17:33:37 -0500

At 11:28 AM 2/4/2002 -0700, you wrote:

Mark Paterson wrote:

EXPAND:TRUE

Jan.
1  you sync and everything is up to date.

Jan.
10  your CS gets METHOD:CANCEL for objects in Feb.

Feb.
1   you sync with a time range of Feb. 1- Feb. 28.

You now missed the METHOD:CANCEL for the VEVENTS
in Feb.

and the results you get back are exactly what
you asked for

and bogus.

Why have I missed it? If I ask for everything that has changed since Jan
1st which falls between Feb 1 and Feb 28th the objects within February
that have been deleted will get returned because their LAST-MODIFIED
attribute with be Jan 10th (greater than Jan 1) and their DTSTARTs fall
within the range. Are the meetings in February part of a recurring entry
in your example? If so, then yes they'd be missed which has been my point
all along that a query against LAST-MODIFIED with a time range catches
everything but instances of recurring entries that no longer exist. This
why in my last response I compromised and only used a time range when
querying for non-recurring entries and did not when querying for
recurring entries since I'll always have the chance of missing these if I
do.

Please note that above I mean the English word "deleted" and
not the CAP command so please don't correct me by telling me that I mean
the modify command updating the METHOD to CANCEL)  Note that in a
previous response you claimed the following...

"Entire objects are marked for delete by using METHOD:MODIFY

and changing the object in the store to METHOD:DELETE"

Here you say CANCEL. Which is it? Its the "delete" command
which zaps the whole object which we don't want CUAs to do and the
"modify" command with METHOD:DELETE (or CANCEL).

Yes I do mean deleted. I mean the English word deleted as in the instance
is no more and not the CAP command AND yes it would show up in your query
along with ever other change within the user's calendar but we were
trying to find a way to just get those changes within a given time
period. In my compromise I used your approach (with no time range) only
for recurring entries to cut down on the amount of unnecessary changes
being reported to the Sync CUA.

You can't 'delete' an instance, you
can only METHOD:CANCEL

I know that !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! From the Sync CUAs
perspective their is an instance that it no more and that is all I am
saying. The CUA which did the deletion should do so as you describe, yes,
we agreed to this several replies back.

> AND RRULE="" (I'm trying to say not recurring. What's the
proper way

> of doing this is?)

"AND RRULE IS NULL" I think is what you are saying. But I
don't

What I am saying is "I'm trying to say not recurring. What's the
proper way

of doing this is?". Exactly what's written in the parentheses. I'm
trying to express a query that gets all changes within a given time
period for all non recurring entries but I wasn't sure how to do so, so I
asked for your help.

(but not a RDATE, EXDATE, or EXRULE),

I know that. That's why in parentheses I state quite clearly "I'm
trying to say recurring. What's the proper way of doing this
is?"  In other words, Please help me with this query.

within the given time
range

I have no time range in this query. It follows your approach of no time
range since there seems to be no way of ensuring that the Sync CUA
catches instances that have been deleted (the English word deleted :-))
if you do. The only way to do it with a time range is if you could query
on something like an EXDATE but we've both agreed that forcing a CUA to
use an EXDATE to get rid of an instance is simply too
restrictive.

that have changed since
last-sync-time. Only instances in that

last-sync-time.

As stated above my 2nd query does not have a time range.

This below would get all instances
(with or without RRULE's) that

BEGIN:VQUERY

EXPAND:TRUE

WHERE LAST-MODIFIED > ..last-sync-time AND METHOD !=
'CREATE'

AND METHOD = 'CREATE'

END:VQUERY

Here's where we disagree and I think why we seem to think differently and
have trouble understanding each other's proposal. I'm going to reply to
this separately next (this reply is already too long).

A problem with your examples, is
that they ignored RDATE,

They did not ignore them. I simply didn't know how to express a query
which only returned recurring entries and was hoping that you make a
suggestion as to how it could be done.

> These two queries will give
the Sync CUA all new, changed and deleted

I think we've covered this. I didn't ignore EXDATE and EXRULE and my
second query had no time range.

> I suspect Sync solution
implementors should be OK with this compromise

> previous reply and seconded by me).

(1) Mark
them for delete with <modify>

(2) Delete
them with <delete>

(3) Cancel
entire object with METHOD:CANCEL

and
RECURRANCE-ID IS NULL

(4) Cancel
instances of object with METHOD:CANCEL

I'm not sure what this text is for? Is this what you want to put in CAP?
We don't want them to zap things with the delete command. You've lost
me.

> 2) Either the CAP sync
requirements should be updated  to reflect what

call last week - I (I think it was me) agreed to write a
proposal.

I would be willing to work with you on this but we first need to get on
the same page. Wait for my next reply before commenting. I'm pretty sure
I know why we don't really seem to understand each other's
ideas.

--

Mark Paterson

Director, Client R&D

Steltor

mailto:[email-masked]

http://www.steltor.com

---

From: Doug Royer <[email-masked]>
Date: Mon, 04 Feb 2002 16:37:02 -0700

Mark Paterson wrote:

> Why have I missed it? If I ask for everything that has changed since
> Jan 1st which falls between Feb 1 and Feb 28th the objects within
> February that have been deleted will get returned because their
> LAST-MODIFIED attribute with be Jan 10th (greater than Jan 1) and
> their DTSTARTs fall within the range.

No, the LAST-MODIFIED date for the METHOD:CREATE is Jan. 10.
And the CS 'does NOT know' how to merge iTIP objects - that
is the job of the CUA. Your original QUERY was (edited):

>   AND RRULE IS NULL

So as you used the 'AND' logical operator, any object would have
to match ALL three expressions, and the Jan-10 object would not
match all three.

> Are the meetings in February
> part of a recurring entry in your example? If so, then yes they'd be
> missed which has been my point all along that a query against
> LAST-MODIFIED with a time range catches everything but instances of
> recurring entries that no longer exist.

Only - CUA processed objects - the Jan-10 object has a LAST-MODIFIED
of Jan-10 and has not yet been processed/merged into modify object(s)
with METHOD:CREATE by the CUA. It does not match your query.

> This why in my last response I
> compromised and only used a time range when querying for non-recurring
> entries and did not when querying for recurring entries since I'll
> always have the chance of missing these if I do.
> 
> Please note that above I mean the English word "deleted" and not the
> CAP command so please don't correct me by telling me that I mean the
> modify command updating the METHOD to CANCEL)  Note that in a previous
> response you claimed the following...

There is NO SUCH THING as a 'deleted instance'. I have no idea
what you mean. 

> Here you say CANCEL. Which is it? Its the "delete" command which zaps
> the whole object which we don't want CUAs to do and the "modify"
> command with METHOD:DELETE (or CANCEL).

I was trying to find out if you meant:

	(a) An instance is CANCELED
or
	(b) An entire object was marked for delete (METHOD:DELETE).

> Yes I do mean deleted. I mean the English word deleted as in the
> instance is no more and not the CAP command AND yes it would show up
> in your query along with ever other change within the user's calendar
> but we were trying to find a way to just get those changes within a
> given time period. In my compromise I used your approach (with no time
> range) only for recurring entries to cut down on the amount of
> unnecessary changes being reported to the Sync CUA.

There is NO such thing in CAP as a DELETED instance.

Which do you mean - CANCELed instance or METHOD:DELETE of
the entire object  and it instances?

> saying. The CUA which did the deletion should do so as you describe,
> yes, we agreed to this several replies back.

But you did say: "How does a Sync CUA find out about deleted instances
                  of a recurring ..."

I was just trying to figure out which of the two you meant.

> entry 
> period for all non recurring entries but I wasn't sure how to do so,
> so I asked for your help.

There is NO way to do that in the CS. Because of 'METHOD:ADD' objects.
This is VALID in the CS:

	BEGIN:VEVENT
	METHOD:CREATE
	UID:<uid-1>
	...
	LOCATION:#1
	DTSTART: in-your-time-range-#1
	...
	END:VEVENT

-AND ALSO IN THE SAME VAGENDA-

	BEGIN:VEVENT
	METHOD:CREATE
	UID:<uid-1>
	...
	LOCATION:#2
	DTSTART: in-your-time-range-#2
	...
	END:VEVENT

The second object with THE SAME UID was created by METHOD:ADD.
As METHOD:ADD adds instances to an object. Nether contains RRULE,
RDATE, EXRULE, or EXDATE. Yet the VEVENT has recurring instances.
They CAN not be combined because the LOCATION property is not
the same.

There is no way to as the CS if there are multiple instances
of object without:

	(a) Asking the CS for all object EXPAND:FALSE and the
            CUA figuring it out.
or
	(b) Asking the CS for all objects EXPAND:TRUE and
            counting the objects per unique UID.

> trying to say recurring. What's the proper way of doing this is?"  In
> other words, Please help me with this query.

It was not clear to me, that is why this IETF process is so fun :-)

> > within the given time range
> 
> I have no time range in this query.

Yes you did (bottom of time range AND top of time range):

>   AND RRULE IS NULL

> It follows your approach of no
> time range since there seems to be no way of ensuring that the Sync
> CUA catches instances that have been deleted (the English word deleted
> :-)) if you do.

So to you mean instance CANCELed or object DELETEed ?
You can't delete an instance.

Which ever you mean is not true.

---

From: Mark Paterson <[email-masked]>
Date: Mon, 04 Feb 2002 21:22:20 -0500

2nd reply.

While putting together my first reply to this message it started to
become clear why Doug and I seem to be so far apart.  I thought of
scrapping the first reply all together and starting over but I still
wanted to point out where I felt what I had written was misinterpreted
such that my original reply could be reconsidered properly.

What I wrote should be coupled with what is in this reply as well to
fully understand things.

Let's look at Doug's example again...

Here is why you don't want
that:

Jan.

Jan.

Feb.

and bogus.

To start I think the example should read METHOD:DELETE and not
METHOD:CANCEL but either way how come I think for sure that I'll get back
the deleted object and Doug doesn't?

The problem lies in how we see objects within the CS and how we expect
VQUERY to react I suspect.

In my view of the world there is an up-to-date copy of the object in
February so when it gets deleted on Jan 10th its last modified time gets
updated to Jan 10, its METHOD becomes CANCEL, the DTSTART is still there,
and I suppose the SEQUENCE has been incremented. So if you apply the
following query to that vision of the world you'll be told about the
meeting in February which has been deleted.

WHERE LAST-MODIFIED > last-sync-time

AND DTSART > bottom of time range

Now let's look at it differently. Instead of there being an up-to-date
object there is an object with a DTSTART in February and a METHOD:CREATE
with a LAST_MODIFIED from perhaps December when the meeting was booked,
and a sequence of say 4. On top of this there is also an object (with the
same UID) with METHOD;DELETE and a LAST_MODIFIED time of Jan 10th and a
sequence of 5. In this vision of the world the query above will not tell
the Sync CUA about the deleted meeting in February.

Now let's take these two visions of the world and apply them to the
larger query which Doug suggested.

BEGIN:VQUERY

EXPAND:TRUE

AND METHOD = 'CREATE'

END:VQUERY

With my vision of the world this query just makes no sense whatsoever.
Why am I asking for this extra stuff?

But if you use the other vision you need to get all the booked entries
within your range along with all the changes. Then your Sync CUA needs to
go through all the changes and match them up with all the booked entries
within the range to see which ones need to be adjusted
accordingly.

If we consider a CAP CS as implemented in this fashion then I agree with
Doug that this is how a Sync CUA would have to figure out changes for a
specific time range.

Essentially the Sync CUA will have to do all the work as is indicated
below.

ONLY a CUA combines objects, the CS
does not, so the CS could

The problem with this is that it doesn't seem to live up to the CAP Sync
requirements as they are written.  A Sync CUA in the end has to
download all booked entries within a range along with all changes and
combine the objects (as described above) and figure out what's
changed.

If this is the case then I think Doug's suggestion from an earlier
response that their be a query such as this...

"a predefined VQUERY, GET-WHAT-CHANGED with a

parameter containing a date-time"

Doug suggested that it be an enhancement for a CAP update but if the only
current way for a Sync CUA to figure out changes is with the bigger query
above where it downloads everything and figures it out on its own then
I'd say it is needed now or NO, CAP does not live up to the Sync
requirements.

This however all hinges on how we expect a CS to react. In the first
example at the top of this email should my query return the deleted
meeting in February? Yes or No?

If the answer is YES (as I thought it would) then something close to the
queries I've been suggesting should take care of things for sync and
satisfy the CAP Sync requirements. If the answer is NO then my argument
above applies.

So which is it?

--

Mark Paterson

Director, Client R&D

Steltor

mailto:[email-masked]

http://www.steltor.com

---

From: Mark Paterson <[email-masked]>
Date: Tue, 05 Feb 2002 08:39:30 -0500

I asked for you to wait for my 2nd reply. I sent it earlier this morning
when I logged in. I think you'll be less frustrated reading it. I know
what you mean now. I don't necessarily agree but based on how you see
objects laid out within the CS (where only CUAs can combine them) I
understand what you are saying and agree your query would work the way
you are thinking.

I still can't figure out why you can't understand that when I write an
English sentence with the word "delete" that I just mean that a
user is sitting in front of his computer and he has his calendar up and
he has chosen to delete something. The user doesn't care how the CUA
actually goes about making the meeting go away. I just find it easier
when describing something at a conceptual level to just keep it in simple
English but I will try be more careful in the future and try to spell out
exactly what is happening in CAPese :-)

At 04:37 PM 2/4/2002 -0700, you wrote:

> >         Jan. 10
your CS gets METHOD:CANCEL for objects in Feb.

match all three.

> recurring entries that no longer exist.

Only - CUA processed objects - the Jan-10 object has a
LAST-MODIFIED

of Jan-10 and has not yet been processed/merged into modify
object(s)

what you mean.

> Here you say CANCEL. Which is it? Its the "delete" command
which zaps

(a) An
instance is CANCELED

or

(b) An
entire object was marked for delete (METHOD:DELETE).

period".

> > > How does a Sync CUA find out about deleted instances of
a

> > recurring

> > > entry that used to fall within a given time period but
which have

> > been

> > > deleted since the last time a sync was performed without
getting

> > ALL

> yes, we agreed to this several replies back.

But you did say: "How does a Sync CUA find out about deleted
instances

of a recurring ..."

> > > AND RRULE="" (I'm trying to say not recurring.
What's the proper

> > way

> so I asked for your help.

There is NO way to do that in the CS. Because of 'METHOD:ADD'
objects.

This is VALID in the CS:

BEGIN:VEVENT

METHOD:CREATE

UID:<uid-1>

...

LOCATION:#1

DTSTART:
in-your-time-range-#1

...

END:VEVENT

BEGIN:VEVENT

METHOD:CREATE

UID:<uid-1>

...

LOCATION:#2

DTSTART:
in-your-time-range-#2

...

END:VEVENT

the same.

of object without:

(a) Asking
the CS for all object EXPAND:FALSE and the

CUA
figuring it out.

or

(b) Asking
the CS for all objects EXPAND:TRUE and

> trying to say recurring. What's the proper way of doing this
is?"  In

> other words, Please help me with this query.

It was not clear to me, that is why this IETF process is so fun
:-)

--

Mark Paterson

Director, Client R&D

Steltor

mailto:[email-masked]

http://www.steltor.com

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Feb 2002 09:42:14 -0700

Mark Paterson wrote:

> February so when it gets deleted on Jan 10th its last modified time
> gets updated to Jan 10, its METHOD becomes CANCEL, the DTSTART is
> still there, and I suppose the SEQUENCE has been incremented. So if
> you apply the following query to that vision of the world you'll be
> told about the meeting in February which has been deleted.

More text that disappeared in 06. This was in 05 and it
has NOTHING todo with CAP tranaport and I can find any discussion
that should have caused it to be removed, I'll assume it was
an errror to remove it. It clearly describes the iTIP CANCEL
and how to use the new METHOD:DELETE. Again this is accidently
deleted text from 05 that we need to put back into CAP (+ BEEP
wrappers for it):

7.2.2.1 Reading Scheduling Components

   A CU might be invited to a meeting.  If the CU had been invited by
   CAP, the entry in the CU calendar will be scheduled, but not booked.
   So a CUA will need to look for scheduled entries in the calendar and
   present them to the CU or automaticly decide if the invitation is to
   be accepted or processed.

   Example:

   The little league coach places the teams entire schedule into your
   calendar.  Lets say that every game and practice is on a Friday night
   and your calendar now has this iTIP scheduling data:

               BEGIN:VCAP
               VERSION:2.0
               METHOD:PUBLISH
               BEGIN:VEVENT
               DTSTAMP;TZID=US/Pacific:20000229T180000
               DTSTART;TZID=US/Pacific:20000303T180000
               ORGANIZER:[email-masked]
               SUMMARY: Schedule of games and practice
               UID:[email-masked]
               SEQUENCE:0
               DESCRIPTION:Please have your child at the field
                and ready to play by 6pm.
               RRULE:FREQ=WEEKLY;COUNT=10
               END:VEVENT
               END:VCAP

   At this point the above VEVENT is not booked in your calendar, It is
   simply scheduled.  A CUA would fetch this and all other scheduled
   VEVENTs from your calendar with:

               C: SENDDATA
               C: Content-type:text/calendar; Method=READ;
Component=VQUERY
               C:
               C: BEGIN:VCAP
               C: VERSION:2.1
               C: BEGIN:VCOMMAND
               C: METHOD:READ
               C: CMDID:xyz12345
               C: TARGET:relcal2
               C: BEGIN:VQUERY
               C: QUERY:SELECT * WHERE FROM VEVENT METHOD != 'CREATE'
               C: END:VQUERY
               C: END:VCOMMAND
               C: END:VCAP
               C: .

   The the CUA and CU could determine which scheduling items were to
   remain on the calendar.  Each scheduling component could be deleted
   or updated with METHOD:MODIFY to change the METHOD from PUBLISH,
   REQUEST, REPLY, ADD, CANCEL, REFRESH, COUNTER, or DECLINE-COUNTER to
   what the CU and CUA had decided.

   In some cases the CUA could automaticly do the work and inform the
   CU.  An example of this is CANCEL.  If configured to process
   METHOD:CANCEL it could METHOD:DELETE the component an inform the CU
   that the booked component had been canceled.

   The CUA MUST process the scheduled components in the order sent.
   Some optimization could be done by the CUA.  One example is if a
   PUBLISH and later a CANCEL for the same component with the same
   SEQUENCE number were scheduled, but not booked.  The CUA might never
   inform the CU and treat it as if the PUBLISH had never been received
   by doing a METHOD:DELETE on both entries.

   It is important to note that scheduled components do not show up in
   busy time as BUSY.  Only when they are booked does the TRANSP:OPAQUE
   property take effect.  A CS implementation MAY mark the time as
   TENTATIVE.  This is an implementation and administrative choice.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 05 Feb 2002 13:04:28 -0500

> 7.2.2.1 Reading Scheduling Components

Doug,

This text is present in ALL versions of draft 06.

Official Draft 06 available from IETF:

  http://search.ietf.org/internet-drafts/draft-ietf-calsch-cap-06.txt

Latest interim version available at calsch.org:

  http://calsch.org/ietf/cap.txt

> 6.3.2 Processing Scheduling Components
> 
>    present them to the CU or automatically decide if the invitation is
>    to be accepted or processed.

Perhaps you've deleted this text accidentally
in your own copy of draft 06?  :-)

Regards,
Bernard
-- 
Bernard Desruisseaux                    mailto:[email-masked]
Research & Development                  Tel.  : +1 514 733-8500 x4213
Steltor                                 Fax   : +1 514 733-8878

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Feb 2002 12:45:14 -0700

> This text is present in ALL versions of draft 06.

Look closer - the text was changed and it changed not
only the transport data - but what was done.

The old text specified that the data is deleted from
the CS and that the entire object may be METHOD:DELETE
(not CANCAL as you have said).

> in your own copy of draft 06?  :-)

No - the meaning of what was done was also changed.

---

From: Bernard Desruisseaux <[email-masked]>
Date: Tue, 05 Feb 2002 16:25:11 -0500

Doug Royer wrote:
> > > More text that disappeared in 06.
> >
> > Doug,
> >

Perhaps, and thank you for bringing this to the
attention of the list.

On the other hand, you shouldn't claim that some
text has disappeared when it has only changed.

Regards,
Bernard

---

From: Doug Royer <[email-masked]>
Date: Tue, 05 Feb 2002 15:40:10 -0700

> text has disappeared when it has only changed.

I was trying to be polite. Is what I really should
have said is that someone got too happy with the text editor :-)