Add windowing to the packet-level protocol.  

Paranoid types may not want to install uuxqt with SETPRV.  UUXQT_DCL
should check the privs, and if it can't get what's needed for the
MAIL/PROTOCOL command, deliver the incoming mail via a standard VMS MAIL 
command.  The mail will appear to come from the VMSnet user, not VN%"...", 
and will therefore not be REPLYable, nor will route-through work.  But...

Make all the log files go to a mailbox, and run a detached process to
copy the mailbox to a single unified log file.  Write it the same way
DCL writes a batch job's log so we can look at it while it's open.  
(One easy way is to run a tiny program in a batch job that copies the
mailbox to SYS$OUTPUT!)   At the moment, if multiple processes try to
open one of the log files for append access, the second one will fail, 
so we can essentially talk to only one remote site at a time.  

Add a "userfile" option.  Validate remote host name against local VMSnet user 
name, and provide a list of directories that the VMSnet user can read and
write, rather than forcing it to VMSNET_SPOOL as we do now.  
A list of allowable uuxqt commands would be useful also.  
Then we could turn off the code in gnuucp that forces it to the 
spool directory.  

Support continuation lines in the "systems" file.  

Call scheduling needs to be better.  We need to be able to say something like:

	Check for outgoing work for system x every <delta_time1>.  
	Even if there's no work for them, call them every <delta_time2> 
	to see if they have work for us.  
	Don't call them at all at <days...> <times...>
	Don't call them if we've had a successful call from or to them 
	within the last <delta_time3>.  

Add a way to use DECnet connections where they exist.  How about: 
Put a "device" entry in the control file containing a DECnet remote 
task specification, and give it a unique name (not acu).  Then the 
systems file tells gnuucp to use this name for that system.  
The login script would be empty.  The DECnet node name need not be 
the same as the uucp node name.  It should *almost* work as-is!  
But something in the systems line should tell gnuucp to skip the data 
link level part of the protocol, as DECnet already provides a reliable 
data path.  
We also need to read packets instead of single characters.  

	Or... the DECnet path could be specfied as an alternate protocol.  

Go through all the code and make the logging more consistent and 
generally nicer.  While we're at it, document the log entries for the 
benefit of the poor system managers.  Should we use the VMS Message 
facility?  

	Since login failures (on dialout) are among the most puzzling of 
	problems, why not save the whole login sequence in a buffer, which
	we throw away if the login succeeds.  Iff the login fails, then
	we write the buffer to the log file.  This way we avoid cluttering
	the log file with explicit details of good logins, which will
	(hopefully) be in the majority.  

	Same for the uucp init sequence.  

	In fact, we could keep the most recent 'n' packets in and out in
	a buffer, and write 'em to the log file in the event of failure,
	under all circumstances.  

	The debug-level number is too crude a control.  Why not make it
	a bit mask, so we can independently enable various logging features?
	In fact, use two different bit masks, one for normal and one for error 
	situations.  

	Keep some statistics so we have an idea of how efficiently we're
	using our links.  

	There should be an option to rename files into a "hold" directory
	instead of deleting them after uuxqt is through with them.  The
	files in the hold directory should be purged after seven days or 
	so... useful for debugging.  

We could get rid of most of the control file (everything except the 
device entries) by using logicals.  But...how much are we willing to make 
this unlike the original gnuucp, just to make it more VMS-like?  If
I see a clear functionality enhancement, I guess I'll do it, but only then.

Processing of "expect" strings needs to be better.  Should be able to 
look for bells, for instance.  

The expect-send1-expect1- ... should have a "repeat last pair forever" option.
In fact, the whole expect/send business should be a lot smarter.  Something
that implements a much better language for this is supposed to be on the 
Fall 88 VAX SIG tape; maybe we can use that.  

Move the modem control tables to a macro module, so that folks without
C compilers can add modem types.  

User's guide:  
	Add some info on modem setups.  

Add some support for rewrite rules for both from and to lines.  For instance, 
on outgoing mail, should we turn host::user into user%host ?  And
the reverse on incoming?  

smail does a binary search (a real trick on a text file!) to look up
host names in paths. .  It's fast enough as is on an unloaded system,
but an indexed file is obviously the right way to go.  (We can even
update it without disturbing anybody who's reading it...)

.signature support would be nice in the mailer.  
Maybe in News, too.  Should enforce a line limit, though.  

A utility to turn Unix diff output into an slp file would be useful.  

We need to look at all the good ideas in HoneyDanBer UUCP and see
what we ought to adopt.  

I wonder if, in putting in the new dialer code, I broke the direct-
connection code? 

News support is still untested.  
Maybe need to write an "rnews" which we can handle just like "rmail".  
Need to support LZ compression a la Unix Netnews.