Invitation to Network Providers

Wed Mar 9 16:40:05 UTC 1994

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 at calsoft.com>
To: frode.greisen at 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 at 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 at netcom.com
CSMail=support at netcom.com
VoicePhone=4085548717

[Software]
Provider=CSI
CSMail=support at 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