inetd enhancements - config syntax

[James Browning <jamesbrowning137%gmail.com@localhost>]

Hello again,

We have gone over the community feedback in-depth, and taken into account all of
your suggestions regarding the new backwards-compatible syntax for inetd.conf.
We have drafted a few ideas, and would like to get your thoughts and feedback on
these ideas.

To reiterate the previous thread about inetd enhancements, it was apparent a new
backwards compatible syntax for inetd.conf would be needed if we are to
implement the new features 
(http://wiki.netbsd.org/projects/project/inetd-enhancements/). As suggested by
David Holland and Mouse on Nov 25, a good way for the parser to distinguish
between the new syntax and old syntax would be based on the second token of a
service configuration. We like the previously suggested idea of using an “on” or
“off” directive to distinguish the new syntax. Something like:

ntalk on ...

or to make the service off by default:

ntalk off ...

This would also provide the advantage of allowing easy enabling/disabling of a 
service if the service configuration extends for multiple lines (which the new
syntax may allow), as opposed to needing to comment/uncomment multiple lines.

We also are favoring key-value pairs, opposed to the current positional syntax,
since that will allow for greater flexibility, making it easier for future
additions to inetd as well as making it easier for handling default or implied
values. For example, if the admin doesn’t assign a value to the “port” key then
the port would be inherited from ‘service-spec’, and similarly for listen-addr
and IPsec policy.

The new syntax would look something like:
<service-spec> on/off key1=value, key2=value1 value2 value3,
key3=”this is a value”, key4=value1 value2 ”this is value3”;

For example:
ntalk on protocol=tcp4, user=nobody, exec=/usr/libexec/ntalkd, args=ntalkd -p;

The exact key-value pair names and purposes is up for debate. It is possible
that we could implement the features of the current syntax almost exactly as
they are now, just as separate key-value pairs, or we could smooth over some of
the awkwardness of the current syntax by allowing parameters like dgram/stream
and wait/nowait to be implied by default by the actual transport protocol if
possible, or vice versa (dgram implies udp). Of course the rules for defaults
would need to be well documented and obvious or unambiguous. Comma delimiters
allow keys to be associated with multiple values, which could be useful for
things like command line arguments or specifying multiple addresses or
interfaces.

There are some lingering thoughts and questions we have regarding implementing
this new syntax. 

Firstly, we are unsure if we should implement escape sequences for arguments
contained inside quotes. Currently, inetd does not do this, and simply removes
all occurrences of quotations from arguments. Would it be useful for us to
support escape sequences in the new syntax? (In other words, is there any use
for being able to pass quotation marks as part of an argument for a service?)

For “per-service” (really just “external”) configuration files, our current
thought is to allow for the “includedir x” directive (includedir is not
necessarily the directive we are set on) inside of inetd.conf where “x”
would be a directory containing fragmented configuration files. But we are also
thinking it would be best to not support “includedir” inside the fragmented
files themselves, in order to avoid potential cycles and to avoid multiple
levels of includedir directives.

Regarding the [listen-addr:] option, our current idea is to leave this
functioning as is (which is that it acts more like a global variable and sets
the listening address for the rest of the config file). We would also like to
introduce a new key value pair, listen-addr=xxx.xxx.xxx (or an IPv6). This would
allow for the listening address to be overwritten only for the service that
specifies it.

We know this is quite a lengthy email, that has quite a lot to consider and
discuss, but your feedback is very useful, and it does help us to consider new
perspectives and see oversights we might have had in our design process. We
prefer to get this new syntax right, and make sure it is thought out and
intelligent as opposed to rushing these changes out. 

Sincerely,
James Browning
Gabe Coffland
Alex Gavin
Solomon Ritzow