Subject: [Fwd: Re: CAP-12-a: Stored queries still?]

From: Doug Royer <[email-masked]>
Date: Wed, 03 Sep 2003 16:07:24 -0600

(I accidentally sent this to Bruce - I meant to send it to the list)

[email-masked] wrote:
> 
> We never reached a clear concensus on the issue of stored queries in 
> CAP.  The thread just stopped in mid-January 2003 and I still question 
> the usefulness of them in CAP.

Is what Bruce means, it it does not end until he agrees. There was
a debate - two of them over the last two years.

> As a refresher for those that may not recall that thread or are new:
> 
> CAP has the ability to store and refer to 'named' queries in the 
> protocol.  However, since there is no ability to wildcard any values in 
> the query ....

Which is irrelevant as there ARE queries that can be saved
without wild cards. No place in CAP does it say that
you must be able to do stored queries based on time or wild cards.

Such as these examples:

	QUERYID:Common
	SELECT VEVENT FROM VEGANDA WHERE STATE() = "UNPROCESSED"
	SELECT VTODO FROM VEGANDA WHERE STATE() = "UNPROCESSED"

	QUERYID:STUFF
	SELECT VEVENT FROM VAGENDA WHERE STATE() = "DELETED"
	SELECT VTODO FROM VAGENDA WHERE STATE() = "DELETED"

	QUERYID:Everything
	SELECT VEVENT FROM VEGANDA WHERE STATE() = "UNPROCESSED"
	SELECT VTODO FROM VEGANDA WHERE STATE() = "UNPROCESSED"
	SELECT VHOURNAL FROM VEGANDA WHERE STATE() = "UNPROCESSED"
	SELECT X-MY-COMP FROM VEGANDA WHERE STATE() = "UNPROCESSED"

	QUERYID:MY RIGHTS
	SELECT VCAR FROM VAGENDA WHERE SELF() IN DENY
	SELECT VCAR FROM VAGENDA WHERE SELF() IN GRANT

	QUERYID:MY CALS
	SELECT CARID FROM VCALSTORE WHERE SELF() in OWNER

	.
	.
	.

-- 

   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

-- 

  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: Tim Hare <[email-masked]>
Date: Wed, 03 Sep 2003 23:12:42 -0400

This may be an implementation question, but I feel it may be germane:

How does the "stored" query save anything? It seems to me that in a limited 
implementation (PDAs were mentioned, but of course that's not the only 
case, I might want to implement CAP on my Atari 400 or something ) the 
premium would be on storage space, and you either store the query 
(memory/disk storage) or you have essentially the same query stored mostly 
as literals within the program itself because the program has to generate 
those literals to accomplish the CAP Query anyway. I agree with Doug that 
there are queries which can be stored without need for  wild cards, but I'm 
not sure I see where the efficiency comes in. Is it intended that the 
stored queries be on the Calendar Store machine, such that a 
smaller-footprint client can invoke them just by name, like a remote 
procedure call of some sort?

Tim Hare

---

From: [email-masked]
Date: Thu, 4 Sep 2003 10:29:09 -0400

> a debate - two of them over the last two years.

Check the archives and you'll see that its not only I who questioned the 
usefulness of the feature as we have designed CAP.    Go ahead, I'll 
wait...

Recently I asked for examples of where its really useful and really has 
benefit versus the cost and complexity to CS implementations.  Of the 2 
people on the list who wanted to keep them (Doug & Andrea), neither 
responded.  Why is that?  Instead of showing a benefit for them, you try 
to deflect the issue now by saying already been covered.  In fact, it was 
not resolved.

We debated the initial idea way back when it was proposed as a solution to 
"thin" clients like PDAs and the like.  The idea was to reduce a CUAs need 
to recraft a common query and just rely on the CS keeping it around. 
Common activities like checking for alarms, searching for new 'stuff', etc 
were all proposed as desireable cases that would be used for this feature 
and there would be lots of saved bandwidth and cycles. 

In taking a practical look at them in recent drafts I question their 
actual usefulness given our query lingua. 

Since there is no way for any client ('fat' or 'thin') to create a stored 
query that is really beneficial and reusable I question the need to have 
them as a mandatory CS feature.  The query language has NO way for 
crafting a query thats reusable like "Find me the alarms that go off in 
the next 15 minutes" or "What entries are on my calendar for today". Thats 
because we have no concept of being able to wildcards; the query MUST use 
exact comparisons to _explicit_ values. 

This hardly makes the stored querys reusable; the CUA will have to update 
them with new _explicit_ values on some regular basis.  Not much savings 
there that I can see and infact it may be more of a burden (ie: extra 
network traffic to recreate the stored query) than a benefit.

> without wild cards. 

Yes there are; _any_ query can be stored.  However they do NOT fulfull the 
original intent of the stored query feature nor does storing them in the 
CS any strong benefit to anyone compared to the cost of implementation.

>                      No place in CAP does it say that

You are missing the point or trying to deflect it.

The intent of stored queries was to make it easier for 'thin' clients to 
keep smaller footprints by allowing them to not have to (re)craft commonly 
used queries again and again; they relied on the CS to keep the query and 
involk it when the CUA needed it.  This is a great concept but we failed 
to design our query language to allow for it to be _actually_ useful.

Until now noone has provided any kind of examples that show why we MUST 
have this as part of ALL CS implemenations.  The CAP drafts make an 
implicit requirement that CS implement stored queries and I think this is 
wrong to do, especially given the lack of any demonstratable benefit.

Now that you've finally got some examples, lets take a look at them to see 
if they meet the original intent and compare any benefits to the cost of 
saving queries...

>    SELECT VTODO FROM VEGANDA WHERE STATE() = "UNPROCESSED"

Yes, this is a common kind of query ("Find me 'new stuff'"). 

However there is nothing complex here that would require any CUA ('fat' or 
'thin') to take up that much extra space or cycles to send.  It can simply 
be a hardcoded string that any CUA simply puts into the payload.  Of 
course you can bloat this query out to be explicit for all kinds of 
components explicitly (and thus miss unprocessed content) or you can take 
the more compact form and use:

SELECT * FROM VEGANDA WHERE STATE() = "UNPROCESSED"

The savings in doing this is 51 octets compared to sending just:

QUERYID:Common

Umm, not any real savings for any kind of CUA that I can see.

>    SELECT VTODO FROM VAGENDA WHERE STATE() = "DELETED"

Is this a common query?  Find me the deleted entries? 

Perhaps if you were building some kind of replication or sync engine on 
CAP but thats not in CAP 1.0 and the usefulness is quite limitied.  Again, 
you can simplify this down to the more compact form of:

SELECT * FROM VAGENDA WHERE STATE() = "DELETED"

but so what?  This is not really a common action and the savings in 
storing it is just 47 octets over sending just:

QUERYID:STUFF

>    SELECT X-MY-COMP FROM VEGANDA WHERE STATE() = "UNPROCESSED"

Nice bloating of the more normalative case:

SELECT * FROM VEGANDA WHERE STATE() = "UNPROCESSED"

which you already covered first.  Nothing new here.

>    SELECT VCAR FROM VAGENDA WHERE SELF() IN GRANT

What kind of common action is this?  How often does a CUA search for 
essentially all VCARs where they are either denied or granted some right? 
VCARs managment is NOT a CAP 1.0 concern (its "Administratin" and thus OOB 
as many are keen to point out).

This is not a commonly performed query that I can see.  Hardly a good 
justification to match the original intent.

>    SELECT CARID FROM VCALSTORE WHERE SELF() in OWNER

This is another common action?  Finding all calendars in the store that 
the CUA is the owner of?  Again, this is hardly a commonly performed query 
and another poor example that does not match the original intent of stored 
queries.  A CUA doesn't often need to check what calendars they own, they 
should that info already or need to discover it at most once per session.

Thats it?  I will now amend what I said before about no examples; I 
finally got 1.  It saved my CUA sending ~50ish octets.  ~50 octets of what 
can easily be just a hardcoded string that creates no real burden on any 
CUA.  After all, any CUA that can hold a CAP 1.0 engine should not have to 
worry about ~50 more bytes...

Not many examples of any kind to justify such an implicit CS requirement 
to me and only 1 was really a commonly performed queries that matches the 
original intent of the feature.  The savings were trival compared to the 
cost for ALL CS's.  Plus there was NOTHING in any of them that required 
ANY kind of load on the CUA; they could all be resourced strings that just 
get stuffed into the command and sent!

I supported the original intent of stored queries but the current design 
does not approach the intent we created them with.  I still think that 
implicitly requiring ALL CS's to implement this for such little benefit is 
a bad idea. 

I noticed you didnt try to show any queries that did things related to the 
original intent of the stored query.  Nothing about checking for alarm 
triggers.  Nothing about checking for calendar contents for "today" or 
"tomorrow" or "this week" etc.  And why not?  Because these more commonly 
used kinds of queries just cannot be stored and reused without being 
rewritten on some regular basis. 

I have a very strong aversion to implicitly mandating unnecessary features 
in CAP servers, especially when the design does not fulfill the original 
intent.  Why should anyone have to build query storage into their CS when 

A) it does not fulfill the original intent of the feature, 
B) there is nothing in CAP about how a CS can reject stored queries yet 
still say they support VQUERYs that are not stored
C) there is nothing in CAP about the CUAs or CSs responsibility for 
maintenance and cleanup of any stored VQUERY

The single common example provided compared to all the ones we originally 
thought of shows exactly how little benefit there is.  A few octets that 
can be a hardcoded string is hardly compelling reason to keep this feature 
in CAP 1.0.

Why as a CS implementor do I need to design in some query storage 
mechanism because we left in a worthwhile feature that we failed to 
adequately design for in our query language?  I should have the ability to 
reject query storage attempt or any attempt to refer to a non-stored query 
but theres nothing in CAP that allows me to do this nor is there anything 
about how a CUA can or should deal with a CS that tries to reject stored 
queries. 

While I do support the original intent, I think we lost sight of the goal 
and missed the mark on this feature somewhere along the way.  As such lets 
simplify an already complex draft and remove the highly doubious 
requirement/feature.

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: [email-masked]
Date: Thu, 4 Sep 2003 11:05:45 -0400

Tim wrote on 09/03/2003 11:12:42 PM:
>                                                   I agree with Doug that 

> not sure I see where the efficiency comes in. 

I think we all agree that not all stored querys need to use wildcards. 

If we consider the original intent of the feature, the current design 
misses the mark and the efficiency for other cases is somewhat tenuous.

>                                               Is it intended that the 

The original intent was to provide a means for clients to save on space 
and cycles by not having to recraft commonly used queries and resend them. 
 Queries like "What alarms trigger in the next 10 minutes?" or "Is there 
anything new for me to look at" or "What entries are on my calendar for 
this morning/today?", etc.

Its possible to craft and store uncommon or infrequently used queries and 
save them away either locally or on the CS.   However making every CS 
support this feature that does not fulfill the original intent is 
something I have a concern about. 

CAP implcitly mandates every CS support stored queries: there is nothing 
in CAP about how a CS can not support stored queries or how a CUA detects 
this.  This is another mistake that CAP needs to correct.  However being a 
proponent of KISS, I think the better solution is to remove the feature 
from CAP 1.0 altogether since it fails to meets it original intent and 
creates an implicit onus on CS's that is not clear no optional.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 09:09:10 -0600

Tim Hare wrote:
> How does the "stored" query save anything? It seems to me that in a 
> limited implementation (PDAs were mentioned, but of course that's not 
> the only case, I might want to implement CAP on my Atari 400 or 
> something ) the premium would be on storage space, and you either store 
> the query (memory/disk storage) or you have essentially the same query 
> stored mostly as literals within the program itself because the program 
> has to generate those literals to accomplish the CAP Query anyway. I 
> agree with Doug that there are queries which can be stored without need 
> for  wild cards, but I'm not sure I see where the efficiency comes in. 
> Is it intended that the stored queries be on the Calendar Store machine, 
> such that a smaller-footprint client can invoke them just by name, like 
> a remote procedure call of some sort?

Yes.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 09:22:35 -0600

> usefulness of the feature as we have designed CAP.    Go ahead, I'll 

That is what you said last time, so keep searching the archives for
the 1st time you brought this up.

> responded.  Why is that?

Because we had replied the previous year to your same claim. Go ahead
and search the archives... There was nothing new to reply to. Same
question, same answer.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 09:49:46 -0600

> 
> Since there is no way for any client ('fat' or 'thin') to create a 
> stored query that is really beneficial and reusable

Your opinions presumes you speak for everyone, and you do not.
If you do not find them useful, then speak for yourself.

> I question the need 
> to have them as a mandatory CS feature.  The query language has NO way 
> for crafting a query thats reusable like "Find me the alarms that go off 
> in the next 15 minutes" or "What entries are on my calendar for today". 
>  Thats because we have no concept of being able to wildcards; the query 
> MUST use exact comparisons to _explicit_ values.  

You also have never proposed a solution to your need that you describe
above. Those that did propose a solution got the text in CAP. That
is the way it works.

> This hardly makes the stored querys reusable; the CUA will have to 
> update them with new _explicit_ values on some regular basis.

Explain how *ANY* of the queries I sent need to be updated on
a regular basis.

> Yes there are; _any_ query can be stored.  However they do NOT fulfull 
> the original intent of the stored query feature nor does storing them in 
> the CS any strong benefit to anyone compared to the cost of implementation.

You can also store bogus VEVENTs that still fit the ABNF grammar,
So what's your point? Do you want to propose that we add text
saying "do not do something unless it is useful"?

> You are missing the point or trying to deflect it.

No, your missing the point, it was debated, added, text changed, and
no one saw that there was a need to add grammar to do the things that
you keep saying would make it useful. If you have a proposal - make it.

> keep smaller footprints by allowing them to not have to (re)craft 
> commonly used queries again and again; they relied on the CS to keep the 
> query and involk it when the CUA needed it.  This is a great concept but 
> we failed to design our query language to allow for it to be _actually_ 
> useful.

You keep (re)stating the obvious - however I find the queries useful
as did CS&T. So did John.

Currently a CS has to CREATE, MODIFY, MOVE, SEARCH, and DELETE
components. VQUERY is just another component. And QUERYID is a way
to say:

	Go SEARCH for a known component (a VQUERY) and store
         the results in in the CUA

	Now send that same component back to the CS and get
	the results and store in the CUA.

Your calculations (omitted) failed to calculate the fetching
of the same query that you then send back to the CS.

Looks beneficial and efficient to me to just say:

	Go to QUERYID and store the results in a the CUA

Remember Cell phones and PDAs do not have a user interface that allows
the user to customize the queries. It gives the PDA and Cell phone
companies the ability to modify the result sets.

Plus there is NO requirement that the contents of QUERYID be
static, they could be dynamic.	

> implicit requirement that CS implement stored queries and I think this 
> is wrong to do, especially given the lack of any demonstratable benefit.

Something was demonstrated you comment on it below.

> Now that you've finally got some examples, lets take a look at them to 
> see if they meet the original intent and compare any benefits to the 
> cost of saving queries...
> 
>  >    QUERYID:Common
> However there is nothing complex here that would require any CUA ('fat' 
> or 'thin') to take up that much extra space or cycles to send.

It allows the Cell phone and PDA to have a GUI-CUA that runs on
a full computer to specify what you get back when you say 'Common'.
Such as VEVENT only, or VTODO only, or whatever. The PDA and
Cell phones are not going to have that ability.

Stored queries allows a 2nd-CUA to specify the query restrictions
for GUI-challanged CUAs.

And if you search the archives you will find that we specifically
stated at the time we were doing the requirements for iCAL that not
all CUAs will have a user interface. They can be hardware or software that
responds to data in the CS. Stored queries allows their search results
to be configured for them. If you also add the fact that the contents
of a stored query can change from time to time, plus the CUA-BOTs
that we talked about, you now have a fully configurable searches.

