Message-ID: <1994Aug18.192042.830@news.media.mit.edu> Newsgroups: news.admin.misc,news.admin.policy,news.software.readers Path: coyote.channel1.com!news.sprintlink.net!hookup!swrinde howland.reston.ans.net!europa.eng.gtefsd.com!uhog.mit.edu!news.media.mit.edu rnewman From: rnewman@media.mit.edu (Ron Newman) Subject: Good Net-Keeping Seal of Approval, Revision 1.1 Message-ID: <1994Aug18.192042.830@news.media.mit.edu> Sender: news@news.media.mit.edu (USENET News System) Supersedes: <1994Aug18.023342.12568@news.media.mit.edu> Organization: MIT Media Laboratory References: <1994Aug18.023342.12568@news.media.mit.edu> Date: Thu, 18 Aug 1994 19:20:42 GMT Lines: 408 Xref: coyote.channel1.com news.admin.misc:19622 news.admin.policy:18249 news.software.readers:11419 [note: this is a supersede of my original article, to fix an erroneous URL for the "son-of-1036" specification. All other text is identical to yesterday's article.] Here's the long overdue Revision 1.1 of my proposed "Good Net-Keeping Seal of Approval" guidelines for Usenet news reading and posting software. I've incorporated a number of suggestions from people who sent me e-mail or posted followups to Revision 1.0. I've also declined to add a number of items, either because the suggestion was too controversial (for example, 50% quoting limit) or not appropriate for this purpose (for instance, scanning the article to automatically generate a Keywords: list). I'll try to respond to some of these suggestions in another post, hopefully later this week. Remember, this is intended to be a set of *MINIMUM* requirements for Usenet software to get along with the rest of the Net. It's not a general wish-list. After a couple more weeks of discussion, I'd like to make this a Periodic Posting to news.software.readers, news.admin.misc, and news.admin.policy. (Any others?) My intent is to accompany it with a list of existing software, showing how each program does or doesn't conform to the guidelines. Finally, I'd like to thank all the people who have volunteered to test software for compliance with these guidelines. I'll be writing to you shortly. ------------- The "Good Net-Keeping Seal of Approval" for Usenet Software by Ron Newman Revision 1.1 -- August 17, 1994 There's a general perception that Usenet has become "noisier" in the last year, as more people have joined it. There are more blank articles, more mangled headers, more "Me too" responses at the end of 100 lines of quoted text, more followups to inappropriate newsgroups, more misattributed quotes, more followup postings that really should have been e-mail replies. This is often blamed on the new users themselves--they are called "clueless newbies", unqualified to participate in Usenet because they don't know Unix, or use a graphical user interface (GUI), or use an off-line news reader, or use a commercial service such as AOL or Delphi. I believe most of this anger is misdirected. The new users aren't really that different from the old-timers. What IS different is that many of the old-timers are using "rn" or its derivatives (such as "xrn" and "trn"), while many of the newbies are using TIN, UQWK, AOL, or various PC and Mac news readers. Unfortunately, these programs frequently violate assumptions that come naturally to users of "rn"-like readers: - The user can see all header fields, including "Newsgroups" and "Followup-To". - The user can edit all header fields when following up. - There's a clear difference between "Followup" and "Reply". - Followups preserve the Subject: and References: of the original article, unless the user edits them explicitly. - News software respects "Followup-To" and "Reply-To" specifications. Newer software should be an improvement over an ancient program like "rn". Instead, much of it instead looks crippled or broken to the "rn" user. I propose that the Usenet community deal with this problem by establishing a "Good Net-keeping Seal of Approval" for Usenet reading and posting software. This "Seal" would certify that the software complies with certain minimum standards, such as those that I propose below. A group of volunteers will test all putative Usenet software to determine whether it deserves the "Seal". We'll arrange to periodically post a list of all tested software to news.software.readers, news.misc, and other appropriate newsgroups. This periodic posting will list both compliant and non-compliant news programs; for non-compliant programs, it will include a list of all violations of the standards. My hope is that this will induce the authors of non-compliant software to bring their programs up to "Good Net-Keeping Seal" standards. Here are the standards I propose to use for granting the "Good Net-Keeping Seal" to a Usenet news program. In the spirit of Henry Spencer's "son of RFC 1036" proposal, I've capitalized the words "MUST", "MUST NOT", and "DO NOT" to indicate absolute requirements, while using the word "should" for things that are merely a Very Good Idea. 1) Display all essential header information When displaying a news article, it MUST by default show the user certain information that is found in the article's header. The information need not be displayed as actual RFC-1036 header lines, but it MUST be shown to the user. The software may allow the user to re-configure it so as to turn off these displays, but if the user has not done this, all of the following MUST be displayed: a) The author of the article (its From: header line) b) The article's Subject. At least the first 71 characters MUST be displayed. c) The list of newsgroups the article was posted to. This MUST be displayed in full, never truncated. d) The article's Followup-To list, if this is different from the Newsgroups list. This MUST be displayed in full, never truncated. e) The article's Reply-To, if this is different from the From: specification. The 71-character minimum does not include the string "Subject: " itself. The list of newsgroups need not be displayed if it has only one element, provided that the software displays the name of the newsgroup that the user is currently reading. Rationale: The user should know, without having to make a special effort, who sent the article she is reading, how to reply to it via e-mail, what discussion groups it was posted to, and whether the author of the message wants to narrow or redirect the location of future discussion. 2) Provide clear, separate commands for new posting, followup, and E-mail reply The software MUST provide separate, clearly distinguished commands to do each of the following: a) Post a new article, unrelated to any existing one, whose Subject is to be supplied by the user, and which has an empty or missing References: header line. b) Post a followup article, with Subject, Newsgroups, and References header lines derived appropriately from the original article (see #5, #6, and #7 below) c) Reply by e-mail, with Subject and To header lines derived appropriately from the original article (see #5 and #8 below) Software that uses the English language is strongly encouraged to include these phrases -- "Post to newsgroup", "Followup to newsgroup", and "Reply to sender" or "Reply by e-mail" -- in menus, on-line help, and written documentation. It should avoid using other verbs such as "Send" or "Respond" whose meaning is not evident to the user. An ordinary, untrained user should be able to easily pick the correct command. Rationale: Users who post followups when they should send e-mail replies, or vice versa, seem to be an endemic problem. They are almost always using software that doesn't make the difference clear, or doesn't even provide both commands. 3) Cross-posting must be implemented When creating either a new article or a followup, the user MUST be allowed to specify multiple newsgroups, and the software MUST cross-post (not multi-post) to them if more than one is specified. Rationale: Cross-posting is an essential feature of Usenet. If the software cannot cross-post, then its users will multi-post instead. 4) Users must be able to change essential headers in new articles and followups When creating either a new article or a followup, the software MUST allow the user to edit the "Subject", "Newsgroups", "Followup-To", and "Reply-To" specifications. The user MUST be able to edit these at any time during composition of the article; she MUST NOT be limited to specifying them only before, or after, editing the article's text. The software MUST allow the user to specify a new Subject field of at least 71 characters, not including the string "Subject: " itself. It is better not to impose any limit at all, other than the overall son-of-1036 limit of 1000 characters per header line. This does not mean that the software must present raw RFC-1036 headers to the user, or that the headers and body must be an indivisible unit of editable text. A graphical user interface that presents each of these as an editable field in a form will meet the requirement. Rationale: Topics drift as a discussion progresses, and users need the ability to change the Subject header to reflect the drift. Similarly, a user may determine that the discussion no longer belongs in some of the places that it started, or that its continuation needs to go elsewhere. The software must not impede the user's ability to make these judgments, possibly during the composition of her followup article. It's not acceptable to have users who respond to "Please direct followups appropriately" with "I can't; the software won't let me." 5) Followups and e-mail replies must contain correct Subject headers When creating either a followup article or an e-mail reply, the software MUST create an initial header which a) Prepends the four characters "Re: " to the "Subject:" if and only if "Re: " is not already present. Note that there is a space character after the colon in "Re: ". DO NOT prepend non-standard prefixes such as "Re(2): " . b) Preserves the *entire* "Subject" line of the original article. DO NOT chop it off at 20 or 25 or even 80 characters. (The user may later change the Subject, of course; see #4 above.) Exception: You may want to compensate for other people's broken software by stripping off such non-standard prefixes as "Re(2): ", "Re:" (no space), or "Re: Re: " and replacing them with "Re: ". Rationale: These things should be obvious, but many authors of news software don't seem to understand the relevant sections of RFC 1036. Truncated Subject: lines, especially when gratuitous non-ASCII characters are also thrown in, are a major annoyance for users and can make threading difficult or impossible. 6) Followups must be directed to the correct newsgroups When creating a followup article, the software MUST create an initial header in which the "Newsgroups:" field is initialized to the original article's "Followup-To:", if one was provided, or "Newsgroups:", if it wasn't. (The user may later change this field, of course; see #4 above.) Rationale: This is basic RFC 1036 compliance. Software that fails to meet this requirement makes its users look at best foolish or incompetent, and at worst willfully unresponsive to the wishes of other Usenet users. 7) Followups must contain a valid References: header When creating a followup, the software MUST create a References: header line that contains, as its last element, the Message-ID of the original article. I strongly encourage you to include at least three additional message-IDs from the original article's References header as well, if they are available. Try to conform to the spirit of "son-of-1036", which states that Followup agents SHOULD not shorten References headers. If it is absolutely necessary to shorten the header, as a des- perate last resort, a followup agent MAY do this by deleting some of the message IDs. However, it MUST not delete the first message ID, the last three message IDs (including that of the immediate precursor), or any message ID mentioned in the body of the followup. Rationale: Threaded news-readers depend on References: fields to do their magic. 8) E-mail replies must be directed to the correct address When creating an e-mail reply, the software MUST create an initial header in which the "To:" line is initialized to the original article's "Reply-to:", if one was provided, or "From:", if it wasn't. (The user may later change this field, of course; see #4 above.) Rationale: See #6 above. 9) Quotation and attribution must be possible When the users requests a followup or an e-mail reply, the software MUST provide some method for including quoted text from the original article. This quoted text MUST be clearly set off in some way--either by indenting it, or by prepending each line with one or more identifiable characters. If this is a followup (as opposed to an e-mail reply), the quoted text MUST be preceded by an "attribution line" identifying the author of the text that is being quoted. (The user may decide to delete this attribution line or to configure it away, but it MUST be there by default.) Rationale: The ability to easily quote text is essential for users who want to provide a proper context for their followups and e-mail replies. Software that provides attribution lines without quoting ability, or that fails to distinctively set off quoted text from original text, is a major cause of "I didn't say that!" misunderstandings. 10) Subject header is mandatory When creating a new article, the software MUST require the user to provide a non-empty Subject. It MUST NOT post an article without a Subject header or with an empty Subject header. It MUST NOT silently add a "Subject: " header because the user didn't specify a Subject. It MUST allow the user to change the Subject header at any time while editing the main text of the article (see #8 above). Rationale: Most news readers allow users to selectively read articles based on the Subject header. An article without a Subject will probably be ignored by most readers, and it's no service to the user to allow posting of such an article. 11) Must provide valid From: header When creating either a new article or a followup, the software MUST initialize the "From:" header to a syntactically valid e-mail address, which includes a fully-qualified domain name (FQDN). If the software is unable to create such an address -- maybe because it was built with incorrect configuration parameters, or some essential parameter is unavailable at runtime -- then it MUST NOT allow posting at all, unless it can obtain a syntactically valid e-mail address from the user. If feasible, the software should try to guarantee that this address actually belongs to the person using the software, and actually accepts e-mail. Rationale: Invalid e-mail addresses make e-mail replies impossible. TIN seems to be a primary offender here--I've seen "name@", "name@site", "name@.domain", and other invalid From headers from TIN users. The string "NoSubDomain.NoDomain" probably ought to be explicitly disallowed as well. 12) Must allow users to cancel their own articles (and no others!) Any software that posts news MUST allow its user to cancel her own articles. It MUST NOT by default allow the user to cancel articles written by other people. Rationale: People make mistakes and need the ability to correct them. Usenet provides "cancel" for a good reason. 13) Try to respect the 80-character line-length convention Any line breaks shown to the user while she is editing her article should still be present when the article is actually posted to the Net. The software should not show the user four 75-character lines while actually posting a single 300-character line. Nor should it show the user a series of 100-character lines while actually posting alternating lines of 80 and 20 characters each. It's also a good idea to warn the user if the article she is about to post contains non-header lines longer than 80 characters. The software should not prevent the posting, but should ask whether the user wants to re-edit or post anyway. If the news software uses an external editor, the default editor should be one that conforms to the above. Rationale: Articles with long lines are unreadable to many users. Articles with alternating 80/20 lines aren't any better. (I've refrained from using MUST in this one, because I don't want to over-specify the relationship between text editing and news software. I'd appreciate suggestions on how to tighten up this requirement, but they need to take into account the diversity of environments that Usenet software currently runs in.) 14) Try to prevent obvious user errors Posting software should prevent the user from posting a blank article, or at least warn the user that she is trying to do this. Posting software should prevent the user from posting an article that consists entirely of quoted text, or at least warn the user that she is trying to do this. Rationale: Users who do either of these things almost never do them on purpose. They are usually confused by unfamiliar new software. (I've refrained from using MUST here as well, mostly because I don't think very much current software does either of these things, and I don't want to require them in order to get the Seal. But I'd like to encourage future programmers to do them.) In addition to these guidelines, anyone writing Usenet software should pay careful attention to these two documents: RFC 1036, "Standard for Interchange of USENET Messages", by M. Horton and R. Adams. ftp://ftp.internic.net/rfc/rfc1036.txt The proposed "Son of 1036", "News Article Format and Transmission", by Henry Spencer. ftp://ftp.zoo.toronto.edu/pub/news.txt.Z (also news.ps.Z) My hope is that a voluntary committee can be formed, respected by most people on the Net, that reviews Usenet software and decides whether it deserves the "Good Net-Keeping Seal of Approval." People who use broken software that does not have the Seal will be strongly encouraged to switch to software that does. Persistent users of broken non-compliant software may be ostracized, or have their sites shunned. -- Ron Newman MIT Media Laboratory rnewman@media.mit.edu