From beepwg-admin@lists.beepcore.org Fri Aug 2 15:44: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 PAA03447 for ; Fri, 2 Aug 2002 15:44:08 -0400 (EDT) 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 g72Je9Q14076; Fri, 2 Aug 2002 12:40:10 -0700 (PDT) Received: from cisco.com (titans.cisco.com [161.44.72.74]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g72JdxQ14054 for ; Fri, 2 Aug 2002 12:39:59 -0700 (PDT) Received: (from gdweber@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id PAA13243; Fri, 2 Aug 2002 15:43:50 -0400 (EDT) From: Greg Weber Message-Id: <200208021943.PAA13243@cisco.com> Subject: Re: [BEEPwg] Channel response serialization To: mrose@dbc.mtview.ca.us (Marshall Rose) Cc: paandrew@cisco.com (Paul Andrews), beepwg@lists.beepcore.org, mrose@dbc.mtview.ca.us (Marshall Rose) In-Reply-To: <007501c23409$059b9eb0$8c00000a@easyinc> from "Marshall Rose" at Jul 25, 2002 11:28:06 AM X-Mailer: ELM [version 2.5 PL1] 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: Fri, 2 Aug 2002 15:43:50 -0400 (EDT) Content-Transfer-Encoding: 7bit Would it be possible to use this beep extension mechanism to negotiate the ability to send one-way messages (messages that do not have any replies)? Greg [new to beep...] > > > OK. I don't want to rat-hole on this so: do I understand correctly that > you > > are proposing to amend the RFC to make serialization on a channel > optional? > > no. what i'm proposing is that we use beep's extension mechanism (called > "features") and write a new document that talks defines a feature that > removes the same-order property. rfc3080 doesn't change. presumably a new > rfc gets published that describes how something implementing rfc3080 can > also say that it does the new thing too. > > /mtr > > > _______________________________________________ > 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 Fri Aug 2 16:27:35 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 QAA05052 for ; Fri, 2 Aug 2002 16:27:34 -0400 (EDT) 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 g72KO2Q14404; Fri, 2 Aug 2002 13:24:02 -0700 (PDT) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g72KNmQ14387 for ; Fri, 2 Aug 2002 13:23:49 -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 7AB3C13EFF; Fri, 2 Aug 2002 16:28:07 -0400 (EDT) To: Greg Weber Cc: mrose@dbc.mtview.ca.us (Marshall Rose), paandrew@cisco.com (Paul Andrews), beepwg@lists.beepcore.org Subject: Re: [BEEPwg] Channel response serialization References: <200208021943.PAA13243@cisco.com> From: Jered Floyd In-Reply-To: <200208021943.PAA13243@cisco.com> Message-ID: <87heidvwdk.fsf@questionably-configured.permabit.com> Lines: 10 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: 02 Aug 2002 16:28:07 -0400 Greg Weber writes: > Would it be possible to use this beep extension mechanism > to negotiate the ability to send one-way messages (messages > that do not have any replies)? Certainly. Is there some situation when this would be significantly better than MSG/NUL exchanges for you? --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Aug 2 16:58: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 QAA06076 for ; Fri, 2 Aug 2002 16:58:15 -0400 (EDT) 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 g72Ks3Q14620; Fri, 2 Aug 2002 13:54:03 -0700 (PDT) Received: from cisco.com (titans.cisco.com [161.44.72.74]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g72KreQ14608 for ; Fri, 2 Aug 2002 13:53:40 -0700 (PDT) Received: (from gdweber@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id QAA15665; Fri, 2 Aug 2002 16:57:43 -0400 (EDT) From: Greg Weber Message-Id: <200208022057.QAA15665@cisco.com> Subject: Re: [BEEPwg] Channel response serialization To: jered@permabit.com (Jered Floyd) Cc: gdweber@cisco.com (Greg Weber), mrose@dbc.mtview.ca.us (Marshall Rose), paandrew@cisco.com (Paul Andrews), beepwg@lists.beepcore.org In-Reply-To: <87heidvwdk.fsf@questionably-configured.permabit.com> from "Jered Floyd" at Aug 02, 2002 04:28:07 PM X-Mailer: ELM [version 2.5 PL1] 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: Fri, 2 Aug 2002 16:57:43 -0400 (EDT) Content-Transfer-Encoding: 7bit > > Greg Weber writes: > > > Would it be possible to use this beep extension mechanism > > to negotiate the ability to send one-way messages (messages > > that do not have any replies)? > > Certainly. Is there some situation when this would be significantly > better than MSG/NUL exchanges for you? I was thinking of performance/traffic. Lack of support for one-way messages despite reliable transport seems to be often cited in support of work similar to beep, e.g. draft-hessing-p2p-messaging-00.txt. Greg > > --Jered > > _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Aug 2 17:13: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 RAA06761 for ; Fri, 2 Aug 2002 17:13:28 -0400 (EDT) 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 g72LA3Q14766; Fri, 2 Aug 2002 14:10:03 -0700 (PDT) Received: from wetware.wetware.com (wetware.wetware.com [199.108.16.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g72L9SQ14744 for ; Fri, 2 Aug 2002 14:09:28 -0700 (PDT) Received: from kallisti.local.(ra05.wetware.com[199.108.16.85]) (1452 bytes) by wetware.wetware.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Fri, 2 Aug 2002 14:13:40 -0700 (PDT) (Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Jul-29) Subject: Re: [BEEPwg] Channel response serialization Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: BEEP WG To: Greg Weber From: james woodyatt In-Reply-To: <200208022057.QAA15665@cisco.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) 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, 2 Aug 2002 14:13:38 -0700 Content-Transfer-Encoding: 7bit On Friday, Aug 2, 2002, at 13:57 US/Pacific, Greg Weber wrote: > > I was thinking of performance/traffic. Lack of support for > one-way messages despite reliable transport seems to be often > cited in support of work similar to beep, e.g. > draft-hessing-p2p-messaging-00.txt. Here's my hipshot response to concerns about network overhead in BEEP: we want tuning profiles for compression protocols. I can imagine a compression protocol that squeezes a lot of bytes out of the BEEP header and trailer, as well as shaving some off the encodings of the management profile messages. Since I don't have a deep compelling need to see such protocols deployed, I'm not agitating loudly to contribute to their drafting. You want to do that? Go for it. I will wait for you here. --james _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Aug 6 15:48:06 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 PAA26264 for ; Tue, 6 Aug 2002 15:48:05 -0400 (EDT) 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 g76JbDQ21219; Tue, 6 Aug 2002 12:37:13 -0700 (PDT) Received: from exchange.visionsolutions.com (visionsolutions.com [204.1.130.5] (may be forged)) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g76Ie2Q20864 for ; Tue, 6 Aug 2002 11:40:02 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01C23D79.47CBC44E" Message-ID: X-MS-Has-Attach: yes Thread-Topic: About beep output and input stream Thread-Index: AcI9eUQxbRlCieXJRPm5gzDrcKFY+A== From: "Russell Hung" To: Subject: [BEEPwg] About beep output and input stream 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, 6 Aug 2002 11:44:22 -0700 This is a multi-part message in MIME format. ------_=_NextPart_001_01C23D79.47CBC44E Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C23D79.47CBC44E" ------_=_NextPart_002_01C23D79.47CBC44E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I have a question about the input and output stream of BEEP. I read the example on the book, "BEEP", written by Dr. Marshall T. Rose and published by O'Reilly. There is a client example on page 52: =20 try { channel.sendMSG(new StringOutputDataStream(request), reply); } catch { ....} =20 InputDataStream ds =3D reply.getNextReply().getDataStream(); InputStream is =3D ds.getInputStream(); =20 while(is.read() !=3D -1) { ++replyLength; }=20 =20 It uses the message reply object to get the input stream. That means we have to send a message and wait for the response. This is not what I want. What I need are two independent threads: one for listening to the port/messages and one for sending out the message through the port. Is there any way to have an independent InputStream? Thanks.=20 =20 Best Regards, =20 Russell Hung rhung@visionsolutions.com =20 ------_=_NextPart_002_01C23D79.47CBC44E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
Hi,
 
I have a question about the input = and output=20 stream of BEEP. I read the example on the book, "BEEP", = written by Dr.=20 Marshall T. Rose and published by O'Reilly. There is a = client example=20 on page 52:
 
try {
    = channel.sendMSG(new=20 StringOutputDataStream(request), reply);
} catch { ....}
 
InputDataStream ds =3D=20 reply.getNextReply().getDataStream();
InputStream is =3D=20 ds.getInputStream();
 
while(is.read() !=3D -1) = {
   =20 ++replyLength;
}
 
It uses the message reply object = to get the=20 input stream. That means we have to send a message and wait for the = response.=20 This is not what I want. What I need are two independent threads:=20 one for listening to the port/messages and one for sending out the = message=20 through the port. Is there any way to have an independent = InputStream?=20 Thanks.
 
Best Regards,
 
Russell Hung
rhung@visionsolutions.com
 
=00 ------_=_NextPart_002_01C23D79.47CBC44E-- ------_=_NextPart_001_01C23D79.47CBC44E Content-Type: image/jpeg; name="Leaves Bkgrd.jpg" Content-Transfer-Encoding: base64 Content-ID: <632492218@06082002-2D99> Content-Description: Leaves Bkgrd.jpg Content-Location: Leaves%20Bkgrd.jpg Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7QZAUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA AQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB AAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA MgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////// //////////////////8D6AAAAAD/////////////////////////////A+gAAAAA//////////// /////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQIAAAAAAAQ AAAAAQAAAkAAAAJAAAAAADhCSU0ECQAAAAAEzwAAAAEAAACAAAAAgAAAAYAAAMAAAAAEswAYAAH/ 2P/gABBKRklGAAECAQBIAEgAAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0 LjAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwM DAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAgACAAwEiAAIRAQMR Af/dAAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAA AQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVS wWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSl tcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFR YXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOE w9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A 6/v5hJJLhPYlA/glwklMpKVolP3pp7p++iSldvNKR3+SRS8klK+SU+CRSSUrv5JSOEo7pT2SUpKN EpMeJSJSUr4pJdkvjykp/9Dr+QkJIShKQT8E9iUEvJJLVJStfmkPw8UvglOsH70lK+PCUd0hwl8U lK8kvhwEvNL4JKUSkEtOEklKjxS0S58vNIpKUlB+SUa6duUoSU//0evTd0/YjhL569k9iUUkktJ8 0lKSBKR5S5SUrRLVIeSY68d0lL9vimGif+KXkkpWiXhHzS4S1RUoifIJaBKdPJL4oKV5/elOmiXw SnXQpKf/0uv14SOqQ8PuSPMp7EpLulKRn5JKUkPvT88pu89+ySlJQAl/rCRjg/JJS3h+Cf8AIkkf E/gkpXKQ8kvuSmPJJStO6RSS/KkpXhPdJKfH5JJKf//T69LjQpf6yl+RPYlf6hLzSB/3JdklK8+3 glz/ABKSUapKVPilx/sSB8PklISUqNP70vxCRSSUrRJKI80vNJSu6RS5S0+SSlJcaH70pCUJKf/U 6/4JDwS+CXKexK+KRMJaz8Eo7JKV3SidTwkkQkpRPyS7pSEklK5SS8+6SSla8pJtDpx5J0lLaJz/ ALwl240SJhJSo1+HZL8qXmlqR8UlP//V67wP4JylH3pTrHfunsSkuPNL8vZLySUrlJNyU6SlJdpS Snx7d0lK158UvMfclyNO6XCSlHRIJfxSSUpIpJQkpQ1SS1kSkkp//9br5180pHZKUpjT8U9iVyUu 2iXxCWqSldvBJLTsUuP4pKV2SA/2Jo08E6SlTokEuNEklKmEkw5TwOUlK8kkvwKRSUqfx4TpkuNB 80lP/9kAOEJJTQQGAAAAAAAHAAMBAQABAQD//gAnRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rv c2hvcKggNC4wAP/uACFBZG9iZQBkAAAAAAEDABADAgMGAAAAAAAAAAAAAAAA/9sAhAAKBwcHCAcK CAgKDwoICg8SDQoKDRIUEBASEBAUEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM AQsMDBUTFSIYGCIUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAz/wgARCADIAMgDAREAAhEBAxEB/8QAfgABAQEBAAAAAAAAAAAAAAAAAAECBgEBAQEB AAAAAAAAAAAAAAAAAAECAxABAAICAwEBAQEAAAAAAAAAAQARECEgMDFBAkASEQACAgIDAAIDAQEB AQAAAAAAAREhMUEQUWFxgZGxwaEi0RISAQAAAAAAAAAAAAAAAAAAAJD/2gAMAwEBAhEDEQAAAO04 bikKQpAUCpAUgWyKigVIpAAi0iUJGqghQCpLRI1QkQpagiLUAtiWKZtsgBSAFJZcVpBbZIW1JAUk tsgKkUAVYlIKsRakBSLUliWkFtSSFKQUJFpKQQ1bItkgFlzVkWhDSySLQEUi2ySLbKQQKublLaRC iipAoJF0kUJGiAhVtSQi6QsQAFBEtsgUAlVGbLAaJUjVFkSyyLpIWWWRagWoIUiGrZIFIUEBSAAR aiFWWI1UgAW2SAsssKCUiipFJLbIWxLELbBJaKEhSQqxm2pVkNEEFIAqrIWJRKsikQ1UEC1JZZVi USrEKLEFhSBDVSBFWWFJZZYhS1IAW1IqRSQoEC1FJVJFJF0kqrJCwokCgKspIAWpIW1M22KkUhVS KlIIVFokW2CFiKKQFCS2xAAUgWpBVgKRFqRCikFIpEKC2wjNVEXVkEQq2ySLUW2SBRUS5soAgqgE isrtIW2QCLRcpYhVWSKCFAsSrZJSFBC0gpFIUEAWsy1FUzFAtSC25LCkiggi2S1FpIWFUhJdWQKC BAAUiKssKCWWJbYktslIUyUssspKQhq2TNagsSyxJpYWpKsSLUC25Z1LAUlJZZYUgssslosgKCFI hRZVkBf/2gAIAQIAAQUAIvB43Di8bhF6Hh84srh86Xh5wOZzewxVdD7wOm4YXsOIcXoHrM1Lx87L xeXFR5XHF4OFc71weB0OQzXI5PXUeV9dS49PvTeXIcnocXzqV03lOlw4Hk4vFYeF4ZXK++8Vyeyp XOudwjn501m8HH5kIPO8ByZXA4E+4cJ1+SuusXPnJ43yvJkzUqXfCs3moPVUeF8w7L4BisOK4h0P vQuXoWf/2gAIAQMAAQUAcMviS4RzeLyS4Rw8jqrorBmuFdd5DjWLw5cV1L0vReDvDFQxXKsuPMOa zfA51ip8hK76wOb43KzX8Liug51/EuayS+Rwrg9FcTsZceN8CXyqpfZXC+dxxfA7jFx7GEcGXB11 hyub4Xi+VcbxfKo8CVj5wDhWaycSLLwcXJkOgl8F5s8x8vi9t32LiulwcmGHi5vNcL5EOLxOFcDs qViv4nj/AP/aAAgBAQABBQB3KK1LQ9B1W2jF78XcQDTN17Bmr1CXvxdyitRN6nsps3EIaLl2hWKh GiVPJ+Xe0BlQExUPFZbELusUEFly9u4bKUZQMbpqqi1EE8w2zcQvSm4XGbt8giaxe/SmXEubC9XB uaJW2VcJ5DcLpLmiBu5VzUqEWNk1B2T6tRKgBNRqW3aSyNSyVPJphG5uqAra/wCf02Mrfsqi5Uqb H47hRPv6LN1shufKI3Wp4nhYlMZutT/NR8FuJA/UEZaT8q4tEblg6nylZRYjKouVLhcQs9+1Ladw dBSEux/WtRu0YVaNghY4ojsBuUXGfm5VwoKx7C4XL3Re58LiDA2rC6Ze/taKZQpo3PES/Z5HT+bp LGA0JPI7gVKqPjU3ZcQumWkvcqo6Ft+lrPmrqXoVjTEQuwhWKLUw3C61EH9O0d/arHsChuWQlaib u3CWWEYfkjUslVDzYlM+toanksSkbYT8iS9sWJZYRnsq5e/Y7n0bmgu1CCTxFtI7l7Z8hVexLnsq 5e7lkPPJWnR/ot3ELqaIm/I+/l3tAZThtKlXCowGts3gES7hNxahbAoqoeLqF2gwsX38ui2IkVq9 CsdzcJuVtdiP5GimDSgu7fal4qoeem4Lfj+q/RWoCYqXr40wuos/IxALt9gVKJtjcLpJRAl1Ny7H FXNxN6on27xtiteT6lyowtbh5RZdK4TdF1YXTU1VDNBdqEu4x9+XumJZu1pKW9Rj6TyAMaIaKKik fH8wd0T7dTUoi6LIeOzyXEZe7qaI1NRowWxodMNKtg0yy/Volq1csIOkYk8jcKnr+jXw1jTGKyiN 1qbsGUW0z75FpG0uErZH9UEaZdN3PIlxRh+ZqbcUWI4fV15LbTXgu9M3QrA38XXy0al0E+t2DVRQ dMfC1QzbZuOwNkbq2eRDNt//2gAIAQICBj8AHH//2gAIAQMCBj8AHH//2gAIAQEBBj8AgghaIm++ MV2SSTJ50KLfRBHRR72RtEQekkpnnQot9EEELQoO+M0j4zx5xmHonJ6Si8mInohueHV9jimS/sp/ BesnpKLIIxw+uJmOz9Mt4EnXF0U4fEiapHpD3xPHpZWeJIWuLJRk/hGOLvo9McTMwJf5x2UuJyie f0KL7P4XkvJ6hLb1x+idk9FZ0Xksqy983ronTJR/rI0ecOiiyrP0OWT+CGRvQuxlCT3sUX2eFuij 9HyOcOyPwVh5Ksh48P8A562y6XZCr1CTyubK5yfI4wfBR+xfoon/AAUWtkf6LtFYGlbREcJ9Hmyh w76KI2LTRP5Jgg+eK+yiUeo7PCinHFqCe+HBOiNEaPT50Mtyxfvj0rJKqMk6I+zwrGx9PBDJeRQf sgvHHR/Bel/klOUyfwf+jjOkTt6474slYZ6RsSX2JHheDw8If0Q8n9Ieez4ou+jMHnRCZ7zWGTsZ Z1xTzwl3sjmBp/SJxx0YJVsT70WRw5Vd8x3hkTZOyetmbRZGivxxiCMoTj5LVlkdEJiivSHxars9 I2eMnZ4uPMnjHcJHq4umXZSlH8JQp/wgcX4yH+Sl9kHpGzx8TscqCSVokh0fOSiUUdvUmBa4hokp Vxk9RD+nxOxyoFURxD/PMvAl2Qvsnok+T4IL2Or7HFMl/YiCETvjqD+kPPZaI09lE95RZGirIJeh PRZKeSxVMiQiMEZIMQxMzkuuOjJEkcQj1Ek5Jynoql4Rh8fI4/HGBw+LP6eHfhDtekdEJl6yekov JOxdmMcUy/s7POz9Dl4JOhrehVfRkjOy8E7RKsspfZZTh9nRK4/0fR1HDKV9FcRkrAv2OVSwyZ4n D4rPXGaIzGxXZDyhTkr74+clEorifwK/khZEiE4YkQSvtMkU/nifwLfZ/CcPZWNkTPpZGxLbIE5t E/k84Z/zsmP+iXo7TPT0iD+FOCBn/JLJMcOU0xtk/jh96PdlEL8EYKox9n7Q+lokrBB8kkZIwQqY qvZiyehzoS6O+ysc5Op4XWyNEFmIjfMqhmJ8I+hdbLxw7nwV42UZyekY7PETB8E6JWDw/pEEctYj RVwTEEjg8I/0hI92T3ji8HjIbvs9QlviFkTxGUdrYqzgsnKeD0vJi9lYITtlo8Z2tirOCycp4P/Z ------_=_NextPart_001_01C23D79.47CBC44E-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Aug 6 15:54:23 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 PAA26569 for ; Tue, 6 Aug 2002 15:54:22 -0400 (EDT) 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 g76Jl2Q21299; Tue, 6 Aug 2002 12:47:02 -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.3/8.11.5) with ESMTP id g76JkKQ21287 for ; Tue, 6 Aug 2002 12:46:20 -0700 (PDT) Received: from dev0196 ([65.125.189.73]) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g76Jo5s05410; Tue, 6 Aug 2002 12:50:05 -0700 (PDT) Message-ID: <013501c23d82$ce751e60$6500000a@dev0196> From: "Marshall Rose" To: "Russell Hung" , Cc: "Marshall Rose" References: Subject: Re: [BEEPwg] About beep output and input stream MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0131_01C23D48.21667E60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 6 Aug 2002 12:52:32 -0700 This is a multi-part message in MIME format. ------=_NextPart_000_0131_01C23D48.21667E60 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0132_01C23D48.21667E60" ------=_NextPart_001_0132_01C23D48.21667E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Messagehi. please send your note to = beepcore-java-users@lists.sourceforge.net... and maybe someone there can = answer it. /mtr ----- Original Message -----=20 From: Russell Hung=20 To: beepwg@lists.beepcore.org=20 Sent: Tuesday, August 06, 2002 11:44 AM Subject: [BEEPwg] About beep output and input stream Hi, I have a question about the input and output stream of BEEP. I read = the example on the book, "BEEP", written by Dr. Marshall T. Rose and = published by O'Reilly. There is a client example on page 52: try { channel.sendMSG(new StringOutputDataStream(request), reply); } catch { ....} InputDataStream ds =3D reply.getNextReply().getDataStream(); InputStream is =3D ds.getInputStream(); while(is.read() !=3D -1) { ++replyLength; }=20 It uses the message reply object to get the input stream. That means = we have to send a message and wait for the response. This is not what I = want. What I need are two independent threads: one for listening to the = port/messages and one for sending out the message through the port. Is = there any way to have an independent InputStream? Thanks.=20 Best Regards, Russell Hung rhung@visionsolutions.com ------=_NextPart_001_0132_01C23D48.21667E60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message
hi. please send your note to beepcore-java-u= sers@lists.sourceforge.net...=20 and maybe someone there can answer it.
 
/mtr
----- Original Message -----
From:=20 Russell Hung
Sent: Tuesday, August 06, 2002 = 11:44=20 AM
Subject: [BEEPwg] About beep = output and=20 input stream

Hi,
 
I have a question about the = input and=20 output stream of BEEP. I read the example on the book, "BEEP",=20 written by Dr. Marshall T. Rose and published by O'Reilly. = There is=20 a client example on page 52:
 
try {
    = channel.sendMSG(new=20 StringOutputDataStream(request), reply);
} catch { ....}
 
InputDataStream ds =3D=20 reply.getNextReply().getDataStream();
InputStream is =3D=20 ds.getInputStream();
 
while(is.read() !=3D -1) = {
   =20 ++replyLength;
}
 
It uses the message reply object = to get=20 the input stream. That means we have to send a message and wait for = the=20 response. This is not what I want. What I need are two = independent=20 threads: one for listening to the port/messages and one for = sending out=20 the message through the port. Is there any way to have an = independent=20 InputStream? Thanks.
 
Best Regards,
 
Russell Hung
rhung@visionsolutions.com
 
------=_NextPart_001_0132_01C23D48.21667E60-- ------=_NextPart_000_0131_01C23D48.21667E60 Content-Type: image/jpeg; name="Leaves Bkgrd.jpg" Content-Transfer-Encoding: base64 Content-ID: <013001c23d82$cdb79ac0$6500000a@dev0196> Content-Location: Leaves%20Bkgrd.jpg Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgEASABIAAD/7QZAUGhvdG9zaG9wIDMuMAA4QklNA+0AAAAAABAASAAAAAEA AQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAAAAEAADhCSU0nEAAAAAAACgAB AAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEAL2ZmAAEAoZmaAAYAAAAAAAEA MgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklNA/gAAAAAAHAAAP////////// //////////////////8D6AAAAAD/////////////////////////////A+gAAAAA//////////// /////////////////wPoAAAAAP////////////////////////////8D6AAAOEJJTQQIAAAAAAAQ AAAAAQAAAkAAAAJAAAAAADhCSU0ECQAAAAAEzwAAAAEAAACAAAAAgAAAAYAAAMAAAAAEswAYAAH/ 2P/gABBKRklGAAECAQBIAEgAAP/+ACdGaWxlIHdyaXR0ZW4gYnkgQWRvYmUgUGhvdG9zaG9wqCA0 LjAA/+4ADkFkb2JlAGSAAAAAAf/bAIQADAgICAkIDAkJDBELCgsRFQ8MDA8VGBMTFRMTGBEMDAwM DAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAENCwsNDg0QDg4QFA4ODhQUDg4ODhQRDAwM DAwREQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM/8AAEQgAgACAAwEiAAIRAQMR Af/dAAQACP/EAT8AAAEFAQEBAQEBAAAAAAAAAAMAAQIEBQYHCAkKCwEAAQUBAQEBAQEAAAAAAAAA AQACAwQFBgcICQoLEAABBAEDAgQCBQcGCAUDDDMBAAIRAwQhEjEFQVFhEyJxgTIGFJGhsUIjJBVS wWIzNHKC0UMHJZJT8OHxY3M1FqKygyZEk1RkRcKjdDYX0lXiZfKzhMPTdePzRieUpIW0lcTU5PSl tcXV5fVWZnaGlqa2xtbm9jdHV2d3h5ent8fX5/cRAAICAQIEBAMEBQYHBwYFNQEAAhEDITESBEFR YXEiEwUygZEUobFCI8FS0fAzJGLhcoKSQ1MVY3M08SUGFqKygwcmNcLSRJNUoxdkRVU2dGXi8rOE w9N14/NGlKSFtJXE1OT0pbXF1eX1VmZ2hpamtsbW5vYnN0dXZ3eHl6e3x//aAAwDAQACEQMRAD8A 6/v5hJJLhPYlA/glwklMpKVolP3pp7p++iSldvNKR3+SRS8klK+SU+CRSSUrv5JSOEo7pT2SUpKN EpMeJSJSUr4pJdkvjykp/9Dr+QkJIShKQT8E9iUEvJJLVJStfmkPw8UvglOsH70lK+PCUd0hwl8U lK8kvhwEvNL4JKUSkEtOEklKjxS0S58vNIpKUlB+SUa6duUoSU//0evTd0/YjhL569k9iUUkktJ8 0lKSBKR5S5SUrRLVIeSY68d0lL9vimGif+KXkkpWiXhHzS4S1RUoifIJaBKdPJL4oKV5/elOmiXw SnXQpKf/0uv14SOqQ8PuSPMp7EpLulKRn5JKUkPvT88pu89+ySlJQAl/rCRjg/JJS3h+Cf8AIkkf E/gkpXKQ8kvuSmPJJStO6RSS/KkpXhPdJKfH5JJKf//T69LjQpf6yl+RPYlf6hLzSB/3JdklK8+3 glz/ABKSUapKVPilx/sSB8PklISUqNP70vxCRSSUrRJKI80vNJSu6RS5S0+SSlJcaH70pCUJKf/U 6/4JDwS+CXKexK+KRMJaz8Eo7JKV3SidTwkkQkpRPyS7pSEklK5SS8+6SSla8pJtDpx5J0lLaJz/ ALwl240SJhJSo1+HZL8qXmlqR8UlP//V67wP4JylH3pTrHfunsSkuPNL8vZLySUrlJNyU6SlJdpS Snx7d0lK158UvMfclyNO6XCSlHRIJfxSSUpIpJQkpQ1SS1kSkkp//9br5180pHZKUpjT8U9iVyUu 2iXxCWqSldvBJLTsUuP4pKV2SA/2Jo08E6SlTokEuNEklKmEkw5TwOUlK8kkvwKRSUqfx4TpkuNB 80lP/9kAOEJJTQQGAAAAAAAHAAMBAQABAQD//gAnRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rv c2hvcKggNC4wAP/uACFBZG9iZQBkAAAAAAEDABADAgMGAAAAAAAAAAAAAAAA/9sAhAAKBwcHCAcK CAgKDwoICg8SDQoKDRIUEBASEBAUEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwM AQsMDBUTFSIYGCIUDg4OFBQODg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwM DAwMDAwMDAz/wgARCADIAMgDAREAAhEBAxEB/8QAfgABAQEBAAAAAAAAAAAAAAAAAAECBgEBAQEB AAAAAAAAAAAAAAAAAAECAxABAAICAwEBAQEAAAAAAAAAAQARECEgMDFBAkASEQACAgIDAAIDAQEB AQAAAAAAAREhMUEQUWFxgZGxwaEi0RISAQAAAAAAAAAAAAAAAAAAAJD/2gAMAwEBAhEDEQAAAO04 bikKQpAUCpAUgWyKigVIpAAi0iUJGqghQCpLRI1QkQpagiLUAtiWKZtsgBSAFJZcVpBbZIW1JAUk tsgKkUAVYlIKsRakBSLUliWkFtSSFKQUJFpKQQ1bItkgFlzVkWhDSySLQEUi2ySLbKQQKublLaRC iipAoJF0kUJGiAhVtSQi6QsQAFBEtsgUAlVGbLAaJUjVFkSyyLpIWWWRagWoIUiGrZIFIUEBSAAR aiFWWI1UgAW2SAsssKCUiipFJLbIWxLELbBJaKEhSQqxm2pVkNEEFIAqrIWJRKsikQ1UEC1JZZVi USrEKLEFhSBDVSBFWWFJZZYhS1IAW1IqRSQoEC1FJVJFJF0kqrJCwokCgKspIAWpIW1M22KkUhVS KlIIVFokW2CFiKKQFCS2xAAUgWpBVgKRFqRCikFIpEKC2wjNVEXVkEQq2ySLUW2SBRUS5soAgqgE isrtIW2QCLRcpYhVWSKCFAsSrZJSFBC0gpFIUEAWsy1FUzFAtSC25LCkiggi2S1FpIWFUhJdWQKC BAAUiKssKCWWJbYktslIUyUssspKQhq2TNagsSyxJpYWpKsSLUC25Z1LAUlJZZYUgssslosgKCFI hRZVkBf/2gAIAQIAAQUAIvB43Di8bhF6Hh84srh86Xh5wOZzewxVdD7wOm4YXsOIcXoHrM1Lx87L xeXFR5XHF4OFc71weB0OQzXI5PXUeV9dS49PvTeXIcnocXzqV03lOlw4Hk4vFYeF4ZXK++8Vyeyp XOudwjn501m8HH5kIPO8ByZXA4E+4cJ1+SuusXPnJ43yvJkzUqXfCs3moPVUeF8w7L4BisOK4h0P vQuXoWf/2gAIAQMAAQUAcMviS4RzeLyS4Rw8jqrorBmuFdd5DjWLw5cV1L0vReDvDFQxXKsuPMOa zfA51ip8hK76wOb43KzX8Liug51/EuayS+Rwrg9FcTsZceN8CXyqpfZXC+dxxfA7jFx7GEcGXB11 hyub4Xi+VcbxfKo8CVj5wDhWaycSLLwcXJkOgl8F5s8x8vi9t32LiulwcmGHi5vNcL5EOLxOFcDs qViv4nj/AP/aAAgBAQABBQB3KK1LQ9B1W2jF78XcQDTN17Bmr1CXvxdyitRN6nsps3EIaLl2hWKh GiVPJ+Xe0BlQExUPFZbELusUEFly9u4bKUZQMbpqqi1EE8w2zcQvSm4XGbt8giaxe/SmXEubC9XB uaJW2VcJ5DcLpLmiBu5VzUqEWNk1B2T6tRKgBNRqW3aSyNSyVPJphG5uqAra/wCf02Mrfsqi5Uqb H47hRPv6LN1shufKI3Wp4nhYlMZutT/NR8FuJA/UEZaT8q4tEblg6nylZRYjKouVLhcQs9+1Ladw dBSEux/WtRu0YVaNghY4ojsBuUXGfm5VwoKx7C4XL3Re58LiDA2rC6Ze/taKZQpo3PES/Z5HT+bp LGA0JPI7gVKqPjU3ZcQumWkvcqo6Ft+lrPmrqXoVjTEQuwhWKLUw3C61EH9O0d/arHsChuWQlaib u3CWWEYfkjUslVDzYlM+toanksSkbYT8iS9sWJZYRnsq5e/Y7n0bmgu1CCTxFtI7l7Z8hVexLnsq 5e7lkPPJWnR/ot3ELqaIm/I+/l3tAZThtKlXCowGts3gES7hNxahbAoqoeLqF2gwsX38ui2IkVq9 CsdzcJuVtdiP5GimDSgu7fal4qoeem4Lfj+q/RWoCYqXr40wuos/IxALt9gVKJtjcLpJRAl1Ny7H FXNxN6on27xtiteT6lyowtbh5RZdK4TdF1YXTU1VDNBdqEu4x9+XumJZu1pKW9Rj6TyAMaIaKKik fH8wd0T7dTUoi6LIeOzyXEZe7qaI1NRowWxodMNKtg0yy/Volq1csIOkYk8jcKnr+jXw1jTGKyiN 1qbsGUW0z75FpG0uErZH9UEaZdN3PIlxRh+ZqbcUWI4fV15LbTXgu9M3QrA38XXy0al0E+t2DVRQ dMfC1QzbZuOwNkbq2eRDNt//2gAIAQICBj8AHH//2gAIAQMCBj8AHH//2gAIAQEBBj8AgghaIm++ MV2SSTJ50KLfRBHRR72RtEQekkpnnQot9EEELQoO+M0j4zx5xmHonJ6Si8mInohueHV9jimS/sp/ BesnpKLIIxw+uJmOz9Mt4EnXF0U4fEiapHpD3xPHpZWeJIWuLJRk/hGOLvo9McTMwJf5x2UuJyie f0KL7P4XkvJ6hLb1x+idk9FZ0Xksqy983ronTJR/rI0ecOiiyrP0OWT+CGRvQuxlCT3sUX2eFuij 9HyOcOyPwVh5Ksh48P8A562y6XZCr1CTyubK5yfI4wfBR+xfoon/AAUWtkf6LtFYGlbREcJ9Hmyh w76KI2LTRP5Jgg+eK+yiUeo7PCinHFqCe+HBOiNEaPT50Mtyxfvj0rJKqMk6I+zwrGx9PBDJeRQf sgvHHR/Bel/klOUyfwf+jjOkTt6474slYZ6RsSX2JHheDw8If0Q8n9Ieez4ou+jMHnRCZ7zWGTsZ Z1xTzwl3sjmBp/SJxx0YJVsT70WRw5Vd8x3hkTZOyetmbRZGivxxiCMoTj5LVlkdEJiivSHxars9 I2eMnZ4uPMnjHcJHq4umXZSlH8JQp/wgcX4yH+Sl9kHpGzx8TscqCSVokh0fOSiUUdvUmBa4hokp Vxk9RD+nxOxyoFURxD/PMvAl2Qvsnok+T4IL2Or7HFMl/YiCETvjqD+kPPZaI09lE95RZGirIJeh PRZKeSxVMiQiMEZIMQxMzkuuOjJEkcQj1Ek5Jynoql4Rh8fI4/HGBw+LP6eHfhDtekdEJl6yekov JOxdmMcUy/s7POz9Dl4JOhrehVfRkjOy8E7RKsspfZZTh9nRK4/0fR1HDKV9FcRkrAv2OVSwyZ4n D4rPXGaIzGxXZDyhTkr74+clEorifwK/khZEiE4YkQSvtMkU/nifwLfZ/CcPZWNkTPpZGxLbIE5t E/k84Z/zsmP+iXo7TPT0iD+FOCBn/JLJMcOU0xtk/jh96PdlEL8EYKox9n7Q+lokrBB8kkZIwQqY qvZiyehzoS6O+ysc5Op4XWyNEFmIjfMqhmJ8I+hdbLxw7nwV42UZyekY7PETB8E6JWDw/pEEctYj RVwTEEjg8I/0hI92T3ji8HjIbvs9QlviFkTxGUdrYqzgsnKeD0vJi9lYITtlo8Z2tirOCycp4P/Z ------=_NextPart_000_0131_01C23D48.21667E60-- _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Fri Aug 9 15:32: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 PAA08328 for ; Fri, 9 Aug 2002 15:32:01 -0400 (EDT) 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 g79JR8Q20875; Fri, 9 Aug 2002 12:27:08 -0700 (PDT) Received: from mail7.atl.registeredsite.com (nobody@mail7.atl.registeredsite.com [64.224.219.81]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g79JQQQ20863 for ; Fri, 9 Aug 2002 12:26:26 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail7.atl.registeredsite.com (8.12.2/8.12.5) with ESMTP id g79JVW9R024020 for ; Fri, 9 Aug 2002 15:31:33 -0400 Received: from central [64.225.30.241] by mail.clipcode.com with ESMTP (SMTPD32-6.06) id A8DA100400F8; Fri, 09 Aug 2002 15:32:42 -0400 From: "Eamon O'Tuathail" To: Message-ID: <000501c23fdb$5a4eb310$293a869f@central> 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.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [BEEPwg] Liberty Alliance / SAML and 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: Fri, 9 Aug 2002 20:31:24 +0100 Content-Transfer-Encoding: 7bit Is anyone looking into the use of the Liberty Alliance / SAML work with BEEP sessions? _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Aug 14 11:26:27 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 LAA13334 for ; Wed, 14 Aug 2002 11:26:26 -0400 (EDT) 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 g7EFJAQ07820; Wed, 14 Aug 2002 08:19:12 -0700 (PDT) Received: from monsoon.us.ny.firstrain.com ([208.198.42.246]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7EFI8Q07805 for ; Wed, 14 Aug 2002 08:18:09 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: Thread-Topic: 4K Limit to Profile element length Thread-Index: AcJDppxU584kWuOqTh2L3MBpK67sug== From: "Bob Wyman" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by qawoor.dbc.mtview.ca.us id g7EFI8Q07805 Subject: [BEEPwg] 4K Limit to Profile element length 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, 14 Aug 2002 11:23:59 -0400 Content-Transfer-Encoding: 8bit Forgive me for a very simple question: RFC3080 says at "2.3.1.2 The Start Message" that: "the content of the "profile" element, if present, must be no longer than 4K octets in length". The question is: If the content of the profile element is encoded (Base64), then does the length restriction apply to the encoded form of the content or to the result after decoding? i.e. if encoding causes the size of the data to grow, does that matter? bob wyman _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Aug 14 11:54: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 LAA14548 for ; Wed, 14 Aug 2002 11:54:27 -0400 (EDT) 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 g7EFo3Q08084; Wed, 14 Aug 2002 08:50:03 -0700 (PDT) Received: from mail.franklin.ro ([166.70.87.233]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g7EFnBQ08062 for ; Wed, 14 Aug 2002 08:49:11 -0700 (PDT) Received: (qmail 26374 invoked from network); 14 Aug 2002 16:54:37 -0000 Received: from dhcp-12.franklin.ro (HELO boys) (10.0.1.12) by bob.franklin.ro with SMTP; 14 Aug 2002 16:54:37 -0000 Message-ID: <00cf01c243aa$5ddde640$0c01000a@boys> From: "Huston" To: "Bob Wyman" , References: Subject: Re: [BEEPwg] 4K Limit to Profile element length MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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, 14 Aug 2002 09:48:16 -0600 Content-Transfer-Encoding: 7bit I took it to mean 4k after encoding because that coincides with the default window size. --Huston ----- Original Message ----- From: "Bob Wyman" To: Sent: Wednesday, August 14, 2002 9:23 AM Subject: [BEEPwg] 4K Limit to Profile element length > Forgive me for a very simple question: > RFC3080 says at "2.3.1.2 The Start Message" that: "the content of the > "profile" element, if present, must be no longer than 4K octets in > length". > The question is: If the content of the profile element is > encoded (Base64), then does the length restriction apply to the encoded > form of the content or to the result after decoding? i.e. if encoding > causes the size of the data to grow, does that matter? > > bob wyman > _______________________________________________ > 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 Wed Aug 14 12:03:27 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 MAA14834 for ; Wed, 14 Aug 2002 12:03:26 -0400 (EDT) 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 g7EFx2Q08152; Wed, 14 Aug 2002 08:59:02 -0700 (PDT) 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 g7EFw6Q08140 for ; Wed, 14 Aug 2002 08:58:06 -0700 (PDT) Received: from san.rr.com (66-75-148-61.san.rr.com [66.75.148.61]) by smtp2.san.rr.com (8.11.4/8.11.4) with ESMTP id g7EG3cO29647 for ; Wed, 14 Aug 2002 09:03:42 -0700 (PDT) Message-ID: <3D5A7F67.403BF9CD@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] 4K Limit to Profile element length References: <00cf01c243aa$5ddde640$0c01000a@boys> 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: Wed, 14 Aug 2002 09:03:51 -0700 Content-Transfer-Encoding: 7bit Huston wrote: > I took it to mean 4k after encoding because that coincides with the default > window size. Except that you can have multiple profile elements in a start message, and you have extra overhead in the start messages too, so a limit of 4K here doesn't mean it fits in the default window size. -- Darren New San Diego, CA, USA (PST). Cryptokeys on demand. ** http://images.fbrtech.com/dnew/ ** Humility? Why would I need to show some humility? _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Aug 14 13:32: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 NAA18287 for ; Wed, 14 Aug 2002 13:32:41 -0400 (EDT) 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 g7EHS3Q08855; Wed, 14 Aug 2002 10:28:03 -0700 (PDT) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7EHRqQ08843 for ; Wed, 14 Aug 2002 10:27:53 -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 6676F13E41; Wed, 14 Aug 2002 13:33:23 -0400 (EDT) To: "Bob Wyman" Cc: Subject: Re: [BEEPwg] 4K Limit to Profile element length References: From: Jered Floyd In-Reply-To: Message-ID: <87hehxe464.fsf@questionably-configured.permabit.com> Lines: 18 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: 14 Aug 2002 13:33:23 -0400 "Bob Wyman" writes: > Forgive me for a very simple question: > RFC3080 says at "2.3.1.2 The Start Message" that: "the content of the > "profile" element, if present, must be no longer than 4K octets in > length". > The question is: If the content of the profile element is > encoded (Base64), then does the length restriction apply to the encoded > form of the content or to the result after decoding? i.e. if encoding > causes the size of the data to grow, does that matter? I believe this to refer to the result after encoding. When this is the case, the initialization message is always small enough to fit into the newly-created channel's window buffer (if, for some reason, an implementation chooses to put it there.) --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Aug 14 14:11:47 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 OAA19746 for ; Wed, 14 Aug 2002 14:11:46 -0400 (EDT) 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 g7EI73Q09132; Wed, 14 Aug 2002 11:07:03 -0700 (PDT) Received: from act-of-god.permabit.com (act-of-god.permabit.com [4.36.55.5]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7EI6uQ09120 for ; Wed, 14 Aug 2002 11:06:56 -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 912AB13E41; Wed, 14 Aug 2002 14:12:33 -0400 (EDT) To: "Bob Wyman" Cc: Subject: Re: [BEEPwg] 4K Limit to Profile element length References: <87hehxe464.fsf@questionably-configured.permabit.com> From: Jered Floyd In-Reply-To: <87hehxe464.fsf@questionably-configured.permabit.com> Message-ID: <87d6sle2cu.fsf@questionably-configured.permabit.com> Lines: 7 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: 14 Aug 2002 14:12:33 -0400 > I believe this to refer to the result after encoding. I, of course, meant "after decoding". I should proofread my mail before I send it, sorry. --Jered _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Aug 20 07:59:49 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 HAA11281 for ; Tue, 20 Aug 2002 07:59:49 -0400 (EDT) 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 g7KBsBV08278; Tue, 20 Aug 2002 04:54:11 -0700 (PDT) Received: from mail.bengburken.net (postfix@flintv156.sn.umu.se [130.239.145.210]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7KBr4V08266 for ; Tue, 20 Aug 2002 04:53:05 -0700 (PDT) Received: from localhost (skinner.codefactory.se [212.32.187.2]) by mail.bengburken.net (Postfix) with ESMTP id 3A18630826A for ; Tue, 20 Aug 2002 13:58:11 +0200 (CEST) Received: by localhost (Postfix, from userid 1000) id C705B12669D; Tue, 20 Aug 2002 13:59:04 +0200 (CEST) To: beepwg@lists.beepcore.org From: jonas@codefactory.se (Jonas =?iso-8859-1?q?Borgstr=F6m?=) Message-ID: <87sn19d9mf.fsf@bengburken.net> Lines: 149 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=latin-iso8859-1 Content-Transfer-Encoding: 8bit Subject: [BEEPwg] ANNOUNCE: roadrunner-0.9 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: 20 Aug 2002 13:59:04 +0200 Content-Transfer-Encoding: 8bit ---------------------------------------------------------------------------- -- RoadRunner 0.9 (An Egg) ------------------------------------------------- 20 Aug, 2002 CodeFactory proudly announces the availability of a new release of RoadRunner, an open source BEEP framework implemented in C. Introduction -------------- RoadRunner is an application toolkit library implementing BEEP (Blocks Extensible Exchange Protocol). Apart from implementing a powerful and flexible BEEP framework, RoadRunner also contains a useful set of profiles, readily available and usable with applications. RoadRunner provides a portable and powerful high-performance framework for developing network applications making use of the BEEP protocol. Changes since version 0.8 --------------------------- * Simplified API. For more info see the API_CHANGES file. * Stability improvements. * New functions. * Improved portability. * Support for AIX added. Supported Platforms --------------------- RoadRunner is primarily developed and regularly tested on GNU/Linux, NetBSD and OpenBSD, but has been compiled and tested on: * GNU/Linux * NetBSD * OpenBSD * FreeBSD * Solaris * MS Windows * AIX RoadRunner is written in portable C code, and should work without modification on all platforms supported by GLib 2 (GNU Utility library). Language Bindings ------------------- The portable design of RoadRunner and the fact that it is written in C enables simple creation of bindings for various languages. Experimental python bindings already exists (in the pyrr cvs module) and other bindings such as C++, Java, perl and scheme are planned. Strengths and Features ------------------------ * Portable * Object oriented design * High performance * Multi-threaded * Open Source Implemented BEEP Profiles --------------------------- RR/TLS -- Transport layer security RR/SASL -- Simple Authentication and Security Layer RR/Syslog -- Reliable delivery for syslog RR/IDXP -- Intrusion detection exchange protocol System Requirements --------------------- RoadRunner requires the following libraries to compile: * Glib 2.0.1 or higher (http://www.gtk.org/) * libxml 2.4.16 or higher (http://www.libxml.org/) The RoadRunner profiles require some extra libraries: * OpenSSL (Used by RR/TLS. http://www.openssl.org/) * Cyrus libsasl2 (Used by RR/SASL. http://asg.web.cmu.edu/sasl/) What is BEEP -------------- BEEP (the Block Extensible Exchange Protocol, rfc3080,3081) is a protocol framework for connection oriented asynchronous message exchange. All message exchange occur in the context of a channel. A profile defines the syntax and semantics of the message exchange. Licensing and Support ----------------------- RoadRunner is distributed under an open source license similar to that of Berkeley DB, permitting unrestricted use of the software at no charge for development of open source applications. This requires the complete source code for your application being available and freely distributable. The terms and details of the license are available at: http://rr.codefactory.se/license.php If you do not wish to freely distribute the source code for your application, or desire commercial support, please visit the CodeFactory website at http://www.codefactory.se/ or email info@codefactory.se. Mailing Lists --------------- There are currently two public mailing lists supporting RoadRunner, one for general discussion and one for tracking CVS commits. More information and subscription is available at: http://rr.codefactory.se/mailinglist.php More information about BEEP and RoadRunner -------------------------------------------- Documentation, source code, sample code, bug repository and more can be found at the RoadRunner project site: http://rr.codefactory.se/ About CodeFactory ------------------- CodeFactory provides development and consulting services enabling organizations to develop, use and learn about open source software and UNIX-like operating systems. CodeFactory is based in Umeå, Sweden. For more information please contact Daniel Lundin at +46 90 718 614 or visit http://www.codefactory.se/ Finally, acknowledgements to Marshall Rose and the rest of the BEEP community for bringing the BEEP protocol to the world. We hope the software will be useful, The RoadRunner team. -- Jonas Borgström jonas@codefactory.se CodeFactory AB http://www.codefactory.se/ Office: +46 (0)90 71 86 10 Cell: +46 (0)70 248 89 58 _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Aug 20 13:35:27 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 NAA19972 for ; Tue, 20 Aug 2002 13:35:26 -0400 (EDT) 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 g7KHU4V10516; Tue, 20 Aug 2002 10:30:04 -0700 (PDT) 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 g7KHTtV10494 for ; Tue, 20 Aug 2002 10:29:56 -0700 (PDT) Received: (qmail 37890 invoked by uid 3039); 20 Aug 2002 17:36:05 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Aug 2002 17:36:05 -0000 From: Gabe Wachob X-Sender: To: Jonas =?iso-8859-1?q?Borgstr=F6m?= cc: Subject: Re: [BEEPwg] ANNOUNCE: roadrunner-0.9 In-Reply-To: <87sn19d9mf.fsf@bengburken.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by qawoor.dbc.mtview.ca.us id g7KHTtV10494 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, 20 Aug 2002 10:36:02 -0700 (PDT) Content-Transfer-Encoding: 8bit Are you guys thinking about coordinating with Huston (or other beepcore folks) and Jered (or other permabeep folks) about getting some organized interoperability testing going? Sounds like we have enough implementations to make it worthwhile at this point. I think the SOAPBuilders have been very successful with interop testing - I would imagine that BEEP implementations would be easier to test for interop... As a starter, it might be useful to construct test cases that everyone agrees are "correct". Not sure how these would be expressed. Would there be interest in starting a beepbuilders list a la soapbuilders? -Gabe On 20 Aug 2002, Jonas Borgström wrote: > ---------------------------------------------------------------------------- > -- RoadRunner 0.9 (An Egg) ------------------------------------------------- > > 20 Aug, 2002 > > CodeFactory proudly announces the availability of a new release of > RoadRunner, an open source BEEP framework implemented in C. > > > Introduction > -------------- > RoadRunner is an application toolkit library implementing BEEP (Blocks > Extensible Exchange Protocol). Apart from implementing a powerful and > flexible BEEP framework, RoadRunner also contains a useful set of profiles, > readily available and usable with applications. > > RoadRunner provides a portable and powerful high-performance framework for > developing network applications making use of the BEEP protocol. > > > Changes since version 0.8 > --------------------------- > > * Simplified API. For more info see the API_CHANGES file. > * Stability improvements. > * New functions. > * Improved portability. > * Support for AIX added. > > > Supported Platforms > --------------------- > RoadRunner is primarily developed and regularly tested on GNU/Linux, > NetBSD and OpenBSD, but has been compiled and tested on: > > * GNU/Linux > * NetBSD > * OpenBSD > * FreeBSD > * Solaris > * MS Windows > * AIX > > RoadRunner is written in portable C code, and should work without modification > on all platforms supported by GLib 2 (GNU Utility library). > > > Language Bindings > ------------------- > The portable design of RoadRunner and the fact that it is written in C enables > simple creation of bindings for various languages. > Experimental python bindings already exists (in the pyrr cvs module) and other > bindings such as C++, Java, perl and scheme are planned. > > > Strengths and Features > ------------------------ > * Portable > * Object oriented design > * High performance > * Multi-threaded > * Open Source > > > Implemented BEEP Profiles > --------------------------- > RR/TLS -- Transport layer security > RR/SASL -- Simple Authentication and Security Layer > RR/Syslog -- Reliable delivery for syslog > RR/IDXP -- Intrusion detection exchange protocol > > > System Requirements > --------------------- > RoadRunner requires the following libraries to compile: > > * Glib 2.0.1 or higher (http://www.gtk.org/) > * libxml 2.4.16 or higher (http://www.libxml.org/) > > The RoadRunner profiles require some extra libraries: > > * OpenSSL (Used by RR/TLS. http://www.openssl.org/) > * Cyrus libsasl2 (Used by RR/SASL. http://asg.web.cmu.edu/sasl/) > > > What is BEEP > -------------- > BEEP (the Block Extensible Exchange Protocol, rfc3080,3081) is a protocol > framework for connection oriented asynchronous message exchange. All message > exchange occur in the context of a channel. A profile defines the syntax > and semantics of the message exchange. > > > Licensing and Support > ----------------------- > RoadRunner is distributed under an open source license similar to that of > Berkeley DB, permitting unrestricted use of the software at no charge for > development of open source applications. This requires the complete source > code for your application being available and freely distributable. > > The terms and details of the license are available at: > http://rr.codefactory.se/license.php > > If you do not wish to freely distribute the source code for your application, > or desire commercial support, please visit the CodeFactory website at > http://www.codefactory.se/ or email info@codefactory.se. > > > Mailing Lists > --------------- > There are currently two public mailing lists supporting RoadRunner, one > for general discussion and one for tracking CVS commits. > > More information and subscription is available at: > > http://rr.codefactory.se/mailinglist.php > > > More information about BEEP and RoadRunner > -------------------------------------------- > Documentation, source code, sample code, bug repository and more can be found > at the RoadRunner project site: > > http://rr.codefactory.se/ > > > About CodeFactory > ------------------- > CodeFactory provides development and consulting services enabling > organizations to develop, use and learn about open source software and > UNIX-like operating systems. > > CodeFactory is based in Umeå, Sweden. For more information please contact > Daniel Lundin at +46 90 718 614 or visit http://www.codefactory.se/ > > > > > Finally, acknowledgements to Marshall Rose and the rest of the BEEP community > for bringing the BEEP protocol to the world. > > We hope the software will be useful, > > The RoadRunner team. > > -- Gabe Wachob gwachob@wachob.com Personal http://www.wachob.com Founder, 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 Tue Aug 20 13:44: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 NAA20245 for ; Tue, 20 Aug 2002 13:44:16 -0400 (EDT) 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 g7KHc2V10600; Tue, 20 Aug 2002 10:38:02 -0700 (PDT) Received: from mpc_3.www.medicalpriority.com (42dbcb11.dsl.aros.net [66.219.203.17]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7KHbYV10581 for ; Tue, 20 Aug 2002 10:37:34 -0700 (PDT) Received: by mpc_3.www.medicalpriority.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Aug 2002 11:49:02 -0600 Message-ID: <26CB1E0213E7D3119E820050DAB61AE6CBD9CD@mpc_3.www.medicalpriority.com> From: Harley Pebley To: beepwg@lists.beepcore.org Subject: RE: [BEEPwg] ANNOUNCE: roadrunner-0.9 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" 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, 20 Aug 2002 11:48:57 -0600 > Are you guys thinking about coordinating with Huston (or > other beepcore folks) and Jered (or other permabeep folks) > about getting some organized interoperability testing going? I was wondering the same thing. > As a starter, it might be useful to construct test cases that everyone > agrees are "correct". Not sure how these would be expressed. > > Would there be interest in starting a beepbuilders list a la > soapbuilders? Once I get back to coding my implementation, I will have an interest in this. Regards, Harley Pebley _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Aug 20 13:48:10 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 NAA20359 for ; Tue, 20 Aug 2002 13:48:10 -0400 (EDT) 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 g7KHh2V10668; Tue, 20 Aug 2002 10:43:02 -0700 (PDT) Received: from monsoon.us.ny.firstrain.com ([208.198.42.246]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7KHgDV10651 for ; Tue, 20 Aug 2002 10:42:13 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: [BEEPwg] ANNOUNCE: roadrunner-0.9 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: Thread-Topic: [BEEPwg] ANNOUNCE: roadrunner-0.9 Thread-Index: AcJIcTN7F0Fh6zmXT4qGx7Q2kawh0wAACW/w From: "Bob Wyman" To: "Gabe Wachob" , =?iso-8859-1?Q?Jonas_Borgstr=F6m?= Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by qawoor.dbc.mtview.ca.us id g7KHgDV10651 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, 20 Aug 2002 13:48:51 -0400 Content-Transfer-Encoding: 8bit Gabe Wachob wrote: > Would there be interest in starting a > beepbuilders list a la soapbuilders? A beepbuilders list would be a very good thing to do, particularly if interoperability is a major focus of the discussion. bob wyman _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Aug 20 14:28:03 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 OAA21295 for ; Tue, 20 Aug 2002 14:28:02 -0400 (EDT) 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 g7KIN4V10996; Tue, 20 Aug 2002 11:23:04 -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.3/8.11.5) with ESMTP id g7KIMsV10984 for ; Tue, 20 Aug 2002 11:22:54 -0700 (PDT) Received: from dev0196 ([65.125.189.73]) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g7KIQYs18210; Tue, 20 Aug 2002 11:26:34 -0700 (PDT) Message-ID: <016301c24877$ae417a30$6500000a@dev0196> From: "Marshall Rose" To: "Bob Wyman" , "Gabe Wachob" , =?iso-8859-1?Q?Jonas_Borgstr=F6m?= Cc: References: Subject: Re: [BEEPwg] ANNOUNCE: roadrunner-0.9 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 20 Aug 2002 11:30:37 -0700 Content-Transfer-Encoding: 7bit > A beepbuilders list would be a very good thing to do, particularly if interoperability is a major focus of the discussion. it's easy enough to setup a new mailing list. before i (or someone else) does so? is there general agreement on splitting off interoperability issues to a new list? pete? /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Aug 20 14:48:10 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 OAA21950 for ; Tue, 20 Aug 2002 14:48:10 -0400 (EDT) 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 g7KIh4V11168; Tue, 20 Aug 2002 11:43:04 -0700 (PDT) Received: from mail.bengburken.net (postfix@flintv156.sn.umu.se [130.239.145.210]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7KIgQV11156 for ; Tue, 20 Aug 2002 11:42:26 -0700 (PDT) Received: from localhost (blinky.bengburken.net [192.168.100.2]) by mail.bengburken.net (Postfix) with ESMTP id B7BAA30826A; Tue, 20 Aug 2002 20:47:45 +0200 (CEST) Received: by localhost (Postfix, from userid 1000) id 31E4212669D; Tue, 20 Aug 2002 20:48:00 +0200 (CEST) To: "Marshall Rose" Cc: "Bob Wyman" , "Gabe Wachob" , Subject: Re: [BEEPwg] ANNOUNCE: roadrunner-0.9 References: <016301c24877$ae417a30$6500000a@dev0196> From: jonas@codefactory.se (Jonas =?iso-8859-1?q?Borgstr=F6m?=) In-Reply-To: <016301c24877$ae417a30$6500000a@dev0196> Message-ID: <87k7mle59c.fsf@bengburken.net> Lines: 20 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=latin-iso8859-1 Content-Transfer-Encoding: 8bit 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: 20 Aug 2002 20:47:59 +0200 Content-Transfer-Encoding: 8bit "Marshall Rose" writes: > > A beepbuilders list would be a very good thing to do, particularly if > interoperability is a major focus of the discussion. > > it's easy enough to setup a new mailing list. > > before i (or someone else) does so? > > is there general agreement on splitting off interoperability issues to a new > list? > Yes, that sounds like a good idea. / Jonas -- Jonas Borgström jonas@codefactory.se CodeFactory AB http://www.codefactory.se/ Office: +46 (0)90 71 86 10 Cell: +46 (0)70 248 89 58 _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Aug 20 15:03: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 PAA22377 for ; Tue, 20 Aug 2002 15:02:59 -0400 (EDT) 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 g7KIw2V11293; Tue, 20 Aug 2002 11:58:02 -0700 (PDT) Received: from wetware.wetware.com (wetware.wetware.com [199.108.16.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7KIvFV11281 for ; Tue, 20 Aug 2002 11:57:16 -0700 (PDT) Received: from kallisti.local.(ra07.wetware.com[199.108.16.87]) (890 bytes) by wetware.wetware.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Tue, 20 Aug 2002 12:03:26 -0700 (PDT) (Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Aug-4) Subject: Re: [BEEPwg] ANNOUNCE: roadrunner-0.9 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: james woodyatt To: BEEP WG In-Reply-To: <87k7mle59c.fsf@bengburken.net> Message-Id: <817B067A-B46F-11D6-8840-000502DB38F5@wetware.com> X-Mailer: Apple Mail (2.543) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by qawoor.dbc.mtview.ca.us id g7KIvFV11281 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, 20 Aug 2002 12:03:26 -0700 Content-Transfer-Encoding: 8bit On Tuesday, Aug 20, 2002, at 11:47 US/Pacific, Jonas Borgström wrote: > "Marshall Rose" writes: >> >> is there general agreement on splitting off interoperability issues >> to a new list? > > Yes, that sounds like a good idea. I concur. --james _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Aug 20 15:18: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 PAA22650 for ; Tue, 20 Aug 2002 15:18:52 -0400 (EDT) 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 g7KJD3V11472; Tue, 20 Aug 2002 12:13:03 -0700 (PDT) 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 g7KJCNV11460 for ; Tue, 20 Aug 2002 12:12:23 -0700 (PDT) Received: (qmail 53172 invoked by uid 3039); 20 Aug 2002 19:18:38 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Aug 2002 19:18:38 -0000 From: Gabe Wachob X-Sender: To: Marshall Rose cc: Bob Wyman , =?iso-8859-1?Q?Jonas_Borgstr=F6m?= , Subject: Re: [BEEPwg] ANNOUNCE: roadrunner-0.9 In-Reply-To: <016301c24877$ae417a30$6500000a@dev0196> 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: Tue, 20 Aug 2002 12:18:38 -0700 (PDT) As initiator of the idea, I think we have sufficient buyin. Marshall, could you please create a beepbuilders@beepcore.org list? THX -Gabe On Tue, 20 Aug 2002, Marshall Rose wrote: > > A beepbuilders list would be a very good thing to do, particularly if > interoperability is a major focus of the discussion. > > it's easy enough to setup a new mailing list. > > before i (or someone else) does so? > > is there general agreement on splitting off interoperability issues to a new > list? > > pete? > > /mtr > > > _______________________________________________ > BEEPwg mailing list > BEEPwg@lists.beepcore.org > http://lists.beepcore.org/mailman/listinfo/beepwg > -- Gabe Wachob gwachob@wachob.com Personal http://www.wachob.com Founder, 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 Tue Aug 20 15:21: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 PAA22706 for ; Tue, 20 Aug 2002 15:20:59 -0400 (EDT) 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 g7KJG2V11561; Tue, 20 Aug 2002 12:16:02 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7KJF3V11544 for ; Tue, 20 Aug 2002 12:15:03 -0700 (PDT) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 17hEXu-0007ph-00 for ; Tue, 20 Aug 2002 21:20:06 +0200 To: beepwg@lists.beepcore.org X-Injected-Via-Gmane: http://gmane.org/ Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 17hERK-0007S7-00 for ; Tue, 20 Aug 2002 21:13:18 +0200 Path: not-for-mail From: Daniel Lundin Newsgroups: gmane.ietf.beep Organization: CodeFactory AB Lines: 24 Message-ID: <87d6sduyui.fsf@tod.codefactory.se> References: <87sn19d9mf.fsf@bengburken.net> NNTP-Posting-Host: h21232164028.kommunicera.umea.se Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1029870798 27411 212.32.164.28 (20 Aug 2002 19:13:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 20 Aug 2002 19:13:18 +0000 (UTC) X-Face: $z6G{rTuG?OLsBU;ehk7{uPNqBQ@U#i<)czx)J}TUbz+Z`FR3adwU5p[t<1o1:?oLC5vl`i(9vI|r=6p9dh5CT(zvj1Mo/.r"@S+3CBBoy.cw]Zr'&-S<.-KBv5yLn.@wSun6D"(jZ1S@PWq1-#2dDZc\MS,GB{s`Bu6sN User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Subject: [BEEPwg] Re: ANNOUNCE: roadrunner-0.9 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: 20 Aug 2002 21:14:29 +0200 Gabe Wachob writes: > Are you guys thinking about coordinating with Huston (or other beepcore > folks) and Jered (or other permabeep folks) about getting some organized > interoperability testing going? Thought about it, yes, spoken about it, no. It is an excellent idea IMHO though. > As a starter, it might be useful to construct test cases that everyone > agrees are "correct". Not sure how these would be expressed. Yes, that should be simple enough. A series of pre-cooked messages and might be a humble, yet useful start. > Would there be interest in starting a beepbuilders list a la soapbuilders? Absolutely. /D -- Daniel Lundin | daniel@codefactory.se CodeFactory AB | http://www.codefactory.se/ _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Aug 20 15:21:03 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 PAA22721 for ; Tue, 20 Aug 2002 15:21:02 -0400 (EDT) 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 g7KJG5V11577; Tue, 20 Aug 2002 12:16:05 -0700 (PDT) Received: from mail10.atl.registeredsite.com (nobody@mail10.atl.registeredsite.com [64.224.219.84]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7KJFXV11549 for ; Tue, 20 Aug 2002 12:15:33 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail10.atl.registeredsite.com (8.12.2/8.12.5) with ESMTP id g7KJLlbZ018491 for ; Tue, 20 Aug 2002 15:21:48 -0400 Received: from central [64.225.30.241] by mail.clipcode.com with ESMTP (SMTPD32-6.06) id A719359C0112; Tue, 20 Aug 2002 15:23:05 -0400 From: "Eamon O'Tuathail" To: Message-ID: <000201c2487e$d0446e60$1e3b869f@central> 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.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [BEEPwg] interoperability list 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, 20 Aug 2002 20:21:39 +0100 Content-Transfer-Encoding: 7bit >> is there general agreement on splitting off interoperability >> issues to a new list? Considering there is not too much traffic on the "normal" beep mailing list, would it not be better to keep the interop discussion right here, and have just one beep mailing list. Eamon _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Tue Aug 20 16:11:04 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 QAA24746 for ; Tue, 20 Aug 2002 16:11:04 -0400 (EDT) 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 g7KK64V11939; Tue, 20 Aug 2002 13:06:04 -0700 (PDT) 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 g7KK52V11927 for ; Tue, 20 Aug 2002 13:05:02 -0700 (PDT) Received: (qmail 59105 invoked by uid 3039); 20 Aug 2002 20:11:17 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Aug 2002 20:11:17 -0000 From: Gabe Wachob X-Sender: To: "Eamon O'Tuathail" cc: Subject: Re: [BEEPwg] interoperability list In-Reply-To: <000201c2487e$d0446e60$1e3b869f@central> 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: Tue, 20 Aug 2002 13:11:17 -0700 (PDT) I would rather see the beepwg list be the place that newcomers and users are attracted to (because its linked up at the IETF, for example) - and I wouldn't want to see a lot of (what I would expect to be) low level discussion discourage higher level discussions. Also, users don't really care about details of interoperability besides at a functional level, so I'd hate to force people off this list who are here *because* it is low volume. -Gabe On Tue, 20 Aug 2002, Eamon O'Tuathail wrote: > > >> is there general agreement on splitting off interoperability > >> issues to a new list? > > Considering there is not too much traffic on the "normal" beep mailing > list, would it not be better to keep the interop discussion right here, > and have just one beep mailing list. > > Eamon > > _______________________________________________ > BEEPwg mailing list > BEEPwg@lists.beepcore.org > http://lists.beepcore.org/mailman/listinfo/beepwg > -- Gabe Wachob gwachob@wachob.com Personal http://www.wachob.com Founder, 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 Tue Aug 20 20:11: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 UAA01013 for ; Tue, 20 Aug 2002 20:11:53 -0400 (EDT) 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 g7L063V13547; Tue, 20 Aug 2002 17:06:04 -0700 (PDT) Received: from episteme-software.com (champdsl-25-66.mcleodusa.net [216.43.25.66]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7L050V13534 for ; Tue, 20 Aug 2002 17:05:01 -0700 (PDT) Received: from [216.43.25.67] (216.43.25.67) by episteme-software.com with ESMTP (Eudora Internet Mail Server 3.1.3); Tue, 20 Aug 2002 19:11:08 -0500 Mime-Version: 1.0 X-Sender: resnick@resnick1.qualcomm.com Message-Id: In-Reply-To: <016301c24877$ae417a30$6500000a@dev0196> References: <016301c24877$ae417a30$6500000a@dev0196> X-Mailer: Eudora [Macintosh version 5.2a3] To: "Marshall Rose" From: Pete Resnick Subject: Re: [BEEPwg] ANNOUNCE: roadrunner-0.9 Cc: "Bob Wyman" , "Gabe Wachob" , Jonas =?iso-8859-1?Q?Borgstr=F6m?= , Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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, 20 Aug 2002 19:10:03 -0500 On 8/20/02 at 11:30 AM -0700, Marshall Rose wrote: >is there general agreement on splitting off interoperability issues >to a new list? > >pete? Just to throw in my 2p: The next thing to do with BEEP is to move it along to Draft Standard. For that, interoperability review is going to need to be done. It seems to me that having these discussions on this list will make that job a bit easier. I'm not going to jump up and down and complain if you really want a new list, but I don't see a particularly good reason to do so. pr -- Pete Resnick QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102 _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Aug 21 00:00:35 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 AAA05760 for ; Wed, 21 Aug 2002 00:00:34 -0400 (EDT) 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 g7L3t4V15254; Tue, 20 Aug 2002 20:55:04 -0700 (PDT) Received: from mail.franklin.ro ([166.70.87.233]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g7L3srV15235 for ; Tue, 20 Aug 2002 20:54:53 -0700 (PDT) Received: (qmail 17899 invoked from network); 21 Aug 2002 05:01:07 -0000 Received: from dhcp-12.franklin.ro (HELO boys) (10.0.1.12) by bob.franklin.ro with SMTP; 21 Aug 2002 05:01:07 -0000 Message-ID: <003b01c248c6$e69eb380$0c01000a@boys> From: "Huston" To: References: <016301c24877$ae417a30$6500000a@dev0196> Subject: Re: [BEEPwg] ANNOUNCE: roadrunner-0.9 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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, 20 Aug 2002 21:57:42 -0600 Content-Transfer-Encoding: 7bit > is there general agreement on splitting off interoperability issues to a new > list? sounds good to me. --Huston _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Aug 21 06:45:36 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 GAA05869 for ; Wed, 21 Aug 2002 06:45:36 -0400 (EDT) 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 g7LAeLV18063; Wed, 21 Aug 2002 03:40:21 -0700 (PDT) Received: from mail3.atl.registeredsite.com (nobody@mail3.atl.registeredsite.com [64.224.219.77]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7LAduV18041 for ; Wed, 21 Aug 2002 03:39:56 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail3.atl.registeredsite.com (8.12.2/8.12.5) with ESMTP id g7LAk82p011967; Wed, 21 Aug 2002 06:46:08 -0400 Received: from central [64.225.30.241] by mail.clipcode.com with ESMTP (SMTPD32-6.06) id AFBFEADD002E; Wed, 21 Aug 2002 06:47:27 -0400 From: "Eamon O'Tuathail" To: "'Gabe Wachob'" Cc: Subject: RE: [BEEPwg] interoperability list Message-ID: <000201c248ff$f21e7d60$5d3b869f@central> 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.2627 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 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, 21 Aug 2002 11:45:46 +0100 Content-Transfer-Encoding: 7bit Gabe, You point is reasonable - we should go with a separate interop list. Eamon -----Original Message----- From: Gabe Wachob [mailto:gwachob@wachob.com] Sent: 20 August 2002 21:11 To: Eamon O'Tuathail Cc: beepwg@lists.beepcore.org Subject: Re: [BEEPwg] interoperability list I would rather see the beepwg list be the place that newcomers and users are attracted to (because its linked up at the IETF, for example) - and I wouldn't want to see a lot of (what I would expect to be) low level discussion discourage higher level discussions. Also, users don't really care about details of interoperability besides at a functional level, so I'd hate to force people off this list who are here *because* it is low volume. -Gabe _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Wed Aug 21 12:42:38 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 MAA15814 for ; Wed, 21 Aug 2002 12:42:38 -0400 (EDT) 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 g7LGb8V20845; Wed, 21 Aug 2002 09:37:09 -0700 (PDT) Received: from kalia.dbc.mtview.ca.us (dhcpd253.dbc.mtview.ca.us [64.168.10.253]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7LGaIV20833 for ; Wed, 21 Aug 2002 09:36:18 -0700 (PDT) Received: from unknown (localhost [127.0.0.1]) by kalia.dbc.mtview.ca.us (8.11.6+3.4W/8.11.6) with SMTP id g7LGgSK01832; Wed, 21 Aug 2002 09:42:28 -0700 (PDT) From: Marshall Rose To: beepwg@lists.beepcore.org Cc: eamon.otuathail@clipcode.com, beepwg@lists.beepcore.org Subject: Re: [BEEPwg] interoperability list Message-Id: <20020821094228.7596ff8b.mrose@dbc.mtview.ca.us> In-Reply-To: <000201c248ff$f21e7d60$5d3b869f@central> References: <000201c248ff$f21e7d60$5d3b869f@central> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.8.0claws (GTK+ 1.2.10; ) 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: Wed, 21 Aug 2002 09:42:28 -0700 Content-Transfer-Encoding: 7bit > You point is reasonable - we should go with a separate interop list. http://lists.beepcore.org/mailman/listinfo/beepbuilders /mtr _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Aug 22 12:20:52 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 MAA01403 for ; Thu, 22 Aug 2002 12:20:52 -0400 (EDT) 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 g7MG3DV01835; Thu, 22 Aug 2002 09:03:18 -0700 (PDT) Received: from mail3.atl.registeredsite.com (nobody@mail3.atl.registeredsite.com [64.224.219.77]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7MG28V01819 for ; Thu, 22 Aug 2002 09:02:08 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail3.atl.registeredsite.com (8.12.2/8.12.5) with ESMTP id g7MG8YWK006558 for ; Thu, 22 Aug 2002 12:08:35 -0400 Received: from central [64.225.30.241] by mail.clipcode.com with ESMTP (SMTPD32-6.06) id ACD1CC890130; Thu, 22 Aug 2002 12:09:53 -0400 From: "Eamon O'Tuathail" To: Message-ID: <000801c249f6$255c65b0$373b869f@central> 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.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal Subject: [BEEPwg] Callback Profile 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, 22 Aug 2002 17:08:23 +0100 Content-Transfer-Encoding: 7bit Is there a need for a callback profile, where an initiator peer asks the listener peer to initiate a new session between the same two peers. (i.e. peer A wishes peer B to initiate a session to peer A, but peer A needs to tell peer B to do this - hence the callback profile). The motivation would be firstly to enhance security in certain environments (a highly secure peer may only permit incoming connections to request a callback, but expose no other functionality [apart from the tuning profiles] to them), and secondly to work in environments when there are business/technical restrictions on the number and direction of open connections. A peer running on Windows XP Home can only maintain five simultaneous incoming connections, and a peer running on Windows XP Professional can only have 10 simultaneous incoming connections. [see http://support.microsoft.com/default.aspx?scid=kb;en-us;Q314882] There are no restrictions on Windows 2000 Server or Windows .NET Server on the number of incoming connections. For all the versions of Windows mentioned, there are no restrictions on the number of outgoing connections. One expensive option is to set up a traditional Windows client-server network, which usually involves Windows Domains. This requires you to buy Windows XP Professional for machines that only act as client (XP Home will not suffice for Windows Domains), buy the Windows Server product for machines that might have more than 10 incoming connections, and buy a "Client Access License" for each client to permit it to access a server. (you Linux guys can stop laughing now). A much better option is to just put Windows XP Home on all the machines, and using the callback profile arrange them as required - maybe point to point, or maybe hub-and-spoke [if one peer exposes a service that many other wish to use]. How would a callback profile work? ================================== 1) A peer [we call it the provider peer] that provides a popular service or a high-security service based on BEEP would list the Callback Profile in its Greeting message. Depending on local configuration this could be the initial greeting message, or the one after the tuning reset following TLS setup; also authentication may be required. 2) A peer wishing to use the remote service [the user peer] would establish a connection to the provider peer, configure security as appropriate, and upon detecting the Callback Profile in the Greeting message, would create a channel based on this profile. 3) The user peer sends a single message on the callback channel to the provider peer identifying the transport mapping details to use for the callback - e.g. transport mapping type [RFC 3081, SCTP, multiple TCP connections] and addressing [for RFC 3081, IP address and port to use]. 4) The existing session is shut down. 5) The provider peer initiates a session with the user peer based on the addressing information provided. After that, it works just as normal. My questions: ============= Anyone see any problems with this approach? Anyone got a better solution? Anyone got a good reference to security issues that have been uncovered with other types of callback usage - e.g. ftp. An alternative to the callback profile in BEEP would be a simple UDP message, but I would have security concerns about that. Eamon _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Aug 22 12:56:24 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 MAA02485 for ; Thu, 22 Aug 2002 12:56:20 -0400 (EDT) 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 g7MGd8V02131; Thu, 22 Aug 2002 09:39:08 -0700 (PDT) Received: from rtp-msg-core-1.cisco.com (rtp-msg-core-1.cisco.com [161.44.11.97]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7MGcYV02113 for ; Thu, 22 Aug 2002 09:38:35 -0700 (PDT) Received: from spamsicle.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g7MGiwl9016471; Thu, 22 Aug 2002 12:44:59 -0400 (EDT) Received: from PAANDREWW2K3 (che-vpn1-38.cisco.com [10.86.240.38]) by spamsicle.cisco.com (Mirapoint) with SMTP id AAJ21300; Thu, 22 Aug 2002 12:44:51 -0400 (EDT) From: "Paul Andrews" To: "Eamon O'Tuathail" , Subject: RE: [BEEPwg] Callback Profile Message-ID: 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 IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <000801c249f6$255c65b0$373b869f@central> 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, 22 Aug 2002 12:44:48 -0400 Content-Transfer-Encoding: 7bit My reading of the Microsoft note is that this only applies to Microsoft network services, not to arbitrary TCP connections. i.e. a single XP Home machine can support 5 other remote machines where each remote machine can perform any number of remote disk mounts, printer shares etc. Have you tried just opening lots of BEEP connections to a peer running on an XP machine? To address one issue more directly: Opening a separate connection for callbacks won't work if you're going through a NATing router (like the little Linksys router I'm using at home at the moment). > -----Original Message----- > From: beepwg-admin@lists.beepcore.org > [mailto:beepwg-admin@lists.beepcore.org]On Behalf Of Eamon O'Tuathail > Sent: Thursday, August 22, 2002 12:08 PM > To: beepwg@lists.beepcore.org > Subject: [BEEPwg] Callback Profile > > > > Is there a need for a callback profile, where an initiator peer asks the > listener peer to initiate a new session between the same two peers. > (i.e. peer A wishes peer B to initiate a session to peer A, but peer A > needs to tell peer B to do this - hence the callback profile). > > The motivation would be firstly to enhance security in certain > environments (a highly secure peer may only permit incoming connections > to request a callback, but expose no other functionality [apart from the > tuning profiles] to them), and secondly to work in environments when > there are business/technical restrictions on the number and direction of > open connections. > > A peer running on Windows XP Home can only maintain five simultaneous > incoming connections, and a peer running on Windows XP Professional can > only have 10 simultaneous incoming connections. > [see http://support.microsoft.com/default.aspx?scid=kb;en-us;Q314882] > There are no restrictions on Windows 2000 Server or Windows .NET Server > on the number of incoming connections. For all the versions of Windows > mentioned, there are no restrictions on the number of outgoing > connections. > > One expensive option is to set up a traditional Windows client-server > network, which usually involves Windows Domains. This requires you to > buy > Windows XP Professional for machines that only act as client (XP Home > will not suffice for Windows Domains), buy the Windows Server product > for machines that might have more than 10 incoming connections, and buy > a "Client Access License" for each client to permit it to access a > server. (you Linux guys can stop laughing now). > > A much better option is to just put Windows XP Home on all the machines, > and using the callback profile arrange them as required - maybe point to > point, or maybe hub-and-spoke [if one peer exposes a service that many > other wish to use]. > > How would a callback profile work? > ================================== > 1) A peer [we call it the provider peer] that provides a popular service > or a high-security service based on BEEP would list the Callback Profile > in its Greeting message. Depending on local configuration this could be > the initial greeting message, or the one after the tuning reset > following TLS setup; also authentication may be required. > > 2) A peer wishing to use the remote service [the user peer] would > establish a connection to the provider peer, configure security as > appropriate, and upon detecting the Callback Profile in the Greeting > message, would create a channel based on this profile. > > 3) The user peer sends a single message on the callback channel to the > provider peer identifying the transport mapping details to use for the > callback - e.g. transport mapping type [RFC 3081, SCTP, multiple TCP > connections] and addressing [for RFC 3081, IP address and port to use]. > > 4) The existing session is shut down. > > 5) The provider peer initiates a session with the user peer based on the > addressing information provided. After that, it works just as normal. > > My questions: > ============= > > Anyone see any problems with this approach? > > Anyone got a better solution? > > Anyone got a good reference to security issues that have been uncovered > with other types of callback usage - e.g. ftp. > > An alternative to the callback profile in BEEP would be a simple UDP > message, but I would have security concerns about that. > > Eamon > > _______________________________________________ > 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 Aug 22 13:08:10 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 NAA02873 for ; Thu, 22 Aug 2002 13:08:09 -0400 (EDT) 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 g7MGo3V02256; Thu, 22 Aug 2002 09:50:03 -0700 (PDT) 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 g7MGnQV02232 for ; Thu, 22 Aug 2002 09:49:26 -0700 (PDT) Received: (qmail 81778 invoked by uid 3039); 22 Aug 2002 16:55:53 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Aug 2002 16:55:53 -0000 From: Gabe Wachob X-Sender: To: "Eamon O'Tuathail" cc: Subject: Re: [BEEPwg] Callback Profile In-Reply-To: <000801c249f6$255c65b0$373b869f@central> 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, 22 Aug 2002 09:55:53 -0700 (PDT) On Thu, 22 Aug 2002, Eamon O'Tuathail wrote: > A peer running on Windows XP Home can only maintain five simultaneous > incoming connections, and a peer running on Windows XP Professional can > only have 10 simultaneous incoming connections. > [see http://support.microsoft.com/default.aspx?scid=kb;en-us;Q314882] > There are no restrictions on Windows 2000 Server or Windows .NET Server > on the number of incoming connections. For all the versions of Windows > mentioned, there are no restrictions on the number of outgoing > connections. I think those numbers apply to netbios connections, not TCP connections. While not personally testing this, I'm told that people routinely drop servers on XP Pro and have > 100 simultaneous incoming TCP connections. If this is true (and I do believe it is), this support bulletin is extremely poorly written. Are you seeing this limit behavior in practice? -Gabe -- Gabe Wachob gwachob@wachob.com Personal http://www.wachob.com Founder, 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 Aug 22 14:04:21 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 OAA04792 for ; Thu, 22 Aug 2002 14:04:20 -0400 (EDT) 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 g7MHx4V02805; Thu, 22 Aug 2002 10:59:04 -0700 (PDT) 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 g7MHwrV02793 for ; Thu, 22 Aug 2002 10:58:53 -0700 (PDT) Received: (qmail 90350 invoked by uid 3039); 22 Aug 2002 18:05:20 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 22 Aug 2002 18:05:20 -0000 From: Gabe Wachob X-Sender: To: Paul Andrews cc: "Eamon O'Tuathail" , Subject: RE: [BEEPwg] Callback Profile In-Reply-To: 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, 22 Aug 2002 11:05:20 -0700 (PDT) I think there would be a lot of use for/interest in a rendezvous profile. There is the tunnel profile but I don't think it address the "dual NAT" problem (ie two parties, each behind NATs, trying to make connections). This is an issue that goes beyond BEEP, of course. -Gabe On Thu, 22 Aug 2002, Paul Andrews wrote: > To address one issue more directly: Opening a separate connection for > callbacks won't work if you're going through a NATing router (like the > little Linksys router I'm using at home at the moment). -- Gabe Wachob gwachob@wachob.com Personal http://www.wachob.com Founder, 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 Aug 22 14:17: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 OAA05286 for ; Thu, 22 Aug 2002 14:17:16 -0400 (EDT) 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 g7MIC6V02951; Thu, 22 Aug 2002 11:12:06 -0700 (PDT) Received: from monsoon.us.ny.firstrain.com ([208.198.42.246]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7MIB5V02934 for ; Thu, 22 Aug 2002 11:11:05 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: [BEEPwg] Callback Profile MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Message-ID: Thread-Topic: [BEEPwg] Callback Profile Thread-Index: AcJJ9txrZ0cSn0X1TOif3N5Sd7CBXAAD8Gkg From: "Bob Wyman" To: "Eamon O'Tuathail" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by qawoor.dbc.mtview.ca.us id g7MIB5V02934 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, 22 Aug 2002 14:17:57 -0400 Content-Transfer-Encoding: 8bit > 3) The user peer sends a single message on the > callback channel to the provider peer identifying > the transport mapping details to use for the callback If a callback mechanism is defined, it would be useful if the callback initiator was able to also pass a token (call it a "calling card") that was to be returned as part of the callback. Data in the calling card would be used to facilitate the process of doing rendezvous with the specific application session that had requested the callback. The data in the calling card could also be used to augment the security of the connection. An application for callback that might be a bit more uplifting than avoiding license restrictions would be load balancing. This might have application in solving the problem of having multiple Apex relays in a single administrative domain. i.e. someone wishing to connect to an array of relays would do so via a callback request to a load balancing server. The load balancing server would then request that the best available relay establish a connection with the endpoint. (This would address some of the issues that led me to suggest a Beep and/or Apex "redirection" option in the past.) bob wyman _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Aug 22 18:18: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 SAA12248 for ; Thu, 22 Aug 2002 18:18:37 -0400 (EDT) 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 g7MMD4V04638; Thu, 22 Aug 2002 15:13:04 -0700 (PDT) Received: from wetware.wetware.com (wetware.wetware.com [199.108.16.1]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7MMC7V04626 for ; Thu, 22 Aug 2002 15:12:07 -0700 (PDT) Received: from kallisti.local.(ra02.wetware.com[199.108.16.82]) (2504 bytes) by wetware.wetware.com via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Thu, 22 Aug 2002 15:18:31 -0700 (PDT) (Smail-3.2.0.114 2001-Aug-6 #1 built 2002-Aug-4) Subject: Re: [BEEPwg] Callback/Rendezvous Profiles Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: james woodyatt To: BEEP WG Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <18D8B3F7-B61D-11D6-88FC-000502DB38F5@wetware.com> X-Mailer: Apple Mail (2.543) 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, 22 Aug 2002 15:18:34 -0700 Content-Transfer-Encoding: 7bit On Thursday, Aug 22, 2002, at 11:05 US/Pacific, Gabe Wachob wrote: > > I think there would be a lot of use for/interest in a rendezvous > profile. > There is the tunnel profile but I don't think it address the "dual NAT" > problem (ie two parties, each behind NATs, trying to make connections). > > This is an issue that goes beyond BEEP, of course. I think both the Callback profile and the Rendezvous profile are actively BAD ideas. I say this as a guy whose day job is maintaining the firmware in a NAT routing home Internet gateway appliance device. I think that there are already plenty of good security mechanisms defined in the BEEP core; there is no additional security benefit to be had by employing a Callback profile. If you don't believe me, then I recommend taking the idea immediately to your nearest friendly neighborhood Security Area specialist, and see how far you can go with it. Consider this: the listener doesn't have to offer any profiles in its greeting message to initiators. It can instead expect the initiator to offer the first tuning profile in its greeting. Also, you should see draft-iab-unsaf-considerations-02.txt for a good description of the set of problems in this Rendezvous profile you are suggesting. (I contributed section C.2 of that document.) I've only seen one protocol for unilaterally fixing the public addresses of multiple peers in different private address realms that didn't make me want to wretch violently. The latest version of it is described in draft-ietf-ngtrans-shipworm-07.txt, and it's used for establishing IPv6 connectivity by tunneling over UDP/IPv4. The reason I make an exception for it is that it is clearly intended to let IPv6 treat IPv4/NAT like the damage it is and route around it. Please please please do not try to advance either of these ideas a Internet standards. --james _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg From beepwg-admin@lists.beepcore.org Thu Aug 22 19:50:29 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 TAA14068 for ; Thu, 22 Aug 2002 19:50:28 -0400 (EDT) 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 g7MNj4V05171; Thu, 22 Aug 2002 16:45:04 -0700 (PDT) Received: from myslo.com (qmailr@adsl-66-122-64-130.dsl.snlo01.pacbell.net [66.122.64.130]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with SMTP id g7MNiuV05152 for ; Thu, 22 Aug 2002 16:44:56 -0700 (PDT) Received: (qmail 1029 invoked from network); 22 Aug 2002 23:51:58 -0000 Received: from unknown (HELO localhost.localdomain) (kkress@10.0.0.12) by 10.0.0.1 with SMTP; 22 Aug 2002 23:51:58 -0000 Subject: Re: [BEEPwg] Callback/Rendezvous Profiles From: Kevin Kress To: james woodyatt Cc: BEEP WG In-Reply-To: <18D8B3F7-B61D-11D6-88FC-000502DB38F5@wetware.com> References: <18D8B3F7-B61D-11D6-88FC-000502DB38F5@wetware.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.8 Message-Id: <1030059288.1525.10.camel@quark> Mime-Version: 1.0 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: 22 Aug 2002 16:34:48 -0700 Content-Transfer-Encoding: 7bit From what I have read the Callback and Rendezvous profiles both could be created without even giving a thought to NAT. NAT breaks 99% of what the net is for anyway (he says through his NATed firewall). In general I try to ignore NAT in hopes that it will go away (ie IPv6 will be used). I think this is a case where ignoring NAT is the right thing to do, both profiles can exist above that layer and allow the protocol binding to handle all that nastiness. As for security, I think both profiles have uses outside the strict security realm. An example Gabe mentioned was using the Rendezvous Profile to allow anonymous connections. Someone else mentioned the callback being used for loadbalencing. just my 2c --Kevin On Thu, 2002-08-22 at 15:18, james woodyatt wrote: > On Thursday, Aug 22, 2002, at 11:05 US/Pacific, Gabe Wachob wrote: > > > > I think there would be a lot of use for/interest in a rendezvous > > profile. > > There is the tunnel profile but I don't think it address the "dual NAT" > > problem (ie two parties, each behind NATs, trying to make connections). > > > > This is an issue that goes beyond BEEP, of course. > > I think both the Callback profile and the Rendezvous profile are > actively BAD ideas. I say this as a guy whose day job is maintaining > the firmware in a NAT routing home Internet gateway appliance device. > > I think that there are already plenty of good security mechanisms > defined in the BEEP core; there is no additional security benefit to be > had by employing a Callback profile. If you don't believe me, then I > recommend taking the idea immediately to your nearest friendly > neighborhood Security Area specialist, and see how far you can go with > it. Consider this: the listener doesn't have to offer any profiles in > its greeting message to initiators. It can instead expect the > initiator to offer the first tuning profile in its greeting. > > Also, you should see draft-iab-unsaf-considerations-02.txt for a good > description of the set of problems in this Rendezvous profile you are > suggesting. (I contributed section C.2 of that document.) > > I've only seen one protocol for unilaterally fixing the public > addresses of multiple peers in different private address realms that > didn't make me want to wretch violently. The latest version of it is > described in draft-ietf-ngtrans-shipworm-07.txt, and it's used for > establishing IPv6 connectivity by tunneling over UDP/IPv4. The reason > I make an exception for it is that it is clearly intended to let IPv6 > treat IPv4/NAT like the damage it is and route around it. > > Please please please do not try to advance either of these ideas a > Internet standards. > > > --james > > _______________________________________________ > 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 Fri Aug 23 09:36:29 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 JAA06316 for ; Fri, 23 Aug 2002 09:36:29 -0400 (EDT) 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 g7NDUjV11064; Fri, 23 Aug 2002 06:30:46 -0700 (PDT) Received: from mail11.atl.registeredsite.com (nobody@mail11.atl.registeredsite.com [64.224.219.85]) by qawoor.dbc.mtview.ca.us (8.11.3/8.11.5) with ESMTP id g7NDT4V11042 for ; Fri, 23 Aug 2002 06:29:04 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail11.atl.registeredsite.com (8.12.2/8.12.5) with ESMTP id g7NDZaKQ018163 for ; Fri, 23 Aug 2002 09:35:36 -0400 Received: from central [64.225.30.241] by mail.clipcode.com with ESMTP (SMTPD32-6.06) id AA7A54DE0112; Fri, 23 Aug 2002 09:36:58 -0400 From: "Eamon O'Tuathail" To: Message-ID: <000001c24aa9$f30f9b90$7c3b869f@central> 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.2627 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [BEEPwg] Re: Callback Profile 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, 23 Aug 2002 14:35:28 +0100 Content-Transfer-Encoding: 7bit Gabe Wachob wrote: > I'm told that people routinely drop servers on XP Pro and have > 100 > simultaneous incoming TCP connections. If this is true (and I do > believe it is), this support bulletin is extremely poorly written. > Are you seeing this limit behavior in practice? No, not in practice, but only in theory! The official license text is in the EULA.TXT file under c:\windows\system32\, and the relevant portion is: "... You may permit a maximum of ten (10) computers or other electronic devices (each a "Device") to connect to the Workstation Computer to utilize the services of the Product solely for File and Print services, Internet Information Services, and remote access (including connection sharing and telephony services). The ten connection maximum includes any indirect connections made through "multiplexing" or other software or hardware which pools or aggregates connections." It is not clear to me exactly what they mean by that. Paul Andrews writes: > My reading of the Microsoft note is that this only applies to > Microsoft network services ... remote disk mounts, printer shares" Since one would assume MS would hard-code whatever licensing limits they have into the software, I suppose I concur with Paul's view, and so we can put the callback profile idea on the backburner. If sometime in the future MS change the licensing, we can revive the callback idea, so whatever changes they make will be irrelevant. NATs and BEEP is another day's work. Eamon _______________________________________________ BEEPwg mailing list BEEPwg@lists.beepcore.org http://lists.beepcore.org/mailman/listinfo/beepwg