Not all CUA's are computer based GUIs with user interfaces and lots
of memory and processing power.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 09:58:33 -0600

> misses the mark and the efficiency for other cases is somewhat tenuous.

If you feel that is true, please post the 'original intent' as posted
to the WG.

> and cycles by not having to recraft commonly used queries and resend 

And it does save both bandwidth and octets especially when you consider
the 2 sets of QUERY/FETCH required without them.

> Queries like "What alarms trigger in the next 10 minutes?" or "Is 
> there anything new for me to look at" or "What entries are on my 
> calendar for this morning/today?", etc.

If you feel that is a requirement, then submit a proposal.

> Its possible to craft and store uncommon or infrequently used queries 
> and save them away either locally or on the CS.   However making every 
> CS support this feature that does not fulfill the original intent is 

You keep claiming the 'original intent' - yet my search of the archives
show that you did not attend the meetings where that was designed
or proposed. You simply do not want them which is a fair statement.
But you were not part of the 'original' design so you really are just
making up claims that have no foundation.

> in CAP about how a CS can not support stored queries or how a CUA 
> detects this.

Bruce you have been on IETF mailing lists for a long time. You know
how it works. Complaining without submitting a proposal is something
that almost never works. If you want to have the ability to say
get me the alarms over the next 10 minutes - submit a proposal,
else - there is nothing to add.

--

---

From: Andrea Campi <[email-masked]>
Date: Thu, 4 Sep 2003 17:58:47 +0200

> to deflect the issue now by saying already been covered.  In fact, it was 

Just to clarify my personal position: I am in a release frenzy right now,
so I have almost 0 time to read the list. This subject however caught
my attention just because I took part in the discussion before.

Without checking at the archives, the last time this came up I was left
with the impression that the best way forward would be to remove stored
queries from this draft and prepare a followup draft that addressed the
exact same points that you are bringing up. In particular, I definitely
agree that if stored queries can only represent shortcuts for queries
we can specify in CAP they're not much use, as Doug's trivial examples
perfectly showed.

So bottomline is: don't keep them on the account of me wanting them in,
at this point I'm absolutely against them (as currently specified).

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: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 10:45:25 -0600

> my attention just because I took part in the discussion before.

What about the round trip time to go fetch the VQUERY manually,
then re-submit it as a query? That save bandwidth and octets
for slow and memory limited devices.

--

---

From: [email-masked]
Date: Thu, 4 Sep 2003 12:16:44 -0400

Doug wrote on 09/04/2003 11:22:35 AM:
>                           There was nothing new to reply to. Same
> question, same answer.

Actually its more like same question, same non-answer. 

Everyone from 2 of the other editors to Andrea question the usefulness of 
this feature in CAP 1.0 given our inability to achieve the original 
intent.  You seem to be the only one steadfastly opposed to removing it 
from CAP.

Bruce
Warning: Dates in Calendar are closer than they appear.

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 11:42:12 -0600

[email-masked] wrote:
> Everyone from 2 of the other editors to Andrea question the usefulness 
> of this feature in CAP 1.0 given our inability to achieve the original 

Bruce - 4 people replied today - two said yes (me and it looks as if
Bernard by replying is saying yes, you said no, and Andrea
said no). Bernard proposed the NAME/QUERYID change - do you want
us to think that that means 'NO' to stored queries?

And you just posted TODAY - so don't you feel just a little
bit embarrassed that you declare 'Everyone from 2 of the other
editors...' question ... it?

And you have failed to find *anything* that supports your
assertion of the 'original intent'.

--

---

From: [email-masked]
Date: Thu, 4 Sep 2003 14:52:56 -0400

> the 2 sets of QUERY/FETCH required without them.

Err, I think you are mistaken in how non-stored queries work. 

The CUA does NOT first retrieve them from the CS (1 trip on the wire) and 
then resend them to CS in a command (1 trip on the wire).   The CUA simply 
crafts the query locally using whatever inputs it needs/has and sends it. 
Just the 1 trip I described, not the 2 you seem to think.

For those frequently used querys like "What events are on my calendar for 
XXX" or "What alarms trigger in the next 15 minutes" the CUA simply does a 
Cscanf() of the correct inputs (XXX or the current date/time) into a 
loaded query and then sends it.   Again, there is no 2 trips across the 
wire for the query.

Even for the stored query case, unless you count the initial storage case, 
there is only 1 trip across the wire for the query.  Subsequent uses 
simply send QUERYID:Foo in the command and the CS goes to find it and then 
uses it (assuming it can find it and the CU has the ability to read it).

There are undiscussed issues related to stored queries such as:

1: Failure to find a particular QUERYID in a given TARGET, 
2: The ability to specify multiple TARGETs in a VQUERY (ie: Do ALL TARGETs 
have to have the QUERYID in it or just one or is it something else?)
3: How are failures to find/use the QUERYID distinguishded from other 
command failures (ie: The SEARCH failed because you cant see/find/use the 
QUERYID in a TARGET vs the SEARCH failed because you cant access the 
TARGET vs the SEARCH failed because you only can read stored queries but 
not other data in a TARGET vs...?)

