Subject: Re: CAP 10: CREATE Command and ordering of responses.

From: [email-masked]
Date: Fri, 21 Feb 2003 12:18:53 -0500

I replied on 02/20/2003 05:56:20 PM
> > The reason multiple QUERYs were added was so that you could get all 
BOOKED
> > entries for a date range and all UNPROCESSED entries in one round 
trip.
> >   ~Something~ like:
> > 
> >    QUERY:SELECT * FROM VAGENDA WHERE <...date range...>
> >           AND STATE() == 'BOOKED'
> >    QUERY:SELECT * FROM VAGENDA WHERE STATE == 'UNPROCESSED'
> > 
> > It avoided two round trips for what was thought to be
> > a common 1st query after authentication.
> 
> If I can craft the EXACT same logical query using: 
> 
> BEGIN:VQUERY 
> QUERY:SELECT * FROM VAGENDA WHERE <...date range...> AND STATE() == 
'BOOKED'
> END:VQUERY 
> BEGIN:VQUERY 
> QUERY:SELECT * FROM VAGENDA WHERE STATE == 'UNPROCESSED'
> END:VQUERY 
> 
> with no apparent justification for this then I call this 
> overengineering it.   Lets simplify the design to avoid "Well I did 
> it this way only since the spec says I can.  I dont care if you only
> designed your product to do it only another way! kinds of 
> discussions we will eventually run into otherwise. 

I should note here that I do NOT disagree w/Dougs described case; it is 
prefectly normal and reasonable.  However it does not factor in that the 
data set of results does NOT overlap.  The current draft has no mention on 
the the sole expected behaviour is for the case where QUERYs result in 
overlapping results.  This is what Andrea and I have been trying to point 
out as needing some more polish.

All we want is there to be some explicit description for the behaviour 
when the results do overlap so we get consistant results no matter the 
implementation.  There, I hope that clarifies the issue.  Now I still 
think that my suggestion of returning 1 result per matching unique entry 
is the way to go.  Is there another way to achieve the same clarity?  Im 
all ears...

Bruce 
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Feb 2003 11:39:35 -0700

It overlaps exactly the same as if two commands have been
each done separately - in the case of delete it can not
overlap because the 1st would have already deleted any overlaps.
Correct?

[email-masked] wrote:

-- 

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

                 We Do Standards - You Need Standards

---

From: [email-masked]
Date: Fri, 21 Feb 2003 15:54:46 -0500

> overlap because the 1st would have already deleted any overlaps.

Not true for the DELETE command.  Ok, back to the "All VEVENTS last week" 
AND "VEVENT with UID:12345@QWERTY" case for this.  Ordering here can and 
will produce DIFFERENT results in the DELETE command:

If the "All VEVENTs last week" deletion is done first then there will be a 
delete-vreply with UID:12345@QWERTY in it and a REQUEST-STATUS:2.0;The 
events gone! property as well so the CUA can see that it was deleted.  So 
when the "VEVENT with UID:12345@QWERTY" deletion is tried there will be a 
delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:5.x;No such 
entry! property in it.  Hence the CUA gets 2 delete-vreplys for the _same_ 
UID; one a success and one a failure.
If the  "VEVENT with UID:12345@QWERTY" deletion is tried there will be a 
delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:2.0;The events 
gone! property as well so the CUA can see that it was deleted.  So when 
the  "All VEVENTs last week" deletion is done next there would be no 
additional delete-vreply to send back since the VEVENT was already removed 
and thus not part of the "last week" set.  Hence the CUA gets 1 
delete-vreply for the UID; one success and NO failures.

Thus ordering here can result in mixed messages to the CUA. 

If the QUERYs did NOT overlap (as in _your_ example) then there is no 
problem since there would be no duplication of responses.  However when 
there is overlap we need to have a clear and concise definition for how 
the processor is to proceed.

If the result sets are combined into 1 total set for processing instead of 
treated as separate actions (since they came on the SAME command its NOT 
the same scneario as if they were issued separately!) then we would get 
back 1 response per matching entry (ie: VEVENT above) and there would be 
no confusion or ambiguity.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 21 Feb 2003 14:55:58 -0700

