Re: an idea as an alternative to stored queries

Your stored query named "CELL-VENDOR-NAME-TODAY"  would need to contain 
strings such as $CURRDATE and $CURRDATE+1 so that the implementation can 
substitute correctly each time. These strings would need to be 
implementation-defined; or else some standard for replaceable variables 
would need to be defined so that other implementations would know what to 
substitute for them.

There would need to be a decreed VCAR to keep one implementation from using 
a stored VCAR which another implementation has defined - but from what I 
see, it isn't particularly easy to authenticate an implementation to assign 
it  a UPN. That's an issue that might be difficult to resolve - I can't 
think of a good way to restrict stored queries by implementation without 
implementations having a UPN - but then each instance (cell phone, PDA, 
whatever) of a particular instance would have the same UPN, which is a 
problem. Another way around it is for each instance to store its own 
queries and lock them to the UPN of the CU using that device (CUA) - i.e. 
"John's stored queries can only be used by John" - but what if that CU uses 
more than one CUA with different implementations? Will the implementation 
name/identifier have to be stored as a propery of the VQUERY component?

We could just let implementations use iana- or x-cmds to provide 
specialized function, but then the CUA would have to connect to a 
particular CS, one which supports the x-cmd, and we'd be almost be back 
to  the proprietary methods we have now.

The few proposals that I have now are (choose one, I'd guess):

1. Allow CUAs to store and retrieve VQUERY objects, much as CAP contains 
now, but explicitly state in CAP that interpretation and execution of the 
stored query is implementation-specific and therefore may not be (and 
probably is not) interoperable.

2. Define a small set of useful commands (as I have proposed before) which 
must be in all implementations (the GET-TODAY, GET-NEXT commands). This 
option requires all parties to agree to the set of commands and their 
implementation (i.e. what does "today" mean, etc.)

3. Remove stored queries from CAP and let each CUA store its own query 
objects in whatever form it wants, modify them, and send them - if there's 
a small set of them, such as the 'CELL-VENDOR-NAME-TODAY' query, it won't 
cost that much storage on a "small"-footprint device; there are also coding 
techniques to "compress" the storage of them (for example encoding 
frequently used strings into an index which points to the string, etcetera).

I, having proposed it before, continue to favor option #2. What we need, 
however, is to reach consensus on _what_ we are going to do. If we are 
going to leave stored queries in CAP then I strongly favor something along 
the lines of option #1.

Side notes:

A) option 2 would _also_ allow cell phones to participate in CAP
B) option 3 needs storage for the query commands- possibly as literals and 
such in the program objects. I think, however, that the amount of storage 
to build a query and send it might be _less_ than the storage to retrieve a 
stored query, parse it enough to substitute variables into it, and send it. 
If we're trying to save space for "small-footprint" devices, that's a 
consideration.
C) let's not forget that the amount of storage on the  "average" device 
which is a CUA  (cell phone, organizer, etc.) is constantly growing - and 
that implementers of CAP on devices like that will probably implement on 
new models of devices, not retrofit it to their older ones

Tim Hare
Interested Bystander, Inc.