[BXXPwg] Draft minutes of meeting in San Diego

Joe Touch touch@ISI.EDU
Sat, 23 Dec 2000 18:06:59 -0800

Keith McCloghrie wrote:
> Any comments on these minutes ?
> Keith.
> --------------
> BEEP WG, Thursday 14 December 2000, 1530-1730
> 1. The notion of mapping a BEEP session onto multiple TCP connections
>    is still under consideration by Joe Touch, even though no I-D has
>    been generated as yet.

What is not yet clear is whether such a document is really
needed, or whether that mapping is essentially trivial.
Mapping BEEP sessions onto a single TCP connection provides
strict priorities within the group only; it isn't clear
how such priorities would interact with other concurrent
BEEP associations on the same path (or same endpoints),
e.g., for different applications, or for different
security mechanisms within a single application. At that
point, the different BEEPs are in effect already
multiple TCP connections (with all their inter-stream

> 3. It was suggested that the "best current practices" for implementing
>    the transport mappings should be documented.  It was agreed that this
>    can be done (based on implementation experience) in a future revision
>    of the transport mappings document(s), e.g., advice of how to implement
>    BEEP's flow control.

It is the lack of #3 which, in part, further impedes #1. 

> Discussion then returned to the issue of whether the "ERR" message
> should be allowed (as an alternative to a "NUL" message) in one-to-many
> exchanges.  The chair observed that this was not a new issue; the
> Working Group had discussed it at least once before on the mailing
> list and decided in favour of the approach in the current documents.
> Another view was that with the current approach, the "ERR" message is
> used to convey errors detected by the BEEP layer, including syntax
> errors for messages; in contrast, application-specific errors are
> conveyed using "RSP" or "ANS" messages.

This is inconsistent with the current ID. BEEP currently 
indicates that many BEEP-level errors simply result in the
termination of the connection, rather than the response of
ERR. ERRs use 3-digit codes determined by the application.
Both of these indicate that ERRs are exactly for the
application, and not for BEEP-level errors.