This may be of interest to some of the folks on this list. I received the copy of this message from Frode Greisen. If you are interested in pursuing this, please contact Bill Baker directly. If not just toss it and move on. --Elise -------------------------forwarded message------------------ Date: Sat, 5 Feb 94 11:51:02 PST From: Bill Baker <bbaker@calsoft.com> To: frode.greisen@uni-c.dk Subject: Network Providers Proposal Frode Greisen European Backbone Network Dear Frode, Let me introduce myself. My name is Bill Baker and I'm president of California Software. For the last year, our company has been developing a Microsoft Windows based InterNet product. Over the course of developing this product several issues concerning Network Providers have arisen. Enclosed is a proposal that I would like to discuss with you or whomever in you organization you feel would be appropriate. It is California Software's desire to create a relationship with a number of network providers and work toward an industry standard that might ease the difficulties related to configuring dial up SLIP or PPP connection into the Internet. We are in full development at this time on a comprehensive software program that we hope will provide the most up to date multi-media communication products as well as being truly "plug and play". I look forward to discussing this further with you and your staff. You may contact me directly by phone or electronically at bbaker@calsoft.com Sincerely, Bill Baker, President California Software, Inc. 2121 East Pacific Coast Hwy. Suite 120C Corona del Mar, California 92625 714-729-4224 USA ___________________________________________________________________ A Solution for Network Providers Standards Today there are many companies working on PC products for Internet connectivity. These same products are also being developed for a variety of other platforms, by both network providers and by independent software vendors (ISVs). Various approaches are being taken in developing these products. At one end of the spectrum, legacy networks like CompuServe and AOL are basing their Internet services on mainframe-based application relays which will give existing users access to conventional Internet services like Archie and Gopher. Internet-centric network providers and ISVs such as NetManage, Spry, and California Software, are working on software that provides "full membership" in the Internet by providing the end user with a TCP/IP link for unlimited access to a variety of services and protocols. We believe that in the long run, this "full membership" Internet access will prevail to become the dominant method for Internet access. Today there are two major technical barriers to "full membership" Internet connection. First is the lack of robustness of the SLIP protocol. PPP is much improved. Second is the extraordinary difficulty, for the typical user, of configuring and bringing up either a SLIP or PPP connection. The question is, can PC software be designed which will effortlessly connect a user to any network provider and provide full Internet connectivity without the personal involvement of the network provider's support staff? We have observed users attempting to bring up SLIP and PPP connections with off-the-shelf networking products and have concluded that using current methods such connections will almost always fail on the first attempt. This usually results in support calls to the network provider, the software vendor, or both. If automatic-configuring software existed the technical support for both the network provider as well as the creator of the software would be drastically reduced. There is no argument that the majority of all technical support efforts which are a direct expense to either the software developer or network provider occur in the first few hours of operation. With this in mind California Software Inc. (CSI) is building into its product automatic configuration code to deal with this issue. With the cooperative effort of both the network provider and software suppliers like CSI, we believe significant savings can be realized. Technical support workloads will be reduced, but more importantly both companies will have satisfied customers and will be looked at as industry leaders with the most advanced products that are useful for users at every level. Difficulty There are two significant stumbling blocks to configuring and managing a SLIP/PPP connection. When a user subscribes to a provider's emulator service, he has only three parameters to manage: the POP telephone number, his User ID, and his Password. The user attempting to bring up a SLIP/PPP connection must manage these three parameters plus at least ten others including Internet addresses for himself, a gateway, an SMTP server, domain name servers, and NNTP servers. Depending on the service, he may also have additional User ID's, passwords, and telephone numbers to cope with. Making matters worse, the establishment of a SLIP/PPP connection requires a negotiated dialog between the user's PC and the service provider's POP controller. This is not standardized and varies from provider to provider. A connection script that works must be tailored to the specific provider. Because of this complexity, the probability of a SLIP/PPP connection working the first time approaches zero. We have never seen such a connection work on its initial attempt. This is guaranteed to be a trying experience for the user and a very expensive customer support challenge for the network provider. Proposed Solution California Software's new product line will incorporate several facilities specifically for simplifying TCP/IP and SLIP/PPP configuration and management. This section describes these. 1. Central Network Data Repository In many competitive products we find that a particular network parameter may appear many times in different places. Typically each network sub-application has a configuration panel in which the user is required to enter his IP address, a target IP address such as the service's SMTP server, and the ever mysterious "subnet mask". CSI's program will have only one place in which this information is stored for all of its sub-applications in a local SLIP.INI file. 2. Parsable SLIP/PPP Parameter List When a user orders a SLIP or PPP connection from a network provider today, he receives a list of 10 to 15 parameters needed for the connection from the provider's network operations center (NOC). This can be in the form of a telephone call, or more typically, embedded in a computer-generated e-mail letter sent to the user's emulator account. The user must understand the meaning of the parameters, find out where they need to be put, and accurately hand copy the numeric IP addresses and other items into his network software. He must obtain all this information typically using a very unfriendly UNIX mail application. We intend to work with Internet network providers to encourage them to adopt an easily parsed standard SLIP.INI document. After a customer orders a SLIP or PPP connection the SLIP.INI document can be placed in the root of his emulator account (this avoids sending user ID's and passwords via e-mail). Our program's automatic configuration process will extract information from the SLIP.INI document to use in configuring the SLIP/PPP connection without user intervention. A copy of a proposed format for the service provider's SLIP.INI file is included as an attachment to this document. Putting the SLIP/PPP access parameters into the proposed SLIP.INI format is a small task (a few hours) for the majority of network providers, who already computer-generate e-mail containing this same information in a form letter. We will supply a parsing macro to extract information from the proposed SLIP.INI format. For those network providers who are not willing to adopt this format we will write parsers to extract configuration information from their e-mail SLIP/PPP letters, but this procedure is open to risk because our automated configuration procedure may fail if a network provider changes the format of its standard letter. 3. Automatic Configuration Once the network parameters are obtained by reading a SLIP.INI document, parsing an e-mail message, or entered by hand into a single dialog box, CSI's software will automatically configure the system. This configuration process includes updating the user's local SLIP.INI file with the new network parameters and propagating parameters to the program's sub-applications as needed. The software program will also obtain, or alternatively ask for, the name of the network provider and/or the brand of the communications server used at the network provider's POP (typically CISCO, Livingston, Emulex, or other hardware). This will enable CSI's program to construct the brief but critical connect-time SLIP/PPP negotiation macro used for initializing the network connection and in some cases, for obtaining the user's dynamic IP address assigned at connect time by some network providers. 4. 911 Log CSI's products incorporate a 911 log which is a running log of warning and error messages which are produced by the program, and which can be used for remote diagnosis purposes. The log is a repository for all of the program's error messages. It is designed as a LIFO stack that can be interrogated remotely by technical support. 5. Network Provider Log in Selection Network providers that are willing to participate with CSI and adhere to a workable standard will be integrated into the automatic software setup process. Customers who do not currently have a network provider or who need to choose a provider will be given at installation time the opportunity to choose service from the CSI's list of "cooperating" providers. This process will probably work from a zip code search, which will make available on screen those providers that have point of presence within local calling distance of the customer. We believe that by incorporating these techniques we will be able to significantly increase the chances the user will be able to establish a SLIP/PPP connection without the need for expensive, professional assistance. The reduction of support costs to the network provider supplies the necessary quid quo pro for adopting the standard SLIP.INI format, as well as for an open standard to be used by other network software vendors. Following is an example of a proposed format and contents for a service provider's SLIP.INI document. Network Providers' SLIP.INI Format Example [Service] Provider=NETCOM NOCMail=noc@netcom.com CSMail=support@netcom.com VoicePhone=4085548717 [Software] Provider=CSI CSMail=support@calsoft.com VoicePhone=7147294223 FAXLine=7146446277 [Dial IP] Protocol=PPP Compression=yes DynamicIP=no DefaultDomainName=smerz.slip.netcom.com UserID=Smerz Password=adioW34 IPAddress=192.187.11.4 PhoneNumber=4083388765 MaxSpeed=14.4 DefaultGatewayIP=192.187.54.56 POPNode="Livingston 2000" CustomDomainName=slg.com [Emulator IP] ConnectionType=VT100 UserID=merz Password=atrn65grB PhoneNumber=4083386432,7148760034 MaxSpeed=9.6 BinXfrMode=zmodem [POP3] DomainName=netcom.com IPAddress=192.100.81.105 [SMTP] DomainName=netcom.com IPAddress=192.100.81.105 [NNTP] DomainName=nntp.netcom.com IPAddress=192.100.81.105 [DNS] IPAddress=192.100.81.101,192.100.81.101