Re: Minutes from Wednesday's meeting

["Paul B. Hill" <pbh@xxxxxxx>]

Hi,

Chris pointed out that although BEEP provides for mutliple channels over a
single connection, nothing mandates it. If a client implementor decides to
use only a single BEEP channel and then open up a new connection for each
operation that they want to perform in parallel, we loose much of the
benefit of BEEP.

The draft should have some langauge about this. We really don't want clients
that open up a large number of parrallel connections.

Chris offered to take a stab at some suggested text.
----- Original Message -----
From: "Doug Royer" <Doug@xxxxxxxxx>
To: <ietf-calendar@xxxxxxx>
Sent: Thursday, November 21, 2002 11:51 AM
Subject: Re: Minutes from Wednesday's meeting


>
> > Issue #3: Multiple connections versus BEEP channels. The current draft
> > doesn't discuss whether servers have to process channels in parallel
> > or if processing on one channel can block the other channels. If
> > clients only make a single TCP connection, rate limiting and other
> > accounting is much easier---but if clients have to open multiple
> > connections to keep long running operations from blocking, they
> > will. Larry Greenfield said that requiring parallel processing of
> > channels is a barrier to implementation and it isn't clear how to
> > write an on-the-wire specification requiring it. Some discussion on
> > Jabber with Marshall Rose and Larry Greenfield.
>
> We DID have this discussion - when we moved from pre-BEEP to BEEP.
> We used to have some kind of parallel processing and we had an attribute
> of CAPABILITY to specify how many parallel operations were possible.
> Then we changed to BEEP - simply allow or do not allow a new channel.
>
>  > Issue #4: Round trips are very expensive; pipelining should be
>  > mandatory.
>
> That is the advantage of BEEP. If the CS (for example) can handle
> multiple parallel commands - then the CUA can send multiple in parallel
> each on a separate channel. If the CS can not handle those parallel
> commands then it should not accept the new channel open request.
>
> I think we have already addressed this issue.
>
>
>   Doug Royer                     |   http://INET-Consulting.com
>   -------------------------------|-----------------------------
>   Doug@xxxxxxxxx                 | Office: (208)612-INET
>   http://Royer.com/People/Doug   |    Fax: (866)594-8574
>                                  |   Cell: (208)520-4044
>
>                  We Do Standards - You Need Standards
>