Subject: Re: What good are stored VQUERYs?

From: [email-masked]
Date: Wed, 4 Dec 2002 17:43:03 -0500

Andrea wrote on 11/19/2002 06:49:29 AM:
> Once again, I don't see the problem. If the CUA sends:
> 
> BEGIN:VQUERY
> QUERY:SELECT VQUERY FROM VAGNEDA WHERE NAME = 'MAGIC01'
> ENV:VQUERY
> 
> The CS replies:
> 
> BEGIN:VQUERY
> QUERYID:MAGIC01
> END:VQUERY
> 
> I don't see why you think it should be an error (although it would 
require
> an ABNF change) - the CS has the query so it sends what it has. It just
> happens to be unable to represent it in CAP-QL. 

But the CS _DID_ represent it in CAP-QL.  It just happens that the CAP-QL 
is 'empty' and thus not really presentable to the CU. 

The VQUERY is just a name, no actions or anything that can be used to 
present or describe it to a CU.  As such this appears to be 'useless'; the 
knowledge that MAGIC01 is a canned non-CAP-QL query exists only at the CU 
level (above the CUA since there are no name spaces for VQUERYs to 
distinguish a CUAs MAGIC01 query from your CUA/CSs canned MAGIC01).

I would prefer some CS response to retrieving the non-CAP-QL encodable 
query like "505 - Server unable to encode the requested data" since this 
is also more useful going forwards in any expansion to CAP we design later 
on.

>                                                 Incidentally, that's the
> reason why a few months ago I proposed we added a way to specify the 
VQUERY
> is hardcoded in the CS and can't be represented in CAP-QL.
> 
> BEGIN:VQUERY
> QUERYID:MAGIC01
> NATIVE:YES   (NATIVE is just an example, you can choose a better name)
> END:VQUERY

Kind of like the predefined VCARs but different in that its unencodable 
(currently) such that a CUA can retrieve it...  I think Id prefer that all 
data be encodable (even if its by adding new properties, components, etc) 
rather than taking a flag approach as a CUA may still want to be able to 
retrieve and present the MAGIC01 query to the CU; after all we dont have 
namespaces on them so we could get into a hairy mess when your CUA uses 
MAGIC01 to my CS and a totally different action happens that is 
expected...

> This would make clear to a CUA that it is looking at a valid VQUERY, but
> nothing is know about its implementation - so the CUA had better know 
what
> to do with it or leave it alone.

We would need some kind of name space for this to work.  See above.

> Also, do you really expect all CUAs to retrieve the VQUERY before 
calling
> it? Then what, do a string compare of the QUERY? It would be even less
> useful then.

As part of building a sync engine ALL components will have to be 
representable in a format that can be retrieved and pushed between 2 
stores.  Otherwise it wont be able to sync fully and opening the door for 
VQUERYs only is just inserting a tiny wedge that allow for justification 
of other non-encodable representations to develop in the future.  Bad 
joss...

> I agree that CAP should allow storing any component. Of course, an 
actual CUA
> implementation should not expect to be able to store components the 
server
> doesn't list as supported in GET-CAPABILITY.

I concur w/the "expect" bit.  I would hope that a CS would try to store 
unknown components in some blobular way such that the CS (Calendar 
_Store_) can act as a true Store for newer data w/o having to actually 
grok it fully.  Nowhere does it say in CAP that a CS needs to be able to 
decypher the intent/meaning of a component; it only talks about how it 
should be represented for querys, etc.  This has an implicit "any blob 
will work" mentality but thats just my take on the text.

> > IMHO there should be no data put into the CS by ANY means 
(Administrative 
> > or not) that cannot be retrieved and/or encoded using the CAP 1.0 or 
> > updated iCalendar specs.  Otherwise it just becomes a recipe for 
disaster.
> 
> I agree. It just happens to have no QUERY property, so what? It's still
> legal, so you can retrieve it.

If the 'native' querys are not encodable in a VQUERY then they cannot be 
returned in one obviously.  As such another means is necessary; a VQUERY2 
or possible some other query mechanism and represenation.  In any case I 
think we are pretty much in agreement on this and the other issues.

> > response to the "SELECT VQUERY FROM VAGENDA ..." command.  I would not 

> > expect a CUA to use a VQUERY that it cannot read from the CS, would 
you?? 
> > (I like to practice Save Hex...)
> 
> That's a CUA choice. In controlled environments (the CUA knows it can
> trust the CS), it would be safe. Remember that I'm talking about 
hardcoded
> VQUERY, so no malicious CUA could change them.

If the CUA got back the 'empty' VQUERY you had at top then its not 
unlikely that a CU may see that there is nothing in the query and try to 
either delete it or modify it for their use.  The CUA _could_ prohibit 
this but again this gets back to the name space issue we have not 
addressed...

> Since I seem to be the only one to defend it, I have no problem with 
taking
> stored queries away and doing it properly in another draft. However, 
this
> requires thinking NOW about how the new draft will extend the current
> model.

The replacement design would be to expressly codify how a CS deals with 
new component types (ie: VQUERY2 for stored queries that do wildcards, 
etc).  That way any work that follows CAP that can deal w/useful stored 
queries wont be encumbered by a poor CAP design.  (I feel Im overlooking 
something else here w/this change but Im tired so Ill let Andrea or Doug 
point it out.)

> Will it change or extend VQUERY? Then we might need to check VQUERY 
> ABNF (I think
> QUERY should be optional).
> Will it introduce a new component? But all commands take VQUERY, so I
> won't be able to send a SEARCH using VQUERY2...

