From bxxpwg-admin@lists.invisibleworlds.com Mon Jul 2 12:49:00 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27090 for ; Mon, 2 Jul 2001 12:48:58 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA28148; Mon, 2 Jul 2001 09:47:54 -0700 (PDT) Received: from monsoon.us.ny.firstrain.com ([208.198.42.246]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA28133 for ; Mon, 2 Jul 2001 09:47:53 -0700 (PDT) content-class: urn:content-classes:message Subject: RE: [BXXPwg] Redirect Feature for BEEP (continued...) Date: Mon, 2 Jul 2001 12:49:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: [BXXPwg] Redirect Feature for BEEP (continued...) Thread-Index: AcEDFvOO9hHKy+EITAeQuz7yTHoANQ== From: "Bob Wyman" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by trystero.not.invisible.net id JAA28134 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 8bit Marshall Rose wrote: >could you give me an example or two as to > how this would be used in practice. Use cases: 1. A Beep server has become well-known as a provider of support for 10 profiles. Due to excessive load on the server, it is decided to redistribute support for the profiles between two machines. So, the redirect feature and a "permanently unavailable" error code would be used to inform users where to find support for profiles moved off the original server. 2. A number of Beep servers are sharing the task of supporting one or more profiles. However, from time to time, the load becomes unbalanced between the servers. In this case, heavily loaded servers could temporarily redirect new connections to machines that have more capacity. 3. A company has two Beep servers that each support the same profile, however, because of quality of service requirements one group of users is required to use one of the servers while a second group uses a different server. So, whenever someone attempts to connect to the wrong machine, they would be redirected to the machine that they belong on. The company could then post the address of only one Beep server and then let the permanent redirects sort people out as they arrive. 4. A Beep server needs to be brought down for maintenance. (i.e. software/hardware upgrade, database reorg, etc.) A secondary system is available to take load during the downtime. So, the server administrator would use a temporary redirect to redirect all new connections to the secondary system and after some reasonable period would terminate existing sessions. When the primary was restored, the process would be reversed. 5. A Beep server needs to be brought down for maintenance but there is no secondary or backup server to take the load. If it is simply software maintenance, the server administrator could replace the existing server with a "dummy" server that responded to all start requests by issuing a "temporarily unavailable" message and "availableAfter" some specific time. Clients should not attempt to access the server until after the time specified. 6. A Beep server is scheduled to be brought down for maintenance on Saturday at 2:00am and will be down for four hours. This is known two weeks in advance. So, the system administrator would cause his servers to publish "availableUntil" to indicate the intent to bring the service down and "availableAfter" to show when it should come back. Email messages saying "servers will be down on Saturday" would NOT be sent to the 10,000 employees of the company hosting the server... Hopefully, these examples will help in crossing the chasm. bob wyman _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jul 2 16:53:30 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04935 for ; Mon, 2 Jul 2001 16:53:28 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA29639; Mon, 2 Jul 2001 13:52:29 -0700 (PDT) Received: from mutley.ebuilt.net (nat.ebuilt.com [209.216.46.200]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA29619 for ; Mon, 2 Jul 2001 13:52:28 -0700 (PDT) Received: (from root@localhost) by mutley.ebuilt.net (8.11.1/8.11.1) id f62Kq0i24663 for ; Mon, 2 Jul 2001 13:52:00 -0700 Received: from waka.ebuilt.net (IDENT:root@i199.ir.ebuilt.net [10.1.2.199]) by mutley.ebuilt.net (8.11.1/8.11.1) with ESMTP id f62Kq0L24582; Mon, 2 Jul 2001 13:52:00 -0700 Received: (from fielding@localhost) by waka.ebuilt.net (8.11.0/8.11.0) id f62KnsV07338; Mon, 2 Jul 2001 13:49:54 -0700 Date: Mon, 2 Jul 2001 13:49:54 -0700 From: "Roy T. Fielding" To: Bob Wyman Cc: bxxpwg@invisible.net Subject: Re: [BXXPwg] Redirect Feature for BEEP (continued...) Message-ID: <20010702134954.A899@waka.ebuilt.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.13-current-20010115i In-Reply-To: ; from bobwyman@firstrain.com on Mon, Jul 02, 2001 at 12:49:25PM -0400 X-AntiVirus: scanned for viruses by AMaViS 0.2.1-pre3 (http://amavis.org/) Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net On Mon, Jul 02, 2001 at 12:49:25PM -0400, Bob Wyman wrote: > Marshall Rose wrote: > >could you give me an example or two as to > > how this would be used in practice. > > Use cases: > 1. A Beep server has become well-known as a provider of support for 10 > profiles. Due to excessive load on the server, it is decided to > redistribute support for the profiles between two machines. So, the > redirect feature and a "permanently unavailable" error code would be > used to inform users where to find support for profiles moved off the > original server. This is what IP load balancers are for -- waiting until the beep session has been established means it has already taken on the load. > 2. A number of Beep servers are sharing the task of supporting one or > more profiles. However, from time to time, the load becomes unbalanced > between the servers. In this case, heavily loaded servers could > temporarily redirect new connections to machines that have more > capacity. Again, load balancers do this. > 3. A company has two Beep servers that each support the same profile, > however, because of quality of service requirements one group of users > is required to use one of the servers while a second group uses a > different server. So, whenever someone attempts to connect to the wrong > machine, they would be redirected to the machine that they belong on. > The company could then post the address of only one Beep server and then > let the permanent redirects sort people out as they arrive. This is an application-level redirect -- it belongs in the profile protocol. > 4. A Beep server needs to be brought down for maintenance. (i.e. > software/hardware upgrade, database reorg, etc.) A secondary system is > available to take load during the downtime. So, the server administrator > would use a temporary redirect to redirect all new connections to the > secondary system and after some reasonable period would terminate > existing sessions. When the primary was restored, the process would be > reversed. Load balancer. > 5. A Beep server needs to be brought down for maintenance but there is > no secondary or backup server to take the load. If it is simply software > maintenance, the server administrator could replace the existing server > with a "dummy" server that responded to all start requests by issuing a > "temporarily unavailable" message and "availableAfter" some specific > time. Clients should not attempt to access the server until after the > time specified. A replacement application for the profile. > 6. A Beep server is scheduled to be brought down for maintenance on > Saturday at 2:00am and will be down for four hours. This is known two > weeks in advance. So, the system administrator would cause his servers > to publish "availableUntil" to indicate the intent to bring the service > down and "availableAfter" to show when it should come back. Email > messages saying "servers will be down on Saturday" would NOT be sent to > the 10,000 employees of the company hosting the server... Another application profile issue. > Hopefully, these examples will help in crossing the chasm. Load balancing needs to be handled before connections are accepted. Application redirects need to be handled after the profile is established (because there may be many different types of redirect, like in HTTP). That is why this kind of feature doesn't need to be in BEEP core. ....Roy _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jul 2 18:35:31 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08689 for ; Mon, 2 Jul 2001 18:35:30 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA00293; Mon, 2 Jul 2001 15:34:35 -0700 (PDT) Received: from monsoon.us.ny.firstrain.com ([208.198.42.246]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA00261 for ; Mon, 2 Jul 2001 15:34:33 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 content-class: urn:content-classes:message Subject: RE: [BXXPwg] Redirect Feature for BEEP (continued...) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Mon, 2 Jul 2001 18:36:32 -0400 Message-ID: Thread-Topic: [BXXPwg] Redirect Feature for BEEP (continued...) Thread-Index: AcEDOSWIiXQYs7gNSU+je1hzxuZXbQAAeifQ From: "Bob Wyman" To: "Roy T. Fielding" Cc: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by trystero.not.invisible.net id PAA00262 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 8bit Roy Fielding wrote: >this kind of feature doesn't need to be in BEEP core. I've proposed these things as BEEP "features" that would be registered and specified separately from the core. (see: RFC3080 section 5.2) > This is what IP load balancers are for -- waiting until > the beep session has been established means it has > already taken on the load. Load balancers work at the wrong level of granularity for some BEEP related needs... As far as I know, there are no existing IP load balancers that could be used to handle the case where one wishes to redirect traffic for some, but not all, of the profiles served by a BEEP server. This is because you can't know which profile the client wants to run until *after* the BEEP session has been established. This is unlike the HTTP case where the URL typically shows the load balancer all it needs to know before a connection to the server is established. To use a load balancer with BEEP would seem to imply that you would have to have two or more servers with identical profiles. You would also have to ensure that the applications were designed so that they could be accessed from multiple machines simultaneously (i.e. the different instances of the applications might have to share state -- such as user lists, activity data, charging data, etc.) These restrictions will not always be reasonable due to problems such as license restrictions on application deployment, increased application complexity, etc. > Application redirects need to be handled after the profile > is established (because there may be many different types > of redirect, like in HTTP). The redirection and availability features I'm proposing would come into play before the application has begun to service the connection since they are statements made about the BEEP server's willingness or ability to support the profile. They are not statements made by the application. The protocols defined in profiles would, of course, be free to define whatever profile specific redirection or availability options that they wanted to. Just as the BEEP server is able to publish the list of profiles that it is willing to support, the server should be able to qualify that willingness (with availability information) or elaborate on it's unwillingness (with redirects). The BEEP server should also be able to respond to a "start" by saying: "I won't start it for you -- go somewhere else." I read "start" as being a service of the BEEP server -- not of the application that is defined by the profile. >> So, whenever someone attempts to connect to the wrong >> machine, they would be redirected to the machine that they belong on. >> The company could then post the address of only one Beep server and then >> let the permanent redirects sort people out as they arrive. > This is an application-level redirect -- it belongs in the > profile protocol. In many implementations the beep server will control access to the various profile protocols. Having the application do the redirect with such servers wouldn't work -- access would be denied before the application had a chance to provide the redirect information. It seems to me that the code which denies access should be able to provide the information needed to recover from the denial. It should not be surprising to suggest that the beep server would take user-specific action based on authentication -- without invoking a specific profile. This has been suggested a number of times in the past. For instance the PDM Internet Draft states: "Accordingly, implementations may wish to advertise only tuning profiles used for privacy in their initial greeting (c.f., Section 3 of [BEEP]), and then advertise the BEEP profile for PDM after a tuning restart." Here, it is the BEEP server that decides who can see which profile -- it is not left to the application to deny access. I suggest that the server should be able to not only deny access, but also state when or where access to the profile might be granted. bob wyman _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jul 3 02:51:06 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA20294 for ; Tue, 3 Jul 2001 02:51:05 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id XAA02168; Mon, 2 Jul 2001 23:50:07 -0700 (PDT) Received: from petmai01.not.invisible.net (petmai01.not.invisible.net [204.62.247.27]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id XAA02152; Mon, 2 Jul 2001 23:50:05 -0700 (PDT) Received: by petmai01.not.invisible.net with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Jul 2001 00:03:36 -0700 Message-ID: From: Bill Mills To: "'Bob Wyman'" , bxxpwg@invisible.net Subject: RE: [BXXPwg] Redirect Feature for BEEP (continued...) Date: Tue, 3 Jul 2001 00:03:35 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net An important issue in 3 below would be proxied authentication/ distributed trust issues. Non-trivial. Probably better if you have this requirement to fail their authentication and make them use the right server. -bill -----Original Message----- From: Bob Wyman [mailto:bobwyman@firstrain.com] Sent: Monday, July 02, 2001 9:49 AM To: bxxpwg@invisible.net Subject: RE: [BXXPwg] Redirect Feature for BEEP (continued...) Marshall Rose wrote: >could you give me an example or two as to > how this would be used in practice. Use cases: 3. A company has two Beep servers that each support the same profile, however, because of quality of service requirements one group of users is required to use one of the servers while a second group uses a different server. So, whenever someone attempts to connect to the wrong machine, they would be redirected to the machine that they belong on. The company could then post the address of only one Beep server and then let the permanent redirects sort people out as they arrive. _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jul 3 10:41:46 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA14478 for ; Tue, 3 Jul 2001 10:41:45 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id HAA03890; Tue, 3 Jul 2001 07:40:46 -0700 (PDT) Received: from monsoon.us.ny.firstrain.com ([208.198.42.246]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id HAA03875 for ; Tue, 3 Jul 2001 07:40:44 -0700 (PDT) Subject: RE: [BXXPwg] Redirect Feature for BEEP (continued...) Date: Tue, 3 Jul 2001 10:42:23 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.4418.65 Thread-Topic: [BXXPwg] Redirect Feature for BEEP (continued...) Thread-Index: AcEDjLLJUqJTykY8R6yrPJyxFPJuMAAQBWoQ From: "Bob Wyman" To: "Bill Mills" , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by trystero.not.invisible.net id HAA03876 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 8bit Bill Mills wrote: > An important issue in 3 below would be proxied authentication/ > distributed trust issues. Non-trivial. A redirect would not raise authentication issues since it is simply advisory information provided by a server. A redirect issued by one server would not do anything to modify the authentication or authorization issues on some other server. It is simply a statement that "I won't serve you here. Try this other machine." Thus, as you suggest, someone who receives a redirect as a result of a start would "fail their authentication" then be advised of the "right server" to use. bob wyman _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jul 3 14:19:20 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14646 for ; Tue, 3 Jul 2001 14:19:17 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA05209; Tue, 3 Jul 2001 11:18:13 -0700 (PDT) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA05190 for ; Tue, 3 Jul 2001 11:18:12 -0700 (PDT) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f63IEJa07251; Tue, 3 Jul 2001 11:14:20 -0700 (PDT) Message-ID: <014701c103ec$7b17d850$8753cf3f@FATORA> From: "Marshall T. Rose" To: Cc: "Marshall Rose" Date: Tue, 3 Jul 2001 11:17:54 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0144_01C103B1.CE64ECE0" 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 Subject: [BXXPwg] new version of soap over beep published Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This is a multi-part message in MIME format. ------=_NextPart_000_0144_01C103B1.CE64ECE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit html version at http://beepcore.org/beepcore/beep-soap.jsp this draft addresses all issues raised since the previous draft. /mtr ------=_NextPart_000_0144_01C103B1.CE64ECE0 Content-Type: message/rfc822; name="I-D ACTION_draft-etal-beep-soap-02.txt.eml" Content-Disposition: attachment; filename="I-D ACTION_draft-etal-beep-soap-02.txt.eml" Delivery-Date: Tue, 03 Jul 2001 09:12:34 -0700 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with ESMTP id f63GCUa06960 for ; Tue, 3 Jul 2001 09:12:30 -0700 (PDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA14718 for ietf-123-outbound.10@ietf.org; Tue, 3 Jul 2001 10:55:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id GAA13031 for ; Tue, 3 Jul 2001 06:58:34 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24561 for ; Tue, 3 Jul 2001 06:58:32 -0400 (EDT) Message-Id: <200107031058.GAA24561@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-etal-beep-soap-02.txt Date: Tue, 03 Jul 2001 06:58:31 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using SOAP in BEEP Author(s) : E. O'Tuathail, M. Rose Filename : draft-etal-beep-soap-02.txt Pages : 23 Date : 02-Jul-01 SOAP is an XML-based messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, RPC, asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. A SOAP binding describes how SOAP messages are transmitted in the network. This memo specifies a SOAP binding to BEEP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-etal-beep-soap-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-etal-beep-soap-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-etal-beep-soap-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010702161713.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-etal-beep-soap-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-etal-beep-soap-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010702161713.I-D@ietf.org> --OtherAccess-- --NextPart-- ------=_NextPart_000_0144_01C103B1.CE64ECE0-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jul 6 05:57:40 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25054 for ; Fri, 6 Jul 2001 05:57:39 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id CAA18251; Fri, 6 Jul 2001 02:56:40 -0700 (PDT) Received: from mail3.registeredsite.com (mail3.registeredsite.com [64.224.9.12]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id CAA18235 for ; Fri, 6 Jul 2001 02:56:39 -0700 (PDT) Received: from mail.clipcode.com (mail.clipcode.com [64.225.30.241]) by mail3.registeredsite.com (8.11.1/8.11.1) with ESMTP id f669uZ022708 for ; Fri, 6 Jul 2001 05:56:35 -0400 Received: from central [64.225.30.241] by mail.clipcode.com (SMTPD32-6.00) id AB4E74A20098; Fri, 06 Jul 2001 05:56:30 -0400 Reply-To: From: "Eamon O'Tuathail" To: Date: Fri, 6 Jul 2001 10:59:37 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Subject: [BXXPwg] Protocol Bindings and XMLP/SOAP Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit Some here might be interested in the disucssion about protocol bindings & XML/SOAP on the xml-dist-app list, starting with: http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0013.html _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Sun Jul 8 17:20:51 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15623 for ; Sun, 8 Jul 2001 17:20:50 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA28253; Sun, 8 Jul 2001 14:19:30 -0700 (PDT) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA28240 for ; Sun, 8 Jul 2001 14:19:30 -0700 (PDT) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f68LEwa24963; Sun, 8 Jul 2001 14:14:58 -0700 (PDT) Message-ID: <032101c107f3$9ac93710$8753cf3f@FATORA> From: "Marshall T. Rose" To: "Henrik Frystyk Nielsen" , , "Mark Nottingham" Cc: References: <79107D208BA38C45A4E45F62673A434D0297CDD5@red-msg-07.redmond.corp.microsoft.com> Date: Sun, 8 Jul 2001 14:18:59 -0700 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 Subject: [BXXPwg] Re: Protocol Bindings Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit [ a conversation in progress... ] > > head-of-line blocking goes away when you do segmentation > >and allocations, the cost is that you sacrifice the ability to > >operate at TCP's theoretical speeds. > > Regardless of segmentation, you cannot avoid outstanding data ahead of > you having to be drained first. Additionally, in order to get reasonable > response time from a channel, you would want fairly small segments, > leaving applications having to cut their data into small pieces. yes, that's the "allocations" part above, except that it's not the application doing the cutting, it's the layer between them and tcp. > > deadlocks, as a potential problem, exist independently -- > >either due to poor protocol design or poor protocol implementation. > > An annoying aspect of communicating with somebody is that you don't > quite have control over how they react or how many resources they have > available :) Because channels are inherently interrelated it is always > possible to provide scenarios where a particular segmentation/allocation > policy gets in the way and can lead to unexpected deadlock situations > regardless of good intentions. i don't think this is provably true. i certainly agree that poor implementation, either inadvertent or purposefully, on the part of one side can lead to deadlock. but that's true of all bi-directional protocols, including, for example, tcp. > > channel aborts can be handled with prioritization of a > >control channel. > > Indeed but again, outstanding data will have to get drained which you > effectively have little control over how long that might take. In > general the purpose of channel aborts is to return the resources used as > quickly as possible. this isn't an argument against layers, instead, it's a truism that you can work only with what's available. regardless of whether you are doing one thing or many between two hosts, if the network locks up, the results are the same. > >none of this is rocket-science, it just requires careful > >engineering and reasonable implementation. > > Certainly it can be done but it seems to me to be a slippery slope - in > order to implement these mechanisms you will end up having to > reimplement much of what TCP already provides and a session layer seems > to me to be the wrong place to do that. i suppose everything can be viewed as a slippery slope. and i'll certainly agree that this is an area where careful implementation is necessary. which is why, i'd rather see people implement beep as a library layer, as opposed to just doing a quick and dirty set of subroutines in their application programs. > >as for the benefits: > > when you are able to amortize the cost of connection > >establishment, security neogitation, and state restoration for > >transactions involving more than one exchange, the benefits > >become noticable. > > I see but tying application state to a particular transport or session > channel doesn't seem like a good idea to me. I can't see why state > cannot be maintained in the endpoints without having any specific link > to the underlying transport. efficiency argues otherwise. the polar opposite approach is the stateless model with http, in which each step of a transaction maps to a single transport connection, which means that in multi-step transactions, you are constantly re-establishing state at both the transport and application layers: tcp discards learned network behavior, servers fork a new process (or refurbish a thread from the free pool), peers generate session keys and authenticate certificates, authorization databases get queried, etc., etc. of course, if your traffic is mostly one transaction = one req/rsp = one tcp connection, i guess it doesn't matter... > > when you are able to operate asynchronously in a > >loosely-coupled system, the benefits become noticable. > > Absolutely - I just don't think it takes a complex session layer to get > there. By supporting bi-directional messaging over a single TCP > connection and then use multiple TCP connections for handling message > interleaving, ... > > >because, in today's operational environments, if you originate > >two tcp connections to the same ip address at the same time, > >you have no guarantee that they terminate at the same system. > >10 years ago, this wasn't an issue... > > This only seems to reinforce my comments about it not being a good idea > to associate application state with the underlying transport. i don't get your reply. what my example shows is that there is no guarantee that multiple tcp connections will terminate at the same system. this means that any approach trying to use multiple TCP connections for interleaving traffic for the same session is doomed to failure. in fact, my example reinforces just the opposite of the conclusion you reach: if i can get establish a single tcp connection (not a sure thing in the operational internet), then i've already survived most of the "attacks of the middlebox". if a middlebox doesn't prevent you from reaching tcp's established state, then it's not likely that it will mess with you any further... (of course, that's only true of this year's boxes...) > >regardless, when you do multiple tcp connections, then there's > >a whole other set of problems that pop up with firewalls, > >viz., ftp-data for the simple case... > > No argument there either but I can't see that this is an argument for a > session layer. If we already have bi-directional messaging and I really > want more than one TCP connection then why can I not ask the party that > established the first connection to establish one more? we really have to have a long talk about NATs some time...the operational internet just doesn't work that way. /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jul 9 01:02:34 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21070 for ; Mon, 9 Jul 2001 01:02:33 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id WAA29576; Sun, 8 Jul 2001 22:01:37 -0700 (PDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with SMTP id VAA29441 for ; Sun, 8 Jul 2001 21:45:26 -0700 (PDT) Received: from 157.54.1.52 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 08 Jul 2001 21:45:18 -0700 (Pacific Daylight Time) Received: from red-msg-07.redmond.corp.microsoft.com ([157.54.12.75]) by inet-imc-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Sun, 8 Jul 2001 21:44:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [BXXPwg] Re: Protocol Bindings Date: Sun, 8 Jul 2001 21:44:35 -0700 Message-ID: <79107D208BA38C45A4E45F62673A434D0297CDDD@red-msg-07.redmond.corp.microsoft.com> Thread-Topic: [BXXPwg] Re: Protocol Bindings Thread-Index: AcEH9JJiK43an2+STFCEoS1Y3vXNbgAPIl0Q From: "Henrik Frystyk Nielsen" To: "Marshall T. Rose" , , "Mark Nottingham" Cc: X-OriginalArrivalTime: 09 Jul 2001 04:44:52.0342 (UTC) FILETIME=[E484E960:01C10831] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by trystero.not.invisible.net id VAA29442 Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 8bit I agree with your comment on the dist-app mailing list [1] and so rather than diving into another round I will just say thanks for your response :) Henrik Frystyk Nielsen mailto:henrikn@microsoft.com [1] http://lists.w3.org/Archives/Public/xml-dist-app/2001Jul/0058.html _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jul 10 12:41:52 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07867 for ; Tue, 10 Jul 2001 12:41:52 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA07701; Tue, 10 Jul 2001 09:17:29 -0700 (PDT) Received: from ns0.notenoughbandwidth.net (infrasearch [209.25.154.238] (may be forged)) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA07685 for ; Tue, 10 Jul 2001 09:17:28 -0700 (PDT) Received: from gonesilent.com (office.jxta.org [63.115.99.226]) by ns0.notenoughbandwidth.net (8.11.2/8.11.2) with ESMTP id f6AGCCi37613; Tue, 10 Jul 2001 09:12:12 -0700 (PDT) (envelope-from jbeatty@gonesilent.com) Message-ID: <3B4B2AC3.9020008@gonesilent.com> Date: Tue, 10 Jul 2001 09:18:11 -0700 From: "john d. beatty" User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2smp i686; en-US; rv:0.9.1) Gecko/20010608 X-Accept-Language: en-us MIME-Version: 1.0 To: bxxpwg@invisible.net References: Content-Type: multipart/mixed; boundary="------------020501010608050602080504" Subject: [BXXPwg] BEEP "Session Broker" Profile: Necessary and Useful? Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This is a multi-part message in MIME format. --------------020501010608050602080504 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I've been working on a BEEP "Session Broker Profile" that aims to define a profile that can be used to broker BEEP session creation for peers that are not directly addressable/reachable because of NATs and firewalls, and I'd appreciate some community feedback. The goal is to establish a direct-as-possible BEEP session between two peers in both the single NAT/firewall and double NAT/firewall scenarios. This profile provides for "reverse connections" in the single NAT/firewall case and "tunnelled connections" in the double NAT/firewall case via an intermediary "session broker" peer. I have attached the beginning of an I-D defining the profile (of course, it hasn't been filed with IETF or anything--this is less formal than it looks!). Please note that this is a rough first draft that only includes the rationale and a sampling of examples. My guess is that some people are going to say "just use APEX" to do asynch messaging between firewalled/NATted peers. While I agree that asynch messaging is certainly very useful, I believe the concept of establishing optimal BEEP sessions in the land of NATs and firewalls is also a useful concept, esp. for applications needing high-volume data transfer. In fact, I believe this profile is orthogonal to APEX; it could actually be used to establish BEEP sessions between APEX peers. The other thing that people might say is "use the TUNNEL profile". I believe what the TUNNEL does is define a BEEP proxy that lives in a demilitarized zone in an enterprise (i.e., it's analogous to an HTTP proxy). Note that I actually do leverage the TUNNEL profile for the double NAT/firewall scenario. So, my questions are: - What do people think of premise and goals of this Session Broker profile? - Has anyone been working on something similar? (I'm pretty new to BEEP) There are a number of issues in the details of the profile, but I'd like to have a high-level discussion first to make sure that lower-level discussions would be worthwhile. I do have a number of lower-level questions, primarily around service provisioning, authentication, authorization, etc. Those details are somewhat overlooked in my draft. john --------------020501010608050602080504 Content-Type: text/plain; name="draft-jbeatty-beep-session-broker-00.txt" Content-Disposition: inline; filename="draft-jbeatty-beep-session-broker-00.txt" Content-Transfer-Encoding: 7bit Network Working Group J. Beatty Internet-Draft Sun Microsystems, Inc. Expires: January 8, 2002 July 10, 2001 BEEP Session Broker Profile draft-jbeatty-beep-session-broker-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 8, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo describes a BEEP profile that allows an intermediary peer to broker BEEP session establishment between two peers that are not directly reachable or addressable with respect to each other due to firewalls or NAT gateways. 1. Rationale The BEEP [1] Session Broker profile provides a mechanism for two BEEP peers to establish a BEEP session with each other when either or both peers are not directly reachable with respect to each other. This is a common scenario on the Internet as peers are frequently behind either a firewall or a Network Address Translating (NAT) gateway. To Beatty Expires January 8, 2002 [Page 1] Internet-Draft BEEP Session Broker Profile July 2001 aid in BEEP session establishment, we name a third peer to be an intermediary to broker session establishment, and possibly relay all traffic in the "double NAT/firewall" sceniaro. The goal is to provide as direct of a connection between two peers as possible for peer-to-peer computing. Given two peers, Peer A and Peer B, where Peer A wishes to establish a BEEP session with Peer B, there are three cases to consider: o Peer B is directly reachable from Peer A. In this case, Peer B has a public IP address, or Peer A and Peer B are on the same private network, and Peer B is not firewalled to BEEP connections. Peer A is free to establish a BEEP session with Peer B as normal; the BEEP Session Broker profile is not needed. o Peer B is not reachable from Peer A, but Peer A is directly reachable from Peer B. This case is commonly referred to as the "single NAT/firewall" case. In this case, Peer B establishes a "broker relationship" with some Peer C such that Peer B initiates and maintains a persistent BEEP session with Peer C. When Peer A wants to establish a session with Peer B, it establishes a session with Peer C (if one is not pre-existing) and sends a "broker- splice-request" element. Peer C sends a "broker-splice-complete" element to Peer B with Peer A's network address, at which point Peer B establishes a BEEP session with Peer A. This is called the "brokered-spliced" session-establishment method. o Peer B is not reachable from Peer A, and Peer A is not reachable from Peer B. This case is commonly referred to as the "double NAT/firewall" scenario. In this scenario, Peer B establishes a "broker relationship" with some Peer C such that Peer B initiates and maintains a persistent BEEP session with Peer C. When Peer A wants to establish a session with Peer B, it establishes a session (if one is not pre-existing) with Peer C and sends a "TUNNEL" element conforming to draft-ietf-idwg-beep-tunnel-01 [2], with the endpoint attribute specified as Peer B's unique "peer id". Peer C sends a "broker-tunnel-callback-request" element to Peer B, at which point Peer B establishes a new BEEP session with Peer C and sends a "broker-tunnel-callback-complete" element, at which point Peer C sets up a tunnel between Peer A and Peer B. This is called the "brokered-tunnelled" session-establishment method. Note that in the first two cases, Peer A must have become privy to the broker relationship that Peer B established with Peer C. How Peer A became privy to this knowledge is outside the scope of this document. Also note that Peer A must have special knowledge about its Beatty Expires January 8, 2002 [Page 2] Internet-Draft BEEP Session Broker Profile July 2001 reachability from Peer B in order to decide whether to send a "broker-splice-request" element or a "TUNNEL" element to Peer C. How Peer B determines this is outside the scope of this document. When a peer establishes a broker relationship with another peer, a unique peer ID for the brokered peer must be agreed upon. Peer A must know Peer B's peer ID when it sends either the "broker-splice- request" or "broker-relay-request". How Peer A became privy to Peer B's peer ID is outside the scope of this document. 2. Examples The first two example show account provisioning and sign-in functionality. The next two examples show the actual BEEP Session Brokering functionality. 2.1 Session Broker Service Provisioning In this example, we show Peer B provisioning a Session Broker relationship with Peer C. This is a one-time operation. (TODO: there will also be a broker-unregister) Peer B Peer C ------ xport connect ------> <------- greeting ----------> --- broker-register [1] ---> <----------- ok ------------- Notes: [1] The broker-register element looks like this: 2.2 Signing in to a Broker Peer After a peer establishes a relationship with a broker, it needs to log in to initialize the broker control session. Note that in the following example, the BEEP session that was used for session provisioning could be used for signing in. This example presumes that the peer had already provisioned Session Broker service. (TODO: Add notes about authentication/authorization) Peer B Peer C ------ xport connect ------> <------- greeting ----------> ---- broker-login [1] -----> <----------- ok ------------- Beatty Expires January 8, 2002 [Page 3] Internet-Draft BEEP Session Broker Profile July 2001 Notes: [1] The broker-login element looks like this: 2.3 Brokered-Spliced Session Establishment The broker-splice-request element is used when Peer A is directly accessible from Peer B. In this example, Peer B has already established a BEEP session with Peer C and performed a broker-login as in the example above. In this example, there are three separate TCP connections, signified by a series of -'s, ='s, and ~'s, respectively. Peer A Peer C Peer B ------ xport connect --------> <------ greeting -------------> -- broker-splice-request[1] -> === broker-splice-complete[2] ==> <--------- ok ---------------- <~~~~~~~~~~~~~~~~~~~~~ xport connect ~~~~~~~~~~~~~~~~~~~~~~~~~ <~~~~~~~~~~~~~~~~~~~~~~~~ greeting ~~~~~~~~~~~~~~~~~~~~~~~~~~~> Notes: [1] The broker-splice-request element looks like this: [2] The broker-splice-complete element looks like this: Beatty Expires January 8, 2002 [Page 4] Internet-Draft BEEP Session Broker Profile July 2001 2.4 Brokered-Tunnelled Session Establishment The TUNNEL element is used when Peer A is not directly accessible from Peer B. In this example, Peer B has already established a BEEP session with Peer C and performed a broker-login as in the example above. In this example, there are three separate TCP connections, signified by a series of -'s, ='s, and ~'s, respectively. The brokered session is signified by the last line. ("greeting"). Note that the BEEP TUNNEL profile is used to set up this connection. Peer A Peer C Peer B ------ xport connect ------> <------ greeting -----------> --- start TUNNEL[1] -------> === broker-tunnel-request[2] ====> <~~~~~~ xport connect ~~~~~~~~~~~ <~~~~~~ greeting ~~~~~~~~~~~~~~~~> <~~~ broker-tunnel-complete[3] ~~ ~~~~~~ start TUNNEL[4] ~~~~~~~~~~> <~~~~~~~~~~ ok ~~~~~~~~~~~~~~~~~~ <========== ok ================== <---------- ok ------------- <----------------------- greeting ~~~~~~~~~~~~~~~~~~~~~~~~~~> Notes: [1] The TUNNEL element looks like this: [2] The broker-tunnel-request element looks like this: [3] The broker-tunnel-request element looks like this: [4] The TUNNEL element looks like this: 3. Message Syntax TODO 4. Message Semantics TODO References Beatty Expires January 8, 2002 [Page 5] Internet-Draft BEEP Session Broker Profile July 2001 [1] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [2] New, D., "The TUNNEL Profile", draft-ietf-idwg-beep-tunnel-01 (work in progress), February 2001. Author's Address John D. Beatty Sun Microsystems, Inc. 600 Townsend Suite 349-E San Francisco, CA 94103 US EMail: jbeatty@jxta.org URI: http://www.jxta.org Appendix A. Typeset Information This document written in XML using the xml2rfc engine and the RFC 2629 DTD, written by M. T. Rose. Beatty Expires January 8, 2002 [Page 6] Internet-Draft BEEP Session Broker Profile July 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Beatty Expires January 8, 2002 [Page 7] --------------020501010608050602080504-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jul 10 15:04:32 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15281 for ; Tue, 10 Jul 2001 15:04:31 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id MAA08834; Tue, 10 Jul 2001 12:03:45 -0700 (PDT) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id MAA08816 for ; Tue, 10 Jul 2001 12:03:44 -0700 (PDT) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f6AIx8a02505; Tue, 10 Jul 2001 11:59:08 -0700 (PDT) Message-ID: <0c2d01c10973$09b6aba0$8753cf3f@FATORA> From: "Marshall T. Rose" To: Cc: "Marshall Rose" Date: Tue, 10 Jul 2001 12:03:42 -0700 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0C2A_01C10938.5CF78B30" 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 Subject: [BXXPwg] new version of soap over beep Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This is a multi-part message in MIME format. ------=_NextPart_000_0C2A_01C10938.5CF78B30 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit html version at: http://beepcore.org/beepcore/beep-soap.jsp just some typos fixed. /mtr ------=_NextPart_000_0C2A_01C10938.5CF78B30 Content-Type: message/rfc822; name="I-D ACTION_draft-etal-beep-soap-03.txt.eml" Content-Disposition: attachment; filename="I-D ACTION_draft-etal-beep-soap-03.txt.eml" Delivery-Date: Tue, 10 Jul 2001 11:50:45 -0700 Received: from loki.ietf.org (loki.ietf.org [132.151.1.177]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with ESMTP id f6AIoha02475 for ; Tue, 10 Jul 2001 11:50:43 -0700 (PDT) Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA08543 for ietf-123-outbound.10@ietf.org; Tue, 10 Jul 2001 13:45:01 -0400 (EDT) Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id KAA06912 for ; Tue, 10 Jul 2001 10:26:35 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00680 for ; Tue, 10 Jul 2001 10:26:34 -0400 (EDT) Message-Id: <200107101426.KAA00680@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-etal-beep-soap-03.txt Date: Tue, 10 Jul 2001 10:26:33 -0400 Sender: nsyracus@cnri.reston.va.us --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Using SOAP in BEEP Author(s) : E. O'Tuathail, M. Rose Filename : draft-etal-beep-soap-03.txt Pages : 23 Date : 09-Jul-01 SOAP is an XML-based messaging protocol used to implement a wide variety of distributed messaging models. It defines a message format and describes a variety of message patterns, including, but not limited to, RPC, asynchronous event notification, unacknowledged messages, and forwarding via SOAP intermediaries. A SOAP binding describes how SOAP messages are transmitted in the network. This memo specifies a SOAP binding to BEEP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-etal-beep-soap-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-etal-beep-soap-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-etal-beep-soap-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010709103703.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-etal-beep-soap-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-etal-beep-soap-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010709103703.I-D@ietf.org> --OtherAccess-- --NextPart-- ------=_NextPart_000_0C2A_01C10938.5CF78B30-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jul 10 21:12:48 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02351 for ; Tue, 10 Jul 2001 21:12:47 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id RAA10496; Tue, 10 Jul 2001 17:19:52 -0700 (PDT) Received: from ns0.notenoughbandwidth.net (infrasearch [209.25.154.238] (may be forged)) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id RAA10482 for ; Tue, 10 Jul 2001 17:19:51 -0700 (PDT) Received: from gonesilent.com (office.jxta.org [63.115.99.226]) by ns0.notenoughbandwidth.net (8.11.2/8.11.2) with ESMTP id f6B0EJi43296; Tue, 10 Jul 2001 17:14:19 -0700 (PDT) (envelope-from jbeatty@gonesilent.com) Message-ID: <3B4B9BC2.9080603@gonesilent.com> Date: Tue, 10 Jul 2001 17:20:18 -0700 From: "john d. beatty" User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2smp i686; en-US; rv:0.9.1) Gecko/20010608 X-Accept-Language: en-us MIME-Version: 1.0 To: Darren New CC: bxxpwg@invisible.net Subject: Re: [BXXPwg] BEEP "Session Broker" Profile: Necessary and Useful? References: <3B4B2AC3.9020008@gonesilent.com> <3B4B4C32.B5B371B4@san.rr.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit Thanks for the excellent feedback, Darren. I believe I'm in agreement with your idea about using the TUNNEL profile with some extra configuration and a bit of extension. I had originally considered trying to extend the TUNNEL profile, but originally decided against for a couple of reasons, which I hint at inline below. But overall, I think trying to use the TUNNEL profile is the way to go. Inline below I explain some of my rationale (esp. for the persistent connections), and expand on some of the issues with extending the TUNNEL profile. I'll work up some examples in the next day or so on how the extended TUNNEL profile might work. thanks again, john Darren New wrote: >"john d. beatty" wrote: > >>o Peer B is not reachable from Peer A, and Peer A is not reachable >> from Peer B. This case is commonly referred to as the "double >> NAT/firewall" scenario. In this scenario, Peer B establishes a >> "broker relationship" with some Peer C such that Peer B initiates >> and maintains a persistent BEEP session with Peer C. When Peer A >> wants to establish a session with Peer B, it establishes a session >> (if one is not pre-existing) with Peer C and sends a "TUNNEL" >> element conforming to draft-ietf-idwg-beep-tunnel-01 [2], with the >> endpoint attribute specified as Peer B's unique "peer id". Peer C >> sends a "broker-tunnel-callback-request" element to Peer B, at >> which point Peer B establishes a new BEEP session with Peer C and >> sends a "broker-tunnel-callback-complete" element, at which point >> Peer C sets up a tunnel between Peer A and Peer B. This is called >> the "brokered-tunnelled" session-establishment method. >> > >It's unclear to me why there needs to be a "callback" or "brokered >tunnel" here. Why would A, B, and C not just use the TUNNEL profile, >with B establishing a new session with C each time the previous session >gets a TUNNEL > > >In other words, in this case, I would have the following steps: > >1) B establishes one or more BEEP sessions to C. > B advertises that it'll serve TUNNEL on each of these sessions. >2) B uses SASL to identify itself to C over all sessions. >3) A establishes a connection+session with C. >4) A requests that C tunnel to B with TUNNEL . >5) C picks one of the sessions already open to B and > sends a TUNNEL . >6) B accepts that and sends a new greeting to A, etc. >7) B, if the load is acceptable and etc, establishes a new session > with C in order to accept more TUNNEL requests from outside. > >Note that this requires no new profiles. It's simply a matter of >configuration. SASL is used for identification in the broker-login sense >(which one would assume is a good idea if one is in a situation where >one is using NAT or firewall to start with). And of course one can use >SASL/ANONYMOUS if one doesn't care after all. > >The trick is that while B initiates the session, C can the >TUNNEL to B (at A's request). > I like this. Simpler, cleaner. The only advantage that I see with the "one persistent session" from B to C that I was proposing is that the session could be used for multiple things, including asynch message relaying (ala APEX). >Note too that this is effective even if A is behind multiple firewalls >(say, departmental and corporate), while it's not clear to me how the >brokering profile addresses such things. > The session brokering profile would be used in conjunction with the TUNNEL profile if Peer A was behind multiple firewalls. It's just trying to connect to C. >In addition, the interaction between TLS and the various brokering modes >would need to be explored. Actually, in general, I think a lot of >security implications would need to be explored. :-) For example, >imagine a DoS attack consisting of my machines making a bunch of >connections to 3rd party machines, and telling their brokers to all >connect back to your server. > Right. This is an issue of whether the TUNNEL profile is used, or this Session Broker profile is used. All the normal anti-DoS measures would need to be built-in to the peer providing tunnelling services. > > >> o Peer B is not reachable from Peer A, but Peer A is directly >> reachable from Peer B. This case is commonly referred to as the >> "single NAT/firewall" case. In this case, Peer B establishes a >> "broker relationship" with some Peer C such that Peer B initiates >> and maintains a persistent BEEP session with Peer C. When Peer A >> wants to establish a session with Peer B, it establishes a session >> with Peer C (if one is not pre-existing) and sends a "broker- >> splice-request" element. Peer C sends a "broker-splice-complete" >> element to Peer B with Peer A's network address, at which point >> Peer B establishes a BEEP session with Peer A. This is called the >> "brokered-spliced" session-establishment method. >> > >This is a case that TUNNEL addresses only with the inefficiency of C >continuing to forward packets. However, I think it would be easier to >extend TUNNEL to handle this efficiently than it would be to design and >implement an entirely new profile. > Agreed. >For this case, A is asking B to set up an outgoing session. I think a >better way of handling this would be to have an extra attribute on the >TUNNEL argument (call it "originator"), which would specify that the >address on that element is actually the originator. If B can establish a >connection back to A at that address, it does so, and rejects the TUNNEL > with an appropriate error code that means "Look for a new >incoming connection from me." If B cannot establish a connection back to >A at that address, then it accepts the TUNNEL and passes packets >through C. If the attribute is set on an element that is not the >innermost element, B would be expected to use TUNNEL to get back to A. >(This is getting complicated, yes. :-) > >This organization has the benefit that A doesn't need to know whether B >can call out to A or not. A merely advertises that it's willing to >accept connections. B can decide what the appropriate method of contact >is, whether to accept the TUNNEL through C, or to try to establish a >reverse-connection back to A. (As far as I can see, the primary >differences are that C is taken out of the loop for better efficiency, >and A can tell B to call back a *different* server.) > It is more efficient if A knows at least something about its reachability so various peers don't have to keep trying to figure it out. There's no reliable way for B to tell whether the address for A is going to work or not. I'm thinking about using some simple peer introspection mechanism that is a simple reachability test that A can used to test itself. The complicated part comes because peers operate on various address spaces (essentially one public network and many private networks). Let me think about some ways to extend the TUNNEL profile. >In other words, A really is tunneling to B via C, but the range of >operations that A can invoke is very limited. Indeed, it is limited >precisely to "call me back." Since TUNNEL already defines everything >needed for addressing a peer behind a firewall, it would seem to make >more sense to extend TUNNEL with a separate operation or parameter, >rather than beginning an entirely new profile to do exactly what TUNNEL >does, only with one more datum at the end. > >In addition, it seems kind of odd to me that A would be contacting B to >say "call me up" with no indication of what B is supposed to do when it >contacts A. Presumedly, a different TUNNEL identifier would have to be >used at B for each service that A might provide. For example, A >requesting that B call it back to get printer status would be different >than A requesting that B call it back to establish an APEX relay-relay >connection, since these are likely implemented in two different programs >in B. Because of this, I'd expect another parameter in the TUNNEL > for the callback case, namely the URI that the program doing the >reverse connection should support. In this case, I would say that if the >"originator" attribute says that the element describes the caller, then >it may have an address *and* a "profile" attribute, indicating that B >should attempt to contact A at that address, starting the indicated >profile. (Implementation-wise, B might have to start a new program with >that start-up information, or otherwise find an executable capable of >dealing with the indicated profile, or reject the TUNNEL entirely if >such a profile is not available at B.) > Good point. I'd be more keen to use a unique ID rather than a URI, however, to reduce possibilities of collisions. >Now, what we don't have if we only use TUNNEL is a registration by which >B can inform C of its willingness to accept connections, and then have >no sessions established with C until A requests C make such a >connection. (I.e., we have no way for B to specify to C a mapping from >B's endpoint identifier to B's address.) However, I assumed that would >be a local configuration at C, rather than at B. That is, I had assumed >that the SASL login would be sufficient to identify to C the >configuration of B. Certainly if the point of the firewall is to >restrict traffic to approved connections, the firewall is the >appropriate place to configure such things. > Note that I do not want to make the assumption that C is within B's firewall or that B is addressable/reachable from C. However, a nice optimization in the case that B is addressable/reachable from C is to obviate the need for the long-lived connection from B to C. It does seems that some sort of account provisioning may be necessary to register an endpoint identifier. It's possible that introspection services could be in-built to C that would determine reachability. >Other comments on the specific draft proposals: > >2.1 vs 2.2 - What's the difference? > 2.1 is account provisionining. 2.2 is saying "I'm willing to accept connections" (and also, "I'm offline/unwilling to accept connections") >2.3 - Of course, you'll want more different forms for "addr". And what >if B needs to use TUNNEL to get back to A? It looks like the channel >between C and B is persistant, rather than being dropped after a single >broker-splice-request? > > >2.4 - What is the benefit of the ~~~ connection? Why not simply send the >TUNNEL over the === connection? B needs to establish a new >connection with C in either case, so use the connection already >established, and let B set up a new connection to C without A having to >wait for it. > Looks like these are moot issues now. However, on 2.4, the same thing applies: I was allowing for this persistent connection to be used for other things. john _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jul 10 22:31:33 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05517 for ; Tue, 10 Jul 2001 22:31:32 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA08566; Tue, 10 Jul 2001 11:40:54 -0700 (PDT) Received: from smtp2.san.rr.com (smtp2.san.rr.com [24.25.195.39]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA08553 for ; Tue, 10 Jul 2001 11:40:53 -0700 (PDT) Received: from san.rr.com ([24.94.25.117]) by smtp2.san.rr.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Tue, 10 Jul 2001 11:36:28 -0700 Message-ID: <3B4B4C32.B5B371B4@san.rr.com> Date: Tue, 10 Jul 2001 11:40:50 -0700 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: "john d. beatty" CC: bxxpwg@invisible.net Subject: Re: [BXXPwg] BEEP "Session Broker" Profile: Necessary and Useful? References: <3B4B2AC3.9020008@gonesilent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit "john d. beatty" wrote: > I have attached the beginning of an I-D defining the profile (of course, > it hasn't been filed with IETF or anything--this is less formal than it > looks!). Please note that this is a rough first draft that only > includes the rationale and a sampling of examples. I'll take a cut at making a few comments. Mind, I'm the author of TUNNEL, so I might be a little nearsighted and/or biased. ;-) > Given two peers, Peer A and Peer B, where Peer A wishes to establish > a BEEP session with Peer B, there are three cases to consider: > > o Peer B is directly reachable from Peer A. In this case, Peer B > has a public IP address, or Peer A and Peer B are on the same > private network, and Peer B is not firewalled to BEEP connections. > Peer A is free to establish a BEEP session with Peer B as normal; > the BEEP Session Broker profile is not needed. We agree on this one. ;-) Note that I've reversed the second and third case, as it makes it a little easier to describe here. Hence, I talk about the case where both A and B are firewalled next. > o Peer B is not reachable from Peer A, and Peer A is not reachable > from Peer B. This case is commonly referred to as the "double > NAT/firewall" scenario. In this scenario, Peer B establishes a > "broker relationship" with some Peer C such that Peer B initiates > and maintains a persistent BEEP session with Peer C. When Peer A > wants to establish a session with Peer B, it establishes a session > (if one is not pre-existing) with Peer C and sends a "TUNNEL" > element conforming to draft-ietf-idwg-beep-tunnel-01 [2], with the > endpoint attribute specified as Peer B's unique "peer id". Peer C > sends a "broker-tunnel-callback-request" element to Peer B, at > which point Peer B establishes a new BEEP session with Peer C and > sends a "broker-tunnel-callback-complete" element, at which point > Peer C sets up a tunnel between Peer A and Peer B. This is called > the "brokered-tunnelled" session-establishment method. It's unclear to me why there needs to be a "callback" or "brokered tunnel" here. Why would A, B, and C not just use the TUNNEL profile, with B establishing a new session with C each time the previous session gets a TUNNEL ? In other words, in this case, I would have the following steps: 1) B establishes one or more BEEP sessions to C. B advertises that it'll serve TUNNEL on each of these sessions. 2) B uses SASL to identify itself to C over all sessions. 3) A establishes a connection+session with C. 4) A requests that C tunnel to B with TUNNEL . 5) C picks one of the sessions already open to B and sends a TUNNEL . 6) B accepts that and sends a new greeting to A, etc. 7) B, if the load is acceptable and etc, establishes a new session with C in order to accept more TUNNEL requests from outside. Note that this requires no new profiles. It's simply a matter of configuration. SASL is used for identification in the broker-login sense (which one would assume is a good idea if one is in a situation where one is using NAT or firewall to start with). And of course one can use SASL/ANONYMOUS if one doesn't care after all. The trick is that while B initiates the session, C can the TUNNEL to B (at A's request). Note too that this is effective even if A is behind multiple firewalls (say, departmental and corporate), while it's not clear to me how the brokering profile addresses such things. In addition, the interaction between TLS and the various brokering modes would need to be explored. Actually, in general, I think a lot of security implications would need to be explored. :-) For example, imagine a DoS attack consisting of my machines making a bunch of connections to 3rd party machines, and telling their brokers to all connect back to your server. > o Peer B is not reachable from Peer A, but Peer A is directly > reachable from Peer B. This case is commonly referred to as the > "single NAT/firewall" case. In this case, Peer B establishes a > "broker relationship" with some Peer C such that Peer B initiates > and maintains a persistent BEEP session with Peer C. When Peer A > wants to establish a session with Peer B, it establishes a session > with Peer C (if one is not pre-existing) and sends a "broker- > splice-request" element. Peer C sends a "broker-splice-complete" > element to Peer B with Peer A's network address, at which point > Peer B establishes a BEEP session with Peer A. This is called the > "brokered-spliced" session-establishment method. This is a case that TUNNEL addresses only with the inefficiency of C continuing to forward packets. However, I think it would be easier to extend TUNNEL to handle this efficiently than it would be to design and implement an entirely new profile. For this case, A is asking B to set up an outgoing session. I think a better way of handling this would be to have an extra attribute on the TUNNEL argument (call it "originator"), which would specify that the address on that element is actually the originator. If B can establish a connection back to A at that address, it does so, and rejects the TUNNEL with an appropriate error code that means "Look for a new incoming connection from me." If B cannot establish a connection back to A at that address, then it accepts the TUNNEL and passes packets through C. If the attribute is set on an element that is not the innermost element, B would be expected to use TUNNEL to get back to A. (This is getting complicated, yes. :-) This organization has the benefit that A doesn't need to know whether B can call out to A or not. A merely advertises that it's willing to accept connections. B can decide what the appropriate method of contact is, whether to accept the TUNNEL through C, or to try to establish a reverse-connection back to A. (As far as I can see, the primary differences are that C is taken out of the loop for better efficiency, and A can tell B to call back a *different* server.) In other words, A really is tunneling to B via C, but the range of operations that A can invoke is very limited. Indeed, it is limited precisely to "call me back." Since TUNNEL already defines everything needed for addressing a peer behind a firewall, it would seem to make more sense to extend TUNNEL with a separate operation or parameter, rather than beginning an entirely new profile to do exactly what TUNNEL does, only with one more datum at the end. In addition, it seems kind of odd to me that A would be contacting B to say "call me up" with no indication of what B is supposed to do when it contacts A. Presumedly, a different TUNNEL identifier would have to be used at B for each service that A might provide. For example, A requesting that B call it back to get printer status would be different than A requesting that B call it back to establish an APEX relay-relay connection, since these are likely implemented in two different programs in B. Because of this, I'd expect another parameter in the TUNNEL for the callback case, namely the URI that the program doing the reverse connection should support. In this case, I would say that if the "originator" attribute says that the element describes the caller, then it may have an address *and* a "profile" attribute, indicating that B should attempt to contact A at that address, starting the indicated profile. (Implementation-wise, B might have to start a new program with that start-up information, or otherwise find an executable capable of dealing with the indicated profile, or reject the TUNNEL entirely if such a profile is not available at B.) Now, what we don't have if we only use TUNNEL is a registration by which B can inform C of its willingness to accept connections, and then have no sessions established with C until A requests C make such a connection. (I.e., we have no way for B to specify to C a mapping from B's endpoint identifier to B's address.) However, I assumed that would be a local configuration at C, rather than at B. That is, I had assumed that the SASL login would be sufficient to identify to C the configuration of B. Certainly if the point of the firewall is to restrict traffic to approved connections, the firewall is the appropriate place to configure such things. Other comments on the specific draft proposals: 2.1 vs 2.2 - What's the difference? 2.3 - Of course, you'll want more different forms for "addr". And what if B needs to use TUNNEL to get back to A? It looks like the channel between C and B is persistant, rather than being dropped after a single broker-splice-request? 2.4 - What is the benefit of the ~~~ connection? Why not simply send the TUNNEL over the === connection? B needs to establish a new connection with C in either case, so use the connection already established, and let B set up a new connection to C without A having to wait for it. -- Darren New / Senior MTS & Free Radical / Invisible Worlds Inc. San Diego, CA, USA (PST). Cryptokeys on demand. Only a WIMP puts wallpaper on his desktop. _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jul 10 23:52:39 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08050 for ; Tue, 10 Jul 2001 23:52:38 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id UAA11235; Tue, 10 Jul 2001 20:51:52 -0700 (PDT) Received: from mail.opencola.com ([216.94.182.2]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id UAA11220 for ; Tue, 10 Jul 2001 20:51:50 -0700 (PDT) Received: from [10.7.1.114] (block.it.ca [216.126.86.6] (may be forged)) by mail.opencola.com (8.11.0/8.11.0) with ESMTP id f6B2r9819157 for ; Tue, 10 Jul 2001 22:53:12 -0400 Mime-Version: 1.0 X-Sender: dnm@mail.vex.net Message-Id: Date: Tue, 10 Jul 2001 23:50:45 -0400 To: bxxpwg@invisible.net From: Dan Moniz Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: [BXXPwg] beepcore-c status Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net I was wondering what the general status of the beepcore-c implementation is. This is perhaps somewhat unfair since the beepcore-ruby project I started on SourceForge hasn't shown any appreciable movement, but I've gotten people at work curious about BEEP again, and it would be more in line with our needs to use a C implementation over the ones available in Java or Tcl. Just curious. -- Dan Moniz [http://www.pobox.com/~dnm/] _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Wed Jul 11 14:57:00 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16053 for ; Wed, 11 Jul 2001 14:57:00 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA14993; Wed, 11 Jul 2001 11:39:09 -0700 (PDT) Received: from mail.utah.invisible.net ([208.187.207.232]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with SMTP id JAA14429 for ; Wed, 11 Jul 2001 09:56:17 -0700 (PDT) Received: (qmail 31145 invoked from network); 11 Jul 2001 16:48:25 -0000 Received: from wilson.utah.invisible.net (HELO wilson) (trilluser@208.187.207.234) by treebeard.utah.invisible.net with SMTP; 11 Jul 2001 16:48:25 -0000 Message-ID: <0ff101c10a2a$16d0ee60$0100a8c0@wilson> From: "Huston" To: Cc: References: Subject: Re: [BXXPwg] beepcore-c status Date: Wed, 11 Jul 2001 10:52:02 -0600 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: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit Dan, The beepcore-C project is proceeding. The basic library is functioning (on Linux and Solaris, win32 is under development) and we are working on TLS and SASL profiles right now. --Huston ----- Original Message ----- From: "Dan Moniz" To: Sent: Tuesday, July 10, 2001 9:50 PM Subject: [BXXPwg] beepcore-c status > I was wondering what the general status of the beepcore-c > implementation is. This is perhaps somewhat unfair since the > beepcore-ruby project I started on SourceForge > hasn't shown any > appreciable movement, but I've gotten people at work curious about > BEEP again, and it would be more in line with our needs to use a C > implementation over the ones available in Java or Tcl. > > Just curious. > > -- > Dan Moniz [http://www.pobox.com/~dnm/] > > _______________________________________________ > BXXPwg mailing list > BXXPwg@lists.invisible.net > http://lists.invisible.net/mailman/listinfo/bxxpwg > _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Wed Jul 11 15:50:09 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17660 for ; Wed, 11 Jul 2001 15:50:07 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id MAA15476; Wed, 11 Jul 2001 12:49:20 -0700 (PDT) Received: from xomi.pair.com (xomi.pair.com [209.68.2.14]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with SMTP id MAA15459 for ; Wed, 11 Jul 2001 12:49:18 -0700 (PDT) Received: (qmail 59231 invoked by uid 3039); 11 Jul 2001 19:49:13 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 11 Jul 2001 19:49:13 -0000 Date: Wed, 11 Jul 2001 12:49:13 -0700 (PDT) From: Gabe Wachob X-Sender: To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1337325908-994880953=:44735" Subject: [BXXPwg] A BEEP poem Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-1337325908-994880953=:44735 Content-Type: TEXT/PLAIN; charset=US-ASCII This poem is GPL'd Its author is Jay Kint, Invisible Worlder. Enjoy -Gabe --0-1337325908-994880953=:44735 Content-Type: TEXT/PLAIN; NAME="BEEP Poem.txt" Content-ID: Content-Description: Content-Disposition: ATTACHMENT; FILENAME="BEEP Poem.txt" Content-Transfer-Encoding: QUOTED-PRINTABLE ------------------------------------------------ Start of #beepnik buffer: Wed Jul 11 13:33:20 2001 *** Now talking in #beepnik. *** Topic of #beepnik: BEEP and APEX - http://www.beepcore.org *** Set by ChanServ 180 minutes ago *** Users on #beepnik: Icosahedron huston @GabeW=20 *** End of /NAMES list. *** Mode for channel #beepnik is "+tn" *** Channel #beepnik was created at Wed Jul 11 10:13:40 2001 *** Join to #beepnik completed in 0 seconds. wow, 3 people! Yes, this is incredible. cruising now... Many faceted one might say :) How come this channel doesn't show up on the list/ ? not enough people in this channel - kinda sux as a chicken/egg = problem Feh. That figures. we get bondolo from the jxta group here a lot - he's a core = developer That should be interesting. of JXTA? What is JXTA? I was on IRC, not know which channel to pick I also have #jxtabeep --- When I heard about the unpopular beepnik http://www.jxta.org * GabeW thinks Icosahedron has had his/her head under a rock ;) So I thought I would wander on over oh, so you have no idea what BEEP is? To see if there was any clover. Instead I see people taking the fall For a wondeful new protocol. There were no wolves with these sheep. They were hip cats talkin' 'bout BEEP. Whoa, Icosahedron is a poet, and he knows it Well this IRC is pretty slick. And I'm a beepnik! well, this IRC is about what, 15 years old technology So just writing code trying to determine the parameter. When I thought I'd drop some iambic pentameter! rock on, Icosahedron * GabeW nominates Icosahedron as #beepnik court poet So in I bounce to this meeting. When I get sent a * GabeW groans I'm thinkin I'll put my wait a while. When it starts askin for my profile Then I see it uses 822, the RFC, and I'm thinkin that's the format for me! Cause everyone knows to save some time. You must format the message according to MIME But the body, that would be difficult to tell. So I think I'll use XML! But securing a session can be such a mess, unless you use the ubiquitous TLS! But authentication, what a hassle. So I fired up a profile called SASL! But these are things I'll those But these issues are dealt with by those With credentials such as Marshall Rose! Well, I'm feeling a bit pink So I'll quit this poem and get rid of the stink. Icosahedron - can you put that into an email and send it to me? This poem is under GPL, so it's free! yeah, but my stupid irc client doesn't let me easily cut/paste That client is such a waste! * GabeW slaps Icosahedron=20 can you send it to me? I want to send it to the bxxpwg list. Unless you can snd it directly Do you have checksums so it'll send correctly? who are you Icosahedron?=20 Well, as my coworkers call me a moron. ah, you are not a I-W employee, by any chance? Well, I would deny it, but then I'd have fiery pants. End of #beepnik buffer: Wed Jul 11 13:33:20 2001 --0-1337325908-994880953=:44735-- _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Wed Jul 11 19:23:18 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24538 for ; Wed, 11 Jul 2001 19:23:17 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id QAA16684; Wed, 11 Jul 2001 16:22:26 -0700 (PDT) Received: from petmai01.not.invisible.net (petmai01.not.invisible.net [204.62.247.27]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id QAA16661; Wed, 11 Jul 2001 16:21:54 -0700 (PDT) Received: by petmai01.not.invisible.net with Internet Mail Service (5.5.2650.21) id ; Wed, 11 Jul 2001 16:35:51 -0700 Message-ID: From: Bill Mills To: "'Gabe Wachob'" , bxxpwg@lists.invisibleworlds.com Subject: RE: [BXXPwg] A BEEP poem Date: Wed, 11 Jul 2001 16:35:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This GPL, it has something to do with poetic license? -----Original Message----- From: Gabe Wachob [mailto:gwachob@wachob.com] Sent: Wednesday, July 11, 2001 12:49 PM To: bxxpwg@lists.invisibleworlds.com Subject: [BXXPwg] A BEEP poem This poem is GPL'd Its author is Jay Kint, Invisible Worlder. Enjoy -Gabe _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jul 16 14:12:59 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09072 for ; Mon, 16 Jul 2001 14:12:54 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA09017; Mon, 16 Jul 2001 11:11:43 -0700 (PDT) Received: from dbc.mtview.ca.us (ppp-63-207-83-130.ded.pacbell.net [63.207.83.130]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA08991 for ; Mon, 16 Jul 2001 11:11:42 -0700 (PDT) Received: from FATORA (ppp-63-207-83-135.ded.pacbell.net [63.207.83.135]) by dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id f6GI63a24466; Mon, 16 Jul 2001 11:06:04 -0700 (PDT) Message-ID: <00d901c10e22$b37dfd60$8753cf3f@FATORA> From: "Marshall T. Rose" To: "john d. beatty" , "Darren New" Cc: , "Marshall Rose" References: <3B4B2AC3.9020008@gonesilent.com> <3B4B4C32.B5B371B4@san.rr.com> <3B4B9BC2.9080603@gonesilent.com> Subject: Re: [BXXPwg] BEEP "Session Broker" Profile: Necessary and Useful? Date: Mon, 16 Jul 2001 11:11:13 -0700 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: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit hi. i suggest that the two of you have a private conversation as to what minimal sets of mods to the tunnel profile are necessary to meet john's requirements, and then you can send a note to the idwg mailing list explaining what you want to do. time is of the essence here, that wg would like to be closing up shop soon... thanks, /mtr _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jul 16 19:02:21 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28709 for ; Mon, 16 Jul 2001 19:02:21 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id QAA10519; Mon, 16 Jul 2001 16:01:28 -0700 (PDT) Received: from omx1.csg.stercomm.com (omx1.csg.stercomm.com [207.43.171.9]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id PAA10464 for ; Mon, 16 Jul 2001 15:59:08 -0700 (PDT) Received: from scidalmsg01.csg.stercomm.com (scidalmsg01.csg.stercomm.com [10.20.32.29]) by omx1.csg.stercomm.com with ESMTP id RAA20436 for ; Mon, 16 Jul 2001 17:55:50 -0500 (CDT) Received: by scidalmsg01.csg.stercomm.com with Internet Mail Service (5.5.2653.19) id <30TDZD5B>; Mon, 16 Jul 2001 17:58:46 -0500 Message-ID: <40AC2C8FB855D411AE0200D0B7458B2B045859B5@scidalmsg01.csg.stercomm.com> From: "Ander, Dale" To: "'bxxpwg@invisible.net'" Date: Mon, 16 Jul 2001 17:58:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [BXXPwg] BEEP Question Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Hello, I have an application in mind that would utilize BEEP but I'm having a hard time getting started. I read RFC 3080 fairly closely (but not 3081), have downloaded the Java implementation of BEEP (0.9.06), and even managed to compile Beepd and Bing (but wasn't sure how to use/run them to prove anything). What should I do to both test Beepd and Bing and to get going with my own application idea? FYI I'm wanting to use BEEP to move data thru a firewall. I want to be able to set up a secure connection from the secure part of my network into a "DMZ" (screened subnet) and pull the data that is sent there via HTTP requests into the secure part of my network. I'd be taking advantage of the ability of BEEP to both multiplex multiple channels over one session (I'd use a different channel for the data associated with each different HTTP request) and it's ability to set up a secure connection (I wouldn't want hackers to be able to sniff the data as it's being transferred from the DMZ into the secure part of my network) and this application would not require a firewall administrator to open up the firewall for connections originating in the DMZ into the secure part of the network (the reverse is already possible - i.e. I'm able to initiate a connection from the secure part of the network into the DMZ). Are there any books/tutorials/web sites/consultants that could help me or do I just need to start reading the Java source codes that I've downloaded? Any help would be much appreciated. I'm looking for any jump start I can get. :-) Thanks, Dale Dale Ander Senior Software Architect Sterling Commerce, Inc. Research and Advanced Technology Group dale_ander@stercomm.com (469) 524-2603 _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Mon Jul 16 20:00:43 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA10534 for ; Mon, 16 Jul 2001 20:00:42 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id QAA10745; Mon, 16 Jul 2001 16:59:54 -0700 (PDT) Received: from xomi.pair.com (xomi.pair.com [209.68.2.14]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with SMTP id QAA10732 for ; Mon, 16 Jul 2001 16:59:53 -0700 (PDT) Received: (qmail 8305 invoked by uid 3039); 16 Jul 2001 23:59:47 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 16 Jul 2001 23:59:47 -0000 Date: Mon, 16 Jul 2001 16:59:47 -0700 (PDT) From: Gabe Wachob X-Sender: To: "Ander, Dale" cc: "'bxxpwg@invisible.net'" Subject: Re: [BXXPwg] BEEP Question In-Reply-To: <40AC2C8FB855D411AE0200D0B7458B2B045859B5@scidalmsg01.csg.stercomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Dale- Your application is a great one for BEEP. I'm not aware of anything particularly useful for you out there - most of the info about BEEP is stuck in people's heads or on beepcore.org, or captured in the archives of this list. That being said, there are some consultants out there who would be able to help - myself in particular. Please email me at your convenience. Finally, if you are so inclined, I've also registered an IRC channel called #beepnik on irc.openprojects.net where you can find me much of the time if you want to chat directly. I'm GabeW there, and some of the I-W developers are there as well. To answer your beepd/bing question, I think you want to get the distro (I work out of cvs code, so I'm not sure if the directory structure is the same), build everything, add the jars (core, sasl, tls) to the classpath and then run: [BEEP SERVER] java org.beepcore.beep.example.Beepd -config beepd-config.xml (that xml file is in the distro somewhere) [BEEP PING CLIENT] - in another shell java org.beepcore.beep.example.Bing localhost There are some command line options for the beep ping client as well. Hope this gets you started!! -Gabe On Mon, 16 Jul 2001, Ander, Dale wrote: > Hello, > > I have an application in mind that would utilize BEEP but I'm having a hard > time getting started. I read RFC 3080 fairly closely (but not 3081), have > downloaded the Java implementation of BEEP (0.9.06), and even managed to > compile Beepd and Bing (but wasn't sure how to use/run them to prove > anything). What should I do to both test Beepd and Bing and to get going > with my own application idea? > > FYI I'm wanting to use BEEP to move data thru a firewall. I want to be able > to set up a secure connection from the secure part of my network into a > "DMZ" (screened subnet) and pull the data that is sent there via HTTP > requests into the secure part of my network. I'd be taking advantage of the > ability of BEEP to both multiplex multiple channels over one session (I'd > use a different channel for the data associated with each different HTTP > request) and it's ability to set up a secure connection (I wouldn't want > hackers to be able to sniff the data as it's being transferred from the DMZ > into the secure part of my network) and this application would not require a > firewall administrator to open up the firewall for connections originating > in the DMZ into the secure part of the network (the reverse is already > possible - i.e. I'm able to initiate a connection from the secure part of > the network into the DMZ). > > Are there any books/tutorials/web sites/consultants that could help me or do > I just need to start reading the Java source codes that I've downloaded? > > Any help would be much appreciated. I'm looking for any jump start I can > get. :-) > > Thanks, > Dale > > Dale Ander > Senior Software Architect > Sterling Commerce, Inc. > Research and Advanced Technology Group > dale_ander@stercomm.com > (469) 524-2603 > > > > _______________________________________________ > BXXPwg mailing list > BXXPwg@lists.invisible.net > http://lists.invisible.net/mailman/listinfo/bxxpwg > _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jul 17 14:24:26 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09844 for ; Tue, 17 Jul 2001 14:24:25 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA15243; Tue, 17 Jul 2001 11:21:54 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id KAA14653; Tue, 17 Jul 2001 10:18:30 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23758; Tue, 17 Jul 2001 13:16:53 -0400 (EDT) Message-Id: <200107171716.NAA23758@ietf.org> From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Date: Tue, 17 Jul 2001 13:16:53 -0400 Subject: [BXXPwg] Note Well Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jul 17 14:26:03 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10135 for ; Tue, 17 Jul 2001 14:26:02 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA15291; Tue, 17 Jul 2001 11:24:01 -0700 (PDT) Received: from roam.psg.com (H-135-207-10-122.research.att.com [135.207.10.122]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id KAA14749; Tue, 17 Jul 2001 10:26:21 -0700 (PDT) Received: from randy by roam.psg.com with local (Exim 3.30 #1) id 15MYb7-0000LK-00; Tue, 17 Jul 2001 13:25:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rsent-To: eos@ops.ietf.org From: The IESG To: AAA Working Group , ACAP Working Group , ADSLMIB Working Group , AFT Working Group , AGENTX Working Group , APEX Working Group , ATOMMIB Working Group , AVT Working Group , BEEP Working Group , BGMP Working Group , BMWG Working Group , BRIDGE Working Group , CALSCH Working Group , CAT Working Group , CCAMP Working Group , CNRP Working Group , DELTAV Working Group , DHC Working Group , DIFFSERV Working Group , DISMAN Working Group , DNSEXT Working Group , DNSOP Working Group , ECM Working Group , EDIINT Working Group , ENTMIB Working Group , ENUM Working Group , EOS Working Group , FAX Working Group , FRNETMIB Working Group , FTPEXT Working Group , GEOPRIV Working Group , GRIP Working Group , GSMP Working Group , HUBMIB Working Group , IDMR Working Group , IDN Working Group , IDR Working Group , IDWG Working Group , IFMIB Working Group , IMAPEXT Working Group , IMPP Working Group , IPCDN Working Group , IPFC Working Group , IPNGWG Working Group , IPO Working Group , IPORPR Working Group , IPP Working Group , IPPM Working Group , IPS Working Group , IPSEC Working Group , IPSP Working Group , IPSRA Working Group , IPTEL Working Group , ISIS Working Group , ISSLL Working Group , ITRACE Working Group , KINK Working Group , KRB-WG Working Group , L2TPEXT Working Group , LDAPBIS Working Group , LDAPEXT Working Group , LDUP Working Group , MALLOC Working Group , MANET Working Group , MBONED Working Group , MEGACO Working Group , MIDCOM Working Group , MMUSIC Working Group , MOBILEIP Working Group , MPLS Working Group , MSDP Working Group , MSEC Working Group , MSGTRK Working Group , MULTI6 Working Group , NASREQ Working Group , NAT Working Group , NFSV4 Working Group , NGTRANS Working Group , NNTPEXT Working Group , OPENPGP Working Group , OSPF Working Group , OTP Working Group , PILC Working Group , PIM Working Group , PKIX Working Group , POISSON Working Group , POLICY Working Group , PPPEXT Working Group , PPVPN Working Group , PROVREG Working Group , PWE3 Working Group , RAP Working Group , RESCAP Working Group , RIP Working Group , RMONMIB Working Group , RMT Working Group , ROHC Working Group , RSERPOOL Working Group , RUN Working Group , SACRED Working Group , SEAMOBY Working Group , SECSH Working Group , SIGTRAN Working Group , SIMPLE Working Group , SIP Working Group , SMIME Working Group , SMING Working Group , SNMPCONF Working Group , SNMPV3 Working Group , SPIRITS Working Group , SSM Working Group , STIME Working Group , SYSLOG Working Group , TEWG Working Group , TLS Working Group , TN3270E Working Group , TRADE Working Group , TSVWG Working Group , UDLR Working Group , URN Working Group , USEFOR Working Group , USWG Working Group , VPIM Working Group , VRRP Working Group , WEBDAV Working Group , WEBI Working Group , WTS Working Group , XMLDSIG Working Group , ZEROCONF Working Group cc: iesg@ietf.org Message-Id: Date: Tue, 17 Jul 2001 13:25:25 -0400 Subject: [BXXPwg] Note Well Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit Greetings, This is the revised text of the NOTE WELL statement. ------------------------------------------------------ NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to: - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jul 17 19:22:57 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09437 for ; Tue, 17 Jul 2001 19:22:57 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id QAA16805; Tue, 17 Jul 2001 16:15:06 -0700 (PDT) Received: from omx1.csg.stercomm.com (omx1.csg.stercomm.com [207.43.171.9]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id QAA16792 for ; Tue, 17 Jul 2001 16:15:05 -0700 (PDT) Received: from scidalmsg01.csg.stercomm.com (scidalmsg01.csg.stercomm.com [10.20.32.29]) by omx1.csg.stercomm.com with ESMTP id SAA15804 for ; Tue, 17 Jul 2001 18:12:10 -0500 (CDT) Received: by scidalmsg01.csg.stercomm.com with Internet Mail Service (5.5.2653.19) id <30TDZKAT>; Tue, 17 Jul 2001 18:15:05 -0500 Message-ID: <40AC2C8FB855D411AE0200D0B7458B2B045859BE@scidalmsg01.csg.stercomm.com> From: "Ander, Dale" To: "Beep (E-mail)" Date: Tue, 17 Jul 2001 18:15:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [BXXPwg] Ran Beepd got error TLS algorithm not found Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net I managed to build Beepd and Bing in the example directory (beepcore-0.9.06\example\org\beepcore\beep\example) today but am still having problems. Details follow. The first time I ran Beepd I got a NoClassDefFoundError for javax/net/ssl/HandshakeCompletedListener. I downloaded the jsee-1.0.2-do.zip file off Sun's web site next under the assumption it had the classes I needed to run Beepd and attempted to install it per Sun's directions (I may or may not have done it right). I wasn't exactly sure what to do but I have an environment variable named JAVA_HOME and it's set to C:\JDK1.3.0_02 in my autoexec.bat file so I put the Jar files jcert, jnet, and jsse, in the directory c:\JDK1.3.0_02\jre\lib\ext. I also edited the java.security file in c:\JDK1.3.0_02\jre\lib\security and added a line that looks like: security.provider.3=com.sun.net.ssl.internal.ssl.Provider Per my interpretation of the installation instructions. Note there were already two other lines there that looked like: security.provider.1=sun.security.provider.Sun security.provider.2=com.sun.rsajca.Provider And finally, I updated my autoexec.bat file (I'm doing all this on a Windows 98 system) to include jcert.jar, jnet.jar, and jsse.jar in my class path (wasn't sure if I needed all three but ...) and then I restarted my system (not completely necessary but that way I was sure my classpath would be set "correctly" when I started my DOS boxes from then on). Now when I run Beepd I get a different message. I get one that says: TSL algorithm not found. Probable cause is the JSSE provider has not been added to the java security file. Now I'm not sure what to do so I'm posting this note in the hopes of getting some help while I keep plugging away. Thanks in advance, Dale Dale Ander Senior Software Architect Sterling Commerce, Inc. Research and Advanced Technology Group dale_ander@stercomm.com (469) 524-2603 _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Tue Jul 17 19:42:37 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13316 for ; Tue, 17 Jul 2001 19:42:36 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id QAA16908; Tue, 17 Jul 2001 16:34:57 -0700 (PDT) Received: from xomi.pair.com (xomi.pair.com [209.68.2.14]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with SMTP id QAA16893 for ; Tue, 17 Jul 2001 16:34:56 -0700 (PDT) Received: (qmail 7858 invoked by uid 3039); 17 Jul 2001 23:34:51 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 17 Jul 2001 23:34:51 -0000 Date: Tue, 17 Jul 2001 16:34:51 -0700 (PDT) From: Gabe Wachob X-Sender: To: "Ander, Dale" cc: "Beep (E-mail)" Subject: Re: [BXXPwg] Ran Beepd got error TLS algorithm not found In-Reply-To: <40AC2C8FB855D411AE0200D0B7458B2B045859BE@scidalmsg01.csg.stercomm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net One solution is to use the beta jdk1.4 which includes all the security stuff already for you. This may not be an option, but it certainly is a quick way to solve the problem. The problems you are having sound like generic JSSE install problems. Have you tried running anything else requiring JSSE? -Gabe On Tue, 17 Jul 2001, Ander, Dale wrote: > I managed to build Beepd and Bing in the example directory > (beepcore-0.9.06\example\org\beepcore\beep\example) today but am still > having problems. Details follow. > > The first time I ran Beepd I got a NoClassDefFoundError for > javax/net/ssl/HandshakeCompletedListener. > > I downloaded the jsee-1.0.2-do.zip file off Sun's web site next under the > assumption it had the classes I needed to run Beepd and attempted to install > it per Sun's directions (I may or may not have done it right). I wasn't > exactly sure what to do but I have an environment variable named JAVA_HOME > and it's set to C:\JDK1.3.0_02 in my autoexec.bat file so I put the Jar > files jcert, jnet, and jsse, in the directory c:\JDK1.3.0_02\jre\lib\ext. > > I also edited the java.security file in c:\JDK1.3.0_02\jre\lib\security and > added a line that looks like: > security.provider.3=com.sun.net.ssl.internal.ssl.Provider > Per my interpretation of the installation instructions. Note there were > already two other lines there that looked like: > security.provider.1=sun.security.provider.Sun > security.provider.2=com.sun.rsajca.Provider > > > And finally, I updated my autoexec.bat file (I'm doing all this on a Windows > 98 system) to include jcert.jar, jnet.jar, and jsse.jar in my class path > (wasn't sure if I needed all three but ...) and then I restarted my system > (not completely necessary but that way I was sure my classpath would be set > "correctly" when I started my DOS boxes from then on). > > Now when I run Beepd I get a different message. I get one that says: > TSL algorithm not found. Probable cause is the JSSE provider has not been > added to the java security file. > > Now I'm not sure what to do so I'm posting this note in the hopes of getting > some help while I keep plugging away. > > Thanks in advance, > Dale > > > > Dale Ander > Senior Software Architect > Sterling Commerce, Inc. > Research and Advanced Technology Group > dale_ander@stercomm.com > (469) 524-2603 > > > _______________________________________________ > BXXPwg mailing list > BXXPwg@lists.invisible.net > http://lists.invisible.net/mailman/listinfo/bxxpwg > _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Wed Jul 18 12:12:18 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02770 for ; Wed, 18 Jul 2001 12:12:17 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA20516; Wed, 18 Jul 2001 09:11:11 -0700 (PDT) Received: from mailsys01.intnet.net (antares.IntNet.net [198.252.32.143]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA20500 for ; Wed, 18 Jul 2001 09:11:10 -0700 (PDT) Received: from [63.236.58.70] (HELO borwankar.com) by mailsys01.intnet.net (CommuniGate Pro SMTP 3.3.2) with ESMTP id 11612300 for bxxpwg@lists.invisibleworlds.com; Wed, 18 Jul 2001 12:09:46 -0400 Message-ID: <3B55B383.FEF2967@borwankar.com> Date: Wed, 18 Jul 2001 09:04:20 -0700 From: Nitin Borwankar X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: "Beep (E-mail)" Subject: Re: [BXXPwg] Ran Beepd got error TLS algorithm not found References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit Hi Dale, I had exactly the same problems so I removed the TLS profile entry in the config file and I was able to get Beepd running and was able to telnet to it. I still haven't managed to get it running in TLS mode, and have kept it aside. I'll try the jdk1.4 approach in a few days to see if it works. Thanks Gabe. -- Nitin Borwankar Gabe Wachob wrote: > > One solution is to use the beta jdk1.4 which includes all the security > stuff already for you. This may not be an option, but it certainly is a > quick way to solve the problem. > > The problems you are having sound like generic JSSE install problems. Have > you tried running anything else requiring JSSE? > > -Gabe > > On Tue, 17 Jul 2001, Ander, Dale wrote: > > > I managed to build Beepd and Bing in the example directory > > (beepcore-0.9.06\example\org\beepcore\beep\example) today but am still > > having problems. Details follow. > > > > The first time I ran Beepd I got a NoClassDefFoundError for > > javax/net/ssl/HandshakeCompletedListener. > > > > I downloaded the jsee-1.0.2-do.zip file off Sun's web site next under the > > assumption it had the classes I needed to run Beepd and attempted to install > > it per Sun's directions (I may or may not have done it right). I wasn't > > exactly sure what to do but I have an environment variable named JAVA_HOME > > and it's set to C:\JDK1.3.0_02 in my autoexec.bat file so I put the Jar > > files jcert, jnet, and jsse, in the directory c:\JDK1.3.0_02\jre\lib\ext. > > > > I also edited the java.security file in c:\JDK1.3.0_02\jre\lib\security and > > added a line that looks like: > > security.provider.3=com.sun.net.ssl.internal.ssl.Provider > > Per my interpretation of the installation instructions. Note there were > > already two other lines there that looked like: > > security.provider.1=sun.security.provider.Sun > > security.provider.2=com.sun.rsajca.Provider > > > > > > And finally, I updated my autoexec.bat file (I'm doing all this on a Windows > > 98 system) to include jcert.jar, jnet.jar, and jsse.jar in my class path > > (wasn't sure if I needed all three but ...) and then I restarted my system > > (not completely necessary but that way I was sure my classpath would be set > > "correctly" when I started my DOS boxes from then on). > > > > Now when I run Beepd I get a different message. I get one that says: > > TSL algorithm not found. Probable cause is the JSSE provider has not been > > added to the java security file. > > > > Now I'm not sure what to do so I'm posting this note in the hopes of getting > > some help while I keep plugging away. > > > > Thanks in advance, > > Dale > > > > > > > > Dale Ander > > Senior Software Architect > > Sterling Commerce, Inc. > > Research and Advanced Technology Group > > dale_ander@stercomm.com > > (469) 524-2603 > > > > > > _______________________________________________ > > BXXPwg mailing list > > BXXPwg@lists.invisible.net > > http://lists.invisible.net/mailman/listinfo/bxxpwg > > > > _______________________________________________ > BXXPwg mailing list > BXXPwg@lists.invisible.net > http://lists.invisible.net/mailman/listinfo/bxxpwg _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Wed Jul 18 14:57:08 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA04678 for ; Wed, 18 Jul 2001 14:57:07 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA21498; Wed, 18 Jul 2001 11:49:10 -0700 (PDT) Received: from omx1.csg.stercomm.com (omx1.csg.stercomm.com [207.43.171.9]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id LAA21480 for ; Wed, 18 Jul 2001 11:49:09 -0700 (PDT) Received: from scidalmsg01.csg.stercomm.com (scidalmsg01.csg.stercomm.com [10.20.32.29]) by omx1.csg.stercomm.com with ESMTP id NAA05558; Wed, 18 Jul 2001 13:45:37 -0500 (CDT) Received: by scidalmsg01.csg.stercomm.com with Internet Mail Service (5.5.2653.19) id <30TDZ3XX>; Wed, 18 Jul 2001 13:48:33 -0500 Message-ID: <40AC2C8FB855D411AE0200D0B7458B2B045859C9@scidalmsg01.csg.stercomm.com> From: "Ander, Dale" To: "'nitin@borwankar.com'" Cc: "Beep (E-mail)" Subject: Re: [BXXPwg] Ran Beepd got error TLS algorithm not found Date: Wed, 18 Jul 2001 13:48:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net I got Bing talking to Beepd without going to the 1.4 Jdk earlier today. I had put the jcert, jnet, and jsse Jar files where they belong and updated the java.security file in my c:\jdk1.3.0_02\jre\lib\security directory but I needed to edit the java.security file in my c:\Program Files\JavaSoft\JRE\1.3.0_02\lib\security directory as that's where the software was looking at runtime I was told by someone more familiar with Java than myself. I also made a copy of the Jar files and put them in my c:\Program Files\JavaSoft\JRE\1.3.0_02\lib\ext directory just for good measure. Dale Ander Senior Software Architect Sterling Commerce, Inc. Research and Advanced Technology Group dale_ander@stercomm.com (469) 524-2603 _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Wed Jul 18 18:07:38 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17275 for ; Wed, 18 Jul 2001 18:07:37 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA22774; Wed, 18 Jul 2001 14:59:29 -0700 (PDT) Received: from c007.snv.cp.net (c007-h011.c007.snv.cp.net [209.228.33.217]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with SMTP id OAA22700 for ; Wed, 18 Jul 2001 14:52:38 -0700 (PDT) Received: (cpmta 25737 invoked from network); 18 Jul 2001 14:50:48 -0700 Received: from unknown (HELO nerdsuce6asd2c) (64.209.22.2) by smtp.activebuddy.com (209.228.33.217) with SMTP; 18 Jul 2001 14:50:48 -0700 X-Sent: 18 Jul 2001 21:50:48 GMT From: "Mathieu Longtin" To: Date: Wed, 18 Jul 2001 17:50:35 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Subject: [BXXPwg] perl implementation Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit Hi, are you aware of anyone working on an implementation of BEEP over TCP? -Mathieu _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jul 19 16:53:40 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11961 for ; Thu, 19 Jul 2001 16:53:34 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA29055; Thu, 19 Jul 2001 13:52:35 -0700 (PDT) Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.89]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA28999 for ; Thu, 19 Jul 2001 13:49:12 -0700 (PDT) Received: by smtpout.mac.com; Thu, 19 Jul 2001 13:44:59 -0700 (PDT) Message-Id: <200107192044.NAA06457@smtpout.mac.com> Received: from asmtp02.mac.com ([10.13.10.66]) by smtp-relay01.mac.com (Netscape Messaging Server 4.15 relay01 Jun 21 2001 23:53:48) with ESMTP id GGQMYY00.TLQ for ; Thu, 19 Jul 2001 13:44:58 -0700 Received: from localhost ([17.206.25.144]) by asmtp02.mac.com (Netscape Messaging Server 4.15 asmtp02 Jun 6 2001 13:16:42) with ESMTP id GGQMYY00.UJY; Thu, 19 Jul 2001 13:44:58 -0700 Date: Thu, 19 Jul 2001 13:45:00 -0700 From: j h woodyatt Reply-To: jhw@wetware.com Content-Type: text/plain; format=flowed; charset=us-ascii Subject: Re: [BXXPwg] perl implementation Cc: BEEP Working Group To: "Mathieu Longtin" X-Mailer: Apple Mail (2.388) In-Reply-To: Mime-Version: 1.0 (Apple Message framework v388) Content-Transfer-Encoding: 7bit Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit On Wednesday, July 18, 2001, at 02:50 , Mathieu Longtin wrote: > > are you aware of anyone working on an implementation of BEEP over TCP? I abandoned mine about halfway through. Since Perl has neither garbage collection nor pre-emptive multi-threading, the task of writing a *complete* implementation of the BEEP core and its TCP mapping is somewhat daunting. Particularly for the listener. I figured somebody else will probably do the obvious thing: write an extension that just does BEEP initiation on a single TCP connection and does everything in a synchronous fashion. I was trying for the hard problem. Silly me. There are several competing cooperative multi-tasking programming frameworks available for Perl in the CPAN, but all of them have problems when you try to develop layered stacks of protocols like BEEP. The one I like the best is POE, but Rocco basically dropped the ball on developing a generalized model of flow control. The others seem basically aimed at enabling applications to handle mouse events. "If you want it done really right, you have to do it yourself," I thought. I got really tired of re-inventing that particular wheel in Perl. It might be easier just to code one-offs into each different Perl 5 implementation of an application protocol defined as a BEEP profile. It's the general BEEP core library extension that is hard to do in Perl, I think. Without pre-emptive multi-threading, it's pretty tough-- but without garbage collection either, it's too much bother for this little bear. I eventually gave up and decided to wait for Perl 6. Maybe there's someone else smarter than me (or less orthodox) who has already done it in Perl 5. If so, I would be delighted to hear about it. -- j h woodyatt "You're standing on sacred ground. Many strange and wonderful things have transpired right where you're standing." --unattributable _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jul 20 15:59:33 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24589 for ; Fri, 20 Jul 2001 15:59:30 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id MAA04733; Fri, 20 Jul 2001 12:58:09 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id MAA04717 for ; Fri, 20 Jul 2001 12:58:08 -0700 (PDT) Received: from localhost (bfeinste@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) with ESMTP id f6KJvnH20321 for ; Fri, 20 Jul 2001 12:57:53 -0700 Date: Fri, 20 Jul 2001 12:57:49 -0700 (PDT) From: Ben Feinstein To: bxxpwg@invisible.net Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [BXXPwg] beepcore examples probs. Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Hey ya'll, I'm having trouble getting Bing to talk to Beepd with TLS enabled. I'm using JDK 1.3.0_02. I've installed the JSSE 1.0.2 jars in $JREHOME/lib/ext and edited my $JREHOME/lib/security/java.security file, adding the line: security.provider.3=com.sun.net.ssl.internal.ssl.Provider I'm running Beepd with the example "beepd-config.xml" file. I can use Bing to talk to Beepd with "-privacy none" option, but I get the following error traces when I use privacy. (running the server) $ java org.beepcore.beep.example.Beepd -config beepd-config.xml (running Bing) $ java org.beepcore.beep.example.Bing -port 10288 -count 10 -privacy required localhost (error output from Beepd, which stays running and will continue to listen on the port) TCPSession Thread #0:TCP Mapping: org.beepcore.beep.core.BEEPException: Malformed BEEP header, EOS org.beepcore.beep.core.BEEPException: Malformed BEEP header, EOS at org.beepcore.beep.transport.tcp.TCPSession.processNextFrame(TCPSession.java:409) at org.beepcore.beep.transport.tcp.TCPSession.access$2(TCPSession.java:393) at org.beepcore.beep.transport.tcp.TCPSession$SessionThread.run(TCPSession.java:514) at java.lang.Thread.run(Thread.java:484) TCPSession Thread #0:org.beepcore.beep.core.Session.terminate: Malformed BEEP header, EOS (error output from Bing, which exits) Exception in thread "main" java.lang.NoClassDefFoundError: COM/claymoresystems/sslg/SSLContextInt at java.lang.Class.newInstance0(Native Method) at java.lang.Class.newInstance(Class.java:237) at org.beepcore.beep.profile.tls.TLSProfile.getInstance(TLSProfile.java:115) at org.beepcore.beep.profile.tls.TLSProfile.getDefaultInstance(TLSProfile.java:98) at org.beepcore.beep.example.Bing.main(Bing.java:73) Any idea what I'm doing wrong? Does someone know of a simple example program using JSSE so I could isolate whether I'm having a JSSE or a Beepcore problem? Thanks, Ben Feinstein _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Fri Jul 20 16:38:04 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11728 for ; Fri, 20 Jul 2001 16:38:03 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA04944; Fri, 20 Jul 2001 13:37:25 -0700 (PDT) Received: from petmai01.not.invisible.net (petmai01.not.invisible.net [204.62.247.27]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id NAA04928 for ; Fri, 20 Jul 2001 13:37:24 -0700 (PDT) Received: by petmai01.not.invisible.net with Internet Mail Service (5.5.2650.21) id <3ZT190ZL>; Fri, 20 Jul 2001 13:51:49 -0700 Message-ID: From: Bill Mills To: bxxpwg@invisible.net Date: Fri, 20 Jul 2001 13:51:48 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [BXXPwg] Beepcore-java-users mailing list Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net This is not intended to discourage questions from folks using BEEP and getting spun up, but I thought it might be time to remind folks that htere is a mailing list avaialble through www.sourceforge.net run through the beepcore-java project there. For your convenience the following might be of interest: beepcore-java project page: http://sourceforge.net/projects/beepcore-java/ beepcore-java mailing lists: http://sourceforge.net/mail/?group_id=24004 beepcore-java-users list: http://lists.sourceforge.net/lists/listinfo/beepcore-java-users I know at some point this mailing list will wrap up, so I wanted to provide a reference to what should be the ongoing resource. -bill _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Sat Jul 21 01:17:01 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17755 for ; Sat, 21 Jul 2001 01:17:01 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id WAA06885; Fri, 20 Jul 2001 22:16:34 -0700 (PDT) Received: from c001.snv.cp.net (c001-h001.c001.snv.cp.net [209.228.32.115]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with SMTP id WAA06838 for ; Fri, 20 Jul 2001 22:13:06 -0700 (PDT) Received: (cpmta 18842 invoked from network); 20 Jul 2001 22:12:57 -0700 Received: from wks-92-141-124.kscable.com (HELO ecathexis.com) (24.92.141.124) by smtp.ecathexis.com (209.228.32.115) with SMTP; 20 Jul 2001 22:12:57 -0700 X-Sent: 21 Jul 2001 05:12:57 GMT Message-ID: <3B5911B0.AF38740B@ecathexis.com> Date: Sat, 21 Jul 2001 00:22:56 -0500 From: Blake Courtney X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: bxxpwg@invisible.net Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [BXXPwg] List? Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit Does beepcore.org have a mailing list or newsgroup? Thanks, Blake _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jul 26 13:31:03 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23147 for ; Thu, 26 Jul 2001 13:31:01 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id KAA04359; Thu, 26 Jul 2001 10:06:33 -0700 (PDT) Received: from ns0.notenoughbandwidth.net (infrasearch [209.25.154.238] (may be forged)) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id KAA04342 for ; Thu, 26 Jul 2001 10:06:32 -0700 (PDT) Received: from thechick (office.jxta.org [63.115.99.226]) by ns0.notenoughbandwidth.net (8.11.2/8.11.2) with SMTP id f6QGxei45077; Thu, 26 Jul 2001 09:59:40 -0700 (PDT) (envelope-from jbeatty@gonesilent.com) Message-ID: <014a01c115f5$27eda0e0$250a0a0a@vrip.com> From: "john d. beatty" To: , , Cc: , References: <397E0659AA2DD411843500508B64F1CE0287DC9E@USBOSMX01> Date: Thu, 26 Jul 2001 10:05:22 -0700 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [BXXPwg] Re: TUNNEL status? Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Content-Transfer-Encoding: 7bit After having offline discussions with Darren, my conclusion is that we should probably not include the "session brokering" functionality in the TUNNEL profile for the following reasons: - I was unable to make a persuasive argument (even to myself) that this was the right approach. - The session brokering functionality is only necessary in a small number of cases. In general, asynch message relaying can be used to communicate to peers lacking reachability due to firewalls and NATs. - It opens up a new set of security concerns. There are still cases where I would like to have direct-as-possible sessions created in the single and double NAT/firewall cases, but I believe there are viable alternatives and that this functionality would convolute and overload the TUNNEL profile. john ----- Original Message ----- From: To: ; Cc: ; ; Sent: Thursday, July 26, 2001 9:42 AM Subject: TUNNEL status? > Hey ya'll, > > So, what was the resolution on this issue? Are we extending the TUNNEL > profile and, if so, where is the updated ID? We're close to releasing > IDXP-03 and putting it into WG Last Call. We need to have the TUNNEL ID > ready for last call at the same time, seeing as IDXP references TUNNEL and > my understanding is that RFCs cannot reference IDs. > > Cheers, > Ben > > PS - Sorry about the last message containing only the quoted reply to > Marshall's email. I accidentally sent it out before it was ready! > > On Mon, 16 Jul 2001, Marshall T. Rose wrote: > > > hi. i suggest that the two of you have a private conversation as to what > > minimal sets of mods to the tunnel profile are necessary to meet john's > > requirements, and then you can send a note to the idwg mailing list > > explaining what you want to do. > > > > time is of the essence here, that wg would like to be closing up shop > > soon... > > > > thanks, > > > > /mtr > > > > > Ben Feinstein > > Software Development Engineer, R & D > > W: 404.460.5193 F: 404.460.5001 M: 678.772.4126 > > 3003 Summit Blvd., Suite 1500, Atlanta, GA 30319 www.guardent.com > > _____________________________________________________ > > G U A R D E N T > > Enterprise Security and Privacy Programs > _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jul 26 17:51:29 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15726 for ; Thu, 26 Jul 2001 17:51:28 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA05636; Thu, 26 Jul 2001 14:50:48 -0700 (PDT) Received: from usbosmx01.guardent.com ([208.9.212.220]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA04203 for ; Thu, 26 Jul 2001 09:42:45 -0700 (PDT) From: Benjamin.Feinstein@guardent.com Received: by USBOSMX01 with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 12:42:40 -0400 Message-ID: <397E0659AA2DD411843500508B64F1CE0287DC9E@USBOSMX01> To: bxxpwg@invisible.net, idwg-public@zurich.ibm.com Cc: mrose+mtr.netnews@dbc.mtview.ca.us, jbeatty@gonesilent.com, dnew@san.rr.com Date: Thu, 26 Jul 2001 12:42:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [BXXPwg] TUNNEL status? Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net Hey ya'll, So, what was the resolution on this issue? Are we extending the TUNNEL profile and, if so, where is the updated ID? We're close to releasing IDXP-03 and putting it into WG Last Call. We need to have the TUNNEL ID ready for last call at the same time, seeing as IDXP references TUNNEL and my understanding is that RFCs cannot reference IDs. Cheers, Ben PS - Sorry about the last message containing only the quoted reply to Marshall's email. I accidentally sent it out before it was ready! On Mon, 16 Jul 2001, Marshall T. Rose wrote: > hi. i suggest that the two of you have a private conversation as to what > minimal sets of mods to the tunnel profile are necessary to meet john's > requirements, and then you can send a note to the idwg mailing list > explaining what you want to do. > > time is of the essence here, that wg would like to be closing up shop > soon... > > thanks, > > /mtr > > Ben Feinstein > Software Development Engineer, R & D > W: 404.460.5193 F: 404.460.5001 M: 678.772.4126 > 3003 Summit Blvd., Suite 1500, Atlanta, GA 30319 www.guardent.com > _____________________________________________________ > G U A R D E N T > Enterprise Security and Privacy Programs _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg From bxxpwg-admin@lists.invisibleworlds.com Thu Jul 26 18:41:16 2001 Received: from trystero.not.invisible.net (trystero.not.invisible.net [204.62.247.11]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15727 for ; Thu, 26 Jul 2001 17:51:28 -0400 (EDT) Received: from trystero.not.invisible.net (localhost [127.0.0.1]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id OAA05660; Thu, 26 Jul 2001 14:50:48 -0700 (PDT) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by trystero.not.invisible.net (8.9.3+Sun/8.9.3) with ESMTP id JAA04166 for ; Thu, 26 Jul 2001 09:40:15 -0700 (PDT) Received: from localhost (bfeinste@localhost) by odin.ac.hmc.edu (8.11.0/8.11.0) with ESMTP id f6QGdsK31736; Thu, 26 Jul 2001 09:39:54 -0700 X-Authentication-Warning: odin.ac.hmc.edu: bfeinste owned process doing -bs Date: Thu, 26 Jul 2001 09:39:54 -0700 (PDT) From: Ben Feinstein X-Sender: bfeinste@odin.ac.hmc.edu To: "Marshall T. Rose" cc: "john d. beatty" , Darren New , bxxpwg@invisible.net, Marshall Rose Subject: Re: [BXXPwg] BEEP "Session Broker" Profile: Necessary and Useful? In-Reply-To: <00d901c10e22$b37dfd60$8753cf3f@FATORA> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: bxxpwg-admin@lists.invisibleworlds.com Errors-To: bxxpwg-admin@lists.invisibleworlds.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: Mailing list for the IETF's BEEP Working Group X-BeenThere: bxxpwg@lists.invisible.net On Mon, 16 Jul 2001, Marshall T. Rose wrote: > hi. i suggest that the two of you have a private conversation as to what > minimal sets of mods to the tunnel profile are necessary to meet john's > requirements, and then you can send a note to the idwg mailing list > explaining what you want to do. > > time is of the essence here, that wg would like to be closing up shop > soon... > <> thanks, > > /mtr > > > > _______________________________________________ > BXXPwg mailing list > BXXPwg@lists.invisible.net > http://lists.invisible.net/mailman/listinfo/bxxpwg > _______________________________________________ BXXPwg mailing list BXXPwg@lists.invisible.net http://lists.invisible.net/mailman/listinfo/bxxpwg