From beepwg-admin@lists.beepcore.org Mon Jun 2 16:47:33 2003 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23302 for ; Mon, 2 Jun 2003 16:47:32 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h52KkFc12517; Mon, 2 Jun 2003 13:46:15 -0700 (PDT) Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h52Kj6c12503 for ; Mon, 2 Jun 2003 13:45:06 -0700 (PDT) Received: from spamsicle.cisco.com (IDENT:mirapoint@spamsicle.cisco.com [161.44.172.225]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h52KiokQ005561 for ; Mon, 2 Jun 2003 16:44:54 -0400 (EDT) Received: from PAANDREWW2K3 (dhcp-161-44-180-172.cisco.com [161.44.180.172]) by spamsicle.cisco.com (Mirapoint) with ESMTP id AAT06951; Mon, 2 Jun 2003 16:44:49 -0400 (EDT) From: "Paul Andrews" To: "Beepwg" Message-ID: <000701c32947$eb465de0$acb42ca1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: [BEEPwg] SOAP Channel Initialization... Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Mon, 2 Jun 2003 16:45:36 -0400 Content-Transfer-Encoding: 7bit I've got a question about RFC 3288. In section 2.1 - Profile Initialization - it states: Alternatively, here is an example in which the boot exchange is unsuccessful: C: C: C: ]]> C: C: S: S: resource not S: supported]]> S: Although the channel was created successfully, it remains in the "boot" state. Does this imply that a subsequent message on the channel of type could cause the channel to leave the boot state? If not, what can actually be done with the channel? _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Jun 2 17:27:19 2003 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24798 for ; Mon, 2 Jun 2003 17:27:18 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h52LR2c12974; Mon, 2 Jun 2003 14:27:02 -0700 (PDT) Received: from shego.dbc.mtview.ca.us (dhcpd254.dbc.mtview.ca.us [64.168.10.254]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h52LQqc12962 for ; Mon, 2 Jun 2003 14:26:52 -0700 (PDT) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h52LQkiW006008; Mon, 2 Jun 2003 14:26:46 -0700 (PDT) From: Marshall Rose To: "Paul Andrews" Cc: beepwg@lists.beepcore.org Subject: Re: [BEEPwg] SOAP Channel Initialization... Message-Id: <20030602142646.478a0ec6.mrose@dbc.mtview.ca.us> In-Reply-To: <000701c32947$eb465de0$acb42ca1@cisco.com> References: <000701c32947$eb465de0$acb42ca1@cisco.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Mon, 2 Jun 2003 14:26:46 -0700 Content-Transfer-Encoding: 7bit > ... > Although the channel was created successfully, it remains in the > "boot" state. > > Does this imply that a subsequent message on the channel of type > could cause the channel to leave the boot state? yes, exactly. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Jun 6 01:14:41 2003 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29005 for ; Fri, 6 Jun 2003 01:14:41 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h565DHc19675; Thu, 5 Jun 2003 22:13:17 -0700 (PDT) Received: from irth.net ([216.180.224.13]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h565CGc19663 for ; Thu, 5 Jun 2003 22:12:16 -0700 (PDT) Received: from [68.34.145.88] (account jrimmer HELO irth.net) by irth.net (CommuniGate Pro SMTP 4.0.6) with ESMTP id 1179126 for beepwg@lists.beepcore.org; Fri, 06 Jun 2003 01:12:03 -0400 Message-ID: <3EE022A3.1010805@irth.net> From: Jason Rimmer User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030416 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: beepwg@lists.beepcore.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEEPwg] [Fwd: [JMX-FORUM] JMXP] Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Fri, 06 Jun 2003 01:12:03 -0400 Content-Transfer-Encoding: 7bit Posted on the JMX-FORUM@JAVA.SUN.COM mailing list. -------- Original Message -------- Subject: [JMX-FORUM] JMXP Date: Thu, 5 Jun 2003 17:26:02 -0500 From: Ward Harold Reply-To: Ward Harold To: JMX-FORUM@JAVA.SUN.COM I've designed a protocol for JMX, called JMXP, using the Blocks Extensible Exchange Protocol (BEEP) application protocol kernel and am proposing it to the IETF as a standard, language neutral mechanism for remote JMX access. The specification can be found at either: http://www.ietf.org/internet-drafts/draft-harold-jmxp-00.txt or for a prettier version: http://www.beepcore.org/beepcore/docs/profile-jmxp.jsp Note that this work in no way conflicts with the remote API designed by the JSR 160 Experts Group. JMXP is a protocol and as such could be used by a JSR 160 provider. My primary intent in designing JMXP was to create a mechanism via which non-Java programmers - read administrators who may prefer Perl, TCL, or shell scripts - can access JMX programmatically. I am of course very interested in feedback on this spec from JMX community ergo, comments/criticism/questions/corrections from this forum are especially welcome. ... WkH Ward Harold wharold@us.ibm.com IBM/Tivoli Software 11400 Burnet Rd. Austin, TX 78758 -- Jason Rimmer jrimmer at irth dot net _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Jun 6 09:30:26 2003 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22715 for ; Fri, 6 Jun 2003 09:30:25 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h56DU6c24023; Fri, 6 Jun 2003 06:30:06 -0700 (PDT) Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h56DTjc23999 for ; Fri, 6 Jun 2003 06:29:45 -0700 (PDT) Received: from spamsicle.cisco.com (IDENT:mirapoint@spamsicle.cisco.com [161.44.172.225]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h56DTXLU011530; Fri, 6 Jun 2003 09:29:33 -0400 (EDT) Received: from PAANDREWW2K3 (che-vpn-cluster-2-237.cisco.com [10.86.242.237]) by spamsicle.cisco.com (Mirapoint) with ESMTP id AAT25293; Fri, 6 Jun 2003 09:29:32 -0400 (EDT) From: "Paul Andrews" To: Cc: "Beepwg" Message-ID: <001501c32c2f$c0e16d70$6501a8c0@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: [BEEPwg] JMXP Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Fri, 6 Jun 2003 09:30:09 -0400 Content-Transfer-Encoding: 7bit My first thought on the JMXP proposal (http://www.ietf.org/internet-drafts/draft-harold-jmxp-00.txt) is that it is a combination presentation and application layer. The presentation layer is made up of elements like and , while the application layer is made up of elements like . I am on something of a crusade to press for separation of these two layers in any standard where I see it. The main reason being that there is a profilferation of XML presentation layers with every new proposed XML based protocol. We already have a presentation layer that has very wide tool support, namely: SOAP. In order to pre-empt many people's automatic response to the acronym 'SOAP' I will say up front that I am not interested in hearing any argument based on its supposed verbosity. I strongly believe, and I am not alone in this, that any mature presentation protocol would present a similar level of verbosity and that any actual verbosity that SOAP has does not significantly impact network or application performance. I also believe that SOAP's (perceived) shortcomings are strongly outweighed by the community, vendor and tool support that it has. Naturally, adopting SOAP for the presentation layer would still leave the application layer protocol undefined and I believe that it is this layer that any proposed standard should address. To summarize I would like to see the JMXP proposal split into two: 1. An information model that defines the application protocol. 2. A presentation binding with SOAP being the preferred binding. If SOAP is the preferred binding for the presentation layer, then the session layers and below are already well defined, in particular bindings are already defined for both BEEP and HTTP. If there are reasons why SOAP should not be used for presentation layer encoding (other than the 'verbosity' argument discussed above), I would be very interested in hearing them. Paul Andrews - Cisco Systems Inc. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Jun 9 05:05:37 2003 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24739 for ; Mon, 9 Jun 2003 05:05:36 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h5994Fc25746; Mon, 9 Jun 2003 02:04:15 -0700 (PDT) Received: from miz-mishtal.dbc.mtview.ca.us (miz-mishtal.dbc.mtview.ca.us [64.168.10.250]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h5993Qc25731 for ; Mon, 9 Jun 2003 02:03:27 -0700 (PDT) Received: from sarek.skynet.be (sarek.skynet.be [195.238.3.230]) by miz-mishtal.dbc.mtview.ca.us (8.12.6/8.12.6) with ESMTP id h5993PFi010290 for ; Mon, 9 Jun 2003 02:03:26 -0700 (PDT) Received: from tomoton.com (145.188-136-217.adsl.skynet.be [217.136.188.145]) by sarek.skynet.be (8.12.9/8.12.9/Skynet-OUT-2.21) with ESMTP id h59938vI031680 for ; Mon, 9 Jun 2003 11:03:09 +0200 (envelope-from ) Message-ID: <3EE44DC4.7090306@tomoton.com> From: Dann Martens Organization: tomoton User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: beepwg@lists.beepcore.org Subject: Re: [BEEPwg] JMXP References: <001501c32c2f$c0e16d70$6501a8c0@cisco.com> In-Reply-To: <001501c32c2f$c0e16d70$6501a8c0@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Mon, 09 Jun 2003 11:05:08 +0200 Content-Transfer-Encoding: 7bit I agree with your point of view. I don't think we need another 'custom' application specific protocol. Of course, JMXP is an interesting initiative in the context of the java JMX technology. But for heteregenous systems, SOAP is intended as the RPC (or RMI whatever you call it) protocol to rule them all. The (early access) Remote Access API for JMX allows for both approaches, but I wouldn't be surprised at all that designers have a JAX-RPC based (Sun's java SOAP 1.1 implementation) connector in mind for the next JMX Reference Implementation. Perl, TCL, or shell scripts will all have SOAP libraries (or binary tools) available, if they don't have them available already (I just haven't checked). Let's put our effort at getting the industry to accept SOAP over BEEP (as we need HTTP put out to pasture), now that would be a worthy cause ! Kind regards, Dann Paul Andrews wrote: >My first thought on the JMXP proposal >(http://www.ietf.org/internet-drafts/draft-harold-jmxp-00.txt) is that >it is a combination presentation and application layer. The presentation >layer is made up of elements like and , while the >application layer is made up of elements like action="remove">. > >I am on something of a crusade to press for separation of these two >layers in any standard where I see it. The main reason being that there >is a profilferation of XML presentation layers with every new proposed >XML based protocol. We already have a presentation layer that has very >wide tool support, namely: SOAP. > >In order to pre-empt many people's automatic response to the acronym >'SOAP' I will say up front that I am not interested in hearing any >argument based on its supposed verbosity. I strongly believe, and I am >not alone in this, that any mature presentation protocol would present a >similar level of verbosity and that any actual verbosity that SOAP has >does not significantly impact network or application performance. I also >believe that SOAP's (perceived) shortcomings are strongly outweighed by >the community, vendor and tool support that it has. > >Naturally, adopting SOAP for the presentation layer would still leave >the application layer protocol undefined and I believe that it is this >layer that any proposed standard should address. > >To summarize I would like to see the JMXP proposal split into two: > >1. An information model that defines the application protocol. >2. A presentation binding with SOAP being the preferred binding. > >If SOAP is the preferred binding for the presentation layer, then the >session layers and below are already well defined, in particular >bindings are already defined for both BEEP and HTTP. > >If there are reasons why SOAP should not be used for presentation layer >encoding (other than the 'verbosity' argument discussed above), I would >be very interested in hearing them. > >Paul Andrews - Cisco Systems Inc. > >_______________________________________________ >BEEPwg mailing list >BEEPwg@lists.beepcore.org >http://lists.beepcore.org/mailman/listinfo/beepwg > > > _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Jun 30 10:50:31 2003 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28639 for ; Mon, 30 Jun 2003 10:50:15 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h5UEi8e15991; Mon, 30 Jun 2003 07:44:08 -0700 (PDT) Received: from act-of-god.permabit.com (act-of-god.permabit.com [67.107.99.100]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h5UEhDe15979 for ; Mon, 30 Jun 2003 07:43:13 -0700 (PDT) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id 1FF1F1331E for ; Mon, 30 Jun 2003 10:43:04 -0400 (EDT) To: "Beepwg" From: Jered Floyd Message-ID: <87brwfwrrb.fsf@questionably-configured.permabit.com> Lines: 67 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [BEEPwg] SEQs after channel close request? Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 30 Jun 2003 10:43:04 -0400 Here we go again. :-) This is similar to a complaint I had last year regarding synchronization for TLS negotation, where I was shouted down for constructing overly obscure scenarios. This is less obscure, and actually a problem I'm running into, but I'm not sure how to best fix. While adding some functionality to PermaBEEP, we encountered a bug we hadn't noticed before. PermaBEEP will not send SEQ frames for a channel once it has processed a locally-initiated request to close for that channel. It doesn't want to generate any further outbound traffic on the channel after the close request, because as soon as the remote side accepts, the remote side considers the channel to be closed. Once the remote peer has processed the close, if it saw a SEQ for the channel in response to it's 'ok' response, it would terminate the connection as per RFC 3081, 3.1.3: When a SEQ frame is received, if any of the channel number, acknowledgement number, or window size cannot be determined or is invalid, then the BEEP session is terminated without generating a response, and it is recommended that a diagnostic entry be logged. (The channel would be closed and thus invalid.) So, the local peer isn't going to be sending any new MSGs after it's made a close request, however RFC 3080, 2.3.1.3: NOTE WELL: until a positive reply to the request to close the channel is received, the BEEP peer must be prepared to process any "MSG" messages that it receives on that channel. This means that once the local peer has sent a close, it must be prepared to process and respond to additional MSGs from the remote peer, and respond to them (with RPY, ANS, or ERR frames). Sending these frames isn't a problem because the remote peer isn't going to accept the close until after it's received complete replies to its outstanding MSGs, so those RPY, ANS, and ERR frames won't ever be received on a channel that the remote peer believes is closed. HOWEVER, because the local peer must still be prepared to handle incoming MSGs after it has sent a close request, the local peer MUST continue sending SEQs or else the channel will stall as the incoming MSG data is not acknowledged. But, the local client has know way of knowing when the remote peer is done sending MSGs and has processed and accepted the close request, so may send a SEQ after the remote peer believes the channel is closed. Any ideas how to resolve this? Two thoughts I've had: - Do not consider SEQ frames for a recently closed channel to be an error. (This requires some definition of 'recently closed'.) - On the local peer, after sending a close request, the last frame sent on a channel must not be a SEQ frame. If we are receiving incoming MSGs then we can happily send SEQs until we have sent the final frame of the response for all known incoming MSGs. I think the latter item there will work but, well, it seems overly complicated. What have other implementors done? --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Jun 30 12:35:45 2003 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04850 for ; Mon, 30 Jun 2003 12:35:44 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h5UGV7e16794; Mon, 30 Jun 2003 09:31:07 -0700 (PDT) Received: from orngca-mls02.socal.rr.com (orngca-mls02.socal.rr.com [66.75.160.17]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h5UGUHe16782 for ; Mon, 30 Jun 2003 09:30:17 -0700 (PDT) Received: from san.rr.com (66-27-127-98.san.rr.com [66.27.127.98]) by orngca-mls02.socal.rr.com (8.11.4/8.11.3) with ESMTP id h5UGQck05039; Mon, 30 Jun 2003 09:26:38 -0700 (PDT) Message-ID: <3F006592.3040707@san.rr.com> From: Darren New User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jered Floyd CC: Beepwg Subject: Re: [BEEPwg] SEQs after channel close request? References: <87brwfwrrb.fsf@questionably-configured.permabit.com> In-Reply-To: <87brwfwrrb.fsf@questionably-configured.permabit.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Mon, 30 Jun 2003 09:30:10 -0700 Content-Transfer-Encoding: 7bit Jered Floyd wrote: > I think the latter item there will work but, well, it seems overly > complicated. What have other implementors done? While doing Beepcore-C's core, I noticed this problem. I only send SEQs *before* sending outgoing packets. That is, I send the SEQ just before sending the RSP or ANS, so it really isn't a problem. As long as the SEQ isn't the last packet you send, the other side should always be waiting for your response and therefore hasn't processed the close yet. The other problem you run into is when a response to a close carries more data than your window can accept. This is more of a doctor-doctor problem. ("Doctor, Doctor, it hurts when I do this!" "Then don't do that.") Hope this helps. -- Darren New, San Diego CA USA (PST) Things to be thankful for, #187: There is no Chinese tradition of changing from shoes to slippers to get off an escalator. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Jun 30 12:52:28 2003 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05842 for ; Mon, 30 Jun 2003 12:52:28 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h5UGq2e17012; Mon, 30 Jun 2003 09:52:02 -0700 (PDT) Received: from shego.dbc.mtview.ca.us (dhcpd254.dbc.mtview.ca.us [64.168.10.254]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h5UGpbe16998 for ; Mon, 30 Jun 2003 09:51:37 -0700 (PDT) Received: from shego.dbc.mtview.ca.us (localhost [127.0.0.1]) by shego.dbc.mtview.ca.us (8.12.6/8.12.6) with SMTP id h5UGpZeZ009618; Mon, 30 Jun 2003 09:51:35 -0700 (PDT) From: Marshall Rose To: Darren New Cc: jered@permabit.com, beepwg@lists.beepcore.org Subject: Re: [BEEPwg] SEQs after channel close request? Message-Id: <20030630095135.1ef2c512.mrose@dbc.mtview.ca.us> In-Reply-To: <3F006592.3040707@san.rr.com> References: <87brwfwrrb.fsf@questionably-configured.permabit.com> <3F006592.3040707@san.rr.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.8claws (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Mon, 30 Jun 2003 09:51:35 -0700 Content-Transfer-Encoding: 7bit > While doing Beepcore-C's core, I noticed this problem. I only send SEQs > *before* sending outgoing packets. That is, I send the SEQ just before > sending the RSP or ANS, so it really isn't a problem. As long as the SEQ > isn't the last packet you send, the other side should always be waiting > for your response and therefore hasn't processed the close yet. this is the same approach i used in beepcore-tcl: SEQs go first. when the spec gets updated, i don't have a problem in changing the spec to ignore SEQs on unknown channels. it's hard to see any downside in that. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Jun 30 13:10:23 2003 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06596 for ; Mon, 30 Jun 2003 13:10:22 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h5UHA4e17205; Mon, 30 Jun 2003 10:10:04 -0700 (PDT) Received: from act-of-god.permabit.com (act-of-god.permabit.com [67.107.99.100]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h5UH97e17181 for ; Mon, 30 Jun 2003 10:09:07 -0700 (PDT) Received: from questionably-configured.permabit.com.permabit.com (questionably-configured.permabit.com [10.142.0.92]) by act-of-god.permabit.com (Postfix) with ESMTP id 12E9A1331E; Mon, 30 Jun 2003 13:09:07 -0400 (EDT) To: Marshall Rose Cc: Darren New , beepwg@lists.beepcore.org Subject: Re: [BEEPwg] SEQs after channel close request? References: <87brwfwrrb.fsf@questionably-configured.permabit.com> <3F006592.3040707@san.rr.com> <20030630095135.1ef2c512.mrose@dbc.mtview.ca.us> From: Jered Floyd In-Reply-To: <20030630095135.1ef2c512.mrose@dbc.mtview.ca.us> Message-ID: <873chrwkzw.fsf@questionably-configured.permabit.com> Lines: 22 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: 30 Jun 2003 13:09:07 -0400 Thanks; I ended up implementing something like this just now. If there exist any messages that have not yet been fully replied to, I will send SEQs, otherwise not. --Jered Marshall Rose writes: > > While doing Beepcore-C's core, I noticed this problem. I only send SEQs > > *before* sending outgoing packets. That is, I send the SEQ just before > > sending the RSP or ANS, so it really isn't a problem. As long as the SEQ > > isn't the last packet you send, the other side should always be waiting > > for your response and therefore hasn't processed the close yet. > > this is the same approach i used in beepcore-tcl: SEQs go first. > > when the spec gets updated, i don't have a problem in changing the spec > to ignore SEQs on unknown channels. it's hard to see any downside in > that. > > /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Jun 30 14:33:38 2003 Received: from qawoor.dbc.mtview.ca.us (adsl-64-168-10-251.dsl.scrm01.pacbell.net [64.168.10.251]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09982 for ; Mon, 30 Jun 2003 14:33:36 -0400 (EDT) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h5UIX4e17850; Mon, 30 Jun 2003 11:33:04 -0700 (PDT) Received: from wetware.com (wetware.wetware.com [199.108.16.1]) by qawoor.dbc.mtview.ca.us (8.11.5/8.11.5) with ESMTP id h5UIWce17837 for ; Mon, 30 Jun 2003 11:32:38 -0700 (PDT) Received: from 208.177.152.18.ptr.us.xo.net ([208.177.152.18] helo=wetware.com) by wetware.com with esmtp (Exim 4.20) id 19X3S1-0004Ie-V5 for beepwg@lists.beepcore.org; Mon, 30 Jun 2003 11:32:30 -0700 Subject: Re: [BEEPwg] SEQs after channel close request? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: james woodyatt To: BEEP WG Content-Transfer-Encoding: 7bit In-Reply-To: <20030630095135.1ef2c512.mrose@dbc.mtview.ca.us> Message-Id: <36102DAC-AB29-11D7-9304-000393BA7EBA@wetware.com> X-Mailer: Apple Mail (2.552) Sender: beepwg-admin@lists.beepcore.org Errors-To: beepwg-admin@lists.beepcore.org X-BeenThere: beepwg@lists.beepcore.org X-Mailman-Version: 2.0.6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Mailing list for the IETF's BEEP working group List-Unsubscribe: , List-Archive: Date: Mon, 30 Jun 2003 11:32:31 -0700 Content-Transfer-Encoding: 7bit On Monday, Jun 30, 2003, at 09:51 US/Pacific, Marshall Rose wrote: > [ Darren New wrote:] >> While doing Beepcore-C's core, I noticed this problem. I only send >> SEQs >> *before* sending outgoing packets. That is, I send the SEQ just before >> sending the RSP or ANS, so it really isn't a problem. As long as the >> SEQ >> isn't the last packet you send, the other side should always be >> waiting >> for your response and therefore hasn't processed the close yet. > > this is the same approach i used in beepcore-tcl: SEQs go first. There is a further complication. You can't wait until just before sending a reply before emitting the SEQ frame. My implementation will send the SEQ frame immediately after extending the window-- which happens when the MSG is acknowledged by the application layer, and possibly well before the application sends a reply. After the local peer sends a request and before it receives the reply, if it receives a MSG for which the application at the local peer does not have any response other than to extend the channel window (to receive more pipelined requests) then the local peer must send a SEQ immediately, while a RPY, ERR or ANS (or the transport reset event) may not be forthcoming until after the application receives more MSG requests. > when the spec gets updated, i don't have a problem in changing the spec > to ignore SEQs on unknown channels. it's hard to see any downside in > that. I don't see any problem with that, but I don't think it is necessary. Implementations can be compliant with the proposed standard without ever sending a SEQ frame on a channel that has been closed already. Don't send the in reply to a request until: 1) you have received all the replies for any messages sent; and 2) you have no more messages to send. -- j h woodyatt that's my village calling... no doubt, they want their idiot back. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg