Michael Mathews writes:
> This brings up a very important question (especially since you used my RFC
> as an example), which is: how shall we know when a particular RFC is
> rejected? My understanding was we should generate RFC's. I don't know if (or
> particularly how) we should be rejecting them before they are fully
> released.
Here's how I see it: at some point the maintainer of the RFC has to
say either:
- we have a conclusion, or
- we are never reaching a conclusion.
The conclusion might be to do it a particular way, or not to do it at
all. If there is a conclusion, that goes into the RFC, end of the
story. This applies even if the conclusion is not to do something.
If there was no conclusion, the maintainer can do one of three things:
- ignore dissenters and finish up the RFC
- scrap the RFC
- conclude that the lack of consensus means it's impractical, and
rewrite the RFC to say that
I don't care particularly if you ignore dissenters. They can have
their own counter-RFC. All we're doing is making suggestions to
Larry, not regulating nuclear weapons or planning a space mission.
Nat
