[ANN] NewsWatcher 2.2
Garner Miller
In article <j-norstad-220...@norstad.at.nwu.edu>,
j-no...@nwu.edu (John Norstad) wrote:
> Prohibit posting and mailing by default.
THANK YOU! THANK YOU! THANK YOU!
> We have also implemented support for the "Mail-Copies-To" header.
Oh, did I mention Thank You? :-)
- Garner "I hate e-mail replies to news articles" Miller
Stefan Haller
John Norstad <j-no...@nwu.edu> wrote:
> McQuary limit: Signatures cannot exceed 4 lines of 80 chars each.
Thank you. It's great to know that I'm not the only one trying to
enforce this.
> We expect that some people will object to the new McQuary limit on
> signatures. That's too bad, but the limit is there for a good reason, and
> we will not change it.
John, I have received quite a lot of complaints about this limit in
MacSOUP, and I expect the same will happen to you. Please don't let
yourself be talked into removing the limit again.
--
Stefan Haller (author of MacSOUP)
Berlin, Germany
http://www.inx.de/~stk/
Sven Guckes
Readers of AFW - good news!
j-no...@nwu.edu (John Norstad):
> NewsWatcher version 2.2 is now available at:
> <ftp://ftp.nwu.edu/pub/newswatcher/>
> NewsWatcher is a free Usenet newsreader for the Macintosh.
>
> The reason for this release is to bring NewsWatcher into compliance
> with version 2.0 of the "Good Net-Keeping Seal of Approval".
> Here's a summary of the changes : [...]
> Don't quote standard signatures in followups and email replies.
> McQuary limit: Signatures cannot exceed 4 lines of 80 chars each.
> Improve "From" header syntax checking of email address and full name.
>
> We expect that some people will object to the new McQuary limit on signatures.
> That's too bad, but the limit is there for a good reason, and we will not
> change it. If you insist on using an excessively long signature, you will
> have to continue using an old version of NewsWatcher or switch to some other
> program.
YES! :-)
Thank you, John!
Sven
--
Sven Guckes guc...@math.fu-berlin.de [afw] Newsgroup alt.fan.warlord on WWW:
AFW Home Page: http://www.math.fu-berlin.de/~guckes/afw/
AFW Best of : http://www.math.fu-berlin.de/~guckes/afw/best.of/
AFW Acronyms : http://www.math.fu-berlin.de/~guckes/afw/afw.acronyms.html
John Norstad
In article <1d3b32m.1t3...@n099h034.berlin.snafu.de>,
s...@berlin.snafu.de (Stefan Haller) wrote:
> John Norstad <j-no...@nwu.edu> wrote:
>
> > McQuary limit: Signatures cannot exceed 4 lines of 80 chars each.
>
> Thank you. It's great to know that I'm not the only one trying to
> enforce this.
You're welcome, and thanks for leading the way on this, Stefan - on the
McQuary limit in particular, and the GNKSA in general. Your MacSOUP has
GNKSA seal #1, and now my NewsWatcher has #2. When I was discussing the
planned changes with Jeroen Scheerder (keeper of the GNKSA) and John
Moreno (NewsWatcher reviewer for the GNKSA), we used MacSoup's
implementation of several of the features as a benchmark against which we
measured our plans for NewsWatcher.
I think it's interesting that the only two newsreaders to pass the GNKSA
so far are both Mac newsreaders - one an online reader, one an offline
reader. All of the UNIX and Windows readers which have been reviewed have
failed!
> > We expect that some people will object to the new McQuary limit on
> > signatures. That's too bad, but the limit is there for a good reason, and
> > we will not change it.
>
> John, I have received quite a lot of complaints about this limit in
> MacSOUP, and I expect the same will happen to you. Please don't let
> yourself be talked into removing the limit again.
No, I won't let myself be talked into removing it.
So far, my mail is running about 10-1 in favor of this change. Most people
are saying "thank you". Very few are complaining.
--
John Norstad <mailto:j-no...@nwu.edu>
Academic Technologies <http://charlotte.at.nwu.edu/jln/>
Northwestern University <ftp://ftp.nwu.edu/>
Sven Guckes
j-no...@nwu.edu (John Norstad):
> I think it's interesting that the only two newsreaders to pass the GNKSA so
> far are both Mac newsreaders - one an online reader, one an offline reader.
> All of the UNIX and Windows readers which have been reviewed have failed!
Yes, this definitely puts the other newsreaders to shame.
(Yes, I know that this depends on the standard set by the GNKSA, but, hey!)
[McQuary limit]
> I won't let myself be talked into removing it. So far, my mail is running
> about 10-1 in favor of this change. Most people are saying "thank you".
> Very few are complaining.
Well, how about adding the McQuary/signature limit for slrn, JED?
Sven [would be very pleased about this]
John Moreno
In news.software.readers Stefan Haller <s...@berlin.snafu.de> wrote:
> John Norstad <j-no...@nwu.edu> wrote:
>
> > McQuary limit: Signatures cannot exceed 4 lines of 80 chars each.
>
> Thank you. It's great to know that I'm not the only one trying to
> enforce this.
>
> > We expect that some people will object to the new McQuary limit on
> > signatures. That's too bad, but the limit is there for a good reason, and
> > we will not change it.
>
> John, I have received quite a lot of complaints about this limit in
> MacSOUP, and I expect the same will happen to you. Please don't let
> yourself be talked into removing the limit again.
He seemed quite enthusiastic about it when it came up - and he's got a
better response than you do. He can tell them to change it themselves.
--
John Moreno
Russ Allbery
In news.software.readers, John Moreno <phe...@interpath.com> writes:
> But the sad thing is that there are a lot of programs that could get the
> GNKSA with just minor improvements
The sad thing is that the GNKSA requires some totally broken or utterly
unnecessary behavior, thus resulting in intelligent newsreaders not
passing not because they are deficient but because the GNKSA is.
> - take Gnus for example. The version reviewed was 5.3 and the only two
> things it fails on are:
> 7c Does not restrict references sensibly
The references restriction is not "sensible."
> 16c Does not warn when posting quoted text only
I believe Gnus does this.
> 7c means keeping the references under 998 octets.
And there is no good reason for this restriction. This was discussed
extensively on the Gnus mailing list, cc'd to Mr. Moreno.
Gnus was more correct in its old behavior, to wrap the References header.
Without wrapping the References header, messages with particularly long
headers may be rejected by some news servers. There has been general
discussion of this point on the USEFOR mailing list, and again my
perception of the course of that discussion is a general consensus that 1k
is unreasonably small. That's certainly my opinion. Whether or not there
should be a limit at *all* has been widely debated.
--
Russ Allbery (r...@stanford.edu) <URL:http://www.eyrie.org/~eagle/>
John Moreno
In news.software.readers Sven Guckes <guc...@math.fu-berlin.de> wrote:
> j-no...@nwu.edu (John Norstad):
> > I think it's interesting that the only two newsreaders to pass the GNKSA so
> > far are both Mac newsreaders - one an online reader, one an offline reader.
> > All of the UNIX and Windows readers which have been reviewed have failed!
>
> Yes, this definitely puts the other newsreaders to shame.
> (Yes, I know that this depends on the standard set by the GNKSA, but, hey!)
It's soon to be 3 as MT-Newswatcher is updated to conform to the GNKSA.
But the sad thing is that there are a lot of programs that could get the
GNKSA with just minor improvements - take Gnus for example. The version
reviewed was 5.3 and the only two things it fails on are:
7c Does not restrict references sensibly
16c Does not warn when posting quoted text only
7c means keeping the references under 998 octets. If they haven't
already been done both of these could be fixed in a afternoon.
Hopefully more programs will conform, and then we might have a chance to
get the commercial programs to conform (I've recently did a review of
Outlook Express for the Mac - it failed on *16* different counts). For
some reason the commercial progams seem to be the worst offenders (with
predicatablly Netscape and Microsoft offerings being the worst), but
they could be fixed by a full time programmer in short order. Hell a
lot of the problems could be fixed in a day (empty subject, empty body,
quoted text only, syntacically valid from address, no defaulting to HTML
- both OE and Netscape could elliminate about half of their problems
with almost no programming)
--
John Moreno
John Morris
POSTED AND MAILED
>> j-no...@nwu.edu (John Norstad):
>> > I think it's interesting that the only two newsreaders to pass the GNKSA so
>> > far are both Mac newsreaders - one an online reader, one an offline reader.
>> > All of the UNIX and Windows readers which have been reviewed have failed!
I currently use Agent 1.5 under Win 95.
I am also just starting to use Linux.
I am a HEAVY user of newsgroups as I make a living using
Autocad and communicate ideas via newsgroups.
Having said all that... _what is GNKSA? And... I'm sorry to
hear that Linux news apps don't pass it (whatever it is).
<g>
I always thought that Linux news apps were the best in
design. Apparently I'm wrong.... correct?
John Moreno
Russ Allbery <r...@stanford.edu> wrote:
> In news.software.readers, John Moreno <phe...@interpath.com> writes:
>
> > But the sad thing is that there are a lot of programs that could get the
> > GNKSA with just minor improvements
>
> The sad thing is that the GNKSA requires some totally broken or utterly
> unnecessary behavior, thus resulting in intelligent newsreaders not
> passing not because they are deficient but because the GNKSA is.
The only behavior that the GNKSA requires that the current version of
Gnus doesn't do is apparently 7c.
> > - take Gnus for example. The version reviewed was 5.3 and the only two
> > things it fails on are:
>
> > 7c Does not restrict references sensibly
>
> The references restriction is not "sensible."
Yes it is. It needs to be done somewhere and 998 is traditional -
whether that should be changed is a totally different question. Until
it *has* been changed it is a sensible thing to require.
> > 16c Does not warn when posting quoted text only
>
> I believe Gnus does this.
>
> > 7c means keeping the references under 998 octets.
>
> And there is no good reason for this restriction. This was discussed
> extensively on the Gnus mailing list, cc'd to Mr. Moreno.
>
> Gnus was more correct in its old behavior, to wrap the References header.
> Without wrapping the References header, messages with particularly long
> headers may be rejected by some news servers.
Even FOLDED messages with particularly long headers may be rejected - as
I said in the USEFOR list - while doing a GNKSA evaluation of Outlook
Express I discovered that my server has a 1024 limit for unfolded
headers and a 3k (3072) limit on folded headers. This means that I go
to respond and the message just disappears. Until there is a standard
requiring the server to accept longer headers, it is unreasonable to not
restrict the References header.
You may call these servers "bad" or "broken" but the fact of the matter
is that they exist (Jeroen mentions a inews server that cut lines to
512) and until the 1036 replacement comes out with stricter standards
there isn't much hope of getting the ISPs to upgrade their servers just
because a few people using some software can loose their messages under
some circumstances - as it is with people using software that doesn't
include the header at all, and others using software that just includes
the precursor, this isn't much of a problem. But that's not something
that should be counted upon.
> There has been general discussion of this point on the USEFOR mailing
> list, and again my perception of the course of that discussion is a
> general consensus that 1k is unreasonably small. That's certainly my
> opinion. Whether or not there should be a limit at *all* has been widely
> debated.
The main thing seems to be a worry that it might become too small with
longer message ids - and a, uhm, strange, desire to have all headers
potentially be of unlimited length. I'll agree that servers shouldn't
care about the length of headers, but the standards and user agents
should (70 chars is fine for Subjects, and I can't think of why a Date
should be a couple of k).
--
John Moreno
John Moreno
In news.software.readers John Morris <jmo...@nemonet.com> wrote:
> >> j-no...@nwu.edu (John Norstad):
> >> > I think it's interesting that the only two newsreaders to pass the
> >> > GNKSA so far are both Mac newsreaders - one an online reader, one an
> >> > offline reader. All of the UNIX and Windows readers which have been
> >> > reviewed have failed!
>
> I currently use Agent 1.5 under Win 95.
Agent 1.5 fails for several reasons. Go to
<http://www.xs4all.nl/~js/gnksa/Evaluations/forte-agent-1.5.txt> and see
why.
> I am also just starting to use Linux.
>
> I am a HEAVY user of newsgroups as I make a living using
> Autocad and communicate ideas via newsgroups.
>
> Having said all that... _what is GNKSA? And... I'm sorry to
> hear that Linux news apps don't pass it (whatever it is).
It's not necessarily that Linux news apps don't pass, it could simply be
that they haven't been reviewed. For instance no version of trn as been
reviewed.
As to what is the the GNKSA - it's the Good Net Keeping Seal of Approval
and is designed to help users pick their newsreaders and to tell
newsreader programmers what basic functionality should be included.
> I always thought that Linux news apps were the best in
> design. Apparently I'm wrong.... correct?
"Best in design" is a very subjective statement. GNKSA isn't designed to
pick the best - just point out problems or the lack of them.
For example, I notice that one of the ways that Agent fails is by not
allowing the user to decide to post after previously having decided to
email and vice-a-versa. If you've been using it for the last 2 years
and have never had occasion to use it to send email then this is hardly
a hardship for you. On the other hand if you send email responses
everyday then it's probably going to be a constant problem.
The GNKSA just list functionality and default behavior - how good it
looks or works is up to you to decide.
--
John Moreno
Russ Allbery
John Moreno <phe...@interpath.com> writes:
> Russ Allbery <r...@stanford.edu> wrote:
>> The references restriction is not "sensible."
> Yes it is. It needs to be done somewhere
No, it does *not* "need" to be done somewhere, except perhaps on a
server-specific basis. There is no reason *for Usenet at large* to
require cutting References headers. I was under the impression that GNKSA
was supposed to measure how well a newsreader worked with the rest of the
Net, whether it generated readable posts by default, and whether it worked
to prevent stupid mistakes. Not whether it conformed to arbitrary and
debatable technical standards irrelevant to how others perceive the
article.
It may be a *nice thing* for a newsreader to cut References to 998 octets
or whatever so that the newsreader will work better with more servers, but
that doesn't affect how good the newsreader is at *Net-Keeping*.
> Even FOLDED messages with particularly long headers may be rejected - as
> I said in the USEFOR list - while doing a GNKSA evaluation of Outlook
> Express I discovered that my server has a 1024 limit for unfolded
> headers and a 3k (3072) limit on folded headers. This means that I go
> to respond and the message just disappears.
If your server rejects posts with no error messages or if your posting
client discards error messages and doesn't tell you about them, one or the
other of the pieces of software that you're using is broken.
The behavior of a news server in rejecting a post with a header of
excessive length is to *reject* it. Not silently discard it.
> Until there is a standard requiring the server to accept longer headers,
> it is unreasonable to not restrict the References header.
I'm not claiming it's *unreasonable* to restrict the References header,
I'm claiming that you're wrong to *require* it. There's a difference.
Simon Lyall
John Moreno <phe...@interpath.com> wrote:
>Russ Allbery <r...@stanford.edu> wrote:
>> The references restriction is not "sensible."
>whether that should be changed is a totally different question. Until
>it *has* been changed it is a sensible thing to require.
Go out and actually read 1036 and 822. 822 has several pages on how
headers can be folded and encourages this for headers longer than 65(!)
characters. "traditional" is no supported by common usage or standards
and certainly doesn't apply to references headers (I used to use tin 1.2pl2
and know how many references lines are longer than that).
>> Gnus was more correct in its old behavior, to wrap the References header.
>> Without wrapping the References header, messages with particularly long
>> headers may be rejected by some news servers.
>Even FOLDED messages with particularly long headers may be rejected - as
>I said in the USEFOR list - while doing a GNKSA evaluation of Outlook
>Express I discovered that my server has a 1024 limit for unfolded
>headers and a 3k (3072) limit on folded headers. This means that I go
>to respond and the message just disappears. Until there is a standard
>requiring the server to accept longer headers, it is unreasonable to not
>restrict the References header.
Perhaps you could point out the part of 1036 that limits folded header to
3072 characters? The server is broken under the current standard.
>> There has been general discussion of this point on the USEFOR mailing
>> list, and again my perception of the course of that discussion is a
>> general consensus that 1k is unreasonably small. That's certainly my
>> opinion. Whether or not there should be a limit at *all* has been widely
>> debated.
>The main thing seems to be a worry that it might become too small with
>longer message ids - and a, uhm, strange, desire to have all headers
>potentially be of unlimited length. I'll agree that servers shouldn't
>care about the length of headers, but the standards and user agents
>should (70 chars is fine for Subjects, and I can't think of why a Date
>should be a couple of k).
If you don't like the concept of unlimited header length then complain to
the email people, *they* don't use the concept of cutting references lines
at all and they certainly don't limit them to 1000 odd characters.
We have had huge problems with arbitrary limits in the past, if you create
*any* sort of limit then programmers will instantly hard-code this in and
it is very hard to change this. A quick check of a newsgroup
(soc.culture.new-zealand actually) shows up several Subject lines that are
longer than 70 characters so I guess some people don't agree with you.
Any limits (especially if they conflict with mail standards) have to have
a bloody good reason behind them and fear that the references header will
grow to a 100K is pointless when other headers (and bodies) are allowed to
be arbitrarily long (and this includes putting 1000 X- headers, each 500
characters long in an article).
--
Simon Lyall. | Looking for Work | Mail: si...@darkmere.gen.nz
"Inside me Im Screaming, Nobody pays any attention." | MT.
"...it's about damn time that all of us who actually
give a damn about Usenet stand up and tell the people
who don't to fuck off and die." -- Russ Allbery
Erland Sommarskog
Russ Allbery <r...@stanford.edu> skriver:
>The sad thing is that the GNKSA requires some totally broken or utterly
>unnecessary behavior, thus resulting in intelligent newsreaders not
>passing not because they are deficient but because the GNKSA is.
It is also strange that GNKSA gives a stamp pf approval news reader that
may change the subject line without being asked, and given no possibility
to turn off this misfeature. I thought GNKSA was about news readers
co-operating, but I might have misunderstood something.
--
Erland Sommarskog, Stockholm, som...@algonet.se
F=F6r =F6vrigt anser jag att QP b=F6r f=F6rst=F6ras.
B=65sid=65s, I think QP should b=65 d=65stroy=65d.
Karl Kleinpaste
Simon Lyall <si...@darkmere.gen.nz> wrote:
>> Go out and actually read 1036 and 822. 822 has several pages on how
>> headers can be folded and encourages this for headers longer than 65(!)
>> characters.
phe...@interpath.com (John Moreno) writes:
> Longer than 65 or longer than 998?
Simon specifically suggested you read the relevant RFCs.
*Please* give it a try.
RFC822, page 15:
3.4.8. FOLDING LONG HEADER FIELDS
Each header field may be represented on exactly one line con-
sisting of the name of the field and its body, and terminated
by a CRLF; this is what the parser sees. For readability, the
field-body portion of long header fields may be "folded" onto
multiple lines of the actual field. "Long" is commonly inter-
preted to mean greater than 65 or 72 characters. The former
length serves as a limit, when the message is to be viewed on
most simple terminals which use simple display software; how-
ever, the limit is not imposed by this standard.
<BakshiWizards>
Folding Good. Length Limits Bad.
</BakshiWizards>
As Russ and others have said, Gnus had it right.
John Moreno
Karl Kleinpaste <ka...@jprc.com> wrote:
> Simon Lyall <si...@darkmere.gen.nz> wrote:
> >> Go out and actually read 1036 and 822. 822 has several pages on how
> >> headers can be folded and encourages this for headers longer than 65(!)
> >> characters.
>
> phe...@interpath.com (John Moreno) writes:
> > Longer than 65 or longer than 998?
>
> Simon specifically suggested you read the relevant RFCs.
> *Please* give it a try.
I did, I do, I have and any other "I " that apply.
BUT, you snipped a bit of Simon's post, the bit where he said that he
had used tin 1.2pl2 and knew how many reference lines are longer than
that - he only mentioned 65 but he was responding to my post which
mentioned 998. His statement could have been taken either way.
-snip quote from 822-
> As Russ and others have said, Gnus had it right.
Gnus doesn't have it right - given the right circumstantces it's actions
can have several bad results. Relayers dropping your articles, the
server either rejecting or simply dropping the article. Taking up
unnecessary space on users drives. The reason you won't see more of
this is because of people using other readers (including ones that don't
include the reference header at all) don't include everything.
Saying that it should be unlimited is simply short sighted - unless the
world goes to crap usenet is probably going to be around for centuries.
And unless people change then there are going to be threads that branch
out and change and end up going on for decades or more. And although by
the time that happens we might all have T3 connections and terrabyte
harddrives, we shouldn't count on it - especially given that the
information is unnecessary and redundant.
--
John Moreno
John Moreno
Erland Sommarskog <som...@algonet.se> wrote:
> Russ Allbery <r...@stanford.edu> skriver:
> >The sad thing is that the GNKSA requires some totally broken or utterly
> >unnecessary behavior, thus resulting in intelligent newsreaders not
> >passing not because they are deficient but because the GNKSA is.
>
> It is also strange that GNKSA gives a stamp pf approval news reader that
> may change the subject line without being asked, and given no possibility
> to turn off this misfeature. I thought GNKSA was about news readers
> co-operating, but I might have misunderstood something.
Co-operating AND standard usage. Prefexing the subject with Re: is
standard usage - but a newsreader that offered the option of turning
this off wouldn't fail (at least not on this count), as long as it
wasn't the default.
Which, although I hadn't previously considered it, is a way that Gnus
could allow infinte references and still get the GNKSA - have a user
adjustable default of trimming to keep within 998. At least I'd pass it
if it has such a setting - I would say it fits into the same category as
showing the Reply-To address if it's different from the From, something
that should be the default but is ultimately under user control.
--
John Moreno
Russ Allbery
Hrvoje Niksic <hni...@srce.hr> writes:
> Maybe it might be a good idea to reestablish the Usenet Seal of Approval
> project with the original aims in mind.
There are two fundamentally different things that need to be measured.
The first is how well the newsreader works with the rest of the net. Does
it create articles that other people can read? Does it take reasonable
steps towards preventing stupid mistakes? Does it allow the sort of basic
functionality that's *necessary* so that people can follow netiquette?
The second is whether the newsreader contains the sorts of features that
by now have been considered standards. Does it thread via References and
not just do subject grouping? Does it have a functional killfile? Does
it allow the author's choice of posting vs. mailing vs. doing both?
The first set answers the question "would deployment of this newsreader
harm Usenet." The second set answers the question "would I be comfortable
recommending this newsreader to a friend." I think those are two
completely separate questions that deserve their own separate criteria.
Given the current behavior of news servers, I will grant putting doing
something about References headers (truncating, wrapping, what have you)
into two. I disagree strongly with placing it in one.
John Moreno
Hrvoje Niksic <hni...@srce.hr> wrote:
> Russ Allbery <r...@stanford.edu> writes:
>
> > In news.software.readers, John Moreno <phe...@interpath.com> writes:
> >
> > > But the sad thing is that there are a lot of programs that could get
> > > the GNKSA with just minor improvements
> >
> > The sad thing is that the GNKSA requires some totally broken or utterly
> > unnecessary behavior, thus resulting in intelligent newsreaders not
> > passing not because they are deficient but because the GNKSA is.
> [...]
>
> Lars put it well: GNKSA used to be a set of *minimum* requirements for a
> newsreader. The 2.0 version is full of various totally unnecessary stuff
> that many authors won't even *bother* to implement -- not to mention the
> broken requirements.
>
> Maybe it might be a good idea to reestablish the Usenet Seal of Approval
> project with the original aims in mind.
And GNKSA/U 1.2 DOES mentions the 1000 rule - see section 4
New requirements
7c) Ensures References will fit in 998 characters M
[1.2 Uses 9 for something else]
9) Allow the user to change her mind about whether to post or mail (or
do both) and behave if doing both
a) Allows users to change their mind and mail rather than
post after having initiated a followup message M
b) Allows users to change their mind and post rather than
mail after having initiated a reply message M
c) Does not offer both posting and mailing as default behaviour M
(Upgraded from SHOULD to MUST, and 14 is now 16)
14a) Warns when attempting to post empty articles M
[New number and added for 2.0]
17) Post human-readable articles unless ordered otherwise
a) Does not (and can not) encode or encrypt articles unless
on explicit user demand M
[New number and added for 2.0]
19) Be kind to servers, leave room for others
a) Does not unnecessarily open multiple connections M
b) Does not generate excessive server load otherwise M
Which of these (besides 7c) do you think are broken or unnecessary?
I've just normalized the two (with comments for the differences, hard,
soft) and there are about 22 different changes. The above 7 MUST, 13
additional SHOULDs and 1 SHOULD upgraded to MUST, 1 MUST downgraded to
SHOULD.
It's in the same format as the 2.0 reviews (so it's missing the
Rationales) and is about 7k. I'll post it if anybody is interested.
--
John Moreno
John Moreno
Simon Lyall <si...@darkmere.gen.nz> wrote:
> John Moreno <phe...@interpath.com> wrote:
> >Russ Allbery <r...@stanford.edu> wrote:
> >> The references restriction is not "sensible."
> >Yes it is. It needs to be done somewhere and 998 is traditional -
> >whether that should be changed is a totally different question. Until
> >it *has* been changed it is a sensible thing to require.
>
> Go out and actually read 1036 and 822. 822 has several pages on how
> headers can be folded and encourages this for headers longer than 65(!)
> characters. "traditional" is no supported by common usage or standards and
> certainly doesn't apply to references headers (I used to use tin 1.2pl2
> and know how many references lines are longer than that).
Longer than 65 or longer than 998? And I think the 998 is in common
enough usage to be called a tradition - for newsreaders that do references
I've seen several classes of behavior
1) Don't add to it - just use immediate precursor (1036 compliant)
2) Trim to last 2 + immediate precursor (1036, with a hand wave at son)
3) Trim to 998 using the rules in son-of-1036
4) Don't trim
Plus the ones that don't include it at all and ones that trim by grabbing
a (semingly) random bit in the middle and precursor.
> >> Gnus was more correct in its old behavior, to wrap the References header.
> >> Without wrapping the References header, messages with particularly long
> >> headers may be rejected by some news servers.
>
> >Even FOLDED messages with particularly long headers may be rejected - as
> >I said in the USEFOR list - while doing a GNKSA evaluation of Outlook
> >Express I discovered that my server has a 1024 limit for unfolded
> >headers and a 3k (3072) limit on folded headers. This means that I go
> >to respond and the message just disappears. Until there is a standard
> >requiring the server to accept longer headers, it is unreasonable to not
> >restrict the References header.
>
> Perhaps you could point out the part of 1036 that limits folded header to
> 3072 characters? The server is broken under the current standard.
As I'm sure you are aware 1036 is silent on this. son-of-1036 allows
relayers to not pass them along if the header is more than 1000 - with no
reference to folding.
No, under the current official standard the server can drop it anytime it
wants to, under the unofficial standard it can't drop until 1000.
> >> There has been general discussion of this point on the USEFOR mailing
> >> list, and again my perception of the course of that discussion is a
> >> general consensus that 1k is unreasonably small. That's certainly my
> >> opinion. Whether or not there should be a limit at *all* has been widely
> >> debated.
>
> >The main thing seems to be a worry that it might become too small with
> >longer message ids - and a, uhm, strange, desire to have all headers
> >potentially be of unlimited length. I'll agree that servers shouldn't
> >care about the length of headers, but the standards and user agents
> >should (70 chars is fine for Subjects, and I can't think of why a Date
> >should be a couple of k).
>
> If you don't like the concept of unlimited header length then complain to
> the email people, *they* don't use the concept of cutting references lines
> at all and they certainly don't limit them to 1000 odd characters.
I don't object to a unlimited header length in general - it just doesn't
apply to *ALL* headers. In fact as long as it isn't used as a excuse to
say that limits can't be set on individual headers then I approve of it.
> We have had huge problems with arbitrary limits in the past, if you create
> *any* sort of limit then programmers will instantly hard-code this in and
> it is very hard to change this. A quick check of a newsgroup
> (soc.culture.new-zealand actually) shows up several Subject lines that are
> longer than 70 characters so I guess some people don't agree with you.
70 chars is fine for a subject, 2k isn't. 70 is a nice minimum. Since
this is something that is usually entered by the user it's not likely to
be a real problem.
> Any limits (especially if they conflict with mail standards) have to have
> a bloody good reason behind them and fear that the references header will
> grow to a 100K is pointless when other headers (and bodies) are allowed to
> be arbitrarily long (and this includes putting 1000 X- headers, each 500
> characters long in an article).
Other headers aren't persistent. Also unless you think usenet is going to
go away soon it's not going to stop at 100k - with the way threads branch
I consider it likely for some of them to last for decades.
--
John Moreno
Hrvoje Niksic
Russ Allbery <r...@stanford.edu> writes:
> In news.software.readers, John Moreno <phe...@interpath.com> writes:
>
> > But the sad thing is that there are a lot of programs that could get the
> > GNKSA with just minor improvements
>
> The sad thing is that the GNKSA requires some totally broken or utterly
> unnecessary behavior, thus resulting in intelligent newsreaders not
> passing not because they are deficient but because the GNKSA is.
[...]
Lars put it well: GNKSA used to be a set of *minimum* requirements for
a newsreader. The 2.0 version is full of various totally unnecessary
stuff that many authors won't even *bother* to implement -- not to
mention the broken requirements.
Maybe it might be a good idea to reestablish the Usenet Seal of
Approval project with the original aims in mind.
--
Hrvoje Niksic <hni...@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"A Real Programmer's code can awe with its fiendish brilliance, even
as its crockishness appalls." -- the Jargon File
Lars Magne Ingebrigtsen
Hrvoje Niksic <hni...@srce.hr> writes:
> Maybe it might be a good idea to reestablish the Usenet Seal of
> Approval project with the original aims in mind.
I think a Usenet Seal of Approval would be nice. What we have now is
John Moreno & Friends' List Of Neat-o-Kean-o Features That We Think
The Newsreaders We Use Should Have.
They've destroyed any of hope of ever making the GNKSA relevant.
--
(domestic pets only, the antidote for overdose, milk.)
la...@ifi.uio.no * Lars Magne Ingebrigtsen
Admiral
This all reminds me of ISO9000 ... shudder ...
On 25 Jan 1998 03:00:48 +0100, Hrvoje Niksic <hni...@srce.hr> wrote:
>Russ Allbery <r...@stanford.edu> writes:
>
>> In news.software.readers, John Moreno <phe...@interpath.com> writes:
>>
>> > But the sad thing is that there are a lot of programs that could get the
>> > GNKSA with just minor improvements
>>
>> The sad thing is that the GNKSA requires some totally broken or utterly
>> unnecessary behavior, thus resulting in intelligent newsreaders not
>> passing not because they are deficient but because the GNKSA is.
>[...]
>
>Lars put it well: GNKSA used to be a set of *minimum* requirements for
>a newsreader. The 2.0 version is full of various totally unnecessary
>stuff that many authors won't even *bother* to implement -- not to
>mention the broken requirements.
>
>Maybe it might be a good idea to reestablish the Usenet Seal of
>Approval project with the original aims in mind.
>
>--
>Hrvoje Niksic <hni...@srce.hr> | Student at FER Zagreb, Croatia
>--------------------------------+--------------------------------
>"A Real Programmer's code can awe with its fiendish brilliance, even
>as its crockishness appalls." -- the Jargon File
---
*
* *
* * Admiral ... http://www.tiac.net/users/admiral ...
John Moreno
Simon Lyall <si...@darkmere.gen.nz> wrote:
> John Moreno <phe...@interpath.com> wrote:
> >Simon Lyall <si...@darkmere.gen.nz> wrote:
> >> certainly doesn't apply to references headers (I used to use tin 1.2pl2
> >> and know how many references lines are longer than that).
> >Longer than 65 or longer than 998? And I think the 998 is in common
> >enough usage to be called a tradition
>
> To clarify I mean 998. tin1.2pl2 has a fixed length buffer or around 1000
> characters. If you use this to enter a newsgroup with articles that have
> lines longer than this (usually Xref and References) then it will print an
> error message to screen for every single one of them. Going into a busy
> newsgroup can take over 10 minutes while all the error messages scroll
> past at about 1 every two second.
Ok. I recently did a poll of the 22 newsgroups that I read (usually
keep them for 2 weeks) and found only 2 articles with References over
998. But of course this might not be a good sample as I could be
reading unusual ngs (on the other hand you could have been reading the
unusual groups).
> >> Perhaps you could point out the part of 1036 that limits folded header to
> >> 3072 characters? The server is broken under the current standard.
>
> >As I'm sure you are aware 1036 is silent on this. son-of-1036 allows
> >relayers to not pass them along if the header is more than 1000 - with no
> >reference to folding.
>
> If you are refering to paragraph 4 of section 4.6 then you are being very
> selective in what you read. I see plenty of references to folding.
>
> I quote:
>
> --cut-here--
> 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. Relayers and trans-
> mission paths confronted with lines beyond their internal
> limits (if any) MUST not simply inject EOLs at random
> places; they MAY break headers (as described in 4.2.3) as a
> last resort, and otherwise they MUST either pass the long
> lines through unaltered, or refuse to pass the article at
> all (see section 9.1 for further discussion).
>
> NOTE: The limit here is essentially the same mini-
> mum as that specified for SMTP mail in RFC 821
> [rrr]. Implementors are warned that Path (see
> section 5.6) and References (see section 6.5)
> headers, in particular, often become several hun-
> dred characters long, so 1000 is not an overly
> generous limit.
>
> --cut-here--
>
> It says that if you are dumb enough to create a relayer with a limit you
> HAVE to make it at least 1000 characters and if you come across an article
> out side that limit you should either drop it, accept it or maybe fold the
> header but you MUST NOT mangle it at random.
Maybe it's a difference in interpretation of "header logical lines" as I
took that to mean the UNFOLDED header line. What I meant wasn't that
the sectoin didn't refer to folding but that it didn't say anything
about accepting longer lines if they were folded.
> >> We have had huge problems with arbitrary limits in the past, if you create
> >> *any* sort of limit then programmers will instantly hard-code this in and
> >> it is very hard to change this. A quick check of a newsgroup
> >> (soc.culture.new-zealand actually) shows up several Subject lines that are
> >> longer than 70 characters so I guess some people don't agree with you.
>
> >70 chars is fine for a subject, 2k isn't. 70 is a nice minimum. Since
> >this is something that is usually entered by the user it's not likely to
> >be a real problem.
>
> What do you mean "70 is a nice minimum" ?
A minimum that a newsreader must accept and display - a GNKSA
requirement, for any RFC standard I would propose 255 (chars not bytes)
if I was proposing anything. My real point here was that a requirement
that newsreaders accept subject of 5k is silly. I've seen people make
mistakes and paste the body of a message in the subect - resulting in
that very thing. A standard that requires newsreaders to accept that is
just plain wrong.
> >> Any limits (especially if they conflict with mail standards) have to have
> >> a bloody good reason behind them and fear that the references header will
> >> grow to a 100K is pointless when other headers (and bodies) are allowed to
> >> be arbitrarily long (and this includes putting 1000 X- headers, each 500
> >> characters long in an article).
>
> >Other headers aren't persistent. Also unless you think usenet is going to
> >go away soon it's not going to stop at 100k - with the way threads branch
> >I consider it likely for some of them to last for decades.
>
> Subject is persistent and Newsgroups and FollowUp-To can be.
Ok, persistent and continuously growing.
> However you have remeinded me of one thing so I will do another draft of
> references with a SHOULD on trimming the header at some *large* limit.
References don't need to be *long*, it only needs to go back far enough
to find another message in the chain anything over that is redundant.
People have pointed out how disk space and transmission speeds have
increased and say in the future 2 or eve a 100k headers are going to be
no problem, there is another side of this. If you want to assume that
things are going to get better, then why not assume that they are going
to get better in a way that only requires 1 back reference?
As I recently suggested on the USEFOR list - if you want to put in a
limit and make it large why not do it in a manner that is byte
independent - say 20 or 30 references? What's the biggest gap you've
ever seen - 2 seems quite common and I know I've seen 4, I think I've
seen 6. Of course this might be because of the fact that I locally
store the messages and set my own expire limits.
--
John Moreno
John Moreno
Lars Magne Ingebrigtsen <la...@ifi.uio.no> wrote:
> Hrvoje Niksic <hni...@srce.hr> writes:
>
> > Maybe it might be a good idea to reestablish the Usenet Seal of
> > Approval project with the original aims in mind.
>
> I think a Usenet Seal of Approval would be nice. What we have now is
> John Moreno & Friends' List Of Neat-o-Kean-o Features That We Think
> The Newsreaders We Use Should Have.
>
> They've destroyed any of hope of ever making the GNKSA relevant.
Uhm, I think I've been insulted - but no more so than Jeroen. I haven't
written a single requirement and the total effect of my input (other
than by doing reviews) has been a slight rewording of the requirement
not to cancel other peoples articles - to lessen it unfortunately,
because on some systems it's not POSSIBLE to verify the user.
Look at message <1d3dqcn.197...@roxboro0-039.dyn.interpath.net>,
you'll see the list of new MUST requirements. Please tell me which ones
you think fall into the category of "Neat-o-Kean-o Features". Possibly
the one about being kind to the server? Not doing HTML or MIME by
default (although how a lack of a feature could be considered a
"Neat-o-Kean-o Features" is beyond me)?
Look at the difference between 1.2 and 2.0 and I think you'll find that
they are in fact minimal and mainly in the area of clarification of
points already in 1.2. For instance, there is a additional SHOULD
regarding the quote prefix - 1.2 mentions that one should be there but
doesn't mention what it should be. 2.0 does, but NEITHER requires it.
If your newsreader wants to quote by saying start quote and stop quote
at the beginning and end of the quoted message it WILL pass the
requirements for quoting. It will be pointed out that the quoting is
nonstandard but it will pass. Also point 2 (separate commands for
posting, replying and followups) has 2 additional SHOULDs referring to
terminology - that it be standard and non-ambiguous).
The only items in the new 2.0 version of the GNKSA that could possibly
be called "Neato-Kean-o Features" are:
9) Allow the user to change her mind about whether to post or mail
Which is a MUST
and
13b) Allows superseding articles
14d Allows rewrapping quoted text
Which are SHOULDs.
I will admit that 14d is a "Neato-Kean-o Feature", but everybody I've
described it to sufficiently for them to understand says that yes that
really should be in all newsreaders. It may not be possible for it to
be in all, but it deserves mentioning just for the hope that new
newsreaders authors will consider implementing it. Given that this is
somethig Gnus does, I didn't think you'd be against it.
As for being able to change their minds about whether to post or mail, I
don't consider that a "Neato-Kean-o Feature" - given inexperienced
posters it's essential, otherwise they'll never take a discussion
private. Probably not even realize that this is possible.
Take a look at the above referenced message and then if you want I'll
post the list of new SHOULDs.
--
John Moreno
John Norstad
In article <m3iurafh...@windlord.Stanford.EDU>, Russ Allbery
<r...@stanford.edu> wrote:
> In news.software.readers, John Moreno <phe...@interpath.com> writes:
>
> > But the sad thing is that there are a lot of programs that could get the
> > GNKSA with just minor improvements
>
> The sad thing is that the GNKSA requires some totally broken or utterly
> unnecessary behavior, thus resulting in intelligent newsreaders not
> passing not because they are deficient but because the GNKSA is.
>
> > - take Gnus for example. The version reviewed was 5.3 and the only two
> > things it fails on are:
>
> > 7c Does not restrict references sensibly
>
> The references restriction is not "sensible."
>
> > 16c Does not warn when posting quoted text only
>
> I believe Gnus does this.
>
> > 7c means keeping the references under 998 octets.
>
> And there is no good reason for this restriction. This was discussed
> extensively on the Gnus mailing list, cc'd to Mr. Moreno.
>
> Gnus was more correct in its old behavior, to wrap the References header.
> Without wrapping the References header, messages with particularly long
> headers may be rejected by some news servers. There has been general
> discussion of this point on the USEFOR mailing list, and again my
> perception of the course of that discussion is a general consensus that 1k
> is unreasonably small. That's certainly my opinion. Whether or not there
> should be a limit at *all* has been widely debated.
Several years ago, I released a new version of NewsWatcher which among
many other changes had no restriction on the length of the References
header, and folded it properly.
I got a flood of angry reports about articles posted using NewsWatcher
which were showing up on many servers around the world with seriously
mangled References headers.
After much detective work, it turned out the problem was caused by a bug
in INN, one of the most popular news servers (and rightly so). I
corresponded with Rich Salz, the author of INN, about the problem. INN
couldn't handle folded References headers at all, and had a limit of about
1000 maximum characters in the header. At Rich's suggestion, I immediately
released an emergency "fixed" version of NewsWatcher which didn't do
folding and which had the 1000 character limit. In theory, in this
situation, NewsWatcher was "right" and INN was "wrong" (the bug was in
INN). In practice, of course, the most important thing is to interoperate
properly with current implementations, even when they're broken. I had to
fix NewsWatcher right away. Things work out this way sometimes with
Internet protocols.
I believe this was INN 1.4. I don't know if later versions have fixed
these problems or not. In any case, I'll bet that INN 1.4 is still widely
used on Usenet, we still have the problem today, and we'll continue to
have the problem well into the forseeable future.
I agree that in the best of all possible worlds, unlimited folded
References headers is obviously best. Unfortunately, in the real world,
this causes problems (or, at least, it caused major problems as recently
as just a few years ago).
This may very well be the reasoning historically for the GNKSA rule 7c. I
don't know.
lvi...@cas.org
According to Lars Magne Ingebrigtsen <la...@ifi.uio.no>:
:Hrvoje Niksic <hni...@srce.hr> writes:
:
:> Maybe it might be a good idea to reestablish the Usenet Seal of
:> Approval project with the original aims in mind.
:
:I think a Usenet Seal of Approval would be nice. What we have now is
:John Moreno & Friends' List Of Neat-o-Kean-o Features That We Think
:The Newsreaders We Use Should Have.
And who's "Usenet" do you use? Usenet is just a group of 'friends'
(in the loosest sense of the word I suspect) exchanging files. John
and his 'friends' have just as much right to create a list of 'neat o
features' as anyone else. You could jump right in and create your own.
--
Larry W. Virden INET: lvi...@cas.org
<URL:http://www.teraform.com/%7Elvirden/> <*> O- "We are all Kosh."
Unless explicitly stated to the contrary, nothing in this posting should
be construed as representing my employer's opinions.
Jeroen Scheerder
Lars Magne Ingebrigtsen <la...@ifi.uio.no>:
> I think a Usenet Seal of Approval would be nice. What we have now is
> John Moreno & Friends' List Of Neat-o-Kean-o Features That We Think
> The Newsreaders We Use Should Have.
Hmmm. Being the GNKSA chief paperclip bender, I seem to be addressed
here.
I don't think this type of suggestivity helps the good cause -- for what
it's worth. The GNKSA strives to set a suite of sensible requirements,
with the aim of increasing both the basic `politeness' of existing
(used) Usenet software, and users' awareness of the fact that many
software isn't particularly well-behaved.
I may or may not have shown less then perfect judgement regarding
particular issues; if you think so, you're perfectly welcome to raise
them. I've been known to listen to reason, every now and then.
> They've destroyed any of hope of ever making the GNKSA relevant.
Strange. While these days some Usenet software seems to be suffering
from featuritis, I explicitly kept GNKSA clear of it, I thought. When
bringing the GNKSA up to date, I went to great length to abstract away
from the Unix-bias it somewhat breathed (due to the fact that it was
pretty much written with `rn' acting as a role model).
It may be imperfect, but it's surely not what you make it out to be, I
hope. Do share your objections with me, though -- there's even a
mailing list for that. Use it. If it's so bad, it can only improve;
what have you got to lose?
Improbably yours,
J.
Jeroen Scheerder
John Norstad <j-no...@nwu.edu>:
[Reference limiting/folding issues]
> I agree that in the best of all possible worlds, unlimited folded
> References headers is obviously best. Unfortunately, in the real world,
> this causes problems (or, at least, it caused major problems as recently
> as just a few years ago).
> This may very well be the reasoning historically for the GNKSA rule 7c. I
> don't know.
It's _exactly_ the reason, as I tried to explain myself. Thank you for
the clear explanation.
Some people now seem to think the servers that suffer the bug at present
have slipped into marginality. They may or may not be right; for good
order, and as a "GNKSA work in progress" message: I'm trying to get more
information on that one.
If the necessity to do the prescribed, admittedly sub-optimal,
restriction on References had disappeared, the GNKSA _will_ recognize
that fact, I promise.
John Moreno
Jon Ribbens <j...@oaktree.co.uk> wrote:
> John Moreno <phe...@interpath.com> wrote:
> > New requirements
> > 7c) Ensures References will fit in 998 characters M
>
> This is broken and unncecessary.
Possibly - see the posts by John Norstad and Jeroen on this issue. This
exact number may no longer be unnecessary, but I don't think it can be
successfully defended that in a hundred years somebody will need to have
a megabyte reference being passed around just because nobody thought to
trim it. It might not be as much of a burden on them as it would be on
us, but I certainly wouldn't want to count upon that.
> > 9) Allow the user to change her mind about whether to post or mail (or
> > do both) and behave if doing both
> > a) Allows users to change their mind and mail rather than
> > post after having initiated a followup message M
>
> This is broken and unnecessary.
Why? If this isn't there then people new to the net are much less
likely to think of taking a discussion private. I consider this a
essential feature of equal importance to being able to reply by mail at
all.
> > b) Allows users to change their mind and post rather than
> > mail after having initiated a reply message M
>
> This is broken and unnecessary.
Here I think you're on firmer ground - since logically the interface
should be the same as above, if you've got one you've got the other.
> > (Upgraded from SHOULD to MUST, and 14 is now 16)
> > 14a) Warns when attempting to post empty articles M
>
> This is broken and unnecessary.
Ok, now was it broken and unnecessary when 1.2 had it as a SHOULD or is
it just the change to a MUST which is unnecessary? If so why?
> > Which of these (besides 7c) do you think are broken or unnecessary?
>
> See above.
Was this necessary?
--
John Moreno
Jeroen Scheerder
John Moreno <phe...@interpath.com>:
> There is nothing in the GNKSA which forbids wrapping - just from having
> a reference header longer than 998+EOL.
Allow me to set this straight, so that no confusion exists on this
point: yes, there _is_ something in GNKSA 2 that explicitly rules out
folding the References header. It's there because I put it in with
great reluctance, because I judged it necessary. This reason is
explained in <1d3d6kb.ocy...@cats.xs4all.nl> and
<j-norstad-260...@norstad.at.nwu.edu> -- so rest assured,
gentle readers, it's of some weird personal fetish concerning mucking
about with precious article headers of mine. :-)
On a further note, this matter is under discussion (on the GNKSA workers
mailing list). I'm considering the possibility of allowing References
folding (estimating the damage this will cause) as I'm typing this.
-- J.
Jeroen Scheerder
[ this is superseding message,
fixing a few nasty typo's ]
John Moreno <phe...@interpath.com>:
> There is nothing in the GNKSA which forbids wrapping - just from having
> a reference header longer than 998+EOL.
Allow me to set this straight, so that no confusion exists on this
point: yes, there _is_ something in GNKSA 2 that explicitly rules out
folding the References header. It's there because I put it in. I did
so very reluctantly, only because I judged it a necessary evil. This
reason is explained in <1d3d6kb.ocy...@cats.xs4all.nl> and
<j-norstad-260...@norstad.at.nwu.edu> -- so rest assured,
gentle readers, it's not some weird personal fetish concerning mucking
John Moreno
John Norstad <j-no...@nwu.edu> wrote:
> After much detective work, it turned out the problem was caused by a bug
> in INN, one of the most popular news servers (and rightly so). I
> corresponded with Rich Salz, the author of INN, about the problem. INN
> couldn't handle folded References headers at all, and had a limit of about
> 1000 maximum characters in the header. At Rich's suggestion, I immediately
> released an emergency "fixed" version of NewsWatcher which didn't do
> folding and which had the 1000 character limit. In theory, in this
> situation, NewsWatcher was "right" and INN was "wrong" (the bug was in
> INN). In practice, of course, the most important thing is to interoperate
> properly with current implementations, even when they're broken. I had to
> fix NewsWatcher right away. Things work out this way sometimes with
> Internet protocols.
>
> I believe this was INN 1.4. I don't know if later versions have fixed
> these problems or not. In any case, I'll bet that INN 1.4 is still widely
> used on Usenet, we still have the problem today, and we'll continue to
> have the problem well into the forseeable future.
I have about a dozen free (or formerly free since I don't keep good
track of them) newservers bookmarked in Cyberdog. It took me about 1
minute to locate a server that is using 1.4, details:
Receive 88 bytes.
>00000000> 201 news01.uni-trier.de InterNetNews NNRP server INN 1.4
>00000039> 22-Dec-93 ready (no posting).
I then looked up another dozen and none of servers used INN had version
numbers less than 1.5, go figure. Of course, it's not going to be of
much comfort to the people who can't post that there are lots of others
servers throughout the world which would allow the to do so.
--
John Moreno
John Moreno
Jeroen Scheerder <j...@xs4all.nl> wrote:
> [ this is superseding message,
> fixing a few nasty typo's ]
>
> John Moreno <phe...@interpath.com>:
>
> > There is nothing in the GNKSA which forbids wrapping - just from having
> > a reference header longer than 998+EOL.
>
> Allow me to set this straight, so that no confusion exists on this
> point: yes, there _is_ something in GNKSA 2 that explicitly rules out
Mea Culpa.
Can I lie and say I just said this to show that the GNKSA wasn't just a
"John Moreno and Friends" document? Would you believe...
--
John Moreno
Lars Magne Ingebrigtsen
lvi...@cas.org writes:
> And who's "Usenet" do you use? Usenet is just a group of 'friends'
> (in the loosest sense of the word I suspect) exchanging files. John
> and his 'friends' have just as much right to create a list of 'neat o
> features' as anyone else. You could jump right in and create your own.
Beyond stating the obvious, what is your point, caller?
Kathy I. Morgan
...about features I consider important in a well-behaved reader. Are you
a troll? Where were you during the discussion that culminated in the
GNKSA?
There are hundreds of thousands of new users who have come on line
recently and are continuing to come on line. They don't know what a FAQ
is, have never read one, don't know how to find the fine manual, haven't
a clue about netiquette, and are not about to go looking for that
information. They don't even know it's out there!
An experienced user, considerate of others and familiar with netiquette,
could probably use almost any newsreader without becoming a nuisance to
the rest of the world, but that simply isn't true of most of these
newbies. They don't mean any harm and most of them are mortified when
they learn that some of the things they do are considered totally
unacceptable. Software that meets the GNKSA standard can help save them
from that embarassment and make Usenet more agreeable for the rest of
us.
If you can make an intelligent and informed decision about which
newsreader to use and you don't like GNKSA, that's fine for you. It's
not fine for an awful lot o poorly informed users. If you want to
participate in discussions regarding future revisions of the GNKSA, I'm
sure Jeroen will listen--after all, he listened to others during the
last round of discussion.
Personally, I'm really pleased about the GNKSA and I do make a point to
mention it when discussing newsreaders. I have been incredibly pleased
with my newsreader since I first downloaded a copy to try it out; it's
icing on the cake that now I can brag about it being the first one to
earn the new GNKSA.
Kathy
Hrvoje Niksic
phe...@interpath.com (John Moreno) writes:
> I don't know about him, but *I'd* appreciate it if you took a look
> at the list of changes and give specific objections to the MUST and
> then maybe latter the SHOULDs.
If you hadn't taken insult in Lars' saying that GNKSA 2 was just a
feature wishlist, you wouldn't have missed the point of his article,
which is that GNKSA 2 is too complex to become relevant as a basic
"Seal of Approval", and yet too lightweight and redundant to serve as
an RFC replacement.
Has anyone ventured to look at `rn' and see if it would pass the new
seal requirements? How many "problems" would there be with it? How
many SHOULD's would it violate?
The original idea behind the seal was to list the most basic things a
newsreader should support (or not support) to be worthy the very
*attention* of the Usenet public. GNKSA 2 is very far from that, and
thus its relevance is approaching nil. :-(
--
Hrvoje Niksic <hni...@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Ask not for whom the <CONTROL-G> tolls.
John Moreno
Hrvoje Niksic <hni...@srce.hr> wrote:
> phe...@interpath.com (John Moreno) writes:
>
> > I don't know about him, but *I'd* appreciate it if you took a look
> > at the list of changes and give specific objections to the MUST and
> > then maybe latter the SHOULDs.
>
> If you hadn't taken insult in Lars' saying that GNKSA 2 was just a
> feature wishlist, you wouldn't have missed the point of his article,
> which is that GNKSA 2 is too complex to become relevant as a basic
> "Seal of Approval", and yet too lightweight and redundant to serve as
> an RFC replacement.
And you've apparently missed the point of MY refering to the list of
changes - there have been 7 (count them SEVEN) additional MUST
requirements added to the GNKSA in moving from version 1.2 to 2.0.
2 - Don't hog or abuse the server
1 - Don't spew HTML or otherwise unreadable articles by default
1 - Post and mail only upon user request
2 - Let user change mind about whether to post or mail
1 - Work with old servers (998)
And one SHOULD changed to a must
1 - Warn when posting empty article
> Has anyone ventured to look at `rn' and see if it would pass the new
> seal requirements? How many "problems" would there be with it? How
> many SHOULD's would it violate?
No one has submitted a review - why don't you. Did it pass the 1.2
GNKSA?
> The original idea behind the seal was to list the most basic things a
> newsreader should support (or not support) to be worthy the very
> *attention* of the Usenet public. GNKSA 2 is very far from that, and
> thus its relevance is approaching nil. :-(
The GNKSA 2 is NOT very far from that - look at the above list, almost
half of the new items are "don't kill the server or send out articles
that other people can't read". This is complicated or somehow stuff
that a newsreader can do and still be worth looking at?
Fine, you use a newsreader that opens up a new connection for every
article read, me I'll stick with ones that only open up one or two
connections per session. And I'll stick with not sending out HTMLized
messages or whatever the flavor of the month is - they'll be just plain
text and won't appear in dayglo colors or with little burning logs which
you can click on to go to my home page, but they'll be readable by
everybody that can read english.
--
John Moreno
John Moreno
Lars Magne Ingebrigtsen <la...@ifi.uio.no> wrote:
> lvi...@cas.org writes:
>
> > And who's "Usenet" do you use? Usenet is just a group of 'friends' (in
> > the loosest sense of the word I suspect) exchanging files. John and his
> > 'friends' have just as much right to create a list of 'neat o features'
> > as anyone else. You could jump right in and create your own.
>
> Beyond stating the obvious, what is your point, caller?
I don't know about him, but *I'd* appreciate it if you took a look at
the list of changes and give specific objections to the MUST and then
maybe latter the SHOULDs. Instead of trying to put it down by saying
it's just me and my friends which is just plain wrong unless you think
I'm trying to co-op the movement (which I have no interest in doing, the
least (but simpliest) important reason why not is I don't have the
resources to do so). I'm a Johnny come lately for the GNKSA.
But I have done a few reviews and I do agree with all of the MUST and I
would certainly like to see something done that could hopefully impact
the Outlook Express and Netscape of the usenet world.
Look at message <1d3dqcn.197...@roxboro0-039.dyn.interpath.net>
and give a detailed response.
The "John Moreno & Friends' List Of Neat-o-Kean-o Features That We Think
The Newsreaders We Use Should Have", besides being totatly inaccurate is
also beneath you.
--
John Moreno
Jon Ribbens
-----BEGIN PGP SIGNED MESSAGE-----
John Moreno <phe...@interpath.com> wrote:
> > > 7c) Ensures References will fit in 998 characters M
> >
> > This is broken and unncecessary.
>
> Possibly - see the posts by John Norstad and Jeroen on this issue. This
> exact number may no longer be unnecessary, but I don't think it can be
> successfully defended that in a hundred years somebody will need to have
> a megabyte reference being passed around just because nobody thought to
> trim it.
Your argument is backwards - you are giving an argument that the software
not be required to produce very long References headers. This is not what
the GNKSA/U is requiring - it says that the software is required not to
produce very long References headers. What is your argument for this?
> > > a) Allows users to change their mind and mail rather than
> > > post after having initiated a followup message M
> >
> > This is broken and unnecessary.
>
> Why? If this isn't there then people new to the net are much less
> likely to think of taking a discussion private.
I don't see why. I have almost never started writing a post and then
decided to email, and even more rarely has my change of mind happened
after I actually started writing my response. Even if it's true, then
it should not be a MUST, but a SHOULD.
> I consider this a essential feature of equal importance to being able
> to reply by mail at all.
Now you're just being ridiculous.
> > > (Upgraded from SHOULD to MUST, and 14 is now 16)
> > > 14a) Warns when attempting to post empty articles M
> >
> > This is broken and unnecessary.
>
> Ok, now was it broken and unnecessary when 1.2 had it as a SHOULD or is
> it just the change to a MUST which is unnecessary? If so why?
No, it was excellent when it was a SHOULD. I don't think that empty posts
cause sufficient problems or are sufficiently common to warrant a MUST on
this.
> Was this necessary?
Was what necessary?
Cheers
Jon
--
____
\ // Jon Ribbens // 100MB virtual-hosted // www.oaktree.co.uk
\// j...@oaktree.co.uk // web space for 99UKP //
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBNNNOboMzEl4yn7LtAQFQlwQAv4/Cvolia9Q1g/puwSYNjqje2Tz5Qs5D
x+wRQoYPTZIccCz9CFL9SyFi07KBlSUDQ3Hc6AlPxx7Vvx+K8Hq6G+5HBuFDbheg
U0f1KFcN/0/3If+jVcZEV8Er5v0cYYuSIcUibEVQhy15xz90TEcGQLdezdDBRYH6
cfe6/zt0vuo=
=BbLn
-----END PGP SIGNATURE-----
Jon Ribbens
-----BEGIN PGP SIGNED MESSAGE-----
Kathy I. Morgan <kmo...@polarnet.com> wrote:
> ...about features I consider important in a well-behaved reader. Are you
> a troll?
I'm a troll[er] because I disagree with you? Neat.
> Where were you during the discussion that culminated in the GNKSA?
Busy, I expect. Where was this discussion?
> Software that meets the GNKSA standard can help save them from that
> embarassment and make Usenet more agreeable for the rest of us.
Yeah. So it's important that the GNKSA/U requirements are sensible,
so as not to devalue its importance.
Cheers
Jon
--
____
\ // Jon Ribbens // 100MB virtual-hosted // www.oaktree.co.uk
\// j...@oaktree.co.uk // web space for 99UKP //
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBNNNPIYMzEl4yn7LtAQHdTwP+JmoS1xV2kTV9zV14aRyRVSTTdbNGan3s
d0/iaBgqLtLlmIvNk/jBc4i1H/TDnej5Aeyae8PQ26sypecQJRL/US2RK3pHy+5b
Tg2RObHy8Pdc+Jw/bTNkCyMaFUf33ehQEbLmMnRG+Hphs+lSxUweuzWGISsMoqox
cvIdBWgOuTs=
=ojs8
-----END PGP SIGNATURE-----
Erland Sommarskog
j...@oaktree.co.uk (Jon Ribbens) skriver:
>I don't see why. I have almost never started writing a post and then
>decided to email, and even more rarely has my change of mind happened
>after I actually started writing my response. Even if it's true, then
>it should not be a MUST, but a SHOULD.
It sure has happened to me, but I've managed to do it without any
particular support in the news reader. On Unix, just save the text
to a file, exit the editor, abort the action, and initiate the
other action, re-using the same file. On Windows it's even easier,
just use the clipboard(*).
I agree entirely with Jon, these requirements seems completely
unnecessary. There are a lot more important stuff that GNKSA could
cover. Handling of 8-bit characters for instance.
The only issue I find important in this area, is that it should be
possible to post and mail in the same action. (It should not be
the default, though.)
(*) Before someone tell me that I can do the same thing on Unix: I have
only used Unix on ASCII terminals and terminal emulators.
--
Erland Sommarskog, Stockholm, som...@algonet.se
F=F6r =F6vrigt anser jag att QP b=F6r f=F6rst=F6ras.
B=65sid=65s, I think QP should b=65 d=65stroy=65d.
John Moreno
Erland Sommarskog <somma...@algonet.se> wrote:
> j...@oaktree.co.uk (Jon Ribbens) skriver:
> >I don't see why. I have almost never started writing a post and then
> >decided to email, and even more rarely has my change of mind happened
> >after I actually started writing my response. Even if it's true, then
> >it should not be a MUST, but a SHOULD.
>
> It sure has happened to me, but I've managed to do it without any
> particular support in the news reader. On Unix, just save the text
> to a file, exit the editor, abort the action, and initiate the
> other action, re-using the same file. On Windows it's even easier,
> just use the clipboard(*).
This is to encourage the usage of email for off topic responses - if the
user (probably someone new to computers as well as the net) changes his
mind it is imperative that this be simple and easy. Just as it is
necessary for it to be clear so that he knows this is possible at all.
-snip-
> The only issue I find important in this area, is that it should be
> possible to post and mail in the same action. (It should not be
> the default, though.)
Just out of curiosity, why the same action? Why not a easily done
second step - frex NewsWatcher allows you to do this by simply clicking
on the icon for mail or news (which one will depend upon whether you
started out for news or mail)? It is not a GNKSA requirement that it be
able to do both, although there are requirements if it does do both.
--
John Moreno
John Moreno
In news.software.readers Jon Ribbens <j...@oaktree.co.uk> wrote:
> John Moreno <phe...@interpath.com> wrote:
> > > > 7c) Ensures References will fit in 998 characters M
> > >
> > > This is broken and unncecessary.
> >
> > Possibly - see the posts by John Norstad and Jeroen on this issue. This
> > exact number may no longer be unnecessary, but I don't think it can be
> > successfully defended that in a hundred years somebody will need to have
> > a megabyte reference being passed around just because nobody thought to
> > trim it.
>
> Your argument is backwards - you are giving an argument that the software
> not be required to produce very long References headers. This is not what
> the GNKSA/U is requiring - it says that the software is required not to
> produce very long References headers. What is your argument for this?
I'm giving a argument that they not be ALLOWED to do so at the current
time, there are servers currently being used (probably with tens of
thousands of posters) who users wouldn't be able to participate in
discussions if the reference header grows to longer than 998.
> > > > a) Allows users to change their mind and mail rather than
> > > > post after having initiated a followup message M
> > >
> > > This is broken and unnecessary.
> >
> > Why? If this isn't there then people new to the net are much less
> > likely to think of taking a discussion private.
>
> I don't see why. I have almost never started writing a post and then
> decided to email, and even more rarely has my change of mind happened
> after I actually started writing my response. Even if it's true, then
> it should not be a MUST, but a SHOULD.
That's probably because you aren't new to the 'net and know when to use
the proper response. The GNKSA isn't about letting exprets easily do
what they know is right - but instead requiring software to guide and
encourage and allow tyro's to do the same thing.
> > I consider this a essential feature of equal importance to being able
> > to reply by mail at all.
>
> Now you're just being ridiculous.
No, I'm not. To a new user if it's not there and easy to do it doesn't
exist - take turing off HTML in Netscape for example, how many times
have you seen people post using it and then say they didn't know how to
turn it off. Me, I've lost count.
> > > > (Upgraded from SHOULD to MUST, and 14 is now 16)
> > > > 14a) Warns when attempting to post empty articles M
> > >
> > > This is broken and unnecessary.
> >
> > Ok, now was it broken and unnecessary when 1.2 had it as a SHOULD or is
> > it just the change to a MUST which is unnecessary? If so why?
>
> No, it was excellent when it was a SHOULD. I don't think that empty posts
> cause sufficient problems or are sufficiently common to warrant a MUST on
> this.
Then isn't "broken and unnecessary" a little harsh? You may feel that
it's stricter than necessary, but that hardly makes it "broken and
unnecessary".
As an off the cuff guess as to why it is now stricter (rememeber I did
NOT have a hand in adding or changing any of these requirements) - I'd
guess it's because they thought that by the time that the 2.0 GNKSA was
being written they thought enough time had passed that new newsreader
should be required to do it and enough of the old good ones did.
> > Was this necessary?
>
> Was what necessary?
Never mind, if you don't know then it's not important.
But I would like you to consider: Out of 26 MUST you have a problem with
4. And only 1 do you apparently think it is wrong to do. Does this
really add up to enough that you think the GNKSA should be scrapped
completely? You may think that 3 of them are unnecessary, but the
requirements are hardly "broken", even the requirements that you don't
agree should be required (with the possible expt of 7c) you don't seem
to think are "bad".
--
John Moreno
Kathy I. Morgan
Jon Ribbens <j...@oaktree.co.uk> wrote:
> No, it was excellent when it was a SHOULD. I don't think that empty posts
> cause sufficient problems or are sufficiently common to warrant a MUST on
> this.
I suspect this is partly a reflection of the groups that you use
regularly. On newsgroups frequented by people with little or no computer
or technical experience it is very common to see empty posts, posts with
100% quoted material, and articles posted 5 times. Warning these users
before they post would stop most of these errors.
kathy
Kathy I. Morgan
Jon Ribbens <j...@oaktree.co.uk> wrote:
> Kathy I. Morgan <kmo...@polarnet.com> wrote:
> > ...about features I consider important in a well-behaved reader. Are you
> > a troll?
>
> I'm a troll[er] because I disagree with you? Neat.
Sorry about that--you hadn't ever posted to the groups I hang out in,
and you didn't contribute to the discussions leading up to GNKSA 2. I've
done some research at DejaNews, and I see you were busy elsewhere.
>
> > Where were you during the discussion that culminated in the GNKSA?
>
> Busy, I expect. Where was this discussion?
There was extensive and sometimes heated discussion here in
news.software.readers. I'm sorry you missed it.
kathy
Jeroen Scheerder
Erland Sommarskog <somma...@algonet.se>:
> [..] There are a lot more important stuff that GNKSA could cover. Handling
> of 8-bit characters for instance.
It cannot. There simply is no platform-independent interpretation of
8-bit chars (yet); even if GNKSA required breaking the Usenet Message
Format RFC's, encouraging passing through higly system-specific 8-bit
character encodings would still only solve the "minor" problem inherent
in transporting 8-bits in Usenet -- i.e. older software choking on it.
There is no "right way" of dealing with 8-bit, system-specific,
non-portable, incompatible encodings. Yet. Once a proper way of doing
this exists and is firmly rooted in predominant software, GNKSA will, in
time, follow and encourage that particular proper way. At present,
8-bit characters (especially in headers) simply are not unambiguously
interpretable damage. Sorry, but that's the grey everyday life for you;
a reminder, if you will, to think about the consequences of using stuff
before using it.
> The only issue I find important in this area, is that it should be
> possible to post and mail in the same action. (It should not be
> the default, though.)
"On Unix, just save the text to a file, exit the editor, abort the
action, and initiate the other action(*), re-using the same file."
(*) pipe into "cat ->/tmp/$$;inews -h</tmp/$$;sendmail -t</tmp/$$"
The very same thing can be claimed for almost _any_ header validation,
or basically anything a newsreader should do. If you're OK with this
argument, you've done a way with the entire concept of "news reading
software"; you can just as well read directly from spool, or port 119,
can't you?
-- J$
--
dash dash space
this is my .sig it's not so .big
Lars Magne Ingebrigtsen
phe...@interpath.com (John Moreno) writes:
> Look at message <1d3dqcn.197...@roxboro0-039.dyn.interpath.net>,
> you'll see the list of new MUST requirements. Please tell me which ones
> you think fall into the category of "Neat-o-Kean-o Features". Possibly
> the one about being kind to the server? Not doing HTML or MIME by
> default (although how a lack of a feature could be considered a
> "Neat-o-Kean-o Features" is beyond me)?
Oooh, clever.
Yes, there are sensible things on the list. (How could there not be?
It's based on GNKSA.) There are also lots and lots of spurious
SHOULDs there, that effectively decimate any credibility of the list.
John Moreno
Lars Magne Ingebrigtsen <la...@ifi.uio.no> wrote:
> phe...@interpath.com (John Moreno) writes:
>
> > Look at message <1d3dqcn.197...@roxboro0-039.dyn.interpath.net>,
> > you'll see the list of new MUST requirements. Please tell me which ones
> > you think fall into the category of "Neat-o-Kean-o Features". Possibly
> > the one about being kind to the server? Not doing HTML or MIME by
> > default (although how a lack of a feature could be considered a
> > "Neat-o-Kean-o Features" is beyond me)?
>
> Oooh, clever.
>
> Yes, there are sensible things on the list. (How could there not be?
> It's based on GNKSA.) There are also lots and lots of spurious
> SHOULDs there, that effectively decimate any credibility of the list.
The 7 totally NEW requirements to get the seal are NOT based upon GNKSA
1.2.
Forget about the SHOULDs for a moment - they've always been a wish list
of features. Like I said, look at the list of new MUST and say why you
think they're bad. say that they are "broken and unnecessary". Please
do this, I'm not being sarcastic or anything but I honestly don't see a
problem with any of them. I think they are all required to either work
with existing software or to encourage new users to do the right things.
--
John Moreno
Justin Sheehy
phe...@interpath.com (John Moreno) writes:
> Hrvoje Niksic <hni...@srce.hr> wrote:
> > Has anyone ventured to look at `rn' and see if it would pass the new
> > seal requirements? How many "problems" would there be with it? How
> > many SHOULD's would it violate?
>
> No one has submitted a review - why don't you. Did it pass the 1.2
> GNKSA?
Heh. Hrvoje's question would probably have made more sense to one who
was aware that the initial GNKSA was basically just a codification of
the behavior of rn...
--
Justin Sheehy
In a cloud bones of steel.
Jon Ribbens
-----BEGIN PGP SIGNED MESSAGE-----
John Moreno <phe...@interpath.com> wrote:
> I'm giving a argument that they not be ALLOWED to do so at the current
> time, there are servers currently being used (probably with tens of
> thousands of posters) who users wouldn't be able to participate in
> discussions if the reference header grows to longer than 998.
I have never heard of this before, and I would have expected that I would
have done. What server software is broken, and in what way? (And how often
do references lines go over 1k anyway? cf. the tin bug)
> That's probably because you aren't new to the 'net and know when to use
> the proper response. The GNKSA isn't about letting exprets easily do
> what they know is right - but instead requiring software to guide and
> encourage and allow tyro's to do the same thing.
The GNKSA is about letting newbies easily avoid doing what they don't
know is wrong. If the user starts out intending to post, I think they're
likely to continue wanting to post, and it almost certainly isn't *wrong*
for them to post.
> > > I consider this a essential feature of equal importance to being able
> > > to reply by mail at all.
> >
> > Now you're just being ridiculous.
>
> No, I'm not.
Of course you are. Being able to mail in a particular way is quite
clearly a less vital feature than being able to mail at all.
> To a new user if it's not there and easy to do it doesn't exist
But that's not what the requirement says. It's talking about switching
from posting to mailing. You're now talking about being able to mail at all.
I would agree that the agent MUST provide an obvious and simple way to send an
email response to a posting.
> > No, it was excellent when it was a SHOULD. I don't think that empty posts
> > cause sufficient problems or are sufficiently common to warrant a MUST on
> > this.
>
> Then isn't "broken and unnecessary" a little harsh? You may feel that
> it's stricter than necessary, but that hardly makes it "broken and
> unnecessary".
The *change* is broken and unnecessary. We're talking about the changes,
remember?
> But I would like you to consider: Out of 26 MUST you have a problem with
> 4. And only 1 do you apparently think it is wrong to do. Does this
> really add up to enough that you think the GNKSA should be scrapped
> completely?
Where did I say that I thought it should be scrapped completely?
Personally I think you should just go back to the old version.
> You may think that 3 of them are unnecessary, but the
> requirements are hardly "broken", even the requirements that you don't
> agree should be required (with the possible expt of 7c) you don't seem
> to think are "bad".
They're fine as SHOULDs. Well, not disastrous, anyway. They're bad as MUSTs.
Cheers
Jon
--
____
\ // Jon Ribbens // 100MB virtual-hosted // www.oaktree.co.uk
\// j...@oaktree.co.uk // web space for 99UKP //
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv
iQCVAwUBNNb7f4MzEl4yn7LtAQH9GwP+IcGp8n4Z/8XsAaYewRksX8dUcrhZwTGL
NNxkD4MkY90Z8sEdf2ZY5w+5pAV1zerVZOIMOAcUKBXqLFvc33UAPCpBHBlzM54L
d6wkXpSGRZwmem+9OKOXdnKzmlX/2oL8FJxd4NQmEXRdVove32/9RWa9QXkRSreM
xfHcDzD07Bo=
=EkIA
-----END PGP SIGNATURE-----
Russ Allbery
>> I'm giving a argument that they not be ALLOWED to do so at the current
>> time, there are servers currently being used (probably with tens of
>> thousands of posters) who users wouldn't be able to participate in
>> discussions if the reference header grows to longer than 998.
> I have never heard of this before, and I would have expected that I
> would have done. What server software is broken, and in what way? (And
> how often do references lines go over 1k anyway? cf. the tin bug)
If the References header goes over 1k and isn't folded (in other words,
it's all on one line), the default configuration of INN will reject the
article. In my experience, that rarely happens, but solely because there
are lots and lots of broken news clients out there that truncate the
References header in various arbitrary and annoying ways, or which fold it
so that people following up afterwards get the benefit of the folding.
If every news posting client were compliant, I think this would be a
bigger problem than it is.
--
Russ Allbery (r...@stanford.edu) <URL:http://www.eyrie.org/~eagle/>
Jeroen Scheerder
Russ Allbery <r...@stanford.edu>:
> If the References header goes over 1k and isn't folded (in other words,
> it's all on one line), the default configuration of INN will reject the
> article. In my experience, that rarely happens, [...]
It happens rather frequently, alas. A commonly used program that
doesn't do _any_ form of decent References folding, nor restriction, is
the Agent family; another is the NN newsreader.
Lots of users get hit by this. NN users tend to remove the References
header for that reason, not appreciating its necessity; others either
get one of the hacks that can be found floating around to fuck
References up *really* awfully, or can't post at all -- which is the
lesser of the two evils, of course.
> [..] but solely because there
> are lots and lots of broken news clients out there that truncate the
> References header in various arbitrary and annoying ways, or which fold it
> so that people following up afterwards get the benefit of the folding.
Newsreaders don't benefit from existing folding, usually. They need to
construct a References header; simply copying an existing one, and
appending a Message-ID will quite often work, but that's not nearly good
enough. And quite a few, if not most, newsreaders just simply don't
operate that way at all.
There is, as of yet, no clear picture of the extent to which existing
software still suffers the overview-bug concerning continued References;
it's terribly hard to get sufficient information that can be regarded as
reasonably representative.
Be that as it may, I'm inclined to let "good intentions" really count
for something, and reward them as such. Continued References quite
possibly will wreak havoc, but properly folded ones *do* indicate that a
newsreader author went the extra mile to do it properly -- the way it
_should_ have worked. There's no final decision yet, and I would be
grateful for insights shared here; there are also some bureaucratic
details to take care of before I can change GNKSA2 to require either
folding or sound and proper restriction to 998 octets w/o EOL
representation. Not to mention a few other changes induced by such a
change.
John Moreno
Justin Sheehy <jus...@linus.mitre.org> wrote:
Actually, I was. But what I don't know is if there were any additions
to the GNKSA for things that rn doesn't or didn't do but that it should
have.
--
John Moreno
Jeroen Scheerder
John Moreno <phe...@interpath.com>:
> But what I don't know is if there were any additions to the GNKSA for
> things that rn doesn't or didn't do but that it should have.
There are. Usenet, or more accurately, Usenet abuse, has changed in
ways unforeseeable at the time of writing rn.
John Moreno
Jeroen Scheerder <j...@xs4all.nl> wrote:
> John Moreno <phe...@interpath.com>:
>
> > But what I don't know is if there were any additions to the GNKSA for
> > things that rn doesn't or didn't do but that it should have.
>
> There are. Usenet, or more accurately, Usenet abuse, has changed in
> ways unforeseeable at the time of writing rn.
I know there are things that are being done now that were unforeseeable
at the time of writing rn - but were there things when when GNKSA 1.2
was being done that rn hadn't considered? I'm not sure but I would
think so - specifically the bit about the References header. I don't
know for sure, but it wouldn't surprise me in the least to learn that rn
didn't handle that correctly and only slightly to learn that it still
doesn't.
--
John Moreno
Jeroen Scheerder
John Moreno <phe...@interpath.com>:
> [...] were there things when GNKSA 1.2 was being done that rn hadn't
> considered?
Yes, I believe so. Note that rn predates GNKSA 1.2 by far.
> [..] it wouldn't surprise me in the least to learn that rn didn't handle
> that [References] correctly and only slightly to learn that it still
> doesn't.
AFAIK rn isn't very intensively maintained. Its descendants seem to be,
though; but a `rn' GNKSA review would be nice, yes.
Russell Schulz
j...@xs4all.nl (Jeroen Scheerder) writes:
> Be that as it may, I'm inclined to let "good intentions" really count
> for something, and reward them as such. Continued References quite
> possibly will wreak havoc, but properly folded ones *do* indicate that
> a newsreader author went the extra mile to do it properly
my newsreader used to fold, but I had to take it out -- the software
with which its use was originally intended (waffle) STRIPS the
continuation lines in news, and all my posts were going out with
only one reference (and not the immediately-preceding one).
--
Russell...@locutus.ofB.ORG Shad 86c
John Moreno
Russell Schulz <Russell...@locutus.ofB.ORG> wrote:
You did a 1.2 GNKSA review of rnr 2.14, how about a GNKSA 2.0 review for
the current version?
--
John Moreno
Russell Schulz
phe...@interpath.com (John Moreno) writes:
> You did a 1.2 GNKSA review of rnr 2.14, how about a GNKSA 2.0
> review for the current version?
I kept waiting for it to be posted without the right-justification
(since we all know only newbies post things with right-justification,
and it dealt with obscure NNTP-specific things, I had no concern of
it affecting GNKS or my software).
imagine my surprise when it _became_ the GNKS.
now I read that it requires any post may be turned into mail, and
any reply may be turned into a followup. the structure in my code
can't handle that at present (and it's not for an environment where
I can assume I have an infinite amount of stack and just have them
keep calling each other). I do wonder how common a thing it is
to add in at all. (and I wonder how strict the checking on the
headers is when it's used on the readers which do allow it. and
do they give a warning if the Followup-To: header of the original
post included a .test group? or all those other things it should?)
my reader is not a graphical one, where a usually-empty list of
newsgroups is sitting there, waiting to be added to with the mouse.
actually: are there ANY non-graphical newsreaders which have
this particular feature?
--
Russell...@locutus.ofB.ORG Shad 86c
ace
Russell Schulz <Russell...@locutus.ofB.ORG> wrote:
[ turning post into mail, and vice versa ]
> are there ANY non-graphical newsreaders which have
> this particular feature?
Pine does. Not that I would recommend my version 3.96 to anyone (see
a.o. http://www.xs4all.nl/~js/gnksa/Evaluations/pine-3.93.txt), but it
will allow you to swap between posting and mailing a message, simply by
putting in or editing out the relevant headers.
ace
--
=^^=
( )~ __________________________________________ (c) ace <a...@xs4all.nl>
Karl Kleinpaste
Russell Schulz <Russell...@locutus.ofB.ORG> writes:
> now I read that it requires any post may be turned into mail, and
> any reply may be turned into a followup.
> actually: are there ANY non-graphical newsreaders which have
> this particular feature?
Depending on your definition of "non-graphical," Gnus does. When
beginning either a followup or reply, one may hit `C-c C-n' to insert
a "Newsgroups:" header, or `C-c C-t' to insert a "To:" header, either
one filled in appropriately.
It's a cute feature, but I don't think it's really, er, critical, or
even an especially good idea. It's there primarily for the sake of
simultaneous post/mail capability, it seems, which is occasionally
useful but widely disparaged.
Stefan Haller
Russell Schulz <Russell...@locutus.ofB.ORG> wrote:
> I kept waiting for it to be posted without the right-justification
> (since we all know only newbies post things with right-justification,
Don't be silly. Most RFCs are right-justified too.
--
Stefan Haller
Berlin, Germany
http://www.snafu.de/~stk/
John Moreno
Russell Schulz <Russell...@locutus.ofB.ORG> wrote:
> phe...@interpath.com (John Moreno) writes:
>
> > You did a 1.2 GNKSA review of rnr 2.14, how about a GNKSA 2.0
> > review for the current version?
>
> I kept waiting for it to be posted without the right-justification
> (since we all know only newbies post things with right-justification,
Huh? If possible I'd do the review using the web-form, if not the form
isn't right justified - it is a worts fully justified.
> and it dealt with obscure NNTP-specific things, I had no concern of
> it affecting GNKS or my software).
Obscure NNTP-specific things?
> imagine my surprise when it _became_ the GNKS.
>
> now I read that it requires any post may be turned into mail, and
> any reply may be turned into a followup. the structure in my code
> can't handle that at present (and it's not for an environment where
> I can assume I have an infinite amount of stack and just have them
> keep calling each other).
Am I misreading this? You have two different code segments to handle
entering the body of news or mail messages? Whatever for?
I probably don't understand enough about how your code/program functions
to comment. But if you already can send both mail and news messages
this shouldn't be hard to add at all.
> I do wonder how common a thing it is to add in at all. (and I wonder how
> strict the checking on the headers is when it's used on the readers which
> do allow it. and do they give a warning if the Followup-To: header of the
> original post included a .test group? or all those other things it
> should?)
Warnings when doing so would be up to the individual programs - header
checking would have to be enough to see that they are syntactically
valid.
> my reader is not a graphical one, where a usually-empty list of
> newsgroups is sitting there, waiting to be added to with the mouse.
Then draw the initial values from the previous message and let them edit
it using the keyboard.
> actually: are there ANY non-graphical newsreaders which have
> this particular feature?
Yes.
--
John Moreno
Brian Clark
As a data point in the references discussion and the behavior of INN with
long reference lines:
I'm using a GNKSA 2.0 compliant newsreader. It truncates the (not folded)
references header using the method specified by GNKSA, and limits the total
length to 998 characters. But that count of 998 is just for the references
themselves, and does not include the length of the "References: " header
name itself. Today, when trying to reply to a different thread with a long
list of references, I got a "line too long" error from the news server,
which was running INN 1.7.2. Modifying the newsreader so that the length of
the complete References header, and not just the references, was no more
than 998 characters eliminated the error message and permitted my response
to be posted.
So, though perhaps this should have been obvious, the GNKSA spec should be
clearer that it's the total header length that should be kept to 998
characters or less. And there clearly are news servers out there today that
will reject posts with lines longer than this.
Erland Sommarskog
j...@xs4all.nl (Jeroen Scheerder) skriver:
>It cannot. There simply is no platform-independent interpretation of
>8-bit chars (yet); even if GNKSA required breaking the Usenet Message
>Format RFC's, encouraging passing through higly system-specific 8-bit
>character encodings would still only solve the "minor" problem inherent
>in transporting 8-bits in Usenet -- i.e. older software choking on it.
>
>There is no "right way" of dealing with 8-bit, system-specific,
>non-portable, incompatible encodings. Yet. Once a proper way of doing
>this exists and is firmly rooted in predominant software, GNKSA will, in
>time, follow and encourage that particular proper way. At present,
>8-bit characters (especially in headers) simply are not unambiguously
>interpretable damage. Sorry, but that's the grey everyday life for you;
>a reminder, if you will, to think about the consequences of using stuff
>before using it.
This is joke, right? Next you will tell me that the bumble bee can't
fly?
Look, we're using 8-bit chars in the Swedish newsgroups, and we know
works and what does not. Post a message in pure Latin-1 and few will
argue with you. Post in Quoted Printable or use RFC2047 headers and
your peers will yell at you.
Erland Sommarskog
phe...@interpath.com (John Moreno) skriver:
>This is to encourage the usage of email for off topic responses - if the
>user (probably someone new to computers as well as the net) changes his
>mind it is imperative that this be simple and easy. Just as it is
>necessary for it to be clear so that he knows this is possible at all.
Still doesn't make sense to make mandatory for a news reader. With
that sort of argument, you should not stop there, but mandate posting
wizards too.
>> The only issue I find important in this area, is that it should be
>> possible to post and mail in the same action. (It should not be
>> the default, though.)
>
>Just out of curiosity, why the same action? Why not a easily done
>second step - frex NewsWatcher allows you to do this by simply clicking
>on the icon for mail or news (which one will depend upon whether you
>started out for news or mail)? It is not a GNKSA requirement that it be
>able to do both, although there are requirements if it does do both.
With News Xpress you can click a Cc:-button if you wish send to a
copy. In the options, you can specify that this function is on by
default. You can also include Cc: in your article-header template
(alas, NX does not permit free editing of the article header), so
you can Cc other people that the author of the article you are
replying to.
That is, I don't need to copy the text to the clipboard, send the article,
then select "Reply to" and then send a mail.
John Moreno
Erland Sommarskog <som...@algonet.se> wrote:
> phe...@interpath.com (John Moreno) skriver:
> >This is to encourage the usage of email for off topic responses - if the
> >user (probably someone new to computers as well as the net) changes his
> >mind it is imperative that this be simple and easy. Just as it is
> >necessary for it to be clear so that he knows this is possible at all.
>
> Still doesn't make sense to make mandatory for a news reader. With
> that sort of argument, you should not stop there, but mandate posting
> wizards too.
Posting wizards? Their is a big difference between allowing a user to
change her mind and hand walking her through the process (which is what
I assume that "posting wizards" means).
> >> The only issue I find important in this area, is that it should be
> >> possible to post and mail in the same action. (It should not be
> >> the default, though.)
> >
> >Just out of curiosity, why the same action? Why not a easily done
> >second step - frex NewsWatcher allows you to do this by simply clicking
> >on the icon for mail or news (which one will depend upon whether you
> >started out for news or mail)? It is not a GNKSA requirement that it be
> >able to do both, although there are requirements if it does do both.
>
> With News Xpress you can click a Cc:-button if you wish send to a
> copy. In the options, you can specify that this function is on by
> default. You can also include Cc: in your article-header template
> (alas, NX does not permit free editing of the article header), so
> you can Cc other people that the author of the article you are
> replying to.
>
> That is, I don't need to copy the text to the clipboard, send the article,
> then select "Reply to" and then send a mail.
That last is good, but the bit about being able to do it by default
isn't.
--
John Moreno
John Moreno
Jeroen Scheerder <j...@xs4all.nl> wrote:
> Brian Clark <bac...@nwu.edu>:
>
> > So, though perhaps this should have been obvious, the GNKSA spec should be
> > clearer that it's the total header length that should be kept to 998
> > characters or less.
>
> Apparently it should be clearer; I _meant_ it to indicate a maximum line
> length of 1000 octets including EOL representation, which of course
> includes the field name. I'll check to see if I can clarify things;
> thanks for informing me about the possible misinterpretation.
If this was either MacSOUP or NewsWatcher then it was a testing error -
that was my understanding and that was what I was (supposed to be)
checking for.
--
John Moreno
Jeroen Scheerder
Stefan Haller <s...@berlin.snafu.de>:
> Most RFCs are right-justified too.
I initially formatted GNKSA/2 right-justified because of exactly that;
and I changed it, months ago, after someone requested it -- not really
caring one way or the other.
Jeroen Scheerder
Brian Clark <bac...@nwu.edu>:
> So, though perhaps this should have been obvious, the GNKSA spec should be
> clearer that it's the total header length that should be kept to 998
> characters or less.
Apparently it should be clearer; I _meant_ it to indicate a maximum line
length of 1000 octets including EOL representation, which of course
includes the field name. I'll check to see if I can clarify things;
thanks for informing me about the possible misinterpretation.
Stefan Haller
John Moreno <phe...@interpath.com> wrote:
> If this was either MacSOUP or NewsWatcher
It was Brian's own YA-NewsWatcher, as you can see by looking at his
"User-Agent" header. (The next version of MacSOUP will show the
User-Agent header by default.)
MacSOUP does keep the entire References header (including keyword) under
998 characters.
Lars Magne Ingebrigtsen
phe...@interpath.com (John Moreno) writes:
> Forget about the SHOULDs for a moment - they've always been a wish list
> of features.
Sorry; it doesn't work that way. For someone who's used to reading
RFC's, a «SHOULD» means that, yes, one SHOULD do what they say.
Heaping lots of hare-brained wishes onto a list of «minimal
requirements» is not something that's going to make that list more
credible.
> Like I said, look at the list of new MUST and say why you think
> they're bad. say that they are "broken and unnecessary". Please do
> this, I'm not being sarcastic or anything but I honestly don't see a
> problem with any of them.
That must mean that you haven't been paying attention much, doesn't it?
Lars Magne Ingebrigtsen
Karl Kleinpaste <ka...@jprc.com> writes:
> > actually: are there ANY non-graphical newsreaders which have
> > this particular feature?
[...]
> It's a cute feature, but I don't think it's really, er, critical, or
> even an especially good idea. It's there primarily for the sake of
> simultaneous post/mail capability, it seems, which is occasionally
> useful but widely disparaged.
Yup. It's more a «why not?» feature than a «why?» feature. Requiring
newsreaders to provide this very, very marginal feature is beyond
silly.
Brian Clark
In article <1d43qp9.qlr...@roxboro0-059.dyn.interpath.net>,
phe...@interpath.com (John Moreno) wrote:
> If this was either MacSOUP or NewsWatcher then it was a testing error -
> that was my understanding and that was what I was (supposed to be)
> checking for.
It was the NewsWatcher code. I cc'd John Norstad in my original post so he
knows of the problem. It's a trivial fix, and I'm sure it will be in the
2.2.1 version that is due out soon anyway.
Curt Welch
Brian Clark <bac...@nwu.edu> wrote:
> As a data point in the references discussion and the behavior of INN with
> long reference lines:
> I'm using a GNKSA 2.0 compliant newsreader. It truncates the (not folded)
> references header using the method specified by GNKSA, and limits the
> total length to 998 characters. But that count of 998 is just for the
> references themselves, and does not include the length of the
> "References: " header name itself. Today, when trying to reply to a
> different thread with a long list of references, I got a "line too long"
> error from the news server, which was running INN 1.7.2. Modifying the
> newsreader so that the length of the complete References header, and not
> just the references, was no more than 998 characters eliminated the error
> message and permitted my response to be posted.
> So, though perhaps this should have been obvious, the GNKSA spec should
> be clearer that it's the total header length that should be kept to 998
> characters or less.
In my testing for my code on NewsReader.Com I found that inn 1.5.1
limited the line to 997 characters, not 998. That is, a References line
with 998 characters plus a CR LF would cause the "line too long" error. A
line with 997 characters plus a CR LF worked. I haven't looked at the inn
code to figure out what was causing it and I haven't tried testing on any
other version of inn.
The 988 value is the "correct" value to match the wording/intent of the
RFC, but to work correctly, you better use 997 if you are writing code to
limit the length of References: headers.
There is of course a chance that my testing was somehow flawed. I'd
appreceate it if some else was to do some testing of their news servers
with reference lines of exactly 998 characters.
--
Curt Welch http://CurtWelch.Com/
cu...@kcwc.com Webmaster for http://NewsReader.Com/
John Moreno
Lars Magne Ingebrigtsen <la...@ifi.uio.no> wrote:
> phe...@interpath.com (John Moreno) writes:
>
> > Forget about the SHOULDs for a moment - they've always been a wish list
> > of features.
>
> Sorry; it doesn't work that way. For someone who's used to reading
> RFC's, a «SHOULD» means that, yes, one SHOULD do what they say.
> Heaping lots of hare-brained wishes onto a list of «minimal
> requirements» is not something that's going to make that list more
> credible.
They mean that yes you should indeed do something unless you have a
credible reason not to. And yes, I believe that most of them should be
done unless you have a good reason not to (the one I disagree with most
was in 1.2). But as they aren't requirements, they should be left until
after the requirements have been settled.
> > Like I said, look at the list of new MUST and say why you think
> > they're bad. say that they are "broken and unnecessary". Please do
> > this, I'm not being sarcastic or anything but I honestly don't see a
> > problem with any of them.
>
> That must mean that you haven't been paying attention much, doesn't it?
Yes, I have, and frankly no one has gone beyond "I don't think it's
necessary".
There are 7 new requirement - I'd like to see a 3 or 4 sentence reason
as to why the feature shouldn't be considered essential and required.
Here they are.
New requirements
7c) Ensures References will fit in 998 characters M
[1.2 Uses 9 for something else]
9) Allow the user to change her mind about whether to post or mail (or
do both) and behave if doing both
a) Allows users to change their mind and mail rather than
post after having initiated a followup message M
b) Allows users to change their mind and post rather than
mail after having initiated a reply message M
c) Does not offer both posting and mailing as default behaviour M
[New number and added for 2.0]
17) Post human-readable articles unless ordered otherwise
a) Does not (and can not) encode or encrypt articles unless
on explicit user demand M
[New number and added for 2.0]
19) Be kind to servers, leave room for others
a) Does not unnecessarily open multiple connections M
b) Does not generate excessive server load otherwise M
I'd also like a final 3 0r 4 sentences explaining why these requirements
are so far outside the realm of "minimal" that talk about starting all
over again shouldn't be considered going a little overboard.
This would give us something to discuss, as it is you are just making
flat statements and leaving it at that.
--
John Moreno
Hrvoje Niksic
phe...@interpath.com (John Moreno) writes:
[...]
> There are 7 new requirement (...)
You keep saying that, missing the point. Which is that all the
needless SHOULD's lower the credibility of the new GNKSA, as is the
case with MUST's. Yes, most of the features are good ones, but they
have no place in this document.
Saying these are "flat statements" does not make their truthfulness
diminish.
--
Hrvoje Niksic <hni...@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Idle RAM is the Devil's playground.
John Moreno
Hrvoje Niksic <hni...@srce.hr> wrote:
> phe...@interpath.com (John Moreno) writes:
> [...]
> > There are 7 new requirement (...)
>
> You keep saying that, missing the point. Which is that all the
> needless SHOULD's lower the credibility of the new GNKSA, as is the
> case with MUST's. Yes, most of the features are good ones, but they
> have no place in this document.
>
> Saying these are "flat statements" does not make their truthfulness
> diminish.
If you don't go beyond flat statements, you sound like a little kid - Am
not! Are too! Am not! Are too! Am not infinity! Are not infinity plus 1!
As for the needless SHOULDs lowering the credibility - that should be
addressed after the 7 new requirements are either accepted, filtered, or
rejected entirely. Since you can (and always have been able to) get the
GNKSA while failing every single one of the SHOULDs, while they might
diminish the credibility they don't change the results.
--
John Moreno
Lars Magne Ingebrigtsen
phe...@interpath.com (John Moreno) writes:
> Since you can (and always have been able to) get the GNKSA while
> failing every single one of the SHOULDs, while they might diminish
> the credibility they don't change the results.
If something is devoid of credibility, who cares what the results are?
I certainly don't. (Any more.)
Karl Kleinpaste
phe...@interpath.com (John Moreno) writes:
> ...while they might diminish the credibility...
Credibility is all you've got, John. If you've diminished *that* (and
indeed you have), nothing else remains.
Russell Schulz
s...@berlin.snafu.de (Stefan Haller) writes:
>> I kept waiting for it to be posted without the right-justification
>> (since we all know only newbies post things with right-justification,
>
> Don't be silly.
I'm not. any non-newbie realizes that makes it harder to read.
> Most RFCs are right-justified too.
most? I know I've seen a few old ones, but I don't recall many.
--
Russell...@locutus.ofB.ORG Shad 86c
Russell Schulz
phe...@interpath.com (John Moreno) writes:
> Am I misreading this?
most of it you did, but not this bit.
> You have two different code segments to handle
> entering the body of news or mail messages? Whatever for?
they check different things about different headers. many of the
warnings are only presented once (at the time the user presses `f'
or `r'), so as to not annoy the user. there are a few lines of code
which check headers after every header edit, and some of these lines
are duplicated.
to turn a posting into mail isn't a big deal (the user can add a
`CC: poster' line at any time). to turn mail into a posting is
not so easy in the code, partly because 1036 is more strict than 822.
--
Russell...@locutus.ofB.ORG Shad 86c
John Moreno
Lars Magne Ingebrigtsen <la...@ifi.uio.no> wrote:
> phe...@interpath.com (John Moreno) writes:
>
> > Since you can (and always have been able to) get the GNKSA while
> > failing every single one of the SHOULDs, while they might diminish
> > the credibility they don't change the results.
>
> If something is devoid of credibility, who cares what the results are?
> I certainly don't. (Any more.)
If you don't address the issues more specifically than "it's bad" or "it
lowers credibility" then YOUR credibility is lowered. Take specific
issue with specific items. Start with the MUST, after they have been
discussed move on to the SHOULDs.
I've asked you 4 or 5 times now, look at the list of 7 new MUST and say
what SPECIFICALLY is bad about including each one as a MUST.
You can't persade me or others (and I at least am certainly willing to
be convinced) that it's bad without giving specific objections - and I
can't try to convince you that it's good if I don't know what you object
to. If it's just the number of items then how many do you feel should
be in it - 1, 2, 10?
Be specific, this isn't a advacacy group where you say - it's from MS
and sucks.
On a different note: Does anybody know if there is a archive of the
gnksa mailing list where these issues were discussed.
--
John Moreno
John Moreno
Russell Schulz <Russell...@locutus.ofB.ORG> wrote:
> phe...@interpath.com (John Moreno) writes:
>
> > Am I misreading this?
>
> most of it you did, but not this bit.
>
> > You have two different code segments to handle
> > entering the body of news or mail messages? Whatever for?
>
> they check different things about different headers. many of the
> warnings are only presented once (at the time the user presses `f'
> or `r'), so as to not annoy the user. there are a few lines of code
> which check headers after every header edit, and some of these lines
> are duplicated.
>
> to turn a posting into mail isn't a big deal (the user can add a
> `CC: poster' line at any time). to turn mail into a posting is
> not so easy in the code, partly because 1036 is more strict than 822.
Do the checking just before sending - or if you allow it be saved and
editted latter, then just before you quit editting.
--
John Moreno
John Moreno
Karl Kleinpaste <ka...@jprc.com> wrote:
> phe...@interpath.com (John Moreno) writes:
> > ...while they might diminish the credibility...
>
> Credibility is all you've got, John. If you've diminished *that* (and
> indeed you have), nothing else remains.
And the MUSTs (since they are the actual requirements to pass) are much
more important to that credibility, address them first and then the
SHOULDs. The SHOULDs only have importance /after/ all of the MUSTs have
been satisified.
--
John Moreno
Greg Berigan
Apologies to those seeing this twice. Apparently unlnews.unl.edu isn't
propogating articles posted to it to even its sibling news server,
crcnews.unl.edu. If you've seen this post before, please let me know.
Searches on DejaNews and other servers turned up nothing. (I was
wondering why my postings on this subject in this newsgroup weren't
getting responses.)
phe...@interpath.com (John Moreno) wrote:
> New requirements
> 7c) Ensures References will fit in 998 characters M
Oh yeah, break newsreader software to cater to broken servers. INN
1.7.2 is in error requiring this header to be under 998 characters. You
yourself said elsewhere software should accept everything given it. Fix
the problem where it lies: with the servers.
Meanwhile, I suggest some new thought behind this.
Newsreaders must not always trim References. If there is a problem and
the server rejects the article for excessive References (and notifies
the newsreader in a way that this reason is detectable), the newsreader
must note this and then and ONLY then trim the References, and only if
it knows the server is operating under this brokeness. It must not be
trimmed unnecessarily. The header should be folded to multiple lines if
it even exceeds 80 characters and especially if servers will accept it
folded.
In general, the newsreader must report any error message the server
gives it. Some newsreaders only say that the posting failed without any
reason why. If the reason is given, the user can take action such as
trimming references, quoted material, making sure Newsgroups and
Followup-To don't list only newsgroups that aren't carried, etc.
In this way, the user gets his articles out, and can know whether it is
his fault or just a stupid restriction put on the server.
> [1.2 Uses 9 for something else]
> 9) Allow the user to change her mind about whether to post or mail (or
> do both) and behave if doing both
> a) Allows users to change their mind and mail rather than
> post after having initiated a followup message M
> b) Allows users to change their mind and post rather than
> mail after having initiated a reply message M
This is an unreasonable burden to put on authors of pre-existing
text-based software. You're viewing this at a GUI perspective where
options to change posting or mailing method are present at all times
during message composition.
I put it to you that the mail to news mind-change is covered by the
existence of mail-to-news gateways, so in a sense all newsreaders pass
on that point. They "allow" it. They just don't _provide_ for it
themselves in a clear manner. (I expect you're going to revise this now
to require they provide this.)
Also, how about the ability of editors to pipe their contents into an
external command? Would this satisfy the requirements both ways?
> c) Does not offer both posting and mailing as default behaviour M
Of this set, this is the only one that makes sense, except I think some
posters might object that it would disallow their use of the
Mail-Copies-To header which requests that posting and mailing be done.
This requirement in the GNKSA would supersede their expressed desires.
(Not that I even agree with the Mail-Copies-To header in the first
place.)
> [New number and added for 2.0]
> 17) Post human-readable articles unless ordered otherwise
> a) Does not (and can not) encode or encrypt articles unless
> on explicit user demand M
So a user must be allowed to post a GIF in the message body without any
text encoding, even when the software knows he doesn't want to do that?
At the least, it should read "encode text articles or encrypt articles"
to allow for automatic encoding of binary content that the user forgets
is a requirement to transmit the article. Think of the bandwidth waste
of sending those binary files in formats no one can use.
The "Post human-readable articles" is not sufficient as it isn't in the
direct wording of the 17a requirement which is the MUST.
> [New number and added for 2.0]
> 19) Be kind to servers, leave room for others
> a) Does not unnecessarily open multiple connections M
Does Multi-Threaded Newswatcher fail on this account? Is its behavior
in allowing the user to read other messages while pulling down a large
binary an instance of opening multiple unnecessary connections, or are
you specifically referring to the behavior of browsers with news
servers? I agree the browsers' behaviors are abusive, but I don't think
MT-Newswatcher's behavior should be lumped into the same category as it
is now.
(Note: this browser behavior is not exclusive to news servers. They
also will start downloading binary content, then abort and immediate
restart downloading the exact same content, both by HTTP and FTP,
because they assume they can display it in the browser window and, to
switch to download mode, have to restart the transfer. They don't think
of checking filename extensions first, something they should be doing
for FTP. They cannot apparently hand over an open stream to the
download routines; those routines have to open the stream themselves. I
wouldn't be surprised if they double-hit MIME-encoded news articles
too. Anyone got any data on this?)
> b) Does not generate excessive server load otherwise M
"Excessive" is a highly subjective term. I would like to see this
spelled out in a bit more detail.
> I'd also like a final 3 0r 4 sentences explaining why these requirements
> are so far outside the realm of "minimal" that talk about starting all
> over again shouldn't be considered going a little overboard.
I think I've been pretty clear about my objections to these, mod the
ones I'd like a bit more explanation on. I don't entirely disagree with
them all, but I do believe they deserve closer scrutiny.
> This would give us something to discuss, as it is you are just making
> flat statements and leaving it at that.
I think I've left plenty open for discussion, and looking forward to it.
Perhaps we can get a better GNKSA 2.1 out of this.
--
_-<#)-=# http://incolor.inetnebr.com/wotw/ (War of the Worlds)
___/___
_-~_--<###) Due to widespread abuse, I no longer read any messages
<~c>' __--< from users who employ munged addresses in their headers.
\_--=____#) Richard Hart and Justin Gunn at C|NET, this means you too.
Jeroen Scheerder
John Moreno <phe...@interpath.com>:
> Does anybody know if there is a archive of the
> gnksa mailing list where these issues were discussed.
Yes; and I'm sad to say, it doesn't exist. No volunteer could be found
to do it, and I had (and have) neither the time nor access to the
necessary resources.
Lars Magne Ingebrigtsen
phe...@interpath.com (John Moreno) writes:
> If you don't address the issues more specifically than "it's bad" or "it
> lowers credibility" then YOUR credibility is lowered. Take specific
> issue with specific items. Start with the MUST, after they have been
> discussed move on to the SHOULDs.
Your wish is my command.
Not.
John Moreno
Lars Magne Ingebrigtsen <la...@ifi.uio.no> wrote:
> phe...@interpath.com (John Moreno) writes:
>
> > If you don't address the issues more specifically than "it's bad" or "it
> > lowers credibility" then YOUR credibility is lowered. Take specific
> > issue with specific items. Start with the MUST, after they have been
> > discussed move on to the SHOULDs.
>
> Your wish is my command.
>
> Not.
So, you don't want to discuss the issues? Fine, but then your
objections don't have much weight.
--
John Moreno
Lars Magne Ingebrigtsen
phe...@interpath.com (John Moreno) writes:
> So, you don't want to discuss the issues?
Where have I said that?
> Fine, but then your objections don't have much weight.
El snorto.
John Moreno
Lars Magne Ingebrigtsen <la...@ifi.uio.no> wrote:
> phe...@interpath.com (John Moreno) writes:
>
> > So, you don't want to discuss the issues?
>
> Where have I said that?
Where you said that you didn't want to give specific objections.
> > Fine, but then your objections don't have much weight.
>
> El snorto.
Look, if you'd actually discuss the matter your opinions would probably
have great weight (certainly more than mine), but if you decline to say
what's wrong, then only people who already agree with you are going to
be influenced.
This is a technically minded group and a vauge - "there's too much to
it" or "the standard is broken" isn't very persuasive.
--
John Moreno
Karl Kleinpaste
phe...@interpath.com (John Moreno) writes:
> And the MUSTs (since they are the actual requirements to pass) are much
> more important to that credibility, address them first and then the
> SHOULDs. The SHOULDs only have importance /after/ all of the MUSTs have
> been satisified.
Fine, John, here's my take on your MUSTs.
I went back a half dozen articles in this thread and found your 7 new
MUSTs. The short version is: Half of them are ridiculous or pointless.
I especially regard the new MUST qualifier on the "post/mail change-
of-mind" issue to be utterly nonsensical. There have been ways of
changing one's mind in midstream since the dawn of Usenet, and your
new demand that all newsreaders provide it as an intrinsic function is
wrong. My newsreader, Gnus, even provides it, but it's *fluff* and
nearly unused. The fact that most newsreaders require one to do some
sort of save/abort/restart in order to change one's mind is a feature,
in my opinion, because the manner of address to both the preceding
author and the subject matter is liable to differ based on whether one
is addressing an individual or a larger audience. E.g., one's choice
of quotation (both style and extent) may change; one may discuss
information known only between the two parties when going to mail,
which then becomes incorrect if one changes one's mind to post. Other
examples abound.
I also take issue with the "be kind to servers" list because it is
open to interpretation whether newsreaders employing a 2nd (not an
arbitrary Nth for large N) connection for article read-ahead is
"unnecessary" or not. At a minimum, the phrasing is poor; and if
someone now intends to tell me that either a double connection or
article read-ahead is wrong, I'm going to tell you where to stuff your
new non-standard. Also, the interpretation of "do not generate
excessive server load" is so ambiguous and open to interpretation as
to be meaningless.
You wanted "3 or 4 sentences" on the MUSTs, so now you've got them.
Now, aside from the new MUSTs, there is the whole issue of the
SHOULDs. SHOULDs should not be used much -- it leaves too much open
to debate. If a newsreader is capable of achieving "PASS" based on
the MUSTs and yet fail to provide even one of the SHOULDs, one wonders
what value the supposed standard has provided, since it's clear that
all those SHOULDs really don't mean squat. That is the problem I
perceive, and that is why the cute-feature-laden view of lots of
SHOULDs irritates me so.
Both of these situations (bogus MUSTs & SHOULDs which have no meaning)
diminish the credibility of the supposed standard, to the point where
it will be ignored. Now, I don't know what jwz will be doing with the
Netscape news interface, but it's pretty clear that Lars couldn't care
less whether Gnus accommodates GNKS any more, and you have only
yourself to blame for that condition having arisen. I wonder how many
other newsreader authors have considered this new GNKS in detail, and
are now considering whether, or have already decided, to toss out the
window the entire goal of GNKS compliance.
GNKS was once an admirable goal, albeit a hideous thing to which to
have resorted when it first came out 3+ years ago -- the very
incarnation of "necessary evil" which managed to transmutate into a
positive thing when a lot of newsreader authors rallied around it so
well. It is no longer a goal at all any more, because of its
preoccupation with fluff.
Lars Magne Ingebrigtsen
phe...@interpath.com (John Moreno) writes:
> Where you said that you didn't want to give specific objections.
I'm sure you can provide the quote where I said that. Right?
Here's a recap of the events: I said that using a list of neato-keano
features (with a smattering of Hard Requirements) as a specification
of minimally compliant behavior is, uh, not a good idea. You said
that I should specify which of the new mandatory items I have problems
with. I responded by saying that using a list of neato-keano features
(with a smattering of Hard Requirements) as a specification of
minimally compliant behavior is, uh, not a good idea. You answered by
saying that I should specify which of the new mandatory items I have
problems with.
I said "Anybody home?"
HTH.
John Moreno
Greg Berigan <gber...@cse.unl.edu> wrote:
> Apologies to those seeing this twice. Apparently unlnews.unl.edu isn't
> propogating articles posted to it to even its sibling news server,
> crcnews.unl.edu. If you've seen this post before, please let me know.
> Searches on DejaNews and other servers turned up nothing. (I was
> wondering why my postings on this subject in this newsgroup weren't
> getting responses.)
Well, I've only seen it once.
> phe...@interpath.com (John Moreno) wrote:
>
> > New requirements
> > 7c) Ensures References will fit in 998 characters M
>
> Oh yeah, break newsreader software to cater to broken servers. INN
> 1.7.2 is in error requiring this header to be under 998 characters. You
> yourself said elsewhere software should accept everything given it. Fix
> the problem where it lies: with the servers.
That's right, and if you have a magic bullet that allow this to happen
with all of the servers that are being used which do this, I'd be happy
to see it used (but that doesn't get you out of trimming entirely).
I can give you the message id of 3 or 4 complaints about this within the
last 3 days - the software IS out there. Given this I'd say that there
are probably 300 that I haven't seen, where nobody bothered saying
anything about it because they couldn't figure it out.
> Meanwhile, I suggest some new thought behind this.
>
> Newsreaders must not always trim References. If there is a problem and
> the server rejects the article for excessive References (and notifies
> the newsreader in a way that this reason is detectable), the newsreader
> must note this and then and ONLY then trim the References, and only if
> it knows the server is operating under this brokeness. It must not be
> trimmed unnecessarily. The header should be folded to multiple lines if
> it even exceeds 80 characters and especially if servers will accept it
> folded.
The References header contains redundant information, as such, it should
only keep enough to provide error correction (delay propogation errors,
and out of order arrivials) not a complete history. Regardless of
whether there is a problem with the servers, Newsreaders should trim.
The USEFOR draft is putting a limit on the number of *IDs* that should
be kept - I think this is better for the future, but the GNKSA is more
appropriate for the present. Fortunately they aren't in direct
conflict, and can produce messages that are identical and conformant to
both. Unfortunately there is the potential for conflict - once the
draft is accepted the GNKSA should be updated to reflect that. I'd
recommend that 7c become a SHOULD while a MUST is added for compliance
with the draft. Or maybe a MUST that it should either do 7c or be
compliant with the draft.
> In general, the newsreader must report any error message the server
> gives it. Some newsreaders only say that the posting failed without any
> reason why. If the reason is given, the user can take action such as
> trimming references, quoted material, making sure Newsgroups and
> Followup-To don't list only newsgroups that aren't carried, etc.
>
> In this way, the user gets his articles out, and can know whether it is
> his fault or just a stupid restriction put on the server.
Again, this is a generally nice idea - but doesn't do you much good with
the existing software (server or newsreader).
> > [1.2 Uses 9 for something else]
> > 9) Allow the user to change her mind about whether to post or mail (or
> > do both) and behave if doing both
> > a) Allows users to change their mind and mail rather than
> > post after having initiated a followup message M
> > b) Allows users to change their mind and post rather than
> > mail after having initiated a reply message M
>
> This is an unreasonable burden to put on authors of pre-existing
> text-based software. You're viewing this at a GUI perspective where
> options to change posting or mailing method are present at all times
> during message composition.
Well, there are a lot of GUI software which doesn't allow this, and it's
perfectly possible to do it in a text-based program. A simple key
command for sending the edited message via mail, and different command
for news. Then query for the additional headers if necessary. Or you
could have a command that changes the headers and plunks you right back
to editting.
> I put it to you that the mail to news mind-change is covered by the
> existence of mail-to-news gateways, so in a sense all newsreaders pass
> on that point. They "allow" it. They just don't _provide_ for it
> themselves in a clear manner. (I expect you're going to revise this now
> to require they provide this.)
Mail-to-news gateways do NOT cover this - it's not reasonable to expect
the user to know even one mail-to-news gateway that allows them to do
this (although if the newsreader provided a easy way to automatically
change the To address to that of a gateway I might be converted).
> Also, how about the ability of editors to pipe their contents into an
> external command? Would this satisfy the requirements both ways?
Yes. Provided that they could do it interactively - i.e. start editing
and then allow the user to do it without doing something silly like
saving and then quiting and then manually piping it into a different
program. That's no more allowing the user to change her mind and maul
instead of posting than the fact that I've messed around with MacSOUPs
binary so it used '] ' for quoting should be grounds for saying that it
doesn't use the standard quoting convention. Extraordinary user action.
I would argue that a program that doesn't actually handle the mailing,
but instead hands it off to another program should pass on this. But if
the message is the posting/mailing is handled within one program that it
apply.
> > c) Does not offer both posting and mailing as default behaviour M
>
> Of this set, this is the only one that makes sense, except I think some
> posters might object that it would disallow their use of the
> Mail-Copies-To header which requests that posting and mailing be done.
> This requirement in the GNKSA would supersede their expressed desires.
> (Not that I even agree with the Mail-Copies-To header in the first
> place.)
Not really, as it means that USER can't configure his software to
automatically generate mail/news messages not that his software can't do
it in response to a users request.
One of the items in the 'Nice features not covered by the GNKSA' section
is support for the MCT header.
> > [New number and added for 2.0]
> > 17) Post human-readable articles unless ordered otherwise
> > a) Does not (and can not) encode or encrypt articles unless
> > on explicit user demand M
>
> So a user must be allowed to post a GIF in the message body without any
> text encoding, even when the software knows he doesn't want to do that?
> At the least, it should read "encode text articles or encrypt articles"
> to allow for automatic encoding of binary content that the user forgets
> is a requirement to transmit the article. Think of the bandwidth waste
> of sending those binary files in formats no one can use.
>
> The "Post human-readable articles" is not sufficient as it isn't in the
> direct wording of the 17a requirement which is the MUST.
No, the idea here is that it should only send plain text articles unless
the user explicitly request otherwise - if the user takes action to send
a GIF then the user isn't sending a plain text article and encoding is
allowed.
No, HTML, mulitpart MIME, VCARDS, or other, similar, attroicities
without explicit user command. Send this GIF is a explicit command.
That means that if you wanted every message to be in HTML or have a
VCARD attached that you (the user) couldn't configure your software to
do it automatically, the developer could allow this by use of a
keystroke or button or menu command after the message is started without
violating 17a. Just so long as it can't happen without user action
(skipping things like macros from other programs that might circumvent
this).
> > [New number and added for 2.0]
> > 19) Be kind to servers, leave room for others
> > a) Does not unnecessarily open multiple connections M
>
> Does Multi-Threaded Newswatcher fail on this account? Is its behavior
> in allowing the user to read other messages while pulling down a large
> binary an instance of opening multiple unnecessary connections, or are
> you specifically referring to the behavior of browsers with news
> servers? I agree the browsers' behaviors are abusive, but I don't think
> MT-Newswatcher's behavior should be lumped into the same category as it
> is now.
>
> (Note: this browser behavior is not exclusive to news servers. They
> also will start downloading binary content, then abort and immediate
> restart downloading the exact same content, both by HTTP and FTP,
> because they assume they can display it in the browser window and, to
> switch to download mode, have to restart the transfer. They don't think
> of checking filename extensions first, something they should be doing
> for FTP. They cannot apparently hand over an open stream to the
> download routines; those routines have to open the stream themselves. I
> wouldn't be surprised if they double-hit MIME-encoded news articles
> too. Anyone got any data on this?)
I wonder why they can't pass it along? But, I haven't done any testing
of any of the browser newsreaders, so I can't say what it does with
MIME. I can say that OE for the Mac doesn't do this, but it's not
really a browser newsreader.
> > b) Does not generate excessive server load otherwise M
>
> "Excessive" is a highly subjective term. I would like to see this
> spelled out in a bit more detail.
You've got to remember that this is the check list for the review not
the specification as to what exactly the item is.
That said, you're right, since the actual specification isn't much
better. I believe that it's going to be changed soon to:
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 as possible, and never more
than 4, simultaneous connections. Also, it MUST NOT open consecutive
connections unnecessarily: once open, existing connections should be
reused whenever possible.
Rationale: News systems are big, resources are scarce, and every
resource claimed is provided at the expense of other users.
I don't know if Jeroen intends to change the wording of the check list.
The consecutive connections is about the "excessive server load", and
I'm not sure about how much detail the GNKSA should go into - how long a
connection should be open before being closed can depend upon a lot of
things.
> > I'd also like a final 3 0r 4 sentences explaining why these requirements
> > are so far outside the realm of "minimal" that talk about starting all
> > over again shouldn't be considered going a little overboard.
>
> I think I've been pretty clear about my objections to these, mod the
> ones I'd like a bit more explanation on. I don't entirely disagree with
> them all, but I do believe they deserve closer scrutiny.
I've got no problem with taking another look at them, it's just that
when you object you need to detail what it is - otherwise it's never
going to get changed.
In fact there is a SHOULD *I'd* like to see dropped - one that was in
1.2 also (was 9d, now 10g). I don't think it is desirable to have the
message id in the attribution under most circumstances - if it's
included in the references like it should be then it's not needed. I
will admit that I have made good use of it actually being there - but
only with messages from people who didn't include a references header at
all (I added one using the one in the attribution). And only until I
could talk them into getting better software that did do references.
> > This would give us something to discuss, as it is you are just making
> > flat statements and leaving it at that.
>
> I think I've left plenty open for discussion, and looking forward to it.
> Perhaps we can get a better GNKSA 2.1 out of this.
Great.
--
John Moreno
John Moreno
Lars Magne Ingebrigtsen <la...@ifi.uio.no> wrote:
> phe...@interpath.com (John Moreno) writes:
>
> > Where you said that you didn't want to give specific objections.
>
> I'm sure you can provide the quote where I said that. Right?
Does the phrase "Your wish is my command. Not" ring any bells. I ask
for a discussion of specific items and that was your response.
> Here's a recap of the events: I said that using a list of neato-keano
> features (with a smattering of Hard Requirements) as a specification
> of minimally compliant behavior is, uh, not a good idea. You said
> that I should specify which of the new mandatory items I have problems
> with. I responded by saying that using a list of neato-keano features
> (with a smattering of Hard Requirements) as a specification of
> minimally compliant behavior is, uh, not a good idea. You answered by
> saying that I should specify which of the new mandatory items I have
> problems with.
>
> I said "Anybody home?"
Then be specific about your objection to particular "neato-keano"
features. The only feature that I think /might/ fit that definition is
14d.
"It's a neato-keano feature list." "What neato-keano features?"
"Neato-keano features don't make a good spec." isn't a very productive
conversation.
And I STILL think that even if this was true, that the place to start
would be with the hard requirements. After they have been agreed upon,
it's easier to change/eliminate any of the SHOULDs.
--
John Moreno
Karl Kleinpaste
phe...@interpath.com (John Moreno) writes:
> Then be specific about your objection to particular "neato-keano"
> features. The only feature that I think /might/ fit that definition is 14d.
9(a) and (b). Do away with these entirely. They don't even deserve
SHOULD status.
Lars Magne Ingebrigtsen
phe...@interpath.com (John Moreno) writes:
> > > Where you said that you didn't want to give specific objections.
> >
> > I'm sure you can provide the quote where I said that. Right?
>
> Does the phrase "Your wish is my command. Not" ring any bells.
Uh, yes. How does that translate to "didn't want to give specific
objections"? In case you weren't paying attention, that was in
response to your "Start with the MUST, after they have been discussed
move on to the SHOULDs." commandment.
> And I STILL think that even if this was true, that the place to start
> would be with the hard requirements. After they have been agreed upon,
> it's easier to change/eliminate any of the SHOULDs.
Tell me why I should care one iota about your silly list of features
you think newsreaders should have. 1) It's not a standard. 2) It has
many items that have absolutely nothing resembing a consensus on. 3)
It has no credibility.
Who cares?
John Moreno
Karl Kleinpaste <ka...@jprc.com> wrote:
> phe...@interpath.com (John Moreno) writes:
> > And the MUSTs (since they are the actual requirements to pass) are much
> > more important to that credibility, address them first and then the
> > SHOULDs. The SHOULDs only have importance /after/ all of the MUSTs have
> > been satisified.
>
> Fine, John, here's my take on your MUSTs.
>
> I went back a half dozen articles in this thread and found your 7 new
> MUSTs. The short version is: Half of them are ridiculous or pointless.
>
> I especially regard the new MUST qualifier on the "post/mail change-
> of-mind" issue to be utterly nonsensical. There have been ways of
> changing one's mind in midstream since the dawn of Usenet, and your
> new demand that all newsreaders provide it as an intrinsic function is
> wrong. My newsreader, Gnus, even provides it, but it's *fluff* and
> nearly unused. The fact that most newsreaders require one to do some
> sort of save/abort/restart in order to change one's mind is a feature,
> in my opinion, because the manner of address to both the preceding
> author and the subject matter is liable to differ based on whether one
> is addressing an individual or a larger audience. E.g., one's choice
> of quotation (both style and extent) may change; one may discuss
> information known only between the two parties when going to mail,
> which then becomes incorrect if one changes one's mind to post. Other
> examples abound.
Excellent. Thank you.
So, you have at least one good points (about quoting style), but 1) If
the article is being read using a online newsreader it may not BE there
for the user to change her mind latter. 2) Save/abort/restart is hardly
something that the flood of new users is going to consider even if they
could figure out how. 3) Content - that's excactly why you want to be
ABLE to change, after starting you've found that the discussion is going
in a different direction. This allows the newbies to not post messages
concerning how cute their kid was when it was born.
> I also take issue with the "be kind to servers" list because it is
> open to interpretation whether newsreaders employing a 2nd (not an
> arbitrary Nth for large N) connection for article read-ahead is
> "unnecessary" or not. At a minimum, the phrasing is poor; and if
> someone now intends to tell me that either a double connection or
> article read-ahead is wrong, I'm going to tell you where to stuff your
> new non-standard. Also, the interpretation of "do not generate
> excessive server load" is so ambiguous and open to interpretation as
> to be meaningless.
>
> You wanted "3 or 4 sentences" on the MUSTs, so now you've got them.
Your right, it should be firmed up (although that may or may not require
a change in the check list - remember that the check list is a
abstraction of the actual GNKSA). And in fact this was brought to
Jeroen's attention just recently.
> Now, aside from the new MUSTs, there is the whole issue of the
> SHOULDs. SHOULDs should not be used much -- it leaves too much open
> to debate. If a newsreader is capable of achieving "PASS" based on
> the MUSTs and yet fail to provide even one of the SHOULDs, one wonders
> what value the supposed standard has provided, since it's clear that
> all those SHOULDs really don't mean squat. That is the problem I
> perceive, and that is why the cute-feature-laden view of lots of
> SHOULDs irritates me so.
SHOULDs were used in both the old and the new GNKSA (13 in the old was
completely filled with SHOULDs, it's 14 now and that hasn't changed
except to add one new item). The majority of the SHOULDs are of warning
or terminology or firming up the previous requirements.
Take for example 10c - previously it was a requirement that quoted
material be clearly distingushed, but no guidelines were set as to what
that should mean. 10c was added to make it clear what was expected -
and don't say that isn't necessary as Jamie was on here just a month or
so ago asking for specs that mentioned quoting style as the marketing
dweebs at Netscape wanted to do something weird.
> Both of these situations (bogus MUSTs & SHOULDs which have no meaning)
> diminish the credibility of the supposed standard, to the point where
> it will be ignored.
SHOULDs have never had any meaning except possibly in a rating manner
(who passes and meets the most SHOULDs). They are there to list
actions/options that aren't serious enough to forbid/require but should
be given careful consideration. If you want I can give you a complete
list of new 'soft' requirements, along with a list of previous 'soft'
requirements and you can pick out which ones you don't think fit that
critera (or what ever critera you feel is appropriate).
> Now, I don't know what jwz will be doing with the Netscape news interface,
> but it's pretty clear that Lars couldn't care less whether Gnus
> accommodates GNKS any more, and you have only yourself to blame for that
> condition having arisen. I wonder how many other newsreader authors have
> considered this new GNKS in detail, and are now considering whether, or
> have already decided, to toss out the window the entire goal of GNKS
> compliance.
I have reviewed most Macintosh newsreaders and sent the completed review
to the authors, and except in the cases where they were no longer
developing it, have gotten very favorable responses. John N. (NW)
jumped right in and got a new version that was compliant out within a
month, Simon Fraser (MT) should be releasing a update very soon. Stefan
Haller (MacSOUP) is compliant. And the commercial newsreaders have been
responsive - but are mainly focusing on stability at the moment.
> GNKS was once an admirable goal, albeit a hideous thing to which to
> have resorted when it first came out 3+ years ago -- the very
> incarnation of "necessary evil" which managed to transmutate into a
> positive thing when a lot of newsreader authors rallied around it so
> well. It is no longer a goal at all any more, because of its
> preoccupation with fluff.
Well, I don't think it's preoccupied with "fluff" there are very few
things in the SHOULD list that I think could be done without, and at
least one of them has been in there since the beginning.
And, like the MUSTs, they should be dealt with indvidually, not as a
group.
--
John Moreno
Greg Berigan
j...@xs4all.nl (Jeroen Scheerder) wrote:
> but a `rn' GNKSA review would be nice, yes.
Well, a review was done once for straight telnet to port 119 as a
newsreader. I don't recall the results though.
--
_-<#)-=# http://incolor.inetnebr.com/wotw/
___/___
_-~_--<###) Due to widespread abuse, I no longer read any messages
<~c>' __--< from users who employ munged addresses in their headers.
\_--=____#) Richard Hart and Justin Gunn of C|NET, this means you too.