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