Re: the RFC mess: tentative summary
On Sun, 13 Jul 2003, Martin Quinson wrote:
> 1. RFC are not software but standards.
>
> Answer 1: What is a software, then? It's impossible to establish a clear
> definition of that (Perl interpreting scripts is not clearly different
> from mozilla or php processing an html document).
> Answer 2: Ok, that's not software. But it should remain free anyway to
> make its way to main (non-free non-software is not equivalent to free
> software)
> Answer 3: If they are not software, they don't belong to Debian (one
> interpretation of "Debian will remain 100% free software")
So, if we add non-free documention, debian will *still* be 100% free software.
It really boils down to whether the above can be interpeted as all inclusive
or exclusive.
> 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.
> 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.
> 10. There is no need for documentation to be free
> Answer: If you adapt the code and cannot adapt the documentation to
> reflect the changes, you'll get into trouble.
> (but that's more related to the GDL. One flamewar after the other, please)
See my reply to 2.2 above. Adding new features, or not implementing some
features, doesn't require changing an existing standards document.
Let's consider RFC12654 as a version number, that describes
Protocol/Application Foo, at a particular point in time. Implementing some
rfc then just means you are compatible with that particular foo, as it was at
some point in the past.
Reply to: