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

From: Andrea Campi <[email-masked]>
Date: Thu, 23 Jan 2003 17:35:04 +0100

On Wed, Jan 22, 2003 at 03:46:14PM -0500, [email-masked] wrote:
> iCalendar, iTIP and iMIP are not ordered.  Why MUST my CS return responses 
> in a particular order?   It sounds like someone wants to cut corners by 

By the way, this same argument holds for VQUERY with multiple QUERY
properties: see 6.1.1 item 5.

OTOH and for completeness sake: we can't take your argument to the
extreme, in some cases we do need to mandate ordering. See results
for CREATE - if results aren't in the same order as the components,
the CUA won't be able to correlate them.

[[
Either that, or we disallow creating more than one component at a time.
Not that this would be a bad idea, given the lack of transaction
and all. This would make our discussion about partial failure moot -
if you need to create different components, send them as separate
commands, even if in the same mime container... But I digress.
]]

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A. - BT Ignite                  http://www.inet.it
Technical Dept. - R&D			  phone: +39 02 32863 ext 1
v. Darwin, 85 - I-20019			  fax: +39 02 32863 ext 7705
Settimo Milanese (MI), Italy

---

From: [email-masked]
Date: Mon, 27 Jan 2003 14:26:12 -0500

> properties: see 6.1.1 item 5.

Yes, thanks you. 

> the CUA won't be able to correlate them.

Huh??  Sure it can.  From the draft-10 12-Jan-2003:

In the following example two new top level "VAGENDA" components are 
created. [Snip, snip]

C: Content-Type: text/calendar
C:
C: BEGIN:VCALENDAR
C: PRODID:-//someone's prodid
C: VERSION:2.0
C: CMD;ID=creation01:CREATE
C: TARGET:cal.example.com
C: BEGIN:VAGENDA                 <- data for 1st new calendar
C: CALID:relcalz1
C: NAME;LANGUAGE=en_US:Bill's Soccer Team
C: OWNER:bill
C: CALMASTER:mailto:[email-masked]
C: TZID:US/Pacific
C: END:VAGENDA
C: BEGIN:VAGENDA                 <- data for 2nd new calendar
C: CALID:relcalz2
C: NAME;LANGUAGE=EN-us:Mary's personal calendar
C: OWNER:mary
C: CALMASTER:mailto:[email-masked]
C: TZID:US/Pacific
C: END:VAGENDA
C: END:VCALENDAR

[Snip, snip]

S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0 
S: PRODID:-//someone's prodid
S: CMD;ID=creation01:REPLY
S: TARGET:cal.example.com
S: BEGIN:VREPLY                    <- Reply for 1st calendar create
S: CALID:relcalz1
S: REQUEST-STATUS:2.0
S: END:REPLY
S: BEGIN:VREPLY                    <- Reply for 2nd calendar create
S: CALID:relcalz2
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: END:VCALENDAR

In this case, the CALID's are in separate VREPLYs that can easily be used 
by the CUA to match up the reponse.  The CS could just as easily have 
returned:

S: Content-Type: text/calendar
S:
S: BEGIN:VCALENDAR
S: VERSION:2.0 
S: PRODID:-//someone's prodid
S: CMD;ID=creation01:REPLY
S: TARGET:cal.example.com
S: BEGIN:VREPLY                    <- Reply for 2nd calendar create
S: CALID:relcalz2
S: REQUEST-STATUS:2.0
S: END:VREPLY
S: BEGIN:VREPLY                    <- Reply for 1st calendar create
S: CALID:relcalz1
S: REQUEST-STATUS:2.0
S: END:REPLY
S: END:VCALENDAR

and there is NO difference. I see no justification for the text inbetween 
the request and reply that I cut out that claims:

When there are multiple "TARGET" properties in the original command object 
then the replies MUST BE in the exact same order as they were provided to 
the CS. The same is true for the objects created, their responses MUST BE 
in the exact same order as they were supplied to the CS. 

since the CUA can simply use the CALIDs to match responses with the 
matching request.  The same goes for the creation of entries w/in the 
VAGENDAs.  There is ALWAYS info in the VREPLY to match the reply up with 
the command and the right target.  Thats _exactly_  how the create-vreply 
is crafted in the draft:

create-vreply  = "BEGIN" ":" "VREPLY" CRLF
                 created-id
                 request-status
                 other-props
                 "END" ":" "VREPLY" CRLF

               ; Where the id is appropriate for the 
               ; type of object created:
               ;
               ; VAGENDA = calid
               ; VCAR = carid
               ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid
               ; VQUERY = queryid
               ; x-component = x-id
               ;

