From: Charles Lindsey (chl@clerew.man.ac.uk)
Date: Fri Dec 12 2003 - 16:54:16 CST
I promised that I would produce a paper comparing GNKSA and USEAGE, and
here it is.
I have also emailed Jeroen Scheerder <js@phil.uu.nl> with a copy, and
invited him to join us on the WG to discuss it.
This document describes the differences between GNKSA
<http://www.faqs.org/faqs/usenet/software/good-netkeeping-seal> and USEAGE
<http://www.landfield.com/usefor/drafts/draft-ietf-usefor-useage--1.03.txt>,
also with some references to USEFOR (draft-ietf-usefor-article-12.txt).
This is done mostly by saying what would NEED to be done to USEAGE in
order to bring it into agreement with GNKSA. That is not to say that all
these changes will _necessarily_ be made to USEAGE, but are intended
rather to form an agenda for discussion of changes that _might_ be made.
OTOH, it would probably be desirable at least to fix those places where
the two documents contradict each other (usually where USEAGE specifies
SHOULD and GNKSA specifies MUST). I also draw attention to a few places
where it might be better for GNKSA to change, to bring it into line with
changes introduced in USEFOR and with modern practice.
One area where GNKSA is currently silent, and might usefully take a
stronger position, is the folding of headers which, according to USEFOR,
is to become a standard feature of Usenet (though not necessarily just
yet).
Currently, GNKSA has much to say on what facilities the User's interface
should provide, whereas USEAGE is silent on this. However, there is a
placeholder (USEAGE section 3.5) which might be entitled "The Well-Behaved
User Interface" where such material could go if we decide to include it.
In the following, I have quoted the main body of GNKSA. Lines taken from
GNKSA are prefixed with "> "; lines not so prefixed are my comments.
Share and Enjoy!
>
>
> 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.
Even if the user shrinks his window size to 1 inch wide? I presume the
requirement to display ALL of it using scrollbars/folding/whatever still
applies. Note that the figure of 70 may be too high in languages such as
Japanese where it is customary to use double width characters AIUI.
>
> 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.
USEAGE 3.3.1 NEEDS to include this.
Other rarely used but important headers which might be included are
Summary (currently SHOULD in Useage)
Distribution
Posted-and-Mailed
Control
These will rarely occur, but users need to be aware of them when they do.
>
> 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.
It might be useful to add folding as another example for showing long headers,
but with a SHOULD leave the poster's folding alone if it ain't broke.
>
> 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.
USEAGE currently silent on this. NEEDS to be added to 3.5.
>
> 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: ".
USEAGE currently silent on this. NEEDS to be added to 3.5.
>
> 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.
USEAGE 3.1 currently has SHOULD for creating _any_ header.
NEEDS MUST for at least these ones.
USEAGE 3.2 likewise
Or maybe this belongs in 3.5.
>
> 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.
USEAGE 3.2.1.1 has SHOULD here. NEEDS MUST and maybe further reinforcement.
(USEFOR has MAY, but SHOULD be done correctly if at all)
>
> (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: ".
USEAGE already says this.
>
> 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.
Mostly already covered in USEFOR and/or USEAGE, but reinforcement NEEDED
in 3.2.1.1.
That last MUST NEEDED in 3.5.
>
> 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.
Already in USEFOR
>
> 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.>>
That requirement concerning Message-IDs in the body is no longer in
USEFOR. It would be a pain to implement, and I doubt it ever was.
>
> 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.>>
USEAGE has 20 rather then 3.
>
> 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.
Is this really so? I had always assumed References would be folded as a
matter of course.
>
> 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.)
GNKSA needs to take account of the Mail-Copies-To-header here.
USEAGE NEEDS to cover this in 3.4.
>
> 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.
That MUST NOT seems a bit strong ...
GNKSA needs to take account of the Posted-And-Mailed-header here.
USEAGE NEEDS to address this in 3.5, and maybe amplify 3.2.1.3.
>
> 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. `> ').
USEAGE has SHOULD. Would NEED MUST.
>
> 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.
Covered in USEAGE 3.2.2.1.
>
> 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).
Covered in USEAGE 3.2.2.1.
>
> 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.)
NEEDED in 3.5.
>
> 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.)
USEAGE has SHOULD. Would NEED MUST.
>
> 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).
USEFOR REQUIRES a non-empty header.
Change of Subject NEEDS to be covered in 3.5.
>
> 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.
All this is already REQUIRED by USEFOR. But possibly some amplification in
USEAGE 3.1.1.2.
>
> If feasible, the software SHOULD try to guarantee that this address
> actually belongs to the person using the software, and actually accepts
> e-mail.
But this is much more dubious in these days of munged addresses. USEAGE
3.1.1.2 tries to steer a middle course.
>
> 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".
This NEEDS to be covered in 3.5.
>
> 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.
A matter for 3.5. But GNKSA also needs to take account of format=flowed,
and could usefully mention folding of headers.
>
> 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.
The limit in USEAGE is 79 rather than 80, with a preference for 72 to
leave room for quoting in followups. However, USEAGE also allows hierarchy
admins to specify different widths (e.g. the Japanese with double width
characters).
>
> 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.
USEAGE 3.1.1 and 3.1.2 cover most of this, but additional coverage is
NEEDED in 3.3.
>
> 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.
Does the discussion of format=flowed in 3.2.2.1 cover this adequately?
>
> 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.
NEEDED in 3.5.
>
> 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.
All fully covered in USEAGE 3.1.2.1.
>
> 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.
Covered in USEFOR.
NEEDS reinforcement in 3.1.2 or 3.5.
>
> * Posting software MUST warn the user about posting articles consisting
> entirely of quoted text, and SHOULD prevent doing so entirely.
NEEDED in 3.2.2 or 3.2.2.1 or 3.5.
>
> * 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.
NEEDED in 3.5.
>
> 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.
Eh? How can an "offline newsreader" be in "direct interaction with the
newsserver"?
>
> 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.
I think GNKSA needs to distinguish between encoding and encryption here.
As for encoding, and taking that as meaning Content-Transfer-Encoding,
USEAGE 3.1.2.3 has SHOULD use 8bit (or 7bit) (though it might have to be
changed upon gatewaying to mail). NEEDS upgrading to MUST.
However, this is not usually under user control, and there us certainly no
need for the user to be aware.
In the case of Encryption, however, all that applies, though I am not
convinced it needs a mention because I am unaware of any user agent stupid
enough to attempt it. But it could be mentioned somewhere in USEAGE 3.1.2.
>
> 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.
USEFOR makes it clear that MIME is now a standard part of Usenet. But
USEAGE 3.1.2.2 discourages many practices, such as HTML (except in
hierarchies that have decided to embrace it). There is no particular harm
in multipart types (except for multipart/alternative) because they still
look quite reasonable even in non-MIME-aware readers.
> 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.
USEAGE NEEDS some mention of Killfiles, in 3.3.1 or 3.5, at the SHOULD
level.
>
> 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.
USEAGE would NEED this in 3.1, but that MUST is a bit steep, and I am not
sure that it belongs in USEAGE anyway.
>
> Rationale: News systems are big, resources are scarce, and every
> resource claimed is provided at the expense of other users.
-- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5