Date: Wed, 19 Jul 2006 03:06:10 +0200
From: Henrik Levkowetz <henrik@xxxxxxxxxxxxx>
Message-ID: <44BD8582.40909@xxxxxxxxxxxxx>
| Ok. So I'm not sure what you propose here - should we not require
| rsync and ftp mirroring capability, or should we ask for it, and not
| specify chapter and verse regarding version etc.? I'd certainly be
| very unhappy completely abandoning the rsync capability.
Today that might be true, but in 6 months, some new mechanism may have
blown rsync away completely. What would you think then if the RFC editor
refused to provide the new mechanism, because they're required to provide
rsync, but don't have the resources to provide both?
All that should be required is that the RFCs be available to be fetched
via some mechanism - which mechanism doesn't matter, and should not be
specified (though given its longevity, mandating FTP as one possibility
wouldn't bother me). If the mechanism(s) provided happen not to include
rsync, and you believe that rsync availability is important then you can
make them available that way (or someone else could). And if the
version of rsync provided isn't the one you want, you, or someone, can
make them available via some other version.
Be reasonable about this stuff, don't put in any specifications that you
wouldn't have included 10 years ago, or that aren't very likely to be
just as relevant 10 years ahead of now.
After that, all that matters is service quality - the RFC editor
will need to keep responding to week by week user demands, or some other
organisation will replace them.
kre
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf