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

From: Andrea Campi <[email-masked]>
Date: Tue, 8 Apr 2003 09:14:53 +0200

I just noticed that I mistakenly had sent the following to Bruce only.

Bye,
	Andrea

Begin forwarded message:

> From: Andrea Campi <[email-masked]>
> Date: Mon Apr 7, 2003  11:25:52  PM Europe/Rome
> To: [email-masked]
> Subject: Re: How do you get the METHOD property on a SEARCH
>
> Hi Bruce,
>
> On Monday, April 7, 2003, at 04:21  PM, [email-masked] 
> wrote:
>> Andrea wrote on 04/07/2003 04:48:31 AM:
>> > 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
>>
>> 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?
>
> Well, I'd expect the VCALENDAR to contain:
>
> PRODID and VERSION as stated by RFC2445
> METHOD as stated by RFC2446
> CMD and TARGET as stated by draft CAP
>
> After all, a reply containing unprocessed components wouldn't be valid 
> iTIP without corresponding METHOD properties, would it?
>
>>
>> > So you have all the information you need; it's your choice how to
>> > 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.  
>
> On the contrary, it sounds to me the above assumption is implicit in 
> iTIP. CAP doesn't state how exactly are you supposed to store the 
> METHOD for each VEVENT, but I'm sure that when you try to read them 
> back again you want to retrieve the original METHOD. To do this, I see 
> no other way then use iTIP.
>
> My view on this is that the METHOD property is sort of an additional 
> property of the VEVENT which happens to be transmitted in a special 
> way. In other words: I'm not sending the METHOD from the original 
> VCALENDAR, I'm grouping the resulting VEVENTs and synthesizing the 
> enclosing VCALENDAR(s).
>
>> 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...
>
> Now that's a good question. However, I'd say that's for (a future 
> update to) iTIP to answer, as we're doing nothing more than applying 
> iTIP here?
>
>
> Let me add that I do share your worries on these items, as I'm sure 
> I've mentioned before; it all sounds tricky and hard to digest. 
> However, over the months I reached the conclusion that there's a sense 
> after all (not that I'd doubted it, with all the smart guys who've 
> been working on this); but I still think we could use some more 
> examples, especially non-trivial ones.
>
> Bye,
> 	Andrea