On Mon, Jan 27, 2003 at 02:26:12PM -0500, Bruce_Kahn@xxxxxxxxxxxxxxxx wrote:
Andrea replied on 01/23/2003 11:35:04 AM:
By the way, this same argument holds for VQUERY with multiple QUERY properties: see 6.1.1 item 5.
Yes, thanks you.
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.
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.
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
-------------------------------|-----------------------------
Doug@xxxxxxxxx | Office: (208)612-INET
http://Royer.com/People/Doug | Fax: (866)594-8574
| Cell: (208)520-4044Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature