From beepwg-admin@lists.beepcore.org Mon Feb 4 05:30:53 2002 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 FAA17972 for ; Mon, 4 Feb 2002 05:30:52 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g14AOAL00625; Mon, 4 Feb 2002 02:24:10 -0800 (PST) Received: from starway.heddley.com (starway.heddley.com [217.204.200.244]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g14ANOL00608 for ; Mon, 4 Feb 2002 02:23:28 -0800 (PST) Received: from pingu.heddley.com ([192.168.0.1] ident=mail) by starway.heddley.com with esmtp (Exim 3.12 #1 (Debian)) id 16XgMO-0004rQ-00 for ; Mon, 04 Feb 2002 10:28:28 +0000 Received: from edmundd by pingu.heddley.com with local (Exim 3.34 #1 (Debian)) id 16XgMK-0001aV-00; Mon, 04 Feb 2002 10:28:24 +0000 From: Edd Dumbill To: beepwg@lists.beepcore.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-N711N2rLLfeBSXnBveyn" X-Mailer: Evolution/1.0 (Preview Release) Message-Id: <1012818504.29344.19.camel@pingu> Mime-Version: 1.0 Subject: [BEEPwg] DIME 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: 04 Feb 2002 10:28:24 +0000 --=-N711N2rLLfeBSXnBveyn Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hello BEEPers, I just came across http://discuss.develop.com/archives/wa.exe?A2=3Dind0202a&L=3Ddime&F=3D&S=3D= &P=3D304 and more particularly http://www.gotdotnet.com/team/xml_wsspecs/dime/draft-nielsen-dime-01.txt [[[Abstract=20 Direct Internet Message Encapsulation (DIME) is a lightweight,=20 binary message format that can be used to encapsulate one or more=20 application-defined payloads of arbitrary type and size into a=20 single message construct. Each payload is described by a type, a=20 length, and an optional identifier. Both URIs and MIME media type=20 constructs are supported as type identifiers. The payload length is an integer indicating the number of octets of the payload. The=20 optional payload identifier is a URI enabling cross-referencing ]]] From first glance this looks to be akin to BEEP framing, but I could be wrong. Another thought that occurred to me is that it's a way to get rid of the issues sending binary objects with SOAP. I'd be interested in the BEEP perspective on this I-D. cheers -- Edd --=-N711N2rLLfeBSXnBveyn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEABECAAYFAjxeYkgACgkQrxbtsbubhxFZlQCglpSzzNp1eRcM0Dfnmxuzl1H9 BLUAnRnyPx9SBg8oCEWltjYwHrkd8KEs =mLTa -----END PGP SIGNATURE----- --=-N711N2rLLfeBSXnBveyn-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Feb 4 11:19:02 2002 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 LAA27437 for ; Mon, 4 Feb 2002 11:19:01 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g14GDBL03160; Mon, 4 Feb 2002 08:13:11 -0800 (PST) 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.3/8.11.5) with ESMTP id g14GCmL03148 for ; Mon, 4 Feb 2002 08:12:48 -0800 (PST) Received: from FATORA (dhcpd253 [64.168.10.253] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g14G8CQ01914; Mon, 4 Feb 2002 08:08:12 -0800 (PST) Message-ID: <00e601c1ad97$7d35cf70$0301000a@FATORA> From: "Marshall T. Rose" To: "Edd Dumbill" , Cc: "Marshall Rose" References: <1012818504.29344.19.camel@pingu> Subject: Re: [BEEPwg] DIME MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 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, 4 Feb 2002 08:17:47 -0800 Content-Transfer-Encoding: 7bit ed - dime is an alternative for multipart/mixed, obstensibly motivated by the "binary objects" with soap problem that you mentioned. there is a second draft, draft-nielsen-dime-soap-00, which talks about using dime to encode soap. neither of these drafts have any "control" component, as such, they are akin to mime, not beep. one could certainly define a beep "profile" to transport soap encoded using dime, just as there's one for transporting soap encoded using mime... /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Feb 4 11:24:28 2002 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 LAA27574 for ; Mon, 4 Feb 2002 11:24:27 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g14GJ2L03213; Mon, 4 Feb 2002 08:19:02 -0800 (PST) Received: from xomi.pair.com (xomi.pair.com [209.68.2.14]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g14GIGL03201 for ; Mon, 4 Feb 2002 08:18:16 -0800 (PST) Received: (qmail 38620 invoked by uid 3039); 4 Feb 2002 16:23:20 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 4 Feb 2002 16:23:20 -0000 From: Gabe Wachob X-Sender: To: Edd Dumbill cc: Subject: Re: [BEEPwg] DIME In-Reply-To: <1012818504.29344.19.camel@pingu> Message-ID: 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: Mon, 4 Feb 2002 08:23:20 -0800 (PST) Edd- DIME is closer to "MIME with chunking" (or more accurately, a MIME container) than frames in BEEP (from my general understanding of DIME and a quick scan of this I-D). DIME chunking is like HTTP chunking (chunked content-encoding) in the sense that I *think* its meant as an efficiency mechanism to allow sending applications to send data "buffer-by-buffer" rather than having to buffer an entire piece of content on the sending side (to determine size) before beginning to send the content. (See section 1.2, design goal #2) Also, DIME is intended for SOAP (at least thats the context I know it from) and as such the motivations for Frame(s) in BEEP are absent from the context of DIME. That is, DIME wouldn't be usable for things like flow control or even managing network buffers, etc, primarily because DIME is presumably visible at a relatively high level of abstraction (though this is implementation dependent I guess). That is, DIME is defined irrespective of the type of transport (one can send SOAP with DIME over SMTP, for example). While one could define a BEEP/SMTP binding, the motivation for Frames there would probably go out the door (along with all of BEEP). Hope this is helpful... Maybe there are some similarities I'm not catching.. -Gabe On 4 Feb 2002, Edd Dumbill wrote: > Hello BEEPers, > > I just came across > http://discuss.develop.com/archives/wa.exe?A2=ind0202a&L=dime&F=&S=&P=304 > and more particularly > > http://www.gotdotnet.com/team/xml_wsspecs/dime/draft-nielsen-dime-01.txt > > [[[Abstract > > Direct Internet Message Encapsulation (DIME) is a lightweight, > binary message format that can be used to encapsulate one or more > application-defined payloads of arbitrary type and size into a > single message construct. Each payload is described by a type, a > length, and an optional identifier. Both URIs and MIME media type > constructs are supported as type identifiers. The payload length is > an integer indicating the number of octets of the payload. The > optional payload identifier is a URI enabling cross-referencing ]]] > > >From first glance this looks to be akin to BEEP framing, but I could be > wrong. Another thought that occurred to me is that it's a way to get > rid of the issues sending binary objects with SOAP. > > I'd be interested in the BEEP perspective on this I-D. > > cheers > > -- Edd > -- Gabe Wachob gwachob@wachob.com Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Feb 7 17:31:37 2002 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 RAA11597 for ; Thu, 7 Feb 2002 17:31:36 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g17MPBL25616; Thu, 7 Feb 2002 14:25:11 -0800 (PST) Received: from nycsmtp1out.rdc-nyc.rr.com (nycsmtp1out.rdc-nyc.rr.com [24.29.99.226]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g17MOeL25600 for ; Thu, 7 Feb 2002 14:24:40 -0800 (PST) Received: from MUMON (24-168-57-57.nyc.rr.com [24.168.57.57]) by nycsmtp1out.rdc-nyc.rr.com (8.12.1/Road Runner SMTP Server 1.0) with ESMTP id g17MTefZ005206 for ; Thu, 7 Feb 2002 17:29:40 -0500 (EST) From: "Michael Fortson" To: Message-ID: <003601c1b027$02f94bf0$6401a8c0@MUMON> 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.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [BEEPwg] question about BEEP tcp mapping 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: Thu, 7 Feb 2002 17:30:08 -0500 Content-Transfer-Encoding: 7bit I've been reading through the BEEP RFCs (3080, 3081) and I was hoping someone here could help me understand the TCP mapping better. I don't really understand why the use of SEQ frames and a sliding window is necessary to avoid starvation and deadlock when the underlying transport (tcp) already addresses these problems (although for ports, not channels). For instance, why can't the underlying TCP socket deal with ensuring that peers don't send more data then the other can receive? As far as BEEP flow control goes, would it be possible for peers to negotiate a larger max-frame-size (restricted by 2/3rds of the TCP max-segment-size) rather than increase the size of their windows? Incidentally, I realize that I'm missing something -- I'm just hoping to arm someone with enough ammunition to quickly point out what I've missed :). -Michael _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Feb 7 17:56:00 2002 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 RAA12070 for ; Thu, 7 Feb 2002 17:55:59 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g17Mo2L25781; Thu, 7 Feb 2002 14:50:02 -0800 (PST) Received: from kalia.dbc.mtview.ca.us (dhcpd253 [64.168.10.253] (may be forged)) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g17MnrL25763 for ; Thu, 7 Feb 2002 14:49:53 -0800 (PST) Received: from kalia (localhost [127.0.0.1]) by kalia.dbc.mtview.ca.us (8.11.3nb1/8.11.6) with SMTP id g17Mlne00581; Thu, 7 Feb 2002 14:47:49 -0800 (PST) From: Marshall Rose To: "Michael Fortson" Cc: mrose@dbc.mtview.ca.us, beepwg@lists.beepcore.org Subject: Re: [BEEPwg] question about BEEP tcp mapping Message-Id: <20020207144749.2884e95b.mrose@dbc.mtview.ca.us> In-Reply-To: <003601c1b027$02f94bf0$6401a8c0@MUMON> References: <003601c1b027$02f94bf0$6401a8c0@MUMON> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.7.0claws (GTK+ 1.2.10; i386-netbsd) 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: Thu, 7 Feb 2002 14:47:49 -0800 Content-Transfer-Encoding: 7bit > I don't really understand why the use of SEQ frames and a sliding window > is necessary to avoid starvation and deadlock when the underlying > transport (tcp) already addresses these problems (although for ports, > not channels). For instance, why can't the underlying TCP socket deal > with ensuring that peers don't send more data then the other can > receive? with rfc3080, it's possible that you have more than one data exchange channel simultaneously active. in this case, you need to have a mechanism wherein the beep peers can negotiate how much each channel gets. otherwise, you can get into a situation where one channel starves another one, potentially even channel 0... > > As far as BEEP flow control goes, would it be possible for peers to > negotiate a larger max-frame-size (restricted by 2/3rds of the TCP > max-segment-size) rather than increase the size of their windows? > i'm not sure i follow what you're asking exactly. you can implement whatever algorithms you want, providing they are consistent with the guidelines given in rfc3081, e.g., priority queues. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Feb 7 17:57:55 2002 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 RAA12123 for ; Thu, 7 Feb 2002 17:57:55 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g17Mq1L25808; Thu, 7 Feb 2002 14:52:01 -0800 (PST) Received: from smtp2.san.rr.com (smtp2.san.rr.com [24.25.195.39]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g17MpXL25796 for ; Thu, 7 Feb 2002 14:51:33 -0800 (PST) Received: from san.rr.com (66-75-151-160.san.rr.com [66.75.151.160]) by smtp2.san.rr.com (8.11.4/8.11.4) with ESMTP id g17MvEJ06617 for ; Thu, 7 Feb 2002 14:57:14 -0800 (PST) Message-ID: <3C630653.C87F3C90@san.rr.com> From: Darren New Organization: Boxes! X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: beepwg@lists.beepcore.org Subject: Re: [BEEPwg] question about BEEP tcp mapping References: <003601c1b027$02f94bf0$6401a8c0@MUMON> 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: Thu, 07 Feb 2002 14:57:23 -0800 Content-Transfer-Encoding: 7bit Michael Fortson wrote: > I don't really understand why the use of SEQ frames and a sliding window > is necessary to avoid starvation and deadlock when the underlying > transport (tcp) already addresses these problems (although for ports, > not channels). For the same reason that TCP has a window for each port. > For instance, why can't the underlying TCP socket deal > with ensuring that peers don't send more data then the other can > receive? They do. But what prevents channel 5 from overrunning the processing at the peer and thereby making channel 7 have to wait for unrelated processing? Say you have two streams, channel 5 getting copied to the printer, channel 7 going to the disk. If the printer is very slow, channel 7 might get held up waiting for channel 5 to drain a large block of 20 pages of text. If channel 5's window is smaller than the printer's buffer and doesn't get opened wider than the printer's buffer, channel 7 will never slow down. > Incidentally, I realize that I'm missing something -- I'm just hoping to > arm someone with enough ammunition to quickly point out what I've missed You're not missing something. You just don't realize you already know the answer. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The opposite of always is sometimes. The opposite of never is sometimes. _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Feb 12 16:46:28 2002 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 QAA28591 for ; Tue, 12 Feb 2002 16:46:27 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g1CLd9i17344; Tue, 12 Feb 2002 13:39:09 -0800 (PST) Received: from bulk.resource.org (bulk.resource.org [192.101.98.10]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g1CLcui17316 for ; Tue, 12 Feb 2002 13:38:57 -0800 (PST) Received: from tron.admin.cto.netsol.com (h240.s231.netsol.com [216.168.231.240]) by bulk.resource.org (8.12.0/8.12.0) with ESMTP id g1CINKX1010427 for ; Tue, 12 Feb 2002 10:23:21 -0800 (PST) Received: (from raldi@localhost) by tron.admin.cto.netsol.com (8.11.6/8.11.6) id g1CILY525815 for beepwg@lists.beepcore.org; Tue, 12 Feb 2002 13:21:34 -0500 From: Mike Schiraldi To: beepwg@lists.beepcore.org Message-ID: <20020212182134.GI24147@research.netsol.com> Mime-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="GdbWtwDHkcXqP16f" Content-Disposition: inline User-Agent: Mutt/1.5.0i X-Last-Reboot: January 9, 2002 (33 days ago) Subject: [BEEPwg] Perl support for beep 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: Tue, 12 Feb 2002 13:21:34 -0500 --GdbWtwDHkcXqP16f Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'm starting a project to bring beep support to Perl, using perl's XS extensions and beepcore-c. If anyone is interested in the project, please let me know and i'll keep you updated. --=20 Mike Schiraldi VeriSign Applied Research --GdbWtwDHkcXqP16f Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIIKIAYJKoZIhvcNAQcCoIIKETCCCg0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC B6wwggR2MIID36ADAgECAhAyACTCO7tQsBTRNUR0/tTjMA0GCSqGSIb3DQEBBAUAMIHMMRcw FQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5 IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRp dmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkMB4XDTAxMDMyMjAwMDAw MFoXDTAyMDMyMjIzNTk1OVowggEaMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UE CxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9y ZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElBQi5MVEQoYyk5ODEeMBwGA1UECxMV UGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdpdGFsIElEIENsYXNzIDEgLSBO ZXRzY2FwZSBGdWxsIFNlcnZpY2UxFzAVBgNVBAMUDk1pa2UgU2NoaXJhbGRpMSgwJgYJKoZI hvcNAQkBFhlyYWxkaUByZXNlYXJjaC5uZXRzb2wuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN ADCBiQKBgQDu28IxMPojtN900dqX3LO3rfhirsJstpbSOzKVwPH9GwIgycFIn3YFkmOpeB40 cBkqNC1HzreGuFFAo9f3Y9xPjbvnEWlNo6oBu/wGL53gUtsUcNcj7tOngfjTr/4V3rohPuWU 4qRAZxjd5qaFUSP3bLh/U/7MoRwRB2Sz82HCqwIDAQABo4IBBjCCAQIwCQYDVR0TBAIwADCB rAYDVR0gBIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93 d3cudmVyaXNpZ24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMC AQEaPVZlcmlTaWduJ3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMp OTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEBBAQDAgeAMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQADgYEAYOkgLNF2 HYrK+ucdU0TN2PIAtbB3vV0cLhHJfE6zzyL9u5PlAKnxqwVYozd5S/u4Lg1WvDFE3vG3mVIE Fobol2RmSNIo6kOgED48B6oWgU/21lysVZ6DRPnGTSX7FsIH12L0mHj7jSDkzTqtkbzY6is/ YBkKDmeAuXnmljJ7H7wwggMuMIICl6ADAgECAhEA0nYujRQMPX2yqCVdr+4NdTANBgkqhkiG 9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNV BAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcN OTgwNTEyMDAwMDAwWhcNMDgwNTEyMjM1OTU5WjCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIElu Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgx SDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBl cnNvbmEgTm90IFZhbGlkYXRlZDCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAu1pEigQW u1X9A3qKLZRPFXg2uA1Ksm+cVL+86HcqnbnwaLuV2TFBcHqBS7lIE1YtxwjhhEKrwKKSq0Rc qkLwgg4C6S/7wju7vsknCl22sDZCM7VuVIhPh0q/Gdr5FegPh7Yc48zGmo5/aiSS4/zgZbqn sX7vyds3ashKyAkG5JkCAwEAAaN8MHowEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4w PAYLYIZIAYb4RQEHAQEwLTArBggrBgEFBQcCARYfd3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQTAPBgNVHRMECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQIFAAOB gQCIuDc73dqUNwCtqp/hgQFxHpJqbS/28Z3TymQ43BuYDAeGW4UVag+5SYWklfEXfWe0fy0s 3ZpCnsM+tI6q5QsG3vJWKvozx74Z11NMw73I4xe1pElCY+zCphcPXVgaSTyQXFWjZSAA/Rgg 5V+CprGoksVYasGNAzzrw80FopCubjGCAjwwggI4AgEBMIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAyACTCO7tQsBTRNUR0/tTjMAkGBSsOAwIa BQCggbEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDIwMjEy MTgyMTM0WjAjBgkqhkiG9w0BCQQxFgQUZ+W9twsFZdqcuc50wZcWyOaLOCMwUgYJKoZIhvcN AQkPMUUwQzAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYF Kw4DAgcwDQYIKoZIhvcNAwICASgwDQYJKoZIhvcNAQEBBQAEgYDs7LTa6CI1yExIBR7HDuc2 7WmpVLzsic55gNrfxBLApoRKw42QybNUf478foP1Vp7GIeIvbz9mD6bMcQPqpRQY6T4mrsEb OBFZ9AdX8Ema0h0NQS5nNaQvy1uQmUd5Imd8w18lKo2LEG7wH0hgjrYJ5YK/cGvAf1tiF1yX NcToZg== --GdbWtwDHkcXqP16f-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Feb 14 16:12:09 2002 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 QAA09891 for ; Thu, 14 Feb 2002 16:12:08 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g1EL5Ci03947; Thu, 14 Feb 2002 13:05:12 -0800 (PST) Received: from web14302.mail.yahoo.com (web14302.mail.yahoo.com [216.136.173.78]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g1EL4Yi03932 for ; Thu, 14 Feb 2002 13:04:34 -0800 (PST) Message-ID: <20020214211059.50181.qmail@web14302.mail.yahoo.com> Received: from [169.237.71.110] by web14302.mail.yahoo.com via HTTP; Thu, 14 Feb 2002 13:10:59 PST From: sa wa To: beepwg@lists.beepcore.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [BEEPwg] Does BEEP conflict with JXTA? 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: Thu, 14 Feb 2002 13:10:59 -0800 (PST) I am a newcomer of distibuted system. Just noticedd that they both are protocols supporting p2p network system; if I need to write an application of p2p, should I use both of them or only one of them? Thanks in advance! sawa __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Feb 14 19:33:28 2002 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 TAA13594 for ; Thu, 14 Feb 2002 19:33:27 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g1F0Q6i05031; Thu, 14 Feb 2002 16:26:06 -0800 (PST) Received: from xomi.pair.com (xomi.pair.com [209.68.2.14]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g1F0PUi05019 for ; Thu, 14 Feb 2002 16:25:31 -0800 (PST) Received: (qmail 82952 invoked by uid 3039); 15 Feb 2002 00:31:49 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 15 Feb 2002 00:31:49 -0000 From: Gabe Wachob X-Sender: To: sa wa cc: Subject: Re: [BEEPwg] Does BEEP conflict with JXTA? In-Reply-To: <20020214211059.50181.qmail@web14302.mail.yahoo.com> Message-ID: 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: Thu, 14 Feb 2002 16:31:49 -0800 (PST) No conflict at all. JXTA uses (among others) BEEP for a transport. I'd suggest checking out the JXTA development lists for more information. -Gabe On Thu, 14 Feb 2002, sa wa wrote: > I am a newcomer of distibuted system. Just noticedd > that they both are protocols supporting p2p network > system; if I need to write an application of p2p, > should I use both of them or only one of them? > > Thanks in advance! > > sawa > > __________________________________________________ > Do You Yahoo!? > Send FREE Valentine eCards with Yahoo! Greetings! > http://greetings.yahoo.com > _______________________________________________ > BEEPwg mailing list > BEEPwg@lists.beepcore.org > http://lists.beepcore.org/mailman/listinfo/beepwg > -- Gabe Wachob gwachob@wachob.com Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Feb 18 05:26:41 2002 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 FAA29688 for ; Mon, 18 Feb 2002 05:26:41 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g1IAJ8i02595; Mon, 18 Feb 2002 02:19:08 -0800 (PST) Received: from gridnode.com (root@[202.172.47.82]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g1IAIUi02583 for ; Mon, 18 Feb 2002 02:18:30 -0800 (PST) Received: from gridnode.com ([192.168.213.203]) by gridnode.com (8.9.3/8.9.3) with ESMTP id SAA03590 for ; Mon, 18 Feb 2002 18:26:45 +0800 Message-ID: <3C70D4B6.2030308@gridnode.com> From: yuexiang User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7) Gecko/20011226 X-Accept-Language: en-us MIME-Version: 1.0 To: beepwg@lists.beepcore.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [BEEPwg] BEEP question 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, 18 Feb 2002 18:17:26 +0800 Content-Transfer-Encoding: 7bit Hello, This question confused me for some time already. In the following, I try to describe my question: A host ---->firewall ---- >internet --> B host <--------internet ------firewall<------C host A direct TCP connection could be established between A host and B host, based on this TCP connection, BEEP protocol can be implemented and employed between A host and B host. But, is it possible that BEEP protocol connects A host and C host? I meam one of them( A host and C host) acting as the INITIATING ROLE and the other acting as the LISTENING ROLE? For example, If I employ JMS to establish a direct virtual connection between A host and C host to support BEEP protocol messages between them. Probably my question is stupid because it is meaningnessless. Any comment? Thanks a lot yangyuexiang _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Feb 18 12:34:32 2002 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 MAA10219 for ; Mon, 18 Feb 2002 12:34:31 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g1IHRJi05417; Mon, 18 Feb 2002 09:27:19 -0800 (PST) Received: from xomi.pair.com (xomi.pair.com [209.68.2.14]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g1IHQDi05405 for ; Mon, 18 Feb 2002 09:26:13 -0800 (PST) Received: (qmail 39338 invoked by uid 3039); 18 Feb 2002 17:32:55 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 18 Feb 2002 17:32:55 -0000 From: Gabe Wachob X-Sender: To: yuexiang cc: Subject: Re: [BEEPwg] BEEP question In-Reply-To: <3C70D4B6.2030308@gridnode.com> Message-ID: 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: Mon, 18 Feb 2002 09:32:55 -0800 (PST) Your question is not meaningless at all! You wouldn't use JMS as a "transport" layer though.. that would simply not be BEEP. In short, there is no BEEP-provided facility for this sort of "rendezvous" functionality. That doesn't mean it couldn't be defined as a BEEP Profile (which all three parties would have to implement in one form or another). You may want to check out the TUNNEL profile at http://www.beepcore.org/beepcore/docs/profile-tunnel.jsp I don't think this will provide the "rendezvous" functionality you are looking for, but it may help in some situations. A profile for your situation is something I've been thinking about for a while, but I don't think anyone has published any profiles towards solving this problem. -Gabe On Mon, 18 Feb 2002, yuexiang wrote: > Hello, > > This question confused me for some time already. > > In the following, I try to describe my question: > > A host ---->firewall ---- >internet --> B host <--------internet > ------firewall<------C host > > A direct TCP connection could be established between A host and B host, > based on this TCP > connection, BEEP protocol can be implemented and employed between A host > and B host. > > But, is it possible that BEEP protocol connects A host and C host? I > meam one of them( A host > and C host) acting as the INITIATING ROLE and the other acting as the > LISTENING ROLE? > > For example, If I employ JMS to establish a direct virtual connection > between A host and C host > to support BEEP protocol messages between them. > > Probably my question is stupid because it is meaningnessless. > > Any comment? > > Thanks a lot > > yangyuexiang > > > _______________________________________________ > BEEPwg mailing list > BEEPwg@lists.beepcore.org > http://lists.beepcore.org/mailman/listinfo/beepwg > -- Gabe Wachob gwachob@wachob.com Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Feb 20 17:02:16 2002 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 RAA21670 for ; Wed, 20 Feb 2002 17:02:15 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g1KLsAi23104; Wed, 20 Feb 2002 13:54:14 -0800 (PST) Received: from nycsmtp1out.rdc-nyc.rr.com (nycsmtp1out.rdc-nyc.rr.com [24.29.99.226]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g1KLrVi23088 for ; Wed, 20 Feb 2002 13:53:31 -0800 (PST) Received: from MUMON (24-168-57-57.nyc.rr.com [24.168.57.57]) by nycsmtp1out.rdc-nyc.rr.com (8.12.1/Road Runner SMTP Server 1.0) with ESMTP id g1KLxec1019013 for ; Wed, 20 Feb 2002 16:59:41 -0500 (EST) From: "Michael Fortson" To: Message-ID: <000001c1ba59$fbb89c00$6401a8c0@MUMON> 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.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [BEEPwg] (no subject) 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: Wed, 20 Feb 2002 17:00:12 -0500 Content-Transfer-Encoding: 7bit Marshall & Darren, thanks for the help on this - I think I was stuck considering the case were all channels were serviced equally well (so it becomes the problem of the beep client layer to hold onto un-received data until an application grabs it), despite this not being a required (or even likely, now that I think about it) implementation. Incidentally, sorry for responding so late -- been having some mail server problems... -Michael -----Original Message----- From: beepwg-admin@lists.beepcore.org [mailto:beepwg-admin@lists.beepcore.org] On Behalf Of Marshall Rose Sent: Thursday, February 07, 2002 5:48 PM To: Michael Fortson Cc: mrose@dbc.mtview.ca.us; beepwg@lists.beepcore.org Subject: Re: [BEEPwg] question about BEEP tcp mapping > I don't really understand why the use of SEQ frames and a sliding window > is necessary to avoid starvation and deadlock when the underlying > transport (tcp) already addresses these problems (although for ports, > not channels). For instance, why can't the underlying TCP socket deal > with ensuring that peers don't send more data then the other can > receive? with rfc3080, it's possible that you have more than one data exchange channel simultaneously active. in this case, you need to have a mechanism wherein the beep peers can negotiate how much each channel gets. otherwise, you can get into a situation where one channel starves another one, potentially even channel 0... > > As far as BEEP flow control goes, would it be possible for peers to > negotiate a larger max-frame-size (restricted by 2/3rds of the TCP > max-segment-size) rather than increase the size of their windows? > i'm not sure i follow what you're asking exactly. you can implement whatever algorithms you want, providing they are consistent with the guidelines given in rfc3081, e.g., priority queues. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg -----Original Message----- From: beepwg-admin@lists.beepcore.org [mailto:beepwg-admin@lists.beepcore.org] On Behalf Of Darren New Sent: Thursday, February 07, 2002 5:57 PM To: beepwg@lists.beepcore.org Subject: Re: [BEEPwg] question about BEEP tcp mapping Michael Fortson wrote: > I don't really understand why the use of SEQ frames and a sliding window > is necessary to avoid starvation and deadlock when the underlying > transport (tcp) already addresses these problems (although for ports, > not channels). For the same reason that TCP has a window for each port. > For instance, why can't the underlying TCP socket deal > with ensuring that peers don't send more data then the other can > receive? They do. But what prevents channel 5 from overrunning the processing at the peer and thereby making channel 7 have to wait for unrelated processing? Say you have two streams, channel 5 getting copied to the printer, channel 7 going to the disk. If the printer is very slow, channel 7 might get held up waiting for channel 5 to drain a large block of 20 pages of text. If channel 5's window is smaller than the printer's buffer and doesn't get opened wider than the printer's buffer, channel 7 will never slow down. > Incidentally, I realize that I'm missing something -- I'm just hoping to > arm someone with enough ammunition to quickly point out what I've missed You're not missing something. You just don't realize you already know the answer. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. The opposite of always is sometimes. The opposite of never is sometimes. _______________________________________________ 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 Thu Feb 21 14:20:34 2002 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 OAA00398 for ; Thu, 21 Feb 2002 14:20:33 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g1LJD3i00876; Thu, 21 Feb 2002 11:13:03 -0800 (PST) Received: from kalia.dbc.mtview.ca.us (dhcpd253 [64.168.10.253] (may be forged)) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g1LJC1i00862; Thu, 21 Feb 2002 11:12:02 -0800 (PST) Received: from kalia (localhost [127.0.0.1]) by kalia.dbc.mtview.ca.us (8.11.3nb1/8.11.6) with SMTP id g1LJIBu10824; Thu, 21 Feb 2002 11:18:11 -0800 (PST) From: Marshall Rose To: apexwg@lists.beepcore.org Cc: ukumar@in.firstrain.com, BEEPwg@lists.beepcore.org Message-Id: <20020221111810.6a58059e.mrose@dbc.mtview.ca.us> In-Reply-To: <205C5F16CA92F94484F054E94520F4D7111A65@mail.in.firstrain.com> References: <205C5F16CA92F94484F054E94520F4D7111A65@mail.in.firstrain.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [BEEPwg] Re: [APEXwg] Apex/Beep doubts about relay/channel 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: Thu, 21 Feb 2002 11:18:10 -0800 Content-Transfer-Encoding: 7bit > Hi all ... > I am a starter in this field so > I am taking this opportunity to clear some of my doubts too .... > > This is quoted from the apex-core draft .... > "relaying between administrative domains is configured > using SRV RRs. Accordingly, the actual number of > relays between two endpoints is not fixed." > > My questions are.... > ?1 If we have to send a message to a differnet domain endpoint we > directly bind > to the realy of that domain .... so isn't this a communication b/w > only concerned > relays ???.... more specifically routing is doen at lower network > level so why should > a relay level routing be there ???? the easy way to understand apex is this: ask yourself "why does SMTP do it that way?" if you can understand why SMTP behaves a certain way, then you will understand why APEX behaves a certain way. > ?2 I am also not sure about the notion of channel ... we can attach > profile to the channels ... > this means on a single tcp session we can talk on several message > semantics ... as i am > a starter in this field i cannot realy think of a real/practical > world example of uses of this... > can u please clear me on this front ??? you may want to associate different priorities/characteristics with each channel. /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Feb 25 16:57:46 2002 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 QAA01439 for ; Mon, 25 Feb 2002 16:57:45 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g1PLn8i04300; Mon, 25 Feb 2002 13:49:08 -0800 (PST) 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.3/8.11.5) with ESMTP id g1PLl4i04274 for ; Mon, 25 Feb 2002 13:47:04 -0800 (PST) Received: from FATORA (dhcpd253 [64.168.10.253] (may be forged)) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g1PLgY505434; Mon, 25 Feb 2002 13:42:34 -0800 (PST) Message-ID: <032201c1be46$fcf928a0$0a01000a@FATORA> From: "Marshall T. Rose" To: , Cc: "Marshall Rose" References: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_031E_01C1BE03.EE835BD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Subject: [BEEPwg] Re: BEEP header & ABNF Question 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, 25 Feb 2002 13:54:23 -0800 This is a multi-part message in MIME format. ------=_NextPart_000_031E_01C1BE03.EE835BD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit instead of "zero or more" it could say "six or seven", i suppose. nothing is optional, however "ANS" has one more parameter than the others. /mtr ----- Original Message ----- From: Bruce_Kahn@notesdev.ibm.com To: BEEPwg@lists.beepcore.org ; ietf-calendar@imc.org Sent: Monday, February 25, 2002 12:18 Subject: BEEP header & ABNF Question [Crossposting this to BEEP and CalSched WGs to insure proper coverage] In my attempt to be come more BEEP savy and dealing with the CAP issues I was rereading the BEEP RFC and I think there is a small disjoin between the text and the ABNF that folks should be aware of (or they can point out where the corrective text is). The text in Section 2.2.1.1 Frame Header says: The frame header consists of a three-character keyword (one of: "MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or more parameters. A single space character (decimal code 32, " ") separates each component. (my emphasis) but the ABNF in Section 2.2.1 Frame Syntax defines each of the parameters as mandatory: data = header payload trailer header = msg / rpy / err / ans / nul msg = "MSG" SP common CR LF rpy = "RPY" SP common CR LF ans = "ANS" SP common SP ansno CR LF err = "ERR" SP common CR LF nul = "NUL" SP common CR LF common = channel SP msgno SP more SP seqno SP size So is it just poor text in Section 2.2.1.1 or is there a case where the parameters are really optional? I ask because it makes the ABNF different if any parameter is truely optional and it makes the parser need a few more checks for 'skipped' parameters (assuming one could 'leave off', say' more as the text seemingly implys). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... ------=_NextPart_000_031E_01C1BE03.EE835BD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
instead of "zero or more" it could say "six or = seven", i=20 suppose.
 
nothing is optional, however "ANS" has one more = parameter than=20 the others.
 
/mtr
----- Original Message -----
From:=20 Bruce_Kahn@notesdev.ibm.com=20
To: BEEPwg@lists.beepcore.org = ; ietf-calendar@imc.org
Sent: Monday, February 25, 2002 = 12:18
Subject: BEEP header & ABNF = Question


[Crossposting this = to BEEP and=20 CalSched WGs to insure proper coverage]

In my attempt to be come more BEEP savy and dealing with the = CAP issues=20 I was rereading the BEEP RFC and I think there is a small disjoin = between the=20 text and the ABNF that folks should be aware of (or they can point out = where=20 the corrective text is).  The text in Section 2.2.1.1 Frame = Header=20 says:

   The frame header = consists=20 of a three-character keyword (one of:
  "MSG", "RPY", "ERR", = "ANS", or=20 "NUL"), followed by zero or more
  parameters.  A = single=20 space character (decimal code 32, " ")
  separates each=20 component.

(my = emphasis) but=20 the ABNF in Section 2.2.1 Frame Syntax defines each of the parameters = as=20 mandatory:

   data   =  =20   =3D header payload trailer

  header     = =3D msg / rpy=20 / err / ans / nul

  =  msg  =20      =3D "MSG" SP common         =  CR=20 LF
  rpy        =3D "RPY" SP common   =  =20      CR LF
  ans        =3D = "ANS" SP=20 common SP ansno CR LF
  err        =3D = "ERR" SP=20 common          CR LF
  nul   =  =20    =3D "NUL" SP common          CR=20 LF

   common   =   =3D=20 channel SP msgno SP more SP seqno SP size

So is it just poor text in Section 2.2.1.1 = or is there=20 a case where the parameters are really optional?   =

I ask because it makes the ABNF different = if any=20 parameter is truely optional and it makes the parser need a few more = checks=20 for 'skipped' parameters (assuming one could 'leave off', say' more as = the=20 text seemingly implys).

Bruce
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Bruce=20 Kahn                   =  =20            INet:=20 Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration   =  =20             Phone: 978.399.6496
IBM = Software=20 Group                   =  =20     FAX: and nothing but the FAX...
Standard disclaimers = apply,=20 even where prohibited by law... ------=_NextPart_000_031E_01C1BE03.EE835BD0-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Mon Feb 25 17:00:42 2002 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 RAA01567 for ; Mon, 25 Feb 2002 17:00:42 -0500 (EST) Received: from qawoor.dbc.mtview.ca.us (localhost [127.0.0.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g1PLr3i04351; Mon, 25 Feb 2002 13:53:03 -0800 (PST) Received: from capricorn.iris.com (capricorn.notesdev.ibm.com [198.112.211.43]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g1PKAki03686 for ; Mon, 25 Feb 2002 12:10:46 -0800 (PST) To: BEEPwg@lists.beepcore.org, ietf-calendar@imc.org MIME-Version: 1.0 X-Mailer: Lotus Notes Build V60_02192002 February 19, 2002 Message-ID: From: Bruce_Kahn@notesdev.ibm.com X-MIMETrack: Serialize by Router on Capricorn/Iris(Build V60_02122002|February 12, 2002) at 02/25/2002 03:13:53 PM, Serialize complete at 02/25/2002 03:13:53 PM Content-Type: multipart/alternative; boundary="=_alternative 006F768985256B6B_=" Subject: [BEEPwg] BEEP header & ABNF Question 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, 25 Feb 2002 15:18:09 -0500 This is a multipart message in MIME format. --=_alternative 006F768985256B6B_= Content-Type: text/plain; charset="US-ASCII" [Crossposting this to BEEP and CalSched WGs to insure proper coverage] In my attempt to be come more BEEP savy and dealing with the CAP issues I was rereading the BEEP RFC and I think there is a small disjoin between the text and the ABNF that folks should be aware of (or they can point out where the corrective text is). The text in Section 2.2.1.1 Frame Header says: The frame header consists of a three-character keyword (one of: "MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or more parameters. A single space character (decimal code 32, " ") separates each component. (my emphasis) but the ABNF in Section 2.2.1 Frame Syntax defines each of the parameters as mandatory: data = header payload trailer header = msg / rpy / err / ans / nul msg = "MSG" SP common CR LF rpy = "RPY" SP common CR LF ans = "ANS" SP common SP ansno CR LF err = "ERR" SP common CR LF nul = "NUL" SP common CR LF common = channel SP msgno SP more SP seqno SP size So is it just poor text in Section 2.2.1.1 or is there a case where the parameters are really optional? I ask because it makes the ABNF different if any parameter is truely optional and it makes the parser need a few more checks for 'skipped' parameters (assuming one could 'leave off', say' more as the text seemingly implys). Bruce =========================================================================== Bruce Kahn INet: Bruce_Kahn@notesdev.ibm.com Messaging & Collaboration Phone: 978.399.6496 IBM Software Group FAX: and nothing but the FAX... Standard disclaimers apply, even where prohibited by law... --=_alternative 006F768985256B6B_= Content-Type: text/html; charset="US-ASCII"
[Crossposting this to BEEP and CalSched WGs to insure proper coverage]

In my attempt to be come more BEEP savy and dealing with the CAP issues I was rereading the BEEP RFC and I think there is a small disjoin between the text and the ABNF that folks should be aware of (or they can point out where the corrective text is).  The text in Section 2.2.1.1 Frame Header says:

   The frame header consists of a three-character keyword (one of:
  "MSG", "RPY", "ERR", "ANS", or "NUL"), followed by zero or more
  parameters.  A single space character (decimal code 32, " ")
  separates each component.

(my emphasis) but the ABNF in Section 2.2.1 Frame Syntax defines each of the parameters as mandatory:

   data       = header payload trailer

  header     = msg / rpy / err / ans / nul
   msg        = "MSG" SP common          CR LF
  rpy        = "RPY" SP common          CR LF
  ans        = "ANS" SP common SP ansno CR LF
  err        = "ERR" SP common          CR LF
  nul        = "NUL" SP common          CR LF
   common     = channel SP msgno SP more SP seqno SP size

So is it just poor text in Section 2.2.1.1 or is there a case where the parameters are really optional?  

I ask because it makes the ABNF different if any parameter is truely optional and it makes the parser need a few more checks for 'skipped' parameters (assuming one could 'leave off', say' more as the text seemingly implys).

Bruce
===========================================================================
Bruce Kahn                                INet: Bruce_Kahn@notesdev.ibm.com
Messaging & Collaboration                 Phone: 978.399.6496
IBM Software Group                         FAX: and nothing but the FAX...
Standard disclaimers apply, even where prohibited by law... --=_alternative 006F768985256B6B_=-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg