On Sun, Jul 13, 2003 at 05:11:30PM -0500, Adam Heath wrote: > > 2. Standards gain their value from their rigid rigid procedure for updates > > and modifications. > > or: > > Who needs to edit the RFCs by the way? > > or: > > Keep cool, IETF are good guys, sharing some goals with us. > > > > Answer 2: As long as the IETF is a good willing institution, that's fine, > > but what will happen in 10 years? If they disapear, we need the *right* > > to modify the existing RFCs to create new ones, and fork the > > standardisation process. > > This is not very different forking gcc: in both cases it's generally a > > bad idea, but the health of a free system depends on it being > > potentially possible. > > Er, hasn't it always been that you never modify an RFC, but just create a new > one, that subsumes the old? There are countless cases of this already(DNS > being a prime example). > > I highly doubt that this would ever change. You're thinking of IETF policy, rather than licensing. > > Answer 3: If I want to document a program following quite well a given > > RFC, but not completely, it's easier for me to edit the RFC file (and > > rename it of course) than paraphrasing it. If I'm not allowed to do > > this edit, I'll probably never document those changes, which is a loss > > for the users. > > Same thing for comments in code explaining which part of the RFC > > constraints some design decision. > > Why would you need to edit and rfc to say that your program doesn't follow it? > This makes no sense to me. More clearly, you can't take text from the RFC and use it in your own documentation. Or in a subsequent standard, for that matter. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK
Attachment:
pgp4D0agg5fiY.pgp
Description: PGP signature