Subject: CAP 13: Bad CAL-QUERY example / description?

From: [email-masked]
Date: Wed, 2 Jun 2004 23:07:19 -0400

While trying to do a resync to CAP-13 I was reading the example 
descriptions (because as Frank loved to point out people will live by them 
as gospel) and I think I found an example in Section 6.1.1 CAL-QUERY Value 
Type that is wrong or Im just misreading it.  The example given is:

       (d) SELECT * FROM VEVENT

and the description that follows is:

       (d) Selects every property and every component
        that is in any "VEVENT" component, with each "VEVENT"
           component wrapped in a BEGIN/END VALARM tags.

I strongly suspect that the bit about wrapping in BEGIN:VALARM/END:VALARM 
is residual from a previous example that was to contrast the (c) case 
above it.  I think that everything after the ',' on the second line really 
should just be removed.  Or am I misunderstanding something?

The other example that I found seemingly incorrectly described is:

       (e) SELECT * FROM VEVENT WHERE
            VALARM.TRIGGER < '20020201T000000Z'
            AND VALARM.TRIGGER > '20020101T000000Z'

which is later described as:

       (e) Selects all properties and all contained
        components in all "VEVENT" components that have a "VALARM"
        component with a "TRIGGER" property value between
        the provided dates and times, with each "VEVENT"
           component wrapped in a BEGIN/END VALARM tags.

Again, Im not sure that the bits at the end about wrapping the VEVENT in a 
BEGIN:VALARM/END:VALARM are correct.   Again, I think that everything 
after the ',' on the last line should be removed.  Would that be a correct 
thing to do??

Bruce
PS: Why is the spacing skewed?  Isn't it supposed to be all left edge 
aligned when indented like that??
===========================================================================
Bruce Kahn                                INet: 
[email-masked]
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Warning: Dates in Calendar are closer than they appear.

---

From: Doug Royer <[email-masked]>
Date: Wed, 02 Jun 2004 23:00:28 -0600

>            component wrapped in a BEGIN/END VALARM tags. 

Fixed to say VEVENT tags. 

>            component wrapped in a BEGIN/END VALARM tags.

Fixed to say VEVENT tags. I left that in because in the past that was a 
question.
Should the properties be in the VREPLY, or inside of a VEVENT?  Inside the
VREPLY would make it difficult to parse separate vevent objects.

> aligned when indented like that?? 

Bug in XML->RFC. Those kinds of fixes will have to be hand edited in the 
final approved push to the IETF.

-- 

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: "Mike Higginbottom" <[email-masked]>
Date: Thu, 03 Jun 2004 14:31:03 +0100

> BEGIN:VALARM/END:VALARM are correct.   Again, I think that everything

I've been looking at exactly the same section this morning.  Are you  
following me Bruce?

I think replacing 'in a BEGIN/END VALARM tags' with 'in BEGIN/END VEVENT  
tags' would fix this in both cases d) and e).  Unless I'm misunderstanding  
something as well ;)

-- 
Regards
Mike Higginbottom

Paul Smith Computer Services
01484 855800
[email-masked]
www.pscs.co.uk

---

From: "Mike Higginbottom" <[email-masked]>
Date: Thu, 03 Jun 2004 16:08:57 +0100

> should just be removed.  Or am I misunderstanding something?

Changed my mind.  I think it should be:

         (d) Selects every property and every component
          that is in any "VEVENT" component, with each contained
             component wrapped in BEGIN/END tags.

This whole section seems confusing to me though.  What query do I need to  
get a list of all the BEGIN/END tagged VEVENTS in a VAGENDA?  SELECT  
VEVENT FROM VAGENDA would seem right.  What about without the BEGIN/END  
tags?  SELECT VEVENT.* FROM VAGENDA sounds good.  But what's the  
difference between that and SELECT * FROM VEVENT?

-- 
Regards
Mike Higginbottom

---

From: [email-masked]
Date: Thu, 3 Jun 2004 14:51:12 -0400

Mike wrote on 06/03/2004 11:08:57 AM:
> VEVENT FROM VAGENDA would seem right.

Actually that query would return to you all the VEVENTS and all their 
data, not a list of them.

>                                       What about without the BEGIN/END 
> tags?  SELECT VEVENT.* FROM VAGENDA sounds good. 

