Subject: QUERY * TARGET * METHOD

From: Andrea Campi <[email-masked]>
Date: Wed, 4 Sep 2002 18:55:22 +0200

Hi all,

what happens if I send:

   C: Content-Type: text/calendar
   C:
   C: BEGIN:VCALENDAR
   C: VERSION:2.0
   C: PRODID:-//someone's prodid
   C: CMD:SEARCH
   C: TARGET:relcal2
   C: TARGET:relcal3
   C: BEGIN:VQUERY
   C: QUERY:SELECT * FROM VEVENT
   C: QUERY:SELECT * FROM VTODO
   C: END:VQUERY
   C: END:VCALENDAR

I should get back one component per TARGET, one component per METHOD
and one component per QUERY - in what order? I would expect the order
I mentioned, right? Note that this IS relevant, as the returned
data doesn't contain any mention of the TARGET it comes from.

Bye,
	Andrea

-- 
Andrea Campi                              mailto:[email-masked]
I.NET S.p.A.                              http://www.inet.it
Direzione Tecnica - 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: Wed, 04 Sep 2002 12:12:29 -0600

> data doesn't contain any mention of the TARGET it comes from.

One object (see 9.1.4 for details) per TARGET, each
object can contain multiple components, as long
as they are all the same METHOD.

In: 9.1.4 CREATE Command

	...
   Response:

   One iCalendar object per TARGET property MUST BE returned.

   The REPLY of any "CREATE" command is:

   ...

And 9.1.4 CREATE Command

 Seems this needs to be moved to "9.1 CAP Commands (CMD)"
 and applied to all commands:

	...
   When there are multiple TARGET values in the original command object
   then the replies MUST BE in the exact same order as they were
   provided to the CS.  The same is true for the objects created, their
	...

---

From: Andrea Campi <[email-masked]>
Date: Thu, 5 Sep 2002 12:26:03 +0200

> as they are all the same METHOD.

Yes, that's the easy case, and *I AM* looking at 9.1.4. You didn't
answer the query, but maybe I wasnt't clear, so I'll provide an
example to what I think will be returned for the above query:

   S: Content-Type: text/calendar
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.0
   S: PRODID:-//someone's prodid
   S: CMD:REPLY
   S: TARGET:ralcal2
   S: BEGIN:VREPLY
....
   S: END:VREPLY
   S: END:VCALENDAR

   S: Content-Type: text/calendar
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.0
   S: PRODID:-//someone's prodid
   S: CMD:REPLY
   S: TARGET:ralcal2
   S: METHOD:REQUEST
   S: BEGIN:VREPLY
....
   S: END:VREPLY
   S: END:VCALENDAR

   S: Content-Type: text/calendar
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.0
   S: PRODID:-//someone's prodid
   S: CMD:REPLY
   S: TARGET:ralcal2
   S: METHOD:REPLY
   S: BEGIN:VREPLY
....
   S: END:VREPLY
   S: END:VCALENDAR

   S: Content-Type: text/calendar
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.0
   S: PRODID:-//someone's prodid
   S: CMD:REPLY
   S: TARGET:ralcal3
   S: BEGIN:VREPLY
....
   S: END:VREPLY
   S: END:VCALENDAR

   S: Content-Type: text/calendar
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.0
   S: PRODID:-//someone's prodid
   S: CMD:REPLY
   S: TARGET:ralcal3
   S: METHOD:REQUEST
   S: BEGIN:VREPLY
....
   S: END:VREPLY
   S: END:VCALENDAR

   S: Content-Type: text/calendar
   S:
   S: BEGIN:VCALENDAR
   S: VERSION:2.0
   S: PRODID:-//someone's prodid
   S: CMD:REPLY
   S: TARGET:ralcal3
   S: METHOD:REPLY
   S: BEGIN:VREPLY
....
   S: END:VREPLY
   S: END:VCALENDAR

Where inside each of the VREPLY component, you have all matching
objects for all the queries, handled as a union.

Is this right?

>    provided to the CS.  The same is true for the objects created, their

I agree, both sentences should be moved.

Bye,
	Andrea

---

From: Doug Royer <[email-masked]>
Date: Thu, 05 Sep 2002 08:48:51 -0600

> example to what I think will be returned for the above query:

Yes. And the objects for the same TARGET that have the
same method could be in the same MIME object. So some
of the text/calendar replies could have multiple VCALENDARS
and some with a single VCALENDAR. 

> objects for all the queries, handled as a union.

'Union'? If you mean one right after the other - yes.

---

From: Andrea Campi <[email-masked]>
Date: Thu, 5 Sep 2002 18:14:15 +0200

> and some with a single VCALENDAR. 

Sorry? Objects for the same TARGET with the same METHOD would be all
inside a single VCALENDAR, I expect. Or do you mean objects for the
same TARGET with the same METHOD, but coming from different queries?

> 'Union'? If you mean one right after the other - yes.

Well, section 6.1.1 says:

#  When multiple QUERY properties are supplied in a single VQUERY component, the results returned are the same as the results returned for multiple VQUERY components having each a single QUERY property and the results are return in the same order as the VQUERYs were specified in the original command.

So I guess you are right, it's not a boolean union operation (by the
way, what happens if two queries match the same object? Is it returned
twice?).

Bye,
	Andrea

---

From: Doug Royer <[email-masked]>
Date: Thu, 05 Sep 2002 11:28:30 -0600

Andrea Campi wrote:
> inside a single VCALENDAR, I expect.

OR - they could each be in a separate VCALENDAR in the same
MIME object - iCalendar allows both, so CAP would need
to expect both.

> Or do you mean objects for the same TARGET with the same METHOD,
> but coming from different queries?

No.

> #  When multiple QUERY properties are supplied in a single VQUERY
> component, the results returned are the same as the results returned
> for multiple VQUERY components having each a single QUERY property and
> the results are return in the same order as the VQUERYs were specified
> in the original command.
> 

I would say Yes.

---

From: Andrea Campi <[email-masked]>
Date: Fri, 6 Sep 2002 12:41:53 +0200

> MIME object - iCalendar allows both, so CAP would need

Sorry but I don't agree. It's not an issue of data format, rather,
this is about the semantics of the SEARCH command (and the others, too).
As long as the resulting data is valid under iCalendar, it's CAP that
must dictate how the reply to the command; and I do agree with the
people who said on the list that it's not good to have different ways
of doing things.

The issue at hand is easy, and could be formulated as: if I send one
VCALENDAR object containing 1+ commands, what should I expect to get
back?
Ideally, it would be good to say: one.
Less ideally, the answer is: one per METHOD times one per TARGET.
Now you are saying the answer is actually "how many the server wants
as long as iCalendar rules are respected"??

Again, I don't think this point can be left as a generic "you can do
anything iCalendar permits". Since in iCalendar there's no such thing
as a command nor a reply, it's up to CAP to define this aspect, and
we can and should define it unambiguously.

Bye,
	Andrea

---

From: Doug Royer <[email-masked]>
Date: Fri, 06 Sep 2002 10:05:16 -0600

> as long as iCalendar rules are respected"??

Same with iMIP - nothing new.

> we can and should define it unambiguously.

With iMIP you can now get one VCALENDAR per MIME object with
multiple CALENDARS in that single MIME object or you could get
multiple MIME objects, each with one VCALENDAR.

Some iMIP implementations can support multipart/<valid> and
others do not. Sometimes you will get multipart/<valid> and
other times you will get separate MIME objects each with
a single body part.

It is not something new.

Currently their is no place that says that that a CUA must
or must not implement multipart/<valid>. So the ambiguity
remains. 244[567] ignored this issue. Now we have to live
with the fact that those are all valid iCalendar objects
in implementations. Which is why I want the 'MULTIPART:...'
capability property in CAP (and I have not seen any objections).

However the single or multiple VCALENDAR objects per MIME object
is not optional. It is explicitly allowed in 2445.

And what is the end effect difference to the calendar - 'nothing'.
All of the VCALENDAR objects must be processed as they come in.
No matter how many or few are in each MIME object.

---

From: John Stracke <[email-masked]>
Date: Fri, 06 Sep 2002 12:55:46 -0400

Doug Royer wrote:

>remains. 244[567] ignored this issue.
>
That's because, in iMIP, it wasn't an issue; a CUA was bound up with a 
MIME-compliant MUA, which was required to support multipart.  But a CAP 
CUA is not (necessarily) an MUA.

> Now we have to live
>in implementations.
False.  There are iMIP implementations that send multipart messages (and 
one, MS Entourage, that does it wrong), but that's irrelevant to CAP. 
 The only case in which one might try to claim it was relevant would be 
an iMIP implementation that used CAP for its backend.  But, in such a 
case, although the iMIP implementation is required to support multipart 
(since it's a MIME MUA), there is no need for it to be able to send that 
multipart up to the CS--indeed, it would be absurd, since the multipart 
probably contains non-iCalendar body parts.  Instead, it should take the 
text/calendar body part and send it to the CS.

>Which is why I want the 'MULTIPART:...'
You most certainly have.  I have repeatedly objected to the notion of 
supporting both multiparts and multiple VCALENDARs.  They are 
functionally equivalent, and there is no need to complicate 
interoperability by specifying both of them.  We have to pick one or the 
other.

I would lean towards multiple VCALENDARs, because a CUA probably 
contains a general-purpose text/calendar parser, which is required to 
cope with multiple VCALENDARs.  However, it is not a given; it would be 
possible to define CAP as using a profile of text/calendar, and 
forbid multiple VCALENDARs in messages transmitted over CAP.  Saying 
that CAP has to be able to support any conceivable iCalendar is like 
saying that SMTP has to be able to carry 8-bit data simply because TCP 
can carry 8-bit data.

-- 
/=================================================================\
|John Stracke      [email-masked]                        |
|Principal Engineer|http://www.centivinc.com                      |
|Centiv            |My opinions are my own.                       |
|=================================================================|
|"How can one conceive of a one party system in a country that has|
|over 200 varieties of cheese?" --Charles de Gaulle               |
\=================================================================/

---

From: Andrea Campi <[email-masked]>
Date: Fri, 6 Sep 2002 19:48:08 +0200

> Same with iMIP - nothing new.
[...]
> multiple MIME objects, each with one VCALENDAR.
[...]
> capability property in CAP (and I have not seen any objections).
[...]
> No matter how many or few are in each MIME object.

Bah, I don't agree. A CAP server is not an iMIP store and forward
mechanism, a server can and will manipulate objects. A server with
an SQL backend can filter and sort objects in a much more efficient
way than a client, so it does make a huge difference whether my
client can expect the data to be in a meaningful order instead of
having to get all data and then sort it again one way or another.

And I surely read objections to the multipart idea, on the
same basis on which I am objecting now: iMIP and other drafts are
tools we should use, but when more than one option is available,
we can and should use the simplest one which fits the bill. And if
there are multiple ways to do the same thing, at the very least CAP
should really go into more details in explaining the alternatives,
or I can tell you we WILL have interoperability problems if a vendor
misses just one of the many alternatives.

Anyway, this is my opinion, but since it doesn't seem to be very
popular, I will now shut up until things change.

---

From: Doug Royer <[email-masked]>
Date: Fri, 06 Sep 2002 14:53:43 -0600

Andrea Campi wrote:
> mechanism, a server can and will manipulate objects.

I agree - and I never said that it was a store and forward
mechanism. 

I said that they will each get processed in order. It makes
no difference.