Pete Loshin writes:
I am particularly interested in hearing about whether such
collections are helpful or not. And if not, what would be more
helpful.
It is my belief that making these source documents available in
print can only help those who need to understand them, provides a
more convenient format for reference, helps novices avoid wasting
time with obsolete specifications, and adds value with indexes
across groups of RFCs as well as prefatory material that summarizes
and puts the selected RFCs in perspective.
As the author or co-author of RFCs in several of your books, I
suppose I have some standing to comment on this.
Other people have raised the issue of equity. I've always
believed that RFCs should be freely copyable, with no royalty or
permission requirements, although I don't think it's written
anywhere that you're *prohibited* from sending the RFC authors
some checks once in a while :-).
But I'm somewhat more concerned about the context created by the
books you've published. Yes, there is some benefit to creating
an index (or indices) covering useful subsets of the RFCs ... not
that this couldn't have been done online, but it's value added,
of a sort. (Although having the RFCs in a searchable format is
probably more valuable, is one of the main reasons why the IETF
insists on ASCII, and is available to anyone for free.)
One aspect of choosing a small subset of the thousands of extant
RFCs to put into a book is that the book-editor has applied some
sort of selection criteria. This could have been valuable to
beginning RFC-readers.
But "RFC" does not mean "always an applicable standard." I went
to the bookstore to actually look at the books, and as far as I
can tell, they include no guidance at all about whether a reader
should take the included RFCs seriously. The answer is "not
always", and I fear that a naive reader could be misled by the
choices that have been made.
Two examples, both picking on myself:
(1) In "Big Book of Internet Host Standards RFCs", you
have included RFC950 (Internet Standard Subnetting
Procedure). Great, this is one of my favorite RFCs.
But it's obsolete; it doesn't say anything at all about
the current mechanism, Classless Inter-Domain Routing
(CIDR) [RFC1519]. And some of the details in RFC950
are in conflict with CIDR. So I think it's a mistake
(in the year 2000) to publish a book reprinting RFC950
without warning the reader to learn about CIDR (which
is not, as far as I could tell, mentioned in the
book).
I'm also not sure if naive readers should be presented
with RFC922 (Broadcasting Internet Datagrams in the
Presence of Subnets) as "essential information to learn
exactly how to make [code] standards-compliant."
(2) In "Big Book of World Wide Web RFCs", you have
included RFC2227 (Simple Hit-Metering and
Usage-Limiting for HTTP). I still think this was a
good technical design, but I've been forced to admit
that it's not going to fly, for business and political
reasons; at least, not any time soon. I doubt anyone
has a complete implementation, and I don't think it
makes to imply that this RFC has an importance on the
level of most (all?) of the other RFCs in the book.
Unfortunately, the local bookstore didn't have a copy
of this volume, and I'm not going to shell out $35 just
to check whether you've warned readers about this RFC
:-)
Additionally, if one simply fetches the current online
rfc-index.txt, each listed RFC is shown with its current IESG
"Status", and obsolete RFCs are so marked. Once an RFC appears
in a printed book, however, it's hard to update its apparent
status. So if/when, for example, RFC2616 (HTTP/1.1 Draft
Standard) is replaced by a new RFC at Full Standard status, how
is the reader of your book to know this?
I think printed books of RFCs could be valuable, but I would
really prefer to see such a book give much more explicit
guidance, both generic ("check a current online rfc-index.txt to
see what the document status is"), and specific ("RFC950 is
modified by RFC1519"; "RFC2227 is not used in practice").
-Jeff