Hmm, thats the right query but it does point out something I was going to 
(You following me Mike??).  Doing that would effectively strip off all 
VEVENT 'wrappers' and blur all VEVENTs into 1 big stream.  Not very useful 
really since theres no way to separate them back out into separate 
VEVENTs.  The same concern applys to the (c) example in that same place:

       (c) SELECT VALARM.* FROM VEVENT

If there are multiple VALARMs on a single VEVENT then this would 
effectively strip away the BEGIN:VALARM/END:VALARM wrappers and mix those 
VALARM properties into the VEVENT properties.  There would be no way for a 
CUA to properly distinguish those VALARM properties from the VEVENT 
properties (had others been part of the SELECT clause) or to distingush 
the different VALARMs from each other.  Not a very useful thing to do in 
my mind. 

>                                                   But what's the 

This query will NOT strip away the BEGING:VEVENT/END:VEVENT wrappers for 
each VEVENT.  The other query would.  Thats the difference.  The former is 
not desirable (at least not that I can picture).  The latter example is 
desirable because it allows distinct parsing of each VEVENT properly.

So I guess the question of usefulness arrises from this.  Whats the use of 
(c) if it has the undesirable effect of bleeding multiple VALARMs into 1 
big mush of properties?  (The same can be asked of Mikes SELECT VEVENT.* 
FROM VAGENDA example...)

Bruce
Standard disclaimers apply, even where prohibited by law...

---

From: Doug Royer <[email-masked]>
Date: Thu, 03 Jun 2004 14:38:51 -0600

>
>
> So I guess the question of usefulness arrises from this.  Whats the 
> use of (c) if it has the undesirable effect of bleeding multiple 
> VALARMs into 1 big mush of properties?  (The same can be asked of 
> Mikes SELECT VEVENT.* FROM VAGENDA example...)

The example shows you what you get if you do that, for what ever reason 
you might want it.
I would agree that in most cases that is not what you want.

It answers the quetion, what property names are in any VEVENTs in my 
calendar.
If that is usful :-)

--

---

From: [email-masked]
Date: Thu, 3 Jun 2004 17:30:47 -0400

> I would agree that in most cases that is not what you want.

Out of curiosity, can anyone describe a case when you would want this 
(VEVENT.* or VALARM.*) as opposed to no ".*"?  If so, is it one we would 
see often?  If not, why did we have this feature?

> It answers the quetion, what property names are in any VEVENTs in my 

If thats the sole benefit / usage then I sure wish that there would be a 
much simpler and faster way than having my poor CUA sort thru all the data 
in my calendar using a brute force linear scan while cloging up my LAN and 
keeping the CS busy streaming all that mush.  %^|

Given that there is an example describing this already:

   SELECT VALARM.* FROM VEVENT WHERE UID = "123"

   Will return all of the properties in each "VALARM" component
   in the matching "VEVENT" component:

   TRIGGER;RELATED=END:PT5M
   REPEAT:4
   ...
   TRIGGER;RELATED=START:PT5M
   DURATION:PT10M
   ...
   ...

Id like to suggest we update the paragraph above to indicate that using 
VALARM.* (or any WIDGET.*) with multiple VALARMs (WIDGETs) is not 
particularly useful or that the results could not be accurately 
interpreted because the bounding wrappers are missing.  Something like:

   Will return all of the properties in each "VALARM" component
   in the matching "VEVENT" component.  If there are multiple
   "VALARM" components then the results will be an mix of all
   "VALARM" properties in one incoherent stream of data such as:

Finesse it as you will but the point is to indicate that amalgumated 
results are not really useful as there is no way to safely rebundle them 
up in any meaningful way.  Perhaps that kind of text would belong to the 
#7 bullet item text just above the example instead...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Thu, 03 Jun 2004 16:26:20 -0600

[email-masked] wrote:

> (VEVENT.* or VALARM.*) as opposed to no ".*"?

Please read the rest of my reply - where I did.

--

---

From: [email-masked]
Date: Thu, 03 Jun 2004 22:49:10 -0400

It seems to me that some of the queries we are discussing allow us to get 
only properties with no component context,  or expect the CUA to maintain 
the context as it awaits the result of the query, i.e., Store the event 
that I'm finding the VALARMs for, then query for the VALARMs and relate the 
results to the stored event. Isn't this opening up huge possibilities for 
errors and mixed-up data (as someone pointed out merging all of the VALARMS 
or VEVENT properties into one big thing has little purpose)?  With the 
complexity of CAP the last thing I'd want to do would be introduce 
ambiguity like that.

It seems to me that a component should be the "atomic" element retrieved 
for queries, and the CUA should do its own parsing/query of properties to 
find out more of the details, but that's just my opinion. I would like to 
go back and read some of the QUERY development process in the archives - 
does anyone have a guess about what timeframes this was taking place?

Thanks
Tim Hare
Interested Bystander, Non-Inc.

>Please read the rest of my reply - where I did.

Tim Hare
Interested Bystander, Non-Inc.

---

From: Doug Royer <[email-masked]>
Date: Thu, 03 Jun 2004 23:24:27 -0600

[email-masked] wrote:

> ...does anyone have a guess about what timeframes this was taking place?

Queries evolved over the last several years. There is not one single 
time frame.

--

---

From: [email-masked]
Date: Fri, 4 Jun 2004 10:44:18 -0400

> Please read the rest of my reply - where I did.

I did read your entire post and I took it to be more a tongue in cheek 
example rather than a pratical usage example.  Sorry if my follow up wasnt 

> It answers the quetion, what property names are in any VEVENTs in my 

It _could_ be useful if I needed to know "Is there a X-Hinkey-Minkey on 
any VEVENT in my calendar?" but I dont think thats a common need really or 
even necessary actually given most queries would just use "*" or can list 
any desired properties on the SELECT and then see what comes back. 

Put another way: Why should I care if it exists on any entry anywhere in 
the calendar when I can easily tell by simply looking for it on any VEVENT 
when I retrieve it normally?  Knowing it exists on a component _somewhere_ 
in the calendar is not that useful as it does not tell me on which one(s) 
and if I needed to just see those kinds of entries I simply use that as 
part of my WHERE clause to begin with...  (SELECT * FROM VEVENT WHERE 
X-HINKEY-MINKEY IS NOT NULL)

Given most queries would typically be of the form:

        SELECT * FROM VEVENT WHERE UID = "123"

to get a specific VEVENT or like:

        SELECT VEVENT FROM VAGENDA WHERE STATE() = 'UNPROCESSED'

to get unprocessed requests, is there any _practical_ use for VALARM.* or 
VEVENT.* that Im just not groking?? 

BTW: The "This does not fetch any components" part above is inaccurate. It 
actually fetches them ALL but combines them into one long massive stream 
of data.  There has been nothing said about 'unwrappering' sub-components 
like VALARMs so I would expect them to be still wrappered in the 
amalgamated stream of VEVENT (and VTODO and VJOURNAL and VTIMEZONE and 
VQUERY and ... ) mush.

Bruce

---

From: [email-masked]
Date: Fri, 4 Jun 2004 10:55:03 -0400

> does anyone have a guess about what timeframes this was taking place?

Pat has an online Full Text indexed copy of the WG archive going back to 
1996 when the WG was created.  I dont have the URL she posted but it 
should be available here or you can poke her in case shes not following 
this thread.  That should allow you to full text search the archives for 
phrases like "VEVENT.*" or whatever.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 04 Jun 2004 09:50:57 -0600

[email-masked] wrote:

> example rather than a practical usage example.  Sorry if my follow up 
> wasn't that clear.  From the previous reply:
>
> It _could_ be useful if I needed to know "Is there a X-Hinkey-Minkey 
> on any VEVENT in my calendar?" but I dont think thats a common need 
> really or even necessary actually given most queries would just use 
> "*" or can list any desired properties on the SELECT and then see what 
> comes back.  

I think it is a very much needed feature. Have you looked at all of the 
custom X- properties
and specific sub-sets of iTIP objects that are coming back? As I learn 
them I add the
ability for the CUA to use them, or translate their features at run time 
into CAP properties
or x- properties that I use, when they overlap. Just check out how 
people define
time zones with special property names as one example.

When getting a VCALEDNAR object back from a random source. The only way
to figure out which set of x- properties they use, is to scan for 
properties and figure it out.
I have generated several compliant VCALENDAR objects that crash popular 
CUAs.
So I translate them into what the CUA can handle. Try pointing several 
of the CUAs
that exist at a full featured CAP VCALENDAR object, I have been able to 
crash
all of the CUAs so far that I can find with various valid objects.

The real solution is more RFCs on how to do specific things, but for now 
they
all seem to be using valid (or nearly valid) iCal objects that are mostly
compatible with each other. At this point run time checking is the only 
way to determine
what you will be getting before trying to use the data.

---

From: [email-masked]
Date: Fri, 4 Jun 2004 15:12:34 -0400

> time zones with special property names as one example.

It may be useful for doing a "find me all properties and subcomponents 
that exist in this container" but I strongly doubt that its something done 
on a regular basis.  It can be useful for debugging or protoyping purposes 
but not for normal CU day to day actions.

Besides why do you care if if appears _anywhere_ in _any _ component when 
those properties will _always_ be returned as part of the normal "Give me 
this VEVENT" SEARCH:

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: TARGET:BrucesRelCal
   C: CMD:SEARCH
   C: BEGIN:VQUERY
   C: QUERY:SELECT VEVENT FROM VAGENDA WHERE UID = [email-masked]'
   C: END:VQUERY
   C: END:VCALENDAR

would result in:

   S: BEGIN:VCALENDAR
   S: TARGET:BrucesRelCal
   S: CMD:REPLY
   S: BEGIN:VREPLY
   S: BEGIN:VEVENT
   S: DTSTART;TZID="Eastern":20040602T090000
   S: DTEND;TZID="Eastern":20040602T130000
   S: TRANSP:TRANSPARENT
   S: DTSTAMP:20040604T181825Z
   S: CLASS:PRIVATE
   S: DESCRIPTION:Join us on Wednesday June 2nd for a presentation 
   S:  and  watch the new Shrek 2 movie! 
   S: SUMMARY:Demo Seminar and Movie
   S: LOCATION:AMC Burlington 10
   S: ORGANIZER;CN="Bruce Kahn":mailto:[email-masked]
   S: UID:[email-masked]
   S: X-Hinkey-Minkey:Some special value
   S: END:VEVENT
   S: END:VREPLY
   S: END:VCALENDAR

The CUA is going to get _all_ the properties in the VEVENT so again I 
think this is only beneficial to developers who want to be able to do some 
form of data scanning; not that they can _interpret_ the results, just 
they can _see_ it.

So again Ill ask what real benefit is there to the CU in being able to do 
a "give me all the properties that appear in an VEVENT in the calendar in 
a mush" dump on any kind of basis?  I seriously doubt its useful to the 
end CU; it sounds more like something useful to developers only and only 
for occasional use even then.   However even this kind of dump can be 
achieved thru other means that are just as simple (SELECT * FROM VEVENT) 
so again _what_ is the benefit in having the component.* in the query 
language??

Looking at it from a slightly different perspective, the only noticable 
difference between:

SELECT VEVENT.* FROM VAGENDA

and

SELECT VEVENT FROM VAGENDA

is just the 22 octets that make up the BEGIN:VEVENT / END:VEVENT wrappers 
of each VEVENT that would be returned.  Well, that and the fact that the 
data from the former case is not actionable by the CUA but the data from 
the latter case actually is.  So where is there any real benefit??

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 04 Jun 2004 14:24:16 -0600

> that exist in this container" but I strongly doubt that its something 
> done on a regular basis.  It can be useful for debugging or protoyping 
> purposes but not for normal CU day to day actions.

It is used every time I load a calendar from an unknown source. One 
vendor has
two modes it uses timezones and both with the same PRODID. Not all 
properties are in all objects
even when they are the same type.

The feature is documented. And works. And even if you do not want to use 
the feature
it appears from this conversation that you did understand from  CAP  
what that
feature does when called. So it does not fall into the bug, broken, 
typo, or grammer category.
And I thought that feature changes were off topic and we were into get 
CAP done mode.

--

---

From: [email-masked]
Date: Fri, 4 Jun 2004 18:02:23 -0400

> It is used every time I load a calendar from an unknown source.

Im not sure where you are finding many calendars "from an unknown source" 
but doing a "full property and subcomponent mush" extraction of all 
properties and subcomponents is NOT something you really should be doing 
every time.  It just doesnt scale well, especially if there is lots of 
data in the calendar.   Hmm, perhaps this is why it looks different, the 
wrappers have been stripped away.

Plus, in case you missed it in my reply, you only save 22 octets per 
subcomponent by having the CS remove the top most container wrapper. Thats 
hardly a big justification for this feature give the hassles it causes 
with multiple subcomponents (ie: multiple VALARMs or multiple VEVENTs) 
being all mushed together. 

> feature does when called. 

I fully get the technical aspects of the bits Im questioning.  Im 
questioning their actual pratical use / benefit.  Just because you have 
protoyped up code based on the current text does not mean that its the 
correct thing to have in CAP.

Having the CS strip off the BEGIN/END markers has 2 effects:

1: It saves a mere 22 octets of data per subcomponent being returned and
2: Causes the data belonging to all subcomponents to bleed together into a 
mush that makes separate subcomponent identification and use impossible

Please show me how this is useful.

> And I thought that feature changes were off topic and we were into get 

This thread has evolved into a questioning of the CAP design from my 
original question.  Asking questions of the design is still allowed in the 
WG last I checked.  By now it should be simple enough to give a good 
justification for everying in CAP; otherwise it has not been properly 
thought out and clearly described. 

Given the 2 points above I find it hard to say that this was fully thought 
out and this part may need some reworking (or simplification).  Perhaps 
this is an artifact of our backtracking from using SQL as the query lingua 
(as evident by the column / table phrasing in Section 6.1.1 still). 
Perhaps its an artifact of having so many editors over time that some 
things just did not make it into the current text like they should have.

If the "component.*" concept was removed from 6.1.1, you can _still_ get 
all your data from all the unknown sources you want.  It would just be a 
few octets longer AND all subcomponents would be fully parsable, 
separatable and usable.  How would that be bad?? 

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 04 Jun 2004 16:30:32 -0600

> Im not sure where you are finding many calendars "from an unknown source"

Hint - from other CUA's that I did not write.

--

---

From: [email-masked]
Date: Sat, 5 Jun 2004 09:11:41 -0400

Here's the link.  It may be a few months behind - I'll put a new copy out 
there next week.

http://www.egenconsulting.com/ietf/ietfcns.nsf

[email-masked] 
Sent by: [email-masked]
06/04/2004 10:55 AM

To
[email-masked]
cc

Subject
Re: CAP 13: Bad CAL-QUERY example / description?

Bruce

---

From: [email-masked]
Date: Mon, 7 Jun 2004 10:07:18 -0400

> Hint - from other CUA's that I did not write.

Thanks for clarifying that non-question.  I dont think I could have 
figured that out ever.  BTW: I was questioning _what_ you consider "an 
unknown source" in the _runtime_ environments that a customer / end user 
(not you personally Doug) will be in but I didnt think I had to clearly 
define that.  Mea culpa, sorry...  (Please dont try to clarify that now; 
lets try to stay focused on the technical questions if we can shall we.)

How about addressing the actual questions / issues that were in the rest 
my posting?

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 07 Jun 2004 09:44:34 -0600

[email-masked] wrote:

>
>
> How about addressing the actual questions / issues that were in the 
> rest my posting? 

I did not see any new questions that had not already been answered.

--

---

From: [email-masked]
Date: Mon, 7 Jun 2004 16:59:54 -0400

> I did not see any new questions that had not already been answered.

There was 1 question and one non-direct question that have not been 

> 2: Causes the data belonging to all subcomponents to bleed together 
> into a mush that makes separate subcomponent identification and use 
impossible
> Please show me how this is useful. 

To make it a formal question then; Can anyone please show me how this is 
really useful?

The undiscussed/unanswered question:

> If the "component.*" concept was removed from 6.1.1, you can _still_
> get all your data from all the unknown sources you want.  It would 
> just be a few octets longer AND all subcomponents would be fully 
> parsable, separatable and usable.  How would that be bad?? 

In the interest of saving time and merging this thread with the other one 
about "*.*" I have a proposal that will:

A: Resolve any ambiguity related to the usefulness of "component.*" vs 
"component" on searches
B: Allow for property discovery without the need for full contained 
component retrieval.
C: Remove the undefined "*.*" special case need for some containers that 
matches the (semi) defintiion of "*" in Section 6.1.1
D: Remove the useless case of returning subcomponent data without the 
BEGIN/END wrappers.

Given:

1: There are times when a CUA wants to perform property _discovery_ 
instead of actual property _processing_ (implicitly described by Doug 
although never actually addressed in CAP text) and
2: The lack of subcomponent BEGIN/END wrappers saves a mere 22 octets BUT 
results in an unprocessable mush of subcomponents and properties and
3: There is at least one ambiguity/conflict between the use of "*" and 
"*.*" in the current text 

I propose we make the following simple changes to CAP that will address 
and resolve all the questions/issues found to date:

        (A) We remove any concept of "component.*" vs "component" in CAP 
(essentially bullet item 7 in Section 6.1.1).  Whenever a subcomponent is 
requested, it will ALWAYS result in that entire subcomponent being 
returned intact (wrappers NOT removed).  In the SELECT clause, there never 
should be a "component.*" or "*.*" usage necessary.

        (B) To simplify things, we define the use of "*" in the SELECT 
clause to only refer to properties or entire containers.  We change bullet 
7 to Section 6.1.1 that says:

        7. When the "SELECT" clause of the query contains an "*" value, 
contained 
           components are not automatically included in the returned 
results.  Only
           those properties found in the component in the FROM clause (or 
the
           implicit container in the case of VCALSTOREs and VAGENDAs) are 
returned.
           If the requestor wants contained components to be included in
           the returned results, they need to expressly request the 
desired
           contained component(s) (or all of them) using the proper 
"INCLUDE"
           clause.  Contained components are always returned with their 
           BEGIN/END markers intact so that component integrity is 
maintained 
           and no mismatching of properties will accidentally occur.  To 
indicate
           all contained components should be included, the value of "*" 
should
           be used in the "INCLUDE" clause of the query.  To indicate all 
properties
           but no contained components should be returned, no "INCLUDE" 
clause would
           be used in the query.
        8. When the "SELECT" clause of the query contains a contained 
component,
           the entire contained component is returned along with its 
BEGIN/END
           markers so that component integrity is maintained and no 
mismatching of
           properties will accidentally occur.

        (C) We slightly change the cal-query ABNF to allow the requestor 
to simply and direclty indicate which subcontainers they want, if any.  We 
also remove the questionable ability to SELECT subcomponet values only. 
        We change the ABNF to:

     cal-query  = "SELECT" SP cap-val SP
               [ "INCLUDE" SP cal-include SP ]  ; ONLY occurs when the 
"SELECT" cap-val contains an "*" value
               "FROM" SP comp-name SP
               "WHERE" SP cap-expr

             / "SELECT" SP cap-cols SP
               [ "INCLUDE" SP cal-include SP ]  ; ONLY occurs when the 
"SELECT" cap-val contains an "*" value
               "FROM"   SP comp-name

     cap-val  = cap-cols
           / param
             / ( cap-val "," cap-val )

     cap-cols = cap-col-select 
           / ( cap-cols "," cap-col-select) 
           / "*"

     cap-col-select    = comp-name
                       / cap-prop

     cal-include  = all   ; This value indicates ALL subcomponents are 
desired
             / comp-name    ; This value indicates a particular desired 
subcomponent
             / ( cal-include "," comp-name) ; This value indicates a list 
of desired subcomponents

        to reflect that the CUA now clearly indicates if they want any 
subcomponents or not and which ones even (so its not an "all or nothing" 
deal). 
        "all" is already defined elsewhere in CAP ABNF. 
        Also, the ability to use subcomponent properties in "WHERE" 
clauses is still intact.  This means that you can still use queries like 
that of (e) in Section 6.1.1 without actually having to retreive the 
VALARM too.

        (D) We remove the text in CAP that special cases "*.*" for 
VCALSTORE and VAGENDA since it is no longer necessary with the above 
changes.

Thoughts / comments / feedback?

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 07 Jun 2004 15:39:49 -0600

[email-masked] wrote:

> To make it a formal question then; Can anyone please show me how this 
> is really useful? 

I made no argument that it was or was smaller per object.

> > parsable, separatable and usable.  How would that be bad??  

You forgot embedded object are included in the other form. MUCH more 
that 22 octets per object.

And again it works as documented, is it really worth rewriting simply 
becuase you want
it another way? What is your justification for wanting to change this at 
this late date?

--

---

From: [email-masked]
Date: Fri, 11 Jun 2004 12:19:38 -0400

> that 22 octets per object.

Please show me how I forgot embedded objects?  I fully took into account 
subcontainers and preserving their integrity when returning them so they 
would be intact and useable. 

When using component names in the SELECT clause, they are to be returned 
with wrappers intact. 

When using "SELECT *" and an INCLUDE clause, the specified subcontainers 
are returned with wrappers intact.

Nowhere in any current CAP text did it say that all wrappers for nested 
subcontainers are to be stripped away.  That is, nowhere does it say that:

would result in all VALARMs in all the VEVENTS would be returned without 
the BEGIN/END wrappers.  Go recheck bullet #7, it only talks about the 
given components wrappers.

> this late date?

Im not sure if this is a case of miscommunication of the issues, 
personality conflict or the normal vendor desire to get something RFCd out 
so products can be shipped so Ill opt for the first one and try again.

There are ambiguities and questionable cases in the query language that I 
think should be resolved before we go to Last Call.  "Works as documented" 
does not address the ambiguities or justify seemingly useless aspects of 
the query language.

The core issues I have are simply put:

1: Component integrity is not always preserved.  There has been no 
justification given for the component-name.* use in the SELECT clause.  It 
results in data that is all mushed togther and not useable as returned.
2: There are "special cases" in CAP that result in different formats 
returning the same data.  So far there has been no reason given for why we 
need the special cases really.

I want to have a query language thats clear, concise and unambiguious. 
That is why I made my proposal.  The changes are not that drastic as you 
would make it sound and I think they even simplify things.

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 11 Jun 2004 11:40:31 -0600

>
> 1: Component integrity is not always preserved.

So you say. EXACTLY HOW?

>  There has been no justification given for the component-name.* use in 
> the SELECT clause.  It results in data that is all mushed togther and 
> not useable as returned.
> returning the same data.  So far there has been no reason given for 
> why we need the special cases really. 

Simply not true.

--

---

From: [email-masked]
Date: Fri, 11 Jun 2004 15:07:35 -0400

> > 1: Component integrity is not always preserved.

Go reread my previous posts in this thread for citations and examples.  I 
wont repeat them here ad infinitum.

> > why we need the special cases really. 

Actually it is true.  I have based all my points on actual CAP text and 
included relevant citations.  Please feel free to go and check them for 
accuracy and make corrections if I missed something.

Please show us how removing the BEGIN/END markers so that all properties 
and subcontainer properties are mixed together in an unusable is _not_ 
true?  One only has to try an actual example to see how useless this is. 

Try a VEVENT with 3 VALARMs: a display, an email and an audio alarm.  The 
VALARM ATTENDEE, ATTACH, DURATION, DESCRIPTION and SUMMARY properties of 
each VALARM will be freely mixed in with each others and those of the 
VEVENT making them inseparable in any meaningful way.  I am now strongly 
inclined to believe that this "component.*" concept is residual from the 
original SQL query modeling and serves no productive purpose in CAP-QL.

Please show us where in CAP it actually defines "*" in the SELECT clause 
as meaning "all properties and subcontainers" or "all properties and no 
subcontainers".

Please show us where in Section 6.1.1 where it gives an special meaning to 
"*" on VAGENDAs and VCALSTOREs thats different from other containers.

Now that I reread 6.1.1 in greater detal, please show how bullet item 4 in 
Section 6.1.1 does NOT actually prohibit querying for subcomponents?  That 
is, "SELECT DTSTART,DTEND,VALARM FROM VEVENT WHERE UID = [email-masked]'" 
is illegal by:

   4.  Everything in the "SELECT" clause and "WHERE" clauses in MUST BE
       from the same component type, or "VAGENDA" component OR
       "VCALSTORE" component in the "FROM" clause.
 
My proposal is intended to fix up all these ambiguities and unspecified 
things so that query behaviour is clear and consistant for all containers. 
 (Actually I just noticed that bullet #4 bit now and didnt address it but 
I think we should...)

Bruce

---

From: Doug Royer <[email-masked]>
Date: Fri, 11 Jun 2004 14:04:43 -0600

[email-masked] wrote:

> Go reread my previous posts in this thread for citations and examples. 
>  I wont repeat them here ad infinitum. 

I consider this thread closed. I see no new points raised and I have not 
been convinced that it is any
more than a disire to get something changed that you do not like. You 
have said that you and your
company are not implemeting CAP, has that changed?  Everyone that I 
personally know that
is impleminting CAP have proposed no changes in this area.  We seem to 
be able to parse
it and implment it.  There is at least one company that is (or soon will 
be) shipping a CAP
product based on the drafts, yet they can make it work. I do not see 
this as a technical
problem with the spec. The missing ABNF will be fixed, other than that 
it seems to work.

--

---

From: Ted Hardie <[email-masked]>
Date: Mon, 14 Jun 2004 09:07:53 -0700

