Re: CAP-12-a: 9.6 VQUERY Component - QUERYID/NAME
| Newsgroups | gmane.ietf.calendar |
|---|---|
| Message-ID | <OFAFB52A56.7E736B6D-ON85256D97.00765EB6-85256D97.0078A9B8@notesdev.ibm.com> |
Doug replied on 09/04/2003 01:51:35 PM: > (1) Bruce - please read all of CAP - not just the diffs. Doug - please post a summary of the changes between versions instead of saying "do the diffs yourself" (paraphrased). I did and now you say, go read the drafts!? Sorry but Im NOT going to reread ~140 pages every time a new draft is reissued since by now there should not be lots of changes going in. Its a typical editors task to provide a summary of the changes, not say "do the diffs yourself" (paraphrased; you're welcome by the way) and then complain in the next posting that Im actually doing that. > (2) You can search for any component by ANY property value. > Are you proposing that we limit searching of VQUERYs to > be less than other components? How the heck did you get that from either my proposal to remove all references to stored queries OR to my comment about NAME being incorrectly used in finding the a particular stored query in a particular TARGET? This is totally a nonsequitor. > > Even if it was suggested, there is NO prose in CAP _now_ for when NAME > > is used, how it is to be used or when it is NOT used in conjunction > > with QUERYID in a VQUERY. If (and thats a big if) the WG decides to > > use NAME in addition to QUERYID as part of VQUERY location then issues > > like dealing with specifying localization code pages used, etc need to > > be answered. > > (1) Did you bother to read section 8.23? In fact I did. Section 8.23 NAME Property says NOTHING about using NAME as part of any criteria for identifying queries. Actually it does not matter now that you've said you will revise the questionable text in Section 9.6 VQUERY Component it doesn't really matter but Im still interested in what I missed. > (2) You can search for any component by ANY property value. > Are you proposing that we limit searching of VQUERYs to > be less than other components? Ahh, I think I see now; you have confused SEARCHing with the act of finding a particular stored query in a particular TARGET that I cited and have been referring to. I have been referring to the questionable text in Section 9.6 VQUERY Component that said that "NAME" was used "when looking for a correct stored "VQUERY" component" and you have incorrectly extended this to all SEARCHing based on the NAME property. > By your removal and (so far) non responsiveness to your incorrect > octet count conclusion, are you agreeing that it does indeed save > one round trip and twice the stored VQUERY size in OCTETS > at a minimum now so it is in fact 'efficient'? I have NO clue where you got the idea in your head that the CUA is going to have to retrieve a query string from the CS only to stuff it into a command buffer and then send it back to the CS. Perhaps the same place you got your definition of the word original. Ive already explained several times that this is incorrect on your part and Ive even given pseudocode on how the CUA does it all itself. Beyond that, I cannot do more. I would still appreciate an explaination of why you think the CUA MUST load the query string from the CS in the first place? Is that how you prototyped it? Or is there just some other nuance of phrasing Im not getting? Arnaud, can you help me out here? Bruce =========================================================================== Bruce Kahn INet: [email protected] Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law...