- Make diald work in reverse, i.e. deal with call in on a line,
  but still do timeouts. Basically this option would start up
  in the state "START_PPP" and once the line reached a down state
  simply exit. The point of this is to allow servers to do timeouts
  on PPP users who call in.

- Way to specify an "always up" filter rule.

- Make diald work both as an "answer" program, and a "callout" program.
  This is to allow people to connect two machines with diald,
  such that either end can dial out to the other end.

- Consider including extra information in the accounting log
  so that initial outgoing calls on callback providers are
  distinguishable.

- Make diald capable of dealing with phone systems where the calls
  charging is quantized (e.g. Germany). The idea here is to know
  the quanta size being used for the current call and keep the link
  up if you wouldn't save any money by putting it down.
  (Of course you may have other reasons to put the link down, 
   like someone else wants the modem!)

- Add in time restrictions to dial outs. i.e. forbid dialouts from
  initiating except within defined time ranges. Possibly even
  controlled by day? What about forcing the link down outside of
  certain time ranges?
  This could either be done by augmenting the filtering code,
  or by having a separate time control system. (The latter
  is more attractive, since this keeps things out of the code
  I would like to move into the kernel.)

- Make diald's use of multiple modems ports more sophisticated.
  What you'd really want is the ability to have different sets of
  options associated with each physical device, and perhaps
  with each "phone number" that be called via that device.

  e.g. global level
	device level
	 chat script level
	 ....
	...

  diald would lock a device down and try each connection option
  until it got a connection, perhaps with delays between options
  and a cycle count for how many times it should cycle around the
  list before quitting and waiting for more network traffic.

- Come up with some way to deal with dynamic IP address assignments,
  either from SLIP or PPP.

  [I have received a patch to diald-0.3 that deals with dynamic SLIP.
   It works, but not with multiple dialds running at the same time.
   Also, it requires changes to chat. I'd like to avoid such things if I can.
   I have also implemented a scheme that works with PPP. I think I 
   might be able to extend my PPP scheme to SLIP, but it requires
   using dip to negotiate and hold up the entire SLIP connection.
   These means SLIP would use two sl? interfaces rather than one.
   On the other hand it would give a speed increase in SLIP mode
   because it would eliminate the need for diald to read the modem
   output and write it back onto a pty.]

- consider the possibility of packet level firewall filtering within diald.

  [I've done an experimental all user space implementation of this.
   It works, but the overhead is way too high. I'm now looking into
   making a per device firewall service in the kernel and using it
   to control the diald links.]

- consider a way to have diald detect a "ring" pattern on a
  connected phone, and dial out in response.

  [I've added SIGUSR1 to mean "bring the link up". I think
   that mgetty or some other getty program should deal with
   the rest of this problem.]

- Consider having a way for users to "block" diald until they
  want it to call out again. (Signal based? SIGTSTP SIGCONT?)

- Consider cost based timeout rules.

- Have a separate (low) retry timeout for attempts that fail
  due to lack of an unlocked outgoing device.

- Do dialing for ISDN devices as well.
  [I can't seem to find any information on doing ISDN on Linux.
   If I could get more info I'd be willing to try this.]

- Maximum timeout per connection and/or maximum time per connection
  site per day (makes more sense on a server!)
