> 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.
Handwaving this is inviting trouble. A macro language for writing chat
scripts (such as Apple's ARA CCL, which sucks but works) needs to be
specified, and the scripts should be delivered in human-readable/editable
(eg. text file, not compiled) format so that they can be tweaked to fit any
local weirdnesses for a particular provider or have hacks installed by a
savvy user to get around local problems like a cranky PBX (ie, don't let the
desire to be user-friendly eclipse the need to be easily reconfigurable by a
knowledgable person). Moreover, hooks for more parameters than just UserID,
Password, IPAddress, PhoneNumber, and MaxSpeed need to be provided to support
things like secondary passwords, callback, etc.
DefaultGatewayIP is superfluous in the case of the single leaf node connected
to a terminal server running PPP. Since nothing else here addresses the
complexities of routing to a subnet, I conclude that this proposal only
addresses the former case. You may as well just dike that field out.
For POP3, NNTP, and SMTP, you need to specify return addresses and full-
names. These will not necessarily be the same as the username in the
terminal emulator or PPP session, for obvious reasons.
I like the idea of a configuration language that hides the nuts and bolts
of PPP from Joe and Jane Luddite with their 486-PC-running-Windows <grin> but
I think it needs lots more thought before it is viable in the wide variety of
circumstances it will find itself in out there in real world.
Oh yeah, I don't think it's such a hot idea to promulgate a new standard in
which (a) passwords are stored online in cleartext, and (b) reusable
passwords are passed back and forth over the net in cleartext. Better by far
to specify Kerberos or a session key handshake for user authentication, and
maybe even encrypt the entire session...
Just my two cents worth...
---Rob