All of these undiscussed issues contribute to the proposal that we pull 
stored queries from CAP 1.0 and defer it to a later draft when they can 
all be covered.  Especially since the feature as it currently exists does 
not fulfill our original intent.

>              Complaining without submitting a proposal is something
> that almost never works.

Likewise, rehashing an issue whose overwhelming data is against you wont 
change things.

>                           If you want to have the ability to say

Perhaps you should read the acutal postings before you just fire back 
responses.  Since you keep overlooking it perhaps Ill just make that the 
body of all repsonses from now on out until you see it (I dont hold my 
breath for accepting it). 

In the mean time, I repropose that all references to stored queries be 
removed from CAP 1.0 and the feature be left for a followon draft when it 
can be accurately and properly done.

Bruce

---

From: [email-masked]
Date: Thu, 4 Sep 2003 14:30:35 -0400

> If you do not find them useful, then speak for yourself.

I'm not the only one who have questioned this dubious feature.  At the 
last IETF I was at everyone there questioned it for the exact reasons I 
described.

Had stored queries been able to achieve the original intent I would not 
question them in CAP 1.0 but they do not remotely approach solving the 
original intent and they put an implicit burden on ALL CSs so I question 
their inclusion.

I can see their use for non-wildcarded cases but they do not fulfill our 
original intent for the feature.  Because of this and because of the extra 
load it places on every CS (since there is NO way under CAP-12-a to opt 
out of it) I concur with Andrea in that it should be removed and left 
until a later draft. 

Since Doug seems to be proficient at extra drafts perhaps he can flesh one 
out that will achieve the original intent...

> above. Those that did propose a solution got the text in CAP. That

I proposed that all references to stored queries be removed from CAP 1.0. 
Or perhaps you missed that in nearly all my other postings on the subject. 

> saying "do not do something unless it is useful"?

<FRUSTRATION SHOW=ON>
Perhaps I should propose we get a co-editor who will pay attention to 
postings on issues w/o trying to ignore or deflect them in an attempt to 
get CAP 1.0 out the door ASAP.
</FRUSTRATION>

Proposal: We remove any and all references to stored queries in CAP 1.0. 
Anyone interested in extending CAP such that the original intent of stored 
queries is achieved can do so in a later draft.

> as did CS&T. So did John.

If its obvious then why is it such a big deal to get it removed?

At the last IETF I was at with the Steltor folks they all questioned the 
usefulness of stored queries given our query language.  So did Steve 
Mansour.  That's 2 of the co-editors of CAP.  Sure, stored queries can be 
used but none has been able to show that we are able to achieve the 
original intent to any real degree (1 example for ~50 octets is hardly any 
benefit).

Given the cost of implementation vs the degree of inability to achieve the 
intent of the feature I propose (in case you missed it before) that we 
remove all references to stored queries from CAP 1.0 and leave it to a 
later draft to add the feature properly.

> of the same query that you then send back to the CS.

Oh, so you think that the CUA is always going to retrieve the VQUERY from 
the CS and then resend it back to the CS on any of those commands?!?  Why? 
 If the CUA knows it wants to find all unprocessed entries it can use a 
hardcoded query and just send it; there's no need to go find it and then 
resend it.

There's never been any implicit or explicit need for the CUA to first find 
the query in the CS and then use it.  My CUA should be able to craft and 
send queries just fine w/o expecting to get them from the CS.  After all, 
just how would your CUA be able to "Find the query that retrieves all 
entries on my calendar for XXX" where XXX is some arbitrary date/time 
value?  The CUA should have no problem calculating the XXX value based on 
some UI inputs (ie: the current date being displayed) and filling in the 
blank before sending the query.  Unless of course you never wrote code 
that used Cscanf() before...

> Looks beneficial and efficient to me to just say:

Saving ~50 octets is hardly efficient when you factor in that the CS has 
to always be able to support stored queries and that the original intent 
for stored queries is unreachable given our current model/design (with 1 
exception).

> companies the ability to modify the result sets.

