home *** CD-ROM | disk | FTP | other *** search
/ ftp.pasteur.org/FAQ/ / ftp-pasteur-org-FAQ.zip / FAQ / usenet / software / good-netkeeping-seal < prev    next >
Encoding:
Internet Message Format  |  2004-05-02  |  35.2 KB

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news2.telebyte.nl!humbolt.nl.linux.org!news.nl.linux.org!phil.uu.nl!not-for-mail
  2. From: Jeroen Scheerder <js@phil.uu.nl>
  3. Newsgroups: news.software.readers,comp.os.msdos.mail-news,comp.os.os2.mail-news,comp.sys.mac.comm,comp.os.ms-windows.apps.comm,comp.os.ms-windows.apps.winsock.news,alt.usenet.offline-reader,alt.answers,comp.answers,news.answers
  4. Subject: Good Net-Keeping Seal of Approval 2.0 (GNKSA 2.0) for Usenet Software
  5. Supersedes: <gnksa_1081029603@gnksa.org>
  6. Followup-To: news.software.readers
  7. Date: 2 May 2004 00:00:05 +0200
  8. Organization: NAKA
  9. Lines: 755
  10. Approved: news-answers-request@MIT.EDU
  11. Expires: 19 Jun 2004 22:00:03 GMT
  12. Message-ID: <gnksa_1083448803@gnksa.org>
  13. NNTP-Posting-Host: goedel.admin.phil.uu.nl
  14. X-Trace: husserl.admin.phil.uu.nl 1083448806 11545 131.211.140.24 (1 May 2004 22:00:06 GMT)
  15. X-Complaints-To: abuse@phil.uu.nl
  16. NNTP-Posting-Date: 1 May 2004 22:00:06 GMT
  17. Summary: Guidelines for writers of Usenet reading and posting programs.
  18.   If you follow these guidelines,  you'll  make your users and the rest
  19.   of the Usenet community much happier.
  20. X-Note: This is an updated and revised descendant of Ron Newman's GNKSA 1.2
  21. Xref: senator-bedfellow.mit.edu news.software.readers:173539 comp.os.msdos.mail-news:8035 comp.os.os2.mail-news:27978 comp.sys.mac.comm:335216 comp.os.ms-windows.apps.comm:19630 comp.os.ms-windows.apps.winsock.news:9093 alt.usenet.offline-reader:42521 alt.answers:72716 comp.answers:57020 news.answers:270680
  22.  
  23. Archive-name: usenet/software/good-netkeeping-seal
  24. Posting-Frequency: monthly (first Sunday)
  25. Last-modified: Oct 29 2003
  26. X-Version: 2.09 ($Id: gnksa.hdr,v 1.8 2003/10/29 07:31:42 js Exp $)
  27. URL: <http://www.gnksa.org/>
  28. Maintainer: Jeroen Scheerder <js@gnksa.org>
  29.  
  30. -----BEGIN PGP SIGNED MESSAGE-----
  31. Hash: SHA1
  32.  
  33.             GNKSA * The Good Net-Keeping Seal of Approval
  34.             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  35.  
  36. There's a general perception that Usenet is becoming "noisier" the more
  37. people join it.  There are more blank articles, more mangled headers,
  38. more "me too" responses accompanying many lines of quoted text, more
  39. followup postings to inappropriate newsgroups, more misattributed
  40. quotes, more followups that really should have been e-mail replies, more
  41. excessive cross- and multi-postings, more unreadibly encoded or
  42. otherwise maimed articles.
  43.  
  44. This is often blamed on the new users themselves -- they are called
  45. "clueless newbies", unqualified to participate in Usenet because they
  46. don't know Unix, or use a misdesigned graphical user interface (GUI), or
  47. use an off-line news reader, or use a commercial service such as America
  48. Online or Delphi.
  49.  
  50. I believe most of this anger is misdirected.  The new users aren't
  51. really that different from the old-timers.  What _is_ different is that
  52. many of the old-timers are using relatively well-behaved software,
  53. while many of the newbies are using various PC newsreaders that frequently
  54. violate assumptions that come naturally to people used to well-behaved
  55. readers:
  56.  
  57.   - The user can see the essential header fields, including "Newsgroups"
  58.     and "Followup-To".
  59.   - The user can edit all header fields when composing a followup.
  60.   - There's a clear difference between `followup' and `reply'.
  61.   - Followups preserve the Subject and References of the original
  62.     article, unless the user explicitly changes them.
  63.   - News software respects "Followup-To" and "Reply-To"
  64.     specifications.
  65.   - What the user writes is what gets posted, as is.
  66.  
  67. Newer software should be an improvement over an ancient program like
  68. `rn'.  Instead, much of it is crippled or broken in comparison.
  69.  
  70. The Usenet community can deal with this problem by establishing a "Good
  71. Net-keeping Seal of Approval" for Usenet reading and posting software.
  72. This "Seal" would certify that the software complies with certain
  73. minimal standards, such as those listed below.
  74.  
  75. A group of volunteers will test all putative Usenet software to
  76. determine whether it qualifies for the "Seal", with the intention to
  77. periodically post a list of all tested software to
  78. news.software.readers, alt.usenet.offline-reader, and other appropriate
  79. newsgroups.  This periodic posting will list both compliant and
  80. non-compliant news programs; for non-compliant programs, it will include
  81. a list of all violations of the standards.  The hope is that this will
  82. encourage the authors of non-compliant software to bring their programs
  83. up to "Good Net-Keeping Seal" standards, eventually.
  84.  
  85.  
  86.                               --%-@#@-%--
  87.  
  88.  
  89. These are the proposed standards a Usenet news program should meet to
  90. deserve the "Good Net-Keeping Seal":
  91.  
  92.   1)  Display all essential header information
  93.   2)  Provide clear, separate commands for new posting, followup, and
  94.       e-mail reply
  95.   3)  Provide cross-posting functionality
  96.   4)  Allow users to change essential headers
  97.   5)  Ensure followups and e-mail replies contain a correct Subject
  98.   6)  Direct followups to the correct newsgroups
  99.   7)  Make sure followups contain valid References
  100.   8)  Direct e-mail replies to the correct address
  101.   9)  Allow the user to change her mind about whether to post or mail
  102.   10) Provide adequate quotation and attribution facilities
  103.   11) Provide a user-specified "Subject: " header
  104.   12) Provide a valid "From: " header
  105.   13) Allow users to both cancel and supersede their own articles (and
  106.       _no_ others!)
  107.   14) Try to respect the 80-character line-length conventions
  108.   15) Separate signatures correctly, and don't use excessive ones
  109.   16) Try to prevent obvious user errors
  110.   17) Post human-readable articles unless ordered otherwise
  111.   18) Provide self-protection
  112.   19) Be kind to servers, leave room for others
  113.  
  114. These requirements are described in more detail below.  In the spirit of
  115. RFC 1123 and Henry Spencer's "son of RFC 1036" proposal, I've
  116. capitalized the words "MUST", "MUST NOT", and "DO NOT" to indicate
  117. absolute requirements, while using the word "SHOULD" for things that are
  118. merely a Very Good Idea, Really.
  119.  
  120.  
  121.                               --%-@#@-%--
  122.  
  123.  
  124. 1)  Display all essential header information
  125.  
  126. When displaying a news article, it MUST by default show the user certain
  127. information that is found in the article's header.  The information need
  128. not be displayed as actual RFC-1036 header lines, but it MUST be shown
  129. to the user in some form.
  130.  
  131.   a) The author of the article (its "From: " header line)
  132.  
  133.   b) The article's Subject.  At least the first 70 characters
  134.      following the "Subject: " string MUST be displayed.
  135.  
  136.   c) The list of newsgroups the article was posted to.  This list MUST
  137.      be displayed in full, never truncated.  This list need not be
  138.      displayed if it has only one element, provided that the software
  139.      displays the name of the newsgroup that the user is currently
  140.      reading.
  141.  
  142.   d) The article's Followup-To list, if this is different from the
  143.      Newsgroups list.  This MUST be displayed in full, never
  144.      truncated.
  145.  
  146.   e) The article's Reply-To, if this is different from the From
  147.      specification.
  148.  
  149. If the required information does not fit fully on the display, the
  150. software MAY display only the initial part of the information, provided
  151. that it offers the user a scrollbar or equivalent means of viewing the
  152. remainder.
  153.  
  154. The software MAY allow the user to re-configure it so as to turn off
  155. these displays, but if the user has not done this, all of the required
  156. information MUST be displayed.
  157.  
  158. Rationale: Without having to make any special effort the user should see
  159. who sent the article she is reading, how to reply to it via e-mail, what
  160. discussion groups it was posted to, and whether the author of the
  161. message wants to narrow or redirect the location of future discussion.
  162.  
  163.  
  164. 2)  Provide clear, separate commands for new posting, followup, and
  165.     e-mail reply
  166.  
  167. The software MUST provide separate, clearly distinguished commands to do
  168. each of the following:
  169.  
  170.   a) Post a new article, unrelated to any existing one, whose Subject
  171.      is to be supplied by the user, and which has an empty or missing
  172.      References: header line.
  173.  
  174.   b) Post a followup article, with Subject, Newsgroups, and References
  175.      header lines derived appropriately from the original article.
  176.                                              (see #5, #6, and #7 below)
  177.  
  178.   c) Reply by e-mail, with "Subject: " and "To: " headers derived
  179.      appropriately from the original article.     (see #5 and #8 below)
  180.  
  181. Software that uses the English language is strongly encouraged to
  182. include the phrases "Post to newsgroup", "Followup to newsgroup", and
  183. "Reply by e-mail" (or "Reply to sender" or "Reply to author") -- in
  184. menus, on-line help, and written documentation.  It SHOULD avoid using
  185. other verbs such as "Send" or "Respond" whose meaning is not evident to
  186. the user.  An ordinary, untrained user SHOULD be able to easily pick the
  187. correct command.
  188.  
  189. Rationale: Users who post followups when they should send e-mail
  190. replies, or vice versa, seem to be an endemic problem.  They are almost
  191. always using software that doesn't make the difference clear, or doesn't
  192. even provide both commands.
  193.  
  194.  
  195. 3)  Provide cross-posting functionality
  196.  
  197. When creating either a new article or a followup, the user MUST be
  198. allowed to specify multiple newsgroups, and the software MUST cross-post
  199. (not multi-post) to them if more than one is specified.
  200.  
  201. Posting software SHOULD prevent the user from excessive cross-posting,
  202. or at least warn against it.  If posting to a very large number of
  203. groups, the user SHOULD either be forced or strongly suggested to set a
  204. "Followup-To" header.  Such a header must be subjected to restrictions
  205. that are at least as strict as those imposed on "Newsgroups: ".
  206.  
  207. Rationale: Cross-posting is an essential feature of Usenet.  If the
  208. software cannot cross-post, then its users will multi-post instead.  A
  209. reasonable attempt should be made, however, to protect the user against
  210. (usually inadvertent; if not, often considered net-abuse) excessive
  211. cross-postings that will only lead to canceling and flame warfare.
  212.  
  213.  
  214. 4) Allow users to change essential headers
  215.  
  216. When creating either a new article or a followup, the software MUST
  217. allow the user to edit the Subject, Newsgroups, Followup-To, and
  218. Reply-To specifications.  The user MUST be able to edit these at any
  219. time during composition of the article; she MUST NOT be limited to
  220. specifying them only before, or after, editing the article's text.
  221.  
  222. The software MUST allow the user to specify a new Subject field of at
  223. least 70 characters, not including the string "Subject: " itself.  It is
  224. better not to impose any limit at all, other than the overall
  225. son-of-1036 limit of 998 characters (see #7) per header line.
  226.  
  227. The software MUST allow the user to specify "Followup-To: poster", which
  228. tells readers of the article that the user prefers e-mail replies rather
  229. than followups to the newsgroup.
  230.  
  231. This does not mean that the software must present raw RFC-1036 headers
  232. to the user, or that the headers and body must be an indivisible unit of
  233. editable text.  A graphical user interface that presents each of these
  234. as an editable field in a form will meet the requirement.
  235.  
  236. Rationale: Topics drift as a discussion progresses, and users need the
  237. ability to change the Subject header to reflect the drift. Similarly, a
  238. user may determine that the discussion no longer belongs in some of the
  239. places that it started, or that its continuation needs to go elsewhere. 
  240. The software must not impede the user's ability to make these
  241. judgments, possibly during the composition of her followup article.  
  242. It's not acceptable to have users who respond to "Please direct
  243. followups appropriately" with "I can't; the software won't let me."
  244.  
  245.  
  246. 5) Ensure followups and e-mail replies contain a correct Subject
  247.  
  248. When creating either a followup article or an e-mail reply, the software
  249. MUST create an initial "Subject: " header which
  250.  
  251.   a) Prepends the four characters "Re: " to the Subject if and only if
  252.      "Re: " is not already present.  Note that this contains an
  253.      upper-case "R", a lower-case "e", and a trailing space.  DO NOT
  254.      prepend non-standard prefixes such as "Re^2: " .
  255.  
  256.   b) Preserves the *entire* Subject of the original article. DO NOT
  257.      chop it off at 20 or 25 or even 80 characters.  DO NOT append
  258.      spaces or any other characters to the end.  DO NOT change the
  259.      case of any character in the original Subject; in particular, DO
  260.      NOT change the Subject to all-upper-case or all-lower-case.
  261.  
  262.   (The user may later change the Subject, of course; see #4 above.)
  263.  
  264. Exception: The software MAY try to compensate for other people's broken
  265. software by replacing non-standard prefixes (such as "Re^2: ", "Re(2):
  266. ", "Re:" (no space), "RE: ", "re: " , or "Re: Re: ")  by the standard
  267. prefix "Re: ".
  268.  
  269. Rationale: These things should be obvious, but many authors of news
  270. software don't seem to understand the relevant sections of RFC 1036. 
  271. Truncated "Subject: " headers, especially when gratuitous non-ASCII
  272. characters are also thrown in, are a major annoyance for users and can
  273. make threading difficult or impossible.
  274.  
  275.  
  276. 6) Direct followups to the correct newsgroups
  277.  
  278. When creating a followup article, the software MUST create an initial
  279. header in which the Newsgroups field is initialized to the original
  280. article's Followup-To, if one was provided, or Newsgroups, if it wasn't.
  281. (The user may later change this field, of course; see #4 above.)
  282.  
  283. If the original article's "Followup-To: " header is set to "poster", the
  284. software MUST warn the user that the original poster requested an e-mail
  285. reply, and generate an e-mail reply by default.
  286.  
  287. Rationale: This is basic RFC 1036 compliance.  Software that fails to
  288. meet this requirement makes its users look at best foolish or
  289. incompetent, and at worst willfully unresponsive to the wishes of other
  290. Usenet users.
  291.  
  292.  
  293. 7) Make sure followups contain valid References
  294.  
  295. When creating a followup, the software MUST create a "References: "
  296. header line that contains, as its last element, the Message-ID of the
  297. original article.  An individual Message-ID MUST never be truncated.
  298.  
  299. The software MUST include at least three additional Message-IDs from
  300. the original article's References header as well, if they are available.
  301. Try to stay as close as possible to the spirit of "son-of-1036", which
  302. states:
  303.  
  304.         <<Followup agents SHOULD not shorten References  headers.   If
  305.           it  is absolutely necessary to shorten the header, as a des-
  306.           perate last resort, a followup agent MAY do this by deleting
  307.           some  of  the  message IDs.  However, it MUST not delete the
  308.           first message ID, the last three message IDs (including that
  309.           of  the immediate precursor), or any message ID mentioned in
  310.           the body of the followup.>>
  311.  
  312. However, it also says:
  313.  
  314.         <<If  it  is  absolutely  necessary  for  an implementation to
  315.           impose a limit on the length of header lines, body lines, or
  316.           header  logical  lines,  that  limit  shall be at least 1000
  317.           octets, including EOL representations.>>
  318.  
  319. So, bear in mind that news transports are not guaranteed to be able to
  320. handle arbitrary long lines.  Furthermore, keep in mind that some news
  321. transports choke on continued (multi-line) "References: " headers.
  322.  
  323. Therefore, keep as many Message-IDs as will fit on a line starting with
  324. "References: " with a maximum length of 998 characters.  (An octet is a
  325. byte of 8 bits, EOL representation takes two bytes.)
  326.  
  327. Exception: Damaged (truncated) Message-IDs SHOULD NOT be included.
  328. Neither should `bogus' Message-IDs -- IDs that somehow got inserted (by
  329. a misguided user, maybe) but don't belong to the thread.
  330.  
  331. Rationale: Threaded news-readers depend on References to do their magic.
  332. This too is basic RFC compliance.  Be as complete as the line length
  333. limit allows, but do not propagate errors.
  334.  
  335.  
  336. 8) Direct e-mail replies to the correct address
  337.  
  338. When creating an e-mail reply, the software MUST create an initial
  339. header in which the "To: " header is initialized to the original
  340. article's Reply-to, if one was provided, or From if it wasn't.  (The
  341. user may later change this field, of course; see #4 above.)
  342.  
  343. Rationale: See #6 above.
  344.  
  345.  
  346. 9) Allow the user to change her mind about whether to post or mail
  347.  
  348. With any followup or reply message, the software SHOULD offer the user
  349. the option to change her mind about whether to post or to mail, and may
  350. allow doing both.
  351.  
  352. If the software has the option to post as well as mail a single
  353. response, that option MUST NOT be default behavior, neither by factory
  354. default nor by user-configuration.  Furthermore, when both posting and
  355. mailing a message, the mailed message's body SHOULD be preceded by a
  356. line clearly stating that the message is an email copy of a usenet
  357. posting.
  358.  
  359. Rationale: People digress when writing, and may find themselves posting
  360. a message that would have been more appropriate for private
  361. communication, or mailing a message that would have been more
  362. appropriately directed to the general audience.  Unsolicited mail
  363. messages are highly unwanted by many users (had they wanted e-mail
  364. replies, they could, should and, for all a reader can assume would, have
  365. requested them).
  366.  
  367.  
  368. 10) Provide adequate quotation and attribution facilities
  369.  
  370. When the user requests a followup or an e-mail reply, the software MUST
  371. provide some method for including quoted text from the original article.
  372. This quoted text MUST be clearly set off in some way -- either by
  373. indenting it, or by prepending each line with one or more identifiable
  374. characters.  The quote prefix SHOULD be `>', with optionally a trailing
  375. space (i.e. `> ').
  376.  
  377. Caveat: with `>', the level of quotation is clearly reflected in the
  378.         number of `>' characters at the start of the line.   However,
  379.         whitespace between quote prefix and quoted material improves
  380.         readability, so it is good practice for newsreaders to use `> '
  381.         as the quote prefix for newly quoted, and `>' for repetitively
  382.         quoted text.
  383.  
  384. Included text SHOULD NOT contain the original article's signature,
  385. unless by explicit request of the user (under the condition that the
  386. signature can be determined of course, which is to say: if clearly
  387. separated by the standard signature delimiter). (see also #15 below).
  388.  
  389. As a direct counterpart to this requirement, the software SHOULD offer
  390. the user some means of selecting exactly which part of a Usenet posting
  391. she wishes to followup to, and quote only that part initially.  (A
  392. special case of this is when a user wishes to react to what's in a
  393. signature.)
  394.  
  395. If it concerns a followup (as opposed to an e-mail reply), the quoted
  396. text MUST be preceded by an "attribution line" identifying the author of
  397. the text that is being quoted.  (The user may decide to delete this
  398. attribution line or to configure it away, but it MUST be there by
  399. default.)
  400.  
  401. Rationale: The ability to easily quote text is essential for users who
  402. want to provide a proper context for their followups and e-mail replies.
  403. Software that provides attribution lines without quoting ability, or
  404. that fails to distinctively set off quoted text from original text, is a
  405. major cause of "I didn't say that!" misunderstandings.  By convention,
  406. quoted lines start with `>', and much software depends on this do
  407. distinguish quoted material from original lines, for presentation
  408. purposes.  Users can be careless or forgetful occasionally (or often,
  409. even) and neglect to edit out spurious quoted material; the signature,
  410. typically, is such material.  In general, facilitating good quoting
  411. behaviour -- by quoting only a part indicated by the user, for example
  412. - - -- is an area in which software can help users substantially to create
  413. better articles.
  414.  
  415.  
  416. 11) Provide a user-specified "Subject: " header
  417.  
  418. When creating a new article, the software MUST require the user to
  419. provide a non-empty Subject.  It MUST NOT post an article without a
  420. "Subject: " header or with an empty "Subject: " header.  It MUST NOT
  421. silently add a default Subject (like "Subject: <None>") if the user
  422. didn't specify one.  It MUST allow the user to change the Subject at any
  423. time while editing the main text of the article (see #4 above).
  424.  
  425. Rationale: An article without a Subject provides no clues for deciding
  426. to read it or not.  For that reason, it's likely to be widely ignored,
  427. and it's no service to the user to allow posting of such an article;
  428. while other readers may read it, only to find out they needn't have
  429. bothered when it annoyingly turns out to be of no interest.
  430.  
  431.  
  432. 12) Provide a valid "From: " header
  433.  
  434. When creating either a new article or a followup, the software MUST
  435. initialize the "From: " header to a syntactically valid e-mail address,
  436. which includes a fully-qualified domain name (FQDN).
  437.  
  438. This requirement must be met regardless of whether the software
  439.  
  440.   (a) creates the "From: " header when it first creates the article to
  441.       be edited by the user, or
  442.  
  443.   (b) adds the "From: " header automatically after the user finishes
  444.       editing the article and requests that it be submitted.
  445.  
  446. If the software allows the user to edit the "From: " header, it SHOULD
  447. check that the user supplied a syntactically valid address.
  448.  
  449. If the software is unable to create such an address -- maybe because it
  450. was built with incorrect configuration parameters, or some essential
  451. parameter is unavailable at runtime -- then it MUST NOT allow posting at
  452. all, unless it can obtain a syntactically valid e-mail address from the
  453. user.
  454.  
  455. If feasible, the software SHOULD try to guarantee that this address
  456. actually belongs to the person using the software, and actually accepts
  457. e-mail.
  458.  
  459. Rationale: Mail and news transport systems and user agents, gateways and
  460. processing software may choke on syntactically invalid headers.  Invalid
  461. e-mail addresses make e-mail replies impossible; see Greg Byshank's
  462. "Help! I've been spammed!" document for an excellent discussion of the
  463. issues involved.
  464.  
  465.  
  466. 13) Allow users to both cancel and supersede their own articles (and
  467.     _no_ others!)
  468.  
  469. Any software that posts news SHOULD provide a command that the user can
  470. invoke to cancel her own articles.  It SHOULD also provide the option to
  471. supersede the user's own articles.  The software MUST guarantee that
  472. the user cannot cancel or supersede other people's articles, as far as
  473. possible.
  474.  
  475. Caveat: since completely reliable authentication can be infeasible, the
  476.         best the software can do is to make a good-faith effort to
  477.         determine whether or not cancelling or superseding is valid:
  478.         i.e. by trusting upon its user configuration and checking it
  479.         against the relevant header(s) in the target article.
  480.  
  481. If the software uses the English language, the text of the cancel
  482. command SHOULD include the word "cancel", rather than non-standard verbs
  483. such as "delete".  Similarly, in English software, the text of the
  484. supersede command SHOULD include the word "supersede".
  485.  
  486. Rationale: People make mistakes and need the ability to revoke or
  487. correct them; both `cancel' and `supersede' exist for good reasons. 
  488. However, software should not encourage users to abuse the net, either
  489. intentionally or accidentally, by sending unauthorized (`rogue') cancels
  490. or supersedes.  The supersede option is essential: due (a.o.) to
  491. sometimes unpredictable usenet propagation, a "cancel-cum-repost" may
  492. behave very different from a "supersede".  News servers might also have
  493. different acceptance policies for both.
  494.  
  495.  
  496. 14) Try to respect the 80-character line-length conventions
  497.  
  498. Any line breaks shown to the user while she is editing her article
  499. SHOULD still be present when the article is actually posted to the Net.
  500. The software SHOULD NOT show the user four 75-character lines while
  501. actually posting a single 300-character line.  Nor should it show the
  502. user a series of 100-character lines while actually posting alternating
  503. lines of 80 and 20 characters each.
  504.  
  505. It's also a good idea to warn the user if the article she is about to
  506. post contains non-header lines longer than 80 characters.  The software
  507. SHOULD NOT prevent the posting, but SHOULD ask whether the user wants to
  508. re-edit or post anyway.
  509.  
  510. Caveat: Occasionally, there are very good reasons for posting long lines
  511.         (for example, when posting a source code snippet containing
  512.         something that will break when wrapped, or when there's a need
  513.         to post something "as is", unreformatted -- unaltered and
  514.         completely intact).  For that reason (re)wrapping cannot be a
  515.         MUST: a SHOULD is all it can be.
  516.  
  517. To get well-readable articles, the user SHOULD be provided with the
  518. possibility to rewrap excessively long lines of quoted text, respecting
  519. quotation -- i.e. have the option to correct `inherited' bad formatting.
  520. Also, tabs SHOULD be expanded to prevent the so-called `tab damage' that
  521. may occur when someone reading your article uses a different tab size.
  522.  
  523. Caveat: Due to the immense variety in quoting styles, quoted text
  524.         reformatting can be extremely hard, practically impossible even.
  525.         No software can be expected to deal with everything; still,
  526.         since the overwhelming majority can be dealt relatively easily,
  527.         it is not unreasonable to expect it from software, if it is to
  528.         be well-equipped for the task of editing Usenet articles.
  529.  
  530. If the news software uses an external editor, the default editor SHOULD
  531. conform to the above.
  532.  
  533. Rationale: Articles with long lines are unreadable to many users.
  534.            Articles with alternating 80/20 lines aren't any better.
  535.  
  536.  
  537. 15) Separate signatures correctly, and don't use excessive ones
  538.  
  539. Posting software SHOULD separate any signature appended to outgoing
  540. articles from the main text with a line containing only `-- ' ("dash
  541. dash space"). To quote son-of-rfc1036:
  542.  
  543.         <<If  a  poster or posting agent does append a signature to an
  544.           article, the signature SHOULD be preceded with  a  delimiter
  545.           line  containing  (only)  two hyphens (ASCII 45) followed by
  546.           one blank (ASCII  32).   Posting  agents  SHOULD  limit  the
  547.           length  of  signatures,  since  verbose  excess bordering on
  548.           abuse is common if no restraint is imposed;  4  lines  is  a
  549.           common limit.>>
  550.  
  551. Hence, posting software SHOULD prevent the user from using excessively
  552. long signatures, or at least warn the user against it.  A widely
  553. accepted standard is the so-called McQuary limit: up to 4 lines, each up
  554. to a maximum of 80 characters.
  555.  
  556. Rationale: Being confronted with (possibly excessively long) signatures
  557. repetitively is, or can be, annoying to many.  Being able to separate
  558. the main text and the signature clearly is important, not only to
  559. prevent the possible mistake of misinterpreting a signature, but also to
  560. enable automatic signature suppression for those who wish to do so.
  561.  
  562.  
  563. 16) Try to prevent obvious user errors
  564.  
  565. * Posting software MUST warn the user for posting empty articles, and
  566.   SHOULD prevent doing so entirely.
  567.  
  568. * Posting software MUST warn the user about posting articles consisting
  569.   entirely of quoted text, and SHOULD prevent doing so entirely.
  570.  
  571. * Posting software MUST warn the user severely when attempting to post
  572.   an article over and over again, and SHOULD do everything it can to
  573.   prevent doing so entirely.
  574.  
  575.   - When posting `asynchronously' (i.e.  when sacrificing knowledge
  576.     about progress, success or failure by handing over the task
  577.     completely to some separate process) it SHOULD NOT allow the user
  578.     to post articles again, once the user issued the final "post"
  579.     command.
  580.  
  581.   - When posting `synchronously', the software has at least partial
  582.     knowledge about progress, and full knowledge about success or
  583.     failure of an attempt to post.  In this case, it SHOULD inform the
  584.     user clearly that the article is being posted while attempting to
  585.     post it; after the attempt, it MUST unequivocally inform the user
  586.     that posting succeeded if it did, and that it failed otherwise.
  587.  
  588. Note: So-called `online' newsreaders usually (but not necessarily)
  589.       post synchronously, while a number so-called `offline' newsreading
  590.       methods (especially the scheduled, batch-oriented ones) usually
  591.       employ asynchronous posting.  However, offline newsreaders using
  592.       NNTP for news transport usually post synchronously, i.e.  are in
  593.       direct interaction with the newsserver, hence get immediate
  594.       results, when posting.
  595.  
  596. Rationale: Users who do any of these things almost never do them on
  597. purpose.  They are usually confused by unfamiliar new software, and
  598. should be offered basic protection.
  599.  
  600.  
  601. 17) Post human-readable articles unless ordered otherwise
  602.  
  603. Posting software MUST by default post only legible usenet articles.  In
  604. a different formulation: it MUST NOT encode or encrypt articles, unless
  605. by explicit user demand.  Hence, it MUST NOT even have the option to
  606. encode or encrypt by default.  Whenever some encoding/encryption will be
  607. used, clear feedback showing that it's in effect MUST be provided to the
  608. user, so she is permanently reminded of the fact that her article will
  609. not be posted as composed.  The worst DO NOT is the combination of
  610. allowing default encoding without even taking the trouble of telling
  611. (warning) the user about it.
  612.  
  613. Note: Common occurrences of this kind of content maiming unasked for,
  614.       and untold to, the user, are HTML- and MIME multi-part
  615.       and/or base64 encodings, as found in newsreaders integrated in
  616.       WWW-browsers better not mentioned.
  617.  
  618. Rationale: Many users may not be able to read (particular) encoded or
  619. encrypted articles at all, or only at the expense of a considerable
  620. effort: such articles ask to be widely ignored. Encouraging posting
  621. maimed messages is a service neither to the user herself, nor to her
  622. audience.  Keep in mind that not everyone shares your particular setup
  623. (newsreader, configuration, operating system), nor should (and can)
  624. anyone be forced to do so, in order to be able to read your articles.
  625.  
  626.  
  627. 18) Provide self-protection
  628.  
  629. News readers SHOULD allow the user to protect herself by filtering out
  630. articles she really does not want to read.  These filtering facilities
  631. SHOULD be sufficiently powerful to enable ignoring postings by
  632. particular persons, about particular subjects, and particular
  633. cross-posts.
  634.  
  635. Rationale: While it looks as if not having filtering only affects the
  636. user herself, people tend to take it out on the net if they are
  637. repetitively (structurally) annoyed by a particular class of postings,
  638. and will be inclined to start canceling, advocate posting restriction or
  639. engage in flame warfare, all of which is harmful to other users.
  640.  
  641.  
  642. 19) Be kind to servers, leave room for others
  643.  
  644. Reading or posting software MUST NOT put excessive demands on news
  645. servers unnecessarily.  The sofware MUST limit itself to 4 simultaneous
  646. connections to a given server.  Spurious connects and unnecessary
  647. traffic MUST be avoided; the software MUST use as few as possible
  648. connections, reusing existing connections whenever possible.
  649.  
  650. Rationale: News systems are big, resources are scarce, and every
  651. resource claimed is provided at the expense of other users.
  652.  
  653.  
  654.                               --%-@#@-%--
  655.  
  656.  
  657. Please remember that this is a set of _minimum_ guidelines to guarantee
  658. that a given piece of software interacts properly with the rest of the
  659. Usenet world.  It is not a general "wish list" of everyone's favorite
  660. features.  I have deliberately avoided taking a position on certain
  661. controversial issues -- for example, whether the user should be allowed
  662. to edit the "Sender: " header, whether news software should prohibit
  663. posting an article that has more quoted text than new text, or whether
  664. posting with certain particular Subjects should be prohibited.
  665.  
  666.  
  667. My hope is that a voluntary committee can be formed, respected by many
  668. people on the Net, that reviews Usenet software and decides whether it
  669. deserves the "Good Net-Keeping Seal of Approval." People who use broken
  670. software that does not have the Seal should then be strongly encouraged
  671. to switch to software that does.
  672.  
  673.  
  674. References and additional reading
  675. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  676.  
  677. The current GNKSA, an evaluation form and an archive of software
  678. evaluations can be found at:
  679.  
  680.   <http://www.xs4all.nl/%7Ejs/gnksa/>
  681.   <http://newsreaders.com/gnksa/> (Mirror)
  682.   <http://newsreaders.com/misc/twpierce/news/> (GNKSA 1.2)
  683.  
  684. The GNKSA page also contains a pointer to a library that newsreader
  685. developers can freely make use of, providing basic `sanitary' functions.
  686.  
  687. In addition to the Seal, anyone writing Usenet software should pay
  688. careful attention to the following documents:
  689.  
  690.   RFC 977, "Network News Transfer Protocol -- A Proposed Standard for
  691.   the Stream-Based Transmission of News", by Brian Kantor and Phil
  692.   Lapsley.
  693.         <ftp://ftp.internic.net/rfc/rfc977.txt>
  694.  
  695.   RFC 1036, "Standard for Interchange of USENET Messages", by
  696.   M. Horton and R. Adams.
  697.         <ftp://ftp.internic.net/rfc/rfc1036.txt>
  698.  
  699.   The proposed "Son of 1036", "News Article Format and Transmission",
  700.   by Henry Spencer.
  701.         <ftp://ftp.zoo.toronto.edu/pub/news.txt.Z>    (also news.ps.Z)
  702.  
  703.   "The UseFor Working Group Documents" (under development: Internet
  704.   Drafts describing the minimal standards for a Usenet article, and
  705.   the minimum features all Usenet software should have), by Simon
  706.   Lyall (et al.).
  707.         <http://www.landfield.com/usefor/>
  708.  
  709.   "Read This Before You Write a Newsreader, News Transport
  710.   System, etc.", by Tom Limoncelli.
  711.         <http://www.xs4all.nl/%7Ejs/gnksa/read-before.txt>
  712.  
  713.   "The "Good Net-Keeping Seal of Approval", revision 1.2, by Ron
  714.   Newman; the previous version of this document, published in
  715.   January, 1995.
  716.         <http://www2.thecia.net/users/rnewman/Good-Netkeeping-Seal>
  717.  
  718. Excellent collections of things well worth reading in this context can
  719. be found at:
  720.  
  721.   "News Hacking", by Tim Pierce.
  722.         <http://newsreaders.com/misc/twpierce/news/>
  723.  
  724.   "Notes on News", by Lars Magne Ingebrigtsen.
  725.         <http://quimby.gnus.org/notes/notes.html>
  726.  
  727. A very informative overview of the issues concerning some forms of net
  728. abuse, and how and how not to deal with it, is:
  729.  
  730.   "Help! I've been Spammed! What do I do?", by Greg Byshenk, based in
  731.   part on an original by Chris Lewis, Posted weekly to news.answers,
  732.   news.newusers.questions, and news.admin.net-abuse.misc.
  733.         <http://www.byshenk.net/ive.been.spammed.html>
  734.   The part that explicitly deals with the issues of messing up
  735.   "From: "-headers is:
  736.         <http://www.byshenk.net/ive.been.spammed.html#2.3>
  737.  
  738. Of related interest -- if you're willing to contribute, or are just
  739. interested in the way things are developing -- could also be the IETF
  740. NNTP Working Group's "attempt to revise NNTP and bring it into the
  741. 1990s".
  742.         <http://www.academ.com/academ/nntp/ietf.html>
  743.  
  744.  
  745. Acknowledgements
  746. ~~~~~~~~~~~~~~~~
  747.  
  748. Simon Lyall c.s., for the praiseworthy UseFor (Usenet Format) Working
  749. Group initiative (and its derivatives).
  750.  
  751. Ron Newman <rnewman@theCIA.net>, of course, for writing the first
  752. version of the GNKSA, of which this document descends, and for
  753. fruitful discussions during revision.
  754.  
  755. Sven Guckes <guckes@math.fu-berlin.de> for providing mailing list
  756. resources (among other things).
  757.  
  758. Tim Pierce <twpierce@midway.uchicago.edu> for scrutinous examination,
  759. useful hints, and previous GNKSA support.
  760.  
  761. Larry Wall <lwall@netlabs.com>, Stefan Haller <stk@berlin.snafu.de>,
  762. John E. Davis <davis@space.mit.edu>, John Norstad <j-norstad@nwu.edu>,
  763. Karl-Johan Johnsson <su95-kjo@nada.kth.se>, Brian Clark <baclark@nwu.edu>,
  764. Simon Fraser <smfr@best.com> for showing inspiring examples of the spirit
  765. of good net keeping in the form of exceptionally well-designed usenet
  766. reading programs.
  767.  
  768. The kind folks of news.software.readers (you know who you are) that
  769. have helped discussing the issues that pertain to the GNSKA cause.
  770.  
  771. -----BEGIN PGP SIGNATURE-----
  772. Version: PGP 7.0
  773.  
  774. iQA/AwUBP59ryKiSBiUDcwTdEQJDqwCdEzcmH+jz54lUTtjRvNIfHwk348cAn01r
  775. HKnj72IXRCeCtRfue0xRz06O
  776. =ZeUt
  777. -----END PGP SIGNATURE-----
  778.