I've been thinking off and on for a few months about how to
incorporate rfc2228 support into ftpd...  I actually got a bit
of code written a few months ago, for handling the ENC/MIC/CONF
commands inside the yacc grammer, but that fell apart after
noticing that ABOR processing didn't go through the normal .y
message parser.  I know that the MIT code handled MIC/CONF/ENC
directly in the getline() function (rather than going through
yacc), but I had already decided that allowing MIC(ENC(command))
to be equivalent to CONF(command) was a pretty neat feature, and
I didn't want to give it up, so I didn't pursue the MIT method.

Fast forward to present day, and I've got an alternative approach
for dealing with the ABOR command, that may also have other
benefits (like allowing one server to transmit several files at
once).  The idea is to move all data input into the .y file, by
adding a new syntax element to the .y file indicating the source
of the data.  The getline() function could be modified to perform
directly, or hook into, a function that executes select() on the
control channel, as well as all data channels, and makes this info
available to YACC, somehow. E.g.:
cmd_list
	: /* empty */
	| cmd_list CONTROL cmd
		{
		}
	| cmd_list CONTROL rcmd
		{
		}
	| cmd_list data_in
		{
			/* indicates data available for input, without
			 * reading it. */
		}
	| cmd_list data_out
		{
			/* indicates the peer is ready to accept more
			 * data. */
		}
(where the values of data_in and data_out are the file descriptors
which have/can accept data.)

The main feature of this is that ABOR no longer needs special case
handling...  It can move right into ftpcmd.y.  A questionable
feature is that this will mean the STOR/RETR handling will need to
be made non-blocking for ABOR to work at all (but, OTOH, making
them non-blocking *would* allow us to run several transfers at
once, and lets the FTP server respond to stuff like CHDIR while a
RETR is happening).

Opinions?
--aidan