Re: RFCs in print
Jeffrey Mogul <mogul@pa.dec.com> Sat, 10 June 2000 01:30 UTC
Received: by ietf.org (8.9.1a/8.9.1a) id VAA21060 for ietf-outbound.10@ietf.org; Fri, 9 Jun 2000 21:30:02 -0400 (EDT)
Received: from mail1.digital.com (mail1.digital.com [204.123.2.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21032 for <ietf@ietf.org>; Fri, 9 Jun 2000 21:29:29 -0400 (EDT)
Received: from pobox1.pa.dec.com (pobox1.pa.dec.com [16.1.240.19]) by mail1.digital.com (8.9.2/8.9.3/WV2.0h) with SMTP id SAA24098; Fri, 9 Jun 2000 18:29:28 -0700 (PDT)
Received: from wera.pa.dec.com by pobox1.pa.dec.com (5.65v3.2/1.1.10.5/07Nov97-1157AM) id AA08005; Fri, 9 Jun 2000 18:29:24 -0700
Received: from localhost by wera.pa.dec.com; (8.8.8/1.1.8.2/06Jun96-0357PM) id SAA05586; Fri, 9 Jun 2000 18:29:24 -0700 (PDT)
From: Jeffrey Mogul <mogul@pa.dec.com>
Message-Id: <200006100129.SAA05586@wera.pa.dec.com>
To: pete@loshin.com
Cc: mogul@pa.dec.com, ietf@ietf.org
Subject: Re: RFCs in print
Date: Fri, 09 Jun 2000 18:29:24 -0700
X-Mts: smtp
X-Loop: ietf@ietf.org
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
- RFCs in print Pete Loshin
- Re: RFCs in print Keith Moore
- Re: RFCs in print R. Muralidharan
- Re: RFCs in print Robert G. Ferrell
- RE: RFCs in print Michael B. Bellopede
- Re: RFCs in print Lloyd Wood
- Re: RFCs in print Jeffrey Mogul
- Re: RFCs in print Paul Ferguson
- Re: RFCs in print Ole J. Jacobsen