Re: [Pan-users] GNKSA

[Duncan]

Joe Zeff posted on Mon, 04 Jul 2011 13:43:13 -0700 as excerpted:

> I've just received a response to my email about updating the GNKSA.  In
> part, it says:
> 
> Actually, I consider the GNKSA a historic document, to be read in the
> context of its own time, rather than a useful guideline for today's
> practice.  It played its part, but to me its relevance is over.  Usenet
> has become a niche, or a suite of niches for a relatively small audience
> and particular purposes.  The GNKSA, by intention anyway, aimed to help
> Usenet function in a time before web forums, "social" sites and the
> like.
> 
> I don't think there's any other interest in updating it or even paying
> any attention to it any longer.  I think it's now time for us to ask
> ourselves if complying to an otherwise dead standard is in Pan's best
> interests, and if not, what other changes are appropriate.

OK, now that I've had some time to let this all sink in and to digest it 
a bit, here's my take.

I originally read that as saying that much like Charles Kerr with pan,
he considered his work with news done, historic, and that he has now 
moved on to other things and no longer really cares about /what/ happens 
to news, news servers/clients, or news users in their news-using context, 
nor is he particularly interested in getting back into the discussion in 
any form -- he considers it a closed chapter in his life.

However, later, you (Joe Zeff) stated:

> I gather that the maintainer would be willing to update the GNKSA if we
> were to come up with reasonable and well-reasoned suggestions.

Obviously, my take as stated above was rather different.  The way I read 
it, he was no longer the least bit interested in being involved, while 
you obviously believe he'd be willing to do an update, at least.

Somewhere in the middle is another way.

Note that someone, presumably him, still owns gnksa.org, and presumably 
considers it of some value.  At minimum, there are very likely old email 
addresses that he'd like to maintain.

Meanwhile, the existing GNKSA 2.0 was first introduced in or before, the 
GNKSA wikipedia article indicates, 2001, with the last update being 2.09, 
dated October 29, 2003, according to the current 2.0 document at 
gnksa.org.

If we're serious about updating GNKSA, then what we're looking at is GNKSA 
2.1 or 3.0 (version numbering to be discussed).  Given that the previous 
GNKSA version jump from 1.2 to 2.0 happened with the transfer of 
maintainership to Jeroen Sheerder (JS from here) from Ron Newman in 2000 
or so, following precedent, if we /do/ decide on an update and it 
involves JS, he can of course decide the version number, but if we do it 
without his active involvement (tho presumably with his blessing), we 
should probably set the version to 3.0.

Note also that at least back in 2003, according to the headers in the 
document (which is in the form of a news post) the GNKSA was being posted 
monthly (first Sunday) to a number of newsgroups, including 
news.software.readers .  If we're serious about modifying GNKSA, someone 
should check to see if news.software.readers is still active and if the 
monthly post is still occurring.  It might also be useful to know when 
the last post was, if it's not still happening.

