Subject: How do you get the METHOD property on a SEARCH

From: "Preston Stephenson" <[email-masked]>
Date: Thu, 03 Apr 2003 14:36:12 -0700

Was this discussed before and I just missed it?

I have two users with two CUA's, CUA1 and CUA2.

CUA1 creates a VEVENT with METHOD:REQUEST in CUA2's calendar.
How does CUA2 get the METHOD property with that VEVENT?
The search logic only returns VEVENT's.
How do you associate the METHOD with the VEVENT since it is outside the
VEVENT?

For example in section 6.1.1.18 there is the query:
   BEGIN:VQUERY
   QUERYID:Fetch VEVENT and VTODO iTIP components
   QUERY:SELECT * FROM VEVENT WHERE
   STATE() = 'UNPROCESSED'
   QUERY:SELECT * FROM VTODO WHERE
   STATE() = 'UNPROCESSED'
   END:VQUERY

The query would return the VEVENT's and the VTODO's.

Would you need to explicitly ask for each method type?

   QUERY:SELECT * FROM VEVENT WHERE
   STATE() = 'UNPROCESSED' AND METHOD = 'REQUEST'

Thanks.

Preston

PS
In the CAP spec there is an example in section 8.33 on the RESTRICTION
property:

   RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST'

VCALENDAR is not defined in the comp-name ABNF.

---

From: Dan Winship <[email-masked]>
Date: 04 Apr 2003 10:20:30 -0500

>    STATE() = 'UNPROCESSED' AND METHOD = 'REQUEST'

If I understand things correctly, that would mean "where *the VEVENT's*
METHOD is 'REQUEST'", which would be invalid because VEVENTs don't have
METHODs. So that won't work either.

-- Dan

---

From: [email-masked]
Date: Fri, 4 Apr 2003 15:45:22 -0500

> Was this discussed before and I just missed it?

Nope.

> How does CUA2 get the METHOD property with that VEVENT?

Interesting quandry.  The property you want/need is outside of the 
component you are SEARCHing for.

I had thought perhaps you'd just SELECT VEVENT FROM * WHERE 
STATE()="UNPROCESSED" and TARGET each CUAs calendar but I strongly think 
thats illegal given the text of Section 6.1.1.5:

Returns one of three values, "BOOKED", "UNPROCESSED", or "DELETED" 
depending on the state of the object. 

In this new case the object in question is the calendar and NOT any 
workflow component so it will have NO STATE.   The ABNF/ prose in 6.1.1.5 
does NOT preclude using STATE() for objects that are non-workflow (ie: 
Calendars, TZ info, Alarms, etc) and that will lead to some kind of 
problem unless clarified.

> How do you associate the METHOD with the VEVENT since it is outside the

"Ya can't get there from here!"

All of us need the ability to get the higher level properties associated 
with the VEVENT but I cant see how we get it.  Otherwise its impossible to 
tell a REPLY from a COUNTER from a REQUEST ...  Hmm...

> VCALENDAR is not defined in the comp-name ABNF.

Its actually there as VAGENDA.  (Calendar was already taken as the outter 
container marker so we made each calendar an 'agenda').

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: John Stracke <[email-masked]>
Date: Fri, 04 Apr 2003 16:11:09 -0500

> component you are SEARCHing for. 

Um...and so is any associated VTIMEZONE.  If the request contained a 
VEVENT and a VTIMEZONE, how do you find the VTIMEZONE?

-- 
/============================================================\
|John Stracke      [email-masked]                     |
|Principal Engineer|http://www.centive.com                   |
|Centive           |My opinions are my own.                  |
|============================================================|
|"God does not play games with His loyal servants." "Whoo-ee,|
|where have you *been*?" --_Good Omens_                      |
\============================================================/

---

From: Andrea Campi <[email-masked]>
Date: Mon, 7 Apr 2003 10:48:31 +0200

Hi all,

first of all: I'm replying considering just my experience and
my interpretation, I didn't check archives.

> The query would return the VEVENT's and the VTODO's.

This query looks appropriate to me, yes. I'd expect the CAP to
reply with something like:

BEGIN:VCALENDAR
METHOD:REQUEST
BEGIN:VREPLY
BEGIN:VEVENT
...
END:VEVENT
BEGIN:VEVENT
...
END:VEVENT
END:VREPLY
END:VCALENDAR

BEGIN:VCALENDAR
METHOD:REPLY
BEGIN:VREPLY
BEGIN:VEVENT
...
END:VEVENT
BEGIN:VEVENT
...
END:VEVENT
END:VREPLY
END:VCALENDAR

and so on.

So you have all the information you need; it's your choice how to
keep that information around.

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: [email-masked]
Date: Mon, 7 Apr 2003 10:21:50 -0400

> reply with something like:

So you expect that the meta information in the _original_ containing 
VCALENDAR of the VEVENT would be copied in to the _response_ containing 
VCALENDAR??

Would that apply ONLY to METHOD or would/should that apply to ALL 
properties?  Or did you forget that the QUERY was for VEVENTs and all 
their containing information and NOT for the VCALENDAR that the VEVENT was 
in which is where the METHOD property resides?

> keep that information around.

Um, the SELECT did not SELECT the contents of the VEVENTs outter 
VCALENDAR, just the contents of the VEVENT so unless there is some 
implicit "When you give me VEVENTs (or VTODOs, etc) then you also MUST 
return the other properties in the associated containing VCALENDAR" then 
what Preston asked for is not possible as CAP is currently written.

I would expect that the _response_ VCALENDAR would contain new properties 
and NOT all the properties of the original VCALENDAR. 

Also, would this apply to all types of objects or just to the core 
VEVENT/VTODO/VJOURNAL/VTIMEZONE/etc type ones?  For example, would the 
information of a containing VEVENT be automatically copied/inserted when 
my CUA queries for VALARMs that TRIGGER in the next 10 minutes?  It MAY be 
necessary to know something from the containing component...

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 07 Apr 2003 10:15:25 -0600

[email-masked] wrote:
> their containing information and NOT for the VCALENDAR that the VEVENT 
> was in which is where the METHOD property resides?

As METHOD belongs in the VCALENDAR, Andrea's reply is exactly
what I was going to post.

> what Preston asked for is not possible as CAP is currently written.

Yes it is and I think that Andrea's response is the only viable solution.
If you provide a query that returns multiple METHOD values, just reply
with multiple VALENDARs.

> I would expect that the _response_ VCALENDAR would contain new 
> properties and NOT all the properties of the original VCALENDAR.  

What *exactly* do you expect?

> my CUA queries for VALARMs that TRIGGER in the next 10 minutes?  It MAY 
> be necessary to know something from the containing component...

Did you have another proposal? As you know the PRODID and VERSION
may also be supplied in the VCALENDAR reply even when they are not
part of the original query.

-- 

  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: [email-masked]
Date: Mon, 7 Apr 2003 18:22:38 -0400

<CAUTION>
This may appear long but its because of the full sized examples.  If you 
skip over them and just read the text initially its not so bad.
</CAUTION>

> what I was going to post.

I think you missed the issue Preston pointed out so Ill try to show it 
graphically.  If I send you an invitation it would look like:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Bruces CUAs prodid
CMD:CREATE
METHOD:REQUEST
TARGET:PatsCalendar
TARGET:DougsCalendar
BEGIN:VEVENT
ORGANIZER;CN=Bruce Kahn:cap:[email-masked]
ATTENDEE;CN=Bruce Kahn;PARTSTAT=Accepted:cap:[email-masked]
ATTENDEE;CN=Pat Egen;PARTSTAT=Needs-Action:cap:[email-masked]
ATTENDEE;CN=Doug Royer;PARTSTAT=Needs-Action:cap:[email-masked]
DTSTART:20030407T180000Z
DTEND:20030407T190000Z
UID:[email-masked]
SUMMARY:Important Meeting on SEARCH Issue
SEQUENCE:5
DTSTAMP:20030407T120000Z
END:VEVENT
END:VCALENDAR

BTW: CAP says NOTHING about whether or not the entry is CREATEd with all 
the propeties sent or not so I assume that both Pat and Doug would get a 
copy like the playload above instead of some stripped down copy.

So when Doug goes and uses his CUA to send the SEARCH to find the any 
'unprocessed' entires he would use:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Dougs CUA's prodid
CMD:SEARCH
TARGET:DougsCalendar
BEGIN:VQUERY
QUERYID:Fetch new VEVENT messages
QUERY:SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED'
END:VQUERY
END:VCALENDAR

According to Andrea and Doug the response to the SEARCH command would be:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//The CSs prodid
CMD:REPLY
METHOD:REQUEST
TARGET:DougsCalendar
BEGIN:VREPLY
REQUEST-STATUS:2.0
BEGIN:VEVENT
ORGANIZER;CN=Bruce Kahn:cap:[email-masked]
Attendee;CN=Bruce Kahn;PARTSTAT=Accepted:cap:[email-masked]
ATTENDEE;CN=Pat Egen;PARTSTAT=Needs-Action:cap:[email-masked]
ATTENDEE;CN=Doug Royer;PARTSTAT=Needs-Action:cap:[email-masked]
DTSTART:20030407T180000Z
DTEND:20030407T190000Z
UID:[email-masked]
SUMMARY:Important Meeting on SEARCH Issue
SEQUENCE:5
DTSTAMP:20030407T120000Z
END:VEVENT
END:VREPLY
END:VCALENDAR

if I read them correctly.  There are a couple problems in achieving this 
though:

1: The METHOD property returned is copied from the VCALENDAR part of 
REQUEST message.  However it is NOT part of the VEVENT component; it is a 
property of the VEVENTs contaniner (the VCALENDAR component)!  As such it 
is NOT SELECTable in the SEARCH command if you scope the query to "FROM 
VEVENT".  The METHOD property data resides OUTSIDE the returned VEVENT and 
as such its not accessible given the rules in 6.1.1. CAL-QUERY Value Type.

2: Nowhere in CAP does it have prose that I read that indicates that some 
'related' or 'meta' data is automagically selected and put into the 
response.  That is, I found no prose that says the METHOD property is 
exempt from the rules and always copied into a SEARCH command response.

3: As John noted this quandry also applys to other components like a 
VTIMEZONE associated with the VEVENT.  If I had sent:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Bruces CUAs prodid
CMD:CREATE
METHOD:REQUEST
TARGET:PatsCalendar
TARGET:DougsCalendar
BEGIN:VTIMEZONE
TZID:US-Eastern
[snip, snip]
END:VTIMEZONE
BEGIN:VEVENT
ORGANIZER;CN=Bruce Kahn:cap:[email-masked]
Attendee;CN=Bruce Kahn;PARTSTAT=Accepted:cap:[email-masked]
ATTENDEE;CN=Pat Egen;PARTSTAT=Needs-Action:cap:[email-masked]
ATTENDEE;CN=Doug Royer;PARTSTAT=Needs-Action:cap:[email-masked]
DTSTART;TZID=US-Eastern:20030407T130000
DTEND;TZID=US-Eastern:20030407T140000
UID:[email-masked]
SUMMARY:Important Meeting on SEARCH Issue
SEQUENCE:5
DTSTAMP:20030407T120000Z
END:VEVENT
END:VCALENDAR

then just how would Dougs CUA be expected to get the VTIMEZONE data sent 
with my REQUEST?  Would it also be magically included? 

Would this magic also apply to PRODID so Doug could see the requestors 
(ie: my) CUAs PRODID?  What about other properties outside the VEVENT?? 
Where do we draw the invisible line???

Given the way we have defined the searching rules in 6.1.1 I think Preston 
found a real problem w/the searching mechanism.

> Yes it is and I think that Andrea's response is the only viable 
solution.

No it is not.  Nowhere in 6.1.1 does it say that properties OUTSIDE of the 
scoped container are returned or even selectable!  The METHOD property is 
part of the REQUESTs VCALENDAR, NOT part of the actual VEVENT.  You are 
assuming that because I can "SELECT * FROM VEVENT" to get all the 
properties within the VEVENT that it also applys to properties "ABOVE" or 
"PEER" to the VEVENT.  NOWHERE IN CAP DOES IT SAY THIS!

> What *exactly* do you expect?

Given the rules from Section 6.1.1 I would expect NO METHOD property on 
the response!

> part of the original query.

You totally missed the point.  All those properties are OUTSIDE the VEVENT 
what the QUERY is scoped to.  As such they are NOT available in the 
response!!

Bruce

---

From: Doug Royer <[email-masked]>
Date: Mon, 07 Apr 2003 17:01:38 -0600

> copy like the playload above instead of some stripped down copy.

"with all of the properties sent" - Why would you rip out any
properties sent?

> REQUEST message.  However it is NOT part of the VEVENT component; it is 
> a property of the VEVENTs contaniner (the VCALENDAR component)!

Yes.

 >   As such
> it is NOT SELECTable in the SEARCH command if you scope the query to 
> "FROM VEVENT".  The METHOD property data resides OUTSIDE the returned 
> VEVENT and as such its not accessible given the rules in 
> 6.1.1. CAL-QUERY Value Type.

So you are saying you do not want it fixed? If not do you have
a problem doing it that way? Or do you have a proposal?

> 2: Nowhere in CAP does it have prose that I read that indicates that 
> some 'related' or 'meta' data is automagically selected and put into the 

Which is why I responded that I'll update the text. Did not object
to the proposal? Or did I miss your proposal?

> with my REQUEST?  Would it also be magically included?  

Magic - no. Did you have another proposal?

--

---

From: Andrea Campi <[email-masked]>
Date: Tue, 8 Apr 2003 08:33:01 +0200

Hi,

I feel I already replied to most of your point so I'll just cover the 
one related to VTIMEZONE.

On Tuesday, April 8, 2003, at 12:22  AM, [email-masked] 
wrote:
> then just how would Dougs CUA be expected to get the VTIMEZONE data 
> sent with my REQUEST?  Would it also be magically included?  

Actually, I do expect VTIMEZONE to also be in the reply, yes. That's 
been a requirement ever since RFC2445. Note that a few months ago I 
asked exactly the same question (didn't sound sane to me to assume this 
much) and even proposed to make it an optional behavior. However, 
violating RFC2445 is not an option - and skipping VTIMEZONE in the 
reply would violate it.

Bye,
	Andrea

---

From: [email-masked]
Date: Tue, 8 Apr 2003 18:49:38 -0400

> > a property of the VEVENTs contaniner (the VCALENDAR component)!

And violating the rules of scoping is NOT good...  Even more so if its 
contrary to the draft!!

> So you are saying you do not want it fixed? 

Im saying that your answer was incorrect given the current CAP text.  If 
we want this behaviour then we have to clearly specify it (and thus we 
will need to change the text for CAL-QUERY)

And of course I want the protocol fixed (Im not the one who wants thinks 
its ready for Last Call and this just confirms it).  To me it was sounding 
as if you and Andrea did not think it was broken.

> Which is why I responded that I'll update the text. 

I did not see any proposal, merely your answer that doing this violation 
of scoping was how it would work in your view.  As Preston noted 
originally its NOT in CAP and thus needs fixing!

>                                                     Did not object
> to the proposal? 

Hmm, let me reread just your bits in your last message since I must have 
missed them the first time around:

Umm, nope, nothing there.

Err, not yet...

Nah, thats not one...

Hmm, thats all the bits you wrote last time and I dont see any actual 
proposal there.  Merely responses to the effect that "Thats how I expect 
it to work" rather than "We need to add prose to CAP to codify this!"

If I take them as some form of oddly worded proposal then I have some 
questions still:

Would this "all inclusive" reponse now include all super-container data in 
it or just merely some selective set?  That is, if I were to search 
"SELECT * FROM VALARM..." would/should I expect to get the original 
container structure back, like:

BEGIN:VCALENDAR
...
BEGIN:VEVENT
...
BEGIN:VALARM
...
END:VALARM
END:VEVENT
END:VCALENDAR

or just the contents of the immediate container its in (ie: just the 
VEVENT and all its properties)? 

Would this inclusion of 'external to the component' data be all inclusive 
or just selective?  That is, for the VEVENT case would it include ALL of 
the data in the containing VCALENDAR it came in or just some of it? 

Would "including all" mean all other components except those of the same 
container type (ie: if I sent 2 VEVENTs in 1 VCALENDAR, would you 
want/expect the 2nd VEVENT if the WHERE clause did NOT match because I 
searched by UID!) or is it the entire contents of the VCALENDAR object?

If the data included from the container object was some partial subset of 
the original data then just how would the CUA get to the rest of it (or 
even could it)?  Who decides which bits are copied and which are left out?

>                           Or did I miss your proposal?

You did not miss my own proposal because I did not present one.  I merely 
pointed out that Preston did indeed find a valid problem w/the way CAP is 
written compared to the expectations of some on how it should work.  I did 
however miss yours...

> Magic - no. Did you have another proposal?

Another?  I have yet to see any first proposal.  Dazzle me...

Bruce

---

From: [email-masked]
Date: Tue, 8 Apr 2003 19:22:08 -0400

Andrea replied on 04/08/2003 02:33:01 AM:
> been a requirement ever since RFC2445. 

Yes it is but that has no bearing on the CAP draft for accessing / 
searching.  There is NO mandate in 2445 on how CAP MUST or MUST NOT return 
data.  A payload in CAP can be a fragment of the entire entry, at least 
thats valid according to the ABNF and prose under 6.1.1.

The text in 6.1.1 NEVER describes the kind of scoping violations you 
suggested.  In fact they uniformly show the contrary!  The first example 
shows that a returned VALARM is NOT bundled inside its containing VEVENT 
even though to properly fire the VALARM needs info from that containing 
VEVENT.  Even the text below has NO mention of returning properties of the 
super-container:

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

The text puts limits the scoping.  There is nothing in the ABNF that 
indicates that properties/parameters from the containing object of the 
scoped object are even accessible, let alone returned.   I realize that 
what you replied is how you expect CAP to function but thats NOT how its 
specified.

>                                          Note that a few months ago I 
> much) and even proposed to make it an optional behavior. 

I was heads down for product end game for a couple months so I did not see 
your posting or the proposal.  Can you tell me at least the thread 
subject?  Also, did the WG pay any attention then?

>                                                            However, 

Im a little on the fence WRT applying stict 2445/2446 requirements for the 
SEARCH command.  Here is why:  If the requesting CUA wanted all the info 
it should ask for it.  In the VALARM example case in CAP:

SELECT VALARM FROM VEVENT WHERE UID = "123"
[snip]
As there is no '.' (dot) in the VALARM after the SELECT above:

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

the CUA clearly knows what it is looking for and only wants some partial 
information back.  However in order to properly fire the 'relative' alarms 
it MUST get the DTSTART (or DTEND) of the containing VEVENT so it SHOULD 
have requested "SELECT DTSTART,VALARM FROM VEVENT WHERE UID = "123"" so 
that it could properly fire the alarms. 

The CUA could have done the SEARCH in order to determine something about 
the alarms rather than try to fire them.  A CUA may want to do some kind 
of pared down SEARCH where it gets only partial info for its own use and 
as such the CS and CAP have no business coercing the data returned in the 
SEARCH. 

Now, NONE of this "allowance" to ignore 2445/2446 is applied on the other 
commands; JUST on the SEARCH command as its NOT part of workflow or strict 
PIM work, it has other uses/needs.  However this is a digression from the 
original point.  I need to go get some food so Ill have to find your other 
reply later...

Bruce