xinetd feature: daemons that listen on multiple ports

I'm thinking about adding a new feature to xinetd, and am seeking
feedback on how best to implement some of it.

Many daemons, such as portmap and modern mail daemons, listen on
more than one port or the same port on tcp and udp.  Currently, 
this essentially means they can't run out of an inetd, or they
need to change their architecture so they can.

It would be useful if these services can be launched out of
xinetd for a variety of reasons.  There are a number of xinetd
internal issues that would need to be resolved to make this
happen, but the biggest issue is defining an interface for the
passing of the socket descriptors to the daemons launched by
xinetd.  Traditionally, inetds have always passed THE socket
descriptor to the child daemon on file descriptors 0, 1, and 2.
This is very convenient for running non-network aware daemons
through inetd.  This obviously breaks down when there is more
than one socket to be passed.

So, here are some ideas that have been floated around.  I'd be
happy to get comments back on any of these ideas, or better yet,
if you have a different way you'd like to see the descriptors passed.
1) Have xinetd specify which file descriptor numbers the socket
descriptors will be passed on.  So, in the xinetd configuration
for the socket, you specify that file descriptor 5 will contain
this socket.  Then in the daemon, it just knows that descriptor
5 will be the right socket.  This approach is very simple, it
keeps with the tradition of inetd's current passing approach,
but is unweildy and potentially error prone for the author of
the daemons.
2) Pass the socket descriptors to the launched daemon via 
a unix domain socket.  This has issues because file descriptor
passing is not standard.  Although most OS's have some ability
to do this, the code is usually not portable.
3) Have xinetd pick randomly which file descriptors in the
process will contain which socket descriptors, then have
the launched daemon recieve addrinfo structures describing
which sockets are on which file descriptors.  

#3 seems to have many benefits, since the descriptors are
already passed to the launched daemon, and it gets complete
information about that socket descriptor from xinetd.  xinetd
could even open the unix domain connection for the launched
daemon on a known file descriptor number, say 3.  The daemon
will then need to read the information off that file descriptor
to figure out what open descriptors it has, and what they are to.

Any comments?  People that write daemons launched from xinetd
should be encouraged to respond.

Thanks,
Rob