As with the mailing list discussed previously, finding out if the group 
is still active and if anyone there's still interested in GNKSA, if it 
is, is probably worthwhile.  Of course, unlike the mailing list, the 
group can be checked (by someone with access, I don't have it) without 
bothering JS.

So please, someone, consider doing so.


Meanwhile, this middle way mentioned above could take all of this into 
account.  If JS is indeed no longer interested but presumably still wants 
to keep control of gnksa.org, there's at least some likelihood that he'd 
be willing to at least setup a redirector to wherever we might decide to 
host GNKSAv3, as it'd presumably be if he was no longer directly 
involved.  He might also setup mail forwarding for a few GNKSAv3 
administrative addresses, if we asked.  (He might even offer us the 
domain provided we were willing to setup forwarding for a few addresses 
he and possibly others use, but that remains of course entirely up to him 
and I'd not count on it.)  In practice, some such infrastructure 
arrangement would be very helpful, tho unless he's trademarked GNKSA and 
interested in pressing it, we could in theory setup a v3 even without his 
cooperation.  But if he's really no longer interested and considers it a 
closed chapter, then some sort of minimal forwarding at least, may well 
be something that could be worked out, even if he does keep the domain, 
which I certainly would want to do if it were me.


As for the GNKSA SHOULD and MUST points themselves, here's the quick 
list, copied from the GNKSA:

---------8><--------------------------------------------><8--------

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

---------8><--------------------------------------------><8--------

After reading thru the detailed treatment of each in the document, I 
believe most of the 19 points are just fine as they are.

#14, respecting 80-char traditions, might be argued by some to be 
anachronistic now.  They'd argue that it should be either updated (to 
reflect format=flowed and/or mime/quoted-printable's
terminating-space=line-continuation indicator, allowing the receiving 
client to wrap as desired), or simply deleted.

I see the continued benefit in maintaining it as-is, but I'd be open to 
further discussion.

#17, human-readable-by-default, is where mime/base64 encoding, mime/multi-
part, and HTML formatting come in.  All three of those are specifically 
mentioned in the detailed treatment as NOT to be the default, tho they 
ARE allowed as non-default (which is where the "unless specifically 
ordered" comes in).

Regulars here will certainly know my position on that, but lest anyone 
doubt, my view is that for text, if the content is isn't worth sending 
and reading in plain text, it's not worth sending and is very likely a 
waste of my time to read.  There are three types of people that send 
HTML, spammers, who sometimes use it to confuse spam filters, those using 
it to spread malware including spyware (thus including spammers who take 
advantage of webbugs and the like to confirm reading, as well as the more 
malevolent crackers who attempt more complex exploits for security 
penetration purposes), and those who simply don't know any better.

As such, I'd leave that as-is too, but there are certainly many who would 
disagree.

#19 is of course our major present concern, since its details have as a 
MUST, that software limit itself to 4 connections per server.  As I've 
indicated, IMO this one was anachronistic in that form even when first 
introduced in (it appears) GNKSA 2.0 in 2001.  Well before then, servers 
that did nothing to limit number of connections per login or IP address 
were inviting and receiving quite some abuse, and as a result, were 
strictly limiting number of connections as required by the server's 
needs.  Thus, I don't see how a GNKSA MUST, limiting the number of 
connections to four, was in any way helpful.

OTOH, the point DOES have some value, as besides the 4-connection limit, 
the details state:

> Spurious connects and unnecessary traffic MUST be avoided;
> the software MUST use as few as possible connections, reusing
> existing connections whenever possible.

As I've explained elsewhere, that directly addressed an abuse by MSOE (at 
least, I was using it back then so know of it personally, and it was 
popular enough to have triggered the addition of this point), which would 
open multiple (upto four) connections for single use (getting high-and-
low-water message numbers, getting the groups list updates, etc) and then 
let them simply sit there after that single task was done, while 
meanwhile, it could only use a single connection for batch downloads, and 
a separate single connection for interactive downloads.  It wasn't using 
as few connections as possible, nor was it reusing existing connections 
wherever possible (nor was their any way for the user to configure the 
number of connections it actually DID use), and it's my suspicion that 
this point was added primarily as a result of that, with the max-four 
connections thing as sort of a polite cover, so it didn't look directly 
targeted at OE for being OE.

Here's the present detail for that one in full:

---------8><--------------------------------------------><8--------

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.

---------8><--------------------------------------------><8--------

Let's see if I can come up with a reasonable first draft of a
rewrite, reflecting the situation as users and news software
find it today:

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

19) Be kind to servers, leave room for others

Reading or posting software MUST NOT put excessive demands on
news servers unnecessarily.  Spurious connects and unnecessary
traffic MUST be avoided; the software MUST use as few connections
as possible, reusing existing connections whenever possible.

If the software allows multiple connections per server, it SHOULD
allow the user to configure the number of connections per server
on an individual server basis.  The default number of connections
per server MUST NOT exceed four, unless the user has specifically 
configured more.

Note: Some servers may allow as little as a single connection per
      IP address or logged in user.  Thus, it is suggested that
      the default pre-configuration limit be a single connection
      per server to avoid problems and keep resource usage to a
      a minimum.  Be that as it may, software MUST NOT exceed
      the limit of four connections per server, by default.

Rationale: News systems are big, resources are scarce, and every
resource claimed is provided at the expense of other users.
Servers enforce their own connections policy but users often
pay for more connections, so the software should allow a user
the opportunity to configure them if desired.

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

This deletes the four-connections-max MUST from the first paragraph, 
adding the second, the note, and all but the original first sentence in 
the rational.  (There's also a slight word order change in one existing 
sentence from "as few as possible connections" to "as few connections as 
possible".  That sounds better to me.  I'm guessing a non-native-English 
speaker must have written the original.  In any case, the meaning of the 
sentence is retained.)

That's intended as a first draft.  I spent a bit of time on it, but 
there's very likely improvements to be made.  If anyone has any, or if 
you disagree with either the wording or the idea, please post!

If you've used other news software that you believe works as it should in 
this regard, that this would negatively affect, DEFINITELY please post!

And, if you have any concerns about the other points, or disagree with 
the position I took on the other two points I believe may be 
controversial and believe they should be changed, please clearly state 
your position, preferably with proposed changes.

FWIW, I'd not be opposed to a revision of point 14, on 80-char, if 
something suitable can be proposed.  I simply don't care enough to try to 
come up with a reasonable change that's sufficiently concise and clear, 
and fear any changes may wreak more damage than they fix.  But if someone 
who feels strongly enough about it needing change can come up with a 
reasonable proposal, go for it!  Do keep in mind, however, that there are 
no doubt some traditionalists still using fixed line length software, and/
or hardware where even 80-char width is wider than their display 
(consider news software, probably text-only, on a cell phone).  If the 
solution is good, it'll be practical for all readers, including those 
groups.

Similarly, if you are aware of any omissions you believe should be dealt 
with, please post them too, with proposed wording if you are upto it, 
otherwise just make your argument and perhaps someone else will be 
persuaded enough to propose reasonable wording.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman