Subject: BEEP and CAP - one-to-many

From: Doug Royer <[email-masked]>
Date: Wed, 13 Mar 2002 10:45:02 -0700

As CAP can not mandate the BEEP payload boundaries, this needs to
be deleted from CAP-07:

 > 3.1 BEEP Exchange Styles
 >
 >   [BEEP] defines three styles of message exchange:
 >
 >      MSG/ANS,ANS,...,NUL: for one-to-many exchanges.
 >
 >      MSG/RPY: for one-to-one exchanges.
 >
 >      MSG/ERR: for requests the cannot be processed due to an error.
 >
 >
 >   A CAP request, targeted at more than one containers, MUST use a one-
 >   to-many exchange, with a distinct answer associated with each target.
 >   CAP request targeted at a single container MAY use a one-to-one
 >   exchange or a one-to-many exchange.  "MSG/ERR" MAY only be used when
 >   an error condition prevents the execution of the request on all the
 >   targeted calendars.

---

From: Patrice Lapierre <[email-masked]>
Date: 13 Mar 2002 15:17:42 -0500

> As CAP can not mandate the BEEP payload boundaries, this needs to

  I don't understand, the section does not specify how messages 
may be partitioned into multiple frames (this is clearly handled
internally and is dependent on the transport service).

  The section simply states when one-to-many exchanges are to be 
used (e.g., in our case when a command refers to more than one 
target).

  ASAIK a profile must indicate what exchange style is to be 
used. Section 5.1 of RFC3080 (Profile Registration Template) 
does have distinct sections for one-to-one exchanges and 
one-to-many exchanges.

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Mar 2002 14:43:01 -0700

