It looks to me like we have a fairly straightforward tradeoff here.
The problem is actually that the IETF is using an FTP server that has
a dubious security anti-feature (no symlinks ever) that causes
operational issues. This is a real problem.
One approach is to turn off FTP. This has costs to the IETF, find all
of the ftp: URLs in the web site and other online materials (e.g.,
auto-generated e-mail and stuff you can get by FTP or rsync), identify
other ways to access the material, and change the links. It also has
costs to anyone using FTP who will at least have to change what they
do and possibly find and install new software, e.g., Windows rsync.
The other possibility is to make it someone's job to fix the FTP
server. There is lots of free FTP server software -- I see about a
dozen of them in the FreeBSD ports collection. I've used a few and
found that they're generally not hard to configure, and symlinks are
no problem (use chroot to limit accidental leakage.) Most provide RFC
4217 TLS support which makes FTP roughly as secure as https if your
client supports it. In this case, the ftp: links keep working, and
assuming reasonable file layout and use of symlinks on the server, it
should be possible to keep existing URLs and paths valid indefinitely.
So it seems to me this is really a question about money. Is it worth
whatever the cost would be to upgrade and document the FTP service so
it doesn't get in the way of other operations? I dunno, sounds like
a job for the IAOC.
R's,
John
PS: I have no sympathy for arguments that we should force people to
use encrypted protocols. Can we please give our users the benefit of
the doubt that they are able to understand their own security
tradeoffs?