Last Updated August 13th, 1995.

This file details the features/changes that I am still considering
adding into this version of diald (before I go for the grand
redesign I keep promising). If something disappears from this list,
that means I either implemented it, or rejected the feature for
the time being. If I rejected a feature it will generally mean
that I can't see how to do it without a complete code redesign.

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

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

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

- Send ICMP unreachable messages to programs that are trying to send
  from an IP address that has changed due to a dynamic reconnection.
  I have _no_ idea how to actually manage this properly though :-)
  I'm also not sure how to recognize such packets, since packets
  with source addresses that are not on the current machine might
  just be forwarded from another machine.

- Add in proxy routing options? At least document how to do it in the FAQ?

- Consider changing diald to find programs using PATH?
  Alternatively make everything including program names configurable
  in /etc/diald.conf. The idea here is to make it possible to create
  a binary distribution for those souls who are to lazy to compile
  things for themselves.

- Add in hooks for a monitoring package?
  I can think of a few approaches:
  (1) send diald a command asking it to open a pipe
      out to a process that does the monitor task.
  (2) send diald a command asking it to open a named
      pipe and write the monitoring data out to it.
  I think I like (2) better.
  The idea I have is to write a "control" utility in tk,
  and maybe another in "dialog" or something.
  I'd probably just write the one in tk first.

- The firewall code needs to tie together TCP connection endpoints
  in a better way so that we can always trap TCP shutdowns properly.
  (Just watching FIN packets on one side of the connection is not enough).
  A two part fix would be
  (1) make both end points of a connection be stored in the same slot.
      This could be done by having the firewall ID construction rules
      sort some portions of the data. This would require a more
      sophisticated construction rule, or a cheat before generating the ID.
      (i.e. just before generating the ID, sort the addresses).
  (2) Add a 2 bit tcp_state variable to each connection.
      One bit for each direction. Both start in "on". If an RST or FIN
      packet comes by the state goes to "off" in that direction.
      This state would have to be computed before running the filter
      rules over the packet.
   NOTE: this would require a change in the semantics of protocol rules.
   Rather than matching a protocol rule together with a filter rule,
   the protocol rule match and ID generation should occur first.
   Then the correct state can be generated (and accessed by the filter rules).