> used (e.g., in our case when a command refers to more than one 

I can't speak to the BEEP profile. But according to RFC3081, BEEP
on a TCP connection selects the window sizes, and thus the
MSG or ANS/NUL replies when a MSG does not fit in a TCP window.

It makes no difference to the CUA or CS. They just process
iCalendar objects - however it might get them from BEEP, iMIP,
or any iTIP object. If I give BEEP a 10M iCalendar object, that
is all I can do. BEEP decides if it is going to use MSG or
ANS/NUL - not CAP

Plus, it is not a true statement. Some of the commands
return multiple targets with one iCalendar object result.
We say you can do that, but only when all of the METHODs
are the same. The only time there has to be multiple iCalendar
objects is when the METHOD changes. iTIP allows that, so
CAP MUST allow that.

---

From: Patrice Lapierre <[email-masked]>
Date: 13 Mar 2002 17:27:35 -0500

> MSG or ANS/NUL replies when a MSG does not fit in a TCP window.

I think that you are confusing the concept of frames and with 
different ANS.

Suppose the server wants to return a 10M iCalendar object, 
the message may indeed be divided as follows:

   RPY 1 23 * seq1 size1
      Part 1 of the 10M object
   END 

   RPY 1 23 * seq2 size2
      Part 2 of the 10M object
   END

   ...

   RPY 1 23 . seqn sizen
      Last part of the 10M object
   END   

All message types can be divided, that is the purpose of 
the '.' or '*' in the header.  The use of ANS/NUL vs RPY 
has nothing to do with the window size.

---

From: Marshall Rose <[email-masked]>
Date: Wed, 13 Mar 2002 14:34:43 -0800

> is all I can do. BEEP decides if it is going to use MSG or

you are confusing "one-to-one" and "one-to-many" which are exchange styles with segmentation that deals with whether a message (MSG, RPY, ERR, ANS, NUL) is sent as one frame or many frames.

MSG, RPY, ERR, ANS and NUL may be segmented into multiple frames. depending on the API you use, this may be done transparently or explicitly.

however, segmentation has nothing to do with one-to-one or one-to-many exchanges. absolutely nothing.

the choice of whether an exchange is one-to-one or one-to-many is up to the profile specification. BEEP doesn't care about how large the MSG, RPY,ERR, or ANS is. it will segment as needed.

/mtr

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Mar 2002 15:52:35 -0700

> 
> you are confusing "one-to-one" and "one-to-many" which are exchange 

> styles with segmentation that deals with whether a message

> (MSG, RPY, ERR, ANS, NUL) is sent as one frame or many frames.

So are you saying that if I send a HUGE attachment, that
CAP can mandate that it only send a single MSG that exceed the
window size? That is what CAP says, as I quoted in my original
message that started this thread.

> MSG, RPY, ERR, ANS and NUL may be segmented into multiple frames.

> depending on the API you use, this may be done transparently or explicitly.
> however, segmentation has nothing to do with one-to-one or one-to-many

> exchanges. absolutely nothing.

The text in CAP says that CAP decides if it is going to be MSG or ANS/NUL.
Are you saying that CAP can say that no matter what the payload size,
that you MUST send the data in on MSG?

You sent email on this before and only said "it is obvious", perhaps
you can be explicit this time - thanks.

---

From: Doug Royer <[email-masked]>
Date: Wed, 13 Mar 2002 15:56:14 -0700

> has nothing to do with the window size.

Yes, perhaps I am confused with RPY.

However we still can't limit iCalendar objects as separate
just because of BEEP when iTIP allows them, so the section
needs to be deleted and each section can specify any limit
it needs. The only iTIP limit is when the METHOD changes.

---

From: Marshall Rose <[email-masked]>
Date: Wed, 13 Mar 2002 16:11:38 -0800

> message that started this thread.

yes. it doesn't matter how large it is. it will get segmented as needed.

> you can be explicit this time - thanks.

first, what you say "MSG or ANS/NUL" makes no sense. presumably, you meant to say "RPY or ANS/NUL".

second, CAP can send a reply as either a RPY or (zero or more ANSs followed by NUL). the RPY and the ANS can be any size. the choice between RPY and ANS is about partial results, not payload size.

/mtr

---

From: Patrice Lapierre <[email-masked]>
Date: 14 Mar 2002 09:27:59 -0500

> it needs. The only iTIP limit is when the METHOD changes.

Sorry, I don't understand your point. What do you mean by 
limit iCalendar objects as separate? Can you provide a 
concrete example that demonstrates how CAP breaks iTIP?

---

From: Doug Royer <[email-masked]>
Date: Thu, 14 Mar 2002 10:42:39 -0700

> concrete example that demonstrates how CAP breaks iTIP?

What is the technical reason for adding this restriction to iCalendar
objects? If I can iMIP an object with multipart/related, why can't
I use CAP to transport it?

---

From: Patrice Lapierre <[email-masked]>
Date: 14 Mar 2002 13:31:27 -0500

On Thu, 2002-03-14 at 12:42, Doug Royer wrote:
> objects?

  A difference between a single RPY and ANS,ANS,...ANS/NUL is
that partial results (several ANS) can be send "simultaneously".

  An implementation could take advantage of this as follows: 
when performing a search command on n TARGETs, several searches
could be started parallel and the results of each individual 
target can be returned as they become available (i.e., no need
to queue all of them).

> If I can iMIP an object with multipart/related, why can't

You CAN! There is nothing in section 3.1 that prevents 
you from transporting a multipart/related object with 
CAP.

---

From: Doug Royer <[email-masked]>
Date: Thu, 14 Mar 2002 14:27:40 -0700

> that partial results (several ANS) can be send "simultaneously".

No, not simultaneously, they MUST still be sent in the same order
as the TARGETs were supplied. If we remove that restriction
on ordering then each reply would have to be on a separate channel
in order for it to be realy simultaneous, they would just be
in random order.

I Thought that we had agreed that you MAY get them in separate
replies, but you can also get them all together. 3.1 seems
to contradict that agreement.

> target can be returned as they become available (i.e., no need

Currently the objects in the reply must be in the TARGET order of the
original request. This restriction was placed in CAP as a result
of a debate in the past where some vendors  did not want
to be forced to re-assemble or wait for  all of the objects.
They wanted to get everything all at once. So we agreed that
the responses must be in the same order as the request.

This I think was related to the creation of the max-component-size
capability (then property) that would limit the object size
in that reply. Its not going to do any good to send a 1MB object
in 10K chunks, if it can only support 500K of data. These thin
clients wanted "all or nothing" in the replies.

Which reminds me - do we want the CUA to send the CS the CUAs limits?

> you from transporting a multipart/related object with 

What if it contains the entire QUERY reply in ONE mime object
for multiple TARGETs? It sounds to me as if 3.1 is saying
that I can never create such an multipart/related object.

If that is not the intent, then how about we add something
like:

   Unless the reply is a multipart/{related, alternate, ...<whatever>
   MIME object when the CS MAY return multiple iCalendar objects
   in one RPY that might or might not contain the results from
   a multiple TARGET query.

---

From: Patrice Lapierre <[email-masked]>
Date: 14 Mar 2002 18:22:27 -0500

On Thu, 2002-03-14 at 16:27, Doug Royer wrote:
...
> in order for it to be realy simultaneous, they would just be

See RFC3080 Section 2.6.1 [Asynchrony] Within a Single Channel,
frames from different ANS may be interleaved.  You may argue that 
this is "not really simultaneous", but then neither is communication 
on different channels if they share the same socket.

> to contradict that agreement.

The only related discussion, that I can remember, was about 
multiple QUERY properties within a VQUERY, that is different.

It now seems that the only point we disagree in section 3.1 is
the MUST in the sentence:

   A CAP request, targeted at more than one containers, MUST use a 
   one-to-many exchange, with a distinct answer associated with 
   each target.

Would you be OK with keeping the section, and simply transforming
it into a MAY

    A CAP request, targeted at more than one containers, MAY use a 
    one-to-many exchange, with a distinct answer associated with 
    each target.

> Which reminds me - do we want the CUA to send the CS the CUAs limits?

I would definitely think so, it was present in the previous drafts.

Draft-06 had the "max-results" and "max-size" elements (MAXSIZE and
MAXRESULT properties in draft-05).

---

From: Doug Royer <[email-masked]>
Date: Thu, 14 Mar 2002 16:58:20 -0700

>     one-to-many exchange, with a distinct answer associated with 

Yes!

---

From: Doug Royer <[email-masked]>
Date: Thu, 14 Mar 2002 17:03:47 -0700

> MAXRESULT properties in draft-05).

No, that was the for the CS sending to the CUA.

I mean, I think we want the CUA to send its capabilities
to the CS? Perhaps in the "get-capabilities" request:

	<get-capabilities>
		<the CUA capabilities> ...
		In exactly the same format as the CS sends to the CUA.
		...
	</get-capabilities>

---

From: Patrice Lapierre <[email-masked]>
Date: 15 Mar 2002 08:30:46 -0500

> No, that was the for the CS sending to the CUA.

I was not referring to the capabilities.

MAXSIZE and MAXRESULT where properties of the VQUERY in draft-05.
and elements of the select element in draft-06, they were 
forgotten in draft-07.

These should remains settable at the command level. For example 
the MAXRESULT may vary for different queries in the same 
session (as for MAXSIZE, I don't know).

> to the CS?
 
It seem like a good idea, some CUA side capabilities could 
be useful. 

> Perhaps in the "get-capabilities" request:
> 
> 
> 	<get-capabilities>

BEEP is peer-to-peer, let's use it. If the server sends a
<get-capability/> MSG, then the CUA will reply with a 
<capability> RPY.

---

From: Doug Royer <[email-masked]>
Date: Fri, 15 Mar 2002 09:43:46 -0700

> <get-capability/> MSG, then the CUA will reply with a 

Sounds just like what I was thinking.

If there are no objections, I'll add text to the capability
section that specifies that the CUA MAY send its capabilities
to the CS. I'll also (if needed) list the ones that don't
apply.