From bxxpwg-admin@lists.invisibleworlds.com Thu Dec 28 18:14:02 2000 Received: from trystero.not.invisible.net ([204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20560 for ; Thu, 28 Dec 2000 18:13:58 -0500 (EST) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA28572; Thu, 28 Dec 2000 15:12:07 -0800 (PST) Received: from cisco.com (ups.cisco.com [171.69.18.21]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA28556 for ; Thu, 28 Dec 2000 15:12:06 -0800 (PST) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA02259; Thu, 28 Dec 2000 15:11:37 -0800 (PST) From: Keith McCloghrie Message-Id: <200012282311.PAA02259@cisco.com> Subject: Re: [BXXPwg] Draft minutes of meeting in San Diego To: touch@ISI.EDU (Joe Touch) Date: Thu, 28 Dec 2000 15:11:37 -0800 (PST) Cc: kzm@cisco.com (Keith McCloghrie), bxxpwg@invisible.net In-Reply-To: <3A455A43.5FBE662A@isi.edu> from "Joe Touch" at Dec 23, 2000 06:06:59 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit Joe, Thanks for your technical comments. However, I was really looking for agreement on recording what happened at the meeting. If you believe that my draft minutes do not reflect what happened, could you suggest alternative wording. Thanks, Keith. > > 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 > _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg