Subject: Re: an idea as an alternative to stored queries

From: [email-masked]
Date: Mon, 1 Dec 2003 11:37:40 -0500

Doug replied on 11/28/2003 03:20:58 PM:
>                               Ether the CUA knew what XXX
> did or not. Ether you were allowed (by VCAR like any other
> component) to modify it, remove it, add one, or not.

You neglect to take into account that a CU may use different CUAs and each 
may have their own expectation of what XXX does depending on who coded 
them (or if XXX was changed by a different CUA or other means).

As such, just because CUA-1 'knows' that XXX performs a particular action 
does not mean it will always be so and unless CUA-1 can retrieve and 
confirm this by existing means then a change by CUA-2 may different 
behaviour for the same CU depending on what CUA they are using.  For 
example, your PDA may have one expecation while your desktop CUA may have 
another.  This is not goodness.

So if CUAs are coded to rely on things they cannot retrieve and look at 
using CAP such as unencodable in CAP actions or queries then this 
expecation that the CUA 'knows' what XXX does is fundamentally flawed and 
bad.

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: Doug Royer <[email-masked]>
Date: Mon, 01 Dec 2003 12:04:11 -0700

[email-masked] wrote:

> You neglect to take into account that a CU may use different CUAs and 
> each may have their own expectation of what XXX does depending on who 
> coded them (or if XXX was changed by a different CUA or other means). 

Your declaration of what I take into account is false.

> As such, just because CUA-1 'knows' that XXX performs a particular 
> action does not mean it will always be so and unless CUA-1 can 
> retrieve and confirm this by existing means then a change by CUA-2 may 
> different behaviour for the same CU depending on what CUA they are 
> using.  For example, your PDA may have one expecation while your 
> desktop CUA may have another.  This is not goodness.
>
> So if CUAs are coded to rely on things they cannot retrieve and look 
> at using CAP such as unencodable in CAP actions or queries then this 
> expecation that the CUA 'knows' what XXX does is fundamentally flawed 
> and bad. 

If you put XXX into your calendar:
        don't tweak it if it will break you or your CUAs.
        If you do not want other to be able tweak XXX, put in a VCAR to 
stop them.

If you did not put XXX into your calendar
     don't tweak it if you do not know what it does.
     If it has a decreed VCAR, you can't tweak it anyway.
     If you do not like it, and you have permission, delete it.

This is NO different than any other component. If you tweak a VEVENT
and add a RRULE, and your other CUA can not handle RRULE's, it is not
the protocols fault and has no moral (bad) implications.

-- 

Doug Royer                     |   http://INET-Consulting.com
-------------------------------|-----------------------------
[email-masked]                 | Office: (208)520-4044
http://Royer.com/People/Doug   |    Fax: (866)594-8574
                               |   Cell: (208)520-4044

               We Do Standards - You Need Standards

---

From: John Stracke <[email-masked]>
Date: Mon, 01 Dec 2003 14:18:18 -0500

Doug Royer wrote:

> the protocols fault

This is entirely different.  With a stored query, there is no hope of 
knowing what the query does.

-- 
/=====================================================\
|John Stracke      [email-masked]              |
|Principal Engineer|http://www.centive.com            |
|Centive           |My opinions are my own.           |
|=====================================================|
|"The Reality Check's in the mail." --L. Peter Deutsch|
\=====================================================/

---

From: Doug Royer <[email-masked]>
Date: Mon, 01 Dec 2003 14:34:41 -0700

> knowing what the query does.

Fetch it and look just like any other component.

--

---

From: John Stracke <[email-masked]>
Date: Mon, 01 Dec 2003 16:55:37 -0500

Doug Royer wrote:

> John Stracke wrote:
>
>> With a stored query, there is no hope of knowing what the query does.
>

But part of the point of stored queries is that you're supposed to be 
able to do things that can't be done in the query language.  (Right?) 
Given that, there's nothing to fetch.

Besides, the only reliable strategy would be to fetch it every time you 
connect; that's not going to save you anything over sending it every time.

---

From: Doug Royer <[email-masked]>
Date: Mon, 01 Dec 2003 16:38:41 -0700

> Given that, there's nothing to fetch. 

No. A dynamically created query is not the same thing as an undefineable 
query.

Today a fetch of a hypthotecial 'CELL-VENDOR-NAME-TODAY' could
return  a VQUERY containing:

    ....where RECURRENCE-ID < 20031202T000000Z
         AND RECURRENCE-ID > 20031201T000000Z

Tomorrow a fetch of that same VQUERY could return
one containing:

    ....where RECURRENCE-ID < 20031203T000000Z
         AND RECURRENCE-ID > 20031202T000000Z

How that dynamically stored VQUERY is inserted into your calendar
and dynamically altered depending on the time/TZ is not a CAP issue,
it is an implementaiton issue.

> Besides, the only reliable strategy would be to fetch it every time 
> you connect; that's not going to save you anything over sending it 
> every time.

No.  If your cell phone needs 'get-vevents-only-for-today' and you tweak
that VQUERY and change the VEVENT to VJOURNAL's, then you
busted the query yourself, it is not a protocol issue, don't do that.

Cell phones do get me XXX queries now (not using CAP however) and the
cell phone can not change what is returned or tweak the contents of the
query and do not need to download the query each time.
Stored queries allow for cell phones to use CAP.

--

---

From: Tim Hare <[email-masked]>
Date: Mon, 01 Dec 2003 19:55:08 -0500

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.

---

From: Doug Royer <[email-masked]>
Date: Mon, 01 Dec 2003 18:58:18 -0700

Tim Hare wrote:

>
> Your stored query named "CELL-VENDOR-NAME-TODAY"  would need to 
> contain strings such as $CURRDATE and $CURRDATE+1 

No.

--

---

From: Doug Royer <[email-masked]>
Date: Mon, 01 Dec 2003 19:19:04 -0700

Tim Hare wrote:

> ...

> 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.

Yes, but not needed. The CS could just return this instance in times version
of the query.

> 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.) 

> A) option 2 would _also_ allow cell phones to participate in CAP 

If everyone could agree what is needed and what they did.
Examples:

    I do not support VJOURNAL, I do not want to pay transfer those.
    Do not transfer attachments.
    Do not transfer DESCRIPTION
    ...

--