Huh?  My cell phone has a built in calendar.  From there I can pick the 
day to see entries on.  That's all that the CU needs to do to get data; 
the underlying CAP engine does the rest.  (Are you expecting CUs to be 
doing query crafting manually instead of letting the CUA do it?? I don't 
want to be beta testing your CUA if that's true...)

If it had a CAP engine, it would have NO way to access any kind of stored 
query on my CS to get the events for "Today" or the day I pick at random! 
None.  The CAP engine in my cell phone MUST craft up the query with the 
"WHERE DTSTART<=[the selected day] AND DTEND>=[the selected day]" and send 
it.  There is NO way around it and that's exactly why the stored query 
feature in CAP 1.0 fails to meet the original intent. 

"[T]he ability to modify the result set" is totally unrelated to the issue 
of query storage!  Post processing of any kind is not relevant to the 
issue of using stored queries or queries within the command.

> static, they could be dynamic. 

Umm, is this germane?  I'm not sure what you are referring to so I cant 
respond. 

> Something was demonstrated you comment on it below.

Your 4 examples were unremarkable and uncompelling.  You duplicated 1 and 
the other 2 were not related to the intent of the feature. 

Of the sole releveant example the only savings was ~50 octets.  To me, 50 
octets is not that compelling given its only for 1 example and there are 
NO other examples that fulfill the original intent.  All the other 
examples you provided were not typical common or frequently used queries 
and as such are hardly compelling incentive to keep the feature in (unless 
you've got code that already does it and don't want to tie it off until a 
later draft.)

> Cell phones are not going to have that ability.

There is no great need for some fancy GUI on thin clients Doug.  My LG 610 
has a built in calendar that allows me to create entries on it and have 
alarms set, etc.  I press 1 button to get the current month and then use 
my arrow buttons to pick a day.  From there any entries I have for that 
day appear.  I can also create new entries or remove those that are there 
(or update them w/alarms).

If I were to try and use CAP to get data from my calendar then the phone 
MUST craft a query like "QUERY:SELECT VEVENT FROM VAGENDA WHERE 
DTSTART<=[date I selected] AND DTEND>=[date I selected]" where the date 
values are based on the day I selected via arrow buttons.  The CAP engine 
simply takes the date I picked and then Cscanf()'s it into the query and 
sends it.  No big GUI needs.  No benefit to using a stored query since it 
cannot wildcard the selected date into the query.  Just a simple Cscanf() 
into a buffer and then send it.

Originally we had envisioned being able to say "QUERYID:Todays_events" and 
the CS would be able to find them for my cell phone, no need for it to 
craft the QUERY.  However we failed to make the query language robust (or 
flexible) enough to convey wildcarded or fixed semantics (ie: "Today"). As 
such the thin clients have no way to get the benefit we intended and the 
CS implementations are implicitly mandated to support stored queries. 

>                               Stored queries allows their search results
> to be configured for them. 

Where do you come up with this stuff?  Referencing a stored query has 
NOTHING to do with any kind of results processing.

A stored query was intended as a means to minimize the CUAs need to send 
the frequently used querys in a command; the query was already on the CS 
so it could be just referenced by QUERYID and the CS would find and use it 
instead of parse the command for the query and perform it. 

> of memory and processing power.

Umm, ~50 octets is hardly that big an impact if the 'thin' client expects 
to be able to hold any amount of possible calendar data returned on the 
search.  After all we dont have a way to throttle off the SEARCH command 
results when too much data is returned short of shutting the BEEP channel. 

So again I propose that we remove all references to stored queries in CAP 
1.0 and anyone interested in extending CAP such that the original intent 
of stored queries is achieved can do so in a later draft.

Bruce

---

From: [email-masked]
Date: Thu, 4 Sep 2003 15:38:32 -0400

> for slow and memory limited devices.

Umm, there is NO roundtrip to get the query string and then resending it 
to the CS.  The CUA simply does (psuedocode below):

        LoadString( (bCheckingEvents) ? QUERY_NEW_EVENTS : 
QUERY_NEW_TASKS, Buffer );
        Cscanf( Buffer, DateToGetEntriesFor );
        SendQUERY( Buffer );

to query the CS for the new events or todos.

Im not sure why you'd think you have to query the CS for the query and 
then resend it, you'd just be crafting the query in the CUA and just 
sending them.   Nobody has said anything about loading the query from the 
CS just to resend it back on the command...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 13:47:59 -0600

[email-masked] wrote:
> The CUA does NOT first retrieve them from the CS (1 trip on the wire) 
> and then resend them to CS in a command (1 trip on the wire).   The CUA 
> simply crafts the query locally using whatever inputs it needs/has and 
> sends it.  Just the 1 trip I described, not the 2 you seem to think.

My point exactly. If I want the query named XXX and we do not support
VQUERY with QUERYID, then the CUA MUST do that 2 round trips.

> For those frequently used querys like "What events are on my calendar 
> for XXX" or "What alarms trigger in the next 15 minutes" the CUA simply 
> does a Cscanf() of the correct inputs (XXX or the current date/time) 
> into a loaded query and then sends it.   Again, there is no 2 trips 
> across the wire for the query.

NO ONE has proposed such a thing - who cares?

> 1: Failure to find a particular QUERYID in a given TARGET,

Why do you feel that would be any different to a query for a UID
that did not exist? Its the component-ID tag. No such distinction
exists.

If you qury for a UID that does not exist in the named TARGET
- you get an error.

If you qury for a QUIERYID that does not exist in the named TARGET
  - you get an error.

If you qury for ANY property that does not exist in the named TARGET
  - you get an error - even when it is not a VQUERY.

Not an issue.

> 2: The ability to specify multiple TARGETs in a VQUERY (ie: Do ALL 
> TARGETs have to have the QUERYID in it or just one or is it something 
> else?)

Not sure which TARGET you mean:

  If you are talking about the TARGET in the VQUERY, then there is no
  difference to manually sending the same VQUERY even when it is not stored.

  Not an issue, So why do you feel it is different if it is stored or not?

  If you are talking about the TARGET at the CMD level, then there is no
  difference to manually sending the same VQUERY even when it is not stored.

  Not an issue. So why do you feel it is different if it is stored or not?

> command failures (ie: The SEARCH failed because you cant see/find/use 
> the QUERYID in a TARGET vs the SEARCH failed because you cant access the 

As you can send the EXACT same query manually, why do you feel that
it would be any different?

> all be covered.  Especially since the feature as it currently exists 
> does not fulfill our original intent.

All of your assertions above are unfounded and unsubstantiated.
They are not real problems. They have nothing to do with the text in CAP.
Those problems do not exist in any way that is different from non-stored
queries.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 14:06:38 -0600

> to the CS.  The CUA simply does (psuedocode below):

Not a clue what you sent below was.

> sending them.   Nobody has said anything about loading the query from 
> the CS just to resend it back on the command...

Okay - I want to do what is stored in a component with
a QUERYID tag of 'XXX' as set by my configureation tool
on my cell phone.

Please show me the VQUERY component that your CUA will send.

Your going to have to (1) fetch XXX, then (2) submit it.
That is 2 round trips.

--

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 14:04:04 -0600

> last IETF I was at everyone there questioned it for the exact reasons I 

I made no such claim. You clamed that only I supported it - not true.

> original intent and they put an implicit burden on ALL CSs so I question 

And what was the original intent?

> 
> I proposed that all references to stored queries be removed from CAP 
> 1.0.  Or perhaps you missed that in nearly all my other postings on the 
> subject.  
> 

> get CAP 1.0 out the door ASAP.

Hint: A proposal suggests something, it is not a question :-)

>  Anyone interested in extending CAP such that the original intent of 
> stored queries is achieved can do so in a later draft.

Thanks for a proposal. Did you notice that I was not the only
one that objects to it being removed - today?

Why do you want VQUERY to be the ONLY component that can not
be fetched or stored?

> Oh, so you think that the CUA is always going to retrieve the VQUERY 
> from the CS and then resend it back to the CS on any of those 
> commands?!?  Why? 

Because cell and small devices do not have a GUI to configure
what they want in the response.

> day to see entries on.  That's all that the CU needs to do to get data;

Yes, but what data is to be included? That is NOT configurable by your
cell phone. Stored queries allow a 2nd CUA to store queries that can
be used by the non-CUI CUAs. There has not been a requirement that
the same CUA store and fetch the same queries.

--

---

From: Bernard Desruisseaux <[email-masked]>
Date: Thu, 04 Sep 2003 16:31:42 -0400

Doug Royer wrote:

>> intent.  You seem to be the only one steadfastly opposed to removing 
>> it from CAP.
> 
> 

My reply was simply clarifying that if CAP were to support stored
VQUERY components, one should use the QUERYID property, and not
the NAME property, when making reference to stored VQUERY components.

As for where I stand with the stored VQUERY issue, like Bruce and
Andrea, I don't see a real benefit from using stored VQUERY as
they are currently specified, and as such I would remove all
references to them in CAP 1.0.

Cheers,
Bernard

---

From: [email-masked]
Date: Thu, 4 Sep 2003 17:28:56 -0400

Doug wished on 09/04/2003 01:42:12 PM:
> said no). 