so that the proper id can be matched up w/the proper objects.  Given the 
TARGET info from the VCALENDAR and the info in the VREPLY matching is 
pretty straight forward unless Im missing something.  If Im not then why 
is ordering important? 

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: Andrea Campi <[email-masked]>
Date: Wed, 29 Jan 2003 18:06:00 +0100

> Huh??  Sure it can.  From the draft-10 12-Jan-2003:

Sorry, you're right. I was thinking of the MUST from the draft.

So basically, there's no need for ordering anywhere, right? I'm
all for removing the requirement then.

But let me insist: we need to clarify how should multiple VQUERY
(or multiple QUERY properties) behave. There is more to this than
SEARCH, since VQUERY are used all over. In addition to the basic
question (that I think I've asked many times), there's the issue
of the same component matching more than once.

Example:

BEGIN:VCOMPONENT
CMD:DELETE
BEGIN:VQUERY
QUERY:SELECT * FROM VEVENT WHERE DTSTART > '20030101'
END:VQUERY
BEGIN:VQUERY
QUERY:SELECT * FROM VEVENT WHERE LOCATION = 'Milan, Italy'
END:VQUERY
END:VCOMPONENT

Should this return:

1 - all results for both in one VREPLY

BEGIN:VCOMPONENT
BEGIN:VREPLY
UID:....
UID:....
END:VREPLY
END:VCOMPONENT

2 - one VREPLY per query

BEGIN:VCOMPONENT
BEGIN:VREPLY
UID:....
...
END:VREPLY
BEGIN:VREPLY
UID:....
...
END:VREPLY
END:VCOMPONENT

3 - one VCALENDAR per query

BEGIN:VCOMPONENT
BEGIN:VREPLY
UID:....
...
END:VREPLY
END:VCOMPONENT
BEGIN:VCOMPONENT
BEGIN:VREPLY
UID:....
...
END:VREPLY
END:VCOMPONENT

4 - undefined

Now what happens if the query matched the same component? Do we
return it in both replies or in one (which one)?

That's my main reason for choosing #1. After all, if we wanted to
separate the answers, we wouldn't send them in one query, right?

Bye,
	Andrea

---

From: [email-masked]
Date: Thu, 30 Jan 2003 14:41:24 -0500

> all for removing the requirement then.

Anyone not agree??

> (or multiple QUERY properties) behave. 

A very good idea but I thought it was covered (in the non-overlapping 
cases) in Subsections 6.1.1.[15-18].  Although as I revisit this area I 
see that no text clearly indicates the kind for responses that would be 
generated for the example querys.  I could guess at the responses given 
the text under the DELETE command (see next bits).

>                                         There is more to this than

There is text for the DELETE command already and I think thats what you 
had in mind at one point:

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

So if Im deleting multiple VEVENTs or VTODOs then I should get back 1 
delete-vreply per deleted entry.  They can be in all in 1 delete-reply OR 
in any number of delete-replys (as long as there is at least 1 
delete-vreply in each delete-reply). 

I havent spent a lot of cycles on it but why can't this apply to all 
commands too?  A spot check of a couple other commands reveals no similar 
text for them.  Perhaps thats what we need...

> QUERY:SELECT * FROM VEVENT WHERE LOCATION = 'Milan, Italy'

Ok, this effectively does 2 sets of DELETEs in 1 transaction.  Not sure 
that this is a normal CU action but its possible (though I am curious to 
see what UI can manage this cleanly) given our current design.  The design 
also permits 2 VQUERYs that select from different components (ie: the 1st 
is VEVENT and the 2nd could be for VTODOs).  What a tangled web we 
weave...

> 1 - all results for both in one VREPLY

Not cool.  There should not be 2 UID properties in a single VREPLY 
component.  This also violates the cited text above.

> 2 - one VREPLY per query

Better in that no duplicate UIDs happen.   It also violates the cited text 
above.

> 3 - one VCALENDAR per query

Overload...  Ugh!

> 4 - undefined

Not cool either.

What happend to just getting back 1 delete-vreply (VREPLY) per matching 
entry?  These VREPLYs can be in any number of VCALENDARsn as long as there 
is at least 1 VREPLY  per VCALENDAR.  This does NOT preclude sending back 
ALL the VREPLYs in 1 VCALENDAR.  There is also nothing in the draft that 
prevents sending back 1 VREPLY per VCALENDAR and sending back 1 per 
matching entry.  Recheck the ABNF for delete-reply.

> return it in both replies or in one (which one)?

IMHO: The responses should (MUST?) be per unique matching entity. 

One could say that its dependent on the internal CS design on how 
operations are sequenced.  If the deletes happened serially then there is 
no way for the 2nd to 'reDELETE' a match from the first set is there?  If 
they happen concurrently then its possible that you'd get back 2 VREPLYs 
that indicate deletion (unless you actually semaphored your container pool 
so that you dont get contention issues!!  Hint, hint...).  However 
concurrent operations on the same data set can be dangerous (esp. if the 
operations are different like DELETE and MODIFY) so Id guess that most CS 
implementations would serialize them.  Still, its kinda dumb in my mind to 
indicate that something got deleted twice (or more really) by a single 
command...

My preference is that we get back 1 XXX-reply per unique affected 
component so 1 delete-vreply per UID in the case of of the DELETE command 
no matter how many VQUERYs or QUERYs match it. 

I have a mild aversion to the idea of returning multiple delete-vreplys 
per matching entity because it serves no purpose to tell the CUA "I 
deleted the VEVENT with UID:EVENT1.  Oh yeah, I deleted the VEVENT with 
UID:EVENT1 (again)."  Does it serve any real purpose?  You really cant 
doubly delete it can you?

Try changing the command to be a another command like, say, SEARCH and see 
if the logic still holds.  The CUA asked for VEVENTs that match a couple 
sets of criteria.  Would it make any sense to return 2 copies of the same 
VEVENT??  I dont think so.

> That's my main reason for choosing #1. 

I dont like your #1 because it does not conform to current practices of a 
single UID per component.   Besides, your #1 does not address the "issue 
of the same component matching more than once."

>                                         After all, if we wanted to

I still wonder how realistic this example is but it is possible...

I think that if we restrict the XXX-reply responses to be per unique 
matching entity no matter the command then that should answer your 
questions.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 30 Jan 2003 13:28:54 -0700

> of the same component matching more than once.

As we are not doing transactions there can not be more than
one match in your example provided. Once it is deleted by the 1st QUERY
it could not have existed for the 2nd QUERY to match. (no matter
which one of them you process 1st).

And even with transactions it will not be possible to delete
the same item more than once so it would not be listed
more than once.

The above facts are valid no matter what kind of database
your CS uses.

Had the 2nd query specifically listed a UID that was deleted by
the 1st, then the 2nd would return an error.

For QUERYs that are not deletes I would say return each VREPLY
that matches the supplied QUERY value.

-- 

  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: Andrea Campi <[email-masked]>
Date: Fri, 31 Jan 2003 09:02:58 +0100

> had in mind at one point:

Sorry no, I thought I'd voiced my concern so many that it would be clear.
This is the text I have in mind:

   5.  When multiple "QUERY" properties are supplied in a single
       "VQUERY" component, the results returned are the same as the
       results returned for multiple "VQUERY" components having each a
       single "QUERY" property and the results are return in the same
       order as the "VQUERY" properties were specified in the original
       command.

Right now, I have no idea what:

                           the results returned are the same as the
       results returned for multiple "VQUERY" components having each a
       single "QUERY" property

because we haven't defined that yet (or agreed upon it, for that matter).
My reading of it was that it added a requirement for keeping results for
different QUERY separater (otherwise how could you possibly order them?)

And there's still a mention to ordering, which I'd like to get removed.

> deleted or marked for delete. 

Uhm yes sorry I overlooked that (maybe because SEARCH doesn't behave like
that: all commands return one match per VREPLY, apart from SEARCH where
it's not clear); but I think I got it right in the code ;-)

> matching entry.  Recheck the ABNF for delete-reply.

I think we agree then. So what about we change the text I quoted to:

   5.  When multiple "QUERY" properties are supplied in a single
       "VQUERY" component, the results are returned just like they
       were matches for a single "VQUERY" component having a single
       "QUERY" property.
       When multiple "VQUERY" componentns are supplied, the results
       are returned just like they were matches for a single "VQUERY"
       component having a single "QUERY" property.

Is that fine with you?

> IMHO: The responses should (MUST?) be per unique matching entity. 
[...]
> doubly delete it can you?

I agree. Now can you show me where in the text is that stated?

> VEVENT??  I dont think so.

Aha! Now you're really seeing my point! Look it might be that I'm being
silly, but I really interpreted the above text as allowing, nah, mandating
that we return 2 copies if they are matched from separate queries.

So just to make sure we agree. From a high level point of view, we basically:
 - for each TARGET:
   - merge all results from all the QUERYs, keeping only 1 copy of each
   - if CMD != SEARCH act on them
   - send them back. SEARCH defines the order in which we need to send results
     back, the other commands return results in undefined order.

OK?

Bye,
	Andrea