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
_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/pan-users
