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

From: "John Stracke" <[email-masked]>
Date: Thu, 14 Mar 2002 14:12:59 -0500

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

That does sound useful.  Does it add extra complexity on the CUA? If so, 
there could be a problem: a CUA that was developed only against a CS that 
doesn't send ANS might not bother to cope with ANS; it would then choke 
when run against a CS that did send ANS.  If the first generation of CSes 
only send RPY, then it could be a problem waiting.

But, if it doesn't add too much complexity on the CUA, then it'd be worth 
calling out in the spec that CUA implementors need to cope with it.

/================================================================\
|John Stracke                    |Principal Engineer             |
[email-masked]   |Incentive Systems, Inc.        |
|http://www.incentivesystems.com |My opinions are my own.        |
|================================================================|
|Using strong crypto on the Internet is like using an armored car|
|to transport money from someone living in a tent to someone     |
|living in a cardboard box.                                      |
\================================================================/

---

From: Patrice Lapierre <[email-masked]>
Date: 14 Mar 2002 14:53:55 -0500

On Thu, 2002-03-14 at 14:12, John Stracke wrote:
...
> 
> That does sound useful.  Does it add extra complexity on the CUA? 

On the CUA side, it's very straight forward to implement. 
All the required information is included in the BEEP header.

When a CUA receives the frames from a response to a 
one-to-many exchange (i.e., a set of ANS with distinct 
ansnos, terminated by a NUL).

For each frame:

  1. If the type is NUL, then were are done.
  2. If the type is ANS, then:
       - the ansno indicates to which partial (TARGET specific) 
	 result the payload should be added.
       - the '.' or '*' indicates if more frames are to be
	 expected for this partial result.