Umm, you better actually read what Bernard wrote.  He said:

In February 2002, Steltor (formerly CS&T, and now Oracle) proposed
to rename the property QUERYNAME to QUERYID and to add a new property
NAME to specify a localizable display name.

VQUERY components should be referred to with their unique QUERYID not
their NAME which may not be unique.

Thats not an endorsement of stored queries.  He's merely giving history to 
their contribution that you referenced. 

>           Bernard proposed the NAME/QUERYID change - do you want

You are incorrectly trying to link what Bernard clarified to a my issue of 
stored queries.  You should be thinking of the other issue I raised: the 
incorrect inclusion of NAME in the searching for a stored query.  The 
latter is related to the former but goes away if the former is removed as 
Ive proposed.

> editors...' question ... it?

If you are trying to bait me into something it wont work.  The issue was 
raised at the San Diego IETF (I think) and nobody there could find a 
compelling reason to keep them given the limitation of our query language 
(which I believe you proposed be simplified under the Subject "I MOVE we 
simplify the query language." back in early 2002). 

The plain fact of the matter is that stored queries failed to meet our 
original intent because the query language cannot support what we thought 
we could design.  Because of this and because of several 
unspecified/unanswer related issues I agree w/Andrea that it should be 
removed from CAP and left for a later draft to properly design and 
specify.

> assertion of the 'original intent'.

Are you now saying that the original intent of stored queries was NOT for 

but I guess you will say I misquoted you.

The motivation has it roots as far back as 1998 when Surendra Reddy 
mentioned it in the context of Simple Internet Calendar Access Protocol. 
Its also been discussed in the context of the original intent often in 
other discussions over the past couple of years. 

In fact, a scan of my archive reveals that this kind of issue was at least 
partly recognized by John Stracke back in March 2003 when he replied to 
you with:

Besides, as things stand, a stored query would be useless for "today's 
alarms", or "today's events", because the query language has no term for 
"today".

Your attempts to question the original intent aside (hey, theres that 
pesky word 'original' again.  I wonder...) I am still proposing that we 
simplify CAP by removing stored queries and that they be deferred to a 
later draft where all issues can be properly delt with.

We simplified the query lingua to speed up CAP but as a side effect we 
gutted the stored queries ability to fulfill our original intent.  We 
should further simplify CAP and remove all references to stored queries 
for CAP 1.0.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 04 Sep 2003 15:58:50 -0600

[email-masked] wrote:
> 
> Are you now saying that the original intent of stored queries was NOT 
> for thin clients?  Gee, you previously confirmed what I said when you 
> wrote:

So rather than define what you are talking about, you show some
history that has nothing to do with the question.

 >> the 2 sets of QUERY/FETCH required without them.

And it does. And despite your assertion to the contrary, you
still forgot to add in the (1) set of octets to get the XXX
query definition.

--

---

From: [email-masked]
Date: Fri, 5 Sep 2003 14:18:49 -0400

> NO ONE has proposed such a thing - who cares?

You have when you keep saying "2 trips on the wire" (paraphrased). However 
I think you are misunderstanding something here: removing stored queries 
entirely means the CUA wont try to use them (trip 1), fail and then craft 
its own query (trip 2).  The CUA simply crafts the query and sends it (1 
trip).

> that did not exist? Its the component-ID tag. No such distinction

Because there is a definite difference between "I cant find the query you 
wanted me to use to find those VEVENTS" and "I cant find those VEVENTS". 
Both are errors but dealing with them is different.  See the difference 
now?

> Not sure which TARGET you mean:

Clearly not (or is this another tactic?).  In a VQUERY there can be one 
(or multiple) TARGET properties to tell the CS where to go look for the 
QUERYID (go recheck the ABNF in 9.6 if not with me still)

It is unspecified how a CS deals with finding/selecting/using the QUERYID 
in multiple TARGETs (those TARGETs you can put inside the VQUERY, not out 
side it at the command level).  Does it use the first one it finds only? 
All of them? All the CU has access to? Does any failure to find the 
QUERYID in any/all/some TARGET mean the command should be rejected or 
attempted anyway? Etc...

> it would be any different?

You really do not understand some of this stuff, or at least are trying to 
appear not to.  Ill give you the benefit of the doubt and say that it was 
not clearly phrased on my part.

In the stored query case the CUA is expecting the CS to do some kind of 
query lookup internally (based on QUERYIDs and TARGETs), use that to find 
the proper data set for the command to work on and return the results.

In the CUA query generated case, the CUA does not expect the CS to have to 
go find and them craft some query to use for the command; it generates the 
exact query it wanted to use.  There is no needing for the CS to go get 
the query or parts of it from any other place in the CS so there are no 
problems like VCARs or non-existant QUERYIDs.

In the former case there is potential for the CS to fail to find/craft the 
query that the CUA was expecting since there are things like VCARs, etc 
that now come into play for getting the query data separate from the data 
set the query is to work on.  As such, the the CUA may not get the same 
results they expect because the effective query used by the CS may not be 
exactly what they intended.

Couple with this the fact that there is no way for the CUA to distinguish 
between "I was unable to craft the query you requested to perform the 
command you sent" from "I was unable perform the command you sent' (see 
top) then it should be clear now that there is added complexity in using 
or relying on stored queries that is not currently clearly described in 
CAP.

