home *** CD-ROM | disk | FTP | other *** search
- 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
- From: Jeroen Scheerder <js@phil.uu.nl>
- 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
- Subject: Good Net-Keeping Seal of Approval 2.0 (GNKSA 2.0) for Usenet Software
- Supersedes: <gnksa_1081029603@gnksa.org>
- Followup-To: news.software.readers
- Date: 2 May 2004 00:00:05 +0200
- Organization: NAKA
- Lines: 755
- Approved: news-answers-request@MIT.EDU
- Expires: 19 Jun 2004 22:00:03 GMT
- Message-ID: <gnksa_1083448803@gnksa.org>
- NNTP-Posting-Host: goedel.admin.phil.uu.nl
- X-Trace: husserl.admin.phil.uu.nl 1083448806 11545 131.211.140.24 (1 May 2004 22:00:06 GMT)
- X-Complaints-To: abuse@phil.uu.nl
- NNTP-Posting-Date: 1 May 2004 22:00:06 GMT
- Summary: Guidelines for writers of Usenet reading and posting programs.
- If you follow these guidelines, you'll make your users and the rest
- of the Usenet community much happier.
- X-Note: This is an updated and revised descendant of Ron Newman's GNKSA 1.2
- 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
-
- Archive-name: usenet/software/good-netkeeping-seal
- Posting-Frequency: monthly (first Sunday)
- Last-modified: Oct 29 2003
- X-Version: 2.09 ($Id: gnksa.hdr,v 1.8 2003/10/29 07:31:42 js Exp $)
- URL: <http://www.gnksa.org/>
- Maintainer: Jeroen Scheerder <js@gnksa.org>
-
- -----BEGIN PGP SIGNED MESSAGE-----
- Hash: SHA1
-
- GNKSA * The Good Net-Keeping Seal of Approval
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
- There's a general perception that Usenet is becoming "noisier" the more
- people join it. There are more blank articles, more mangled headers,
- more "me too" responses accompanying many lines of quoted text, more
- followup postings to inappropriate newsgroups, more misattributed
- quotes, more followups that really should have been e-mail replies, more
- excessive cross- and multi-postings, more unreadibly encoded or
- otherwise maimed articles.
-
- 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 misdesigned graphical user interface (GUI), or
- use an off-line news reader, or use a commercial service such as America
- Online 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 relatively well-behaved software,
- while many of the newbies are using various PC newsreaders that frequently
- violate assumptions that come naturally to people used to well-behaved
- readers:
-
- - The user can see the essential header fields, including "Newsgroups"
- and "Followup-To".
- - The user can edit all header fields when composing a followup.
- - There's a clear difference between `followup' and `reply'.
- - Followups preserve the Subject and References of the original
- article, unless the user explicitly changes them.
- - News software respects "Followup-To" and "Reply-To"
- specifications.
- - What the user writes is what gets posted, as is.
-
- Newer software should be an improvement over an ancient program like
- `rn'. Instead, much of it is crippled or broken in comparison.
-
- The Usenet community can 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
- minimal standards, such as those listed below.
-
- A group of volunteers will test all putative Usenet software to
- determine whether it qualifies for the "Seal", with the intention to
- periodically post a list of all tested software to
- news.software.readers, alt.usenet.offline-reader, 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. The hope is that this will
- encourage the authors of non-compliant software to bring their programs
- up to "Good Net-Keeping Seal" standards, eventually.
-
-
- --%-@#@-%--
-
-
- These are the proposed standards a Usenet news program should meet to
- deserve the "Good Net-Keeping Seal":
-
- 1) Display all essential header information
- 2) Provide clear, separate commands for new posting, followup, and
- e-mail reply
- 3) Provide cross-posting functionality
- 4) Allow users to change essential headers
- 5) Ensure followups and e-mail replies contain a correct Subject
- 6) Direct followups to the correct newsgroups
- 7) Make sure followups contain valid References
- 8) Direct e-mail replies to the correct address
- 9) Allow the user to change her mind about whether to post or mail
- 10) Provide adequate quotation and attribution facilities
- 11) Provide a user-specified "Subject: " header
- 12) Provide a valid "From: " header
- 13) Allow users to both cancel and supersede their own articles (and
- _no_ others!)
- 14) Try to respect the 80-character line-length conventions
- 15) Separate signatures correctly, and don't use excessive ones
- 16) Try to prevent obvious user errors
- 17) Post human-readable articles unless ordered otherwise
- 18) Provide self-protection
- 19) Be kind to servers, leave room for others
-
- These requirements are described in more detail below. In the spirit of
- RFC 1123 and 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, Really.
-
-
- --%-@#@-%--
-
-
- 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 in some form.
-
- a) The author of the article (its "From: " header line)
-
- b) The article's Subject. At least the first 70 characters
- following the "Subject: " string MUST be displayed.
-
- c) The list of newsgroups the article was posted to. This list MUST
- be displayed in full, never truncated. This list 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.
-
- 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.
-
- If the required information does not fit fully on the display, the
- software MAY display only the initial part of the information, provided
- that it offers the user a scrollbar or equivalent means of viewing the
- remainder.
-
- 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 required
- information MUST be displayed.
-
- Rationale: Without having to make any special effort the user should see
- 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: " headers derived
- appropriately from the original article. (see #5 and #8 below)
-
- Software that uses the English language is strongly encouraged to
- include the phrases "Post to newsgroup", "Followup to newsgroup", and
- "Reply by e-mail" (or "Reply to sender" or "Reply to author") -- 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) Provide cross-posting functionality
-
- 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.
-
- Posting software SHOULD prevent the user from excessive cross-posting,
- or at least warn against it. If posting to a very large number of
- groups, the user SHOULD either be forced or strongly suggested to set a
- "Followup-To" header. Such a header must be subjected to restrictions
- that are at least as strict as those imposed on "Newsgroups: ".
-
- Rationale: Cross-posting is an essential feature of Usenet. If the
- software cannot cross-post, then its users will multi-post instead. A
- reasonable attempt should be made, however, to protect the user against
- (usually inadvertent; if not, often considered net-abuse) excessive
- cross-postings that will only lead to canceling and flame warfare.
-
-
- 4) Allow users to change essential headers
-
- 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 70 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 998 characters (see #7) per header line.
-
- The software MUST allow the user to specify "Followup-To: poster", which
- tells readers of the article that the user prefers e-mail replies rather
- than followups to the newsgroup.
-
- 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) Ensure followups and e-mail replies contain a correct Subject
-
- When creating either a followup article or an e-mail reply, the software
- MUST create an initial "Subject: " header which
-
- a) Prepends the four characters "Re: " to the Subject if and only if
- "Re: " is not already present. Note that this contains an
- upper-case "R", a lower-case "e", and a trailing space. DO NOT
- prepend non-standard prefixes such as "Re^2: " .
-
- b) Preserves the *entire* Subject of the original article. DO NOT
- chop it off at 20 or 25 or even 80 characters. DO NOT append
- spaces or any other characters to the end. DO NOT change the
- case of any character in the original Subject; in particular, DO
- NOT change the Subject to all-upper-case or all-lower-case.
-
- (The user may later change the Subject, of course; see #4 above.)
-
- Exception: The software MAY try to compensate for other people's broken
- software by replacing non-standard prefixes (such as "Re^2: ", "Re(2):
- ", "Re:" (no space), "RE: ", "re: " , or "Re: Re: ") by the standard
- prefix "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: " headers, especially when gratuitous non-ASCII
- characters are also thrown in, are a major annoyance for users and can
- make threading difficult or impossible.
-
-
- 6) Direct followups 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.)
-
- If the original article's "Followup-To: " header is set to "poster", the
- software MUST warn the user that the original poster requested an e-mail
- reply, and generate an e-mail reply by default.
-
- 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) Make sure followups contain valid References
-
- 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. An individual Message-ID MUST never be truncated.
-
- The software MUST include at least three additional Message-IDs from
- the original article's References header as well, if they are available.
- Try to stay as close as possible to the spirit of "son-of-1036", which
- states:
-
- <<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.>>
-
- However, it also says:
-
- <<If it is absolutely necessary for an implementation to
- impose a limit on the length of header lines, body lines, or
- header logical lines, that limit shall be at least 1000
- octets, including EOL representations.>>
-
- So, bear in mind that news transports are not guaranteed to be able to
- handle arbitrary long lines. Furthermore, keep in mind that some news
- transports choke on continued (multi-line) "References: " headers.
-
- Therefore, keep as many Message-IDs as will fit on a line starting with
- "References: " with a maximum length of 998 characters. (An octet is a
- byte of 8 bits, EOL representation takes two bytes.)
-
- Exception: Damaged (truncated) Message-IDs SHOULD NOT be included.
- Neither should `bogus' Message-IDs -- IDs that somehow got inserted (by
- a misguided user, maybe) but don't belong to the thread.
-
- Rationale: Threaded news-readers depend on References to do their magic.
- This too is basic RFC compliance. Be as complete as the line length
- limit allows, but do not propagate errors.
-
-
- 8) Direct e-mail replies to the correct address
-
- When creating an e-mail reply, the software MUST create an initial
- header in which the "To: " header 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) Allow the user to change her mind about whether to post or mail
-
- With any followup or reply message, the software SHOULD offer the user
- the option to change her mind about whether to post or to mail, and may
- allow doing both.
-
- If the software has the option to post as well as mail a single
- response, that option MUST NOT be default behavior, neither by factory
- default nor by user-configuration. Furthermore, when both posting and
- mailing a message, the mailed message's body SHOULD be preceded by a
- line clearly stating that the message is an email copy of a usenet
- posting.
-
- Rationale: People digress when writing, and may find themselves posting
- a message that would have been more appropriate for private
- communication, or mailing a message that would have been more
- appropriately directed to the general audience. Unsolicited mail
- messages are highly unwanted by many users (had they wanted e-mail
- replies, they could, should and, for all a reader can assume would, have
- requested them).
-
-
- 10) Provide adequate quotation and attribution facilities
-
- When the user 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. The quote prefix SHOULD be `>', with optionally a trailing
- space (i.e. `> ').
-
- Caveat: with `>', the level of quotation is clearly reflected in the
- number of `>' characters at the start of the line. However,
- whitespace between quote prefix and quoted material improves
- readability, so it is good practice for newsreaders to use `> '
- as the quote prefix for newly quoted, and `>' for repetitively
- quoted text.
-
- Included text SHOULD NOT contain the original article's signature,
- unless by explicit request of the user (under the condition that the
- signature can be determined of course, which is to say: if clearly
- separated by the standard signature delimiter). (see also #15 below).
-
- As a direct counterpart to this requirement, the software SHOULD offer
- the user some means of selecting exactly which part of a Usenet posting
- she wishes to followup to, and quote only that part initially. (A
- special case of this is when a user wishes to react to what's in a
- signature.)
-
- If it concerns 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. By convention,
- quoted lines start with `>', and much software depends on this do
- distinguish quoted material from original lines, for presentation
- purposes. Users can be careless or forgetful occasionally (or often,
- even) and neglect to edit out spurious quoted material; the signature,
- typically, is such material. In general, facilitating good quoting
- behaviour -- by quoting only a part indicated by the user, for example
- - - -- is an area in which software can help users substantially to create
- better articles.
-
-
- 11) Provide a user-specified "Subject: " header
-
- 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 default Subject (like "Subject: <None>") if the user
- didn't specify one. It MUST allow the user to change the Subject at any
- time while editing the main text of the article (see #4 above).
-
- Rationale: An article without a Subject provides no clues for deciding
- to read it or not. For that reason, it's likely to be widely ignored,
- and it's no service to the user to allow posting of such an article;
- while other readers may read it, only to find out they needn't have
- bothered when it annoyingly turns out to be of no interest.
-
-
- 12) Provide a 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).
-
- This requirement must be met regardless of whether the software
-
- (a) creates the "From: " header when it first creates the article to
- be edited by the user, or
-
- (b) adds the "From: " header automatically after the user finishes
- editing the article and requests that it be submitted.
-
- If the software allows the user to edit the "From: " header, it SHOULD
- check that the user supplied a syntactically valid address.
-
- 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: Mail and news transport systems and user agents, gateways and
- processing software may choke on syntactically invalid headers. Invalid
- e-mail addresses make e-mail replies impossible; see Greg Byshank's
- "Help! I've been spammed!" document for an excellent discussion of the
- issues involved.
-
-
- 13) Allow users to both cancel and supersede their own articles (and
- _no_ others!)
-
- Any software that posts news SHOULD provide a command that the user can
- invoke to cancel her own articles. It SHOULD also provide the option to
- supersede the user's own articles. The software MUST guarantee that
- the user cannot cancel or supersede other people's articles, as far as
- possible.
-
- Caveat: since completely reliable authentication can be infeasible, the
- best the software can do is to make a good-faith effort to
- determine whether or not cancelling or superseding is valid:
- i.e. by trusting upon its user configuration and checking it
- against the relevant header(s) in the target article.
-
- If the software uses the English language, the text of the cancel
- command SHOULD include the word "cancel", rather than non-standard verbs
- such as "delete". Similarly, in English software, the text of the
- supersede command SHOULD include the word "supersede".
-
- Rationale: People make mistakes and need the ability to revoke or
- correct them; both `cancel' and `supersede' exist for good reasons.
- However, software should not encourage users to abuse the net, either
- intentionally or accidentally, by sending unauthorized (`rogue') cancels
- or supersedes. The supersede option is essential: due (a.o.) to
- sometimes unpredictable usenet propagation, a "cancel-cum-repost" may
- behave very different from a "supersede". News servers might also have
- different acceptance policies for both.
-
-
- 14) Try to respect the 80-character line-length conventions
-
- 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.
-
- Caveat: Occasionally, there are very good reasons for posting long lines
- (for example, when posting a source code snippet containing
- something that will break when wrapped, or when there's a need
- to post something "as is", unreformatted -- unaltered and
- completely intact). For that reason (re)wrapping cannot be a
- MUST: a SHOULD is all it can be.
-
- To get well-readable articles, the user SHOULD be provided with the
- possibility to rewrap excessively long lines of quoted text, respecting
- quotation -- i.e. have the option to correct `inherited' bad formatting.
- Also, tabs SHOULD be expanded to prevent the so-called `tab damage' that
- may occur when someone reading your article uses a different tab size.
-
- Caveat: Due to the immense variety in quoting styles, quoted text
- reformatting can be extremely hard, practically impossible even.
- No software can be expected to deal with everything; still,
- since the overwhelming majority can be dealt relatively easily,
- it is not unreasonable to expect it from software, if it is to
- be well-equipped for the task of editing Usenet articles.
-
- If the news software uses an external editor, the default editor SHOULD
- conform to the above.
-
- Rationale: Articles with long lines are unreadable to many users.
- Articles with alternating 80/20 lines aren't any better.
-
-
- 15) Separate signatures correctly, and don't use excessive ones
-
- Posting software SHOULD separate any signature appended to outgoing
- articles from the main text with a line containing only `-- ' ("dash
- dash space"). To quote son-of-rfc1036:
-
- <<If a poster or posting agent does append a signature to an
- article, the signature SHOULD be preceded with a delimiter
- line containing (only) two hyphens (ASCII 45) followed by
- one blank (ASCII 32). Posting agents SHOULD limit the
- length of signatures, since verbose excess bordering on
- abuse is common if no restraint is imposed; 4 lines is a
- common limit.>>
-
- Hence, posting software SHOULD prevent the user from using excessively
- long signatures, or at least warn the user against it. A widely
- accepted standard is the so-called McQuary limit: up to 4 lines, each up
- to a maximum of 80 characters.
-
- Rationale: Being confronted with (possibly excessively long) signatures
- repetitively is, or can be, annoying to many. Being able to separate
- the main text and the signature clearly is important, not only to
- prevent the possible mistake of misinterpreting a signature, but also to
- enable automatic signature suppression for those who wish to do so.
-
-
- 16) Try to prevent obvious user errors
-
- * Posting software MUST warn the user for posting empty articles, and
- SHOULD prevent doing so entirely.
-
- * Posting software MUST warn the user about posting articles consisting
- entirely of quoted text, and SHOULD prevent doing so entirely.
-
- * Posting software MUST warn the user severely when attempting to post
- an article over and over again, and SHOULD do everything it can to
- prevent doing so entirely.
-
- - When posting `asynchronously' (i.e. when sacrificing knowledge
- about progress, success or failure by handing over the task
- completely to some separate process) it SHOULD NOT allow the user
- to post articles again, once the user issued the final "post"
- command.
-
- - When posting `synchronously', the software has at least partial
- knowledge about progress, and full knowledge about success or
- failure of an attempt to post. In this case, it SHOULD inform the
- user clearly that the article is being posted while attempting to
- post it; after the attempt, it MUST unequivocally inform the user
- that posting succeeded if it did, and that it failed otherwise.
-
- Note: So-called `online' newsreaders usually (but not necessarily)
- post synchronously, while a number so-called `offline' newsreading
- methods (especially the scheduled, batch-oriented ones) usually
- employ asynchronous posting. However, offline newsreaders using
- NNTP for news transport usually post synchronously, i.e. are in
- direct interaction with the newsserver, hence get immediate
- results, when posting.
-
- Rationale: Users who do any of these things almost never do them on
- purpose. They are usually confused by unfamiliar new software, and
- should be offered basic protection.
-
-
- 17) Post human-readable articles unless ordered otherwise
-
- Posting software MUST by default post only legible usenet articles. In
- a different formulation: it MUST NOT encode or encrypt articles, unless
- by explicit user demand. Hence, it MUST NOT even have the option to
- encode or encrypt by default. Whenever some encoding/encryption will be
- used, clear feedback showing that it's in effect MUST be provided to the
- user, so she is permanently reminded of the fact that her article will
- not be posted as composed. The worst DO NOT is the combination of
- allowing default encoding without even taking the trouble of telling
- (warning) the user about it.
-
- Note: Common occurrences of this kind of content maiming unasked for,
- and untold to, the user, are HTML- and MIME multi-part
- and/or base64 encodings, as found in newsreaders integrated in
- WWW-browsers better not mentioned.
-
- Rationale: Many users may not be able to read (particular) encoded or
- encrypted articles at all, or only at the expense of a considerable
- effort: such articles ask to be widely ignored. Encouraging posting
- maimed messages is a service neither to the user herself, nor to her
- audience. Keep in mind that not everyone shares your particular setup
- (newsreader, configuration, operating system), nor should (and can)
- anyone be forced to do so, in order to be able to read your articles.
-
-
- 18) Provide self-protection
-
- News readers SHOULD allow the user to protect herself by filtering out
- articles she really does not want to read. These filtering facilities
- SHOULD be sufficiently powerful to enable ignoring postings by
- particular persons, about particular subjects, and particular
- cross-posts.
-
- Rationale: While it looks as if not having filtering only affects the
- user herself, people tend to take it out on the net if they are
- repetitively (structurally) annoyed by a particular class of postings,
- and will be inclined to start canceling, advocate posting restriction or
- engage in flame warfare, all of which is harmful to other users.
-
-
- 19) Be kind to servers, leave room for others
-
- Reading or posting software MUST NOT put excessive demands on news
- servers unnecessarily. The sofware MUST limit itself to 4 simultaneous
- connections to a given server. Spurious connects and unnecessary
- traffic MUST be avoided; the software MUST use as few as possible
- connections, reusing existing connections whenever possible.
-
- Rationale: News systems are big, resources are scarce, and every
- resource claimed is provided at the expense of other users.
-
-
- --%-@#@-%--
-
-
- Please remember that this is a set of _minimum_ guidelines to guarantee
- that a given piece of software interacts properly with the rest of the
- Usenet world. It is not a general "wish list" of everyone's favorite
- features. I have deliberately avoided taking a position on certain
- controversial issues -- for example, whether the user should be allowed
- to edit the "Sender: " header, whether news software should prohibit
- posting an article that has more quoted text than new text, or whether
- posting with certain particular Subjects should be prohibited.
-
-
- My hope is that a voluntary committee can be formed, respected by many
- 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 should then be strongly encouraged
- to switch to software that does.
-
-
- References and additional reading
- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
- The current GNKSA, an evaluation form and an archive of software
- evaluations can be found at:
-
- <http://www.xs4all.nl/%7Ejs/gnksa/>
- <http://newsreaders.com/gnksa/> (Mirror)
- <http://newsreaders.com/misc/twpierce/news/> (GNKSA 1.2)
-
- The GNKSA page also contains a pointer to a library that newsreader
- developers can freely make use of, providing basic `sanitary' functions.
-
- In addition to the Seal, anyone writing Usenet software should pay
- careful attention to the following documents:
-
- RFC 977, "Network News Transfer Protocol -- A Proposed Standard for
- the Stream-Based Transmission of News", by Brian Kantor and Phil
- Lapsley.
- <ftp://ftp.internic.net/rfc/rfc977.txt>
-
- 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)
-
- "The UseFor Working Group Documents" (under development: Internet
- Drafts describing the minimal standards for a Usenet article, and
- the minimum features all Usenet software should have), by Simon
- Lyall (et al.).
- <http://www.landfield.com/usefor/>
-
- "Read This Before You Write a Newsreader, News Transport
- System, etc.", by Tom Limoncelli.
- <http://www.xs4all.nl/%7Ejs/gnksa/read-before.txt>
-
- "The "Good Net-Keeping Seal of Approval", revision 1.2, by Ron
- Newman; the previous version of this document, published in
- January, 1995.
- <http://www2.thecia.net/users/rnewman/Good-Netkeeping-Seal>
-
- Excellent collections of things well worth reading in this context can
- be found at:
-
- "News Hacking", by Tim Pierce.
- <http://newsreaders.com/misc/twpierce/news/>
-
- "Notes on News", by Lars Magne Ingebrigtsen.
- <http://quimby.gnus.org/notes/notes.html>
-
- A very informative overview of the issues concerning some forms of net
- abuse, and how and how not to deal with it, is:
-
- "Help! I've been Spammed! What do I do?", by Greg Byshenk, based in
- part on an original by Chris Lewis, Posted weekly to news.answers,
- news.newusers.questions, and news.admin.net-abuse.misc.
- <http://www.byshenk.net/ive.been.spammed.html>
- The part that explicitly deals with the issues of messing up
- "From: "-headers is:
- <http://www.byshenk.net/ive.been.spammed.html#2.3>
-
- Of related interest -- if you're willing to contribute, or are just
- interested in the way things are developing -- could also be the IETF
- NNTP Working Group's "attempt to revise NNTP and bring it into the
- 1990s".
- <http://www.academ.com/academ/nntp/ietf.html>
-
-
- Acknowledgements
- ~~~~~~~~~~~~~~~~
-
- Simon Lyall c.s., for the praiseworthy UseFor (Usenet Format) Working
- Group initiative (and its derivatives).
-
- Ron Newman <rnewman@theCIA.net>, of course, for writing the first
- version of the GNKSA, of which this document descends, and for
- fruitful discussions during revision.
-
- Sven Guckes <guckes@math.fu-berlin.de> for providing mailing list
- resources (among other things).
-
- Tim Pierce <twpierce@midway.uchicago.edu> for scrutinous examination,
- useful hints, and previous GNKSA support.
-
- Larry Wall <lwall@netlabs.com>, Stefan Haller <stk@berlin.snafu.de>,
- John E. Davis <davis@space.mit.edu>, John Norstad <j-norstad@nwu.edu>,
- Karl-Johan Johnsson <su95-kjo@nada.kth.se>, Brian Clark <baclark@nwu.edu>,
- Simon Fraser <smfr@best.com> for showing inspiring examples of the spirit
- of good net keeping in the form of exceptionally well-designed usenet
- reading programs.
-
- The kind folks of news.software.readers (you know who you are) that
- have helped discussing the issues that pertain to the GNSKA cause.
-
- -----BEGIN PGP SIGNATURE-----
- Version: PGP 7.0
-
- iQA/AwUBP59ryKiSBiUDcwTdEQJDqwCdEzcmH+jz54lUTtjRvNIfHwk348cAn01r
- HKnj72IXRCeCtRfue0xRz06O
- =ZeUt
- -----END PGP SIGNATURE-----
-