Hmm, there is a way to make this expansion savy but it requires a layer of 
wrapping OR some ABNF tweaking for the query format.  That is, we select 
based on a VQUERY component that can have subcomponents that augment or 
supercede the query of the VQUERY.  Alternately we could have a 
QUERYVERSION in the VQUERY to distinguish the kind of query it contains 
and make sure the ABNF allows for expansion (ie: wildcarding, etc)...

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: Andrea Campi <[email-masked]>
Date: Thu, 5 Dec 2002 10:23:14 +0100

I don't have much time at hands right now, so I'll only briefly
reply to parts of your email...

> We would need some kind of name space for this to work.  See above.

Well, we have something like that; at least, we had a proposal which
several people including Doug agreed to. See
<[email-masked]> from Patrice Lapierre
<[email-masked]> and followups.  I have no idea why this
wasn't integrated in the draft.

The idea is to add a TARGET property when operating with stored queries,
to indicate where you want to store or fetch the query from.

Don't you think this would address your objections?

> will work" mentality but thats just my take on the text.

I concur this is a desirable behavior, and one which would make
extensibility much much easier. However, if this is the expected
behavior, there should be something to that effect in the draft. I see
nothing like that currently.

> this but again this gets back to the name space issue we have not 

Personally, if my CS and my CUA both know that
cap://cap.example.com/inet.it-stored-queries, then I'd write my CUA so
that it doesn't show the CU anything about queries stored there. IMO this
is just a form of an RPC so it's internal to the CUA and CS couple. This
is useful if you have exclusive control of both; or if the stored queries
are standardized.

> new component types (ie: VQUERY2 for stored queries that do wildcards, 
[...]
> wrapping OR some ABNF tweaking for the query format.  That is, we select 

I need to think more about this; I'm too busy ATM. Maybe we should
find a way to discuss this more in depth between a few of us in a more
interative way...

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, 05 Dec 2002 11:25:17 -0700

> wasn't integrated in the draft.

In the ABNF:

              ; 'queryid' is OPTIONAL but MUST NOT occur
              ; more than once. If the "TARGET" property
              ; is supplied then the "QUERYID" property
              ; MUST BE supplied.
              ;

and later below the ABNF:

    For a search, if the "TARGET" property is supplied in a "VQUERY"
    component, then the CS is to search for the query in the calid
    supplied by the "TARGET" property value.

    For a create the "TARGET" property MUST NOT be supplied as the
    destination container is already supplied in the "TARGET" property of
    the "VCALENDAR" component.

-- 

  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: Andrea Campi <[email-masked]>
Date: Fri, 6 Dec 2002 09:52:40 +0100

>    supplied by the "TARGET" property value.

Sorry Doug, I must have overlooked it. Thanks for pointing out.

Bye,
	Andrea

---

From: [email-masked]
Date: Fri, 6 Dec 2002 16:36:10 -0500

>     supplied by the "TARGET" property value.

Ok, I may be a bit rusty on the drafts finer details but if the normal 
structure of the CAP command is basically:

BEGIN:VCALENDAR
PROID:/HandCraftedWithLove
VERSION:2.0
CMD:<SOME_COMMAND>
TARGET:RELCALID01
BEGIN:VQUERY
...
END:VQUERY
END:VCALENDAR

where the inner BEGIN/END varies by whats being created in the TARGETs 
then wouldn't a SEARCH just need the TARGET in the 'outer' layer instead 
of having one inside the VQUERY.  That is, why is:

BEGIN:VCALENDAR
PROID:/HandCraftedWithLove
VERSION:2.0
CMD:SEARCH
TARGET:RELCALID01
BEGIN:VQUERY
QUERY:SELECT DTSTART,DTEND,SUMMARY,UID
 FROM VEVENT
 WHERE DTEND >= '19990310T080000Z'
 AND DTSTART <= '19990310T190000Z'
 AND STATE() = 'BOOKED'
END:VQUERY
END:VCALENDAR

good enough to get say, "objects on March 10,1999 between 080000Z and 
190000Z" (no TARGETs inside the VQUERY) but to use a 'named query' I would 
have to use:

BEGIN:VCALENDAR
PROID:/HandCraftedWithLove
VERSION:2.0
CMD:CREATE
TARGET:RELCALID01
BEGIN:VQUERY
QUERYID:VOODOO1
TARGET:RELCALID01
END:VQUERY
END:VCALENDAR

if I stored the QUERY?  Why isnt the TARGET from the VCALENDAR sufficient 
to find the VQUERY in RELCALID01?  There can only be 1 QUERYID:VOODOO1 in 
RELCALID01 right??  What am I missing here?  Would the TARGET in the 
VCALENDAR ever be different from that of the VQUERY??

Hmm, are you trying to use a stored VQUERY from a someone elses calendar, 
is that it??

>     the "VCALENDAR" component.

This I grok and agree with...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 06 Dec 2002 17:04:27 -0700

> if I stored the QUERY?  Why isnt the TARGET from the VCALENDAR 
> sufficient to find the VQUERY in RELCALID01?

Only when the stored query is in the current TARGET. The VQUERY
TARGET is for when it is not - I'll update the draft to say
that TARGET is used in the VQUERY when the stored QUERY is not
in the CMD-TARGET.

> Hmm, are you trying to use a stored VQUERY from a someone elses 
> calendar, is that it??

Yes - see this WG list over the last few months.

--