Given the discussion on these points, I believe it would be appropriate
to have the chairs make the determination that the issues raised
have been resolved.  Until the chairs declare the issue closed, I believe
it should remain open, so that others may comment.  I encourage
others to comment on the issues raised and the proposed resolution.

Please also note that one is not required to implement a specificaiton to
be an effective reviewer; in my own experience, folks who are not
steeped in the code often find both doc bugs and assumption issues
that those who are steeped in the code miss.

			regards,
				Ted Hardie
				co-Area Director, Applications

At 2:04 PM -0600 6/11/04, Doug Royer wrote:
>>Go reread my previous posts in this thread for citations and 
>>examples.  I wont repeat them here ad infinitum.
>
>I consider this thread closed. I see no new points raised and I have 
>not been convinced that it is any
>more than a disire to get something changed that you do not like. 
>You have said that you and your
>is impleminting CAP have proposed no changes in this area.  We seem 
>to be able to parse
>it and implment it.  There is at least one company that is (or soon 
>will be) shipping a CAP
>problem with the spec. The missing ABNF will be fixed, other than 
>that it seems to work.
>
>--
>
>Content-Type: application/x-pkcs7-signature; name="smime.p7s"
>Content-Disposition: attachment; filename="smime.p7s"
>Content-Description: S/MIME Cryptographic Signature
>
>Attachment converted: Macintosh HD:smime 193.p7s (    /    ) (0017ED25)

---

From: "RL 'Bob' Morgan" <[email-masked]>
Date: Wed, 16 Jun 2004 16:27:49 -0700 (PDT)

As Ted points out, when an issue is contentious it is the chairs who will
declare closure after seeking consensus.  I think the reasonable
interpretation of Doug's comment is that he sees no consensus to change
the document at this time based on Bruce's comments.  The chairs are
inclined to agree with that view, even though we understand Bruce's
points.  If no other implementors (or other reviewers) are prepared to
support the position that these constructs need to be changed or removed,
then they will stand as written, at least for purposes of producing a
last-callable CAP document; so please comment *now* if you want to see
changes.  We are inclined to think that the discussion indicates a need
for actual response data along with the example queries in this section,
to clarify what the response is supposed to be (and maybe support the
"mush" point of view).  But we won't ask the editor to make that change
unless others also think it would be useful.

 - RL "Bob" and Pat

---

From: Harrie Hazewinkel <[email-masked]>
Date: Fri, 18 Jun 2004 09:54:39 +0200

> even when they are the same type.

This looks like, virtual hosting. I start wondering and thinking of
the need for this. This can be done with the VCALSTORE or the
hostpart in the CALID. I think it is dangerous to use for instance a
timezone in order to choose a different set of features. In the
long-term this is not providing inter-operability, but non
inter-operability.

Maybe it could be wise to make a draft for this (or include it).

> And I thought that feature changes were off topic and we were into get 

Understanding the draft well, I believe a GET-CAPABILITY could be used 
for this. Although, modifications are needed. It may also be useful, to
indicate which properties are required by the CS for instance.

An example discovered by trying to synchronize a telephone with a
CAP server (telephone <-SYNCML-> syncserver <-CAP-> CAP server).
The telephone does not support the UID property, but implicitly
expresses it be some other means outside the VEVENT. This is sufficient 
for the communication between the telephone and sync server. While
transfering the VEVENT to the CAP server it refused the new VEVENT
due to the missing UID property.
I have no real way of learning this in the sync server. Asking for
a complete list of supported properties is not the same, since it does
not tell me if it is required.
For this example one can say, "but the UID property is required by
the protocol definition". Yes, I agree, but it is applicable for
other properties.

Harrie

---

From: Doug Royer <[email-masked]>
Date: Fri, 18 Jun 2004 08:18:57 -0600

Harrie Hazewinkel wrote:

>
> Doug Royer wrote:
>
>>
>>
>>>
>>> It may be useful for doing a "find me all properties and 
>>> subcomponents that exist in this container" but I strongly doubt 
>>> that its something done on a regular basis.  It can be useful for 
>>> debugging or protoyping purposes but not for normal CU day to day 
>>> actions.
>>
>>
>>
> This looks like, virtual hosting. 

No. It has nothing to do with virtual hosting. It has to do with not all 
implementations comply with the RFC's.
The time zone text  was just one example.

--