> All of your assertions above are unfounded and unsubstantiated.

If you stil think so then perhaps we need to get an someone here who sees 
the difference described above and can see the issues when they are 
presented.

>                             They have nothing to do with the text in 
CAP.

Err, part of the issue is precisely that: there is NO text in CAP to deal 
with these things.  This is yet another reason why stored queries need to 
be removed.  All aspects of their use has not been fully designed or dealt 
with in CAP.

> Those problems do not exist in any way that is different from non-stored

Actually they do not.  Go recheck the part related to issue 3 again...

So, my proposal is still on the table: We remove all references to stored 
queries in CAP 1.0 and defer them to a followon draft when they can be 
properly designed to meet our original intent.

So far the only disagreement on this proposal is yours.  Anyone else?

Bruce

---

From: George Babics <[email-masked]>
Date: Fri, 05 Sep 2003 14:40:21 -0400

Doug Royer wrote:
> 
> ... 
>
>> The intent of stored queries was to make it easier for 'thin' clients 
>> to keep smaller footprints by allowing them to not have to (re)craft 
>> commonly used queries again and again; they relied on the CS to keep 
>> the query and involk it when the CUA needed it.  This is a great 
>> concept but we failed to design our query language to allow for it to 
>> be _actually_ useful.
> 
> 
 > ...

Oracle (formerly Steltor, which used to be CS&T) does not find
them useful. I had a quick look at the archives and I believe
that John also did not think that they were needed.

George

---

From: [email-masked]
Date: Fri, 5 Sep 2003 14:44:37 -0400

> a QUERYID tag of 'XXX' as set by my configureation tool

Err, QUERYID is only on queries to identify them.  Its not specified to be 
on other components so you must be still thinking of stored queries.  If 
we dont have stored queries then you wont be looking for it in the CS, the 
CUA will be the one generating it as it needs it using something akin to 
my pseudocode from before.  Hence, no 2 trips...

> Please show me the VQUERY component that your CUA will send.

Go recheck that psuedocode.  The CUA crafts the proper query itself and 
sends it.  There is NO way around it if the CUA wants to find "Any alarms 
that trigger in the next 15 minutes", etc.

> Your going to have to (1) fetch XXX, then (2) submit it.

Slowly in... Slowly out...

The does NOT do attempt to go find any stored query in the CS using 
QUERYID:XXX, pull it down and then resend it.  You are missing the entire 
proposal.  There are no more stored queries.  This means then that the CUA 
simply generates the correct query (since the CS cant do it anyway!) and 
sends it.  That means 1 trip, not 2.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 05 Sep 2003 13:02:18 -0600

[email-masked] wrote:
> You have when you keep saying "2 trips on the wire" (paraphrased). 
>  However I think you are misunderstanding something here: removing 
> stored queries entirely means the CUA wont try to use them (trip 1), 
> fail and then craft its own query (trip 2).  The CUA simply crafts the 
> query and sends it (1 trip).

And you keep failing to reply to the example - why?

--