You are currently viewing a snapshot of taken on April 21, 2008. Most of this content is highly out of date (some pages haven't been updated since the project began in 1998) and exists for historical purposes only. If there are any pages on this archive site that you think should be added back to, please file a bug.

Notice: This document currently describes the 4.x protocol and configurations. The changes for 5.0 have not been incorporated (or identified) yet.

Guide to Online Internet Account Creation

Netscape Communicator 4.0

Milan 4.0 Client - Server


Netscape provides this document solely as additional information. No technical support obligation is implied. A sample Internet account server can be found on the Mission Control CD. This software is supplied by Solect Technology. This document simply contains advice about the generic account-creation process, based on internal experience with the Netscape Communicator Dial-Up Edition and Netscape's own Internet Account Server. This information is subject to change at any time and without prior notice. If you are unable to implement an account server application, your options are limited to those available through the Dial-Up Edition itself as documented in the Netscape Mission Control Guide.

© 1996, 1997 Netscape Communications Corporation
All Rights Reserved.

Netscape Communications, Netscape, Netscape Navigator, Netscape Communicator,
and the Netscape Communications logo are trademarks
of Netscape Communications Corporation.

All other brand and product names mentioned herein
are trademarks or registered trademarks
of their respective owners.


This document describes the generic interaction between Netscape Navigator (the client) and an Internet account server during the online account creation process. You can also find described here specific client-to-server (request) and server-to-client (reply) protocols available to support this process. For more information about the client side of the account creation process, see the Netscape Mission Control Guide.

Purpose of This Document

You can use this document to help you plan and build a custom online account creation process for your Internet service customers and to help you acquire subscribers for your access services.

What This Document Doesn't Cover

This document doesn't explain how to customize the client, nor does it cover how to create or implement a server-side account creation application.

See the Netscape Mission Control Guide for information about customizing the account creation process on the client. The Dial-Up Edition documentation offers specific information you can use to customize the client to interact with your account-creation application.


The purpose of an Internet account server is to receive customer information, create a new service account based on that information, and to configure the client for access by sending the necessary new account configuration information back to the client.

Ordinarily, Netscape Communicator Dial-Up Edition users have two paths they can take during installation: "create an account online" or "create an account offline." This document advises ISPs who want to offer users an online, direct path to an account creation server of their own design.

The standard Netscape Communicator Dial-Up Edition package includes three components with which users interact:

    • The Installation Program
    • Account Setup
    • Netscape Navigator

The Installation Program installs Account Setup and Netscape Communicator. After installation, the user runs Account Setup to establish an account with an Internet Service Provider - in this case, your service.

Account Setup guides the user through the information-collection and server-contact processes. It leverages information you've pre-configured in the ACCTSET.INI, SAMPLE.IAS, and REGISTER.HTM files. These steps include running the dialer and Account Setup and establishing a PPP connection to your server for account creation.

Netscape Navigator passes the user's registration data to your account-server application (as an HTTP or HTTPS POST Request). The account server processes this data as appropriate, and walks the user through your registration screens, which usually includes creating a user account and packaging the final configuration information necessary to connect this client to your service. The overall flow of information is as follows:

Navigator is started with a special flag, forcing it into kiosk mode. (On the Macintosh platform, an Apple Event is used to accomplish this.) A user goes through the screens which collect data and set up the modem. Navigator connects to the server and passes along the information collected plus the contents of the REGISTER.HTM file.

Note: Some information is overwritten by the client regardless of the content of the REGISTER.HTM file. These fields are located in the values set by JavaScript section of REGISTER.HTM.

The server sends back any forms necessary to account creation and finishes by sending back a MIME stream as described below. When all of this is completed successfully, Account Setup will catch the MIME stream, interpret it, and configure the dialer and TCP/IP software for connecting to your service based on the information returned from the server. A copy of the MIME stream information is stored in ACCTINFO.TXT in the new profile directory.

Process and protocols

Here's the generic account-creation process in more detail. The available creation protocols appear with the steps they support.

Overview of Account Creation & Configuration

The following steps must occur for a successful installation and account creation/configuration:

  1. User runs installation program
  2. User runs Account Setup
  3. Account Setup collects account data
    • from forms presented to the user
    • from the SAMPLE.IAS file
    • from the REGISTER.HTM file
    • some values are reserved to Account Setup
  4. Account Setup dials the ISP's account server
  5. Navigator passes the account data to the server
    • Account Setup sends a form POST to the ISP's RegCGI URL containing all of the collected data.
  6. The ISP's server passes configuration data back to Navigator
    • The ISP server gets control of a frame to display any forms needed in the server's registration process.
  7. ISP configuration data is returned
    • When all data is collected and the account is successfully created, the ISP server returns the MIME encoded data.
  8. Account Setup puts configuration data in local files
    • Account Setup intercepts the MIME stream, configures the computer and finishes up.

Process: User Runs Installation Program

The user runs the Install program from a CD or from Disk 1 of the Netscape Communicator installation diskettes. The installer places all of the necessary files on the user's hard disk.

Process: User Runs Account Setup

The user starts Account Setup which runs inside Navigator.

Note: You must test Account Setup using the exact customized version of the client that you intend to distribute to customers.

Process: Account Setup Collects Account Data

Account Setup gathers the user's information.

Protocol: Essential Account Data

There are two possible sources for the initial package of customer data that passes from client to server. The first is REGISTER.HTM. In REGISTER.HTM, there are two types of values - those that can be overwritten and those that can't. The values that can be overwritten are set by JavaScript. The values that can't be overwritten are set by changing the VALUE item.

The second source of customer data that passes from client to server is done so by the client's HTTP header.

Values set by JavaScript in REGISTER.HTM

Data Element Data Element Name Type Length Accepted Values
Last Name (See Note 1) CST_LAST_NAME String 30 Free form, not null
First Name (See Note 1) CST_FIRST_NAME String 30 Free form, not null
Organization Name CST_ORGANIZATION_NAME String 30 Free form
Address, Line 1 CST_STREET_1 String 30 Free form, not null
Address, Line 2 CST_STREET_2 String 30 Free form
City CST_CITY String 20 Free form, not null
State or Province CST_STATE_PROVINCE String 10 Free form, not null
Postal Code CST_POSTAL_CODE String 10 Free form, not null
Country CST_COUNTRY String 30 Free form, not null
Phone (see Note 2) CST_PHONE String 25 TAPI canonical form, not null
Credit Card Number CST_CC_NO String 25 Credit card number (digits,spaces,dashes)
Credit Card Type CST_CC_TYPE String 2 MC=MasterCard, VI=VISA, AX=American Express, DC=Discover Card
Expiration Month CST_CC_MTH_EXPIRE String 2 01-12
Expiration Year CST_CC_YEAR_EXPIRE String 2 00-99
Name on Card CST_CC_CARDHOLDER String 30 Free form, not null
Can we share your information with other vendors? CST_JUNK_MAIL String 3 YES, NO

Further explanation for the columns above:

  • Data Element - Describes the data element collected.
  • Data Element Name - The name of the element as it will be used by CGI scripts, HTML forms, INI files, and customer database fields.
  • Type - The type of data contained in the element, as it corresponds to database table definitions.
  • Length - The byte length of the data element as it corresponds to database table definitions and validation.
  • Accepted Values - The format or valid contents for the data element.

Note 1: Since Account Setup Wizard asks for first and last names together in one field, you can have your Internet account server double check the CST_FIRST_NAME field whenever the CST_LAST_NAME field is missing. If there are two names there, then reparse the CST_FIRST_NAME.

Note 2: TAPI canonical form is defined as "+CountryCode Space [(AreaCode) Space] Subscriber Number." Subscriber Number can include periods (.), spaces ( ), and dashes (-). For example, Netscape's receptionist is +1 (415) 254-1900.

URL Escaping

All of the data element values passed between the client and the account server are encoded according to RFC 1738 -- Universal Resource Locators (URLs).

Values set by changing the VALUE item in REGISTER.HTM

Data Element Data Element Name Type Length Accepted Values
Account Setup Version REG_SIGNUP_VERSION String 30 Version of the sign-up application.
Distribution Name (see Note 3) REG_SOURCE String 30 Distribution name. Element only included if not null.
OS Platform of Client (see Note 1) REG_PLATFORM String 30 Platform identifier (i.e., WIN31 or WIN95). Element only included if not null.
Distribution ID (See Note 3) REG_CHANNEL String 30 A distribution identification string passed through to ISP.
PPP Login Scripting Supported by Client? REG_SCRIPTING String 3 YES, NO
Name for Account Setup program on client (See Note 4) REG_SETUP_NAME String 30 This can be anything the ISP sets on the client. The Macintosh client defaults to "Account Setup."
HTML publishing supported on the client? REG_PUBLISHING String 3 YES, NO. Element only included if not null. If not sent, assume NO.
Lock File AS_LCK_SUPPORT String 3 YES, NO
Bookmark File AS_BOOKMARK_SUPPORT String 3 YES, NO
Windows Animation File AS_WIN_ANIMATION_SUPPORT String 3 YES, NO
Macintosh Animation File AS_MAC_ANIMATION_SUPPORT String 3 YES, NO

Any information defined in this section is simply sent as-is, and is optional.

Note 1: Optionally, you can use REG_PLATFORM to have your server tailor its account-creation process to the client's operating system.

Note 2: REG_PUBLISHING is valid only in Netscape Navigator 3.0 and later versions.

Note 3: REG_SOURCE and REG_CHANNEL can be used to uniquely identify different versions for different distribution channels.

Note 4: This is useful if the Account Setup program is referred to by your Internet account server and has different names on the client.

From the client's HTTP header

The Internet account server can collect the following information about the client from the HTTP header it receives:

Data Element Data Element Name Type Length Accepted Values
Client Type (Navigator version and platform information) REG_USER_AGENT String 100 Use "user-agent" HTTP header line; can be accessed by a CGI script using the HTTP_USER_AGENT environment variable.
IP address of connecting client (used for debugging) REG_REMOTE_ADDR String 20 Standard IP address in format.

Protocol: REGISTER.HTM File Format

In Communicator 4.0, Account Setup stores the information it gathers in an HTML file, REGISTER.HTM, in the following format:
<!-- The following values can be set by changing the VALUE item -->
<INPUT NAME="name" TYPE = "hidden" VALUE = "value">

<!-- The following values are set via JavaScript -->
<INPUT NAME="name" TYPE="hidden">

The first set of values may be modified or supplemented. The values set by JavaScript must be left untouched for proper operation.

Process: Account Setup Dials ISP's Phone Number

Once it has collected the data, Account Setup uses information in the SAMPLE.IAS file to run the dialer, which dials your Internet account server's phone number. The dialer establishes a PPP connection.

The dialer handles user verification with the PAP protocol using a fixed user name and password, which is also set in the SAMPLE.IAS file. For more information on the .IAS file format, see the Netscape Mission Control Guide. The IAS password tool in the \Tools directory of the Dial-Up Edition CD should be used to create the encrypted password in the SAMPLE.IAS file. However, if you're using the Account Setup Editor, the passwords are automatically encrypted.

Process: Navigator Passes Account Data to Server

All of the data collected is used to build a form which is then HTTP POSTed to the RegCGI URL you have provided in the SAMPLE.IAS file. Navigator uses the URL you've stored in the SAMPLE.IAS file as the target of the form. This behavior is the same as if you had entered the following HTML syntax:

<form action = "https://SERVER.ISP.COM/REG.CGI">
where SERVER is the name of your registration server, ISP is your company name, and regcgi is the CGI script to be used.

Because account information is confidential (especially credit card numbers), you should implement your account-creation application with an SSL-capable web server such as Netscape's Enterprise Server. Note that the REGISTER.HTM file format example above specifies the HTTPS protocol to enable Secure Sockets Layer (SSL) encryption. However, you can change the protocol to HTTP.

Process: Server Interacts with User

Account Setup provides a frame in which server generated forms may be displayed to the user to gather account creation data. These forms are generated by your server using standard CGI protocols.

Process: Server Passes Configuration Data Back to Navigator

Your account server application should create the account based on the data submitted and send that configuration data to the client so Account Setup can finish configuring the dial-in components for your service.

When Navigator receives the configuration data from the server, a plug-in parses the data.

  1. The icon (<ICON>) for your service is saved in the user's profile directory. The filename comes from the DOMAIN_NAME value returned in the MIME stream. This is the same as the ISP name.
  2. Once the data is received and parsed, the plug-in returns control to Account Setup.

Protocol: ISP Configuration Data

Your configuration information is sent in a MIME stream. The MIME header in your CGI script must be followed by two carriage returns, per the standard CGI format. The MIME type Navigator uses to receive ISP configuration data can be either of two specially coded content types:


When Navigator sees this MIME type, it expects data in the format described below. The binary file format used by this MIME type is simple, yet extensible. It consists of consecutive name/value pairs separated by 2 bytes of size information:

| 2 bytes | ------ x bytes ------ | 2 bytes | ------ y bytes ------ |  (x)              (name)            (y)             (value)

The parser iterates as follows until it reaches the end of the stream:

  • Read 2 bytes of binary data and cast to int for size of Name in bytes (x)
  • Read (x) bytes of ASCII data for the name
  • Read 2 bytes of binary data and cast to int for size of Value in bytes (y)
  • Read (y) bytes of ASCII data for the value

Communicator 4.0+ also accepts the following MIME type:


When Navigator sees this MIME type, it expects data in the format described below. The binary file format used by this MIME type is simple, yet extensible. It consists of consecutive name/value pairs separated by 4 bytes of size information:

| 4 bytes | ------ x bytes ------ | 4 bytes | ------ y bytes ------ |  (x)              (name)            (y)             (value)

The parser iterates as follows until it reaches the end of the stream:

  • Read 4 bytes of binary data and cast to int for size of Name in bytes (x)
  • Read (x) bytes of ASCII data for the name
  • Read 4 bytes of binary data and cast to int for size of Value in bytes (y)
  • Read (y) bytes of ASCII data for the value


  • This format is virtually identical to the 3.0 format with the exception that the length descriptions for the name and value fields is a 32 bit integer rather than a 16 bit integer.
  • The 3.0 format (application/x-netscape-autoconfigure-dialer with 16 bit integers) will continue to be accepted, but may not be adequate to contain some of the new data fields. The new format is only required when a large amount of data must be contained in one or more fields.
  • Older clients will not recognize the new v2 format. We only recommend sending this format if the REG_SIGNUP_VERSION value is 4.0 or greater.
  • We recommend continuing to use the 3.0 format, unless you are sure that the version is 4.0 or greater, or if one of your data fields is larger than 16K.

Navigator extracts the following name/value pairs from the data and processes them according to the tables below.

The first name/value pair must always be the status value. If a user cancels, the account server needs to send a MIME stream of STATUS=ERROR to let Navigator gracefully shut down. Otherwise, STATUS=OK and the remaining items are included in the stream.

The length fields are represented in Little Endian ("1234") format. The integer value 6 is represented as 00 06 in application/x-netscape-autoconfigure-dialer and as 00 00 00 06 in application/x-netscape-autoconfigure-dialer-v2. On machines using Big Endian ("4321") or PDP Endian ("3412") formats, you must take care to convert appropriately.

Written to the [ISP Information] section of SAMPLE.IAS

Navigator writes this information to the SAMPLE.IAS file. (The order of entries may change and some are optional. Since each element is self-identifying via the name this isn't a problem):

Data Element Data Element Name Type Description
Must be the first field
STATUS String This is set to OK for a normal download. The STATUS field needs to be the first name/value pair passed back in the MIME stream. If the user cancels, it's set to ERROR and no other items are sent. This can also be set to EXIT, to completely shutdown Account Setup. Both ERROR and EXIT result in no account creation.
Site File
SITE_FILE String This names the Shiva remote (.SR) site profile file and icon file. It's limited to 8 characters so you can derive up to an 8+3 file for that host. A typical example would be netisp which would lead to site file NET ISP.SR being used by the dialer.
Site Name
SITE_NAME String A short textual name of the site, used for identification purposes (e.g., Windows 3.1 Program Manager or Windows 95 Dial-Up Networking item name).
User Login
LOGIN String The login ID (in clear text) used to contact your Internet access service.
User Password
PASSWORD String The encrypted password for the above login.
Phone Number
PHONE_NUM String The complete phone number to dial to contact your site. It's passed in (xxx) xxx-xxxx format. The dialer automatically adjusts for area codes, etc.

Note: TAPI cononical form is defined as "+CountryCode Space [(AreaCode) Space] SubscriberNumber." Subscriber Number can include periods, spaces, and dashes.

DNS Address
DNS_ADDR String DNS address in format.
Alternate DNS Address
DNS_ADDR_2 String Secondary DNS address in format (set to if none exists).
NNTP_HOST String The news host (either IP address or hostname).
SMTP_HOST String The email host (either IP address or hostname).
Domain Name
DOMAIN_NAME String Your organization's domain name (for email purposes).
POP Server / Login
POP_SERVER String The login name and host name or IP address of the user's POP server. The format is <USER>@<POP_SERVER>. This data is stored in the user's mail configuration file.
Email Password
POP_PASSWORD String The password for the above POP server.
Home Page URL
HOME_URL String The default home page URL. Note: if the home page is locked using the Administration Edition NETSCAPE.LCK file this URL information will be ignored.
Email Address
EMAIL_ADDR String The email return address for the user.
Custom Animation ANIMATION_DAT;
Animated gif file These files are combined into the "Custom Animation" file in the profile.
Large Animation ANIMATION_LARGE Animated gif file Windows Only: 32x32 binary gif animation data to replace Netscape N in upper right corner of navigator
Small Animation ANIMATION_SMALL Animated gif file 16x16 binary gif animation data to replace Netscape N in upper right corner of navigator
Auto-send character AUTO_SEND String Specifies characters to send from client to server prior to initiating scripted or TTY logins. Applicable only if such characters are needed (e.g., sending two carriage returns to begin a connection).
Bookmark File BOOKMARK_FILE String The new bookmarks are appended if a bookmark file already exists. The new bookmarks will replace the default bookmark file of a brand-new profile.
Dial Area Code (See Phone number information below) DIAL_AREA_CODE String If DIAL_AS_LONG_DISTANCE is set to YES, but calling plan doesn't support dialing area code, set to NO.
Long Distance Flag (See Phone number information below) DIAL_AS_LONG_DISTANCE String If long-distance dialing is needed, set to YES.
ISP Icon ICON 32x32 Icon File (Windows platforms only) 32x32 Windows ICO format icon of your organization's logo. Saved in file called <SITE_FILE>.ico. For Macintosh platforms, the contents of the icon file must be sent as inline data for this element.
ISP Account ID IDS_ACCT_ID String The user's account ID with you. Ignored on the client.
IMAP Host Server IMAP_HOST 1, 2, ... String The server(s) for IMAP mail, where 1, 2, ... is an integer.
IMAP Server Path IMAP_SERVERPATH String This information overrides the POP_SERVER when present.
ISP Technical Support Number ISP_SUPPORT String Support number the customer should use to contact you.
ISP WWW URL ISP_URL String Your organizations' URL, which is added to the user's bookmark file. This is paired with SITE_NAME for the new bookmark entry.
Lock File LCK_FILE String This data becomes a new profile.cfg file in the current profile. Client-side support of lock files is indicated by AS_LCK_SUPPORT=YES in the initial form post from the client.
LDAP Description LDAP_DESC_ 1, 2, ... String Where 1, 2, ... is an integer and LDAP_HOST[i] is described by LDAP_DESC[i].
LDAP Host LDAP_HOST_1, 2, ... String The server(s) for directory (LDAP) information, where 1, 2, ... is an integer.
Login Script LOGIN_SCRIPT String Only specify a login script if your server doesn't support PAP or CHAP protocols. See below for more information on login scripts.
Long Description LONG_DESC String A longer description of the site to be stored for help information.
Location of where new pages will be published PUBLISH_PUSH_URL String URL of where client will upload new HTML pages to. Examples include: ftp://username@server/usr/home or http://username@server/./
Password for account used in PUBLISH_PUSH_URL above PUBLISH_PUSH_PASSWORD String Clear text password for the account on the web publishing server specified in the URL of PUBLISH_PUSH_URL.
Location of where published pages can be viewed PUBLISH_VIEW_URL String URL of where client will view new HTML pages.
Netscape Registration ID REG_ID String Netscape registration ID as stored in the cookie. Netscape reserved field.
VJ Compression VJ_COMPRESSION String YES, NO.

Allows the account server to control VJ compression status on the client. This field is ignored on the Macintosh client.

Phone number information

Generally, Account Setup uses a combination of the user's phone number and the ISP's phone number to derive the number to dial (i.e., 1+area code + number, versus the number alone). However, it can happen that both phone numbers are in the same area code but the user still needs to dial a "1" prefix. These two flags give you independent control over dialing "1" (DIAL_AS_LONG_DISTANCE ) and the area code (DIAL_AREA_CODE). For default behavior, see that your account server doesn't set either of these flags.

If DIAL_AS_LONG_DISTANCE is set to YES then the "Home" (default) location for this account will be set up to dial a '1' before the number in the PHONE_NUM field. This field will be ignored if InternationalMode was set in ACCTSET.INI

If DIAL_AREA_CODE is set to YES then the "Home" (default) location for this account will dial the area code given in the PHONE_NUM field. If there is no area code given in the PHONE_NUM then this field has no effect. This field will be ignored if InternationalMode was set in ACCTSET.INI

If neither of these fields are sent back by your Internet account server, then Account Setup will set 'logical' defaults (both true if the number being dialed has an 800 area code, or has a different area code than the user's number.

The Login Script

On Windows 3.1, we use the ShivaPPP script language which is an extremely limited derivative of the Microsoft scripting language. These limitations are further constricted by Account Setup and reduced to the auto_send and login_script variables.

When auto_send and login_script are returned to the PC client, Account Setup does the following:

  1. Place the auto_send character into the <isp>.sr file as:
  2. [Security]
    AutoSend=<auto_send value>

    This value is only meaningful when the login_script value is not also present. The Shiva dialer will ignore the auto_send if a script exists.

  3. Parse the login_script into a script file and place it in <isp> .scp in the same directory as <isp>.sr.
  4. The login_script configuration value is formatted as:

    wait_for_string "|" [ reply_string ] [ "|" wait_for_string "|" [ reply_string ] ]...

    Note that if the reply_string is omitted and more wait/reply cycles remain, then the "|" delimiter must be present or the cycle will get out of sync. Also note that every character is significant.

    The reply_string values "%name" and "%password" are handled specially. The "%name" is converted into the scripting variable $USERID and the "%password" is converted into the scripting variable $PASSWORD. All other values are passed through unmodified.

    • The script prolog is:
    • ; <isp>.scp
      ; Created: <date> at <time>
      proc main
      transmit "^M"
    • The wait_for_string is scripted as:
    • waitfor "<wait_for_string>",matchcase until 4
    • The reply_string is scripted as:
    • transmit "<reply_string>"
      transmit "^M"


      transmit $USERID
      transmit "^M"


      transmit $PASSWORD
      transmit "^M"
    • The script is terminated with:
    • endproc
  5. Create the [Script] section in the <isp>.sr file. Set the flags to use scripting and add a pointer to the new script file <isp>scp.
  6. [Script]
    ScriptEnabled=Yes ; use a script
    ScriptRecord=No ; don't go into record script mode
    ScriptTerminal=No ; don't playback script output during login

    ScriptFileName=<full path to <isp>.scp>

As an example, the login_script value:


will result in the script:

; <isp>.scp
; Created: <date> at <time>
proc main
transmit "^M"

waitfor "name:",matchcase until 4
transmit "ispname"
transmit "^M"

waitfor "type:",matchcase until 4
transmit "ppp"
transmit "^M"

waitfor "login:",matchcase until 4
transmit $USERID
transmit "^M"
waitfor "password:",matchcase until 4
transmit $PASSWORD
transmit "^M"


Publishing information

REG_PUBLISHING is set to 'yes' in REGISTER.HTM in the Netscape Navigator 3.0 Gold and all 4.0 and greater releases of the dial up products. When this is sent to an Internet account server, it will send back the appropriate 'push' PUBLISH parameters back to Account Setup. These are then written into NETSCAPE.INI for Windows 3.1 or the Registry for Windows 95 at the given locations:

    • PUBLISH_PUSH_URL - Written to [Publish] DefaultLocation= also written to [Publish] LastLocation=
    • PUBLISH_VIEW_URL - Written to [Publish] DefaultBrowseLocation=
    • PUBLISH_PUSH_PASSWORD - encrypted and then written to [Publish] DefaultPassword= [Publish] LastPassword= [Mail] POP Password= also [Publish] RememberPassword="yes"

Process: Account Setup Puts Configuration Data in Local Files

After Navigator exits, control returns to Account Setup.

Windows platforms

Account Setup automatically performs these steps on Windows platforms:

  1. Create a connection file for your organization named <SITE_FILE>.sr.
  2. On Windows 3.1, move the temporary icon file to the directory where the Account Setup program is located. Rename the icon file <SITE_FILE>.ico.
  3. Update Navigator's initialization files (e.g., on Windows 3.1, NETSCAPE.INI, and SHIVAPPP.INI; on Windows 95, Windows Registry).
  4. On Windows 3.1, the client creates a Windows Program Manager item in the Netscape Dial-Up Edition group for this dial-in connection. The properties of the dialer icon include:
Description <SITE_NAME> field returned from your Internet account-server application.
Command Line Path to dialer executable with your organization's parameters.
Working Directory Path to dialer's working directory.
Shortcut Key None.
Icon <ICON> file returned from your Internet account-server application.

On Windows 95 the client uses data sent back from the account server to configure a Dial-Up Networking object on the desktop and in the Dial-Up Networking folder in the My Computer folder.

Macintosh platforms

On Macintosh platforms Account Setup updates the preferences files for Netscape Navigator, Free PPP, MacTCP (if installed), and Open Transport (if installed).

Process: User Runs Dialer and Navigator

After exiting Account Setup, the user can run the dialer and then Navigator to log directly into the new account using the configured data. Navigator should immediately connect to all the proper ports and servers.