I still do not follow your point.

In a calendar:

			VEVENT 1
			========
			UID:1
			SUMMARY:ABC

			VEVENT 2
			========
			UID:2
			SUMMARY:ABC

If you issue a DELETE with:

		QUERY:SELECT * FROM VAGENDA WHERE SUMMARY = 'ABC';

Both UID 1 and UID 2 get deleted - agree?

If you were instead had issued as SEPARATE commands:

		QUERY:SELECT * FROM VAGENDA WHERE SUMMARY LIKE 'A%'

Then later:
		QUERY:SELECT * FROM VAGENDA WHERE SUMMARY LIKE '%C'

The 1st query would have deleted both.
The 2nd query would have not deleted anything.
You would get UID:1 and UID:2 listed in the first response.

The 2nd response would be empty - no overlap. Just the same as
if you had issued the two queries in the same command.

Do you agree?

Now, instead of DELETE subsitute SEARCH:

The 1st query would have returned both UID:1 and UID:2
The 2nd query would have returned both UID:1 and UID:2

They overlap - agree?

--

---

From: [email-masked]
Date: Mon, 24 Feb 2003 11:27:29 -0500

> Both UID 1 and UID 2 get deleted - agree?

Yup.

> The 2nd query would have not deleted anything.
[Snip]
> Do you agree?

Yes.

The first query would result in 2 delete-vreplys being sent back; both 
with REQUEST-STATUS;2.0 on them and each with the proper UIDs. 

The second query would result in 1 delete-vreply being sent back; most 
likely with a REQUEST-STATUS;4.x;No matches found and NO UIDs.  Actually I 
think it is NOT currently doable given the current DELETE ABNF in the 
17Feb2003 Draft:

delete-reply   = "BEGIN" ":" "VCALENDAR" CRLF
                 calprops   ; MUST include 'reply-cmd'
                 1*(delete-vreply)
                 "END" ":" "VCALENDAR" CRLF

delete-vreply  = "BEGIN" ":" "VREPLY" CRLF
                 deleted-id
                 request-status
                 "END" ":" "VREPLY" CRLF

                ; Where the id is appropriate for the 
                ; type of object deleted:
                ;
                ; VAGENDA = calid
                ; VCAR = carid
                ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid
                ; VQUERY = queryid
                ; ALARM = sequence
                ; VTIMEZONE = tzid
                ; x-component = x-id
                ; An instance = uid recurid
                ;
deleted-id    = ( calid / carid / uid / uid recurid
               / queryid / tzid / sequence / x-id )

As you will note, the deleted-id MUST be in the delete-vreply but there 
are NONE to return in the case where none match.  So I think we found a 
flaw in the ABNF.  The ABNF needs to be amended so that its permissable to 
return a REQUEST-STATUS but NO deleted-id for those cases where none 
match!!  Better add this to the CAP issues list before we forget it.

The above was done on separate DELETE commands.  The ordering of querys in 
the SAME command would probably have the same results.

However you did not address my cases where it can be shown that the 
ordering of the querys in the SAME command WILL generate different and 
conflicting results.

Your cases are generic enough because they deal with pools of entries 
rather than pools and specific entries.  My example of "All events last 
week" and "VEVENT with UID:12345@QWERTY" is 100% legal and it deals with 
the case where the 2nd querys delete-vreply WOULD have a UID on it to 
match it to my QUERYs SELECT information. 

For this kind of case we can potentially get mulitple delete-vreplys for 
the same UID in the _SAME_ command with _different_ REQUEST-STATUSs.  So 
what is the CUA to make of that?? 

This is why I think we need to simplify the approach as I already 
described.  That way we do not generate potentially conflicting 
information on the SAME command.

Lets revisit my case of the "All VEVENTS last week" AND "VEVENT with 
UID:12345@QWERTY" to also look at the separate command case too.

First, the ordering here can and will produce DIFFERENT results in a 
single DELETE command: 

1.      If the "All VEVENTs last week" deletion is done first then there 
will be a delete-vreply with UID:12345@QWERTY in it and a 
REQUEST-STATUS:2.0;The events gone! property as well so the CUA can see 
that it was deleted.  So when the "VEVENT with UID:12345@QWERTY" deletion 
is tried there will be a delete-vreply with UID:12345@QWERTY and a 
REQUEST-STATUS:5.x;No such entry! property in it.  Hence the CUA gets 2 
delete-vreplys for the _same_ UID; one a success and one a failure. 
2.      If the  "VEVENT with UID:12345@QWERTY" deletion is tried there 
will be a delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:2.0;The 
events gone! property as well so the CUA can see that it was deleted.  So 
when the  "All VEVENTs last week" deletion is done next there would be no 
additional delete-vreply to send back since the VEVENT was already removed 
and thus not part of the "last week" set.  Hence the CUA gets 1 
delete-vreply for the UID; one success and NO failures.

Thus ordering here can result in mixed messages to the CUA.   Right?

If the 2 were done in separate DELETE commands the results would be as 
follows:

If the "All VEVENTs last week" deletion is done first , there will be a 
delete-vreply with UID:12345@QWERTY in it and a "REQUEST-STATUS:2.0;The 
events gone!" property so the CUA can see that it was deleted.   Then if 
the CUA decided to ignore the fact that it just got a  delete-vreply for 
UID:12345@QWERTY it could just blindly try to expressly DELETE it.  For 
that separate DELETE command it would get back a separate delete-verply 
with UID:12345@QWERTY and a REQUEST-STATUS:5.x;No such entry! property in 
it.  As such it got back 2.0 on one attempt and 5.x on another; NO 
conflicting information really (just a dumb CUA to try and reDELETE 
something it was just told was DELETEd!

If the  "VEVENT with UID:12345@QWERTY" deletion is done first there will 
be a delete-vreply with UID:12345@QWERTY and a REQUEST-STATUS:2.0;The 
events gone! property so the CUA can see that it was deleted.   When the 
"All VEVENTs last week" deletion is tried later there would be no 
delete-vreply with UID:12345@QWERTY in it since the VEVENT was already 
removed.  The CUA again does NOT percieve a conflict as it did not get 
back a "Could not DELETE UID:12345@QWERTY" response in the latter case as 
it was not there to delete nor would there be any way to SELECT it from 
the pool of existing VEVENTs. 

So by looking at the cases of sequencing of multiple QUERYs within a 
_single_ it can be demonstrated that ordering WILL result in conflicting 
result information in some cases when done on the SAME command.

Did I miss anything that would make my example analysis wrong?

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 24 Feb 2003 10:16:59 -0700

[email-masked] wrote:

> flaw in the ABNF.  The ABNF needs to be amended so that its permissable 
> to return a REQUEST-STATUS but NO deleted-id for those cases where none 

I edited the text, I added the last sentence in the following paragraph
and changed '1*(delete-vreply)' to '*(delete-vreply)' in the ABNF.

  When components are deleted, only the top most component
  "REQUEST-STATUS" properties are returned. No "REQUEST-STATUS"
  properties are returned for components inside of the selected
  components. There MUST BE one "VREPLY" component returned for
  each object that is deleted or marked for delete.
  Note that if there are no "VREPLY" components then nothing
  matched and nothing was deleted.

  ...

                    *(delete-vreply)

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 24 Feb 2003 10:22:53 -0700

[email-masked] wrote:

> The above was done on separate DELETE commands.  The ordering of querys 
> in the SAME command would probably have the same results.

No matter which order they were sent, no matter of they were
sent in one or two commands. You can NEVER delete the same UID twice.

> ordering of the querys in the SAME command WILL generate different and 

You can NEVER delete the same UID twice.

> what is the CUA to make of that??  

You can NEVER delete the same UID twice no matter how complex
the query. It does not say find everything that matches. It says:

	"...There MUST BE one "VREPLY" component returned for
	each object that is deleted or marked for delete. ..."

It does not say that if your query matches the same UID multiple
times return the SAME UID multiple times.

--