At 05:32 PM 3/27/2004, grenville armitage wrote:
"Kurt D. Zeilenga" wrote:
The problem I see with being specific here is that what's crap to me
is not necessarily the same as to you, and we'll just end up arguing
over wether something is crap or not, and that will overshadow the
key aspect of my argument that we should each be allowed to own
opinions as to what is crap and be able to act on those opinions,
including publication of what others might consider to be crap.
You do have avenues for publishing 'crap' outside the RFC series.
Put your content up on a website. Send it to a mailing list. Shout it from the
treetops.
Yes, other avenues are available publishing independent works.
However, it has been a long standard tradition of the RFC series
to provide an avenue for publication of independent works
(subject to minimal review). There is merit to the Internet
technical community in this tradition as it combines opposing
opinions into a single series of documents.
I strongly believe that hindering the publication of individual
submissions, as Keith suggests, will have long term negative
impact upon the overall technical merit of the series. That
is, you'll get want you seem to wish, individuals will go elsewhere.
And I don't mean just in terms of publication avenues, but
in terms of where and how Internet engineering is done.
Your argument against improved expectations of standards in the RFC
publication process seems unconvincing.
Arguments that we should reenforce the false expectations of
the quality and/or community acceptance of documents in the
RFC series are unconvincing to me. We'll always have documents
of different quality (including crap) and community acceptance
(including none) in the series, we should focus more on how to
distinguish the levels of quality and community acceptance.
Attempting to restrict the series to those documents
believed to be of high quality and broad community acceptance
is simply infeasible (if not impossible).
I see Vanity Press written all over it.
Minimal review undertaken by the RFC Editor appears to be
sufficient to address such concerns.
Kurt