Subject: Re: BEEP and CAP - one-to-many

From: "John Stracke" <[email-masked]>
Date: Fri, 15 Mar 2002 10:04:50 -0500

>> 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.
>
>Yes!

But, Doug, that doesn't solve the thin-client problem you were talking 
about, because the MAY leaves it entirely up to the CS.  A thin client 
that can't handle a monolithic reply can't tell whether the CS will send 
one or not.  Right?

/===============================================================\
|John Stracke                    |Principal Engineer            |
[email-masked]   |Incentive Systems, Inc.       |
|http://www.incentivesystems.com |My opinions are my own.       |
|===============================================================|
|Reality is what refuses to go away when I stop believing in it.|
\===============================================================/

---

From: Patrice Lapierre <[email-masked]>
Date: 15 Mar 2002 10:41:19 -0500

On Fri, 2002-03-15 at 10:04, John Stracke wrote:
...
> A thin client that can't handle a monolithic reply can't tell 
> whether the CS will send one or not.  Right?
> 
  
What do you mean by a thin client can't handle a monolithic 
reply?

If you mean to inverse (thin client that can only handle 
a monolithic reply), then these small clients could always
limit themselves to a single TARGET per command.
 
Another alternative would be to add a CUA side capability,
to indicate if the CUA supports one-to-many exchanges,
but that might be an overkill.

---

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

> that can't handle a monolithic reply can't tell whether the CS will send 

Thin clients pick their provider. I don't think it will be an issue.