Re: CAP-12-a: 9.6 VQUERY Component - QUERYID/NAME

[email protected]
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...
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.