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